CTSS: Getting data in and out

At the time there were basically three media that could be used.

Printed paper - as typewriters were used as consoles, a printed record of what you were doing would be created automatically. But the print quality was not great, and it would also be slow to print a large file. So computer facilities like MIT offered ways to print on a faster and better quality printer.

Punched cards can be used for both input and output of programs and data. A user could punch a set of cards offline on a dedicated key punch (see image above), and get them loaded into the system. They could also get the computer to punch out cards and use the resulting deck as a backup or a way to transfer the data to another computer. At roughly a line of 80 characters per card, this only made sense with relatively small amounts of data; they were also slow to read.

Magnetic tapes was the choice for large amounts of data needed to be backed up or transferred elsewhere, but these were more expensive. Although operators and system programmers would use tape regularly, I believe end users would be less likely to use tape, at least at the time of CTSS.

(One further option was paper tape, but I believe this was used on smaller computers like the PDP-1.)

Card punches and magnetic tape drives are things you are very unlikely to have access to today - even printers are getting more scarce - so how does this work with an emulated system?

Put simply, it maps to files on your host system. Printer output goes to a single text file. Cards and tape map to binary files whose format is determined by the emulator, which provides tools to convert them to PC readable data at the cost of losing the original format.

Let's look at some ways we can use to do data interchange, starting with facilities provided by CTSS.

On the real 7094, printing and card punching was not done online due to the CPU load it would place on the system. Instead, users could request files to be printed and punched. Several times a day, the CTSS operators would collect the files on to a tape and bring this to a smaller system for printing and punching, and then distribute the results to users. The command to initiate this on CTSS was RQUEST.

We can use this facility with the emulator as well.

1. While online, type RQUEST PRINT name1 name2 to request printing of file name1 name2 or RQUEST DPUNCH name1 name2 to request punching. Wildcards are OK, so you could type RQUEST PRINT * BCD to produce a print out of all compile listings.
2. Shut down CTSS
3. Run dskedtctss on your host
4. You will need to press Enter a few times and then `q` when done.

If you are running the ELIZA version of ctss-kit, all printer output will be in output/sysprint.txt and each punched file will be a separate file based on the original filename in output.

For the upstream version of ctss-kit, you will need to convert the output tapes produced by dskedtctss as follows:

• Printouts: Run bcd2txt -p sysprint.bcd sysprint.txt.
• Punches: Run punchctss syspunchid.bcd syspunch.bcd .

We can use a utility provided by s709 called extractctss to get files from inside CTSS to your host machine. Usage is:

extractctss file-type name1 name2 prob prog local-file

file-type should be t for card image files and l for listings.

Note that the CTSS system should be shut down when you do this.

A sample run to get the HELLO MAD source file from the guest user:

extractctss t hello mad m1416 guest hello.mad

This will produce hello.mad in your current directory.

extractctss can also download several files in batch mode; see the ctss-kit README for more details

Should you use RQUEST or extractctss? I use both and think RQUEST is useful when you are logged into CTSS, looking at files and picking several to print or punch. extractctss is great for automated downloading.

You can also go the other way, uploading files from your host machine to CTSS. This is a two step process.

First, convert the file into a tape format readable by the upload program using obj2img. Here's an example to prepare upload.mad to become file UPLOAD MAD on the guest account:

obj2img -a " M1416GUEST " -f upload -e mad -t -o upload.img upload.mad

The -a flag determines the account to send it to; the problem number (M1416) must be right justified into 6 characters, and the programmer number (GUEST) must be left justified. Both must be in capital letters.

The -f and -e flags determine the name1 and name2 of the file on CTSS.

-t specifies card image format; obj2img can also do line marked, binary files and other special formats. See obj2img -h for options.

Second, to get this image file loaded into CTSS, run setupctss as follows:

setupctss upload.img 

IBM 7094-CTSS Simulator 2.4.3


 ATTACHING TO  M1416 GUEST                                              
 COPY TO TEXT FILE UPLOAD    MAD                                        
 DISK INITIALIZATION COMPLETE.                                          
 CTSS IS FINISHED. YOU MAY NOW CLEAR CORE.

You can then remove the .img file.

The Disk Editor on the real CTSS system also allowed you to upload files by giving the operators a card deck, but I don't believe this is supported on the s709 virtual system.

CTSS provided a number of tape handling commands so you could MOUNT a tape and then associate files on there with entries in a UFD to it can read/written. These commands are available, but are not fully supported by s709 I believe.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com