THE EVOLUTION OF THE DECsystem-10 505

schemes were conventional, while the last scheme was used in the KL10/20 structure so that an attached PDP-l1 minicomputer could transmit data directly into the memory of the KL10. This scheme was first used in the early 1970s for handling multiple communication lines.

The initial goals and constraints for the user environment are summarized in Table 2. The most important goal was to provide a general-purpose timesharing system. The Monitor was to allow the user to run in the mode most suited to his requirements, including interactive timesharing, real-time, and batch. In timesharing, there was no requirement for a human operator per Se. Instead, the operator's console was a user terminal with special privileges. Real-time programs had to be able to operate I/O directly, locked in core, and batch was to be provided as a special case of a terminal job.

Because of the modular expandability of the hardware structure, the software system had to be equally modular to facilitate varying system configurations and growth. The core resident timesharing monitor was only fixed at system generation (i.e., IBM's SYSGEN) time when software modules could be added to meet the system requirements. The core space required for monitor overhead had to be minimized. Thus, job-specific functions were placed in the user area instead of in the Monitor. The first 96 locations of each user job contained pertinent information concerning that job. A temporary area (stack) for monitor operations was also included. In this way, the Monitor was not burdened with information for the inactive jobs. This structure permitted the entire job state to be moved easily.

Adequate protection was to be given to each user from other nonmalicious users. However, the user was not protected against himself because various user status information in the job area could be changed to affect his own job. Because common system resources were allocated upon demand and deadlocks could occur, the term "Gentlemen's Timesharing" was coined for the first monitor.

The UUO or "system call" instruction, provided both Monitor-user communication and upward hardware compatibility. In the latter case, the instruction would use the hardware if available; otherwise, the instruction would trap to the Monitor for execution. For example, double-precision hardware was available on later CPU models. The number of UUOs implemented in the Monitor for Monitor-user communication has been significant. The initial use of UUOs included requests for: core, I/O assignment, I/O transmission, file control, data and time, etc.

Monitor was the name given to a collection of programs that were initially core resident and provided overall coordination and control of the operating environment. A nonresident part was later added with the advent of secondary program swapping and file memories (i.e., drum and disk). The Monitor did not include utilities, languages, and their run-time support.

The PDP-6 Monitor was constrained to run in a 16 Kword (minimum) machine with console printer, paper tape reader (for maintenance) and two DECtape units. DECtape was a 128-word/block, block-addressable medium of 450 Kcharacters for which a file system was developed. Memory minimizing led to very sparing use of shared tables. The key global variable data was restricted to: core allocation table, clock queue, job table, linked buffers for Teletype and other buffered I/O devices (e.g., DECtape directory), and a directory of system programs and Monitor facilities.