LOGIN is the only command available when you first connect to CTSS. It is also treated as a user level command so you can use it to switch accounts when logged in.

TTPEEK will show how much CPU time and disk space you have used. A quota for this was established when a user ID was created.

DIAL allows a non logged in terminal to be associated with a logged in session. Once associated it can be used by programs on the logged in session to send and receive text, but cannot run commands directly. However none of the existing commands on CTSS use this facility.

HELLO gives a simple system summary similar to what you see at login.

SUBSYS and OPTION restrict what type of operations can be done. It seems to be intended as a way for a login to be used to run a specific interactive program rather than issue general commands. These are selected by the user and can be changed so it is not a security mechanism.

A sample of WHO output:

who
W 1815.0
        
MIT8C0 STARTED AT 1127.2 02/15.
                               
 2  USERS AT  1815.0 02/15.
                           
LINE   USER     NAME  GRP UNIT  TUSED TIMEON
 1 C0056 99995 FIBMON  0 (FIB)     .0 1127.2 02/15
 3 M1416    10  ELIZA  1 700000    .0 1815.0      
                                            
R .016+.016

These have been discussed in the post Files and directories.

The exception is CALL, which is a thin wrapper around several system calls. For example to delete a file A MAD you could use CALL DELFIL A MAD.

P is a good choice to view any type of text file.

These are all line-orientated editors. The ED family shares a very similar command set, documented on the ED page. QED is a more sophisticated editor allowing multiple buffers; it was created by Ken Thompson of Unix fame. These will be looked at in a lter post.

These exist to translate between text formats and to save space.

We looked at SQUASH and XPAND in the post Files and directories.

CRUNCH was used with the BEFAP assembler which is also not available.

SQZBSS and PADBSS works on BSS object files by removing card sequence numbers and compressing sequences of zero value words.

ARCHIV is reminiscent of Unix tar, bundling a number of files into a single file so it takes up less space (both in terms of disk and entries in the directory) and can be un-archived later. Its first argument is a command like C for create and X for extract, also implying that tar was modelled on this. The semantics were a bit different as it generally worked on files with the same name2. For example, if you wanted to archive files A MAD B MAD and C MAD into an archive ARC MAD you would type archiv arc mad a b c.

APND is used as follows:

APND sub mad main main

which will append a copy of SUB MAD to the end of MAIN mAD.

APEND is similar but takes multiple files as input and writes to the first file as output, so to get SUB1 MAD and SUB2 MAD appended to MAIN MAD you would do:

APEND main mad sub1 mad sub2 mad

COMBIN is useful for card image files as it can adjust the seqeunce numbers of the combined file to make them contiguous. It is also used to create a libary from several BSS files.

We looked at these in the post Files and directories.

RUNCOM will run a series of commands stored in a file.

The FIB commands allow you to queue a job to be run the next time you are logged out.

Both of these will be discussed in a later post.

ECHO is like the Unix shell set -x in that it prints its arguments and then executes them as a command.

We'll look at these in the next post.

PINFO appears to be like the Unix man command, showing text files about each command on the system. Both PINFO and its files are not available on the CTSS we have.

None of these commands are available on the CTSS we have today. Most deal with typewriter control.

PRNTER appears to be used to debug issues communicating with a typewriter.

REMARK allows a user to send comments to the operators: these are appended to a public file and was then printed out once a day.

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

As mentioned previously, each file name has two parts, with up to six characters for each part. (Six characters as a limit comes up a lot in CTSS, as 6 x 6 bit BCD characters would fit into a 36-bit machine word.) The two parts of the file name (called name1 and name2) are separated by a space when giving them to a command.

By convention, the second part of the name indicated the file type, eg MAD for MAD source code or BSS for object files.

Metadata on the file directory included the record size and the number of records, so fixed record data files are supported.

