OS4000

OS4000

Developer	GEC Computers Ltd.
Written in	Babbage
Working state	No further development, but still supported
Source model	Closed source
Initial release	1977 (1977)
Latest release	6.5 / 1993?
Marketing target	Minicomputer, Process control, Real time, multi-user, Time-sharing, Batch processing, Data communications
Available in	English (UK)
Platforms	GEC 4000 series
Kernel type	Hardware and Firmware
Default user interface	CLI - OS4000 JCL
License	Proprietary

OS4000 is a proprietary operating system introduced by GEC Computers Limited in 1977 as the successor to GEC DOS, for its range of GEC 4000 series 16-bit, and later 32-bit, minicomputers. OS4000 was developed through to late 1990s, and has been in a support-only mode since then.

History

The first operating systems for the GEC 4000 series were COS (Core Operating System) and DOS (Disk Operating System). These were basically single-user multi-tasking operating systems, designed for developing and running Process control type applications.

OS4000 was first released around 1977. It reused many of the parts of DOS, but added multi-user access, OS4000 JCL Command-line interpreter, Batch processing, OS4000 hierarchical filesystem (although on-disk format very similar to the non-hierarchical DOS filesystem). OS4000 JCL was based on the Cambridge University Phoenix command interpreter.

OS4000 Rel 3 arrived around 1980, and included Linked-OS — support for Linked OS4000 operating systems to enable multi-node systems to be constructed. The main customer for this was the central computing service of University College London (Euclid), where a multi-node system consisting of a Hub file server and multiple Rim multi-access compute server systems provided service for over 100 simultaneous users. Linked-OS was also used to construct fail-over Process control systems with higher resilience.

OS4000 Rel 4 arrived around 1983, and upped the maximum number of user modules to 150 (again, mainly for the University College London Euclid system), together with an enhanced Batch processing system. It also included support for the GEC 4090 processor, which introduced a 32-bit addressing mode.

OS4000 Rel 5 introduced a modified version of the OS4000 filesystem called CFSX, in order to allow easier use of larger disks. The initial Rel 5 only supported the CFSX filesystem, but support for the original CFS1 filesystem was reintroduced as well quite quickly.

OS4000 Rel 6 introduced support for dual processor systems (GEC 4190D).

OS4000 was developed in the UK at GEC Computers Borehamwood offices in Elstree Way, and at GEC Computers Dunstable Development Centre in Woodside Estate, Dunstable.

Architecture

The architecture of OS4000 is very heavily based around the features of the platform it runs on, the GEC 4000 series minicomputers, and these are rather unusual. They include a feature called Nucleus, which is a combination of a hardware- and firmware-based kernel, which cannot be altered under program control. This means that many of the features typically found in operating system kernels do not need to be included in OS4000, as the underlying platform performs these functions instead of the operating system. Consequently, there is no provision for running privileged mode code on the platform—all OS4000 operating system code runs as processes.

Nucleus supports up to 256 processes, and schedules these automatically using a fixed priority scheme. OS4000 lives entirely within these processes. A set of system tables are used to configure Nucleus, and access to these system tables can be granted to processes which need to alter the configuration of Nucleus, e.g. to load new programs into processes, adjust the Nucleus scheduling for time-shared processes, etc. The system tables tell Nucleus which processes are permitted to communicate with each other, and these are updated as processes are created and destroyed, e.g. when users login and logout. All I/O is performed directly from processes, and the system tables identify which processes have access to which peripherals and handle peripheral interrupts. For example, a device driver for a disk controller is a process, which is responsible for issuing commands through Nucleus to the disk controller, and handling the interrupts passed back from the disk controller via Nucleus, and the system tables will explicitly state that process has access to that disk controller. The system tables will not grant this device driver access to any other peripherals. In the event of a process stopping or crashing, Nucleus looks up its owner process in the system tables, and informs it. The owner process can then take the decision to let the system continue running without that process, or to take out the system (like a Unix panic), or to take some action such as reload and/or restart the process. Functions such as filesystems, store allocation, terminal drivers, timing services, etc. also exist as separate processes.

