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

Chapter 3. Base functions 55

3.3.3 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 to 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.

3.4 How the base functions are implemented in a single stack

There are several areas of interest that require your attention and action in order to

implement a TCP/IP stack successfully.

3.4.1 z/OS tasks for UNIX Systems Services

In Chapter 1, “Introduction” on page 1, we reviewed the UNIX concepts in the z/OS

environment. We made specific references to the BPXPRMxx member in SYS1.PARMLIB.

We now need to identify the parameters in BPXPRMxx that warrant our attention and action.

However, first we need to discuss important security considerations for the UNIX

environment.

RACF actions for UNIX

Security is an important consideration for most z/OS installations and there are a few features

we need to mention here for the base functions of any TCP/IP environment. TCP/IP has

some built-in internal security mechanisms and relies on the services of a security manager,

such as the IBM Resource Access Control Facility (RACF).

A security manager is a requirement in the z/OS Communications Server IP environment. As

an online application, it is important that TCP/IP undergo security checks to eliminate

possible security exposures. Some basic security concepts are included in the following

sections, but for a more detailed explanation refer to Communications Server for z/OS V1R2

TCP/IP Implementation Guide Volume 7: Security, SG24-6840.

APF authorization

The TCP/IP system program libraries must be APF authorized. Authorized Program Facility

(APF) means that z/OS built-in security may be bypassed by programs that are executed