The System/360 had a 32 bit architecture with 24 bit addressing and 8 bit bytes, using EBCDIC for character encoding. The smallest standard machine came with 8KB of core memory and the most powerful could address up to 8MB. Larger machines could transfer more data at once, and would have facilities like floating point implemented in hardware. Only the System/360 model 67 had support for dynamic address translation needed for efficient and secure time-sharing, but these facilities became standard in later iterations such as the System/370.

Machines were generally rented rather than purchased by customers, allowing easy upgrades. Monthly costs were "from $2,700 for a basic configuration to $115,000 for a typical large multisystem configuration". (Multiply that by 10 to get a rough idea of what this would cost in 2026 dollars).

IBM announced a unified operating system called OS/360 at the launch of System/360, but despite a great deal of effort (made famous in The Mythical Man-month, written by Fredrick Brooks who was a manager on the project), it could not create something that would work on the entire range of models. Simpler systems, such as TOS/360 (Tape Operating System) and DOS/360 (Disk Operating System, not related to the IBM PC DOS) were launched first, and several iterations of a multi-processing disk based batch system were introduced, including MVT (Multiprogramming with a Variable number of Tasks) which would become MVS (Multiple Virtual Storage) on the System/370.

The original plans for system software did not include time-sharing (to be fair, CTSS and Dartmouth DTSS were only just starting to be developed when IBM designed System/360). Demand from several customers in the mid-1960s led to TSS/360 (Time Sharing System) being made, but it was not a great success.

A different approach was taken by IBM's Cambridge Scientific Center, which created a virtualised operating system hypervisor (called CP) that could run multiples copies of a single user system (CMS) independently, and later other operating systems. This CP/CMS system became known as VM/370 on the System/370 and was popular as another approach to time-sharing. It is still available from IBM today as z/VM.

Work continued on the batch operating system MVS, and TSO - the Time Sharing Option - was created as a shell on top of the system to allow multiple users to access the machine interactively. This was probably the most widespread multi-user interactive system on System/360 hardware. MVS is supported by IBM today under the name z/OS.

IBM created many more operating systems - see the Wikipedia article History of IBM mainframe operating systems for full details.

Several universities, frustrated by the delays in IBM's development of time-sharing, produced their own operating systems, notably the University of Michigan's MTS (Michigan Terminal System) and McGill's MUSIC/SP (Multi-User System for Interactive Computing/System Product).

Edinburgh University created a version of their EMAS operating system for a System/360 compatible machine. Stanford built a system on top of MVS called ORVYL that was roughly comparable with TSO.

The Linux kernel has also been ported to the System/390 and several popular distributions are available, eg Debian.

System/360 front panel on display at the Computer History Museum. Source: Rupert Lane. License: CC0.

Prior to 1969, IBM bundled operating systems (often including source code) with its hardware and did not assert copyright. This has allowed distribution of early versions of MVS, VM and TSS. In some cases, hobbyists have taken these old versions and added modern facilities, such as Volker Bandke's Turnkey MVS and the VM/370 Community Edition.

MTS, MUSIC/SP and ORVYL are freely available, as of course is Linux. There is currently work being done to get EMAS running again; see the Github repo here.

Bitsavers has a large collection of IBM hardware and software documentation.

Several real System/360s have been preserved in museums, including the Computer History Museum in California and the Science Museum in London.

The most widely developed and used emulator is Hercules, which includes support for classic System/360 and later variants, along with networking and peripherals. Several forks are available, with the best supported today being SDL Hercules 4, whose source is on Github. Jay Moseley's introduction page is a good guide to what can be done with Hercules.

Richard Cornwell has written an emulator for the System/360 and /370 under simh that can run many early operating systems. Roberto Sancho Villa's simh_cpanel project adds graphical front ends and a distribution of VM/370 plus batch operating systems. Richard is also working on a microcode level simulation of the System/360 with a very detailed front panel.

Also of interest is Ken Shirriff's browser based IBM 360/50 Simulator that shows how the front panel looks when executing code, along with what is happening internally.

I plan to cover these operating systems in more detail. Links will be added as I come to them.

• IBM TSS/360
• IBM CP/CMS (VM/370)
• IBM MVS with TSO
• Michigan MTS
• McGill MUSIC/SP

Emerson Pugh's book IBM's 360 and early 370 systems goes into great detail on the history of this computer, including chapters on peripherals and software. You can read it online at the Internet Archive. A summary, also by Pugh, can be found at the Engineering and Technology History Wiki.

The Computer History Museum has a virtual exhibit on the System/360, and a real front panel on display in the museum (see the picture above).

