14 August 2006

Intro to Client/Server Computing-1

The IBM Stretch 7070 7030 with a teletype for interface; the operator console on the extreme left of the upper photo was for maintenance & service. IBM built eight of these.

It's difficult to sort through the colossal variety of client/server computing formats, which all seem like a fairly old idea with many hairline distinctions. The basic concept has been with us from the beginning of a serious commercial computer industry: people didn't exactly have a Stretch sitting on their desks!

Readers are reminded ahead of time that this blog is autodidactic and entries are likely to have errors. Why waste time reading it then? Well, I'll be linking to information sources that are of much greater reliability than this.

First, let's discuss a few of the motives for client/server computing systems. From the beginning engineers have sought to built a reliable and safe way for multiple users to use the same processor at the same time. How could this be dangerous? One risk is that the computer, attempting to run multiple jobs at the same time, gets the thread for any two mixed up. Computer processors typically economize on register space, so designers have to ensure that the kernel--the program responsible for allocating register space, among other things--does not run the risk of having data from one user thread get inserted into that of another. Overcoming this challenge was to become a major preoccupation with the various computer manufacturers, most famously IBM. IBM's System/360 was supposed to have been introduced with a multi-user interface, but the software division failed to create one. Fortunately, the University of Michigan developed MTS. Another multi-user operating system for mainframes was Multics, which was influential in the development of Unix.

The great motivator to overcome these obstacles was the expense of computers; most computers were leased to large organizations, and lease rates were typically so high that only a few large organizations could afford one. Moreover, once an organization (such as a university) had a computer available, there was the problem of training personnel to use it. Writing programs required lots of time spent unproductively. Finally, processing speed was a major concern for engineers. Once a very fast computer was developed, it made sense to ensure its capacity was constantly utilized, which suggested that some overlap in user access would be necessary.

The concept of multiple access developed along competing lines. One line was MVS, actually a latecomer to the technology since it was introduced in 1974, long after MTS and Multics. MVS is actually a dynasty of successive operating systems, like Windows; in recent years it has been known under different trade names, such as z/OS. The essence of the MVS approach to supporting multiple users was to introduce each progam-user (instance) as a batch process. This minimized any application interference with the operating system, or with its close collusion with the IBM architecture.

Alternative to MVS was VM/CMS, another OS created for the IBM System/360. The name comes from two separate operating systems that were integrated to handle separate functions. The virtual machine (VM) was responsible for allocating data among instances by providing them with a "virtual" (i.e., software-simulated) mainframe. VM was so elegantly designed that it was possible to run multiple instances of VM on a single instance of VM, without any penalty in performance. In order to achieve this feat, the virtual machine had to be so convincing it could load and run itself exactly as if it were a tangible computer. This is quite useful because it makes the computer running VM far more difficult to crash.

(VM is used in this sense as a product name; however, VM refers to a generic concept, very closely related, of the virtual memory. )

VM was developed with its other half, the Conversation Monitor System (CMS), which was actually responsible for the time-sharing part of the system. VM/CMS was among the first of the operating systems to have a life [mostly] independent of the vendor's wishes, and it is in common use today. VM/CMS differs from MVS in the sense that VM/CMS (and its successors, VM/ESA and z/VM) have a federal division of the entire computer's resources, whereas MVS (now z/OS) is more of a unitary state.

Digital Eguipment Corp. (DEC) differed from IBM in that it was "politically" aligned with the large population of "dwarves" that resisted IBM's attempts to rule by decree. Its fleet of minicomputers were fundamentally different from IBM's mainframes, not merely in size, but also architecture and usage. Digital machines generally were closer in conception to the modern home computer, in which the organization of computer processes assumed multiple users or multiple programs (instances), and response to user "events" such as the typing of a command. With the VAX/VMS series, Digital introduced virtual addresses to accommodate 32-bit words, an innovation that swept away its competition. One feature that was especially consequential was "clustering," or distributed computing. This allowed a network of linked VAX machines to distribute a processing job among themselves.

(Part 2)
ADDITIONAL READING & SOURCES: "Introduction and Overview of the Multics System"; "The Creation of the UNIX* Operating System"; "What is MVS?," Pam McCann and David Migliore; PDP-8 FAQ;

"The Elements of Operating-System Style" & "Operating-System Comparisons"The Art of Unix Programming (online book) by Eric Steven Raymond;

Labels: , ,


At 3:46 AM, December 06, 2006, Anonymous Anonymous said...

This note starts out wrong in its caption. A STRETCH was an IBM 7030, not a 7070. 7070 was a decimal machine, a "transistorized 650," not nearly as big or rare. See http://www.multicians.org/thvv/7070.html

The subsequent discussion of operating systems is chaotic, jumping around in time and mixing systems of different generations.

(tom, editor, multicians.org)

At 11:59 AM, January 20, 2007, Blogger jrm said...

Thanks for visiting Tom, and sorry I haven't responded sooner. Regretably, I'm trying to educate myself on this subject and this is at the beginning of my research. I apologize for shortcoming arising from this, here and elsewhere.

I greatly appreciated your article. Any other criticism would be welcome.


Post a Comment

<< Home