GLOBALCONFIG statement

Parameters

ADJUSTDVIPAMSS AUTO | ALL | NONE

Specifies sub parameters 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.

AIASSIST

Specifies the configuration for the following AI-powered TCP/IP instance features.

BATCHOUTBOUND | NOBATCHOUTBOUND

NOBATCHOUTBOUND

Do not configure the TCP/IP instance for AI-powered network outbound packet batching. This is the default value.

BATCHOUTBOUND

Configure the TCP/IP instance for AI-powered network outbound packet batching. Information about the outbound network activity for all Network Express and OSA-Express network interfaces is recorded into an EzNoSQL database, and used for training the AI model. Predictions from the AI model are used to assist the TCP/IP instance in determining how outbound packet batching occurs.

Guidelines:

• Configure the AI Framework for z/OS using the z/OSMF Configuring network outbound packet batching for Communications Server workflow before configuring the TCP/IP instance for this AI assisted feature. See Infusing AI into IBM z/OS for more information.
• To train and enable AI-powered network outbound packet batching for applicable network interfaces, use the AI Control Interface (AICI) component of the AI Framework for z/OS.

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. 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 OSA interface statements. The OSA interface statement must also have been defined with the virtual MAC (VMAC) parameter to request an OSA-generated VMAC address.

The OSA 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 OSA 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 TCP/IP in an ensemble.

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® 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.

POLICYREQUIRED YESIFTTLS | YES | NO

Specifies sub parameters to control the timing of the output of message EZD1314I TCP/IP AND EXTENDED SERVICES ARE NOW INITIALIZED. The message will be generated at a different time depending on the option that is specified.

YESIFTTLS

If AT-TLS is configured in the TCP/IP profile (TCPCONFIG TTLS), the stack will wait for Policy Agent processing to complete before issuing EZD1314I. If AT-TLS is not configured in the profile, the stack will issue EZD1314I without waiting for Policy Agent. This is the default option.

YES

The stack will wait for Policy Agent processing to complete before issuing EZD1314I.

Tip: This option should be considered if you know subsystems/processes are reliant on policies other than, or in addition to, AT-TLS (IPSec, QoS, IDS, etc.)

NO

The stack will issue EZD1314I without waiting for the Policy Agent to process policies.

Tip: This option should be considered if you do not require any policies to be installed to the stack before continuing operations.

IKEDREQUIRED YESIFDYNIPSEC | NO

Specifies sub parameters to control the timing of the output of message EZD1314I TCP/IP AND EXTENDED SERVICES ARE NOW INITIALIZED. Depending on the option specified, IKED initialization may or may not be required before EZD1314I is output.

YESIFDYNIPSEC

If all of the following conditions are met, the stack will wait for IKED initialization before issuing EZD1314I:

• IPSECURITY is configured on the IPCONFIG statement of the TCP/IP profile.
• POLICYREQuired YESIFTTLS (TCPCONFIG TTLS) or POLICYREQuired YES is configured on the GLOBALCONFIG statement of the TCP/IP profile.
• IPSec policy includes dynamic filter rules.

Otherwise the stack will not wait for IKED initialization before issuing EZD1314I.

This is the default option.

NO

The stack will not wait for IKED initialization before issuing EZD1314I.

Tip: This option should be considered if you do not require IKED to be active before continuing operations. An example of this would be when the only IPSec protection required for this stack is for target-only DVIPAs.

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 features. TCP segmentation offload support transfers the overhead of segmenting outbound data into individual TCP packets to OSA devices whose features support this function. Offloading segmentation of streaming-type workloads reduces CPU use and increases throughput.

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 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 feature.

SMCD | NOSMCD

Specifies whether this stack uses Shared Memory Communications - Direct Memory Access (SMC-D). For more information about SMC-D, see Shared Memory Communications - Direct Memory Access 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 sub parameters, you get one of the following results:

• If you specify the SMCD parameter for the first time, the FIXEDMEMORY and TCPKEEPMININTERVAL sub parameters are set to default values.
• If you previously specified the SMCD parameter with sub parameters, TCP/IP retains the knowledge of the sub parameter 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 sub parameter 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.

SYSTEMEID | NOSYSTEMEID

Specifies whether or not a system EID will be generated for use with SMC-Dv2. The system EID (SEID) is an internal EID that is built by the SMC-Dv2 software stack that has a predefined, constant value representing the CPC that the OS is executing on. The IBM Z® SEID is a globally unique ID representing an IBM CPC (type and serial are encoded within the SEID). The SEID format is consistent with the UEID (32-character bytes) format. The SEID is only applicable to SMC-Dv2.

