Ed Gould wrote:
I don't think SNA has anything like a DNS (warning my info is old). The
last time I did a 3745 gen you had to hardcode a lot of subareas.
Although I do think they have updated it since then (hope so anyway).
There were some route tables that could get hairy. I had access to the
RTG tool and it made a complicated map reasonably easy. IIRC, SNI was
another mess that helped, but it was still complicated. JES2 could add
complexity as he could start routing output via another node that you
didn't expect if you weren't careful. To most (all?) nodes in my 200+
node JES2 network I turned off the JES2 routing as we were connected all
over the place and I did not want the output to be done through a 3rd
party node.
I suppose if the nodes were all one company it wouldn't make a
difference. But financial information was too important to let others
see it.
re:
http://www.garlic.com/~lynn/2006l.html#45 Mainframe Linux Mythbusting
(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
http://www.garlic.com/~lynn/subtopic.html#hasp
by the time JES2 networking was announced as a product, the internal
network had over 255 nodes
http://www.garlic.com/~lynn/subnetwork.html#internalnet
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 associated 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.
----------------------------------------------------------------------
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
