Compatible time-sharing system: A programmer's guide

The Compatible Time-Sharing System
A Programmer's Guide

The M.I.T. Computation Center

The M.I.T. Press
Massachusetts Institute of Technology

Cambridge, Massachusetts, 1963

Copyright © 1963
by
The Massachusetts Institute of Technology
All Rights Reserved

Library of Congress Catalog Card Number: 63-19793
Printed in the United States of America

Preface

This handbook is an attempt to document the techniques of using a current version (Model 13) of the compatible time-sharing-system (CTSS) which has been developed at the MIT Computation Center. It is primarily a manual of how to use the system, in contrast to many of the research memos, which have been more detailed in their documentation of the techniques of implementation. Because CTSS is basically a system which will allow an evolutionary development of time-sharing while continuing to allow more conventional background systems to operate, it is expected that the present manual will of necessity be revised many times before it reaches a final form. A good deal of the difficulty arises from, on the one hand, the rather drastic change in user operating techniques which time-sharing permits, and on the other hand the immense amount of programming required to fully implement the system.

The present work, although not highly polished, is being presented now to assist in this evolutionary process. It is expected to be a supplement to the Computation Center's Procedures Handbook which explains many of the general administrative details of the Center. Furthermore, a knowledge of programming is assumed of the reader. It has been our objective to present to an experienced programmer a reasonably complete manual which will allow him to use wisely the present version of the time-sharing system.

Because of the rapidity with which many of the features are being implemented, and the delays in distributing the inevitable revisions, some features are described here which are not yet accomplished. The reason for this is that it was felt to be important to indicate the intended scope and objectives of the system so that individual users could plan ahead in their applications. The features which are not implemented will be found listed in an appendix which will be revised periodically. In addition, each of the chapters can be expected to be periodically revised.

Since the present work is primarily a handbook, no attempt has been made to make any comparisons with the several other time-sharing and remote-console efforts which are being developed by groups elsewhere. The only other general purpose time-sharing system known to be operating presently, that of the Bolt, Beranek and Newman Corporation for the PDP-1 computer, was recently described by Professor John McCarthy at the 1963 Spring Joint Computer Conference. Other time-sharing developments are being made at the Carnegie Institute of Technology with a G20 computer, at the University of California at Berkeley with a 7090, at the Rand Corporation with Johnniac,and at MIT (by Professor Dennis) with a PDP-1. Several systems resemble our own in their logical organization; they include the independently developed BBN system for the PDP-1, the recently initiated work at IBM (by A. Kinslow) on the 7090 computer, and the plans of the System Development Corporation with the Q32 computer.

To establish the context of the present work, it is informative to trace the development of time-sharing at MIT. Shortly after the first paper on time-shared computers, by C. Strachey at the June 1959 UNESCO Information Processing Conference, H. M. Teager and J. McCarthy at MIT delivered an unpublished paper "Time-Shared Program Testing" at the August 1959 ACM Meeting. Evolving from this start, much of the time-sharing philosophy embodied in the CTSS system has been developed in conjunction with an MIT preliminary study committee (initiated in 1960), and a subsequent working committee. The work of the former committee resulted, in April 1961, in an unpublished (but widely circulated) internal report. Time-sharing was advocated by J. McCarthy in his lecture, given at MIT, contained in "Management and the Computer of the Future" (MIT, 1962). Further study of the design and implementation of man-computer interaction systems is being continued by a recently organized institute-wide project under the direction of Professor Robert M. Fano. In November 1961 an experimental time-sharing system, which was an early version of CTSS, was demonstrated at MIT, and in May 1962 a paper describing it was delivered at the Spring Joint Computer Conference.

As might be expected, the detailed design and implementation of the present CTSS system is largely a team effort with the major portions of it being prepared by the following: Mrs. Marjorie M. Daggett, Mr. Robert Daley, Mr. Robert Creasy, Mrs. Jessica Hellwig, Mr. Richard Orenstein, and Professor F. J. Corbató. Important contributions to some of the commands and the background system have been made by Mrs. Lynda Korn. Valuable criticism and advice has been offered by Professor Jack Dennis, Mr. J. R. Steinberg, and members of the Computation Center Staff. Mrs. Leslie Lowry, Mr. Louis Pouzin, and Mrs. Evelyn Dow have contributed to the preparation of the commands.

Special credit is given to Professor Herbert Teager for the design and development of his Flexowriter control subchannel which allowed the original experimental version of the present system to be developed, tested, and evaluated; only with such an opportunity was it possible to have the confidence to make the present pilot development of the CTSS system.

We should also like to extend our thanks to the Computer Center of the University of Michigan where Professor Bernard Galler, Mr. Bruce Arden, and Mr. Robert Graham have been very helpful in advising us on the use of their Mad Compiler in our time-sharing system. In addition, Mr. Robert Rosen kindly made available the Madtran editing program for processing Fortran II subprograms to Mad subprograms.

We should further like to take this occasion to acknowledge partial support by the National Science Foundation, the Office of Naval Research, and the Ford Foundation, of the development of our present system. We also add our appreciation for the support provided the Computation Center by the IBM Corporation.

Finally, we should like to encourage the readers of this handbook to examine the present system with a view toward improvements, and we shall welcome such criticisms.

F. J. Corbató

Cambridge, Massachusetts
May 1963

Introduction

The motivation for time-shared computer usage arises out of the slow man-computer interaction rate presently possible with the bigger, more advanced computers. This rate has changed little (and has become worse in some cases) in the last decade of widespread computer use.

In part, this effect has been due to the fact that as elementary problems become mastered on the computer, more complex problems immediately become of interest. As a result, larger and more complicated programs are written to take advantage of larger and faster computers. This process inevitably leads to more programming errors and a longer period of time required for debugging. Using current batch monitor techniques, as is done on most large computers, each program bug usually requires several hours to eliminate, if not a complete day. The only alternative hitherto available was for the programmer to attempt to debug directly at the computer, a process which is grossly wasteful of computer time and hampered seriously by the poor console communication usually available. Even if a typewriter is the console, there are usually lacking the sophisticated query and response programs which are vitally necessary to allow effective interaction. Thus, what is desired is drastically to increase the rate of interaction between the programmer and the computer without large economic loss and also to make each interaction more meaningful by extensive and complex system programming to assist in the man-computer communication.

In addition to allowing the development of usable and sophisticated debugging techniques, an efficient time-sharing system should make feasible a number of relatively new computer applications which can be implemented only at great cost in a conventional system. Any problem requiring a high degree of intermixture of computation and communication on a real-time basis should readily lend itself to time-sharing techniques. Examples of this type of application include: decision-tree problems; real-time management problems (airline reservations, hospital administration, etc.); gaming problems; sociological experiments; teaching machines; language learning problems; library retrieval; text editing; algebra manipulators; and many more.

The Compatible Time-Sharing System (CTSS) is a general-purpose programming system which allows a new form of computer operation to evolve and yet allows most older pre-time-sharing programming systems to continue to be operated. CTSS is used at a console which may be of several varieties, but which in essence is an electric typewriter. Each console user controls the computer (i.e. as seen by him) by issuing standard commands, one at a time. The commands allow convenient performance of most of the routine programming operations such as input, translation, loading, execution, stopping and inspection of programs. This command convenience, although it has a fixed format, is with no loss of generality since a command can also be used to start an arbitrary programming subsystem with its own control language level.