Text files evolved over time. Initially card image or line-numbered files were used: these use 14 machine words (so 84 BCD characters) per line. This allows interchange with punched cards, with each card representing a line in the file. Especially at the start of CTSS, many users would have collections of cards for their programs and data, and would transfer from these to and from the disk. The line-numbered name refers to the convention for punched cards of having a sequence number in columns 73-80 so the order of cards could be recovered if you accidentally dropped the deck on the floor.

Although easy to access specific lines, the problem with this format is it is inefficient: a completely blank line would be represented by 14 words of space characters. Line-marked files offered a solution, where each line could have a variable length and the start of each line would have a marker and its length.

Later on - I think as a byproduct of doing Multics development on CTSS - ASCII format files were supported, with the familiar 8 bit encoding and variable line length. There was also support for 12-bit BCD files which packed 3 characters into a word and allowed lower case.

It is up to each program to decide what type of files it supports. The MAD and FAP compilers accepted both card image and line-marked files, but some other compilers only accepted one format. For editing files, use EDC for card image and EDL for line-marked.

You can convert a card image file to a line-marked one with the SQUASH command and go the other way with XPAND.

As an example, let's look at a two-line program stored as a card image file HWC MAD and as a line-marked file HWL MAD. We use PRINT to show how the two files look and PRBIN to show a binary dump.

Note that PRINT puts the line number at the start of the print out. PRBIN will print in octal, with each two-digit number representing a BCD character; for example, 60 is space and 00 is digit 0.

print hwc mad
W 1059.9
        
   HWC    MAD      01/11  1059.9
                                
   00010               PRINT COMMENT $HELLO, WORLD$
   00020               END OF PROGRAM              
R .016+.016                          
           
prbin hwc mad
W 1100.0
        
   HWC    MAD  01/11  1100.0
                            
     1 606060606060 606060606047 513145636023 464444254563 605330254343 467360664651
     7 432453606060 606060606060 606060606060 606060606060 606060606060 606060606060
    13 606060000000 010060606060 606060606060 606060606025 452460462660 475146275121
    19 446060606060 606060606060 606060606060 606060606060 606060606060 606060606060
    25 606060606060 606060606060 606060000000 020060606060                          

R .016+.016

print hwl mad
W 1101.7
        
   HWL    MAD      01/11  1101.7
                                
	PRINT COMMENT $HELLO, WORLD$
	END OF PROGRAM              
R .016+.016           
           
prbin hwl mad
W 1101.8
        
   HWL    MAD  01/11  1101.8
                            
     1 777777000005 724751314563 602346444425 456360533025 434346736066 465143245357
     7 777777000003 722545246046 266047514627 512144575757                          

R .000+.016

Directories in CTSS are rooted in the single Master File Directory (MFD) which contains pointers to several User File Directories (UFD). Each user would have their own UFD named after their login project number and name, eg M1416 GUEST. It is not possible to make sub-directories under a UFD.

You can change to another user's directory with eg ATTACH M1416 ELIZA and return to your own directory with just ATTACH. But you are only able to do this if the other user has given you access with PERMIT.

Common files are UFDs intended for sharing. There are 5, numbered 1-5 and named CMFL01 to CMFL05. Although you could use ATTACH, the simplest way to get to them is type COMFIL n where n is a number; 0 will return you to your own directory. On s709/ctss-kit, this is how they are used

You can also view other directories using LISTF without changing to them by giving parameters. Foe example, the MAD compiler is stored as MAD TSSDC. in common files 2. Here is two ways to see it.

listf (cfl2) MAD TSSDC.
W 1122.7
        
   MAD TSSDC. 000    33 01/10/14
                                

R .016+.033
           
comfil 2
W 1122.8
R .000+.000
           
listf MAD TSSDC.
W 1122.8
        
   MAD TSSDC. 000    33 01/10/14
                                

R .016+.000

COPY will allow you to take a copy of a file from common files to your own UFD. Let's return home and grab that binary.

comfil 0
W 1123.9
R .016+.000
           
listf mad tssdc.
W 1124.1
        
NAMES NOT FOUND
   MAD TSSDC.  
             
R .016+.016
           
