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: 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
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
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