The consoles of CTSS form the foreground system, with computation being performed for the active console users in variable-length bursts, on a rotation basis, according to a scheduling algorithm. The background system is a conventional programming system (slightly edited for the time-sharing version) which, at the least, operates whenever the foreground system is inactive, but which may also be scheduled for a greater portion of the computer time. The entire operation of the computer is under the control of a supervisor program which remains permanently in the 32,768 word A-bank of core memory; all user programs are either kept in the 32,768 word B-bank of core memory, or swapped in and out of the disk (or drum) memory as needed.

Not only are the active user programs swapped in and out of the two secondary memory disk modules (4.6 x 10⁶ words each) and the drum (.2 x 10⁶ words) but it is expected that all console users will utilize the disk memory for semi-permanent storage of their active program and data files. Cards and magnetic tapes will still serve in secondary roles as long-time and back-up storage devices; they will be usable in CTSS only through the central Computation Center facilities and not directly through the remote user consoles.

Figure 1.1 is a system diagram of the 7090 computer at the Computation Center, which is to be converted to a 7094 Model 1 in August, 1963, with the addition of the 7320 drum at the same time. The motivation for the equipment configuration is described in the next chapter.

Figure 1.1 7090/94 System Diagram

History, Plans, and Current Status of System

Initially an experimental time-sharing system was developed using the special three-Flexowriter subchannel designed and built under H. Teager's direction. The first public demonstrations of this system were in November 1961, and the work was reported at the Spring Joint Computer Conference in May, 1962. During the latter half of 1962, in addition to refinement of the initial system, studies were made of how to remove several limitations in the system, namely: 1) the limited number of typewriter console stations, 2) difficulties of installing and maintaining remote connections, 3) lack of compatibility of operation with other 7090 programming systems, and 4) problems of information retrieval and information security associated with a large on-line secondary memory.

These studies resulted in plans for the conversion of the experimental time-sharing system to a pilot system which would be capable of operating simultaneously with most of the work load already handled by the 7090 at the Center. These plans for the 7090 included: 1) the implementation of the interrupt clock, memory protection, and relocation features; 2) the addition of an IBM 7750 communications channel which allows up to 112 Teletype consoles to be attached via phone lines at remote locations; 3) the addition of a second bank of 32,768 words of core memory; 4) the installation of the IBM 1301 disk file; and 5) the design and programming of a master disk control subroutine (memo CC-196) and an associated disk editor program (memo CC-208) for flexibility in using the crucial secondary memory. As separate experiments, two smaller computers are being specially attached to the 7750 channel by telephone line links: the Electrical Engineering PDP-1 is to be used as an experimental display console, and the Civil Engineering IBM 1620 will be used to control remote analog input-output equipment such as a pen plotter. All of the above equipment and attachments should be installed by spring, 1963, and the necessary programming adaptation required for the first pilot version of the time-sharing system is expected to be completed by summer, 1963. In fall, 1963, the addition of an IBM 7320 moderate-speed drum should further increase system performance by allowing somewhat faster secondary memory access and transmission speeds for swapping programs in and out of core memory, although the drum memory capacity is limited. At this time the general performance of the 7090 will be improved by upgrading it to a 7094 Model 1.

To implement effective operation of a pilot time-sharing system, the initial 16 Teletype consoles have been deployed as follows: two consoles for the Center system programming staff to assist in implementation and evaluation; one in the programmer consulting office to allow rapid assistance to users in the location of errors; one with the Center keypunch operators for service keypunching directly into the disk memory; one for the 7090 computer console operator; one for the 7090 tape-mount operator; one in Professor Minsky's research group for their applications and system evaluation; one in Professor Corbató's office for analysis, monitoring, demonstrations, and programming purposes; one more remotely located at Professor Miller's Civil Engineering Computation installation; and seven in an open pool for general time-sharing users at the Center.

One of the principal design features of the pilot system is that most older pre-time-sharing systems may be operated in the role of a background program simultaneously with the foreground time-sharing console system (memo CC-202-1). Because of the weakness of input-output memory protection in the 7090, it was necessary to develop an intricate input-output analyzer-monitor program for safe operation of older programs which had been developed without time-sharing in mind. Besides easing the programming transition problems of changing from batch processing to time-sharing techniques, this compatibility feature eliminates the necessity for immediately satisfying all of the Center's 400 research users (and a similar number of student users) with the initial version of the time-sharing system.

To achieve programming compatibility, the time-sharing system uses the same programming languages normally available in the major Center system, FMS: Fap, Mad, and Fortran in the form of the nearly equivalent Madtran (memo CC-188). Initial requirements dictated special core-memory-only versions of these compiler programs, but this restriction is being eliminated.

To contrast with batch-computing techniques, it is informative to summarize a typical time-sharing usage. A user has written a subprogram in a compiler language and wishes to incorporate it into his set of programs already developed and kept in the central disk file. After sitting down at a console, he first gives a login command to identify himself. His next command, input, turns his console into a pseudo-keypunch. Using simple conventions, he types in his subprogram for storage with other subprograms on the disk. If he should note any typing or logic errors in his new file, now or at any later time, he can correct the file using an edit command. (If he wanted to avoid the tedium of typing a long program, a suitably trained keypunch operator could just as easily have done the operation in advance.) Using an appropriate command the user can compile his subprogram, and if he has no diagnostics requiring correction, he can prepare to test it. Using the load command, he collects in core the newly compiled subprogram in binary form, any subprograms previously prepared, and the necessary library subprograms drawn from as many libraries as he wishes. If loading is successful, and does not require re-entry for the addition of missing subprograms, a start command initiates his program. He notes the results (if any) that he receives, and after stopping the program, if necessary, inspects the status of various locations and variables within the set of subprograms loaded. After a suitable amount of probing he detects his programming error, makes the necessary corrections, and continues in this manner until he wishes to terminate the session by giving a logout command.

To the above basic time-sharing system, which consists presently of a few dozen commands, many new features and additional commands must be added before it will be generally acceptable. Among the more important ideas are the ability 1) to request from the consoles large-scale delayed printing or punching of programs and cards at the central Center facility; 2) to create delayed graphical plots at the Center; 3) to allow foreground-initiated jobs to be run as background after a user leaves his console; 4) to assign by user request, for the duration of a console session, various input-output units, such as tape units, from the common central pool; 5) to allow inter-user console communication for activities such as management games; 6) to be more flexible and versatile in the allowable debugging techniques such as traces, interpreters, selective dumps, and so forth. Specifications for some of these features are described in later sections.

In addition to the obviously heavy programming development required for the above improvements, there are large operational questions which will need to be determined in the areas of reliability, error detection, programming system and hardware maintenance under conditions of near-continuous operation, automatic traffic and performance monitoring, and automatic accounting.

Finally, in the areas of hardware, there are evaluations to be made of the various consoles: the various model Teletypes, especially models 28 and 33, the Kleinschmidt 311 Teleprinter, the IBM 1050 Selectric typewriter, as well as possibly others. Vast questions lie in the area of self-maintaining display consoles, and finally questions of improved high-speed drums and future memory hierarchy schemes will need to be studied.

General Description and Usage Techniques

The foreground system is organized around commands, which each user gives at his console, and the user's private program files which are kept on the disk. For convenience, the format of the disk files is such that they have titles with name and class designators. (Files can be entered from cards or punched out at disk editing time.)

The Supervisor

The supervisor program remains in A-core at all times when CTSS is in operation. Its functions include: handling of all input and output for the consoles; scheduling of console-initiated (foreground) and offline-initiated (background) jobs; temporary storage and recovery of programs during the scheduled swapping; monitoring of all input and output from the disk, as well as input and output performed by the background system; and performing the general role of monitor for all foreground jobs. These tasks can be carried out by virtue of the supervisor's direct control of all trap interrupts, the most crucial of which is the one associated with the Interval Timer Clock.

