VS/9

VS/9
Company type	Operating system
Industry	Computer software
Predecessor	RCA TSOS, Univac OS/7
Founded	Late 1960s
Headquarters	United States
Products	Operating system for UNIVAC Series 90 mainframes (90/60, 90/70, 90/80)

VS/9 is an operating system designed for the UNIVAC Series 90 mainframes—specifically the 90/60, 90/70, and 90/80 models—utilized from the late 1960s through the 1980s. The 90/60 and 90/70 models were essentially rebranded versions of the Univac 9700 systems. Following Sperry’s acquisition of RCA, it became apparent that RCA’s TSOS offered more advanced features than Univac’s OS/7. Consequently, Sperry combined Univac hardware with RCA’s TSOS software, introducing the 90/70 model first, followed by the slower and more affordable 90/60. The 90/80 was the inaugural platform engineered to fully exploit VS/9’s capabilities for both interactive and batch processing environments.

Background

In September 1971, after incurring significant financial setbacks competing against IBM, RCA withdrew from the mainframe market. It transferred its computer division assets to Univac, which included the Spectra mainframe series, peripheral devices such as video terminals, tape drives, and punched card readers, as well as its TSOS operating system.

TSOS provided users with functionality surpassing that of IBM’s offerings but was distributed exclusively bundled with hardware rather than sold independently. Univac refined TSOS and reintroduced it under the VS/9 name; however, the original 'TSOS' login remained as the principal privileged account, analogous to Unix’s 'root' user. Additionally, RCA licensed TSOS to what later became Fujitsu, which used it as a foundation for Fujitsu's BS2000 mainframe operating system.

Interactive use

VS/9’s interactive operation relied on terminals connected through a terminal concentrator device, comparable to IBM’s 3270 terminal architecture. Unlike personal computers that process input character-by-character, data entry was transmitted only after pressing enter. The concentrator unit—initially termed the Communications Control Module (CCM)—had its patents sold by RCA to Singer Corporation. Subsequently, Univac developed an emulator known as the Multiterminal Connection Controller model 16 (MCC-16).

The MCC-16 accommodated both the Univac standard terminal (later renamed Uniscope Video Display Terminal or VDT) and generic ASCII dumb terminals. The Uniscope VDT was notable for its advanced editing functionalities at the time, enabling users to modify text at line or page levels on-screen before sending it. It supported direct cursor positioning and input protection by accepting input only from text following the cursor position, along with a scrolling feature that allowed partial screen scrolling within a defined "window."

A fundamental difference existed between interactive (timesharing) terminals and transactional terminals. Interactive terminals were directly managed by the operating system itself, whereas transactional terminals operated under a batch program originally called MCP (Multichannel Communications Program). MCP was initially created for RCA and Sperry batch operating systems—TDOS and DOS—but was later adapted for VMOS (Virtual Memory Operating System), an advanced OS evolved from TSOS on RCA Spectra 70 and Univac Series 70 machines.

MCP was further developed to support Sperry Univac terminals and renamed COS (Communication Operating System). Ports in both CCM hardware and MCC emulation could be configured as either interactive or transactional but not simultaneously as both. Interactive ports were governed by VMOS or VS/9 timesharing services, allowing users to execute programs, generate files, and request system resources individually as separate tasks. This was made possible through virtual memory management that swapped fixed-size memory pages (4096 bytes) to disk or drum storage to optimize multitasking despite limited physical memory. Transactional ports were controlled by COS; users had restricted access without individualized task identities or resource requests.

In both CCM and MCC emulation modes, these devices functioned as "dumb" interfaces where all network protocol operations—including terminal polling, error handling, and message assembly—were processed by the mainframe itself. It was only when MCC operated as an actual front-end processor during the VS/9 period that much of this workload was shifted away from the mainframe, thereby freeing up computing capacity for application processing tasks.

Batch Processing

VS/9 supported one or multiple card readers linked to the system. Users initiated processing by placing a deck of cards into the input hopper and pressing "Start." The system then read the input deck and transferred the processed cards to the output hopper. Valid login decks were treated as jobs ready for execution.

System Administration

A central-site operator controlled VS/9 through a system console, which initially was a teletype device but was later replaced by a video display terminal equipped with a printer. All OS-generated messages, including unsolicited ones, were recorded in logs. The operator's duties encompassed:

Booting the system to initialize operations.
Launching batch job processes.
Loading communication control software (MCP or COS) to manage interactive terminals.
Providing input data via punched cards or magnetic tape media.
Mounting and dismounting removable disk drives and tapes for both batch and interactive workloads.
Managing job priorities within queues.
Adjusting limits for batch processing and terminal sessions to enhance efficiency.
Supplying paper for local printing devices.
Reporting hardware or software issues to vendor maintenance teams.
Executing any additional tasks assigned by customer management.

Volume Group Management

