+

Search Tips   |   Advanced Search

(ZOS) Running multiple TCP/IP stacks

We might want to run multiple TCP/IP stacks on the same system to provide network isolation for one or more of the applications. For instance, you may have multiple Open System Adapter (OSA) features, each one connecting the system to a different network. We can assign a TCP/IP stack to each feature.

When configuring the product on a system with multiple stacks, first establish the product's stack affinity to the desired stack. Establishing stack affinity binds all socket communications to that stack, and allocates the proper host name resolution configuration data sets to the product. These data sets enable host name lookups to have the desired results.

Use the NETWORK DOMAINNAME parameter of SYS1.PARMLIB(BPXPRMxx) to specify the common INET physical file system, C_INET PFS, and then use this file system to set up multiple TCP/IP stacks. This physical file system allows configuration of multiple physical file systems (network sockets) and make them active concurrently.

If we plan to configure the product to use a non-default TCP/IP stack, consult z/OS UNIX System Services Planning, and z/OS Communications Server: IP Configuration Reference, for details.

In the following steps, we will set a number variables. It is important to understand that these variables should be set at the node level.

To configure the product on a system with multiple stacks:


Tasks

  1. Configure the data set for each application server's host name resolution. In the administrative console, clickEnvironment > WebSphere variables > New.

    1. Add the RESOLVER_CONFIG UNIX process variable and specify the data set name in the value field.
    2. Export the RESOLVER_CONFIG variable in client shell scripts.

    • We can also use JCL to specify the name resolution configuration data set. To use JCL, add //SYSTCPD DD DSN=some.tcpip.DATA,DISP=SHR to the server JCL. The RESOLVER_CONFIG variable overrides the SYSTCPD DD statement.

    See z/OS Communications Server: IP Configuration Reference, for more information on the RESOLVER_CONFIG variable.

  2. Establish the Application Server's stack affinity to the desired stack.

    1. In the administrative console, click Environment > WebSphere variables and set the _BPXK_SETIBMOPT_TRANSPORT UNIX process variable to the value of the desired transport. If this variable does not exist, click New and add it.
    2. Export the _BPXK_SETIBMOPT_TRANSPORT variable in client shell scripts.

    To set the BPXK_SETIBMOPT_TRANSPORT variable in the was.env file for the Daemon, we must prefix the variable with DAEMON_. This additional information causes the transformer that generates the was.env files to put add the variable to the was.env file for the Daemon. Because the _BPXK_SETIBMOPT_TRANSPORT variable already has a leading underscore, the final version of this variable, when set for the Daemon, contains two underscores preceding the variable name, as shown here DAEMON__BPXK_SETIBMOPT_TRANSPORT.

    If we are setting this variable for the Daemon, you probably want to set it at the cell level to give all the Daemons in that cell the same setting. Unless one of the Daemons is serving multiple nodes, if for some reason we need to specify different settings for different Daemons in a cell,, we can set this variable at the node level.

    See z/OS UNIX System Services Planning, for more information on the _BPXK_SETIBMOPT_TRANSPORT variable.


Subtopics