A fix is available
APAR status
Closed as program error.
Error description
After cancel two CICS connected via IPIC, a severe error x'180' in module DFHISRE is issued when the CICS are restarted and the IPIC connection tries to be re established, because some UOW was indoubt state. On CICS restart the resync'd UOW is recovered by the 2 CICS regions which attempt to resync again. This time the UOWLINKs are in a forward state. remote_uow_status = rmln_forward instead of remote_uow_status = rmln_indoubt when the first resync was attempted. This produces a soft error from recovery manager on the RMLN SET_RECOVERY_STATUS - EXCEPTION REASON RMLN_ALREADY_SET. DFHISRE routine isre_set_recovery_status should tolerate and handle this exception but instead raises an error which causes to take the wrong codepath leading to DFHIS0002 reason code 180C.
Local fix
No Local Fix
Problem summary
**************************************************************** * USERS AFFECTED: All * **************************************************************** * PROBLEM DESCRIPTION: MSGDFHIS0002 severe error code 180C * * during IPIC reconnection. * **************************************************************** * RECOMMENDATION: * **************************************************************** Message DFHIS0002 reason code X'180C' occurs when re-establishing an IPCONN connection following a warm or emergency restart. DFHISRE is attempting to RESYNC a UOW with another CICS region which has been RESYNC'd in a previous CICS run but where CICS terminated abnormally before the forget of the RESYNC was hardened. This time the remote_uow_status of the ISCI RMLINK is RMLN_FORWARD rather than RMLN_INDOUBT when the first RESYNC occurred. When DFHISRE attempts to set the recovery status of the link to FORWARD it receives an exception from DFHRMLN indicating that the state is already set. DFHISRE should treat this response as a soft error but instead it takes an error path which means that recovery manager is not notified that the UOW should be terminated. It also fails to send a response to the IPIC partner which initiated the RESYNC. This leaves the IPIC session being used by the RESYNC task in SEND state. The RESYNC task loops around and issues an IPIC RECEIVE to obtain the next RESYNC request from the partner CICS. This receive fails because the IPIC session is still in SEND state. The receive error results in the DFHIS0002 message and IS0002 system dump. The IPCONN is left in OBTaining state and is unusable.
Problem conclusion
The DFHISRE routine which sets the recovery state of a CICS to CICS UOW during resync processing ( isre_set_recovery_status ) has been changed to tolerate a response of RMLN_EXCEPTION with reason RMLN_ALREADY_SET.
Temporary fix
FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PM08780
Reported component name
CICSTS V3 Z/OS
Reported component ID
5655M1500
Reported release
400
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2010-03-02
Closed date
2010-05-20
Last modified date
2010-06-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PM14323 UK57185
Modules/Macros
DESISRE DFHISRE
Fix information
Fixed component name
CICSTS V3 Z/OS
Fixed component ID
5655M1500
Applicable component levels
R500 PSY UK57185
UP10/05/27 P F005
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":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"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":"3.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 June 2010