Go back to On-Line-Docs

The Control of Multiprocessing

The game is to keep a big expensive machine "computing" even though one or more "programs" in the machine are waiting for

It is lots of fun talking about

but the rubber hits the road when you ask an operator(s) to control this swirling mass

Early ( not first ) multi processing - excluding "time sharing".
My first "experience" was with the General Electric 625.

Each task had its own block of protected memory, a supervisor program could set up the memory bounds, and load, start, stop the "application" program. The "application" could not read/write out of its assigned memory, but could "trap" into the supervisor program for service requests.

There was an IBM typewriter on the console - and life seemed very clumsy - operator had to sort through pages of type outs, remembering Job Ids, and the thread through the various jobs. And if the overworked typewriter failed in some way
- ribbon, paper
- mechanical unit on "solid state reliable" computer
- ...
there was an interesting mess to painstakingly try to resolve.
Was job ??? hanging waiting for a specific tape???

CDC 6x00 machine
My next experience was a CDC 6x00 machine with the twin boob tubes.
Using the prevalent SCOPE operating system,
- Operator had 8 control points ( 8 jobs ) usually left screen
- Operator selected details (or chess game) usually on right screen.
- Great control from keyboard !!
An ENORMOUS improvement !!!

Unfortunately - these is only slight standardization of nomenclature between manufacturers

On a 2009 trip to the Washington, DC area,
a docent at National Electronics Museum told me that he had worked for/at the U.S. Social Security agency. He told wonderous tales of multiple System/370 Model 165 systems per floor, with ?shared? tape robots, tape operator's console for tape requests/responses, rooms of printers with printer operator's console for printer operator instructions. Massive operations far above my experience. He told of modifying IBM system code to divert tape and printer operator instructions to the appropriate consoles. Unfortunately he was not interested in writing his experiences or system descriptions.

so, when Lee Veal - < lveal @ prodigy . net . mx >
talked about "guest machines" at a Garland, Texas site, I had no clue if he was talking separate hardware or what.
Under the operating system called Virtual Machine (VM) of which there have been many versions, VM/ESA was the one that was just about to come out when I retired. Before VM an operating system had complete control of all resources in the real machine. An operating system controls the address space in the machine; it could define the user program space as 1 partition or multiple. With VM at the base, though it controlled all real resources on the real machine. However, it allowed for virtual address spaces where other whole operating systems could run in a virtual environment. 'Virtual' means 'in essence but not in fact', so 'guest' operating systems like DOS/VS, DOS/VSE, DOS, OS-PCP, OS-MVT, MVS and on and on could run in an environment which for all the world looked to the 'guest' like a 'real' machine, but it wasn't because VM was creating an illusion that the environment was real. It was an environment that looks real, and the 'guest' operating system/machine could not tell that it was not real.

Before VM we had DOS/VS running 5 partitions (1 was the spooler, 1 was the CICS teleprocessing system, and there 3 batch partitions.) DOS/VSE gave us 12 partitions. The problem was we still only had 1 address space in the real computer, and it was getting really crowded because we had every on-line application running in one partition. The solution was to install VM, then to carve the one big on-line system into multiple parts that didn't have to communicate with each other. The Police and Court systems talked and communicated with each other, they were in one guest machine. The Utility Billing system was in another guest because nothing that happened in that system had to communicate directly with any other system. One guest machine was for all the General Accounting systems because it like the others never dealt with other systems directly. Each of these three guests were running in a virtual environment with their own guest operating system, their own teleprocessing system their own spooler, everything they needed was there virtually (in essence but not in fact), but to the guest operating system and everything in that environment it looked like 'in fact' it was there.

Another virtual guest machine was an on-line test environment where any program could be run without danger of crashing the whole system. A test program could crash the the virtual environment, but it couldn't crash the 'real' environment.

The last virtual guest was used for batch programs only. It was the 'guest machine' we actually used to run those payroll, billing, status reports programs, etc It was as if we had 5 different computers because each 'guest machine' running under the control of VM's hypervisor which was managing the real set of equipment resources in such a way that whatever was running in a 'guest' machine thought that it was running all by itself.

I don't know what the IRS, Soc. Sec. and other big systems use now. I know that when I used to receive actual checks from the gov't (instead of having them direct deposited), I was pretty sure that the checks were being printed to a 1403 or a 1403-N1 (chain or train, respectively) instead of a drum-style printer.

EDS, Ross Perot's company in Dallas, used to do process a lot of company's big batch jobs like payroll, etc. They use large IBM MVS systems.

A lot of businesses are using mid-range systems to process their big batch load and even on-line systems now. The unfortunate thing is that mid-range systems are too oversold and under configured. After several upgrades in the start-up phase it sort of works. Immediately, though, planning starts to scrap the barely adequate system and replace it ASAP with the bigger, faster, higher capacity system that should have been installed in the first place. But often by this time the big iron has already been pushed out the door because the new system sort of works. What a lot of folks didn't pay attention to was the mid-range systems were designed for mid-range application loads. A mid-range system wasn't designed to have a big system's load dumped on it. A lot of money was supposed to be saved, but rarely was any money saved.

You may have seen this video, but even if you have, it's quite complimentary of the 1401. http://www.ibm.com/ibm100/us/en/icons/mainframe/

Lee

p.s. In a VM environment, if the systems programming staff has made a bunch of mods to the system and wants to test them, they can run the modified VM in a guest machine of the unmodified VM. It'd sort of be like running Windows under Windows so that the new version could be tested.

If you have comments or suggestions, Send e-mail to Ed Thelen

Started Feb 24, 2011