VS/9

VS/9 was a computer operating system available for the Univac 90/60, 90/70 and 90/80 mainframe during the late 1960s through 1980s. It provided the capability to allow both interactive and batch operations on the same computer.

Background

In the late-1960s, RCA decided to exit the mainframe computer business after losing about a 1/2 billion dollars trying (and failing) to compete against IBM. Most of the assets of the computer division were sold 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'.

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) called the Video Display Terminal or VDT, as well as ordinary ASCII dumb terminals. Univac's 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. (The same feature for "split screen scroll" would become available about 20 years later in the Apple II microcomputer.)

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.

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.

ystem 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.If one had issued a break to a running program 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.

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 text 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 EDTand 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 $EDTor 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.

ee also

*BS2000
*Timeline of operating systems

References

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