The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
m...@mentor-services.com (Mike Myers) writes: > Of course, we all know that PR/SM was eventually released and I have > always held that CMS under MVS helped pave the way for OMVS, but > that's only conjecture. re: http://www.garlic.com/~lynn/2010d.html#66 LPARs: More or Less? oh ... we did some amount of consulting to the executive pushing posix support into MVS ... nominally there was a business case that customers then would naturally move much of their posix workload to MVS platform. the issue in the early 80s was that there was a sharp decrease in the cost of building a computer platform ... lots of mini-computer & workstation vendors springing up all over the place based on some chip or another. the problem was that the proprietary operating system paradigm from the 60s & 70s ... didn't see a corresponding drop in costs. To some extent these vendors were being forced into something like a "portable unix" ... because of the drastically reduced costs to get it up, running, and shipped on their hardware platform. customers & the market then started getting caught up in this ... because it started to provide them with independence from proprietary hardware ... a software layer that supposedly offered relative portability across a wide-range of increasingly commoditised hardware platforms. This was large part of motivation behind POSIX standards activity ... further providing the market with hardware independence (and being able to easily switch to the most cost effective hardware platform). Few of the people associated with the MVS posix support understood the market drivers behind posix. as an aside, the executive responsible for the original MVS posix support ... was also out doing various and sundry other kinds of activity. One involved NCAR and Mesa Archival. NCAR had hierarchical storage system (early NAS/SAN) with 370 mainframe as controller and CKD dasd farm all interconnected with HYPERChannel to various supercomputers. supercomputer would send hyperchannel message to the ibm mainframe, the ibm mainframe would locate the data (possibly staging to disk) and load dasd channel program into the hyperchannel device adapter ... and return the channel program handle to the supercomputer. the supercomputer would then directly invoke the channel program (ibm mainframe being used for control but not for actual data flow). For a period, NCAR attempted to spin this off as a product in an independent company Mesa Archival ... with lots of funding by the executive also doing MVS posix support (and we were used to periodically review/audit how they were doing; part of it was migrating the ibm mainframe code to rs/6000 and replacing all the CKD disks with FBA disks). similar hyperchannel approach was done by some number of other institutions. in the standards groups for IPI disks and HIPPI channels ... part of the standard activity was HIPPI switch support for "3rd party" transfers (allowing the hyperchannel nas/san disk farm implementation to be mapped to IPI&HIPPI environment; aka controller setting up the transfer mechanics but actually occuring from/to a different processor). HIPPI was standardization of 100mbyte/sec cray channel ... being championed by LANL. The 3090 group tried to play in 100mbyte/sec HIPPI (disk arrays, high-speed graphics, misc. other stuff) ... but the 3090 channel interface was nowhere near fast enough. The only thing that came close was the extended store bus ... so there was this interesting thing done with HIPPI interface being cut into the side of the extended store bus. Then because the only operations to extended store were synchronous 4k byte moves, I/O programming for HIPPI channel became sort of analogy to PEEK/POKE operations (found in the PC world) using synchronous 4k byte extended store move operations (to "reserved" extended store addresses). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