NOSYSTEMEID

The SEID will not be generated and SMC-Dv2 will only be enabled if SMCEID is configured. This is the default.

SYSTEMEID

The SEID will be generated for use with SMC-Dv2. In cases where SMCEID is not configured, this option also activates SMC-Dv2 functionality.

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 sub parameter. 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 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.

SMCPERMIT/ENDSMCPERMIT

Specifies the SMC filter that allows SMC negotiation with peers within the listed TCP/IP address(es)/subnet(s). If the user implements the SMCPERMIT, only the defined IP address/subnets will be allowed to participate in SMC by including the TCP/IP SMCR option in the TCP 3-way handshake. This filter applies to both the z/OS client and server and is applied to the peer host’s TCP/IP connection IP address/subnet. When Permit filters are defined, one of the filters must match the peer’s IP address/subnet to allow SMC negotiation to proceed.

SMCPERMIT

Allows the users to specify up to 256 IP addresses/subnets/prefixes each for IPv4 and IPv6 categories. If SMCPERMIT/ENDSMCPERMIT is configured as an empty block with no IP addresses specified or specified with the keyword ALL, then SMC negotiation will be allowed to proceed for all IP addresses/subnets.

Specifying SMC filters is optional. When not specified, the default will be the same as if "SMCPERMIT ALL ENDSMCPERMIT" is specified.

IPv4Addr

The destination IPv4 address. This can be a TCP/IP address or subnet. Users can specify up to 256 IP addresses.

NumMaskBits

An integer value in the range 1 - 32 that represents the number of leftmost significant bits for the address mask of an IPv4 address. If not specified, it will be defaulted to 32.

IPv6Addr

The destination IPv6 address. For IPv6, the destination address can be a host, prefix or default address. In addition, multiple routes having an identical destination IP address and address mask can be specified.

PrefixLength

An integer value in the range 1 - 128 representing the number of bits in the ipaddr value that are used to determine the destination address of the IPv6 address. If not specified, it will be defaulted to 128.

SMCEXCLUDE/ENDSMCEXCLUDE

Specifies the SMC filter that prevents SMC negotiation with peers within the listed TCP/IP address(es)/subnet(s). If the user implements the SMCEXCLUDE, then the defined IP address/subnets will not be allowed to participate in SMC. When the SMCEXCLUDE list is empty or SMCEXCLUDE is not specified, then there will be no entries on the Exclude list (So no IP addresses/subnets/prefixes will be explicitly excluded). This filter applies to both the z/OS client and server. The processing of filters specified in SMCEXCLUDE takes precedence over those specified in SMCPERMIT when there is an overlap in the IP addresses specified.

SMCEXCLUDE

Allows the users to specify up to 256 IP addresses/subnets/prefixes each for IPv4 and IPv6 categories. If SMCEXCLUDE/ENDSMCEXCLUDE is configured as an empty block with no IP addresses specified, SMC negotiation will be allowed to proceed for all IP addresses/subnets.

Specifying SMC filters is optional. When not specified, the default will be the same as if an empty SMCEXCLUDE/ENDSMCEXCLUDE block is specified.

IPv4Addr

The destination IPv4 address. This can be a TCP/IP address or subnet. Users can specify up to 256 IP addresses.

NumMaskBits

An integer value in the range 1 - 32 that represents the number of leftmost significant bits for the address mask of an IPv4 address. If not specified, it will be defaulted to 32.

IPv6Addr

The destination IPv6 addresses. For IPv6, the destination address can be a host, prefix or default address. In addition, multiple routes having an identical destination IP address and address mask can be specified.

PrefixLength

An integer value in the range 1 - 128 representing the number of bits in the ipaddr value that are used to determine the destination address of the IPv6 address. If not specified, it will be defaulted to 128.

SMCEID/ENDSMCEID

The SMCEID/ENDSMCEID block allows the users to specify up to 4 user-defined EIDs (UEIDs). The presence of any UEIDs will enable SMCv2. For example, if SMCEID/ENDSMCEID is configured as an empty block with no UEIDs specified, SMCv2 will not be enabled. Similarly, if SMCv2 is already enabled, and then SMCEID/ENDSMCEID is configured as an empty block with no UEIDS specified, this will disable SMC-Rv2; it will also disable SMC-Dv2 as long as the SYSTEMEID keyword was not configured under the SMCD section of the profile.

Restriction:

SMC-Dv2 supports both IPv4 and IPv6. SMC-Rv2 supports IPv4 only.

SMCEID

Allows for up to 4 EIDs to be configured. If any EIDs are configured, SMCv2 functionality will be enabled. By default, SMCEID is not configured and SMCv2 is disabled.

user_EID_values

A user defined identifier that represents a group of systems that are allowed to communicate using SMC over multiple IP subnets using the SMC V2 protocol. The EID is a user defined, fixed length, 32-byte character (ASCII 4) field defined within the SMCv2 CLC messages supporting any valid combination of valid ASCII characters (ASCII 4) with no spaces or blanks. Below are the rules to follow when configuring a user EID.

Rules:

• The characters are capitalized alphanumeric in addition to allowing both the "." and "-" special characters (A-Z,0-9,-,.).
• A UEID however, may not start with any special character.
• A UEID might not have consecutive "." characters.
• UEIDs should be globally unique. IBM provides guidelines for creating globally unique EIDs.

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 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 sub parameters, 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 sub parameters are set to default values.
• If you previously specified the SMCR parameter with sub parameters, TCP/IP retains the knowledge of the sub parameter 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 sub parameter settings.

PFID pfid

Specifies the Peripheral Component Interconnect Express (PCIe) function ID (PFID) value for a RoCE feature that this stack uses. PFIDs specified here will allow for SMC-Rv1 communications. (For multiple IP subnet support (SMC-Rv2 communications), you must specify the SMC-Rv2 parameters (PFID, SMCRIPADDR) on the OSA INTERFACE statement.) A pfid is a 2-byte hexadecimal value that identifies this TCP/IP stack's representation of a RoCE supports values for pfid in the range 0 to FFFF. The maximum supported PFID value depends on the System z® machine level.

The PFID configured on the OSA INTERFACE statement is used for SMC-Rv2 communications. When SMC-Rv1 communications are also required, configuring the same PFID on the GLOBALCONFIG statement enables this PFID for SMC-Rv1. However, the VLAN definition for the INTERFACE statement impacts the SMC-Rv1 communications capability as follows:

• When VLAN is configured on the INTERFACE statement (trunk mode), this PFID can also be used for SMC-Rv1 communications. For this case, configuring this same PFID on the GLOBALCONFIG statement enables SMC-Rv1 connectivity.
• When VLAN is not configured on the INTERFACE statement (access mode), this PFID can conditionally be used for SMC-Rv1 connectivity described as follows:
  • When the OSA interface and all RoCE PFIDs on the PNET that are to be used for SMC-Rv1 connectivity are all defined in the associated switch ports with a single VLAN ID, SMC-Rv1 connectivity is supported. For this case, the PFID should be configured on the GLOBALCONFIG statement.
    Restriction: When the OSA interface and all RoCE PFIDs on the PNET that are to be used for SMC-Rv1 connectivity are not defined in the associated switch ports with a single VLAN ID, SMC-Rv1 connectivity is not supported. When enabling SMC-Rv2 communications in this access mode configuration the PFID must not be configured on the GLOBALCONFIG statement.

    Result: Configuring PFID on the GLOBALCONFIG statement for this case could result in connection hangs with SMC-Rv1 link timeouts.

Rules:

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

PORTNUM num

Specifies the RoCE 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 or RoCE Express3 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/RoCE Express3 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 sub parameters to configure the operation of the sysplex autonomics function. For more information about sysplex problem detection and recovery, 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 sub parameters. If the SYSPLEXMONITOR parameter is specified but not all sub parameters are specified in the initial TCP/IP profile, then the sysplex autonomics function uses the default values for those SYSPLEXMONITOR sub parameters 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 sub parameters, 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) if OMPROUTE is not started and active.

NODELAYJOIN

Attempt to join the TCP/IP sysplex group without waiting for OMPROUTE to be started and active. This is the default value.

DELAYJOIN

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

DELAYJOINIPSEC | NODELAYJOINIPSEC

Specify whether TCP/IP should delay joining or rejoining the TCP/IP sysplex group (EZBTCPCS) if the IPsec infrastructure is not active and operational.

NODELAYJOINIPSEC

Attempt to join the TCP/IP sysplex group without waiting for the IPsec infrastructure to be active and operational. This is the default value.

DELAYJOINIPSEC

Delay joining or rejoining the TCP/IP sysplex group and processing any VIPADYNAMIC block or DYNAMICXCF statements until the IPsec infrastructure is active and operational.