Nucleus implements a segmented memory system, with processes having their access to memory segments defined by the system tables, which is maintained by OS4000. OS4000 provides a memory system which handles both store-resident memory, and virtual memory backed by disk which is known as overlay, with overlaying being performed at the segment level. OS4000 also inherited grouped segments from DOS, where a group of segments were to be overlaid and retrieved as a single group, but this feature was very little used in OS4000. A process may use any mixture of resident and overlayable segments, although a process performing real-time tasks would normally be designed to only use resident segments.

OS4000 supports a fully mixed set of process scheduling within the same system, from hard real-time processes, through soft real-time, time-shared, and background. Given that OS4000 also includes full program development and test/debug facilities, this made OS4000 ideal for developing and deploying real-time applications such as process control and high speed (at the time) data communications all within one system.

Filesystem

OS4000 uses its own proprietary filesystem. The filesystem is extent based, and variable block size — different files can be created with different blocksizes, ranging from 256 bytes to 16,384 bytes in 256-byte multiples.

When a file is created the initial disk allocation is specified and if required what later allocations are permitted. Most files are given discrete (fragmented) allocations although a file can be created with a contiguous (single and fixed size) allocation.

The filesystem is hierarchical, with components limited to 8 characters and the "." (period) used as the component separator. OS4000 JCL limits characters in file path components to upper case letters and numbers only. Each file path starts with a context pointer which is a name which refers to a position in a filesystem, followed by zero or more catalogues (equivalent to Unix directories), and ending with a filename. Each disk on the system contains a separate and independent filesystem, and the volume name of a disk is the same as the name of its top level catalogue or master catalogue. There must be one disk mounted with a volume name of SYSTEM which contains specific files required by OS4000. In larger systems, there will usually be additional disks containing user files, data files, etc. although these can all coexist on the SYSTEM disk, space permitting. Users are each given a set of initial context pointeralloweds which each point to a catalogue on a filesystem, and users can only see the filesystem hierarchies below their initial context pointers. Systems are usually configured so that unprivileged users cannot see other users files or the system's files, except for the system executables held in SYS. By convention, an area called POOL is available for all users, and enables the transfer/sharing of files.

The access rights for the owner of the file is different from the access rights for other users.

Files in an OS4000 filesystem are typed, which means that the filesystem can hold several different types of file, and understands how the contents are structured. Most common are logical files which contain a record structure. These are split into sequential and random files, with random files having all records the same length to enable seeking to record numbers. Finally, text and binary files are distinguished, mainly to prevent applications which expect textual data from accidentally using a binary file. This results in a set of logical file types identified by three letters, e.g. Logical Sequential Text is LST. The logical file types are LST, LSB, LRT, LRB. The converse to logical files are physical files, which are accessed block at a time, and these are known as Physical Random Binary (PRB) files. File types PST, PSB, PRT also exist in theory, but have the same capabilities as PRB and are not generally used. Additionally, there is a Logical Indexed Sequential (LIS) filetype, which is an ISAM file and always appears to be sorted on its key field, and a Byte stream (BYT) filetype, which was added in Rel 6.5 to better support the OS4000 NFS server. A filetype CAT is used to hold catalogues—it is actually the same as an LSB file, but can only be modified by the filesystem itself.

In addition to files and catalogues, there are 3 types of symbolic links. References (REF) can be created to point to another file or catalogue which creator of the REF can see through an initial context pointer, in either the same filesystem or another filesystem. Off Disk Pointers (ODP) are similar to references but can be created to point to a file or catalogue which cannot be seen through any initial context pointers, and creating an ODP is a privileged operation only available to the system manager. Support for Unix style symlinks (arbitrary text stored in a catalogue) was added in Rel 6.5 to better support the OS4000 NFS server, but symlinks can only be created and are only visible from NFS clients.