The Interval Timer Clock is set for a small quantum of time, q. Every q seconds the supervisor can interrupt the program currently running in B-core in order to accept input from the consoles or to issue output to the consoles. If the input from a console is other than a command line, it is left in the supervisor's core buffers until it is read by the user's program (whether a command or a user-written program). If the input line is a command, it is given immediate priority and the supervisor, after dumping as much as necessary of the current B-core program onto drum or disk, brings in the requested command program from the disk.

Except for this initial top priority, the time-sharing programs are each run for a burst of time which is some multiple of q determined according to the scheduling algorithm. At the end of each program's appropriate time the supervisor determines which user is to be run next. It must then determine whether the program or programs currently in core must be dumped (to disk or drum), in part or entirely, to leave room in core for the next user. The next user must then be retrieved from secondary storage together with the proper machine conditions.

In addition to maintaining input and output buffers for each user console, the supervisor keeps a record of the status of each user. The status of a user may be: "working," where a program is ready to continue running whenever it is next brought in; "waiting command," where the user has just completed a command line at his console; "input-wait" or "output-wait," where the program is temporarily held up waiting to get a console line in or out; "dormant," where the program has stopped running and returned control to the supervisor, but machine conditions and the status of memory are preserved for inspection, modification, or re-entry; and "dead," where the program has terminated, control has been returned to the supervisor, and machine conditions and the status of memory have been scrapped.

It should be noted that command programs are handled in exactly the same manner as the user's own programs, with respect to status and scheduling. The background system is also considered another user; at present it has a different place in the scheduling algorithm, with permanently lowest priority. In addition there will be another type of background, consisting of batch jobs initiated from consoles but left to run without console interaction; these jobs will be run with exactly the same type of scheduling as normal foreground programs.

Command Format

The commands are typed by the user to the time-sharing supervisor (not to his own program) and thus can be initiated at any time regardless of the particular program in memory. (For similar reasons of coordination, the supervisor handles all input-output of the foreground system typewriters.) Commands are composed of segments separated by blanks; the first segment is the command name, and the remaining segments are parameters pertinent to the command. Each segment consists of the last 6 characters typed (initially an implicit 6 blanks). A carriage return is the signal which initiates action on the command. Whenever a command is received by the supervisor, "WAIT" is typed back. When the command is completed, "READY" is typed back. Where possible, the computer responses are in the opposite color from the user's typing. A command may be abandoned at any stage, including during the typing of the command line or during command output, by giving the "quit signal" peculiar to the console.

Command Initiation

A user starts a command when he completes a command line at his console and is automatically placed in a waiting command status. The time-sharing supervisor uses the interrupt clock feature every quantum of time to interrupt the user program being run and assign the users in waiting command status to a working status with an initial priority based on the size of the requested command program.

Program Termination

A foreground program leaves the working status by two means. It can re-enter the supervisor in a way which eliminates itself and places the user in a dead status; alternatively, by a different entry the program can be placed in a dormant status (or be manually placed there by the user giving a quit signal). The dormant status differs from the dead status in that the user may still restart or examine his program.

Input and Output Wait States

User input-output is through each typewriter via the supervisor, and even though the supervisor has a few lines of buffer space available, it is possible for a program to become input-output limited. Consequently, there is an input-wait status and an output-wait status, both similar to dormant, into which the user program is automatically placed by the supervisor whenever input-output delays develop. When buffers become nearly empty on output or nearly full on input, the user program is automatically returned to working status; thus waste of computer time is avoided.

Scheduling

In order to optimize the response time to a user's command or program, the supervisor uses a multi-level scheduling algorithm. The basis of the algorithm is the assignment of each user program, as it enters the system to be run (or as a response to a user is completed), to an ${\textstyle \ell }$th level priority queue. Programs are initially entered into a level ${\textstyle \ell _{O}}$ corresponding to their size, such that

$$\ell _{O}=\left[\log _{2}\left({\frac {w_{p}}{w_{q}}}+1\right)\right]$$

where ${\textstyle w_{p}}$ is the number of words in the program, ${\textstyle w_{q}}$ is the number of words which can be transmitted in and out of the high-speed memory from the secondary memory in the time of one quantum, q, and the bracket indicates "the integral part of". Ordinarily the time of a quantum, the basic time unit (currently about 200 ms.), is as small as possible without excessive overhead losses when the supervisor switches from one program in high-speed memory to another. The process starts with the time-sharing supervisor operating the program at the head of the lowest-level occupied queue, ${\textstyle \ell }$, for up to ${\textstyle 2^{\ell }}$ quanta of time, and then if the program is not completed (i.e. has not made a response to the user) placing it at the end of the ${\textstyle \ell +1}$ level queue. If there are no programs entering the system at levels lower than ${\textstyle \ell }$, this process proceeds until the queue at level ${\textstyle \ell }$ is exhausted; the process is then iteratively begun again at level ${\textstyle \ell +1}$, where now each program is run for ${\textstyle 2^{\ell +1}}$ quanta of time. If during the execution of the ${\textstyle 2^{\ell }}$ quanta of a program at level ${\textstyle \ell }$, a lower level, ${\textstyle \ell ^{\prime }}$, becomes occupied, the current user is replaced at the end of the ${\textstyle \ell }$th queue and the process is reinitiated at level ${\textstyle \ell ^{\prime }}$.

Change of Program Size

Similarly, if a program of size ${\textstyle w_{p}}$ at level ${\textstyle \ell }$, during operation requests from the time-sharing supervisor a change in memory size to ${\textstyle w_{p}^{\prime \prime }}$, then the enlarged (or reduced) version of the program should be placed at the end of the $\ell ^{\prime \prime }$ queue where

$$\ell ^{\prime \prime }=\ell +\left[\log _{2}\left({\frac {w_{p}^{\prime \prime }}{w_{p}}}\right)\right]$$

Again the process is re-initiated with the head-of-the-queue user at the lowest occupied level ${\textstyle \ell ^{\prime }}$.

Message Interaction Considerations and Usage Times

Because a user cannot "see" his program running, it is important that the programmer resort to appropriate cues and confirmation messages in his programming. Thus when input is expected, a good technique is to have the program first type out a message such as "type next data set" or "A=". Similarly after input it is often reassuring, if a long computation is required, to see some program output acknowledging the receipt (and perhaps the accuracy) of the input message.

The reply response time is governed by the basic scheduling algorithm described earlier and depends on the number of other users. In the current implementation of the algorithm a user-computer interaction consists of the period from an input message to an output message. Although the response time is only a few milliseconds if the user's program is already in core, whenever there is more than one user the usual minimum time for a response, which is the minimum computer usage time per response, is (in the current drumless system) approximately ${\textstyle S/8}$ seconds plus the response computation time, where ${\textstyle S}$ is the number of program words in thousands. For example, eight different user programs, of one thousand words each, could simultaneously respond within a second to input messages requiring only negligible computation.

For those interactions which require non-trivial computation, the computer usage time is approximately given by the sum of two series, the first of which is for the computation:

$$T=\sum _{i=0}^{n}\left(2^{i}{\frac {S}{8}}\right)+\sum _{i=0}^{n}\left({\frac {S}{8}}\right)\mathrm {sec.}$$

where the ${\textstyle n}$th term of the series is that just necessary to complete the computation. As can easily be seen, in the limit of large computations the ratio of usage time to computation time asymptotically approaches one.

