z/OS V1R13 Communications Server: IP Configuration Reference

Troubleshooting

Problem

Add publication updates for z/OS V1R13 Communications Server: IP Configuration Reference as illustrated below.

Resolving The Problem

In Chapter 2, in the PROFILE.TCPIP search order section, update the search order list:

//PROFILE DD statement
jobname.nodename.TCPIP
TCPIP.nodename.TCPIP
jobname.PROFILE.TCPIP
TCPIP.PROFILE.TCPIP

In Chapter 2, add a paragraph at the beginning of the ATMARPSV statement, ATMLIS statement, and ATMPVC statement sections:

Because support will be eliminated for the ATM device type in a future release, this statement will no longer be supported.

In Chapter 2, update the description of parameter gateway_addr in the BEGINROUTES statement section:

gateway_addr

The host IPv4 or IPv6 address of a gateway or router that you can reach directly, and that forwards packets for the destination network or host over the interface that is identified by interface_name.

Requirement: This value must be either a fully qualified address or an equal sign (=), meaning that the messages are routed directly to destinations on that network or directly to that host. The equal sign is not supported for DEFAULT or DEFAULT6 route entries. It cannot be a local IP address on this TCP/IP stack. A local IP address can be defined on the HOME, INTERFACE, VIPADEFINE, or IPCONFIG/IPCONFIG6 DYNAMICXCF statement.

In Chapter 2, in the BEGINROUTES statement, update the Direct Routes part of the example:

In Chapter 2, in the BEGINROUTES statement and GATEWAY statement sections, update the first paragraph and add a tip after the second paragraph in the description of Retransmission parameter considerations:

The parameters listed in this topic affect the TCP retransmit algorithms. When TCP packets are not acknowledged, TCP begins to retransmit these packets at certain time intervals. If these packets are not acknowledged after a specified number of retransmits, TCP aborts the connection. The time interval between retransmissions increases by approximately twice the previous interval until the packets are acknowledged or the connection times out.

The time intervals between retransmissions and the number of times that packets are retransmitted before the connection times out differs for initial connection establishment and for data packets . For initial connection establishment, the initial time interval is set at approximately 3 seconds and the SYN packet is retransmitted 5 times before the connection is timed out. Data packets use a smoothed Round Trip Time (RTT) as the initial time interval, and data packets are retransmitted 15 times before the connection is timed out. All of the remaining parameters listed in this topic affect the data packet retransmission algorithm. Only the MINIMUMRETRANSMITTIME parameter affects the initial connection establishment.

Tip: A new route lookup is performed after every two retransmissions for a data packet. For more information about the route lookup process, see Route selection algorithm in z/OS Communications Server: IP Configuration Guide. Be careful when you design networks with firewalls. A firewall in an alternate routing path can generate a RESET packet for the rerouted data packets, which causes TCP to abort the connection.

In Chapter 2, add a paragraph at the beginning of the DEVICE and LINK — ATM devices statement, DEVICE and LINK — CLAW devices statement, DEVICE and LINK — HYPERchannel A220 devices statement, DEVICE and LINK — SNA LU0 links statement, DEVICE and LINK — SNA LU 6.2 links statement, DEVICE and LINK — X.25 NPSI connections statement, and DEVICE and LINK — 3745/46 channel DLC devices statement sections:

This device type will not be supported in a future release. It is recommended that you migrate to a later interface type, such as OSA-Express QDIO or HiperSockets.

In Chapter 2, update the second sentence in the description of parameter INBPERF DYNAMIC in the DEVICE and LINK -- MPCIPA OSA-Express QDIO devices statement, INTERFACE -- IPAQENET OSA-Express QDIO interfaces statement, and INTERFACE -- IPAQENET6 OSA-Express QDIO interfaces statement sections:

The DYNAMIC setting is effective only for OSA-Express2 or later features on at least an IBM System z9 that supports the corresponding Dynamic LAN Idle function.

