Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 1: Base Functions, Connectivity, and Routing

24 Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 1 - Base Functions, Connectivity, and Routing

2.3 The common design scenarios for the Resolver

When thinking about how to implement the Resolver in a z/OS environment, it is important to

understand and review the environment variables and their purpose.

To demonstrate how this is done, we are going to show two basic scenarios:

򐂰 Using the Resolver address space in a single stack environment, where we are going to

design a Resolver address space with specific global settings and a default Resolver

config, and how it applies to a single stack environment.

򐂰 Using the Resolver address space in a multiple stack environment, setting up a Resolver

global statement in a multiple stack environment, allowing applications to use an specific

stack affinity or use all stacks to receive or send connection requests.

Benefits Fast (no name resolution).

Good in some debugging

situations (you know

exactly which IP address

is being used).

Fast (local name

resolution).

IP address changes can

be done without any local

changes. All host names

(in the entire network) can

be resolved. A

hierarchical name space.

Drawbacks Difficult to remember

IP addresses. Very

inconvenient in case an

IP address change

occurs. Just think about

IPv6.

If an IP addressing

change is needed, all the

local hosts files have to be

updated. Only locally

configured host names

can be resolved.

Additional packets

(requests) flow to resolve

host name before

destination can be

reached.

Hard-coded IP

addresses

Local hosts file Domain Name System

(DNS)

Recommendation: Although there are specialized cases where multiple stacks per LPAR

can provide value, we in general recommend implementing only one TCP/IP stack per

LPAR. The reasons for this recommendation are as follows:

򐂰 A TCP/IP stack is capable of exploiting all available resources defined to the LPAR in

which it is running. Therefore, starting multiple stacks will not yield any increase in

throughput.

򐂰 When running multiple TCP/IP stacks, additional system resources, such as memory,

CPU cycles, and storage, are required.

򐂰 Multiple TCP/IP stacks add a significant level of complexity to TCP/IP system

administration tasks.

򐂰 It is not necessary to start multiple stacks to support multiple instances of an application

on a given port number, such as a test HTTP server on port 80 and a production HTTP

server also on port 80. This type of support can instead be implemented using

BIND-specific support where the two HTTP server instances are each associated with

port 80 with their own IP address, via the BIND option on the PORT reservation

statement.

One example where multiple stacks can have value is when an LPAR needs to be

connected to multiple isolated security zones in such a way that there is no network level

connectivity between the security zones. In this case, a TCP/IP stack per security zone can

be used to provide that level of isolation, without any network connectivity between the

stacks.