Storage Allocation

Presently only one user program is kept in core memory at a time. However, in order to improve response time, as many user programs as possible should be left in core memory. When required, as much as necessary of the lowest priority program in the scheduling algorithm may be moved to the disk (or drum) memory to make more core memory available. Because of the relative slowness of the 7320 drum and the 1301 disk transfers, moving program segments about in core is an effective way to consolidate space into which to read the user program next to be run. Thus the swap time required to give a response to a user will be only that dictated by the size of his own program. To carry out this procedure, several storage allocation algorithms are under consideration.

Although other possibilities exist, as in the Atlas Computer, initially no attempt will be made to operate any user program unless all of its program segments are contiguous and sequential in core memory. Also the possibility exists of performing a look-ahead operation of swapping a user program in or out while operating another user program (i.e. multiprogramming). Again, initially no attempt will be made to implement the look-ahead feature, since the effectiveness is seriously reduced if scheduling changes (i.e., program completions) are frequent, or if there is frequent competition with the operating program for use of the drum or disk channel.

Memory Protection and Relocation

To avoid fatal conflicts between the supervisor and multiple users, the CTSS IBM 7090/94 includes a special modification which behaves as follows:

Core memory is considered to be divided into 256-word blocks. There are two 7-bit protection registers which, when the computer is in the normal mode, can be set by program to any block numbers. Whenever a user program is run, the supervisor, as a final step just before transferring to the user program, switches the computer to a special mode such that if execution of any memory address outside the range of the protection register block numbers is attempted, the normal mode is restored and a trap occurs to the supervisor.

There is also a 7-bit relocation register which modifies every memory address, during executions, by addition of the relocation register block number. Thus programs which have been interrupted by the supervisor may be moved about in memory, if necessary, with only the proper readjustment of the relocation register required.

Finally, if the user program, while in the special mode, should attempt to execute any instructions concerning input-output, changes in mode or core bank reference status, or resetting of the protection or relocation registers, the normal mode is restored and a trap occurs to the supervisor program in core bank A.

User Communication with the Supervisor

The supervisor performs a number of control functions which may be directly requested by the user. These include: all input and output (e.g., disk, drum, consoles, tapes); requests for information about or extension of the user program memory allocation; simulation of floating trap; control of each user's status, input level, and input mode; and other functions which involve communication with, or control by, the supervisor.

Since all protection violations cause a trap to the supervisor, a convenient means of user-supervisor communication is for the user to cause a protection violation; if the violation conforms to an established convention it may be recognized as a call to a subroutine in the supervisor. Since the supervisor is in A-core at all times, and since the user is in B-core operating in the protection mode, the following convention is used:

      TIA   LOC
LOC   BCI   1,NAME

(or equivalently, TIA =HNAME) where NAME is the BCD name of the desired subroutine; the attempted transfer from B-core to A-core causes a protection violation.

In the future, should memory space in the supervisor region be available, some commonly-used library subroutines may be kept in this region and reached via dummy subprograms which issue the appropriate supervisor call

Time-Used Messages

Since usage time and computation time are different from real time, the user may periodically want to know how much computer time he has used. He may request from the supervisor a message of the following form:

MIN. USED = 12.070 + 2.005 IN 24.011 + 5.725

In this example, the user has logged 2.005 minutes of computer time since he last requested a time message, which was 5.725 minutes (real time) ago; at that time he had used 12.070 in 24.011 minutes; he has now used a total of 14.075 minutes since he logged in 29.736 minutes ago. Comparison of these sets of figures affords an estimate of his rate of service.

The time-request is made by typing in a special message at any level of console input; the message convention is initially set to "TIME" followed by carriage return. If the user wishes he may by use of the time command either change the time-request message to another set of characters or discontinue the facility altogether.

Interval Timer Clock

To facilitate running programs for a limited amount of time, the CTSS IBM 7090/94 has an interval timer clock available. This clock is completely under control of the supervisor; its action is as follows: location 5, memory A, is incremented in the units portion every 1/60 sec; whenever it overflows on a count of 2³⁵, an interrupt occurs which, if the clock is enabled, causes a trap to location 7 and the trap location to be stored in location 6.

The supervisor uses this clock both for interrupting programs and for time accounting. Base-time and day-of-the-month information are obtained from the on-line printer clock. The supervisor can, however, simulate the interrupt clock behavior for each user. By supervisor calls similar to those of MITMR (memo CC-193), the user can program for nested interrupts and computation time readings.

Break Characters

Whenever a user types into his console, regardless of whether his program is running or not, the input character is received at the supervisor level within 200 ms. The supervisor compares the character against the break character list of that user. (In routine circumstances, and after every command, the break character list includes only the carriage return.) The input character is added to the user's input message and if it is not a break character, no further action is taken. If the character is a break character, the message is called complete and one of several actions results.

If the user input was at the command level (i.e., the user was in the dead or dormant status), he is placed in a waiting command status. If the user's program was in an input-wait status, it is returned to the working status so that it may resume by reading the input message. If the user's program was already in the working status, the message is merely considered early and is left in the buffer for subsequent reading by his program. (If early messages continue to arrive and the input buffer area becomes nearly filled, a message is typed out to the user requesting that he stop typing until his previous input is read.)

If a programmer desires to interact more frequently with input messages (including character-by-character reading), any arbitrary break character may be added to and deleted from his break character list by means of subroutine calls to the supervisor. The programmer, however, should anticipate response time delays and the extra computer time usage for each interaction.

Quit Signals and Console Input Levels

When a user issues a command, two actions are initiated. First, his console input level is logically dropped from level 0 (command level) to level 1; second, a program is started (i.e., placed in working status), either the command program or his own, which executes until it terminates and enters dead or dormant status, or until the user manually terminates the program and places it in dormant status. Clearly this manual quit feature is desirable in that it allows the user to change his mind, correct mistakes, etc. The termination is performed by the user's issuing a single quit signal (varying with the console type) which may be issued even if the console is typing out. Upon issuance of the quit signal, the user's console input level is raised by one, normally back to level 0.

In addition to this basic two-level scheme, it is possible for the user to extend the number of input levels, thereby allowing for program subsystems, each with its own control language (e.g., for debugging). This is accomplished by the program giving subroutine calls to the supervisor, which on each entry drops the user console a level (to a limit of level 3). Whenever a quit signal from the console is received by the supervisor, the user's input level is raised by 1 (but no further than level 0); control is returned (by means of a push-down list) to the subsystem entry point previously assigned by the program to the current level, or finally, after the right number of quit signals, to dormant status.

Character Mode Switch

For routine computer work, especially older applications, the normal 7090/94 BCD character set is sufficient for console messages. This set consists of 47 characters and blank, augmented by a few console control functions, namely: carriage return, tabulation, back space, color shift, delete-last-character, delete-last-message, and ignore; this normal BCD set is contained in a 6-bit code. When the character mode switch of a console is set to "normal", a console will transmit in the normal BCD mode.

The user's program, however, by issuing specific subroutine calls to supervisor entry points, may change the character switch to the "full" setting which, by means of a 12-bit character code, allows the user precise knowledge of console input as well as full flexibility upon output. Whenever a user program is completed and the supervisor is receiving input from a console at the command language level, the character mode switch is automatically restored to the "normal" setting.

Consoles and Character Sets