In Chapter 2, update the description of parameter first_hop in the GATEWAY statement section:

first_hop

Specify one of the following values:

An equal sign (=), meaning that datagrams are routed directly to destinations on that network or directly to that host over the interface that is identified by link_name. This is not supported for DEFAULT or DEFAULTNET.
The IP address of a gateway or router that you can reach directly, and that forwards datagrams for the destination network or host over the interface that is identified by link_name. The address must be a host address that uniquely identifies the gateway or router. It cannot be a local IP address on this TCP/IP stack. A local IP address can be defined on the HOME, INTERFACE, VIPADEFINE, or IPCONFIG DYNAMICXCF statement. The IP address must be a fully qualified address in the form a.b.c.d.

In Chapter 2, update the description of the INCLUDE statement section:

This statement causes profile statements from the named data set to be included at the point that the INCLUDE statement is encountered. In general, a profile statement must begin and end within the same data set. For example, the statement beginning with BSDROUTINGPARMS and ending with ENDBSDROUTINGPARMS must be contained within the same data set.

In Chapter 2, update the description of parameters NTATRCSERVICE | NONTATRCSERVICE and PKTTRCSERVICE | NOPKTTRCSERVICE in the NETMONITOR statement section:

NTATRCSERVICE | NONTATRCSERVICE
Specifies the behavior of the real time TCP/IP OSAENTA trace service (SYSTCPOT).

Tip:

The CTRACE SYSTCPOT component must be active. The component is activated by default. The TRACE CT,ON,COMP=SYSTCPOT,SUB=(tcpprocname) command activates the trace and the TRACE CT,OFF,COMP=SYSTCPOT,SUB=(tcpprocname) command deactivates the trace.
The VARY TCPIP,,OSAENTA,ON command must be issued, or the OSAENTA statement in the TCP/IP profile is used to specify the parameters to collect data from an OSA-Express adapter. For trace data collection from an OSA-Express adapter, verify the following requirements:
An extra DATAPATH device must be defined for the TRLE for the OSA-Express adapter.
The hardware definitions for the OSA-Express adapter must be defined to allow OSAENTA trace data to be collected.

Real-time TCP/IP network monitoring NMI

z/OS Communications Server: IP Programmer's Guide and Reference

PKTTRCSERVICE | NOPKTTRCSERVICE
Specifies the behavior of the real time TCP/IP packet trace service (SYSTCPDA).

Tip:

The CTRACE SYSTCPDA component must be active. The component is activated by default when TCP/IP starts. The TRACE CT,ON,COMP=SYSTCPDA,SUB=(tcpprocname) command activates the trace and the TRACE CT,OFF,COMP=SYSTCPDA,SUB=(tcpprocname) command deactivates the trace.
If the network management application collects packet trace data, the VARY TCPIP,,PKTTRACE,ON command must be issued to specify the parameters to collect trace data from TCP/IP interfaces.
If the network management application collects data trace data, the VARY TCPIP,,DATTRACE,ON command must be issued to specify the parameters to collect application data.

Real-time TCP/IP network monitoring NMI

z/OS Communications Server: IP Programmer's Guide and Reference

In Chapter 2, add a tip before the guideline in the description of parameter ABBREV in the OSAENTA statement section:

Tip: The size value that OSA returns is the maximum amount of trace data that OSA can return. Depending on the model, OSA can return fewer bytes than the maximum. OSA-Express3 or later version returns only 120 bytes for unicast packets, and return up to the maximum amount of trace data for multicast, broadcast, or unrouteable packets.

In Chapter 2, update the description of the SHAREPORT and SHAREPORTWLM parameters in the PORT statement section:

SHAREPORT

Required when reserving a port to be shared across multiple listeners on the same interface. When SHAREPORT is specified, TCP/IP allows multiple listeners to listen on the same combination of port and IP address.

