z/OS V1R12 Communications Server: IP Configuration Guide

Troubleshooting

Problem

Publication updates for the z/OS V1R12 Communications Server: IP Configuration Guide

Resolving The Problem

=========================================================
In Chapter 2, "IP configuration overview", under "Performance considerations", after the bulleted list, change the remainder of the section to the following:

On systems with significant FTP activity, you can improve performance by placing the FTP program objects into the dynamic link pack area (LPA). Putting the FTP program objects into the dynamic LPA eliminates the need to load these program objects from DASD for each FTP session. You can place these program objects into the dynamic LPA using either of the following methods:

Include the following statement in the PROGxx member of SYS1.PARMLIB and then issue a SET PROG=xx command:

LPA,ADD,MODNAME(EZAFTPLS,FTPDNS,EZAFTPLC,FTP),DSNAME(LNKLST)

Issue the following SETPROG command:

SETPROG LPA,ADD,MODNAME(EZAFTPLS,FTPDNS,EZAFTPLC,FTP),DSNAME(LNKLST)

Tip: You can also place the SET PROG=xx command or the SETPROG command in a COMMNDxx SYS1.PARMLIB member to have the command issued at IPL time.

Requirement: If maintenance is applied to these program objects, you must update the program objects in storage using one of the following methods:

Issue an LLA refresh command, and then issue a SET PROG=xx command that points to a PROGxx member that contains the following command:

LPA,ADD,MODNAME(EZAFTPLS,FTPDNS,EZAFTPLC,FTP),DSNAME(LNKLST)

Issue an LLA refresh command, and then issue the following SETPROG command:

SETPROG LPA,ADD,MODNAME(EZAFTPLS,FTPDNS,EZAFTPLC,FTP),DSNAME(LNKLST)

For more information, see z/OS MVS System Commands.

=========================================================
In Chapter 2, "IP configuration overview", under "Considerations for networking hardware attachment", under "QDIO inbound workload queueing", add the following restriction to the list of restrictions:

Restriction: QDIO IWQ does not apply for traffic that is sent over an OSA port that is shared by the receiving TCP/IP stack when an indirect route (where the next hop and destination IP address are different) is used; OSA places such traffic on the primary input queue. QDIO IWQ does apply when traffic on the shared OSA path uses a direct route (where the next hop and destination IP address are the same).

=========================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Offloading log files", after the first paragraph, add the following guideline:

Guideline: You should use this method of offloading or archiving files only if you do not use the automatic archive function of syslogd that is described in Configuring syslogd for automatic archiving. Because both of these methods rely on creating new log files, results are unpredictable if you try to use both methods together.

=========================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Configuring syslogd for automatic archiving", after the first paragraph, add the following guideline:

Guideline: You should use this method of archiving files only if you do not offload files using the provided sample configuration and procedure that are described in Offloading log files. Because both of these methods rely on creating new log files, results are unpredictable if you try to use both methods together.

=========================================================
In Chapter 16, "Policy-based networking", under "FLUSH and PURGE considerations", after the results list, change the next paragraph and Table 45 to the following:

Table 45 shows the results of using the FLUSH and PURGE parameters.

Event	IPSec policies	Routing policies	Other policies
Policy Agent start (FLUSH defined)	All policies are replaced in the TCP/IP stack.	All policies are deleted and reloaded into the TCP/IP stack.	All policies are deleted and reloaded into the TCP/IP stack.
Policy Agent start (NOFLUSH defined)	All policies are replaced in the TCP/IP stack.	All policies are deleted and reloaded into the TCP/IP stack.	All changed policies are updated in the TCP/IP stack. Deleted policies are not removed from the TCP/IP stack.
Policy Agent termination (PURGE defined)	TCP/IP stack policies are unchanged.	TCP/IP stack policies are unchanged.	All policies are removed from the TCP/IP stack.
Policy Agent termination (NOPURGE defined)	TCP/IP stack policies are unchanged.	TCP/IP stack policies are unchanged.	TCP/IP stack policies are unchanged. Deleted policies are not removed from the TCP/IP stack.
Policy Agent update (FLUSH defined)	If there are any changed or deleted policies, then all policies are replaced in the TCP/IP stack.	Any changed policies are replaced in the TCP/IP stack, and then all deleted policies are removed from the TCP/IP stack.	Any changed policies are replaced in the TCP/IP stack, and then all deleted policies are removed from the TCP/IP stack.
Policy Agent update (NOFLUSH defined)	If there are any changed or deleted policies, then all policies are replaced in the TCP/IP stack.	Any changed policies are replaced in the TCP/IP stack, and then all deleted policies are removed from the TCP/IP stack.	Any changed policies are replaced in the TCP/IP stack. Deleted policies are not removed from the TCP/IP stack.
Policy Agent refresh (FLUSH defined)	If there are any changed or deleted policies, then all policies are replaced in the TCP/IP stack.	If there are any changed or deleted policies, then all policies are deleted and reloaded into the TCP/IP stack.	If there are any changed or deleted policies, then all policies are deleted and reloaded into the TCP/IP stack.
Policy Agent refresh (NOFLUSH defined)	If there are any changed or deleted policies, then all policies are replaced in the TCP/IP stack.	If there are any changed or deleted policies, then all policies are deleted and reloaded into the TCP/IP stack.	Any changed policies are replaced in the TCP/IP stack. Deleted policies are not removed from the TCP/IP stack.

