Computer history TNO-FEL:
Most of this information was extracted
from a CDC NOS/VE information leaflet
The NOS/VE operating system core services were:
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.
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.
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.
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 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.
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.
- Execute only
- Read only
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.
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.
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.
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
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.
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.
NOS/VE supports 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)
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.
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
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.