APAR status
Closed as program error.
Error description
IST1222I INOP for MPC subchannel when VTAM on the other side of active MPC is stopped and re-started. The MPC itself re-activates - because other read and write subchannels in the MPC group do become active.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All using FICON CTC/MPC connections. * **************************************************************** * PROBLEM DESCRIPTION: FICON CTCs (AHHC/MPC/CTC) subchannel * * INOPs after partner is stopped and * * restarted. For MPC/AHHC connections, * * the MPC group may become active even * * though an individual READ or WRITE * * device fails activation. * **************************************************************** * RECOMMENDATION: * **************************************************************** Sample Configuration: HOST1===FICON MPC===HOST2 The problem is summarized as follows: 1) A FICON MPC connection is active between two hosts. 2) The MPC connection is stopped from HOST2. 3) HOST1 recognizes the outage and tries to recover the MPC subchannels. 4) HOST1 times out while initiating X-side channel programs. 5) The MPC subchannels hang in Contact/Wait state at this point. 6) At this point, HOST2 restarts the MPC connection. 7) Upon restart, two asynchronous DE interrupts are received on HOST1. 8) HOST1 should wait for the second asynchronous DE or an ATTN for each subchannel, prior to initiating a Y-side channel program. 9) During the recovery of the MPC devices on HOST1, VTAM failed to reset the XCNURTRY bit when setting the state to Contact/Wait state. This led VTAM to erroneously initiate the Y-side channel program upon the receipt of the first asynchronous DE. 10) This caused the two sides to get out of synchronization with each other. A queued ATTN (in IOS) from XID0 processing was presented to HOST1 after the XID0 exchange occurred. This caused HOST1 to read in the XID7, thinking the partner initiated the XID7 processing. 11) Since HOST2 did not send XID7, HOST1 read in what it thought to be the XID7. An INOP occurred on HOST1 while verifying the XID7 contents (ISTTSCXI).
Problem conclusion
ISTTSCXI - Has been modified to set the XCNURTRY bit on when setting the XCNSSFSM to Contact/Wait state. This will cause ISTTSCCA to wait for a second asynchronous DE prior to redriving the Y-side channel program. ISTTSC8E - Included for maintenance purposes.
Temporary fix
Comments
APAR Information
APAR number
OA41355
Reported component name
VTAM V4 MVS/ESA
Reported component ID
569511701
Reported release
1A0
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-01-31
Closed date
2013-02-19
Last modified date
2013-02-19
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UA68093
Modules/Macros
ISTTSCXI ISTTSC8E
Fix information
Fixed component name
VTAM V4 MVS/ESA
Fixed component ID
569511701
Applicable component levels
R1A0 PSY
UP
[{"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":"1A0","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":"1A0","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
19 February 2013