Rules:

The TCP/IP stack results do not apply for policy client or import requestor policies configured on the policy server.
The PURGE and NOPURGE parameters have no effect on policy client or import requestor policies configured on the policy server.

=========================================================
In Chapter 19, "IP security", under "Overview of using IP security", under "FIPS 140 and IP security", in the fourth paragraph that includes the initial bulleted list, two bullets have been deleted, and the paragraph now contains only the following:

In FIPS 140 mode, the IKED, the NSSD, and the TCP/IP stacks enforce the following restrictions on the cryptographic algorithms that can be used for IP security:

You cannot use the DES encryption algorithm.
You cannot use the HMAC-MD5, HMAC-MD5-96, AES128-XCBC, and AES128-XCBC-96 algorithms for authentication or pseudo-random function.
You cannot use Diffie-Hellman groups 1, 2, and 5.
You cannot use certificates for RSA signature authentication that have key lengths less than 1024 bits.
You cannot use pre-shared keys whose length is less than half the key size of the chosen HowToAuthMsgs (IKEv1) or PseudoRandomFunction (IKEv2) algorithm

=========================================================
In Chapter 19, "IP security", under "Overview of using IP security", under "FIPS 140 and IP security", in the sixth paragraph that includes the second bulleted list, delete the first bullet.

=========================================================
In Chapter 19, "IP security", under "Overview of using IP security", under "FIPS 140 and IP security", under "Steps for configuring IP security to support FIPS 140 mode", under step 2, delete the last sentence of the tip, resulting in the following:

Tip: A single z/OS system can support multiple TCP/IP stacks, and you can configure some TCP/IP stacks with FIPS 140 support and others without FIPS 140 support. The stacks that are configured in FIPS 140 mode must not have access to the SAF resource FIPSEXEMPT.SYSTOK-SESSION-ONLY in the CRYPTOZ class.

=========================================================
In the BookManager BOO file, in section "2.10.12.8.1 IP filter policy", under "Example 2", the initial paragraph and code sample might not be displayed properly when viewing from your browser and should appear as follows:

Example 2: Deny rule that blocks all traffic from all private address spaces that is inbound to a public interface:

IpFilterRule deny-private
{
IpSourceAddrGroupRef PrivateAddrs
IpDestAddr all
IpService
{
SourcePortRange 0
DestinationPortRange 0
Protocol all
Direction inbound
Routing either
SecurityClass 0
}
IpGenericFilterActionRef deny-log
}

=========================================================
In the BookManager BOO file, in section "2.10.12.8.1 IP filter policy", under "Example 3", the initial paragraph and code sample might not be displayed properly when viewing from your browser and should appear as follows:

Example 3: An ipsec rule that requires IPSec protection for all traffic between the secure server and an administrative machine on the internal network:

IpFilterRule Rule2Admin
{
IpSourceAddrRef InternalServerAddressA1
IpDestAddrRef AdminClient
IpServiceRef All-traffic-local
IpGenericFilterActionRef ipsec
IpDynVpnActionRef Silver-TransportMode
}

=========================================================
In Chapter 2, "IP configuration overview', under "Considerations for networking hardware attachment", under "TCP segmentation offload" at the end of the section, add the following requirement:
Requirement: To determine the OSA microcode level required to use TCP segmentation offload support, see the Preventive Service Planning (PSP) bucket for the appropriate device.

=========================================================
In Chapter 8, "TCP/IP in a sysplex", under "Steps for configuring scenario 1 - sysplex distributor load balancing to DataPower", under "Configure sysplex distributor tier 1 distributed DVIPAs and ports", change the example to the following:
VIPADEFINE TIER1 255.255.255.0 10.91.1.1
VIPADISTRIBUTE DEFINE
GRE DISTM TARGCONTROLLED
TIER1 GROUP1
CONTROLPORT 5601
10.91.1.1 Port 8080
DESTIP 201.81.10.1 201.81.10.2
201.81.10.3 201.81.10.4

=========================================================
In Chapter 8, "TCP/IP in a sysplex", under "Steps for configuring scenario 1 - sysplex distributor load balancing to DataPower", under "Configure a distributed DVIPA for the target z/OS application servers used by the group of DataPower appliances (optional)", change the example to the following:
VIPADEFINE 10.81.1.1
VIPADISTRIBUTE DEFINE
DISTMETHOD SERVERWLM
10.81.1.1 Port 9001
DESTIP ALL

