IBM Support

Enterprise Extender PU does not automaticaly recover after moving to new Z13 and V2R1 for z/OS comm Server

Question & Answer


Question

Sometimes after an IPL of nodes in our network, and sometimes after an INOP error, our EE PU's in VTAM hang in CONCT or PREQC status. This did not happen running the prior release of V1R13.

Answer

To enable EE connections to automatically activate (without having to issue VARY DIAL commands), put both the EE XCA major node and the switched major node in the VTAM configuration list, and specify DWACT=YES on the EE switched PUs. When VTAM initialization completes, the EE connections will fully activate without further intervention. When the connections are activated, they should be automatically recovered after any type of failure (such as an IP network problem or even a loss of the TCP/IP stack itself). Certain operands automate the recovery of the EE switched PUs and LINEs when initial activation fails, or when a later connection failure is detected. The operands include:

 **KEEPACT** 

 Coding the KEEPACT value as YES on the EE LINE indicates that you want VTAM to immediately try to reactivate the LINE after it fails. This is especially useful in instances where the TCP/IP stack fails or is taken down, thereby making all of the EE LINEs inoperable. With KEEPACT=YES, the lines are reactivated automatically when the TCP/IP stack is recovered.

 **DWINOP** 

 Setting Dial When INOP (DWINOP) on the switched PU to YES indicates to VTAM that you want the PU to be redialed after a failure.

 **REDIAL** 

 If DWINOP=YES is specified on the switched PU, then by default VTAM will make up to 3 redial attempts. The REDIAL parameter can be coded on the PATH statement to change the number of redial attempts to a number in the range 0 - 254, or to FOREVER, meaning that VTAM will redial indefinitely.

 **REDDELAY** 

 By default, VTAM waits 30 seconds between redial attempts. You can adjust that interval to any value in the range 1 - 1200 seconds by coding the REDDELAY parameter on the PATH statement.

When an EE connection is composed of two z/OS EE endpoints, specifying DWACT=YES or DWINOP=YES on both endpoints can lead to both hosts attempting to initiate or recover an EE connection simultaneously. This can produce unnecessary dial collisions, resulting in delayed activation or recovery, or in some cases failed activation or recovery.

Guideline : When coding DWACT=YES, DWINOP=YES, or both, specify it on only one side of the connection to avoid PU busy conflicts. ** When coding DWINOP=YES, also consider coding the REDIAL and REDDELAY operands on the corresponding switched major node PATH statement. The current defaults for these two parameters are REDIAL=3 and REDDELAY=30. With these defaults values, z/OS Communications Server retries for only approximately 120 seconds after an INOP before giving up attempts to contact the partner EE node.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Platform":[{"code":"PF035","label":"z\/OS"}],"Component":"","Version":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Product Synonym

ZOSCS COMMSERVER

Document Information

Modified date:
17 May 2016

UID

dwa1271432