LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 510.64 Ii&r no. 613-^17 Cop ^ Digitized by the Internet Archive in 2013 http://archive.org/details/batchsystemwithr614muel U). to 1 ? ^n-n^b coo-2383-0005 A BATCH SYSTEM WITH RAPID OVERLAY CAPABILITIES by David Henry Mueller December 1973 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS THE LIBRARY OF THE 4 1974 UNIVERSilY OF ILLINOIS AT URRAI UIUCDCS-R-T3-611+ A BATCH SYSTEM WITH RAPID OVERLAY CAPABILITIES by David Henry Mueller December 1973 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA- CHAMPAIGN URBANA, ILLINOIS 6l801 * Supported in part by the Atomic Energy Commission under contract US AEC AT (11-1)2383 and submitted in partial fulfillment of the requirements of the Graduate College for the degree of Master of Science in Computer Science. Acknowledgment s The author would like to express his thanks to Dr. C. W. Gear and Dr. M. H. Pleck for their assistance in the work reported in this thesis, to Mrs. Barbara Armstrong and Mrs. Debra Sweet for their help in typing the manuscript, to Mr. Wayne Walker for doing the illustrations and to Miss Renee Krasno for her help in proofreading the manuscript. 11 List of Figures Page 2 .1 System as Viewed by DOS 5 2 .2 System as Viewed "by the Supervisor 5 2 . 3 System as Viewed by a Monitor , 7 3-1 Schematic of Overlay Table Structures 11 Ill Table of Contents Page Acknowledgments i List of Figures ii 1. Introduction 1 2 . System Structure h 3. Data Structures for the System 10 h. System Routines 15 5 . An Example of System Execution 19 6. Conclusion 21 Bibliography 2U Appendix A The Supervisor 1. INTRODUCTION The Illinois Computing Graphics System (ICGS) Supervisor was written as a part of a project whose main purpose was to develop a graphics and simulation system on a minicomputer. The machine chosen for this was a PDP-11 /20, a minicomputer with a very flexible addressing scheme. Also attached to the mainframe were l6K of core storage and a KE11-A Extended Arithmetic Element, which provides hardware fixed-point multiply and divide functions as well as fast logical and arithmetic multiple shift capabilities . Direct access storage was provided by a RFll/RSll disk unit and controller, a fixed-head disk with a storage capacity of 256K words. Mass storage was provided by a TC11/TU56 DECtape unit, a bidirectional magnetic tape unit. Also attached to the system was a Documation M200 card reader for card entry and an ASR Teletype for system control and limited data entry. The unique element of the hardware system was the hard copy output device, a Gould H800 electrostatic printer/plotter. This is a rastor unit with a resolution of 80 dots per inch, which provides either fast hard copy plotting or printing capabilities. This was intended to provide graphics drawings as a part of the drafting system, graphs as a part of the simulation system, and printed output. The operating system used was the standard DEC Disk Operating System. This software provides job management capabilities and I/O support for program communication with peripheral equipment. It provides file structuring and managing capabilities for "both the disk and DECtape units as well. Programming was to be done "by a staff of graduate students, under the supervision of faculty members of the University. The graduate students involved had had little experience in working with operating systems. Since this was true and since the major thrust of the project was not the development of the Supervisor itself, the capabilities of DOS were used without modification or addition, and the Supervisor was written as an executing program under DOS. The Supervisor itself is written to provide sequencing and overlay support for the various system modules . The relationship of the Supervisor to the system modules is the same, then, as that between an operating system and a compiler or linkage editor. In turn, the system modules operate on user programs and bear the same relationship to them that a compiler does to the program it is compiling. The system modules are of two basic types. The first type consists of a set of program steps which are performed in a pre- determined order, independent of the user programs on which they are working. An example of this type is the Grafix package. The second type consists of one or more program steps which may themselves require several overlays. These overlays may be called in an arbitrary order, depending on the data and the user program which is executing. An example of this is the DIFSUB step of the Illism package. Further, the sets of steps in the modules are not mutually exclusive; that is , the same step may "be used "by two different modules. For instance, the Basic Plotting Package step is executed by the Grafix package to produce the final drawings on the Gould, and is intended to be used "by the Illism package to produce graphs on the same device. In addition, most of the system's modules require all available core in order to reduce the amount of overlaying required. Finally, the entire system has to operate in batch mode with respect to the user programs. These considerations led to a set of requirements which the Supervisor had to satisfy. First, it had to provide a rapid overlay capability to accommodate Illism. Second, it had to allow a large number of overlays for a module — .approximately 15 for one module. Third, it had to provide for rapid sequencing between system modules and between steps within a module, and a great deal of flexibility in the order in which the steps were executed. Finally, it had to be as small as possible to allow as much core space as possible to be given over to the system modules. 2. SYSTEM STRUCTURE With these goals in mind, the following structure emerged. The entire system runs under control of and with the services of the Disk Operating System (DOS). From the point of view of DOS, the system looks like a single program, a portion of which is permanently core resident and the remainder of which resides on storage devices in the form of overlays. The core resident portion is the Supervisor and is responsible for providing the overlaying facilities. DOS, then, views the system as in Figure 2.1. The Supervisor views the remainder of the system as a set of monitors, each of which may or may not possess a set of overlays. Each of the monitors and overlays is identified to the Supervisor by an ordered pair of numbers. In the case of an overlay, the pair is (monitor number, overlay number). In the case of a monitor, the pair is (0, monitor number), since the Supervisor is monitor 0. The sets of overlays are structurally mutually exclusive, but the structural information for two overlays contained in the Supervisor may, in fact, refer to the same overlay file. The monitors are responsible for notifying the Supervisor of changes in the status of the overlays, calling the Supervisor to read in overlays, and directing the Supervisor what to do when the monitor is done. Options for a monitor upon completion include running another monitor, turning to the batch input device for the next job, or returning to a previous monitor. The latter option allows a monitor to temporarily SYSTEM Figure 2.1 System as viewed by DOS z / / / / SUPERVISOR ^L S / MONITOR T 1 MONITOR 1 MONITOR N \ \ \ \ \ \ \ £ \ OVERLAY 0VERLAY 1 TO TO MONITOR MONITOR X MONITOR K TO MONITOR 1 \ \ 0VERLAY TO MONITOR 1 ^ 0VERLAY Kj TO MONITOR 1 Figure 2 .2 System as viewed by the Supervisor relinquish control to another monitor, then regain control later. It is the responsibility of the monitor to keep track of which overlays are in core and at what points another overlay is required. Since the Supervisor cannot monitor I/O operations, the monitor itself must also notify the Supervisor when the location of an overlay file has changed. A monitor knows the location of its file by the file name; the Supervisor, upon request, looks this file up in the directory of one of the mass storage devices and records the physical location of the file in its tables. The Supervisor can then use this information to read the file in rapidly when requested to do so. All the facilities of DOS are also available to a monitor. In effect, the Supervisor and DOS combined appear to a monitor as a single operating system. Further, a monitor knows only of its own overlays; it may not have access to another monitor's overlays. Thus, to a monitor the system appears as in Figure 2.3. Because the Gould was not defined as an I/O device under DOS and since we did not wish to extend DOS itself, a monitor was written to allow the Gould to be used as a line printer. A monitor may request that the line printer monitor be run before the next monitor is executed. For purposes of batch execution, the monitors are grouped into sequences known as subsystems. The Grafix subsystem, for instance, consists of the Grafix compiler monitor and the Basic Plotting Package monitor. The structure of these subsystems is not contained in the Supervisor or its tables — it is defined by the monitors as each requests DOS AND SUPERVISOR T I i MONITOR / / I / / I / I / / I / I / / I OVERLAY L OVERLAY 1 \ N \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ k \ OVERLAY 2 OVERLAY N Figure 2.3 System as viewed by a monitor the next in the subsystem. The Supervisor maintains the identity of the first monitor in each subsystem and the subsystem name by which the user communicates with the system. This overall structure gives the maximum amount of flexibility while requiring the least amount of information to be stored in the Supervisor. Further, by identifying the Supervisor itself as a monitor with the other monitors as its overlays, the same routines may be used for reading in both monitors and overlays. Likewise, the same table may be used to store the information common to both. By leaving the responsibility for calling for overlays up to the monitor and by requiring the monitor to transfer control to that overlay, the entire responsibility for determining the structure of the system below the level of the monitor is left to the monitors themselves — The Supervisor neither knows nor has to remember this structure. Finally, by requiring the monitors to tell the Supervisor what to do next, by allowing a monitor to be in more than one subsystem, and by allowing a group of monitors to be re-executed an arbitrary number of times, a great deal of flexibility in the structure of the subsystems is gained, and at the same time, the overhead on the Supervisor is reduced. The system itself consists of five parts: the core-resident Supervisor, the supporting system monitors, the user-supplied monitors and overlays, the table initializer, and the debugging support. The Supervisor consists of the Sequencer, the Overlayer, and the Table Manager. There are two system monitors — one for using the Gould as a line printer, and one for handling system errors. The Initializer is a bootstrap routine which sets up the system tables and locates the monitors and overlays on the storage devices. Finally, there is a program to build overlay files and a version of the Initializer specifically designed for debugging. 10 3. DATA STRUCTURES FOR THE SYSTEM The Supervisor routines are essentially table driven. The tables vere set up to allow maximum flexibility in the structure and interrelationships of the monitors and overlays. The tree-like structure of the lines of control (see Figure 2.2) is the only structural constraint imposed; the remainder of the structure is defined by the tables. The information contained in the tables includes, for all overlays and monitors, the location and length of the overlay on the mass storage devices and the starting address for the overlay in core. In addition, monitors require tables of their transfer addresses, the number of overlays per monitor, and the region of core occupied by each monitor and its overlays. The latter is required in order to initialize the stack pointer before a monitor is read in. This gives as much stack space as possible to each monitor while preventing a monitor from overwriting the stack with an overlay. Subsystem structure is defined by a table giving subsystem names and a corresponding table giving the first monitor in each subsystem. All tables except the overlay table are simply vectors containing the information. The overlay table is constructed in a hierarchical manner to provide as much protection for the overlays as possible (see Figure 3>l). Each monitor is allocated a subtable containing the information for its overlays. In addition, the Supervisor _ 9 MONITOR TABLE 11 MONITOR SUBTABLE MONITOR 1 SUBTABLE MONITOR N SUBTABLE LINE PRINTED ERROR ROUT- ING > MONI- TOR 2 1 MONI- TOR 3 S (SUPERVISOR) FILE NAME LENGTH LOCATION FILE NAME LENGTH LOCATION FILE NAME LENGTH LOCATION FILE NAME LENGTH LOCATION t( ERROR ROUTING) FILE NAME LENGTH LOCATION 'OVERLAY OVERLAY OVER-, LAY1 OVER- LAY 2 FILE NAME LENGTH LOCATION FILE NAME LENGTH LOCATION FILE NAME LENGTH LOCATION Figure 3.1 Schematic of Overlay Table Structure 12 in its role as a monitor, is allocated, a suitable containing the information for the monitors . The Supervisor remembers the identity of the currently executing monitor and allows it — using the overlay routine — to access only its own overlays. This provides some protection for the table and corresponding overlays. The size of each subtable is determined at load time when the initializer is run. The subtables are allocated core space at that time and may be initialized then as well. The information in the subtables may also be changed, however, using the table managing routine. This would allow, for example, a monitor to move an overlay from tape to disk, then ask the Supervisor to change its tables to reflect the new situation. The length of the overlay and its starting address in core may also be changed. As is the case with the overlay routine, the table manager allows a monitor to access only the information on its own overlays . The overlay table functions as follows. The Supervisor uses the number of current monitor to index the Monitor Table. This yields a pointer to the beginning of the monitor's subtable. The overlay number is then used to access the overlay information in the subtable. If the request is to read in an overlay, the location of the overlay, its length, and the core location to which it is to be read are used to read in the overlay. If the request is to change an entry in the table, the appropriate changes are made. The Supervisor protects itself by not allowing any overlay to overwrite its code or its tables. However, the memory containing 13 the Supervisor, DOS, and the stack is not hardware-protected, and the Supervisor does not provide software protection for either DOS or the stack. Protection of the Supervisor's code and tables depends entirely on the monitors using only the Supervisor routines to access that area of core. Full software protection would have required changes to DOS, and hardware protection would have required hardware modification step which was not even contemplated. Initialization of the tables is accomplished by a routine executed as a bootstrap to the system. The routine exists in two versions, differing only in the source of the data to be used in the initialization. In the version to be used in production runs, the data is contained in the routine itself and is presumed to be in the correct form; little checking is done for consistency. The version used for debugging uses data obtained from an input file such as a card reader or a disk file. This data is not presumed to be correct and extensive format and consistency checking is done. The reasoning behind the use of two versions is as follows: In the case of production runs, the bootstrap should be fast, reliable, and easy to run, so that an operator with a minimum amount of training can execute the system with the greatest ease. Flexibility is not a great consideration in this case since the structure of the system as a whole will not change between production runs. However, in the case of debugging runs where new portions of monitors are being tested, the situation is exactly reversed. The operator is an experienced programmer, and the speed of the bootstrap 11+ is not as important as its flexibility. Since the structure of the * system, particularly the size, location, and starting addresses of monitors and overlays, will almost certainly change between runs, the operator must be able to easily alter the initial data put in the Supervisor tables. This is best accomplished if the data is taken from an input file rather than stored within the Supervisor's load module. By this table organization, then, the Supervisor gains flexibility. Changing the structure of the system requires changing only the information in the Supervisor tables, not altering the Supervisor code itself. Debugging is made somewhat easier since the tables may be reinitialized from an external file at the beginning of each run. Finally, the Supervisor provides as much protection as possible without making hardware changes or changes to DOS. 15 k. SYSTEM ROUTINES The system is divided into five major sets o? routines. The first set is a core-resident Supervisor which is supported by the second set of two systems monitors. The third set consists of the initializers; the fourth, the debugging support, the fifth is the remaining monitors and overlays. The core-resident Supervisor is in turn made up of three routines: the Scheduler, the Overlayer, and the Table Manager. The Scheduler's main responsibility is to sequence from one monitor to another and to insure that the stack is properly relocated. The Scheduler is also responsible for executing the line printer emulator and for maintaining a structure known as the nest. The nest is a pushdown stack used to provide a primitive looping facility among monitors. A monitor, before relinquishing control, may request that the Scheduler save its identification number so that it may be re-entered at a later point. These numbers are pushed onto the nest and popped off it at the request of a subsequent monitor. The monitor whose number was just popped off the nest is then given control. Thus, by making use of this facility and by passing information in core, a sequence of monitors may be re-executed an arbitrary number of times until some condition is satisfied. When it is called, the Scheduler identifies the Supervisor as the monitor in control. It determines if the line printer emulator has been requested and executes it if it has. It then 16 determines what action has "been requested by the previous monitor. Options include executing another specific monitor, either with or without stacking the previous monitor's number on the nest, or running the monitor whose number is on top of the nest. If the latter option is requested and the nest is empty, the Scheduler reads the next control card from the card reader and determines the next monitor from the subsystem name. In any case, the stack is reset and the next monitor is read in and given control. The Overlayer is responsible for reading all monitors and overlays into core. It is also responsible for providing most of the system protection, such as preventing a monitor from accessing overlays which are not its own and from overwriting the Supervisor. When it is called, the Overlayer first checks the overlay number to see that it is valid and that all the overlay's table information has been initialized. It then sets up the I/O blocks from the table, checks for Supervisor overwrite, and transfers the overlay to core. Finally, it returns control to the calling program. The third routine in the core-resident Supervisor is the Table Manager. Its primary prupose is to allow monitors to change information in the Supervisor tables to correspond to changes in the status of the monitor's overlays. For example, this allows a monitor to shift the physical location of an overlay or even change the correspondence between overlay numbers and overlay files. The routine can alter any of the information in the overlay tables, but it does IT restrict a monitor to changing only its own suitable . Further, this routine serves to insulate the monitor from the precise form of the data in the table while allowing it to change the data if necessary. In addition to the core-resident Supervisor, there are two monitors used by the Supervisor — a line printer emulator and an error handler. These are identified within the system structure as overlays and 1 to monitor Os the Supervisor. The line printer emulator is responsible for taking an alphanumeric file from the disk and printing it on the Gould. Output had to be buffered in this fashion because the Gould produces smears on the paper if it is halted for too long. Further, in order to make the Gould available directly as an output device, it would have been necessary to define it as such in DOS, requiring changes to DOS. The error routine handles errors which arise as a part of the Supervisor operation. These are exclusive of the errors handled by DOS, such as "device not ready" or "illegal opcode", and include such errors as attempting to overwrite the Supervisor or to use illegal overlays. In the current version, all errors are considered fatal. An error message is printed giving the type of error and all pertinent information, and the system is terminated. The bootstrap routines are responsible for filling in the initial values of all Supervisor tables. There are two versions: one gets the values from tables in the initializer itself, and the other gets its values from an input device. In either case, the 18 Table Manager is used to locate the overlay files and fill in the initial values of the overlay table. The other tables are filled in directly. Finally, a separate program is provided to create overlay files. This is not a part of the executing system, but a stand-alone program. A load module is built, using DOS routines, which reflects the core configuration at the time the overlay is in core. This is read into core, and the Overlay Builder is placed where the Supervisor would normally be. The user then specifies the name of the overlay file and the area of core containing the overlay. The program then creates a contiguous file of the required size and writes the overlay into. it. 19 5. AN EXAMPLE OF SYSTEM EXECUTION A typical run of the System might proceed as follows. The Supervisor and the Initializer are read into core, and the Initializer is executed. This fills in all the Supervisor tables, allocates the overlay table, and uses the Table Manager to locate monitors and overlays and fill their locations into the overlay table. Control is then transferred to the Scheduler. The Scheduler reads a card to find the name of the first subsystem to be run. The subsystem table is accessed to give the first monitor in the subsystem and that monitor is read into core and given control. When the monitor wishes to read in its first overlay, it calls the Overlayer, passing as a parameter the number of the overlay to be read in. The Overlayer uses the monitor number to gain access to the monitor's subtable, then the overlay number to get the information on the overlay. The Overlayer fills in the I/O control blocks from the overlay table and calls a DOS routine to do the transfer. It then returns control to the calling monitor. Suppose that, at some point, the monitor moves one of its overlays from one device to another. The monitor must then call the Table Manager to make the necessary changes to the Supervisor tables. The Table Manager locates the file on the new device and changes the tables accordingly. Of course, specifications other than the physical location of the file could have been changed by this routine, had the 20 monitor so ordered. Suppose the monitor then exits, requesting that the line printer he run, followed by a second monitor. The Scheduler is given control and it overlays and executes the line printer. It then overlays the second monitor and gives it control. This monitor may exit, requesting the execution of a third monitor, then its own re-execution. The second monitor's number is pushed onto the nest and the third monitor is read into core and executed. It returns, say, with no further requests . The nest is popped and the second monitor read in and executed again. This monitor then exits, with no further requests, and, since the nest is empty, another card is read from the card reader to determine the next subsystem. 21 6 . CONCLUSION In summary, a system has "been written which satisfies the stated objectives. The system utilizes the fastest possible DOS routines for overlaying so that the overlaying takes place at almost the hardware speed. Little motion is wasted in getting the overlay into core . The number of overlays per monitor is arbitrary, subject only to overall space in the Supervisor tables. The current restrictions are for 10 monitors with the total number of monitors and overlays set at 2k. There is also a restriction on the number of subsystems to 5, but again, this is a restriction imposed by . the size of the tables, not by the system code. Since monitor and overlay numbers are contained in a single byte, there would appear to be a restriction to 256 monitors each with 256 overlays ; but by extending the monitor and overlay to a fullword and suitable adjusting the table accesses, the restriction can be raised to 65,536 monitors each with 65,536 overlays. If the former is not, for all practical purposes, sufficient, the latter certainly is. The resident Supervisor currently takes up 600 words. This is the size of the DEC overlaying facility and seems to be a reasonable size. However, only about half of this is taken up by code; the remainder is occupied by the tables, primarily the overlay table. By 22 adjusting the size of these tables and consequently increasing or decreasing the number of monitors and overlays, the size of the Supervisor itself can be made to vary. Rapid sequencing has been achieved by considering the Supervisor as a monitor with the actual monitors as its overlays. Thus, all of the speed achieved for the overlays is made available to the Scheduler. Finally, the system makes as few assumptions about the nature and interrelationships of the monitors and overlays as possible, thus giving them as much freedom as possible. However, all this has not been accomplished without a price. Primarily in order to gain speed, DOS routines were used for the Overlayer which required the overlay files to be contiguous. Further, in order to give the programmers developing monitors and overlays as much control as possible over what went into the overlay file, the overlay builder requires a load module which is essentially a snapshot of core at the time that the overlay is in core. It then provides the programmer word-by-word control over what block of core is put into the file. The resulting procedure for building overlays is rather lengthy, requiring the use of the DEC linkage editor to build the load module, then the overlay builder to make the actual overlay. Further, the debugging version of the Initializer requires the input file to be rather highly formatted, and requires the programmer to make some statement about all monitors and overlays in the system. The whole 23 debugging procedure thus "becomes rather clumsy. The awkwardness of debugging is more than justified, however, by the fact that the system is not designed to facilitate debugging monitors and overlays , but to execute them efficiently in a production situation. 2k Bibliography Brown, R. Leonard, Jr., Numerical Systems on A Minicomputer, Report No. UIUDCS-R-T3-555 AEC-COO-ll+69-0215, Department of Computer Science, University of Illinois, Urbana, February, 1973. Digital Equipment Corporation, PDP 11-20 Processor Handbook, Maynard, Massachusetts, 1971' Mueller, David, The ICGS System: System Tables Manual, Report No. UIUCDCS-R-73-609 AEC COO-2383-003, Department of Computer Science, University of Illinois, Urbana, January, 197^- Mueller, David, The ICGS System: Users Manual, Report No. UICUDCS-R-73-60 AEC COO-2383-002 , Department of Computer Science, University of Illinois, Urbana, January, 197^- Appendix A The Supervisor MAIN. MACRO V004A PAGE 1 Al 9 10 11 12 13 14 15 16 17 18 19 20 21 24 t£b SYSTEM NUCLEUS DAVID MUELLER MAV, 1972 PDP11, 16K PAL-11R, V005A TO SUPERVISE THE RUNNING OF ICQ* PROGRAMS PROGRAM NAME AUTHOR/DATE MACH I NE/L ANGUAGE PURPOSE DECLARATIONS . TITLE SVSPUB ; GLOBAL STATEMENT FOR PUBLIC USE . GLOBL CRLINK, DFLINK, KBLINK, LP, NEXT, PARAM . GLOBL SVC, OVRLAV, UPDATE, LPFILE, CRHEAD . TITLE SVSINT J GLOBAL STATEMENT FOR INIT . GLOBL NSVS, SVSTAB, SVSNAM, NTABLE, MODTBL, CORTOP, START . GLOBL SVSMOD, SVC, UPDATE, DFLINK, MODEND, REGION TITLE SVSERR :. GLOBAL STATEMENT FOR ERROR . GLOBL KBLINK, PARAM, MODHLD, NFIRST, CORTOP, NEXT . GLOBL TRA. ; <— 8 000090'' . CSECT 29 000000 R0=?i0 36 000001 Rl=Jil 31 000002 R2=K2 ~ z* 000003 R3=;:3 SS 000004 R4=V4 24 000005 R5=X5 35 000006 SP-K6 36 OO0007 pc=;-:7 40 00000 41 00004 42 00010 43 44 45 46 47 48 49 50 00014 00016 00020 00022 00024 0O0167 O00742 00O167 001310 000167 001672 000000 000000 000000 000000 000000 i ENTRV POINTS SVC : JMP SVC1 OVRLAV : JMP 0VRLV1 UPDATE : JMP UPDT1 DATA ALLOCATIONS TABLES SVSNAM : WORD O, 0, 0, 0, O SCHEDULER OVERLAY ROUTINE UPDATE ROUTINE } TABLES USED BV SYSTEM ALONE i SUBSYSTEM NAMES - 1,-SUBSVSTEM A2 . MR IN. MACRO V004A PAGE 1+ 51 00026 000 NSVS : BVTE 52 53 0002? £ (' f SVSTAB : . BVTE 00030 00031 377 3 1' t 00032 £ i*' r' 00033 377 54 55 56 00034 57 00035 58 £10036 37? £ r' i' £ 1 1 ' r NTflBLE : . BVTE BVTE BVTE -1 -1 -1, - -1, -1, -1, "I 00037 £ (' i' 00040 £ i*' *'" 00041 £ i'* r" 00042 59 00043 £ f' i*' ji ■ r' r BVTE -1, - -1, -1, -1, -1 00044 £ i' 1 »'' 00045 377 00046 377 00047 60 j'.- r r' EVEN 61 00050 000000 REGION: WORD 62 09052 000000 WORD 63 00054 000000 WORD 0, 0. 0, 0.. 00056 000000 00060 000000 08062 €100000 00064 000000 64 00866 000000 WORD 0.. 0. 0. 0.. 00070 000088 08872 000000 00874 888888 08876 888888 65 €•€> EVEN 67 00108 888000 START : WORD 68 08182 080000 WORD €9 80184 000000 WORD 0.. 0, 0.. 00186 000000 08118 08000W 88112 000000 00114 888888 70 08116 800000 . WORD 0.. 0. 0, 00120 888888 00122 888868 00124 000000 00126 000000 ; NUMBER OF SUBSVSTEMS ; SUBSVSTEM TABLE ; # OF MONITOR TO BE CRLLED TABLES USED BY SVSTEM AND INI T # OF OVERLAYS / MONITOR SVSTEM DUMMY MONITOR SPARES REGION ADDRESSES LP ERROR SPARES TABLES USED BY SVSTEM AND OVPLAY STARTING ADDRESSES LP ERROR SPARES 71 7 3 O 013: O 1 6 O • M D T B L 74 00132 177777 75 00134 177777 00136 177777 00140 177777 00142 177777 00144 177777 EVEN WORD MONO WORD -1 WORD -1; -!.■ -1' -1:' "I ; .; TABLES USED BY OVRLAV AND LOOK BASES OF MONITOR OVERLAY TABLE 1 : SVSTEM DUMMY MONITOR SPARES A3 MR IN. MACRO V004A PAGE 1+ 00146 177777 08150 177777 00152 177777 00154 177777 00156 177777 WORD -1, -1, ->ls -1, -1 EVEN :7 9 00160 000000 MONO : . WORD 80 00162 000000 . WORD 81 00164 000000 . WORD 82 00166 000000 WORD 0,. 0.. 00170 000000 00172 000000 82 000420 . =. +148. 34 00420 000000 MODEND . . WORD 86 > VARIABLES 88 . EVEN feci 00422 000000 PARAM : WORD 0.. 0.. 0j 0.. 00424 000000 00426 000000 00470 000000 004 <2 000000 &0 00424 000000 . WORD 0.. 0.. 0. 0.. 00436 000000 00440 000000 00442 000000 00444 000000 Pi 00446 000 SVSMOD . BVTE 8g 00447- 000 MODHLD BVTE p3 0U450 000 LP: BVTE 94 |5 00451 000 NEXT BVTE 96 00452 000000 LPFILE WORD 0, 0. 00454 000000 90456 Q7 €100000 98 00460 044 SVSCHK : ASCI] : ,••**,■■• 00461 044 99 00462 000 NEST • BVTE 0.. 0. 0.. 0.. 0i 00462 000 00464 000 £10465 000 00466 000 00467 000 100 EVEN 101 0470 000462" NFIRST: . WORD NEST 102 102 04 72 000470 NLAST : WORD NEST +6 104 0474 000462" SRI : WORD NEST 105 106 0476 000000 USET : . WORD 107 0500 040000 WORD 40000 108 0502 100000 . WORD 100000 109 0504 140000 WORD 140000 lie 000003. STflTUS=3 SVSTEM OVERLAV TABLE LINE PRINTER ABSOLUTE BLOCK # ON DT/DF MEMORV ADDRESS # OF WORDS & UNIT SPECS ERROR i END OF SVSTEM OVERLAV TABLE VARIABLES USED BV ALL ROUTINES PARAMETER FIELD MUNI TUP NUN IN CONTROL MUNI TUP PREVIOUSLY IN CONTROL LINE PR INTER INDICATORS 10 PUN =0 IF NO I NEXT MUNI TUP TO BE EXECUTED FILE TO BE PRINTED : VARIABLES USED BV SVSTEM ALONE > SVSTEM CONTROL CARD ID NEST ADDRESS OF BEGINNING OF NEST •..NOTE - THIS VARIABLE ALSO REFERENCED BV ERROR ROUTINE.' ADDRESS OF END OF NEST + 1 SAVE AREA FUR NEST PU INTER ■'ARIABLES USED BV LUUf ALONE UNIT NUMBERS TO SET IN NWORDS INDEX TU STATUS BVTE FOR UPDATE MR IN. MACRO V004A PAGE 1+ 111 i VARIABLES USED BV OVRLAV AND ERR© 112 113 114 115 116 117 0510 116 0512 119 120 121 0514 122 0515 123 124 125 126 127 0516 128 0520 129 0521 130 0522 131 132 0524 0525 0526 133 0527 053O 0531 0532 0533 134 135 136 137 138 139 140 141 0506 O00000 CORTOP : WORD 8 > ; CONSTANTS - AVAL I ABLE TO ALL 021411 EXIT=021411 014760 UNIT: . RAD50 /DF / 016040 . RAD5Q /DT / 000510- DF=UN IT 000512 -' DT=UN I T+2 000 ZERO: . BVTE 001 ONE : . BVTE 1 .; I/O BUFFERS 000122 CRHEAD 000 000 000122 000 SVSCRD 000 000 000 nextip: 000 000 000 000 000646'' EVEN WORD 82. BVTE 6 BVTE WORD 82. BVTE 0, 0.. BVTE 0.. 0.. 0.. 0.. O =. +74. I/O CONTROL BLOCKS 0646 0650 0652 142 0654 143 0655 144 0656 145 Q€SH 146 06 6 2 147 0664 14:3 0666 149 0667 150 0670 151 0672 152 0674 153 0676 0700 0701 0702 154 155 156 157 158 159 00U000 O C R L I N K 012624 001 000 01262O 000000 O D F L I N K 016003 001 000 014760 000000 000000 KBL I NK 100071 001 000 O42420 'CRD, "CR 0704 0706 160 0710 161 0712 000000 000000 LINK 000000 001 EVEN WORD O WORD O RAD50 . BVTE 1 BVTE RAD50 . WORD WORD O RAD50 /DSK. BVTE 1 BVTE RAD50 WORD O WORD RAD50 BVTE 1 BVTE RAD50 /KB WORD O WORD O WORD O BVTE 1 -'DF ••TTV ADDRESS OF TOP WORD IN CORE EXIT CODE UNIT NAMES CONSTANT DF ■- < rad i x 50 > CONSTANT ■DT ■- •:: RADIX 50 > CONSTANT CONSTANT 1 .! BUFFER USED BV SVSTEM ALONE .; MAXIMUM BVTE COUNT i MODE i STATUS ACTUAL BVTE COUNT i CARD READER BUFFER .; CONTROL CARD ID NEXT INPUT REMAINDER OF BUFFER LINK BLOCKS FOR PUBLIC USE CARD READER LINK BLOCK LINK POINTER LOGICAL NAME # OF WORDS TO FOLLOW UNIT NUMBER PHVSICAL DEVICE NAME DISK LINK BLOCK LINK POINTER LOGICAL NAME OF DATA # OF WORDS TO FOLLOW UNIT # PHVSICAL DEVICE NAME TTV LINK BLOCK LINK POINTER LOGICAL NAME OF NUMBER OF WORDS UNIT # UNIT NAME CONTROL BLOCK FOR OVRLAV AND LOOK. LINK BLOCK LINK POINTER LOGICAL NAME OF NUMBER OF WORDS ;et DATA TO F( SET )LLOW DATA SET TO FOLLOW MR IN. MACRO V004R PAGE 1+ A5 162 0712 600 163 0714 000000 164 165 166 0716 0000O0 167 0720 000000 168 0722 00O000 163 0724 000004 170 0726 000000 171 000716' 172 173 0730 000000 0732 000000 174 0734 000000 0736 000000 175 0749 000000 176 07 : '42 000000 177 0744 000000 178 179 ISO 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 0746 116767 177474 177473 199 8754 1.05067 177466 200 0760 016706 177064 201 0764 016701 II 7 7504 282 284 285 8778 185767 177454 286 0774 801418 287 0776 884567 177802 288 1002 0004O1 289 1884 800514 UN UNO: . BVTE O UNRME : . WORD . EVEN TRRN : . WORD MEMRDD : . WORD NWORDS : . WORD . WORD 4 . WORD BLKNO=TRRN FILE EXT : WORD 0, WORD 0, WORD WORD WORD O i UNIT # ; PHYSICRL DEVICE NRME ; CONTROL BLOCK FOR OVERLRV ALONE ) TRAN BLOCK .: ABSOLUTE BLOCK NUMBER ; MEMORY START ADDRESS .; # OF WORDS FUNCTION STATUS .; # OF WORDS NOT TRANSFERRED j ; CONTROL BLOCK FOR LOOK ALONE ; FILE BLOCK i FILE NAME i EXTENSION UIC i PROTECT CODE NAME AUTHOR/DATE SCHEDULER DAVID MUELLER JULY, 1972 MACHINE/LANGUAGE PDP-11, 16K PAL-11R, V0Q5A PURPOSE TO SUPERVISE THE SEQUENCING OF MONITORS CALL SEQUENCE JMP SVC GLOBAL PARAMETERS NEXT NEXT MONITOR TO BE RUN LP LINE PRINTER INDICATOR - IF NO RUN - 1 IF PUN LPFILE LINE PRINTER FILE NAME PRRRM PARAMETER FIELD FOR COMMON I CRT ION BETWEEN MONITORS ENTRY POINT FOR THE INITIALIZER - RETURN POINT FOR R MODULE SVC1: MOVB SVSMOD, MODHLD ; SAVE NUMBER OF MODULE RELEASING CLRB SYSMOD MOV REGION, SP MOV SRI, Rl •CONTROL, IDENTIFY SYSTEM IN i CONTROL , RESTORE NEST POINTER RUN LINE PRINTER IF NECESSARY TSTB LP BEQ SYS010 JSR R5, OVRLRY BR . +4 . WORD ZERO : CHECK FOP LINE PRINTER REQUEST .: BRANCH IF NOT , ELSE OVERLAY LINE PRINTER A6 MR IN. MACRO V904R PAGE 1+ 210 1006 004777 177066 211 1012 105067 177432 212 213 214 215 1016 105767 177427 216 1022 001452 217 1024 116700 177421 218 1020 002424 219 1032 116700 177413 220 1036 042700 177400 221 1042 006300 222 1044 016006 000050 223 1050 004567 176730 224 1054 000401 225 1056 000451 JSR PC, 9START CLRB LP RUN LINE PRINTER DECIDE WHAT MODULE IS TO BE RUN NEXT AND OVERLAV IT i CHECK NEXT .; BRANCH IF NEST IS TO BE RCCES! i SET UP TO TRANSFER CONTROL .! BRANCH IF NEST IS TO BE ADDED ; SET UP TO INDEX TABLES > OVERLAY NEXT MODULE 226 22'? 1060 010167 177410 230 1064 116767 177361 177254 231 1072 105067 177353 232 1076 000170 000100 233 234 235 236 1102 105467 177243 " |7 1106 020167 177360 22-fc! 1112 001403 239 1114 116721 177331 240 1120 000744 241 1122 004567 176656 242 1126 000401 243 1130 000515 244 11.32 105067 177264 245 1136 010167 177262 246 1142 004577 176734 767 SVS010: TSTB NEXT BEQ SVS050 MOVB NEXT.. R0 BLT SVS030 SVS020 : MOVB NEXT, R0 BIC #177400, RQ ASL R0 MOV REGION, SP JSR R5, OVRLAV BR . +4 . WORD NEXT TRANSFER CONTROL TO NEXT MODULE MOV Rl, SRI ; SAVE NEST POINTER MOVB NEXT, SVSMOD ; IDENTIFY NEXT MODULE IN CONTRC CLRB NEXT ,TMP C-START'.:R0> NEST ADDITION REQUESTED ;VS030: NEQB NEXT CMP Rl, NLRST BEQ SYS040 MOVB NEXT, -::R1> + BR SYSO20 ;VSO40 : JSR R5, OVRLAV BR . +4 WORD ONE CLRB PARAM :ed TO )L MOV Rl, PARAM+2 JSR R5, i?START+2 .i TRANSFER CONTROL ; NEXT - -NEXT ; CHECK FOR NEST OVERFLOW .; BRANCH TO ERROR ROUTINE IF SO .; ELSE RETURN TO OVERLAV MODULE .: NEST OVERFLOW - GET ERROR .; ROUT I NE i SET ERROR CODE ; GO TO ERROR ROUTINE A7 MR IN. MACRO V004A PAGE 1+ 247 1146 104060 248 249 25S 251 252 1150 O20167 177314 253 1154 0014O3 254 1156 114167 177267 255 1162 000723 256 1164 012746 000650 ■' 257 1170 104006 258 1172 012746 00O516 ' 259 1176 012746 000650' 260 1202 104O04 261 1204 012746 000650' 262 1210 104001 263 1212 026767 177306 177240 264 1220 001364 265 1222 012746 000527"' 266 1226 005046 267' 1230 104042 268 1232 103757 269 1234 011603 270 1236 012716 000650 271 1242 104007 272 1244 020327 021411 273 1250 001417 274 1252 005008 275 1254 812702 000014 276 1268 822203 ■ 277 1262 001405 278 1264 0O5200 279 1266 12006 7 176534 2Sk) 1272 003772 281 1274 000733 282 L276 116867 i 000027 177145 283 1384 002727 284 1306 000651 285 1210 012746 £ 000662 286 1314 184007 287 1316 104060 EMT 60 GET NEXT MODULE FROM NEST NEXT MODULE FROM READER SVS050: CMP Rl, NFIRST BEQ SVSO60 MOVE; -, NEXT BR SVS02O SVS060 : MOV #CRL I NK, - < SP > EMT 6 SVS070: MOV WCRHEflD, - MOV #CRLINK, -vSP::' EMT 4 MOV #CRLINK, --::SP> EMT 1 CMP SVSCRD, SVSCHK BNE SVS070 MOV #NEXTIP, -•: CLR -•::sp> EMT 42 BCS SVS07O MOV •:.SP>, R3 MOV #CRLINK, sp: VS030 ; CMP BEQ •:P2>+, r: 5VS09O I NC RO CMPB R0, NSVS ; SYSTEM EX I T IF NEST IS NOT EMPTV, ELSE GET i CHECK TO SEE IF NEST IS EMPTV ; BRANCH I F SO i ELSE TAKE NEXT MODULE FROM NEST .i AND BRANCH TO OVERLAV If .; NEST EMPTV - INIT CARD READER ; READ A CARD i WAIT i CHECK FOR SVSTEM CONTROL CARD BRANCH TO READ ANOTHER IF NOT ELSE CONVERT MODULE NAME TO RAD50 BLE SVS080 BR SVS060 VS090: MOVB SYSTRB < R0 > .. NEXT VS100 BLT SVS060 BR SVS02O MOV #DFLINK - •.: sp EMT EMT 60 . BRANCH IF INVALID , STORE SUBSYSTEM NAME i RELEASE CARD READER ■ CHECK FOR EXIT ; BRANCH I F SO ELSE SET UP TO SEARCH SUBSYSTEM TABLE CHECK SUBSYSTEM NAME BRANCH IF EQUAL ELSE INCREMENT SUBSYSTEM tt CHECK TO SEE IF ['ONE BRANCH IF NOT IF DONE SKIP CARD SUBSYSTEM FOUND - SET NEXT BRANCH IF INVALID EXIT - RELEASE DISK AND EXIT A8 MAIN. MACRO V004A PAGE 1+ 289 230 j 291 292 293 i 294 i 295 i 296 i 29? ;, 298 j 299 .< 306 .; 201 i 302 ■ > 303 j 304 .1 305 .; 306 .; 307 1320 010046 C 308 1322 010146 309 1324 010246 310 311 312 313 1326 116700 177114 314 1332 042700 177400 315 1336 016501 000002 316 1342 126011 000034 '" 317 1346 602507 318 219 220 321 1350 006300 322 1352 016000 000130" 3 .£ 3 1356 003503 224 1360 111101 ~: 3 ,e "i 1362 042701 177400 226 1366 110102 i 2. <■' 1370 006301 ii'o 1372 06O100 229 1374 006301 i-30 1376 060100 ]:31 1400 012067 177312 J- —• til. 1404 003501 H3 1406 012067 177306 124 1412 003476 535 1414 012001 i3€- 1416 032701 PROGRAM NAME AUTHOR/DATE OVRLAV DAVID MUELLER MACHINE/LANGUAGE PDP-11, 16K JULV, 1972 PAL-11R/ V005A PURPOSE CALL SEQUENCE TO READ IN OVERLAYS JSR R5, OVRLAV BR . +4 . WORD OVR WHERE OVR IS THE ADDRESS OF A BYTE CONTAINING THE NUMBER OF THE OVERLAY TO BE READ IN. A MONITOR MAV READ IN ONLV ITS OWN OVERLAYS OVRLY1: MOV RO, - MOV Rl, - MOV R2, - ">AVE REGISTERS GET PARAMETERS AND VALIDATE OVERLAY NUMBER MOVB SYSMOD, R0 ; GET NUMBER OF MODULE CURRENTLY BIG #177400, R0 .i IN CONTROL MOV 2-:R5>,R1 .: GET OVERLAY NUMBER ADDRESS CMPB NTABLE-::R0>, .; BLT OVR050 .; GET PARAMETERS FOR TRANSFER .; GET BASE OF OVERLAY TABLE ASL R0 MOV MODTBLvRO), R0 BLE OVR050 MOVB '::ri:>, Rl BIC #177400, Rl MOVB Rl, R2 ASL Rl ADD Rl, RO ASL Rl ADD Rl, RO MOV +, MEMADD BLE OVR060 MOV +, Rl BIT #100000, Rl BRANCH IF THERE ARE NO OVERLAY': GET OVERLAY NUMBER PICK UP ABSOLUTE BLOCK NUMBER BRANCH IF NOT INI TED PICK UP MEMORY ADDRESS BRANCH IF NOT INI TED PICK UP NUMBER OF WORDS TEST FOR UNIT NUMBER A9 MAIN MACRO V004A PAGE 1+ 100000 137 1422 001003 BNE OVR010 £38 1424 105067 CLRB UNITNO 177263 333 1430 000403 BR OVR020 3 46i 1432 112767 OVR010 : MQVB #1, UNITNO 000001 177253 241 1446 032701 040000 OVR020 : BIT #40000, Rl 242 1444 001404 BEQ OVR030 £43 1446 016767 177040 177240 MOV DT, UNAME j:44 1454 000403 BR OVR040 ;45 1456 016767 177026 177230 OVR030 : MOV DP, UNAME i:46 1464 042701 140000 OVR040 : BIC #140000, Rl 247 1470 022701 003777 CMP #3777, Rl ;4S 1474 001445 BEQ OVR060 1.49 1476 010167 177220 MOV Rl, NWORDS :5W 51 i CHECK FOR POSSIBLE SVS :53 1502 006301 ASL Rl :54 1504 €166701 17721Q ADC- MEMADD, Rl :55 1510 162701 WW W002 SUB #2, Rl :56 1514 020167 176766 CMP Rl, CORTOP • c -,.■» 1520 101041 BHI OVR070 '._''"' 1522 012746 000706 MOV #LINk, - :5'-> 1526 1040W6 EMT tz. ;66 1530 012746 300716' MOV #TRAN, -',SP> 61 1534 012746 0007W6 MOV #LINK, -vSP.> 62 1540 104010 EMT 10 63 1542 012746 000706 MOV #LINK, -vSP • 64 1546 104001 EMT 1 65 1550 012746 000706 MOV #LINK, -vSP,- 66 1554 104007 EMT y 6 ? 1556 012602 0VR999 : MOV +, R2 68 1560 012601 MOV •:SP>+, Rl 69 1562 012600 MOV < SP > + ■ R0 70 71 1564 000205 RTS R5 . INVALID OV ERLAV i , i BRANCH IF ONE ; ELSE SET UNIT NUMBER TO O i SET UNIT NUMBER TO 1 ; CHECK FOR UNIT NAME .: BRANCH IF DISK .; ELSE SET TO DECTAPE i SET TO DISK i CLEAR UNIT BITS i CHECK TO SEE IF NOT INI TED , BRANCH IF SO PROTECT I ON V I OLAT I ON ;FIND TOP ADDRESS OF OVEPLAS , TEST AGAINST MAXIMUM TOP : BRANCH IF GREATER THAN . ELSE INIT DATA SET , TRANSFER OVERLAY . WA I T , RELEASE DATA SET RESTORE REGISTERS A10 MR IN. MACRO V004A PAGE 1+ 374 1566 112767 OVR050 : MOVE #1, PflRflM } SET ERROR CODE 000001 176626 375 1574 111167 MOVE , PARAM+2 ; STORE OVERLAY # REQUESTED 176624 376 160O 116067 MOVE NTABLE.. PARRM+3.1 STORE NUMBER OF OVERLAYS 000034 ■" 176617 377 1696 000423 BR OVR080 .: 379 .; UNITIATED OVERLAY 380 ; 381 1610 112767 OVR060 : MOVE #2, PARAM 000002 176604 382 1616 110267 MOVE R2, PARAM+2 176602 383 1622 000415 BR OVRO80 384 .: 385 j SYSTEM PROTECTION VIOLATION 386 J 387 1624 112767 0VR070 . MOVE #3.. PARAM 008083 176578 388 1632 118267 176566 389 1636 016767 177856 176562 398 1644 816767 177952 176556 391 1652 818167 176554 ) SET ERROR CODE STORE OVERLAY # MOVE R2, PARAM+2 ; SET ERROR CODE i STORE OVERLAY # MOV MEMADD, PARAM+4 .; STORE MEMORY ADDRESS MOV NWORDS, PARAM+6 J STORE NUMBER OF WORD: MOV Rl, PARAM+10 STORE CALCULATED TOP ADDRESS .1 CALL ERROR ROUTINE 94 CLRB SVSMOD JSR R5, OVRLAV BR . +4 . WORD ONE JSR R5, 0START+2 395 1656 116767 OVR080 : MOVE SVSMOD, PRRAM+1 ; STORE MONITOR # 176564 176537 396 1664 105867 176556 397 1678 884567 176118 3 9 8 1 6 ? 4 8 8 8 4 8 1 3 9 9 1 6 7 6 8 8 8 515 408 1780 884577 176176 481 1784 184868 482 483 484 485 486 487 488 489 EMT :.0 PUT SYSTEM IN CONTROL GET ERROR ROUTINE GO TO ERROR ROUTINE TERMINATE SYSTEM NAME JPDATE AUTHOR/DATE DAVID MUELLER MACHINE/LANGUAGE PDP-11, 16K JULY, 1972 PRL-11R, V885A PURPOSE TO MAKE CHANGES TO THE SYSTEM TABLES All MAIN. MACRO V004A PAGE 1+ 410 411 412 413 414 415 416 417 418 419 426 421 422 422 424 425 426 427 42S 429 420 421 422 422 424 425 426 437 .i 438 429 440 44:1. 442 442 4 41 . 445 1 706 010046 U #46 I 7 J. 91014rt. 44 ? 1 712 010246 448 1 21-1 010246 44'-" 1 7.16 010446 459 ■]. 2:' 9 012704 009004 451 452 452 454 1 7 24 116 200 1 76516 455 12 7 29 006300 4 5f-- 1 P32 016000 000120 45,' I. ' _ f. 116501 909002 458 :12 ■'42 906301 459 1 "44 060190 469 1' "46 096291 461 1 "59 960100 462 i CALL SEQUENCE JSR R5, UPDATE BR CONT . BVTE OVERLAY . BVTE STATUS WHERE OVERLAV IS THE OVERLAV NUMBER STATUS IS AN INSTRUCTION BVTE AS FOLLOWS BIT = UNIT NUMBER - 0=0 1=1 BIT 1 = UNIT NAME - 0=DISK 1=DECTAPE BIT 2 = BLANK - FOR ROUTINE USE ONLV BIT 3 = 1 IF MEMORV ADDRESS TO BE CHANGED BIT 4 = 1 IF LENGTH TO BE CHANGED BIT 5 = 1 IF ROUTINE TO LOOK ONLV AT UNIT INDICATED BIT 6 = 1 IF ROUTINE IS TO SCAN ALL UNITS BIT = RESULT - = IF FILE FOUND = 1 IF FILE NOT FOUND THIS BVTE IS FOLLOWED BV WORDS CONTAINING THE FOLLOWING PARAMETERS, IN ORDER !':■• FILE NAME AND EXTENSION, IN RAD IK 50. IF BIT 5 OR 6=1 2> MEMORV ADDRESS. IF BIT 2 = 1 2> LENGTH, IF BIT 4 = 1 THE PARAMETERS ARE PRESENT IFF THE CORRESPONDING BITS IN THE STATUS BVTE ARE ON THEV MUST BE IN THE ORDER GIVEN, BUT ANY COMBINATION OF THEM MAY BE PRESENT THE LAST PARAMETER IS FOLLOWED BV AN INSTRUCTION .LABELED CONT SAVE REGISTERS AND INITILIZE UPD T 1 MOV RO, -CSP3 MOV Rl, --•:.SP,> MOV R2, -'.:sp> MOV R2, -vSP> MOV R4, -, Rl ASL Rl ADD Rl, RO ASL Rl ADD Rl, RO , GET MONITOR # i GET MONITOR TABLE j i GET OVERLAV # i GET OVERLAY ENTRV A12 MAIN. MACRO V904A PAGE 1+ 462 464 465 1752 01O501 466 1754 062701 000004 467 468 469 476 1760 122765 000140 000002 471 1766 001464 472 1770 012167 176740 472 17/4 012167 176726 474 2000 012167 176724 475 2004 116502 000002 476 2010 042702 177774 477 2014 620227 000001 473 2020 001502 479 2022 010202 480 2024 042702 177775 48:1 202:0 016267 000510 176656 482 2026 116567 000002 176647 432 20 'J- 4 142767 000276 176641 484 2052 012746 000706 ■ 485 2056 104006 486 20i-0 012746 000724'' 437 2064 005046 488 2066 012746 000706'' 489 2072 104014 496 2074 012746 000706 491 2100 104007 492 2102 042766 177477 000004 492 2110 022766 000200 000004 494 2116 001042 495 2120 012610 i GET ADDRESS OF PARAMETER LIST MOV R5, Rl J ADD #4, Rl .; CHECK FOR EITHER LOOK OR SEARCH AND LOOK IF NECESSAR 1 EilTB #140, STATUS J CHECK STATUS BVTE BEQ UPD029 MOV +/FILE MOV '::R1>+, FILE+2 MOV (Rl)+, EXT JPD010: MOVB STATUS < R5 >, R2 Bit #177774, R2 CMP R2, #1 BEQ UPD050 MOV R2, R2 EMC #177775, R2 MOV UNIT':.R2::', UNAME BRANCH IF NEITHER GET FILENAME GET EXTENSION GET UNIT CODE CHECK FOR DF1 BRANCH IF SO GET UNIT NAME MOVB STATUS EMT 6 MOV #FILE, -<::SP> CLR - MOV #LINK.. - EMT 14 MOV #LINK, - EMT 7 BIG #177477, 4-:: SP> CMP #200, 4 BNE UPD040 MOV '::SP> + , '::R0> INIT LOOK RELEASE CHECK TO SEE IF FILE IS PRESENT ; AND CONTIGUOUS .; BRANCH IF NOT .: ELSE SET BLOCK NUMBER A13 MR IN. MACRO V0O4R PRGE 1+ 496 497 498 499 596 501 502 503 504 505 507 508 5:1.0 511 512 513 5:14 515 516 517 518 519 520 52 J. 2122 042760 140000 000004 2130 056360 000476 000004 2136 022626 2140 142765 000200 000003 2146 132765 000010 000003 2154 001402 2156 012160 000002 2162 132765 000020 000003 2170 001407 2172 042711 140000 2176 042760 037777 000004 2204 052160 000004 BIC #140000.. 4 J SET UNIT CODES BIS USET, 4 ; CMP +, '::SP>+ :• CLEAR STACK ; CHECK FOR MEMORY ADDRESS AND LENGTH UPD020: BICB #200, STATUS i SET RESULT BITB #10, STATUS i CHECK FOR PRESENCE OF MEM RDD BEG! UPD030 MOV <&±')+, 2 ; BRANCH I F NOT .; ELSE SET MEMADD UPD030: BITB #20, STATUS i CHECK FOR PRESENCE OF LENGTH BEG UPD999 BIC #140000, BIC #37777, 4-:: RO> BIS .Rl :< + , 4 i BRANCH IF NOT i ELSE SET LENGTH 2210 01-604 2212 012602 2214 012602 2216 012601 2220 012600 &2.22 000205 521 2224 022626 524 2226 005726 525 2230 152765 000200 000003 52^. 2236 132765 000100 000003 527 2244 001761 528 2246 005304 529 2250 001757 5^.0 2252 105265 000003 531 225€ 00UL'52 532 000001 END OF SUBROUTINE UPD999 : MOV <5P>+, R4 MOV +, R3 MOV ■:SR>+, R2 MOV +, Rl MOV +, RO RTS R5 L K U N S U C C E S S F U L IJPD040: CMP vSR>+, + TST '.:sp> + UPD050 BISB #200, STATUS ; UNSTACK REGISTERS J J , RETURN POP STACK SET ERROR CODE BITB #100.. STRTUS',R5> j CHECK TO SEE IF SEARCH BEQ UPD999 DEC R4 BEQ UPD999 INCB STRTUS