■HMHMMH8 I ■ BIB IHjHovII IwnSsfl BHHBInH mm BnU HMiiuiiiiiiHH I —Hi rl1n»¥v HDQflHll IHIUSl HSBMU&BbuuI HHBO^B tSB LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN Digitized by the Internet Archive in 2013 http://archive.org/details/etssystemusersgu523oxle 5/o. r disk (was an FCB) 2 => teletype k => DECtape 6 => line printer 10 => paper tape reader 12 => paper tape punch Ik => card reader Example II. 2 Routine to Extract Device Type and Branch to Special Routine 6. jbstat/jbwait In order to implement timesharing it is not sufficient to be able to start, stop and switch jobs. Jobs will often generate conditions which require them to wait for some later event (e.g., completion of a line of TTY input). It is very inefficient to keep restarting a job to allow it to check for the occurrence of a given event. A better solution is to set some type of flag and let the system watch for the event, then wake the job when the event has occurred. In ETS there are a number of specific events on which a job might wait (in particular, each device has a unique event associated with it as does the file processor and the timer service). When a job is created it is assigned 2 status words ( JBSTAT/ JBWAIT ) to indicate blockages that may occur. When a job is running both JBSTAT=1 and JBWAIT=1. When a job requests a service for which it must be blocked, JBWAIT is cleared and the bit associated with that event is set by the system event routine in JBSTAT. The condition that a job be able to run is then JBSTAT * JBWAIT ^ 0. The system then can check JBSTAT ^ JBWAIT and schedule a job to run only when it is not blocked. Note that a job will then run if any one of a number of blockages are relieved; it will not wait until they are all relieved. 7« IOSTS is a one word pointer to a job's i/O status which is kept in the second word in the job data block. This word contains the result of the last i/O or file operation performed by the job (see figure II. k for a list of error codes). 8. REGREL identifies six bytes which provide the register relocation controls (see section III.B). 10 ERROR NAME ERROR NUMBER BADCMD 1 BADDIR 2 BADNAM k NOTFND 6 INUSE 10 NOROOM 12 NOSUCH Ik NOTCLS 16 NOTAVL 20 NOTOFN 22 PRVIOL 2k EOF 26 ABORT 30 DATERR 32 KNGDEV 3k NOLOAD 35 CKSMER 36 OUTRNG 37 MEANING Invalid command Directory screwed up Badly formed file name File not found File of same name is in use Directory is full or disk is full File or UFD does not exist Can't open already open channel Device not available to user Trying to operate on unopened channel Protection violation End of file on read/write Operation aborted Data error on device Hung device for job No load address specified on object file Checksum error in loader Address requested out of user area Figure II. k FIP or i/O Error Codes 11 9« COMWRD identifies four words which are reserved for communi cations between the system and the user job. These words presently have no designated meaning in the system and may be used at will by the user job. 10. USRFLG is a communication word in which the system sets flags to indicate that the user has typed a control character which should be meaningful to the user job (see section VII. B) . 12 III. Code Description A. Dynamic Relocatability Since the PDP-11 has no relocation hardware and ETS intends to be a timesharing monitor, the code in ETS must be relocatable. This means that ETS must be able to stop the execution of the user job at any time in order to swap it out to allow another process to run. When ETS determines a job is to be swapped in again from disk, it does not necessarily return the job to the same position in memory. A job does, however, always remain in a single contiguous block so relative distances within the job itself do not change. 1. Dynamic relocatability requires the use of strictly relative addressing modes with the user's program variables. 2. When referencing system variables such as REGREL or USRFLG the user must use strictly absolute addressing (i.e., INCB @#REGREL) . 3» With the exceptions noted here, the user must not develop absolute addresses pointing anywhere in the user area. k. ETS does provide limited ability to develop absolute pointers into the user area. The user job may inform ETS of its intentions to place an absolute address in a register or it may place absolute addresses on the stack or it may place them in reserved pointers in system area (RELPTR). B. Register Relocatability 1. When a user wishes to place an absolute pointer in a register he may tell ETS of his intentions by putting a non-zero quantity in the register relocation byte (REGREL) corresponding to that register. Six REGREL bytes are assigned to the registers RO to 13 R5 in order beginning with RO. Any non-zero quantity in a register relocation byte indicates that a user may have absolute pointers in the corresponding register (see example III.l). 2. Conditional Relocation When ETS finds a non-zero REGREL byte, it assumes that the corresponding register may contain an absolute pointer into the user area. However, should ETS need to relocate that register, it will check the contents of the register, to see if it actually contains a value which would be a valid pointer into user area. If it does not contain a possible absolute address for the user (a value which lies between 30000o and 60000n), ETS will not relocate the register. 3« Conditional relocation allows the user to conveniently construct absolute pointers in registers without having critical segments of code (code which must not be interrupted during execution). The following example is not a critical section because of conditional relocation: INCB @^REGREL+1 ;Mark Rl as absolute MOV #K-.-6, Rl ;Load offset to desired variable ADD PC, Rl ;Make it an absolute pointer If the job is interrupted and swapped between the MOV and ADD instructions, it will try to relocate Rl but will not find a value in Rl which does not point to user core (X is a local variable) and will not change it. Without conditional relocation, the system would modify Rl which, at the time of the interrupt, contained a relative offset rather than an absolute pointer. 11+ REGREL - xxx ;Address of register relocation ;Byte zero INCB @t^IEGREL+3 ;Register 3 is to be relocated INCB @^REGREL+5 ;Register 5 is to be relocated Example III.l Marking Registers Which May Contain Absolute Pointers 15 k-. The stack in ETS is a conditionally relocated area (see III.D), and consequently the user must be careful about saving registers on the stack. In general, registers which are relocatable may be placed on the stack and registers which contain arbitrary data should not be pushed on the stack. C. COMWRD and RELPTR 1. There are four reserved words, beginning at COMWRD, in the system area which have been set aside as communication words between the system and the user. None of these four words are presently in use; hence, the user may store anything he wishes in this area. 2. There is an additional communication word by the name of USRFLG whose usage has already been defined (see section II.C.10). 3. There are seven words beginning at RELPTR which are kept as automatically relocated user offsets. Each of these seven words is changed by an amount equal to the distance which a user is moved anytime the user is swapped. Thus, the user may construct an offset to an absolute pointer which does not point directly into user core and still have the system relocate it each time he is moved. When a user job begins execution each of these seven "relative pointers" will point absolutely to the first location in the user area. Therefore, the user does not need to construct a program counter relative offset in these pointers. He may simply add the offset from the beginning of his own area to the present contents of the pointer and construct his absolute pointer (see example III. 2). D. Stack Conventions 1. The user stack is also treated as a conditionally relocated area. Each time a user's job is swapped out and brought in at a different 16 RELPTR = XXX PTRONE RELPTR PTRTWO RELPTR+2 ; Address of relocating pointers ADD #XRB,@#PTRONE ; PTRONE now contains an absolute jpointer to XRB - the system initially loads ; PTRONE "with the user job origin LNCB @#REGREL+1 ;Mark Rl as absolute MOV @#PTR0NE,R1 ;Pick up pointer in Rl Example III. 2 Establishing and Referencing Absolute Locations using RELPTR IT location the system examines all words "between the current top of stack and the stack base, and relocates any of those which point absolutely into the user area. Note that the JSR instruction and the processor trap instructions also cause the current value of the program counter to be pushed onto the stack. The trap instructions also cause the processor status word to be pushed onto the stack. Since the stack is a conditionally relocated area the system will modify the program counter values when necessary; however, the processor status word is not a possible pointer into the user area and the system will not change it. 2. When a user gob begins execution it has the minimal stack size of ^00n bytes. The user may increase this if need be, however, he may not decrease it. When calculating the amount of stack necessary for his job, the user should determine the maximum number of bytes that he might need at any time and then add 200 o o bytes to that for system use and for a protection buffer. Notice that there is no form of protection for user stack overflow. Thus, care must be taken to insure that no user stack overflows occur. 3. Should a user need to increase his stack size, he simply loads his desired stack size into a system variable called STKBAS. (He cannot just add an increment.) The user can use this facility should he need to create a table of pointers into his user area. By telling the system that he has increased his stack size but not actually doing so, the user can create a table which will be conditionally relocated. If he loads the absolute values of the pointers he wants into this table, he has a table of relocated values which may be used as a dispatch table (see example III. 3). 18 STKBAS = xxx JOBORG = xxx TBLSIZ = 16 ;Address of user stack size variable ; System pointer to beginning of user job ;Our jump table will have 16 entries MOV #TBLSIZ+TBLSIZ-t400,@#STKBAS MOV #TBLSIZ, RO ADD #1-01, @t^EGREL+2 MOV @#J0B0RG, R2 MOV R2, R3 ADD #100, R2 Bl: MOV Rj5, (R2) + DEC RO BGT Bl ADD #^00, R3 ADD #3UB1, (B5)+ ADD $SUB2, (R3)+ Set our new "stack" size Set up TBLSIZ entries Mark R2 & R3 as absolute address regs, Pick up start of our job and replicate Point just above stack base Fill table with our own job origin Count this entry And get them all Now use Rj5 to finish construction of table Abs. jump address to SUBl Abs. jump address to SUB2 ADD #SUBl6 (R3)+ ;Abs. jump address to SUB16 Example III. 3 Construction of a Dispatch Table Containing Absolute Addresses at Base of Stack 19 km The user should be careful about using instructions of the form JSR R5, X where R5 may not be a relocatable register since the system pushes the contents of the register onto the stack. If R5 is an absolute piece of data which looks like a pointer into the user area the system will change the data in R5 if the user is swapped. A useful technique for the user who needs a stack which may contain arbitrary data is to create a separate data stack below the user's real stack and use another register such as R5 as a stack pointer. Note that R5 must be indicated as a relocatable register. Also note that R5 does not behave exactly like SP in doing byte operations in auto increment and auto decrement mode. E. Processor Status Word Manipulation 1. In general the user should avoid modifying the processor priority. However, he may examine and modify the condition codes in the processor status word at will. There may be times when it is necessary for the user to execute short sections of code without interruption. This may be done by running at system priority seven. The user may either set the priority to seven in the processor status word himself or he may use system routines to do so. The system provides two routines: IOF and ION to raise the priority to seven and lower it to its original priority respectively. These routines are called by JSR PC, @#IOF and JSR PC, @#ION respectively. These two routines must be executed as a pair and the user must take caution to avoid executing two consecutive IOF calls. (This will cause the system to be locked at priority seven.) 20 2. In general the user does not need to run at priority seven; however, he may wish to execute sections of code without being swapped out. He can do this by running at system priority three. This allows the system to perform normal I/O but will not allow the system to switch to another job. The user need not worry about informing the system about absolute pointers which exist only during PR3 execution, as the user cannot be swapped. a. Like the use of priority seven, the use of priority three should be restricted to short segments of code. Normally 50 to 100 instructions or less. b. Should the user need to execute large segments of code at priority three, he must inform the system when it is alright for him to be swapped. In general, if more than 1-2$ of a user's code is to be executed at priority three he should attempt to inform the system each time he returns to priority ' that he is available for swapping. This is done by simply executing an EMT .BREAK. If the system has another job requesting the use of the CPU it will switch to that job; if not, it will return immediately to the user job. c. Even though the user does not intend to execute his code at priority 3> he may cause the same effect if he does a great deal of disk i/o. When the user executes a disk i/o transfer, he is locked into his core. While the processor may switch tasks if there is another runnable task which is core resident, the job may not be swapped out. Consequently, programs doing many disk transfers should execute an EMT .BREAK periodically (~3-5 transfers) to allow the system to swap him out. 21 F. System Buffer Allocation 1. Some other operations require the use of buffers which remain in core even though the user may he swapped out. For this purpose the system maintains a pool of approximately 100 buffers which may be allocated to the user for short periods of time. All system buffers are 20n words in length and are allocated by calls to the system buffer allocation routine (see section IV. H). All buffers are allocated on 40n address boundaries. 2. When the system allocates a buffer to the user job, it loses all record of that buffer and depends on the user to return it when he has completed his work with it. Since it is possible for the student to cause the user job to be killed by typing a CNTL C (tC), users must be careful about the allocation and deallocation of system buffers. Special care should be taken to see that user jobs do not have system buffers allocated during I/O operations. G. Anchor Mode If for some reason it is impossible or impractical to write code which is dynamically relocatable, a user may specify that his code be run in 'Anchor Mode' which means that the system will swap him back to the same place each time he is brought into core. In order to run in Anchor Mode, the user must first execute an EMT .ANCHR (see section VI. A) and then cause himself to be swapped out so the system can position him (see example III.lj-). When a user no longer requires that he be anchored he should execute a .HOIST to release himself. Since the use of anchor mode works quite a hardship on the system, it should be avoided whenever possible. 22 ;This routine will anchor a 2K program at 30000. ; Since the program may have already been loaded ; elsewhere it is necessary to force the program ;to be swapped to the proper location. This can ;be done by increasing the size of the program ;and then decreasing it again. .ANCHR = lOlj-112 .CORE = 104056 HEGIN: MOV #30000, Rl .ANCHR MOV #2,R0 .CORE MOV #3,R0 .CORE MOV #2,R0 .CORE ;Anchor at 30000 > ;We should be at size two. ;Make sure we are. ;Now increase to size three ; forcing a swap. ;Now decrease to size ;two again. Example III. h Anchoring a Program 23 H. Named Code In order to allow the system to provide special assistance to selected programs, it accepts a name for a program which it may use to identify the type of job in progress. When a program begins execution, it may execute an EMT .NAME (see section VI. ). When the program executes a .EXIT, the name will be removed. This facility is useful when the system must service a user who may have terminated execution. By checking the existence of the proper name, the system can avoid damaging or unnecessarily servicing users. It is necessary that any new names be unique among the names known to the system. However, this is not a hardship since names are useful only when special service routines are included in the system and the names may be selected when the routines are written. Currently only the name DTAD0=1 is in use and is reserved for routines using DECtape service. 2k IV. File Handling A. File Operation All operations which concern the handling of data which is stored on the disk are file operations. In addition, ETS supports a number of non-resident functions which are also treated as file operations though they may actually have little or nothing to do with the filing system. The ETS filing system consists of a core-resident and a disk -resident portion. On disk are stored a number of special functions which may be called into core when needed. All file operations are carried out by allocating a system buffer, called a FIRQB, and placing the number of the requested function as well as any necessary parameters in this buffer. The user then places the address of the buffer in F&- and executes an EMT CALFIP. B. File Request Queue Block (FIRQB) 1. When performing file operations, the user must request a system buffer and load it with the proper parameters (see figure IV. l). This FIRQB requires the user's job number, FQJOB, and a function code, FQFUN (the system provides a routine to allocate the buffer and load these two words - see section IX. C). In addition, the user must supply any special parameters relative to the process he is using (see section IV.C). Generally, the system will return the FIRQB to the user on completion of an operation. The user may get any results which were returned in the FIRQB and should then return the FIRQB to the system. See example IV. 1. C. Available File Operations 1. EXTFQ is a routine to extend the length of a disk file. The user loads in FQFIL the channel index of the file which he wishes extended. In FQSIZ he supplies the number of 256-. _ word blocks to extend the file. If the disk is full, or no disk blocks remain, 25 Purpose Queue word for chaining requests Job # issuing request (*2) Function requested Channel index Error or message # requested from file Size of file to be created or number of segments to extend file New protection code Project -programmer number of UFD desired FILENAME. EXT in RAD50 Project -programmer number of second UFD FILENAME. EXT of second file Number of absolute loader blocks loaded Number of check sum errors encountered. Offset from beginning of user area to "relative 0" of file to be loaded EAD50 device name RAJJ50 device number Length of string to be parsed Absolute pointer to buffer containing source string to be parsed—string is in chained set of system buffers for SWIFQ (Note that FQJOB and FQFUN must always be supplied — all other parameters need to be supplied when actually needed. ) Figure IV. 1 FIRQB Structure Name Value Length (bytes) FQQQ 2 FQJOB 2 1 FQFUN 3 1 FQFIL k 1 FQERNO k 2 FQSIZ 5 1 FQPROT 5 1 FQPPN1 6 2 FQNAM1 10 6 FQPPN2 16 2 FQNAM2 20 6 FQBLCK 22 2 FQCKSM 2h 2 FQSTRT 26 2 FQDEV 30 2 FQDEVN 32 2 FQLEN 3h 2 FQPTR 36 2 BUFFER = k GETSML = 200 RETSML = FQJOB = 2 FQFUN = 3 FQFIL a k FQLEN = 3h FQPTR = 36 OPNFQ = 10 CSIFQ = 1+6 CALFIP = 101+050 REGREL = XX JOBORG = XX IOSTS = XX JOB = xx • STRING: • • .ASCII /fileab.ext/ STREND: .BYTE CHNNDX: .BYTE k .EVEN • • INCB @#REGREL+0 BUFFER GETSML MOV #STRING,RO AIJD @#JOBORG,RO MOVB (R0)+, (Rl+) + BNE .-2 BIC #37, R^ MOV Bk, -(SP) BUFFER GETSML MOV ' (sp)+,fqptr(rV) MOV #STREND-STRING, FQLEN (Rl+) MOVB #csifq,fqeun(ri+) MOVB @#job,fqjob(ri+) CALFIP MOV @#I0STS,R1 MOV FQPTR (Rif),-(SP) TST (HI), BNE ERROR MOVB CHNNDX, FQFIL (Rl+) MOVB #opnfq,fqfun(ri+) CALFIP TST (HI) BEQ OKAY ERROR: BUFFER RETSML OKAY: MOV BUFFER RETSML (SP)+,Rl+ Example IV. 1 Routine ' 26 ;Name of file to be opened ; Channel index - even # RO is relocatable Request a 16 word buffer Pointed to by ~Rk Point to file name relative offset Make an absolute pointer Store string in buffer a byte at a time Make Rl+ point to beginning of buffer Save Rl+ Get a FIRQB Store pointer to file string in FIRQB Store length of file string Load function desired Load our job index Call the file processor Get pointer to our I/O status Save pointer to file string buffer for later return Operation successful? No Yes - load channel index on which file is to be opened Set open function Call file processor again Successful Yes - FIRQB was not returned Failed - return FLRQB Get pointer to file string buffer and return it into a FIRQB and Open the File on Channel 2 27 an error code 12 (NOROOM) is returned in IOSTS. 2. DELFQ is a routine to delete an open file. The user supplies the channel index of the file in FQFIL. The user must be write enabled on the file in order to delete it. 3. CLSFQ is a routine to close an open file. The user supplies in FQFIL the channel index of the file he desires closed. h. OPENFQ is a routine to open a file. The user must supply in FQFIL a presently unused channel index. In FQNAM1 he must supply a three word file name which is packed RAD50. If the user wishes to open a file which belongs to a different project -programmer number he supplies the project -programmer which owns the file in FQPFN1. In order to open a file a user must be either read enabled, write enabled or the owner of the file. If the open operation is successful the FIRQB will not be returned to the user. 5. CREFQ is a routine to create a file. The user supplies in FQNAM1 a file name of the form FILNAM.EXT packed RAD50. In FQSIZ he specifies the length of the file which he wants created. A length of zero or one is created as a file of length one block. If a file of this name already exists in the user's UFD and the user is write enabled on that file, the system will delete that file and recreate it at its new length. 6. RENFQ is a routine to rename an existing file. The user supplies in FQNAM1 the name of the file which he wishes to rename. He supplies in FQNAM2 the new name of the file. The user must be write enabled on a file before he can change its name. If the file does not belong to the user's project -programmer number he specifies a project -programmer number of the file in both FQPPN1 and FQPFN2. 28 7« BYEFQ is a routine to log out a user from the system. No parameters other than the user's job number need be supplied. Before logging out a user, the system will close all his open files. BYEFQ does not return! ! 8. DIRFQ is a routine to return directory information on a file entry. The user supplies in FQPPN1 a project-programmer number of the directory with which he is concerned. All files in a given directory (UFD) are numbered sequentially beginning with zero. The user supplies in FQFIL the number (this is not a channel index) of the file on which he wishes information. If there exists a file corresponding to the number specified, the system will return the name of the file in the three words beginning at FQNAML. The system will return the protection code associated with the file in FQPEN2. It will return the date of the last access at FQNAM2, which will be immediately followed by the size of the file (the number of 256 ~ word blocks), followed by the creation date of the file, followed by the time the file was created. 9. FROFQ is a routine to change the protection code associated with the file. The user supplies in FQFIL the channel index on which the file is open. He supplies in FQPROT the new protection code to be assigned to the file. The user may not change the protection of a file unless he is either write enabled or the owner of the file. 10. EKRFQ is a routine to return an error message from the system error file. The user supplies in FQEKNO the error number which he would like to have returned. On return the system will pack the error message into the FIRQB beginning at FQKRNO. 29 11. LOAFQ, is the system relocating loader. The user supplies in FQFIL the channel index of the file to be loaded. He supplies in FQSTRT an offset from the beginning of the user area to the zero of the load file (a zero here causes the file to be loaded "with the load "0" corresponding to the beginning of the user area). On return the system supplies in FQBLCK the number of loader blocks loaded. This includes the six word start block. The system also returns in FQCKSM the number of checksum errors occurring during the load. 12. RSTFQ, is a routine to close all i/o channels except channel zero. The user needs no additional parameters. 13. CSIFQ, is a routine to parse DEV : FILE. EXT [X,X] . The user must allocate a system buffer and pack the string to be parsed into the buffer. He then places the address of this buffer at FQPTR and places the length of the string to be parsed at FQLEN. The system returns the RAD50 pack of any device name at FQDEV. The RAD50 pack of any device number is returned at FQftEVN. Independent of the presence or absence of a device name and device number, the system packs a string of up to six characters as a file name. They are packed RAD50 and placed beginning at FQNAM1. If there are less than six characters, the name is considered to be extended on the right with blanks to form a six character name. A file name may be followed by a three character extension to indicate its type. The extension is packed and stored at FQNAMl+ij-. It too is extended with blanks. Additionally, the user may specify a project-programmer number by enclosing it in square brackets ([k, 5])« The two numbers are considered as octal and must be separated by a comma. They will be stored in the two bytes of FQRFN1 — the first digit goes into the high order byte. 30 Ik-. SWIFQ, is a routine to parse a list of switches. The user must pack the list of switches into system buffers which may be chained together. He supplies a pointer to the first buffer at FQPTR. The first word of each buffer is then a pointer to the next buffer in the chain. The last buffer in the chain has a zero in its first word. The user supplies the length of the string in FQLEN. See figure IV. 2 for a description of a possible switch list. On return, the system returns the FIRQB in addition to the first buffer in the chain. All other buffers are returned to the system buffer pool. The buffer pointed to by FQPTR will contain the parse information for the switch list. Each of the possible switches is associated with two words in the buffer (beginning with the third word of the buffer, in order, as given in in figure TV.2). In the low order byte of the first word of any switch which occurs is stored an octal constant or the length of an arbitrary string which was the last parameter to the switch. Bits 8 through Ik indicate the presence of the parameters numbered 1 through 7 (in order as given by in figure IV.2). Bit 15 of the first word is set to indicate that this particular switch occurred in the list of switches. The second word of the switch list is a pointer, relative to the beginning of the string, to the beginning of an ASCII string which was a parameter to that switch. In case of an error return all buffers except the FIRQB will be returned to the system. Figure IV. 3 is a diagram of the buffer returned for a sample switch string. 31 |; j: op|cl|ee|pr|de|s6|s7 | :| : | : cn|ee|p3|p 1 +|p5|p6|p7 Figure IV. 2 The BNF Definition of a Switch List ASCII String Switch Presence Bits ASCII String Parameter Bits i — i I 1 i i 1 1 ; 23 1+6 j i i_ 55 IT 123 32 , — _ 1 i j i i i ! | 1 i |il ill! * i l | | | 1 | ! 1 , : — i 1 — 1 , 10 "M String Length Ik String Position 20 2h to Octal Constant 30 Constant Position 3^ = 0P:CW : P6;CL;RE : P3 :FILABC .EXT[ 1, 1 ] ^S6 ; 123; S7 : 12^ buffer position k 10 Ik 30 3^ 129 is not a valid octal constant, hence it is returned as a string length Figure IV. 3 The Buffer Returned on Parsing a Switch List 33 15- FNDFQ, is a routine to check if a given file or device is open and if so to return the channel index on which it is open. It is called by placing the name of the file at FQNAM1 or the device name at FQDEV with any device number at FQfEW. On return FQFIL will contain the channel index of the channel on which the given file or device is open. If the file or device is not open it will return an error lk- (NOSUCH). If the file or device does not exist it returns an error 22 (NOTOPN). D. Error Return When a specified file request fails to function properly it will return in the second word of the user's job data block an error code. The system variable IOSTS contains a pointer to this i/O status word. Figure II. 3 contains a list of possible error codes and an indication of their meaning . V. Input -Output A. General Principles 1. All device i/O in ETS is controlled by constructing a transfer control block (XRB) which contains all the necessary parameters for the desired operations (see figure V.l). There are four basic items which must be supplied: a. Buffer Address. The user places in the XRB in two places (XRPTR and XRLOC) the address of the buffer to be used in the transfer. The address is in the form of the relative distance from the buffer to the XRB (#XRB-BUF). The buffer must be in the user area proper. b. Transfer Length. On a read operation, the user places a zero in XRBC and the maximum length of transfer (in bytes) in XRLEN. On return, the system will put the number of bytes actually transferred in XRBC. On a write operation, the user places the actual write count in XRBC. c. Channel. All read/write operations must take place to a file/device which the user has successfully opened (channel zero is automatically open). The user places the channel index in XRCI. Before allowing the operations to proceed, the system checks the protection associated with a channel and aborts the operation if necessary. d. Parameters. Reading from the card reader requires that the user supply parameters to allow the service routine to perform the proper character translation. Parameters are supplies in XRPAR and XRPAR2 (see V.B.3). 35 R3 (Point) •z» XRB (Lnk) (Rel) (Len) (Tran) (Rel) (Chnnl) (Parm 1) (Parm 2) BUF Point = Lnk Rel Len Tran Chnnl Parm 1 = Parm 2 = Relative distance from start of job to XRB Monitor link word Relative distance (XRB-BUF) from XRB to i/O buffer Maximum length of i/O buffer Actual transfer count i/O channel for operation Parameter word Parameter word Figure V.l Transfer Control Block Structure 36 2. Once the user has set up his XRB, he places its relative address in R3 (distance from user "0" to the XRB) and executes EMT 52 (.READ) or EMT 5^ (.WRITE). 3- When doing i/O to a device other than disk, it is possible that all data is not immediately available; hence, the system vd.ll swap the user out of core to await physical i/O. This is not true for disk operations. B. i/O to a Serial Device 1. Line - Block Oriented Read Normally, on read operations, the system will attempt to supply the maximum possible number of characters, with two exceptions. a. Any read operation is terminated when an EOF is encountered on the source device. b. Line oriented devices will terminate a read after transferring a line delimiter (provided the delimiter is encountered before the maximum transfer is completed. 2. Papertape Reader - Papertape Punch The papertape reader and papertape punch do strictly block oriented transfers of binary data. All operations will terminate with either the maximum transfer length fulfilled or an EOF or EOM (End of Medium), Since leader and trailer tape look like perfectly valid binary data, the user must be careful when he wants to avoid processing undesirable 1 nulls ' . 3» Card Reader There are two types of transfers from the card reader: 37 a. ASCII Source Data. The user may specify parameters to the card reader driver which causes the first n columns to be ignored, or he may ignore the last m columns, or he may request that trailing blanks be suppressed, or any combination of the three. Figure V.2 details the parameters and their meaning. b. Binary Data. The card reader looks like the papertape reader where the top eight rows of the card correspond to the columns of a papertape (row 5 = bit l). The card reader will try to fulfill the read request before terminating the transfer. k. Line Printer The line printer accepts block transfers on output. No parameters are necessary where outputting to the line printer; however, it does do some special processing on output characters in order to provide formatting ability. a. A form-feed (ASCII code = Ik) is echoed as a page eject. b. A carriage return is ignored. c. A line feed is echoed as a line feed and a carriage return (the hardware does this). d. A tab (ASCII code = 11) prints as spaces up to the next eight space boundary (column eight is the first such boundary). e. Rubouts (ASCII code = 177) are ignoredo f. Vertical tabs (ASCII code =13) are ignored. g. All other characters print as themselves if they exist on the print drum. If they do not exist on the drum, the hardware 38 XRPAR XRPAR2 L5 87 First Last ? / ■7 Mode Suppress First - logical first column of card -1 Last - logical last column on card Mode = =>EBCDIC 1 =>binary data in top eight rows Suppress - =>suppress trailing blanks if in EBCDIC mode 1 =>do not suppress trailing blanks Figure V.2 XRB Parameters for Using the Card Reader 39 ignores then causing the counted line position to be one greater than the real line position. (Figure V.J is a table of characters on the print drum. ) h. The maximum line length is 128 characters. Attempts to print more than this number of characters will result in the 129th character being deleted and replaced with a line feed. 5. Teletype The teletype is a line oriented input device, but a block oriented output device. Because of the use of the teletype as a job control device, many input characters cause special processing to occur. With the exceptions in the special characters noted below, all characters cause their correct 7 bit ASCII code to be transferred to the user buffer. On output, characters for which there is no output character will echo as nulls. a. A carriage return echoes as a carriage return, line feed and inserts both a carriage return and a line feed into the user's input buffer. The carriage return is a delimiting character and will cause the job to be started if it is blocked awaiting a del im iter. On output, a carriage return does not echo a line feed. b. A line feed echoes as a carriage return, line feed but inserts only the line feed into the user's buffer. The line feed is a delimiter. On output, the line feed prints as a line feed only. c. CNTL C echoes as a tC and causes the user job to be aborted. The teletype buffers are flushed. The user will be returned to monitor mode. 1+0 , _ . _. • 1 bT o 1 1 b6 1 1 b5 1 1 lok b3 b2 bl Space @, p 1 i l A Q 10 it 2 B E 11 # 3 C S 10 $ k D T 10 1 i 5 E U 110 %-. 6 F V 111 t 7 G w 10 ( 8 H X 10 1 ) 9 I Y 10 10 LF * : J z 10 11 + 3 K [ 110 FF ) < L 110 1 - = M ] 1110 • > N >*v 1111 i ■ .. / ? V Figure V-3 Line Printer Character Set in d. CNTL B echoes as a tB and causes the termination of all echoes until the next tB is typed. No character is inserted into the buffer. e. CNTL echoes as atO and causes all programmed output to be discarded as well as any input -which is not a delimiter. The effect of a tO is terminated when the delimiter is read out of the input buffer by the user program. f. CNTL Q echoes as tQUIT and places a in the user buffer. Sets bit 15 of USRFLG. g. CNTL U echoes as a tU and causes the user input buffer to be flushed (throwing away the current line of input). h. CNTL Z echoes as a t Z and is given to the user as an EOF 'error'. i. A CNTL V echoes as a tV and puts a in the user input buffer; however, it sets bit zero of USRFLG. j. Altmode echoes as a $ and acts as a delimiter. No characters are placed in the input buffer, k. Rubout operates in two modes: (1) In tape mode (which is set via an EMT .TTAPE) it is discarded. Tape mode is for use in reading from an ASR paper tape reader and can be terminated by an EMT .TTRST. (2) In normal mode, it causes the last character in the input buffer to be fetched and discarded. Characters discarded are echoed in reverse order between two back slashes. 1. A tab echoes as spaces up to the next eight character boundary. A tab (ASCII code = 11) is inserted into the user buffer. m. A vertical tab echoes as eight line feeds and inserts a vertical tab (ASCII code = 13) into the buffer, n. A form feed echoes as eight line feeds and places a form feed (ASCII code = Ik) into the buffer. 1 42 Example V.l gives a sample program to input a character string from a teletype. Example V.2 is a sample message output routine. File I/O File operations involve all transfers to and from the disk. All such transfers involve exactly 256 nn words. Files in ETS are logically sequential, but they may physically reside anywhere on the disk. When a file is opened, a pointer (FCWLB) is set up to the first block (block zero) in the file. Each read/write operation causes this pointer to be advanced by one block. Before reading or writing to/from a file, the user must open the file (see section IV) on an available channel. On the disk, an EOF is generated anytime the user attempts to operate on a disk block which is not a part of that file. If the operation was read, an EOF indicates the end of the data; however, if the operation was a write, the system provides a function which the user may call to extend the file (EXTFQ, - section IV.C.l) so that the write operation may be repeated. Although most normal disk usage is of a sequential nature, ETS provides facilities so that users may perform random block access operations. This requires that the user know the logical block number which he wishes to read/write. To select a specific block, the user must place the block number desired in the first parameter word of the XRB and the channel on which the file is open at XRCI. He then places the relative address of the XRB in Rj5 and executes an EMT .FIND. If the request is for a non-existent block, the system will set bit 15 of the XRPAR on return. In such a case, +3 Reader is a routine to read a string from the TTY into an 80 character input buffer Call JSR PC, READER RO relocatable Return RO points absolutely to input string R3 contains byte count READER: MOV #XRB,R3 .READ MOV XRB+6, R3 MOV #INBUE,R0 ADD @#J0B0RG, RO MOV XRB+2, XRB+10 CLR XRB+6 RTS PC XRB: .WORD 0, INBUE -XRB, INBUE: .WORD .=.+120 r ;Read a string ; Store byte count in R3 ;Get absolute address of INBUE ;In 2 steps ;Restore XRB pointer ; Clear byte count ; Return ; Input buffer Example V.l A Routine to Read a String from the Teletype kh MESSAG is a routine to output a message on the TTY Call JSR R5, MESSAG + MSG Where R5,R0 are relocatable MSG is the assembly (0 relative) address of the message to be output. The first word contains the length of the message (in bytes). Return R0,R3 destroyed MESSAG: MOV ADD ADD ADD MOV MOV XRBW: MSG1: .WRITE MOV MOV RTS .WORD (R5)+,R0 R0,XRBW+2 R0,XRBW+10 @#JOBORG, RO (R0),XRBW+6 #XRBW, R3 #2-XRBW,XRBW+2 #2-XRBW,XRBW+10 R5 ;Get pointer to the message ;Set XRPTR in write XRB ;Set XRLOC ;Get absolute pointer to message ;Load byte count ;Get relative pointer to XRBW ; Output message ;Reset XRPTR ; Re set XRLOC ; Return MSG1ND' .ASCII MSG1ND: .ASCII .EVEN MSG2 : MSG2ND .ASCII MSG2ND: .ASCII .EVEN 0, 2 -XRBW, 0, 0, 2 -XRBW, -MSG1 - 1 /THIS IS THE FIRST MESSAGE/ A/ - MSG2 - 1 /ISN'T IT A BEAUTIFUL DAY/ hi Example V.2 A Routine to Output a Message on the Teletype ^ the present pointer to the file is unchanged. Example V.3 is a routine to read an arbitrary block of a disk file. D. Errors 1. EOF. An end-of-file (Error #26) is returned when a user tries to read/write past the end of a file or from a device on which an end-of-file separator is encountered. All errors are returned in the second word of the job data block which is pointed to by the system variable IOSTS. 2. NOTOFN (Error #22) is returned when the user attempts to perform an I/O transfer to an unopened channel. 3. PRTVOL (Error #2^) is returned when the user attempts to operate on a file/device which is protected from him. He may either be trying to access a file belonging to another UED which is protected or doing something brilliant like reading from the line printer. A PRIVOL error is also returned when a user attempts to write to a file which another user currently has open. h. NOTAVL (Error #20) is returned when the user attempts to get a device which is currently servicing another user. 5. DATERR (Error #32) is returned if there is a device malfunction or data error. 6. HNGDEV (Error #3^+) indicates that a device is not available to the system, e.g., it may be off-line. MS XRB: .WORD XRCI: .WORD XRPAR: .WORD BUT: .=.+1000 0, BUR -XRB, 1000, 0, BUF-XRB ;This routine will read the disk block specified in ;the variable BLOCK from the file opened on the ; channel given in CHNNL. Data will be placed in a buffer ;beginning at BUR. In case of error, the return is to ERROR. READER : MOV CHNNL, XRCI ? MOV BLOCK, XRPAR . MOV #XRB, R3 i .FIND '■> TST XRPAR ? BME ERROR 5 .READ 5 CLR XRB+6 > MOV XRB+2, XRB+10 MOV @#IOSTS, Rl 5 TST (Rl) 5 BNE ERROR J Set channel index for operation This is the disk block Set relative offset from start of job to XR] Point to the block we want Did we get it? No — either not a valid file or no such bloc] Yes — read the block Reset byte count for later try- Reset pointers for later use Get our i/O status Any errors Too bad Example V-3 Finding and Reading a Particular Disk Block V7 VI. Special EMT Functions A. .ANCHR (EMT 112) Anchor mode is used to allow programs to be attached to specific locations in core and to force the system to swap jobs into the same position in core each time (see section III.G). In order to operate properly, after a user has been achored, he must force himself to be swapped out so that the system will have a chance to reposition him. This is best accomplished by increasing his core allocation. The user places the core address (relative to the beginning of the user area) in Rl and executes a .ANCHR. This will place the user in anchor mode, but will not reposition him if he is not already in the correct position (this is handled by the monitor swap routines); therefore, the user should increase his core size which will cause him to be swapped out and brought in at the correct place. It Is the user's responsibility to see that his anchor request is a valid one (i.e., he does not want. to anchor a 2K job in the top IK of core). Also note that the necessity of increasing size prevents the user from anchoring a job to the highest core block. A user who wishes to anchor a IK job may increase his size to 2 to cause the swap and then reduce his size to the desired IK. Again note that anchor mode should be avoided if at all possible. B. .BREAK (EMT 66) When users execute long sections of code which may cause the system to fail to act on clock interrupts (e.g., many disk accesses), the user should inform the system that he can be swapped if there is another job ready to run. In general, users should return to the system after k or 5 "consecutive" disk accesses. The user does this by simply executing 48 a .BREAK. No parameters are necessary. This will cause the system to save the job and run the scheduler. If no other jobs are pending, control will return immediately to the user. C. .CORE (EMT 56) This is a call to the system core allocation routine. It may be called any time the user needs additional core or has core to return to the system. The core allocater is called by executing a .CORE with the size which the user wishes to be in RO. On return, RO will contain zero to indicate success. Requests for size zero are ignored. If the request is for more than the maximum possible size, the request is ignored. Size is counted in blocks of ^OOOo bytes. When the user wishes to return core to the system, the core will be removed from the end (higher addresses) of his job. He will not be swapped, and will return to execution immediately. When the user wishes to increase his size, the system will swap him out and the next time he runs, he will be brought in at his new size; thus, he must be swappable at the time of the EMT. Should he be locked in core at the time, results are unpredictable. D. .DAR (EMT 62) and .DAW (EMT 6k-) This is a routine to handle direct access disk requests. The user may read (write) to/from the disk without going through the normal read/write processor. To do this he must set up a pointer in Rh- to the File Control Block of the file he wishes to use (the file must be open in order to operate on it). Before executing the .DAR (.DAW) the user must place the relative core address for the transfer at FCETC(=l6) in the FCB; the number of blocks to transfer is placed at the byte FCBC(=2). FCNLB(=6) in the FCB points to the block number of the file for the operation h9 (the first block is block zero, each access causes FCNLB to be incremented by one). Before allowing the disk transfer to proceed, the system will still check to see that the user is permitted access to this file. (See example VI. 1.) E. .EXIT (EMT 76) This routine causes the termination of the user job. No parameters are necessary. The system will simulate the typing of a tC by the user. A .EXIT causes all I/O buffers belonging to the user job to be flushed, thus, terminating any i/o in progress by the job. When a routine must wait on the completion of some i/o before exiting, it should execute a .STALL then a .EXIT. F. .HOIST (EMT 11*0 A user who has been executing in anchor mode and no longer needs this facility should execute an EMT .HOIST to terminate anchor mode. No parameters are necessary and no damage is done if the user is not really in anchor mode. 0. .LOCK (EMT 60) and .UNLCK (EMT 10*0 .LOCK is used when a routine must not be swapped out of core for some reason (e.g., he wants to use the system loader). No parameters are necessary. The user should use .LOCK only when absolutely necessary and then must unlock himself as soon as possible. .UNLCK will free a user who is locked in core; it requires no parameters. Since the process jobs for lack of available core space, users are requested to execute a .BREAK after executing .UNLCK. Execution of a .LOCK when a user is already locked in core or a .UNLCK when a user is not locked in core has no effect. 50 START: IOSTS = XX JOBDA = XX FCETC = 16 FCBC = 2 CHOTL = nn BLKS • = nn * • MOV @#JOBDA, Rk MOV (■Rk),nk MOV @CHML(BiO,BA MOV #CORBUF, FCETC (R^) MOVB #BLKS,FCBC(R^) .DAE MOV @#I0STS,R5 TST (R5) BEE ERROR ; System i/O status pointer ; System pointer to job data "block ;FCB offset to core address ;FCB offset to # blocks to transf ; Channel index on which file is c ;Number of blocks to transfer ;Get pointer to job data block ;Get pointer to i/O block ;Get pointer to FCB ;Load relative core address for ;transfer ;Load # of blocks to be transfer! ;Read them in ;Get pointer to i/O status ;Any errors ;Yes ;No CORBUF: . = .+ 2000 ; Buffer for transfer ; Length = #BLKS*1000 Example VI. 1 Use of Direct Access Read - DAR 51 H. .NAME (EMT 116) A user may assign a name to a program by placing the name he wishes assigned in Rl and executing an EMT .NAME. When the user job terminated (either normally or via a system abort) the name will be removed. Names should only be used when informing the system that a user is executing a program which requires some special service on the part of the system. I. .STALL (EMT 102) It is sometimes a good idea for a routine to wait for a period of time before executing more code (e.g., it wishes to open the line printer which is currently in use). The routine may place a number of seconds to wait in Rl and execute a .STALL. This will cause the job to be blocked for the number of seconds specified. The use of .STALL is much better than sitting in a null loop since the user is not using CPU time. .STALL should also be used when the user wants to close a device which may be in the process of physical output. Since the close routine will cause a device's output buffers to be flushed, it is possible that output will be lost; consequently, a job that wants to close a device to which he has just finished output should stall for a few seconds before executing the close. (Figure VI. 1 gives suggested times for stalling for each device.) J. .TTAPE (EMT 7k) and .TTRST (EMT 72) Sometimes it is necessary to read paper tape through the low speed reader on the ASR-33 teletype. When the user wishes to do this, he would usually like to suppress the echo and ignore any rubouts on the tape. He may also wish to do the same processing for the input from the teletype keyboard. This type of transfer is called tape mode and may be reached by executing a .TTAPE. No parameters are necessary. A .TTRST is used to get out of the mode. .TTRST can also be used to kill any 52 Card Reader Line Printer Paper Tape Reader Paper Tape Punch Keyboard Teletype Printer no stall necessary 3 sees. no stall necessary 3 sees. no stall necessary l/lO sec/character /max number of output characters --to a maximum of 12 sec. Figure VI. 1 Suggested Stall Times for Various Devices 53 'no output flags' (e.g., tO typed on the keyboard - see section VIII. D). A .TTRST is useful when a program wishes to inform the user of some abnormal condition which may have arisen during a process which normally requires so much output to the teletype that a user may turn it off. K> .WAIT (EMI 70) A routine may sometimes desire to wait on the completion of some event (e.g., typing of a delimiter at a teletype). The system provides a .WAIT for this purpose. A .WAIT has the effect of causing the system to save the user's job and run the scheduler. If there is no other job ready to run, the effect of a .WAIT by itself is much like a .BREAK. However, the user may set a wait bit in the system control variable JBWAIT which identifies an event on which he wants to wait (see section II. C 6). If he then executes a .WAIT, the system will not restart him until the specified event has occurred (see example VI .2). L. .FIND (EMT 100) •FIND is used to position a disk file at a certain point (see section V.C). M. .TREAD (EMT 122) .TREAD is used to read from a teletype and if a response is not given in a specified time, the user program will be awakened. .TREAD is simply a .READ (pg k6) combined with a .STALL (pg 51 )• The user will be awakened when either is successfully completed. The user sets up the parameters as described for both a .READ and a .STALL and executes a .TREAD. When he is awakened, he may check the XRBC field of his XRB to determine whether he has received any input from the teletype. Note, that no input is transferred to the user program until a terminal character is typed on the teletype. ^ JOB = xx ;Byte containing user job index JSKEY JBWAIT = 20000 = xx ; Teletype delimiter blockage bit ;Wait table for user jobs MOVB MOV @#J0B, RO #JSKEY, JBWAIT (RO) BIC #jskey,jbstat(ro) .WAIT ;Get user job index - sign extend ;Set bit to wait on appearance of ; delimiter or TTY - Clear any other ;unit conditions ;Make sure we don't already have ;the bit set ;Go into wait - we will be ; awakened when the user types a ; delimiter on his teletype Example VI. 2 Setting a Wait Condition 55 VII. Use of Interrupts and Special Functions A. Interrupts ETS provides the user with two interrupt vectors which he may use as his own. TRAP (vector = 3k) and BPT (vector = Ik) are maintained by ETS as relocated pointers into the user area. Each time a user routine is saved, the contents of these two vector locations are saved with the relevant job information to he restored and relocated when the job is restarted. B. CNTL V (tV) Many times students will request the performance of special functions from a user job which will cause results they had not expected (e.g., lengthy interpretation). Since it is often desirable to stop the given process without killing the job (especially if the abnormal termination of the job can damage a file), ETS provides a character tV which can be used as a communication flag between the user and the running job. When a tV is typed at the user's teletype, ETS sets bit in the variable USRFLG which the running job should interrogate periodically. The job is responsible for clearing the bit to indicate to ETS that it has noticed it. The action taken on the occurrence of a tV is generally an abort of some type. The job may either return to the system or ask for input from the user to determine the reason for the tV. C. CNTL Q (tQUIT) With two exceptions, t Q, works exactly like tV. t Q, sets bit 15 of USRFLG, and by system convention, tQ, is a request by the user for the program to terminate its processing and return to the monitor via a .EXIT. 56 VIII. System Service Routines The following are routines which the system uses for some of its own processing, but which might be useful to users running under the system. The routines are compatible with a user's requirements of dynamic relocata- bility. In general, they may clobber one or more registers and will pass parameters in the other registers. It is the user's responsibility to save his own registers and to see that appropriate parameters are passed. Since the position of these routines is dependent on the version of the system in use, users are cautioned against running programs on separte versions of the system without checking the new definitions of the routine names. Example VIII. 1 uses many of these routines. A. SETDDB This is a routine to load the TTY Device Data Block address in Rl and the TTY line index in RO. While users may find little direct use for this routine, it is good for setting up parameters required by OCTIN and NAME IN. Call: JSR PC, SETDDB ;no parameters are necessary Return: ;R0 contains the TTY Line Index ;R1 points to the TTY DDB ;no additional registers are clobbered B. OCTOUT This routine will output the octal number in R5 onto the teletype. The number will be followed by a . In order to output the characters Jl = XX = XX = XX = XX = XX = XX = XX = XX = XX = 20000 = 10 = k = 1 = 10^050 = 1+ = Byte containing job index Blockage table Unblock table Register relocation System Routines and Variables Entry point for system error message handler TTY delimiter Open function Byte offset in FIRAB to channel index Invalid command error message EMT to call file processor I0T to buffer allocator Buffer return parameter @#T0B, R0 #JSKEY,JBWAIT(R0) #jskey,jbstat(ro) @#REGREL+5 FC,@#SETDDB R5,@#SETFQ 0PNFQ PC,@#NAMEIN ERR PC,@#0CTIN ERR R2 #-7-1, R2 R2,FQFIL(R^) @#I0STS,R2 (R2),R2 ERR1 Get Job index - sign extend Set blockage - we wait for the user to type a line And make sure we wait Begin wait Mark R5 as relocatable Load pointers to TTY DDB Get a FIRQB -* R^+ and load OPEN function Get a name and pack in FIRQB Didn't get a good one Get a channel number Didn't make it Convert to channel index Make it legal (0-7) Store it in FIRQB Try the open Get pointer to i/O status Get error code Error - too bad No error FIRQB was not returned #BADCMD, R2 PC,@#SIMESlf ; Choose our own error code ; Output error message - R2 contains # ; Return the FIRQB Example VIII. 1 Accepting a File Name and Channel From the Teletype and Trying to Open it 58 OCTOUT needs parameters set up and calls SETDDB to do it. Call: JSR PC, OCTOUT ;R5 contains the number to be output Return: ;R0 contains the TTY Line Index ;R1 points to the TTY DDB ;R2, R5 clobbered C. SETFQ SETFQ, is a routine to set up a FIRQB for use in file processor calls. SETFQ, allocates a system buffer and stores in it the user's job number and the function requested. Call: JSR R5, SETFQ + FTMFQ ;FUNFQ, is the FIP function desired ;R5 should be marked relocatable Return: ;R^ will point absolutely to the FIRQB ;R0 clobbered When the user has finished with the FIRQB, he must return it to the system. D. SIMESS SIMESS is a routine to retrieve a message from the system message file and output It on the teletype. There are two entry points to SIMESS, the first will request a message from the teletype for outputting. The second, and more useful, will accept a message code in R2 and output the corresponding message. 59 Call: JSR PC, SIMESS or JSR PC, SIMES4 ;a message code is supplied in R2 when using ;SIMES^ ;a message code will be accepted from the teletype ;when using SIMESS Return : ;R0,R1,R2,R4,R5 clobbered E. ENDTST ENDTST is a routine to determine if a character is a terminal. Terminal characters are , , , , or k Parm, 31 Parm List, 31 Parm String, 31 PRIVOL, k5, 10 Processor Status Word, 19 PROFQ, 28 REGREL, 9, 12 RELPTR, 15 RENFQ, 27 RSTFQ, 29 Rub outs, 37, kl Serial Device, 36 SETDDB, 56 SETFQ, 58 SIMESS, 58 Stack, 2, 15 Stack, Changing Size, 17 Stack, Data, 19 Stack, Overflow, 17 STKBAS, 17 SWIFQ, 30 Switch, 31 Switch List, 30, 31 Switch String, 30, 31 Tab, 37, hi Teletype, 39 Transfer Control Block (see XRB) TRAP, 55 UFD, 28 USRFLG, 11, 12, Ij.1, 55 Vertical Tab, 37, hi Wait Condition, ^h XRB, 3^, 36, 38, k2 BLIOGRAPHIC DATA EET 1. Report No. UIUCDCS-R-72-523 3. Recipient's Accession No. 5- Report Date May, 1972 Title and Subtitle ETS System User's Guide Author(s) Donald W. Oxley 8. Performing Organization Rept. No. Performing Organization Name and Address Department of Computer Science University of Illinois Urbana, Illinois 61801 10. Project/Task/Work Unit No. 11. Contract /Grant No. GJ-812 Sponsoring Organization Name and Address National Science Foundation Washington, D. C. 13. Type of Report & Period Covered Research 14. Supplementary Notes Abstracts This manual is intended to serve as a reference to persons who wish to write programs for use under the Educational Timesharing System - ETS. It discusses in detail the conventions and facilities used or supported by ETS. It assumes some familiarity with ETS and a thorough understanding of the PAL-11 assembly language. Key Words and Document Analysis. 17a. Descriptors Identifiers/Open-Ended Terms It COSAT1 Field/Group UAvailability Statement Unlimited Release 19.. Security Class (This Report) ,. - UNCLASSIFIED 20. Security Class (This Page UNCLASSIFIED 21- No. of Pages 63 22. Price 't'M NTIS-35 (10-70) USCOMM-DC 40329-P7 1 <*i/c >ar e m m m m Boat WWM '•};(:> m ■ Hi Hi