IBM Support

PK82081: ODBM THREADS HUNG DURING VOLUME/STRESS TESTING.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • ODBM threads were hung because max TCBs of 60 was reached and
    all 60 ODBT TCBs (ODBR AWE servers) were waiting in IMS block
    mover in the IMS APSB scheduler process for pool space. There
    was no more pool space because of all the outstanding work
    that was still in progress (ie.  DPSBs have not been done
    yet), but this outstanding work could not complete because
    all 60 of the ODBM TCBs were hung waiting to complete APSB
    requests.  Thus, all new requests arriving for existing
    threads in progress (ie.  DLI calls, etc) were getting
    queued by BPE, awaiting any ODBM AWE server to process it.
    This is PTM KB50120
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All IMS V11 Open Database users              *
    ****************************************************************
    * PROBLEM DESCRIPTION: KB50120:                                *
    *                      Hung threads in ODBM                    *
    *                                                              *
    *                      KB50126:                                *
    *                      ABENDU0711-10 in module DFSRRSI0 with   *
    *                      OpenDB XA environment.  Reg2 at abend   *
    *                      contains F00x                           *
    *                                                              *
    *                      KB30416:                                *
    *                      OpenDB XA Error Scenario:               *
    *                      ABENDU0768-02 in DFSISWIT               *
    *                                                              *
    *                      KB30417:                                *
    *                      OpenDB XA Error Scenario:               *
    *                      ABENDU0769-02 in DFSIDSP0.  ABENDU0770  *
    *                      can also occur.                         *
    ****************************************************************
    * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
    ****************************************************************
    KB50120:
    ODBM threads were hung because max TCBs of 60 was reached and
    all 60 ODBT TCBs (ODBR AWE servers) were waiting in IMS block
    mover in the IMS APSB scheduler process for pool space.  There
    was no more pool space because of all the outstanding work that
    was still in progress (ie.  DPSBs have not been done yet), but
    this outstanding work could not complete because all 60 of the
    ODBM TCBs were hung waiting to complete APSB requests.  Thus,
    all new requests arriving for existing threads in progress (ie.
    DLI calls, etc) were getting queued by BPE, awaiting any ODBM
    AWE server to process it.
    
    
    KB50126:
    Stress test with XA RAR with 300 users gives IMS U711-10 abend.
    ABENDS0C4 is the real problem and occurs in the ATRPDUE RRS
    service itself because the ATRPDUE parm area was overlaid.  The
    ATRPDUE parm area (PSTLOGWA) was overlaid because another
    request arrived for the same PST due to the RRS post deferred
    processing that completed and caused control to be returned to
    the client.  However, before RRS could set the return code for
    the ATRPDUE call and return to the caller, the new request from
    the client caused the PSTLOGWA ATRPDUE parm area to get
    overlaid.  Thus, RRS ATRPDUE encountered an 0C4 when it grabbed
    a bad address from the parm area for the return code pointer.
    
    
    KB30416:
    This was occuring because IMS Connect was not waiting for the
    internal CSLDMI DPSB call to complete before issuing ATRABAK.
    Thus, we had two tasks active processing the same IMS ITASK (ie.
    the same PST) simultaneously for DPSB processing and for RRS
    BACKOUT exit processing.
    
    DFS629I IMS ODS TCB DUMP  - IMS 0768          IMS1
    DFS0693I RIS ESTABLISHED FOR PSB DFSSAM02,  034
    PRTKN=00010040, TOKEN=ODBA00320000000B00000000 IMS1
    DFS629I PSW AT ERROR = 077C1000 8A1986C4  IMS1
    DFS629I MODID = DFSISWIT          EPA = 0A3AFECA  IMS1
    DFS629I R0-3   80000000 80000300 0A1A0160 8A429C82
    DFS629I R4-7   09F90CA0 00000000 40401000 00400000
    DFS629I R8-11  09691040 09691060 895004A0 00C5E840
    DFS629I R12-15 0A19A100 09FF0B80 C0C88001 00000002
    
    
    KB30417:
    This was occuring because IMS Connect was not waiting for the
    internal CSLDMI DPSB call to complete before issuing ATRABAK.
    Thus, we had two tasks active processing the same IMS ITASK (ie.
    the same PST) simultaneously for DPSB processing and for RRS
    BACKOUT exit processing.
    
    DUMP01 TITLE=IMS1     ABEND SYS 000 USER 0769    , DATE.TIME:
                 075.223319, CALLER=CTL , TCB=CTL, MODULE=UNKNOWN ,P
        DUMP TAKEN TIME=22.33.20 DATE=03/16/2009
        ERRORID=SEQ00052 CPU0000 ASID002C TIME=22.33.15
        USER   ABEND CODE=0769 REASON CODE=00000000
        MODULE=DFSIDSP0 CSECT=*UNKNOWN
        PSW AT TIME OF ERROR=077C1000 8A192ECE ILC=2 INT=0D
        TRANSLATION EXCEPTION ADDR=00000000
        ABENDING PROGRAM ADDR=******** RECOVERY ROUTINE=********
        GPR 0-3   80000000  80000301  00000000  80C4B0EB
        GPR 4-7   0A19BB80  00000004  0A19BC50  0FC4E2D7
        GPR 8-11  09684040  0968B040  8A113BA0  00C5E840
        GPR12-15  0A195100  0A189478  0A192244  00000002
    
    Other symptoms of this problem include U0770 abend and S0C4
    abend in the JES SSI (Subsystem Interface):
    
    DUMP00 TITLE=COMPON=SSI,COMPID=5752SC1B6,ISSUER=IEFJSARR,
                 MODULE=IEFJSRE1,ABEND=S0C4,REASON=00000011,
                 SNAME=IMS1
        DUMP TAKEN TIME=22.33.15 DATE=03/16/2009
        ERRORID=SEQ00051 CPU0000 ASID0032 TIME=22.33.13
        SYSTEM ABEND CODE=0C4  REASON CODE=00000011
        MODULE=IEFJSRE1 CSECT=IEFJSRE1
        PSW AT TIME OF ERROR=077C4000 826373E8 ILC=4 INT=11
        TRANSLATION EXCEPTION ADDR=00600001
        ABENDING PROGRAM ADDR=******** RECOVERY ROUTINE=IEFJSARR
        GPR 0-3   00000001  0967F040  0A4D5738  0967F040
        GPR 4-7   00000000  00002E00  006FF048  09644120
        GPR 8-11  0967F040  00600000  0968C060  00C5E840
        GPR12-15  82637150  00000000  89652FEE  00000731
    
    
    Additional Keywords:
    OPENDB OPENDATABASE U0711 R2=F00 R2=X'F00' R2='F00'X S0C4
    U769 U768 U770 U0770 ABENDU0770
    

