VS/9 is a computer operating system for the UNIVAC Series 90 mainframes (90/60, 90/70, and 90/80), used during the late 1960s through 1980s. The 90/60 and 90/70 were repackaged Univac 9700 computers. After the RCA acquisition by Sperry, it was determined that the RCA TSOS operating system was far more advanced than the Univac counterpart (named OS/7), so the company opted to merge the Univac hardware with the RCA software and introduced the 90/70. The 90/60 was introduced shortly thereafter as a slower, less expensive 90/70. It was not until the introduction of the 90/80 that VS/9 finally had a hardware platform optimized to take full advantage of its capability to allow both interactive and batch operations on the same computer.
Background In September 1971, RCA decided to exit the mainframe computer business after losing about half a billion dollars trying (and failing) to compete against IBM. They sold most of the assets of the computer division to what was then Univac. This included RCA's Spectra series of computers, various external hardware designs (such as video terminals, tape drives and punched card readers), and its operating system, Time Sharing Operating System (TSOS).
TSOS may have been a better operating system from a user standpoint than any of IBM's, but at the time, operating systems were not considered something sold separately from the computer, the manufacturer included it free as part of the purchase price. Univac introduced some additional new features to TSOS, and renamed it VS/9. The name 'TSOS' however, remained as the username of the primary privileged (System Manager) account, which on Unix-type systems, is called 'root'. RCA also sold TSOS to what would become Fujitsu, and it is the basis for Fujitsu's BS2000 operating system on its mainframes of the same name.
Use Interactive use Interactive use of VS/9 was done through terminals connected to a terminal concentrator unit, which passed control signals to and from the terminals, in a manner similar to the way IBM would provide with its IBM 3270-style terminals. This provided, in general, for input to the terminal to be sent in response to an enter key, as opposed to the practice on PCs of taking input one character at a time. The concentrator unit was originally known as the Communications Control Module, or CCM. However, RCA had sold the patents and designs for its CCM terminal controller to Singer Corporation, so Univac developed an emulator device for the CCM which was known as the Multiterminal Connection Controller model 16, or MCC-16.
The MCC-16 supported both the Univac standard terminal (from RCA) renamed to the Uniscope Video Display Terminal or VDT, as well as ordinary ASCII dumb terminals. Univac's Uniscope VDT provided sophisticated (for the time) editing capability including the ability to edit text on screen and make changes a line at a time or a page at a time, then transmit the text back to the computer. The VDT also supported direct cursor positioning and input protection through a cursor which indicated that only text after the cursor was to be recognized. It also supported special scroll mode in a subset of the screen, or "window" in which, instead of the entire screen scrolling upward when the last line is displayed, it was possible to make the scroll area only the bottom half of the screen.
A distinction was made between interactive (timesharing) terminals and transactional terminals. Where interactive terminals were controlled directly by the operating system, transactional terminals were controlled from a batch program. Initially, this batch program, known as MCP for Multichannel Communications Program, was developed for the RCA and Sperry batch-oriented operating systems, TDOS (Tape-Disk Operating System) and DOS (Disk Operating System). Once it became clear that they would be phased out in favor of the much more robust interactive operating system, VMOS, MCP was ported to run on VMOS. VMOS (Virtual Memory Operating System) became the new moniker for TSOS on RCA Spectra 70 models 46, 61, 3, and 7 computers, and then initially on Univac Series 70 (formerly RCA) computers.
Eventually, MCP was enhanced to support Sperry Univac terminals and its name was changed to COS (Communication Operating System). Ports in the CCM and later in the MCC running in emulation mode could be designated either interactive or transactional, but not both. If a port was designated an interactive port, it was controlled by the timesharing services integrated into the VMOS or VS/9 operating system. Transactional ports, on the other hand, were controlled by COS. All terminals connected to these ports became the "property" of the respective controlling host software. Timesharing was used for program development allowing much faster program development than the traditional batch process which was state of the art at the time. Each timesharing user was a task by itself and could execute programs, create files, and request system resources as needed. What made much of this possible was the operating system's ability to manage "virtual memory", or temporarily save pages of memory (including executing programs) to disk or drum while not in use and then retrieve them later as needed. Virtual memory page size was fixed at 4096 bytes. This allowed many more tasks to be running simultaneously than would otherwise be constrained by limited and expensive main memory space. Transactional users, on the other hand, were all controlled by a single program and their view of the environment was limited to that which was presented to them. They were not identified as individual tasks and did not have the ability to run programs or request system resources.
The CCM and the MCC running in emulation mode were "dumb" hardware interfaces. That is, all the network protocol intelligence, including terminal polling, error recovery, and message construction resided in the mainframe, while the CCM and MCC simply acted as conduits between the mainframe and the phone lines. It was not until the MCC was used as a true front end processor that much of this overhead (such as polling and error recovery) was offloaded from the mainframe, thus freeing up computer time for running application programs. This did not occur until the VS/9 era.
Batch use VS/9 supported one or more card readers, which were connected to the computer and activated by the user placing a card deck in the hopper and pressing the "Start" button. Presumably, the computer would read the source deck, and place all of the cards read in the output hopper. If the card deck consisted of a valid login, it would process the card deck as a job to execute.
Site Operations VS/9 was controlled by a computer operator at the central site. Computer operators interacted with the system through a system console. Initially, this console was a teletype device, but was later upgraded to a video display device with an attached system console printer. All system console messages were logged to the system console printer. Unsolicited messages originating in the operating system were also logged to the system console printer. Computer operators had a number of responsibilities:
Initialize the system through a boot process. Start batch program processes. Load the communication control program (MCP or COS) if the site had transactional terminals. Supply input data via punched cards or magnetic tapes. Mount/dismount removable disks and tapes as needed for batch and/or interactive tasks. Prioritize jobs executing or in the input queues. Adjust batch and interactive terminal limits to optimize system performance. Supply paper for the onsite, locally connected printers. Report system malfunctions to vendor maintenance personnel. Perform other duties as specified by the customer management team.
Features Volume Groups One of the more useful enhancements late in the life of VS/9 was volume groups. Disk technology at the time provided limited storage space on each disk. Since disk drives were comparatively large and quite expensive, manufacturers of disk drives provided the capability to physically remove the actual disk from the device and replace it with another. Customers thus had the ability to store many times the capacity of their disk drives, albeit they could not necessarily be used simultaneously unless there were enough free disk drives. Limited disk storage space also presented users with another problem. Very often files would be larger than could be contained on one disk. Volume groups helped mitigate this technological problem by allowing files to span multiple disks. Volumes (disks) that had to be mounted simultaneously were designated a "volume group". Owners could be defined in order to limit access to sensitive data. Once mounted and attached to an active task, the entire volume group could not be dismounted until all attached tasks either released it or terminated. Every disk available to the system was part of a volume group, even if there was only one volume in the group. Volume groups could be designated as removable or fixed. Fixed volume groups could not be removed at any time. This was necessary for disks that housed the operating system and the files that supported the transactional terminals.
Remote Batch Processing Remote Batch Processing (RBP) was a capability that existed in VS/9, although it was never completely exploited, probably due to limited demand. RBP allowed remote users to submit batch jobs for execution on the mainframe and receive the results back at their offsite printer. Typically, a remote batch device consisted of a card reader and a printer connected to a communication line which interfaced with the remote batch services in the operating system. Like a local batch job, operators could receive requests for tape or disk mounts/dismounts and program prompts for responses to questions.
Task Types VS/9 managed tasks by task type. Task types could be either executing programs or queues of pending tasks. The following were the task types used by VS/9:
Batch input queue Executing batch programs Active timesharing users Print and punch spool output queue Print and punch devices printing or punching RBP output queue Not used RBP devices printing
MCP and COS were always type 2 tasks. The computer operator would see a count of the number of tasks within each queue on the system console. A complete list of the task queues was available from any interactive terminal with administrator access via a field-written program known as "Stat200". This program would scan the task queues every few seconds and display a rolling list of tasks on the terminal screen until it was interrupted or terminated. While not an officially released product, it became the de facto standard for task monitoring.
Account access VS/9 controlled access through the use of an account name and a user name. The account name was a 1 to 7 character identifier, and the user name was also a 1 to 8 character identifier. Identifiers for account names and user names could only be letters and numbers. The account name was the equivalent of a directory name under Unix-style user accounts, with the note that the user name indicated which person sharing that account was the party using it. Thus, for example, if there was an account name of S0103, if there were two users, whose name were Pat and Leslie in that account, they would have a complete identifier of S0103, PAT and S0103, LESLIE. All of their files would be stored in the directory S0103 and thus, they could not create files with the same name. Note that if there was an account name of, say, PA5, if there was a user named Pat, their identifier would be PA5, PAT and would be completely unrelated to any other user named Pat.