Each type of console attached to CTSS has associated input-output mapping tables (Figure 3.1) for both the 6-bit and 12-bit character codes. (The high order 6 bits will be referred to as logical case bits.) In addition each console has a particular quit signal technique. All characters are interpreted individually; hence any combination of legal characters may be used in a message. In particular, the physical case is automatically kept track of on both input and output, so that the user need not program physical case shifts.

In the case of 6-bit normal BCD mode input, characters which do not map into normal BCD characters or functions are enclosed in parentheses on the following chart and are ignored on input. The 6-bit normal BCD mapping is obtained by deleting the 6 high-order case bits. In a l2-bit mode input, all characters are coded and kept in a message.

In the case of console output, in the 6-bit normal BCD mode, logical case 0 will be used, while in the full 12-bit mode, all characters will be printed as specified with unused codes being ignored. After all output messages, the console physical case will be restored to its previous case before output, except for the IBM 1014 and 1050 Selectric typewriter consoles, where lower case will be restored after output.

When using Model 28 Teletype consoles, the quit signal is generated by depressing and relasing the break key. There are no backspace or color shift functions available.

When using the IBM 1014 Selectric typewriter consoles, the quit signal is generated by the sequence of: inquiry request, "#," inquiry release. To initiate each line of input, the inquiry request key must be depressed. If the check light comes on from typing too fast, inquiry cancel must be given and the line reinitiated. Inquiry release acts as a carriage return signal. The color shift function automatically reverses between input and output and is not codable. The only break character possible is carriage return. Type balls may be changed by a chball command. It is not possible to input a non-printing message, hence when it is desired to issue a carriage return with no message, the character "π," which is always ignored, is issued before the carriage return.

When using the Flexowriter consoles, the quit signal is generated, if there is no output typing, by the following sequence: depressing and releasing "code delete" (a lever above the keyboard), followed by a carriage return. If there is output typing, instead the red button on the control box in front of the keyboard must be depressed once. At present these consoles are only implemented for a single break character of carriage return.

Code Table Conventions, Figure 3.1

12-bit mode
input to the user program	In the columns for the appropriate console, the keys with the characters or control functions indicated, when depressed, generate a logical case and 6-bit code as a single 12-bit code. A keystroke causes no CTSS control action, with the exception of a break character or quit signal. In the case of the quit signal, no code is transmitted to the program.
output from the user program	The character or control function corresponding to the logical case and 6-bit code in the columns under the appropriate console is typed out. If there is no character shown for the code, nothing types out.
6-bit mode
input to the user program	In either of the columns for the appropriate console, depression of a key with an indicated character or control function produces the corresponding 6-bit input code; if a character or control function is enclosed in parentheses the character is ignored and no input code is produced. In the case of the delete-character (d.c.), delete-message (d.m.) and quit signals, no code is transmitted to the user's program and instead the appropriate control action is taken. All other characters or control function codes are transmitted to the user's program. (The end-of-command character (e.o.c.) is generated by CTSS as a terminal flag to mark the end of the command parameter list.) It is not possible to input to a program the codes for which there are blanks in the column labelled "7090 program input."
output from the user program	The character or control function corresponding to logical case 0 and the 6-bit code in the column under the appropriate console is typed out. If for a code there is no character or control function indicated in the column labelled "7090 program output," the code will be ignored; for uniformity and future compatibility, it is recommended that the standard "ignore" code be used if this effect is desired.

Special Input Modes

To anticipate noisy console lines, especially for future remote or dialed connections, a confirmation mode will be available. In this mode, every input message (i.e., up to the break character) will immediately be copied back as an output message. If a user detects a garble he should issue a quit signal or take whatever action he has anticipated in his program.

When a person is working closely with his console at the command level, it will be possible to enter a brief mode. All programs which have been properly prepared will be able to interrogate the brief mode status indicator and to adjust the verbosity of their output accordingly. Both the brief and confirmation modes are set by the use of a command.

Interconsole Messages

Any user console can send a message to another user console by subroutine calls to the supervisor. These messages are placed in an input message pool for the receiving user along with the user number of the sender. The receiving user program can read its message pool at any time by a supervisor call similar to that for reading its own input console; an input-wait status can occur if no messages are present. If a receiver fails to read or acknowledge a message this is assumed to be intentional. The user number of another console must be determined by supervisor subroutine calls which give the desired user number on the basis of the console location, problem number and/or programmer number.

Disk Memory Control

For a good understanding of the disk control subroutine, the following list of considerations concerning the use of the disk may be helpful.

1. The user is able to write and maintain permanent program and data files on the disk.
2. System programs (commands and standard library) are permanently recorded on the disk.
3. The user has only symbolic reference to his files.
4. The user is able to read and write many files simultaneously, and, for the sake of efficiency, may specify in which logical module a new file is to be written. In this way much unnecessary seek time may be avoided by using two separate modules for a simple read-write operation.
5. The user is not able to reference any files not authorized to him.
6. The user is able to initiate files in different modes, such as temporary files, permanent files, or permanent read-only files.
7. In order to utilize the maximum storage capacity of the disk file and to be compatible with any future I.B.M. programs using the disk, Format 1 (i.e., a single record per track) is used.

A high level of user information protection can be achieved using the 1301 disk unit with the CTSS 7090. Complete protection is maintained (up to machine error and user identification errors) of all information on the disk unit. All users and systems use a single standard supervisor subroutine for reading and writing the disk. Because of the input-output trapping and memory protection features, mishaps will not occur if the user executes wild transfers, tries to store spurious information in the subroutine, or tries to execute explicit instructions for writing the disk.

It is desirable, from the point of view both of programming and of disk administration, that the user have no notion of the absolute location where his files of information are stored in the disk. Rather, the user will refer to his files only by symbolic names and logical module number. Furthermore, if the user does not specify the logical module number, it will be assigned for him by the subroutine. Each of the user's files has two names; commonly the second name is descriptive of the type of file, as "FAP," "DATA," "BSS," etc. Each name is at most six BCD characters long; the characters may be any alphanumeric characters, but special characters should not be used; the special characters are used to distinguish the names of certain files created for the user by the supervisor.

Normally different programmers on the same problem are treated as different users. To allow convenient cooperation between programmers, such as students in classes or group projects, there is a feature which makes it possible to have files common to several different programmers with the same problem number. To gain access to these common files (referred to by programmer number zero) a special supervisor call must be given which places the user in a "common file mode;" another supervisor entry allows the user to return to the normal "personal file mode." More elaborate cross-referencing of files can be accomplished by the link or copy disk editor control cards described in Chapter 5.

Organization of the Disk Memory

When the user initially requests use of CTSS in his Computation Center Problem Application Form he may also request the allocation of a number of tracks on the disk. If none are requested, an initial allotment will be made automatically which may later be extended by request. The track allocation information is kept on the disk in the master file directory of all users, which in addition contains the location of each user file directory. A track usage table is also maintained on the disk.

Each user has on the disk a user file directory (UFD) which contains a 4-word entry for each of his files. The first two words contain the file name and class name of the file. The third word contains the mode of the file in the prefix, a document number (a number assigned internally to each file, for tracing and retrieval purposes) in the decrement, and the address of the first track of the file in the address and tag. The fourth word contains the number of tracks used by the file in the address, and the date the file was last used (day, month, and last digit of year, coded as MMDDY, in octal) in the decrement.

