1GTLEJS@CALSTATE.BITNET (Ed Skochinski) (02/08/90)
I avoided a detailed discussion of lids to bypass a discussion on NOS
host-to-host file routing. A brief, and what I hope is sufficient,
discussion follows as to why BITEARN NODES must have site-specified
"linkname=lid" entries for NJEF tables.
A "lid" is a three character "Logical IDentifier" which is associated
with a particular, physical host machine. One host may have several
lids. Each lid allows file routing to specify not only the host, but
certain routing and file residence characteristics. On closely
coupled hosts, a lid can specify which actual machine will run a job
or maintain a file.
For host-to-host routing, source and destination host must know about
each other, and must agree that the lids specifying the hosts are
defined. For sites with multiple NOS hosts wishing to route to each
other, each host must share a common set of lid definitions and
declarations.
CALSTATE (the entity, not the BITNET node) not only has multiple
CYBERS, but it has multiple sites with multiple CYBERs, all of which
route to each other in an interconnected topology (not
hub-and-spokes). Only one CALSTATE CYBER has a BITNET connection, and
the others have BITNET mail functionality, but through indirect access
via the central machine (a unified BITNET addressing space. An
entirely separate and complicated story...). The other machines route
queued files to/from the central machine via lid specification. With
so many hosts, lid naming conventions have been adopted. For GR to
algorithmically generate lids, it would have to guarantee that it did
not violate the conventions already in place, not only for CALSTATE,
but any other NJEF sites with lid naming conventions. The lid
definitions that GR would have to avoid have absolutely NO pertinence
to BITNET, and have accumulated a great deal of resistance to change
because a great deal of CALSTATE code depends upon the naming
conventions.
The NOS NJEF networking software implements IBM's NJE protocol. There
is no prohibition against having machines linked via NJE lines to
other possibly non-CYBER machines, invisible to BITNET---they just use
NJE as their communications protocol. NJEF requires a lid for each
neighbor, and GR would have to avoid generating duplicate lids. By
associating NJE node names and NOS lids, the NJE protocol fits rather
cleanly inside the NOS environment.
While three characters aren't a whole lot, they still can be mnemonic.
CALSTATE's neighbor is USCVM; the associated lid is "USC". This means
something to an analyst or user when viewing queued file statuses.
I'm not aware of any CALSTATE code which depends upon this value, but
other NJEF sites may have hardcoded dependencies.
Lids do more than just specify sources and destinations, they trigger
appropriate software to effect a file transfer.
Ed Skochinski
Operating Systems Support
The California State University