One significant late-stage improvement was the introduction of volume groups, designed to overcome limitations in disk capacity and file size. Disk drives were physically removable, allowing customers to increase storage by swapping disks, though simultaneous use required sufficient free drives. Volume groups enabled files to span across several disks mounted concurrently. Access restrictions could be imposed by assigning ownership rights. Once mounted by active processes, volume groups remained attached until all associated tasks released them. System disks were organized into volume groups—either fixed or removable—with fixed groups containing essential OS components and transactional terminal support files, preventing their removal during operation.

Remote Batch Submission

VS/9's Remote Batch Processing (RBP) feature permitted users at remote locations to submit batch jobs to the mainframe and receive output at local printers. Remote batch setups typically consisted of card readers and printers connected through communication lines interfacing with the OS’s remote batch service. Operators could handle tape or disk mounting and respond to program prompts similarly to local batch operations. Despite its capabilities, RBP saw limited adoption, likely due to low demand.

Task Classification

Tasks within VS/9 were categorized by type, differentiating between program executions and queued tasks:

Batch input queue
Running batch programs
Active timesharing sessions
Print and punch spool output queue
Print and punch devices currently printing or punching
Remote Batch Processing output queue
Unused slot
Remote Batch Processing devices printing

MCP and COS consistently appeared as type 2 tasks. Operators tracked task numbers via the system console, while administrators accessed "Stat200," a custom field-developed program available from terminals that displayed active task lists in real time. Although unofficial, Stat200 became widely accepted as the standard tool for task monitoring.

User Authentication

Access control in VS/9 utilized an account name (1–7 alphanumeric characters) paired with a user name (1–8 alphanumeric characters). The account acted similarly to a Unix directory, allowing multiple users under one account to share files while maintaining distinct identities via their usernames (e.g., S0103,PAT versus S0103,LESLIE). Users with identical usernames but different accounts remained separate entities.

Accounts could be configured with constraints such as passwords, file quotas, permitted usage times, and CPU consumption limits. Users also had the option to set session interrupts triggered by elapsed wall-clock time or CPU usage.

To initiate login, users pressed the red key on a Univac VDT or on an ASCII terminal. The system then prompted:

Users authenticated by entering logon followed by their account and username, optionally including a password of 1–4 characters. Passwords containing spaces required enclosing quotes; non-printable or binary characters were input using an 'X' followed by an 8-digit hexadecimal sequence. For example:

If authentication failed, this message appeared:

After successful login, any pending system manager messages were displayed before presenting the standard / command prompt. Sessions concluded by typing followed by transmit or pressing on ASCII terminals.

Terminal capabilities

The Univac VDT terminal included four function keys that VS/9 recognized:

F1 served as a break key, halting active programs and switching to break mode for command entry. Users could input R or INTR to continue execution.
F2 and F3 were programmable but remained unused by VS/9.
F4 triggered an immediate logoff, functioning similarly to the CTRL-ALT-DEL sequence on MS-DOS.

Command structure

VS/9 processed commands with optional parameters; batch commands required a leading slash, whereas terminal commands did not. Important commands included:

EXEC to load and execute programs
LOAD to load programs into memory without execution, facilitating debugging
DO to run batch files within the current session
ENTER to execute batch files as if submitted through a card reader
SYSFILE to control the handling of printed output
LOGOFF to terminate sessions, with options such as for instant re-login prompts and to redirect output to magnetic tape instead of printing

When in break mode—activated via the break key or LOAD command—users could issue all the above commands plus:

R to resume programs that were interrupted
INTR to interrupt and then resume supported programs
Various debugging commands

The Interactive Debugging Aid (IDA), embedded within VS/9, allowed users to inspect memory and registers, trap errors, and save memory contents directly from break mode without needing separate software modules.

Additionally, the "CareCity" utility enabled system administrators to examine OS memory relative to module starting points and insert patches into designated free spaces within modules during runtime. This feature facilitated live updates without requiring module reassembly or system downtime.

File naming standards

File names could be up to 56 characters long, composed of letters, numbers, dashes, and digits. Names entirely numeric were permitted; however, consecutive periods were prohibited. To access files from other accounts, those files needed to be public. Public files were referenced by prefixing the filename with a dollar sign ("$"), followed by the account name and a period.

For instance, if account S0103 had a public file named "A," a user in account PA5 would access it as . Users within the same account could reference the file simply as "A" or use a fully qualified name including their own account prefix.

Public files in the special TSOS account could be accessed using alone unless the filename coincided with an account number, which required explicit referencing like . For example, accessing S0103.XYZZY within TSOS necessitated using .

TSOS also acted as the default account for missing local files. For example, running the EDT editor involved typing

If a local file named EDT existed, launching the system editor required

or explicitly specifying

With Unisys discontinuing sales of 9000 series mainframes in favor of the more economical EXEC 8 series amid declining mainframe demand, VS/9 was effectively phased out.

References

VS/9 User Reference Manual, Sperry Unisys, Cinnaminson, New Jersey, 1972
VS/9 Programmer Reference Manual, Sperry Unisys, Cinnaminson, New Jersey, 1975