The executive was E3RM (for small 1900's 1901/2) and E6RM for the big beasts (1903T, 1904, 1906). The small machines were designed in Stevenage (Hertfordshire), while the large ones came from West Gorton (Manchester). In general a user program written on one machine was binary compatible with the other type of machine as the 1900 order code was the same.
ICL programs on 1900 traditionally started with an X so that they could be distinguished from user programs (although a user could have a program that started with an X, but why?). The big flaw with the exec / program name relationship was when multi-programming arose. How could you have 2 programs of the same name loaded in the system. The problem was solved in E3RM/2903/ME29 by using 'slot' numbers. The slot refered to an instance in a process list table. So you could have multiple copies of the same program loaded in different slots.
Some utility programs:
- XPJ1 - Format a hard disk
- XPJ2 - Create the System Control Area to UDAS (Unified Direct Access Standards)
- XPJC - Allocate / Deallocate a file
- XPJW - Archive files
- DMAP - Disc map
- XSDC - Sort
- XPJZ - Re-organisation generator for Index sequential files
- XPLM - Plan compiler
- XPCK - Consolidator
- XEKB - COBOL Compiler
- XFAE - Fortran Compiler
- XALE - Algol Compiler
- XPJD - File list print (not as good as DMAP because DMAP sorted the list into alphbetic order)
- XPJL - File block print
- XPEU - Program library manipulation
1900 Program architecture
A program was made up of a number of 24 bit words (each byte was 6
bits). The following words are reserved:
- 0-7 The accumulators (registers)
- 8 NIPR (Next Instruction Program Register)
- 9-19 Reserved (I can't remember but some were used for transient copies of the floating point register used when the process was not running)
- 20-29 Program entry points. As a programmer you could choose where the program would start. I think 20 was for cards, 21 for paper tape and 22 for MS.
- 30 The switch word. ON#abcd 3; OFF#abcd 4
- 31-44 Reserved (I think 31 was a system status word and used by MS#abcd=xxxxxx
- 45- Data area.
The executive made no distinction (and offered no protection) between user data and intructions. There were no "read only" parts of the user program memory. Program instructions had the following layout (values in octal):
- 3 bits for accumulator (0-7)
- 7 bits for the instruction code (in range 0 to 177)
- 2 bits for a modifying accumulator (0=no modifier; 1-3 add the contents of this register to the address in bits 12-23)
- 12 bits for an address.
As the address part of an instruction was only 12 bits, this gave an addressable range of 0 - 4095. Hence to index arrays to Upper variables / presets (that is with an address > 4095) you had to use a modification accumulator or an SMO instruction (supplementary modifier). I can't remember all the instruction codes but the basic stuff was:
- 000-127 (these are hardware type instructions);
- 000 LDX
- 023 OBEY
- 010 STO
- 060 BRN
- 100 LDN
- 130-137 (floating point; could be hardware or synthesised by the Executive depending on hardware fitted)
- 140-177 Extracodes - always performed by the Executive
- 140-147 on most 1900 these cause ILLEGAL X; They are used by George 3 and TME on ME29
- 150-157 Input/Output
- 157 PERI (initiate peripheral)
- 156 SUSBY (suspend if peripheral busy)
- 160-167 Program control; I think 160 was display; 161 was halt
- 163 I think was sub program; 164? 165 was GIVE (get date, time, memory size)
- 166 RRQ (read / write the program request slip)
- 170-177 ILLEGAL-X (except on George 3 machines)
Every program had a request slip (usually 16 words long) which was generated by the consolidator. For programs written in COBOL and Fortran, consolidation was automatic. If you wrote in Plan, you had great control over the final "binary" output. The request slip contained information like:
- The program name
- The priority (max value 99)
- The trusted status
- Initial I/O device to grab
- Initial memory requirements
The trusted status used a code of Q, R, S and T. Q allowed a program to read the System Control Area. S allowed a program to rewrite the system control area. T was for George 3 and R allowed a program to control another (a lot like strace on Linux). I wrote an 'R' trusted program so I could reverse engineer some of the disk utility programs supplied by ICL when I was a customer.
What was the consolidator for?
The consolidator was a linker. The compilers produced semi-compiled output, which the consolidator then took and added any subroutines from the subroutine library before producing the executable binary.
When you typed Fi#abcd#wxyz the exec loaded a bootstrap program which it then executed. The bootstrap would 'find' the program (from a library if necessary) and overwrite itself. The user program was always automatically executed by the bootstrap but Word 18 of the user program had a SUSWT 'LD' instruction. This caused the exec to come up with the message #abcd HALT-LD
The operator would then set any switches (or maybe even do alts as in AL#abcd xxxx yyyyyyy - This altered word xxxx of the program to value yyyyyyy) and issue a GO command. A GO on its own would start the program at the next instruction. If the program only had one entry point and didn't need operator intervention then the program could be patched so that the SUSWT at word 18 was replaced by a NULL instruction. This gave 'automatic' entry for the program.
The replacements for large (E6RM) 1900 type systems
DME (Direct Machine Environment) was developed so that 'legacy' (that is 1900 range software) could run on 2900 (dubbed New Range) equipment. This was only possible on later systems which were microcode based (S3 range). These were based around the 2966 type system. The early 2900's (2980 type) ran native VME with hardware decoding so 1900 emulation was not possible.
The issue then arose of how do we migrate the legacy 1900 customers on DME to VME? Hence the advent of CME (Concurrent Machine Environment) which allowed DME and VME to co-exist (and run) concurrently on the same platform. CME was basically microcode which I suppose provided similar functionality as Vmware does today.
The replacements for small (E3RM) 1900 type systems
The replacements for 1901, 1901A,1901T and 1902 was a bit different. The new hardware was based on a 32 bit architecture with the machines being called 2903 and 2904. They ran all the 1900 type programs but also had DDE (Direct Data Entry). This was a move away from the old days of punched cards and paper tape.
The next big move for smaller systems was the ME29 (Machine Environment 29). This was a 32 bit architecture but ran 24 bit code. 3 models were manufactured, the 37, 45 and 54. The model 54 was the fastest and this was achieved by using hardware instruction decode. The ME29 had its own operating system, TME (Transaction Machine Environment). Again you could run your legacy 1900 Apps (as we had as a customer, 1901T ->ME29) but it also brought lots of other facilities:
- Filestore with directories (not hierachical though like Unix or Windows)
- MAC (Multi Access Computing)
- TP (Transaction Processing)
- DDE (Direct Data Entry)
- RAPID (A built in Database / Development System)
- CL (Control language: A poor man's version of VME SCL, but better than George 2 JCL)
The TME executive was huge when compared to a 1900 exec. The main increase in size came through the support of MAC/TP/RAPID/Filestore. Still, having staff using terminals rather than looking at line printer output was fantastic. In the old days (1900) a processor was either executing in usermode or exec mode. Now we had leaf mode! All these wonderful new facilities were known as foliage (hence leaf mode). The group 14 instructions (140-147) were used in leaf mode.
The next issue was how to migrate ME29 users to VME. ICL produced a small VME system called DM1. The system came in a number of similar sized units and looked like some sort of storage heaters! The DM1 could run CME* (CME star). The main difference between CME and CME* was that CME* ran TME as a VME VM (virtual machine). Around about 1987 ICL also experimented with running Unix as a VME VM (but that never took off - ICL's Unix offerings did though in a big way).
VME systems are still around today mainly used by big corporations and Government departments. The latest technology trend is to run VME on Intel based processors.
Keith Smith
Back to ICL 1900 Series