In chapter 2. TCP/IP profile (PROFILE.TCPIP) and configuration statements
In the "DEVICE and LINK -- MPCIPA OSA-Express QDIO devices statement","INTERFACE -- IPAQENET OSA-Express QDIO interfaces statement", and "INTERFACE -- IPAQENET6 OSA-Express QDIO interfaces statement" topics, update the DYNVLANREG | NODYNVLANREG parameter descriptions as follows:
DYNVLANREG | NODYNVLANREG
Controls VLAN ID configuration behavior for this link.
Restriction: This parameter is applicable only if a VLAN ID is specified on the statement.
NODYNVLANREG
Specifies that if a VLAN ID is configured for this link, the ID must be manually registered with the physical switches on the corresponding LAN. This is the default value. If this parameter is specified without a VLAN ID, it is ignored.
DYNVLANREG
Specifies that if a VLAN ID is configured for this link, the ID is dynamically registered with the physical switches on the corresponding LAN. If this parameter is specified without a VLAN ID, message EZZ0056I is issued and the NODYNVLANREG setting is used instead.
=============================================
In Chapter 2. TCP/IP profile (PROFILE.TCPIP) and configuration statements, update the SMFCONFIG statement topic as follows:
- Update "SMFCONFIG statement" description:
The SMFCONFIG profile statement controls only whether SMF records are written to the MVS SMF data sets. Some of the SMF 119 records are also available to applications that connect to the following network management interface (NMI) services:
- Real-time TCP connection SMF data NMI (SYSTCPCN)
- Real-time SMF data NMI (SYSTCPSM)
These functions are part of the real-time TCP/IP network monitoring NMI. For more information about the real-time TCP/IP network monitoring NMI functions，see NETMONITOR statement. If you want your application to process only SMF 119 records by using the real-time TCP/IP network monitoring NMI functions, you need to configure only the NETMONITOR profile statement. You do not need to request support for these records on the SMFCONFIG profile statement.
- Update PROFILE parameter description:
PROFILE
Requests that SMF type 119 records of subtype 4 are created. These records are SMF event records that provide TCP/IP stack profile information. They are created when the stack is first started and when profile changes occur as a result of VARY TCPIP,,OBEYFILE command processing. This operand is valid if the current record type setting is TYPE119. For more information about the contents of this record, see TCP/IP profile event record (subtype 4).
- Add additional bullet to "Related topics":
Related topics
NETMONITOR statement
============================================
In Chapter 2. TCP/IP profile (PROFILE.TCPIP) and configuration statements, update the "NETMONITOR statement" topic as follows:
- Update "NETMONITOR statement" description as follows:
The NETMONITOR parameters, TCPCONNSERVICE and SMFSERVICE, provide two functions:
- They control the availability of the real-time SMF services that are associated with each parameter
- They control the creation of the SMF 119 records that are supported by each service.
If you want your application to process only SMF 119 records by using these real-time SMF services, you need to configure only the NETMONITOR profile statement. You do not need to request support for these SMF 119 records on the SMFCONFIG profile statement.
- Update parameter descriptions as follows:
Parameters
TCPCONNSERVICE | NOTCPCONNSERVICE
Controls the behavior of the real-time TCP connection SMF data network management interface (NMI), service (SYSTCPCN), and the generation of SMF 119 records that are supported on this service.
NOTCPCONNSERVICE
If the parameter is specified in PROFILE.TCPIP at initialization, this parameter indicates that the TCP connection SMF data NMI service should not be started on the stack. This is the default value. If the parameter is specified by the VARY TCPIP,,OBEYFILE command, this parameter indicates that the service should be stopped.
TCPCONNSERVICE
Enables the real-time TCP connection SMF data NMI service to run on this TCP/IP stack. The service runs as a subtask in the TCP/IP stack address space. The TCP connection SMF data NMI service provides an interface for network management applications to obtain information about TCP connections on this stack. For more information about the real-time TCP connection SMF data NMI service and a list of the SMF 119 records supported on this service, see real-time TCP/IP network monitoring NMI in z/OS Communications Server: IP Programmer's Guide and Reference.
Whether you enable or disable this service, or whether you create the associated SMF records, SMF 119 records that are written to the MVS SMF data sets as a result of the settings on the SMFCONFIG profile statement are not effected. You should provide access control for this service. For more information, see z/OS Communications Server: IP Configuration Guide.
SMFSERVICE | NOSMFSERVICE
Controls the behavior of the real-time SMF data network management interface (NMI) service (SYSTCPSM), and the generation of SMF 119 records that are supported on this service.
NOSMFSERVICE
If the parameter is specified in PROFILE.TCPIP at initialization, this parameter indicates that the real-time SMF data NMI service should not be started on the stack. This is the default value. If the parameter is specified using the VARY TCPIP,,OBEYFILE command, this parameter indicates that the service should be terminated.
SMFSERVICE
Enables the real-time SMF data NMI service to run on this TCP/IP stack. The service runs as a subtask in the TCP/IP stack address space. The SMF data NMI service provides an interface for network management applications to obtain stack information in the form of SMF 119 records. This parameter can also be used, with or without subparameters, to request the creation of specific SMF 119 records which are then provided to applications that are connected to this NMI service. For more information about the real-time SMF data NMI service and a list of all the SMF 119 records supported on this service, see real-time TCP/IP network monitoring NMI in z/OS Communications Server: IP Programmer's Guide and Reference.
Rules: - If you have specified the SMFSERVICE parameter (with or without subparameters), certain FTP and Telnet SMF records are created. There are no subparameters to control the creation of these SMF records.
- You can specify only the SMFSERVICE parameter, without any subparameters, to enable the creation of all supported SMF 119 records on this stack.
- For the SMF records whose creation is controlled by subparameters, specify the SMFSERVICE parameter with one or more subparameters to enable or disable the creation of the SMF records for the specified subparameter only.
Whether you enable or disable this service, or whether you create the associated SMF records, SMF 119 records that are written to the MVS SMF data sets as a result of the settings on the SMFCONFIG profile statement or the FTP.DATA SMF configuration statements are not effected. You should provide access control for this service. For more information, see z/OS Communications Server: IP Configuratin Guide.
IPSECURITY | NOIPSECURITY
Controls the creation of the real-time IPSec SMF records.
IPSECURITY
Specifies that the real-time IPSec SMF records should be created and provided on the real-time SMF NMI service.
NOIPSECURITY
Specifies that the real-time IPSec SMF records should not be created.
PROFILE | NOPROFILE
Controls the creation of the real-time TCP/IP profile SMF event records.
PROFILE
Specifies that the real-time TCP/IP profile SMF event records should be created and provided on the real-time SMF NMI service.
NOPROFILE
Specifies that the real-time TCP/IP profile SMF event records should not be created.
. . . .
Related topics
========================================
In chapter 11. OMPROUTE, in the "OMPROUTE cataloged procedure (optional)", update the Restriction description as follows:
When you use the environment variable _CEE_ENVFILE with an MVS data set, allocate the data set with the value RECFM=V. You should not use RECFM=F because RECFM=F causes the environment variable values to be padded with blanks.
=========================================
In chapter 11. OMPROUTE, update the statement description in the "RouterID Statement" topic as follows:
Use the RouterID statement as an alternative to specifying the RouterID parameter on the OSPF configuration statement. See "OSPF Statment" for the statement description. The following concepts apply to the RouterID statement:
- If the RouterID statement is specified, the value configured is used as the OSPF router ID. This value must be one of the OSPF interface IP addresses that is configured for the stack.
Rule: Loopback and reserved 0.0.0.0 addresses are not valid OSPF interface IP addresses.
- If the router ID is not configured, one of the OSPF interface addresses will be used as the OSPF router ID, provided that the interface exists in the TCPIP profile and matches the corresponding OSPF interface statement in the OMPROUTE configuration file at startup.
Result: When OMPROUTE has to assign the router ID, it does not use dynamic VIPA IP addresses. This avoidance of dynamic VIPA IP addresses cannot be guaranteed; for example, if dynamic VIPAs are the only active OSPF interfaces when OMPROUTE chooses the router ID, then one of them will be choosen.
Guideline: Because dynamic VIPAs (DVIPAs) can move between z/OS hosts, the router ID should be a physical interface or a static VIPA, not a dynamic VIPA address. To ensure an appropriate router ID, specify the router ID to OMPROUTE.
==========================================
In chapter 11. OMPROUTE, update the RouterID statement description in the "OSPF Statement" topic as follows:
RouterID - If this RouterID statement is specified, the value configured is used as the OSPF router ID. This value must be one of the OSPF interface IP addresses that is configured for the stack.
Rule: Loopback and reserved 0.0.0.0 addresses are not valid IP interface addresses.
- If the router ID is not configured, one of the OSPF interface addresses will be used as the OSPF router ID, provided that the interface exists in the TCPIP profile and matches the corresponding OSPF interface statement in the OMPROUTE configuration file at startup.
Result: When OMPROUTE has to assign the router ID, it does not use dynamic VIPA IP addresses. This avoidance of dynamic VIPA IP addresses cannot be guaranteed; for example, if dynamic VIPAs are the only active OSPF interfaces when OMPROUTE chooses the router ID, then one of them will be choosen.
Guideline: Because dynamic VIPAs (DVIPAs) can move between z/OS hosts, the router ID should be a physical interface or a static VIPA, not a dynamic VIPA address. To ensure an appropriate router ID, specify the router ID to OMPROUTE
============================================
In chapter 11. OMPROUTE, update the RouterID statement in the "IPv6_OSPF Statement" topic as follows:
- Add a rule as follow in the following condition:
If this router ID is configured, the value configured is used as the IPv6 OSPF router ID.
Rule: The reserved 0.0.0.0 address cannot be used as a router ID.
- Remove the guideline in the following condition:
If this parameter is not configured and IPv4 OSPF is also active on OMPROUTE, the IPv4 Router ID value is also used for IPv6.
==============================================
In chapter 21. Syslog daemon, update the "Starting syslogd with a cataloged procedure" topic description as follows:
Update the cataloged procedure, syslogd, by copying the sample in SEZAINST(SYSLOGD) to your system or recognized PROCLIB. Specify syslogd parameters and change the data set names to suit your local configuration. See the syslog daemon section of SEZAINST(EZARACF) for SAF considerations for started procedures. When you start syslogd from a procedure that does not use BPXBATCH, the resulting job name is the same as the procedure name. When you start syslogd from the z/OS UNIX shell or from a procedure that uses BPXBATCH, the resulting job name is the user ID or the value of the _BPX_JOBNAME environment variable.
===============================================
In chapter 21. Syslog daemon, add an additional rule in the "Starting syslogd from the UNIX shell" topic as follows:
If you start syslogd from a cataloged procedure that uses BPXBATCH, you need to include a sleep command in your script after you start syslogd. The sleep command gives syslogd time to initialize before the shell script ends. For more information about including a sleep command, see Starting daemons in z/OS UNIX System Services Planning.
=================================================
In chapter 22 Policy Agent and policy applications, update the IpFilterPolicy statement syntax as:
=================================================
In chapter 22. Policy Agent and policy applications, in the "Starting Policy Agent as a started task" and "Starting the network SLAPM2 subagent as a started task" topics, update the restriction description as follows:
When you use the environment variable _CEE_ENVFILE with an MVS data set, allocate the data set with the value RECFM=V. You should not use RECFM=F because RECFM=F causes the environment variable values to be padded with blanks.
==================================================
In chapter 22. Policy Agent and policy applications, in the "IPSec policy statements" section, under LocalDynVpnRule, add a new bullet to the Rules list after the "A matching KeyExchangeRule value must exist" rule:
-If IKE is configured for this stack as an NSS client for certificate services, the NSS server must be active and IKE must be connected to NSS before autoactivation is attempted.
==================================================
In chapter 22. Policy Agent and policy applications, update the "TTLSConnectionAdvancedParms statement" topic as follows:
- Add rule and restriction to the ServerHandshakeSNIList parameter as follows:
ServerHandshakeSNIList
Rule: You can use comment indicators and embedded blanks as part of the
certificate label value for this attribute. For example:
ServerHandshakeSNIList myservername/Root#CA Certificate
value used: myservername/Root#CA Certificate
Restrictions: - The total length of all the server names and certificate labels specified must be less than 32K.
- When the certificate label value contains embedded blanks, you must specify the entire parameter value within the first 1024 characters of the configuration file line.
- Update rule and restriction in the CertificateLabel parameter as follows:
Rule: Comment indicators and embedded blanks are treated as part of the
value for this attribute. For example:
CertificateLabel Root#CA Certificate
value used: Root#CA Certificate
Restriction: When the value contains embedded blanks, you must specify the entire value within the first 1024 characters of the configuration file line.
===================================================
In chapter 22. Policy Agent and policy applications, update the "TTLSEnvironmentAdvancedParms statement" topic as follows:
- Add rule and restricion to the ServerHandshakeSNIList parameter as follows:
ServerHandshakeSNIList
Rule: You can use comment indicators and embedded blanks as part of the
certificate label value for this attribute. For example:
ServerHandshakeSNIList myservername/Root#CA Certificate
value used: myservername/Root#CA Certificate
Restrictions: - The total length of all the server names and certificate labels specified must be less than 32K.
- When the certificate label value contains embedded blanks, you must specify the entire parameter value within the first 1024 characters of the configuration file line.
- Update rule and restriction in the CertificateLabel parameter as follows:
Rule: Comment indicators and embedded blanks are treated as part of the
value for this attribute. For example:
CertificateLabel Root#CA Certificate
value used: Root#CA Certificate
Restriction: When the value contains embedded blanks, you must specify the entire value within the first 1024 characters of the configuration file line.
==================================================
In chapter 22. Policy Agent and policy applications, update rule and restriction in the GSK_LDAP_USER parameter in the "TTLSGskLdapParms statement" topic as follows:
GSK_LDAP_USER
Rule: You can use comment indicators and embedded blanks as part of the
value for this attribute. For example:
GSK_LDAP_USER cn=cert #label
value used: cn=cert #label
Restriction: When the value contains embedded blanks, you must specify the entire value within the first 1024 characters of the configuration file line.
==================================================
In chapter 22. Policy Agent and policy applications, add rule and restriction to the X500dn parameter in the "LocalSecurityEndpoint statement" topic as follows:
X500dn
Rules: - When an X500dn type identity is specified, the DN attributes must have the same order as those of the corresponding certificate subject name.
- When an X500dn type identity is parsed, it is converted to an ASN.1 stream and DER-encoded. The maximum length accepted for the DER-encoded name is 1024 bytes.
- Comment indicators and embedded blanks are treated as part of the value for this attribute. For example:
Identity X500DN cn=#my identity
value used: cn=#my identity
Restriction: When the value contains embedded blanks, you must specify the entire parameter value within the first 1024 characters of the configuration file line.
===================================================
In chapter 22. Policy Agent and policy applications, add rule and restriction to the X500dn parameter in the "RemoteIdentity statement" topic as follows:
X500dn
Rule: You can use comment indicators and embedded blanks as part of the value for this attribute. For example:
Identity X500DN cn=#my identity
value used: cn=#my identity
Restriction: When the value contains embedded blanks, you must specify the entire parameter value within the first 1024 characters of the configuration file line.
====================================================
In chapter 22. Policy Agent and policy applications, update the "RemoteSecurityEndpoint statement" topic as follows:
- Add rule and restriction to the X500dn parameter as follows:
X500dn
Rule: You can use comment indicators and embedded blanks as part of the value for this attribute. For examples:
Identity X500DN cn=#my identity
value used: cn=#my identity
Restriction: When the value contains embedded blanks, you must specify the entire parameter value within the first 1024 characters of the configuration file line.
- Update rule and restriction in the CaLabel parameter as follows:
Rule: Comment indicators and embedded blanks are treated as part of the value
for this attribute. For example:
CaLabel Root#CA Certificate
value used: Root#CA Certificate
Restriction: When the value contains embedded blanks, you must specify the entire value within the first 1024 characters of the configuration file line.
====================================================
In chapter 23. RSVP Agent, in the "Starting RSVP as a started task" topic, update the Restriction description as follows:
When you use the environment variable _CEE_ENVFILE with an MVS data set, allocate the data set with the value RECFM=V. You should not use RECFM=F because RECFM=F causes the environment variable values to be padded with blanks.
====================================================
In chapter 25. Simple Network Management Protocol, in the "SNMP agent (OSNMPD)" topic, update the Restriction description as follows:
When you use the environment variable _CEE_ENVFILE with an MVS data set, allocate the data set with the value RECFM=V. You should not use RECFM=F because RECFM=F causes the environment variable values to be padded with blanks.
====================================================
In Chapter 30 SMTP Server, add two more examples to Postermaster statement examples:
Examples
Code the following examples to set the user ID to receive the POSTMASTER mail to MAILGUY at POSTOFC:
POSTMASTER MAILGUY@POSTOFC
a.b.c@company.com
mail.guy@postofc.com
====================================================
In chapter 34. Remote execution server, in the "Remote execution server parameters" topic, update the "TSC= or TSCLASS=" description as follows:
The SYSOUT class for the SYSTSPRT DD statement for submitted jobs. The default is A.
Restriction:
For JES3 users, the HELD output class needs to be defined as a HELD output class for external writer.
=====================================================
In Appendix C. Type 119 SMF records, update the "TCP/IP profile event record (subtype4)" as follows:
The TCP/IP profile record provides profile information for the TCP/IP stack. The creation of this record is controlled by the PROFILE and NOPROFILE parameters of the SMFCONFIG or NETMONITOR profile statements. The first or only record always contains the following sections:
This record is created as an event record for the following reasons:
- If the record is created during the initialization of the stack. In this case, the record contains the complete profile information for the stack.
- If the profile is changed by the use of the VARY TCIP,,OBEYFILE command. In this case, the record contains only changed profile information.
- The NMTP_PICOSecChanged flag bits in the profile information common section indicate which sections actually contain information.
. . . . - If the profile data set referenced by the VARY TCIP,,OBEYFILE command changed the SMFCONFIG setting from PROFILE to NOPROFILE, one final SMF event record is created and written to the MVS SMF data sets to record this change.
- If the profile data set referenced by the VARY TCIP,,OBEYFILE command changed the NETMONITOR SMFSERVICE setting from PROFILE to NOPROFILE, one final SMF event record is created and written to the real-time SMF data network management interface (NMI) to record this change. For more information about the real-time SMF data NMI, see real-time TCP/IP network monitoring NMI in z/OS Communications Server: IP Programmer's Guide and Reference.
|