Guideline: The DELAYJOINIPSEC parameter is only relevant when Sysplex-wide Security Association (SWSA) support is enabled with the DVIPSEC parameter on the IPSEC statement. If SWSA support is not enabled, the DELAYJOINIPSEC parameter is not accepted. Message EZZ0839I is issued indicating that DELAYJOINIPSEC is ignored.

Restrictions:

• If your IPsec infrastructure includes the Network Security Services daemon (NSSD), and the IKED to NSSD connection uses a DVIPA as the source or destination IP address, do not configure DELAYJOINIPSEC.
• If you use a centralized Policy Agent server for IPsec or AT-TLS policy, and the connection from the policy client to the policy server uses a DVIPA as the source or destination IP address, do not configure DELAYJOINIPSEC.

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. When MONINTERFACE is configured, this is the default value.

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.

Similarly, if you configure NOJOIN and DELAYJOINIPSEC, DELAYJOINIPSEC is initially ignored. If you subsequently issue a V TCPIP,,SYSPLEX,JOINGROUP command, NOJOIN is overridden, DELAYJOINIPSEC becomes active, and the stack joins the sysplex group when the IPsec infrastructure is active.

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).

MONIPSEC | NOMONIPSEC

Specify whether TCP/IP should monitor the IPsec infrastructure after the stack has joined the sysplex group. MONIPSEC or NOMONIPSEC can only be specified as a sub parameter of DELAYJOINIPSEC.

NOMONIPSEC

The TCP/IP stack should not monitor the IPsec infrastructure after the stack has joined the sysplex group.

MONIPSEC

The TCP/IP stack should monitor the IPsec infrastructure after the stack has joined the sysplex to detect if it is not active and operational. When DELAYJOINIPSEC is configured, this is the default.

Restriction:

• If your IPsec infrastructure includes the Network Security Services daemon (NSSD), and the IKED to NSSD connection uses a DVIPA as the source or destination IP address, do not configure MONIPSEC.
• If you use a centralized Policy Agent server for IPsec or AT-TLS policy, and the connection from the policy client to the policy server uses a DVIPA as the source or destination IP address, do not configure MONIPSEC.

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 IBM Health Checker for z/OS 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 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 importance level in z/OS Communications Server: IP Configuration Guide .

NOWLMPRIORITYQ

Specifies that 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 write priority values should be assigned to packets associated with WorkLoad Manager service class valuesand to forwarded packets.

You can assign specific write priority values by using the IOPRIn sub parameters, where n is one or more of the priority values in the range 1 - 4. For each sub parameter, 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 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 sub parameters. 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 priority assigned to the packet:

Table 1. WLM Service Class Importance Levels

Control value	Type of packet	Default priority queue
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 sub parameters, then the write priority values are assigned as shown Table 1.

IOPRIn control_values

Use the IOPRIn sub parameters to correlate control values with specific write priority values. You can use one or more of the following sub parameter keywords:

• IOPRI1
• IOPRI2
• IOPRI3
• IOPRI4

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

control_values

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

Digits 0 - 6

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

FWD

This keyword causes the write priority value indicated by the IOPRIn sub parameter 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 sub parameter. 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 sub parameters on a GLOBALCONFIG statement.
• If any control value is not explicitly specified on an IOPRIn sub parameter, then the associated packets are assigned a default write priority 4.

In the following example, priority 1 is assigned to packets associated with control values 0 and 1, priority 2 is assigned to packets associated with control value 2 and to forwarded packets, priority 3 is assigned to packets associated with control values 3 and 4, and 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 sysplex 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 sub parameters 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 INTVAL sub parameter. For more details on the zERT aggregation function, see What does zERT aggregation collect? in z/OS Communications Server: IP Configuration Guide.

INTVal

Specifies the interval at which zERT aggregation will be reported.

SMF

Indicates the system’s SMF interval is to be used. This is the default.

nn

Specifies the recording interval in one hour increments. Valid values are 1 through 24.

SYNCval hh:mm

Indicates a reference time for which zERT aggregation records will be recorded. SYNCVAL is a sub-parameter of the INTVAL sub-parameter. This field is in the form of 24 hour clock format hh:mm (hour and minute value separated by a colon). This reference time will be used to indicate the point from which the first zERT summary records should be recorded (SMF 119 subtype 12). If not specified, the default value is midnight or 00:00.

Specifies a reference time upon which INTVAL is based. The value is a time of day specified in hours and minutes in 24 hour clock format.

hh

Specifies the hour of the day, between midnight (00) and 11 PM (23).

:

Is a required separator with no intervening blanks.