As incoming client connections arrive for this port and IP address, TCP/IP distributes them across the listeners. Specification of this keyword causes incoming connection requests for the port to be distributed among the listeners using a weighted round-robin distribution method based on the servers' accept Efficiency Fractions (SEFs) of the listeners sharing the port. The SEF is a measure, calculated at intervals of approximately one minute, of the efficiency of the server application in accepting new connection requests and managing its backlog queue. Alternatively, SHAREPORTWLM can be coded instead; SHAREPORTWLM changes the connection distribution algorithm.

If the same port is reserved for multiple job names, SHAREPORT or SHAREPORTWLM needs to be specified on only one instance of the port reservation. SHAREPORTand SHAREPORTWLM are valid only for TCP ports. The last setting of either SHAREPORT or SHAREPORTWLM is used for all TCP/IP servers that use that port.

SHAREPORTWLM

Required when reserving a port to be shared across multiple listeners on the same interface. When SHAREPORTWLM is specified, TCP/IP allows multiple listeners to listen on the same combination of port and IP address.

...

In Chapter 2, in the PORT statement and PORTRANGE statement sections, add a restriction to the last bullet of the list at the end of the description of the jobname parameter:

Restriction: The VTAM job name cannot include a wildcard character (*) when it reserves EE UDP ports.

In Chapter 2, update the description of parameters TCPMAXRCVBUFRSIZE and TCPRCVBUFRSIZE in the TCPCONFIG statement section:

TCPMAXRCVBUFRSIZE tcp_max_receive_buffer_size
The TCP maximum receive buffer size is the maximum value an application can set as its receive buffer size using SETSOCKOPT(). The minimum acceptable value is the value coded on TCPRCVBUFRSIZE, the maximum is 512 K, and the default is 256 K. If you do not have large bandwidth interfaces, you can use this parameter to limit the receive buffer size that an application can set.

Note: If Dynamic right sizing (DRS) is active for a connection, the TCPMAXRCVBUFRSIZE value is ignored and a maximum value of 2M is used. For more information about DRS, see TCP receive window in z/OS Communications Server: IP Configuration Guide.

IBM Health Checker for z/OS can be used to check whether the TCPMAXRCVBUFRSIZE value is sufficient to provide optimal support to the z/OS Communications Server FTP server. By default, it checks that TCPMAXRCVBUFRSIZE is at least 180 K. For more details about IBM Health Checker, see z/OS Communications Server: IP Diagnosis Guide.

TCPRCVBUFRSIZE tcp_receive_buffer_size

TCP receive buffer size between 256 and TCPMAXRCVBUFRSIZE. The default is 16384 (16K). This value is used as the default receive buffer size for those applications which do not explicitly set the buffer size using SETSOCKOPT().

Increasing the receive buffer size does not allocate or consume any additional storage. The receive buffer size determines the amount of data that TCP/IP can buffer for the application to receive. When the TCP/IP stack receives the data, the data is stored in CSM data space or TCP/IP private storage. Each received segment has an associated data descriptor that resides in ECSA or TCP/IP private. No external mechanism controls which storage type is selected for the received data. For more information about the receiver buffer size and the TCP receive window, see TCP receive window in z/OS Communications Server: IP Configuration Guide.

In Chapter 2, update the description of the TTLS parameter in the TCPCONFIG statement section:

TTLS
Indicates that the AT-TLS function is activated for the TCP/IP stack. The AT-TLS function provides invocation of System SSL in the TCP transport layer of the stack. When a TCPCONFIG TTLS value is specified, the AT-TLS function uses AT-TLS policy information (configured using Policy Agent) to determine how application connections are processed. If the setting is modified using the VARY TCPIP,,OBEYFILE command, only new connections are affected by the change.

Guideline: If AT-TLS is enabled, you must activate the SERVAUTH class, define the INITSTACK resource profile, and permit users to it.

For more information about AT-TTLS data protection, see z/OS Communications Server: IP Configuration Guide.

In Chapter 2, in the description of the VIPADYNAMIC - VIPADISTRIBUTE statement, in the
description of the PORT parameter, the third paragraph is changed as follows (with a fourth
paragraph added):

