A fix is available
APAR status
Closed as program error.
Error description
Many dependent regions hung in TERM THREAD waiting for FNCB ELOCK in DBFATRM0. ESCDNLAT shows lock is owned by an EPST no longer in TERM THREAD. DBFATRM0 attempts to prevent U0113 abends by checking EPSTW2FN on terminating EPSTs to determine if they were waiting for FNCB ELATCH when the abended. If the bit is on, a STIMER is issued to wait 2 seconds, and then the bit checked again. If bit is no longer on then it is assumed latch was granted and it can be released. However, this logic is wrong, as EPSTW2FN is only reset in the expansion of DBFELOCK after EPST is redispatched after being posted out of the IWAIT, which will never happen. A path is then taken to SETU113, but this will only trigger a U0113 abend if running under CTL TCB and not DEP, so it is possible for an EPST to escape DBFATRM0 while either holding ( from ESCDNLAT ) the latch or waiting for it. This will cause the latch to eventually be stranded. Also, the STIMER value is coded wrongly, it is actually approximately 5 seconds not 2 seconds, and there is no check to prevent it being issued if DBFATRM0 is running under CTL TCB, which would not be acceptable. DBFATRM0 is called for both normal and abnormal termination and both paths get the FNCB latch, so once the latch is stranded terminations will hang. Finally, code executed by dependent regions which might be targeted with /STO REG ABDUMP should set SAPX4ADS (ABDUMP SYNC) to defer U0474 at least while obtaining and releasing FNCB latch. DBFATRM0 and DBFNOTM0 are examples.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: IMSFP V13 users. * **************************************************************** * PROBLEM DESCRIPTION: DEPENDENT REGIONS HUNG IN TERM-THRD, * * WAITING IN DBFATRM0 FOR FNCB LATCH. * **************************************************************** * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** Many dependent regions hung in TERM THREAD waiting for FNCB ELOCK in DBFATRM0. ESCDNLAT shows lock is owned by an EPST no longer in TERM THREAD. DBFATRM0 attempts to prevent U0113 abends by checking EPSTW2FN on terminating EPSTs to determine if they were waiting for FNCB ELATCH when the abended. If the bit is on, a STIMER is issued to wait 2 seconds, and then the bit checked again. If bit is no longer on then it is assumed latch was granted and it can be released. However, this logic is wrong, as EPSTW2FN is only reset in the expansion of DBFELOCK after EPST is redispatched after being posted out of the IWAIT, which will never happen. A path is then taken to SETU113, but this will only trigger a U0113 abend if running under CTL TCB and not DEP, so it is possible for an EPST to escape DBFATRM0 while either holding ( from ESCDNLAT ) the latch or waiting for it. This will cause the latch to eventually be stranded. Also, the STIMER value is coded wrongly, it is actually approximately 5 seconds not 2 seconds, and there is no check to prevent it being issued if DBFATRM0 is running under CTL TCB, which would not be acceptable. DBFATRM0 is called for both normal and abnormal termination and both paths get the FNCB latch, so once the latch is stranded terminations will hang. Finally, code executed by dependent regions which might be targeted with /STO REG ABDUMP should set SAPX4ADS (ABDUMP SYNC) to defer U0474 at least while obtaining and releasing FNCB latch.
Problem conclusion
GEN: KEYWORDS: *** END IMS KEYWORDS *** The following changes have been made to correct the reported problem: DBFATRM0: - Update code to check EPSTT1,EPSTT1FN if it has not posted from a notify response, abend U113 will be issued. - Add DFSXMWIN ABDUMP_SYNC surround FNCB latch obtain to defer U474 if /sto region abdump was issued. - Correct STIMER value of two seconds. - Add code to to defer U474 if running under CTL TCB. DBFNOTM0: - Add DFSXMWIN ABDUMP_SYNC surround FNCB latch obtain to defer U474 if /sto region abdump was issued. - Add code to to defer U474 if running under CTL TCB.
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PM86367
Reported component name
IMS V13
Reported component ID
5635A0400
Reported release
300
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-04-04
Closed date
2013-05-10
Last modified date
2013-10-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK94205
Modules/Macros
DBFATRM0 DBFNOTM0
Fix information
Fixed component name
IMS V13
Fixed component ID
5635A0400
Applicable component levels
R300 PSY UK94205
UP13/05/14 P F305 ¢
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"},"Platform":[{"code":"PF054","label":"z Systems"}],"Version":"300","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
14 December 2020