is HE iffiSjfsSs WBP rbrH Iraafl II H1IH1I111 Sislili WssBMsm m M HH H 9 Bill inM&SMMrfl B Offl B Q w BBSs H Hi Hi ^H HI SB Hi HBfl ■ ■ Hi Bi H k /jd Eli 3fel 19181 ■ ■■■HhMBhHBBI MM £\ r I 'i. I •■* ■Until iHBffrorffl Bi Mwn ■■BH bSbBH he ■■hBBhb«I » QfflB LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAICN 510.84 TiQr ho. 637 -£42 cop. 2- The person charging this material is re- sponsible for its return to the library from which it was withdrawn on or before the Latest Date stamped below. Theft mutilation, and underlining of books are reasons £ ssr octi - - -* - *sji= To renew call Telephone Center, 333-8400 SEP 2 2 RE^ L161— O-1096 Digitized by the Internet Archive in 2013 http://archive.org/details/systemmonitorfor639wong LJMfA' uiucdcs-r -7^-639 September, 197^ }?UA^ A SYSTEM MONITOR FOR PROGRAMS IN ARTIFICIAL INTELLIGENCE by Tze-Wah Wong JAN 6 1974 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN The Library of the JAN 3 - 1975 URBANA, ILLINOIS uiucDCS-R-7i)--639 A SYSTEM MONITOR FOR PROGRAMS IN ARTIFICIAL INTELLIGENCE *y Tze-Wah Wong September, 197*4- ■Department of Computer Science University of Illinois at Urb ana -Champaign Urbana, Illinois 6l801 ACKNOWLEDGMENT The author wants to express his sincere thanks to Professor R. S. Michalski whose presentation of the texture recognition problem (discussed as an example in this paper) has motivated the development of this project, and to his thesis advisor, Dr. H. G. Friedman, for his useful guidance and comments. Thanks to Professor Peter A. Alsberg for his valuable suggestions to the design of the monitor. Thanks to the consultants Mr. Bob Foster, Mr. Kurt Hir chert, Mr. Gordon Chase, and Mr. Steve Leighton who have given information on OS360 necessary for coding and debugging of the monitor program. Thanks also to Mr. Joseph Wayne Hamilton for his help in editing this literature, and Mrs. Connie Slovak for typing this documentation. PREFACE A lot of programs have been written dealing with Texture Recognition and other areas of Artificial Intelligence. The large amount of core these programs take up makes it impractical to have an entire program in core before execution. Therefore a MONITOR program that loads each sub-program at the time it is needed is desirable. Also the fact that the flow of control between these sub-programs may not be easily pre-determined makes it necessary that the MONITOR be flexible enough to allow programmers to easily modify the flow of control during execution. A MONITOR which fulfills the above needs in research in artificial intelligence was implemented on the IBM 360-75 under OS MVT release 20.6 at the University of Illinois Urbana-Champaign. In addition to general design principles of the MONITOR, the following paper will also give discussions of methods of setting up a supervisor-slave type system under the MONITOR, as well as possible ways of interfacing interactive console support to the MONITOR. TABLE OF CONTENTS Page 1. MOTIVATION AND DESIGN SPECIFICATIONS 1 2. BACKGROUND CONCEPTS . . . 4 3. MONITOR DESIGN AND DESCRIPTION 15 4. USING THE MONITOR AND RELATED SOFTWARE 22 4.0 Monitor Instruction Block Format 23 4.1 ATTACH Instruction 24 4.2 DETACH Instruction 26 4.3 QUEUE Instruction ..... 27 4.4 CHANGE PRIORITY Instruction 30 4.5 SUSPEND Instruction 32 4.6 RESUME Instruction 33 4.7 EXECUTE Instruction 33 4.8 NOP Instruction 34 4.9 END Instruction 35 4.10 UTILITIES 36 4.11 START Routine 37 4.12 LOOK QUEUE Routine 38 4.13 SERVICE DONE Routine 40 4.13 MODIFY TASK TABLE Routine 4l 4.14 MODIFY QUEUE ENTRY Routine 43 4.15 EXTRACT Routine 44 4.16(a) WAIT Routine 45 Page 4.16(b) POST Routine k5 4.17 SCAN TASK TABLE Routine 46 4.18 SYSTEM PROCEDURES . . 48 If. 19(a) MONITR entry 49 4.19(b) UTILTY entry 49 4.20 DELAY entry ..... 50 4.21(a) LIST entry 51 4.21(b) IADDR function 51 4.22(a) IPACK function 52 4.22(b) IUNPK function 52 4.23 IPARAM function 53 4.24 INITIAL TASK STARTING 55 5. EXAMPLE OF INTERACTIVE CONSOLE PROGRAM 56 6. USAGE EXAMPLE (TEXTURE DISCRIMINATION) 6l 7. USAGE EXAMPLE (MULTI- INSTALLATION PROGRAMMING) 63 8. MONITOR LOGIC 64 9. SUMMARY OF COMMANDS 68 9.1 PARM field Format 68 9.2 ATTACH Instruction 68 9.3 DETACH Instruction 69 9.4 QUEUE Instruction 69 9.5 CHANGE PRIORITY Instruction 69 9.6 SUSPEND Instruction 69 9.7 RESUME Instruction 70 9.8 EXECUTE Instruction 70 9.9 NOP Instruction 70 Page 9.10 END Instruction 70 9.11 START Routine 70 9.12 LOOK QUEUE Routine 71 9.13 SERVICE DONE Routine 71 9.1^ MODIFY TASK TABLE Routine 71 9.15 MODIFY QUEUE ENTRY Routine 72 9.16 EXTRACT Routine 72 9.17(a) WAIT Routine 72 9.17(b) POST Routine 72 9.18 SCAN TASK TABLE Routine 73 9.19 SYSTEM PROCEDURES 73 9.20(a) MONITR entry 73 9.20(b) UTILTY entry 73 9.21 DELAY entry 73 9.22(a) LIST entry 7^ 9.22(b) IADDR function 7^ 9.23(a) IPACK function Ik 9.23(b) IUNPK function 7^ 9.2*4- IPARAM function 7^ 10. JCL TO SET UP THE SYSTEM 75 11. EXAMPLE OF PL/l PROGRAM SETUP 76 12. EXAMPLE OF RUN 78 BIBLIOGRAPHY 8k APPENDLX-A 86 APPENDIX-B 112 1. MOTIVATION AND DESIGN SPECIFICATIONS Most of the programs in artificial intelligence involve solving certain restricted classes of problems with ad hoc ideas and heuristic methods. These programs work fantastically on some of the problems and poorly or not at all on other problems. Therefore in order to develop more reliable programs to solve more general sets of problems, a combination of several ad hoc methods must be used. However the large amount of core required for programs on each of the methods makes it impractical to have all the programs in core before execution (which is the way OS36O is normally set up). A program that dynamically loads the sub-programs as they are needed is thus desirable. When several methods are employed in solving a problem, it is often not possible for the programmer to know before hand which is the best method. It is sometimes necessary to try each of the methods for a short time and from the result determine if it is fruitful to continue the present method or go on to another one. There- fore it is necessary to have supervisory programs which evaluate the method being attempted and interrupt its processing if necessary. To help evaluate the present method, these supervisory programs may choose to request help from the programmer through the interactive console support. It is thus necessary for the MONITOR to provide convenient means to implement such systems. Based on these needs, the following design guide- lines are observed: l) The MONITOR must provide a generalized method of linking existing programs. The method of loading and linking programs must be simple enough that only trivial modifications are needed to existing programs, regardless of the source language they are written in. The method must also be directly compatible with Operating System programs such as compilers and utilities which are not modifiable by users. It is obvious that this requirement has to be imposed. The cost of rewriting existing programs is far too high for many research projects. The compatibility with system programs also makes the monitor immediately compatible with new programs the research programmer may obtain from other similar installations. 2) The MONITOR must be quite immune to errors caused in problem programs. Assumptions must be made that most of the research programs are not very reliable, either because the method they use to solve problems does not always work, or because not all the "bugs" and subtleties have been considered during coding. Therefore some form of supervision and possibly correction of the problem programs is needed. The MONITOR should provide ways for problem programmers to implement supervisory programs and error recovery programs. 3) The problem programs must be modular ly replaceable. This would facilitate updating and maintenance of problem programs. Methods must also be provided to replace modules during execution. This is particularly useful when several sub -methods are available to solve a sub-problem and the supervisory program decides that one of the methods works best, or that one of the methods has a "bug". The proper module can then be used. k) The MONITOR commands that manipulate problem programs must not be privileged to a few supervisory programs. The idea of supervisory program is not always clearly defined. One can envision employing several methods to solve a problem as a group of specialists in conference would solve a technical problem. Each of them is good at some area and thus should be given more authority at the time questions in that area arise. We have a mutually supervisory system in which one program is confident at some time and thus supervises others, and not quite confident at other times and thus is being supervised. Such a system can only be implemented if MONITOR commands are available to all programs. 5) Facilities should be provided to help program debugging. For example, features for establishing break points in problem programs and continuing execution from the previous break point should be provided. Experience shows that a great deal of programming time can be saved if on-line debugging facilities are available. 6 ) Methods should be provided to add new features to the system. No system is perfect; updating and addition of new features are unavoidable. To save maintenance overhead, such modifications should be easy to make. 2. BACKGROUND CONCEPTS (More advanced readers may skip this chapter and proceed directly to Chapter 3- ) Since our major problem is that there is not enough physical core to load in all the routines of a program, it is natural to look at some of the methods that tackle the problem here. It is obvious that some region of core has to be allocated to more than one routine. The method of allocating the regions of core is the main concern. This allocation can be done by the programmer using the overlay option of the linkage editor; the allocation can also be done automatically by the operating system using most commonly the method of demand loading. In the overlay method the problem programmer, after studying the amount of physical core available to him and the amount of core needed for each one of his load routines, explicitly specifies to the linkage editor the method of dividing the physical region of core into sub-regions (probably of unequal length), and allocates each of these sub-regions to each of his routines. He thus specifies the set of routines that are in core at a certain time, and the logical points in his program when a specified routine is to be replaced by another specified routine. Although often quite efficient core allocation can be done after careful planning, this method is tedious and completely lacking in generality. A slight modification of the source program may mean a major change in core allocation. The method of core allocation by the operating system at execution time is often known as virtual memory. This is because the allocation of physical core is completely transparent to the user and so his program can think that it has all the core it wants. Since the operating system does not have the knowledge of the logic of the user's program, it is immediately faced with the problem of deciding which part of core is to be replaced by the new routine the user program requests during execution. Two major problems may arise from a poor replacement procedure. The routine that is replaced may be a more frequently used part of the program; thus it has to be loaded almost immediately into core again. The memory may also be fragmented, that is the unused blocks of core are spread out all over memory; thus when a contiguous block of core is needed, it may not fit into any block of unused core. One of the methods that has been used to prevent memory fragmentation is to use a fixed size page scheme. In this method, the complete user program is logically divided into fixed size blocks of code (e.g. every 2K bytes of code) known as pages. When a page is needed, it will be loaded into core. Since all the pages are of fixed size, it will always fit into an unused block of core, i.e. it will always replace a page of same size. This method is used in systems like MULTICS. Since the line of division of pages bears no significance to the logic of the program, a page may contain parts of two logically different parts of the program. Thus parts that are not needed may also be loaded. A page within the same logical group, and thus used frequently, may also be replaced. Since the user has no way of knowing page boundaries, he would have no way of telling the operating system when a new page may be needed. So as far as the operating system is concerned every instruction has the potential to refer to a page that is not in core. The checking of missing pages is extremely expensive unless specialized hardware is used for it (e.g. IBM 360/67). Obviously this method is not feasible on IBM 360/75. Another method of assigning boundaries is to base them to some extent on the logic of the program. This is known as variable size segments, since logical units in a program may not be of the same length. The user program may now explicitly ask the operating system to check whether a segment is in core before referencing it. Since this checking occurs only occasionally, virtual address conversion overhead is reduced to a minimum. The fact that each segment is a logical entity in the program also ensures that most often needed code will not be replaced when a new segment is loaded. However, the problem of memory fragmentation exists, since segments are of unequal length. Thus, a good choice of which logical entities are to constitute segments has to be done to minimize this placement difficulty. A statement is the smallest logical unit in any language. It is compiled into a piece of code beyond direct control of the user. The method of communication of data and flow of control between statements is usually dependent on the compiler and the context of each statement. Thus the statement is not a good choice as a logical entity, except in rare cases such as incremental compilers and interpreters, where special methods are used during compilation. Statements in a program are usually grouped together to represent a basic unit. Such basic units are usually represented as blocks on a flow chart. However this is also not a good choice for a segment due to non-standard ways of compilation as before. Blocks on a flow chart are again grouped together to form procedures. A procedure usually solves a sub-problem. There are two types of procedure: subroutines and coroutines. Subroutines are implemented in most high level languages. A CALL statement is used to transfer control to the beginning of the subroutine. Upon executing a RETURN/END statement, control is returned to the caller right after the call statement. Since a sub- routine may be called from a large number of CALL statements, quite a bit of code is saved over coding the subroutine in line. Unlike subroutines, coroutines, though useful, are seldom implemented in high-level languages. The only distinction between coroutine and subroutine is that a CALL statement does not always pass control to the beginning of the coroutine. Control is passed to the beginning of the coroutine on the first CALL statement. Upon executing a coroutine RETURN, control is returned to the caller as before. However if the caller calls the coroutine a second time, control is passed to the statement following the coroutine RETURN last executed instead. flow of control Main Program Coroutines are most useful if the nature of the sub-problem is dependent on the previous sub-problem solved. For example in the implementation of several inter -coupling finite state automata, or compilers composed of 8 key-word scanners, precedence parsers, and post-fix to machine language code generators, coroutines are a very natural tool to use. In procedures, standard ways are usually set up for communication of data and flow of control between them. Data is usually transferred as parameters in CALL statements. There are 3 types of parameter passing that are most commonly used. They are call by value, by reference, and by name. In a call by value (e.g. SNOBOL), only the value of the parameters are given to the procedure. If the procedure changes the value of the parameter, the caller is not affected since values are not passed back to the caller. In the call by reference, the addresses of the parameters are logically given to the procedure, although actual implementation may differ slightly (be careful of FORTRAN scalars). If the value of the parameter is changed in the procedure, the caller's corresponding parameter is also changed. In the call by name, the code that is needed to evaluate the parameters is passed to the procedure. This code is to be executed every time a reference is made to the parameter by the procedure. This kind of call is used in ALGOL 60 to pass expressions to subroutines. Given all these well-defined rules of communication of data and flow of control between procedures in high-level languages, procedures would seem to be candidates for choice as segment boundaries. This is often true in many FORTRAN time sharing systems. However this is not the case in block-structured languages such as PL/l and ALGOL. In a block-structured language, a procedure may be internal (known only within the block it is defined) or external (known to all blocks). In the case of internal procedures parameter passing is not the only method of data communication. Since variables defined in the outside blocks are also known to the internal procedure, they may be referenced at any time. The method of such communi- cation is dependent on the compiler. To ensure that such communication does not exist, only the outermost blocks may be used as candidates for segment boundaries. In OS360 the name CSECT is used to describe such logical entities. Thus each outside block of a blocked language and each subroutine of a non-blocked language generates a CSECT for the machine code . A description of each CSECT generated is given as part of the output of the compiler. CSECT, though convenient from the stand-point of the operating system to be used as segments, does not allow the programmer to explicitly specify the configuration of the segments if he so wishes. In some cases, it may be more efficient to put several closely intercalling CSECT' s in the same segment to save segment loading overhead. In OS36O a special system programs is used to combine CSECTs together, known as the LINKAGE EDITOR. The output of the LINKAGE EDITOR is called a LOAD MODULE, because it is in a format readily acceptable by the OS36O system loader. Since each subroutine is compiled separately, only the names of the entry point of the subroutines referenced are known during compilation. The relative addresses of these entry points must be resolved by the LINKAGE EDITOR after it has determined the layout of the CSECTs (generated from the compiler) in the load module. Besides resolving subroutine references, the LINKAGE EDITOR also does a lot of optional editing on the CSECT level. For example it is possible to replace a particular CSECT with another one, it is also possible to create load modules with user defined overlay. Thus proper use of LINKAGE EDITOR commands can lead to efficient organization of load modules and segments. Some compilers generate different CSECTs for constants. 10 Besides the significance of load modules as segments, a load module can also be thought of as a resource needed by a procedure. As a resource, load modules may be classified into several categories. A load module is reusable (serially) if no loading is needed the second time it is entered. Thus before returning to the calling procedure, the load module must restore itself to the condition it was in before it was called. A load module is reentrant if several processes can be executing the same copy of the load module at the same time. Thus it must not contain any process dependent code /variable. A load module is recursive if it can call itself as a subroutine as many times as needed in the program logic. A load module is refreshable if the copy in core may be refreshed (i.e. reloaded) at any time without affecting the course of execution of the process. A load-module is execute only if it does not modify itself in the course of execution. That is the process is unaffected if the load module is stored in read-only memory. (All IBM/360 core is read only to the user process except the region with the same CPU protect key. ) Address resolution can be done by the LINKAGE EDITOR because the layout of the CSECT is known. However this is not true for inter-load module references. Since the loading is dynamic, the address of the reference point is not known until execution. Thus address resolution must be done by segment table look-up during execution. In systems such as MU1TICS, THE, and TSS360/67, special hardware is used to facilitate the table look-up. In systems without look-up hardware, this must be done by the software system or explicitly by the user. When transfer of control is needed to another load module, a system command may be issued to transfer control to the software system which looks up the segment table and then retransfers control to the required load module. Thus a small 11 amount of overhead is needed to achieve this dynamic loading. This overhead may be saved in some circumstances if the address of the load module is passed as a parameter in a procedure call. Thus when a reference to the load module is needed, its address is readily available from the parameter. A process or task in OS36O is created if the CPU is allocated to execute the load modules in core. A process is the execution of a sequence of machine instructions serially and synchronously. Most modern computers are capable of running several processes simultaneously. That is the CPU is allocated sequentially to each of the processes for a short period of time. For example, in a time sharing environment, this time quantum is made small enough that it is invisible to the (possibly many) users who are receiving service from the system at the same time. The method of CPU allocation differs from system to system. In OS36O a priority system is used. That is the highest priority dispatchable process is run until a higher priority process becomes dispatchable or the process itself is blocked for an event (e.g. waiting for i/O). A process is dispatchable if it can be readily executed by the CPU, that is it is not waiting for any event to complete. Besides more efficient utilization of the CPU, multitasking is a convenient and systematic way of taking care of several asynchronous processes at the same time. For example, in a system with a card reader and a line printer, it is desirable that card reading and output printing overlap with problem processing time so that the CPU is not wasted waiting for the slow i/O devices. Tremendous bookkeeping may be saved if multi- tasking is used to implement such a system, because otherwise actual code would have to be inserted into the problem program to look at the i/O devices every short time interval. Perhaps the most useful feature of 12 multitasking from a problem programmer's standpoint is its ability to implement software interrupts. For example, in most systems the task that handles console commands is assigned a higher priority than problem programs. When a command is issued to the console, its process always gets control and thus it can modify or remove any problem task before returning control to the job scheduler which eventually executes the problem programs again. This is particularly useful in establishing a supervisory versus problem program environment. The supervisory program may be assigned a higher priority than the problem program so that it gets control when it wants to. A timer can then be set so that the supervisory program inspects the problem program once every timer interval. Tasks in a multitasking environment are considered as asynchronous. However sometimes it may be necessary for several processes to synchronize with each other. For example after the printer task has printed out the last line in the buffer, it is necessary to wait for the problem programs to generate more lines before printing can resume. On the other hand, several problem programs may want to put print lines on the printer buffer at the same time. However, if there is only one buffer, only one task should be manipulating the buffer at a time. The first case is involved in tasks being blocked for an event to complete; the second case is involved in tasks contending for a non-reentrant resource. In OS36O a full-word variable called an event control block (ECB) is used to synchronize tasks with events. When a system procedure WAIT is called with a zero ECB, the active task is blocked and marked nondispatchable. The task being blocked will be dispatchable again when a system procedure POST is called with the same ECB by another task. Many ways are available to solve the problem of contention. The system procedure ENQ, may be called by the task requesting 13 the resource. The system checks if the resource is readily available. If not, the task is blocked and placed in the waiting queue for the resource. The resource is released if the task that has the resource calls the system procedure DEQ. At this time the first task that is in the waiting queue for the resource is unblocked and is given control of the resource. A more sophisticated approach may be to have a separate task to handle the resource. This is the only task that can operate on the resource. All other tasks must request service from the handler to do the operations for them. Now if the handler is assigned a higher priority than any of the requesting tasks, and the handler never blocks itself when servicing requests, then no contention can occur since once a request is issued by one of the tasks (by unblocking the handler task), the handler at once gets control and none of the other tasks can get control until the previous request is completed and the handler blocks itself to wait for another request for service again. It is possible to implement many features by careful synchronization of several tasks. For example, it is possible to implement coroutine calls by creating handler tasks for each of the coroutines. A call would thus be simply an unblock of the handler to execute the coroutine. A return is simply a block of the handler again. Since the handler can block itself at a multiple number of places, and control is always returned to the point last blocked/returned when next unblocked, a coroutine RETURN is implemented. In OS 36O a task is created when a system procedure ATTACH is called. The new task is called the sub-task of the issuing task. A tree of tasks can thus be created . Any task in OS36O can change the priority of itself and any of its sub-tasks down the tree. It can also change the dispatching status of any of its sub- tasks. However such Ik operations are not permitted on other tasks that are not sub-tasks of the issuing task. When the mother task terminates, all of its sub-tasks will be terminated. This ownership property of tasks is useful in some problems and restrictive on other problems. A job step is an allocation of resources (e.g. i/O device and CPU) for a basic unit of processing. The devices and core are first allocated according to the specification of Job Control Language (JCL) statements for the step. Then the initial task is created to start the processing. A JOB may consist of several steps which are executed sequentially. 15 3. MONITOR DESIGN AND DESCRIPTION One of the major criteria for the design of the monitor is that it should be able to load program segments dynamically as they are needed. Using the IBM 360/75 computer where address translation hardware is not present, a fixed-size page virtual memory system is out of the question. Instead, the load module is used as segments for dynamic loading due to its flexibility in OS36O described earlier. Thus everything that has to be dynamically loaded by the monitor must be in the form of load modules before execution. Also, in order to save overhead and simplify the design, segments that are being replaced are not saved back into secondary storage (disk). Thus when the segment is loaded the second time, a brand new copy of the load module is brought in, and any data within the segment that is modified in the first run, is lost. The user is held responsible for separating data from code, and having it placed in another segment that remains in core all the time, or saving and restoring the data portion on disk himself. This should not be too strict a limitation, since most programs do not depend on data within itself modified during previous runs (i.e. very few programs are history or memory functions). Even if they do, it usually involves trivial change to move that part of the data into the parameters of the procedure instead, and thus occupy storage in the calling procedure which presumably stays in core all the time. If the calling program may be replaced also, the same method may be used to move the data portion up the calling tree into higher level callers until into one that stays in core all the time. Even if this does not work, it is 16 still a trivial change to put i/O statements in the load module to save and restore the data on disk. To simplify the return of the load module to the calling program, the entire hierarchy of calling programs stays in core during the execution of the load module. Thus the problem of loading the caller upon return does not exist. It is necessary to impose this restriction since segments being replaced are not saved, and it is almost certain that the caller depends on data that is modified before the CALL statement. So a fresh loading of a brand new copy of the caller will not work. One of the difficulties that arises from this restriction is that the hierarchy of calling programs may occupy a considerable amount of core. A solution to the above problem is to reorganize the calling structure of the program so that a more shallow hierarchy of calling programs is used. Thus fewer callers have to stay in core at the same time. The callers may also be arranged so that the part of code or data that does not directly involve the CALL statement is regrouped into a separate subprogram so that this portion of code need not stay in core while the load module being called is executing. Such modification can usually be made on most programs without difficulty. However, if difficulty is encountered in such conversion, it is still simple to write procedures that save and restore the most trouble causing calling programs. Address resolution to enable communication of data and flow of control between CSECTs is done by the LINKAGE EDITOR since the lay-out of the CSECTs in the load module is known before execution. This address resolution for load modules that are loaded dynamically must be done by the monitor. However there are many types of communication, such as coroutine and subroutine calls. Also the load module may be reusable, 17 or reentrant. To simplify the bookkeeping for these attributes of the load modules, a more general approach is used. A task is created at the same time the segment is loaded into core. This task is the only process that executes the code in the load module. When the task is created the CPU is directed to start executing the load module from the beginning. The calling program may wait for the task to complete by using the system procedure WAIT with an EC B whose address is passed to the task. The calling program may choose to execute asynchronously or, at some point, wait for the completion of the task. The task (sub-task) signals its completion by calling the system procedure POST to declare the completion of the event ECB. At this point the sub-task may terminate itself if it is a non- reusable load module or use the WAIT procedure to wait for the next call if it is a reusable resource. If this second method is used, the calling program can then POST the ECB instead, on any subsequent calls to the sub-task. Since this waiting for a call can appear anywhere, the sub-task can choose whether a subroutine return or a coroutine return is suitable. In all cases execution resumes right after the WAIT statement. Besides the fact that assigning a sub-task to handle each load module can simplify bookkeeping tremendously and provides a simple way to implement coroutine calls, it also provides software interrupt ability which is useful to implement supervisory programs. Because the priority of each of the sub-tasks is alterable by the user, and the task with the highest priority is given control when requested, all that is needed is to assign a higher priority to the supervisory program. Thus this program will always get control when it wants to and it can examine the problem program any time it likes. 18 The picture now is that there exists a large number of tasks all of them quite independent of each other except at times when they want to synchronize with one another using POST and WAIT. All that is missing is a means to communicate between them (i.e. a telephone network): to pass addresses of ECB s and parameter lists. This is the job of the monitor. The monitor has a knowledge of all the tasks since all tasks are implemented as direct sub-tasks of the monitor. This information is stored in a table maintained by the monitor. When a task is created, the address of an ECB is passed as one of the parameters to the task. This is the means for communicating to the monitor. Normally the monitor task is waiting for a request for service from any of its sub-tasks via this ECB. When the ECB is posted, the address of a monitor instruction block is also given to the monitor. The monitor will then interpret the instruction block and perform the service requested by the task. Upon completion, the monitor task will again wait for another request for service. To ensure that no other task may issue a request before the current request is serviced, the monitor is given a priority If units greater than the initial priority of the sub -tasks. Once the monitor gets control, it causes all of the sub -tasks to be marked non-dispatchable until the service is completed. There are two kinds of communication between sub-tasks, depending on whether the load module is reusable or not. Two monitor instructions are provided. To create a sub-task and thus load a fresh copy of the load module in core (unless a copy is already in core and is marked reentrant), the ATTACH instruction is provided. The monitor checks to see if the module to be attached is already in core. If so, the ATTACH may be suppressed depending on the options used. Otherwise a new copy is brought into core and a new task is created. The addresses of the calling parameters are passed to the new task. A new entry is then made in the task table to 19 include the newly created task. To request service from a reusable load module a QUEUE instruction is implemented. Associated with each task is a request queue (the actual order of the requests in the queue may be other than first in first out ) which contains a list of requests for service for the load module. The addresses of calling parameter lists are stored in each of these queue entries. When the QUEUE instruction is executed, the request with its parameter list is placed on the queue of the task being called. The task is then unblocked by the POST. (in order for the monitor to know the ECB which the task is WAITing for, a special monitor wait procedure must be used instead of the OS36O WAIT procedure. ) The task can now call a monitor utility procedure to examine the queue and service the requests. Both of these instructions involve the name of another sub-task as an operand. The name may be specified in 2 formats. Both formats require the actual 12 character name in the first field. With format 1 an integer called "occurrence" is needed in the second field. Since several tasks with the same name may be executing at the same time, this occurrence field refers to the number of times the same name appears on the task table. For example an occurrence of 2 means the task whose name is the second occurrence on the table. (The order of the names on the task table is unpredictable. ) With format 2 the address of the entry on the task table is given instead. Each task on the task table has its name as part of the entry. This name is compared with the name requested in the monitor instruction operand. Since the entries in the task table can be modified during execution, format 1 provides a very flexible reference to load- modules. It is possible to replace a module dynamically by merely deleting the existing one and changing the name of the replacement to the name of the module being replaced. 20 Some monitor instructions are implemented for supervisory purposes. A SUSPEND instruction is used to temporarily suspend the processing of a task. This provides time for the supervisory program to examine and modify the problem programs. A RESUME instruction is provided to continue execution after the SUSPEND instruction. A DETACH instruction is provided to abort a task when a disastrous error is detected by the supervisory program. Since not all programs execute correctly, some form of super- vision is needed by the monitor to help the supervisory programs. In particular, the CPU time and the ellapsed time are checked. Together with the operand of the ATTACH instruction, the estimated CPU time (seconds) and ellapsed time (minutes) are given to the monitor. This is the initial time estimate of the task. The monitor updates the timer every 5 seconds of CPU time and every minute of ellapsed time. When the estimated time limits are exceeded, the task will be abnormally terminated. The task during execution may extend its time limits, however. All tasks may specify an exit routine to be entered every 5 seconds of CPU time, an exit routine to be entered every minute of ellapsed time, and an exit routine to be entered when the task terminates normally or abnormally. It is hoped that with these exit routines, easier error detection and more flexible program implementation may be done. When a task terminates abnormally, special considerations are necessary to clean up the situation. For example, the task may have ATTACHed sub -tasks that are still actively operating on data in this task. The attached subtasks must therefore also be terminated abnormally to prevent them from further executing data which is known to be erroneous. (Unless, of course, the sub-task has declared to the monitor earlier that its execution is no longer dependent on the data of the creating task. ) The 21 terminating task may be requesting service from another task. This request may be currently under service. In this case the only way to stop execution is to terminate the servicing task abnormally also and inform all requesting tasks, which are still in the queue, that the request is cancelled. The servicing task however may declare to the monitor earlier that its service to all the requests on the queue is vitally important and that it should not be terminated even though the task currently being serviced terminates abnormally. In this case the termination of the calling process is deferred until the service routine has completed. 22 k. USING THE MONITOR AND RELATED SOFTWARE The monitor and related software can be used by three types of commands. The first type of commands includes requests for the monitor to perform certain task manipulating functions. These services are done by the monitor task rather than by the requesting task. The second type of commands, known as UTILITIES, is a collection of reentrant procedures that perform functions that depend on the set-up of the monitor. For example looking through the request queue, extending time limits, and declaring exit routines belong to this category. This type of service is executed by the requesting task. The third type of command, known as system procedures, is a collection of mostly non-reentrant procedures that set up the linkages to use the former two types of commands. Some procedures are implemented merely to extend the capability of some high-level language and are loosely connected to the monitor. These procedures are link-edited into the user's load-modules. 23 k-.O Monitor Instruction Block Format ; (assume set-up in a full-word integer array) ELEMENT 1 Reserved for use of MONITR subprogram. ELEMENT 2 onwards Contains monitor instructions one after another. Direct monitor commands are issued by first constructing an instruction block and then telling the monitor task to interpret the instructions and thus service the request. The monitor is notified of the request when the problem task calls the type 3 procedure MONITR with the instruction block as parameter. For example in FORTRAN the set up is as follows : - INTEGER INSTR(50)/50*0/ set up the INSTR array (put instructions in array) CALL MONITR ( INSTR ) calls monitor for service continue process The instruction block, being an INTEGER*^ array, is in the following format. The first element is reserved for the use of the MONITR procedure. An identification which indicates the issuing task will be placed in this location. Following that, starting from the second element, is a sequence of monitor instructions one following right after another. The monitor will interpret these instructions one after another until an END instruction is encountered which signals the end of the instruction block. Since no other task is dispatchable during interpretation of these instructions, the execution of these instructions can be considered as non-interruptable. 2k k.l ATTACH Instruction : ELEMENT +1 +2 +3 +h FORMAT 1 -6 TASK NAME FORMAT 2 +6 TASK NAME To create a new task. +5 +6 +7 +8 +9 OCCUR CPU ELP PARM ECB ENTRY CPU ELP PARM ECB TASK NAME - 12 Character name of the new task. The first 8 characters are the name of the load module. OCCUR - Number of times the name appears in the task table (binary- integer). Replaced by address of task table entry of new task after execution. ENTRY" - Address of the entry of the new task in the task table. CPU - CPU time limit for the task in seconds, (k byte packed decimal) ELP - Ellapsed time limit for the task in minutes, (k byte packed decimal) PARM - Address of the parameter list to be passed to the new task. The first parameter should be a PARM-field string. ECB - Address of the event control block to be posted when the new task terminates. An entry of zero means that no posting is needed. The ATTACH instruction is used to create a new task. The monitor checks to see if the task already exists or not. If so the attach is suppressed Otherwise a copy of the load module is brought into core if a usable one is not already present. The ATTACH instruction has 2 formats. With format 1 the operation code of -6 is placed in the first element of the instruction. The succeeding 3 elements are filled with the 12 character task name, the first 8 characters of which are -interpreted as the name of the load module. The 5th element of the instruction is the occurrence count. That is the number of times the task appears in the monitor task table. A value of or negative is treated as 1. The 6th element is the initial limit of CPU time for the task. This number is in k byte packed decimal format. The 7th element is the initial ellapse time limit, also in packed decimal. The 8th element is the address of the parameter list which is to be passed to 25 the newly created task. The 9th element is the address of an ECB which is to be POSTed when the task terminates. If a zero is entered in this field, or if the ECB is non-zero and not waited for, no posting will be done. Format 2 of the ATTACH instruction is almost the same as that of format 1 except that an operation code of +6 is used instead. The address of the entry in the task table is given in element 5 of the instruction instead of the occurrence count. This time the monitor only checks to see if the particular entry in the task table has the same name as the task to be created. If not, the task will be created even though there may be several copies of the task executing already. After the ATTACH instruction is executed, the address of the entry on the task table for the newly created task is placed in element 5 of the instruction. The first byte of the entry is set to Hexadecimal 'FF f if the ATTACH was suppressed because a task with same name already exists. In this case the lower order 3 bytes contain the address of the entry in the task table which contains the task with the same name. If the entry is 0, it means the monitor has failed to create the task because the task table is completely full. In this case the user is advised to wait until other tasks terminate to release space or to restart the monitor (thus cancelling all existing tasks). If the monitor is requested to POST the completion ECB, the last three bytes of the ECB are tiie return code. A return code of means the task has reached a RETURN statement which returns control to the monitor. A return code of 3 means the task was abnormally terminated. 26 k.2 DETACH Instruction : To abnormally terminate a task. ELEMENT +1 +2 + 3 +k + 5 FORMAT 1 -3 TASK NAME OCCUR FORMAT 2 +3 TASK NAME ENTRY TASK NAME - 12 Character name of the task. The first 8 characters are the name of the load module. OCCUR - Number of times the name appears in the task table (binary- integer). Replaced by address of task table entry of the task after execution. ENTRY - Address of the entry of the task in the task table. The DETACH instruction is used to abnormally terminate a task. The instruction also has two formats. With format 1 the operation code of -3 is placed in the first element of the instruction. The next 3 elements contain the name of the task to be terminated. The 5th element is the occurrence count as mentioned before. With format 2 the operation code is +3 and the task table entry address is used instead. If the task is found, it is terminated abnormally. Otherwise the DETACH is suppressed. After the DETACH instruction is executed, the address of the entry on the task table for the task that was terminated is placed in element 5 of the instruction. If this entry is zero, the task was not found and DETACH was not performed. 27 k • 3 QUEUE Instruction: To request service ELEMENT +1 +2 +3 H +5 +6 +7 +8 FORMAT 1 -5 TASK NAME OCCUR CPU ELP PARM FORMAT 2 +5 TASK NAME ENTRY CPU ELP PARM TASK NAME - 12 Character name of the task. The first 8 characters are the name of the load module. OCCUR - Number of times the name appears in the task table (binary- integer). Replaced by address of task table entry of the task after execution. ENTRY - Address of the entry of the task in the task table. CPU - CPU time limit for service (k byte packed decimal). Will be replaced by address of queue entry after execution. ELP - Ellapsed time limit for the task in minutes. (k byte packed decimal) PARM - Address of the parameter list to be passed to the task. The QUEUE instruction is used to request service from another task. The request call parameters are placed in the request queue of the servicing task. The servicing task may then look at the request queue sequentially at its own pace. Meanwhile the requesting task may wait for the service to be completed or continue to execute asynchronously. The QUEUE command is also in two formats. With format 1, the operation code of -5 is placed in the first element of the instruction. The 12 character task name of the servicing task is placed in the next 3 elements. The occurrence count is placed in the 5th element. The CPU time limit for servicing the request (packed decimal) is placed in the 6th element, and the ellapsed time limit (packed decimal) is placed in the 7th element. (The monitor only keeps track of the task time limits for each task. It is up to the individual task to keep track of the time needed for each service. ) The address of the parameter list to be passed to the servicing task is placed 28 in the 8th element of the instruction. With format 2, the operation code of +5 is used instead and the address of the task table entry for the servicing task is placed in element 5 instead. The monitor searches for the servicing task in the task table. The CALL is placed in the request queue of the servicing task. The servicing task is notified of the new request by POSTing the request ECB. This ECB may be tested or waited for by the servicing task. After executing the QUEUE instruction, the address of the entry on the task table for the servicing task is placed in element 5 of the instruction. If this entry is zero, the task was not found and the QUEUE instruction was suppressed. The 6th element is set to the address of the entry of the request queue for the CALL. If this entry is zero, the request queue is completely full and the QUEUE was not performed. The user can either wait for some services to complete and thus release space for the queue or restart the monitor (thus cancelling all tasks and requests). The issuing task may test or wait for the service ECB which will be POSTed when service is terminated. This ECB is at a location 36 past the beginning location of the queue entry (36 + the new value of element 6). The issuing task must place a "non-zero number with zero in the high-order byte" (e.g. l) in this entry after inspecting this ECB to release the space of the queue entry for use by other requests. If this value is placed in the ECB before posting is done, the POST will be- suppressed. Otherwise the last 3 bytes of the ECB after the POST contain the return code of the service. A return code of zero means normal return from service. A return code of 1 means the request was cancelled by the monitor before service due to abnormal termination of the servicing task. A return code of 2 means the request was terminated abnormally while being serviced. The user written service program may introduce i 29 other return codes if needed. It is possible to cancel the request before or during execution. This is done by placing a zero or negative number (k byte packed decimal) in the request queue entry at a displacement of 2k from the beginning (2k + the new value of element 6). If the request is already under service, cancellation is deferred until the service routine checks the CPU limit (displacement 2k) parameter of the request at some later point. NOTE: Be sure to fix up QECB (element 6 + J>6) if requesting task wants to cancel the request. 30 k.k CHANGE PRIORITY Instruction : Changes dispatching priority ELEMENT +1 +2 +3 +k + 5 +6 FORMAT 1 -k TASK NAME OCCUR PRTY FORMAT 2 +k TASK NAME ENTRY PRTY TASK NAME - 12 Character name of the task. The first 8 characters are the name of the load module. OCCUR - Number of times the name appears in the task table (binary- integer). Replaced by address of task table entry of the task after execution. ENTRY - Address of the entry of the task in the task table. PRTY - New priority of the task. (k byte packed decimal) The CHANGE PRIORITY is used to change the dispatching priority of the task. This is needed for supervisory programs since they must be able to get control before the problem programs do. The sub -tasks are dispatched at an initial priority of zero. (All priorities are relative to [monitor task priority - k] . ) The monitor task is therefore at a priority of k. Since the monitor task must execute at a higher priority than any of the tasks to avoid contention for monitor service, no task should request this priority. Priority 3 is reserved for communication tasks that interactively communicate with the programmer. Since the interactive console task is not part of the monitor, user tasks may use this priority if slow console response is not of concern. Priorities 2 and 1 are reserved for supervisory programs and sub-system monitors. It is also possible to use negative relative priority to lower the priority of some tasks (provided that the negative value is not too large). It may be good practive to lower the priority for CPU bound tasks. The CHANGE PRIORITY instruction also has two formats. With format 1 the operation code of -k is placed in the first element of the instruction. The next 3 elements contain the 12 character name of the task. The 5th element is for the occurrence count. 31 The sixth element is the new relative priority of the task (packed decimal) . With format 2 the operation code is -+4 and the address of the task table entry is given in member 5 instead. After executing the CHANGE PRIORITY instruction, the address of the task table entry for the task being changed is placed in element 5. If the entry is zero, the task was not found and the instruction was suppressed. 32 k. 5 SUSPEND Instruction: Temporarily suspend the execution of a task. ELEMENT +1 +2 +3 +k +5 FORMAT 1 -7 TASK NAME OCCUR FORMAT 2 +7 TASK NAME ENTRY TASK NAME - 12 Character name of the task. The first 8 characters are the name of the load module. OCCUR - Number of times the name appears in the task table (binary- integer). Replaced by address of task table entry of the task after execution. ENTRY - Address of the entry of the task in the task table. The SUSPEND instruction is used to temporarily suspend the execution of the problem program so that a supervisory program can examine it at its own pace. The SUSPEND instruction also has 2 formats. With format 1 the operation code of -7 is placed in element 1 of the instruction. The next 3 elements are for the 12 character task name. The 5th element is for the occurrence count. With format 2 the operation code is +7 and the task table entry address for the task is placed in element 5« After executing the SUSPEND instruction, the address of the task table entry for the task being suspended is placed in element 5, as for the instructions mentioned before. 33 h. 6 RESUME Instruction : Continue execution of a previously suspended task. ELEMENT +1 +2 +3 +k +5 FORMAT 1 -8 TASK NAME OCCUR FORMAT 2 +8 TASK NAME ENTRY TASK NAME - 12 Character name of the task. The first 8 characters are the name of the load module. OCCUR - Number of times the name appears in the task table (binary integer). Replaced by address of task table entry of the task after execution. ENTRY - Address of the entry of task in the task table. The RESUME instruction is used to continue execution of the previously SUSPENDed tasks. Issuing this instruction to tasks not previously suspended produces unpredictable results and may cause abnormal termination of the monitor task. Format 1 of the instruction has an operation code of -8. Format 2 of the instruction has an operation code of +8. The instruction format and resultant condition is exactly the same as the SUSPEND instruction. 14-. T EXECUTE Instruction : Execute a sub-program in the monitor task. ELEMENT +1 +2 EXEC 2 ENTRY ENTRY - Address of the entry point of the sub-program. The EXECUTE instruction is used to request the monitor task to execute a subroutine. Upon return the monitor resumes interpreting the rest of the instructions in the instruction block. The operation code of 2 is placed in the first element and the entry point address of the subroutine is placed in the second element. The subroutine must use standard FORTRAN linkage conventions, No parameters are passed to the subroutine. 3* 4.8 NOP Instruction : No operation ELEMENT +1 NOP 1 The NO-OPERATION is a one element instruction provided for easy coding (e.g. pack with NOP). The operation code is 1. It does not have any operands. 35 k.9 END Instruction : Marks the end of an instruction block. ELEMENT +1 END The END instruction signals the end of the instruction block. The instruction code is 0. It does not have any operands. If an illegal instruction code is encountered, the monitor places a Hexadecimal 'FF' in the first byte of the operation code. Instruction interpreting is then terminated. 36 1+.10 UTILITIES : The UTILITIES are a collection of procedures rather than an instruction interpretor. They may be used by calling the type 3 procedure UTILTY which provides the linkages. In FORTRAN the set up is as follows: CALL UTILTY (Operation code, Other parameters,....) The first parameter of UTILTY is the operation to be performed. Depending on the operation code, various routines are entered and the rest of the parameters will be interpreted differently. 37 14- . 11 START Routine To pick up task parameters. CALL UTILTY (6, SUB) SUB - This subroutine will be given control with task parameters as its parameters. When a task is created, the address of the parameter list is passed to it. However this is not in a linkage convention acceptable to most high-level languages. The START routine picks up the parameter list and passes it to a user defined procedure. The START routine is entered by calling UTILTY with operation code 6 followed by the entry of the subroutine which is going to pick up the parameters. START will call this subroutine with the task parameters. For example, in FORTRAN if the task is created with the parameter (PARM,P1,P2,P3>P^>. • • ) then the set up within the task should be as follows : EXTERNAL PROCESS main program CALL UTILTY (6, PROCESS) SUBROUTINE PROCESS (PARM, PI, P2, FJ, .. .) process the parameters RETURN END When PROCESS gets control, it will pick up the same parameters passed to it by the creating task. In OS36O the first parameter passed to a task should be a 2 byte count field followed by a character string, which is known as the PARM field in JCL. The user is advised to follow this convention to be compatible with the rest of the programs in the system. 38 4.12 LOOK QUEUE Routine ; To sequentially look at the request queue. CALL UTILTY (5, SUB, KONTRL) SUB - This subroutine will be given control with service parameters as its parameters. KONTRL - Full-word integer used to specify options of LOOK QUEUE. If it is zero, routine will not wait for new request at beginning of queue. Every task has a request queue associated with it. The LOOK QUEUE routine is used to inspect the request queue for the task. The LOOK QUEUE routine is entered by calling UTILTY with an operation code of 5, followed by a subroutine entry which is going to service the request. A third parameter KONTRL is used to control the mode which the routine operates. When LOOK QUEUE is entered with KONTRL nonzero, it will first look to see if there is anything in the Queue. This is known since the monitor POSTs the request ECB every time a new request is placed in the queue. If there is nothing in the queue, LOOK QUEUE will wait for the request ECB until a request for service is present. Then it will pick up the parameters for the request and call the subroutine in the second parameter of UTILTY, giving it all the parameters just the way the START routine works. At the same time the address of the entry of the request queue being processed is placed in KONTRL. Upon return from the PROCESS subroutine control is returned to the caller of UTILTY. If LOOK QUEUE is called again, it will look at the second member in the request queue and pass control to the subroutine as before. This goes on until the request queue is exhausted. When LOOK QUEUE is entered again it will test the request ECB to see if any new request has arrived. If not, it will wait for a new request as it did the first time. Otherwise it will go through the request queue again and start processing the new requests. Every time LOOK QUEUE starts looking at the queue from the beginning again, 39 the first byte of KONTRL is set to Hex. 'FF\ The user subroutine is responsible for canceling the request after finishing service. Sometimes it is desirable to merely inspect the queue without processing it. This may be done by calling LOOK QUEUE with KONTRL equal to zero. (Since the value of KONTRL is changed every time, it is necessary to initialize it to zero before entering LOOK QUEUE. ) With KONTRL zero, LOOK QUEUE works exactly the same as before except that when it reaches the end of the request queue, instead of it checking for new requests, the calling program is held responsible for that. In this case, the PROCESS subroutine is not entered. KONTRL is set to the address of the request ECB that the user program should wait for. The first byte of KONTRL is again set to Hex. 'FF'. With this option, it is possible to examine the request queue as many times as one likes. (The entries in the request queue stay until they are explicitly cancelled. ) Since the request queue may be modified by a number of tasks, user programs should only process the request that is currently being looked at by LOOK QUEUE. One of the functions of LOOK QUEUE is to inform the monitor that the request is currently under service and that it should not try to do anything to that element of the request queue. J+o If. 13 SERVICE DONE Routine : To remove a request from the queue. CALL UTILTY (8, Completion-code) Completion-code - This code is placed in the last 3 bytes of the service completion ECB. (full-word integer) The element in the request queue stays until it is canceled. The SERVICE DONE routine removes the member from the request queue and signals completion of service by POSTing the completion ECB. The SERVICE DONE routine is entered by calling UTILTY with operation code of 8, followed by the return code to be placed in the last 3 bytes of the ECB. CALL UTILTY (8, 0) return code is zero. kl k.13 MODIFY TASK TABIiE Routine ; CALL UTILTY (k, CANCEL, HJD, CPU, ELP, RTEXIT, UTEXIT, UCOMP) CANCEL: Fullword binary integer which specifies if the servicing task should be terminated if the requesting task terminates. +ve = do not terminate servicing task = keep entry same as before -ve = terminate servicing task IND: Fullword binary integer which specifies if the issuing task is independent of the creating task. +ve = dependent -ve or = keep entry same as before CPU: Set remaining CPU time in seconds (fullword binary integer). Entry is algebraically added to the remaining CPU time limit of the task table. A bias of -100,000,000 may be added to the desired CPU time to specify that the task CPU time is to be replaced by this value directly, instead. ELP: Set remaining ellapsedtime in minutes. Description is same as CPU. RTEXIT, UTEXIT, UCOMP: Subroutines to be given control every minute of real time, every 5 seconds of CPU time, and when the task terminates. An entry of zero means that no exit routine is needed. An entry of -1 means keep entry same as before. It is possible to modify the time limits and other attributes of the active task. This is done by calling the MODIFY TASK TABLE routine. The MODIFY TASK TABLE routine is entered by calling UTILTY with an operation code of If, followed by a list of modifications. If the second parameter is positive (integer), the monitor is notified that the issuing task does not want to be terminated even though the requesting task whose request the issuing task is servicing terminates abnormally. Instead the termination of the requesting task is to be deferred. If the second parameter is negative, this declaration to the monitor is reset. If the entry is zero, no declaration is given to the monitor. The status remains as before. This feature is provided for tasks that are so important that they cannot be terminated (e.g. console task). Extreme care should be taken when using k2 this feature since the task may be processing erroneous data. The third parameter is also a declaration to the monitor. If it is positive, the monitor is notified that it is now independent of the creating task and thus should not be terminated when the creating task terminates. This feature is provided for service tasks that mainly work on data from the request queue rather than parameters passed at creation time. If the third parameter is negative or zero, the status remains as before. The fourth parameter is the number to be algebraically added to the remaining CPU time limit of the task. Alternatively, an absolute value may be placed in the remaining CPU time limit instead (i.e. regardless of the previous remaining time). This is done by giving a value which is equal to -100,000,000 plus the desired time limit. The fifth parameter is the modification of the remaining task ellapsed time limit which works exactly the same as CPU time. The next J parameters are the minute ellapsed time exit routine, the 5 second task time exit routine, and the task completion exit routine. These routines will be entered in the specified time quantum or when the task terminates. FORTRAN linkage conventions should be used. No parameters are passed to these exit routines. If the entry is zero, the monitor is notified that the exit routine no longer exists. hi k.lk MODIFY QUEUE ENTRY Routine : CALL UTILTY (j>, EXEC, CPU, ELP) EXEC: Fullword binary integer specifying if the request is under service. +ve = under service = keep entry same as before -ve = no longer under service CPU, ELP: same as "that for MODIFY TASK TABLE It is also possible to modify the request queue member currently being looked at by LOOK QUEUE. This is done by calling UTILTY with an operation code of 3, which enters the MODIFY QUEUE ENTRY routine. The second parameter is concerned with whether the request is currently under service or not. If the entry is positive, it declares that the request is under service. A negative entry cancels this declaration. An entry of zero means let status stay as before. By definition, the request being looked at by LOOK QUEUE is currently being processed. However a task may decide to process several requests simultaneously. The only way to declare this is to go through the request queue and declare the request being serviced one by one, then perform the service. The monitor will not attempt to modify the request queue for these requests. The servicing task is responsible for going back again and resetting the previous declarations one by one upon completion of the service. The third and the fourth parameter are to modify the reauest CPU and ellapsed time limit. They work the same way as for the task time limits. 1* fc.15 EXTRACT Routine : To obtain information from the task table. CALL UTILTY (2, CPU, ELP, QCPU, QELP) CPU:- Remaining task CPU time in seconds (fullword binary integer) ELP:- Remaining task ellapsed time in minutes (fullword binary integer) I QCPU:- Remaining CPU time for the service (fullword binary integer) I QELP:- Remaining ellapsed time for the service (fullword binary integer) I It is possible to find out the remaining time limits of the task. This is done by entering the EXTRACT routine by calling UTILTY with operation code 2. In return the 2nd through the ?th parameters are filled in with the remaining task CPU time, remaining task ellapsed time, current request queue member CPU time, and queue ellapsed time, respectively. Since the monitor does not keep track of the queue times, the servicing task will have to take care of it using the UTILITIES routines above. 45 k. 16 (a) WAIT Routine : Wait for the completion of event control "blocks. CALL UTILTY (l, COUNT, ECB1, ECB2, ...) COUNT: Number of events that have to be completed before the task is unblocked. (fullword binary integer) ECB1, ECB2,....- List of event control blocks to wait for. (b) POST Routine : To post the completion of an event control block. CALL UTILTY (0, ECB, Completion-code) ECB:- Event control block to be posted as complete Completion- code: To be placed in the last 3 bytes of the event control block. (fullword integer) One of the methods of task synchronization is to use the POST and WAIT system procedure. The WAIT procedure is implemented using an operation code of 1 in UTILTY. The second parameter is the number of events (ECB) that have to be completed before the task is unblocked. Following that is a list of ECB's the task is to wait for. The initial value of all these ECB's before WAIT should be zero. The POST is implemented using operation code of zero in UTILTY. The second parameter is the ECB. The third parameter is the completion code to be placed in the last 3 bytes of the ECB. k6 ^ #17 SCAN TASK TABLE Routine ; To inspect the entries of the task table — " ~ ' sequentially. CALL UTILTY (9, SUB, WORK) SUB: This subroutine will be given control passing to it the following parameters. SUBROUTINE SUB(TASKTB, IRETN) Fullword array to be overlaid on the entries of the task table. TASKTB; IRETN- Fullword binary integer specifying whether the inspection should be terminated before completion. A non-zero IRETN means that the task table inspection should be terminated. (SUB will be called again and again until IRETN f 0) WORK: An 11-fullword array used for temporary storage. It is also possible to scan the task table thus finding out the names of tasks that are executing. This is done by calling UTILTY with an operation code of % followed by the- entry of the inspect task subroutine that looks at the task table. The third parameter is an array of 11 elements used for working storage by the SCAN TASK routine. When SCAN TASK is entered, the inspect subroutine will be called passing it as the first parameter an array which overlays the first entry of the task table. The second parameter passed to this subroutine is RETURN_CODE, into which the subroutine must place a value before returning to SCAN TASK. If RETURN_CODE is zero, the inspect routine will be called again with the array in the first parameter overlaying the second entry of the task table. This is continued until the entire task table has been inspected and then SCAN TASK will return to the calling program. The scanning of the task table may be terminated in the middle if the inspect task subroutine returns with RETURN_CODE non-zero. In this case SCAN TASK returns to the caller immediately. The working storage passed to the SCAN TASK routine is used to store temporary values and thus it should not be modified until the SCAN TASK routine returns to the hi caller. The array that is passed to the inspect task routine is overlaid on the actual task table. Thus the inspect routine should not try to modify any of its entries or the monitor task may terminate abnormally. The inspect task routine should also be aware that while the task table entries are being inspected, other tasks may be modifying the entries at the same time. A safe way is to use a one instruction non-interruptable move instruction to move the task table to another block of storage before inspecting it. In high-level languages this can be accomplished making use of string moving facilities. The task table contains a lot of entries that are useful only for house-keeping of the monitor. A few that may be useful to the user are given here. The 12 character name of the task starts at a displacement of 32 from the beginning of the task table. This is the same as elements 9, 10, and 11 of the array. The remaining CPU time limit is in element 16 (k byte packed decimal). The remaining ellapsed time limit is in element 17 (packed decimal). The priority is in element 2k (packed decimal). In FORTRAN the set up of the program to print out the name of all the tasks is as follows : INTEGER IWORK(ll) EXTERNAL INSPCT CALL UTILTY (9, INSPCT, IWORK) STOP SUBROUTINE INSPCT (ITASK, IRETN) END INTEGER ITASK(2if) WRITE (6, 100) (ITASK(I),I=9,11) 100 FORMAT (' TASK = %3M) IRETN = RETURN END Note: All the parameters used by the software are full-word integers and should be declared FIXED BIN (31) ALIGNED in PL/l. k. 18 SYSTEM PROCEDURES : COMMENCE entry: To initialize the system routines. It must be the entry point of the load module. After initialization is complete, control will he transferred to entry point ENTER. CALL COMMENCE The system procedures are a set of subroutines that are to be LINK EDITED into the user's load module. They set up linkages to use the monitor and also perform other useful functions. Most of the routines are non-reentrant and non-recursive. They are reusable however. As mentioned before, the address of the monitor service ECB is passed to the task when it is created. This is the only way the task can use all the facilities of the monitor. Therefore it is essential to save this address for later use. The COMMENCE routine performs this function. This must be the entry point of the load module and must be the first routine to get control. After initializing the other subroutines in the system procedures, control is transferred to the entry point ENTER by means of a subroutine call. ENTER should therefore be the entry point of the user's main program. In FORTRAN this can be accomplished by giving the option 'NAME^ENTER' in the PARM field of the compiler. It can also be done by writing a subroutine ENTER which calls MAIN as a subroutine (since the name of the FORTRAN main program is MAIN by default). In PL/ 1 the problem is a little bit more difficult. PL/l/(F) compiler generates code whose entry point is IHENTRY. An ASSEMBLY or a FORTRAN subroutine may be needed to pass control to this entry point. To specify that COMMENCE is the entry point of the load module the ENTRY COMMENCE statement of the LINKAGE EDITOR may be used. In FORTRAN the deck set up may be as follows : h9 mam program SUBROUTINE ENTER CALL MAIN RETURN END //LKED.SYSIN DD * ENTRY COMMENCE I4-. 19 (a) MONITR entry : Request the monitor task to execute an instruction block. CALL MONITR (INSTR) INSTR: Fullword integer array to store the instruction block. (b) UTILTY entry : Link to UTILITIES routine. CALL UTILTY (CODE, parameters, ...) CODE: Fullword binary integer to specify the routine to link to. After the procedures have been initialized, these subroutines may be used. The MONITR subroutine which sends a request in the form of an instruction block to the monitor, and the UTILTY subroutine which sets up linkages to use the UTILITIES have been mentioned in previous sections. 50 ^.20 DELAY entry : To post an event control block after an ellapsed time. CALL DELAY (MINUTE, ECB) MINUTE:- Delay time in minutes (fullword binary integer) ECB:- Event Control block to be posted The user may request the active task to be blocked for a fixed period of time. This is done by using the DELAY routine in the following way (in FORTRAN): MINUTE = ... IECB=0 CALL DELAY (MINUTE, IECB) CALL UTILTY (1,1, IECB ) wait for IECB I continue process The ECB will be POSTed as complete after the specified minutes ellapsed time. Meanwhile the active task can wait for this ECB using the UTILTY WAIT routine. This routine makes use of the MINUTE ELLAPSED TIME EXIT routine of the monitor. Therefore if another exit routine has been specified using the MODIFY TASK TABLE routine earlier, it will be lost. This routine should not be entered before the time interval runs out. Otherwise the previous time interval is lost and the previous ECB is not posted. OS360 only allows one timer for each task. This timer is used by the monitor to maintain many of the time functions. The problem programs therefore should not attempt to use this timer. (For example, the DELAY state- ment in PL/lmay be disastrous.) in order to achieve a real time delay, this subroutine must be used. 51 Ik 21 (a) LIST entry : To place values in an integer array (fullword) CALL LIST (IARRAY, IVAL1, IVAL2, ...) IARRAY:- Fullword integer array which is to receive the values. IVAL1, IVAL2, ...- Values to be placed in the array IARBAY sequentially. (t>) IAD PR function : Returns the address of the parameter. I = LADDR (J) The address of identifier J will be placed in I. To request monitor service, it is necessary to set up an instruction block in an array. In FORTRAN, since only one statement per card is allowed, the set up of the array is tedious and hard to read. A subroutine is implemented to set up the instruction array. The subroutine LIST accepts the instruction array as the first argument. This is followed by a list of arguments. The contents of the second parameter is placed in the first member of the array, the value of the third parameter is placed in the second member of the array, and so on until the parameter list is exhausted. For example to set up an attach instruction in FORTRAN, the following statements may be used: INTEGER INSTR(11),NAME(3)/'SUBTVASK1V 7 CALL LIST(INSTR,0,-6,NAME(1),NAME(2),NAME(3),1,ICPU, IELPS,IAPARM,IAECB,0) CALL MONITR(INSTR) where ICPU is in packed decimal, as is IELPS, and IAPARM and IAECB are the addresses of the parameter list and the completion ECB respectively. In the previous example the addresses of variables are needed. The IADDR function subprogram is implemented for this purpose. It accepts a FORTRAN identifier and returns an integer which is the actual address of the identifier. In PL/l the same function is done by the ADDR built-in function 52 which returns a pointer value. Using this IADDR function, it is possible to address any absolute location in memory using a programming trick: L0GICAL*1 C0RE(1) J=IADDR(C0RE(1)) WRITE (6,10) I,C0RE(I+1-J) 10 FORMAT ('CONTENT OF LOCATION', ZT, 'IS', Z3) This trick makes use of the fact that FORTRAN assumes the array to be contiguous in memory. Using this trick, a complicated data structure similar to that of PL/l BASED variables can be set up. 4.22 (a) IPACK function : To convert binary into packed decimal. IPKDEC = IPACK (IBINAR) The packed decimal representation of the fullword binary integer IBINAR is placed in IPKDEC. (b) IUNPK function : Convert packed decimal into binary representation. IBINAR = IUNPK (IPKDEC) The binary integer representation of the k byte packed decimal number IPKDEC is placed in the fullword IBINAR. The example of attaching a task also needs the packed decimal representation of numbers. The function subprogram IPACK accepts an integer argument and returns an integer which is in k byte packed decimal format. The function subprogram IUNPK accepts an integer argument which is in k byte packed decimal format and returns the binary integer representation of the number. 53 k.2~5 IPARAM function : Prepares a parameter list IAPARM = IPARAM ( JAPARM, Al, A2, ...) The address of the parameter list formed by Al, A2, ... is placed in IAPARM and JAPARM. The parameter IAPARM in the previous example is the address of a parameter list to "be passed to the new task. The parameter list itself is a list of addresses on contiguous locations. The last entry should have a Hexadecimal '80' in its first byte. These addresses are the machine locations of the parameters to be passed to the new task. It is possible to set up this parameter list in FORTRAN using an INTEGER array. For example to pass (A,B) to the new task the parameter list may be set up as follows :- INTEGER LPRMLT (2) LOGICAL #1 LPRMLT (8 ) , Z80/Z80/ EQUIVALENCE ( LPRMLT, LPRMLT) iprmlt(i)=iaddr(a) ^ , , , . ., \ or CALL LIST(IPRMLT ; ,IADDR(A),IADDR(B)) IPRMLT(2)=IADDR(B) J LPRMLT(5)=Z80 put Hex. '80' in first byte of last parameter IAPARM=IADDR ( IPRMLT ( 1 ) ) A more convenient way is implemented. The function subprogram IPARAM can prepare the parameter list. The first parameter of IPARAM is JPARAM which is used to return the address of the parameter list. At the same time the value returned from this function is also the address of the parameter list. So this subprogram can be used either as a function or as a subroutine. The parameters are put starting from the 2nd argument of IPARAM. To accomplish the example above, the following FORTRAN statement may be used:- IAPARM=IPARAM( IAPARM, A, B ) In OS36O conventions the first parameter for a new task is called the PARM field. The format of the parm field is that the first half-word % is the COUNT which tells the number of bytes following this COUNT field. The bytes that follow are used to store a character string that is less than or equal to 100 characters long. This character string is used in many system programs to specify the options to be used. For example it is possible to change the standard options of the compilers by specifying the desired options in this PARM field. Although most of the user programs may not need this character string, it is good practice to always reserve this parameter so that the program is compatible with OS programs. In setting up this PARM field, it must be noted that the actual character string (excluding the COUNT) must start on a full-word boundary. 55 k.2k INITIAL TASK STARTING : With the previously mentioned 3 types of commands to use the monitor and software , a very flexible program can be set up. The only problem is to start the first user task which can then issue the commands to create new tasks. The monitor interprets and executes the PARM field passed to it when the monitor task is created, as the first instruction block. The first 2 full-words of the PARM must be zero. The second full- word is used as the completion ECB for the first task. The 3rd through the 9th full-words are the 12 character name, occurrence count, packed decimal CPU time limit, ellapsed tine limit, and address of parameter list to be passed to the new task. The 10th full-word can be anything and will be set to the address of the completion ECB which is the 2nd full-word. After attaching this task, monitor continues to interpret the next instruction in the PARM field until an END statement is executed. 56 5. EXAMPLE OF INTERACTIVE CONSOLE PROGRAM A program that displays to the programmer messages and status of programs at run time, and allows the programmer to inspect and modify the programs, would be a very useful tool in developing artificial intelligence programs. The on-line supervision allows the programmer to better understand the strong points and the weak points of his methods. This is particularly useful in understanding learning type programs. Since communication hardware that enables this on-line facility differs greatly from one remote site to another, the site at the ILLIAC III machine room is used as an example below, to illustrate the design of the CONSOLE program. The actual implementation may differ depending on the programmer. A PDP-8/e computer with 8K 12 bit words is used at this site to handle communication with the IBM 360/75 at D.C.L. as well as controlling some of the peripherals at this site. Connected to this PDP-8/e computer are two teletypes which can be used as consoles. Also connected to the computer is an 80 character/second line printer which can be used for printing output of programs. A lj.6 mm film flying spot scanner is included to digitize pictures for researches in pattern recognition. Two Frabretek core boxes of l6K 72 bit words each are used for intermediate storage for on-site processing programs. Two Line tape drives are used for secondary storage. Communication on the IBM 360 end is handled by a 2701 parallel data adaptor which is connected to the selector channel of the system. A separate task is used to implement the console program to allow it to execute asynchronously with other programs. This task is to have a 57 priority of +3 and all other tasks should have priorities less than or equal to 2. This ensures that the CONSOLE task will get control when a command is issued to it from the remote site. Since the CONSOLE task handles all communications between the remote site and the main computer, it may get requests for service from both sources. The remote site may need service because it is ready to transmit commands and data to the main computer. Any task in the main computer may need service because it has messages to be sent to the remote site. Requests from other tasks can be handled easily using the QUEUE instruction of the monitor. Any task that wants to send messages can QUEUE for the CONSOLE. The CONSOLE can then look at the request queue and send the messages one after another. Requests from remote sites are done by hardware interrupts. When an interrupt occurs, OS36O will POST an earlier declared ECB complete. When the program that handles the I/O sees this ECB completed, it can then initiate the data transfer by issuing commands to the channel. The CONSOLE program must therefore be aware of 2 ECBs : one that indicates new requests in the request queue, and one that indicates a request from the remote site. CONSOLE should be unblocked when either of these ECBs is POSTed. The option of the LOOK QUEUE routine which allows the user to check the request ECB must be used. I.e., KONTRL must be initialized to zero everytime before LOOK QUEUE is entered. CONSOLE can then check this KONTRL parameter every time when LOOK QUEUE returns. If it is negative, LOOK QUEUE has just reached the end of the request queue and is prepared to start from the beginning again. The lower order 3 bytes of KONTRL make up the address of the request ECB which indicates if new requests have come or not. After zeroing the first byte, CONSOLE can wait for either this request ECB or the remote site ECB to complete using the UTILITIES WAIT routine. This is accomplished by specifying a wait count 58 of one and listing both ECB s following it. Once out of the WAIT, CONSOLE should check both ECBs to find out which (or both) is POSTED. The one POSTED will have a one in the second bit of the first byte. After finding out the source of request, both ECBs should be zeroed since another request may come while the current one is being processed. Requests at the remote site should be given higher priority, since they may be direct commands from the programmer. A channel read may be issued to fill a buffer with information from the remote site. This may contain commands to be executed or messages to be routed to the tasks. If the input is a command, it can be executed either entirely in the CONSOLE task or by constructing the proper instruction block to be passed to the monitor task to be executed. If the input is a message to be routed, the reply table can be checked to find out the task to route it to. When a task wants to get reply messages from the remote site, one of the parameters of the QUEUE to CONSOLE is reserved for CONSOLE to put an identification number in to keep track of the issuer. A message is sent to the remote site with the reply identification to notify the remote programmer of the request for reply. The request in the queue is not removed. When a message is received from the remote site, CONSOLE can then go through the request queue again using LOOK QUEUE to find out the one ■ to route the message to. The request in the queue can then be removed using the UTILTY command SERVICE DONE- (8). If the request in the queue is just to send a message, the proper message can be sent to the remote site and the request can be removed from the queue immediately. It is more efficient to group the messages and commands into a large block before sending them. Both CONSOLE and the remote site should thus reserve space for the buffer. Transmission only occurs when the buffer is full, unless the message is very important and has to be sent 59 immediately. A parameter should be passed to CONSOLE to tell the importance of the message. The device to he sent to (e.g. printer or teletype) should also be specified. Since both the printer and the teletype are slow devices, only important messages should be sent to these devices. The normal program output should be sent to LINC tapes to be printed out later. The commands that the CONSOLE accepts from the remote site should be flexible enough so that the programmer can do practically any on-line processing, and also simple enough so that the commands can be entered easily and efficiently from the teletype. However these two objectives are often against each other. To be flexible a lot of options must be provided to handle all needs. To be simple to use standard options and decisions must be done for the programmer so that he is not bothered with typing in all the options that do not affect him. For example, machine assembly gives flexibility, yet high-level languages are easy to use. To accomplish both flexibility and simplicity of use, it is best to implement two sets of commands. For flexibility, the first set of commands should allow the remote site to construct monitor instruction blocks, parameter lists, and actual parameters. It is even better if it is possible to load routines from remote sites. Storage should thus either be reserved or dynamically obtained in which to place these commands. The remote site should be able to inspect the contents of any location in core and modify the region of core belonging to the user program. This feature would allow remote site programmers and computers to construct any program in the main computer. For commands to be simple to use, it is only necessary to implement commands that are most often used in the second set of commands. The following is a sketch of possible commands: 6o 1. RUN program (parameters,...) -- This command essentially loads a program and executes it. If time limits etc. are not specified, a default limit should be provided for it. The programmer should be notified when the program terminates. 2. CALL program (parameters,...) -- This command essentially puts a request in the request queue of the servicing task. The programmer should be notified if the servicing task cannot be found. 3. SUSPEND program -- This command temporarily suspends the particular program for the programmer to inspect it. An option should be provided to suspend all programs. (Use SCAN TASK TABLE and suspend each one except CONSOLE. ) If. RESUME program -- This command resumes execution of a previously suspended program. CONSOLE should keep track of which task has been suspended and issue the command after checking this table. An option should be provided to resume all programs. 5. CANCEL program -- This command abnormally terminates a program. 6. CHANGE PRIORITY program, priority — This command changes the dispatching priority of a program. The program should never be allowed to have a priority higher than 2. 7. CHANGE TIME LIMITS program, time limits ... -- The time limits of the program are changed. 8. DISPLAY TASK program -- The status of the program is displayed on the teletype. An option should be provided to display all the programs executing at the time. 9- REPLY reply-identification, 'reply message . . . ' -- A reply message is routed back to the program which requests a reply from the remote site. 10. RESTART SYSTEM — The system monitor is restarted and all executing programs are lost. This is provided in case a disastrous error is found. 11. WRITE TO OPERATOR 'message, ... ' -- The message is routed to the main computer operator. If a reply is needed, it will be displayed on the teletype. The RUN and the CALL commands are most useful in adding new features to the system. It is possible to implement these features as separate programs that will be started when the particular service is needed by the CONSOLE. 61 6. USAGE EXAMPLE (TEXTURE DISCRIMINATION) The following problem arises when developing programs to recognize textures. The program can be separated into 5 steps. In the first step a texture on film is scanned and digitized at the remote site. The digitized picture is sent to the main computer to be stored in secondary memory for further processing. In the second step, operations are performed on the 2 dimension digitized picture array using the subroutine package PAX II which is a simulation of the hardware of the ILLIAC III pattern articulation unit. Features that are considered relevant are extracted. In the third step these features are processed by statistical programs to determine the correlations between them. In the fourth step, results of statistical analysis are processed by variable logic programs that construct discriminating rules for the textures. In the fifth step the rules are checked against the original texture to determine the accuracy of these rules. At the same time the picture is edited to enhance places where discrepancies occur. This new picture is reprocessed starting from step 2 to derive further discriminating rules. Meanwhile tests are performed to determine if any further discrimination is obtained by another iteration. One of the problems that arises is that all of the routines to perform the steps take up a considerable amount of core. What makes the problem worse is that these routines were written by different persons who did not take the other routines into consideration at the time they were developed. Some of the routines are written in FORTRAN and some of the 62 routines are written in PL/l. Most of the routines accept input from the card reader and print output on the printer. Therefore the problem of linking these routines involves changing these programs to accept input and to output results through parameter passing. The structure of the program has to "be arranged such that only one of the 5 steps is in core at a time. Another problem that arises in this example is that the routines used for statistical and variable logic analysis are not very reliable. In some cases, these routines execute for a long time without giving any results at all. The nature of the problem may be both methodological and program implementation. However, the cause of the problem can usually be easily determined and possibly corrected if the intermediate results of the computation are examined for every time interval. In other words, some kind of supervision is needed when running these two steps. The above two problems can be solved by organizing the program as below. A main program is written as a separate task. This main program calls each of the 5 steps sequentially by means of the ATTACH instruction, so that only one of them is in core at a time. Space is reserved in this main program to pass intermediate results from one step to another. A supervisory program is created every time the statistical and the variable logic analysis steps are executed. This program examines the intermediate results and communicates to the programmer through the CONSOLE. The edited picture after each iteration is displayed on the remote site and the programmer can determine whether to start the next iteration or not. MAIN PROGRAM i DATA ' CONSOLE Remote Site STEP 1 PICTURE SCANNING STEP 2 FEATURE EXTRACTION STEP 5 STATISTICAL ANALYSIS < > SUPERVISOR PROGRAM (-i STEP k VARIABLE LOGIC STEP 5 PICTURE EDITING 63 7. USAGE EXAMPLE (MULTI- INSTALLATION PROGRAMMING) The nature of some problems may be such that best efficiency- is obtained if part of the problem is run on one installation whereas another part is run on another installation. For example the IBM 360/75 at the University of Illinois is efficient in processing the preliminary steps of pattern analysis because of its efficient i/O facilities. However the IBM 360/91 at U. C.L.A. is efficient in processing the variable logic step due to its fast CPU. The parallel processor ILLIAC IV at Ames, California is efficient in doing Fourier transforms on pictures. All these computers are accessible either through telephone lines directly or through the ARPA network. However the problem of automatically routing portions of the program to these installations and communicating to them simultaneously cannot be easily done by conventional programming methods. Yet this is readily solved using the monitor. Since as far as the monitor is concerned, the CONSOLE is a task just like any other task running under it, it is possible to have many console programs such as CONSOLEJJCLA, CONSOLE_ILLIAC_IV, etc. Each of these console programs can handle communications from one installation. Thus when the user program wants to route portions of the computation to another installation, it is only necessary to call the corresponding console program which will generate the correct control statements to start the job at the other installation. These console programs can be written in such a way that the routing of programs is completely transparent to the caller and thus running of the programs can be installation independent. 6k 8. MONITOR LOGIC The system monitor is a load module written in IBM 360 assembler language. The program is reusable, reentrant, refreshable, and execute only. Currently it is tested under OS36O MVT release 20.6 with HASP. However, the assembly should be compatible to both IBM 36O and IBM 370 with OS, with the exception of IBM 360/91 which requires special instructions for machine synchronization. The system monitor nucleus is written with the concept that virtually no structural modifications are to be done to it in the future. (Superficial changes such as inserting NOPR's at appropriate places to run under IBM 360/91 may be done. ) This is because all conceivable changes and modifications can be done by either inserting new load modules which are going to be run as service tasks or using the EXEC instruction of the monitor to implement parts that have to be run in the monitor task. A pretty good knowledge of OS36O would be needed to make any nontrivial changes. Even so, it is still very easy to miss certain semaphores used in the program which are designed to prevent contention and dead-lock. The same monitor code is executed simultaneously by many processes and there are numerous instances when contention may occur. According to experience, the programming tricks to prevent contention efficiently is not one of the problems most programmers have encountered. Therefore it is risky to make changes to the monitor and introduce an error which turns out only when several events occur at the same time. The belief is that to a programmer who is familiar with both OS and multiprogramming, the monitor is not worth 65 much, and it is probably more efficient for him to rewrite it instead. It is because of this that the description of the monitor logic is aimed at giving the monitor application user better knowledge of its usage rather than to someone who intends to make major changes to it. On the other hand, the author is willing to help any user with special needs to implement new features to the monitor. To the application user, who does not have to worry about the problem of several processes contending to execute the same piece of code, the implementation of the monitor is extremely simple. It can be thought of as having individual routes in the monitor each of which is responsible to implement one monitor instruction. A separate routine is used to search the task table sequentially to find the entry of the task that is referenced in the instruction. When monitor gets control a pointer is set pointing to the first instruction of the instruction block. The name and occurrence count portion of the instruction is input to the search routine to find the task. After this routine returns, the operation code is decoded and control is transferred to the corresponding routine which executes the instruction. After execution, the instruction pointer is incremented to point to the next instruction. The next instruction is executed in exactly the same way as the first one. Most of the instructions are directly supported by OS36O and thus their implementations are trivial. Some of them require additional work of the monitor. For example in the attach routine an unused task table entry is found and the name of the new task is then placed in the task table. The same has to be done for a QUEUE instruction except that the entries are parameter lists instead of task names. Both of these searches are trivially simple sequential searches. If an empty space is not found, the proper 66 indication is placed in the instruction and the rest of the instruction is suppressed. The reverse is done during a DETACH instruction. The entry of the task that is to be detached is cleared and marked empty for a future attach request to use. (The user must note that the space used for the entry is not given back to the operating system and thus cannot be used by other user tasks. The monitor determines the size of the table according to the total amount of core available and the amount of requests. If it is found to take up too much space, it can be released only if a RESTART MONITOR command is issued. ) The execution of monitor instructions is a little bit different when the monitor task is first started. The first instruction is reformatted to a proper attach instruction and control is transferred directly to the attach routine after initializing variables used in the program. 6? Attach a task (start) initialization reformat initial attach WAIT for next service ZL Search referenced task Detach Change priority Queue SUSPEND * END Resume Exec 68 +8 +9 PARM ECB PARM ECB 9. SUMMARY OF COMMANDS Monitor Instruction Block Format : (assume setup in a full-word integer array) Element 1 Reserved for use of MONITR subprogram. Element 2 onwards Contains monitor instructions one after another. 9.1 PARM field Format : FULLWORD 123^5 6 7 8 9 10 CONTENT ZERO INITIAL TASK OCCUR CPU ELP PARM ECB 9.2 ATTACH Instruction : To create new task. ELEMENT +1 +2 +3 +k +5 +6 +7 FORMAT 1 -6 TASK NAME OCCUR CPU ELP FORMAT 2 6 TASK NAME ENTRY CPU ELP TASK NAME - 12 Character name of the new task. The first 8 characters is the name of the load module. OCCUR - Number of times the name appears in the task table (binary- integer). Replaced by address of task table entry of new task after execution. ENTRY - Address of the entry of the new task in the task table. CPU - CPU time limit for the task in seconds. (!+. byte packed decimal) ELP - Ellapse time limit for the task in minutes, (k byte packed decimal) PARM - Address of the parameter list to be passed to the new task. The first parameter should be a PARM- field string. ECB - Address of the event control block to be posted when new task terminates. An entry of zero means that no posting is needed. 69 9.3 DETACH Instruction : To abnormally terminate a task. ELEMENT +1 +2 + 3 +k +5 FORMAT 1 -3 TASK NAME OCCUR FORMAT 2 3 TASK NAME ENTRY Definition of entries same as ATTACH. o,.lj. QUEUE Instruction :- To request for service. ELEMENT +1 +2 +3 +k +5 +6 +7 +8 FORMAT 1 -5 TASK NAME OCCUR CPU ELP PARM FORMAT 2 5 TASK NAME ENTRY CPU ELP PARM Definition of entries same as ATTACH except CPU - CPU time limit for service (k byte packed decimal). Will be replaced by address of queue entry after execution. 9.5 CHANGE PRIORITY Instruction :- Changes dispatching priority. ELEMENT +1 +2 +3 +k +5 +6 FORMAT 1 -k TASK NAME OCCUR PRTY FORMAT 2 k TASK NAME ENTRY PRTY Definition of entries same as ATTACH PRTY - New priority of the task. (k byte packed decimal) 9.6 SUSPEND Instruction :- Temporary suspend the execution of a task. ELEMENT +1 +2 +3 +k +5 FORMAT 1 -7 TASK NAME OCCUR FORMAT 2 7 TASK NAME ENTRY Definition of entries same as ATTACH 70 9-7 RESUME Instruction :- Continue execution of a previously suspended task. ELEMENT +1 + 2 +3 +k +5 FORMAT 1 -8 TASK NAME OCCUR FORMAT 2 8 TASK NAME ENTRY Definition of entries same as ATTACH 9»8 EXECUTE Instruction :- Execute a subprogram in the monitor task. ELEMENT +1 +2 EXEC 2 ENTRY ENTRY - Address of the entry point of the subprogram. 9.9 NOP Instruction :- No operation. ELEMENT +1 NOP 1 9 '10 END Instruction :- Marks the end of an instruction block. ELEMENT +1 END UTILITIES . 9*11 START Routine :- To pick up task parameters. CALL UTILTY (6, SUB) SUB - This subroutine will be given control with task parameters as its parameters. 71 9.12 LOOK QUEUE Routine :- To sequentially look at the request queue. CALL UTILTY (5, SUB, KONTRL) SUB - This subroutine will he given control with service parameters as its parameters. KONTRL - Full-word integer used to specify options of LOOK QUEUE. If it is zero, routine will not wait for new request at beginning of queue. 9.13 SERVICE DONE Routine :- To remove a request from the queue. CALL UTILTY (8, Completion- code) Completion- code - This code is placed in the last 3 bytes of the service completion ECB. (full-word integer) 9. Ill MODIFY TASK TABLE Routine :- CALL UTILTY (k, CANCEL, IND, CPU, ELP, RTEXIT, UTEXIT, UCOMP) CANCEL:- Fullword binary integer which specifies if the servicing task should be terminated if the requesting task terminates. +ve = do not terminate servicing task = keep entry same as before -ve = terminate servicing task IND:- Fullword binary integer which specifies if the issuing task is independent of the creating task. +ve = independent -ve or = keep entry same as before CPU:- Set remaining CPU time in seconds (fullword binary integer). Entry is algebraically added to the remaining CPU time limit of the task table. A bias of -100,000,000 may be added to the desired CPU time to specify that the task CPU time is to be replaced by this value directly, instead. ELP:- Set remaining Ellapse time in minutes. Description is same as CPU. RTEXIT, UTEXIT, UCOMP:- Subroutines to be given control every minute real time, every 5 seconds CPU time and when task terminates. An entry of zero means that no exit routine is needed. An entry of -1 means keep entry same as before. 72 9.15 MODIFY QUEUE ENTRY Routine :- CALL UTILTY (3, EXEC, CPU, ELP) EXEC:- Fullword binary integer specifying if the request is under service. +ve = under service = keep entry same as before -ve = no longer under service CPU, ELP:- same as that for MODIFY TASK TABLE 9.16 EXTRACT Routine :- To obtain information from the task table. CALL UTILTY (2, CPU, ELP, QCPU, QELP) CPU:- Remaining task CPU time in seconds (fullword binary integer) ELP:- Remaining task ellapse time in minutes (fullword binary integer) QCPU:- Remaining CPU time for the service (fullword binary integer) QELP:- Remaining ellapse time for the service (fullword binary integer) 9.17 (a) WAIT Routine : - Wait for the completion of event control blocks. CALL UTILTY (l, COUNT, ECB1, ECB2, ...) COUNT:- Number of events that has to be completed before the task is unblocked. (fullword binary integer) ECB1, ECB2, ...- List of event control blocks to wait for. (b) POST Routine : - To post the completion of an event control block. CALL UTILTY (0, ECB, Completion-code) ECB:- Event control block to be posted as complete. Completion-code:- To be placed in the last 3 bytes of the event control block. (fullword integer) 73 9.18 SCAN TASK TABLE Routine ;- To inspect the entries of the task table sequentially. CALL UTILTY (9, SUB, WORK) SUB:- This subroutine will be given control passing to it the following parameters. SUBROUTINE SUB(TASKTB, IRETN) TASKTB:- Fullword array to be overlaid on the entries of the task table. IRETN:- Fullword binary integer specifying if the inspection should be terminated before completion. A non-zero IRETN means that the task table inspection should be terminated. (SUB will be called again and again until IRETN f 0) WORK:- A 11 -fullword array used for temporary storage. 9.19 SYSTEM PROCEDURES :- COMMENCE entry:- To initialize the system routines. It must be the entry point of the load module. Control will then be transferred to entry point ENTER. CALL COMMENCE 9.20 (a) MONITR entry :- Request the monitor task to execute the instruction block. CALL MONITR (iNSTR) INSTR:- Fullword integer array to store the instruction block, (b) UTILTY entry :- Link to UTILITIES routine. CALL UTILTY (CODE, parameters, ...) CODE:- Fullword binary integer to specify the routine to link to. 9.21 DELAY entry:- To post an event control block after an ellapse time. CALL DELAY (MINUTE, ECB) MINUTE:- Delay timein minutes (fullword binary integer) ECB:- Event Control block to be posted 7^ 9«22 (a) LIST entry :- To place values in an integer array (fullword) CALL LIST (lARRAY, IVAL1, IVAL2, ...) IARRAY:- Fullword integer array which is to receive the values. IVAL1, IVAL2, . ..- Values to he placed in the array IARRAY sequentially, (b) IAD PR function:- Returns the address of the parameter. I = IADDR (J) The address of identifier J will be placed in I. 9.23 (a) IPACK function :- To convert binary into packed decimal. IPKXjEC = IPACK ( IBINAR) The packed decimal representation of the fullword binary integer IBINAR is placed in IPKDEC. (b) IUNPK function :- Convert packed decimal into binary representation. IBINAR = IIMPK (IPKDEC ) The binary integer representation of the k- byte pack decimal number IPKDEC is placed in the fullword IBINAR. 9.2^ IPARAM function :- Prepares a parameter list. IAPARM = IPARAM (JAPARM, Al, A2, . . . ) The address of the parameter list formed by Al, A2, ... is placed in IAPARM and JAPARM. 75 10. JCL TO SET UP THE SYSTEM To create a load-module the following statements may be used: //CREATE EXEC FORTLKED, PARM.FORT- 'NAME=ENTER * , LIBFILE= 'USER. Pxxxx. SYSTEM' //FORT. SYS IN DD * FORTRAN source statements /* //LKED. SYSLMOD DSN=USER. Pxxxx. LOADLIB(programl) ,DISP=OLD //LKED.SYSIN DD* object deck for system procedures (if not on disk) ENTRY COMMENCE /* To run the above program under monitor: //RUN EXEC PGM=moni tor, PARM=' ?????? ??programl ????????????????' //STEPLIB DD DSN=USER. Pxxxx. LOADLIB,DISP=SHR // DD DSN=USER. Pxxxx. SYSTEM, DISP-SHR //FT06F001 DD SYS OUT =k //FT05F001 DD * //SYSUDUMP DD SYS0UT=A. To create a new load library: //NEWLIB EXEC PGM=IEFBR1!^ //LOADLIB DD DSN=USER. Pxxxx. LOADLIP,DISP=(NEW,CATLG) ,UNTT=DISK,, // VOL=SER=UIUSRx,SPACE=(TRK,(xx,x,x),RLSE) // Change "CATLG" to "DELETE" to delete the load library. 76 11. EXAMPLE OF PL/ 1 PROGRAM SETUP /* EXAMPLE OF CALLING SEQUENCE*/ MAIN .-PROCEDURE (PARM) OPTIONS ( MAIN); /*SET UP PL1 ENVIRONMENT*/ DECLARE PARM CHARACTER(lOO) VARYING, START ENTRY; /* INITIALIZATION BEFORE PICKING UP OTHER PARAMETERS*/ CALL UTILTY (BINARY^, 31,0 ), START); /* GO TO START TO PICK UP OTHER PARAMETERS AND PROCESS. NOTE THAT UTILTY ONLY TAKES FULL-WORD ARGUMENTS */ START: PROCEDURE (lC0UNT,PARMl,PARM2,PARM3,ETC);/* PICK UP PARAMETERS*/ DECLARE KONTRL FIXED BINARY(3l) ALIGNED INIT(l) , SERVICE ENTRY; /* INITIALIZE THE ROUTINE */ SERVICE_QUEUE:CALL UTILTY (BINARY (5,31,0), SERVICE, KONTRL); /*LOOK AT THE REQUEST QUEUE AND CALL SERVICE TO PERFORM THE SERVICE IF KONTRL = 0_KAY THEN GOTO SERVICE_QUEUE; /* DECIDE TO SERVICE NEXT REQUEST OR NOT DEPENDING ON KONTRL AND OTHER VARIABLES */ SERVICE .-PROCEDURE (QPARM1,QPARM2,QPARM3,QPAPM_ETC); /* ROUTINE THAT ACTUALLY PERFORM THE SERVICE */ /* TAKE CARE OF THE QUEUE TIMING HERE */ /* PERFORM THE SERVICE HERE */ CALL UTILTY (BINARY (8, 31,0) , BINARY (0,31,0) );/*SIGNAL END OF SERVICE WITH RETURN CODE OF "0" */ END SERVICE; END START; /* EXAMPLE OF QUEUEING FOR SERVICE */ DECLARE PARMLIST (5) POINTER, IPARMLIST (5) FIXED BINARY(3l) BASED (PP); DECLARE BPARMLIST(32) BIT(l) UNALIGNED BASED (PB); PP=ADDR(PARMLIST(1));/* OVERLAY PARMLIST WITH IPARMLIST */ PB=ADDR( PARMLIST (5));/* OVERLAY BPARMLIST WITH LAST PARAMETER ADDR*/ /* CONSTRUCT A PARAMETER LIST FOR QUEUEING */ PARMLIST ( 1 ) =ADDR ( 1 ); PARMLIST ( 2 ) =ADDR ( 2 ); PARMLIST ( 3 ) =ADDR ( 3 ) ; PARMLIST(lf ) =ADDR(i^ ) ; PARMLIST(5 ) =ADDR(5 ) ; BPARMLIST (l)='l'B;/*DENOTE LAST ELEMENT OF PARMLIST*/ CALL QUEUE ( CHAR ( 'PDP8 10', 12), IPARMLIST);/* QUEUE FOR SERVICE */ QUEUE : PROCEDURE ( NAME_OF_PROGRAM, PARAMETER_LIST_ ARRAY ) ; /* REQUEST SERVICE FROM A NON-RE-ENTRANT PROGRAM */ DECLARE NAME_OF_PROGRAM CHARACTER (12) , PARAMETER_LIST_ARRAY (*) FIXED BINARY (31),INSTR(11) FIXED BINARY(3l) ,INAME(3) FIXED BINARY(3l) BASED (P), PI POINTER; P=ADDR(NAME_OF_PROGRAM);/*OVERLAY NAME OF PROGRAM AND INAME */ INSTR=0;/* CONSTRUCT INSTRUCTION TO CALL MONITOR */ 77 CALL LIST (lNSTE(l),BINARy(0,3l,0),BINARY(-5,31,0),INAME(l), IMME(2),INAME(3),BINARY(1, 31,0), BINART(27, 31,0), BINARY(29, 31,0 )); Pl=ADDR(PARAMETER_LIST_AERAY(l))j P=ADDR(P1);INSTR(9)=INAME(1); CALL MONITR(lNSTR(l)); /* CALL MONITOR FOR SERVICE*/ IF INSTR(6)=0 THEN PUT LIST( 'PROGRAM NAME NOT FOUND'); ELSE IF INSTR(7) = THEN PUT LIST ( 'MONITOR QUEUE SPACE EXCEEDED'); P =ADDR(P);/* OVERLAY INAME WITH P */ INAME(l)=INSTR(7)+36;/* OVERLAY INAME (l) WITH QECB*/ /* WAIT FOR THE REQUEST TO BE SERVICED*/ CALL UTILTY (BINARY(l,31,0), INAME (l) ); INAME (l)=INAME(l)-l|*l6**7;/* GET RID OF POST BIT*/ IF INAME (1) -1 = THEN PUT LIST ('ABNORMAL RETURN FROM QUEUE'); END QUEUE; /* EXAMPLE OF RUNNING A NON-RE -USABLE PROGRAM */ /* PREPARE PARMLIST ARRAY SAME AS THAT FOR QUEUE */ /* IN ORDER TO BE COMPACTABLE WITH OS 360 THE FIRST PARAMETER SHOULD BE A COUNT FIELD FOLLOWED BY PARM FIELD STRING */ CALL RUN(CHAR('AQ7',12),IPARMLIST);/* RUN THE PROGRAM*/ RUN: PROCEDURE (NAME_OF_PROGRAM, PARAMETER_LIST_ARRAY ) ; /* REQUEST SERVICE FROM A NON-RE-USABLE PROGRAM */ DECLARE NAME_OF_PROGRAM CHARACTER (12) .INAME (3) FIXED BINARY (31) BASED(PR),INSTR(ll) FIXED BINARY ( 31 ), PARAMETER LIST_ ARRAY (*) FIXED BINARY (3l),P2 POINTER, IECB FIXED BINARY (31); ' PR=ADDR(NAME_0F_PR0GRAM);/* OVERLAY NAME OF PROGRAM AND INAME */ INSTR=0;/* CONSTRUCT INSTRUCTION TO CALL MONITOR */ CALL LIST(INSTR(1),BINARY(0,31,0),BINARY(-6,31,0),INAME(1), INAME(2),INAME(3),BINARY(1,31,0),BINARY(^2,31,0),BINARY(1+8,31.0)); P2=ADDR(PARAMETER_LIST_ARRAY(1) ); PR=^IDDR(P2); INSTR(9)=INAME(l); P2=ADDR(IECB); INSTR(lO)=INAME(l) 5 LECB=0; CALL M0NITR(INSTR(1));/* CALL MONITOR FOR SERVICE */ IF INSTR(6)<0 THEN PUT LIST ('PROGRAM ALREADY EXECUTING. '); IF INSTR(6)=0 THEN PUT LIST ( 'MONITOR QUEUE SPACE EXCEEDED'); /* WAIT FOR THE RUN PROGRAM TO COMPLETE */ CALL UTILTY(BINARY(1, 31,0), BINARY(l,3l,0), IECB); IECB=IECB->4*16**7; /* GET RID OF POST BIT*/ IF IECB-»=0 THEN PUT LIST ('ABNORMAL RETURN FROM RUN*); END RUN; END MAIN; 78 12. EXAMPLE OF RUN The BACK SPACE statement is available in FORTPAN to position a file to read the last record. This statement is not available in the highly developed language PL/l. Therefore it is sometimes convenient to use FORTRAN to handle the I/O of some PL/l programs. In the following example a FORTRAN program is written as a servicing task. When the task is created, a parameter is given to specify the number of the file to start process. The actual i/O is done using the QUEUE instruction. (i) // Job card (2) (3) ('4) (5) (6) (7) //* ALLOCATE SPACE FOR THE LOAD-MODULE LIBRARY //CREATE EXEC PGM=IEFBRli|. //EXAMPLE DD DSN=USER.P2123.EXAMPLE,DISP=(NEW,CATLG),UNIT=DISK, // SPACE=(TRK, (10, if, 3), RLSE),DCB=RECFM=U,V0L=SER=UIUSR7 //* FORTRAN SERVICE PROGRAM //FORTRAN EXEC FORTLKED, LIBFILE = ' USER. P2123. SYSTEM ' , PARM. F0RT=' NAME=EI //FORT. SYS IN DD * EXTERNAL START C PICK UP PARAMETERS CALL UTILTY(6, START) STOP END SUBROUTINE START (ICNT,JFILE) INTEGER*2 ICNT COMMON IFILE,IEOF EXTERNAL READF IFILE = JFILE KONTRL = 1 C PREPARE TO SERVICE READ REQUEST 100 CALL UTILTY (5, READF, KONTRL) CALL UTILTY (8,0) IF(IE0F.EQ.0) GOTO 100 RETURN END SUBROUTINE READF (IC0DE,IBUFF,NBUF) INTEGER IBUFF(NBUF) 79 COMMON IFILE, IEOF IEOF = IF( CODE.NE.l) GOTO 100 BACK SPACE IFILE RETURN 100 READ ( IFILE, END=200) IBUFF IF(CODE.EQ.-l) IE0F=2 RETURN 200 IEOF = 1 RETURN END /* (8) //LKED. SYSLMOD DD PSN=USER. P2123. EXAMPLE (READF),DISP=0LD //LKED.SYSIN DD * (9) ENTRY COMMENCE /* //* PL1 MAIN PROGRAM (10) //PL1 EXEC PLLLKEDjLIBFILE-'USER. P2123. SYSTEM 1 , PARM. PL1»' NEST* //PLl.SYSIN DD * /* EXAMPLE PROGRAM */ MAIN : PROCEDURE (PARM_FIELD) OPTIONS (MAIN ); DECLARE PARM_FIELD CHARACTER ( 100 ) VARYING, 1 PARM ALIGNED, 2 FULLWORD FIXED BINARY ( 31 ), 2 HALFWORD FIXED, 2 ICNT INITIAL (0), PARMLIST(3) POINTER. IPARMLIST(3) FIXED BINARY ( 31 ) BASED (P), BPARMLIST(32) BIT(l) UNALIGNED BASED (PB), JPARM(3) BIN(3l), (NBUF, IFILE) FIXED BINARY (31) ALIGNED; NEXTJTLE: PB = ADDR(PARMLIST(2) ) ; P = ADDR(PARMLIST(l) ) ; PUT LIST (*PARM =', PARM_FIELD); /* CONSTRUCT PARM LIST FOR ATTACH */ PARMLIST(l) = ADDR(ICNT); PARMLIST(2) = ADDR(lFILE); BPARMLIST(l) = 'l'B; JPARM = IPARMLIST; /* ATTACH THE FORTRAN PROGRAM */ GET COPY LIST ( IFILE, NBUF); CALL RUN (CHAROREADF',^), JPARM); (11) /* ASSUME PROC RUN IS SAME AS MENTIONED BEFORE */ BEGIN; DECLARE (ICODE, IBUFF ( NBUF)) FIXED BINARY (31) ALIGNED; /* CONSTRUCT QUEUE PARMLIST */ PARMLIST(l) = ADDR( ICODE); PARMLIST(2) = ADDR(IBUFF(1)); PARMLIST(3) = ADDR(NBUF); PB = ADDR(PARMLIST(3)); BPARMLIST(l) = 'l'B; ON END FILE (SYS IN) GOTO FINISH; 80 LOOP: GET LIST(lCODE); CALL QUEUE ( CHAR ('READF', 12 ),IPARMLIST); /* ASSUME PROC QUEUE SAME AS MENTIONED BEFORE */ PUT DATA (I BUFF); IF ICODE = -1 THEN GOTO NEXT_FILE; GOTO LOOP; FINISH: PUT SKIP DATA; END; END MAIN; /* (12) //LKED. SYSLMOD DD DSN=USER. P2123. EXAMPLE (MAIN) ,DISP=OLD //LKED. SYS IN DD * (13) ENTRY COMMENCE (Ik) INCLUDE SYSLIB(ENTER) /* (15) //TEL36272 EXEC PGM=INIT,REGI0N=(100K,15K),PARM= , MA.IN' (16) //STEPLIB DD DSN=USER. P2123. SYSTEM, DISP=SHR //FT06F001 DD SYS OUT =A //SYSPRINT DD SYSOUT=A //SYSUDUMP DD SYSOUT=A (17) //FT10F001 DD DSN=FILE10,DISP=SHR //FT11F001 DD DSN=FILE11,DISP=SHR //FT12F001 DD DSN=FILE12,DISP=SHR //FT13F001 DD DSN=FILE13,DISP=SHR //SYS IN DD * 10, 120, -1 1, 0, 1, 11, 50 1, 0, 0. 0, 0, 0, 0, /* // 0, 0, 1, 0, 0, 0, 0, 0, 0, (1) Put in the job card to run this example. Be sure to allow sufficient lines, execution time, i/O requests, region of core etc. for the program. It is also best to include MSGLE'VEL=(l,l) in the job card to obtain a full listing of the messages about the files used. (2) This step executes a dummy program to allocate space for the load module library. It is only needed if the file has not been allocated before. (3) This DD card allocates a new dataset to be used later for putting load modules. The DSN=USER. Pxxxx. EXAMPLE specifies the name of the dataset. 81 This follows the naming convention used in the accounting system. The "xxxx" is the computer center account number to be used to charge the disk space used. "EXAMPLE" is any name chosen by the user. It cannot be longer than 8 characters. DISP=(NEW,CATLG) specifies that the file is new (Space should be allocated for it. ) and that the name of the file should be placed in the system catalog so that the file can be found easily. In order to place the file name in the system catalog, the index level USER. Pxxxx. must already have been established. If not, consult IBM UTILITIES IEHPROG to do it. UNIT=DISK specifies that space is to be allocated on the disk. SPACE=(TRK, (10, If.,}), ELSE) specifies and the amount of space needed for the file. "TRK, (10" specifies that initially 10 tracks should be allocated for the file. A track is about 7000 bytes of storage. 'V means that if the initial space allocation is not enough, space is added in an increment of If. tracks up to a maximum of 15 additions (or 15 * k - 60 more tracks) provided that the disk have enough space at the time. "3" specifies the number of directory block space to be allocated. The name of each load module in the file is placed in this directory. Each directory block has space to store 6 to 7 load module names. "ELSE" means that if the allocated space is not completely used up at the end of the step, it is to be given back to the system. "DCB=RECFM=U" specifies the format of the file. The format used here is that of load modules. "V0L=SER=xxxxxx" specifies the name of the particular disk pack which the file should reside. "xxxxxx" must be the name of a disk pack that is on the disk drive at the time the program is run. The user must note that disk space is expensive. Thus one should specify just enough space for the load module. 82 (1+) This step compiles and link edits the FORTRAN service program into load module. "LIBFILE= " is the name of the file which stores the system routines. "PARM='NAME=ENTER"' specifies that the name of the CSECT for the FORTRAN main program should be ENTER which is needed for the COMMENCE routine. (5) Control is transferred to subroutine START to pick up the task parameters. (6) Control is transferred to subroutine READF to service read disk requests. (7) Keeps on servicing requests until an END-OF-FILE is reached. (8) "(READF)" specifies the name of the load module for the service program. (9) It specifies that routine COMMENCE should be the entry point for the load module. This should be the first routine that gets control when the task is created. (10) This step compiles and link edits the PL/l main program into a load module . (11) Procedure RUN discussed in an earlier example should be placed in this position in the PL/l deck. The way parameter lists are prepared is exactly the same as that mentioned in a previous example. (12) "(MAIN)" specifies that the name of the PL/l load module should be MAIN. (13) It specifies that the entry point for the load module should be COMMENCE. (ll*.) Presumably a routine ENTER is written which transfers control to IHENTRY which is the actual entry point of the PL/l program. 83 (15) This step executes the two load modules created earlier under the monitor. "INIT" is the name of the load module of the monitor nucleus. 100K fast core and 15K LCS is requested for the step. (The user may- make adjustments to this figure according to the nature of the problem. ) "PARM='MAIN'" specifies the name of the PL/l program as the first task that should be attached by the monitor. Note that a newer version of the monitor is used so only the name of the first task has to be specified in the PARM field. (16) This statement makes the routines of the monitor available to use during execution. (17) This DD card specifies the name of the first file that the PL/l program wants to read. The following DD cards specify other files that the PL/l program may want to read. 8k BIBLIOGRAPHY 1. Assembler (p) Programmer's Guide, GC26-3756-6. 2. Data Management Magro Instruction, GC26 -379^-0 • 3. FORTRAN IV G and H Programmer's Guide, GC28 -6817-2. k. FORTRAN IV Language, GC28-6515-8. 5. FORTRAN Program Logic Manual, Y28-66^2-3. 6. Job Control Language User's Guide, GC28-6703. 7- Katzan, Harry, Jr., "Operating Systems A Pragmatic Approach," Pratt Institute. 8. Knuth, D. E., Fundamental Algorithms, The Art of Computation, Vol. 1. 9. Linkage Editor and Loader, GC28-6538. 10. MVT Supervisor Program Logic Manual, GY28-651I+-8. 11. OS36O Introduction, GC28-653^. 12. Payne, William H., "Machine Assembly and Systems Programming for the IBM 360." 13. PLl/F Language Reference Manual, GY33-6003. Ik. PLl/F Program Logic Manual, GY33-6020-0, Y28-6801-5- 15. PLl/F Programmer's Guide, GC28-659I-7. 16. PL1 Optimizing Compiler Language Reference Manual, SC33-0009-2. 17. PL1 Optimizing Compiler Program Logic Manual, SC33-0025-0. 18. PL1 Optimizing Compiler Programmer's Guide, SC33-0006-0. 19. Principle of Operation, GA22 -6821-8. 20. Programmer's Guide to Debugging, GC28-667O-5. 21. Sayers, Anthony P., "Operating System Survey," Comtre Corporation. 85 22. Supervisor Services and Magro, GC28-6646-6. 23. System Control Blocks, GC28-6628-8. 2k. Tsichritzis, Denis, "Lecture Notes on Operating System," Technical Report jjhk, Aug. 1972, Department of Computer Science, University of Toronto. 25. Utilities, GC28-6586-I2. 26. Watson, Richard W., "Timesharing System Design Concepts," Shell Development Company and University of California, Berkeley. 27. Wong, Tze-Wah, "A Semi -Virtual Memory Multiprogramming System for the Mini Computer PDP/8, " Department of Computer Science Report UIUCDCS-R-7^-641, May 197^. 28. Wong, Tze-Wah, "A Semi -Virtual Memory Multiprogramming System for the Mini Computer PDP/8 Program Listing, " Department of Computer Science File UIUCDCS-F-74-879, May 1974. APPENDIX -A MONITOR, UTILITY, SYSTEM ROUTINES Program Listing 86 87 MACRtf aHPimiLF S-YSUM1 «.P/0L«g,ftTAHKRTi3?2,ftQlNSPrTi1 , MHIPATCHsX »FF FFF Y ' , Lnr, £Nfc)TATCH*X'FFFFFF',MNSRV»2,&N0TSRV«l,&AbN0RML«3, &N0RMAL*U &MdNITR,*TITI SM0NITR LCLA SETC kit &KM0NTR 'M0N1T0R' uutaaouu " EQ ") t KL0flP- SMONITR SETC '&M0DULE' .KLU0P AN0P &KM0NTR SETA *KM0NTR»1 &KM0NTP & TITL A IF ('&M0NlTR.»'(aKM0NTR,l) SETA &KM0NTR-1 _4£-TX ' I M0NITR* NE f «').Kl.00P &TITL . T I T OU T AIF SETC A N tt P UKM0NTR LE 4).TIT0UT ' HM0N I TR '(!,?) , '&M0NITR* (&KM0NTR-1 ,?) iTITL iMONITR TITL CSEC fc 'SYSTEM M0NIT0R T --- EDITEP BY :- TZE-WAH W0NG' ««*im««««i»*«*«« «»*»*»»»« fcjfcAjfcJUt* *_*_» SYSTE F0RMA M M0N T 0F c qu n IGRAM J0B STEP J- > ME . ZERO , CPU , F LA P SE, LIST IT0R MAIN PR0( PARM FIELD 0F T , ZER , EC 8 , N A ME , ZERO , CPU , F L A P SE , P A RM , Z E R O, END I OF MONITOR INSTRUC 8 START -j awe TI0NS NAME,TCA/0CCURENCE» NA ME.TC A /0CC U R E NC e > N AME # TCA/0CCURtNCE, CPU, ELAPSE, PARM, A (ECB) NAME, TCA/0CCURENCE, CPU, ELAPSE, P ARM > 6 ATTACH 5 UUEUE -0 C HA N C E PRI O RITY N A ME , TC A / 0CCU R E N CE , V ALUE REL A T I VE T O MONITOR 3 DETACH NAME,TCA/0CCURENCE; -2 E XEC UTE R O UTINE ENTRY P B INTl lVE NOP END ME A NS O CC U R E N CE, *V E ME A N S TC A TCA FLAG BIT PATTERN :- RE G 13 QUEUE, ACTIVE, NO-CANCEL, PURGE, NORM Au-END, G-EXEC, HALTED, N0T-»USED SA VE A R EA PO I NTER REG REG 12 11 R EG I D PROGRAM BASE REGISTER STORAGE AREA POINTER TC A POINT E R REG REG Ufr, 9 6 STORAGE POOL POINTER QUEUE-ELEMENT POINTER npit nspn 88 RFC « REG 3 tt££ d RET, l« n-ib-ia DETACH R0UTINE RETURN ADDRESS INSTRUCTION BL^CK P0INTFR INSTHUCT10N C0UE PkJlNltR TEMPORARY WPIRKING REGISTtR A_£Ltfi3 AXtLJtX JAB- A Ntt?*-Z£.RtL,N.0N» MEANS N0T Td PMST THt TASK CUMPLE AFTER ExtllJTlPiN, THE TCA IS PLACF N0J HdUNQ.— '_E_F * IV FIRST. HYT PI ACFn in T HE CPu FIELD. Ttf FREE P'O' AND THt UEC6 SET T0 INSPECTF *. KEUTLA , M U ST NUT -Pel NT TB -THE Q«E, TING LLh IN THE ATTACH INSTh. TI0N ECB, IN TCA/0CCHRENCE HELD fZERU IF ATF ATTACH) -TJAE-AX-UE) IS A Qt THfc CPU MUST HE SET T0 UE D, B0TH OEXAMS F0R ISSUETCA AND N0Tt THAT A TASK MAY GET CANCELLE A CANCELLED O-fc. HF VERY CAREFUL t)TT Mi N,SINCE--ELNL Y T HE R EUUESTI TASK AS WELL AS THE REQUESTING TA RETA1NEO, THUS MULTIPLE UUEUEING hHE N -EJMTfcRlNb ANY EX I T RHI.lT INF , Lfl POINTS T^i TCA. THE HIGHER 0RDER H ALL USER ROUTINE. MUST SAVE REGIST E . fi .- iiTH 1 15 REGISTERS AND REG. ESTABLISH BASE 15 AS TKM P RA R REGISTERS V BASE RFf.TSTFK BRANC PRhGR * PR flGR H AR0UND PR0GRAM NAME AM NAME LENGTH AH NAME IN EBCDIC ALF-W/RD B0UNDARY TERS REG, 12 A S BASE R EGIS TE R L0NGER N THE NEW THF STHR EEDED AS B PR0GRAM BA AGE BASE R ASE REGISTER SE REGISTER FGISTER THE TCA THE ST0R THE G>F BASE REGIS AGE P00L R BASF REGIS TER EGISTER R) T0 REG AT LAST 2 NT T0 FUl , 2 BIT 0F RE L-H0RD BflU GISTER 2 NDA RY ? T0 L0AD-M0OULE R) T0 REG, 2 PUT INT0 AVAIL LIST RCHY«1,SP RCHY»J,SP U AS S ■P00L GET »P00L GET TflRAGE ARE ACCAL A(0UR BUR SET U AILC2Q),TCAAVA LERS SAVE SAVE P REG, 13 T0 P IL ZER0 TCAAVA TIME0U SAVE AREA AREA) T0 AREA) T0 ) T0 MURS REG, 1 CALLERS ST0RAGE AREA* ST0RAGE AREA A BASE REG, 0INT T0 0U ILrGAVAILf T,SfRVICF R SAVE AREA DLIST, LA ST l A 1, UTILITY It AUTILITY 9. MGFTRI K AtUTI PUT U SET II LITY TILIT P REG PR0GRAM) Y PR0GRAM . 9 AS ST T0 REGISTE ADDRESS I PIRAGF Prim R 1 N POINTER XC GETNEXT(4),GETNEXT ZERB GETNEXT,NB M0RE ST0RAGE P00L LA 0,GETL*ST END 0F STBRAGE PBBL T0 REG, Li lO,GET N £X Tt4 SET HP REG, in AS TEA PftlNTFR LA l.TCALAST END 0F TCA T0 REG, 1 Hi MVC FLAG(a) ,TCAAVAIL TCA-FLAG P0INT T0 AVAIL LIST SJ lfl,TCAAVAlL AVAIL P0 I NT Ifl TC A LR 10,1 A(NEXT TCA) T0 REG, 10 LA 1,TCALAST END PiF TCA TB REG, 1 CJ L+fl ANV MPIBF SPACE TN STPIRAKE Eflfll 2 BNH M2 IF YES,CBLLECT NEXT TCA AGAIN *. — .— -ATTACH TIMER TASK T0 KEEP TRACK 0F ELIAP5E TIME * LA 1,T IM F0UT AfTTMEBUT) T0 REGISTER 1 *-.-.. ---ATTACH EP«&M0NITR ATTACH THE TIMER TASK F0R fcLLAPSE TIME * ATTACH EP«&M0NITR ATTACH THE TIMER TASK F0R ELLAPSE TIME « STATUS ST0P STBP TTMER TASK UNTIL WF FINISH SERVICE t_ STATUS ST0P ST0P TIMER TASK UNTIL WE FINISH SERVICE LA 1,6(,2) A(PARM ECB) T0 REG, 1 SI l,l«(,g) SET UP A(£CB) IN PA R M FTE L.D LA i,2(,2) A(INSTRUCTI0N BLBCK) T0 REG, 3 LA 2, «t, 3} A(INSTRUCTI0N C0DE)T0 REG, 2 B MATTACH ATTACH THF FIRST TASK SPACE b ♦ .....-—DETERMINE TIMER TASK, SET UP ELLAPSE TIME* AND INTERRUPT * M LINK LJJ 10,1 A(TSERVICE) T0 REGISTER ID S 10,«AtTSERVICF-MTIME) SET UP REG, 10 T0 P0INT T0 TCA LR 2,ia RETURN AODRESS T0 REGISTER 2 L iJ,0(,l) A(PARM) T0 REGISTER LTR 0,0 IS THIS THE TIMER TASK ? BNZ MATIME IF N0T,LINK T0 L0AD M0DULE LA LU4 ACTIME0LIT) T0 BEG. 11 S 11,«A(TIME0UT-MSAVARA) REG, || P0INT T0 ST0RAGE AREA *—.--..STIMER WAIT,BINTVL««F'6000' SET UP ELLAPSE TIMER * HWATf STIMEB WAIT , BINTVL««F 'bOOD' SET UP FLLAP3F TIMER MVI TIME0UT,X'FF' INDICATE TIMER INTERRUPT TS TIME0UTM INDICATE READY T0 P0ST SERVICE ECB BX 4, MWATE IF 0THERS WANT TB P0ST,LFT THEM OB IT LA 1, SERVICE A(SERVICE-ECB) T0 REGISTER 1 LA 0,MWEND A(END INSTRUCTI0N) TB REGISTER CL4 0(l)»X'aO* WERE ME IN THE WAIT STATF HFF0BE ? BNE MWATE IF N0T,DB N0T P0ST *....... -P0ST (l),(0) REQUEST TB SERVICE TIMER INTERRUPT * PB3T (1), (0) REQUEST T0 SERVICE TIMER INTERRUPT B MWATE SET UP NEXT TIMER INTERVAL MWEND OC A(0,0) ISSUETCA,ENDfNULL PRBGRAM TB INTERRUPT SPACE 6 *....... -SET UP TASK TIMER, LINK TB LBAD-MBDULE # ........ -REGISTERS ARE NBT REST0RED IN MLINK * *— — — STIMER TASK,MTIME,BINTVU««F f 500f SET UP TASK TIMER INTERRUPT « MATIME STIMER TASK , MTIME, BINTVL"«F»500* SET UP TASK TIMER INTERRUPT * ---L0AD EPLBCvNAME LBAD THE LBAD MBDULE IN CBRE * L4U0 — EPLBC«NAME LBAD THE LBAD MBDULE IN CBRE LR 15,0 ENTRY PBINT BF LBAD MBDULE TB REG. 15 LA 15,0(,15) CLEAR HIGH BRDER BYTE BF ENTRY PBINT &I 15,TTBACE PUT ENTRY PBINT TB TRACE I 1,TPARM A(PARAMETER LIST) TB REGISTER 1 STM 14,12,12(13) SAVE REGISTERS -BJM-R^ U,15 HRANCH TB FXECUTE LBAD MBDULE LM 14,12,12(13) REST0RE REGISTERS BI FLAG,X»08' SET N0RMAL CBMPLETIBN FLAG BIT -HV4 12(13), X'FF^ INDICATF RFTURN BR 2 RETURN FRBM SUB-TASK SPACE 6 JMMaaa H EAD FR F B R T I MER A N D T ASK EX I T R 0U T I NE S T B B E M B V ED TB TC A DS OF ALIGN 0N FULL«WBRD BBUNDARY DR0P 12 REG, 12 N0 LBNGER VALID AS RASE REGISTER IIKTMR *.m RFC 1 «i 4ft Tt-MPlXBARV BASF wrr.TQTPB 90 THEADtR STM 14(12,12(13) SAVE REGISTERS L 12,ATTEXIT A(TIMER EXIT ROUTINE BODY) TO REG, 12 OR L2 BRANCH TO TIMER EXIT ROUTlNF BODY DS H ALIGN PIN FULL-WOHD BOUNDARY ATTEXIT DC X'«0 f SET FLAG BYTE ACTIVE TCA OX ALMTTEXIT) AfTIMFR FXIT RglUTTNF HPIDYl DROP 15 WE WANT TO CHANGE BASE ORIGIN USING *,15 REG, 15 AS TEMPORARY BASE REGISTER STM ltt,1?,l?(M) SAVE REGISTERS L 12,ATC0MP A(TASK COMPLETION ROUTINE BODY) TO REG, 12 BR 12 bRANCH TO TASK COMPLETION EXIT RUUTINC OS ti ALIGN ON FULL»WQKO BOUNDARY ATC0MP DC A(TASKCOMP) A(TASK COMPLETION ROUTINE BODY) SPACE b *— — . —task timer exit,updatf rpu, decide to ABfNn or not *- DROP 15 REG, 15 NO LONGER VALID AS BASE REGISTER USING *,12 REG, 12 AS TEMPORARY BASE REGISTER TTFXTT IS 10, 15 SFT UP REG, 10 AS TCA POINTER S 12,«A(TTEXIT-M61) SET UP REG, 12 AS PERMANENT BASE REG, DROP 12 WE WANT TO CHANGE BASE ORIGIN USING MM, 12 RFG, 12 IS OUR PFRMANFNT BASE REGISTER SP TCPUU),*P'5' DECREMENT TASK CPU TIME BP Mbi IF TIME NOT EXPIRED, ENTER USER EXIT R0UTIN » — -.ABEND TAH0RT,DI1MP ABORT T ASK IF T IM F F XPIRES •_ ABEND TABORT,DUMP ABORT TASK IF TIME EXPIRES M63 L 15,UTEXIT A(USER EXIT ROUTINE) TO REG, 15 LA 15,0(,15) CLFAR H IGH ORDF R B Y TE LTR 15, IS IS THERE ANY USER EXIT ROUTINE ? BZ Mb2 IF NOT, SET TIMER FOR NEXT INTERRUPT mt MTIMF(q),hO(13) SAVF ORIGINAL REGISTER 10 MVC MTIME + 4U), 68(13) SAVE ORIGINAL REGISTER 12 ST 14,MTIME*8 SAVE RETURN ADDRESS S-IM 14,12,12(13) SAVF REGISTFR8 BALR 14,15 BRANCH TO USER TIMER EXIT ROUTINE LM 14,12,12(13) RESTORE REGISTERS fiiLL 1?(4,13), MTIMF»B R FST0RE R EGISTE R 1 4 SAVE AR M MVC 68(4,13)(MTIME*4 RESTORE REGISTER 12 SAVE AREA MVC feO(4,13),MTIME RESTORE REGISTER 10 SAVE AREA mt MTIMF(lP) (THFADFR RFSTORE TIMFR EXIT HEADFR IN TCA ST 10,16(,13) RESTORE REGISTER 15 SAVE AREA * — — — 5TIMER TASK,MTIME,BINTVL»*F'50Q' SET UP TASK TIMER INTERRUPT * Ji*2 ST IM ER T A,SK| MT I H EfBINTVL i«r'5 00' SFT UP T ASK TIMER INTERRUPT LM 14,12,12(13) RESTORE REGISTERS MVI 12(13), X'FF' INDICATE RETURN Bfl 14 RETUR N FR OM TT MFR EXIT R OUTINE SPACE b •—.——TASK COMPLETION EXIT ROUTINE, DECIDE NORMAL OR ABNORMAL END * DROP 12 W E W ANT TO CHANGE BASE ORIGIN USING TASKC0MP,12 REG, 12 IS OUR TEMPORARY BASE REGISTER TASKCOMP LR 10,15 PREPARE REG, 10 AS TCA POINTER S_ 1O,»A(TC0MP» MT IME) SET UP R FG, 1 AS TCA POINTER S 12,>A(TASKC0MP-Mbl) SET UP REG, 12 AS PERMANENT BASE REG DROP 12 WE WANT TO CHANGE BASE ORIGIN USING Hbl,12 RFG, 12 IS OUR PERMANFNT BASF REGISTER ST 1O,TC0MP*8 SET UP ISSUE TCA MVC BTC0MP(4),«F'3» SET UP OETTACH OPERATION CODE SJ 10,TPARM SET IIP TC A TO BE OETTACHEO XC TTRACE(4),TTRACE SET UP END INSTRUCTION CODE MVC TELAPSE(4),«PL4»«5000000» MAKE SURE SUB-TASK CANCELLED Li O f TrwMP*w AdNS TR U CTI ON BLOCK) TO R EGTSTFR L 1,TSERVICE A(SERVICE«ECB) T0 REGISTER 1 LR 11,1 A(SERVICE*ECB) TO REGISTER 11 S ll,iA(SERVir.F- MS AVARA) REG, 11 P0INT TB STORAGE AREA TS TIMEOUT*! INDICATE READY TO POST SERVICE ECB BC 4,MMb IF OTHERS WANT T0 POST, LET THEM D0 IT r.i t nm.x«an' wfrf wf in the watt state before ? 91 BNE MMb IF N0T,D0 N0T P0ST •P0ST (1),(0) P0ST T0 DETTACH THfc TASK PMST (1) , (Q) PA ST T0 OET TA C H THE TAS K MMb LM 14,12,12(13) REST0RE REGISTERS MVI 12(13), X'FF' INDICATE RETURN OR L4 SPACE b -RET ST0RAGE P00L C«DES T0 BE M0VED T0 ST0RAGE AREA (RENTRANT)* J1S OF ALIGN A N F ULL tW HRD flBUNDARY «... ... --GET MA IN tC,UV»GETLAST-GETNEXT,HIARCHY«l,A«(9) ,SP«P00L * GETST0R GETMAlN EC , LV-GETL AST-GETNEXT , MI ARCHYil , A« (9) , SP»P00L B. K GE T KET1JH N FK 0. M GET STORAGE P0 (flL R O UT INE GfcTEND US OH END 0F GET ST0RAGE BL0CK SPACE 6 »..»... ..f.FT A F(?FF TPA B|-MrK,MFMPlRv MANAGEMENT BBUTTNE i_ GETTCA L 1D,TCAAVAIL TCA AVAIL LIST T0 REG, 10 LTR ID, 10 IS THERE ANY TCA IN AVAIL LIST ? hJU hb IF Y FS,AI L0CA T E TH E T CA LR 10, 14 SAVE REGISTER 14 LA 9,HSAVARA*lb ADDRESS T0 PUT A(ST0RAGE AkEA) T0 REG. 9 MV/C M S AVAPA-»PO(GFTENn.r.FTST0W1 ,GETST0R MUVE GET ST0WE r.flDFTN B MSAVARA+20 BRANCH T0 GET ST0RAGE P00L RGET LR 14,10 REST0RE REGISTER 14 _SJi 1 fj , 1 ZER0 REGISTFR 10 LTR 15,1b 00 WF GET ANY ST0RAGE BNZ 0(,14) IF N0T,ERR0W RETURN L 9,MSAVARA + lh SET UP REGISTER 9 AS ST0RAGE PldBI P0INTFH LA 9,0(,9) CLEAR HIGH 0RDER BYTE MVC GETNEXT(4) ,MGETBLK AVAIL LIST T0 ST0RAGE P00L ST 9,MGPTBLK SFT UP AVAIL LIST T0 P0INT T0 NEW PAUL LA 0,GETLAST END 0F ST0RAGE P00L T0 REG, LA 10,GETNEXT*4 SET UP REG, 10 AS TCA P0INTER Uk 1,TCALAST ENQ BF TCA T0 REG, 1 M# MVC FLAG(4),TCAAVAIL TCA-FLAG P0INT T0 AVAIL LIST ST 10,TCAAVAIL AVAIL POINT T0 TCA L* 1-0*4 A (N E XT TC A) T O R E G , 1 LA 1,TCALAST END 0F TCA T0 REG, I CR 1,0 ANY M0RE SPACE IN ST0RAGE P00L ? BNH m IF Y£S,rOLLECT NEXT TCA AGAIN Mb L 10,TCAAVAIL TCA TO REGISTER 10 MVC TCAAVAIL(4),FLAG AVAIL P0INT T0 NEXT TCA BR 14 RETURN FR0M GET-TCA ROUTINE SPACE b t- — — -GET A FREE Q-E, MEMORY MANAGEMENT R0UTINE I KETQE L fl,QAVAIL AVAIL LIST T0 REGISTER 8 LTR 8,8 IS THERE ANY Q-E IN AVAIL LIST BNZ M7 IF YES, ALLOCATE Q-E «,»,„. ..^GARBAGE COLLECTION, C0LLECT ALL CANCELLED Q-E 1 LA 9,MGETBLK SET UP REGISTER 9 AS STORAGE P00L P0INTER M7b LA 0,GETLAST ENQ 0F ST0RAGE POOL TO REGISTER L-A 10,GETNEXT»4 SET UP REGISTER 10 AS TCA P0INTFR LA 1,TCALAST END 0F TCA T0 REGISTER 1 M75 TM FLAG,X»80' IS THIS A QUEUE ELEMENT 7 B2 (OS IF NOT, LOOK AT NEXT TCA LR 8,10 SET UP REGISTER 8 AS Q-E POINTER M74 TM NEXTRESP,X'40' IS THE Q-E ACTIVE T Bi H74 IF YES, LOOK AT NEXT Q-E CP UCPU(4),iP'0' IS THIS A CANCELLED Q-E T BH M71 IF N0T,LO0K AT NEXT Q-E 15 , R E QTC A A CR EQ U ES TFO TC A ) TM R EG, 15 LTR 15,15 IS THE REQUESTED TASK STILL THERE ? BZ M180 IF N0T, CHECK THE ISSUE TASK C 8, QE XAM«MT I M E (, 1 5) I S TH IS Q -E C U RR E NT L Y BE ING EXA M I N ED ? BE M71 IF YES, LOOK AT NEXT Q-E M160 L 15,ISSUETCA A(ISSUING TCA) T0 REG, 15 I T» IS. IS IS TSRIlTNG TASK STTll THFBF •* 92 BZ M181 IF NUT, CHECK U-EXEC BIT 0F 0-E C 8,QEXAH-MTIME(,15) IS THIS Q-E CURRENTLY BEING EXAMINE07 JLE Mil IF Vf S.l 00K AT MFXT Q»F M181 TH NEXTRESP,X»04' IS Q-EXEC BIT 0N 7 B0 H71 IF 0N,L00* AT NEXT O-E CU BECB,X'BQ* IS S0MEB0OYHAITING FAR TMF ECB 7 BE M71 IF YES,L00K AT NEXT Q-E CUI UECB,X'40' HAS Q-ECB BEEN P0STED 7 BE HT4 IF YES,L00K AT NEXT Q-E CLC QECB(4),«F'0' D0ES ISSUE TASK WANT T0 L00K AT ECB 7 BE M71 IF YES,L00K AT NEXT Q-E L 15,LASTQE A(LAST BmEJ T0 REGISTER 15 LTR 15,15 IS THERE ANY Q-E BEF0RE THIS 0NE 7 BZ H72 IF N0T, CHANGE RQUEUE 0F KEUUESTED TCA mt NEXTQF.-LASTQF(4,15),NFXTQF LAST Q»E PBINT T0 NFXT Q«E B M130 BRANCH T0 CHANGE NEXT Q-E P0INTER M72 L 15,REQTCA A(REOUESTED TCA) T0 REGISTER 15 LXM 1 5 , 15 IS THE REQUESTED TCA STILL EXIST 7 BZ M130 IF N0T, CHANGE NEXT Q-E P0INTER MVC RQUEUE-MTIME(a,15),NEXTQE ROUEUE P0INT T0 NEXT Q-E M13Q L 15,NEXTQE A(NEXT Q»E) T0 REGISTER 15 LTR 15,15 IS THERE ANY Q-E F0LL0WING THIS 0NE 7 BZ M7J IF N0T,TAKE CARE Bf" RE8P0NSIBILITY LIST mt LASTQE-LASTQF (4,15),LASTQF NFXT QwF P0INT T0 LAST Q-E M73 L 15,LASTRESP A(LAST RESP0NSIBILITY LIST) T0 REG. 15 LTR 15,15 IS THERE ANY Q-E BEF0RE THIS 0NE 7 B-Z dXl IF N 0T,CHANGF R LIST I N I SSUING T CA MVC NEXTRESP-LASTQEtl (3,l5),NEXTRESP*l LAST Q-E P0INT T0 NEX B M131 BRANCH T0 CHANGE NEXT RESP0NSIBILITY LIST JUl L 1S,ISSIJETCA ACTSSUING TCA) Tfl REG, 15 LTR 15,15 IS ISSUING TASK STILL EXIST 7 BZ M131 IF N0T, CHANGE NEXT RESP0NSIBILITY LIST MY£ RLIST. MT IME*! (3, 15) , NEXTRESP»1 ISSUING TCA RLIST TB NFXT M131 L 15,NEXTRESP A(NEXT RESP0NSIBILITY LIST) T0 REG, 15 LA 15,0(,15) CLEAR HIGH 0ROER BYTE LXM 15,15 IS THERF ANY RE8PBN8IBILITY LIST F0LL0WTNG BZ M32 IF N0T,PUT Q-E 0N AVAIL LIST MVC LASTRESP-LASTQE(4,15),LASTRESP NEXT Q-E T0 LAST M33 mt NEXTRESP*! (3),QAVAIL»1 B»f PAINT TB AVAIL LIST MVI NEXTRESP.X'80' RESET Q-E ACTIVE FLAG ST 8,QAVAIL QUEUE AVAIL LIST P0INT T0 THIS Q-E J1Z1 U B,QELAST SET UP REGISTER B TB P0INT T0 NEXT Q»F LA 15,QELAST END 0F Q-E TB REGISTER 15 CR 15,1 ANY MBRE Q-E IN THE CURRENT TCA BLBCK 7 BNH MIA IF YES,LBBK AT THE NFXT QmE M7Q LR 10,1 ACNEXT TCA) TB REGISTER 10 LA 1,TCALAST END BF TCA TB REGISTER 1 CR i+U IS T HERE ANY M BRE T CA IN STBRAfiE PBBL T BNH M75 IF YES,LB0K AT NEXT TCA BLBCK L 9,GETNEXT ACNEXT STBRAGE PBBL) TB REGISTER 9 L-T-R S+3 18 THERE ANY MBRE STBRAfiE PBBL. 7 BNZ M76 IF YES,LBBK AT NEXT STBRAGE P00L L 6,QAVAIL Q-AVAIL LIST T0 REGISTER 8 L-M 8^-8 IS THFRE ANY Bag IN AVAIL LIST 7 BNZ M7 IF YE8,ALLBCATE Q-E *— ----- GET A TCA BLBCK TB FBRMAT IT XNTB Q-E *S U- B^U SAVE REGISTER ltt BAL U,5ETTCA GET BNE TCA BLBCK LR 14,8 RESTBRE REGISTER 14 SR k+A ZERB REGISTER 8 LTR 10,10 DB WE GET ANY TCA BLBCK 7 BZ 0(,14) IF N0T,ERR0R RETURN LB 8,10 SFT UP REGI8TFR 8 AS QnF PB1NTFR LA 0,TCALAST END BF TCA BLBCK TB REGISTER LA t.QELAST END BF QUEUE ELEMENT TB REGISTER 1 HA MUr NPVTBtr*P*1 CX} . GiK ATI *1 D.F TBI OUiJI If ST 93 MVI NEXTKESP,X'80' RESET QUEUE ACTIVE FLAG BIT ST 8,QAVAIL AVAIL POINT TO THIS Q»E _LH 6+4 A(NEX T B -E) TO R EGI STE R 6 LA 1,QELAST END 0F Q*E T0 REGISTER I CR 1,0 IS THERE ANY M0RE SPACE IN TCA BLOCK ? gjtti tLB IF Y FS, COLLEC T N EX T Q -E L B,QAVAIL AVAIL LIST T0 REGISTER 8 M7 *VC QAVAIL-M (3) ,NFXTRESP*1 QUEUE-AVAIL P0INT T0 NEXT Q-F BH 1<1 RETURN FROM GET-Q-fc. ROUTINE SPACE 6 *...... --CHECK TIMER FLAG, WAIT F0R AN0THER REQUEST F0R SERVICE * MWATT n T TTMF0IIT f O D0 WF HAVE TO UPDATE E^APSF TTME F0H TASK BE MIC) IF N0T,WAIT F0R AN0THEP REQUEST F0R SERVIC *— — — -PROCESS THE TIMER INTERRUPT , UPDATE ELLAPSE TIME,0ETTACH TASK * Myi TTMFBinT f n ZER O TIM EOU T T fl IN DICATE INTE R RUPT S F RV IC LA 9,MGETHLK SET UP REG, 9 AS ST0RAGE P00L P0INTER MmT ECB«SERVICF WAIT FBR NEXT RFQUEST F0R M0NITBR SFPVICF* WAIT ECBbSERVICE WAIT F0R NEXT REQUEST F0R M0NIT0R SERVICE .———STATUS ST0P ST0P ALL SUB«TASK UNTIL REQUEST IS O0NE * STATUS STEP STgP ALL SUB-TASK UNTIL REQUEST IS DONE L 3, SERVICE ACINSTRUCTI0N BL0CK) T0 REGISTER 3 XC SERVICEC4), SERVICE ZER0 SERVICE-ECB F0R NEXT REQUEST ma TIMEBUT»1,0 READY T0 ACCEPT AN0THER P0ST AGAIN MVI 0(3), CLEAR HIGH 0RDER BYTE 0F ISSUE-TCA LA 2,4(,3) A(FIRST INSTRUCTION) T0 REGISTER 2 -M400 L 15,0 ( , 2) INS TRU C T I ON CODS T O R E GI S T E R 15 LTR 15,15 INSTRUCTION FORMAT IS TCA OR OCCURENCE ? BNM M15 BRANCH T0 DECODE TCA INSTRUCTION F0RMAT L 1,U(,2) OCCURENCE TO REGISTER 1 LA 9,MGET8LK SET UP REGISTER 9 AS STORAGE POOL POINTER M13 LA 0,GETLAST END OF STORAGE POOL TO REGISTER LA in.GFTNEXT*<» SET IIP RFGTSTFR IP AS TTA PPITNTFR 9k LA 14,TCALAST tND OF TCA T0 REGI8TER 14 M12 TM FLAG,X'9U' IS THIS A TCA WHICH IS N0T IN PURGE STATE? &2 MM IF YES,CHECK IF TCA IS ACTIVE B MJ 1 IF N0T,L00K AT BTHtR TCA M80 TM HAG,XMO f IS THIS TCA ACTIVE T HZ M44 IF N0T,L0BK AT flTHER TCA CLC NAME(12),4(2) DOES THE NAME MATCH WITH THAT IN INSTRUCTI UNt Mil IF N0T,L00K AT 0THER TCA S l,«F'l* nFCREMENT OCCURENCE BY 1 8NP M14 IF ALL 0CCURENCE FOUND, BRANCH T0 DEC0DE IN MU LR 10,14 A(NEXT TCA) T0 REGISTER 10 LA 14,TCALAST END PlF TCA TM HFKTSTFR 14 CR 14,0 ANY M0RE TCA LEFT ? BNH M12 IF YES, LOOK AT NEXT TCA L 9,GETNFXT Af NF XT S TORAG E P0 0L) TB R EGISTE R 9 LTR 9,9 IS THERE ANY M0RE ST0RAGE P00L ? BNZ M13 IF YES, LOOK AT NEXT 5T0RAGE P00L Mlb Sfi 10, 10 INNATE TCA NOT FOUND B M14 C0NTINUE T0 DEC0DE INSTRUCTI0N M15 C 15,»F'3 f D0ES INSTRUCTI0N HAVE ANY NAME FIELD ? &L MJJ IF NaT t DECanF UN,NAMFD TNSTRlirTTtflN L 10,16(,2) A(REOUESTED TCA) T0 REGISTER 10 LA 10,0(,10) CLEAR M0ST SIGNIFICANT BYTE" IM Ft AG, X* 80' IS T HIS A TC A ? B0 MU IF N0T, INDICATE TCA N0T FOUND TM FLAG,X'40' IS THIS TCA ACTIVE ? B2 MJjj IF N UT, INDICATE TC A N0T F0 UND CLC NAME(12),4(2) D0ES THE NAME MATCH ? 8NE M16 IF N0T, INDICATE TCA N0T F0UND _MU9 LP-fi 15,15 M AKE I N ST R UCTION C0D E P BS ITI VE SPACE 6 •-——-SERVICE THE ATTACH INSTRUCTION * C IS, *F'h» IS TNSTRUCTI0N AN ATTACH ? BNE M84 IF N0T, CHECK BTHER INSTRUCTION C0DE LTR 10,10 D0ES TASK ALREADY EXIT ? B-Z M AT T ACH IF NOT , P R EPARE T0 A T T ACH THE T ASK ST 10,16(,2) PUT ATTACHED TCA IN INSTRUCTION MVI 16(2), X'FF' INDICATE TASK ALREAOY EXIST L 1,32(,2) AITASK CB MP LETIBN ECB) TB R EGISTER 1 LA 1,0(,1) CLEAR HIGH 0RDER BYTE BF ADDRESS LTR 1,1 DBES MOTHER WANT T0 BE POSTED T &2 MHO I F N OT,D B NOT PO S T CLI 0(1),X»80* IS SOMEBODY WAITING FOR THE ECB 1 BE M18 IF YES, POST DUPLICATE REQUEST CLC 0(4,1) ,«F* 0* HAS M OTHER CHANGED M I ND N OT TB PA ST ? BNE MHO IF YES, DO NBT POST *..-.-„-_ pasT (1),DUPATCH PBST DUPLICATE ATTACH ATTEMPTED * JtlJ POST (1),0UPATCH PBST DUPLICATE A T T ACH A TTE MP T ED B MHO INCREMENT INSTRUCTION POINTER MATTACH BAL 14,GETTCA GET A NEW TCA LXfi 10, 10 DB W E RE T A NY N EW TC A T BZ M81 IF NOT, WE CANNOT ATTACH THE TASK MVC MTIME(32),THEADER MOVE EXIT ROUTINE HEADERS IN TCA M*C NAMF(12),4(?) COPY NAME IN TCA : MVC TPARM(4),28(2) MOVE PARAMETER ADDRESS IN TCA XC TTRACE(8),TTRACE ZERO TTRACE AND QUEUE EXAMINE POINTER LA 1,SERVICF A(SERVICEtECB) TO RFGISTER 1 ST t,TSERVICE PUT ADDRESS OF SERVICE-ECB IN TCA MVC TCPU(8),20(2) MBVE CPU AND ELLAPSE TIME IN _MV£ TFCBU),32(2) M BVE T ASK CB MP L FTI BN ECB IN TCA L 1,0(,3) ACM0THER TASK TCA) TO REGISTER 1 ST 1, FATHER PUT MOTHER TASK TCA IN -XX BRBTHER(12),BR0THFR ZERB BRBTHER,LASTlINK, SBN ZAP TPRIBRTY(4),«P'0* SET PRIORITY TO ZERO XC TQECB(24),TQECB ZERO TQECB, RQUEUE, RLIST, RTEXIT,UTEXIT, iichmp 95 LTR 1,1 DOES MOTHER TASK EXIST ? BZ M82 IF N0T, PREPARE T0 ATTACH TM£ TASK L U,SBN -MT IhE (, 1) ACSI ST EK TC A) T0 R EGISTER 14 ST 14, BROTHER PUT SISTER TASK TCA IN ST 1,LASTLINK PUT MOTHER TASK TCA IN LAST-UINK SJ in f snN.MTiMFr r n mpiTher task tca phint Ta this tca LTR ia,ia IS THERE ANY SISTER TASK ? BZ M82 IF N0T, PREPARE T0 ATTACH THE TASK SJ_ m f l AST! TNK.MTlMFf f \ a\ CHANf.F STSTFR TASK'S TCA T0 THTS M82 LA 1,TSERVICE SET UP REG, 1 T0 P0INT T0 TSERVICE IN TCA MVC MSAVARA*12CEATTACH»LATTACH),UATTACH MOVE ATTACH PARAMETR LA 9, TC d HP AfTASK r.PlMP^TTPIN E X T T RUIITTnF T ti Rhr. t Q ■ATTACH EP"&M0NITR,LPM0D«l,DPM0D»-4,ETXk»(9),SF«(E,MSAVARA+l2)* ATTACH EP«&M0NITR,LPM0D«i,nPM0O«-4,ETXR«(9) , SF» (E, MS A VARA* 12) _&I L+JSA PUT A(TCtt) IN TCA LTR 15,15 IS THE ATTACH SUCCESSFUL ? BNZ M88 IF N0T,TAKE THE TASK 0UT 0F TREE AGAIN ■ STATUS STMP.TrwTCH PRFVFNT TASK FRBM EXECUTING UNTIL HE nrtNF* STATUS ST0P,TCB«TCB PREVENT TASK FR0M EXECUTING UNTIL *E O0NE B M81 PUT TCA IN INSTRUCTION maa L l f FATHFR ACM0TH E R TC A) T B R EGI ST ER 1 L 14, BROTHER A(SISTER) TCA) TO REGISTER 14 LTR 1,1 IS THERE ANY MOTHER TCA ? B_Z MM4 IF NOT, PUT THE TCA RACK ON AVAIL LIST ST 14,S0N-MTIMEt, 1) A(SISTER TCA) T0 MOTHER TCA LTR 14,14 IS THERE ANY SISTER TASK T B-Z tMiX IF N0T,PUT TCA BACK ON AVAIL LIST ST 1,LASTLINK-MTIMEC,14) A(M0THER TCA) TO SISTER TCA MM1 MVC FLAGC4) ,TCAAVAIL TCA-FLAG POINT TO AVAIL LIST SJ 10,TCAAVAIL TCA-AVAU POINT TO THIS TCA SR 10,10 INDICATE TASK NOT ATTACHED M81 ST 10,16(,2) PUT ATTACHED TCA IN INSTRUCTI0N LTR 10,10 HAS TASK BEEN ATTACHFD ? BNZ MHO IF YES,L0OK AT NEXT INSTRUCTION L 1,J2(,2) ACTASK COMPLETION ECB) TO REGISTER 1 LA 1,0(,1) CLEAR HIGH ORDER BYTE OF.AODRESS LTR 1,1 DOES MOTHER WANT TO BE POSTED ? BZ MHO IF NOT, DO NOT POST CLI 0(U,X'8Q' IS SOMEBODY WAITING FOR THE FfR ? BE M19 IF YES, POST UNSUCCESSFUL ATTACH CLC 0(4*1), bF'O' HAS MOTHER CHANGED MIND NOT T0 POST ? BNE HLW I F YE S , D O N O T PO S T »— — — -PBST (1),N0TATCH POST UNSUCCESSFUL ATTACH * Ml* POST (l),N0TATCH POST UNSUCCESSFUL ATTACH -H443 LA 2,36(,2? INCREMENT INSTRUCTION POINTER B M100 LOOK AT THE NEXT INSTRUCTION SPACE 6 ttfif". PARAMETER LIST FOR ATTACH MACRO TO BE MOVED INTO STORAGF RENT* DS OF ALIGN ON FULL-WORD BOUNDARY t——— ATTACH EP«*M0NITR,LPM0D«1,OPM0D«-4,SF»L PARAMETER FOR ATTACH * LATTACH — ATTACH EPilMQNITR, LPHOO'l , QPMQPa.ft, SF«L PARAMETER FOB ATTACH EATTACH DS OH END 0F ATTACH PARAMETER LIST * RUBBER BAND -* RUBBER BAND '. SPACE 6 •——.—SERVICE THE CHANGE PRIORITY INSTRUCTION * -HA4 C 1S,«F*4' IS INSTRUCTION CHANGE PRIORITY ? BNE M20 IF NOT, CHECK OTHER INSTRUCTION CODE LTR 10,10 DOES THE REQUESTED TCA EXIST T M ZAP M65 IF— NgT, LOOK AT NEXT INSTRUCTION MSAVARA*ib(8),20(4,2) PREPARE PRIORITY TO CONVERT BINARY CVB 0,MSAVARA«-16 CONVERT PRIORITY TO BINARY Z-AP MSAVARA»lfe(8),TPRlORTY(4) PREPARE ORIGINAL PRIORITY CVB 14,MSAVARA*16 CONVERT ORIGINAL PRIORITY TO BINARY MVC TPRI0RTY(4),20(2) MOVE NEW PRIORITY IN TCA r n.aF'a* ts BtnnFcTTsir. potciwttv utrufb than i tmtt 96 BNH M66 IF NBT, PREPARE TB CHANGE PRIORITY BF TASK ZAP TPRIBRTY(4),«P'4' jEj PRIBRITY BF TASK T0 MBNITBR'S LA 0,0095 CHANKF THE PRTBBTT Y AS HIGH AS PaSSIB^E M86 SR 0,14 CBMPUTE DIFFERENCE TB BE CHANGED • — ..----CHAP C0),TCB CHANGE SUB-TASK PRIBRITY * CMAE 10),TCB CHANGE SUB-TASK PRIBRITY MS5 ST 10,16(,2) PUT REQUESTED TCA IN INSTRUCTIBN LA 2,24(,?) INCREMENT INSTRUCTIBN PBINTER B Ml 00 LBBK AT NFXT INSTRUCTIBN SPACE 6 *.. — .— -SERVICE THE QUEUE INSTRUCTIBN * M20 C lS,tF'S* IS THF INSTRUHTIBN A QUFUF T BNE M21 IF NBT, CHECK BTHER INSTRUCTIBN CBDE ST 10,1M,2) PUT REQUESTEO TCA IN INSTRUCTIBN Sfl 8^-8 INDICATE N0 Q^F HAS BFFN ALLOCATED YET LTR 4,10 DBES REQUESTED TCA EXIST ? BZ M87 IF NBT, PREPARE TB LBBK AT NEXT INSTRUCTIBN HAL 14,GETQE GFT A NEW Q>E LR 10,4 RESTBRE REGISTER 10 LTR 8,8 OB WE GET ANY NEW Q-E T B-Z (187 IF NflT,PREPARF TB 1 BBK AT NFXT INSTRUCTIBAL XC LASTQE(4),LASTUE ZER0 LAST Q-E L 1,RQUEUE REQUEST LIST TB REGISTER 1 SJt 1,NEXTQE Q»F PBINT TB REQUFST LIST ST 8,RQUEUE REQUEST LIST PBINT TB Q-E LTR 1,1 IS THERE ANY Q-E FBLL0WING ? BJ HAS IF NBT, SET UP Rf SPBNSIRILITY I 1ST ST 8,LASTQE-LASTQE(,1) CHAIN NEXT Q-E TB THIS BNE M89 LA l,TQECB A(QUEUE ECB BF TASK) IN REGISTER 1 LL4 QCn,X«fln" IS 3BHEBBDY WAITING FBR THE EJ lfl ? BE M92 IF YES, INDICATE REQUEST TB TASK CLC 0(4,1),«F'0' DBES REQUEST TASK ASK NBT TB BE P0STED ? BN£ M95 IF YES,ng NBT PBST «... — — -PBST (I), (8) INDICATE REQUEST TB TASK • M92 PBST (1),C8) INDICATE REQUEST TB TASK M9S X£ LA3TRE3P(fl),LASTRE3P ZERB LAST RESPONSIBILITY LIST TN QE ST 10,REQTCA PUT REQUESTED TCA IN Q-E L 10,0(,3) AdSSUING TCA) TB REGISTER 10 L 1,RLIST RFSPBNSIRILITY LIST TB REGISTER 1 ST 1,NEXTRESP PUT RESP, LIST TB THIS Q-E MVI NEXTRESP,X'C0* SET UP QUEUE, ACTIVE FLAG BIT &X 8,RLIST RESPBNSIBILITY LIST PBINT TB THIS Q»E LTR 1,1 IS THERE ANY RESP, Q-E FBLLBWING ? BZ M9Q IF NBT,CBNTINUE TB SET UP Q-E ST 8,LASTRESPrLASTQE(,l) CHAIN NFXT RESP, Qrf TB THIS BNE M9Q ST 10,ISSUETCA PUT ISSUING TCA IN Q-E MVC QCPU(12),20(2) MBVE IN Q-E QCPU, QELAPSE , QPARM XC QECBU),QFCB 7FRB REQUEST fBMPLFTIBN ECB M87 ST 8,20(,2) PUT ADDRESS BF Q-E IN INSTRUCTION LA 2,32(,2) INCREMENT INSTRUCTIBN PBINTER B MIOQ LfBK AT THE NFXT INSTRUCTIBN SPACE 6 ..———SERVICE THE STBP INSTRUCTIBN * -M24 C 15,iFfT' IS THF INSTRUCTIBN A STBP T BNE M22 IF NBT, CHECK BTHER INSTRUCTIBN CBDE LTR 10,10 DBES THE REQUESTED TCA EXIST ? B2 H41 IF NBT, LBBK AT NEXT INSTRUCTION •———STATUS STBP,TC8«TCB STBP THE SUB-TASK * STATUS STBP,TCB«TCB STBP THE SUB-TASK -H94 SJ 10,lfc(,2) PUT TCA IN INSTRUCTIBN LA 2,20(,2) INCREMENT INSTRUCTIBN PBINTER B M1Q0 EXECUTE NEXT INSTRUCTIBN SPACE 6 •—.——SERVICE THE START INSTRUCTIBN • M22 C 15,»F'8» IS THE INSTRUCTION A START ? BNE M102 IF NOT. CHECK BTHER TNSTRUCTIBN CBDE 97 LTR 10,10 DOES REQUESTED TCA EXIST ? 6Z M94 IF N0T, PREPARE T0 L00K AT NEXT INSTRUCTION ■ STATUS START. TCB»TCB START THE SUB-TASK *_ STATUS START, TCB»TCB START THE SUB-TASK M94 ST 10,16(,2) PUT TCA IN INSTRUCTI0N Li 2 f 2nf r ?l 1NCRFMFNT INSTRUCTI0N PgllNTER B MIOO EXECUTE NEXT INSTRUCTI0N SPACE 6 .SFHVICfc THE DETTACH INSTRUCTION M102 C 15,»F'3' IS THE INSTRUCTI0N A DETTACH ? bNE M93 IF NOT, PREPARE FOR ERR0R EXIT SI 10,lh(,2) PUT TC A I N IN ST R UC TI O N LTR 10,10 D0ES THE RtQUESTED TCA EXIST ? bZ M103 IF N0T, PREPARE T0 LOOK AT NEXT INSTRUCTI0N ML TEI.APSF (4) ,Dl 1 ST TCA PO I N T TO UET TA C H L IST ST 10, DLIST DETTACH LIST P0INT T0 TCA NI FLAG,X'9F' CLEAR ACTIVE AND NO-CANCEL FLAG ftA| fl f MpFTArH BRANCH TO DETTACH R0UTINE M103 LA 2,20(,2) INCREMENT INSTRUCTI0N P0INTER B MIOO EXECUTE NEXT INSTRUCTION SPACE fa • - — ----ILLEGAL INSTRUCTION CODE , TERMINATE THIS SERVICE * M93 MVI 0(2),X'FF' INDICATE THE INVALID INSTRUCTION CODE a MWAIT WAI T F 0R TH f N FXT SFRVICE RFQUFST SPACt 6 *........ SERVICE THE END INSTRUCTION * H IT LIS IS, IS IS INSTRUCTION AN END ? BZ MWAIT IF SO, WAIT FOR ANOTHER REQUEST FOR SERVICE SPACE 6 t. «.„--- -SERVICE THE NOP OR NOwQPERATIQN INSTRUCTION *_ C 15,«FM' IS THE INSTRUCTION A NOP ? BNE MIOl IF NOT, IT MUST BE AN EXECUTE UA 2,aC,2) INCREMENT INSTRUCTION PPIlNTFR B MIOO EXECUTE NEXT INSTRUCTION SPACE 6 t..«.-»-.SERVICE THE EXECUTE INSTRUCTION •_ MjOl L 15,4(,2) ENTRY POINT TO REGISTER 15 LA 13,MSAVARA OUR SAVE AREA T0 REGISTER 13 -&XM U,12,12C13) SAVF REGISTFRS BALR 1«»15 BRANCH T0 EXECUTE ROUTINE LM 14,12,12(13) RESTORE REGISTERS -LA 2,6(,2) INCREMENT INSTRUCTION POINTER B MIOO EXECUTE NEXT INSTRUCTION SPACE 6 «„,.,..-. .ROUTINE TO DETTACH A LIST OF TASKS, TASK MANAGEMENT *_ ♦———FIND THE CLOSE SET OF TASKS THAT HAS TO BE DETTACHED * *......— PLACE TASKS IN DLIST, VISIT DAUGHTER TASKS * MDfTACH — L 10, OUST SET UP REG. 10 TB POINT TO DETTACH TCA B M142 BRANCH TO CHECK IF ANY TO DETTACH M141 L 10,TELAPSE ACNEXT TCA TO BE DETTACHED) T0 REGISTER 10 M\A2 LI* UX*-4X) ANY MORF TASK TO nFTTACH ? BZ MHO IF NOT, DETTACH ALREADY EXISTING ONES XC TCPU*l(3),TCPU*l CLEAR BACK-WARD POINTER T0 Q-E H¥4 TCPU,X'FF' PSEUQO.INDICATE PATH C0MTNG FROM QhF MVI LASTLINK,0 INDICATE PATH DOES NOT COME FROM SISTER B M148 BRANCH TO L00K AT DAUGHTER TASK JilAJ LR ifl+4 SET UP REGISTER 10 TO POINT TB TCA MVI TCPU,0 INDICATE PATH O0ES N0T COME FROM Q»E MVI LASTLINK, X'FF* INDICATE PATH COMES FROM SISTER/MOTHER -M152 MJ FLAG,X'9F* CLEAR ACTIVE AND NB»CANCEL FLAG BIT MVC TELAPSE(4), DLIST TCA POINTS TO DETTACH LIST ST 10, DLIST DETTACH LIST POINTS T0 THIS TCA -M4A9 CU SfliM) HAS DAUGHTER TASK BEEN VISITED ? BNE M143 IF VISITED,L00K AT SISTER TASK M140 L 1,S0N A(DAUGHTER TASK TCA) TO REGISTER 1 MUT R&W.Y'rF* TNnirATF rtAIIGMTFU HAS RFFN WTRTTFO 98 M150 LTR 1,1 IS THERE ANY DAUGHTER TASK 7 BZ M143 IF N0T,L00K AT SISTER TASK L Q,FATHFR»MT IMFt f 1 ) A(MaTHF R HF DAUGHTFH) TH BfcCISTFB p LTR 0,0 DOES DAUGHTER WANT T Id HAVE A MOTHER 7 BNZ MUO IS YES, PREPARE T0 LOOK AT DAUGHTER I 1,RR0THER-MTTME(,1) IF NOT, LOOK AT SISTFR k)F DAUGHTFR LA 1,0(,1) CLEAR HIGH ORDER BYTE, TO BE SURE B M150 CHfcCK IF SISTER 0F DAUGHTER EXIST MlfcO IM F) AT— MTTMEfM , X'flfV HAS nA^ir.HTFH RFFN VT^TTFR BV WTHFPS B0 M147 IF N0T, VISIT THE DAUGHTER FR0H ITS S0N LR 10,1 SET UP REGISTER T0 P0INT T0 DAUGHTER TCA ttJU LASTLI N K, X'FF' STACK UP BACK-O UT P0 INTER SPACE 6 • .- — — VISIT SISTER TASKS * M 1A 3 QU LA3TLINK,Q WAS T ASK LAST VI SITFD B Y SIflTF R/M QTHF R BE M144 IF N0T,L00K AT RESP0NSIBILITY LIST INSTEAD CLI BR0THER,O HAS SISTER BEEN VISITED 7 B.NE M144 IF VISITED, L,a0K AT RFSP0NSIBIL IT Y LIST L 1, BROTHER A(SISTER TCA) T0 REGISTER 1 MVI BROTHER, X'FF' INDICATE SISTER TASK HAS BEEN VISITED B M1SQ BRANCH TM CHFCK IF SISTER EXIST SPACE 6 ♦ — .VISIT RESPONSIBILITY LISTS * M lqg CL-I RLIST,Q HAS R ESPMNSIRIt I T Y LIST BEEN V ISI T ED 7 BNE M145 IF VISITED, BACK-0UT FR0M PATH L 8,RLIST A(O-E) T0 REGISTER 8 mi RL 1ST, X'FF' INDICATE RESPONSIBILITY LIST VISITED LTR 8,8 ANY Q-E IN RESPONSIBILITY LIST 7 BZ M145 IF NOT, PREPARE TO BACK-0UT FR0M PATH HHtt L 10,RFQTCA AtREQUFSTED TCA) TO REGISTFR 10 LTR 10,10 IS REQUEST TASK STILL THERE 7 BZ *H6 IF N0T,L0BK AT NEXT 0-E IN RESP, LIST LM FLAG,X«aO' HAS REQUESTED TCA BFEN VISITED 7 BZ M14b IF VISITED, L«0K AT NEXT Q-E IN RESP, LIST TM FLAG,X'20' IS NO-CANCEL FLAG BIT ON 7 BJB ttiilA IF PIN,LBBK AT NFXT Q«E IN RESP, LIST TM NEXTRESP,X'0«' IS REQUEST CURRENTLY BEING SERVICED 7 BO M151 IF YES,L00« AT THE REQUESTED TASK C 8,QFXAM IS REQUEST CURRENTLY BEING SERVICED 7 BNE Ml4fe IF N0T,L00K AT NEXT Q«E IN RESP, LIST 01 N£XTRESP,X'04» INDICATE REQUEST CURRENTLY BEING SERVICED H151 SJ fl,TCPU PUT BACKWARD POINTER TO fl«E UN TCA MVI TCPU, X'FF* INDICATE PATH C0MING FROM Q-E MVI LASTLINK,0 PATH DOES NOT COME FROM SISTER/MOTMER B VL132 LOOK AT THE SERVICING TASK •—.LOOK AT THE FOLLOWING RESPONSIBILITY LIST QUEUE-ELEMENT * M14fc L l,NEXTRESP ACNEXT RESPONSIBILITY LIST Q-E) TO REG, 1 LA 1,0(,U CLEAR HIGH ORDFR BYTE LTR 1,1 ANY MORE Q-E IN RESPONSIBILITY LIST 7 BZ M153 IF NO MORE, BACK-OUT FROM PATH LR 6,1 SFT UP RFGISTER ft TO POINT TO Q»E B M1S4 LOOK AT THE Q-E IN RESPONSIBILITY LIST M153 L 10,ISSUETCA SET UP REG, 10 TO POINT TO ISSUING TCA SPACF 6 *...... —BACK OUT FROM LASTLINK * M145 CLI LASTLINK, WAS TCA LAST VISITED BY SISTER/MOTHER 7 BE M155 IF NOT,RACK«OUT INTO Q-E IN RESP, LIST LR 1,10 ACTHIS TCA) TO REGISTER 1 MM4 MVI LASTLINK, UNSTACK BACK-OUT POINTER L 10, LASTLINK SFT UP RES, 10 TO POINT TO LAST TCA MVI S0N,O ZERO HIGH ORDER BYTE OF DAUGHTER C 1,S0N ARE WE BACKING UP INTO THE MOTHER TCA 7 BE B4-43 IF YES,L00K AT SISTER TCA BE MOTHER L 0, FATHER ACMOTHER TCA) TO REGISTER LTR 0,0 DOES SISTER WANT T0 HAVE A MOTHER 7 HUJ HU1 TF VFfi.RACK OUT TNT0 STfiTER TASK 99 B MM4 IF N0T,BACK 0UT FURTHER T0 AN0THER SISTER SPACE 6 .RACK 0UT TNTPI RE&P0NS I H T L I T Y LIST i M155 L b,TCPu REG, 8 P0INT T0 BACK-0UT INT0 Q-E LA 8,0(,8) CLEAR HIGH 0RDER BYTE LTH a f a IS TH ERE A NY Q - F TB BACK-flUT I N T0 ? BZ H141 IF N0T,L00K AT NEXT TCA IN DETTACH LIST 6 M146 IF YES,L00K AT NEXT Q-E SPACE b .—..—RE-SCAN OUST TAKING CARE 0F REQUEST QUEUE , FREEING, CANCELL ING* MHO L 10,DLIST SET UP REGISTER 10 T0 P0INT T0 DETTACH TCA b M170 hRANCH Tl ri CHECK IF ANY TM DET T ACH M192 L 10,TELAPSE SET UP REGISTER 10 T0 P0INT T0 NEXT TCA M170 LTR 10,10 ANY M0RE TCA IN DETTACH LIST ? B.2 H1S3 IF N M 0RE, P R EPARE T0 DFTT AC H THt T ASKS L 8,RQUEUE SET UP RfcGISTER 8 T0 P0INT T0 Q-E B M172 BRANCH T0 CHECK IF ANY Q-E LEFT M t7fl NJ NEXT R ESP, X»FB * CLFA R THE Q- EXEC F LAG HIT IN Qrl L b,NEXTQE SET UP RfcGISTER 8 T0 P0INT T0 NEXT Q-E M172 LTR 8,8 IS THERE ANY Q-E F0LL0WING 7 B-Z Ml 71 IF N0T,L00K AT RESP0NSIB U TTY LIST XC REUTCA(4) ,REQTCA INDICATE REQUESTED TCA N0 L0NGER EXIST CP QCPUU) ,«P'0' IS THIS A CANCELLED Q-E 7 &UH Ml7a IF Sfl,L00K AT NEXT Q-f MVC QCPU(fl) ,«PL4'-5000000' INDICATE CANCEL Q-E LA 1,QECB ACC0MPIETI0N ECB) T0 REGISTER 1 CL4 n(l),X'fln' IS S0MEBHDY WAITING F0R THIS FCB 7 BE M98 IF S0, PREPARE T0 P0ST C0MPLETI0N ECB CLC 0(4,1),«F'0' D0ES ISSUE TASK WANT T0 BE P0STED 7 BNE M174 IF N0T,O0 N0T P0ST M96 TH NEXTRESP,X»04* IS Q-E CURRENTLY BEING SERVICED 7 B0 M173 IF S0, INDICATE THIS IN THt C0MPLETI0N ECB t—w----P0ST U),N0TSRV P0ST CBMPLFTIBN AND N0T SERVICFD YET l_ P0ST (1),N0TSRV P0ST C0MPLETI0N AND N0T SERVICED YET B M174 L00K AT NEXT Q-E «»».— — P0ST tn,INSRV P0ST C0MPLETI0N ANn UNDER 3ERVICF *_ M173 P0ST (i),INSRV P0ST C0MPLETI0N AND UNDER SERVICE B M174 L00K AT NEXT Q-E SPACE h *........ TAKING CARE 0F RESP0N8IBILITY LIST , FREEING, DECIOE PURGE FLAG * M171 NI FLAG,X»EF' CLEAR PURGE FLAG BIT -H442 L ft, RUST SET UP REGISTER 8 TB PBINT T0 RESP. LIST B M175 BRANCH T0 CHECK IF ANY M0RE Q-E IN RESP, M190 L 8,NEXTRESP SET UP REGISTER 8 T0 P0INT T0 NEXT Q-E M175 U fl,0(,8) CLEAR HIGH 0RDER BYTE LTR 8,8 IS THERE ANY Q-E LEFT 7 BZ M178 IF N0T,REM0VE THE TCA FR0M THE TREE M¥C QCPUC4),«PL4'-'S00Q000« INDICATE REQUEST CANCELLFO MVC QECB(4),iAL4(QINSPCT) INDICATE C0MPLETI0N ECB EXAMINED TM FLAGrXMO* IS THE PURGE FLAG BIT 0N 7 B3 M17T IF 8N,PUT ISSUING TCA BACK BN Q«F XC ISSUETCA(4),ISSUETCA INDICATE ISSUE TASK N0 LBNGER EXIST L 1,REQTCA A(REQUESTED TCA) T0 REGISTER 1 L*K W4 OB E S THE RE Q U ES T E D T AS K S T ILL EXIS T T BZ M190 IF N0T,L00K AT NEXT Q-E IN RESP, LIST TM NEXTRESP,X'04' IS THIS Q-E CURRENTLY BEING SERVICED 7 B48 M191 IF SB, CHECK IF NB-CANCEL BIT IS 0N C 8 f QEXAM-MTIME(,l) IS REQUEST CURRENTLY BEING SERVICED 7 BNE M190 IF N0T,L00K AT NEXT Q-E IN RESP, LIST -M494 IM FL AG -MT I ME( 1 ) , X'2Q» IS NB-C A NC E L F LA G BI T BN 7 BZ M190 IF N0T,L00K AT NEXT Q-E IN RESP, LIST 01 FLAG,XM0' SET THE PURGE FLAG BIT BN B M14* GB THRBUGH THE RESPBNSIBILITV LIST AGAIN M177 ST 8,ISSUETCA PUT ISSUING TCA BACK BN THE Q-E B M190 LBBK AT THE NEXT Q-E IN RESP, LIST *-- — — -P0ST NkJBMAI at) ARNPIBMAl FNH (IF TASK » 100 M176 TM Be L M204 l.TECB IS PURGE FLAG BIT 0N ? IF 0N, REMOVE TASK FROM TREE A(TA8K COHPLXT ION PCR) TB RFGTSTFR 1 LA LTR H? 1,0(,1) 1,1 A2JXA CLEAR HIGH 0RDER BYTE BF ADDRESS D0ES MBTHER TASK WANT TB BE PBSTED ? IF NBT.RFMBVE TASK FROM TREF CLI BE CLE 0(l),x*80' M179 IS S0MEBBOY WAITING FBR THE ECB ? IF SB, PREPARE TB PBST HAS M0THFR CHANGED ITS MIND TB NBT PBST- BNE M204 IF SP,D0 NBT PBST, REMOVE TASK FRBM TREE M179 TM FLAG,X'08' N0RMAL»END FLAG BIT 0N ? BB M230 IF 0N,PO8T NORMAL CBMPLETlldN *.... — --PBST PBST B *....... -P0ST M230 PBST SPACE *.. .... — REMBVE M204 L LA (1) ,ABN0RML (1),ABN0RML M2Q4 PBST ABNORMAL-END 0F TASK PBST ABNORMAL-END 0F TASK RFMBVE TASK FRBM TREF Cl),NBRMAL C1),N0RMAL 6 PBST NBRMAL-END BF TASK P0ST N0RMAL-END BF TASK TASK FRBM THE TASK TREE, UNCHAINING THEM 15, BROTHER A(SISTER TCA) T0 RtGISTER 15 15, PC, 15) CLEAR HIGH BRQfR BYTE *M?03 L LA -LT-S- 1,LASTLINK i,o(,n -U4 A(LAST TCA IN TREE) T0 REGISTER 1 CLEAR HIGH 0RDER BYTE DBES LAST TCA EXIST T BZ M2Q2 IF NBT, CHECK IF SISTER EXIST L 14,SBN.MTIMEC,1) ACDAUGHTER TCA) T0 REGISTER 14 LA lfl,0(,ltt) CLEAR HIGH BRDER BYTF . CR 10,14 DBES LASTLINK P0INT T0 M0THER TASK ? BNE M201 IF N0T, CHANGE PREVI0US SISTER P0INTER ST 15,30N.MTIMF(,1) MBTHER TCA N0W POINT TB SISTER B M202 CHECK IF SISTER EXIST M201 ST 15,BR0THER-MTIME(,1) PREVIOUS SISTER N0W P0INT T0 SISTER H?0? LTR 15,15 IS THFRF ANY SISTFR FBLLBWING T BZ ST _E OU- M203 IF N0T,TAKE CARE 0F DAUGHTER 1»LASTLINK-MTIME(,15) SISTER N0W P0INT T0 PREVI0U8 SISTE M192 NB NEED T0 UNCHAIN S0N M203 M193 L LA -LTA- 1,S0N l,Oi,l) -l+L- A(DAUGHTER TCA) T0 REGISTER 1 CLEAR HIGH ORDER BYTE IS THERE ANY DAUGHTFR TASK ? BZ M192 IF N0T,L00K AT 0THER TCA IN DETTACH LIST XC LASTLINK»MTIMEC4,1),LASTLINK*MTIME(1) CLEAR LAST LINK -B M192 L00K AT 0THFR TCA IN DETTACH LIST SPACE •RESCAN DLIST, FREEING TCA, DETTACH TASK BR CLEAR PURGED TCA « 10,DLIST SET UP REG. 10 TB PBINT T0 TCA IN 0, LIST LTR 10,10 IS THERE ANY TCA IN DETTACH LIST ? BZ 0(,4) IF NBT, RETURN FRBM DETTACH RBUTINE -MVC PLIST(tt),TFLAP3E DFTTACH LIST PBINT TB NEXT TCA TM FLAG,XMO' IS PURGE FLAG BIT 0N 1 B0 M205 IF 0N,D0 N0T DETTACH THE TASK,ST0P INSTEAD -I 15,UC0MP A (US PR TASK COMPLETION RBUTTNF) TB RFG, 15 LA LTR 15,0(,15) 15,15 Mfe4 CLEAR HIGH BRDER BYTE IS THERE ANY USER COMPLETION EXIT RBUTINE IF NBT, PREPARE TO ISSUF DFTTACH TB TASK LA STM 13,MSAVARA 14,12,12(13) ALR — 14,1 5 REGISTER 13 PBINT TB SAVE AREA SAVE REGISTERS BRANCH TB USER COMPLETION EXIT ROUTINP LM 14,12,12(13) M*4 MVC FLAG(4),TCAAV ST 1Q, T C A A V AI L — M65 tan »« RESTORE REGISTERS AIL TCA PBINT TB AVAIL LIST AVAIL P0INT TO THIS TCA LA S, 10 NUMBER OF TIMES TO START TASK TO REG, 8 DS OH LOOP T0 START TASK BEFORE DETTACH ■STATUS START, TCRlTCR START THE TASK RFFORF OETTATH *_ STATUS BCT .DFTACH START, TCB-TC 8,M65 TTR. RTAF»VFR B START THE TASK BEFORE DETTACH START AGAIN TO BE SURE OF CLEARING STOP CN nFTT»rn THF TARK * 101 DETACH TCB,STAE"YES DETTACH THE TASK B M193 DETTACH THE NEXT TASK ■ CL FAR TTA FOR PURGED TASKS. STOP THE TASK FROM EXFCUTION M205 01 FLAG,X'«0' INDICATE TCA IS ACTIVE XC UEXAM(a),QEXAM ZER0 QUEUE EXAM P0INTER zae Tr.Piirfl) f iP>n» set task cpu time to ?fhm ZAP TELAPSE(«),«P'0' SET TASK ELLAPSE TIME T0 ZERO XC BRkJTHER(12), BROTHER ZER0 BROTHER, L.ASTL INK, S0N XX RQUEUF(4) ,RQUF UE ZF R R EQUEST QUEU E PA I N TE R XC RTEXIT(8),RTEXIT ZERO RTEXIT, UTEXIT TM FLAG,X'02' HAS TASK ALREADY BEEN HALTED ? aa M1 93 IF Y FS,DB NET ST0P TH E T ASK A GA IN •STATUS ST(3P,TCB«TCB ST0P THE PURGED TASK STATUS ST0P,TCH*TCB STOP THE PURGED TASK Jdl FLAG,X'0?' INDICATE TASK HAS BFFN HALTFI) B M193 DETTACH NEXT TCB IN DETTACH LIST SPACE b 1 T0RG SPACE b UR0P 12 N0 LINGER USE REG, 12 AS BASE _DS OH ALIGN BN H ALF- W ORD BOUNDARY EJECT ******** tJtLI ************************************************************* UTILITY PROGRAM, ROUTINE EXECUTED IN SUB-TASKS F UTILITY INSTRUCTIONS t- LIST 0F UTILITY INSTRUCTIONS t 9 SCAN TASK INSPECT ROUTINE, WORK SPACE (11 FULL-W0RD) INSPECT R0UT. TCA ARRAY , RETURN«C0nE B SERVICE D0NE C0MPLETI0N-C0DE 7 CALL MONITOR INSTRUCTION 8L0CK -b START SUBROUTINE ENTRY 5 L00K QUEUE SUBR0UTINE ENTRY , C0NTR0L a M0DIFY TCA NO-CANCEL, MOTHERLESS, TCPU, TELASPE, RTEXIT ENTRY, UTEXIT ENTRY, UC0MP ENTRY 3 M0DIFY Q-E QEXEC,QCPU,QELAPSE 2 EXTRACT TCPU, TELAPSE, QCPU, QELAPSE -1 WA-I4 WAIT«COUNT,ECB,ECB,FCR, FTC, P0ST ECB,C MPLETI0N-C0DE A NHNwZERB BETURN-C0UE MEANS FND 0F INSPECTION. THE ISSUE TCA WILL BE PLACE AT THE BEGINING 0F INSTRUCTION BL CONTR0L«D INDICATES NO-waIT WHEN BEGINING 0F QUEUE IS REACHED BUT INSTEAD RETURN THF ADDRESS 0F TQECB, THE FIRST BYTE OF C0NTR0L IS SET T0 X'ff EVERY TIME THE BEGINING 0F QUEUE IS REACHED, THE ADDRESS 0F CURRENT Q-E IS RETURNED IN C0NTR0L F0R CPU AND ELLAPSE, "100000000 SHOULD BE ADOED IF ABS0LUTE VALUE IS NEEDED, FOR OTHER ENTRIES MEANS CANCEL PREVI0US ENTRIES, -I MEANS DO NOT MODIFY THE ENTRY, 0N E NTRY R EG I S T E R M US T PO I NT T IS S UE TC A REGISTERS 15 AND 1 MAY NOT BE RESTORED FOR SOME INSTRUCTIONS S P A C E 6 UTILITY STM 14,12,12(13) SAVE REGISTERS BALR 12,0 ESTABLISH REG, 12 AS BASE REGISTER USI N G « ,1 2 R EG I S TER 12 AS BASE RE G I S TER LR 10#0 SET UP REGISTER 10 AS TCA P0INTER LA 10,01,10) CLEAR HIGH ORDER BYTE Uk 3 , M4(,1 3 ) A (RE GIS T E R b SA VE A R EA) T0 RE GI STER 3 N 3,.x*FFFFFFF8» TRUNCATE T0 D0UBLE-W0RD BOUNDARY L 2,0(,1) AUNSTRUCTI0N C0DE) T0 REGISTER 2 1 2 ,0 ( , 2) INS TRU C T IO N C0 D E T RE G ISTER 2 SPACE b •———SERVICE THE START EXECUTION INSTRUCTI0N C 2,iF'b* IS INSTRUCTION A START EXECUTION ? BNE U4 IF NOT, CHECK 0THER INSTRUCTION CODE L 15,«(,l) A(ENTRY P0INT) T0 REGISTER 15 I t5.0f.lS) ENTRY POINT TO REGISTER 15 102 I l,TPARM •INITIALIZE THE TTR _0J LlRACF,X f flO ! ACTA3K PARAMETER LIST) TO REGISTER 1 ACE SOMEHOW HERE I NQICATF STABI-FXECUTION ENTfRF.D LM BR ^SP-AIX 2, 12,28(13) 1% ± RESTORE PART OF THE REGISTERS TRANSFER WITHOUT RETURN T0 SUB-ROUTINE U4 U2 tf •SERVI C HN£ — CE THE QUEUE 2,»F'5» _U5 LOOK UP INSTRUCTION IS THIS A L00K QUEUE INSTRUCTIBN ? IF NOT, CHECK 0THER INSTRUCTIONS L 2, FLAG SAVE ORIGINAL VALUE 0F FLAG IN REG t 2 01 FLAG,X*20' SET N0-CANCEL FLAG BIT WHILE SEARCHING X 4,B(,l) ACC0NTB0L PARAMETER) T0 RFGISTER a L 9,0(,4) SAVE ORIGINAL VALUE 0F C0NTR0L IN REG. 9 MVI U(4),0 ZER0 FIRST BYTE 0F C0NTR0L.N0T AT BEGIN -L fl,QEXAM LAST Q-E T0 REGISTER 8 LTR 8,8 IS THERE ANY Q-E T BZ U25 IF NOT, CHECK IF THIS IS A NO-WAIT L00K-UP HVr. QEXAM(4),Nf-XTQf- LOOK AT THE NEXT Q-E B Ul U25 CLC 0(4,4),«F'0» BNE U4 PREPARE T0 L00K AT THE Q-E IS THIS A NO-WAIT QUEUE LOOK UP ? IF N0T.PRFPARF T0 EXAMINE THE QUFUF XC TQECB(4),TQECB ZER0 QUEUE REQUEST ECB F0R NEXT P0ST MVC QEXAM(4),RQUEUE PREPARE T0 LOOK AT THE FIRST Q-E -U4 L B,QFXAM Q-E TO REGISTER 8 LTR 8,8 ANY Q-E IN REQUEST QUEUE T BNZ U2 IF YES, PREPARE T0 LOOK AT NEXT Q-E LA 15,TQECB A(TQET.B) T0 RFGISTER 15 ST 15,0(,4) PUT A(QUEUE REQUEST ECB) IN CONTROL PARM, MVI 0(4), X'FF* INDICATE AT BEGINING OF QUEUE S4 2, FLAG — REST0RE OLD VALUF OF FLAG LTR 9,9 D0 WE WANT TO WAIT FOR NEXT REQUEST ? BZ URTN IF NOT, PREPARE TO RETURN TO CALLER ♦———W AI T ECBlTQECB WATT F OR A QUEUE R EQUEST i WAIT ECB»TQECB WAIT FOR A QUEUE REQUEST LM 14,1,12(13) RESTORE LINKING REGISTERS Jt£ TQFCB(4),TQFCR ZFRO QUEUE REQUEST ECB FOR NEXT POST 01 FLAG,X*20' SET NO-CANCEL FLAG BIT WHILE SEARCHING MVC QEXAM(4),RQUEUE LOOK AT FIRST Q-E -B U4 EXAMINE THE FIRST Q»F CP BH •TT IS QCPU(4),*P'0' IS THIS A CANCELLED Q-E I U3 IF NOT, PREPARE TO SERVICE THE REQUEST POSSIBLE T O CANCEL Q-FXE C F LAG BIT H ERE. IN CASE F 0RGFT* -UA. MVC B ST QEXA Ul 2 , F LA G M(4),NEXTQE PREPARE TO LOOK AT THE NEXT Q-E EXAMINE THE NEXT Q-E RESTORE OLD VALUE OF FLAG MVC -TAKE 1(3,4),QEXAM*1 A (Q-E) TO CONTROL PARAMETER CARE OF REQUEST QUEUE CPU AND ELLAPSE TIME HERE 15, at,!) A(FNTRY) TO RFGISTER 15 L L -LM- 15,0 1,QP -2+4* (,15) ENTRY POINT TO REGISTER 15 ARM ACPARAMETER LIST) TO REGISTER 1 f ^S-ti^ RESTORE PART OF THE REGISTERS BR * RUBBER 8AND -* — RUBBER BAND 15 TRANSFER WITHOUT RETURN TO SUB-ROUTINE -US- SPACE •SERVI _C CE THE MODIFY TCA IN f.mfH* IS TH STRUCTION IS A MODIFY TCA INSTRUCTION ? BNE L U6 2»0t2) MBVE UTFXT T ENTRY TN TCA UJ5 L 2,28(,i) A(UC0MP ENTRY PARAMETER) T0 REGISTER 2 CLC 0(4,2),«F'-1' DB WE WANT TB MBDIFY UC0MP ? B4 UBTN IF NBT,PRFPARF TB RETURN TB CALLER MVC UCBMPC4) ,0(2) MBVE UC0MP ENTRY IN TCA B URTN PREPARE TB RETURN TB CALLER S P A C E 6 • — . — — SERVICE THE MBDIFY Q-E INSTRUCTI0N * Ub C 2,«F'3' IS THIS A M0OIFY 0»E INSTRUCTI0N ? **£ U17 . IF N0T,LB0K AT BTHEB INSTRUCTION CBDE L B,QEXAM SET UP REGISTER 8 TB P0INT TB CURRENT Q-E LTR 8,8 IS THERE ANY Q-E WE ARE CURRENTLY L00KING B-Z UERR IF N0T,FKRBR RETURN L 2#«(il) A(QEXEC PARAMETER) T0 REGISTER 2 L 2,0(,2) UEXEC PARAMETER T0 REGISTER 2 UM i+2 DB WE NEED TB MBDIFY THE QEXEC ENTRY ? BNP U18 IF N0T "SET QEXEC BIT" CHECK BTHER M0D, 01 NEXTRESP,X'04* SET QEXEC FLAG BIT 6 U4$ LBBK AT QCPU PARAMETER U18 BNZ U19 IF NB MBOIFICATIBN WANTED, LBBK AT QCPU NI NEXTRESP,X'FB' CLEAR QEXEC FLAG BIT -U4S L 2 ,8 ( , 1) A CQCPU P A R A M E T E R) T B R EGIS T E R 2 L 2,0(,2) QCPU PARAMETER TB REGISTER 2 C 2,"F*-10000000' IS THE ENTRY ABSBLUTE 0R INCREMENTAL BNH-— LLM I F A B S B LU TE , PREP A RE T0 SE T A B SBLU TE CP U CVD 2,0(,3) CBNVERT CPU PARAMETER TB PACK DECIMAL AP QCPU(4),4(4,3) INCREMENT THE QCPU -B 024 L00K AT QELAPSE PARAMETER U20 A 2,«F'1000000no' GET RID 0F BIAS CPU PARAMETER CVD 2,0(,3) CBNVERT ABSBLUTE CPU PARAMETER T0 DECIMAL H¥4 QCP U(4 ) ,4(3 ) MBV R N E W Q CPU V AL U E I N Q« E U21 L 2,12(,1) A(QELAPSE PARAMETER) TB REGISTER 2 L 2,0(,2) QELAPSE PARAMETER TB REGISTER 2 r. ?.tF'.mnnnnnn' ts twf fntbv arrhi iitf hr tntrfmfntai 101+ U22 U17 BNH U22 IF ABS0LUTfc.,PRtPARt T0 StT ABSOLUTE ELAPSE CVO 2,0(,3) CONVERT fcLAPSE PARAMETER TO PACK DECIMAL __ Q£ULES£tai,a(a^rX ItiCJi£M£NT THF UF| AP*_ b URTN PREPARE TO RETURN TO CALLER A 2, ■F'lOOOOOOOO' GET RID OF BIAS ELAPSE PARAMETER CVD 2,U(,^) CONVFRT ABS0UITF FL APSI- PARA M ETEK T O DFf, MVC UELAPSEU) ,4(3) M0VE NEW QELAPSE VALUE IN 0-E b URTN PREPARE T0 RETURN T0 CALLER SPACE b . •SERVI C J__. CE THE FXTR *,«F'2' i_a_ ACT INF0RMATI0N INSTRUCTION IS THIS AN EXTRACT INSTRUCTI0N ? TF NPIT, CHECK OTHFR T NSTRUET T PIN r._DE ZAP 0(8,3) ,TCPU(4) M0VE TASK CPU T0 W0RK CVB 0,0(,3) C0NVERT TASK CPU TO BIN 4. 2,4(11) A (TASK CP U PA RAMETER) T AREA T0 C0NVERT BIN ARY REGISTER 2 ST 0,Q(,2) PUT BINARY CPU TIME T0 CPU P ZAP 0(8,3) ,TELAPSE(4) M0VE TASK ELLAPSE T0 W_R CVB 0,0(,3) CONVF R T T ASK EL.LAP SF TI ME T O ARAMETER K AREA, CONVERT BINARY L 2,8(,1) A(TASK ELLAPSE PARAMETER) T0 REGISTER 2 ST 0,0(,2) PUT TASK ELLAPSE TIME IN ELLAPSE PARAMETER _L 2,1?(,1) A CMIIP'UF CP U P ARAME T F R ) TO R EGISTER 2 XC 0(4, 2), 0(2) ZER0 QUEUE CPU TIME, IN CASE L 15,lb(,l) A(QUEUE ELLAPSE PARAMETER) T _C 0(4, IS) ,0(1*1) ZER0 QUEUE EH A PSE ,IN CASE N0 Q-E PRESENT REGISTER IS _J B__£ PR ES EN T L LTR _____ 8, QEXAM 8,8 URTN SET UP REGISTER 8 P0INT T0 CURRENT Q-E IS THERE ANY CURRENT Q-E ? IF N 0T, P R EPARE T RFTU RN ZAP 0(8,3),QCPU(4) M0VE QUEUE CPU T0 W0RK AREA.C0NVERT CVB 0,0(,3) C0NVERT QUEUE CPU TIME T0 BINARY _SJ Q,0(,P) PUT QUEUE CP U TI ME I N P ARAM ET ER ZAP 0(8,3),QELAPSE(4) M0VE QUEUE ELLAPSE T<2 W0 CVB Q,0C,3) C0NVERT QUEUE ELLAPSE T0 BIN _SI Q,0( ,1S ) PUT QUFUE CPU TIM E IN P AKA HE RK AREA.C0NVER ARY I__3 B SPACE ■SERVI URTN b CE T HE W AIT PREPARE T0 RETURN T0 CALLER INSTRUCTI ON U24 C BNE 2,«F'l U2b -2-»u4 U44- IS THIS A WAIT INSTRUCTION ? IF N0T,L00K AT 0THER INSTRUCTI0N CODE A(_AIT CHUNT) 10 R EGISTF R 2 L LA -WAIT 0,0(,2) 1,8(,1) (0),ECRLIS WAIT C0UNT T0 REGISTER • A(ECB LIST) TB REGISTER I T»(l) W A IT FO R TH E EVENTS T0 0CCUR WAIT b SPACE (0),ECBLIS URTN ± T«(l) WAIT F0R THE EVENTS T0 0CCUR PREPARE T0 RETURN T0 CALLER -SERVICE THE P0ST INSTRUCTI0N LTR 2,2 IS THIS A P0ST INSTRUCTI0N T BM7 U37 IF N 0T, CHEC K F0 R 0THER TN STRUCTI0N CBDE U26 L L 4JL uc i 2,8(,1) A(C0MPLETI0N C0DE) T0 REGISTER 2 2,0(,2) C0MPLETI0N C0DE T0 REGISTER 2 0,0( > 2) LOWER 0RDE R 3 B Y TE 0F CB M P. CODE TB REG,Q U37 L LA l,4(,t) 1»0(,1) !# J XU QUl+XMAQ* A(ECB) T0 REGISTER 1 CLEAR HIGH 0RDER BYTE IS S 0M EB0DY W AITING FBR THF FCB ? BE U37 IF YES, PREPARE T0 P0ST CLC 0(4,1),«F'0' D0ES ISSUER WANT ECB T0 BE P0STED ? BNF LULtM IF N OT, DO N AT PB ST. PRFPARF TB RETURN •PBST PBST -B CI), (0) CI), CO) URTN PBST THE ECB PBST THE ECB P R EPARE T R ETURN T0 CA| LER -U2X SPACE b •SERVICE THE CALL -C 2,iF'7' M0NIT0R INSTRUCTION T_ THT« * _AU MPINTT-P TNSTBHrTIBN ? BNE U28 L 2,4(,1) LA 2.0C?l IF N0T, CHECK 0THER INSTRUCTION CODE ACINSTRUCTIBN BLOCK) TO REGISTER 2 CLEAR HIGH ORDER BYTE 105 ST 10,0(,2) PUT ISSUE TCA AT BEGIN1NG OF INSTRUCTION B L 1,TSERVICE A(SERVICE ECU) TO REGISTER 1 ■POST (1), (2) REQUFST SE RV ICE FR B H MO NI T0 R *_ POST (1),(2) REQUEST SERVICE FR0M MONITOR B URTN PREPARE TO RETURN T0 CALLER SPACE b • — .- — -SERVICE THE QUEUE SERVICE D0NE INSTRUCTION * U28 C d,*F f R* IS THIS A SERVICE COMPLETED INSTRUCTION ? &ht LL3D IF N OT, CHECK THFR I NSTR UCTI0N COPE L 8,QEXAM A(Q-E) TO REGISTER 8 LTR 8,8 IS THERE ANY Q-E T R7 UP HP IF MPiT.FKRiaR RFTilRN MVC QCPU(4),«PL4'-5000000' INDICATE U-E COMPLETED AND CANCtL M NF,XTRESP,X'FB' CLEAR Q-EXEC FLAG BIT LL1 UFrft , X'flO* IS SOIMFBODY WATTINt, FOR THfc fJ-FCb ? BE U36 IF YES, PREPARE TO POST Q-ECB COMPLETION CLC UECBC4) ,«F'0* DOES ISSUER WANT TO LOOK AT QECB ? BNf URTN IF NOT, DO NOT POST, PREPARE TO RETURN U36 L 2,4(,1) ACC0MPLETI0N-C0OE) TO REGISTER 2 L 2,0(,2) COMPLETION CODE TO REGISTER 2 UA n,QC,2) LOWER ORDER 3 BYTE OF CBMP. CODE TO REG.O LA 1,QECB A(COMPLETI0N ECB) TO REGISTER 1 * PBST (1),(0) POST SERVICE COMPLETE ECB * PBST (1), CO) POST SERVICF COMPIETF FCB t) URTN PREPARE TO RETURN TO CALLER SPACE 6 t — T — -SFRVICF THE SCAN TASK INSTRUCTION *_ • - — — -INSPECT ROUTINE MUST NOT CHANGE REGISTER 1 SAVE AREA * U30 C 2,«F'9' IS THIS A SCAN TASK INSTRUCTION ? BiHE Uii IF NOT, CHECK BTHSB INSTRUCTION CODh L 8,8(,1) A(WORK-SPACE) TO REGISTER 8 ST 1,12(,8) SAVE REGISTER 1 &X* 14,15, lhC8) SAVE REGISTERS 14 AND 15 L 15,4(,1) A(SUBR0UTINE ENTRY ADDRESS) T0 REGISTER lb L 15,0(,15) SUBROUTINE ENTRY ADDRESS TO REGISTER 15 LB L*~8— — A(WBBK.SPACE) TB REG. 1>0UR PABM, L 9,TSERVICE A(SERVICE ECB) T0 REGISTER 9 LA 9,MGETBLK-SERVlCt(,9) ACFIRST STORAGE P00L) T0 REG. 9 -U35 LA 8,GETUAST END 0F STBRAGF POOL TB BFGISTEB ft LA 10,4C,9) A(FIRST TCA BLOCK) TB REGISTER 10 LA UtTCAlAST END *«*»**** ****************************** * ***************************** * N THE WEUUEST QUEUE LINK LIST) N THt REQUEST QUFUE LINK LIST) N THfc R ESP BN SIBIL ITY LI ST) LASTQE NEXTUE LAST H L SP PS US HS_ A(LAST Q-E I A(NEXT Q-E I A [LA ST Oaf I NEXTRESP ISSUETCA K EQ TC A DS US I1S_ FLAG # ACNEXT TCA 0F ISSUI TC A UF K EQUE 0-E IN RE3P, LIST) NG TASK STFn Task QCPU QELAPSE JJRAfiM OS OS J1A. MAX, CPU T0 PROCESS REQUEST (SEC0NUS) MAX. ELLAPSE ' ACP A RAMET E K TIME T0 PR0CE5S REQUEST (MIN) LIST) QECB UELAST OS DS SPACE F OF b SERVICE C0MP END 0F QUEUE LETI0N ECP ELEMENT MN0TE MN0TE MNttTE *,'ENO &M0NITR MUST F *, 'PUNCH " HIARCHY 1,&M *, 'PUmth !! N AM E & M0N I TR 0LL0W MACR0 CALL' 0NITR" SH0ULD F0LL0W END' " MUST FMlLftm HTARf.HY LARD' SPACE MENO SPACE M0NTR2 SYSTE END PUNCH Ml M0NTR3 _• HIARCHY START EXECUTI0N AT M0NTR2 l,M0NTRg' PUNCH RUBBER BAND im NAME M0NTR2' 108 IADOR CSfcCT *.-. — ---UOOH CPARAMETER) ■ ADDRESS 0F PARAMETER IN REGISTER LB 0-»4 SAVE REGISTER I IN REGI3TFR L 1,0(,1) ACPARAMETER) T0 REGISTER I LA i,0(,l) CLEAR HIGH 0ROER BYTE US 0*4 R£G t QiAtPAJ tM)« A ( PARM L-XSi) XR 1,0 REG,1«A(PARM LIST) XR 0,1 REG.O"A(PARAMETER) MM U RETURN Ifl CALLER SPACE 6 LIST CStCT • LIST (ARRAY, LIST 0F PARAMETERS) , TB PLACE THE VALUE Bf THE *_ •LIST 0F PARAMETERS IN THE ARRAY, STM 14,12,12(13) SAVE CALLER'S REGISTERS BALE — 12+0 ESTABLISH REGISTER 12 AS BASE REGISTER USING *,12 USE REGISTER 12 AS BASE REGISTER L 2»0(,1) A(ARRAY PARAMETER) T0 REGISTER 2 LISTLflHP L 4,4(,1) A(MEMBgR BF PARAMFTER LIST) TB RFGISTER 4- MVC 0(4, 2), 0C<») PUT VALUE IN C0RRESP0NDING MEMBER 0F ARRAY LA 1,4(,1) INCREMENT PARAMETER P0INTER REG, 1 LA 2,a ( , a) INCREMENT ARRAY PB1NTER REGISTERS LTR 4,4 IS THIS THE LAST PARAMETER ? HP LISTL00P IF N0T,TAKE CARE 0F NEXT PARAMETER IM 1 4,1 2,12(1 34 R E8 T0RE R EGIS T E RS BE F R E R E T U RN MVI 12(13),X'FF* INDICATE RETURN BR 14 RETURN T0 CALLER S P A CE > IPARAM CSECT *....-.-. IPARAM (ADDRESS, LIST 0F PARAMETERS) , RETURNS THE ADDRESS 0F * *----- — -PARAMETFW I 1ST TN RFG. n A«V WEll AS "AnnBFSS" PARAMFTER * 109 ■ - - * - STM 14,12,12(13) SAVE REGISTERS L 2,Q(,1) A(Af)D«ESS PARAMETER) T0 REGISTER 2 L-A 0,tt(,l) A(PARAMFTER LIST) TO REGISTER ST 0,0(,2) PUT ADDRESS 0F PARAMETER LIST IN "ADDRESS" LH 2,12,28(13) REST0RE M03T OF THE REGISTERS MAU 12(13), X*FF» INDICATE RETURN BR 14 RETURN T0 CALLER SPACE b CPAKM CSECT *........ C PAPM (SUB-R0UTINE ENTRY, PARAMETER LIST ARRAY) , T0 CALL A * #---.----SUHR0UTINE WjTM ITS PARAMETERS ST0RED IN AN ARRAY * t-MTPv ir :p jbm , atp tun , dtp arm, rrp arm , cnp ahm ICPARM DS UH INTEGER FUNCTI0N ENTRY P0INT ACPARM US OH WEAL FUNCTI0N ENTRY P0INT QCPARM US OH RFAL«8 FUNCTION FNTRY P0INT CCPA«M OS OH C0MPLEX FUNCTI0N ENTRY P0INT CDPARM OS OH C0MPLEX*lfe FUNCTI0N ENTRY P0INT L 1S,0(,1) A(SHBR0UTINF ENTRY) TO RPGISTER 15 L 15,0(,l5) SUBR0UTINE ENTRY T0 REGISTER 15 L l,4(,l) A(SUBR0UTINE'S PARAMETER LIST) T0 REG, 1 BjR IS BRANCH WITHPIUT RETURN T0 SUBRflUT f Nt" SPACE b IPACK CSFCT »,,...,., IPaC ;k (INTEGER) . R ETURNS IN RFG. Q PACK RFPRFSFNT AT IdN HF IN* ENTRY IUNPK USING *,15 REGISTER 15 AS BASE REGISTER LB 0*4 SAVE ORIGINAL VALUfr OF RHilSTFB 1 IN RFfi.O L 1,0(,1) A(1NTEGER PARAMETER) IN REGISTER I L 1,0(,1) INTEGER PARAMETER IN REGISTER 1 - C-V-0 1,WPAC* C0NVERT INTEGER PARAMfTFR T0 PACK DFCIMAt LR 1,0 RESTORE 0RIGINAL VALUE 0F REGISTER 1 L 0,WPACK*4 PACK DECIMAL NUMBER T0 REGISTER B_R U RETUR N T0 CALLE R DR0P 15 REGISTER 15 N0 L0NGER VALID AS BASE SPACE b t .„.,...l UNP n (PACK DEC IM AL « 4 B Y TE*) , R F TI IRNS I N R EGISTER TM F *_ «... ,.--. ai N A MY VALUE 0F PACK DECIMAL * USING *,15 REGISTER 15 AS BASE REGISTER IUNPK LR CU4 SAVF 0RIGTNAL VALUE BE REGISTER 1 IN REG.O L 1,0(,1) A(PACK DECIMAL PARAMETER) IN REGISTER 1 ZAP WPACK(8), 0(4,1) M0VE PACK DECIMAL NUMBER T0 H0RK AREA Lfi t+JD RFST0RF 0RIGINAL VALUE MF REGISTER 1 CVB 0,WPACK C0NVERT T0 BINARY BR 14 RETURN T0 CALLER HPACK OS U TFMPBRARY WORK ARFA F0R C0NVERSI0N EJECT COMMENCE CSECT ftftft»ftft>*ftftftftt>ftftftft*ftftftftftftftt*ftft*»»ftftftftft**ftftft«ftft»***ft*ftft*ftftftftft«****ftft*ft«ft * R0UTINES RESIDENT IN L0AD-M0DULE8 , T0 BE LINK-EDITED TOGETHER * * M0ST ENTRIES ARE NEITHER RE-ENTRANT N0R RECURSIVE, S0ME M0DUL* -* ARE EVEN NflN.BEUSIBLE, *- ENTRY DELAY, UTILTY, M0NITR SPACE b «... .... -C0MMENCE«T0 INITIALIZE THE R0UTINE, THIS SH0ULO BE THE ENTRY * «... ... — P0JNT F0R THE L0AD-M0DULE, C0NTR0L WILL BE TRANSFERED T0 * t. ...... ,"ENTER" AFTER INITIALIZATION, *- *...... --COMMENCE HAS N0 ARGUMENT, * USING *,15 REGISTER 15 AS TEMPORARY BASE 8 S4 BRANCH AROUND PROGRAM ID, DC ALK8) PROGRAM NAME LENGTH OC CL^'COMMENCE' EBCOIC PROGRAM NAME -S4 iW 14,12,12(13) SAVE REGISTERS CNOP 4,8 ALIGN 0N MIDDLE OF DOUBLE«M0RO,SAVE AREA BAL 12,52 BRANCH AROUND SAVE AREA.REG, 12«A (SAVEAREA) D8HP IS BPCT4TFR IS MM I UNRFR NFFDFn ** BASF 110 USING *,12 REGISTER 12 AS BASE REGISTER OC 18F'Q* SAVE AREA _S2 SJ u^axoi) AlBUa^SAVX AHEA) Ta CALLERS _ ST 13,4(,l2) A(MIS SAVE AREA) T0 BURS LR 13,12 SET UP REGISTER 13 T0 P0INT T0 SAVE AREA LA 10,0t,lQ) CLEAR H IGH BRDER BY T E ST 10, TCA SAVE 0UR TCA AOORESS F0R LATER USE *......— INITIALIZE 0THER VARIABLES HERE * ill XMn»r|Qi f i'qn* TNnirATE cbmmence entered in ttracf Ft as L 15,»V(ENTER) A(ENTER CSECT) T0 REGISTER 15 BALR 14,15 BRANCH T0 MAIN PR0GRAM L H,a(,n) BE&U1EB 13 P0INT 12 CALLERS SAVE AREA B SRTN PREPARE T0 RETURN T0 CALLER DR0P 12 REGISTER 12 NB LONGER VALID AS BASE SPACE b *.....-. -DELAY (MINUTES, DELAY-ECB) , T0 SPECIFY A ECB T0 BE P0STED * *.....-. -AFTER CERTAIN NUMBER 0F MINUTES, THE ECB IS 2ER0-EO BEF0RE * „.-..-. - -THE TIMER IS S ET , THUS ALL PR EVIBU S PB STS ARE LBST «_ OELAY STM 14,12,12(13) SAVE REGISTERS BALR 12,0 ESTABLISH REGISTER 12 AS BASE USING 0,12 USF RFGISTER II AS B ASF R EGI3TF R L 10, TCA SET UP REGISTER 10 T0 P0INT T0 TCA L 2,0(,1) A(MINUTE) T0 REGISTER 2 L 2,Q(,2) MINUTES TO RFCI3TFR 2 CVU 2, MINUTE C0NVERT MINUTES T0 PACK DECIMAL L 2,4(,1) A(ECB) T0 REGISTER 2 - LA 2,0(,2) CLEAR HIGH BRDER BYTF ST 2,ADECB SAVE A(DELAY ECB) F0R P0STING LATER XC 0(4, 2), 0(2) ZER0 ECB BEF0RE WAIT LA 2,BTEXIT RFAL TIMF EXIT H0UTINE ENTRY TB RF6, ? ST 2,X'8C'(,10) PUT REAL TIME EXIT R0UTINE IN TCA B SRTN PREPARE T0 RETURN T0 CALLER OBBP 12 REGISTER 12 N0 LBNGER VALID AS BASF * ——DELAY REAL TIME EXIT R0UTINE, (EXECUTE IN M0NIT0R M0OE) * RTEXIT STM 14,12,12(13) SAVE CALLER'S REGISTERS BAU* 1-2^0 ES T A BLI S H R E GI S T E R 1 2 A S BASE USING *,12 USE REGISTER 12 AS BASE REGISTER SP MINUTE(8),»P'l' DECREMENT WAIT TIME BY I MINUTE 8J*M &*-T-N IF TIME N0T EXPIRE YET,RFTUBN T0 M0NIT0R XC X'8C(4,10),X'8C»(10) CANCEL THE TIMER EXIT R0UTINE L i,ADECB A(DELAY ECB) T0 REGISTER 1 LA 1 , Q ( , 1) C L E A R HI G H BR 0E 8 B YT E CLI 0(1),X'80» IS S0MEB0DY WAITING F0R THE ECB T BE 83 IF YES, PREPARE T0 P03T THE ECB CIC P(4,l),*F'-q» DBES CALLER WANT ECB T0 BE PBSTED t BNE SRTN IF N0T,D0 N0T P0ST S3 PAST (1) P0ST C0MPLETI0N 0F TIME INTERVAL B SJUAJ PREPARE T0 RETURN T0 MBNITBR DR0P 12 REGISTER 12 N0 L0NGER VALID AS BASE SPACE 8 U* — — U TI L TY ( P ARA M E T E R S TB BE P AS SE D T U T IL ITY PR B GR A MS ) USING *,15 USE REGISTER 15 AS BASE REGISTER UTILTY STM 14,12,12(13) SAVE CALLER'S REGISTERS L 1 5 , T CA A (0UB TC A ) T B R EG I S TER 15 DRBP 15 REGISTER 15 NB LBNGER VALID AS BASE LR 0,15 A(0UP TCA) TB REGISTER 1S ,X '3 8 ' ( , 1 5) A( 8ERVICE«ECB ) T B R EGIS T E R 15 L 15,4(,l5) A(UTILITY PR0GRAM) TB REGISTER 15 BR 15 TRANSFER TB UTILITY PRBGRAM WITH0UT RETURN SPACE 8 «... — — MBNITR (INSTRUCTIBN BLBCK) , THE TCA WILL BE FILLED IN THE • *— — — FIRST FULL-WBRD BF INSTRUCTIBN BLBCK BY THIS RBUTINE * MBN I TR SXM 14,12,12(13) SAVE CALLER'S REGISTERS BALR 12,0 ESTABLISH REGISTER 12 AS BASE USING «,12 USE REGISTER 12 AS BASE REGISTER i J.nf.n a t t w«Toi irr taw Bi»r*\ t« bfrt«tfb 3 Ill LA e!.U(,2) CLLAK HIGH 0RDER BYTE L IOiTCA A(0UR TCA) Tk) REGISTER 10 Jil 10,0(,2) PUT flUR TC A I N BtGl N I N G 0F I N S T H UC T J-feLNL fltK L 1,X'38'(,10) ACSEWVICt tCB) T0 REGISTER 1 P8ST (1),(2) P0ST SERVICE FCB F0R SERVICE _B SRTN PRFPARE T0 RETURN TCI CALIFS UR0P 12 REGISTER 12 N0 L0NGER VALIO AS BASE SPACt 6 •RETURN Tl/I CALLFK. BESTglSE REGISTERS, SRTN LM 14,12, 12(13) REST0RE REGISTERS MVI 12(13), X'FF' INDICATE RtTURN ttii 14 RETURN T0 CALLER SPACt b TCA DC F*O f ADDRESS 0F 0UR TCA T0 BE PLACED HERE ADECB DC F'C" A(DELAY ECU) TB RE PLACED HERE MINUTE DC D'O* DELAY TIME IN MINUTES T0 BE PLACED HERE LT0RG tm C0MMENCE START EXFCLITING AT C0MMENCF 112 APFENDIX-B Program Examples (Refer to "ILLIAC 3 Show and Tell User's Guide" by Walt Donovan, Department of Computer Science File No. UIUCDCS-F-73-875 for a description of PAXDRIVR and related routines used in the example.) The following are only portions of programs that use the monitor to illustrate how to use it. It is not a complete runable program. 113 /*rn HflJLflalfJS //DELtTE EXEC PUM«I£FBK14 //PAX1 DO D5N»USER # P2123,W0NG,PAX1,DISP»(0LD, DELETE), UNIT*PI5K //ASSE M BLE E XEC ASM, PAKM. ASMl 'RE NT, RLD , ESP' //ASM.SYSPUNCH DO SYS0UT"A //ASM.SYSIN DO * HFGIN CSECTsGENMES LA 1Q,0(,10) ST 10,ISSUET 0NC FM0RE M VP, TINSTR (200) , ISSUE T LA 0,TINSTB L 1,X'38'(,10) pasT cu, cnj L 8,TINSTB*24 MVC 3b(«,8) ,iF'l' STIMER HAIT,ttINTVLi«E # bOO0' d UNCEM0RE PMfcS DC A(LINE)»X'80',AL3(LEN) -LIU DC F' b O* LINE OC CL72' X HALL0 FP0M 360 GENMES' ISSUET OC F'Q»,F'«5',CL12'PAX0',F'1',PL«'2',PL4'3',A(PMES),20F'0' TINSTB DC 50F'b' . END GENMES PUNCH ' NAME GENMES' SPACE 6 ENTER CSECT USING *,15 15,»V(PAXnRIVR) BR 15 LT0RG SPACF h 114 /• //FkJRTRAN EXEC F0RTLKED,LIBFILE»'uSER i Pt>539,3M0NTELL', -U PiRM^FHRTa 'NflQECKVP ABM .IKEPm'LFT, LIST, MAP* //FidHT.SYSIN DO * SUBROUTINE TEST! C INSTR, I0CC , I CPU, I EL AP, IP ARM) I NT ECE B IBU F( 20 ) , I RLK( 12 ) CALL UTILTY(«, -I, 0,6*100000000, 10-100000000, -1,-1,-1) CALL UXTlN(IHUF,ILEN) CALL LlST(I8LK,0,INSTR,IBUF(i),IBUF(2),IBUF(3),iaCC,IPACK(ICPU), &IPACK(!ELAP),IPARM,IADDR(JECB),0,0) JfcfHiO CALL M0NITRCIBLK) RETURN SUBROUTINE TEST2 INTEGER IW0RK(H)/11*O/ EXTERNAL MESSAG, INSPCT 100 CALL UTILTY (4, -1,0, 6- 100000000, 10- 100000000, -1,-1,-1) K0NTRL*O CALL UTU.TYCS, MESSAG, K0NTB1 IU- IF CK0NTRL.GT.O) G0T0 100 CALL UTILTYC9, INSPCT, IW0RK) RFTURN END SUBROUTINE MESSAG (LINE, LEN) INTEGER llNEClfl: D- CALL TEXT0U (LINE, LEN) CALL UTILTY (8,0) RETURN END SUBR0UTINE INSPCT(ITCA) INTEGER ITCA(30),LINF(4)/««'XXXX'/ LINE(1)«ITCA(9) LINE(2)«ITCA(10) L INE( 3 )i I TC A( U) CALL TEXT0U(LINE,lb) RETURN FND /* //LKED.SYSLM0O DD DSN«USER .P2123, W0NG.PAX1 (PAXDJ , UNIT«DISK , ML PI SP» (NEW, C ATLG, OELf TF ), SPACEt CTRK, ca,a,2) ,»LflF) » VBLiSFBlUU)8B7 /* 115 * RUBBER BAND TEST1 CSECT USING *,b ST-* U , 1 2 , 12 (13 ) LR 5,15 WT0 'TEST1-I-TEST i R0UTINE ENTERED' -I 2 ,X' 3B '(,1 ) LA 1,UC0MP ST 1,X'7«*(,10) XI l.RTEXTT ST l,X'6C'(,10) ST 10,ISSUETCA -V4 Q ,ISS UETC A P05T IM MVI BR DR0P US IN G (2), (U) 14,12,12(13) 1 2(1 3 ) , X'Ff 14 b UC0MP STM 14,12,12(13) WTW 'TEST1-I-UC0MP- C0MP|_ETI0N TEST 1 R0UTINE' -LW U, 12, 12(13) MVI 12(13), X'FF' BR 14 -QAStfL IS USING *,15 RTEXIT STM 14,12,12(13) UZS6— — f TeSTl»I«RTEXIT« RKAU TIME TEST! EXIT' LM 14,12,12(13) MVI 12(13), X'FF' BR . 14 ... . 116 ISSUETCA UC DC -DC- F'40* F»-6',CL12*TEST5',F't',PL4M',PL4'9',A(EH),A(EH) F»p» F'O' TEST! EM UC END PUNCH ' NAME TESTf TEST2 C8ECT USING sin — »,5 1 4, 1 2, 12 (1 3 ) LR WT0 5, 15 'TEST2-I- 2 ,X ' 3fl ' (, TEST £ R0UTINE ENTERED • UU ACSERVICE fcCB) LA ST -UL 1,UC0MP i,x'74'0 1,RTEXIT 10) ST ST l,X'feC'(» I0 f ISSUET n.ISSUETC 10) CA A P0ST (2),(0) WAIT ECB-E4 JOB *TF3T2»IttAFTFR PR0CESSING TF3T4' LM MVI BR 14,12,12c 12(13), X* -U 13) FF' UC0MP DR0P USING 5 *,15 U,l? , 1?(H) *T0 LM MVI 'TEST2-I* U,12>12( 12(13), t* UC0MP- C0MPLETI0N TEST 2 R0UTINE' 13) LEI : BR DR0P USING 14 15 S15 RTEXIT STM WT0 -UL 14,12,12(13) •TEST2-I-RTEXIT- REAL TIME TEST2 EXIT* U, 12, 12(13) MVI BR ISSUFTCA DC 12(13), X' 14 F'99* ff DC DC -DX- F'-5',CL1 F'06»,CLl F'Qfc',CLl 2'WRlTES«,F'l',PL4'i',PL4'2',A(MSG) 2»TEST5',F»1OO',PL4'1',PL4'1',A(UC0MP),A(E5) 2'TFST5',F'l0n*,PLflM',PL4'9',A(UCaMP),A(F5) DC DC P'06',CL1 F'06»,CL1 F'O' 2*TEST5»,F'iOO',PL4M»,PL« # 9',A(UC0MP),A(E5) 2'TEST4',F*1',PL4'1*,PL4'9«,A(TEST2),A(E4) E4 E5 MSB DC DC -DX- F'O' P»0' CL32 r T EST2-QUFUE M ESSAGE' TEST! END PUNCH C8ECT TEST2 ' NAME TEST2' USING STM -L* *,5 14,12,12(13) 5 .1 5 WT0 LA -ST LA ST LM 3-I»TEST 3 R0UTINE ENTERED* MP # •TEST 1,UC0 1,X'74'(,10) 1,RTE l,X»* 14,1? XIT C*C,10) , 12(13) MVI BR -D- R0P 12(13), X«FF» 14 _5 UC0MP USING STM kiTC •,15 14,12 »TF*T ,12(13) v.T.iireiMP* r«MPl FTTBN TFST X RflllTTNF* 117 LM 14,12,12(13) MVI 12(13), X'FF' Jifi L4 UR0P 15 USING *,15 RTEXIT SJil 14,12,12(13) WTB 'TEST3-I-RTEXIT- REAL TIME TEST3 EXIT' LM 14,12,12(13) _tt*I 12(13), X'FF' bR 14 END TE3T3 PUMtH * NAME TES TV TEST4 C3ECT USING *,b ilW 14,t2,l?(li) LR 5,15 kTtt 'TEST4-I-TEST 4 ROUTINE ENTERED' -I 2,X'^B f (,U1) LA 1,UC0MP ST 1,X'74'(,10) 1,BTFXIT ST 1,X'6C'(,10) ST 10,ISSUETCA -LA O.ISSUETCA P0ST (2),(0) WAIT ECb«MINUT -M 14,1 2,1 2 (11) MVI 12(13), X'FF' BR 14 UB0P 5 USING *,15 UC0MP STM 14,12,12(13) *X% f TEST4»I«UC0MP» CBHPLFTIHN TEST tt RCIUTINE' LM 14,12,12(13) MVI 12(13), X'FF' B* Ui DR0P 15 USING *,15 RT 6X IT S4* 14,1 2 , 1 2(13 ) WT0 'TEST4-I-RTEXIT* REAL TIME TEST4 EXIT' LM 14,12,12(13) ** REST0RE BASE REGISTER (15) **** P-BAT MIN U T LM 14,12,12(13) MVI 12(13), X'FF' B* U DROP 15 USING *,5 -S4JS SIM 14,1 2,12(1 3 ) LR 5,15 WT0 'TEST4-I--SUB WAIT F0R A WHILE' S TIM E B W A IT, B INTV L» «F' tO OO Q ' LM 14,12,12(13) BR 14 IS8UETCA DC f'T DC F'*5',CL12'WRITES',F'1»,PL4'1»,PL4'2',A(MSG) DC F'O*',CL12'TEST5',F'1OO',PL4'1',PL4'9',A(UC0MP),A(E5) Dt F > t' , CLl 2 ' LB aP , » F'O > , P L 4 , l ' , PL 4 *7' ,A ( gL0 P), A ( EL 0> ) DC F'-»5»,CL12*WRITES',F'l»,PL4'i',PL4'2',A(MSG) DC F'-.8',CL12'TEST5', F'2' _DC F'M a ' .CL ^'T ES TSSF^* DC F'-8',CL12'TEST5',F'2' DC F'-8',CL12'TEST5», F'2' -DC F'«8' ,CL1 2'T E» TS' , F'a' DC F'-8',CL12'TEST5»,F'2» DC F'-8',CL12'TEST5', F'2' DC F'2'.AfSUBl i L8 Eb MI NUT. EL0P MSG TESTS uc oc DC DC oc ENn PUNCH CSECT USING F'O' F'O' F'U' CL32'TEST4-0UEUE MESSAGE* TEST4 NAME TESTfl* *+5_ LR wT0 LA 5.15 'TEST i,ucb 5-I-TEST 5 R0UTINE ENTERED' MR ST LA _SX 1 f X'7 1,RTE 4'(,10) XIT '( ,1 D) 4C xc WAIT DRglP 0UMC4 tCB«D -5 ),DUM UM UC0MP USING STM WT0 *»15 14,12 'TEST ,12(13) SmXmllCflMga CPIMPLFTIBN TEST 9 RBUTINE' LM MVI BR 14,12 12(13 -U ,12(13) ),X'FF' RTEXIT DR0P USING STM 15 *,15 14, 1 2 , 1 2(13) WT0 *TEST5«I»RTEXIT« REAL TIME TE8T5 EXIT* LM 14,12,12(13) -M40 12(11), X'FF' : DUM BR DC END 14 F'O' TF8TS WRITES PUNCH CSECT USING ' NAME TEST5' -*♦*- STM 14,12,12(13) LR 5,15 -L * , X' 38 '( ,10 ) LA O,UC0MP ST 0,X'74'(,10) -U , RT E XIT ST 0,X'*C'(,10) LA 0,UTEXIT SI 0,X'70'(,10) W2 WT0 WAIT •WRI ECI« :» TESI-WRITF N0W EXECUTING' X'fcO»(,10) X'J»0'(4,10),X'fcO'(10) -W- MVC X'34'(4,10),X'*4'(10) a y i MHZ Xf l4 f( 4 ,1 0),4(S ) Ml L B,X'34'(,10) LTR S,S -M wa CP X»lI'(4fS),«P*0' BNH W3 -L 4 , X»1 ' (, S) LA MVC 6,X» WMES -CM* CU4- 24'(,S) ♦24CI8),0(4) WMES 08 WT0 -U— OH *WRI O.X' TES>RQUEUE< *Oti ORIGINAL MESSAGE BEFBRE MBOIPICATIBN P0ST ZAP B (6), X'16 WY (0) '(4,8),«P'Q* 119 UC0MP DROP 5 USING *,15 WT0 'WRlTESl*UC0MP« LM 14,12,12(13) _bju 12(13),x'FF' WRITES C0MPLETI0N R0UTINE ENTERED' BR 14 OR0P 15 JSINb i». IS US 1 1 RTEXIT STM WT0 -Ul_ 14 'W ,12,12(133 RITESI-RTEXIT-REAL TIME EXIT ,1 2,12 ( 13) R0UTINE ENTERED' MVI 12(13), X'FF* BR 14 nRgip ls USING *,15 UTEXIT STM 14,12,12(13) UXJi 'WRITESI.UTEXITrTASK TIME EXIT RMUTINF ENTFRPD' LM MVI BR 14 12 ,12,12(13) (13), X'FF' LM0P ENO PUNCH CSECT WR * ITES NAME WRITES* AGAIN USING *,5 LR 5,15 WTB 'C00E — I L00P R0UTINE IS ACTIVE 1 8TIMER WAIT,BINTVL«»F'1000' B AGAIN -EJ*0 LAAR PUNCH BEGIN -ST* ' NAME L00P' CSECTiMAIN U, 12 , 1 2 ( 13 ) WT0 'MAIN-. AN ERR0R IN THIS PR0GRAH MAY CAUSE INFINITE WAIT X STATE,' WT0 'MAIN — S0 PLEASE CANCEL WITH DUMP AFTER 30 MINUTES FR0M X TIME 0F THIS MESSAGE' WT0 'MAIN-- I MAY BE REACHABLE TEL. 3-6272 -L 2 ,X ' 3S ' (, 10 ) A ( S ERVIC E wEC B) T B RE G. 2 T, W0NG' LA 0, RTEXIT ST 0,X'*C'C,10) -U O,UC0 MR REAL TIME EXIT ST 0,X'74»(,10) L* 0, UTEXIT -W ,X'7 '( , 10) TASK EXIT RBUTINE ST ST -UL- 10,ISSUETCA 10,TCA1 0,IS S U ET CA P0ST (2),(0) AP X'40»(4,10),«P'1B' -W448 ' MA IN—I A FTER A TT A C H ING E V E RYTHIN G ' AGAIN XC DUM(4),DUM WT0R 'AFTER 30 MIN, Y0U MAY CANCEL BY PR0VIOING PR0PER REPLY X T T H I S M ESSAGE ' , RE»tY , 2 b, O UM WAIT ECB-OUM CLC REPLY (2«») , «C ATTENTI0N«.W0NG«»CANCEL»DUMP' WT0 'CANCEL C0MMANO ACCEPTED' ABEND X't22», DUMP, STEP -B AGAIN ISSUETCA DC DC DC- F'lO' A(l,2 r SUB) F'4' TCA1 DC CL12'MAIN' OC F'M' ne . Pi A**?* 120 OC F'*5',CL12'MAlN',F'l',PL4'i',PL4'i',A(TCAt) DC F'Ut»',CL12'TESTl',F'100*,PL4'l',PL4'fe',A(UTEXlT),A(El) DC F 'Ufc',CXi2'TEST2'^r'100*,Pl4'l*.,PL4'ft',A(UTEXlT) ,AXE2) DC F'06',CL12'TEST3',F'100',PL4'1',PL4'9',A(UTEXIT),A(E3) DC F'06',CL12'TEST5',F'l00',PL4'i',PL4'b',A(UTEXlT),A(E5) -DC F'0h',CLl?'HRlTFS',F"f9',PL4'5*,PL4'20',A(EM8),A(FKR) DC F'-5',CL12'WRITES',F'1',PL4'1',PL4*2',A(MSG) DC F'-3',CLl2'IEFBRl4',F'0* -OX F'lQQ' El DC F'O' E2 DC F'O' -EJ DX F'O' L5 DC F'O' EE DC F'O* _£jlfi DX F'O' D(jM DC F'O' REPLY DC CL2fc'N0T YET REPLY' MSG DX CL32'MAlNi»QU£UF MESSAGE* DR0P 12 USING *,12 rtfxit sum u,i2,i?(H) LR 12,15 WT0 'MAIN--I-RTEXIT--REAL TIME EXIT R0UTINE ENTERED' -LM 14, 12, 12(H) MVI 12(13), X'FF' BR U ORglP L2 USING *,12 UC0MP STM 14,12,12(13) LJ 12,15 NTB »MAIN--I»UC0MP«-TASK C0MPLETI0N R0UTINE ENTERED' LM 14,12,12(13) -HSU 1?(13),X*FF* BR 14 DR0P 12 USING t,l? UTEXIT STM 14,12,12(13) LR 12,15 ktt 'MAIN.»I-UTFXlT*iTA8K TIME FXIT R0UTTNE ENTERED* LM 14,12,12(13) MVI 12(13), X'FF' -BJ* U DR0P 12 USING *,12 -8UB 8TM 14,12,12(13) LR 12,15 WT0 *MAIN»-I-8UB«»GET C0NTR0L R0UTINE ENTERED' -tM 14,1 2 ,1 2 ( 13 ) MVI 12(13), X'FF' BR 14 END MAIN //LKED.SYSLM0O DO DSN«USER,P2123, W0NG.M0NIT0R (MAIN) , UNIT«0ISK , -U — DISP«(NEM,CATLG,OELETE) > SPACFi(TRK, ( 1 0, T, 2) ,RL8E) , VBL«8ERiUIUSR7 //TEL36272 EXEC PGM«M0NIT0R,C0ND«EVEN,REGI0N*3OK, // PARM»* MAIN • //8TFPLIB OP DXNi*. PLEASE, L*ED,SYSLH0O,OISPiSHR //SY8PRINT DO SY80UT»A //TRACE OD SYS0UTBA //8Y8UDUMP DP SYSBUTiA EXITTT CL08E TRACK L0G0UT /• // $8 /t /* -1* /* JIBLIOGRAPHIC DATA .HEET 1. Report No sport No. , ~ UIUCDCS-R-71+-639 3. Recipient's Accession No. I"itle and Subtitle A SYSTEM MONITOR FOR PROGRAMS IN ARTIFICIAL INTELLIGENCE 5. Report Date September, I974 . Author(s) Tze-Wah Wong I- Performing Organization Rept. No. Performing Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 618OI 10. Project/Task/Work Unit No. 11. Contract/Grant No. 2. Sponsoring Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 13. Type of Report & Period Covered 14. 5. Supplementary Notes 6. Abstracts A lot of programs have been written dealing with Texture Recognition and other areas of Artificial Intelligence. The large amount of core these programs take up makes it impractical to have an entire program in core before execution. Therefore a MONITOR program that loads each sub-program at the time it is needed is desirable. Also the fact that the flow of control between these subprograms may not be easily predetermined makes it necessary that the MONITOR be flexible enough to allow programmers to easily modify the flow of control during execution. A MONITOR which fulfills the above needs in research in artificial intelligence was implemented on the IBM 360-75 under OS MVT release. 20. 6 at the University of Illinois Urbana-Champaigr In addition to general design principles of the MONITOR, the following paper will also give discussions of methods of setting up a supervisor -slave type system under the MONITOR, as well as possible ways of interfacing interactive console support to the MONITOR. 7. Key Words and Document Analysis. 17o. Descriptors I IBM 360 j IBM 370 os 360 I ILLIAC-III I MULTIPROGRAMMING MONITOR INTERACTIVE PROGRAMMING ; ; 7b. ldentif iers/Open-Ended Terms 7c. (OS ATI Fie Id /Group 8. A\ ailability Sr y Statement ORM NTIS-35 ( 10-70) 19. Security Class (This Report) UNCLASSIFIED 20. Security Class (This Page UNCLASSIFIED 21- No. of Pagvs 22. Price USCOMM-DC 40329-P7 1 3? Fees H$ *w -•:::',"■"•• Beggar ■I ' i ■ Hi IW. m ■ I ■I H ■ ■ ■ ■ ■ ^^^B