TCP/IP additional tips

The ISPF Workstation Agent is not linked with the application programming interface (API) modules provided by any specific communications software vendor.

The default behavior for accessing a TCP/IP subsystem in Microsoft Windows environments is for the ISPF WSA to try to locate WINSOCK.DLL. In the Microsoft Windows environment, many different vendors supply a winsock.dll so it is critical that the first winsock.dll located by the ISPF WSA contains the TCP/IP API modules actually used by the active TCP/IP subsystem on the workstation. The difficulty of managing multiple winsock.dll files in a given workstation environment is compounded by the fact that the search order used by Windows to locate a dynamic link library is not constrained by something equivalent to the CONFIG.SYS LIBPATH statement in OS/2. The Windows search order is as follows:

current directory
WINDOWS directory
WINDOWS\SYSTEM directory
directory containing the executable file for the current task
directories listed in the PATH environment variable
list of directories mapped in a network

If the dynamic link library cannot be located or if the TCP/IP API modules cannot be loaded successfully from the selected library then TCP/IP communication will be inoperative.

You can specify an explicit path to the socket DLL used by the active TCP/IP subsystem in a Microsoft Windows workstation environment. Specifying an explicit path overrides the default DLL search order for Windows. The directory defined by the explicit path is searched for WINSOCK.DLL. The explicit path to the TCP/IP socket DLL is specified by using the Set WINSOCK Path function available from the Options pull-down found on the Client/Server Agent Window (see The Workstation Agent window). This function is useful in environments such as those using LAN operating systems, in which the directories containing software from several TCP/IP vendors can be accessed by a workstation.

The Client/Server feature of ISPF (ISPF WSA) takes advantage of the TCP/IP keepalive socket option to enable ISPF on the host to detect an abnormal end to a session with the ISPF Workstation Agent on the workstation. Abnormal endings include such events as powering off or rebooting the workstation before closing the session with the ISPF WSA agent. The behavior of the keepalive facility differs for each workstation platform and TCP/IP product supported by ISPF:

Workstation Platform: Keepalive behavior
Windows: Reboot (CTRL-ALT-DELETE), power off, and Program Manager close are detected.
AIX®: Reboot, power off, and shutdown of an AIX host are detected. Reboot (CTRL-ALT-BACKSPACE) of an X-station client is detected, but power off of an X-station client is detected only when the X-station is powered on again.
HP-UX: Reboot, power off, and shutdown of an HP-UX host are detected.
Solaris: Reboot, power off, and shutdown of a Solaris host are detected.

If no transmissions have been received over a socket connection to the workstation during the specified timer interval, TCP/IP sends a keepalive packet to the workstation. If there is no response on the socket connection or if the socket connection has been reset, an error is returned and the ISPF C/S session ends on MVS™.

The keepalive timer value for z/OS® Communications Server: IP is controlled by the KEEPALIVEOPTIONS statement in the TCP/IP configuration data set. The INTERVAL parameter specifies the number of minutes that TCP/IP waits after the last transmission from the workstation before sending a keepalive packet. The SENDGARBAGE parameter specifies whether the packet contains any data. ISPF C/S was tested with the INTERVAL value set to 1 and the SENDGARBAGE value set to TRUE.