Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 12/28/2012 10:56 AM, Jack Coats wrote: > VM370 was pretty good. Of course it was not built as an OS but as a > hardware emulator. (IBM initially built it because they couldn't afford a > mainframe for every development group, hardware and software, to use.) > > I was a sysprog for several years at a big company where we had thousands > of users logged in and mainly active running anything from CMS to MVS under > VM. (CMS was a single user simple OS that most interactive users used. We > often ran entire VM systems second level to do production work especially > for disaster recovery testing, testing new releases of VM or other systems, > or on rare occasion for better computing security. > > VM took about 5% of the hardware 'bandwidth' to run the VM. But like was > mentioned it was very efficient at virtual memory. To test, the most VM I > ran under VM was 6 levels deep. Even with a nice size mainframe, it was > terribly slow at that many levels of VM running under each other. > > But like was mentioned for VS1, most OSes could detect that they were > running 'second level' (or further) and passed back up to the top level VM > to actually handle the paging/swapping (and there was a difference back > then). > > VMs were not new with IBM either. I think it was Burroughs that used them > and published on it way before IBMs VM came about. > > Oh, and to let the secret out, the way IBM did VM was to use a 'diagnose' > instruction which was officially an un-authorized machine language > instruction so it generated an interrupt and an interrupt service routine > took over (just like would happen when there was a I/O operation end or a > hardware timer go off, or violating virtual memory boundries). The > interrupt service routing looked at the instruction and the byte or two > after it in the 'user memory' to determine if it was a 'real diagnose' or > 'a user problem', and took appropriate action. The diagnose was initially > an instruction used by the IBM CE (customer engineer) in their hardware > diagnostic programs, but the software guys got in on the act too. > > Oh on each mainframe we typically ran around 2000 CMS users and a MVS or > two for batch or to take care of SNA networking. RSCS was another virtual > system that ran the network communications. VM did it's own spooling and > driving of printers and such directly, but it could let guest operating > systems like MVS or VS1 deal with it too. > > And yes, we had a source code license, and we did no occasion read the > source code. There were many places in the source that the documentation > was not 'kept up' or did not describe what the code really did, so we still > had to be able to read the assembler. Most of VM had been rewritten from > assembler to SPL (System Programming Language, similar to PL/1) by the time > I got into the arena in the early to mid 80's. > > My first UNIX was running Amdahl's UTS under VM. A different animal when > working on block mode terminals. We did bring up UTS on first level a time > or two for play, and it did scream. In those years we did a lot of seismic > processing on Perkin-Elmer machines (small IBM 360 type clones), and they > ran their own unix-like system but with a more MVS style JES JCL (job > control language) flavor. > > One consultant we had on VM over the years was on the initial HASP > development team in Clear Lake City at NASA. NASA had a lot of big iron > mainframes in those days, but even their budget couldn't support what IBM > told them they needed, so NASA said they needed a way to share input and > output peripherals (mainly card readers and line printers in those days), > so IBM put together a small team to make it happen. In just a few months > they did come out with the first cut of HASP (Houston Automatic Spooling > Program). It basically ran all the cards to disk, then fed them to > computers (not just 1) on demand. And took the 'printer output' as > generated on each computer and saved it to disk till the job on the other > computer was done, then put it in a print queue. Saved a lot of hardware > and IBMs collective butt at NASA. IBM was almost thrown out over it, but > HASP saved the day, and went on to be a big cash cow and saved mainframes > for many years. It eventually was 'virtualized' and rolled into the basics > of JES in its flavors (Job Entry System that also handled spooling > printouts, and job control networking). > IBM actually developed it on the IBM 360 where they had some contracts that required virtual memory and neither OS/MFT nor OS/MVT was Virtual Memory capable (it was called CP/360 for the high end 360 systems). But, yes, it was a hardware emulator and had some very good benefits. We sold our 370/135 to an insurance company in San Antonio who had some ancient applications that would not run on a 370 native. I don't know if Burroughs had a VM, but they did have virtual memory before IBM. Burroughs had an operating system, MCP, that was very efficient. -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |