TCP/IP API Support › Miscellaneous TCP/IP Considerations › Using Multiple TCP/IP Stacks

Using Multiple TCP/IP Stacks

In a multiple TCP/IP stack environment, a CA IDMS system is able to use several available TCP/IP stacks concurrently. Only z/OS and z/VM support multiple TCP/IP stacks.

In the z/OS environment, the Common INET (CINET) configuration is required to run multiple TCP/IP stacks concurrently. CA IDMS uses special system calls to get a list of the available TCP/IP stacks in the system. For more information about the CINET feature, see the IBM's z/OS Communication Server IP Configuration Guide.

For z/VM, multiple TCP/IP stacks are implemented by starting each stack in its own virtual machine.

Limit the TCP/IP stacks available in a CA IDMS system

In a multiple TCP/IP stack environment, you can control or limit the stacks that are usable by the socket applications running in the CA IDMS system. This enhancement is primarily for CA IDMS systems running on z/OS with CINET active and on z/VM. It is useful in an environment where certain applications need to use secured sockets or some TCP/IP stacks are for testing only.

You can control or limit the TCP/IP stacks using the following methods:

• At startup, through the INCLUDE STACK or EXCLUDE STACK clause from the TCP/IP system generation statement
• At startup, through the INCLUDE_TCP/IP_STACK or EXCLUDE_TCP/IP_STACK SYSIDMS parameters
• Dynamically, through the DCMT VARY TCP/IP command

Note: On z/VM, the definition of the TCP/IP stacks to use through the SYSTCPD file and the 8 SYSIDMS parameters (TCP/IP_STACK_1 -> TCP/IP_STACK_8) as used in r16 is still available and is kept for compatibility reasons.

More Information:

• For more information about the TCP/IP system generation statement, see the CA IDMS System Generation Guide.
• For more information about the SYSIDMS parameters, see the CA IDMS Common Facilities Guide.
• For more information about the DCMT VARY TCP/IP command, see the CA IDMS System Tasks and Operator Commands Guide.
• For more information about the SYSTCPD file, see the CA IDMS System Operations Guide.

Default TCP/IP stack

In a multiple stacks environment, the assignment of the default stack also depends on the operating system where the CA IDMS system is running as follows:

• On z/OS, the system always assigns a specific stack as the default stack. If TCP/IP stacks are excluded from the system list, either using SYSGEN or using SYSIDMS parameters, then the default stack for the socket environment will be assigned to the following:
  • the default stack from the system, if it has not been explicitly excluded.
  • the first active stack from the resulting list, if the default stack from the system has been excluded
• On z/VM, the default stack will always be the first stack from the resulting list of stacks.

There is a possibility to overwrite this default stack assignment in the system:

• At startup, through the DEFAULT STACK clause from the TCP/IP system generation statement
• Dynamically, through the DCMT VARY TCP/IP command.

Current TCP/IP stack for a DC task

When a DC task is started, the current TCP/IP stack for the DC task is the default TCP/IP stack from the CA IDMS system. The SETSTACK function can be used to assign another value to the current TCP/IP stack or to restore the default value for the DC task.

Stack affinity

This concept refers to sockets. When a socket is created and it is exclusively attached to a specific TCP/IP stack, it is said to have "stack affinity." The stack affinity is equal to the value of the current TCP/IP stack when the socket was created. A socket that is not attached to a specific TCP/IP stack has no stack affinity.

Default stack affinity

When a socket is created in the default DC task environment, that is, no specific SETSTACK calls have been issued in the task yet, the default stack affinity is the default TCP/IP stack.

When a socket has set stack affinity to *ALL and the application issues an ACCEPT socket call with the IP address equal to INADDR_ANY in the corresponding socket address structure, then the ACCEPT request is propagated to all available TCP/IP stacks, and therefore the application can accept connections from clients specifying an IP address from any of the available TCP/IP stacks. This configuration is possible on z/OS only. If the accepting socket is assigned a specific stack affinity, the client must specify the IP address corresponding to that specific stack.

If a socket application is accepting connections from all the TCP/IP stacks available in the system, that is its current stack affinity is set to *ALL, and if some of the TCP/IP stacks have been excluded by the user, then the current processing for the #SOCKET ACCEPT socket function will reject all connections that were explicitly addressed to one of the excluded stacks. This processing is done internally. The user applications do not require any changes. The output of the DCMT DISPLAY TCP/IP STATISTICS shows the number of accepted connections that have been rejected for that reason.

Two socket functions return values that are influenced by which TCP/IP stack is current on the DC task.

• GETHOSTID—Returns the IP address of the current TCP/IP stack.
• GETHOSTNAME—Returns the hostname of the current TCP/IP stack.

The output from the DCMT DISPLAY TCP/IP STACK TABLE command shows the available TCP/IP stacks with their associated IP address and hostname.

More Information:

For more information about DCMT DISPLAY TCP/IP, see the CA IDMS System Tasks and Operator Commands Guide.