If you have Hercules version 4 (either Aethra or SDL) already installed on your system, you can skip this step.

Otherwise, type ./build-hercules.sh. If you are on MacOS add one of these two command line arguments depending on the package system you use

     --homebrew
     --macports

This will download hercules-helper, the Hercules source code and associated tools then build the system and install it under hercules/ in this repo. It takes 2-3 minutes on my system.

Type ./build-tss.sh. This will download the disk images and copy them to the dasd/ directory.

Type ./run.sh. It will check that Hercules is available and then start the main Hercules console. The red line saying Hercules is not running in an elevated mode is expected.

Open two other windows and connect via telnet to port 1052 on your local machine, eg by typing telnet 0 1052. The first window will be the operator console and the second the user console. In the screenshot below you can see this with Hercules on the left, the operator console on the top right and the user console in the bottom right.

TSS/360 before IPL. Source: Rupert Lane. License: CC0.

These telnet sessions must be connected before doing the next step.

Now type ipl 250 in the Hercules console to IPL (initial program load, ie boot the system). Press Enter in the operator console and you will get a ? prompt.

Type ls (meaning long start) to start the loading process. Answer the questions as shown below (<Enter> means just type the Enter key at this point)

ENTER PHY ADDRESS OF CARD RDR OR DEFAULT = EOB.
<Enter>
ENTER ADDR OF PAGING DISK
251
PRINT MAPS? 0 1 2 3...NONE IVM RESSUP BOTH
3
ENTER CODE FOR FUNCTIONS NOT TO BE LOADED.ALL FUNCTIONS WANTED = EOB
99
QUICK START REQUESTED?  IF Y ENTER ADDR  OF PACK FOR QUICK START DATA SET--N = EOB
<Enter>
DELTA DATA SETS?  Y OR N
n

It will then ask you if the clock is correct

CURRENT CLOCK VALUE IS 12/10/26 05.16.13 IS CLOCK CORRECT?

I normally just accept this by typing y, but you can change it by typing n and then following the prompt.

Finally the initial start up has completed and you will get a $ prompt. Type run to start the system fully, entering n to the bulk I/O question for now, and typing reply 1,ok to the next question.

$ run
 BULKIO REQUIRED?
n
   N ACCEPTED
05:16:20        SYSOPER0 NO DRUM PATH AVAILABLE
05:16:20        TSS00001 BATCH MONITOR HAS BEEN INITIALIZED
05:16:20 R=0001 SYSOPER0 VALIDATE THE SYSTEM HARDWARE CONFIGURATION. REPLY OK WHEN DONE.
reply 1,ok

It will then print

TSS370
 STARTUP COMPLETE,USERS MAY LOGON

In the user console (the second telnet window), press Enter and type logon tss,ibm to log on as user tss with password ibm.

The screen will now look something like the screenshot below. Note in the Hercules window I'm showing the system panel, you can switch between the Hercules console and panel by typing Esc. If you don't like the colours, edit hercules.cnf in this repo and change the line PANOPT MSGCOLOR=DARK.

TSS/360 after IPL. Source: Rupert Lane. License: CC0.

The prompt is an underscore: on a a physical teletype, this would have been followed by a backspace so the first character you typed would be underlined, which is a nice way of distinguishing user and system text on the printout. The terminal emulator allows you to correct mistakes with Delete and Control-U before pressing Enter.

Commands are 1-8 letters long: for example usage will print a summary of your resource usage so far.

Commands can take parameters, which are separated by commas and can be specified positionally or via keywords. For example, exhibit uid will show what users are logged on to the system.

exhibit uid
ACTIVE USER STATUS AT 09:36:38     12/17/26
USERID    TID TYPE SYSI
SYSOPER0    1 CONV  209 SYSOPER0    2 BACK    0 TSS*****   13 CONV  21F

To just show conversational users, you can set the type option.

exhibit uid,type=conv
ACTIVE USER STATUS AT 09:36:58     12/17/26
USERID    TID TYPE SYSI
SYSOPER0    1 CONV  209 TSS*****   13 CONV  21F