=========================================================
In Chapter 8, "TCP/IP in a sysplex", under "Steps for configuring scenario 2 - sysplex distributor load balancing to DataPower in a multi-tier and multisite environment", under "Configure sysplex distributor tier 1 distributed DVIPAs and ports", change the example to the following:
VIPADEFINE TIER1 255.255.255.0 10.91.1.1
VIPADISTRIBUTE DEFINE
GRE DISTM TARGCONTROLLED
TIER1 GROUP1
CONTROLPORT 5601
10.91.1.1 Port 8080
DESTIP 201.81.10.1 201.81.10.2
201.81.20.1 201.81.20.2

=========================================================
In Chapter 8, "TCP/IP in a sysplex", under "Steps for configuring scenario 2 - sysplex distributor load balancing to DataPower in a multi-tier and multisite environment", under "Configure tier 2 distributed DVIPAs for each CPC containing target servers used by a group of DataPower appliances", change the first example to the following:
VIPADEFINE TIER2 CPCSCOPE 255.255.255.0 10.81.2.2
VIPADISTRIBUTE DEFINE
DISTMETHOD SERVERWLM
TIER2 GROUP1
10.81.2.2 Port 9001
DESTIP ALL

=========================================================
In Chapter 8, "TCP/IP in a sysplex", under "Steps for configuring scenario 2 - sysplex distributor load balancing to DataPower in a multi-tier and multisite environment", under "Configure tier 2 distributed DVIPAs for each CPC containing target servers used by a group of DataPower appliances", change the second example to the following:
VIPADEFINE TIER2 CPCSCOPE 255.255.255.0 10.81.1.1
VIPADISTRIBUTE DEFINE
DISTMETHOD SERVERWLM
TIER2 GROUP1
10.81.1.1 Port 9001
DESTIP ALL

=========================================================
In Chapter 11, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Telnet configuration data set customization details", under "Connection persistence", under "SCANINTERVAL and TIMEMARK", change the fourth sentence to the following:
If the SCANINTERVAL value is greater than the TIMEMARK value, the SCANINTERVAL value is reset to the TIMEMARK value.

=========================================================
In Chapter 12, "Transferring files using FTP", under "Configuring the optional FTP user exits", under "The FTCHKCMD user exit", change the first sentence to the following:
The FTCHKCMD user exit is called whenever the server receives an FTP command.

=========================================================
In Chapter 12, "Transferring files using FTP", under "Configuring the optional FTP user exits", under "The FTCHKCMD user exit", change the second bullet to the following:

The FTP command to be processed

=========================================================
In Chapter 12, "Transferring files using FTP", under "Configuring the optional FTP user exits", under "The FTCHKCMD user exit", change the first two sentences of the last paragraph to the following:
The user exit enables an installation to modify the arguments of an FTP command or to deny a user from issuing the command. For example, if the server receives a LIST * command, the exit can either deny the command or modify it to LIST 'USER1.*'.

=========================================================
In Chapter 12, "Transferring files using FTP", under "Install the SQL query function (optional) and access the DB2 modules", change the introductory paragraphs before the sample job to the following:
To use FTP to perform SQL queries, bind a plan that allows FTP to invoke the package EZAFTPMQ in collection EZAFTPMQ, and grant execution privileges for that plan to PUBLIC. You can specify the name of the plan using the DB2PLAN keyword in FTP.DATA, or the default is EZAFTPMQ. This FTP facility performs only SELECT operations on the DB2 tables; it does not perform UPDATE, INSERT, or DELETE operations.

Requirement: If secondary authorization for SQL queries is required, you must modify the DSN3SATH sample exit shipped by DB2. The exit returns the primary AUTHID for requests that originate from the FTP server.

The following sample job is provided in the FTOEBIND member of the SEZAINST data set; you can use it to enable the FTP server and client to perform SQL queries.

=========================================================
In Chapter 16, "Policy-based networking", under "Steps for configuring the Policy Agent", under "Step 1: Configure general information", change the introductory sentence for step 4 to the following:
4. Define the log file destination and the appropriate logging level.

You can specify that Policy Agent log messages should be written to the syslog daemon or to a z/OS UNIX file. To indicate the syslog daemon, specify SYSLOGD in uppercase. To indicate a z/OS UNIX file, specify the file name. Specify the log file destination using the -l start option or the PAGENT_LOG_FILE environment variable, or you can use the default value /tmp/pagent.log.

Tip: Specify SYSLOGD to take advantage of a centralized logging mechanism.

Result: If Policy Agent cannot read the start options, then it does not have a log file destination. Policy Agent might fail to open a z/OS UNIX log file. In these situations, Policy Agent logs error messages to the syslog daemon and exits abnormally.