copy 2 mad tssdc.
W 1124.3
R .050+.016
           
listf mad tssdc.
W 1124.4
        
   MAD TSSDC. 000    33 01/11/14
                                

R .033+.016

UPDATE does the same in reverse, ie copies a file from your UFD to a common file directory.

However there is no way in general to refer to a file in another directory, so for example if you want to PRINT a file you would need to change directory first rather than referring to a path to access it.

RENAME and DELETE work as expected. MOVE is used to copy a file within the same UFD.

CTSS also had a way to link a file name to another one. This is what we'd call a soft link today - there is a record pointing to a file name rather than multiple directory entries. This was often used to make files available to other users, for example having a common file entry point to the real file in a user's UFD. Links have a maximum depth of 2.

Permission to link must be granted via PERMIT, even to link to your own files. So to make HELLO2 MAD point to HELLO MAD we could do:

permit hello mad 0 * *
W 1742.0
R .000+.016
           
link hello2 mad m1416 guest hello
W 1742.2
R .000+.016
           
listf
W 1742.3
        
    10 FILES    14 RECORDS
 NAME1  NAME2 MOD NOREC   USED
PERMIT   FILE 120     1 01/11/14
 HELLO    MAD 000     1
  [...] 
                       
HELLO2    MAD 000  M1416 GUEST   HELLO
                                      
R .016+.016

Note PERMIT saves permissions to PERMIT FILE rather than using file metadata, and that the new link file is displayed at the end of LISTF output in a special format.

UNLINK can be used to remove a link file.

You can see the permissions field in the MOD column of the LISTF output above. Like Unix there are three octal digits that can be OR-ed together but the meaning is different

The effect of making a file both read- and write- only seems to be neither is permitted.

Permissions to delete a file come from whether it can be written to or not.

The command to change permissions is CHMODE which takes the file names first and then the new mode at the end.

The CTSS Programmer's Guide section AD discusses how the file system works, and sections AH.3 - 6 have further details on the commands mentioned in this post.

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

Diagram of CTSS hardware. Source: Rupert Lane. License: CC0.

The hardware controlled by CTSS changed over its lifespan. This is the setup that matches the CTSS source code used in the emulator. Most I/O work was done by channel controllers which offloads some of the work from the CPU. Each channel can have up to 10 devices connected to it. User programs cannot access components directly, they need to go through supervisor services.

There are two separate 32kW banks of memory, known as Core Memory A and B. Note each word is 36 bits, so that's the equivalent of around 147 kilobytes in each bank. As the 7094 can only address 32kW at a time, these are switched between as needed. The supervisor sits in Core A at all times. User programs are brought into Core B as requested by the user, and may be swapped out to drum or disk as CTSS schedules other tasks to run. The maximum memory available to a task is 32kW and there is no concept of virtual memory; however several smaller tasks can be in memory at the same time.

A fixed maximum number of users can be logged in at any time (30 is the limit on the emulated system). Each user can only have one task active, so could not login twice simultaneously or create (fork) a new task while an existing one is running.

There is no equivalent to a shell as a separate user program. Logged in users type in commands which are processed by the supervisor. Commands and their parameters can each be up to 6 characters long. Commands can be either system programs (eg LISTF) or user created programs and are treated the same way: the supervisor will load the program into core B and transfer to it. Once a task is completed, control is returned to the supervisor.

Each task can be in a particular state, such as working, waiting for I/O etc. Two special states refer to the task after it is completed: dormant means the program has finished but is still in core so can be restarted or the machine state analysed. Dead means the program is out of core.

The scheduling algorithm for CTSS evolved over time as experience was gained using the system. As of the later system it had nine priority queues, ordered so that smaller or newer tasks would get a small amount of CPU time quickly, and longer running tasks would run less frequently but get more CPU time when it was being run.

It is also possible to run background tasks at a lower priority. This included jobs submitted by users from the online system (called FIB jobs) as well as non-time-sharing aware jobs, such as batch or standalone 7090 programs. This ability to run pre-CTSS jobs explains the 'Compatible' in the OS's name.