mm

Specifies the minutes after the hour, between 00 and 59.

If SYNCVAL is not specified, the default is midnight (00:00).

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 sub parameters that control whether TCP/IP displaces CPU cycles onto a System z9® Integrated Information Processor (zIIP). You must specify at least one sub parameter. If the ZIIP parameter is specified with no sub parameters, 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 using z9 Integrated Information Processor (zIIP IP security) 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 OSA interfaces are not affected, but the stack will attempt to activate a dynamic IQDC interface on any subsequent OSA 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 NOEXPLICITBINDPORTRANGE 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 interfaces. For a change in these parameters to take effect, all the OSA 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 sub parameter 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 sub parameters, unless new values for the sub parameters 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 sub parameter 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.

SMCEID/ENDSMCEID

If you specify SMCEID-ENDSMCEID block with the VARY TCPIP,,OBEYFILE command, the values are changed to the data set that contains the new user EID values. All existing definitions for SMCEID-ENDSMCEID block will be fully replaced with the new definitions immediately. Specifying SMCEID-ENDSMCEID block while SMCv2 is disabled will enable both SMC-Dv2 and SMC-Rv2. Specifying SMCEID-ENDSMCEID block with no values will disable SMC-Rv2; it will also disable SMC-Dv2 if NOSYSTEMEID is in effect.

SYSTEMEID/NOSYSTEMEID

If SYSTEMEID has previously been configured and you then specify NOSYSTEMEID with the VARY TCPIP,,OBEYFILE command, SMC-Dv2 will be disabled. If NOSYSTEMEID has previously been configured and you then specify SYSTEMEID with the VARY TCPIP,,OBEYFILE command, SMC-Dv2 will be activated.

SMCPERMIT/ENDSMCPERMIT

If you specify SMCPERMIT-ENDSMCPERMIT block with the VARY TCPIP,,OBEYFILE command, the values are changed to the data set that contains a new SMCPERMIT-ENDSMCPERMIT values. All existing definitions for SMCPERMIT-ENDSMCPERMIT block will be fully replaced with the new definitions immediately.

SMCEXCLUDE/ENDSMCEXCLUDE

If you specify SMCEXCLUDE - ENDSMCEXCLUDE block with the VARY TCPIP,,OBEYFILE command, the values are changed to the data set that contains a new SMCEXCLUDE - ENDSMCEXCLUDE values. All existing definitions for SMCEXCLUDE - ENDSMCEXCLUDE block will be fully replaced with the new definitions immediately.

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 sub parameter 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 sub parameters, unless new values for the sub parameters 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 sub parameter 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 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 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 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.

DELAYJOINIPSEC and NODELAYJOINIPSEC

Changing from DELAYJOINIPSEC to NODELAYJOINIPSEC while the TCP/IP stack is in the process of delaying joining the sysplex group because the IPsec infrastructure is not active causes the TCP/IP stack to immediately join the sysplex group.

Changing from NODELAYJOINIPSEC to DELAYJOINIPSEC NOMONIPSEC has no immediate effect until the TCP/IP stack leaves the sysplex group and then attempts to rejoin while the IPsec infrastructure is not active.

Changing from NODELAYJOINIPSEC to DELAYJOINIPSEC with MONIPSEC configured or defaulted activates monitoring of the IPsec infrastructure.

MONIPSEC and NOMONIPSEC

Changing from MONIPSEC to NOMONIPSEC after the TCP/IP stack has detected a problem with the IPsec infrastructure does not clear message EZD1977E or cause the TCP/IP stack to rejoin the sysplex group (if RECOVERY had caused it to leave the sysplex). If you want the TCP/IP stack to rejoin the sysplex group, you must issue a VARY TCPIP,,SYSPLEX,JOINGROUP command.

Changing from NOMONIPSEC to MONIPSEC activates monitoring of the IPsec infrastructure.

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 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 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 INTVAL, zERT aggregation will flush the existing records and begin for new TCP and Enterprise Extender connections, with a new INTVAL. If not specified, the default value for INTVAL is SMF (which is the SMF interval time).

If you use the VARY TCPIP,,OBEYFILE command to change SYNCVAL, zERT aggregation will flush the existing records and will begin for new TCP and Enterprise Extender connections, with a new SYNCVAL (INTVAL always has to be specified since SYNCVAL is a sub-parameter of INTVAL). If not specified, the default time for SYNCVAL is 00:00 which is midnight.

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,,OBEYFILE command to change the sub parameter 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 sub parameter 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.