On 24 March 2014 08:11, Paul Gilmartin <paulgboul...@aim.com> wrote: > On Sun, 23 Mar 2014 20:12:49 -0400, Shmuel Metz (Seymour J.) wrote: >> >>I''m not asking a question; I'm pointing out a false analogy. "TCP/IP, >>in contrast, is blessedly tolerant." makes no sense. >>... >>I'm asking in what sense TCP/IP is more tolerant than SNA. It's >>certainly not in the ability to run multiple applications on the same >>host, since SNA does that as well as TCP/IP does. >> > I can use FTP (a TCP/IP protocol) to submit jobs to localhost. I > do not need multiple TCP/IP stacks to do this; only a conventional > TCP/IP configuration. Generally, TCP/IP-based protocols such as > FTP, HTTP, SSH, ... can communicate with localhost with no > special configuration. The discussion here indicates that to use > NJE to submit jobs or otherwise communicate with the local host > requires some unusual configuration such as multiple instances > of JES or multiple instances of NJE. So, I perceive TCP/IP as > more tolerant; it has no bias against the local host.
Nonetheless the analogy fails. NJE is a protocol (and loosely, an implementation of the protocol) that uses an underlying transport layer of SNA or TCP (or originally and perhaps long gone, BSC, which predates most notions of layering along the lines of TCP/IP, OSI, and so on). There is no reason to expect all users of a transport layer to implement the same functionality. In the cases of FTP and Telnet, there is notionally always a client and a server, and certainly a client on one system can connect to and meaningfully use the services of a server on the same system. In the case of NJE, each endpoint is a "node". (Poor choice of word, perhaps, but we're not here talking of graph theory or CS trees, and one can even argue there are leaves in NJE, though they're not called that.) Each node both provides services and acts as a client to other nodes, and there are well defined rules for the routing and transmission of units of work (jobs, sysout, etc.) from one node to another, possibly via intermediate nodes. It is not a deficiency or lack of generality that a node is not willing to talk to itself as though it were another node, any more than is the refusal of a web server to talk to other web servers, or Telnet clients to other Telnet clients. To allow this -- to some unclear end -- routing rules would have to be changed to avoid loops, and the system as a whole would surely be allowed to optimize out the unnecessary sending of a UW from a node to itself, as it does today when you use e.g. /*ROUTE XEQ <localnode>. There's another view of all this. Historically, although as Lynn Wheeler has pointed out innumerable times the JES2 implementation of NJE had a fuzzy mix of routing and transmission protocols with SPOOL related matters, one can think of NJE as a routing scheme using BSC as the link layer, with the routable units being spooled units of work. In the early days of NJE, Vnet, Bitnet, and smaller intra-company networks, it was entirely normal for units of work to be routed through multiple nodes on the way to their destination. In this model, the NJE nodes were analogous to today's IP routers, with the services (printing, job execution, etc.) provided at a leaf, implemented on a node and unfortunately to some extent integrated into the same code that provided the routing. Indeed the larger networks (Vnet, Bitnet) had a number of routing-only nodes and what we would today calle firewalls or gateways that provided no local services at all. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
