At Michigan State University, we ran a heavily customized version of a Control Data operating system. Nevertheless, many of the fundamental aspects of the system were similar not only to the original ~1969 SCOPE 3.2 on which our OS was based, but also to other CDC 6000 operating systems, especially the later NOS/BE (Network Operating System/Batch Environment).
MSU's original main innovation was the integration of batch and interactive job scheduling. The portion of the system that scheduled jobs was called Hustler. Batch and interactive jobs were treated by most portions of the system as similarly as possible.
With no virtual memory, jobs had to be either in memory or swapped out--nothing halfway. In order for a job to be swapped into memory, it had to be assigned to a slot called a control point. A control point was not a fixed region of memory, but rather a table entry that corresponded to a movable and resizable region of contiguous memory as well as to other resources being used by a job. Typical jobs ("Hustler jobs") were allowed to stay at a control point only when they were actively executing. Otherwise, they were swapped out to ECS or to disk. Swapping involved transferring not only the job's entire field length to or from memory, but also ancillary information such as the job accounting information, information about open files, and so on. "Control point jobs" were different. These were jobs which were not scheduled by Hustler, but rather stayed at a control point for the life of a job.
Various tables throughout the system reserved three bits for control point numbers, allowing a maximum of 8 control points. Control point 0 didn't really exist and was used to refer to the operating system; hence, there were really 7 control points. This meant that regardless of how much free memory was available and how small the jobs were, only 7 jobs could fit in memory at once.
The situation was worse than you might think because several control points were dedicated to running system jobs. Control point 1 always ran MANAGER, a program which managed interactive service. Control point 2 ran ARGUS, which talked to card readers, CDC-brand line printers, and the MERIT network. For a while, control point 3 ran a program which serviced E/I 200 remote batch stations, but this functionality was folded into one of the other programs to free up a control point. Still, the result was that 5 or fewer control points were available for user jobs. Further, operators could tie up a control point by explicitly running control point jobs via the console. Typically this was done only for the backup program SELDUMP.
In practice, especially with the 750 with its larger memory, 5 (or fewer) available control points weren't enough to make optimal use of the system. Thus, after the purchase of the 750, a major software project was instituted to increase the number of control points to 15 (13 available). The project was completed successfully, but it was a lot of work for a single bit.
The operations policies for the operating system accounted for some of the success of the system. The mainframe was deadstarted (rebooted) nearly every day, so if there were small resource leaks, they did not have a significant effect on the system. Security was based partly on keeping secret passwords secret, and on physically restricting access to the computer room and to the Systems Programming offices. The filesystem was dumped (backed up) to tape religiously. The heavy reliance on paper printouts and tapes for normal operation was dealt with by having the system staffed with operators 24 hours a day (though there were times of the week when tapes and printouts were not available).
Below are my notes to myself on sections to add here:
Recall bit. Autorecall on FETs.
Job priority
Editor
System-level I/O was simple. Record Manager was user code.
Field length. AUTORFL on/off/part/full(?).
Tape labels and tape handling. Mount a tape on any drive. Taperes count.
Command line parsing: front end, MISTIC, EDITOR, local files, LIBRARY, system.