IBM Support

z/OS V1R10 Communications Server: IP Configuration Guide

Troubleshooting


Problem

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

Resolving The Problem

===================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "Local user access control to TCP/IP resources using the SAF", in Table 11 "SERVAUTH profiles used by TCP/IP", the "SERVAUTH profile" column for "DCAS server access control" should be changed as follows:

FunctionDescriptionSERVAUTH profile
DCAS server access controlControls ability to access DCAS server based on SAF user ID associated with TLS-authenticated X.509 client certificate EZA.DCAS.cvtsysname

===================================================================
In Chapter 6, "Routing", under "OMPROUTE configuration", under "Steps for configuring OMPROUTE", in step 5 change the example of the portion of the services file relevant to OMPROUTE to the following:
route 520/udp router omproute
route 521/udp ipv6rip ripng

===================================================================
In Chapter 6, "Routing", under "Steps for configuring OSPF and RIP (IPv4 and IPv6) ", in step 1 under "IPv4 OSPF", add the following at the end of the first paragraph:
For more information about the rules and guidelines for the ROUTERID parameter of the OSPF statement, see z/OS Communications Server: IP Configuration Reference.

===================================================================
In Chapter 6, "Routing", under "Steps for configuring OSPF and RIP (IPv4 and IPv6) ", in step 1 under "IPv6 OSPF", add the following at the end of the first paragraph:
For more information about the rules and guidelines for the ROUTERID parameter of the IPV6_OSPF statement, see z/OS Communications Server: IP Configuration Reference.

===================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", under "Steps for customizing the FTP server for Kerberos", change steps 6 and 7 to the following:
6. Create the service principal against a RACF ID for use with a keytab (see step 7 for using Kerberos with no keytab).
a. Create a RACF user ID to associate with the FTP service principal.
adduser FTP NOPASSWORD DFLTGRP(SYS1) omvs(autouid home('/u/ftp') prog('/bin/sh'))

b. After the FTP RACF user ID is created, add the Kerberos principal to it.
ALTUSER FTP PASSWORD(ftp) NOEXPIRED KERB(KERBNAME(ftp/<hostname>))

c. If a password is not assigned to the FTP ID, issue the following command to remove it.
ALTUSER FTP NOPASSWORD

d. To ensure the Kerberos segment was added, use the following command to display the ID.
LU FTP NORACF KERB

Result:

USER=FTP


KERB INFORMATION
----------------
KERBNAME= ftp/<hostname>
KEY VERSION= 001
KEY ENCRYPTION TYPE= DES DES3 DESD


To add the FTP service principal to the keytab file, do the following:


a. The keytab file is located in the /etc/skrb directory. Switch to that directory using the following command:
cd /etc/skrb

b. Use the following command to see what is currently in the keytab file:
keytab list

If nothing is currently in the keytab file, the following is returned:
Key table: /etc/skrb/krb5.keytab


c. Add the FTP service principle using the following command:
keytab add ftp/<hostname>

You will be prompted for the principals' password. For this example, that password is FTP. The password must be entered in uppercase. This password was assigned with the RACF ALTUSER command when the FTP service principal was created.



d. Issue the keytab list command again.

The following should be displayed when the FTP service principal is present:

Key table: /etc/skrb/krb5.keytab

Principal: ftp/<hostname>@<realm>
Key version: 1
Key type: 56-bit DES
Entry timestamp: 2005/02/04-16:21:10

Principal: ftp/<hostname>@<realm>
Key version: 1
Key type: 56-bit DES using key derivation
Entry timestamp: 2005/02/04-16:21:10

Principal: ftp/<hostname>@<realm>
Key version: 1
Key type: 168-bit DES using key derivation
Entry timestamp: 2005/02/04-16:21:10


7. An alternate way to run without a keytab file is to associate the FTP service principal to the ID under which the FTP started task runs. If the ID that the FTP started task runs under is FTPD, issue the following command to create the FTP service principal and have it associated to that ID.

ALTUSER FTPD PASSWORD(ftpd) NOEXPIRED KERB(KERBNAME(ftp/<hostname>))


Rule: In this setup, you must set the KRB5_SERVER_KEYTAB
environment variable. Specify it directly in the FTP startup
procedure as follows:

//FTPD EXEC PGM=&MODULE,REGION=4096K,TIME=NOLIMIT,
// PARM=('POSIX(ON) ALL31(ON)',
// 'ENVAR("KRB5_SERVER_KEYTAB=1")/&PARMS')

Another way of specifying the environment variable directly in the
startup procedure is to specify a file where the environment
variables are listed.

//FTPD EXEC PGM=&MODULE,REGION=4096K,TIME=NOLIMIT,
// PARM=('POSIX(ON) ALL31(ON)',
// 'ENVAR("_CEE_ENVFILE=/etc/ftp.envvars")/&PARMS')

Then, within the /etc/ftp.envvars file, add the following:

KRB5_SERVER_KEYTAB=1



===================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", under "Steps for migrating the FTP server and client to use AT-TLS", in Table 31 "Migrating existing FTP server and client configuration", in the "AT-TLS equivalent statement" column, change "V3CipherSuite" to "V3CipherSuites" as follows:
FTP.DATA statementAT-TLS equivalent statementAT-TLS policy statement
KEYRINGKeyringTTLSKeyRingParms -> TTLSEnvironmentAction
CIPHERSUITEV3CipherSuitesTTLSCipherParms ->
TTLSEnvironmentAction
TLSTIMEOUTGSK_V3_SESSION_TIMEOUTTTLSGskAdvancedParms -> TTLSEnvironmentAction

===================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", at the end of subsection "Steps for migrating the FTP server and client to use AT-TLS", change "V3CipherSuite" to "V3CipherSuites" (three occurrences) in the TTLSCipherParms statement as follows:

TTLSCipherParms
{
V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA
V3CipherSuites TLS_RSA_WITH_3DES_EDE_CBC_SHA
V3CipherSuites TLS_RSA_WITH_NULL_SHA
}

===================================================================
In Chapter 11, "Transferring files using FTP", under "Configuring the optional FTP user exits", under "The FTPOSTPR user exit", change the note to the following note list:
Notes:
1. Fields above marked with an asterisk (*) are valid only for IPv4 addresses, including IPv4-mapped IPv6 addresses.
2. The directory type reflects the current working directory. The MVS data set or z/OS UNIX file that is retrieved or stored can be located in a different type of directory.

===================================================================
In Chapter 13, "Domain Name System", under "Performance Issues", after the second paragraph, add the following paragraph:
The BIND 9 name server randomizes the UDP source port that is used for processing recursive queries. Randomizing the port provides additional security against DNS spoofing. When random ports are used, the CPU time used by BIND 9 can increase up to 50 percent for a recursive request. If you use the PORT or PORTRANGE statement to reserve a large portion of the UDP ports, the BIND 9 name server consumes higher amounts of CPU time and might be unable to process recursive requests. You can disable port randomization by coding random-port-attempts 0 in the options statement. However, disabling port randomization increases the exposure to DNS spoofing attacks. When using BIND 9 in environments that might be susceptible to spoofing attacks, you can use port randomization to minimize this exposure or you can disable recursive queries in the BIND 9 name server by coding recursion no in the options statement. In environments with a limited number of UDP ports available to the BIND 9 name server, recursive queries should not be used in conjunction with port randomization.

===================================================================
In Chapter 20, "Application Transparent Transport Layer Security data protection", under "Common setup considerations", add the following subsection:
Preparation for diagnostic traces
In addition to the steps for diagnosing AT-TLS problems described in z/OS Communications Server: IP Diagnosis Guide, you might need to collect a System SSL trace when you are diagnosing an AT-TLS problem. The only practical method for collecting this trace is by using the GSKSRVR CTRACE, as described in z/OS System SSL Programming.

Guideline: Activate the GSKSRVR started task as part of the system IPL, so that you can collect diagnostic traces when needed without having to recycle TCP/IP. The GSKSRVR started task must be active before TCP/IP is started.

If you are not using any other features provided by the GSKSRVR started task, then you can use the sample procedure provided in the SGSKSAMP library without any changes.

===================================================================
In Chapter 22, "Automated domain name registration", under "ADNR configuration example", the resource records displayed in the line descriptions were corrupted in the BookManager output. Check the PDF output for the correct resource records, or the following:
Lines 29 and 31:
prodplex.mvsplex.mycorp.com IN A 10.1.1.22
prodplex.mvsplex.mycorp.com IN A 10.1.10.22
prodplex.mvsplex.mycorp.com IN A 10.1.1.1
prodplex.mvsplex.mycorp.com IN A 10.1.10.1

Line 40:
sysa.mvsplex.mycorp.com IN A 10.1.1.22
sysa.mvsplex.mycorp.com IN A 10.1.10.22

Line 45:
sysb.mvsplex.mycorp.com IN A 10.1.1.1
sysb.mvsplex.mycorp.com IN A 10.1.10.1

Line 81:
ztelnet.mvsplex.mycorp.com IN A 10.1.1.22
ztelnet.mvsplex.mycorp.com IN A 10.1.1.1

Line 91:
telnetprimary.ztelnet.mvsplex.mycorp.com IN A 10.1.1.22

Line 97:
telnetsecondary.ztelnet.mvsplex.mycorp.com IN A 10.1.1.1

Line 108:
zftp.mvsplex.mycorp.com IN A 10.1.1.22
zftp.mvsplex.mycorp.com IN A 10.1.1.1

===================================================================
In Chapter 2, "IP configuration overview", under "Performance considerations", change the second paragraph to the following:
VTAM, TCP/IP, and some associated server applications must be able to obtain cycles to maintain their network presence. The following dispatching priority guidelines apply for these functions:
  • In general, you should set VTAM and TCP/IP to a higher dispatching priority than that of the applications that use their services.
  • For server applications such as OMPROUTE, TN3270E Telnet server, IKED, NSSD, and FTPD, you should 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, if you make these tasks non-swappable, they will be 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.
  • Set non-critical applications, such as Policy Agent and TRMD, to a lower priority.
  • Set the SNMP agent and all the SNMP subagents to the same WLM service class so that they all have the same dispatching priority. Timeouts can occur if the SNMP subagents are set to a lower dispatching priority than the SNMP agent.

===================================================================
In Chapter 2, "IP configuration overview", under "Required steps before starting TCP/IP", under "Step 3: Configure VMCF and TNF", after the second paragraph, change the note to a tip, and change the paragraph following the note to a guideline, as follows:
Tip: Host name is the value normally specified on the TCPIP.DATA HOSTNAME statement.

Guideline: The VMCF node name is used as a system-name qualifier when processing the TCPIP.DATA file and it is used by the SMTP server as the NJE node name. For this reason, you should use the MVS system name for the VMCF node name specification and specify the NJE node name explicitly by using the NJENODENAME statement in the SMTP configuration data set.

===================================================================
In Chapter 2, "IP configuration overview", under "Required steps before starting TCP/IP", under "Step 3: Configure VMCF and TNF", under "Restartable subsystems", change step 3 to the following:
3. Start VMCF and TNF using the procedure EZAZSSI before starting TCP/IP. If your node name is the same as the MVS system symbolic &SYSNAME, then you can start VMCF and TNF with the following command:
S EZAZSSI

If your node name is different than the MVS system symbolic &SYSNAME, start VMCF and TNF with the following command:
S EZAZSSI,P=nodename

Replace nodename with the system name of your MVS system. If you use SMTP, verify that the SMTP NJE node name is specified by using the NJENODENAME statement in the SMTP configuration data set.

===================================================================
In Chapter 2, "IP configuration overview", under "Required steps before starting TCP/IP", under "Step 3: Configure VMCF and TNF", under "Non-restartable subsystems", change the last paragraph to the following:
Replace nodename on the VMCF line with the system name of your MVS system. If you use SMTP, verify that the SMTP NJE node name is specified by using the NJENODENAME statement in the SMTP configuration data set.

===================================================================
In Chapter 3, "Security", under "Network security services for the IPSec discipline", in the lists of SERVAUTH resource profiles, some of the profile names include a misspelling and should be as follows:
  • EZB.NSS.sysname.clientname.IPSEC.CERT
  • EZB.NSS.sysname.clientname.IPSEC.NETMGMT
  • EZB.NETMGMT.sysname.clientname.IPSEC.DISPLAY
  • EZB.NETMGMT.sysname.clientname.IPSEC.CONTROL

===================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Starting and stopping syslogd", after the third paragraph that includes the list of three modes, add the following requirement:
Requirement: You must install and activate the AF_UNIX domain prior to starting syslogd in normal or local-only mode.

===================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Diagnosing syslogd configuration problems", before the first paragraph, add the following paragraph:
You must install and activate the AF_UNIX domain prior to starting syslogd in normal or local-only mode. To determine whether AF_UNIX was successfully started, check for a message in the console log similar to the following:
BPXF203I DOMAIN AF_UNIX WAS SUCCESSFULLY ACTIVATED.

===================================================================
In Chapter 8, "TCP/IP in a sysplex", under "Workload balancing", under "Internal load balancing solutions", under "Sysplex distributor", under "Steps for setting up sysplex distributor to be the service manager for the Cisco MNLB (IPv4 only)", between existing steps 4 and 5, add the following new step 5 (with existing step 5 now being step 6, and subsequent step numbers also being increased by 1):
5. If you are using V1R7 or later, configure all forwarding agents with IP PIM DENSE-MODE to ensure that MNLB packets are forwarded properly.

===================================================================
In Chapter 10, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Steps for starting the TN3270E Telnet server", under "Steps for defining security for a user ID and associating the user ID with the Telnet procedure name", under the first bullet in step 1, change the example ALTUSER command in step B3 to the following:
ALTUSER TN3270E DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(23) HOME('/'))

===================================================================
In Chapter 10, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Steps for starting the TN3270E Telnet server", under "Steps for defining security for a user ID and associating the user ID with the Telnet procedure name", under the second bullet in step 1, change the example ALTUSER command to the following:
ALTUSER TN3270E DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(23) FILEPROCMAX(150000) HOME('/'))

===================================================================
In Chapter 10, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Steps for starting the TN3270E Telnet server", under "Steps for defining security for a user ID and associating the user ID with the Telnet procedure name", under the fourth bullet in step 1, change the example ALTUSER command to the following:
ALTUSER TN3270E DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(0) HOME('/'))

===================================================================
In Chapter 10, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Steps for starting the TN3270E Telnet server", under "Steps for defining security for a user ID and associating the user ID with the Telnet procedure name", add the following new step 3, with the existing step 3 becoming step 4:
3. If you are using secure Telnet connections, make sure that the user ID that runs Telnet has access to the SSL key ring and certificates. Do one of the following:
===================================================================
In Chapter 10, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Telnet configuration data set customization details", under "Associating Telnet with one TCP/IP stack", change the third paragraph to the following:
If you want to explicitly associate Telnet with one stack for control purposes or for functionality support, use the TCPIPJOBNAME statement in the TELNETGLOBALS block when you start Telnet. If you use the TCPIPJOBNAME statement, you must continue to use it on all future profile updates to set affinity to the same stack.

===================================================================
In Chapter 10, "Accessing remote hosts using Telnet", under "TN3270E Telnet server", under "Telnet configuration data set customization details", under "LU name mapping statements", under "LUMAP, PRTMAP, LUGROUP, PRTGROUP", change the second and third examples (and the intervening paragraph) to the following:
LUGROUP LUGRP1 LUT101..LUT400..FFFNNN ENDLUGROUP
PRTGROUP PRTGRP1 PRT101..PRT400..FFFNNN ENDPRTGROUP

IPGROUP IPGPAY 255.255.0.0:9.8.0.0 ENDIPGROUP

LUMAP LUGRP1 IPGPAY
PRTMAP PRTGRP1 IPGPAY

If these same LUs can be mapped by more than one Telnet, put them into shared LU groups instead by adding an S to the object type as follows:
SLUGROUP LUGRP1 LUT101..LUT400..FFFNNN ENDSLUGROUP
SPRTGROUP PRTGRP1 PRT101..PRT400..FFFNNN ENDSPRTGROUP

===================================================================
In Chapter 10, "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", after the second tip, in the list of factors for why a takeover attempt might not complete as expected, add the following bullet:
  • TKOSPECLURECON and TKOGENLURECON do not preserve a session if the takeover is done for a shared Telnet LU name managed by a LUNS.

===================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", under "Steps for customizing the FTP server for TLS", under step 1 in the first bullet in the BOO file only (PDF is correct), change the statement to the following:
TLSRFCLEVEL DRAFT

===================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", under "Steps for customizing the FTP server for TLS", under step 1 in the second bullet in the BOO file only (PDF is correct), change the statement to the following:
TLSRFCLEVEL RFC4217

===================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", under "Steps for customizing the FTP client for TLS", under step 1 in the first bullet in the BOO file only (PDF is correct), change the statement to the following:
TLSRFCLEVEL DRAFT

===================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", under "Steps for customizing the FTP client for TLS", under step 1 in the second bullet in the BOO file only (PDF is correct), change the statement to the following:
TLSRFCLEVEL RFC4217

===================================================================
In Chapter 13, "Domain Name System", under "Advanced BIND 9 name server topics", under "TSIG", under "Instructing the server to use the key", change the second paragraph to the following:
Multiple keys can be present, but only the first is used. This directive does not contain any secrets, so it can be in a world-readable file. A world-readable file or directory is one that anyone can read. For directories, assuming the directory is also world-executable, world-readable means that anyone can list the files contained inside the directory. Passwords and other sensitive data should never be in world-readable files. For information about setting the other permissions that make a file or directory world-readable or non-world-readable, see z/OS UNIX System Services Command Reference.

===================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", after the search order used when starting the Policy Agent, change the next paragraph to the following:
The syntax for a z/OS UNIX file is different than the syntax for an MVS data set. Following are examples using the PAGENT_CONFIG_FILE environment variable:
  • PAGENT_CONFIG_FILE=/dir/file
  • PAGENT_CONFIG_FILE=//'mvs.dataset.name'

===================================================================
In Chapter 18, "Network security services", under "Preparing to provide network security services", under "Steps for authorizing resources for NSS", in step one change the first command to the following:
ADDUSER NSSD DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(0) HOME('/'))

===================================================================
In Chapter 18, "Network security services", under "Preparing to provide network security services", under "Steps for authorizing resources for NSS", in step 7a, change the ADDUSER command to the following:
ADDUSER userid DFLTGRP(OMVSGRP) OMVS(UID(x))

===================================================================
In Chapter 18, "Network security services", under "Preparing to provide network security services", under "Steps for authorizing resources for NSS", in step 7a, change the "Rule:" to the following:
Rules:
  • Multiple NSS clients can use a single user ID. However, each NSS client must have a unique client name.
  • A SAF user ID must have an OMVS segment with either AUTOID or a specific UID(x) defined for NSSD to authenticate it as an NSS client.

===================================================================
In Chapter 18, "Network security services", under "Preparing to provide network security services", under "Steps for authorizing resources for NSS", after step 7a, insert the following new step 7b, and change existing step 7b to now be step 7c, and so on for subsequent steps:
b. If you choose to define an NSSD profile in the APPL class with UACC(NONE), issue the following command to authorize each SAF user ID to the NSSD application:
PERMIT NSSD CLASS(APPL) ID(userid) ACC(READ)
SETROPTS RACLIST(APPL) REFRESH

===================================================================
In Chapter 19, "Defensive filtering", under "Enabling defensive filtering", under "Steps for configuring the DMD" in step 3 change the fourth paragraph to the following:
If the DMD was defined to the external security manager with a nonzero UID, ensure that the DMD has permission to read the configuration file. The DMD user ID must have both read access to the configuration file and execute access to the directory containing the configuration file.

Tip: You can create the configuration file in the /var/dm directory and use the DMD_FILE environment variable to specify the configuration file. You set up the /var/dm directory in step 2 to allow DMD to create, delete, read, and write files to this directory.

===================================================================
In Chapter 19, "Defensive filtering", under "Steps for authorizing resources for the DMD and the ipsec command", in step 1 change the ADDUSER command to the following:
ADDUSER DMD DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(0) HOME('/'))

===================================================================
In Chapter 19, "Defensive filtering", under "Steps for authorizing resources for the DMD and the ipsec command", change the first sentence of step 3 to the following:
3. Define SERVAUTH profiles to control the users that are allowed to manage defensive filters.

===================================================================
In Chapter 20, "Application Transparent Transport Layer Security data protection", under "Policy considerations", under "Action refresh", after the second paragraph, add the following paragraph:
Sometimes after you have made a change to an AT-TLS policy, the changed policies are not automatically reinstalled by the Policy Agent; new connections might fail until the policies are reinstalled. If you see AT-TLS connection setup errors with message EZD1286I or EZD1287I after you made an AT-TLS configuration change, you can force all AT-TLS policies to be reinstalled by refreshing the Policy Agent. From the MVS console, issue the MODIFY procname,REFRESH command. For more information about controlling the refresh of polices using the TcpImage and PEPInstance statements, see z/OS Communications Server: IP Configuration Reference.

===================================================================
In Chapter 22, "Automated domain name registration", under "Steps for configuring automated domain name registration", under "Step 7: Define security server profiles for ADNR", in the first paragraph, change the example ADDUSER command to the following:
ADDUSER ADNR DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(nn) -
HOME(’/RDWR_working_directory’) PROGRAM(’/bin/sh’))

===================================================================
In Chapter 23, "Simple Network Management Protocol", under "Step 1: Configure the SNMP agent", in the first paragraph, change the information after the figure and before the bulleted list to the following:
Configure the SNMP agent based upon your security need. The SNMP agent accepts both SNMPv1 and SNMPv2c requests for community-based security. The SNMP agent can be configured to also use the User-based Security Model and the View-based Access Control Model. You should assign the SNMP agent and all the SNMP subagents to the same WLM service class so that they all have the same dispatching priority. Timeouts can occur if the SNMP subagents are set to a lower dispatching priority than the SNMP agent.

To configure the SNMP agent, perform the following tasks:

===================================================================
In Chapter 25, "Remote procedure calls", under "Steps for configuring the rpcbind address space", under "Step 2: Configuring security server (or RACF equivalent) items", change the first line of the example to the following:
ADDUSER RPCBIND DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(0) HOME(’/’))

===================================================================
In Chapter 26, "Mail servers", under "Configuring the SMTP server", under "Checklist for working within the SMTP environment", change step 3 to the following:
3. Because SMTP needs authority to create, read, write, and purge data on the JES spool, any security programs that protect JES spool access must have the user ID or group ID that is associated with the SMTP started task name in their definitions of authorized users. If your security product is RACF, you can control the association of a user ID or group ID to a started task name by the STARTED class. For more information about RACF controls for the JES spool, see z/OS Security Server RACF Security Administrator’s Guide.

===================================================================
In Chapter 26, "Mail servers", under "Configuring z/OS UNIX sendmail and popper", under "Steps for configuring z/OS UNIX sendmail", under "Creating the Message Submission Program file submit.cf", in the example in the fifth paragraph, change the first ADDUSER command to the following:
ADDUSER SENDMAIL DFLTGRP(SMMSPGRP) NOPASSWORD OMVS(UID(0) HOME(’/’))

===================================================================
In Chapter 29, "Remote Execution", under "Configuring the TSO Remote Execution server", under "Step 5: Create a user exit routine (optional)", change the second paragraph to the following:
The user exit should have the AMODE(31) and RMODE(ANY) attributes to provide addressability to the input parameters.

===================================================================
In Appendix E, "Steps for preparing to run IP security", under "Step 2: Authorizing the IKE daemon to the external security manager", under "Steps for authorizing the IKE daemon to RACF", in the example in step 1, change the ADDUSER command to the following:
ADDUSER IKED DFLTGRP(OMVSGRP) NOPASSWORD OMVS(UID(0) HOME(’/’))

===================================================================
In Appendix E, "Steps for preparing to run IP security", under "Step 2: Authorizing the IKE daemon to the external security manager", under "Steps for authorizing the IKE daemon to RACF", change step 3 to the following:
3. If the certificates used by IKED are not site certificates, enable IKED to access the certificates on an ESM key ring by issuing the following commands:
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(IKED) ACCESS(READ)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(IKED) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH

If the certificates used by IKED are site certificates, enable IKED to access them by issuing the following commands:
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENCERT UACC(NONE)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(IKED) ACCESS(UPDATE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(IKED) ACCESS(READ)
PERMIT IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(IKED) ACCESS(CONTROL)
SETROPTS RACLIST(FACILITY) REFRESH

=============================================================
In Chapter 2, "IP configuration overview", under "Performance considerations", starting with the third paragraph, 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 14, "Policy-based networking", under "FLUSH and PURGE considerations", after the results list, change the next paragraph and Table 40 to the following:

Table 40 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 2, "IP configuration overview", under "Configuration files for TCP/IP applications", under "Resolver configuration files", after Table 3 "Local definitions available to resolver", change the next paragraph to the following:
The actual search order of the candidate files varies depending on the type of API that is used and the resolver setup. The search orders are explained in more detail in Search orders used in the z/OS UNIX environment and Search orders used in the native MVS environment. Because the resolver runs in the address space of the application, the candidate files are accessed from the application address space.

====================================================================
In Chapter 2, "IP configuration overview", under "MVS-related considerations", under "MVS system symbols", change the fifth paragraph and the subsequent note to the following:
For MVS system symbols in other configuration files, use the symbol translator utility, EZACFSM1, to translate the symbols before the files are read by TCP/IP. EZACFSM1 reads an input file and writes to an output file, translating any symbols in the process. For lists of the static system symbols and dynamic system symbols supported by EZACFSM1, see z/OS MVS Initialization and Tuning Reference.

Guideline: The input file and output file can be MVS data sets or z/OS UNIX files; however, do not specify the same file for both the input and output file. If you specify the same file, a return code of 45 is returned and no translation is attempted.

====================================================================
In Chapter 2, "IP configuration overview", under "UNIX System Services security considerations", under "Program control", in Table 7 "Program control", in the "Details" column of the third row, change the list of commands to the following:
RDEFINE PROGRAM * ADDMEM(’SYS1.LINKLIB’/volser/NOPADCHK) UACC(READ)
RALTER PROGRAM * ADDMEM(’SYS1.SIEALNKE’/volser/NOPADCHK)
RALTER PROGRAM * ADDMEM(’cee.version.SCEERUN’/volser/NOPADCHK)
RALTER PROGRAM * ADDMEM(’TCPIP.SEZALOAD’/volser/NOPADCHK)
RALTER PROGRAM * ADDMEM(’TCPIP.SEZATCP’/volser/NOPADCHK)
RALTER PROGRAM * ADDMEM(’db2.DSNLOAD’/volser/NOPADCHK)
RALTER PROGRAM * ADDMEM(’db2.DSNEXIT’/volser/NOPADCHK)
RALTER PROGRAM * ADDMEM(’ftp.userexits’/volser/NOPADCHK)

====================================================================
In Chapter 2, "IP configuration overview", change the "Maximum transmission unit considerations" section to the following:
Determining the maximum transmission unit
TCP/IP uses the maximum transmission unit (MTU) value to determine the largest sized frame to send. The MTU value that is in effect for a given outbound send is one of the following two values:
  • Path MTU value

TCP/IP automatically enables path MTU discovery for IPv6. If a packet is an IPv6 packet, or if a packet is an IPv4 packet and path MTU discovery is enabled, the path MTU value is used to determine the maximum size of the packet. Path MTU discovery initially sets the path MTU value to the actual route MTU value for the route. If packets require fragmentation to get to the final destination, path MTU discovery determines the path MTU value by repeatedly decreasing the value until it can send packets to the final destination without fragmentation.

Guideline: You can enable path MTU discovery for IPv4 by configuring IPCONFIG PATHMTUDISCOVERY in the TCP/IP profile.
  • Actual route MTU value

If path MTU discovery is not enabled, the actual route MTU value is used. The actual route MTU value is the lesser of the interface MTU value and the configured route MTU value.
  • Interface MTU value

The interface MTU value is a characteristic of an interface, and is either learned from the device during activation or is hardcoded based on the type of the physical device. For information about the interface MTU values that TCP/IP uses for the various network interface types supported by TCP/IP, see the summary of DEVICE and LINK statements and the summary of INTERFACE statements in z/OS Communications Server: IP Configuration Reference. For an IPAQENET6 interface, or an IPAQENET interface defined with the INTERFACE statement, you can configure a lower interface MTU value using the MTU keyword on the INTERFACE statement.

Restriction: You cannot modify the interface MTU value for IPAQENET interfaces defined using the DEVICE, LINK, and HOME statements.

Results:
  • The TCP/IP stack sets the interface MTU value to the lesser of the learned MTU value and the MTU value configured on the INTERFACE statement.
  • For an active link or interface, TCP/IP reports the interface MTU value in the ActMtu field of the Netstat DEVLINKS/-d report.
  • Configured route MTU value

The configured route MTU value is the MTU size that is configured for a route.
  • Static route

For a static route, you can specify the configured route MTU value in the TCP/IP profile on a ROUTE entry in a BEGINROUTES block or on a GATEWAY statement.
  • IPv4 dynamic route

For IPv4 dynamic routes over an interface that are added by OMPROUTE, the configured route MTU value is the value of the MTU keyword specified on the RIP_INTERFACE, OSPF_INTERFACE or INTERFACE statement in the OMPROUTE configuration file for the outgoing interface of the route.

Result: If you do not specify an MTU value for an interface in the OMPROUTE configuration file, OMPROUTE uses the value 576.
  • IPv6 dynamic route

For IPv6 dynamic routes added by OMPROUTE, OMPROUTE learns the interface MTU value from TCP/IP; you cannot configure a route MTU value in the OMPROUTE configuration file.

Result: For IPv6 dynamic routes that are learned by OMPROUTE, the configured route MTU size is the same as the interface MTU size.

These factors comprise a general set of rules for how TCP/IP determines the MTU, but there are some exceptions. For example, if an application uses the IPV6_USE_MIN_MTU socket option, TCP/IP sends outbound packets using the IPv6 minimum MTU value 1280.

Guidelines:
  • Enable path MTU discovery in configurations where traffic originating in the z/OS TCP/IP stack will traverse multiple hops with different MTU sizes.
  • The OSA-Express Gigabit Ethernet adapter supports an interface MTU value of 8992, but not all routers and switches support an MTU value of this size. If you are using this adapter and any routers or switches in your configuration do not support an MTU value of 8992, then either configure a lower MTU value for your routes or specify a lower MTU value on the INTERFACE statement in the TCP/IP profile.
  • When you are using OMPROUTE, specify the MTU keyword for each IPv4 interface.
  • When you are using OMPROUTE, configure all nodes on a LAN to use the same MTU value. Otherwise, you might encounter problems, such as OSPF adjacency errors.

====================================================================
In Chapter 2, "IP configuration overview", under "Required steps before starting TCP/IP", under "Step 3: Configure VMCF and TNF", change the first paragraph to the following:
The Pascal socket interface uses the IUCV/VMCF services for a limited set of inter-address space communication flows. As a result, if you are using any applications (provided by IBM or others) that use the Pascal socket API, you must ensure that the Virtual Machine Communication Facility (VMCF) and Termination Notification Facility (TNF) subsystems are active before the applications are started. TCP/IP provides the following applications and commands that use the Pascal socket interface:
  • SMTP and LPD servers
  • TSO HOMETEST, LPQ, LPR, LPRM, LPRSET, TELNET, and TESTSITE commands

If you are using any of these applications or commands, you need to set up VMCF and TNF.

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Starting and stopping syslogd", after the list of the three modes, add the following paragraph:
In all three modes, syslogd can send messages to remote syslog daemons.

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Starting and stopping syslogd", after the restriction and before the syntax information, add the following information:
To record timestamps more accurately, you need to set the TZ environment variable to local time. You can set the TZ environment variable in the following ways:
  • When you start syslogd from the z/OS shell

Export the TZ environment variable before you start syslogd. Export it in /etc/profile or in .profile in the HOME directory. For example, if you are in the Eastern time zone in the United States, issue the following command:

export TZ=EST5EDT
  • When you are starting syslogd as a started task, use either of the following methods:
  • Specify TZ using the ENVAR parameter on the PARM statement in the started procedure. For example:

// PARM='ENVAR("TZ=EST5EDT")/'
  • Export the TZ environment variable in a file specified with the STDENV DD statement. For example:

// PARM='ENVAR("_CEE_ENVFILE=DD:STDENV")/'
//STDENV DD PATH='/etc/syslogd.env',PATHOPTS=(ORDONLY)

Place the following statement in the /etc/syslogd.env file:

TZ=EST5EDT

Use the STDENV DD statement when you want to specify more than one environment variable; there is a JCL limit of 100 characters on the PARM parameter. Language Environment recommends a variable record format for the STDENV file.

You can also set the TZ environment variable for all applications in the CEEPRMxx PARMLIB member. You should define the TZ environment variable for all three LE option sets (CEEDOPT, CEECOPT, and CELQDOPT). For example:

CEECOPT(ALL31(ON), ENVAR('TZ=EST5EDT') )
CEEDOPT(ALL31(ON), ENVAR('TZ=EST5EDT') )
CELQDOPT(ALL31(ON), ENVAR('TZ=EST5EDT') )

For more information about specifying run-time options, see z/OS Language Environment Programming Guide. For details on setting the TZ environment variable, see z/OS UNIX System Services Command Reference.

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Starting and stopping syslogd", in the list of syslogd command options, change the entry for -i to the following:
-i Start in local-only mode, and do not receive messages from the IP network. This option is mutually exclusive with the -n option. If syslogd is started with the -i option, another instance of syslogd can be started with the -n option. This is the only supported way to run two instances of syslogd on the same z/OS image. Syslogd can still send messages to remote syslogd instances when it is running in local-only mode.

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Starting and stopping syslogd", in the list of syslogd command options, change the entry for -n to the following:
-n Start in network-only mode, and receive messages from only the IP network. This option is mutually exclusive with the -i option. If syslogd is started with the -n option, another instance of syslogd can be started with the -i option. This is the only supported way to run two instances of syslogd on the same z/OS image. Syslogd can still send messages to remote syslogd instances when it is running in network-only mode.

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Diagnosing syslogd configuration problems", change the paragraph after the rule to the following:
If you are running syslogd in batch with -d, debug output is written to SYSPRINT, SYSTERM, or SYSERR, whichever is found first. The sample syslogd procedure SEZAINST(syslogd) defines SYSPRINT so that debug messages are stored in the job output. The following example shows how to change the SYSPRINT DD statement to write debug output to a file.
SYSPRINT DD PATH=’/var/syslog/syserr’,PATHOPTS=(OWRONLY,OCREAT)

====================================================================
In Chapter 7, "Virtual IP Addressing", under "Configuring distributed DVIPAs — sysplex distributor", in the list of the distribution methods, add the following to the end of the description for "Weighted active forwarding":
To enable the distributing stack to use server-specific abnormal completion and health information to affect the active connection weight, specify SYSPLEXROUTING on the IPCONFIG statement for all participating stacks.

====================================================================
In Chapter 7, "Virtual IP Addressing", under "Configuring distributed DVIPAs — sysplex distributor", change the last paragraph before the first subsection to the following:
Guideline: If you are using OMPROUTE for connectivity to a dynamic VIPA, the LPAR with the distributing stack that owns that dynamic VIPA is the only target stack (no remote target stacks are available), and a HiperSockets (iQDIO) interface is not configured, code a static route that represents the shared IP address in the attached network router to maintain connectivity; otherwise, because a HiperSockets interface is not configured, OMPROUTE does not advertise the routing information representing the shared IP address for the dynamic XCF interfaces in that LPAR, and the address might become unreachable because the interfaces to the remote target stacks are deleted or marked inactive. Unlike IUTSAMEH and DXCF interfaces, a HiperSockets interface that shares an IP address can remain active when there are no more remote target stacks available, and OMPROUTE advertises the routing information to the neighboring network routers (for example, Cisco) for connectivity to the shared IP address.

For more information about sysplex distributor, see Communications Server for z/OS V1R10 TCP/IP Implementation Volume 3: High Availability, Scalability, and Performance, SG24–7698.

====================================================================
In Chapter 8, "TCP/IP in a sysplex", under "Connectivity in a sysplex", under "Dynamic XCF", under "IUTSAMEH", change the second paragraph to the following:
The IUTSAMEH device and link (IPv4) or interface (IPv6) do not become active and remain in SENT SETUP status until either another TCP/IP stack or Enterprise Extender connection is activated on this MVS image.

====================================================================
In Chapter 13, "Domain Name System", under "Setting up and running the name server", under "Configuring a master (primary) name server", under "Step 8. Configure logging (For BIND 9 only)", change the last example to the following:
logging {
channel main_log {
file "/tmp/named_main.log" versions 2 size 20M;
print-time yes;
print-category yes;
print-severity yes;
print-threadid yes;
# severity debug 99;
severity info;
};
channel security_log {
file "/tmp/named_security.log" versions 2 size 1M;
severity info;
# severity debug 99;
};
channel query_log {
file "/tmp/named_query.log" versions 2 size 10M;
# severity debug 99;
severity info;
};
channel transfer_log {
file "/tmp/named_transfer.log" versions 2 size 10M;
severity debug 7;
};

category client { main_log; };
category config { main_log; };
category database { main_log; };
category dispatch { main_log; };
category dnssec { security_log; main_log; };
category general { main_log; };
category network { main_log; };
category notify { main_log; };
category resolver { main_log; };
category security { security_log; main_log; };
category update { main_log; };
category queries { query_log;};
category lame-servers { query_log; main_log; };
category xfer-in { "transfer_log"; };
category xfer-out { "transfer_log"; };
category default { main_log; };
category unmatched { main_log; };
};

====================================================================
In Chapter 14, "Policy-based networking", under "Steps for configuring the Policy Agent", change the first paragraph to the following:
Before you begin: You need to understand the hierarchy and relationships of the different configuration files. A single file, the main configuration file, is specified explicitly or by default when the Policy Agent is started. This main configuration file points to other configuration files, as shown in the following figure.

For more information about the Policy Agent search order, see z/OS Communications Server: IP Configuration Reference.

====================================================================
In Chapter 14, "Policy-based networking", under "Steps for configuring the Policy Agent", under "Step 1: Configure general information", add the following two new steps before the existing first step, and renumber the existing steps:
1. Set the TZ and LIBPATH environment variables.

Use the TZ environment variable to specify the correct time zone. Use the LIBPATH environment variable so that the required dynamic link library (DLL) files can be located when you start the Policy Agent. For information about how to specify these environment variables, see Starting and stopping the Policy Agent. You can also refer to comments in the sample start procedure that is shipped in SEZAINST(EZAPAGSP).

2. Specify the name of the main configuration file.

You can specify the name of the main configuration file using the following methods:
  • -c start option
  • PAGENT_CONFIG_FILE environment variable
  • Default file name /etc/pagent.conf

For information about the search order that Policy Agent uses to locate the main configuration file, and for examples of different ways to specify the main configuration file name, see Starting and stopping the Policy Agent. You can also refer to comments in the sample start procedure that is shipped in SEZAINST(EZAPAGSP).

====================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", after the first paragraph, add the following subsection title:
AUTOLOG considerations
If a procedure in the AUTOLOG list...

====================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", after the autolog tip and the next paragraph, add the following subsection title:
Specifying environment variables
The Policy Agent requires access to one or more DLLs at run time...

====================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", under the new "Specifying environment variables" section added by the previous update, change three paragraphs to the following:
The Policy Agent requires access to one or more DLLs at run time. The LIBPATH environment variable needs to be set to include the /usr/lib directory, which normally includes all the required DLLs.

For policy time specifications to be properly acted upon, the TZ environment variable needs to be set to local time. You can set the LIBPATH and TZ environment variables as follows:
  • When starting from the z/OS shell:

Export the LIBPATH and TZ environment variables before starting the Policy Agent. This is best accomplished in /etc/profile or in .profile in the HOME directory. For example, if you are in the Eastern time zone in the United States:

export LIBPATH=/usr/lib
export TZ=EST5EDT
  • When starting as a started task, use either of the following methods:
  • Specify LIBPATH and TZ using the ENVAR parameter on the PARM statement in the started procedure. For example:

// PARM=('ENVAR("LIBPATH=/usr/lib","TZ=EST5EDT")/')
  • Export the LIBPATH and TZ environment variables in a file specified with the STDENV DD statement. For example:

// PARM='ENVAR("_CEE_ENVFILE=DD:STDENV")/'
//STDENV DD PATH='/etc/pagent.env',PATHOPTS=(ORDONLY)

In the /etc/pagent.env file:
LIBPATH=/usr/lib
TZ=EST5EDT

The use of the STDENV DD statement works well when you want to specify more than one environment variable; there is a JCL limit of 100 characters on the PARM parameter. Language Environment recommends a variable record format for the STDENV file.

You can also set the TZ environment variable for all applications in the CEEPRMxx PARMLIB member. You should define the TZ environment variable for all three LE option sets (CEEDOPT, CEECOPT, and CELQDOPT). For example:

CEECOPT(ALL31(ON), ENVAR('TZ=EST5EDT') )
CEEDOPT(ALL31(ON), ENVAR('TZ=EST5EDT') )
CELQDOPT(ALL31(ON), ENVAR('TZ=EST5EDT') )

For more information about specifying run-time options, see z/OS Language Environment Programming Guide. For details on setting the LIBPATH and TZ environment variables, see z/OS UNIX System Services Command Reference.

====================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", after the above "Specifying environment variables" information, add the following subsection title:
Main configuration file search order
Although the /etc/pagent.conf is the default configuration file,...

====================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", after the "Main configuration file search order" information (two paragraphs), add the following subsection title:
Other considerations when starting the Policy Agent
If the Policy Agent cannot successfully parse the start options, log output is written to the syslog daemon (syslogd)...

====================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", after the "Other considerations when starting the Policy Agent" information (seven paragraphs), add the following subsection title:
Stopping the Policy Agent
You can stop the Policy Agent by:...

====================================================================
In Chapter 16, "Intrusion Detection Services", under "Attack policies", change the bullet for "Inbound fragment restrictions" to the following:
  • Inbound fragment restrictions

Many attacks are the result of fragment overlays in the IP or transport header. You can use this support to protect your system against future attacks by detecting fragmentation within the first 88 bytes of a datagram.

Guideline: Examine packets flagged by this attack type to determine whether the packets are legitimate traffic. Although fragmentation within the first 88 bytes of a datagram is suspicious, it is does not violate any RFC specifications.

You can use IDS policy to provide notification of a packet that has been fragmented within the first 88 bytes, as well as to discard the packet.

Tip: Initially use the NoDiscard action and evaluate any packets flagged by this attack type. If legitimate traffic in your network is being flagged as suspicious because it is fragmented in the first 88 bytes, you should not use the Discard action.

====================================================================
In Chapter 16, "Intrusion Detection Services", under "TRMD", in the bulleted list, change the second bullet to the following:
  • A timestamp that is generated when the syslogd record ID is created. This timestamp is dependent on the setting of the TZ environment variable at the time that TRMD is started. If you want this timestamp to be based on UTC, then ensure that the TZ environment variable is properly set (for example, export TZ=0) before starting TRMD.

====================================================================
In Chapter 16, "Intrusion Detection Services", under "TRMD", after the bulleted list, add the following information:
You can set the TZ environment variable in the following ways:
  • When starting TRMD from the z/OS shell:

Export the TZ environment variable before starting TRMD; you should do this in /etc/profile or in .profile in the HOME directory. For example, if you are in the Eastern time zone in the United States:

export TZ=EST5EDT
  • When starting TRMD as a started task, use either of the following methods:
  • Specify TZ using the ENVAR parameter on the PARM statement in the started procedure. For example:

// PARM=’ENVAR("TZ=EST5EDT")/’
  • Export the TZ environment variable in a file specified with the STDENV DD statement. For example:

// PARM=’ENVAR("_CEE_ENVFILE=DD:STDENV")/’
//STDENV DD PATH=’/etc/trmd.env’,PATHOPTS=(ORDONLY)

Place the following statement in the /etc/trmd.env file:
TZ=EST5EDT

The use of the STDENV DD statement works well when you want to specify more than one environment variable; there is a JCL limit of 100 characters on the PARM parameter. Language Environment recommends a variable record format for the STDENV file.

You can also set the TZ environment variable for all applications in the CEEPRMxx PARMLIB member. You should define the TZ environment variable for all three LE option sets (CEEDOPT, CEECOPT, and CELQDOPT). For example:

CEECOPT(ALL31(ON), ENVAR(’TZ=EST5EDT’) )
CEEDOPT(ALL31(ON), ENVAR(’TZ=EST5EDT’) )
CELQDOPT(ALL31(ON), ENVAR(’TZ=EST5EDT’) )

For more information about specifying run-time options, see z/OS Language Environment Programming Guide. For details on setting the TZ environment variable, see z/OS UNIX System Services Command Reference.

====================================================================
In Chapter 17, "IP security", under "Steps for preparing the z/OS system for IP security", in step 4, change the guideline to the following:
Guideline: You should not change the logging levels of the IKE daemon (IkeSyslogLevel) and Policy Agent (PagentSyslogLevel) from their default values for normal day-to-day operation. Higher logging levels can affect performance and should be used for temporary diagnostic purposes only. The default PagentSyslogLevel value 0 prevents the IKE daemon from logging diagnostic information about its interactions with Policy Agent. The default IkeSyslogLevel value 1 provides basic informational and error messages. You can set the IkeSyslogLevel value to 0 to disable IKE syslog messages entirely (for both the IKE daemon and Policy Agent; to collect PagentSyslogLevel tracing, the IkeSyslogLevel value must also be a nonzero value). You can set the IkeSyslogLevel value to a higher value to identify the source of an error; for example, if you experience problems with Security Association negotiations that are caused by a configuration error, you might enable IkeSyslogLevel 4 (debugging information for Security Association negotiations).

====================================================================
In Chapter 20, "Application Transparent Transport Layer Security data protection", under "Common setup considerations", change the subsection "Preparation for diagnostic traces" (that was previously added in this technote) to the following:
Preparation for diagnostic traces
In addition to the steps for diagnosing AT-TLS problems described in z/OS Communications Server: IP Diagnosis Guide, you might need to collect a System SSL trace when you are diagnosing an AT-TLS problem. The only method for collecting this trace is by using the GSKSRVR CTRACE, as described in z/OS System SSL Programming. You cannot use the GSK_TRACE environment variable because it causes an abend if it is used with AT-TLS. When you use GSKSRVR CTRACE to diagnose AT-TLS problems, the job name that you specify on the JOBNAME parameter of the CTRACE command should be the TCP/IP job name rather than the application job name.

If you are not using any other features provided by the GSKSRVR started task, then you can use the sample procedure provided in the SGSKSAMP library without any changes.

====================================================================
In Chapter 1, "Overview of z/OS Communications Server", under "Connectivity and gateway functions", modify the description for MPCIPA interfaces, as shown in the PDF that is contained in the technote for z/OS V1R10 Communications Server: TCP/IP in an ensemble, reference # 7019754, under Chapter 2, "IP Configuration Guide", under "Overview of z/OS Communications Server", under "Connectivity and gateway functions".

====================================================================
In Chapter 2, "IP configuration overview", under "Configuration files for TCP/IP applications", under "Resolver configuration files", in the list of Communications Server TSO commands that use the native MVS search order, change the bullet and note for "FTP (batch)" to the following:
  • FTP (batch only)

  • Rule: Batch FTP jobs use //SYSTCPD if it is specified. If //SYSTCPD is not specified, then the z/OS UNIX search order is used.

====================================================================
In Chapter 2, "IP configuration overview", under "Configuration files for TCP/IP applications", under "Resolver configuration files", in the list of Communications Server UNIX commands that use the z/OS UNIX search order, change the bullet for "ftp" to the following:
  • ftp

  • Rule: The TSO FTP command also uses the z/OS UNIX search order.
====================================================================
In Chapter 2, "IP configuration overview", under "MVS-related considerations", under "MVS system symbols", after the note, add the following restriction:
Restriction: The record length of the input file cannot exceed 80 bytes.

====================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "Local user access control to TCP/IP resources using SAF", change the second paragraph to the following:
You define SAF resource profiles in the SERVAUTH class to control access to the TCP/IP resources. After you define a SAF resource profile, a local user can access the associated TCP/IP resource if their user ID has at least READ access to the resource.

====================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "Stack access control", change the first paragraph to the following:
You can create a SAF resource profile to control access to a TCP/IP stack. There are no new TCP definitions required. The resource profile controls whether users or groups of users have access to the TCP/IP stack by controlling their ability to open an AF_INET or AF_INET6 socket and to obtain the host ID or host name. Create the EZB.STACKACCESS.sysname.tcpname resource profile in the SERVAUTH class for the TCP/IP stack to be protected. After you define this resource profile, permit users to the profile and grant them READ access to the resource. If a user does not have READ access to the resource for a stack, the user cannot access the stack. If you do not define a resource profile for a stack, all users have access to that stack.

====================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "Port access control", under "Controlling access to particular ports", change the third paragraph to the following:
If you specify the SAF keyword on the PORT or PORTRANGE statement, it can provide additional access control by verifying that the user ID associated with an application at the time of a bind to the port is authorized to access the port. The SAF keyword value specifies a portion of the resource name that represents the port. Define the EZB.PORTACCESS.sysname.stackname.port_safname resource profile in the SERVAUTH class to control access to the port, where port_safname is the same value that you specify on the SAF keyword of the PORT or PORTRANGE statement. The user ID that is associated with the application at the time of the bind request must have READ access to this resource for the application to be able to bind to the port.

====================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "Network access control", in the bulleted list, change the third and fourth bullets to the following:
  • SAF is used to check whether users or groups of users have READ access to a security zone.
  • You define a SAF resource profile for each security zone and provide READ access to these resources to the users or groups of users that you want to have access to particular security zones. A security zone is represented by the EZB.NETACCESS.sysname.tcpname.zonename resource name in the SERVAUTH class.

====================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "Netstat access control", change the first paragraph to the following:
You can control access to Netstat command output from the TSO or UNIX System Services shell environments using the System Authorization Facility (SAF). There are no new TCP definitions required. The Netstat command output is considered the resource to be protected, and you protect it by defining EZB.NETSTAT.sysname.tcpname.netstatoption resource profiles in the SERVAUTH class. A user ID has access to the Netstat output for a particular option if a security profile is defined in the SERVAUTH class for that option, and that user ID has READ access to the associated resource. Access is also given if there is no resource profile defined for a resource.

====================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "Fast Response Cache Accelerator access control", change the second paragraph to the following:
You can control application access to FRCA services by defining the EZB.FRCAACCESS.sysname.tcpname resource profile in the SERVAUTH class. Access to FRCA services is allowed if the web server user has READ access to this resource, or if the resource profile is not defined. There are no new TCP definitions required. This function is enabled if the SERVAUTH class is active and the FRCA resource profile is defined. If this resource profile is not defined, the check is not made.

====================================================================
In Chapter 3, "Security", under "TCP/IP resource protection", under "TCP/IP stack initialization access control", change the first paragraph to the following:
You can control whether an application can access a TCP/IP stack before the required policies have been installed, during the period of time after the stack is active but before Application Transparent Transport Layer Security (AT-TLS) has been initiated from policy. Access checking is performed only if you have configured AT-TLS in the initial PROFILE.TCPIP configuration data set. If AT-TLS is configured, you can control whether an application can access the TCP/IP stack before the required policies have been installed by defining the EZB.INITSTACK.sysname.tcpname resource profile in the SERVAUTH class. During the period of time after the stack is active and before AT-TLS has been initiated from policy, all socket requests are blocked if this resource profile is not defined. If this resource profile is defined, access to the stack is permitted only to user IDs that have READ access to the resource. Checking ceases the first time that the Policy Agent processing of the AT-TLS policy is completed, or when a profile change deactivates AT-TLS.

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Starting and stopping syslogd", after the list of syslogd command options, change the paragraph and examples for terminating syslogd to the following:
To terminate syslogd, you can issue the STOP command, issue the MODIFY command, or send a SIGTERM signal.
STOP jobname
MODIFY BPXOINIT,TERM=processID
kill -s TERM processID

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the syslog daemon", under "Starting and stopping syslogd", after the paragraph and examples for terminating syslogd, change the kill command example used to force syslogd to reread its configuration file and activate any modified parameters without stopping to the following:
kill -s HUP processID

====================================================================
In Chapter 5, "TCP/IP Customization", under "Configuring the local host table (optional)", under "Creating HOSTS.LOCAL site host table", under "HOST entries", in the bulleted list, change the last two bullets to the following:
  • A list of IP addresses, separated by commas, for that host. You can specify a maximum of six IP addresses per HOST entry.
  • A list of fully qualified names, separated by commas, for that host. You can specify a maximum of 20 host names per HOST entry. Only the first six host names per host entry are used in the hlq.HOSTS.ADDRINFO data set. All 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.IPNODES and /etc/ipnodes", add the following to the end of the first bullet:
If you need more than 256 characters for the IP address and the associated host names, you can code additional lines with the same IP address as follows:
Address1 Hostname1
Address1 Hostname2
Address1 Hostname3

====================================================================
At the end of Part 1, "Base TCP/IP system", add Chapter 9, "TCP/IP in an ensemble", as shown in the PDF that is contained in the technote z/OS V1R10 Communications Server: TCP/IP in an ensemble, reference # 7019754, under Chapter 2, "IP Configuration Guide", under "TCP/IP in an ensemble".

====================================================================
In Chapter 10, "Accessing remote hosts using Telnet", under "The TN3270E Telnet server", under "Telnet configuration data set customization details", under "Advanced LU name mapping topics", under "LU name assignment user exit", change the sixth paragraph to the following:
In another example, assume that the clients specify LUGROUP names that match the default applications on the LUMAP statement. The LU names are to be created based on the last two numbers of the IP address and a prefix that identifies the application. For example, TSO, IMS, and CICS are three current applications, and the prefix for each is TS, IM, and CI, respectively. The connection from IP address 9.1.240.111 specifies LUGROUP LUGTSO and is assigned the name TS240111. The connection from IP address 9.1.240.212 specifies LUGROUP LUGIMS and is assigned the name IM240212. The connection from IP address 9.1.89.7 specifies LUGROUP LUGTSO and is assigned the name TS089007. Three LU name exits are required (LUGTSO, LUGIMS, LUGCICS), but they are all functionally equivalent. The LU name specified in the LUGROUP statement is passed to the LU name exit as part of the parameter list, and that name is used by the exit as the prefix. The client IP address is also in the parameter list. To force Telnet to call each exit, the LU name exit must return a nonzero return code when the LU name sent by the client does not match the LUGROUP name. The LU name exit combines the prefix with the last portions of the IP address to create an LU name. The following statements can be used to support this scenario.

====================================================================
In Chapter 11, "Transferring files using FTP", under "Customizing Transport Layer Security and Kerberos security", under "Steps for customizing the FTP client for TLS", change the first three paragraphs of step 4 to the following:
4. Use a CERTAUTH virtual key ring, or create a client key ring database and add the certificates that you need to that database.

If you are using server authentication only and the FTP server certificate is signed by a certificate authority (CA), the FTP client can use a CERTAUTH virtual key ring and you do not need to create a client key ring database. To use a CERTAUTH virtual key ring, use the key ring name *AUTH*/*.

If you cannot use a virtual key ring, create the client key ring database and add the certificates that you need to that database. For information about how to create a key ring database and add certificates to that database, see Creating and managing keys and certificates at the server. Every TLS session handshake includes server authentication. If a server certificate is self-signed, you must import that certificate to the key ring database of any client that will log in using TLS. If the server certificate is signed by a CA, the CA certificate used to sign the server certificate (rather than the server certificate itself) needs to be in the client key ring database. For more information, see Server authentication and Creating and managing keys and certificates at the server.

====================================================================
In Chapter 11, "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 11, "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 11, "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 14, "Policy-based networking", under "Policy components overview", under "Policy sample files", replace the second set of LDAP sample files (the sample files for the definition of the schemas in LDAP protocol version 3 format) with the following:
/usr/lpp/tcpip/samples/pagent_r8qosschema.ldif
    This file contains the schema version 3 QoS schema definitions.
/usr/lpp/tcpip/samples/pagent_r5idsschema.ldif
    This file contains the schema version 3 IDS schema definitions.
====================================================================
In Chapter 14, "Policy-based networking", under "LDAP server", under "Installing the schema definition on the LDAP server", change the information between the first and last paragraphs to the following:
For LDAP protocol version 3, the schema definition is shipped in ldif format and installed on the LDAP server as a modification to the generic schema entry, known as a subschema. You must modify the existing schema entry to include the supported schema as a subschema by using the ldapmodify command. The schema definition files that you must install are located in the /usr/lpp/tcpip/samples directory. You must install the files in the following order:
1. pagent_r8qosschema.ldif
2. pagent_r5idsschema.ldif

This process is supported for the z/OS LDAP server.

To install the schema definitions, use commands like those shown in the following examples:
ldapmodify -h <server address> -p <server port> -D <administrator userid>
-w <password> -f /usr/lpp/tcpip/samples/pagent_r8qosschema.ldif

ldapmodify -h <server address> -p <server port> -D <administrator userid>
-w <password> -f /usr/lpp/tcpip/samples/pagent_r5idsschema.ldif

====================================================================
In Chapter 14, "Policy-based networking", under "Steps for configuring the Policy Agent", under "Step 1: Configure general information", change the introductory sentence for step 2 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.

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 14, "Policy-based networking", under "Steps for configuring the Policy Agent", under "Step 6: Configure Policy Agent for configuration file import services", in the second paragraph of the first step, change the fourth sentence to the following:
You can specify the image name to be used, or use the name specified (or specified by default) on the TCPIPUSERID statement or TCPIPJOBNAME statement in TCPIP.DATA.

====================================================================
In Chapter 14, "Policy-based networking", under "Steps for configuring the Policy Agent", under "Step 6: Configure Policy Agent for configuration file import services", in the first step change the first bullet to the following:
  • If the specified name does not match any TcpImage statement, the Policy Agent generates an internal TcpImage statement with default values to represent the TCP/IP image. This means that you can specify a maximum of only 7 (instead of 8) TcpImage or PEPInstance statements.

====================================================================
In Chapter 14, "Policy-based networking", under "Starting and stopping the Policy Agent", shortly after the configuration file search order, delete the following sentence:
If the Policy Agent cannot successfully parse the start options, log output is written to the syslog daemon (syslogd).

====================================================================
In Chapter 23, "Simple Network Management Protocol", under "Step 1: Configure the SNMP agent", under "Sample JCL procedure for starting OSNMPD from MVS", change the example to the following:
//OSNMPD EXEC PGM=EZASNMPD,REGION=4096K,TIME=NOLIMIT,
// PARM=’-c abc -d 255 -p 761’

====================================================================
In Chapter 10, "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 because of syntax errors.

====================================================================
In Chapter 20, "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.

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

[{"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.10","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
15 June 2018

UID

swg21326585