■HI Hi ■H HB Hfl MiinfT 1 I W&B HI m i I H ' t ; , Ban W i ntfiH fig w yBBgB IHBIS HBM1 LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAICN 510. 84 no. 601-612 cob. 2 for each non-returned £ ; ° 5 ^ e ^ materiaU can Theft, mutilation .or J^^S^^^Ho?. All materials be causes for student W«J fa are the OWne ^ b ^te^r:fVno!s an" are prated by APR When renewing by phone, write new due date below previous due date. y^uIUCDCS-R-TU-609 ThrtJ AEc-coo-2383-0002 THE ICGS SYSTEM: SYSTEM TABLES MANUAL by David Henry Mueller February 197^ UIUCDCS-R-TU-609 THE ICGS SYSTEM: SYSTEM TABLES MANUAL by David Henry Mueller February 197^ DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS 6l801 * Supported in part by contract US AEC AT (11-1)2383 Table of Contents Part I Introduction 1. Introduction 1 1.1 Monitors and Overlays 1 Part II The System 2 . The Nucleus h 2.1 The Scheduler (SVC) h 2.1.1 Line Printer Facility h 2.1.2 Call for Next Monitor h 2.2 The Overlay Facility (0VRLAY) 5 2.3 The Table Managing Facility (UPDATE) 5 2 . k Other Facilities 6 3 . The In it iali ze r 8 h. Executing The System 8 Part III The Debugging Package 5. The Overlay Builder (0VRBLD) 9 6. The Debugging Initializer 10 6.1 The Input File 10 6.1.1 Record Description 10 6.1.2 File Description 12 Bibliography 15 Digitized by the Internet Archive in 2013 http://archive.org/details/icgssystemsystem609muel ICGS System Users Manual Part I Introduction 1. Introduction The ICGS System is a batch system for a mini -computer . It executes a limited number of system programs, and provides facilities for rapid overlaying of these programs. The system was written for the following configuration: 1) PDP-11/20 with l6K of core memory 2) KE-11A Extended Arithmetic Element 3) Teletype h) RF11 256K-2M word fixed-head disk 5) 2 TCll Dectapes 6) GDI model 100 card reader 7) Gould U800 printer /plotter The System is intended to run under DOS. The System itself consists of a core resident Supervisor, a set of disk resident System modules, a set of desk resident user-defined modules , two bootstrap loaders , and an independent program to aid in the building of user modules. This Manual is intended to aid the user in preparing the modules and executing the system. Familiarity with the PDP-11 and DOS is assumed. 1.1 Monitors and Overlays 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. The set 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 Supervisor is responsible for reading in monitors and passing control to them. It is also responsible for reading in a monitor's overlays upon request and for storing the information necessary to do this. 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 has finished execution. 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 last option allows a monitor to temporarily relinquish control to another monitor ., then regain control later. All the facilities of DOS are also available to a given 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. 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 the next in the subsystem. The Supervisor maintains the subsystem name and the identity of the first monitor in each subsystem by which the user communicates with the system. 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 -2- 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. -3- Part II The System 2 . The Nucleus 2.1 The Scheduler (SVC) The Scheduler controls the execution of the monitors. As each monitor returns to the Supervisor, it tells the Scheduler what is to be run next. The Scheduler then runs the line printer, if it has been requested to do so, determines the next monitor to be executed, reads it in, and gives it control. The call sequence is: JMP SVC 2.1.1 Line Printer Facility- All line printer output from a monitor must be put in a single file on disk. Before exiting, a monitor which wants to run the line printer must put the radix 50 equivalent of the file name and extension in three consecutive words beginning at LPFILE and set an indicator byte LP to 1. Both LPFILE and LP are resident in the system and must be declared global. LP will be cleared after the line printer is executed. 2.1.2 Call for Next Monitor Upon exit, a monitor must set a byte labeled NEXT to indicate what procedure is to be followed in determining the next monitor to be executed. There are three options: 1) if NEXT is positive, the scheduler reads in the monitor whose number is given by NEXT. 2) if NEXT is negative, the monitor pushes the number of the monitor which just finished execution on a stack called the nest. It then takes the absolute value of NEXT to be the number of the next monitor to be executed. -a- 3) if NEXT is zero, the scheduler takes the number of the next monitor to be executed from the top of the nest, and the nest. If the nest is empty, the Scheduler reads cards from the card reader until it reads a system control card (one with a ' $$ ' in cc 1-2). It then uses the characters in cc k-6 as a subsystem name and searches a list to find the monitor to execute. The card buffer is available with its line buffer header at the global location CRHEAD. Possible errors in SVC include an attempt to execute a non-existent monitor, or to nest more than six monitors. 2.2 Overlay Facility (0VRLAY) The overlay facility may be called by a monitor or one of it overlays. The overlay routine reads in an overlay and returns to the calling Program. The call sequence is as follows: JSR R5, 0VRLAY BR ,+k .WORD 0VR 0VR is the address of a byte containing the number of the overlay to be read in. A monitor may read in only its own overlays. Possible errors include an invalid overlay number, an attempt to read in an uninitialized overlay (i.e. - one for which all parameters are not present in the system table), and an attempt to overlay the Supervisor. 2.3 The Table Managing Facility (UPDATE) The Supervisor tables keep four parameters for each overlay: 1) The I/O unit on which the file containing the overlay is located. 2) The start block of the overlay file. 3) The start address of the overlay in core. h) The length of the overlay, in words. These parameters may be set by the initializer, and they must all be present -5- before 0VERLAY is called. If at any time one of the parameters changes , UPDATE must be called to make the change in the supervisor tables. The call sequence is as follows: JSR R5 , UPDATE BR C0NT .byte Overlay . byte status other parameters C#NT: 0VERLAY is the overlay number and STATUS is a status byte set up as in figure \ 1. The other parameters are: 1) File name and extension , in radix 50, present if bit 5 or 6 is 1 2) Memory start address, present if bit 3 is a 1 3) Length, in words, present if bit h is 1 These parameters are present if and only if the corresponding bits in the status byte are on. They must be in the order given, but any combination of them may be present. A monitor may update only its own overlay table. If the routine fails, the result bit is set to 1 and no change is made to the tables. 2.1+ Other Facilities In addition to the routines above, the Supervisor provides the following facilities: 1) A link block for the disk labeled DFLINK, and one for the reader labeled CRLINK which have already been inited. 2) A link block for the teletype, labeled KBLINK, which has not been inited. -6- The Status Byte =0 for unit Unit Number =1 for unit 1 =0 for Disk Unit Name =1 for Dectape Reserved for use by UPDATE =1 if Memory Start address is to be changed -1 if Length is to be changed =1 if UPDATE is to look only on the unit indicated in bits 0-1 to find the overlay file =1 if UPDATE is to search all units beginning with the unit indicated in bits 0-1 to find the overlay file result =0 if update successful = 1 if (l) file not found or not contiguous on update or search, or (2) if overlay numbers invalid Figure 2.1 -7- 3) A ten-word field labeled PARAM, which can be used to pass information between monitors. k) The system card read in by the monitor, with line buffer header CRHEAD. 3. The Initializer The initializer is the first routine executed when the System is run. It initializes all system tables and variables, then transfers to SVC to begin execution. The initialization of the System tables is controlled by tables within the initializer. The intializer tables consist of a table of transfer addresses for the monitors, a table giving the highest numbered overlay in each monitor, tables describing the subsystem, and, finally, a table giving the parameters for the overlays, i.e., the Status byte for use by UPDATE, the file name and extension of the overlay file, the memory start address, and the length of the overlay. All or none of these parameters will be initialized, depending on the status bytes. A more detailed description of the initializer tables appears in the System Tables Manual. h. Executing the System Before executing the System, mount all DECtapes which are necessary. Log in, and type $RUN SYSTEM. This will bring in the system nucleus and the initializer, run the initializer, and jump to the Scheduler, which will, in turn, read a control card from the card reader and execute the subsystem indicated. -8- Part III The Debugging Package 5. The Overlay Builder (0VRBLD) The Overlay Builder is a program for building overlays to the system and monitors. It is a self-contained program which creates a contiguous file containing the overlay. The overlay builder is executed by first running the Linker to obtain a load module, then executing the Overlay Builder to create the overlay. The load module which is created will contain only the modules in the overlay. Run the Linker as is described in the Link-11 Linker Manual, with the following qualifications: 1) In addition to the output load module and load map, the load symbol table may be obtained by typing a file specification after the file specification for the load map. This will be used if further overlays are to be read in while this overlay is present. 2) The first input should be the load symbol table describing the remainder of the system configuration. This will always include the Supervisor nucleus, and may include ODT and other monitors and overlays. It will be obtained from a previous linkage. The symbol table for the Supervisor nucleus alone is SYSTEM. LSM, and for the nucleus and ODT, SYSTST.LSM. 3) After the last input file, on the first time specify the T switch as follows: /T:n, where n is the top word to be occupied by the overlay. Top addresses for the Supervisor are 075176 without ODT and 067 1 +3 1 4 with ODT. After finishing with Link, type the following commands $GET 0VERLAY where 0VRLAY is the load module § CTRL C output from the Linker .KI $RUW 0VRBLD # This will load the overlay and the overlay builder into core. Then type a command string as follows : -9- #_ file name specification/switch where switch is one of the following: 1) SL:s:l where s is the starting address of the overlay and 1 is its length in bytes. 2) SE:s:e where s is the starting address of the overlay and e its ending address The values of s, 1, and e must be six digit octal numbers with leading zeros, if necessary. The overlay will be built under the name given in the file name specification. 6. The Debugging Initializer This routine is similar to the regular initializer, but initialization of the monitor tables is controlled by an input file rather than core resident tables. These are described below. The intention is to give greater ease in altering the initial values of the tables. 6.1 The Input File The input file consists of a series of records describing the monitors, overlays, and subsystems present. These are described below as cards, but they may be on any input device except the teletype keyboard. The records are described individually, then the make-up of the file is described. 6.1.1 Record Description Card ID cc Description $1 1-2 Card ID-' $1 ' -number of monitor card k-9 Number of monitors -minimum 1 maximum 10 -10- Card ID cc Description 1-2 Card ID-' $2 'Monitor Description Card k-9 Monitor Number -minimum 2 11-13 Unit designation for the monitor file- DFO = Disk DTO = Dectape DTI = Dectape 1 2 15-20 File Name of the monitor file 2 22-2U Extension for the Monitor File 26-31 Memory start address 33 Switch-L = following field is length, in bytes E = following field is end address * = ignore following field 35-^0 Length, in bytes, or end address U2-U7 Transfer i+9-5*+ Number of overlays for this monitor 56-61 Region size, in bytes, (i.e., the largest number of bytes in core occupied by this monitor its overlays at one time) $3 1-2 Card ID-* $3' -overlay card U-9 Overlay number -minimum 2 11-13 Unit of overlay file - DFO = Disk DTO = Dectape DTI = Dectape 1 2 15-20 File name of overlay file 2 22-2U Extension of overlay file 3 26-31 Memory start address 33 Switch-L = following field is length, in bytes E = following field is end address * = ignore following field -11- Card ID $U cc 1-2 U-9 11-16 18-20 Description Card ID- 1 $U '-number of subsystem card Sul system number Monitor number of first monitor subsystem First three characters of subsystem name $0 1-2 Card ID-' $0' -end of initilation An asterisk (*) following this field will cause no action to be taken on the record. 2 An asterisk (*) in the first character of the file name field will cause the file not to be located. The unit and extension fields will be ignored. An asterisk (*) in the first character of this field will cause the filed to be ignored. All numbers must be six digit octal numbers, with leading zeros, since the conversion routines will not accept leading blanks. 6.1.2 File Description The first record must be a $1 card. This is followed by sets of $2 and $3 cards, one set for each monitor. Each set consists of a $2 card, followed by one $3 card for each overlay to the monitor. There are no $3 cards if the monitor has no overlays. After the last $3 card comes a $i+ card, then one $5 card for each subsystem. The file is terminated by a $0 card. There must be $2 card for each monitor number from 2 to M+l , where M is the number in cc k-9 of the $1 card. For each $2 card, there must be a set of $3 cards, one for each overlay number between and N-l, where N is the number in cc 1+9-5^ of the corresponding $2 card. All $3 cards must be in sequence by overlay number behind the corresponding $2 card and all $2-$3 -12- card sets must be in sequence by the monitor number on the $2 card. There must be one $5 card for each subsystem number between and S-l, where S is the number in cc k-9 of the $h card. All $5 cards must be in sequence ny subsystem number. Finally, tht^re may be no more than 2k $2 and $3 cards, that is, no more than 2h monitors and overlays. 6.2 Operating Procedures The debugging version of the System consists of the debugging initializer ODT, and the Supervisor. To execute the debugging initializer, type the following commands. 1) $_GET SYSTST ODT - this brings debugging supervisor into core 2) $ODT - this executes ODT optional 3) ^076276 ;B - this will set a breakpoint on the last instruction of the Scheduler. When this point is reached, the monitor is in core and may be debugged, optional h) ^07676U;B - This will set a breakpoint on the last instruction of 0VRLAY. When this point is reached, the overlay is in core and may be debugged. 5) j^063^7^;G - this begins execution of the supervisor initializer 6) #file name specif cation/OD - This gives the input file for the debugging initializer. The initializer will finish execution and transfer to SVC. 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 -13- knows the location of its file by the file name, the Supervisor ., upon request, look this file up in the directory of oen 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 upon request. -lU- Bibliography Brown, R. Leonard, Jr., Numerical Systems on A Minicomputer, Report No. UIUCDCS-R-73-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, A Batch System with Rapid Overlay Capabilities, Report No, UIUCDCS-R-73-6lU AEC-C00-2 383-0005, Department of Computer Science, University of Illinois, Urbana, January, 197^. Mueller, David, The ICGS System: System Tables Manual, Report No. UTUCDCS-R-73-609 AEC-C00-2 383-0003, Department of Computer Science University of Illinois, Urbana, January, 197^. FmAEC-427 (6/68) ECM 3201 U.S. ATOMIC ENERGY COMMISSION UNIVERSITY-TYPE CONTRACTOR'S RECOMMENDATION FOR DISPOSITION OF SCIENTIFIC AND TECHNICAL DOCUMENT I See Instructions on Reverie Side ) 1 AEC REPORT NO. AEC-C00-2 383- 0002 2. TITLE THE ICGS SYSTEM: SYSTEM TABLES MANUAL TYPE OF DOCUMENT (Check one): [3 a. Scientific and technical report I | b. Conference paper not to be published in a journal: Title of conference Date of conference Exact location of conference Sponsoring organization ^} c. Other (Specify) RECOMMENDED ANNOUNCEMENT AND DISTRIBUTION (Check one): R3 a. AEC's normal announcement and distribution procedures may be followed. ~2 b. Make available only within AEC and to AEC contractors and other U.S. Government agencies and their contractors. ] c. Make no announcement or distrubution. REASON FOR RECOMMENDED RESTRICTIONS: SUBMITTED BY: NAME AND POSITION (Please print or type) C. W. Gear Professor and Principal Investigator Organization Department of Computer Science University of Illinois Urbana, Illinois 6l801 j£& Signature k> T Date February 197 1 * FOR AEC USE ONLY AEC CONTRACT ADMINISTRATOR'S COMMENTS, IF ANY, ON ABOVE ANNOUNCEMENT AND DISTRIBUTION RECOMMENDATION: PATENT CLEARANCE: LJ a. AEC patent clearance has been granted by responsible AEC patent group. [_) b. Report has been sent to responsible AEC patent group for clearance. LJ c. Patent clearance not required. BLIOGRAPHIC DATA