Example

Here is a simple two node network and the JES2 initialization statements that are required to communicate between the two nodes using NJE/TCP:
Figure 1. Example of a two node network and the JES2 initialization statements required to communicate between the two nodes using NJE/TCP
Example of a two node network and the JES2 initialization statements that are required to communicate between the two nodes using NJE/TCP

This example defines two nodes, POK and WSC. Each node has similar NJEDEF and NODE definitions, with NODE(1) defined as POK and NODE(2) defined as WSC. Each node then also needs to define a NETSRV device, a local socket defining the IP address and port that NETSRV is to listen on, and a non-local socket defining the IP address and port of each connection to be established with other network nodes. In this case, there is only one of those.

On node POK, a single NETSRV device is defined, pointing to socket POKJ2. SOCKET(POKJ2) specifies the local node number (1) on the NODE= parameter, and takes the default values for IPADDR= and PORT=. Therefore, when NETSRV1 is eventually started, it listens on all IP addresses, and because SECURE=YES is not specified, it uses the port that is associated with VMNET (175). The non-local socket for the connection to node WSC, defined by the SOCKET(WSCJ2) statement, indicates that the connection is associated with node 2 (per the NODE=2 keyword), and specifies an IP address of 9.57.1.33. In this case, the explicit IP address is specified in dotted decimal format. Because PORT= is not specified, the default value (VMNET, or 175) is also used.

On node WSC, a single NETSRV device is defined, pointing to socket WSCJ2. SOCKET(WSCJ2) specifies the local node number (2) on the NODE= parameter, and takes the default values for IPADDR= and PORT=. The non-local socket for the connection to node POK, defined by the SOCKET(POKJ2) statement, indicates that the connection is associated with node 1 (per the NODE=1 keyword), and specifies an IP address of pok.ibm.com. In this case, a symbolic address is specified rather than an explicit address; either can be used. Because PORT= is not specified, the default value (VMNET, or 175) is also used.

To connect the two nodes, processing is very similar to SNA and BSC NJE. You can use the $SLINEnnn command to activate the logical line that is to be used for the connection, and the $SN command to start networking on the connection.

Figure 2. Example of a two node network and the JES2 commands required to start networking
Example of a two node network and the JES2 commands that are required to start networking

First, on each end of the connection, you must start the NETSRV device and logical line with the $SNETSRV1 and $SLNE1 commands, respectively.

Next, when you issue the $SN,SOCKET=WSCJ2 command, this tells NETSRV1 (by default) to initiate a connection between itself and the IP address that is provided on the SOCKET(WSCJ2) statement. Because NETSRV1 on node WSC is listening on this IP address and port, you can establish a connection successfully. You can also establish the connection by issuing $SN,SOCKET=POK from node WSC.

Displaying the attributes of the NETSRVs, lines, and sockets on both sides of the connection results in the following displays:
On Node POK:

16.27.24           $dnsv1                                               
16.27.24           $HASP898 NETSRV1                                     
$HASP898 NETSRV1    STATUS=ACTIVE,ASID=0024,NAME=JES2S001,              
$HASP898            SOCKET=LOCAL,STACK=,TRACEIO=(JES=YES,               
$HASP898            COMMON=YES,VERBOSE=YES)                             
16.27.42           $dsock(pokj2,wscj2)                                 
16.27.42           $HASP897 SOCKET(POKJ2)                               
$HASP897 SOCKET(POKJ2)     STATUS=ACTIVE/NETSRV1,                       
$HASP897                   IPADDR=::9.57.1.235,                    
$HASP897                   PORTNAME=VMNET,SECURE=NO,LINE=0,             
$HASP897                   NODE=1,REST=0,NETSRV=0                       
16.27.42           $HASP897 SOCKET(WSCJ2)                                 
$HASP897 SOCKET(WSCJ2)     STATUS=ACTIVE/LNE1/NETSRV1,              
$HASP897                   IPADDR=9.57.1.161,PORT=175,                  
$HASP897                   PORTNAME=VMNET,SECURE=NO,LINE=0,             
$HASP897                   NODE=2,REST=0,NETSRV=0,SOCKID=S3             

On Node WSC:   

16.27.24           $dnsv1                                               
16.27.24           $HASP898 NETSRV1

Note the following in the previous display:

  • First, even though the local sockets (POKJ2 on node POK and WSCJ2 on node WSC) did not specify an IP address in the initialization deck, a value is now displayed for each, rather than the *LOCAL value that was displayed before the NETSRV device was started. This is the primary IP address associated with the NETSRV device.
  • Second, the PORT= value is now filled in for the remote socket associated with each node. On POK, the value for WSCJ2 is now displayed as PORT=175 (this is the value that is associated with VMNET). On WSC, however, the value for POKJ2 is displayed as PORT =1038, which is not associated with anything specified in the JES2 parameters. The reason for this is that TCP/IP can assign an ephemeral port number to the socket on the receiving node. If the connection drops, the value reverts to the value you specified, in case the connection needs to be re-established.
  • Finally, the STATUS= parameter on the SOCKET display shows the line or NETSRV associated with the SOCKET, or both. For local sockets, only the NETSRV that is listening on that socket is displayed; for remote sockets, both the associated line and associated NETSRV are displayed.
Note: When associating an incoming request with a SOCKET, you can only use the NODE= and SECURE= values to make that association; the IPADDR= and PORT= values are ignored. This is because the inbound IP address might not match what is specified on the SOCKET statement because of the presence of firewalls, NAT translation, and so on. The inbound port might not match as TCP/IP assigns an ephemeral port value to the inbound socket, which in general cannot be predicted. It is also possible that for an inbound connection, neither the IP address nor the port matches the value that would have to be specified if the connection were initiated from this end of the connection. You must specify the correct values, though, to initiate the connection successfully from either end of the connection.