The NOS/VE operating system
Most of this information was extracted from a CDC NOS/VE information leaflet. The NOS/VE operating system core services were:
- 8-bit ASCII/64-bit word
- Large virtual address space
- Segmented virtual address space
- Implicit I/O
- Pure re-entrancy
- Shared memory data
- Shared files with record lock
- File access procedures
- File catalog structure
- Large real memory
- User assistance
- System tools
- CYber Implementation Language (CYBIL)
- System Command Language (SCL)
- Homogeneous system
The word size on the CYBER 180 was 64 bits, which provided very high computational precision; double precision arithmetic was available beyond this. The word could also contain eight ASCII characters, and full ASCII support was available in the languages and utilities of NOS/VE.
NOS/VE allowed tasks to have up to 8.8 trillion bytes (8,800 gigabytes) of virtual space (typically a job consists of one or more tasks. The actual space used by a program or data would usually be far smaller since the space was allocated as a series of pages; that is, pieces of memory.
The address space consisted of segments. Each task could have a maximum of 4,096 segments. Each segment had one or more pages; the maximum size of a segment was 2.1 gigabytes (the page size, which was variable, is discussed later). Segmentation provided a number of benefits, which derived from the separation of programs into separate instruction segments and data segments. A segment contained either data or instructions (code). There was a third type of segment, which linked a data segment to an instruction segment to form a job. This type of segment was called a binding segment. A segment never contained a mix of instructions and data. This was very different from most systems, which have a single segment with instructions and data jumbled together.
Segments had properties. A segment could be read-only which was typically used for data constants, or execute-only, which was used for programs. The third property was write access. When you separate data and programs, you gain three major benefits that were difficult or impossible on single segment systems:
These benefits are discussed next. A further benefit of segmentation was security. Since the hardware views all memory words as belonging to a segment, it checks to see if a program is referencing a correct segment (one with the correct binding and properties). If the reference is incorrect, the system can stop that reference and prevent damage and/or security violations.
This was a technique that allowed a FORTRAN or CYBIL programmer to equate an array in memory (part of the program) with a disk file area. Instead of writing and reading to and from the disk file, the programmer simply read or updated locations in memory, and the system read or updated the disk file as needed. Two benefits arose. First, the programmer did not have to write I/0 statements since he or she is just referencing memory, which makes programming productivity higher. Second, since the disk file was updated as needed, the system controlled the 1/0 flow to and from the disk in the most optimised manner. In most cases, this meant that the job ran faster. The result was programs that took less time to write and ran faster. Of the active systems at that time, IBM could do the same but it required costly and difficult assembly language routines. Under IBM, it was portrayed as an optimization technique for the most skilled programmer rather than the NOS/VE general purpose solution.
Re-entrancy was a technique that allowed more than one user to execute the same instructions (piece of program) at the same time. This saved a considerable amount of real memory, particularly when executing large multi-user applications. Re-entrancy was completely automatic under NOS/VE. All programs and applications supplied by Control Data and all programs written under NOS/VE were reentrant. Re-entrancy was also known as having “pure” procedures.
Since segments could be linked together, it was possible to bind (link) two instruction segments to the same data segment. This feature allowed an application designer the benefit of considerable flexibility. Many times, large applications had a need to have a set of data processed at the same time by two different programs; this was very easy to do under NOS/VE. It is very difficult or impossible on other systems.
NOS/VE allowed the sharing of disk data between two jobs on the same host. Two programs could open a file for segment access and share that memory segment via “Implicit I/O” as described earlier. That segment or another could include interlocking information that was managed directly by the programs. Two programs could open a file for record access and share that file at that level. The sharing of data on disk was interlocked so that accidental over-writing could be avoided. This interlocking was known as record locking and was a standard access method service under NOS/VE. Thus, both techniques were complementary and offered design advantages to the application designer and flexibility to the end user.
For most computing environments, records on the disk files were accessed by system routines called access methods. When a program did a read or write, the access methods located, formated, and delivered the data to the program. We have already seen how NOS/VE offers an alternative to this process called Implicit I/0. It quite frequently happens that an application writer needs to augment or modify the access methods. In most systems, this was not possible or required a very complex process. NOS/VE provides a very easy method to allow such modification or augmentation called File Access Procedures (FAP). Such procedures were associated with a file and any access to that file is first passed to the FAP. The FAP then performed its processing and then, most likely, calls the access method although this was optional. Every access to and from that file must be processed by the FAP.
This feature allowed application writers to add such capabilities as encrypting data for security purposes before writing to the disk, or it may be as simple as requesting a password before access was allowed to the file. It could be as dramatic as using data in very different ways, such as a new data manager. It should be noted that the NOS/VE access methods were themselves FAPs and were associated with files by default.
NOS/VE used a hierarchical file structure; that is, master catalogs could contain subcatalogs, which could contain sub-subcatalogs, and so forth. This allowed the user to name and deal with groups of files and, when dealing with large numbers of files, to segment them into controllable groups. The number of levels in the hierarchy was not fixed and was dependent on how long a name was used to absolutely locate the file; however, “more than sixteen” is a good answer.
Note that master catalogs were grouped into families. Requests could cross family boundaries. More importantly, a family could be identified with a specific host thereby allowing a request for a file that specified the family name to be relayed to another host. Thus, the user was unconcerned with the residency of files. Files under NOS/VE could have thirty-one character names and had security access controls. This meant that no one could access a file unless the owner permitted that access and then only in the mode permitted. These modes were:
- Execute only
- Read only
A user could also require a password for access to the file.
NOS/VE files could have cycles; that is, several versions of the same file may exist with the same name with different version numbers. The benefit was that different versions of the same application (test version, release version, etc.) could exist.
Real memory provided performance particularly in NOS/VE implementations of virtual memory. NOS/VE was designed to accommodate new, cheaper, larger, real memories as they become available.
Paging, in a virtual system, is the process of moving data and programs between a disk and real memory. The size of the page affects performance. On most machines, the page size is fixed and is a compromise between execution speed of a specific job and the throughput of the entire system. In the Control Data 180 architecture, there was no such rigidity. The page size could be changed from a hardware size of 2,048 bytes to 65K bytes (the currently implemented software range was smaller). Most importantly, the page size could be changed without affecting any system or application software. (the machine had to be completely idle to do this.) The variable page size meant that one could tune today’s system for maximum performance and when very large real memories arrived to increase the page size for most efficient operation.
A task is a piece of useful work that the system handles. System directives (command statements) are tasks and so are programs. System services such as record managers are separate tasks. By designing a system to be multitasked, it could be made modular and efficient.
The concern for usability in NOS/VE was one of the primary design requirements. As an example of usability, consider the user “help” system. Like most modern systems, NOS/VE offered a full error message mode for the novice and a brief message mode for the experienced user prompting for missing parameters. Should the messages or the prompts be insufficient, the user could request further help from the system. (Procedures could also contain help text so that the user is always within a keystroke of assistance.) Should the user still be unable to proceed, he or she could access the on-line documentation. This was linked to error messages so that the user was taken to the correct page of the on-line manuals. All manuals that a user would normally need were on-line.
On-line manuals also solved the problem of documentation distribution and consistency; that is, the documentation on the system was always up-to-date. Control Data supplied the source text to these manuals so that customers could reflect local changes in their on-line documentation. New customer written applications could have on-line manuals created for them as Control Data provides the utility within NOS/VE.
NOS/VE had a full complement of system tools to make the writing, maintaining, and debugging of programs as productive as possible. Note that other productivity tools such as the environments offer further productivity advances over conventional techniques. NOS/VE supported a powerful full screen editor for PCs, VT1OO/VT220, and Apple terminals. Complete with undo feature for backing out of erroneous activities, the editor was function key driven and represented a powerful programming tool.
To maintain and modify source code, the Source Code Utility (SCU) provided unusual flexibility in the administration of decks or parts of programs. The SCU and the full screen editor were fully integrated so that changes made to source code were automatically collected into a modification deck. Such integration made the creation of large programs manageable. Interlocking of decks to control the release of new modifications of the system and tools for system integration were all built in.
The object code utility provided standard services for the linking, binding, and analysis of load modules. Within this utility was a job performance utility that reports such factors as time spent in the various subroutines, the system time associated with the program, and paging activity. The results were displayed in easy-to-read, graphical format and allowed the ready optimization of programs.
A comprehensive, symbolic debug facility was provided, which allowed breakpoints, interruptions at a specific line or variable, tracing, and the monitoring of variables. Unusually flexible and quick, the debug tool again offered enhanced programmer productivity.
NOS/VE was entirely written in the higher level, block structured language called CYBIL. This language, which was based on Pascal, provided a more stable, error free system than assembly language based systems. CYBIL also isolated the system software from the hardware thus allowing Control Data to radically improve the hardware, without impact at the system level. CYBIL is also used in Control Data’s communication system software called CDCNET, which executed on the Motorola 68000 processor. This illustrated the flexibility of CYBIL as a language that could execute on microprocessors and the CYBER vector processor Model 990. Such flexibility is the customer’s guarantee that we can constantly improve our products without harmful disruption to them.
NOS/VE supported a wide range of languages:
- FORTRAN (ANSI 1977 and 1987 anticipated standard)
- VECTOR FORTRAN
- COBOL (ANSI 1974)
- COMMON LISP (Compiler and interpreter)
- C (both with UNIX and without UNIX support)
NOS/VE had an unusually powerful command and job control language. Indeed, it was a language that could perform many functions that previously required detailed conventional programming. It was a block structured language and adhered to firm, consistent, and obvious naming and syntactical constraints making SCL also very easy to learn to use. All commands had status fields so that SCL procedures could respond to errors and abnormal conditions. SCL offered prompting for missing parameters.
All commands went through a generalized interpreter and then to a command processor. This interpreter could handle a wide set of variables including strings, lists, and ranges of text or numbers. The interpreter could be used, therefore, to easily create new command sequences (such as the VAX VMS user interface); designers of such a new interface had to only concern themselves with the command processing, as the interpreter did the command cracking.
SCL could be grouped with other command processors such as the Source Code Utility (SCU) into a stack. Stacks could include user written command processes. The system obviously encouraged the writing of procedures and allows system wide epilogs and prologs, user epilogs and prologs, and scheduling class epilogs and prologs. Such procedures were executed automatically when a job started and finished or when a user logged on or off.
Fundamental to the design of NOS/VE was the goal to remove those constraints that cause so many programming problems and so many usability issues in other systems. This was done by making the system more than merely integrated; it was made homogeneous. It was made consistent across all interfaces. NOS/VE did not maintain archaic distinctions between batch and interactive modes, nor did it establish barriers between programs and command language. Procedures could call programs and, uniquely, programs could call procedures.
This latter benefit provided a new way of writing applications. Instead of large pieces of control language directives preceding a program and instead of programs failing because of an external error, the command language could be imbedded in the program; that is, located next to the code that it supported. More importantly, since all SCL commands had a status field, the program could tell if the procedure executed to completion. Thus, the program now controled the entire execution environment and could prevent many of the mishaps and catastrophes that plagued conventional applications during their execution.