sipp...@sg.ibm.com (Timothy Sipples) writes: > Let's take a brief look at this "not exactly new" history. I can fairly > easily trace JES3 back a quarter century. (Perhaps somebody else would like > to go back into the pre-Sysplex JES3 era, from 1973 to 1990, to see what > IBM recommended and/or required.)
trivia ... my wife was in the gburg JES group and part of the "catchers" of ASP (from the west coast) to turn into JES3. She then was part of the authors of JESUS (JES unified system) that combined all the features that the JES2 and JES3 customers couldn't live w/o ... but it never got very far because of various internal political issues. She then got con'ed into going to POK to be in charge of mainframe loosely-coupled architecture ... where she did "peer-coupled shared data" architecture. she didn't remain long because her architecture1 saw very little uptake ... except for IMS hot-standby (until SYSPLEX and parallel SYSPLEX). She was also being badgered by the communication group to force her into using SNA for loosely-coupled operation (there would periodically be a truce where communication group had strategic ownership of everything that crossed the datacenter walls and she could use whatever she wanted within a datacenter ... but then they would start badgering again). I can't speak to the other issues ... but on the JES2 networking side in the 70s & 80s ... not only couldn't JES2 talk to anything else ... talking to another JES2 at a different release level could result in taking down both JES2 and the MVS system. The issue was that JES2 networking implementation intermixed networking control and job control fields and minor release-to-release changes resulted in incompatible systems. On the internal network, JES nodes were kept at edge boundary nodes. Major internal network talked to JES nodes by using drivers that emulated JES protocol ... and because of the issues with JES incompatible release vulnerabilities ... a large library of internal network software drivers grew up that would not only format fields expected for specific JES release being talked to ... but also handle JES release reformating ... allowing different JES systems to communicate. I've periodically commented on the infamous case of files from San Jose disk plant site JES system resulting in Hursley MVS crashes ... and it was blamed on the Hursley internal network software. The actual issue was some new release-to-release JES field incompatibility and the internal network software driver library hadn't been updated to handle the new case (as part of countermeasure for keeping JES systems at different release levels from crashing MVS system). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
