[TNO-logo]
Museum logo

Computer history TNO-FEL:
NOS/VE

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

The word size on the CYBER 180 is 64 bits, which provides very high computational precision; double precision arithmetic is available beyond this. The word can also contain eight ASCII characters, and full ASCII support is available in the languages and utilities of NOS/VE.

Large Virtual Address Space

NOS/VE allows 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 is allocated as a series of pages; that is, pieces of memory.

Segmented Virtual Address Space

The address space consists of segments. Each task may have a maximum of 4,096 segments. Each segment has one or more pages; the maximum size of a segment is 2.1 gigabytes. (The page size, which is variable, is discussed later.)

Segmentation provides a number of benefits, which derive from the separation of programs into separate instruction segments and data segments. A segment contains either data or instructions (code). There is a third type of segment, which links a data segment to an instruction segment to form a job.

This type of segment is called a binding segment. A segment never contains a mix of instructions and data. This is very different from most systems, which have a single segment with instructions and data jumbled together.

Segments have properties. A segment can be read only, which is typically used for data constants, or execute-only, which is used for programs. The third property is write access.

When you separate data and programs, you gain three major benefits that are difficult or impossible on single segment systems:

These benefits are discussed next. A further benefit of segmentation is 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.

Implicit I/O

This is a technique that allows 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 reads or updates locations in memory, and the system reads or updates the disk file as needed. Two benefits arise. First, the programmer does 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 is updated as needed, the system controls the 1/0 flow to and from the disk in the most optimized manner. In most cases, this means that the job runs faster. The result is programs that take less time to write and run faster.

Of the active systems today, IBM can do this but it requires costly and difficult assembly language routines. Under IBM, it is portrayed as an optimization technique for the most skilled programmer rather than the NOS/VE general purpose solution.

Re-entrancy

Re-entrancy is a technique that allows more than one user to execute the same instructions (piece of program) at the same time. This saves a considerable amount of real memory, particularly when executing large multi-user applications.

Re-entrancy is completely automatic under NOS/VE. All programs and applications supplied by Control Data and all programs written under NOS/VE are reentrant. Re-entrancy is also known as having "pure" procedures.

Shared Memory Data

Since segments can be linked together, it is possible to bind (link) two instruction segments to the same data segment. This feature allows an application designer the benefit of considerable flexibility. Many times, large applications have a need to have a set of data processed at the same time by two different programs; this is very easy to do under NOS/VE. It is very difficult or impossible on other systems.

Shared Files

NOS/VE allows the sharing of disk data between two jobs on the same host. Two programs can open a file for segment access and share that memory segment via "Implicit I/O" as described earlier. That segment or another can include interlocking information that is managed directly by the programs. Two programs can open a file for record access and share that file at that level. The sharing of data on disk is interlocked so that accidental over-writing can be avoided. This interlocking is known as record locking and is a standard access method service under NOS/VE. Thus, both techniques are complementary and offer design advantages to the application designer and flexibility to the end user.

File Access Procedures

For most computing environments, records on the disk files are accessed by system routines called access methods. When a program does a read or write, the access methods locate, format, and deliver 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 is not possible or is a very complex process. NOS/VE provides a very easy method to allow such modification or augmentation called File Access Procedures (FAP).

Such procedures are associated with a file and any access to that file is first passed to the FAP. The FAP then performs its processing and then, most likely, calls the access method although this is optional. Every access to and from that file must be processed by the FAP.

This feature allows 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 is 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 are themselves FAPs and are associated with files by default.

File Catalog Structure

NOS/VE uses a hierarchical file structure; that is, master catalogs may contain subcatalogs, which may contain sub-subcatalogs, and so forth. This allows 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 is not fixed and is dependent on how long a name is used to absolutely locate the file; however, "more than sixteen" is a good answer.

Note that master catalogs are grouped into families. Requests can cross family boundaries. More importantly, a family can be identified with a specific host thereby allowing a request for a file that specifies the family name to be relayed to another host. Thus, the user is unconcerned with residency of files.
Files under NOS/VE can have thirty-one character names and have security access controls. This means that no one can access a file unless the owner permits that access and then only in the mode permitted. These modes include:

A user can also require a password for access to the file.