IBM's System/360 Principles Of Operation is a clear overview of the system's architecture and can be found at Bitsavers.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.

Xerox provided a XGP to Stanford, MIT and a number of other research institutes in around 1972. The printer was based on an earlier Xerox experiment, the LDX (Long Distance Xerography) which was a fax type system with a scanner and a printer. The XGP just had the printer part. It was similar to modern laser printers in that it used an electrostatic drum and ink powder to print an page, but it had a CRT rather than a laser as its light source.

It could print 192 dots to the inch on a roll of paper 8.5" wide; it had a knife under system control so pages could be cut or it could simply produce a long scroll. Output was black or white only with no greyscale.

Here's a picture taken by a DEC representative of the XGP at SAIL; not the console in the front, it's in the background at the centre of the picture. It seems most sites put a bin in front of it to catch its output. so it often looks quote humdrum.

The XGP in the SAIL computer room. Source: CHM.

Each institute integrated this into their systems differently: MIT, for example, interfaced it to their PDP-10 via a PDP-11. Stanford chose to connect it to their PDP-6 (running side-by-side with the PDP-10 at this point) and developer an interface in the WAITS monitor. This could print in either bitmap or text mode; in text mode it could

• select different bitmap fonts stored on disk
• write text, with support for kerning, overprinting and underlining
• position items on the page with pixel accuracy
• draw simple vector graphics

Many output files that were sent to the XGP have been preserved in the saildart.org archive - manuals, project proposals, letters - created by the users as part of their regular work.

You can also make new XGP files using the simh emulator by running the source processors like PUB on either contemporary input files or your own creations

This was all taking place in the 1970s, well before Postscript or any of the font technologies we use today. Staff at SAIL created their own bitmap fonts, and there was lots of sharing with MIT, CMU and other XGP sites. As of 1974 the SAIL system had 71 fonts and by the time it was shut down in the 1990s there were over 500. These went beyond just English characters with different appearances, with fonts for Cyrillic, Hebrew and graphics.

Sample XGP fonts. Source: scanned copy of Find-a-font

On WAITS there are utilities that use the DD terminal to display a font file (R DDFONT) and edit them (R EDFONT).

Along with writing programs, creating documents was one of the key activities of the Stanford AI Lab: a study from 1970 reported that in 1969 the 64 staff produced 23 external documents, 28 AI memos and 15 SAILON operational notes during that year. (It then goes on to facetiously extrapolate from the rate of the growth in the 1960s to the year 2001 where it expected 158 million staff producing 29 billion documents).

To support this need, and to use the XGP, several document production tools were created at SAIL. These would all take a marked-up text file as input and produce a .XGP file as output, which could be sent to the printer via the XSPOOL command,

POX - Prototype Overlay Xewrographics - was written by Robert Maas and was a simple language specifically designed for the XGP. It has around 10 single letter commands introduced by a backslash: for example the below will define two fonts, set "Preface" in font 0 and use font 1 for the body, then starts a paragraph with justified text.

\M0BAXL30;\M1NGR25

\F0Preface\F1

\JThis document will introduce the POX language...

It also had a simple register based programming facility similar to TECO's called Q-registers, but no high level commands for producing structured text. It was generally used for smaller documents like letters. This can be run on WAITS via R POX which will prompt for an input file.

Cover of the PUB manual. Source: saildart.org

PUB was a scriptable markup language, implemented in 1971 by Larry Tesler from an idea by Les Earnest. This spread to other PDP-10 sites where it was extended (support for the XGP printer was added by CMU, for example). It had around 100 commands with an English like syntax together with a built in programming language similar to SAIL. An example from the manual to set up headers and footers with date and page number, and to indent paragraphs by six spaces:

.EVERY HEADING(DAN MATION,PARACYBERNETIC PHENOMENA,{DATE})
.EVERY FOOTING(,{PAGE},)
.INDENT 6

Although it was powerful, it was quite slow, processing around 15 pages per minute. Many of the SAIL manuals, such as those for FAIL, were produced using PUB. PUB is integrated into the RPG system so you can type PUB filename.pub to start the program.

A section from the TeX manual about running it at SAIL. Source: saildart.org

The most famous text processing language to come out of Stanford was TeX, by Donald Knuth. The first full version was written in the SAIL language and made available in 1978. This produced output to an XGP file rather than the DVI files used today. This was pre-METAFONT, so Knuth created XGP font files to integrate with the SAIL printing system.

As the disk images we have running today are from 1974, that means that TeX is not available to run under simh at present. However, the XGP emulator can render to PDF existing XGP files produced by TeX.

The new emulator, xgptopdf, is a Python program that is independent from the WAITS simh emulator. It takes a XGP file produced by PUB, POX or TeX as input and produces a PDF file as output. You can directly reference a saildart.org file by giving its WAITS filename; the tool will download the file and produce output in one step.

For example, International Yum Yum was the lab's guide to restaurants around the world, the cover of which you can see in the bottom right of the montage at the top of this article. The first version of this file from 1978 is preserved at saildart.org as YUMMY.XGP[P,DOC]`, so you can type

    xgptopdf YUMMY.XGP[P,DOC]1

and it will make a file YUMMY.XGP[P,DOC]1.pdf in your current directory that can be viewed or printed.

For new XGP files generated by PUB or POX using the WAITS simh emulator, use the techniques described in an earlier post to extract the files to your own computer via a virtual tape file. When unpacking the DART archive you need the -Woct switch to extract in octal format. So say you had a tape file extract.tap that contained an XGP file MY.XGP[1,REL] run

$ dart -Woct -xf extract.tap
$ xgptopdf rel/1/my.xgp

and it will produce my.pdf in your current directory.

The XGP spool file does not embed the font, rather it references which fonts it wants to use via a file name. Therefore the emulator contains a collection of font files from the SAIL backup and a facility to switch font assignments if needed.

The Github repo contains a few examples of PDFs created by this tool. There are several hundred original XGP files on the saildart.org archive - and many more that can be created from their PUB or POX source - so it's well worth exploring to see what you can find.

The computer history wiki gunkies.org has a page about the XGP. There's information on how it was used at MIT, plus some pictures, at the PDP-10 Github organisation.

Find-a-font - SAILON 74 - contains a guide to the fonts available on WAITS and the font format.

saildart.org has the original PUB manual in text form, along with a version with additional notes from Larry Tesler.

September 2026: Lars Brinkhoff correctly pointed out that Stanford connected their XGP to the PDP-6, not directly to the PDP-10.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.

Stanford had a version of Lisp on the IBM 7090 and PDP-1 machines used in the first few years of the lab's existence. When they got their PDP-6 they took an early version of Maclisp from MIT, made changes to get it to work with the WAITS system and released it in 1966 in Lisp 1.6. The authors were John Allen, Lynn Quam and Whitfield Diffie (who after leaving SAIL became famous for his work on cryptography).

Lisp 1.6 gained some additional features: as of 1974, the date of the disk image we are using, it had:

• An arbitrary precision fixed point number system.
• An interactive s-expression editor called ALVINE.
• Flexible I/O, including to the teletype and to files.
• A compiler, which reportedly produced code that ran twenty times faster than interpreted code.
• A library to control the III display terminal.
• Debugging and tracing features.

Start the interpreter with R LISP. By default this will give you 12k of core which is only enough for trivial programs, to give more core space add a number representing the core size in kilowords, eg R LISP 48.

It will ask you ALLOC? which if you type Y will allow you to change sizes of memory buffers; normally just press Enter here. It will then put you at the * prompt where you can type s-expressions. Use upper case.

.r lisp

ALLOC? 


*(PLUS 2 2)

4

Note that integers are in octal, so use real numbers for calculations.

*(TIMES 8 3)

30 
*(TIMES 8.0 3)

24.0

Typing altmode (the Escape key) will close all open parens, for example after entering 5 below I pressed Escape, the interpreter printed $ and the two close parens were supplied automatically.