The PORT parameter can also be omitted entirely from the VIPADISTRIBUTE statement. If the PORT parameter is omitted, then any server that binds a socket to the distributed DVIPA and a specific (nonzero) port, and establishes that socket as a listening socket, is eligible for connection workload balancing. The following methods can be used to bind a socket to the distributed DVIPA and a specific (nonzero) port:

If available, use a socket option provided by the server application to override the INADDR_ANY address and to specify a distributed DVIPA address for the listening port.
Code a BIND parameter that specifies a distributed DVIPA for the listening port in the TCP/IP profile PORT statement.
Use the TCP/IP profile SRCIP statement to specify a job name for the server application, the distributed DVIPA address, and the SERVER option. The listening port for the server application is associated with the distributed DVIPA address.

When the PORT parameter is omitted from the VIPADISTRIBUTE statement, any ports that are bound to the distributed DVIPA are eligible for distribution.

The Rules and the Requirement sections remain the same.

In Chapter 5, add a restriction before the syntax in the COMMONSEARCH/NOCOMMONSEARCH statement section:

Restriction: You must code the COMMONSEARCH statement if you use IPNODES for the local hosts file. For more information, see Search orders used in the z/OS UNIX environment and Search orders used in the native MVS environment in z/OS Communications Server: IP Configuration Guide.

In Chapter 5, add Usage notes at the end of the RESOLVEVIA statement section:

Usage notes

EDNS0 processing

z/OS Communications Server: IP Configuration Guide

In Chapter 11, in the OMPROUTE cataloged procedure (optional) section:

In the example, change the copyright years (in the 5th line) from 1998, 2003 to 1998, 2011.

Also in the example, after these lines:
//* For information on the above environment variables,
//* refer to the IP CONFIGURATION GUIDE.

Add the following:
//* When using _CEE_ENVFILE with an MVS data set, the data
//* set must be allocated with RECFM=V. To use a RECFM=V
//* data set, _CEE_ENVFILE_S should be used to prevent the
//* environment variable values from being padded with
//* blanks

After the example, change the restriction to the following:

Restriction: When using _CEE_ENVFILE with an MVS data set, the data set must be allocated
with RECFM=V. To use a RECFM=V data set, _CEE_ENVFILE_S should be used to prevent the
environment variable values from being padded with blanks.

In Chapter 11, in the description of the OSPF_INTERFACE statement, replace the existing Usage notes with the following paragraph:

When you configure multiaccess parallel interfaces (primary and secondary interfaces that have IP addresses in the same subnet) for OMPROUTE (OSPF), code the Parallel_OSPF=Primary parameter to set a specific interface as the primary interface. If none of the interfaces on the same subnet are coded as primary, Omproute selects the primary interface from the set of interfaces attached to the subnet. In case of a primary interface failure, Omproute uses the first available secondary interface and marks it as the primary interface.

In Chapter 11, change the message number from EZZ8164I to EZZ8163I in the description of MTR in the OSPF_INTERFACE statement, RIP_INTERFACE statement, and INTERFACE statement sections.

In Chapter 11, in the OSPF_INTERFACE statement, RIP_INTERFACE statement, IPv6_OSPF_INTERFACE statement, IPv6_RIP_INTERFACE statement, INTERFACE statement, and IPv6_INTERFACE statement sections, update the first paragraph and add a tip after the second paragraph in the description of Retransmit Parameters:

The following parameters are used by OMPROUTE to set values in the routes that use this interface; the values are added to the TCP/IP route tables. The values affect the TCP retransmit algorithms. When TCP packets are not acknowledged, TCP begins to retransmit these packets at certain time intervals. If these packets are not acknowledged after a certain number of retransmissions, TCP aborts the connection. The time interval between retransmissions increases by approximately twice the previous interval until the packets are acknowledged or the connection times out.