If the user exceeds his track quota while writing a file, there will be an automatic temporary extension of his quota. This will allow him to complete any file he has begun; it will also allow for the automatic dumping of his machine status in case of system shut-down (see "System Service Changes and Supervisor Messages"). As soon as the track quota is exhausted the supervisor will notify the user of the fact. The extension will be maintained when the user issues logout. When he next logs in, he should relieve the excess in his track quota by adequate deletions. Should he fail to do this, a sufficient number of his oldest files will automatically be dumped at the next disk editing to restore his track quota to normal; the procedure for dumping these files will be similar to that for over-age files (see "Disk Editing Procedures").

Keypunching and Card Input to the Disk

Normally, it is expected that casual program writing, editing and data generation will be done directly from the user's console. Even for the case of long programs which are too tedious for the programmer to type, a trained typist can still type the program directly into the disk memory. However, for various reasons such as distance, convenience, or exchange with other computer centers, it is still sometimes necessary to input punched cards. In this case, input cards must be brought, with an appropriate control card, to the Center Dispatching Area for entry into the disk during the disk editing period, which occurs at least once a day.

Delayed Output and Disk Editor Control Cards from the Console

Normally, a programmer will find it more convenient to maintain brief but frequent interactions with his program through his console, but there will be occasions when large-scale output is desired. This output may still be obtained via the Center 1401 computers in the form of printing, punched cards, or pen plotting, by the user's issuing appropriate delayed output commands. The output files must be stored by the user on the disk in appropriate formats. The delayed output commands initially will cause appropriate disk editor control cards to be generated by the supervisor and automatically inserted in the disk editing procedure; thus the delayed output occurs at disk editing time. The user can also by appropriate commands or supervisor calls generate other disk editor control cards to be entered into the disk editing process.

Disk Editing Control Cards

Periodically, requests will be processed by the Center Staff for input to the disk from cards and for output from the disk, either printed or punched. Control cards are submitted to the Center Dispatching Area which specify these requests. A variety of operations, specified by control cards, may be performed at disk-editing time, including, in addition to off-line input and output: editing of a binary program onto the disk; deletion of a file, with or without punched-card dumping; changing the mode of files (in particular of "read-only class 2" files); copying a user's file for another user; and linking several users (i.e., giving them access) to a particular user's file.

Disk Reliability, Malfunctions and Recovery

The 1301 disk memory is expected to be quite reliable - more so, for example, than tape - but to date enough information has not been gathered to offer any definite appraisal of its reliability.

During times when CTSS is not in operation, the disk may on occasion be used by other systems. For this reason, as well as to protect information from loss due to malfunction of the disk, the contents of the disk are dumped onto magnetic tapes as needed and at least once a day. These tapes are used to reload the disk at the same time that any requests for new input to the disk are being processed. Disk dump tapes are written in duplicate to safeguard against tape errors. Dump tapes will be kept for backup purposes for several days, and a set of dump tapes will also be preserved from certain fixed points in the past (e.g., week-old, month-old, three-month-old, etc.). Thus if any information on the disk should be lost or garbled, any or all user files could be restored to the status of an earlier day.

For example, were the entire contents of the disk to be erased, the last set of dump tapes would be used for reloading, and the loss confined to less than twenty-four hours worth of new information. (This is not expected to happen since erasure does not occur easily and the disk normally retains all information in case of power failure.)

If both sets of duplicate dump tapes were to prove unreadable, the loss would be no greater than twenty-four hours, since the preceding day's tapes would be available. If the dump tapes were being used to restore information after disk loss, and both sets of tapes were unusable (an unlikely concatenation of misfortunes), the loss would still be confined to forty-eight hours since an earlier day's tapes would be available.

If an individual user's file is lost or garbled due to undetected failure of one or more disk tracks or to undetected tape error, the single file could be retrieved from earlier dump tapes either in earlier form or precisely, using the document number of the file for confirmation. If the user does not reference the file very frequently, however, it is possible that he might not ascertain the error until, say, a week after the loss occurred, and it might not exist on any older backup tape. Consequently, as with every type of information storage, it behooves the user to take his own precautions concerning valuable files.

Disk Editing Procedures

Despite the rather large capacity of the IBM 1301 disk modules for secondary storage they are still capable of being filled by various means, from runaway programs to careless user file "housecleaning." To minimize the latter effect, each user is assigned an initial but usually adequate track quota, which can only be extended by a formal request to the Center. Furthermore a technique is used of automatically displacing, from the disk secondary storage to magnetic tape tertiary storage, those user files which have been unused and inactive for several weeks. These tertiary storage tapes will be created in duplicate each week and will be called history tapes. History tapes will automatically be erased after six months. No direct notice of file displacement will be made to each user; rather each user, upon examining his file directory, can by inspection see which files are still on the disk. Any attempt to use a displaced file will result in a console message to the user.

The above history tape procedure represents a compromise between automatic information disposal and the convenience of the user. The procedure which is illustrated in Figure 3.2 is done in conjunction with the normal disk editing procedures of dumping and loading the disk (at least daily).

Figure 3.2 Diagram of Disk Editing Procedure

The first phase of the procedure starts with the 7090 dump editor and 7090 dump control cards being recorded on magnetic tape via the 1401 to run as a standard 7090 FMS job. The job first processes control card files left on the disk by the time-sharing supervisor, and then the input tape control cards, before producing the requested dump tapes. In addition, the current history tapes are extended by the over-age files and any files which the user has asked to be deleted; corresponding file directory entries are marked along with the date dumped and the history tape position. Finally, the dump program produces an output tape for the 1401 of output requested by the dump control cards, both those submitted directly and those generated from consoles. This output consists of: BCD printing, BCD and binary cards, prefix-7 binary cards (for convenient and safe reloading of the disk), and those remaining control cards not acted upon which were produced at the consoles and left by the supervisor. The latter control cards, which may include requests to restore to the disk some files which have been displaced to the history tapes, are sorted for systematic retrieval in the next editing phase. Requested disk output of all forms will be kept at the Center for a period of only 2 weeks before being disposed of. During this time, it is the user's responsibility to pick up his output at the Center.

The second phase of the procedure is that of loading the disk. The load-edit program is placed in the 1401 card reader, along with the control cards produced by the 7090 dump-edit program, as well as those load-control cards and input card decks submitted to the Center Dispatching Area. Input card decks, after they have been used by the edit program, will be placed in the Output Request Section of the Center and have a similar 2-week lifetime before disposal. By means of a special 1401 program, the above input is used to write a 7090 input tape which includes those files requested from history tapes. The latter is accomplished by the 1401 load-control cards produced by the 7090, which log on the 1401 printer giving the 1401 operator detailed instructions on the mounting and dismounting of history tapes. Finally the 7090 load-edit program, with input data, is run as a standard FMS job, where the input edit data and the previous disk dump tapes form the input.

The user will be able by a retrve command to retrieve his file from a history tape and replace it on the disk while at his console. This command will first give the user an estimate of the minutes of 7090 computer time required to position the appropriate history tape; if the user wishes to continue, the command will carry out the retrieval using the attach command; otherwise the user is free to create a 1401 load-edit control card such that the desired file will be entered into the disk at the next disk-edit period.

System Service Changes and Supervisor Messages

Normally the CTSS system will operate for scheduled periods in blocks of time during each day. System operation will commence with messages typed on all consoles that are on (or can be remotely turned on and off) stating that the system is on and at what time the system will cease to operate again.

When the CTSS system is shut down, either on a scheduled basis or an emergency basis, the following procedure occurs. Each active user ceases to run, a cutoff message is sent to his console, all files are closed, all attached input-output units are disconnected, the user's program is created as a file of name cutoff with class saved, the user is given a logout command, and a message is placed in the user's console message file on the disk giving a summary of the cutoff process including the unread characters in the console input buffer.