*(PLUS 10.0 2 (TIMES 6 5$
42.0

Variables can be set with SETQ and functions defined with DE.

*(SETQ Y 3)

3 
*(DE DOUBLE (X) (TIMES X 2))

DOUBLE 
*(DOUBLE Y)

6

The I/O system can handle multiple channels, but for simple reading from the terminal you can use READ which will accept a s-expression as input. PRINT will type out its argument, but you can also just evaluate a form to display its value.

Programs - collections of functions and other declarations can be created by editors outside of Lisp and read in to the environment using DSKIN. For example, (DSKIN (FOO . LSP)) will read in the file FOO.LSP in your current file area.

Let's demonstrate Lisp by implementing the TPK algorithm in Lisp 1.6. We can use the Lisp 1.5 code for CTSS as a base. In the Lisp 1.5 version, the key function to calculate TPK, √|x| + 5x³, is expressed as

(F (LAMBDA (X) (PLUS (SQRT (ABS X)) (TIMES 5 (EXPT X 3)))))

so in Stanford Lisp 1.6 this would be:

(DE F (X)
    (PLUS (SQRT (ABS X)) (TIMES 5 (EXPT X 3))))

However, whereas Lisp 1.5 had EXPT but no SQRT or ABS, here we have ABS but not EXPT or SQRT. We can implement (EXPT X 3) as a cube function (TIMES X X X) but for SQRT we will need to resort to the Babylon algorithm we last used in the Essex BCPL program.

(DE CLOSE (X GUESS)
    (LESSP (ABS (DIFFERENCE (TIMES GUESS GUESS) X)) 0.000001))

(DE IMPROVE (X GUESS)
    (QUOTIENT (PLUS GUESS (QUOTIENT X GUESS)) 2.0))

(DE BABYLON (X GUESS)
    (COND ((CLOSE X GUESS) GUESS)
          (T (BABYLON X (IMPROVE X GUESS)))))

(DE SQRT (X)
    (BABYLON X (QUOTIENT X 2.0)))

This is recursive, so may run out of space for large numbers.

The heart of the program is then:

(DE F (X)
    (PLUS (SQRT (ABS X)) (TIMES 5 (CUBE X))))

(DE LIMIT-F (X)
    (PROG (RESULT)
          (SETQ RESULT (F X))
          (RETURN (COND
                   ((GREATERP RESULT 400.0) (QUOTE TOO-LARGE))
                   (T RESULT)))))

(DE TPK (NUMS)
    (MAPCAR (FUNCTION LIMIT-F) (REVERSE NUMS)))

MAPCAR is available so this was slightly simpler to write compared to Lisp 1.5.

Finally, a driver program doing the I/O:

(DE MAIN ()
    (PROG (NUMS)
          (PRINT (QUOTE "Please enter 11 numbers in a list"))
          (SETQ NUMS (READ))
          (PRINT (QUOTE "Results are"))
          (RETURN (TPK NUMS))))

To run, we load the file onto the file system using the techniques discussed in a previous post. When we run Lisp we need to give it some more core - here 32k just to be sure. We load in the file with DSKIN and execute the main function.

.r lisp 32

ALLOC? 

*(DSKIN (TPK.LSP))

CLOSE 
IMPROVE 
BABYLON 
SQRT 
CUBE 
F 
LIMIT-F 
TPK 
MAIN 
FINISHED-LOADING 
*(MAIN)

"Please enter 11 numbers in a list" *(10.0 -1.0 1.0 2.0 3.0 4.0 4.3 4.305 4.303 4.302 4.301)

"Results are" 
(399.88630 TOO-LARGE TOO-LARGE TOO-LARGE 399.60864 322.0 136.73204 41
.414213 6.0000000 -3.9999999 TOO-LARGE)

The primary manual for Stanford Lisp 1.6 can be found in LISP.WD[S,DOC].

The Computer History Museum Software Preservation Group has a detailed history of Lisp, including a page on Lisp 1.6 with several versions of the above manual in PDF format, and information on versions derived from this.

A simpler introduction to Lisp of this area can be found in Clark Weissman's LISP 1.5 Primer, which is also available at the Lisp history page above.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.

SAIL was a combination of work done on two languages. The first was Gogol, which was a simplified version of Algol 60 for the PDP-1. Not much information on this remains apart from a list of its error messages.

The other source - primarily for its associative arrays - was the LEAP language, which was written by Jerome Feldman and Paul Rovner for the Lincoln Labs Tx-2 machine; there's a paper describing this at the ACM.

The compiler was written by SAIL members Don Swinehart and R. Sproull, with the first version being available in November 1969. As the manual puts it

SAIL in a sense has something for everyone. For those who think in ALGOL, SAIL has ALGOL. For those who want the most from the PDP-10 and the time-sharing system, SAIL allows flexible linking to hand-coded machine language programs. For those who have complex input/output requirements, the language provides complete access to the I/O facilities of the PDP-10 system. For those who aspire to speed, SAIL generates fairly good code.

It achieved its goal, with wide use at Stanford and it spread to other PDP-10 sites.

In 1980, there was a commercial spin off of SAIL called MAINSAIL. This was cross-platform, with initial versions on other PDP-10 and -11 operating systems, and possibly VAX and System/360 also. The language had some success (one user was VLSI Technologies for electronic design tools) and was available for at least HP-UX, AIX and IRIX up to the early 2000s. Bitsavers has some documentation.

Like every other Algol 60 implementation, program format and I/O is slightly different, so to set the scene, here's a simple hello world program.

BEGIN
    INTEGER I;
    COMMENT Print Hello World 5 times;
    FOR I ← 1 STEP 1 UNTIL 5 DO
        OUTSTR("HELLO, WORLD" & '15 & '12)
END PROGRAM

This follows the typical Algol 60 block structure, using BEGIN … END and having statements separated rather than terminated by semicolons, so the last statement in a block should not have a semicolon at the end. Comments are statements as well so need to be terminated depending on their position.

The assignment operator ← is an arrow, which was typeable using the Stanford keyboard; on a teletype you could use _ instead. A ↔ B would swap the values of A and B.

For I/O there is an extensive set of routines that can handles files and different devices, but for console I/O you can use OUTSTR to print strings (adding a CR/LF line terminator in the above example) and read a line of input to a string with INCHWL.

Real, integer and boolean types are provided, along with arrays. Strings are internally represented as a two word value, the first being a character count and the second a pointer to an array of 7 bit characters. The body of the OUTSTR shows concatenation of a string literal with two characters, CR/LF, to produce a new string.

Procedures take value or reference parameters, can be called recursively (with the keyword RECURSIVE PROCEDURE). Procedures can also be passed into other procedures.

The LEAP facilities allow sets (PUT item IN set) and associative arrays (MAKE key ⊗ object ≡ value). You can then do search operations on these using FOREACH. An example adapted from the manual:

FOREACH x,y,z SUCH THAT father ⊗ x ≡ y AND father ⊗ y ≡ z DO
    PUT z IN grandfathers

Macros are similar to C's macro processor: you can define constants and then they get expanded in the program when used:

    DEFINE ARRAY_SIZE="11";
    ...
    INTEGER ARRAY DATA[1:ARRAY_SIZE];

or to take parameters.

    DEFINE APPEND(x, y)="x ← x & y";

Let's use the compiler to run the TPK algorithm. The source code can be found here. This can be loaded onto the disk using the techniques described in this post.

The full program looks like this:

BEGIN
    COMMENT TPK algorithm in SAIL for WAITS;

    REQUIRE "{}{}" DELIMITERS;
    COMMENT Size of array to use for TPK;
    DEFINE N = {11};
    COMMENT Macro definitions to print a string with CR/LF at the end;
    DEFINE CRLF={('15 & '12)};
    DEFINE TYPE(MSG)={OUTSTR(MSG & CRLF)};

    REAL PROCEDURE FN(REAL X);
    BEGIN
        RETURN(SQRT(ABS X) + 5*X↑3)
    END;

    COMMENT Main program;
    INTEGER J;
    REAL ARRAY A[1:N];
    TYPE("Please enter 11 numbers");
    FOR J ← 1 STEP 1 UNTIL N DO
    BEGIN
        STRING REPLY;
        BOOLEAN BRCHAR;
        REPLY ← INCHWL;
        A[J] ← REALSCAN(REPLY, BRCHAR)
    END;
    TYPE("Results are");
    FOR J ← N STEP -1 UNTIL 1 DO
    BEGIN
        REAL RESULT;
        RESULT ← FN(A[J]);
        IF RESULT > 400.0 THEN
            TYPE("Too large")
        ELSE
            TYPE(CVF(RESULT))
    END;
END

One additional trick is used for macros:

    REQUIRE "{}{}" DELIMITERS;
    DEFINE TYPE(MSG)={OUTSTR(MSG & CRLF)};

The first line redefines the start and end delimiters for macros to be curly brackets rather than double quotes; if this is not done, any double quotes in the text being expanded, for example a string constant TYPE("Hello") would not work.

The procedure FN shows use of ABS as a unary function, and ↑ as the exponentiation operator.

We use several type conversion functions here. REALSCAN takes a string and a boolean and returns a real value if found, otherwise it will set the boolean to true (we ignore this in the program). CVF conversed a real to a string.

To compile and run, assuming the program is stored in a file tpk.sai, use exec:

.exec tpk

SAIL: TPK    1
LOADING

LOADER 2K CORE
EXECUTION
Please enter 11 numbers

Errors found in compilation are handled interactively. If for some reason I had put UNREAL PROCEDURE it would halt with

.comp tpk

SAIL: TPK    1
UNDECLARED IDENTIFIER: UNREAL
TPK, PAGE 1
01100           UNREAL
                       PROCEDURE FN(REAL X);
^

At this prompt, you can press Enter to continue: in some cases it may be able to correct the situation but here it would ignore the statement. You could press E and it would open the file at that line in the SOS editor; T would do the same in TV. X would exit. Pressing ? shows a full list of what options are available

The main manual for SAIL can be found in SAIL.DCS[S,DOC] or on Bitsavers as a PDF.

Dan Swinehart gave a talk on the history of SAIL (and some background on its name) at a 2009 reunion - the video is at the Stanford Archives.

I welcome any questions or comments, and also especially any corrections if I have got something wrong. Please email me at rupert@timereshared.com and I will add it here and update the main text.