=========================================================
In Chapter 16, "Policy-based networking", under "Starting and stopping the Policy Agent", under "Other considerations when starting the Policy Agent", delete the first sentence.

=========================================================
In Chapter 28, "Mail on z/OS", under "Configuring the CSSMTP application", under "Setting up CSSMTP", under "Steps for configuring and starting CSSMTP", add the following at the end of step 1:
Because the CSSMTP JCL sample contains a JOB card, you should define the procedure library that you use in the IEFJOBS or IEFPDSI concatenation of the master JCL, or put the new data set member in a subsystem procedure library such as SYS1.PROCLIB.

=========================================================
In Chapter 2, "IP configuration overview", under "Understanding search orders of configuration information", under "Configuration data set naming conventions", under "Dynamic data set allocation", under "High-level qualifier", under the hlq bullet, change the last sentence to the following sentence:

Note that the DATASETPREFIX value is not used as the high-level qualifier of the data set name used as the last step in the search order for the TCPIP.DATA configuration file.

=========================================================
In Chapter 2, "IP configuration overview", under "Understanding search orders of configuration information", under "Configuration data set naming conventions", under "TCP/IP configuration data sets", change the search order for PROFILE.TCPIP to the following search order:

The MVS data set that is specified on the PROFILE DD statement in the TCP/IP stack started procedure.
jobname.nodename.TCPIP
TCPIP.nodename.TCPIP
jobname.PROFILE.TCPIP
TCPIP.PROFILE.TCPIP

//PROFILE DD DSN=aaa.bbb.ccc(anyname)
jobname.nodename.TCPIP
TCPIP.nodename.TCPIP
jobname.PROFILE.TCPIP
TCPIP.PROFILE.TCPIP

=========================================================
In Chapter 2, "IP configuration overview", under "Configuration files for the TCP/IP stack", under "PROFILE.TCPIP search order", under "Examples", after the examples, change step 3 of the search order to the following step:

3. TCPIP.nodename.TCPIP

If TCPIP.nodename.TCPIP is found, the search stops here.
=========================================================
In Chapter 2, "IP configuration overview", under "MVS-related considerations", under "Automatic restart manager", change the second paragraph to the following:

During initialization, TCP/IP automatically registers with the automatic restart manager by using the following options:

REQUEST=REGISTER
ELEMNAME=EZAsysclonetcpname
ELEMTYPE=SYSTCPIP
TERMTYPE=ELEMTERM

where:

sysclone is a 1– or 2–character shorthand notation for the name of the MVS system. For a complete description of the SYSCLONE static system symbol, see z/OS MVS Initialization and Tuning Reference.
tcpname is a 1– to 8–character name of the TCP/IP stack that registers with the automatic restart manager. For example, if the SYSCLONE value is 02 and the TCP/IP stack name is TCPCS, the resulting ELEMENT value is EZA02TCPCS.

Rule: The TCP/IP stack supports automatic restart only on the same system. Do not explicitly specify TERMTYPE(ALLTERM) in the automatic restart management policy for TCP/IP. A policy that uses the default value ALLTERM is overridden by the TCP/IP stack registration value ELEMTERM.

=========================================================
In Chapter 2, "IP configuration overview", under "Performance considerations", replace the second bullet with the following bullet:

For server applications such as OMPROUTE, TN3270E Telnet server, IKED, NSSD, and FTPD, set the priority value to the same value to which TCP/IP is set, or to a priority that is just below that value. If you are using WLM, assign these tasks to the SYSSTC service class. Additionally, you can make these tasks non-swappable so they are available during periods of high CPU usage. The MVS default program property table sets Telnet to be non-swappable and privileged, which automatically assigns the task to the SYSSTC service class.

=========================================================
In Chapter 2, "IP configuration overview", under "Considerations for networking hardware attachment", under "Steps for converting from IPv4 IPAQENET DEVICE, LINK, and HOME definitions to the IPv4 IPAQENET INTERFACE statement", in step 3, change the lead-in sentence to the following:

3. If you have configured the SOURCEVIPA parameter on the IPCONFIG statement, perform the following steps:

=========================================================
In Chapter 2, "IP configuration overview", under "Considerations for networking hardware attachment", under "QDIO inbound workload queueing", after the list of restrictions, add the following guideline:

Guideline: Display the VTAM TRLE name that is associated with the interface to determine the amount of CSM storage that is being used. Additional CSM 4K DSPACE64 storage is used when implementing the QDIO inbound workload queue.

=========================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "OSM access control", change the second paragraph to the following:

The intranode management network can be accessed only through OSM interfaces. To use IOCTL calls to retrieve information about an OSM interface or to send or receive data over OSM interfaces on this network, an application must have READ authorization to the EZB.OSM.sysname.tcpname resource. If you start one of these authorized applications on a z/OS image, authorize the application user ID to this SAF resource. In addition, authorize to this resource any user IDs that might issue diagnostic commands, such as Ping and Traceroute, over OSM interfaces to verify connectivity. Traffic over OSM interfaces is exempt from network access control.

=========================================================
In Chapter 6, "Routing", "OMPROUTE configuration", under "Steps for configuring OMPROUTE", under step 1 to create the OMPROUTE configuration file, change step a of the search order to the following step:

a. The MVS data set or z/OS UNIX file specified on the OMPCFG DD statement in the OMPROUTE started procedure.

=========================================================
In Chapter 8, "TCP/IP in a sysplex", under "Connectivity in a sysplex", under "Network interfaces monitoring", add the following bullet to the list of scenarios where the monitoring function can create problems:

Preferred routing interface is not monitored

If you use multiple interfaces and at least one interface is preferred from a routing perspective over the other interfaces, ensure that the preferred interfaces are monitored (the MONSYSPLEX keyword is specified for the LINK or INTERFACE statement). If the preferred interfaces are not monitored, an inadvertent recovery action might be initiated.
=========================================================
In Chapter 9, "TCP/IP in an ensemble", under "Steps for using the intranode management network (CHPID type OSM)", change step 1 to the following step:

Authorize the application to the EZB.OSM.sysname.tcpname resource. To use IOCTL calls to retrieve information about an OSM interface or to send or receive data over an OSM interface, an application must have READ authorization to the EZB.OSM.sysname.tcpname resource. If used on this image, authorize the application to this resource.

=========================================================
In Chapter 11, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Telnet diagnostic tools", under "TESTMODE", change the paragraph to the following paragraph:

You can use the TESTMODE parameter statement in a TELNETPARMS block to allow a port to be processed by Telnet but then dropped before the statements for that port become active. Using TESTMODE ensures that LU assignments, security levels, and other Telnet parameters are not compromised due to syntax errors.

=========================================================
In Chapter 11, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Telnet configuration data set customization details", under "Advanced application topics", under "Check client connection and connection/session takeover", change the first sentence of the sixteenth paragraph (the paragraph that is two paragraphs before the order for connection security) to the following:

Part of session initiation includes Telnet issuing a SETLOGON VTAM macro that contains control vectors, including control vector 64 described in “Connection information passed on the CINIT control vector 64” under Advanced application topics.

=========================================================
In Chapter 19, "IP security", under "Special considerations when using IP security for IPv6", under "IPv6-specific protocols", change the paragraph to the following information:

The protocol number for ICMPv6 (58) is different from the protocol number for IPv4 ICMP (1); remember this when configuring IPv6 filter rules.

The handling of fragments in IPv6 is different from IPv4. For information about fragmented IPv6 packets, see Routed traffic and fragmented packets.

=========================================================
In Chapter 19, "IP security", under "Data encryption and authentication — IPSec", under "Dynamic key management - IKE and IPSec negotiations", under "Phase 1", under "Peer authentication", under "Identity information", change the paragraph before the bulleted list to the following text:

Identity information: Multiple identities can be assigned down to the level of individual IP addresses for each IKE negotiation, or for ease of configuration, a single identity can be assigned to represent the IKE daemon for the TCP/IP stack. With either method, the identity that is assigned must be an identity that is known to the remote IKE peer. Similarly, the local server must know the identity of any remote IKE peer with which it is to negotiate.

Guideline: Do not use the same identity on more than one TCP/IP stack or z/OS system image. IKED assumes that an identity is not used by any other stack, and this assumption can lead to a disruption of IPSec service for other stacks when identities are shared between stacks.

The identity can be one of the following types:

=========================================================
In Chapter 22, "Application Transparent Transport Layer Security data protection", under "Getting started with AT-TLS", under "Configuring the client systems", in the table "AT-TLS configuration for the client system", for the "Create key ring" task, add the following additional tip:

Tip: Because a copy of the specified key ring contents is loaded into TCP/IP private storage for each user, keep a minimal number of certificates connected to the key ring.

=========================================================
In Chapter 22, "Application Transparent Transport Layer Security data protection", under "Getting started with AT-TLS", under "Steps for starting AT-TLS and verifying its operation", add the following new step 3 before the existing step 3 (with the existing step 3 becoming step 4, the existing step 4 becoming step 5, and so forth):

3. If System SSL needs to access Integrated Cryptographic Services Facility (ICSF), start ICSF. For information about using cryptographic features with System SSL, see z/OS Cryptographic Services System SSL Programming.

=========================================================
In Chapter 28, "Mail on z/OS", under "Configuring the CSSMTP application", under "Security for CSSMTP", in the list of additional security measures for CSSMTP, in the second bullet, replace the ADDUSER statement and the first RDEFINE statement in the example JESSPOOL definition with the following statements:

ADDUSER CSSMTP DFLTGRP(OMVSGRP) OMVS(UID(nn) HOME('/')) -
NOPASSWORD NAME('Simple Mail Transfer') OWNER(OMVSGRP)
RDEFINE STARTED OWNER(SYS1) CSSMTP.* STDATA(USER(CSSMTP))

=========================================================
In Chapter 28, "Mail on z/OS", under "Configuring the CSSMTP application", under "Security for CSSMTP", in the list of additional security measures for CSSMTP, in the fourth bullet, in the list of tips, change the first tip to the following tip:

SETR GENERIC(SERVAUTH) GENCMDS(SERVAUTH)
SETR CLASSACT(SERVAUTH)
RDEFINE SERVAUTH EZB.CSSMTP.sysname.writername.originJESnode -
UACC(NONE)
PERMIT EZB.CSSMTP.sysname.writername.originJESnode -
CLASS(SERVAUTH) ID(userid) ACCESS(READ)

PERMIT EZB.CSSMTP.sysname.writername.* -
CLASS(SERVAUTH) ID(userid) ACCESS(READ)

SETROPTS RACLIST(SERVAUTH) REFRESH

=========================================================
In Chapter 28, "Mail on z/OS", under "Configuring z/OS UNIX sendmail and popper", under "Steps for configuring z/OS UNIX sendmail", under "Creating the configuration file", change the section on "Retrieving the m4 preprocessor" to the following section:

Retrieve the m4 preprocessor: Retrieve the m4 macro preprocessor from the Tools and Toys for z/OS UNIX System Services website.

Select the binary format to download.

You can provide input to the m4 macro preprocessor to generate a z/OS UNIX sendmail configuration file. Input is a master configuration source file (.mc file) that you can use to define mail delivery mechanisms using files provided in the sample directory. For more information about the .mc file, see “Creating the .mc file” under Creating the configuration file.

The m4 preprocessor is downloaded as m4.pax.Z.bin. After downloading the file, issue the following command:

pax -rzf m4.pax.Z.bin

The m4 preprocessor is created in ./bin/m4.

=========================================================
In Chapter 31, "Remote Execution", under "Configuring the TSO Remote Execution server", replace section "Step 5: Create a user exit routine (optional)" with the following replacement section:

Step 5: Create a user exit routine (optional)
The TSO Remote Execution server enables you to provide an optional user exit routine. You can use this routine to alter the JOB and EXEC statement parameters. In addition, you can use this routine to provide JES control statements to meet installation-specific requirements, such as updating accounting information before the submission of the TSO batch job.

On entry to the exit, register 1 points to the following parameter list:

Offset Description
+0 A pointer to an AF_INET or AF_INET6 address structure in the following format:

Offset Description

+0 Address family AF_INET or AF_INET6 (2 bytes)
+2 Server port (2 bytes)
+4 Client AF_INET or AF_INET6 IP address (4 or 16 bytes)

+4 A pointer to a 1024-byte string terminated by the null character (0x00), which contains the JOB statement parameters.

userid

passwd

msgclass

seclabel

userid

passwd

msgclass

+8 A pointer to a 256-byte string terminated by the null character (0x00), which contains the EXEC statement parameters.

+12 A pointer to a 256-byte string terminated by the null character (0x00), which the exit can use to provide JES control statements. On entry, the string is set to 0x00.

Exit return codes:

nonzero

Rules:

Code the exit with the AMODE(31) and RMODE(ANY) attributes to ensure proper addressability of the input parameters.
The exit must terminate all modified strings with the null character (0x00).
If the server is IPv6 enabled and an IPv4 client connects, the IP address is the 4-byte IPv4 address and not the IPv4-mapped IPv6 address.
If the exit provides JES control statements, the server inserts the control statements into the JCL stream following the JOB statement and before the EXEC statement without any parsing. If more than one control statement is present, the exit must ensure proper JCL line separation by including the NL character or CRLF character as necessary.
The server inserts the EXEC parameters into the JCL stream without parsing. If the exit modifies the EXEC parameters, it must ensure proper JCL line separation by including the NL character or CRLF character as necessary.

Guidelines:

For RSH commands without passwords, the PASSWORD parameter is not present.
The userid in the first positional parameter of the JOB statement parameters can be processed by installation-written JES exits.
The modified parameters are submitted as a TSO batch job.

Tip:
The exit can have the server reject a connection by setting a nonzero return code. The exit can replace the JOB statement buffer contents with message text to be returned to the client. The first byte of the buffer can be set to 0x00 to reject the connection without sending a message to the client.

The user exit is shipped as a sample in the RXUEXIT member of the SEZAINST data set. For more information about this sample, see the REXEC topic in z/OS Communications Server: IP Configuration Reference.

=========================================================
In Chapter 2, "IP configuration overview", under "Understanding search orders of configuration information", under "Configuration data set naming conventions", under "TCP/IP configuration data sets", add the following entry in Table 1, "TCP/IP configuration data sets":

Name (search order)	Copied from	Usage
INETD.CONF The MVS data set or z/OS UNIX file specified on the EXEC DD statement in the INETD started procedure	/samples/inetd.conf	Provides configuration management statements of generic servers for the Internet Daemon (InetD). InetD handles rlogin, telnetd, rshd, rexec, and other applications. For more information about InetD, see z/OS UNIX System Services Planning.

=========================================================
In Chapter 2, "IP configuration overview", under "Understanding search orders of configuration information", under "Configuration data set naming conventions", under "TCP/IP configuration data sets", in Table 1, "TCP/IP configuration data sets", change the search order for the PROFILE.TCPIP data set to the following search order:

1. The MVS data set specified on the PROFILE DD statement in the TCP/IP stack started procedure.
2. jobname.nodename.TCPIP
3. TCPIP.nodename.TCPIP
4. jobname.PROFILE.TCPIP
5. TCPIP.PROFILE.TCPIP

=========================================================
In Chapter 2, "IP configuration overview", under "Configuration files for the TCP/IP stack", under "PROFILE.TCPIP search order", change the first bulleted list to the following list:

//PROFILE DD DSN=aaa.bbb.ccc(anyname)
jobname.nodename.TCPIP
TCPIP.nodename.TCPIP
jobname.PROFILE.TCPIP
TCPIP.PROFILE.TCPIP

=========================================================
In Chapter 2, "IP configuration overview", under "Configuration files for the TCP/IP stack", under "PROFILE.TCPIP search order", under "Examples", change step 3 to the following step:

3. TCPIP.nodename.TCPIP
If TCPIP.nodename.TCPIP is found, the search stops here.

=========================================================
In Chapter 2, "IP configuration overview", under "Considerations for multiple instances of TCP/IP", under "Port management overview", under "Generic servers in a CINET environment", replace the example that uses JCL for the started procedure for INETD to the following example:

//INETD PROC
//************************************************************
//INETD EXEC PGM=BPXBATCH,
//* PARM=’PGM /usr/sbin/inetd -d /etc/inetd.conf’
// PARM=’PGM /usr/sbin/inetd //’’USER1.INETD.CONF’’’
//* PARM=’PGM /usr/sbin/inetd //’’SYS1.TCPPARMS(INETDCNF)’’’
//*
//STDERR DD PATH=’/tmp/inetd.debug.stderr’,
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=SIRWXU
//STDOUT DD PATH=’/tmp/inetd.debug.stdout’,
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=SIRWXU
//STDENV DD DISP=SHR,DSN=USER1.INETD.ENVIRON
//*STDENV DD DISP=SHR,DSN=SYS1.TCPPARMS(INETDENV)

=========================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the local host table (optional)", under "Creating HOSTS.LOCAL site host table", under "HOST entries", change the third bullet to the following bullet:

A list of fully qualified names for that host, which are separated by commas. The first name is the official host name, or CNAME (canonical name), and any additional host names after the CNAME are alias names. You can specify a maximum of 20 host names. Only the first six host names are used in the hlq.HOSTS.ADDRINFO data set. All 20 host names are used in the hlq.HOSTS.SITEINFO data set.

=========================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the local host table (optional)", under "Creating /etc/hosts", replace the second bullet with the following bullet:

The line starts with an IP address, followed by a blank, followed by host names. Host names are separated by one or more blanks. The first host name that follows an IP address is the official host name, or CNAME (canonical name). Any additional host names that follow the CNAME are alias host names.

=========================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the local host table (optional)", under "Creating ETC.IPNODES and /etc/ipnodes", add the following bullet after the third bullet:

The line starts with an IP address, followed by a blank, followed by host names. Host names are separated by one or more blanks. The first host name that follows an IP address is the official host name, or CNAME (canonical name). Any additional host names that follow the CNAME are alias host names.

=========================================================
In Chapter 7, "Virtual IP Addressing", under "Configuring distributed DVIPAs — sysplex distributor", under "Sysplex-wide source VIPA", under "Sysplex-wide source VIPAs for TCP connections", change the first paragraph to the following information:

The TCPSTACKSOURCEVIPA keyword on the IPCONFIG or IPCONFIG6 statements allows users to specify a single VIPA, static or dynamic, to be used as a source IP address for TCP applications that initiate outbound connections on that stack. TCPSTACKSOURCEVIPA is in effect only when SOURCEVIPA is enabled and an application issues a connect() without a bind(). Applications that perform an explicit bind() do not use the TCPSTACKSOURCEVIPA address, such as the following applications:

LPQ
LPR
REXEC as a TSO command
RSH
SMTP when mail is being sent to other servers
TELNET client

