Every now and then (the documentation seems deliberately vague about this, but says 'several times a day') a 'disk edit' program was run by the admin staff. This must have evolved over time - the earlier documentation refers to separate 'load' and 'dump' programs, and seems to have dumped the hard disk to tape backups and then reconstructed it every time (maybe from a time when the computer wasn't exclusively used for CTSS). The version I have is a single program, and I don't think it rebuild's the disk at all - it just executes the jobs in the queue - reading from REQUEST files and the card reader.

I loaded the MUSIC.FAP cards offline, i.e. I shut down CTSS, booted from the DSKEDT tape, and restarted CTSS once all jobs had been processed. The documentation does refer to it as 'background task', so I suspect there may have been a way of doing it without having to shut down the OS first.

A couple of things about old mainframes which seem unusual today. The first is that halting the processor is a thing - code is written to trigger a halt, the user then loads a tape, or flicks some switches, or something, and then presses a start button to get the CPU to continue. I suspect this stopped happening once you had time sharing up and running, but it crops up when administering CTSS. Secondly, you have sense switches and lights - these are literally a bank of toggle switches and lights which can be read or written to in code. The switches are used for configuration - presumably because if you're writing machine code by hand it's easier to use the built in 'jump if sense switch set' operation than it is to write a parser for a configuration file.

#retrocomputing #ibm #mainframes

2/n