CTSS applies relocation to each task so it can be placed anywhere in memory without the task being aware of its physical position. The system also keeps track of what areas of memory the program is using, so any access outside of there leads to a protection violation and the program being terminated.

The original paper by Fernando Corbato is available at the ACM. It describes an earlier version of the system we have today, but also includes information on why the system was developed.

The CTSS Programmer's Guide section AA gives more detail on the supervisor.

Bob Supnik's analysis of CTSS hardware was also useful in understanding how CTSS worked and is emulated.

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

How then was the computer used?

Sample hand written program for the 701. Source: IBM's early computers by Charles J Bashe.

According to George F. Ryckman, who worked with a 701 at General Motors Research Laboratories in the early 1950's:

Each user was allocated a minimum 15-minute slot, of which time he usually spent 10 minutes in setting up the equipment to do his computation. He mounted his own tapes and set up the card reader, card punch, and printer to carry out his computation. By the time he got his calculation going, he may have had only 5 minutes or less of actual computation completed-wasting two thirds of his time slot.

For the programmer, this was not a great experience as they had limited time to debug their programs. For the computer owners it was even worse, given the great expense of the machine, most of the time the CPU was sitting idle as programmers set up their program and tried to work out what was going on,

The idea of a programming language operating at a higher level than assembly had been discussed since the 1940s, with one of the first fully working ones being Short Code for the UNIVAC. Assembly language programmers expressed scepticism: running a compiler would add to the time taken to produce the machine code, and how could code produced by a compiler compile to their own hand-optimised code?

Cover of the 704 Fortran manual. Source: IBM Manual at bitsavers.org

Fortran, developed between 1956 and 1957 by John Backus and a team at IBM, helped answer these questions. It had a syntax that allowed easy translation of mathematical formulae into code and was fairly quick to run. Scientists and researcher adopted it quickly, and it spread to many other contemporary computers.

A simple Fortran program to print Hello World 5 times:

C     HELLO WORLD PROGRAM
      DO 10 I=1,5
      WRITE (6,20)
10    CONTINUE
      STOP
20    FORMAT(13H HELLO, WORLD)
      END

Another early language was MAD, the Michigan Algorithm Decoder. Developed at the University of Michigan in 1959 for the 704, it provided a more English-like syntax inspired by early drafts of the Algol language, and had a fast compiler.

The equivalent of the above program in MAD:

*     HELLO WORLD PROGRAM
      THROUGH LOOP, FOR I=1, 1, I .G. 5
          PRINT COMMENT $HELLO, WORLD$
LOOP  CONTINUE
      END OF PROGRAM

High level languages like these helped speed the development process, but the problem of efficient machine utilisation was still present.

The solution to this was batch processing. A series of jobs for several programmers could be grouped together into a batch of work that could be executed by the computer in sequence with minimal set up time. Programmers would submit their code and running instructions to the operator, who would prepare a set of tapes to load into the computer and execute. After the batch was run, a tape containing items to print or punch to cards would be transferred to a smaller computer, and the physical paper/cards delivered to the programmers.

The development of these batch operating systems again started with customers contributing and sharing code: examples are the SHARE Operating System and Bell Labs' BESYS. Eventually, IBM adapted the Fortran Monitor System (used at MIT) and released this as IBSYS.

An example of a set of control cards to compile the above Fortran code, run it and produce a listing.

$JOB           HELLO WORLD
$EXECUTE       FORTRAN
$ID    HELLO
*      XEQ
*      LIST8

Along with increased utilisation, this helped efficiency as jobs had to be submitted in a way that was understandable by the computer. The set up tasks were also done by experienced operators who used the machine constantly rather than programmers who did not.

The disadvantages were latency and lack of debugability. It could take hours or days for the batch to finish and each programmer to receive their output. Minor errors in the program that could have been quickly fixed in the "open shop" method of operation would now have to wait for the next batch run.

The solution to this was time-sharing, of which CTSS was one early example. Next time we'll look at CTSS, starting with the supervisor.