The time intervals between retransmissions and the number of times packets are retransmitted before the connection times out differs for initial connection establishment and for data packets. For initial connection establishment, the initial time interval is set at approximately 3 seconds and the SYN packet is retransmitted 5 times before the connection is timed out. Data packets use a smoothed Round Trip Time (RTT) as the initial time interval and are retransmitted 15 times before the connection is timed out. All of the following parameters affect the data packet retransmission algorithm. Only the Min_Xmit_Time parameter affects the initial connection establishment.

Tip: A new route lookup is performed after every two retransmissions for a data packet. For more information about the route lookup process, see Route selection algorithm in z/OS Communications Server: IP Configuration Guide. Be careful when you design networks with firewalls. A firewall in an alternate routing path can generate a RESET packet for the rerouted data packets, which causes TCP to abort the connection.

In Chapter 11, change the last sentence of the description of the Max_Xmit_Time parameter to the following:

This parameter affects the initial connection establishment retransmission timeout for all APIs, except the Pascal API (TcpOpen), that are using the socket connect function.

This change occurs in the Max_Xmit_Time parameter definition in these 6 statements In Chapter 11:

OSPF_INTERFACE
RIP_INTERFACE
IPv6_OSPF_INTERFACE
IPv6_RIP_INTERFACE
INTERFACE
IPv6_INTERFACE

In Chapter 11, Tables 27 and 28, the 6th column is mislabeled, the correct heading should be "Point-to-multi-point" as shown here:

Interface type	Connectivity	Multiaccess broadcast	Non- broadcast multiaccess (NBMA)	Point-to- point	Point-to- multi-point	Futile neighbor state loop detection support

In Chapter 14, in the section titled "FTP server user exits", replace the requirement list after the sentence "The remainder of the parameter list points to values the FTP user exit uses in its processing.", update the requirement list, and add a rule after the requirement list:

Requirements:

The user exit load modules must be in a cataloged data set and placed in an APF-authorized library to which the FTP server has access by way of STEPLIB, linklist, or LPA.
The authorization state (JSCBAUTH) must be the same after exiting from the user exit as it was upon entry.
User exit routines must be reentrant.
User exit routines are invoked in TCB mode, problem program state, with AMODE(31). If the user exit routine changes a setting, the user exit routine must restore the setting before returning to the caller.
The FTPCHKIP user exit is loaded when the FTP daemon initializes. If you want the FTP daemon to use a new version of this exit routine, you must stop the FTP daemon and start it again.

Rule: All data areas that are passed to the exit, including the Language Environment save area stack, will be above the line (31 bit addressing). If the exit routine uses any system services that require data areas below the line (24 bit addressing), it must obtain the necessary storage below the line itself and copy any data values there.

In Chapter 14, remove the following restriction statement from the sections titled "The FTCHKCMD user exit", "The FTCHKIP user exit", "The FTCHKPWD user exit", and "The FTCHKJES user exit":

Restriction: To function with the FTP server, AMODE must be coded as 31 and RMODE must be coded as ANY.

In Chapter 14, add the following section after the section titled "ANONYMOUSMVSINFO (FTP server) statement“:

APPLNAME (FTP server) statement

Use the APPLNAME statement to specify the FTP server application name (applid).

Syntax
>>-APPLNAME--applname------------------------------------------><

Parameters
applname
The FTP server application name.

Examples
Use the OMVSAPPL as FTP server application name:
APPLNAME OMVSAPPL

Usage notes
If you do not specify any value for APPLNAME, FTP server will use job name as application name. The maximum length of this statement is 8 bytes. Any invalid value will be ignored.

In Chapter 16, update the table in the description of parameter DEFAULT in the ENCRYPTION statement section:

cipher_spec Telnet Display Abbreviation Cipher number
-------------- -------------------- ---------------
SSL_RC4_SHA 4S 05
SSL_RC4_MD5 4M 04
SSL_AES_256_SHA A2 35
SSL_AES_128_SHA A1 2F
SSL_3DES_SHA 3S 0A
SSL_DES_SHA DS 09
SSL_RC4_MD5_EX 4E 03
SSL_RC2_MD5_EX 2E 06
SSL_NULL_SHA NS 02
SSL_NULL_MD5 NM 01
SSL_NULL_Null NN 00

