GLOBALCONFIG statement

Parameters

ADJUSTDVIPAMSS AUTO | ALL | NONE

Specifies subparameters to control whether TCP/IP changes the Maximum Segment Size (MSS) that is advertised for a TCP connection. Connections that use VIPAROUTE to forward Sysplex Distributor packets add a Generic Routing Encapsulation (GRE) header to the packet. The addition of a GRE header increases the packet size and can cause IP fragmentation between the distributor and the target stack. To avoid this fragmentation, the length of the GRE header can be subtracted from the MSS that TCP connections advertise at connection establishment. Changes to ADJUSTDVIPAMSS affect only the new connections.

AUTO

Indicates that TCP/IP automatically adjusts the MSS to accommodate the length of a GRE header. For inbound connections on a target stack, the MSS is adjusted if the destination address is a distributed DVIPA and VIPAROUTE is being used. For outbound connections on a target stack, the MSS is adjusted if the source IP address is a distributed DVIPA. This is the default value.

ALL

Indicates that TCP/IP adjusts the MSS for connections that use a DVIPA as the local IP address, whether the DVIPA is distributed or not.

NONE

Indicates that TCP/IP does not adjust the MSS for any connections.

AUTOIQDC | NOAUTOIQDC

Specifies whether to dynamically create Internal Queued Direct I/O (IQD) interfaces and transparently converge the dynamic IQD interfaces with the associated OSA interfaces for OSD CHPIDs. The IQD interface that is dynamically created and managed is logically converged with the OSA interface and is referred to as a HiperSockets Converged Interface (IQDC).

See Steps for modifying for details about changing this parameter while the TCP/IP stack is active. See z/OS Communications Server: IP Configuration Guide for information about the HiperSockets Converged Interface and the IQD External Bridge function.

NOAUTOIQDC

Do not use dynamic IQD (HiperSockets) converged interfaces. This value is the default value.

AUTOIQDC

Dynamically manage access to IQD (HiperSockets). AUTOIQDC will dynamically create / delete, start / stop, and transparently converge IQD interfaces (IQDC) with your OSA interfaces for external networks. AUTOIQDC applies to IPv4 (IPAQENET) and IPv6 (IPAQNET6) OSD interface statements. The OSD interface statement must also have been defined with the virtual MAC (VMAC) parameter to request an OSA-generated VMAC address.

The OSA (OSD) CHPID associated with your OSA interface must have a PNetID configured in HCD for the associated OSA port. The dynamic IQD interface is created if an IQD CHPID is found to be configured (in HCD) with the External Bridge function and a PNetID that matches your OSA PNetID.

ALLTRAFFIC

Use IQD interfaces for all eligible outbound traffic flowing on the external IP data network. This value is the default value.

NOLARGEDATA

Do not use IQD dynamic interfaces for outbound TCP socket data transmissions of length 32 KB or larger. Use dynamic IQD interfaces for all other eligible outbound traffic. See z/OS Communications Server: IP Configuration Guide for more information about this setting.

Tips:

• When coding AUTOIQDC, also code IQDIOMULTIWRITE on the GLOBALCONFIG statement to optimize outbound write processing over all HiperSockets interfaces.
• Even when coding AUTOIQDC, some traffic might use the OSD interface to avoid fragmentation. If you use jumbo frames for your OSD interfaces that are associated with a converged HiperSockets CHPID, specify (in HCD) an IQD frame size larger than 16 KB when you configure your converged HiperSockets CHPID. This avoids fragmentation, which allows more traffic to flow over the converged HiperSockets interface.

AUTOIQDX | NOAUTOIQDX

Specifies whether to use dynamic Internal Queued Direct I/O extensions (IQDX) interfaces for connectivity to the intraensemble data network.

See Steps for modifying for details about changing this parameter while the TCP/IP stack is active. See z/OS Communications Server: IP Configuration Guide for information about the intraensemble data network and the dynamic IQDX function.

NOAUTOIQDX

Do not use dynamic IQDX interfaces.

AUTOIQDX

Use dynamic IQDX interfaces when an IQD CHPID has been configured with the Internal Queued Direct I/O extensions (IQDX) function. This value is the default value.

ALLTRAFFIC

Use IQDX interfaces for all eligible outbound traffic on the intraensemble data network. This value is the default value.

NOLARGEDATA

Do not use IQDX interfaces for outbound TCP socket data transmissions of length 32KB or larger. Use IQDX interfaces for all other eligible outbound traffic. See z/OS Communications Server: IP Configuration Guide for more information.

ECSALIMIT ecsalimit K | M

Specifies the maximum amount of extended common service area (ECSA) that TCP/IP can use. This limit can be expressed as a number followed by a K (which represents 1024 bytes), or a number followed by an M (which represents 1048576 bytes). If the K suffix is used, ecsalimit must be in the range 10240K and 2096128K inclusive or 0. If the M suffix is used, ecsalimit must be in the range 10M and 2047M inclusive or 0. The default is no limit, and it can be specified as 0 K or 0 M. The minimum value for ECSALIMIT and POOLLIMIT is not allowed to be set to a value if the current storage in use would be greater than or equal to 80% of that value (for example, not allowed to set it such that there is an immediate storage shortage).

ECSALIMIT ensures that TCP/IP does not overuse common storage. It is intended to improve system reliability by limiting TCP/IP's storage usage. The limit must account for peak storage usage during periods of high system activity or TCP/IP storage abends might occur. The limit does not include storage used by communications storage manager (CSM). CSM ECSA storage is managed independently of the TCP/IP ECSALIMIT. See z/OS Communications Server: SNA Network Implementation Guide for more information about CSM.

Specifying a nonzero ECSALIMIT enables warning messages EZZ4360I, EZZ4361I, and EZZ4362I to appear if a storage shortage occurs.

EXPLICITBINDPORTRANGE | NOEXPLICITBINDPORTRANGE

NOEXPLICITBINDPORTRANGE

Indicates that this stack does not participate in the allocation of ports from a pool of ports. The ports in the pool are guaranteed to be unique across the sysplex in that they are allocated to only one requestor in the sysplex at any one time, when processing an explicit bind() of a TCP socket to the IPv4 INADDR_ANY address, or to the IPv6 unspecified address (in6addr_any), and port 0.

EXPLICITBINDPORTRANGE

Indicates that this stack participates in the allocation of ports from a pool of ports guaranteed to be unique across the sysplex, when processing an explicit bind() of a TCP socket to the IPv4 INADDR_ANY address, or to the IPv6 unspecified address (in6addr_any), and port 0. This parameter also designates the range of ports that defines that pool. This parameter defines the range used by all stacks participating in EXPLICITBINDPORTRANGE port allocation processing throughout the sysplex. The most recently processed profile or OBEYFILE command that specifies EXPLICITBINDPORTRANGE defines the range for the sysplex.

Use this parameter so that you can specify distributed DVIPAs as the source IP address on DESTINATION or JOBNAME rules in a SRCIP block. See SRCIP statement.

1st_port

The starting port for the range of ports. The 1st_port value is in the range 1024 - 65535. The sum of the 1st_port value plus the num_ports value minus 1 cannot exceed 65535.

num_ports

The number of ports in the range. The num_ports value is in the range 1 - 64512. The sum of the 1st_port value plus the num_ports value minus 1 cannot exceed 65535.

Guidelines:

• All TCP/IP stacks in the sysplex that participate in EXPLICITBINDPORTRANGE processing should have the same port range specified. To ensure this, specify the GLOBALCONFIG EXPLICITBINDPORTRANGE statement in a file that is specified in an INCLUDE statement in the TCP profiles data set of all the participating stacks.
• The port range defined on the EXPLICITBINDPORTRANGE parameter should not overlap any existing port reservations of any TCP/IP stacks in the sysplex. Any reserved ports that are within the EXPLICITBINDPORTRANGE range are excluded from the EXPLICITBINDPORTRANGE port pool, effectively making the pool smaller.
• The EXPLICITBINDPORTRANGE port range must be large enough to accommodate all applications in the sysplex that might issue explicit bind() calls for the IPv4 INADDR_ANY address, or for the IPv6 unspecified address (in6addr_any), and port 0.
• If additional TCP/IP stacks or systems are introduced into the sysplex, the extent of the port range defined by EXPLICITBINDPORTRANGE should be re-evaluated.
• If the size of the port range defined by the EXPLICITBINDPORTRANGE parameter is too large, there are fewer ports available for local ephemeral port allocation.

Restriction: In a common INET (CINET) environment, this parameter is accepted, but the EXPLICITBINDPORTRANGE function is supported in a limited set of conditions only. It is supported when CINET is managing one stack only on the system or when the affected application has established stack affinity. Otherwise, results can be unpredictable.

IQDMULTIWRITE | NOIQDMULTIWRITE

Specifies whether HiperSockets interfaces should use multiple write support. HiperSockets multiple write might reduce CPU usage and might provide a performance improvement for large outbound messages that are typically generated by traditional streaming workloads such as file transfer, and interactive web-based services workloads such as XML or SOAP. This parameter applies to all HiperSockets interfaces, including IUTIQDIO and IQDIOINTF6 interfaces created for Dynamic XCF.

Restriction: HiperSockets multiple write is effective only on an IBM® System z10 or later and when z/OS® is not running as a guest in a z/VM® environment.

See the modifying information in this topic for details about changing this parameter while the TCP/IP stack is active. See the HiperSockets multiple write information in z/OS Communications Server: IP Configuration Guide for more information about HiperSockets multiple write support.

NOIQDMULTIWRITE

HiperSockets interfaces do not use the multiple write support. This is the default.

IQDMULTIWRITE

HiperSockets interfaces do use the multiple write support.

IQDVLANID vlan_id

Specifies a VLAN ID to be used when HiperSockets (iQDIO) connectivity is used for dynamic XCF support. VLAN IDs are used to partition communication across HiperSockets. Stacks on the same CPC using the same HiperSockets CHPID that use the same VLAN ID can establish communications; stacks on the same CPC using the same HiperSockets CHPID that use different VLAN IDs cannot.

The specified value, vlan_id, is used for both IPv4 and IPv6 DYNAMICXCF HiperSockets connectivity. This parameter is intended to be used in conjunction with the GLOBALCONFIG XCFGRPID parameter to support subplexing.

Subplexing enables TCP/IP participation in a Sysplex to be partitioned into subsets based on the XCFGRPID value. When using subplexing, TCP/IP stacks with the same XCFGRPID value should specify the same IQDVLANID value. Stacks with different XCFGRPID values should have different IQDVLANID values. If you have stacks in the default subplex (that is, stacks that do not specify an XCFGRPID value) that use the same HiperSockets CHPID as stacks within a non-default subplex (an XCFGRPID value was specified), then the stacks in the default subplex should specify an IQDVLANID value that is different from the other IQDVLANID values specified by the other non-default subplex stacks that use the same HiperSockets CHPID.

Restriction: The IQDVLANID parameter can be specified only in the initial profile.

Valid VLAN IDs are in the range 1 - 4094. For more information about VLANs and Hipersockets see z/OS Communications Server: IP Configuration Guide.

MAXRECS

Specifies the maximum number of records to be displayed by the DISPLAY TCPIP,,NETSTAT operator command. The term records refers to the number of entries displayed on each report. For example, for the connection-related reports, a record is a TCP connection or listener, or a UDP endpoint. This configured value is used when the MAX parameter is not explicitly specified on the command. The default value is 100. If the number of output lines exceeds the maximum number of lines for a multi-line Write to Operator (WTO), the report output is truncated. See the information about the Display TCPIP,,NETSTAT command in z/OS Communications Server: IP System Administrator's Commands for more details about the command.

*

A value of asterisk (*) specifies that all records are to be displayed.

recs

This value specifies the number of records to be displayed. The valid range is 1 - 65535.

MLSCHKTERMINATE | NOMLSCHKTERMINATE

NOMLSCHKTERMINATE

Specifies that the stack should remain active after writing an informational message when inconsistent configuration information is discovered in a multilevel-secure environment.

Informational message EZD1217I is written to the system console summarizing the number of problems found. Additional informational messages between EZD1219I and EZD1234I are written to the job log for each configuration inconsistency found.

This is the default value.

MLSCHKTERMINATE

Specifies that the stack should be terminated after writing an informational message when inconsistent configuration information is discovered in a multilevel-secure environment.

Informational message EZD1217I is written to the system console summarizing the number of problems found. Additional informational messages between EZD1219I and EZD1234I are written to the job log for each configuration inconsistency found.

POOLLIMIT pool_limit K | M

Specifies the maximum amount of authorized private storage that TCP/IP can use within the TCP/IP address space. This limit can be expressed as a number followed by a K (which represents 1024 bytes), or a number followed by an M (which represents 1048576 bytes). If the K suffix is used, pool_limit must be in the range 10240K and 2096128K inclusive or 0. If the M suffix is used, pool_limit must be in the range 10M and 2047M inclusive or 0. The default is no limit, and it can be specified as 0K or 0M. The minimum value for ECSALIMIT and POOLLIMIT is not allowed to be set to a value if the current storage in use would be greater than or equal to 80% of that value (for example, not allowed to set it such that there is an immediate storage shortage).

POOLLIMIT ensures that TCP/IP does not overuse its authorized private storage. Most systems can use the default POOLLIMIT (no limit). Systems with limited paging capacity can use POOLLIMIT to help limit TCP/IP storage usage. If the limit is used, it must account for peak storage usage during periods of high system activity or TCP/IP storage abends might occur.

POOLLIMIT can be higher than the REGION size on the TCP/IP start procedure because POOLLIMIT applies to authorized storage, whereas REGION applies to unauthorized storage. Specifying a nonzero POOLLIMIT enables warning messages EZZ4364I, EZZ4365I, and EZZ4366I to appear if a storage shortage occurs.

SEGMENTATIONOFFLOAD | NOSEGMENTATIONOFFLOAD

Specifies whether the stack should offload TCP segmentation for IPv4 packets to OSA-Express® features. TCP segmentation offload support transfers the overhead of segmenting outbound data into individual TCP packets to QDIO-attached OSA-Express devices whose features that support this function. Offloading segmentation of streaming-type workloads reduces CPU use and increases throughput. This parameter is ignored for OSA-Express features that do not support segmentation offload.

Guideline: The support for specifying IPv4 segmentation offload on the GLOBALCONFIG profile statement has been deprecated. The parameters are still supported on the GLOBALCONFIG statement, but the support for specifying these parameters on the GLOBALCONFIG statement will be dropped in a future release. It is recommended to specify these parameters on the IPCONFIG profile statement instead.

Rule: The SEGMENTATIONOFFLOAD and NOSEGMENTATIONOFFLOAD parameters specified on the IPCONFIG statement override the equivalent parameters specified on the GLOBALCONFIG statement.

See the Modifying topic for information about changing this parameter while the TCP/IP stack is active. See TCP segmentation offload information in z/OS Communications Server: IP Configuration Guide for more information about TCP segmentation offload support.

NOSEGMENTATIONOFFLOAD

TCP segmentation is performed by the TCP/IP stack. This is the default.

SEGMENTATIONOFFLOAD

TCP segmentation is offloaded to the OSA-Express feature.

SMCD | NOSMCD

Specifies whether this stack uses Shared Memory Communications - Direct Memory Access (SMC-D). For more information about SMC-D, see in z/OS Communications Server: IP Configuration Guide.

NOSMCD

Specifies that this stack should not use SMC-D communications. This is the default setting.

SMCD

Specifies that this stack should use SMC-D communications. You can use this parameter to define operational characteristics for SMC-D communications.

Result: The AUTOCACHE and AUTOSMC monitoring functions are started if SMCGLOBAL AUTOCACHE and AUTOSMC are configured, either by default or by being explicitly specified.

If you specify the SMCD parameter without any subparameters, you get one of the following results:

• If you specify the SMCD parameter for the first time, the FIXEDMEMORY and TCPKEEPMININTERVAL subparameters are set to default values.
• If you previously specified the SMCD parameter with subparameters, TCP/IP retains the knowledge of the subparameter settings, even if SMC-D processing is stopped by issuing the VARY TCPIP,,OBEYFILE command with a data set that contains a GLOBALCONFIG NOSMCD parameter. Therefore, a subsequent specification of a GLOBALCONFIG SMCD profile statement resumes SMC-D processing with the previous subparameter settings.

FIXEDMEMORY mem_size

Specifies the maximum amount of 64-bit storage that the stack can use for the receive buffers that are required for SMC-D communications. The mem_size value is an integer in the range 30 - 9999, and represents the maximum storage in megabytes of data. The default value is 256 megabytes.

TCPKEEPMININTERVAL interval

This interval specifies the minimum interval that TCP keepalive packets are sent on the TCP path of an SMC-D link.

Rules:

• If a keepalive interval is also specified on the INTERVAL parameter of the TCPCONFIG statement or is set for a specific SMC-D link socket by the TCP_KEEPALIVE setsockopt() option, the largest of the three interval values is used.
• The valid range for this interval is 0-2147460 seconds, and the default value is 300 seconds.
• A value of 0 disables TCP keepalive probe packets on the TCP path of an SMC-D link.
• The SO_KEEPALIVE setsockopt() option must be set to use keepalive processing.

Result: The TCPKEEPMININTERVAL setting has no effect on keepalive processing for the SMC-D path of an SMC-D link.

For more information about TCP keepalive processing for the TCP path and the SMC-D path of SMC-D links, see TCP keepalive in z/OS Communications Server: IP Configuration Guide.

SMCGLOBAL

Specifies global settings for Shared Memory Communications (SMC). SMC includes Shared Memory Communications over Remote Direct Memory Access (RDMA), or SMC-R, for external data network communications and Shared Memory Communications - Direct Memory Access (SMC-D). For more information about SMC-R and SMC-D, see Shared Memory Communications in z/OS Communications Server: IP Configuration Guide.

AUTOCACHE | NOAUTOCACHE

Specifies whether this stack caches unsuccessful attempts to use SMC communication. Use SMCGLOBAL AUTOCACHE to prevent the overhead of persistent attempts to establish a TCP connection to a specific destination IP address over SMC if previous attempts to the same destination failed.

NOAUTOCACHE

Specifies that this stack does not cache unsuccessful attempts to create an SMC-R or SMC-D link and that existing SMC cache entries are cleared.

AUTOCACHE

Specifies that this stack caches unsuccessful attempts to create an SMC-R or SMC-D link per destination IP address. Subsequent TCP connections to the same destination bypass the use of SMC while the IP address is cached. To clear this cache, specify the NOAUTOCACHE subparameter. Cached entries remain in effect for approximately 20 minutes. AUTOCACHE is the default setting. The AUTOCACHE function is started only when you enable SMC. For more information about enabling SMC, see the description of the GLOBALCONFIG SMCR and SMCD parameters.

AUTOSMC | NOAUTOSMC

Specifies whether this stack monitors inbound TCP connections to dynamically determine whether SMC is beneficial for a local TCP server application. Results of this monitoring influence whether TCP connections to a particular server or port use SMC. AUTOSMC monitoring ensures that TCP connections use the most appropriate communications protocol, either TCP or SMC. You can use the Netstat ALL/-A command to monitor the results of this dynamic monitoring and SMC enablement or disablement. For more information about the Netstat ALL/-A command, see Netstat ALL/-A report in z/OS Communications Server: IP System Administrator's Commands.

Guideline: Configuration of either SMC or NOSMC on the PORT or PORTRANGE statement overrides configuration of the AUTOSMC monitoring function for particular servers. For more information, see PORT statement and PORTRANGE statement.

NOAUTOSMC

Specifies that this stack does not monitor inbound TCP connections to determine whether the connections can benefit from using SMC.

AUTOSMC

Specifies that this stack monitors inbound TCP connections to determine whether the connections can benefit from using SMC. AUTOSMC is the default setting. The AUTOSMC monitoring function is started only when you enable SMC. For more information about enabling SMC, see the description of the GLOBALCONFIG SMCR and SMCD parameters.

SMCR | NOSMCR

Specifies whether this stack uses Shared Memory Communications over Remote Direct Memory Access (RDMA), or SMC-R, for external data network communications. For more information about SMC-R, see Shared Memory Communications over Remote Direct Memory Access in z/OS Communications Server: IP Configuration Guide.

NOSMCR

Specifies that this stack should not use SMC-R for external data network communications. This is the default setting.

SMCR

Specifies that this stack should use SMC-R for external data network communications. Use this parameter to define the "RoCE Express" features that this stack should use for SMC-R communications. You can use this parameter to define additional operational characteristics for SMC-R communications.

Result: If at least one PFID is defined, the AUTOCACHE and AUTOSMC monitoring functions are started if SMCGLOBAL AUTOCACHE and AUTOSMC are configured, either by default or by being explicitly specified.

If you specify the SMCR parameter without any subparameters, you get one of the following results:

• If this is the first time that you specify the SMCR parameter, the following results occur:
  • No Peripheral Component Interconnect® Express (PCIe) function IDs are defined.
  • FIXEDMEMORY and TCPKEEPMININTERVAL subparameters are set to default values.
• If you previously specified the SMCR parameter with subparameters, TCP/IP retains the knowledge of the subparameter settings, even if SMC-R processing is stopped by issuing the VARY TCPIP,,OBEYFILE command with a data set that contains a GLOBALCONFIG NOSMCR parameter. Therefore, a subsequent specification of a GLOBALCONFIG SMCR profile statement resumes SMC-R processing with the previous subparameter settings.

PFID pfid

Specifies the Peripheral Component Interconnect Express (PCIe) function ID (PFID) value for a "RoCE Express" feature that this stack uses. A pfid is a 2-byte hexadecimal value that identifies this TCP/IP stack's representation of a "RoCE Express" feature. z/OS supports values for pfid in the range 0 to FFFF. The maximum supported PFID value depends on the System z® machine level.

Rules:

• You must code at least one PFID subparameter for this stack to use SMC-R communications.
• You can specify a maximum of 16 PFID subparameter values on the SMCR parameter.
• The value for each PFID and PORTNUM pair must be unique.
• When the "RoCE Express" feature operates in a shared RoCE environment, you cannot simultaneously activate a "RoCE Express" feature that uses the same PFID value from different TCP/IP stacks within the same logical partition (LPAR).

PORTNUM num

Specifies the "RoCE Express" port number to use for a particular PFID. Configure each PFID to use only a single port. The port number can be 1 or 2; 1 is the default value.

Rules:

• You do not need to configure PORTNUM for IBM RoCE Express2 features in the TCP/IP profile. The correct port number for these features is configured in the Hardware Configuration Definition (HCD) and is learned by VTAM® and the TCP/IP stack during PFID activation. VTAM ignores the GLOBALCONFIG SMCR PORTNUM value if it differs from the port number configured in the HCD for the IBM RoCE Express2 feature.

• If the 10 GbE RoCE Express feature operates in a dedicated RoCE environment, you can activate either port 1 or port 2 but not both simultaneously for an individual PFID value. If PORTNUM 1 and PORTNUM 2 definitions for the same PFID value are created, the port that is first activated is used.
• If the 10 GbE RoCE Express feature operates in a shared RoCE environment, you can use both port 1 and port 2 on an individual RNIC adapter, but the PFID value that is associated with each port must be different. You cannot simultaneously activate PORTNUM 1 and PORTNUM 2 definitions for the same PFID value.

  For example, if PFID 0013 and PFID 0014 are both defined in HCD to represent the RNIC adapter with PCHID value 0140, you can configure PFID 0013 PORT 1 PFID 0014 PORT 2 to use both ports on the RNIC adapter. However, if you specify PFID 0013 PORT 1 PFID 0013 PORT 2, only the first port that is activated is used.

MTU mtusize

Specifies the maximum transmission unit (MTU) value to be used for a particular PFID. The MTU value can be 1024, 2048, or 4096. The default value is 1024 and can be used for most workloads. If you set the MTU size to 2048 or 4096, you must also enable jumbo frames on all switches in the network path for all peer hosts. For more information about the RoCE maximum transmission unit, see z/OS Communications Server: IP Configuration Guide.

FIXEDMEMORY mem_size

Specifies the maximum amount of 64-bit storage that the stack can use for the send and receive buffers that are required for SMC-R communications. The mem_size value is an integer in the range 30 - 9999, and represents the maximum storage in megabytes of data. The default value is 256 megabytes.

TCPKEEPMININTERVAL interval

This interval specifies the minimum interval that TCP keepalive packets are sent on the TCP path of an SMC-R link.

Rules:

• If a keepalive interval is also specified on the INTERVAL parameter of the TCPCONFIG statement or is set for a specific SMC-R link socket by the TCP_KEEPALIVE setsockopt() option, the largest of the three interval values is used.
• The valid range for this interval is 0-2147460 seconds, and the default is 300 seconds.
• A value of 0 disables TCP keepalive probe packets on the TCP path of an SMC-R link.
• The SO_KEEPALIVE setsockopt() option must be set for keepalive processing to be used.

Result: The TCPKEEPMININTERVAL setting has no effect on keepalive processing for the SMC-R path of an SMC-R link.

For more information about TCP keepalive processing for the TCP path and the SMC-R path of SMC-R links, see TCP keepalive in z/OS Communications Server: IP Configuration Guide.

SYSPLEXMONITOR

Specifies SYSPLEXMONITOR subparameters to configure the operation of the sysplex autonomics function. For more information about connectivity problems in a sysplex, see z/OS Communications Server: IP Configuration Guide.

If the SYSPLEXMONITOR parameter is not specified in the initial TCP/IP profile, then the sysplex autonomics function uses the default values for all SYSPLEXMONITOR subparameters. If the SYSPLEXMONITOR parameter is specified but not all subparameters are specified in the initial TCP/IP profile, then the sysplex autonomics function uses the default values for those SYSPLEXMONITOR subparameters that are not specified. For example, if SYSPLEXMONITOR is specified without RECOVERY or NORECOVERY specified in the initial profile, then the NORECOVERY action is in effect.

Rule: If you specify the GLOBALCONFIG statement in a data set associated with a VARY TCPIP,,OBEYFILE command and the SYSPLEXMONITOR parameter is specified without any subparameters, an informational message is issued and the parameter is ignored.

AUTOREJOIN | NOAUTOREJOIN

Specifies whether TCP/IP should automatically rejoin the TCP/IP sysplex group when a detected problem is relieved after the stack has left the sysplex group.

NOAUTOREJOIN

Do not rejoin the TCP/IP sysplex group when a detected problem is relieved. This is the default value.

AUTOREJOIN

When all detected problems (that caused the stack to leave the sysplex group) are relieved, the stack automatically rejoins the sysplex group and reprocesses the saved VIPADYNAMIC block configuration.

Restriction: AUTOREJOIN cannot be configured when NORECOVERY is configured (or set to the default value).

Guideline: AUTOREJOIN should be used when RECOVERY is configured to allow the stack to rejoin the sysplex group without operator intervention.

DELAYJOIN | NODELAYJOIN

Specify whether TCP/IP should delay joining or rejoining the TCP/IP sysplex group (EZBTCPCS) during stack initialization, or rejoining the sysplex group following a VARY TCPIP,,OBEYFILE command.

NODELAYJOIN

Attempt to join the TCP/IP sysplex group. When specified during stack initialization, the stack attempts to join the sysplex group. This is the default value.

DELAYJOIN

Delay joining the TCP/IP sysplex group and processing any VIPADYNAMIC block or DYNAMICXCF statements during stack initialization until OMPROUTE is started and active.

DYNROUTE | NODYNROUTE

Specifies whether TCP/IP should monitor the presence of dynamic routes over monitored network links or interfaces.

NODYNROUTE

The TCP/IP stack should not monitor the presence of dynamic routes over monitored network links or interfaces. When MONINTERFACE is not configured, this is the default value.

DYNROUTE

The TCP/IP stack should monitor the presence of dynamic routes over monitored network links or interfaces.

Tip: This level of monitoring is useful in detecting problems that OMPROUTE is having in communicating with other routing daemons on the selected network interfaces.

If no dynamic routes are present in the TCP/IP stack from that network, a specific interface attached to that network might not be active or routers attached to that network might not be active or healthy. In either case, when these conditions are detected, they provide a reasonable indication that client requests for DVIPAs or distributed DVIPAs owned by this TCP/IP stack might not reach this stack over that interface. These checks can help further qualify the state of a network interface on this TCP/IP stack. When the MONINTERFACE parameter is specified, This is the default value.

Restriction: DYNROUTE cannot be specified when NOMONINTERFACE is configured (or is the default value).

Rules:

• Specify DYNROUTE only when OMPROUTE is configured and started; otherwise, the TCP/IP stack might be forced to leave the TCP/IP sysplex group if RECOVERY is coded.
• If DYNROUTE is specified, also specify DELAYJOIN to avoid a scenario where the TCP/IP stack leaves the TCP/IP sysplex group before OMPROUTE is started.

NOJOIN

Specifies that the TCP/IP stack should not join the TCP/IP sysplex group (EZBTCPCS) during stack initialization. If this value is specified, the TCP/IP stack does not process any VIPADYNAMIC block or DYNAMICXCF statements. Any other GLOBALCONFIG SYSPLEXMONITOR parameter settings (configured or default) are ignored, and the settings are saved in case you want the TCP/IP stack to join the sysplex group at a later time.

If you subsequently issue a VARY TCPIP,,SYSPLEX,JOINGROUP command, the NOJOIN setting is overridden and the saved GLOBALCONFIG SYSPLEXMONITOR parameter settings become active. For example, if you configure NOJOIN and DELAYJOIN, DELAYJOIN is initially ignored. If you subsequently issue a V TCPIP,,SYSPLEX,JOINGROUP command, NOJOIN is overridden, DELAYJOIN becomes active, and the stack joins the sysplex group if OMPROUTE is initialized.

Any sysplex-related definitions within the TCP/IP profile, such as VIPADYNAMIC or IPCONFIG DYNAMICXCF statements, are not processed until the TCP/IP stack joins the sysplex group.

Restriction: You can specify this parameter only in the initial profile; you cannot specify it when you issue a VARY TCPIP,,OBEYFILE command.

MONINTERFACE | NOMONINTERFACE

NOMONINTERFACE

The TCP/IP stack should not monitor the status of any network links or interfaces. This is the default.

MONINTERFACE

The TCP/IP stack should monitor the status of specified network link or interfaces. The interfaces or links being monitored are those that are configured with the MONSYSPLEX keyword on the LINK or INTERFACE statement. See Summary of DEVICE and LINK statements or Summary of INTERFACE statements for more information.

Guideline: This level of monitoring can further qualify the health of the TCP/IP stack by ensuring that at least one key interface is active and available. This option can be useful in environments where the dynamic XCF interface is not configured as an alternate network path for this stack (for example, where no dynamic routes are advertised over dynamic XCF interfaces and no static or replaceable static routes are defined over those interfaces).

RECOVERY | NORECOVERY

Specify the action to be taken when a sysplex problem is detected.

NORECOVERY

When a problem is detected, issue messages regarding the problem but take no further action. This is the default value.

RECOVERY

When a problem is detected, issue messages regarding the problem, leave the TCP/IP sysplex group, and delete all DVIPA resources owned by this stack. As allowed by a configuration with backup capabilities, other members of the TCP/IP sysplex automatically take over the functions of this member that was removed from the TCP/IP sysplex group.

Recovery is the preferred method of operation because other members of the TCP/IP sysplex can automatically take over the functions of a member with no actions needed by an operator. IBM Health Checker for z/OS enhancements can be used to check whether the RECOVERY parameter has been specified when the IPCONFIG DYNAMICXCF or IPCONFIG6 DYNAMICXCF parameters have been specified. For more details about IBM Health Checker for z/OS enhancements, see the IBM Health Checker for z/OS enhancements information in the z/OS Communications Server: IP Diagnosis Guide.

TIMERSECS seconds

Time value specified in seconds. Determines how quickly the sysplex monitor reacts to problems with needed sysplex resources. Valid values are in the range 10 - 3600 seconds. The default value is 60 seconds.

SYSPLEXWLMPOLL seconds

Time value specified in seconds. Determines how quickly the sysplex distributor and its target servers poll WLM for new weight values. A short time results in quicker reactions to changes in target status. Valid values are in the range is 1 - 180 seconds. The default value is 60 seconds.

TCPIPSTATISTICS | NOTCPIPSTATISTICS

NOTCPIPSTATISTICS

Indicates that the TCP/IP counter values are not to be written to the output data set designated by the CFGPRINT JCL statement.

The NOTCPIPSTATISTICS parameter is confirmed by the message:

EZZ0613I TCPIPSTATISTICS IS DISABLED

This is the default value.

TCPIPSTATISTICS

Prints the values of several TCP/IP counters to the output data set designated by the CFGPRINT JCL statement. These counters include number of TCP retransmissions and the total number of TCP segments sent from the MVS™ TCP/IP system. These TCP/IP statistics are written to the designated output data set only during termination of the TCP/IP address space.

The TCPIPSTATISTICS parameter is confirmed by the message:

EZZ0613I TCPIPSTATISTICS IS ENABLED

The SMFCONFIG TCPIPSTATISTICS parameter (see SMFCONFIG statement) serves a different purpose. It requests that SMF records of subtype 5 containing TCP/IP statistics be created. These statistics are recorded in SMF type 118 or 119, subtype 5 records.

WLMPRIORITYQ | NOWLMPRIORITYQ

Specifies whether OSA-Express QDIO write priority values should be assigned to packets associated with WorkLoad Manager service classes, and to forwarded packets. See the information about prioritizing outbound OSA-Express data using the WorkLoad Manager service class in z/OS Communications Server: IP Configuration Guide .

NOWLMPRIORITYQ

Specifies that OSA-Express QDIO write priority values should not be assigned to packets associated with WorkLoad Manager service class values or to forwarded packets. This value is the default.

WLMPRIORITYQ

Specifies that OSA-Express QDIO write priority values should be assigned to packets associated with WorkLoad Manager service class valuesand to forwarded packets.

You can assign specific OSA-Express QDIO write priority values by using the IOPRIn subparameters, where n is one or more of the priority values in the range 1 - 4. For each subparameter, you can specify a control value in the range 0 - 6, which correlates to the WLM services classes, or you can specify the keyword FWD for forwarded packets. WLM supports a service class for the SYSTEM value, but this value is always assigned the OSA-Express QDIO write priority 1 and its assignment cannot be configured; therefore, a control value is not assigned for the SYSTEM WLM service class.

You can use the default assignment by specifying the WLMPRIORITYQ parameter without any IOPRIn subparameters. See the description of the default_control_values variable in this topic to understand the default assignment.

control_values

Control values are used to represent the WLM service classes and forwarded packets. Valid control values are the digits 0 - 6, which represent WLM service classes, or the keyword FWD, which represents forwarded packets. Table 1 identifies the control value, the type of packet that it represents, and the default QDIO priority assigned to the packet:

Table 1. WLM Service Class Importance Levels

Control value	Type of packet	Default QDIO priority
0	System-defined service class (SYSSTC) used for high-priority started tasks	1
1	User-defined service classes with importance level 1	2
2	User-defined service classes with importance level 2	3
3	User-defined service classes with importance level 3	3
4	User-defined service classes with importance level 4	4
5	User-defined service classes with importance level 5	4
6	User-defined service classes associated with a discretionary goal	4
FWD	Forwarded packets	4

default_control_values

When the WLMPRIORITYQ parameter is specified without any IOPRIn subparameters, then the OSA-Express QDIO write priority values are assigned as shown Table 1.

IOPRIn control_values

Use the IOPRIn subparameters to correlate control values with specific OSA-Express QDIO write priority values. You can use one or more of the following subparameter keywords:

• IOPRI1
• IOPRI2
• IOPRI3
• IOPRI4

Each subparameter keyword corresponds to one of the four QDIO write priority values, 1 through 4. Each subparameter can be specified once on a GLOBALCONFIG statement.

control_values

Indicates the type of packet to which the QDIO write priority value should be assigned. Valid values are:

Digits 0 - 6

Causes the QDIO write priority value that is specified by the IOPRIn subparameter to be assigned to packets associated with the WLM service classes represented by the control value.

FWD

This keyword causes the QDIO write priority value indicated by the IOPRIn subparameter to be assigned to forwarded packets.

Rules:

• IOPRIn must be followed by one or more priority level releases.
• You can specify more than one control value for an IOPRIn subparameter. Each control value must be separated by at least one blank.
• A specific control value can be specified only once in the set of IOPRIn subparameters on a GLOBALCONFIG statement.
• If any control value is not explicitly specified on an IOPRIn subparameter, then the associated packets are assigned a default QDIO write priority 4.

In the following example, QDIO priority 1 is assigned to packets associated with control values 0 and 1, QDIO priority 2 is assigned to packets associated with control value 2 and to forwarded packets, QDIO priority 3 is assigned to packets associated with control values 3 and 4, and QDIO priority 4 is assigned to packets associated with control values 5 and 6.

WLMPRIORITYQ  IOPRI1 0 1
              IOPRI2 2 FWD
              IOPRI3 3 4
              IOPRI4 5 6

XCFGRPID group_id

This parameter is needed only if you want subplexing. If specified, the value provides a 2-digit suffix that is used in generating the XCF group name that the TCP/IP stack joins. Valid values are in the range 2 - 31. The group name is EZBTvvtt, where the vv value is the VTAM XCF group ID suffix (specified with the XCFGRPID VTAM start option) and the tt value is the group_id value supplied on this parameter, used as a 2-digit value converted to character format. If no VTAM XCF group ID suffix was specified, the group name is EZBTCPtt. If no VTAM XCF group ID suffix and no TCP XCF group ID suffix is specified, the group name is EZBTCPCS.

These characters are also used as a suffix for the EZBDVIPA and EZBEPORT structure names, in the form EZBDVIPAvvtt and EZBEPORTvvtt. If no VTAM XCF group ID suffix was specified, the structure names are EZBDVIPA01tt and EZBEPORT01tt.

If XCFGRPID is not specified, the XCF group name is EZBTvvCS and the structure names are EZBDVIPAvv and EZBEPORTvv. If no VTAM XCF group id suffix was specified, the group name is EZBTCPCS and the structure names are EZBDVIPA and EZBEPORT.

Restriction: XCFGRPID can be specified only in the initial profile.

This allows multiple TCP/IP stacks to join separate Sysplex groups and access separate Coupling Facility structures, isolating sets of TCP/IP stacks into subplexes with XCF communication only with other TCP/IP stacks within the same subplex.

If HiperSockets is supported on this system, the IQDVLANID parameter, on the GLOBALCONFIG statement, must be specified if XCFGRPID is specified. Stacks on the same CPC using the same HiperSockets CHPID that specify the same XCFGRPID value must specify the same IQDVLANID value.

Stacks on the same CPC using the same HiperSockets CHPID specifying different XCFGRPID values must specify different IQDVLANID values. This allows partitioning of connectivity across the Sysplex to include partitioning of connectivity across HiperSockets.

Creating TCP/IP and VTAM subplexes can add some complexity to your VTAM and TCP/IP configurations and requires careful planning. Before setting this parameter you should review the information about setting up a subplex in the z/OS Communications Server: IP Configuration Guide.

ZERT|NOZERT

Specifies whether the z/OS Encryption Readiness Technology (zERT) will monitor TCP and Enterprise Extender traffic on this TCP/IP stack.

NOZERT

Indicates that the TCP and Enterprise Extender traffic will not be monitored by zERT. This is the default value.

ZERT

Indicates that TCP and Enterprise Extender traffic will be monitored by zERT. The zERT discovery function, which monitors and collects information about security sessions on a per-TCP- and per-EE connection basis, is always enabled when ZERT is specified. In addition, you can specify subparameters to enable other zERT functions.

AGGregation

Indicates that the zERT aggregation function is enabled. zERT aggregation uses the information collected by zERT discovery to create summarized security session information. The zERT aggregation information is reported at fixed intervals of time, as defined by the configured SMF interval value. For more details on the zERT aggregation function, see What does zERT aggregation collect? in z/OS Communications Server: IP Configuration Guide.

NOAGGregation

Indicates that the zERT aggregation function is disabled. This is the default.

Note that additional configuration is required to specify where zERT data is to be written. For more information of those configuration parameters, see SMFCONFIG statement and NETMONITOR statement. Separate SMFCONFIG controls exist for zERT discovery records and for zERT aggregration records.

See the Steps for modifying in this topic for details about changing this parameter while the TCP/IP stack is active.

ZIIP

Specifies subparameters that control whether TCP/IP displaces CPU cycles onto a System z9® Integrated Information Processor (zIIP). You must specify at least one subparameter. If the ZIIP parameter is specified with no subparameters, an informational message is issued and the parameter is ignored.

IPSECURITY | NOIPSECURITY

Specifies whether TCP/IP should displace CPU cycles for IPSec workload to a zIIP. For more information about this function, see the Additional IPSec assist using z9® Integrated Information Processor (zIIP IP security) topic in z/OS Communications Server: IP Configuration Guide.

NOIPSECURITY

Do not displace CPU cycles for IPSec workload to a zIIP. This is the default value.

IPSECURITY

When possible, displace CPU cycles for IPSec workload to a zIIP. Workload Manager (WLM) definitions should be examined and possible changes made before this option is used. See the more detailed description in the additional IPSec Assist by way of z9 Integrated Information Processor (zIIP IPSECURITY) topic in z/OS Communications Server: IP Configuration Guide.

IQDIOMULTIWRITE | NOIQDIOMULTIWRITE

Specifies whether TCP/IP should displace CPU cycles for large outbound TCP messages that are typically created by traditional streaming work loads such as file transfer, and interactive web-based service workloads such as XML or SOAP. The TCP/IP outbound message must be at least 32KB in length before the write processing is off-loaded to an available zIIP specialty engine. For more information about this function, see the information about HiperSockets multiple write assist with IBM zIIP in z/OS Communications Server: IP Configuration Guide.

NOIQDIOMULTIWRITE

Do not displace CPU cycles for the writing of large TCP outbound messages to a zIIP. This is the default value.

IQDIOMULTIWRITE

When possible, displace CPU cycles for the writing of large TCP outbound messages to a zIIP.

Rules:

• You cannot specify IQDIOMULTIWRITE as a ZIIP parameter when GLOBALCONFIG IQDMULTIWRITE is not configured. When GLOBALCONFIG IQDMULTIWRITE is not configured, HiperSockets interfaces do not use the multiple write support.
• Only large TCP outbound messages (32KB and larger) are processed on the zIIP specialty engine.
• The TCP message must be originating from this node. Routed TCP messages are not eligible for zIIP assistance.

Tip: These ZIIP parameters apply to pre-defined HiperSockets interfaces, as well as HiperSockets interfaces that are created and used by dynamic XCF definitions.

Steps for modifying

To modify parameters for the GLOBALCONFIG statement, you must respecify the statement with the new parameters.

The following list describes how to modify individual parameters:

AUTOIQDC and NOAUTOIQDC

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from AUTOIQDC to NOAUTOIQDC, no new dynamic IQDC interfaces will be activated. All active dynamic IQDC interfaces will remain active and available for use. To stop existing interfaces, you must issue a V TCPIP,,STOP command for each active IQDC interface.

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from NOAUTOIQDC to AUTOIQDC, active OSD interfaces are not affected, but the stack will attempt to activate a dynamic IQDC interface on any subsequent OSD activations.

AUTOIQDX and NOAUTOIQDX

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from AUTOIQDX to NOAUTOIQDX, no new dynamic IQDX interfaces will be activated. All active dynamic IQDX interfaces will remain active and available for use. To stop existing interfaces, you must issue a V TCPIP,,STOP command for each active IQDX interface.

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from NOAUTOIQDX to AUTOIQDX, active OSX interfaces are not affected, but the stack will attempt to activate a dynamic IQDX interface on any subsequent OSX activations.

EXPLICITBINDPORTRANGE and NOEXPLICITBINDPORTRANGE

If you specified the EXPLICITBINDPORTRANGE parameter and then you change to the NOEXPLICITBINDRANGE parameter, then the stack stops allocating more ports from the EXPLICITBINDPORTRANGE pool. However, the existing active range for the EXPLICITBINDPORTRANGE pool in the coupling facility is unaffected unless you are changing the parameter on the last stack in the sysplex using this function.

If you specified the NOEXPLICITBINDPORTRANGE parameter and then you change to the EXPLICITBINDPORTRANGE parameter, then a range of ports used for the EXPLICITBINDPORTRANGE pool is set. The stack uses ports from that pool for explicit bind() requests to the IPv4 INADDR_ANY address, or to the IPv6 unspecified address (in6addr_any), and port 0. If the range specified on the EXPLICITBINDPORTRANGE parameter is different from the currently active range for the EXPLICITBINDPORTRANGE pool in the coupling facility, the new range replaces that value.

Changing the starting port (1st_port), the number of ports (num_ports), or both for the EXPLICITBINDPORTRANGE parameter changes the port numbers in the pool of ports that is guaranteed to be unique across the sysplex for future port allocation

Guidelines:

• Changing the range specified on the EXPLICITBINDPORTRANGE parameter of the GLOBALCONFIG statement affects every stack in the sysplex that has configured a GLOBALCONFIG EXPLICITBINDPORTRANGE value. Future port allocations for all such stacks use the new port range.
• Ports in the EXPLICITBINDPORTRANGE range are usually assigned to a stack in blocks of 64 ports. When expanding the range, use multiples of 64 multiplied by the number of stacks that use a GLOBALCONFIG EXPLICITBINDPORTRANGE configuration.

IQDMULTIWRITE and NOIQDMULTIWRITE

If this parameter is changed with the VARY TCPIP,,OBEYFILE command, the new value does not take effect for any active HiperSockets (iQDIO) interfaces. For a change in this parameter to take effect for an active iQDIO interface, you must stop and restart both the IPv4 and IPv6 interface for the change to be effective.

IQDVLANID

If the IQDVLANID parameter was previously specified and you modify that value, then you must stop and restart the TCP/IP stack for the change to take effect.

MLSCHKTERMINATE

You cannot change the MLSCHKTERMINATE parameter to the NOMLSCHKTERMINATE parameter when the RACF® option MLSTABLE is on and the RACF option MLQUIET is off. You can always change the NOMLSCHKTERMINATE parameter to the MLSCHKTERMINATE parameter, but this change is ignored if the value is specified in the data set of a VARY TCPIP,,OBEYFILE command and consistency errors are detected at the same time.

SEGMENTATIONOFFLOAD and NOSEGMENTATIONOFFLOAD

If this parameter is changed with the VARY TCPIP,,OBEYFILE command, the new value does not take effect for any active OSA-Express QDIO interfaces. For a change in these parameters to take effect, all the OSA-Express QDIO interfaces that support TCP segmentation offload must be stopped and restarted.

SMCD and NOSMCD

• If SMC-D support is not enabled, you can specify the SMCD parameter in a VARY TCPIP,,OBEYFILE command data set to activate the support.
  Result: TCP/IP retains knowledge of the last set of SMCD subparameter values that are specified on the GLOBALCONFIG statement, even if GLOBALCONFIG NOSMCD was specified subsequently. If you issue a VARY TCPIP,,OBEYFILE command with GLOBALCONFIG SMCD specified, TCP/IP uses the last saved set of SMCD subparameters, unless new values for the subparameters are coded on the GLOBALCONFIG SMCD statement. Therefore, you can temporarily stop SMC-D processing by issuing a VARY TCPIP,,OBEYFILE command with GLOBALCONFIG NOSMCD specified. Then you can resume SMC-D processing with the previous subparameter settings by issuing a second VARY TCPIP,,OBEYFILE command with just GLOBALCONFIG SMCD specified. Specifying the SMCD parameter also causes the AUTOCACHE function and AUTOSMC monitoring function to be restarted if the SMCGLOBAL AUTOCACHE and AUTOSMC parameters are enabled.
• If SMC-D support is enabled, you can specify the NOSMCD parameter in a VARY TCPIP,,OBEYFILE command data set to deactivate the support.
  • No new TCP connections that use SMC-D processing will be established.
  • Existing TCP connections that use SMC-D will continue to use SMC-D processing.
  • The AUTOCACHE function will be stopped if SMC-R processing is not active.
  • The AUTOSMC monitoring function will be stopped if SMC-R processing is not active.

SMCGLOBAL

AUTOCACHE and NOAUTOCACHE

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from AUTOCACHE to NOAUTOCACHE, the following actions occur:

• Destination IP addresses cached not to use SMC will be deleted from the cache.
• The stack will not cache unsuccessful attempts to create an SMC-R or SMC-D link per destination IP address for new TCP connections.

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from NOAUTOCACHE to AUTOCACHE, the SMCGLOBAL AUTOCACHE function is enabled.

SMCR and NOSMCR

• If SMCR support is not enabled, you can specify the SMCR parameter in a VARY TCPIP,,OBEYFILE command data set to activate the support.
  Result: TCP/IP retains knowledge of the last set of SMCR subparameter values that are specified on the GLOBALCONFIG statement, even if GLOBALCONFIG NOSMCR was specified subsequently. If you issue a VARY TCPIP,,OBEYFILE command with GLOBALCONFIG SMCR specified, TCP/IP uses the saved last set of SMCR subparameters, unless new values for the subparameters are coded on the GLOBALCONFIG SMCR statement. This allows you to temporarily stop SMC-R processing by issuing a VARY TCPIP,,OBEYFILE command with GLOBALCONFIG NOSMCR specified. Then you can resume SMC-R processing with the previous subparameter settings by issuing a second VARY TCPIP,,OBEYFILE command with just GLOBALCONFIG SMCR specified.Specifying the SMCR parameter also causes the AUTOCACHE function and AUTOSMC monitoring function to be restarted if the SMCGLOBAL AUTOCACHE and AUTOSMC parameters are enabled.
• If SMCR support is enabled, you can specify the NOSMCR parameter in a VARY TCPIP,,OBEYFILE command data set to deactivate the support.
  • No new TCP connections that use SMC-R processing will be established.
  • Existing TCP connections that use SMC-R will continue to use SMC-R processing.
  • The AUTOCACHE function will be stopped if SMC-D processing is not active.
  • The AUTOSMC monitoring function will be stopped if SMC-D processing is not active.
• You cannot change the SMCR PFID parameter values that are currently configured when the associated "RoCE Express" interfaces are active. To change the SMCR PFID parameter values that are currently configured, you must perform the following steps in order:
  1. Stop the associated "RoCE Express" interface.
  2. Issue the VARY TCPIP,,OBEYFILE command with the new PFID values that are coded in the command data set. The new PFID values replace the existing PFID values.
• To add PFID values when you have one or more PFID values coded, you must specify the existing PFID values and the additional PFID values on the SMCR parameter in the VARY TCPIP,,OBEYFILE command data set. Existing PFID values and any existing "RoCE Express" interfaces are not affected.

SYSPLEXMONITOR

AUTOREJOIN and NOAUTOREJOIN

If you change NOAUTOREJOIN to AUTOREJOIN after the stack has left the sysplex and before the problem that caused it to leave has been relieved, the stack automatically rejoins the sysplex group when the problem is relieved. However, if you change NOAUTOREJOIN to AUTOREJOIN after the problem that caused the stack to leave the group has been relieved, you must issue a VARY TCPIP,,SYSPLEX,JOINGROUP command to cause the stack to rejoin the sysplex.

DELAYJOIN and NODELAYJOIN

Changing from DELAYJOIN to NODELAYJOIN while the TCP/IP stack is in the process of delaying joining the sysplex group because OMPROUTE is not active causes the TCP/IP stack to immediately join the sysplex group.

Changing from NODELAYJOIN to DELAYJOIN has no immediate effect until the TCP/IP stack leaves the sysplex group and then attempts to rejoin while OMPROUTE is not active.

SYSPLEXWLMPOLL

You can change the polling rate for WLM values while the TCP/IP stack is active. In order for the change to be effective, you should change the polling rate on all stacks that participate in sysplex distribution (all active distributing stacks, any backup stacks that might take over distribution, and all target stacks).

WLMPRIORITYQ

If you specify WLMPRIORITYQ with the VARY TCPIP,,OBEYFILE command, the IOPRIn values are changed to the values specified for the default_control_values variable. The new values take effect immediately for all workloads influenced by this function.

WLMPRIORITYQ IOPRIn control_values

If you specify this parameter with the VARY TCPIP,,OBEYFILE command, and you do not specify all the control values, the QDIO priority 4 is assigned to packets associated with all control values omitted. The new values immediately take effect for all workloads influenced by this function.

Rule: You cannot modify individual IOPRIn control values. If you attempt to modify IOPRIn control values, but you specify only those control values that you want to modify, then the QDIO priority 4 is assigned to packets that are associated with any control values that you omitted.

XCFGRPID

For a change in this parameter to take effect, you must stop and restart the TCP/IP stack.

ZERT|NOZERT

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from ZERT to NOZERT then all ZERT discovery and aggregation functions stop. In addition, all zERT SMF recording stops and all collected data is discarded.

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from NOZERT to ZERT then zERT discovery will begin for new TCP and Enterprise Extender connections only. TCP and Enterprise Extender connections that existed before zERT discovery was enabled will not be monitored. The zERT aggregation function remains disabled.

If you use the VARY TCPIP,,OBEYFILE command to change this parameter from NOZERT to ZERT AGGREGATION, then both the zERT discovery and aggregation functions will begin for new TCP and Enterprise Extender connections only. TCP and Enterprise Extender connections that existed before zERT was enabled will not be monitored, nor will they be included in the aggregation function statistics.

If you use the VARY TCPIP,,OBEFYFILE command to change the subparameter from ZERT NOAGGREGATION to ZERT AGGREGATION, then zERT aggregation will begin for new TCP and Enterprise Extender connections only. TCP and Enterprise Extender connections that existed before zERT aggregation was enabled will not be included in the summarized data. The zERT discovery function is not affected.

If you use the VARY TCPIP,,OBEYFILE command to change the subparameter from ZERT AGGREGATION to ZERT NOAGGREGATION, then the zERT aggregation function stops, although zERT discovery continues. All zERT summary information is discarded and one final set of zERT summary records is generated.

Related topics

• SMFCONFIG statement
• For more information about TCP/IP networking in a multilevel-secure environment, see the security information in z/OS Communications Server: IP Configuration Guide.