GLOBALCONFIG statement
Use the GLOBALCONFIG statement to pass global configuration parameters to TCP/IP.
Syntax
Tip: Specify the parameters for this statement in any order.
>>-GLOBALCONFig-------------------------------------------------> .--------------------------------------------------. V | >----+----------------------------------------------+-+-------->< | .-ADJUSTDVipamss AUTO------. | +-+--------------------------+-----------------+ | '-ADJUSTDVipamss--+-ALL--+-' | | '-NONE-' | | .-ALLTRAFFIC--. | | .-AUTOIQDX--+-------------+-. | | | '-NOLARGEDATA-' | | +-+---------------------------+----------------+ | '-NOAUTOIQDX----------------' | | .-ECSALimit 0K----------------. | +-+-----------------------------+--------------+ | '-+-ECSALimit --ecsa_limitK-+-' | | '-ECSALimit --ecsa_limitM-' | | .-NOEXPLICITBINDPORTRANGE------------------. | +-+------------------------------------------+-+ | '-EXPLICITBINDPORTRANGE 1st_port num_ports-' | | .-NOIQDMULTIWRITE-. | +-+-----------------+--------------------------+ | '-IQDMULTIWRITE---' | +-+-------------------+------------------------+ | '-IQDVLANid vlan_id-' | | .-MAXRECS 100------. | +-+------------------+-------------------------+ | '-+-MAXRECS *----+-' | | '-MAXRECS recs-' | | .-NOMLSCHKTERMinate-. | +-+-------------------+------------------------+ | '-MLSCHKTERMinate---' | | .-POOLLimit 0K----------------. | +-+-----------------------------+--------------+ | '-+-POOLLimit --pool_limitK-+-' | | '-POOLLimit --pool_limitM-' | | .-NOSEGMENTATIONOFFLoad-. | +-+-----------------------+--------------------+ | '-SEGMENTATIONOFFLoad---' | | .-NOSMCD----------------. | +-+-----------------------+--------------------+ | '-SMCD-| SMCD options |-' | | .---------------------. | | V .-AUTOCACHE---. | | +-SMCGlobal----+-+-------------+-+-+-----------+ | | '-NOAUTOCACHE-' | | | | .-AUTOSMC---. | | | '-+-----------+---' | | '-NOAUTOSMC-' | | | | | | .-NOSMCR----------------. | +-+-----------------------+--------------------+ | '-SMCR-| SMCR options |-' | | .-SYSPLEXMONitor--| Sysplex options |-. | +-+-------------------------------------+------+ | '-SYSPLEXMONitor--| Sysplex options |-' | | .-SYSPLEXWLMPoll 60------. | +-+------------------------+-------------------+ | '-SYSPLEXWLMPoll seconds-' | | .-NOTCPIPStatistics-. | +-+-------------------+------------------------+ | '-TCPIPStatistics---' | | .-NOWLMPRIORITYQ---------------------------. | +-+------------------------------------------+-+ | | .-default_control_values-. | | | '-WLMPRIORITYQ--+------------------------+-' | | '-IOPRIn control_values--' | +-+-------------------+------------------------+ | '-XCFGRPid group_id-' | '-+-------------------------------------+------' | .---------------------------. | | V .-NOIPSECURITY-. | | '-ZIIP----+-+--------------+------+-+-' | '-IPSECURITY---' | | .-NOIQDIOMULTIWRITE-. | '-+-------------------+-' '-IQDIOMULTIWRITE---'
SMCD options .------------------------------------------. V .-FIXEDMemory--256------. | |----+---+-----------------------+----------+-+-----------------| | '-FIXEDMemory--mem_size-' | | .-TCPKEEPmininterval--300------. | '---+------------------------------+---' '-TCPKEEPmininterval--interval-' SMCR options .-----------------------------------------------. V | |----+-------------------------------------------+-+------------| | .---------------------------------------. | | | .----------------------. | | | V V | | | +---PFID - pfid----+------------------+-+-+-+ | | .-PORTNum -1---. | | | +-+--------------+-+ | | | '-PORTNum -num-' | | | | .-MTU -1024----. | | | '-+--------------+-' | | '-MTU -mtusize-' | | .-FIXEDMemory--256------. | +---+-----------------------+---------------+ | '-FIXEDMemory--mem_size-' | | .-TCPKEEPmininterval--300------. | '---+------------------------------+--------' '-TCPKEEPmininterval--interval-' Sysplex options .-NOAUTOREJOIN-. |--+-+--------------+-------------------+-----------------------| | '-AUTOREJOIN---' | | .-NODELAYJOIN-. | +-+-------------+--------------------+ | '-DELAYJOIN---' | +-+--------+-------------------------+ | '-NOJOIN-' | | .-NOMONINTERFACE NODYNROUTE------. | +-+--------------------------------+-+ | | .-NODYNROUTE-. | | | +-NOMONINTERFACE--+------------+-+ | | | .-DYNROUTE---. | | | '-MONINTERFACE--+------------+---' | | '-NODYNROUTE-' | | .-NORECOVERY-. | +-+------------+---------------------+ | '-RECOVERY---' | | .-TIMERSECS 60------. | '-+-------------------+--------------' '-TIMERSECS seconds-'
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.
- 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.
- If you specify the EXPLICITBINDPORTRANGE parameter in a sysplex
that contains pre-V1R9 TCP/IP stacks, each distributor, backup, and
target TCP/IP stack of a distributed SYSPLEXPORTS DVIPA that is configured
as a source IP address on a SRCIP profile statement must have one
of the following characteristics:
- Run on a V1R9 or later system.
- Use the PORTRANGE profile statement on the pre-V1R9 stacks to reserve the ports that are configured on the V1R9 or later stacks with the EXPLICITBINDPORTRANGE parameter.
- The DVIPA-specific pool by a pre-V1R9 system
- The EXPLICITBINDPORTRANGE pool by a V1R9 or later system
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 IBM 10 GbE 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 10 GbE RoCE
Express feature that this stack uses. A pfid is a 2-byte hexadecimal
value in the range 0 - 0FFF
that identifies this TCP/IP stack's representation of a
10 GbE RoCE Express
feature.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 10 GbE RoCE Express feature that uses the same PFID value from different TCP/IP stacks within the same logical partition (LPAR).
- PORTNUM num
- Specifies the 10 GbE 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:
- 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:
This is the default value.EZZ0613I TCPIPSTATISTICS IS DISABLED
- 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
- 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.
- 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:
- 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.
- 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.
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 10 GbE RoCE Express
interfaces are active. To change the SMCR PFID parameter values that are currently configured, you
must perform the following steps in order:
- Stop the associated 10 GbE RoCE Express interfaces.
- 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 10 GbE RoCE Express interfaces are not affected.
- If SMCR support is not enabled, you can specify the SMCR parameter in a VARY TCPIP,,OBEYFILE
command data set to activate the support.
- 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.
Examples
GLOBALCONFIG SYSPLEXMONITOR AUTOREJOIN DELAYJOIN MONINTERFACE DYNROUTE RECOVERY
The following example shows the use of the EXPLICITBINDPORTRANGE parameter to define 1024 ports in the range 5000 - 6023. The ports are used for explicit binds to the IPv4 INADDR_ANY address, or to the IPv6 unspecified address (in6addr_any), and port 0:
GLOBALCONFIG EXPLICITBINDPORTRANGE 5000 1024
The following example shows the use of the SMCR parameter to define two 10 GbE RoCE Express features that use PFID values 0018 and 0019 and port numbers 1 and 2, and to limit the stack to 500 megabytes of 64-bit storage for SMC-R communications.
GLOBALCONFIG SMCR PFID 0018 PORTNUM 1 PFID 0019 PORTNUM 2 FIXEDMEMORY 500
![Start of change](./delta.gif)
GLOBALCONFIG SMCD FIXEDMEMORY 500
![End of change](./deltaend.gif)
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.