This could also be entered as exhibit uid,conv or even exhibit type=conv,option1=uid

Sometimes commands will prompt you for more information. If you want to stop the current program, enter ! as the first character of the line and press Enter. For example below I enter the print command without a file name and so it prompts for one; as I don't have anything to print I type ! to exit out.

print
 ENTER DSNAME
!

There is no online help, but explain can be used sometimes to provide more information about the last error message. Below I enter an unknown command foo and then get more information.

foo
 CANCELLED: SYMBOL FOO      TO BE LOADED NOT FOUND
explain
 NO MODULE WAS FOUND IN ANY OF THE DEFINED JOBLIBS CONTAINING THE SYMBOL.
  THE SYMBOL WAS EITHER NOT FOUND OR WAS CONTAINED IN A MODULE WHICH IN THE
  PROCESS OF BEING LOADED,HAD ALL CONTROL SECTIONS REJECTED

Let's enter and compile a simple hello world program in Fortran. Type edit source.hworld and it will print the initial line number 100 for this new file. Now enter the following program, using spaces not tabs. You can use Delete to correct any mistakes on each line.

        DO 1 J=1,5
1       WRITE(6, 2)
2       FORMAT(' HELLO, WORLD!')
        STOP
        END

To exit the editor, you need to use the END command, but you need to type an underscore first to signal this is a command rather than just text

To compile, type ftn hworld and to execute run hworld. Your session should look something like this:

edit source.hworld
0000100         DO 1 J=1,5
0000200 1       WRITE(6, 2)
0000300 2       FORMAT(' HELLO, WORLD!')
0000400         STOP
0000500         END
0000600 _end
ftn hworld
run hworld
HELLO, WORLD!
HELLO, WORLD!
HELLO, WORLD!
HELLO, WORLD!
HELLO, WORLD!
 TERMINATED: STOP

Let's take a look at our files now. Type pc? to print the catalog to the screen, ie do a directory listing. You will see a bunch of existing files and our source file is there

TSS*****.SOURCE.HWORLD,   ACCESS: RW

(The asterisks after the user id TSS are to pad it to 8 characters).

By typing line? source.hworld you can list the contents of this file to the terminal.

You'd expect also to see an object file as a result of the compilation, but there's no obvious candidate. In fact, the object code has been added to this library file

TSS*****.USERLIB,   ACCESS: RW

TSS/360 collects object code into libraries like this and when you type RUN to execute it, does the run time dynamic linking needed.

There's also a listing file produced by the compile which you can view by typing line? list.hworld. But looking at the catalog we see this strangely named file:

TSS*****.LIST.HWORLD.G0000V00,   ACCESS: RW

This is a generational data group, a way of keeping several older versions around. Compile the source again by typing ftn hworld and then pressing Enter when it says DEFAULT TO REPLACE PREVIOUS MODULE. Do a pc? again and you will now see two files

TSS*****.LIST.HWORLD.G0000V00,   ACCESS: RW
TSS*****.LIST.HWORLD.G0001V00,   ACCESS: RW

These files can be accessed by the full names given above, but you can also use list.hworld(0) and list.hworld(1) to see the latest and previous version.

As you can see, TSS/360 handles files quite differently from what we've seen on other operating systems - it even gives them a different name, calling them data sets. In a future post I will go into more detail.

Type logoff in the user console. This will trigger a bug in the system where the logoff accounting procedure does not run correctly. There is a way to work around this, however. Disconnect your user console telnet window (close the window or type Control-] and then quit). Switch to the operator console and type run twice to clear the error. You can now reconnect the user console and logon again if desired.

To shutdown the system, switch to the operator console and type shutdown. It will print a message saying this is completed. Now go to the Hercules console and type quit.

Bitsavers has a comprehensive set of manuals for TSS/360. Most of these are references, but a tutorial style guide that extends on the above can be found in Introducing TSS/360: A Primer for FORTRAN Users

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.