Whenever there are individual or general disk failures as well as system changes of great importance, appropriate messages will be placed by the supervisor in each of the user console message files. A console message file (named "MESSAGE.FILE") is created for the user when necessary and is normally typed out by the login command, at which time it is deleted. During operation of his console, additional messages nay be generated; a user can read his console message file at any time with the printf command, which will not delete the file. The console message files, which are created by the supervisor, use disk tracks of the user's quota.

For writing message files and for saving the user's program at the time of a system shut-down, the supervisor may have to take advantage of the feature which allows an extension of the user's track quota (see "Organization of the Disk Memory"). In this event the user should, the next time he is at a console, relieve this condition by dumping some of his files, or else older files will be dumped automatically for him at disk editor time. If at shut-down time the user himself has already exceeded his quota, no further extension will be allowed; his machine status will be lost and so may his message.

Assignment of Input-Output Units

There are numerous devices such as tape units, scopes, plotters, satellite computers, etc., which are of such a nature that it is desirable to assign them to a single user for his session at his console. This assignment is done by means of an attach command, where the user may receive a busy signal whenever requested units are actively engaged. Addressing conventions of input-output units will always be by logical unit numbers except when location is relevant.

The supervisor will maintain for each user an input-output assignment table in which the logical-physical unit number interconnection will be kept. When a user gives a logout command at his console at the end of his session, all assigned units will be disconnected.

Magnetic Tape Usage

Although for a large number of cases the disk memory, because of its quasi-random access, is more appropriate for program data and temporary storage requirements, there are still many problems such as payrolls, bubble chamber scanner output, etc., where magnetic tapes are more appropriate. This is true partly because of the vast quantities of information.

Within CTSS, the user may use private tape reels in the following way. The user types in an attach command specifying, for example, that file-protected private tape reel 103 should be mounted as logical tape 2 on logical channel 2. The computer replies "WAIT," as the command requests from the supervisor pool an available tape drive. Upon receipt of an appropriate tape drive assignment, the attach command sends an interconsole message to the tape operator's console (where his program is continuously processing messages), of the form:

"mount reel 103 as tape A3, file protected."

The tape operator, on completing the action, types "ok" which causes a confirming interconsole message to be sent back to the attach command. The command can relay to the user the tape mounting information by repeating the input information and concluding with "READY."

Dataphones

In addition to Teletypes, the IBM 7750 Communication Channel allows the attachment of higher speed devices (1200 bits/sec.) by means of Bell System Model 202B Dataphone sets, one at the 7750 and another at the device, with a telephone line between them. The devices (e.g., a PDP-1 computer or a 1620 computer) will appear as input-output units, and a user, from his console, may request to have them logically attached to his program. For convenience each device can be considered by the programmer to consist of several logical subunits; in particular, for control purposes one of these subunits (e.g., the typewriter keyboard) can represent a user console, so that an auxiliary console is not needed. Provision has been made for error detection and transmission correction in the internal character and message formats, which are further described in memo CC-210.

Command Programming

Whenever a user issues a command at his console, the command name and parameter segments are placed in order in a command parameter list, and the corresponding command program is located and started wherever indicated by the initial machine conditions of the program. The command program reads the parameter segments by issuing supervisor calls.

The only exception to the above process occurs with the resume command where the format for resuming program ${\textstyle \alpha }$, which has been "saved" by the save command, is

$$\mathrm {resume} \ \alpha \ p_{1}\ p_{2}\ \ldots \ p_{n}$$

. In this case, just before starting the ${\textstyle \alpha }$ program, the command list is reordered to contain the sequence ${\textstyle \alpha \ p_{1}\ p_{2}\ \ldots \ p_{n}}$. The purpose of this exception is to allow the user a trivial way to develop and use private commands which can also be compatibly added to the general system.

A useful property of the command mechanism is the ability of one command to call another command. The setting of the next command name and parameter list is done by the operating command program issuing appropriate supervisor calls.

By letting a command program set up an internal "command location counter" (not seen by the user), it is possible to run a master command program which in effect operates a "program" of subcommands, each of which returns to the master command after increasing the command location counter; the master command effects the return to the supervisor. The master command and the subcommands may, by means of a supervisor subroutine call, modify the command parameter list.

When this procedure is used, a fresh copy of the master command program is brought in each time it is executed, and the "command location counter" is used to dispatch control to the next command sequence. Conditional branching can be realized by letting the subcommand increase the location counter by a variable amount. Communication between subcommands must be accomplished by leaving data files on the disk.

Console-Initiated Background

Although the foreground console system is highly useful for preliminary programming, experimentation, and general man-machine interaction problems, there are occasions when long, uninterrupted computations must be performed by foreground programs. In these cases, the user ordinarily neither needs nor wants to occupy a console during the computation. To avoid this situation, it will be possible for the user, by placing his operating program in dormant status and issuing a bkgrnd command, to turn his job over to the supervisor for operation as console- initiated background. In the bkgrnd command the user will specify as parameters: the computation cut-off time; the name of the job file; a name for the file to contain the final status of the program; and the name of a file for any console messages which may develop (including information concerning the final job status).

After a console-initiated background program is turned over to the supervisor, the user, at a later time (even after he has issued logout and login commands), may interrogate the supervisor by means of a status command to obtain the status of his one or more jobs. From the status command, the user receives a report containing: whether the job has finished or not; the time the job was submitted; the computer time used to date; the cutoff time; the current program level number; and the level populations in the scheduling algorithm.

Estimate of Computation Completion Time

When a user is present at his console operating a foreground program, he can easily determine the rate of computational progress by the use of the time command. However in the case of console-initiated background, estimation of completion time becomes a more difficult problem. For this purpose, an estimate command will be made available. Its properties are expected to be as follows:

The console user gives as command parameters the designation of the particular background job in question, and the total expected computation time required by the job. The estimate command can determine the position of the job in the scheduling algorithm, and it has available a cumulative history of the scheduling traffic on, for example, an hourly basis over a period of a week. For each hour, the traffic history consists of a histogram, for each level of the scheduling algorithm, of the number of job initiations versus the total computation time required (including time in subsequent levels). Knowing in addition the current job status and the scheduling algorithm itself, the estimate command is in a position to run a high-speed Monte Carlo simulation, into future time, of the expected system behavior. By running several such simulations, using different initial settings of the pseudo-random number generator, the estimate command can type out a message like: "Range of estimates over 3 trials = 131 min. to 237 min . Estimated Completion time between 3:16 pm July 1 and 5:02 pm July 1." (An alternative message might be "job already completed.")

If the estimated time is too long, the user will initially have no recourse except to cancel or stop the background job. Future systems may contain priority alternatives, with additional usage charges serving as restraints.

Background System Restrictions

The normal user of CTSS will not need to concern himself with the following section which is primarily of interest to those programmers dealing with older pre-time-sharing programs.

Certain programming conventions or restrictions must be followed in programs running as background jobs in CTSS. These restrictions are principally dictated by the need periodically to interrupt all programs operating in CTSS. Normally, well-programmed systems will already satisfy the requirements. What is required, in the main, is a program which is timing-insensitive (i.e., one which would operate correctly were the computer to be put in manual operation at any moment).

1. The use of the following instructions is prohibited; if a system uses one of these instructions, a protection mode violation occurs and a diagnostic will be given.

   ECTM        LPI
   ESNT        LRI
   ESTM        SEA
   ETM         SEB
   LCH         TIB
   