OS4000 also provides a non-hierarchical temporary filesystem. This supports exactly the same types of file as permanent filesystems, except for CAT, REF, ODP, and symlinks. The file contents are stored in dedicated temporary filing disk regions, but the file metadata is stored in memory. Each logged in user has a private temporary filing name space which cannot be seen by any other logged in user (nor even another logged in user with the same username). A user's temporary files are deleted when the user logs out (and implicitly if the system is rebooted). Temporary filenames start with a percent "%" or ampersand "&" and are limited to 8 characters.

Multi-access Environment

The following shows a short Multi-access login session:

SESSION STARTING OS4000 Rel 6.5 A036 on A7 SUN 17 MAY 2009 11:06:27 Logging in user SMAN password ID last used SAT 16 MAY 2009 22:21:43 STARTED - SUN 17 MAY 2009 11:06:31 OS4000 Rel 6.5 A036 on A7 SUN 17 MAY 2009 11:06:31 Only an authorised person should be logged in as SMAN READY EXAMINE EXAMINE version 305 Catalogue USER -------------------------------------------------------------------------------- DATA Odp GEST Odp IPL CAT MAILAREA CAT MCODE CAT OPER CAT PDA1 Odp POSTCAT Odp POSTFOLD CAT SEBACKUP LST SMAN CAT SOURCE Odp SOURCE1 Odp SPOOL Odp SUNDRY Odp SYS CAT SYSFILES CAT SYSGEN Odp SYSGEN1 Odp TEST Odp USEA Odp USEB Odp USEC Odp WORK Odp X25 CAT YBTS CAT -------------------------------------------------------------------------------- READY ***TO REMAIN ONLINE TYPE COMMAND WITHIN 5 MINS ***STOPPED CPU used: 3 ieu elapsed time used: 15 mins User SMAN terminal 2 logged out SUN 17 MAY 2009 11:21:31

In this case, user SMAN has logged in and issued the EXAMINE command. Then the session has been left to timeout through inactivity.

When a user logs in, the OS4000 JCL command interpreter SYS.COMM is loaded into the user's COMM process and started. This reads commands from the terminal. A number of system commands are built into SYS.COMM. In the case of a command which isn't built in, executable binary files are loaded into the USER process and run, and text JCL files are opened and processed directly by SYS.COMM itself. A user normally also gets an AIDA process which is privileged and used to load only trusted debugging programs.

Main Applications

Real-time Process Control accounts for over half of all the OS4000 systems deployed. Of these systems, steel production accounts for a significant proportion. The earlier of these Real-time Process Control systems were upgraded from DOS to OS4000.

X.25 Packet Switches account for a significant proportion of systems (although earlier GEC X.25 Packet Switches ran a special operating system called NOS which was a cut down operating system halfway between DOS and OS4000).

Civil Command and Control systems, e.g. Fire Service control systems interfacing the emergency telephone operator with the Fire Stations.

Prestel (UK) and the public Videotex systems used in many other countries, and many private Viewdata systems.

Multi-User Minicomputers, used in many Education and Research establishments.

Ports

OS4000 was ported to the GEC Series 63 minicomputer where it was known as OS6000. This required the addition of a software Nucleus emulation, as this was not a feature of the GEC Series 63 hardware. GEC Computers dropped OS6000, and the source code was given to Daresbury Laboratory who was the main user of it, and they continued to keep it in step with OS4000 releases for the lifetime of their two GEC Series 63 systems.

See also

• GEC 4000 series minicomputers
• Babbage (programming language)
• GEC Computers Limited

Further reading

• Burren, J. W. (1989). Project UNIVERSE : an experiment in high-speed computer networking. Oxford: Clarendon Press. ISBN 0198537239.
• Lavington, S. H. (2011). Moving targets : Elliott-Automation and the dawn of the computer age in Britain, 1947-67. London: Springer. ISBN 9781848829336.

External links

• GEC 4000 family, Which Computer?, May 1979
• The Centre for Computing History
• Bullet III - A Part of UK Network History