Problem conclusion

  • GEN:
    KEYWORDS:
    
    *** END IMS KEYWORDS ***
    KB50120:
    CSLDANCH
    Added fields ANCH_APSBQCNT and ANCH_APSBTATT
    
    CSLDAWXI
    Added new AWE functions AWXI_FUNCDMIC_APSB and AWXI_FUNCDMI_APSB
    
    CSLDBAWI
    CSLDBAW0
    Added new APSB AWE server
    
    CSLDBR00
    CSLDBR10
    Added logic to support the new AWE functions AWXI_FUNCDMIC_APSB
    and AWXI_FUNCDMI_APSB for APSB offload.
    
    CSLDBTCI
    CSLDBTC0
    Added new APSB TCBs
    
    CSLDCODE
    Added new functions DCOD_DMIC_APSB and DCOD_DMI_APSB
    
    CSLDDM00
    Use new ANCH_ODBTTMAX equate
    
    CSLDIN00
    Initialize new anch_apsbtatt field
    
    CSLDTFM0
    CSLDTF10
    CSLDTRC
    Trace info for new function codes.
    
    
    KB50126:
    DFSRRSI0
    Code has been added to ensure that ATRPDUE can properly return
    to DFSRRSI0 without abending.
    
    
    KB30416:
    KB30417:
    DFSAERC0
    Changed logic to check dsphase1 to determine whether or not to
    clear the RRS LCRE fields.
    
    DFSDABN0
    Clear the RRS LCRE fields.
    
    DFSDAST0
    Turn on bit LCR4PRAB so the subsequent DFSSYNC ABTERM call will
    perform backout even if we are InDoubt.
    
    DFSDSC00
    Check bit LCR4PRAB to determine if backout should be performed
    even though the thread might be InDoubt.
    
    HWSMREC0
    HWSMXMT0
    HWSNDXMT
    Convert the CSLDMI DPSB call to synchronous by specifying the
    ECB paramater.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PK82081

  • Reported component name

    IMS V11

  • Reported component ID

    5635A0200

  • Reported release

    100

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2009-03-08

  • Closed date

    2009-06-10

  • Last modified date

    2010-01-04

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK47340

Modules/Macros

  • CSLDANCH CSLDAWXI CSLDBAWI CSLDBAW0 CSLDBR00
    CSLDBR10 CSLDBTCI CSLDBTC0 CSLDCODE CSLDDM00 CSLDFM0F CSLDIN00
    CSLDTFM0 CSLDTF10 CSLDTRC  CSLD1ENU DFSAERC0 DFSAPST0 DFSASK00
    DFSDABN0 DFSDAST0 DFSDSC00 DFSDTTA0 DFSRRSI0 HWSMREC0 HWSMXMT0
    HWSNDXMT IPST
    

Fix information

  • Fixed component name

    IMS V11

  • Fixed component ID

    5635A0200

Applicable component levels

  • R100 PSY UK47340

       UP09/06/25 P F906

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 January 2010