The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
chrisma...@belgacom.net (Chris Mason) writes: > [2] http://www.garlic.com/~lynn/gcard.html > > [3] There is actually a mistake on the supposedly "green card" text in that > the > machine "Immediate" "space 0 lines" should be X'03', that is, a > "no-operation" - > because - think about it - nothing happens! my gcard.html ... was q&d conversion of (CMS) IOS3270 file that was widely available internally, I wasn't the original author, but had added the *sense* information in the file ... most of which came from the 360/67 (blue) "reference card"; see bottom of web page for original attribution. scan of "real" green card: http://www.bitsavers.org/pdf/ibm/360/referenceCard/ gimick that VNET/RSCS used for networking control ("TAG") information was a no-op ('03') ccw pointing to the control information (with length of the information) ... aka VNET/RSCS used the cp (unit record) spool system for all its files ... so everything had to look like a printer or punch stream (generated with appropriate channel commands, cp treated the no-op as no-op ... but would still copy the indicated data into its spool file). A major internal email client was VMSG. The PROFS group at one point acquired the source for an early copy of VMSG for the PROFS email client code. Later the VMSG author offerred to upgrade PROFS with latest VMSG version that had a lot more function ... the PROFS group denied that it was using VMSG and then attempted to have the VMSG author fired. That was suspended when the VMSG author pointed out that every PROFS message carried his initials in the comment portion of the RSCS network control ("TAG") information. RSCS/VNET was the dominant internal networking infrastructure ... part of it was because of the NJE (HASP/JES) heritage using the HASP psuedo device table to define networking nodes. The internal network was larger than the arpanet/internet from just about the beginning until sometime mid-85 or early 86. misc. past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet The early HASP networking source code changes had "TUCC" out in cols. 68-71 ... and used the left-over entries in the one-byte index (255 entry) psuedo device table; installations frequently had 60-80 psuedo (unit record) devices (printer, punch, reader) ... which left less than 200 for defining networking nodes. By the time JES2/NJE shipped, the internal network was already over 200 nodes. Corporate wasn't even going to allow RSCS/VNET to be announced (this was in the period when POK had convinced corporate to kill off vm370, shutdown the burlington mall development group and move all the people to POK ... justification was because POK needed all the people in order to meet the MVS/XA ship schedule; endicott eventually managed to save the vm370 product mission, but had to reconsitute a group from scratch; head of POK is also considered a major contributor to VAX/VMS because so many people left for DEC rather than move to POK). The JES2/NJE group did manage to talk the corporation into a joint JES2/RSCS product announcement. The issue was that even at the minimum monthly rate that could be charged for corporate product ... it would still cover the VNET/RSCS development costs. However, there was no customer forcast at any monthly price that would cover the NJE development costs (number of customers times monthly rate was always less than NJE costs; as projected monthly rate went up, the number of forcasted customers declined). The way out for JES2 was to combine the RSCS+NJE costs divided by the combined RSCS+NJE customer forcast ... which finally resulted in number the business people could agree with. VNET/RSCS had a fairly clean layered implementation ... which among other things allowed native drivers to co-exist with NJE drivers. In fact, VNET/RSCS quickly became mechanism to keep different JES2s from crashing MVS. JES2/NJE had jumbled up networking information and JES2 control information ... and network traffic between JES2 at different releases could result in JES2 failure, also taking down the MVS system. As a result, there was a growing library of VNET/RSCS NJE drivers ... allowing the specific NJE driver for the release of JES2 on the other end of the link. The VNET/RSCS NJE drivers also had a growing body of code that would rewrite NJE headers (originating from another JES2 system) to be compatible with the directly connected JES2 system. There is the infamous case of a modified San Jose JES2 system causing MVS systems in Hursley to crash ... and it being blamed on VNET/RSCS (because the Hursley VNET/RSCS NJE drivers hadn't been updated with the latest countermeasures for keeping incompatible releases of JES2 causing MVS to crash). misc. past posts mentioning HASP, JES2, and/or hasp/jes2 networking http://www.garlic.com/~lynn/submain.html#hasp Native VNET/RSCS drivers continued to be used on the internal network long after the decision was made to only ship (non-native) NJE drivers ... in part, because the native VNET/RSCS drivers were significantly more efficient and got higher sustained throughput. Similar VNET/RSCS technology (w/NJE drivers but w/o native drivers) was used during the 80s for educational BITNET in US and EARN in europe ... misc. past posts mentioning BITNET/EARN http://www.garlic.com/~lynn/subnetwork.html#bitmet By the time that JES2 got around to supporting 999 nodes, the internal network had exceeded 1000 nodes ... and by the time JES2 was upgraded to support 1999 nodes, the internal network had exceeded 2000 nodes. JES2 also had a nasty habit of not only discarding network traffic when the destination node wasn't defined in its table ... but would also discard traffic when the origin node wasn't in its table (so you never wanted JES2 in any critical location in the internal network) -- 40+yrs 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
