On Tue, 25 Mar 2014 18:39:55 -0400, Shmuel Metz (Seymour J.) wrote: >In <[email protected]>, on >03/25/2014 > at 11:46 AM, Paul Gilmartin <[email protected]> said: > >>A single TCP/IP stack "can communicate with itself". > >You're still evading the question, although I'm not sure what you mean >by "communicate" in this context[1], or why you would want it to. Can >an FTP server communicate with itself? > OK. An FTP server can't "communicate with itself". I never said it could. I don't know why you're asking.
>[1] Certain two TCP/IP applications using the same stack can > communicate with each other, but that has nothing to do with > the stack communicating with itself, just properly forwarding > packets. If you are referring to two applications using the > same stack, how does that differ from two applications using > the same VTAM? > I don't know the NJE jargon. What is the analogue of a "client" from which jobs might be submitted, and which writes output to a printer, and of a "server" which places jobs in the spool or reads output from the spool of the system on which it runs? The complaint (however mild) was that it's relatively difficult to submit jobs via NJE to run on the local host, and relatively easy to submit them to run on a remote host. With FTP, there's no differential in difficulty. Why is it harder with NJE? Is it simply that the local host is customarily left out of the routing tables? Someone else suggested that with a /*ROUTE command it could be done. But: o Regardless how simple, this is modifying the JCL, probably making it ineligible to run on other systems until it's changed back o Does this work by routing the job to an (arbitrarily chosen) remote host which sends it back? Ugh! -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