• IBM's early computers by Charles J Bashe describes the hardware and software of the IBM 7x and other early computers.
• Classic operating systems by Per Brinch Hansen has a chapter on how the 701 was used in an "open shop" manner at General Motors Research Laboratory, plus many other details on operating system history.
• Early assemblers such as UASAP can be run on simh, along with a manual.
• IBSYS is available to run on both s709 and simh, with manuals on bitsavers.

Please email me at rupert@timereshared.com and I will update this page.

The IBM 7094 was big, taking up a large room at the MIT computer centre for its CPU and peripherals.

It was one pf the fastest computers available in the early 1960s.

It was also very expensive: a typical system sold for $2.9 million (equivalent to $23 million in 2023) or could be rented for $63,500 a month (equivalent to $501,000 in 2023) (from Wikipedia).

All this meant that very few sites could afford one - mostly universities and large corporations with extensive need for scientific computation facilities.

From 1952 IBM had developed a range of computers, first using vacuum tubes and later transistors. The table below shows how their scientific range evolved - there were also commercial application versions that were not completely compatible with the scientific models.

MIT had a 704, then a 709 which was the first machine to get CTSS. They upgraded through 7090 - 7094 - 7094 II and had a second machine to support Project MAC.

The 7094 had a 36 bit word size and could directly address up to 32kw of core memory (so around 144kB - bytes as a standard measure of memory had not yet been standardised).

It has a single main accumulator and a multiplier/quotient register for multiplication and division. It has four index registers allowing indirect addressing. Numbers were stored in sign/magnitude form, with the top bit the sign and the remaining 35 bits the number.

At the time there was no standard for text encoding like ASCII; the 7094 used 6-bit BCD encoding, allowing only numbers, capital letters and some punctuation symbols.

For CTSS, MIT requested an additional 32kw of memory used in a bank-switched manner, so one bank was for the supervisor and the other bank could be fully utilised by the client program.

The primary storage mechanism for computers at the time was magnetic tape. This offered fast sequential read/write but due to the linear nature of tape could be slow for random-access. Installations would often have multiple tape drives: for a batch Fortran compile run for example, there could be one tape for the compiler, one for the input program, one for scratch storage and one for the output object, all being used at the same time. CTSS used tapes for user file storage on early versions before the disk was available; after that it was used for bulk file input and backup. Each tape could store around 3MB and could be read at several hundred bytes per second.

Random-access storage was done by what IBM called DASDs (direct access storage devices) and what we'd now call drums and hard disks. The 7320 drum was a cylinder with one head per track that could store 174,000 36 bit words. CTSS used this for swapping and some file storage.

The 1301 hard disk was one of the first commercially available hard disks and could store 28MB of data. It spun at 1800 rpm and could transfer around 90,000 bytes per second. CTSS used this for file storage. If you wanted to buy one, it would cost over $100,000 in 1963 dollars.

The console had switches and lights for the operator to toggle in values, view the state of the computer and start operations. There was also a line printer for logging.

User data could be fed into and out of the machine by punched card. Each card holds 80 characters. In practice this was not used for regular user input as it was too costly in CPU cycles; the user would instead punch data to cards using an off-line punch; the cards would be transferred to tape via a smaller computer and finally the tape loaded into the 7094.

What is missing here is interactive input/output. MIT requested IBM to build a data concentrator to handle multiple serial lines and used this to attach teletypwriters like the one below. It was also possible to connect over the telephone wires using an acoustic coupler.

Teletype Model 37. Source: Wikipedia. License: CC BY-SA 4.0

There was also an experimental graphical display connected to the IBM via a PDP-7, but this is not supported by the emulator.

There were also a number of other items requested from IBM by MIT to support CTSS:

• Trapping I/O operations to interrupts so they could be handled by the supervisor
• Memory protection and relocation
• A real time clock and interval timer

Much of the information on this page came from Wikipedia. Another great source is Tom Van Vleck's page on multicians.org about CTSS.