A fix is available
APAR status
Closed as program error.
Error description
ABEND0C6 receieved on ODBA ITASK while trying to return using a save area that is already marked as returned with the low order bit being set on. . This abend occurs during terminating synchpoint processing after the backout exit is driven. Backout processing completes, at which time EOT processing kicks off and completes prior to terminating synchpoint processing. Terminating synchpoint cleanup receives the ABEND0C6.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of IMS v11 ODBA * **************************************************************** * PROBLEM DESCRIPTION: Double use of savearea during * * terminating syncpoint may lead to * * ABEND0C6 or other symptoms. * **************************************************************** * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** In an ODBA environment with RRS enabled, there are two separate code paths that are driven if a thread or dependent region terminates abnormally. There is a timing issue where these code paths can interfere with one another, causing the double use of a save area. This double use of a save area can lead to a variety of external symptoms. In the reported case, the customer encounters an ABEND0C6 when a module attempts to return to its caller using a return address for which the low order bit has already been set -- the branch target is invalid because it is not on a halfword boundary. Code path 1: RRS detects that the dependent region address space is coming down and drives DFSRRSI0, which calls DFSAERN0 to process a terminating syncpoint. DFSAERN0 calls modules to process the syncpoint, then clean up the thread. It then responds to RRS for post deferred UR processing. Code path 2: DFSSDA20 is driven by a terminate identify AWE. This module performs serveral tasks needed to clean up dependent region control blocks in the event of abnormal termination. This includes cleaning up the thread. The problem comes as a result of both code paths attempting to clean up the thread. There is a flag, LCRTODBA, defined in the LCRE that is intended to prevent this from happening. Each code path sets the flag to indicate that it is handling thread cleanup, and will not drive thread cleanup if the other code path has already set the flag. The defect exists because there is a way for the DFSRRSI0 path to drive thread cleanup without setting LCRTODBA.
Problem conclusion
GEN: KEYWORDS: *** END IMS KEYWORDS *** In the LCRE, a new flag is defined and an existing flag is moved so that the DFSRRSE0 and DFSSDA20 processing can be better coordinated. DFSRRSI0 is changed because it uses the flag that is moved. DFSSDA20 contains more extensive changes to the way it handles abnormal ODBA thread termination. Module changes -------------- DFSLCRE - A new flag byte, LCREF5, is defined using existing reserved space in the control block. The existing flag LCRTODBA is moved from LCREF1 to LCREF5. A new flag, LCRTTRM1, is defined in LCREF5. This new flag is set by DFSSDA20 the first time it is called to process a terminating syncpoint for the LCRE in question. This allows DFSSDA20, when it is re-driven for PST cleanup, to detect that it has been called a second time. The reason LCRTODBA is moved is that during DFSSDA20 terminating syncpoint processing, the flags in LCREF1 through LCREF4 are cleared. This creates a timing window where DFSRRSE0 can check LCRTODBA after it has already been cleared, resulting in DFSRRSE0 attempting to drive thread cleanup even though DFSSDA20 is already doing so. LCREF5 is not affected by this, so moving the flag removes this timing exposure. DFSRRSI0 - This module checks and sets LCRTODBA as part of terminating syncpoint processing. This flag is moved from LCREF1 to LCREF5, so DFSRRSI0 is changed to reflect this. DFSSDA20 - Multiple changes are made for terminating syncpoint processing. References to LCRTODBA are changed to use LCREF5 instead of LCREF1. On the second pass through DFSSDA20, if LCRTTRM1 has been set, skip checking LCRTODBA and go directly to label SDA20550, where CLEANPST will be called. The tracing call at SDA20550 is moved to label TMSETUP so that the trace will be written only once, during the first pass. It will no longer be written a second time during the second pass through DFSSDA20. Additional keywords: ABEND0C6
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PM91423
Reported component name
IMS V11
Reported component ID
5635A0200
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-06-19
Closed date
2014-10-10
Last modified date
2014-11-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
DFSLCRE DFSRRSI0 DFSSDA20
Fix information
Fixed component name
IMS V11
Fixed component ID
5635A0200
Applicable component levels
R100 PSY UI22128
UP14/10/15 P F410
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":"100","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCVRBJ","label":"System Services"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"100","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
04 November 2014