msmmmmm fl EM _m loii aw&fiS nflramc i|Xu| BVi9n^uiuiMi IK^BI ■HB WBuWR m •WHM Bel wBr BBSS Hi H rait JSKSffif Biffi Hmw»Wv IB (Ml H IS MfXl H Bra DDfl 1 ■flHtHI HHu ■H H [HI HI MMBliMHi LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN oof • *• Digitized by the Internet Archive in 2013 http://archive.org/details/gpsssimulationof528salz ■ UIUCDCS-R-72-528 TrjaXi "L A GPSS SIMULATION OF THE 360/75 UNDER HASP AND O.S. 36O by Fred Salz June 1972 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS THE LIBRARY OE THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN A GPSS Simulation of the 360/75 under HASP and O.S. 360 by Fred Salz Department of Computer Science University of Illinois Urbana, Illinois (This research was supported in part by the National Science Foundation under Grant No. NSF C-J 28289). I would like to thank Bob Skinner for his assistance in supplying the necessary information regarding the I.B.M. 360/75. ABSTRACT The success or failure of a computing system in today's highly competitive market is often determined by the efficiency of its operating system. Consequently, existing operating systems are constantly being modified, extended, and, hopefully, improved. The key question pertaining to the implementation of proposed changes is "Does the proposed change improve the existing operating system?" One appealing method of answering this question is to simulate the operation of the computing system both under the existing operating system and the system with the proposed changes included. The obvious first step in such a study is to build a model to simulate, with accuracy, the existing system. In this paper, such a model is presented for the IBM 360/75 operating under HASP and O.S. A GPSS simulation of the system is presented and some results are given which verify the accuracy of the simulation. I, Introduction In order to study the effect of new computer system proposals, a number of techniques may be employed. One method is to write the new feature into the existing system and run tests. Obviously, for a complex change, this would be extremely costly in both the programmer's time, and unproductive machine time. An analytical model could be devised based on queuing theory analyses, but it would become extremely burdensome for a complex situation. A third method, and the one to which this paper is directed, is to simulate the proposed changes on the computer system currently in use. This results in a minimum of time that is not spent running users programs during the analysis. For a simulation to be of value however, it must be accurate both statistically and functionally. In order to be certain that analysis of changes based on the simulator are realistic, the model performance must be measured against a known quantity, i.e., the existing system. For this reason, the model described in this paper is a representation of the IBM 360/75 operating under HASP and O.S. Once it has been shown that statistics from the two sources agree, the model can be used for its intended purpose, that is, an evaluation of new proposals. II. Model Description A. System operation 1. HASP Initiation Jobs are fed into the system simultaneously from terminals, tape, readers, disks, and other devices. As a job arrives, it is placed onto the HASP SPOOL (which has a limit of ^00 jobs). If the spool is full, either input unit is detached, or the job is recycled back out to tape to be re-read later at a controlled rate. Once spooled, the job is given a HASP class. In the case of the U. of I . system, the class is assigned based on estimates of CPU time, I/O requests, and lines printed. Each job must go through a sequence of events in a set order, i.e. initiation, execution, printed output, termination, etc. This sequence is controlled by a progression list, which is included in the job information data. The job waits on the SPOOL until selected by a HASP initiator Each of the 7 initiators can be set to recognize up to h different classes of jobs, in a specific order. It is in this order, that a free initiator will take a job off the SPOOL and feed it to O.S. For example, if an initiator is set CBA, it will first search the spool for a class C job, if not found it will look for a class B. If there is no B job, and no A job either, the initiator will be put in a wait state. Once the job is selected, it is put on the O.S. QUEUE to be serviced by the operating system. 2. O.S. Initiation Once a job is placed on. the O.S. queue, there is no longer any class distinction. There is another set of initiators that select jobs in a first- come first-served manner and removes them from the O.S. queue. It is the function of these initiators to take the job through the various stages of execution. The JCL for the first (or next) step is scanned for errors, and if everything is satisfactory, data management is called to allocate devices as described on the DD statements. The initiator waits for completion. The O.S. Supervisor is then called to allocate core space. The first block of contiguous core large enough to contain the step request is allocated to the job. If no such space is available, the initiator must wait, and is therefore tying up both the OS and HASP initiators. No procedures exist for compacting core to avoid fragmentation. Once core is allocated, the program is loaded, and the job is placed on a ready queue with the highest nonsystem priority. 3. O.S. Scheduler Jobs are selectively given control of the CPU by the O.S. Scheduler. The job with the highest dispatching priority is given control until an interrupt occurs - either user initiated or system initiated. HASP - Dispatcher Every two seconds, a signal is sent by the dispatcher which interrupts the CPU if busy. All of the jobs on the ready queue are then reordered by the assignment of new dispatching priorities based on utilization in the previous 2 second interval. The job that has the lowest ratio of CPU time to I/O requests will get the highest dispatching priority, e.g. - the jobs that used the least CPU time will tend to get the CPU first on return from the interrupt. During this time, HASP updates elapsed statistics, and checks these against job estimates, and will terminate the job if any have been exceeded. (. HASP - Termination When execution of the job is completed, control is returned to the HASP initiator to proceed with job termination. Accounting is updated, the progression list is set to completion, and Print or Punch service is called to produce the actual output. Purge service is then called to physically remove the job from the system. The initiator is then returned to a free state to select a new job from the spool, i. Express Since express is available on the 360/75 » it had to be represented in the simulation. There are two major differences between events as a job goes through express rather than HASP. First, an express job does not request core, since a piece is dedicated to it at all times. Therefore, in the simulation model, when an express job is initiated, the core allocation routine is bypassed. Since devices are not allocated, and other system procedures are not necessary, the overhead time normally associated with these functions is not executed. This will be fully discussed in the next section. Figure 1 shows the system as modelled. READERS PAPER TAPE (terminals) - I TAPE \ KJ SPOOL LOGICAL STRUCTURE - HASP HASP Initiators (Initiator Flow) (Job Flow) BPOOL PLACE JOB ON O.S. QUEUE JOB ACCOUNTING OUTPUT HASP DISPATCHING PRIORITY CHECK LIMITS REMOVE NEXT JOB FROM O.S. QUEUE PREPARE TO RUN NEXT STEP CALL SUPERVISOR TO ALLOCATE CORE SPACE LOAD AND EXECUTE PROGRAM O.S. Initiators SCHEDULER (Yes) XMORE JOB \(Mo) Return Initiator PEPS yS~ 1 / (No) Job Flow STEPS ? Figure 1 LOGICAL STRUCTURE - O.S. 3°0 B. General Model Theory 1. Representation of O.S. entities by GPSS. Before constructing the model of the 360/75, it was necessary to decide how specific entities of the real system would be represented "by the model. The method used had to both resemble the real system in its operation, and be compatible with the rest of the GPSS program. The first issue that had to be decided was the length of the clock unit. Since only one clock interval length could be used throughout the simulation, a unit that was small enough to represent very small time slices while allowing larger units of time (such as 1 hour) had to be chosen. It was decided that each GPSS clock unit would be one millisecond. Since there are events that require less than 1 ms . of time to complete, and this time had to be accounted for, it was included in the general system overhead. For each job run, a certain amount of time is spent in initiation/ termination, reordering of dispatching priorities, etc. This could have been handled in one of two ways, the first being a strict addition of one or two milliseconds each time a certain operation by the system was to be performed. The second is to account for all system time in one piece, at some point in execution. The later was chosen for the following reasons: It is not accurately known how much time is spent performing each task (e.g., one millisecond or two, etc.). Therefore, each time this time is used, an error will be added. For example, in five minutes of simulated time, approximately 11,000 time slices would be run, the chains would be reordered 150 times, etc., with each function involving many segments in which overhead must be accounted. If there is a 10$ error per operation amounting to 1 millisecond, with say 10 of these operations per time slice, this would result in at least a 110 second error in this area alone, or 3.6 seconds per job, (based on ^0 iobs run in this time) . On the other hand, if the same error occurs in the IBM statistics showing an average of 5 seconds initiation/termination time and system over- head this would result in only a 500 millisecond per job error. In the same period of simulated time, 30 jobs will complete execution, resulting in a total error of only 15 seconds. Therefore, I have considered that each job (with express as an exception) must execute a fixed amount of overhead. This is accomplished at the end of execution of all job steps. This time is then broken into two pieces - one part being executed while the job retains its current core allocation, and one part executed after deallocation has occurred. Since the dispatcher on the other hand only performs its task once every 2 seconds, a constant overhead time for that section is defined and executed. It should be noted that all overhead times, as other constants, are initialized as variables and can be changed as more accurate information becomes available. The logical structure of the simulator is shown in Figures 2a and 2b. 1. Jobs A job is represented by one GPSS transaction with U8 parameters. The parameters, shown in Table 1, are referenced throughout the simulation to keep a record of what was done, and indicate what the next step will be. In this way, by moving the "job" from one section of the model to another, it could indicate different stages of execution. 2. HASP and O.S. Initiators In reality, there are two sets of initiators, one for HASP, and another for O.S. They each require the same information about the jobs they are servicing, SECTION II 3ECTTON I ASSIGN UMBER, CLASS SIGN REQUESTS OR EACH STEP IME,l/0,CORE) PUT JOBS ON SPOOL ASSIGN NUMBER MAKE CLASS SETTINGS (UNH) UNLINK JOB FROM SPOOL (E NTER) V INITIALIZE JOB (ENTl) INITIALIZE STEP REQUESTS SECTION III Figure 2a SECTION IV (Yes) (RUNB) UNLINK FROM READY QUEUE ASSIGN SLICE CHECK LIMITS SECTION V (EXEC) DISPATCHER INTERRUPT EVERY 2 SEC. RUN JOB FOR THIS SLICE (WAIT] ISSUE I/O REQUEST (ACT Yes ASSIGN CORE LINK TO READY QUEUE (RLINK) UPDATE ELAPSED STATS SECTION V (CONT'd) (EXECh] RETURN TO READY QUEUE (EXECil DE -ALLOCATE CORE UPDATE STATS RECORD TIMES (PUNK) (Yes) (EXEC 8) (Yes) ENTER COMPLE- TION TIME [FREE INITIATOR WRAP UP (EXE12) LINK TO COMPLETED CHAIN (NQT» V SET JOB TO IN CORE OVERHEAD SECTTON VT {EXEC 7) RESET CORE MAP FREE JOBS AWATTTNG CORfl SET JOB TO OUT OF CORE OVERHEAD £EXE10) RETURN TO READY QUEUE WAIT TWO SECONDS INTERRUPT CPU 1 RE-ASSIGN DISPATCHING PRIORITY RE-UNK JOBS TO READY QUEUE Figure 2b 11 and the HASP initiator for a specific job must be dormant while the O.S. initiator is running and vice versa. Therefore, 7 transactions were created, each of which represents "both HASP and O.S. initiator. Upon creation, each initiator is assigned up to h class settings, which could he changed at any time. Class A=l, ..., express=5. They are then put in an inactive state awaiting the arrival of jobs into the system. After the initiator completes initiation of a job and places it on the ready queue, the HASP initiator becomes an O.S. initiator. It is the O.S. initiator that flows through the core allocation routine to request core space, and finally places the job on the ready queue to run. This initiator then becomes dormant waiting for the job (or job step) to complete. When the entire job completes, this initiator is returned to the section of the simulation where it again performs the function of HASP. 3. Queues All HASP and O.S. queues are represented by user chains. This allows ordering of the objects on the queues, while gathering waiting time and size statistics, and allows arbitrary manipulation of the elements on the chains. There is a separate chain for each of the five classes of jobs (1-5). This allows for an efficient method of checking if any jobs of the desired class exists, by merely checking the length of that chain. This scheme also returns waiting statistics broken down into each of the four classes, since each chain is independent. Whenever an initiator or job is to be put in a wait state, it must be taken off the current events chain, and therefore, it is placed on a chain 12 representing that condition. Initiators waiting for jobs are put on chain 6, and initiators waiting to assign core go to chain 9. When a job arrives, all transactions are unlinked from 6, and when any job deallocates core, chain 9 is emptied. Jobs that are waiting for core are placed on chain 5. When its initiator is notified that core has been allocated, the waiting job is put on the ready queue (chain 8) according to the contents of Parameter 7 (dispatching priority) to execute. Representing this queue as a chain, allows for this ordering. k. CPU Usage - Scheduler The scheduler has the responsibility of determining which task will next get control of the CPU. The scheduler is represented by one high priority transaction that unlinks jobs from the chain they are waiting on, and lets them seize facility 1 thorugh h depending on the current status of the job. While advancing the clock in the facility, no other transactions are permitted to do so. Other transactions may, however, enter advance blocks representing I/O requests, and other system processes may take place. This is a rational approach since many functions in the real system are actually carried out in parallel. When a transaction releases the facility, control is returned to the scheduler which gives the next ready job control of the CPU. 5. The Dispatcher The HASP dispatching priority reassignment is carried out by one final transaction. Every "2 seconds", this transaction is given control of the simulator, and proceeds to reorder the jobs on the ready queue (chain 8) and the jobs waiting for I/O requests (chain ll) . The job currently in control of the CPU (if any) is interrupted, and placed back on the ready queue according to its new priority. 13 When all of the reordering is complete, the scheduler is freed, and the dispatcher is made dormant for another two seconds. Communication between Program Sections For any of a number of reasons, certain sections of the simulator must operate in synchronization with other sections. The most frequent example of this situation occurs when a transaction that is not representing a job (i.e., an initiator, dispatcher, etc.) must access information stored in a job transaction's parameter. Since no transaction can access the parameters of another, the "job" must be given control of the simulator, while the transaction desiring the information is forced to wait. In this situation, the transaction desiring the information sets on logic switch, and waits for it to be reset, or it enters a buffer block, depending on the relative priorities of the transactions. Since the transaction containing the information is now on the current events chain, it is given control of the simulator. It then passes the desired information to the requesting transaction, usually through a savevalue or matrix savevalue, or it changes information within itself (such as dispatching priority). When completed, the logic switch is reset, and control is given back to the requesting transaction. Examples of this type of communication can be seen following block UNH in section II, as information about a job just selected is passed back to the initiator. Another area that requires synchronization is the scheduler. Once a job is given control of the CPU, no other one may do so until the previous one has completed. Again, a logic switch is set by the scheduler ( #51) when a job is given the CPU, and the job resets it when completed. More discussion in detail will be found in later sections. 1U C. Specific Model Operation In order to fully understand the detailed operation of the simulator the following paragraphs describe the individual sections of the program, and should he used in conjunction with the program flow chart and listing in appendices A and B. Specific blocks are referenced by block name. The word in parentheses on the listing at the beginning of each program segment designates the type of transaction flowing in that section. Section I - Creation of Job Stream. Each of the two generate blocks in this section create transactions with a priority of 100 (for reasons that will become evident later), and U8 fullword parameters . To look at the system at the normal load level, without waiting for the queues to build up, initial jobs are created (NOTl) and placed on the appropriate chains. A separate class assignment is made since no express jobs originate on queues. The generate block at (N0T2) creates transactions exponentially with a mean interarrival rate defined in V"60 . The transactions from both generate blocks continue from block BE GIN . As a job is created, the transactions that are waiting on chain six (initiators) are unlinked to test the new job. Since the jobs have a priority of 100, and the initiators a priority of 50, all of the ent erring jobs will link themselves to chains 1-5 before the initiators gain control of the simulator, which is the desired sequence of events. The assignments that are made at this point are commented on in the listing. 15 The PRIORITY block at INITF is a dummy block that sets the status change flag. This insures that if the arrival of this job effected any- higher priority transactions that already gave up the simulator, they will get another chance to run. The jobs are then linked onto the chain for their job class, whose number is in parameter 2, and the unlinked initiators are free to run. Section II - Creation of Initiator /Terminators Seven initiator /terminators are created with a priority of 50, and containing the default of 12 fullword parameters. The assignments made at N0T3 come from the temporary information stored in matrix INFO, and the cells are cleared when the information is received. The class designations are stored in Parameters 2-5. At UNH1, the initiator checks the chain corresponding to its primary class for the availability of a job. If the chain is empty the other classes in P3-P5 are checked beginning at TEST1. Section Ha If no suitable jobs are found, the initiator is linked to chain 6 to await the arrival of new jobs. When a match is found, the class of that job is stored in savevalue. TEMPI, and one job from job from that chain is unlinked and sent to ENTER. In order to pass the initiator number to the job, it is stored in savevalue 6, Control now must be given to the job in order to pass information to the initiator and matrix INFO, as well as to initialize the first job step. This is accomplished by the blocking process described in its place earlier, (i.e. in this case a BUFFER block). 16 The job passing through section lib makes the assignments described on the listing. The blocks from ENTER to ENT1 are executed only at job initialization. Those following ENT1 make the initializations for each step, and therefore are executed at the beginning of each step. Parameter 12 is used frequently in the model to allow indirect addressing of other parameters. The intent of the block at ENT1 and the one following is to access information stored in the parameter whose number is determined by Vkl. The method employed here is the most efficient allowed by GPSS . The job is then linked on a chain waiting for core to be assigned. When control is returned to the initiator, it receives the information passed to it, and transfers to section III to request core. (UNH2) Section III - Core Allocation Since the system essentially contains 600k of core allocated in a minimum of 2k chunks, core in the model is represented as 300 units. If EXPRESS is simulated, this figure is reduced to 200. The algorithm used is that the FIRST available CONTIGUOUS block large enough to contain the job is allocated. The logic behind blocks REQN through REQF can best be seen on the flow chart. The four blocks surrounding REQA loop through the section of "core" allocated to the job, placing the job number in the cell. This prevents the cell from being allocated to any other job, and can give a pictoral representation of the core map if desired. The time the request was filled is passed to the job, and the job is released from chain 5 and sent to section Ilia to be prepared for running, while the initiator links itself to chain 7 to await completion of execution. IT Section. Ilia determines the mean running time bet-ween I/O requests, and records other information about its current status. The job then signals the scheduler that there is something on the ready queue, (presetting logic switch 50) and links itself to chain 8 according to dispatching priority. Section IV - Control Section The control section of the program insures that only one task uses the CPU at any one time. All transactions that use the CPU (except the dispatcher) are on chain 8, and only section IV unlinks transactions and sends them to section V to execute. The ready queue (chain 8) is tested for the presence of a job. If none is found, logic switch 50 is set to block the scheduler, until another job enterring the queue resets it. If a job is present, it is sent to section V (EXEC) to run, and the scheduler is blocked until the job interrupts. When the job returns control, the scheduler is free to look for the next job, even though the previous one has not returned to the queue. This is further discussed in the details of section V. Section V - Job Execution Jobs that are to be given control of the CPU are sent to EXEC, where preliminary actions are taken before running. Savevalue SLICE is assigned the number of milliseconds the job will run before interruption due to an I/O request. This is determined by an exponential distribution about the mean in parameter 17»assigned in section Ilia. The minimum slice allocated is one millisecond. The block at EXECA tests to see if the elapsed time for the step plus the new slice is greater than the total time requested for the step. 18 If so, the slice is reduced to the remaining time until completion. If not, the facility whose number is in PU8 (PU8 is the job status indicator) is seized. The facility entity was used to represent the CPU for a number of reasons. First, the statistics gathered by a facility are the most valuable in this case (Percent utilization, etc.). Secondly, the facility may be interrupted, thereby allowing the dispatcher to reorder the ready queue every 2 seconds. (See section Vl). And thirdly, by using different facilities for different functions (specified in PU8) separate statistics can be accumulated. Once the facility is seized, the slice is advanced, the elapsed times are updated, and control is returned to the scheduler by resetting logic switch 51. Parameter h^ and U6 contain the number of milliseconds and I/O requests respectively issued since the last dispatcher interrupt. Note that even though the scheduler is freed to give another job the CPU, the current job is not returned to the ready queue. Blocks EXEC3 through EXECU simulate the I/O request time. In order to facilitate the reassignment of dispatching priorities, each transaction issuing an I/O request is split in two. Since jobs may be in an advance block when the interruption occurs, they cannot be removed to do the reassign- ment. Therefore, the original transaction is placed on chain 11 where the dispatcher is free to unlink it and link it back, while the copy waits in the advance block. When the time for the I/O request is complete, the copy unlinks the original, sends it to RLINK, and terminates. At RLINK, the step wait time is updated and if the step hasn't completed it is relinked to the ready queue. 19 To understand the logic of the procedures followed when a step completes, it is necessary to refer to the general flow diagram in Appendix B. The actions taken under different conditions is described below, and may be taken in an order not identical to the block diagram. a. Job just completed execution of step, but all steps not complete. (EXEC T) • If the number of elapsed I/O requests is less than the number requested, the remaining requests are issued. The core space given to this step is deallocated and all jobs waiting for core are free to inspect this new segment. The core allocation information in INFO is cleared, and the job is sent to EXEC9, where step statistics are recorded. The job is now transfered to ENT1 in section lib for the new step requests to be initialized b. Job has just finished executing all of its steps (NOT h) . Appropriate indicators (in INFO and PU8) are set to indicate the job is to run its overhead while in core (see section J) . The step end stats are seconded, initializations are made so the overhead can be run, and the job is placed back on the ready queue. c. Job has just finished running overhead in core. (NOT 5) • Indicators are set for running overhead out of core, and initializations are made to run overhead out of core. The job is placed back on the ready queue, after core is deallocated. d. Job has just finished overhead out of core (EXEC 8) . This marks the end of execution for this job, and all final statistics are recorded, as commented on the program listing. The initiator for this job is freed, and the job is placed on chain 10 to be printed out at the end of the run. 20 Section VI - The Dispatcher f. The dispatching priority reassignment as previously described is carried out by one final transaction flowing through the "dispatching section". When the transaction awakes after two seconds, it interrupts the CPU. The Facility representation was chosen for the CPU so that it could he preempted by the dispatcher. The preemption merely removes the job in the advance block and places it back on the ready queue, without allowing the scheduler to continue running jobs. In this way, all jobs not issuing I/O requests are in the same place (i.e. on the ready queue) so their priorities can be revised. All of the jobs on the ready queue are unlinked and proceed to change their own priorities. This is the most practical way of accomplishing this, since only the transaction itself can reference its parameters, which in this case contain all of the necessary data. Once the reassignment is completed, the jobs are relinked onto the ready queue (chain 8), the scheduler is freed, and the dispatcher goes to sleep for another two sections. 21 D. Discussion of output data As an aid to understanding some of the statistics available from the simulation, same sample output data is shown in Figures 3-5. The results represent 1 hour of simulated time and required 9 minutes of 360/75 processor time for execution. The amount of core needed to run the simulation -will vary depending on what information is kept throughout the run. For example, if all completed job transactions are kept, the larger (256k) version of GPSS will "be required, with a certain amount of reallocation (see GPSS operation's manual). If these transactions are terminated, the ll6K version would be sufficient, with minor reallocation necessary. In studying the statistical printout, it should be noted that the arrival rates used are derived from a monthly average, and therefore utilization figures, queue sizes, etc., will seem low for a normal daytime period. For details of times and constants used, see the initializations and variable definitions on the program listing in appendix B. The facility statistics are shown in Figure 3. Facility 1 represents the CPU time used for user problem programs, and shows a 19.6% utilization. The number of entries (63, 121) are the number of time slices allocated, with the average being 11. 22^ milliseconds. SEIZING PREEMPTING TRANS. NO. TRANS. NO. 241 241 ACILITY AVERAGE NUMBER AVERAGE UTIl . I Z AT ION ENTRIES TINE/TRAN 1 .196 63121 11.224 2 .082 551 541.948 3 .082 534 557.115 4 .024 1757 50.0C0 5 .362 63558 20.525 Figure 3 22 Facilities 2 and 3 represent the CPU usage for in core and out of core overhead discussed earlier, and Facility k is the dispatcher's use of the CPU. The total of 1, 2, and 3 is shown in Facility 5. User chains 1-5, shown in Figure k t are the queues for job classes A-EXPRESS as discussed in section II-B-d. The average time /trans act ion entry is the expected waiting time, and the average contents is the expected number on each of the queues. Note that there was no class h initiator set, and therefore, the current and maximum contents for class h are equal. :hain TOTAL AVERAGE CURRENT AVERAGE MAXIMUM ENTRIES TIME/TRANS CONTENTS CCNTENTS CONTENT* l 54 21907.386 .32 8 8 2 59 291859.437 4.783 1 1 3 10 163^91.000 1 .454 2 17 4 17 1972960.000 17 9.316 5 104 1690.451 .054 2 6 659 15618.820 4 2.359 6 7 258 41080.484 3 2.944 6 8 65457 58.274 2 1.059 5 9 187 23039.699 1.196 4 10 223 931415.375 105 57.695 118 11 566C6 96.8C4 1.522 6 13 154 27976.777 1.196 4 14 118 1800000.000 113 59.000 118 Figure k Chain 8 is the ready queue and shows that the average job had to wait 58. 27^ milliseconds before regaining control of the CPU after an 1/0 request. For details of the other chains, see Table 1. Tables 1-5, Figure 5 , measure the average turnaround time for each job class. The mean argument is the expected time in the system. Figure 6 shows a few sample completed jobs. With the aid of Table 2 , the information available is evident. r* e 1 EN IES IN TABLE MEAN ARGUMENT STANDARO DEVIATION 54 86475 ,75C 79872. 000 UPPER CBSERVEO PEF CENT CUMULATIVE CUMULATIVE LIMIT FREQUENCY OF TOTAL PERCENTAGE REMAINDER .00 .0 100.0 25000 16 29.62 29.6 70.3 50000 9 16.66 46.2 53.7 75000 5 9.25 55.5 44.4 100000 5 9.25 64.8 35.1 125000 3 5.55 70.3 29.6 150000 4 7.40 77.7 22.2 175000 3 5.55 83.3 16.6 200000 4 7.40 90.7 9.2 225000 1 1.85 92.5 7.4 250000 .00 92.5 7.4 275000 3 5.55 98.1 1.8 300000 .00 98.1 1.8 325000 1 1.85 100.0 .0 HklNING FREQUENCIES ARE ALL ZERC .E ■IES 2 IN TABLE MEAN ARGUMENT STANDARO DEVIATION 57 448727 .612 166400. 000 UPPER OBSERVED PEF CENT CUMULATIVE CUMULATIVE LIMIT FREQUENCY OF TOTAL PERCENTAGE REMAINOER .00 .0 100.0 25000 .00 .0 100.0 50000 .00 .0 100.0 75000 .00 .0 100.0 100000 1 1.75 1.7 98.2 125000 1 1.75 3.5 96.4 150000 .00 3.5 96.4 175000 1 1.75 5.2 94.7 1 200000 2 3.50 8.7 91.2 | 225000 .00 8.7 91.2 250000 1 1.75 10.5 89.4 275000 3 5.26 15.7 84.2 ■1 300000 .00 15.7 84.2 i 325000 .00 15.7 84.2 DVERFLCW 48 84.21 100.0 .0 AVERAGE VALUE OF OVERFLOW 496389.62 1 LE 3 6R1ES IN TABLE MEAN ARGUMENT STANOARD OEVIATIC 8 300598 75 C 158464. 000 UPPER CBSERVEC PER CENT CUMULATIVE CUMULATIVE LIMIT FREQUENCY OF TOTAL PERCENTAGE REMAINDER .00 .0 100.0 40000 .00 .0 100.0 80000 .00 .0 100.0 120000 2 25.00 25.0 75.0 160000 1 12.50 37.5 62.5 200000 .00 37.5 62.5 240000 .00 37.5 62.5 280000 .00 37.5 62.5 320000 .00 37.5 62.5 360000 1 12.50 50.0 50.0 40000C 2 2 5.00 75.0 25.0 440000 .00 75.0 25.0 480000 1 12.50 87.5 12.5 520000 1 12. 50 100.0 .0 IIAINING FREQUENCIES ARE ALL ZERO THE 5 E RIE S IN TABLE MEAN ARGUMENT STANDARD DEVIATION 104 10820. 679 9344. 000 UPPER OBSERVED PER CENT CUMULATIVE CUMULATIVE LIMIT FREQUENCY OF TOTAL PERCENTAGE REMAINOER .00 .0 100.0 2500 15 14.42 14.4 e5.5 5000 18 17.30 31.7 68.2 7500 16 15.38 47.1 52.8 10000 15 14.42 61.5 38.4 12500 6 5.76 67.3 32.6 15000 9 8.65 75.9 24.0 17500 3 2.88 78.8 21.1 20000 6 5.76 84.6 15.3 22 500 3 2.88 87.4 12.5 25000 3 2.88 90.3 9.6 27500 2 1.92 92.3 7.6 30000 2 1.92 94.2 5.7 32500 1 .96 95.1 4.8 OVERFLOW 5 4.80 100.0 .0 AVERAGE VALUE OF OVERFLOW 36629.79 Fig ure 5 SUM OF ARGUMENTS 4669692.000 . MULTIPLE OF MEAN -.000 .289 .578 .867 1.156 1.445 1.734 2.023 2.312 2.601 2.890 3.180 3.469 3.758 SUM OF ARGUMENTS 25577488.000 MULTIPLE OF MEAN -.000 .055 .111 .167 .222 .278 .334 .389 .445 .501 .557 .612 .668 .724 SUM OF ARGUMENTS 2404790.000 MULTIPLE OF MEAN -.000 .133 .266 .399 .532 .665 .798 .931 1.064 1.197 1.330 1.463 1.596 1.729 SUM OF ARGUMENTS 1125351.000 MULTIPLE OF MEAN -.000 .231 .462 .693 .924 1.155 1.386 1.617 1.848 2.079 2.310 2.541 2.772 3.003 NON-WEIGHTED DEVIATION FROM MEAN -1.082 -.769 -.456 -.143 .169 .482 .795 1.108 1.421 1.734 2.047 2.360 2.673 2.986 NON-WEIGHTEC DEVIATION FROM MEAN -2.696 -2.546 -2.396 -2.245 -2.095 -1.945 -1.795 -1.644 -1.494 r 1.344 -1.194 -1.044 -.893 -.743 NON-WEIGHTED DEVIATION FROM MEAN -1.896 -1.644 -1.392 -1.139 -.887 -.634 -.382 -.129 . 122 .374 .627 .879 1.132 1.384 NON-WEIGHTEC DEVIATION FROM MEAN -1.158 -.890 -.622 -.355 -.087 .179 .447 .714 .982 1.249 1.517 1.785 2.052 2.320 USER CHAIN 10 66 715798 100 66 67 735747 100 67 16 762756 100 16 76 775843 100 76 73 777691 100 73 79 779940 100 79 52 785046 100 52 Figure 6 569231 55 1 2524 30 1 1 668478 715798 3000 14«» 2524 30 49 668478 695421 3000 71(! 9703 567440 54 1 161 141 1 1 658358 735747 12400 161 161 141 51 65835e 695421 12400 73( 22652 1 11 2 8286 1148 3 3 453549 762756 113900 76; 4928 154 20 453549 453549 14500 49 2439 559 69 493334 493334 55900 60< 919 43 5 58 604687 665878 43500 750* 20357 53014 47309 i 766206 65 1 3014 9 1 1 766206 775843 900 ■: 3014 9 38 766206 766206 900 77'M 509 * 764678 64 5 373 49 1 1 764678 777691 4900 1 373 49 764678 764678 490C 77 7740 773737 66 5 1359 7 1 1 254 777691 780040 . 700 1359 7 777691 777691 700 78 290 625334 58 3 8380 166 1 1 697971 785046 16600 15 8380 166 81 ^ 697971 733197 16600 77144 C c 21769 25 PARAMETERS AM) INDICES HASP/O.S-i INITIATORS Priority 50 Parameters ■ 12 1. 2. 3- k 5- 6. 7- Initiator Number First Class Preference Second Class Preference Third Class Preference Fourth Class Preference Job number when selected USER CHAINS 1- Class 1 Jobs on queue (Jobs) 2- Class 2 Jobs on queue (Jobs) 3- Class 3 Jobs on queue (Jobs) h. Class h Jobs on queue (Jobs) 5- Class 5 Jobs on queue (Jobs) 6. Init • wait for Jobs (init) 7- Init wait for job to run (init) 8- Ready queue (linked by P7) (Jobs) 9- Wait for Core (init) 10- Completed Jobs (Jobs) 11. Waiting for i/O requests (Jobs) 13- Waiting for core in 0.S- (Jobs) Ik. More completed jobs (jobs) MSAVEVALUE INFO (7,10) Row Number (l-7) is initiator number Columns • 9 1 Job number 2 Step number 3- Status indicator h- Core request 5 Base of core allocated 6- Class of job 7 Execution time - this step 8- i/O requests - this step 9- Time of job creation MSAVEVALUE CORE (l, Xl) Columns • XI Savevalue XI initialized to size of core 1 - Xl-1 Job number using this space in core XI Dummy space always (-l) Job Status Indicator 1. Running requested time 2. Running overhead in core 3- Running overhead out of core h. Job completed Table 1 JOBS Priority 100 Parameters: H8 26 PARAMETERS AND INDICES 1. Job number 2. Job class 3. Execution time - current step 1+. Elapsed execution time 5. I/O requests - current step 6. Elapsed I/O requests 7. Dispatching priority 8. Initiator number when chosen 9. Total Number of steps 10. Current step executing * ; -'ll. Work space * 12. Work space 13. Time removed from spool ll+. Time execution completed 15. Number of cards read 16. Number of lines printed IT. Mean time slice 18. Number of I/O req. per slice * 19. Wait time for I/O requests 20. Turnaround time * 1+5. Time elapsed since interrupt * 1+6. I/O elapsed since interrupt 1+7 . Place of origin of this job 1+8. Job status indicator 21. Execution time - step 1 22. I/O requests - step 1 23. Core request - step 1 2U. Core allocation - step 1 25. Step 1 start 26. Step 1 core request filled 27. Wait for I/O this step 28. Step 1 end 29. Execution time - step 2 30. I/O requests - step 2 31. Core request - step 2 32. Core allocation - step 2 33. Step 2 start 3l+. Core request filled 35. Wait time for 1/0 requests 36. Step 2 end 37. Execution time - step 3 38. 1/0 requests - step 3 39. Core request - step 3 1+0. Core allocated - step 3 1+1. Step 3 start U2. Core request filled 1+3. Wait for 1/0 requests 1+1+ . Step 3 end Job Status Indicator - Job executing requested time - Job running overhead in core - Job running overhead out of cor - Job completed At job completion, 1+5. Wait time on ready queue - step 1 1+6. Wait tima on ready queue - step 2 1+7. Wait time on ready queue - step 3 3. Total execution time for Job (CPU) 5. Total 1/0 request for Job 19. Total wait time for job (I/O) Parameters indicated by (*) are used during execution for purposes other than what might appear on the final completion chain. Table 2 APPENDIX A Section I ,v6U,ioo, U8.F N0T2 ,,100,U8,F 2.FN2 ASSIGN BEGIN MARK w Section II / gen Y^ W' 7 ' 50 " F (sAVEVALUE ) 2+,Kl 2 , 1,X2 ( ASSIGN J NOT 3 2,V10 ASSIGN ( ASSIGN J U,V12 ASSIGN © SAVEVALUE ASSIGN UNH2 TRANS FER^" Section lib ENTEH mark 13 U8,K1 ( ASSIGN J ,X6 ASSIGN MSAVEVALUE INE0,P8 K1.P1 G MSAVEVALUE INTC),P8 K3.K1 ( MSAVEVALUE^) INF0,P8 K6,P2 ( MSAVEVALUE ) INF0,P6 K9,F12 SAVEVALUE T,P1 © ENT1 12, Ml ( ASSIGN J 3,V*12 ASSIGN I MSAVEVALUE INF0,P8 K7,P*12 U,KO ASSIGN 12,VU2 ASSIGN 5,P*12 ASSIGN MSAVEVALUE INF0,P8 K8, 1*12 6.K0 ASSIGN c MSAVEVALUE, INF0,P8 K2,P10 ENT2 12,VU3 Section Ha TEST1 f\ i Section III (lllh) SAVEVALUE 12*3 . HEQT ^ UNLINK PI lACT LINK 7 IFIFO Section IV w Section III (Continued) Section Ilia (ACTl), 17, Kl ASSIGN 18, V6 ASSIGN RANSKER x(ACT2) ACTl 17,X12 ASSIGN 18, Kl ASSIGN LOGIC R50 EXEC D— <£) fEXECA) SAVEVALUE 3,K1 SAVEVALUE 3,V22 EXEC 2 SEIZE *U8 X SEIZE SAVEVALUE 13,1*8 ADVANCE X3 U,V20 ASSIGN Section V © **5,V33 (^ ASSIGN ) LOGIC R51 RELEASE RELEASE SP] 7 (WAIT) 1 ' 1 N ) 6,Vl+3 f ASSIGN c 1 U6,V3 1 + ) ASSIGN 1 r ~^ LINK FIFO WAIT ADVANCE V25 ^V O UNLINK IRLUJIL RLINK w W EXEC 5 V ADVANCE V30 1 7 19+.V3C SAVEVALUE 9,P"12 12.VU3 ASSIGN 11,P*12 c ASSIGN I MSAVEVALUE C0RE.K1, X9.K0 SAVEVALUE 9+.K1 LOOP 1 (FREE) UNLINK REQN MSAVEVALUE INFO.P8, Kll.KO I MSAVEVALUE EXEC9)XP'«8 K2 IMSAVEVALUEJ INFO.P8, K3.K3 V >48,K3 ( ASSIGN ) EXE10 3.V66 ASSIGN I4.KO ASSIGN 1T.V66 ASSIGN 18, KO ASSIGN 7,K0 ASSIGN EXEC 9 EXEC8 11, K9 ASSIGN EXE11 MSAVEVALUE INF0.P8, Pll.KO LOOP EXE12 (EXE11) UNLINK UNH1 19.V26 ASSIGN 3.V29 c ASSIGN © l*,KO ( ASSIGN ) ! 1 5.V32 ( ASSIGN ) ' 6.K0 ( ASSIGN ) 7 17, KO ( ASSIGN ) 1 r 18, KO ( ASSIGN ) ? 20, Ml ( ASSIGN ) © 1»5, V17 ( ASSIGN ) J 1»6,V18 ( ASSIGN ) •♦7.V19 ( ASSIGN ) 1 1*8, Kk \^ ASSIGN ) r fZ TABULATE \ F TABULATE 1 f~\ LINK FIFO v_y Section IV BUFFER M0RE1 PRIORITY PREEMPT PR.M0RE2.il. RE RETURN PRIORITY BUFFER DONE Stction Via DISP2 DISP3 DISPU (DISP5) / TRANSF APPENDIX B REALLOCATE FAC, 50 ,STO, 10, QUE t 10, LOG, 55, FS V, 50 .COM, 80000 ,VAR ,75 REALLOCATE TAB, 10 ,BLC, 500, FUN, 20 BLOCK NUMBER *LOC OPERATION A, B,C, 0, E, F, G COMMENTS 1 2 3 4 5 10 k CORE INFO IORE TIME 1 .6,1/ 2 .21,1 3 .05,2 EXP 0..10 .8,1. .97,3 EXP1 0,.10 .8,1. .97,3 EXP2 0, . 10 .8,1. .97,3 * 1 2 5 6 7 3 4 8 9 10 11 12 13 17 18 19 20 22 23 24 25 26 27 28 29 30 31 32 33 34 35 41 42 43 44 45 46 47 48 SIMULATE TABLE TABLE TABLE TABLE TABLE TABLE MATRIX MATRIX Q MATRIX MATRIX INITIAL INITIAL INITIAL INITIAL INITIAL INITIAL INITIAL INITIAL INITIAL INITIAL FUNCTICN .9, 2/. 93, 3 FUNCTICN /.49,2/. 53 FUNCTION /. 20,3/1,1 FUNCTICN 0/.1..104/ 6/. 84, 1.83 .5/. 98,3.9 FUNCTION 0/.1..104/ 6/. 84, I. 83 .5/. 98, 3. 9 FUNCTICN 0/.1..104/ 6/. 84, 1.83 .5/. 98, 3. 9 VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE VARIABLE P20, 0,25000, 15 P20, 0,25000, 15 P20, 0,40000, 15 P20, 0,20000, 15 P20, 0,2500, 15 P20, 0,25000, 15 X, 1,201 X,7,9 X.1,5 X.1,5 MXSCOREU, 2011,-1 MX$TIME«l,l»,1606/MX*TIME!l,2»,49 35 MX»TIME(1,3I,7096/MX*TIME<1,4) ,8420 MX$ IOREOI I, 1) ,77/MX$IOREQ( 1,2) ,368 MXSI0REQ(1,3) ,9E5/MX$I0RE0(1,4) ,1224 MX$TIME(1,5), 1000/MX$IOREQ(1,5I ,50 MX $ INFO (2-4, 2 ), l/MX$INFO(5-6,2l,2/MX$INFOI7,2f, 3 MX$INFO<2-4,3),0/MX*INFO(5-6,3I ,0/MX$ INFOI 7 ,3 1 , 2 MX$INF0<1,2),5 XI, 201 RN2,04 /1,4 RN2,05 ,3/. 61 ,4/1.0,5 RN2.03 R .2 /.88 /.99 R .2,. /. 88 /.99 R .2,. /.88 /.99 N4.C24 222/. 3 ,2.12/ ,4.6/. N5.C24 222/. 3 ,2.12/ ,4.6/ N3.C24 222/. 3 ,2.12/ ,4.6/. ,.355/. 4,. 509/. 5,. 69/. 6,. 9 15/. 7, 1.2/. 75, 1.38 .9, 2. 3/. 92, 2. 52/. 94, 2. 81/. 95, 2. 99/. 96, 3. 2 995, 5. 3/. 998, 6. 2/. 999, 7/. 9998, 8 ,.35 5/ .4,. 509/. 5,. 69/. 6,. 9 15/. 7, 1.2/. 75, 1.38 .9, 2. 3/. 92, 2. 52/. 94, 2. 81/. 95, 2. 99/. 96, 3. 2 995, 5. 3/. 998, 6. 2/. 999, 7/. 9998, 8 ,.3 5 5/. 4,. 509/. 5,. 69/. 6,. 915/. 7, 1.2/. 75, 1.38 .9, 2. 3/. 92, 2. 52/. 94, 2. 81/. 95, 2. 99/. 96, 3. 2 995,5. 3/. 998, 6. 2/. 999, 7/. 9998, 8 500000 RN6/10 P3/P5 P5/P3 PI P8 10*P8 K50 CH8+CHI fXMNFO HX$INFO MXSINFO MXSINFO P28-P27 P36-P35 P44-P43 P4+X3 P3-P4 P6*P18 P4/P6 P18*V61 P27+P35 P4*1X3 P45*< X3 P21+P29 IP5-P6) P15-P14 P22+P30 P45+X3 P46+P18 P45/P46 13*P10* 14*P10» 15+P10» 16+P10* 17+P10» 18+P10» 19+P10* 20+P10* 1 (X2.K2) (X2.K3I (X2.K4) (X2.K5I -P26-P21 -P34-P29 -P42-P37 ♦P43 Pill -Pill ♦P37 *V61 P4-P19 ♦ P38 CARD NUMBER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 26 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 60 61 62 63 64 65 66 70 71 72 VARIABLE K15000 VARIABLE MOO VARIABLE K50 VARIABLE K20C0 VARIABLE K15 VARIABLE K18C0OO0 VARIABLE K2500 FVARIABLE P17*FN$EXP2 FVARIABLE I MX *T IME ( 1. P2 I » *FN»EXP FVARIABLE (MXtlOREQd ,P2I )«FNtEXP SECTION I CREATE JOB STREAM (JOBS) ► INITIALIZE N0T1 GENERATE ASSIGN TRANSFER ► N0T2 GENERATE ASSIGN BEGIN MARK UNLINK SAVEVALUf ASSIGN ASSIGN ASSIGN ASSIGN ASSIGN TEST E ASSIGN TRANSFER NEXP ASSIGN TEST G ASSIGN ASSIGN ASSIGN TEST G ASSIGN ASSIGN ASSIGN INITF LINK STARTING JCBS ON THE QUEUE M ,V64,100,48,F 2 t FNl ASSIGN CLASS FOR INITIAL JOBS .BEGIN V60,FN$EXP1,, 2,FN2 12 6.UNHI, ALL 4+.K1 1.X4 10. Kl 9.FN3 21.V71 22.V72 P2.K5.NEXP 9.K1 , INITF 23. V2 P9.K1.IMTF 29.V71 30.V72 31, V2 P9.K2, INITF 37.V71 38.V72 39, V2 P2.FIF0 >* SECTICN II ,100, 48, F ASSIGN JOB CLASS MARK CREATION TIME TO PASS TO INFO FREE WAITING INITIATORS INCREMENT JOB NUMBER COUNTER ASSIGN JOB NUMBER STEP COUNTER TO I ASSIGN NUMBER OF STEPS STEP 1 TIME STEP 1 I/O REQUESTS IS THIS AN EXPRESS JOB? EXPRESS JOBS CAN HAVE ONLY ONE STEP STEP 1 CORE REQUEST ANY MORE STEPS? STEP 2 TIME STEP 2 I/O REQUESTS STEP 2 CORE REQUEST ANY MORE STEPS? STEP 3 TIME STEP 3 I/O REQUESTS STEP 3 CORE REOUEST PUT JOB ON "HASP SPOOL" ** CREATE SEVEN INITIATOR/TERMINATORS N0T3 UNH1 UNH UNH2 GENERATE SAVEVALUE ASSIGN ASSIGN ASSIGN ASSIGN ASSIGN MSAVEVALUE MSAVEVALUE TEST G SAVEVALUE UNLINK SAVEVALUE BUFFER ASSIGN TEST E LINK TRANSFER ,, ,7,50,,F 2 + .K1 1.X2 2.V10 3,V11 4.V12 5.V13 INFO,P1,K2,KO INFO, PI ,K3,K0 CH*2,K0,TEST1 5.P2 X5, ENTER, 1 6, PI MAKE APPRCPRI 8.X7 P2.K5.UNH2 7, FIFO ,REQN * C TEST ** SECTION I HECK ALTERNATE CLASS DEF IN COUNTER ASSIGN IN ASSIGN IN ASSIGN IN ASSIGN IN ASSIGN IN ZERO OUT ZERO OUT ANYTHING INDICATE UNLINK JO PASS INIT ATE JOe ASSI PUT CORRE IS THIS A SKIP CORE GET CORE I-A ** ITIONS ( INITIATORS) IT [AT OR NUMBER ITIATOR PRIMARY CLASS ITIATOR SECONDARY CLASS ITIATOR THIRD CLASS ITIATOR FOURTH CLASS TEMP INFO IN "INFO" TEMP INFO IN "INFO" ON THE SPOOL? WHICH CLASS SELECTED B THAT JUST GOT INITIATOR IATOR NUMBER TO JOB GNMENTS SPONDING JOB NO. IN INIT N EXPRESS JOB? ALLOCATION ROUTINE ALLOCATION (INITIATORS) TEST2 TEST3 BLOCK TEST NE TEST G SAVEVALUE TRANSFER TEST NE TEST G SAVEVALUE TRANSFER TEST NE TEST G SAVEVALUE TRANSFER LI NK P3,K0,BLCCK CH*3,K0,TEST2 5.P3 ,UNH P4,K0, BLOCK CH*4,K0,TEST3 5,P4 ,UNH P5.K0, BLOCK CH»5,K0, BLOCK 5,P5 .UNH 6, FIFO CHECK FCR SECONDARY CLASS DEFINITION ANY JOBS ON THIS CHAIN? INDICATE WHICH CLASS SELECTED CHECK FOR THIRD CLASS DEFINITION ANY JOBS ON THIS CHAIN? INDICATE WHICH CLASS SELECTEO CHECK LAST CLASS DEFINITION ANY JOBS ON THIS CHAIN? INDICATE WHICH CLASS SELECTEO PUT BLOCKED INITIATOR IN WAIT STATE 85 86 87 68 .89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 156 159 160 161 162 163 164 165 166 167 168 169 * •* SECTION I I-B ** 170 * 171 * ENTER JOB INFO INTO "INFO" (JOBS) 172 * 173 58 ENTER MARK 13 ENTER TIME REMOVED FROM SPOOL 174 59 ASSIGN 48, Kl INITIALIZE STATUS COUNTER 175 60 ASSIGN 8,X6 ASSIGN INITIATOR NUMBER TO JOB 176 61 MSAVEVALUE INF0,P8,K1, PI ENTER JOB NUMBER 177 62 MSAVEVALUE INFO, P8 ,K3, Kl SEND STATUS TO INFO 178 63 MSAVEVALUE INF0,P8,K6, P2 ENTER CLASS OF THIS JOB 179 64 MSAVEVALUE INFO ,P8,K9, P12 PUT JOB CREATION TIME IN INFO 180 65 SAVEVALUE 7, PI SEND JOB NO. TO INITIATOR 181 66 ENT1 ASSIGN 12.V41 182 67 ASSIGN 3,P*12 ASSIGN STEP EXEC TIME 183 68 MSAVEVALUE INF0.P8, K7, P» 12 ENTER STEP TIME 184 69 ASSIGN 4,K0 ASSIGN ELAPSED STEP TIME 185 70 ASSIGN 12,V42 186 71 ASSIGN 5,P*12 ASSIGN STEP I/O REQUESTS 187 72 MSAVEVALUE INFO ,P8 ,K8, P*12 ENTER STEP I/O REQUESTS 188 73 ASSIGN 6,K0 ASSIGN ELAPSED STEP I/O REQUESTS 189 74 MSAVEVALUE INFO, P8 , K2, P10 SEND STEP NUMBER TO INFO 190 75 TEST E P2.K5.ENT2 IS THIS AN EXPRESS JOB? 191 76 MARK 25 MARK STEP START 192 77 MARK 26 MARK TIME (EXPRESS DOESN'T HAITI 193 78 TRANSFER .ACT GO DIRECTLY TO READY QUEUE 194 79 ENT2 ASSIGN 12.V43 195 80 MSAVEVALUE INFO ,P8, K4, P* 12 ENTER STEP CORE REQUEST 196 81 HARK V45 HARK STEP START 197 82 LINK 13, FIFO 198 * 199 * ** SECTION III »* 200 » 201 * CORE ALLOCATION ROUTINE (INITIATORS! 202 * 203 83 REON SAVEVALUE 8,K1 INITIALIZE BASE COUNTER 204 84 REQS TEST E PX$CGRE < 1 ,X8 ) ,KO,REQI IS THIS A FREE BLOCK? 205 85 ASSIGN ll,MXSINFC(Pl,K4t INITIALIZE CORE REQUEST (SIZE) 206 86 SAVEVALUE 9,X8 STORE TEMPORARY BASE 207 87 INNER TEST E MXiCORE ( 1 ,X 8) ,KC, REOI IS THIS A FREE BLOCK? 208 88 SAVEVALUE 8*,K1 INCREMENT CORE LOCATION 209 89 TEST LE X8,X1,REQW IS MORE CORE AVAILABLE 210 90 LOOP 11, INNER 211 91 TRANSFER ,REQF REQUEST FULFILLED 212 92 REQI SAVEVALUE 8*,K1 INCREMENT CORE LOCATION 213 93 TEST LE X8.X1.REQW IS MORE CORE AVAILABLE 214 94 TRANSFER ,REQS 215 95 REQW LINK 9, FIFO UAIT FOR CORE TO BECOME AVAILABLE 216 96 REQF MSAVEVALUE INFO ,Pl , K5 , X9 ENTER eASE ADDRESS OF ALLOCATION 217 97 ASSIGN ll,MX$INF0(Pl,K4) INITIALIZE CORE REQUEST (SIZE) 218 98 REQA MSAVEVALUE C0RE.K1 ,X9, fX $1 NFO ( PI ,K 1) PUT JOB NO. IN CORE MAP 219 99 SAVEVALUE 9*,K1 INCREMENT CORE LOCATION 220 100 LOCP 11, REQA 221 101 MARK 9 TIME CORE REQUEST FILLED 222 102 SAVEVALUE 10, P9 PASS THIS TIME TO JOB 223 103 REQT UNLINK 13, ACT ,1 , 8, PI PREPARE JOB TO RUN 224 104 LINK 7, FIFO HOLO COMPLETED REQUESTS TEMPORARILY 225 * 226 * ** SECTION III-A ** 227 * 228 * PUT JOB CN RUN-STATLS BY DISPATCHING PRIORITY (JOBS) 229 * 230 105 ACT SAVEVALUE 12, V5 DEFINE TIME BETWEEN INTERRUPT FOR I/O 231 106 TEST E X12.K0.ACT1 IS THE RATIO ZERO? 232 107 ASSIGN 17, Kl 1 IS THE MINIMUM RATIO 233 108 ASSIGN 18, V6 NUMBER OF I/O REQ. IN THIS MINIMUM 234 109 TRANSFER ,ACT2 235 110 ACT1 ASSIGN 17.X12 ASSIGN THIS RATIO 236 111 ASSIGN 18, Kl NUMBER OF I/O IN THE SLICE EQUAL 1 237 112 ACT2 TEST E P2.K5.ACT3 IS THIS AN EXPRESS JOB? 238 113 ASSIGN 7.K0 EXPRESS JOB GETS TOP PRIORITY 239 114 TRANSFER ,ACT4 240 115 ACT3 ASSIGN V44 ,MX* INFO( P8, K5 ) ASSIGN STEP ITS CORE ALLOCATION 241 116 ASSIGN 7,K1 ASSIGN INITIAL DISPATCHING PRIORITY 242 117 ASSIGN V46.X10 ASSIGN TIME CORE REQUEST FILLEO 243 118 ACT4 LOGIC R 50 SIGNAL SOMETHING ON READY QUEUE 244 119 LINK 8,P7 PUT JOB ON "READY QUEUE" 245 * 246 ■ ** SECTION IV ** 247 * 248 * CONTROL SECTION (CNE CCNTROL TRANSACTION) 249 * 250 120 GENERATE ,,,1,125, ,F GENERATE ONE CONTROL TRANSACTION 251 121 RUNA TEST E CH8,K0,RUNB ANYTHING REAOY TO RUN? 252 122 LOGIC S 50 WAIT FOR A READY JOB 253 123 GATE LR 50 254 124 RUNB GATE LR 51 LIMIT CPU TO ONE TASK 255 125 UNLINK 8, EXEC, 1 SEND FIRST JOB ON REAOY QUEUE TO EXEC. 256 126 LOGIC S 51 WAIT FOR JOB TO RUN 257 127 TRANSFER ,RUNA 258 •• SECTION • EXECUTE JOB 128 EXEC SAVEVALUE 3.V70 129 TEST E X3.K0, EXECA 130 SAVEVLAUE 3.K1 131 EXECA TEST GE V20.P3.EXEC2 132 SAVEVALUE 3.V22 133 EXEC2 SEIZE •48 I 34 SEIZE 5 135 SAVEVALUE 13.P48 136 ADVANCE X3 137 ASSIGN 4.V20 138 ASSIGN 45.V33 139 LOGIC R 51 140 RELEASE *48 141 RELEASE 5 142 TEST NE P18,K0,RLINK 143 SPLIT l.WAIT 144 ASSIGN 6.V23 145 ASSIGN 46.V34 146 LINK 11, FIFO 147 WAIT ADVANCE V25 148 UNLI NK ll.RLINK.l , 1 ,P1 149 TERMINATE 150 RLI NK ASSIGN 19*,V25 151 TEST NE P4.P3.EXEC5 152 LOGIC R 50 153 TEST E P6,P5,EXEC4 154 ASSIGN 18, KO 155 EXEC4 LINK 8.P7 156 EXEC5 TEST E P6,P5,EXEC3 157 ADVANCE V30 158 ASSIGN 19t,V30 159 EXEC3 TEST E P2.K5, EXECB 160 ASSIGN 27.P19 161 MARK 28 162 TRANSFER ,EXE12 163 EXECB TEST E P48.K2.EXEC6 164 EX6C7 ASSIGN 12.V44 165 SAVEVALUE 9,P*12 166 ASSIGN 12.V43 167 ASSIGN ll,P*12 168 FREE MSAVEVALUE C0RE,K1,X9,K0 169 SAVEVALUE 9+.K1 170 LOOP 11, FREE 171 UNLINK 9.RE0N, ALL 172 MSAVEVALUE INF0,P8,K4,K0 173 MSAVEVALUE INF0,P8,K5,K0 174 TEST E P48,K2,EXEC9 175 N0T5 MSAVEVALUE INF0,P8,K3,K3 176 ASSIGN 48, K3 177 EXE10 ASSIGN 3,V66 178 ASSIGN 4,K0 179 ASSIGN 17.V66 180 ASSIGN 18,K0 181 ASSIGN 7,K0 182 LOGIC R 50 183 LINK 8,P7 184 EXEC6 TEST E P10.P9.EXEC7 185 TEST NE P48.K3.EXEC8 186 N0T4 MSAVEVALUE INF0,P8,K3,K2 187 ASSIGN 48, K2 188 MARK V48 189 ASSIGN V47.P19 190 ASSIGN 19, KO 191 TRANSFER •EXE10 192 EXEC9 MARK V48 193 ASSIGN V47.P19 194 ASSIGN 19, KO 195 ASSIGN 10*,K1 196 UNLINK 7,REQN,1,1,P8 197 TRANSFER ,ENT1 198 EXEC8 ASSIGN 11, K9 199 EXE11 MSAVEVALUE INF0,P8,P11 ,K0 200 LOCP 11 , EX El 1 201 EXE12 MARK 14 202 UNLINK 7.UNH1, 1.1.P8 203 ASSIGN 19.V26 204 ASSIGN 3.V29 (JOBS! ASSIGN SLICE IS THE NEW SLICE ZERO? ASSIGN MINIMUM SLICE IS STEP FINISHED? ASSIGN SLICE TO EXECUTE TO COMPLETE TAKE THE CPU ACCOUNT FOR ANY USE OF THE CPU PASS THIS FACILITY TO DISPATCHER ADVANCE THE SLICE UPDATE ELAPSEO TIME UPOATE TIME IN THE INTERVAL FREE THE SCHEDULER FREE THE CPU INDICATE CPU FREE ANY MORE I/O REQUESTS TO ISSUE? CREATE DUMMY TRANSACTION UPDATE ELAPSED I/O REQUESTS UPDATE I/O IN INTERVAL PUT JOB IN WAIT STATE ADVANCE FOR I/O REQUESTS RE-ACTIVATE WAITING JOB KILL THE DUMMY TRANSACTION UPDATE I/O REQUESTS ISSUED DID STEP COMPLETE? SIGNAL SOMETHING ON READY QUEUE ARE ALL I/O REQUESTS FINISHED? NO MORE I/O REQUESTS RETURN TO READY QUEUE DID JOS JUST DO O'HEAD IN CORE? RE-INITIALIZE STEP CORE BASE RE-INITIALIZE STEP CORE LENGTH DE-ALLOCATE THIS PIECE OF CORE INCREMENT CORE LOCATION RESET CORE MAP FREE JOBS WAITING FOR CORE RESET CCRE INFORMATION IN INFO RESET CCRE INFORMATION IN INFO DID JOB JUST DO O'HEAO IN CCRE? SET OUT OF CORE OVERHEAD INDICATOR SET INDICATOR TO O'HEAD OUT OF CORE RESET EXEC TIME RESET ELAPSED TIME SET MINIMUM TIME SLICE I/O REQUESTS TO ISSUE ASSIGN TOP PRIORITY SIGNAL SOMETHING ON READY QUEUE PUT BACK ON READY QUEUE ARE ALL STEPS COMPLETE? DID JUST COMPLETE O'HEAD OUT OF CORE SET OVERHEAD INDICATOR SET INDICATOR TO O'HEAD IN CORE MARK STEP END ENTER STEP I/O REQUESTS RESET I/O COUNTER MARK STEP END STEP WAIT TIME RESET WAIT COUNTER INCREMENT STEP COUNTER AWAKE THIS INITIATOR NUMBER OF ELEMENTS IN ROW OF INFO CLEAR THIS ROW OF INFO ENTER COMPLETION TIME FREE INTITIATOR ENTER TOTAL WAIT TIME ENTER TOTAL EXEC TIME 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 ASSIGN 4,K0 CLEAR ELAPSED TIME 341 ASSIGN 5.V32 ENTER TOTAL I/O REQUESTS 342 ASSIGN 6,K0 CLEAR ELAPSED I/O REQUESTS 343 ASSIGN 17, KO ZERO OUT TEMPORARY INFORMATION 344 ASSIGN 18, KO ZERO OUT TEMPORARY INFORMATION 345 ASSIGN 20, Ml ENTER TURNAROUND TIME 346 ASSIGN 45, KO CLEAR INTERVAL RECORDER 347 ASSIGN 48.K4 MARK JC6 COMPLETEION 348 ASSIGN 45.V17 WAIT TIME ON READY QUEUE STEP 1 349 ASSIGN 46, V18 WAIT TIME ON READY QUEUE STEP 2 350 ASSIGN 47.V19 WAIT TIME ON READY QUEUE STEP 3 351 TABULATE *2 TABULATE TURNAROUND BY CLASS 352 TABULATE 10 TABULATE TURNAROUND FOR OVERALL SYSTEM 353 LINK 10.FIFC PUT JOB ON COMPLETEC CHAIN 354 * 355 « ** SECTION VI »* 356 * 357 * DISPATCHING SECTICN (DISPATCHER! 358 * 359 GENERATE ,,,1,,,F CREATE CI SPATCHER 360 DISP LOGIC S 51 8L0CK THE SCHEOULER 361 LOGIC R 50 INDICATE SCMETH1NG ON REAOY QUEUE 362 BUFFER LET ALL TRANSACTIONS REACH THEIR GOAL 363 UNLINK 8,DISP1,ALL REOROER REACY QUEUE 364 BUFFER 365 UNLINK 11,DISP4,ALL REORDER I/O WAITING QUEUE 366 BUFFER 367 MCRE1 GATE U 5.0CNE IS THERE A JOB IN THE CPU? 368 PRIORITY 127 GIVE DISPATCHER HIGH PRIORITY 369 PREEMPT X13,PR,MORE2,U,RE INTERRUPT JOB IN THE CPU 370 RETURN X13 RELEASE THE CPU 371 PRIORITY 0, BUFFER REASSIGN THIS JOBS PRIORITY 372 DCNE SEIZE 4 TAKE THE CPU 373 ADVANCE V62 EXECUTE DISPATCHER CVERHEAO 374 RELEASE 4 RELEASE THE CPU 375 LOGIC R 51 FREE THE SCHEOULER 376 ADVANCE V63 DISPATCHER TO SLEEP FOR 2 SECONCS 377 TRANSFER ,DISP REPEAT RE-ORDERING PROCESS 378 M0RE2 ASSIGN 4.V27 UPDATE STATS FOR INTERRUPTED JOB 379 ASSIGN 45.V28 UPDATE TIME IN INTERVAL 380 ASSIGN 12, K8 INDICATE JOB TO BE RETURNED TO READY 381 RELEASE 5 RELEASE THE CPU 382 TRANSFER ,DISP5 383 ► 384 ► ** SECTION VI-A ** 385 ► 386 f RE-ORDER CHAINS (JOBSI 387 ► 388 DISP1 ASSIGN 12, K8 DESIGNATE THIS JOB IS FROM REAOY QUEUE 389 0ISP5 TFST NE P7,K0,0ISP2 IS THIS ZERO PR JOB? 390 ASSIGN 7.V35 NEW TEMP DISPATCHING PRIORITY 391 TEST E P7,K0,DISP2 IS TEMP DISPATCHING PRIORITY ZERO? 392 ASSIGN 7,K1 ASSIGN MINIMUM NON SYSTEM OISPATCHING 393 0ISP2 ASSIGN 45, KO RESET TIME IN INTERVAL 394 ASSIGN 46, KO RESET I/O REQUESTS IN INTERVAL 395 DISP3 LINK *12,P7 RELINK TO READY QUEUE 396 DISP4 ASSIGN 12.K11 DESIGNATE JOB IS FROM I/O WAIT QUEUE 397 TRANSFER ,0ISP5 398 ► 399 ► 400 * PRINT TEST RESULTS 401 * 402 403 404 405 406 407 408 409 NNCC LINK 14, FIFO 410 411 412 413 GENERATE V65 PRINT ,,F,X PRINT ,,u,x PRINT ,.T,X PRINT 10,10,CHA,X UNLINK 10, NNCC, ALL TERMINATE LINK 14, FIFO START 1,NP END BIBLIOGRAPHIC DATA SHEET 1. Report No. UTUCDCS-R72-528 3. Recipient's Accession No. 4. Title and Subtitle A GPSS SIMULATION OF THE 360/75 UNDER HASP AM) 0. S. 36O 5- Report Date June 1972 7. Author(s) Fred Salz 8- Performing Organization Rept. No. 9. Performing Organization Name and Address Department of Computer Science University of Illinois Urbana, Illinois 618OI 10. Project/Task/Work Unit No. 11. Contract/Grant No. NSF GJ 28289 12. Sponsoring Organization Name and Address National Science Foundation Washington, DC 13. Type of Report & Period Covered Research 14. 15. Supplementary Notes 16. Abstracts The success or failure of a computing system in today's highly competitive market is often determined by the efficiency of its operating system. Consequently, existing systems are constantly being modified, extended, and, hopefully, improved. The key question pertaining to the implementation of proposed changes is: "Does the proposed change improve the existing operating system?" One appealing method of answering this question is to simulate the operation of the computing system both under the existing operating system and the system with the proposed changes included. The obvious first step in such a study is to build a model to simulate, with accuracy, the existing system. In this paper, such a model is presented for the IBM 360/75 operating under HASP and O.S. A GPSS simulation of the system is presented and some results are given which verify the accuracy of the simulation. 17. Key Words and Document Analysis. 17a. Descriptors System Modeling, Simulators 17b. Identifiers/Open-Ended Terms 17c. COSATI Field/Group 18. Availability Statement Release unlimited FORM NTIS-35 (10-70) 19. Security Class (This Report) UNCLASSIFIED 20. Security Class (This Page UNCLASSIFIED 21. No. of Pages 1+8 22. Price USCOMM-DC 40329-P71 */ *