IBM Support

PM86367: DEPENDENT REGIONS HUNG IN TERM-THRD, WAITING IN DBFATRM0 FOR FNCB LATCH.

A fix is available

Subscribe

You can track all active APARs for this component.

 

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:

    PM85338

  • 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