The ICL 1900 machine that we had on site was a bit confusing because it was in the process of being upgraded from a 1902T to something better. It was, by today's standards, a dinosaur. It was composed of several huge blue metal cabinets, all connected together by thick cables that ran under the false floor. Its connection to the human world was through none other than a standard 110-baud teletype. Part of my job was making sure that this cream-coloured oversized typewriter was supplied with paper. If the machine tried to communicate with us and there was no paper in the teletype, the message would be lost forever. I have a vague memory of trying to read something that had been printed around the rubber roller, so I guess I must have neglected my duties at some point.
The inside of the 1900 is still a mystery to me. It seemed to have two CPU boxes or perhaps one wasn't actually in use. These boxes were the largest in the room, each measuring roughly 3 metres in length by 1.5 metres high by 1.5 metres thick. One of the boxes was connected to the teletype, and also to another large box across the room, whose name escapes me. It was the peripheral controller, and was directly connected to a row of disk drives and a block of magnetic tape decks. The front panel of the CPU contained hundred of lights — not LEDs, but little flickering neon lights. Whenever the beast crashed, we had to draw a light map to give to the engineers. It was very tedious, and I doubt they were ever used for anything. After all, the thing would sometimes crash if you bumped against it. There was talk of it having a core store made of thousands of ferrite rings mounted on a cross-wired loom, but no one seemed to know for sure if that's what it used for memory, or whether it used transistor or IC-based memory. Whatever it used, we called it "core" anyway; our one had a capacity of 96K — not bytes like today's machines, but 24-bit words. Each word was composed of eight 3-bit digits, each of which could have a value from 0 to 7, so it was an octal system.
Executive
A typical Sunday night would see us powering up the machine, and loading the master control program which was called Executive. This was done by first mounting the main system disk in one of the drives, waiting for it to spin up to speed, and then pressing something or other on the controller box. The disk light would flash while the hardware pulled some code from a very specific part of the disk and executed it. If this worked (it often needed a few retries) then within a few minutes, the main part of Executive would be in core. At this point the teletype would rattle as Executive announced its presence. I have a vague memory of it asking for the date and time, but the details are lost. Executive was a program just like any other, but a rather privileged program which was able to load and delete other programs. It had two-letter commands, and responded to them by saying either O.K. or Error X, where X was a letter from A to Z. There was an error list above the teletype so we could tell what was going on. I found it easier to just remember the codes. Error A was my favourite because it meant two different things and you had to guess which one. It either meant "Program not loaded" or "Program already loaded". Error C meant "No such command". Error J was "Device wronged or does not exist". Error P was, I think, "Device not ready". That's all I can remember. It was twenty years ago, after all.
Magnetic Disks
The disk drives were like washing machines in a launderette. Each one could take an exchangeable disk cartridge, about 16 inches in diameter with something like 9 individual platters. They were heavy, and carrying more than one was a difficult feat for poor little me. These cartrides each had a capacity of 60 megabytes. This seems absolutely ridiculous now, but there it is. They were called EDS60s. Each one had a six-digit octal label called a cartridge serial number (CSN). Since octal was designated by an asterisk, these cartridges were called such interesting names as *604705 and *000002. The system disk was called *777777 which is the highest octal number you can have in six digits.
Magnetic Tapes
Each magnetic tape could hold a single file whose name was recorded on the tape header. Each tape also had an octal serial number, of course. Such appetising names as *5026, *467 and *730 were common. We didn't need to know what was on the tapes, just what tapes were required and in what order. The drives that these tapes were mounted on were amazing devices. They stood about six feet tall, and must have weighed a ton. The tapes were mounted on the top spool, and threaded through a gate, around various rollers. These rollers had to be kept clean and the day-shift trainee's first job was visiting each deck with a lint-free cloth and a can of some kind of lethal alcohol which could get you high very quickly if you breathed the fumes. The tape had a beginning of tape marker (BOT) and an end of tape marker (EOT). These were little sticky reflective strips that the deck used to detect the start of the recordable tape. After mounting a tape and pressing the GO button, a vacuum would be set up behind a glass panel that would act as a buffer to allow the tape to move freely without any mechanical drag. Most of the failures of these decks were attributed to loss of vacuum. If the tape was in use, this would be followed by a message like this:
#PROG; MT22- FAIL *10
The octal code was an indication of the kind of failure, but we didn't care what the reason was. This could mean the loss of four hours work, and often saw the trainee running back to the tape store to fetch an armful of tapes that he had just painstakingly put away. It could also mean the loss of our next coffee break, and maybe even the loss of company money if the job was not completed on time. In every way, tape decks represented loss to all who came in contact with them. Yet, I'm still awestruck that these monsters ever worked reliably at all. The tape itself was half an inch wide and had nine tracks — eight for the data and one for parity, a simple data-integrity checking system. I never really understood how it worked, but Executive was able to detect errors and correct them in-flight. When this happened we would be greeted by a long rattling display of:
#EXEC; MT22- 8I
#EXEC; MT22- 8I
#EXEC; MT22- 8I
#EXEC; MT22- 8I
#EXEC; MT22- 8I
#EXEC; MT22- 8I
#EXEC; MT22- 8I
I remember how we could tell from the coffee room, by listening to the sound of the console, that it was "just a tape repeating again".
Programs
Programs were designated by a # character followed by the four-character name. So, a message from Executive would look like this:
#EXEC; DISP- Something
where something was always extremely terse. There was such limited memory that everything was abbreviated. Everything was also in uppercase. Programs were, like today, composed of a collection of words which were stored on disk or tape, and read into core as needed. There was an overlay system whereby only the parts of code that were needed at any one time would be called into core, overlaying parts that were no longer needed. This was a kind of primitive predecessor to virtual memory. It was swapping without the automation — a program had to be coded explicitly to swap bits of itself in and out. Each program started with a range of words that had special meaning. One of the words contained 24 switches or flags which had a meaning only to that program. For example, switch 1 might tell the program that it should generate a certain kind of output. Switch 2 might mean that it should do some extra special processing. #EXEC had its own switches which could be used to control some of the basic operating parameters, but I can't remember what they were. To run a program, first you had to load it into core. The first thing you would do was type in PR to get a listing of programs that were loaded, so you could see if there was enough free core. This would result in a printout something like this:
1 #FRED S 2048
2 #XKEE R 3072
3 #OUTA R 2058
Each program occupied a slot in the core. The name of the program, its status (running, suspended etc.) and the amount of core it was taking up were also shown. To load a program, you had to get Executive to find it. The command was:
FI#PROG#AREA
where #PROG was the name of the program, and #AREA was the name of a file where programs were stored. Most programs resided on the system disk, *777777, but some of the larger or least-used ones were stored on magnetic tape. In the case of the above command, Executive would load a little searching program which would be identified by the name of the program you were looking for. This program would look for a file called PROGRAM AREA on each mounted disk, and failing to find it, it would turn to the tape drives and have a look at the header of each tape. If it found a tape called PROGRAM AREA it would then read down it to find program #PROG. A nice feature was that most program tapes were actually labelled PROGRAM TAPE, which meant that to find a program from tape you would type:
FI#PROG#TAPE
I thought that this was quite elegant at the time. No one else seemed to notice this kind of thing so I had no one to share my excitement with.
If the search program successfully found the program you were looking for, it would load it in and then disappear from core. This would result in the program displaying a message like this:
#PROG; HALT- LD
The program has now loaded and halted execution. Failing to find your program, the little search program would sit in core under the alias of the program it was wired to search for. You could then mount another disk or tape, and type:
GO#PROG
to make it do another search cycle. One trick we used often was to find #FRED, a program that did not exist and was easy to type. By doing this, the little search program (now called #FRED) would look at all the tape headers. This was the only known way to get the system to read tape headers so that you could find out the names of various tapes that were mounted. In the early days, there was no tape-labelling command in Executive. You had to find a special program called #XQMY, modify certain key words of it to be the octal codes representing the characters of the required label, give it the tape deck to use, and then run it. Talk about convoluted! The special words defaulted to the values for SCRATCH TAPE which meant that you could easily label any tape as scratch, meaning that certain programs would pick it up and start using it without any operator intervention.
Once your program was ready in core, you could run it. There were ten so-called entry points which you could choose from, numbered 20 to 29. I believe that these ten words were organised as a kind of jump table into the correct execution points of the code, because Executive used to let you GO a program at any word address if you wanted, usually with the result:
#PROG; ILL- X
which was an efficient way of saying "this program has executed an illegal instruction and will be shut down".
The ten entry points had predefined meanings that the programmer was supposed to adhere to for consistency. I used to know them all, but time has faded my memory:
20 - Normal execution.
21 - Can't remember.
22 - Can't remember.
23 - Can't remember.
24 - Can't remember.
25 - Abort execution.
26 - Skip current task and do something else.
27 - Restart the program (often used after a tape failure).
28 - End batch.
29 - Program-specific.
Just typing GO#PROG without a number caused the program to execute from the next instruction. This was usually used after suspending a program.
Input and Output
Data was introduced into the system by way of punched cards, and results were printed on a line printer. The card reader was huge, of course, and had a tray thet you could put a big stack of cards on — the hopper — and a tray that received cards after they were read — the stacker. Strangely, the hopper was below the stacker, and the cards were read by being pulled upwards across a photocell array of some sort. Each card was punched with 80 columns of rectangular holes and therefore it carried this much data:
The biggest job I remember running required about six boxes of cards. Each box contained something like 500 cards so the whole set was about 3000 which makes about 240KB of data. It took ages to feed them in, and they would sometimes (often) tear and wreck, requiring us to go around to the punch room and re-punch them. Sometimes they wrecked so badly that it was impossible to read them to re-punch them, so the job was abandoned until morning. And all because of eighty bytes of data! From where I'm sitting now, it seems like it was just too much hard work to employ a computer to do anything useful before the late eighties. I'm probably just spoiled. Needless to say, the introduction of VDU screens made life much easier for everyone, and must have saved a lot of trees too, but we were still using punched cards when I left the company in 1988. It was just too much trouble to change all the systems. Of course, they were gradually changing them, but it took many years. I don't think they're using cards there anymore!
You can find more information on the ICL 1900 systems and their replacements here, courtesy of Keith Smith.
Back to ICL Mainframes