The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Ed Finnell) writes: > Some of the ex-IBMers at SHARE claimed a CMS for MVS back in mid-eighties > that was 'shelved' for 'market considerations' whatever that is. Shortly > after > a RATSO(really advanced) project was started but didn't get much traction > with IBM. Don't know if was politics or personalities. I'm told it's in same > the > bin as the IBM internal clist compiler(CLIQ). re: http://www.garlic.com/~lynn/2008m.html#59 CHROME and WEB apps on Mainframe? http://www.garlic.com/~lynn/2008m.html#60 CHROME and WEB apps on Mainframe? in the mid-70s there was an small advanced technology symposium held in POK ... the 801 group was there (i.e. risc, precursor to romp, rios, current power, etc) and we were there with a 16-way 370 smp (which was going fine until it was realized that it was going to take MVS decades to come up with 16-way smp support). there wasn't another such sumposium until one i hosted in the early 80s ... reference http://www.garlic.com/~lynn/96.html#4a which included a presentation on running CMS applications under MVS. for other trivia ... the person responsible for APPN reported to the person doing the CMS under MVS presentation. We used to rib him on stop wasting his time on APPN and work on real networking. note that a lot of applications running under CMS were ported over from os/360 ... made possible by a little under 64k bytes of code that emulated os/360 system services. there was even a joke that the price/performance of the <64kbyte os simulation in cms was significantly better than the 8mbyte os simulation in mvs. somewhat in the same category as the internal clist compiler was some enhancements that better than doubled the capability of the cms os/360 system services emulation. a lot of the cms market segment was thruput and performance sensitive ... and while the "CMS under MVS" supported functional execution ... it didn't address the customer market requirements. I've mentioned before that the world-wide internal sales & marketing HONE system ... originally started out after the 23jun69 unbundling announcement ... to provide virtual machines for branch office SEs to keep up their skills running other operating systems ... but CMS\APL based applications supporting sales & marketing came to dominate all use (it wasn't too long before a mainframe order could only be processed after it had been first run thru a HONE application). Thru much of the early 80s, there were several repeated significant (failed) efforts to migrate HONE from vm370 to MVS. Part of the issue was HONE was part of the marketing group and every 18 months or so would cycle a new executive (typically having come from a branch manager's job). They could come in as the new HONE chief executive and find themselves extremely mortified to learn that HONE was a vm370-based system and figure they would make their name in the corporation by being responsible for the HONE migration to MVS. After 9-12 months of extensive effort, it would quietly fail ... the executive would eventually be replaced and it would start all over again. misc. past posts mentioning HONE. http://www.garlic.com/~lynn/subtopic.html#hone somewhat related, I had proposed an advanced technology new kernel project (i.e. which was the basic theme for the symposium I was sponsoring). my approach was to do a rapid prototyping effort (with a very small core of people) ... but somehow it got picked up as a strategic effort and got totally out of control ... at one point a couple hundred people just writing specifications. It eventually imploded under its own weight ... somewhat the way i had characterized the future system effort: http://www.garlic.com/~lynn/subtopic.html#futuresys in the strategic flavor of the new kernel effort ... part of the justification was about the significant (duplicated) cost of just doing device support and recovery software in the corporation's multiple operating systems. The "new" kernel would be common to all operating systems ... sharing common device support and recovery. slightly related ... they would let me play disk engineer in disk engineering lab (blg. 14) and disk product test lab (blg. 15). One of the things that they had tried was doing engineering development testing under MVS (in part so they could test multiple devices concurrently instead of the stand-alone dedicated time process they had been using). Unfortunately ... they found that MVS MTBF in that environment was on the order of 15 minutes (i.e. something requiring an MVS re-ipl/reboot). One of the things that I had done for them was work on a i/o supervisor rewrite that would allow multiple devices to be testing concurrently in an operating system environment (and wouldn't fail). I gave an (internal company only) presentation on the results (significantly improved disk engineering development productivity) ... which resulted in taking a lot of heat from the POK RAS manager. misc. past posts mentioning getting to play disk engineer http://www.garlic.com/~lynn/subtopic.html#disk -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
