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
> [email protected]
>
>
>
> From: Jake anderson <[email protected]>
> To: [email protected],
> Date: 03/21/2014 09:03 AM
> Subject: Re: NJE Clarifications
> Sent by: IBM Mainframe Discussion List <[email protected]>
>
>
>
> 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.
> <[email protected]>wrote:
>
>> 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 [email protected] with the message: INFO IBM-MAIN
>
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
