Re: Reflexivity (was: NJE Clarifications)
In 9607598388776077.wa.paulgboulderaim@listserv.ua.edu, on 03/25/2014 at 11:46 AM, Paul Gilmartin paulgboul...@aim.com 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? [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? -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
On Tue, 25 Mar 2014 18:39:55 -0400, Shmuel Metz (Seymour J.) wrote: In 9607598388776077.wa.paulgboulderaim@listserv.ua.edu, on 03/25/2014 at 11:46 AM, Paul Gilmartin paulgboul...@aim.com 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
Paul Gilmartin said: 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! That was me, and I'm not understanding your problem. Your first bullet: /*ROUTE XEQ name/nodename vs. an IP address. If you want to run on different systems, you have to modify -something-. Unless you want to run on the system you submitted from. Then you specify /*ROUTE XEQ LOCAL, and it works from wherever you are. Your second bullet: Nothing like imagining something, and shuddering in horror at the imagined sins. Which don't exist, in this case. What am I missing in your stated requirements? Cheers,,,Steve Steven F. Conway, CISSP Hosting Services Division, Cloud Technology and Hosting Office, AO-DTS-CTHO-HSD z/OS Systems Support Phone: 703-295-1926 Mobile: 703-402-2650 steve_con...@ao.uscourts.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Conway Sent: Wednesday, March 26, 2014 6:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reflexivity (was: NJE Clarifications) Paul Gilmartin said: 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! That was me, and I'm not understanding your problem. Your first bullet: /*ROUTE XEQ name/nodename vs. an IP address. If you want to run on different systems, you have to modify -something-. Unless you want to run on the system you submitted from. Then you specify /*ROUTE XEQ LOCAL, and it works from wherever you are. I think that some of this is a real difference between the way the two protocols work. Using FTP, I can submit a given JCL deck to any host I have access to and authority to run. I can do this without making changes to the JCL itself. Localhost is a valid target for my FTP PUT. I haven't actually used NJE much, but I don't think it supports changing the NJE target from outside the JCL deck. The /*ROUTE XEQ (inside the JCL deck) is the method for specifying the target node. On the other hand, /*ROUTE XEQ LOCAL seems equivalent to an FTP open localhost, and a put of a JCL deck to JES. :) Cheers,,,Steve Steven F. Conway, CISSP Hosting Services Division, Cloud Technology and Hosting Office, AO-DTS-CTHO-HSD z/OS Systems Support Phone: 703-295-1926 Mobile: 703-402-2650 steve_con...@ao.uscourts.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
A job can routed for execution to another NJE node by JES command. If there happens to a SYSAFF card, the job might not run until the SYSAFF name is changed or nullified, but JES commands allow a job or its output to be sent anywhere in the network by operator command. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/26/2014 11:03 AM Subject:Re: Reflexivity (was: NJE Clarifications) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Conway Sent: Wednesday, March 26, 2014 6:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reflexivity (was: NJE Clarifications) Paul Gilmartin said: 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! That was me, and I'm not understanding your problem. Your first bullet: /*ROUTE XEQ name/nodename vs. an IP address. If you want to run on different systems, you have to modify -something-. Unless you want to run on the system you submitted from. Then you specify /*ROUTE XEQ LOCAL, and it works from wherever you are. I think that some of this is a real difference between the way the two protocols work. Using FTP, I can submit a given JCL deck to any host I have access to and authority to run. I can do this without making changes to the JCL itself. Localhost is a valid target for my FTP PUT. I haven't actually used NJE much, but I don't think it supports changing the NJE target from outside the JCL deck. The /*ROUTE XEQ (inside the JCL deck) is the method for specifying the target node. On the other hand, /*ROUTE XEQ LOCAL seems equivalent to an FTP open localhost, and a put of a JCL deck to JES. :) Cheers,,,Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
That is true, but it is still a second action required after the JCL is submitted. Issuing the command requires use of a different interface (SDSF or (E)JES). I probably should have known better than to interject in a Shmuel/Gil discussion. :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Wednesday, March 26, 2014 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reflexivity (was: NJE Clarifications) A job can routed for execution to another NJE node by JES command. If there happens to a SYSAFF card, the job might not run until the SYSAFF name is changed or nullified, but JES commands allow a job or its output to be sent anywhere in the network by operator command. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/26/2014 11:03 AM Subject:Re: Reflexivity (was: NJE Clarifications) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Steve Conway Sent: Wednesday, March 26, 2014 6:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reflexivity (was: NJE Clarifications) Paul Gilmartin said: 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! That was me, and I'm not understanding your problem. Your first bullet: /*ROUTE XEQ name/nodename vs. an IP address. If you want to run on different systems, you have to modify -something-. Unless you want to run on the system you submitted from. Then you specify /*ROUTE XEQ LOCAL, and it works from wherever you are. I think that some of this is a real difference between the way the two protocols work. Using FTP, I can submit a given JCL deck to any host I have access to and authority to run. I can do this without making changes to the JCL itself. Localhost is a valid target for my FTP PUT. I haven't actually used NJE much, but I don't think it supports changing the NJE target from outside the JCL deck. The /*ROUTE XEQ (inside the JCL deck) is the method for specifying the target node. On the other hand, /*ROUTE XEQ LOCAL seems equivalent to an FTP open localhost, and a put of a JCL deck to JES. :) Cheers,,,Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
Skip Robinson is of course quite right. A job can be sent to any NJE node for execution by operator command, and operator commands can of course be generated. There are, however, simpler solutions. JCL that differs parametrically from one instance to another of its use is easy, very easy, to generate using, say, the HLASM's macro language, after which it can be handed off to the the internal reader. (REXX or the PL/I macro preprocessor could be used instead.) This pother about whether JCL is or is not changed is not really very interesting. It is either in error or it does something in any of its states, and defaults for the usual case are easy to provide. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
In 4657009561737029.wa.paulgboulderaim@listserv.ua.edu, on 03/26/2014 at 07:00 AM, Paul Gilmartin paulgboul...@aim.com 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
In 0de6a9840123e547b061ac5b6765c026dda...@exmb-05.ad.wsu.edu, on 03/26/2014 at 06:03 PM, Gibney, Dave gib...@wsu.edu said: I think that some of this is a real difference between the way the two protocols work. Not that I can see. I think that some of this is a real difference between the way the two protocols work. Using FTP, I can submit a given JCL deck to any host I have access to and authority to run. No you can't. You can submit a given JCL file to the primary JES on any host running an FTP server that you have access to. You can't control what node and member it runs on without modifying the JCL. I haven't actually used NJE much, but I don't think it supports changing the NJE target from outside the JCL deck. The /*ROUTE XEQ (inside the JCL deck) is the method for specifying the target node. The methods are not part of the NJE protocl, and /*ROUTE is not the only method. On the other hand, /*ROUTE XEQ LOCAL seems equivalent to an FTP open localhost, No. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
In 5228466182930420.wa.paulgboulderaim@listserv.ua.edu, on 03/24/2014 at 07:11 AM, Paul Gilmartin paulgboul...@aim.com said: I can use FTP (a TCP/IP protocol) to submit jobs to localhost. I do not need multiple TCP/IP stacks to do this; What does that have to do with the price of eggs in China? I asked for differences, not similarities. The question was and remains in what sense TCP/IP is more tolerant than SNA. Generally, TCP/IP-based protocols such as FTP, HTTP, SSH, ... can communicate with localhost with no special configuration. Again, that's a similarity rather than a difference, unless you are claiming that, e.g., an FTP server can communicate with itself over TCP/IP. 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. Not even close. So, I perceive TCP/IP as more tolerant; That perception appears to be based on something other than facts. it has no bias against the local host. Neither does SNA. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
On Mon, 24 Mar 2014 10:19:06 -0400, Shmuel Metz (Seymour J.) wrote: Again, that's a similarity rather than a difference, unless you are claiming that, e.g., an FTP server can communicate with itself over TCP/IP. A single TCP/IP stack can communicate with itself. Yes. over TCP/IP? It appears to, although I suspect it short- circuits the path. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
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. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
You can use /*ROUTE to route execution and/or SYSOUT to the local system, as well as remote systems. See Chapter 27 of the JCL Reference. I believe this meets your stated requirement of no extra setup, a simple JCL change to test, and so on. Cheers,,,Steve Steven F. Conway, CISSP Hosting Services Division, Cloud Technology and Hosting Office, AO-DTS-CTHO-HSD z/OS Systems Support Phone: 703-295-1926 Mobile: 703-402-2650 steve_con...@ao.uscourts.gov From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/24/2014 08:11 AM Subject:Re: Reflexivity (was: NJE Clarifications) Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU 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. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
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
Re: Reflexivity (was: NJE Clarifications)
In 7668784065325551.wa.paulgboulderaim@listserv.ua.edu, on 03/21/2014 at 03:52 PM, Paul Gilmartin paulgboul...@aim.com said: o NJE can't communicate with the local host. FSVO host. NJE can communicate between two distinct nodes on the same host, but neither node can communicate with itself. TCP/IP, in contrast, is blessedly tolerant. FSVO tolerant; try using the same port number, not just the same IP address. Why would anyone want to do that? Suppose I have a filter that tailors some JCL and submits it to a remote host. Running in your JES? That seems contrived. I might want to test a design without using a remote host. Secondary JES works fine for that. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
In cahtvvrwyciqkkofab1q7-t2xb7tpti1yyosuc5awvt9xfnt...@mail.gmail.com, on 03/21/2014 at 09:33 PM, Jake anderson justmainfra...@gmail.com said: Can this be possible in a MAS environment What are you trying to do? In MAS each system already has access to the SPOOL, so how would NJE be relevant? -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
On Sat, 22 Mar 2014 22:03:10 -0400, Shmuel Metz (Seymour J.) wrote: TCP/IP, in contrast, is blessedly tolerant. FSVO tolerant; try using the same port number, not just the same IP address. The question makes no sense; a server listens on a port; a client connects to that port. Give me more details of what you're asking me to try. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
In 4922808670825025.wa.paulgboulderaim@listserv.ua.edu, on 03/23/2014 at 10:58 AM, Paul Gilmartin paulgboul...@aim.com said: The question makes no sense; I''m not asking a question; I'm pointing out a false analogy. TCP/IP, in contrast, is blessedly tolerant. makes no sense. a server listens on a port And an SNA application on a host opens an ACB for a specific LU. Give me more details of what you're asking me to try. 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. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
To pick another example, IBM i (formerly i5/OS, formerly OS/400) also supports NJE. There it's known as the VM/MVS Bridge. Timothy Sipples VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
t...@harminc.net (Tony Harminc) writes: For many years (decades, actually) there have been other products (IBM and non-IBM) that talk the NJE protocols. Most notably, IBM's RSCS on VM uses an overlapping subset of the same protocol, and is interoperable. There have been NJE implementations for UNIX and other operating systems over the years, long predating NJE over TCP/IP. One popular product in the 1980s was JNET, from Joiner Associates, which ran on the DEC VAX. NJE originated as HASP networking at customer (source col. fields 68-71 use to carry TUCC). It defined nodes in the unused entries in the 255 table of psuedo (unit record) devices ... so number of nodes was typically limited to 160-180. It also had designed that it tossed traffic when it didn't recognize the original or destination nodes. The internal network had relatively early passed 255 nodes (the internal network was larger than arpanet/internet from just about the beginning until sometime late '85 or early '86) some past posts http://www.garlic.com/~lynn/subnetwork.html#internalnet and so NJE nodes couldn't be trusted except as edge nodes (since they were prone to tossing traffic). NJE also was relatively dirty implementation ... intermixing network and job control fields ... as a result NJE systems at different release levels exchanging traffic had habit of crashing the host (MVS). By comparison, RSCS was very clean layered network design ... done by coworker at the science center ... some past science center posts http://www.garlic.com/~lynn/subtopic.html#545tech reference http://en.wikipedia.org/wiki/Edson_Hendricks it didn't have the number of nodes limitations, didn't toss traffic when it didn't understand the origin ... and it's clean layered design was straight-forward to have drivers that understood other protocols ... useful in supporting JES/MVS as edge nodes. In fact, as the number of nodes exploded around the world ... and all JES/MVS systems couldn't be kept at the same release levels ... involving JES/MVS systems in one part of the world crashing MVS systems in other parts of the world ... a library of RSCS NJE drivers grew up that translated NJE header fields to canonical form ... and then a specific RSCS NJE driver would be used to convert any NJE fields to the appropriate format required by the NJE system at the other end of the link (as countermeasure to traffic crashing the host MVS system) ... there was the famous case of traffic from san jose (gpd) mvs system crashing mvs system in hursley ... and it being blamed on the hursley vm/rscs people for not having the correct vm/rscs nje driver started (to keep mvs from crashing). VM/RSCS was also the basis for IBM-sponsored BITNET for educational institutions (where this ibm-mailing list originated) http://en.wikipedia.org/wiki/BITNET some past posts http://www.garlic.com/~lynn/subnetwork.html#bitnet internal politics eventually stopped the shipping of native RSCS drivers, just the NJE drivers ... even though they continued to be used on the internal network, in part because they werre more efficient ahd had much higher throughput. then later, internal politics forced the move of the internal network to SNA/VTAM, at a time when it would have been much more cost effective to have moved to tcp/ip ... which BITNET did. Some old internal network related email http://www.garlic.com/~lynn/lhwemail.html#vnet including this reference to a little of the internal politics behind moving to sna/vtam http://www.garlic.com/~lynn/2006x.html#email870302 http://www.garlic.com/~lynn/20011.html#email870306 it was in the same time period that they were spreading misinformation internally that the NSFNET backbone (precursor to modern internet) could be done on sna/vtam ... somebody had collected a lot of the internal misinformation and forwarded it to us ... heavily snipped and redacted to protect the guilty http://www.garlic.com/~lynn/2006w.html#email870109 other old NSF related email http://www.garlic.com/~lynn/lhwemail.html#nsfnet past posts mentioning hasp, jes, and/or nje http://www.garlic.com/~lynn/submain.html#hasp one of the other early NJE issues was they couldn't find a valid business case to ship the product ... the standard internal process resulted in price much higher than customers would pay i.e. IBM still adjusting to having to charge for software (after the unbundling announcement). Eventually they came up with the hack that they would announce a joint vm/rscs and JES2/NJE product ... business case where they combined the costs revenue for the two products (pricing vm/rsc the same as jes2/nje ... where vm/rscs revenue was used to cover the jes2/nje costs... and eventually eliminating shipping native vm/rscs drivers helped with the facade). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send
NJE Clarifications
Hi, For an NJE to work we must have to two different nodes. Is there a way for NJE to work within a single Node(Monoplex) just to communicate to another product(As a socket-Running in same Node) ? Is there a case study for the NJE to work on a Monoplex environment ? I tried looking at the share site or JES2 tunning guide But I do not see anything about NJE on Monoplex. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
W dniu 2014-03-21 16:18, Jake anderson pisze: Hi, For an NJE to work we must have to two different nodes. Is there a way for NJE to work within a single Node(Monoplex) just to communicate to another product(As a socket-Running in same Node) ? Is there a case study for the NJE to work on a Monoplex environment ? I tried looking at the share site or JES2 tunning guide But I do not see anything about NJE on Monoplex. IMHO no. NJE is for JES to JES commnunication. You can have secondary JES subsystem, but this is unpopular solution and in this case maybe the JES instances can communicate vie NJE. However it's still JES to JES, not internal within-JES communication. Monoplex environment can use NJE to communicate to other JES nodes (monoplex of sysplex - as you need). BTW: what's your goal? What do you need to do? -- Radoslaw Skorupka Lodz, Poland --- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
Hi, I was just trying to understand this feature for our POC. NJE is for JES to JES commnunication. Can this be possible in a MAS environment(Where two LPARS have same Node) and communicate to a product running in either of 1 LPAR. On Fri, Mar 21, 2014 at 9:00 PM, R.S. r.skoru...@bremultibank.com.plwrote: W dniu 2014-03-21 16:18, Jake anderson pisze: Hi, For an NJE to work we must have to two different nodes. Is there a way for NJE to work within a single Node(Monoplex) just to communicate to another product(As a socket-Running in same Node) ? Is there a case study for the NJE to work on a Monoplex environment ? I tried looking at the share site or JES2 tunning guide But I do not see anything about NJE on Monoplex. IMHO no. NJE is for JES to JES commnunication. You can have secondary JES subsystem, but this is unpopular solution and in this case maybe the JES instances can communicate vie NJE. However it's still JES to JES, not internal within-JES communication. Monoplex environment can use NJE to communicate to other JES nodes (monoplex of sysplex - as you need). BTW: what's your goal? What do you need to do? -- Radoslaw Skorupka Lodz, Poland --- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: 526-021-50-88. Wed ug stanu na dzie 01.01.2014 r. kapita zak adowy mBanku S.A. (w ca o ci wp acony) wynosi 168.696.052 z ote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
On 21 March 2014 11:18, Jake anderson justmainfra...@gmail.com wrote: For an NJE to work we must have to two different nodes. Is there a way for NJE to work within a single Node(Monoplex) just to communicate to another product(As a socket-Running in same Node) ? For many years (decades, actually) there have been other products (IBM and non-IBM) that talk the NJE protocols. Most notably, IBM's RSCS on VM uses an overlapping subset of the same protocol, and is interoperable. There have been NJE implementations for UNIX and other operating systems over the years, long predating NJE over TCP/IP. One popular product in the 1980s was JNET, from Joiner Associates, which ran on the DEC VAX. Is there a case study for the NJE to work on a Monoplex environment ? I tried looking at the share site or JES2 tunning guide But I do not see anything about NJE on Monoplex. I don't know what you mean by a case study. Do you have a problem to solve that you think NJE can somehow address? Are you just trying to understand how things work? Or making up a checklist or the like? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
NJE is more precisely a means to connect two or more network nodes, any of which might be for example (z)VM RSCS as well as JES2 or JES3. Any task that follows NJE protocol can play in the game. 'NJE with oneself' has no meaning. All JES2 systems in a single MAS communicate with each other simply by putting 'something' into the common spool. For example, a job submitted for execution can in principle be executed on any member, and sysout from that job can be processed by any member. If one member needs to communicate with another member via SNA or via TCP/IP, then that communication must be set up outside of JES. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jake anderson justmainfra...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/21/2014 09:03 AM Subject:Re: NJE Clarifications Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi, I was just trying to understand this feature for our POC. NJE is for JES to JES commnunication. Can this be possible in a MAS environment(Where two LPARS have same Node) and communicate to a product running in either of 1 LPAR. On Fri, Mar 21, 2014 at 9:00 PM, R.S. r.skoru...@bremultibank.com.plwrote: W dniu 2014-03-21 16:18, Jake anderson pisze: Hi, For an NJE to work we must have to two different nodes. Is there a way for NJE to work within a single Node(Monoplex) just to communicate to another product(As a socket-Running in same Node) ? Is there a case study for the NJE to work on a Monoplex environment ? I tried looking at the share site or JES2 tunning guide But I do not see anything about NJE on Monoplex. IMHO no. NJE is for JES to JES commnunication. You can have secondary JES subsystem, but this is unpopular solution and in this case maybe the JES instances can communicate vie NJE. However it's still JES to JES, not internal within-JES communication. Monoplex environment can use NJE to communicate to other JES nodes (monoplex of sysplex - as you need). BTW: what's your goal? What do you need to do? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
W dniu 2014-03-21 17:03, Jake anderson pisze: Hi, I was just trying to understand this feature for our POC. NJE is for JES to JES commnunication. Can this be possible in a MAS environment(Where two LPARS have same Node) and communicate to a product running in either of 1 LPAR. It seems to be a candidate for sysplex communication. You have sysplex, because it's prerequisite fo MAS(*). AFAIK that require APF. BTW: what's wrong with TCP/IP? (*)Fine print: many moons ago it would be possible to have MAS without sysplex. Note, it may be basic sysplex. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
It has been around long before SYSPLEX of any sort. We called it 'Shared SPOOL'. Now it's Multi-Access SPOOL (MAS). - -teD - Original Message From: R.S. Sent: Friday, March 21, 2014 16:12 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: NJE Clarifications W dniu 2014-03-21 17:03, Jake anderson pisze: Hi, I was just trying to understand this feature for our POC. NJE is for JES to JES commnunication. Can this be possible in a MAS environment(Where two LPARS have same Node) and communicate to a product running in either of 1 LPAR. It seems to be a candidate for sysplex communication. You have sysplex, because it's prerequisite fo MAS(*). AFAIK that require APF. BTW: what's wrong with TCP/IP? (*)Fine print: many moons ago it would be possible to have MAS without sysplex. Note, it may be basic sysplex. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Reflexivity (was: NJE Clarifications)
On Fri, 21 Mar 2014 09:21:57 -0700, Skip Robinson wrote: ... 'NJE with oneself' has no meaning. ... There's a peculiar tendency of designers and testers to ignore, even shun, that reflexive boundary condition. o NJE can't communicate with the local host. o iconv used to reject input character set and output character set the same (it's better now). TCP/IP, in contrast, is blessedly tolerant. It even has a pseudo-hostname, localhost, for the purpose. Why would anyone want to do that? Suppose I have a filter that tailors some JCL and submits it to a remote host. Suddenly I want to employ the filter but run the job locally. Unless the design was sufficiently modular, I must modify the utility to detect and treat specially the local host case. I might want to use iconv to test a file against a character set for validity by translating it to the same character set. I might want to test a design without using a remote host. (One might be prudent to prohibit using a filter where the input and output files are the same. That can cause data corruption. But CMS COPYFILE operating on MDFS files always creates a temporary file and renames it at the end. This avoids corruption in the routine case, and somewhat protects against data loss even if the system crashes.) The OP thought he had a valid motivation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
The SORTs (Sync or DF) will happily allow SORTIN/SORTOUT to be the same file. And in today's world of lot'o'region and space this is probably safer than it used to be. They didn't fire me when in the first few weeks (many moons ago) on the job I used this trick on the payroll master tape. Ran just fine until the need to allocate buffers for the output phase died for lack of region. I don't know how the more senior programmer recovered the data, but it took him some hours. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, March 21, 2014 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Reflexivity (was: NJE Clarifications) On Fri, 21 Mar 2014 09:21:57 -0700, Skip Robinson wrote: ... 'NJE with oneself' has no meaning. ... There's a peculiar tendency of designers and testers to ignore, even shun, that reflexive boundary condition. o NJE can't communicate with the local host. o iconv used to reject input character set and output character set the same (it's better now). TCP/IP, in contrast, is blessedly tolerant. It even has a pseudo-hostname, localhost, for the purpose. Why would anyone want to do that? Suppose I have a filter that tailors some JCL and submits it to a remote host. Suddenly I want to employ the filter but run the job locally. Unless the design was sufficiently modular, I must modify the utility to detect and treat specially the local host case. I might want to use iconv to test a file against a character set for validity by translating it to the same character set. I might want to test a design without using a remote host. (One might be prudent to prohibit using a filter where the input and output files are the same. That can cause data corruption. But CMS COPYFILE operating on MDFS files always creates a temporary file and renames it at the end. This avoids corruption in the routine case, and somewhat protects against data loss even if the system crashes.) The OP thought he had a valid motivation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
The SORTs (Sync or DF) will happily allow SORTIN/SORTOUT to be the same file. And in today's world of lot'o'region and space this is probably safer than it used to be Dave, For DFSORT, your statement is true only if you are SORTING the data as for a copy application, the SORTIN data set should NOT be the same as the SORTOUT data set or any OUTFIL data set because this can cause lost or incorrect data or unpredictable results. Thanks, Kolusu DFSORT Development IBM Corporation IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 03/21/2014 01:58:33 PM: From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@listserv.ua.edu, Date: 03/21/2014 01:58 PM Subject: Re: Reflexivity (was: NJE Clarifications) Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu The SORTs (Sync or DF) will happily allow SORTIN/SORTOUT to be the same file. And in today's world of lot'o'region and space this is probably safer than it used to be. They didn't fire me when in the first few weeks (many moons ago) on the job I used this trick on the payroll master tape. Ran just fine until the need to allocate buffers for the output phase died for lack of region. I don't know how the more senior programmer recovered the data, but it took him some hours. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, March 21, 2014 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Reflexivity (was: NJE Clarifications) On Fri, 21 Mar 2014 09:21:57 -0700, Skip Robinson wrote: ... 'NJE with oneself' has no meaning. ... There's a peculiar tendency of designers and testers to ignore, even shun, that reflexive boundary condition. o NJE can't communicate with the local host. o iconv used to reject input character set and output character set the same (it's better now). TCP/IP, in contrast, is blessedly tolerant. It even has a pseudo-hostname, localhost, for the purpose. Why would anyone want to do that? Suppose I have a filter that tailors some JCL and submits it to a remote host. Suddenly I want to employ the filter but run the job locally. Unless the design was sufficiently modular, I must modify the utility to detect and treat specially the local host case. I might want to use iconv to test a file against a character set for validity by translating it to the same character set. I might want to test a design without using a remote host. (One might be prudent to prohibit using a filter where the input and output files are the same. That can cause data corruption. But CMS COPYFILE operating on MDFS files always creates a temporary file and renames it at the end. This avoids corruption in the routine case, and somewhat protects against data loss even if the system crashes.) The OP thought he had a valid motivation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sri h Kolusu Sent: Friday, March 21, 2014 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reflexivity (was: NJE Clarifications) The SORTs (Sync or DF) will happily allow SORTIN/SORTOUT to be the same file. And in today's world of lot'o'region and space this is probably safer than it used to be Dave, For DFSORT, your statement is true only if you are SORTING the data as for a copy application, the SORTIN data set should NOT be the same as the SORTOUT data set or any OUTFIL data set because this can cause lost or incorrect data or unpredictable results. I stand corrected. Improper assumption on my part. Was DFSORT named DFSORT in 1982? Thanks, Kolusu DFSORT Development IBM Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
And note that in this context a network node does not correspond to an LPAR (or the main SNA or TCP/IP designations for some LPAR) but specifically means a JES MAS (which might be shared by one or more LPARS) or RSCS running under a VM LPAR. As Skip points out, a non-JES product (e.g., VM RSCS) can be designed to to use the JES NJE protocol and establish contact and move jobs and SYSOUT around in the same way, but it would have to carefully adhere to all the security conventions that are part of the NJE protocol as well. I think I would trust IBM to do this right, but less so for a 3rd-party vendor or some local product. If the object is to transfer JES MAS SPOOL content to/from a non-JES product running on one of the LPARS in the same MAS, I guess you could in theory design an interface into the product that would look just like a JES NJE node and add appropriate JES PARMLIB definitions and console commands to establish an NJE connection; but I would think it would be much simpler, safer, and more efficient to just use the standard JES API interfaces and make functional requests directly to the local JES subsystem, rather than try to use NJE protocol to ship requests and data over some communication link to JES. I would also be inclined to suspect that since NJE protocol is not really intended for direct application use in this way, that getting accurate and stable details of how to roll your own NJE node could be a non-trivial exercise. Joel C. Ewing On 03/21/2014 11:21 AM, Skip Robinson wrote: NJE is more precisely a means to connect two or more network nodes, any of which might be for example (z)VM RSCS as well as JES2 or JES3. Any task that follows NJE protocol can play in the game. 'NJE with oneself' has no meaning. All JES2 systems in a single MAS communicate with each other simply by putting 'something' into the common spool. For example, a job submitted for execution can in principle be executed on any member, and sysout from that job can be processed by any member. If one member needs to communicate with another member via SNA or via TCP/IP, then that communication must be set up outside of JES. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jake anderson justmainfra...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/21/2014 09:03 AM Subject:Re: NJE Clarifications Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi, I was just trying to understand this feature for our POC. NJE is for JES to JES commnunication. Can this be possible in a MAS environment(Where two LPARS have same Node) and communicate to a product running in either of 1 LPAR. On Fri, Mar 21, 2014 at 9:00 PM, R.S. r.skoru...@bremultibank.com.plwrote: W dniu 2014-03-21 16:18, Jake anderson pisze: Hi, For an NJE to work we must have to two different nodes. Is there a way for NJE to work within a single Node(Monoplex) just to communicate to another product(As a socket-Running in same Node) ? Is there a case study for the NJE to work on a Monoplex environment ? I tried looking at the share site or JES2 tunning guide But I do not see anything about NJE on Monoplex. IMHO no. NJE is for JES to JES commnunication. You can have secondary JES subsystem, but this is unpopular solution and in this case maybe the JES instances can communicate vie NJE. However it's still JES to JES, not internal within-JES communication. Monoplex environment can use NJE to communicate to other JES nodes (monoplex of sysplex - as you need). BTW: what's your goal? What do you need to do? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
At 12:19 -0400 on 03/21/2014, Tony Harminc wrote about Re: NJE Clarifications: For many years (decades, actually) there have been other products (IBM and non-IBM) that talk the NJE protocols. Most notably, IBM's RSCS on VM uses an overlapping subset of the same protocol, and is interoperable. POWER (DOS/VSE's JES equivalent) supports NJE. I used to have a Network with Power/NJE nodes. The flow was mostly from the JES System to the POWER system for SYSOUT but there some JOB Submission from the DOS System to the JES Spool to run. This was harder due to the difference in JCL but SYSOUT was able to flow in both directions (IOW: Jobs run under DOS were able have their printouts sent to JES for printing). Also VS1 had NJE capabilities. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
