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.
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.
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.
Multiple Virtual Storage, more commonly called MVS, is the most commonly used operating system on the System/370, System/390 and IBM Z IBM mainframe computers. IBM developed MVS, along with OS/VS1 and SVS, as a successor to OS/360. It is unrelated to IBM's other mainframe operating system lines, e.g., VSE, VM, TPF.
A mainframe computer, informally called a mainframe or big iron, is a computer used primarily by large organizations for critical applications like bulk data processing for tasks such as censuses, industry and consumer statistics, enterprise resource planning, and large-scale transaction processing. A mainframe computer is large but not as large as a supercomputer and has more processing power than some other classes of computers, such as minicomputers, servers, workstations, and personal computers. Most large-scale computer-system architectures were established in the 1960s, but they continue to evolve. Mainframe computers are often used as servers.
In computing, time-sharing is the concurrent sharing of a computing resource among many tasks or users by giving each task or user a small slice of processing time. This quick switch between tasks or users gives the illusion of simultaneous execution. It enables multi-tasking by a single user or enables multiple-user sessions.
Computerized batch processing is a method of running software programs called jobs in batches automatically. While users are required to submit the jobs, no other interaction by the user is required to process the batch. Batches may automatically be run at scheduled times as well as being run contingent on the availability of computer resources.
Computer operating systems (OSes) provide a set of functions needed and used by most application programs on a computer, and the links needed to control and synchronize computer hardware. On the first computers, with no operating system, every program needed the full hardware specification to run correctly and perform standard tasks, and its own drivers for peripheral devices like printers and punched paper card readers. The growing complexity of hardware and application programs eventually made operating systems a necessity for everyday use.
RT-11 is a discontinued small, low-end, single-user real-time operating system for the full line of Digital Equipment Corporation PDP-11 16-bit computers. RT-11 was first implemented in 1970. It was widely used for real-time computing systems, process control, and data acquisition across all PDP-11s. It was also used for low-cost general-use computing.
BS2000 is an operating system for IBM 390-compatible mainframe computers developed in the 1970s by Siemens and from early 2000s onward by Fujitsu Technology Solutions.
UNIVAC was a line of electronic digital stored-program computers starting with the products of the Eckert–Mauchly Computer Corporation. Later the name was applied to a division of the Remington Rand company and successor organizations.
In computing, Interactive System Productivity Facility (ISPF) is a software product for many historic IBM mainframe operating systems and currently the z/OS and z/VM operating systems that run on IBM mainframes. It includes a screen editor, the user interface of which was emulated by some microcomputer editors sold commercially starting in the late 1980s, including SPF/PC.
Time Sharing Option (TSO) is an interactive time-sharing environment for IBM mainframe operating systems, including OS/360 MVT, OS/VS2 (SVS), MVS, OS/390, and z/OS.
Job Control Language (JCL) is a scripting language used on IBM mainframe operating systems to instruct the system on how to run a batch job or start a subsystem. The purpose of JCL is to say which programs to run, using which files or devices for input or output, and at times to also indicate under what conditions to skip a step. Parameters in the JCL can also provide accounting information for tracking the resources used by a job as well as which machine the job should run on.
ORVYL is a time-sharing monitor developed by Stanford University for IBM System/360 and System/370 computers in 1967–68. ORVYL was one of the first time-sharing systems to be made available for IBM computers. Wylbur is a text editor and word processor program designed to work either without ORVYL, or in conjunction with ORVYL.
A Supervisor Call instruction (SVC) is a hardware instruction used by the System/360 family of IBM mainframe computers up to contemporary zSeries, the Amdahl 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M, and 5990A, and others; Univac 90/60, 90/70 and 90/80, and possibly others; the Fujitsu M180 (UP) and M200 (MP), and others; and is also used in the Hercules open source mainframe emulation software. It causes an interrupt to request a service from the operating system. The system routine providing the service is called an SVC routine. SVC is a system call.
The history of IBM mainframe operating systems is significant within the history of mainframe operating systems, because of IBM's long-standing position as the world's largest hardware supplier of mainframe computers. IBM mainframes run operating systems supplied by IBM and by third parties.
OS/360, officially known as IBM System/360 Operating System, is a discontinued batch processing operating system developed by IBM for their then-new System/360 mainframe computer, announced in 1964; it was influenced by the earlier IBSYS/IBJOB and Input/Output Control System (IOCS) packages for the IBM 7090/7094 and even more so by the PR155 Operating System for the IBM 1410/7010 processors. It was one of the earliest operating systems to require the computer hardware to include at least one direct access storage device.
In computing, job control refers to the control of multiple tasks or jobs on a computer system, ensuring that they each have access to adequate resources to perform correctly, that competition for limited resources does not cause a deadlock where two or more jobs are unable to complete, resolving such situations where they do occur, and terminating jobs that, for any reason, are not performing as expected.
OS 2200 is the operating system for the Unisys ClearPath Dorado family of mainframe systems. The operating system kernel of OS 2200 is a lineal descendant of Exec 8 for the UNIVAC 1108 and was previously known as OS 1100. Documentation and other information on current and past Unisys systems can be found on the Unisys public support website.
In computer programming, a fully qualified name is an unambiguous name that specifies which object, function, or variable a call refers to without regard to the context of the call. In a hierarchical structure, a name is fully qualified when it "is complete in the sense that it includes (a) all names in the hierarchic sequence above the given element and (b) the name of the given element itself."
EDT is a text editor running on the Unisys VS/9 operating system using the UNIVAC Series 90 mainframe computers, and as of 2013 runs on the Fujitsu BS2000 mainframe computer and operating system. It was developed by RCA for the TSOS operating system for Spectra series mainframes. The RCA version was later sold to Sperry Univac, and was released for the VS/9 operating system.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