NOS/VE files can have cycles; that is, several versions of the same file may exist with the same name with different version numbers. The benefit is that different versions of the same application (test version, release version, etc.) can exist.

Large Real Memory

Real memory provides 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 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 is no such rigidity. The page size can be changed from a hardware size of 2,048 bytes to 65K bytes (the currently implemented software range is smaller). Most importantly, the page size can be changed without affecting any system or application software. (The machine must be completely idle to do this.) The variable page size means that we can tune today's system for maximum performance and when very large real memories arrive increase the page size for most efficient operation.

Multi tasking

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 can be made modular and efficient.

User Assistance

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 offers a full error message mode for the novice and a brief message mode for the experienced user prompting for missing parameters is provided. Should the messages or the prompts be insufficient, the user can request further help from the system. (Procedures can 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 can request the on-line documentation. This is linked to error messages so that the user is taken to the correct page of the on-line manuals. All manuals that a user would normally need are on-line.

On-line manuals also solve the problem of documentation distribution and consistency; that is, the documentation on the system is always up-to-date. Control Data supplies the source text to these manuals so that customers may reflect local changes in their on-line documentation. New customer written applications can have on-line manuals created for them as Control Data provides the utility within NOS/VE.

System Tools

NOS/VE has 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 supports a powerful full screen editor for PCs, VT1OO/VT220, and Apple terminals. Complete with undo feature for backing out of erroneous activities, the editor is function key driven and represents a powerful programming tool.

To maintain and modify source code, the Source Code Utility (SCU) provides unusual flexibility in the administration of decks or parts of programs. The SCU and the full screen editor are fully integrated so that changes made to source code are automatically collected into a modification deck. Such integration makes the creation of large programs manageable. Interlocking of decks to control the release of new modifications of the system and tools for system integration are all built in.

The object code utility provides standard services for the linking, binding, and analysis of load modules. Within this utility is 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 are displayed in easy-to-read, graphical format and allow the ready optimization of programs.

A comprehensive, symbolic debug facility is provided, which allows breakpoints, interruptions at a specific line or variable, tracing, and the monitoring of variables. Unusually flexible and quick, the debug tool again offers enhanced programmer productivity.

CYBIL Language

NOS/VE is entirely written in the higher level, block structured language called CYBIL. This language, which is based on Pascal, provides a more stable, error free system than assembly language based systems. CYBIL also isolates 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 executes on the Motorola 68000 processor. This illustrates the flexibility of CYBIL as a language that can 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.

Languages

NOS/VE supports a wide range of languages:

System Command Language

NOS/VE has an unusually powerful command and job control language. Indeed, it is a language that can perform many functions that previously required detailed conventional programming. It is a block structured language and adheres to firm, consistent, and obvious naming and syntactical constraints making SCL also very easy to learn to use. All commands have status fields so that SCL procedures can respond to errors and abnormal conditions. SCL offers prompting for missing parameters.

All commands go through a generalized interpreter and then to a command processor. This interpreter can handle a wide set of variables including strings, lists, and ranges of text or numbers. The interpreter can be used, therefore, to easily create new command sequences (such as the VAX VMS user interface); designers of such a new interface have to only concern themselves with the command processing, as the interpreter does the command cracking.

SCL can be grouped with other command processors such as the Source Code Utility (SCU) into a stack. Stacks ca include user written command processes. The system obviously encourages the writing of procedures and allows system wide epilogs and prologs, user epilogs and prologs, and scheduling class epilogs and prologs. Such procedures are executed automatically when a job starts and finishes or when a user logs on or off.

Homogeneous System

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 does not maintain archaic distinctions between batch and interactive modes, nor does it establish barriers between programs and command language. Procedures can call programs and, uniquely, programs can call procedures.

This latter benefit provides a new way of writing applications. Instead of large pieces of control language directives preceding a program and instead of programs failing because of external error, the command language can be imbedded in the program; that is, located next to the code that it supports. More importantly, since all SCL commands have a status field, the program can tell if the procedure executed to completion. Thus, the program now controls the entire execution environment and can prevent many of the mishaps and catastrophes that plague conventional applications during their execution.

[email protected]
25/02/1998

Museum Homepage