2. Data channel traps on channels A and B will operate normally except that when a trap occurs, instead of an effective XEC of location 13 or 15, control is transferred to location 13 or 15. Therefore, if data channel traps are expected, location 13 or 15 can only contain an unconditional transfer for proper program operation. (If this condition is not satisfied a diagnostic will occur.)
3. The background system, if authorized by the Center, may use the Disk Control Subroutines (Chapter 5) by calls identical with those used by foreground programs.
4. Since many foreground users may have programs operating, it is undesirable to have the operator intervene in the conventional manner to take terminal post-mortems. The "Load Cards" and "Load Tape" buttons are not to be used by the operator, since they reset the memory protection and relocation mode. The "Start" button cannot be used because the operator does not know when the background system is operating.

   However, in order that the operator may effectively perform these functions, the address of the console keys is continually checked by the Time-Sharing Supervisor. (The background system cannot use the address section of the keys.) When the supervisor finds certain codes, it simulates the following functions:

   1. Depressing the "Load Cards" button.
   2. Depressing the "Load Tape" button.
   3. Depressing the "Start" button.
   4. Initiating the "standard error procedure."

   The "standard error procedure" consists of storing the instruction counter in a specified location, and transferring control to some address which is the start of a post-mortem routine or a return to the background system monitor. The background system should therefore specify two locations for use by the Time-Sharing Supervisor. This is done by the following call to a supervisor subroutine:

   TSX       DEFERR,4
   PZE       ERRILC,,ERRTRA
   

   where DEFERR contains: TIA =HDEFERR. DEFERR is the name of a supervisor subroutine which defines the error procedure. ERRILC is the address where the instruction counter will be stored, and control will be transferred to location ERRTRA.

5. GETTM is the subroutine used to read the date and time from the special Computation Center on-line printer clock. The original version of the program uses the "load channel" instruction (which is illegal), and is not interruptable. A new, interruptable version will be available.

   The interval timer clock will be simulated for use by the background system. This clock will only operate when the background system is in control and should therefore be used to determine the amount of time run. MITMR, the Center's timer program (CC-193), may be used in the normal manner.

6. In general on the 7090, when an interrupt occurs, the interrupted program is resumed at the location specified in the appropriate lower core register. When the 7090 is stopped by an HPR instruction, the instruction counter is set to the next location; it is this location which is stored if an interrupt occurs. Thus if there is an interrupt at this point, the program resumes at the next instruction after the HPR. Since interrupts are a normal occurrence in the Time-Sharing System, the 7090 cannot always be stopped by an HPR instruction. The HTR instruction, however, produces a genuine program stop and should be used in place of the HPR.
7. Only the following I/O units are available for background systems:
   1. the card reader, card punch and printer;
   2. tape units A1-A6, A10, B1-B6 and B10.

   If other units are referenced, a diagnostic will occur.

8. The "Load Channel" instruction is prohibited. A diagnostic will occur if an LCHX instruction is used. A "Reset and Load Channel" instruction, if given, must immediately follow the select instruction; otherwise, the I/O check light will be turned on. An exception is made for three instructions; up to three SPR's, or SPU's, and/or NOP's may be inserted between the select and reset and load instructions.
9. All I/O commands (including TCH commands) must have a "1" in bit position 20. This will automatically be done on assembly if the BCORE pseudo-op is used in the Center version of the Fap assembler. I/O instructions, if generated, must also contain this bit. A diagnostic will be given if this condition is not met.
10. When the supervisor determines that the background system is to be saved while a foreground program receives attention, the background system's machine conditions must be saved. In order to save the status of an I/O channel, the supervisor must wait for current I/O activity to stop. If the background system reads or writes long records on tape, the time spent waiting in the supervisor can be detrimental to the foreground response time. It is normally required, therefore, that all physical records read or written on tape be less than 1000 words. If this condition cannot be met, the matter should be discussed with the Computation Center Staff.
11. To ensure insensitivity to timing, proper interlocking of I/O commands and the CPU program must be guaranteed, usually with TCOX instructions. When this is not done, it is sometimes possible to get erratic program operation due to the probabilistic nature of other program interrupts (and consequent program delays) occurring during the operation time of I/O commands which change the working data area of the interrupted program. This also applies to control-card coding.

Supervisor Subroutine Calls

The subroutines listed below are available to CTSS users through the supervisor program; a brief description of their function follows. The entries to the disk control subroutine are also via the supervisor; the function of each of these entries is described in Chapter 5.

Supervisor Subroutines

RDFLXA
WRFLX
WRFLXA
DEAD
DORMNT
(EFTM)
(LFTM)
GETMEM
SETMEM
GETCOM
AKNOLG
TSSFIL
USRFIL
SETBRK
SAVBRK
GETBRK
SETFUL
SETBCD
NEXCOM
GETILC
FNRTN
INSTRT
INPEND

Disk Control Subroutine Entries

.DUMP
.LOAD
.ASIGN
.WRITE
.APEND
.FILE
.SEEK
.READK
.ENDRD
.RELRW
.CLEAR
.DLETE
.RENAM
.RESET
.FILDR
.FSTAT

Supervisor subroutines are called by means of the trapping convention described in Chapter 3, "User Communication with the Supervisor." Where arguments are expected, they are located relative to index register 4 as in normal calling sequences; for example

          TSX     RDFLXA,4
          PZE     BUFF,,4 
                  . . .
                  . . .
RDFLXA    TIA     =HRDFLXA

is a call to RDFLXA with a single argument in (1,4) and a return to (2,4). The BCD name of the supervisor entry, as specified in the TIA instruction, must be left-justified with trailing blanks. To read an input line from the console,

TSX     RDFLXA,4
PZE     BUFF

reads 14 words into memory starting at BUFF. On return the logical AC contains N where the break character is the Nth character; the word containing the break has blanks to the right of the break; subsequent words contain blanks. To issue an output line to the console,

TSX    WRFLX.4  or   TSX     WRFLX,4 
PZE    BUFF,,N       PZE     BUFF,,N

where WRFLX writes the N words (N≤14) starting at BUFF, adding a carriage return at the end of the line, and a color shift at beginning and end where the color shift is available; blanks are deleted from the end of the line. WRFLXA differs in that it does not add carriage return or color shift, and does not delete terminal blanks.

All entries to the master disk control subroutine are interpreted like supervisor calls. See Chapter 5.

The call:

TSX    DEAD,4

returns control to the supervisor and puts the user in dead status, i.e., machine conditions are not saved.

TSX    DORMNT,4

returns control to the supervisor and puts the user in dormant status, i.e., machine conditions and the current status of the user's program are saved, unless a command is issued which causes a new program to be read into memory. If the start command is issued, control returns to (1,4). The call:

TSX    (EFTM),4

causes entry into the floating-point trapping mode, with trapping simulated in B-core.

TSX    (LFTM),4

causes exit from this mode. The call:

TSX    GETMEM,4

returns in the address of the AC the size of the user's current memory allocation. The call:

TSX    SETMEM,4

sets the size of the user's memory allocation to the value in the address portion of the AC. This subroutine must be used whenever the user wishes to increase the size of his program. If he fails to do so and refers to locations outside his original memory allocation he may not cause a protection violation, since the protection indicators are set by block count rather than word count; but dumping, when users are swapped in and out of core, is done by word count, and all information stored beyond the memory bound will be lost. The call:

TSX    GETCOM,4
PZE    N

returns in the logical AC the Nth word of the user's latest command. Each command issued by the user is written in the supervisor region, one word per argument, in an 18-word buffer; after the last word (the last parameter in the command line) a marker is written consisting