In Chapter 16, add the parameter MVS mvsdsname in the ENCRYPTION statement section:

Syntax

>>-+-------------------------------+---------------------------><
'-KEYRING--+-HFS--hfsdsname---+-'
'-MVS--mvsdsname---'
'-SAF--keyringname-'

Parameters

MVS mvsdsname

The fully-qualified MVS data set name of the key ring that uses the RACF ADDRING function.

In Chapter 16, add the INCLUDE statement section after the INACTIVE statement section:

INCLUDE statement

This statement causes profile statements from the named data set to be included at the point that the INCLUDE statement is encountered. In general, a profile statement must begin and end within the same data set. For example, the statement beginning with BSDROUTINGPARMS and ending with ENDBSDROUTINGPARMS must be contained within the same data set. There are two exceptions to this requirement:

INCLUDE statements can be used within the BEGINVTAM - ENDVTAM block of statements.
INCLUDE statements can be used within a list of LUNAMES.

Syntax

>>-INCLude--data_set_name--------------------------------------><

Parameters

data_set_name

A fully qualified data set name that identifies a sequential file. The sequential file can be a sequential data set or a PDS with the member name. It cannot be a z/OS UNIX file.

In Chapter 16, under the Telnet parameter statements in the Telnet profile subheading, change the description of the TESTMODE statement as follows:

+++++++++++
TESTMODE statement
Use the TESTMODE parameter statement to allow an operator to try the statements for a port that is defined in the same TELNETPARMS block without applying them. All the processing and checking is done for an actual port update, but at the end of the process, instead of applying the new statements, all data structures for that port are released. TESTMODE applies to only the port that is defined in the TELNETPARMS section where it is coded and not to the entire profile. If this statement is not coded, the profile for the port becomes the current profile when it is processed.

TESTMODE can be coded only in the TELNETPARMS statement block.

With the TESTMODE statement coded in all of the TELNETPARMS blocks, a Telnet administrator can issue a VARY TCPIP,,OBEYFILE command for a profile data set and can determine whether there are any syntax or semantic errors without concern for applying a profile that is not valid. TESTMODE profiles can be processed as often as necessary.

The TESTMODE statement can be specified in the initial startup profile. However, the end result is that the port is not opened and clients cannot connect. It would be as if no profile statements existed for that port.

In Chapter 16, in the description of the XCFGROUP statement, fix a typo in the Syntax diagram:

Change XCFMONIOR to XCFMONITOR in 2 places as shown here:

In Chapter 18, the Section named "FTP server user exits" and its sub-sections are in the wrong place. It is now a sub-section of "FTP configuration statements in FTP.DATA". Move the whole section up so that it is placed between "FTP server cataloged procedure (FTPD) parameters" and "FTP configuration statements in FTP.DATA".

In Chapter 18, update the description of the +52 offset in the FTCHKCMD user exit section:

+52

Pointer to a 256-byte scratchpad buffer, which can be used to pass information between user exits. All exits receive a pointer to this buffer except FTCHKIP and FTCHKPWD. FTP does not query or alter the contents of the scratchpad at any time. The extended tracing (DUMP) identifier of the scratchpad is 87. If extended tracing of the scratchpad is requested, the contents are dumped after execution of the user exit.

Restriction: If the exit is used for USER/PASS command processing, the scratchpad buffer should not contain a pointer unless the storage location that is referenced is available to all address spaces.

In Chapter 18, add a note list at the end of the description of the +36 offset in the FTCHKPWD user exit section:

Notes:

When PASSPHRASE FALSE is configured in FTP.DATA of the server, the pointed buffer consists of a 2-byte field, which contains zeros, and is followed by 100 blanks.
When PASSPHRASE TRUE is configured in FTP.DATA of the server, the pointed buffer consists of a 2-byte field, which contains the length of the password or password phrase, and is followed by a 100-byte field. The 100-byte field contains the password or password phrase that is used to log in to FTP and is right-padded with blanks that are up to 100 characters in length.

In Chapter 18, add the CHKPTFLUSH (FTP client) statement section:

CHKPTFLUSH (FTP client) statement

If FTP saves checkpoint information in the checkpoint file or data set, z/OSmight buffer the records in volatile storage instead of writing the data to storage media immediately. Use the CHKPTFLUSH statement to specify whether FTP forces z/OS to flush checkpoint information to storage media when each record is written, or allows z/OS to determine when checkpoints are flushed from volatile storage to storage media.

Guideline: When you allow z/OS to buffer checkpoint records, if you configure a large checkpoint interval and your operator cancels a file transfer operation when check pointing is active, you might lose most or all of the checkpoint data. This is because z/OS cannot flush buffered data to storage media when the FTP job is canceled. If you lose most or all of the checkpoint data, you cannot restart the file transfer from the point where it is interrupted. This is inefficient for long running file transfer operations. Code CHKPTFLUSH TRUE if this is a problem at your installation.

Syntax

.-CHKPTFLUSH FALSE------.
>>-+-----------------------+-----------------------------------><
'-CHKPTFLUSH--+-FALSE-+-'
'-TRUE--'

Parameters

FALSE
z/OS is allowed to buffer checkpoint records in volatile storage when FTP saves them. z/OS determines when to flush buffered records to storage media. This is the default value.

TRUE
z/OS flushes checkpoint records to storage media as soon as FTP saves them.

Examples
z/OS flushes checkpoint records to storage media as soon as FTP saves them.
CHKPTFLUSH TRUE

Usage notes
None

Related topics

In Chapter 18, add a restriction after the first paragraph in the DSWAITTIME (FTP client and server) statement section:

Restriction: The DSWAITTIME statement does not support tape data sets.

In Chapter 18, in the description of the DSWAITTIME (FTP client and server) statement.
Add new third bullet under Guidelines heading:

If you experience control connection time-outs while the server is waiting for access to an MVS data set, try configuring a nonzero value for FTPKEEPALIVE at the client or the server. If keepalive packets do not prevent FTP control connection time-outs, configure a smaller DSWAITTIMEREPLY value.

Add new first bullet under Related topics heading:

DSWAITTIMEREPLY (FTP server) statement

Add the following statement in alphabetical order:

DSWAITTIMEREPLY (FTP server) statement
Use the DSWAITTIMEREPLY statement to specify how often to send the following reply message to the client while the FTP server is waiting for access to an MVS data set.
125 - Data set access will be retried in 1 minute intervals
-- number attempts remaining
Results:

The server always issues the following reply at one-minute intervals while waiting for access to a data set for the amount of time specified by the DSWAITTIME configuration option.

125 - FTP Server unable to obtain

usage

use of

data set

which is held by

asid jobname accessmode

on

qname

125 - Data set access will be retried at 1 minute intervals

--

number

attempts remaining

The DSWAITTIMERREPLY value is applied only when you have configured a DSWAITTIME value that is greater than zero.

Tip: Coding a DSWAITTIMEREPLY value that is smaller than 60 can prevent an FTP client control connection from timing out while the server is waiting for a data set.

Syntax:

Parameters:
seconds

125 - Data set access will be retried at 1 minute intervals

--

number

attempts remaining

Examples:
In this example, the DSWAITTIMEREPLY value is 30. The following reply message is issued every 30 seconds:

125 - Data set access will be retried at 1 minute intervals

--

number

attempts remaining

If the DSWAITTIMEREPLY value is 3, the following would be the actual output:

125 - FTP Server unable to obtain EXCLUSIVE use of

USER.TEST.DATA which is held by: 0035 USER2

EXCL on SYSDSN