In <[email protected]>, on
03/26/2014
   at 07:00 AM, Paul Gilmartin <[email protected]> said:

>OK. An FTP server can't "communicate with itself".  I never said it
>could. I don't know why you're asking.

Because that's the TCP/IP analog to NJE talking to itself.

>I don't know the NJE jargon.  What is the analogue of a "client"
>from which jobs might be submitted,

There is none. NJE is a peer-to-peer protocol for jobs and other
entities that something has already submitted. The mechanism for
submitting a job is outside the scope of the protocol, just as the
editor used to create a file is outside the scope of FTP. For MVS you
use an internal reader to submit a job. either explicitly or under the
covers. For other systems you use something else. Similarly, if a job
creates a sysout data set then the ultimate disposition of that data
set is outside the scope of NJE, just as there is nothing in FTP to
affect what you do with a file after you FTP it.

>The complaint (however mild) was that it's relatively difficult to
>submit jobs via NJE to run on the local host,

In fact, it's impossible. It is, however, trivial to submit jobs to
JES[2|3] in an NJE network to run on the local host, and doing so does
*NOT* require the local node to talk to itself.

>With FTP, there's no differential in difficulty.

With FTP, a local client can talk to a local server. Again, neither
can talk to itself.

>Why is it harder with NJE?

That depends on what "it" is. The analog of what you are asking NJE to
do is for an FTP client to talk to itself or for an FTP server to talk
to itself, neither of which is possible.

>Is it simply that the local host is customarily left out of the 
>routing tables?

No, it's that NJE was not designed to talk to itself and nobody has
ever shown that there would be any utility in allowing it.

>Someone else suggested that with a /*ROUTE command it could be 
>done.

No, they suggested that a /*ROUTE could do what you really wanted, as
opposed to what you asked for.

>o Regardless how simple, this is modifying the JCL, probably
>  making it ineligible to run on other systems until it's changed
>  back

How would you expect the software to determine that the intended
routing is not what you have in the JCL? How would allowing the local
node to talk to itself facilitate that determination?

BTW, I would probably use the shorter /*XEQ JECL statement.

>o Does this work by routing the job to an (arbitrarily chosen)
>  remote host which sends it back?

No, it works by noticing that the node name given matches the node
name of the local node.
 
-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to