VS/9 is a computeroperating system for the UNIVAC Series 90mainframes (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, 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 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.
Accounts could be given restrictions such as requiring a password to use, limits on amount of files, amount of usage, time of permitted usage (such as only allowing logons after 5 p.m. or before 8 a.m.) and CPU limits. A user could also issue commands to have the system interrupt a program if the current session used more than a certain amount of wall-clock or cpu time.
A user at a terminal that was not logged on, who wanted to start a session would press the red Transmit key on a Univac VDT, or use Control+C on an ASCII terminal. VS/9 would issue the following response:
Welcome to the VS/9 terminal system. Please logon.
Followed by a slash ("/"), and in the case of the Univac VDT, the prompt character, which looked like an inverse color greater than sign (">"). The user would logon by typing the word 'logon followed by their identifier, e.g. their account name, a comma, and their user name. If they had a password on their account, they would type a comma followed by their password, which could be from 1 to 4 characters. If it contained one or more spaces (other than trailing spaces, which could be omitted), it had to be typed in single quotes. If it contained non-printable or binary characters, it had to by typed in by using the letter X followed by a quote and the 8-character hexadecimal value of their password. So if the account S0103 had the password (in hexadecimal) A0B0C0 and a space, then user LESLIE would logon to the system by typing
/LOGON S0103,LESLIE,X'A0B0C0'
If their credentials were incorrect, either because the account name, user name or password were incorrect, they would get the message,
Logon invalid, please try again.
and would be given a / prompt to logon again.
If their credentials were correct, then if the system manager (the owner of account $TSOS) had posted a system message, it would display at this time. The user would be at command mode, and a standard / prompt would appear where they could type various commands. The user would finish their session by typing LOGOFF and pressing transmit on the Univac VDT or Control+C on an ascii terminal.
Terminal functions
Univac's VDT terminal had four function keys at the top, and VS/9 specifically recognized them.
F1 was the equivalent to the break key on an Ascii terminal. If a program was running, it would be interrupted, and the user would enter break mode, in which they could issue a command. They could type R or INTR to resume running the program where the break had been struck.
F2 and F3 could be set up to be recognized by a program for various functions, but were not used by VS/9.
F4 performed an immediate forced logoff of the user if struck, by accident or on purpose. This would be the equivalent on MS-DOS of pressing CTRL-ALT-DEL, which force-reboots the machine immediately.
System commands
VS/9 accepted commands by typing the command and any options. Commands issued in a batch stream either as cards or as a batch file required that they be preceded by a slash; commands entered at a terminal did not require use of the slash. Commands included the following:
EXEC to load and run a program
LOAD to load a program into memory and break to command mode without running, to allow debugging commands
DO to run a batch file in the current session
ENTER to run a batch file as if it had been submitted to the card reader
SYSFILE to specify the disposition of printed output
LOGOFF to end one's session. If someone was going to use the terminal, or they wanted to change accounts, they could also type LOGOFF BUT to issue an immediate request for a new login. Any printed output the user had generated during their session would be spooled to the line printer and printed at this time. The option 'TAPE' could be used, as in LOGOFF TAPE, LOGOFF BUT,TAPE or LOGOFF TAPE,BUT to indicate that pending printed output should be spooled to magnetic tape instead of being printed. A request would be sent to the system operator.
If one had issued a break to a running program (through the Break key on an ASCII terminal or the F1 key on a Univac VDT) or had used the LOAD command instead of EXEC, one would be in "break mode" in which the program was suspended to allow the user to be at command mode. They could issue the above commands as well the following:
R to resume a program interrupted by the break key
INTR to issue an Interrupt-Resume to a program supporting INTR
Debugging commands
VS/9 included the Interactive Debugging Aid (IDA) which provided commands to view memory and registers, trap program errors, and store memory in locations. Unlike other systems where an interactive debugger required either you run a program to use it or link a module into a program, IDA was a part of the operating system and its commands were available from break mode.
Another very helpful, but unsupported product for debugging operating system problems was a program called "CareCity". The VS/9 operating system was supplied as pre-assembled modules on magnetic tapes. During installation, selected modules were linked together based on the configuration parameters supplied to form the functioning operating system and then saved to disk. Each module had a designated free space at the end, which was used to patch existing code in the event of an error, without re-assembling the entire module. CareCity enabled the administrator to view the operating system memory contents using addresses relative to the start of each operating system module. Patch code could then be inserted into the designated patch areas as needed and then branches from existing code to the newly installed code could be inserted. This could all be done while the operating system was in use.
File name conventions
File names could be up to 56 characters in length. A file could consist of letters, numbers, dashes, and digits. A file name of all digits was permissible, but a file could not have two consecutive periods. To access a file in another account, it was necessary for a user in that account to make the file public. If the file was public, it could be accessed by another user by prefixing the name of the file with the indicator that a file being referenced is in another account, which was the dollar sign ("$"), followed by the account name, followed by a period.
If there was a file named "A" in account S0103, and a user in account PA5 wanted to access the file in account S0103, first, the file would have to be marked as public, and second, it would have to be referenced by account name and the name of the file. So a user in account PA5 who wanted to access file A in account S0103, if the file was public, would reference it as $S0103.A. Note that a user in account S0103 could reference the file simply as "A" or could reference it with a fully qualified file name by including a dollar sign and their own account name, followed by a period and the name.
Public files in the special account TSOS could be accessed by using $ alone as the first character of the file, unless the file began with a name that was identical to an account number, in which case the explicit account reference $TSOS. would be required. Also, $TSOS. was what would be called the path name for missing files referenced by name which were not found in the user's account. For example, if there was a file called S0103.XYZZY in account $TSOS, and there was an account on that system named S0103, any user wanting to access it would have to access it as $TSOS.S0103.XYZZY.
TSOS was also the "default" account for a file that was referenced that did not exist locally. For example, to execute the EDT editor program, one would issue the command to run a program, EXEC, followed by the name of the file, which was called EDT. So, if the user had not created a file named EDT, they could execute the EDT editor by typing
/EXEC EDT
and pressing the transmit key. If they had, for some reason, created a program of the same name, to use the system editor, they would have to type
/EXEC $EDT
or they could explicitly type in the system account
/EXEC $TSOS.EDT
When Unisys discontinued sales of the 9000 series mainframes in favor of the EXEC 8 series computers (probably because they were no longer cost effective, and the market for mainframes had shrank), VS/9 was effectively abandoned by the company.