By 1964, IBM had experimented with creating time-sharing systems, such as this one for the 7090, and had helped provide the hardware needed for MIT to produce CTSS, but had never released anything to customers. As MIT was planning for its replacement for CTSS, IBM assumed that they would use the new System/360 as their hardware. But MIT did not like the initial design of the computer, as it lacked many of the hardware support features needed for time-sharing like address translation. They, together with AT&T, decided to go with General Electric, and eventually produced Multics for a modified GE-635 computer.

IBM was not happy about this outcome, perceiving the loss of university and scientific support as detrimental to the long term success of System/360. In August 1965 they announced the System/360 Model 67, which had some of the hardware features missed by MIT, and an operating system called TSS/360 to go with it.

Details from a TSS brochure. Source: Bitsavers

The hardware was available in 1966, but the planned shipping date for TSS in mid 1967 was missed, despite IBM throwing large numbers of programmers at it. An experimental release came in October of that year, but performance was not great (one attendee of CHM's conference on time-sharing remembered walking out of a demo in disgust when the system had not finished booting up after 30 minutes).

Potential customers drifted away to other operating systems such as VM and MTS, and to other machines, and only a handful of sites stuck with TSS. IBM did continue to improve it, boosting its performance and reliability, replacing the scheduling algorithm and command set, but decided to switch to TSO under MVT/MVS as their preferred implementation of times-sharing in 1971. Support for TSS continued for a while. including a version for newer hardware called TSS/370, but it was pretty much extinct by the mid 1970s.

TSS/360 consists of a central memory-resident supervisor that controls tasks: each user can have one interactive task and any number of non-interactive/batch tasks running, and the system time-slices between them; later versions had a dynamic scheduler that could be adjusted by the system owner. It's possible to have more than one CPU in the system.

TSS was designed to run only on System/360 and later models that supported dynamic address translation. The system uses virtual memory, called virtual storage by IBM.

Data is stored in a catalog and is accessed via the concept of data sets which may span multiple files. Data sets can be in different formats, such as sequential, indexed sequential and partitioned, and there is provision for saving older versions of files automatically.

User commands include logon, profile management (settings and synonyms for commands), data set management and editing, language processors like Fortran, debugging and bulk I/O requests such as printing. Users can also write their own commands to extend those provided by the system. It's even possible to replace error and information messages produced by system programs with your own messages.

Users are divided into several classes, such as system managers, operators and regular users, with different commands being available to each group. It's possible to share data sets between users. Memory protection exists between tasks, with the ability for reenterable code to be shared between them.

Dynamic loading is used to start programs, allowing libraries and data sets to be associated with tasks at run time.

Jay Maynard has preserved version 3 of TSS/370 at this website. This includes the installation tape, a set of installed disk images and the system source code (excluding the source of some copyrighted compilers). This is the only known version that is available.

Bitsavers has a nearly complete collection of IBM manuals for TSS, covering both early and later versions.

The above software kit works on Hercules, allowing you to IPL (boot), login and run tasks. There are several bugs, such as user logoff not working properly that are probably underlying issues with TSS, but it is usable. With Hercules running much faster than the original hardware, performance is not an issue today.

Richard Cornwell has written a System/360 and 370 emulator which is available in his sims fork of simh. I've got this booting using Jay Maynard's disk kits but I have not been able to get remote user logins working yet.

I plan to cover the following topics as we look closer at TSS/360.

• A quick tour of running TSS/360 on Hercules.
• Data sets.
• Users and security.
• Tasks and user customisation.
• Getting data in and out.
• The file editors.
• Programming in Fortran.

A note on naming: I will generally call the operating system "TSS/360" in these pages, although IBM also used "TSS/370" and just plain "TSS" in their documentation.

Again, Emerson Pugh's book IBM's 360 and early 370 systems is a great source for history. You can read it online at the Internet Archive.

Tom Van Vleck gives an account of TSS/360 and VM from the perspective of a Multics developer at multicians.org.

IBM's IBM Time Sharing System Concepts and Facilities is a good first read on TSS/360's architecture and key concepts. Several versions are available on Bitsavers, with the most recent here.

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.

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.