In addition, applications that use the Pascal API TcpOpen() call have an explicit bind() performed for them.

=========================================================
In Chapter 7, "Virtual IP Addressing", under "Dynamic VIPAs and routing protocols", under "IPv4 considerations for OMPROUTE", after the list of tips, change the remainder of the topic to the following information:

OMPROUTE cannot build an advertisement with a size that exceeds the largest IP packet size, which is 64K. When this limit is reached, the following message is displayed:

EZZ7967I ADVERTISEMENT DISCARDED, OVERFLOWS BUFFER: LS
TYPE x ID x.x.x.x ORG y.y.y.y

Result: If this limit is reached with a router link-state advertisement (LSA), OMPROUTE cannot send the router LSA and other hosts cannot calculate routes to destinations (for example, VIPAs) owned by the stack on which OMPROUTE is running. OMPROUTE ends if it encounters this condition. If OMPROUTE cannot send its router LSA, it is useless as a router.

If an LSA exceeds the maximum transmission unit (MTU) size on its network, the LSA is fragmented. This fragmentation is not a problem for OMPROUTE, but some routers cannot accept fragmented LSAs.

Tip: If you are experiencing adjacency problems with routers and have many interfaces on your stack, check for fragmentation of the OMPROUTE router LSA.

Normally, large router LSAs are not a problem, as the size of LSAs seldom exceeds 64K, or even network MTU sizes. However, if many VIPA or dynamic VIPA interfaces are defined on a host, router LSA size can become a consideration. The size of the router LSA includes 52 bytes for headers, plus the number of bytes required to advertise the interfaces that the host owns. The number of bytes required for each interface is:

VIPA 12 bytes, plus 12 bytes for each VIPA subnet

Tip:

Point-to-point 24 bytes

Point-to-multipoint 12 bytes, plus 12 bytes for each neighbor on the interface

All other types 12 bytes

=========================================================
In Chapter 14, "The resolver", under "Resolver configuration files", under "Search orders used in the z/OS UNIX environment", under "Translate tables", change the tip to the following tip:

Tip: Preallocating the STANDARD.TCPXLBIN data set using a JCL DD statement stops the resolver from issuing dynamic allocations for the data set. The name on the DD statement can be any valid ddname. Preallocation eliminates the dynamic allocation messages (for example, IEF237I and IEF285I) from being written to the job output log.

=========================================================
In Chapter 14, "The resolver", under "Resolver configuration files", under "Search orders used in the native MVS environment", under "Translate tables", change the tip to the following tip:

Tip: Preallocating the STANDARD.TCPXLBIN data set using a JCL DD statement stops the resolver from issuing dynamic allocations for the data set. The name on the DD statement can be any valid ddname. Preallocation eliminates the dynamic allocation messages (for example, IEF237I and IEF285I) from being written to the job output log.

=========================================================
In Appendix A, "Setting up the inetd configuration file", replace the first two paragraphs with the following paragraphs:

The Internet Daemon (InetD) is a generic listener program that is used by such servers as the z/OS UNIX telnet server and the z/OS UNIX rexec server. Other servers such as the z/OS UNIX ftp server have their own listener program and do not use InetD. For more information about generic servers and sample InetD started procedure JCL, see Generic servers in a CINET environment.

The inetd.conf file is an example of the user configuration file. This file is stored in the /etc directory and is referenced as a start parameter in the InetD started procedure JCL. The inet.conf file can also be stored as an MVS data set. Ensure that you use configuration statements like those statements in the following example to enable the InetD services that are required on your system:

=========================================================
In Appendix A, "Setting up the inetd configuration file", replace the last example with the following example:

#
# All ftp, rexecd, rshd
# debug messages (and above
# priority messages) go
# to server.debug.a
#
daemon.debug /tmp/syslogd/server.debug.a

=========================================================
In Appendix B, "TLS/SSL security", under "Secure Socket Layer overview", under "Encryption algorithms", under "Enable CSFSERV resources", replace the first two paragraphs, including the numerical list of CSFSERV resources (service-names) that are accessed by System SSL, with the following information:

If hardware encryption and Integrated Cryptographic Services Facility (ICSF) are installed, system SSL verifies that the user ID that is associated with the server is permitted to use CSFSERV resources. The RACF administrator can permit the RACF user ID to use the CSFSERV resources:

PERMIT service-name CLASS(CSFSERV) ID(serverid) ACCESS(READ)

For information about the CSFSERV resources (service-names) that are accessed by System SSL, see z/OS Cryptographic Services System SSL Programming.

=========================================================

[{"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"All","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"1.12","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Tips

z/OS V1R12 Communications Server: IP Configuration Guide

Troubleshooting

Problem

Resolving The Problem

Was this topic helpful?

Document Information

UID

Share your feedback

Need support?