A fix is available
APAR status
Closed as program error.
Error description
EE lines do not reactivate after TCPIP is recycled.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All using Enterprise Extender connections. * **************************************************************** * PROBLEM DESCRIPTION: EE lines do not reactivate after * * TCPIP is recycled. * **************************************************************** * RECOMMENDATION: * **************************************************************** The problem is summarized as follows: 1) Enterprise Extender is defined and active with a TCPIP stack. 2) The stack is inactivated with a "P TCPIP" command. 3) A CLEAR_Req is received in VTAM to cleanup the IUTSAMEH EE (FastUDP) connection. 4) The CLEAR_Req is processed by the IPNCB PU PAB. As part of cleanup, each line associated with the active VIPA is scheduled for dead port processing. 5) Each AUNCB (line) PU PAB is dispatched and builds an INOP Rupe to notify PUNS of the inoperative condition. 6) PUNs receives and processes each INOP Rupe and performs appropriate cleanup of each line. 7) One line fails to cleanup when ISTPUCIL could not find the PUSCB from the INOP Rupe. This leaves a nonzero count in the IPNCB (IPNCB_LINE_ALLOC_CNT). 8) Because the IPNCB_LINE_ALLOC_CNT is nonzero, the IPNCB is not fully deactivated. The IPNCB also has the IPNCB_DEAD_PORT bit on because it is undergoing cleanup processing. 9) As part of KEEPACT processing for each EE line, timer processing automatically tries to activate each line at regular intervals. 10) These automated activations each fail because the IPNCB with the IPNCB_DEAD_PORT is located. The KEEPACT processing simply sets another timer and retries the activation at a later time. This process repeats indefinitely, and the EE lines do not automatically recover. NOTE: A D NET,Pending command shows all the EE lines in an INOP state. The root cause of the problem is the INOP RUPE is built incorrectly. In this case, the line and PU (PUX) were defined as extended network addresses which had different extended address indices. In general, the line and PU network address indices come from the same extended address table. This configuration happened to define large numbers of EE lines which caused extended network addresses to span tables. This occurs after 32K extended network addresses have been defined.
Problem conclusion
ISTAUCKI - Has been corrected to build a link INOP with the correct network address index. ISTAUCLA - Included for maintenance purposes.
Temporary fix
Comments
APAR Information
APAR number
OA41624
Reported component name
VTAM V4 MVS/ESA
Reported component ID
569511701
Reported release
1D0
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-03-08
Closed date
2013-03-20
Last modified date
2013-05-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UA68407 UA68408
Modules/Macros
ISTAUCKI ISTAUCLA
Fix information
Fixed component name
VTAM V4 MVS/ESA
Fixed component ID
569511701
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1D0","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1D0","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 May 2013