Mainframe Linux Mythbusting Was: Using Java in batch on zOS 3813

Ed Gould

re: (Was: Using Java in batch on z-OS?)

a lot of the original hasp-jes2 networking code running originally on the internal network still carried the "TUCC" identifier on source code "cards".

HASP had a 255 entry table for psuedo devices. the hasp-jes2 support started out defining networking nodes using unused entries in the psuedo device table. that typically allowed JES2 to defined something like 160-200 networking nodes. misc. past hasp &-or jes2 postings

by the time JES2 networking was announced as a product, the internal network had over 255 nodes

and by the time JES2 had support for 999 nodes, the internal network was over 1000 nodes, and by the time JES2 had support for 1999 nodes, the internal network was over 2000 nodes. JES2 would trash any network traffic that came thru the node, where JES2 didn't have the destination node in its local table. However, JES2 also would trash any network traffic where the originating node wasn't in its local table. This made JES2 almost unusable on the internal network except as carefully controlled end-node (not as any sort of intermediate store&forward node).

the other problem was that JES2 network architecture was notorious for getting networking mixed up with work load processing. relatively minor changes in header formats between releases could result in one JES2 system crashing another JES2 (and buttociated MVS) system. there is an infamous case on the internal network where a JES2 system in San Jose was causing a MVS system in Hursley to crash.

since the primary mainstay of the internal network had implemented gateway-like capability ... it also implemented a large array of different interfaces-gateways to JES2 systems .... allowing JES2 networking some modicum of participation in the internal network. because of the problem with one jes2 system causing other jes2-mvs systems to crash (due to even minor from changes in version-releases) ... there grew up compensating processes in the internal network jes2 gateway interfaces. basically a canonical jes format representation. An internal network interface that talked directly to a real JES2 node ... would be specific to that version-release of jes2 ... and eventually had the code that converted from canonical JES2 format to the format needed by that specific JES2 system (as countermeasure preventing different JES2 systems causing each other to crash).

....

as an aside ... the corporate requirements for the internal network required all transmission leaving a corporate facility to be encrypted. at one point there was the claim that the internal network had over half of all the link encryptors in the world. one of the harder issues getting internal network connectivity in various parts of the world was the issue of encrypted links crossing national boundaries ... it was frequently a really tough sell to get two (or more) different government agencies to all agree that a link going from one corporate location (in one country) to another corporate location (in a different country) could be encrypted.

disclaimer ... during part of this period my wife served a stint in the g'burg jes group.