Converting Networking Protocols

It is possible to convert nodes from one networking protocol to the other. In other words, nodes that are currently using BSC protocol can be converted to SNA and conversely. The following scenario describes converting an existing BSC node to SNA. Converting back to BSC can be accomplished by reversing the procedure.

It is possible to convert nodes from one networking protocol to the other. In other words, nodes that are currently using BSC, SNA, or TCP/IP protocol can be converted to one of the others. The following scenarios describe converting an existing BSC node to SNA and converting an existing SNA node to TCP/IP. Converting back to the original protocol can be accomplished by reversing the procedure.

Before converting to SNA, you must install:
  • MVS/BDT Version 2
  • ACF/VTAM Version 1 with the Multisystem Networking Feature, ACF/VTAM Version 2 Release 1, or ACF/VTAM Version 3 Release 1
  • TSO/E Release 2 (if networking jobs are to be submitted through TSO)

Because SNA protocol uses MVS/BDT to transfer data between nodes, ensure that node names are defined the same to MVS/BDT in the MVS/BDT initialization stream and to JES3. You can define node names to JES3 using operator commands or in the JES3 initialization stream. To define a node to MVS/BDT, use the MVS/BDT SYSID and BDTNODE statements. For detailed information on defining MVS/BDT initialization statements, see MVS/Bulk Data Transfer Facility: Initialization and Network Definition.

You can code the NJERMT initialization statement to define networking nodes to JES3 during initialization. See Table 1 to determine which parameters you must code on the NJERMT initialization statement. If you have more than one MVS/BDT facility in your JES3 complex, you should also include a JES3 SYSID initialization statement to define the default MVS/BDT facility. You can also define networking nodes dynamically using the JES3 *MODIFY,NJE command. z/OS JES3 Commands describes how to use the *MODIFY,NJE command.

When the nodes are defined in their initialization streams, you can warm start or hot start with refresh JES3 and warm start MVS/BDT. The operator can then migrate any jobs that remain waiting for a BSC line by using the NJEROUT DSP. Jobs are transmitted when the MVS/BDT session is activated. See MVS/Bulk Data Transfer Facility: Operator's Guide for descriptions of operator commands to control MVS/BDT sessions.

When the SNA job entry network is stable, you can remove the physical BSC links from the complex.

Before converting to TCP/IP, you must do the following steps:
  1. Define a network server (Netserv) using the NETSERV statement.
  2. Define profiles for the Netserv in the STARTED security class. See Making security definitions for a TCP/IP/NJE Netserv. You also need to adjust the service class that is assigned to the address space. The address space uses separate subtasks for each connection. If the address space is supporting many connections, it can use as much CPU resource as the system allows it to transmit and receive data. If its priority is too high, it can lock out other work in the system.
  3. Define a socket describing the IP address or host name of the remote node, and a port.
  4. Define any IP addresses and host names that nodes use to TCP/IP.
  5. Warm start or hot start with refresh JES3 when the nodes are defined in their initialization streams. You can dynamically add nodes; restarting JES3 is necessary only to make the additions permanent.

Before you can establish any Internet Protocol network connections, z/OS® Communications Server TCP/IP must be active, which in turn requires z/OS UNIX System Services and ACF/VTAM to be active. A TCP DSP can be started by issuing *CALL,TCP. This can start a Netserv address space. If the TCP DSP is started by issuing *CALL,TCP before TCP/IP is active, the Netserv address space waits until TCP/IP is active. If the remote node is JES2 or JES3, you must start the appropriate Netserv there also. The sockets can then be activated from either side.

The operator can migrate any jobs that remain waiting for a BSC line or for BDT to despool the output by using the NJEROUT DSP.

Jobs are transmitted when the socket is activated.

When the TCP/IP job entry network is stable, you can remove the physical BSC links or BDT definitions from the complex.