undefined
I should add that I've done all of this using the s709 emulator from David Pitts (https://cozx.com/dpitts/ibm7090.html), using the eliza-ctss distribution from Rupert Lane (https://timereshared.com/). I'm sure both of these projects involved a massive amount of work, for which I'm incredibly grateful.
#retrocomputing #ibm #mainframes
4/4
Here's what's actually involved in doing a DSKEDT run (once CTSS is shut down and the CPU is halted):
1. Mount the DSKEDT tape (in drive A1 by default, at least in the emulator).
2. Execute 'load tape'. I believe this might have been a physical button on a real machine, which loaded the contents of the tape into memory.
3. Set the accumulator to be "CTSS ". I don't really know why you need this, but you seem to.
Next up is toggling the sense switches. I think you have three options: all down = start with REQUEST FILES, sw1 up = read cards and sw4 up = read the data which would be on the cards from tape A2. I actually used the sw4 version, having first mounted the tape.
Once you've done this you can hit start. The program will say it's started the tape drive, and halt. Then to continue:
4. Set sw4 down.
5. Hit start again. The system will process the jobs and then halt again.
6. Set sw2 up.
7. Hit start. The system will print 'EXIT CALLED' and you can shut down the emulator.
This process is really fussy, and it's super easy to get it to crash badly enough to require you to run a recovery program before you'll be able to try again (I think due to inconsistent state information for the DSKEDT program, not wider filesystem corruption). Many of the prompts output by the program are hard to make sense of, or seem to tell you to do the opposite of what you really need to do.
#retrocomputing #ibm #mainframes
3/n
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
Let me add a bit more detail on how this works. The #ibm7094 (specifically the one in the #MIT Computation Center which ran #CTSS) had a hard disk which was used for working storage. My understanding is that the preferred way of working was for users to enter files directly into the system via a teletype terminal, but the system did also have a card reader and multiple magnetic tape drives.
I don't think CTSS provided a friendly way for users to initiate loading from cards (although I'm not sure what there really was in the way of access control for the hardware if you were willing to write your own code). I suspect you wouldn't have had physical access anyway, so you would have had to have worked through the admin staff.
In practice, you would have done this by submitting a job. Jobs covered various I/O tasks, e.g. bulk printing, and for the most part could be submitted through an OS command (which wrote to a special file in the user's home directory). The one exception to this was card input, as that required the physical cards to be submitted to a helpdesk. Those cards were bookended by a metadata card (specifying the user and output filename) at the start and an EOF card at the end. In theory all of the job types could be submitted in the same way - except the 'deck' in those cases would just be the metadata card (and in fact the REQUEST in the users home directory was just an online representation of the same cards).
#retrocomputing #ibm #mainframes
1/n
This is progress - I have uploaded source code onto the #ibm7094 emulator and run it through the assembler. There are errors, but they make sense and I think many of them are just down to me getting used to the syntax.