VP/CSS

VP/CSS shared the basic architecture and concepts of CP/CMS, which were revolutionary for their time. A control program (called CP in CP/CMS, VP in VP/CSS) created multiple independent virtual machines (VMs), implementing a full virtualization of the underlying hardware – meaning that each time-sharing user was provided with a private virtual machine. Each appeared to be an entire, stand-alone computer, capable of running any software that could run on the bare machine, including other operating systems. (This concept was pioneered with IBM's research system CP-40 in the first version of CP/CMS.)

This design was a departure from IBM's other monolithic operating systems. Isolating users from each other improved system stability: a bug in one user's software could not crash another user's virtual machine, nor the underlying control program. This approach made CP/CMS a superior choice for commercial time-sharing, and thus a strong foundation for National CSS as it broke new ground in what would become an important new industry.

Each VM created by VP ran a simple, single-user operating system called CSS, derived from IBM's Cambridge Monitor System. CSS allowed users to run programs, manipulate a file system, and manage virtual devices.

Since VP and CSS began life as CP and CMS, respectively, they closely resembled these systems, particularly in their early days. Continuous development and introduction of new features in both VP/CSS and IBM's VM led to significant differences over time; but the systems retained an obvious family resemblance.

IBM's decision to add virtualization and virtual memory features to the S/370 reflects the success of the virtual machine approach to time-sharing. Some credit for this belated decision has been attributed to IBM's awareness of the commercial success of National CSS.[1]

In 1968, the founders of National CSS saw that the CP/CMS operating system would be a good foundation for a time-sharing business – because of the system's technical merits, its ability to share mainframe resources among many interactive users, and its availability in source code form at no cost. Another firm, Interactive Data Corporation, reached the same conclusion. Each firm lured away key CP/CMS technical personnel from CSC, MIT, and Union Carbide.

National CSS quickly discovered, however, that CP/CMS initial performance was not adequate to sustain profitable operations – that, literally, selling every available minute of interactive time would only pay for the $50K/month equipment lease. A crash technical project began to improve performance; this led to a number of fundamental enhancements, and soon allowed the business to make money. Thus began a lengthy reimplementation effort that would occupy a large development team over the course of some fifteen years. At the end of its lifespan, VP/CSS had diverged a long way from its CP/CMS roots, and boasted a surprising array of features, some of which would be considered quite modern even today.

Key enhancements to the original CP/CMS system included changes in the dispatching algorithm and the paging system. Virtual memory was of course a new concept at the time, and the IBM System/360-67 address translation technology enabled various technical approaches. Ultimately, the VP/CSS page migration algorithm and three-queue dispatcher became well-known, and some NCSS personnel eventually joined IBM's Thomas J. Watson Research Center to work on VM technologies.

Another area for throughput improvement was in the performance of the CSS single-user operating system. One important change was replacing Channel Command Words (CCWs) and other expensive simulated instructions with something like what today are termed BIOS calls. Simulating the complex S/360 I/O architecture through virtualization was an amazing feat – done in CP's complex innermost core, in a routine called "CCWTRANS," as I/O operations were trapped within each virtual machine. However, it proved enormously cheaper to make direct hypervisor calls for targeted functions, rather than simulating the operation of low-level I/O commands. In VP/CSS, this was done using paravirtualization via the non-virtualized DIAG (diagnose) instruction. The same technique was used by IBM in CP/CMS release 3.1, and carried forward into VM/370. (It is unclear which implementation came first – or whether they were invented independently.)

Early National CSS technical efforts quickly established VP/CSS as a commercially viable version of CP/CMS. VP/CSS was reputed to have much better performance than IBM's reimplementation of CP/CMS, VM/370 – which in turn was reputed to have a substantial performance advantage over IBM's "preferred" timesharing solution, TSO. Unfortunately, documented period performance statistics are hard to find today. However, there are several data points that support such claims.

• Regarding VM/CMS performance relative to OS/TSO:

1. Numerous VM documents, such as Varian's famous paper, cite "CP's performance advantages over TSO".[2]
2. From structural arguments, it is reasonable that CMS under VM should consistently outperform TSO under OS. VM was designed as a time-sharing system, and had a substantial technical edge in running interactive applications.
3. OS/VS had well known performance problems in this period. (The MVS performance group famously adopted the turkey as the operating system's mascot.)
4. CP/CMS started with good relative performance; and then a broad range of performance improvements followed.

• Regarding VP/CSS performance relative to VM/CMS:

1. NCSS had a strong commercial incentive to run as many users as possible, a pressure not present at IBM.
2. NCSS succeeded in selling large VP/CSS site license installations to the likes of Bank of America and Standard Oil of California for time-sharing use – in spite of the manifest problems that such large IBM customers would face by going against the IBM mainstream.

The following relative performance is believed to be accurate, although documented sources remain to be located:

• CP-67 on S/360-67 at Lincoln Laboratory: able to support 15 CMS users[3]
• OS/VS2-TSO on S/370-168: able to support 35-50 TSO users
• VM/370 on S/370-168: able to support 75-100 CMS users
• VP/CSS on S/370-168: able to support 200+ CSS users

As described in History of CP/CMS, IBM's primary emphasis on MVS and its successors as its core mainframe operating system led IBM to waste the substantial technical advantage represented by VM/370. This made it possible for an independent vendor like NCSS to strike into new territory. (Industry observers have pointed out that a hardware vendor has a natural preference for selling more hardware than for increasing the number of users per machine.) NCSS gained technical advantages, and ultimately became very successful commercially, despite the fact that the optimization techniques it used to enhance VP and CSS performance were well understood, and well-documented in the literature of the day.[4]

Ultimately, after Amdahl Corporation publicized its sales wins at several large VP/CSS data centers, IBM began to pay more public attention to NCSS and its technical innovations. Not long thereafter, as the time-sharing industry began to feel pressure from the personal computer revolution, the need for a super-optimized multiuser mainframe operating system waned.

NCSS moved away from VP/CSS in the mid 80s, retargeting Nomad for VM and other platforms. It is unknown how long any NCSS site-license customers continued to use VP/CSS on their own equipment (though it seems unlikely any could continue for long without ongoing NCSS operating system support).

• CP/CMS
• History of CP/CMS
• Time-sharing system evolution

• Feinleib, Harold (2005-03-04). "A technical history of National CSS" (PDF). Computer History Museum. Retrieved 2008-02-23.
• Orenstein, Dick (2005-01-14). "From the very beginning...from my vantage point" (PDF). Computer History Museum. Retrieved 2008-02-23.

• The Computer History Museum's Information Technology Corporate Histories Collection has many additional first-person accounts of National CSS and VP/CSS.