IBM Support

PM69760: MSGIXC522I RSN=00000008 WHEN ATTEMPTING TO REBUILD SCA STRUCTURE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The commands SETXCF START,REALLOCATEand SETXCF START,RB,
    STRNAME=xxxx_SCA incurred the messages:
    IXC522I REBUILD FOR STRUCTURE xxxx_SCA IS BEING STOPPED TO
    FALL BACK TO THE OLD STRUCTURE DUE TO CONNECTOR SPECIFIC REASON
    USER CODE: 00000008
    IXC521I REBUILD FOR STRUCTURE xxxx_SCA HAS BEEN STOPPED
    
    
    
    DSN7504I  -ssid DSN7LST2 SCA STRUCTURE xxxx_SCA REBUILD
    UNSUCCESSFUL, REASON CODE = 8 is displayed.
    Right before the DSN7504I, there was DSNT376I indicating timeout
    from CORRELATION-ID=014.RBDBET01, holder is thread with
    CORRELATION-ID=020.STOPDB09 (from -STOP DB command).
    DSNT501I DSNILMCL RESOURCE UNAVAILABLE is also issued with
    CORRELATION-ID=014.RBDBET01, REASON 00C900C0, TYPE 00002105
    and NAME INTERNAL LOCK.
    ----------------------------------------------------------------
    .
    Exposure if the enabling APAR PM74803 were to be applied on any
    member before applying the preconditioning APAR PM69760:
    The exposure is that if SCA REBUILD is running and there is a
    concurrent DBET activity (e.g. a utility running on a member
    without the enabling APAR PM74803 and turning on UTRW), members
    that have the enabling APAR on might ignore the notify to turn
    on an exception state for an object. So members in the group
    could get out of synch between each other with regard to a DBET
    state - some will have it turned on, some won't, which could
    lead to allowing access to the object when it should be
    protected by DBET state. However, this chance for inconsistency
    is only if there is SCA REBUILD running and only if the member
    that has the enabling APAR on isn't the one driving the DBET
    activity (and therefore originating DBET notifies).
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All DB2 10, DB2 9 and DB2 V8 for z/OS data   *
    *                 sharing users of the z/OS SETXCF REBUILD     *
    *                 command when issued against SCA              *
    ****************************************************************
    * PROBLEM DESCRIPTION: Timeout MSGDSNT376I MSGDSNT501I with    *
    *                      RC00C900C0 TYPE00002105 may occur in    *
    *                      data sharing when a REBUILD of the SCA  *
    *                      structure is issued (e.g.               *
    *                      SETXCF START,REBUILD,STRNM=DSNCAT_SCA), *
    *                      resulting in stoppage of the rebuild,   *
    *                      with messages MSGDSN7504I, MSGIXC522I   *
    *                      and MSGIXC521I                          *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    REBUILD of the SCA structure may experience a timeout on
    resource type 00002105 when running concurrently with
    database exception table (DBET)-heavy activity such as during
    utility workloads that turn on/off various DBET states like
    UTRW, RBDP etc.
    
    The following sample illustrates the issue:
    ----------------------------------------------------------------
    DSNT376I  - PLAN=BCT      WITH 398
            CORRELATION-ID=014.RBDBET01
            CONNECTION-ID=V91A
            LUW-ID=DSNCAT.SYEC1DB2.CA3071BF1397
            THREAD-INFO=SYSOPR:*:*:*
            IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=
    WITH
            CORRELATION-ID=020.JOBSTO07
            CONNECTION-ID=V91A
            LUW-ID=DSNCAT.SYEC1DB2.CA3071B10954=7
            THREAD-INFO=SYSOPR:*:*:*
            ON MEMBER V91A
    
    DSNT501I  - DSNILMCL RESOURCE UNAVAILABLE 399
               CORRELATION-ID=014.RBDBET01
               CONNECTION-ID=V91A
               LUW-ID=DSNCAT.SYEC1DB2.CA3071BF1397=0
               REASON 00C900C0
               TYPE 00002105
               NAME INTERNAL LOCK 05
    
    DSN7504I  - DSN7LST2 400
    SCA STRUCTURE DSNCAT_SCA REBUILD UNSUCCESSFUL. REASON CODE =  8.
    
    IXC522I REBUILD FOR STRUCTURE 401
    DSNCAT_SCA IS BEING STOPPED
    TO FALL BACK TO THE OLD STRUCTURE DUE TO
    CONNECTOR SPECIFIC REASON
     USER CODE: 00000008
    
    IXC521I REBUILD FOR STRUCTURE DSNCAT_SCA 405
    HAS BEEN STOPPED
    ----------------------------------------------------------------
    
    The reason for the timeout of the SCA REBUILD is that a mainline
    DBET updater (e.g. a utility) is suspended (while holding the
    DBET hash lock) by the SCA REBUILD process. When the SCA REBUILD
    tries to obtain the same lock, it cannot do so because the
    holder is suspended and therefore the SCA REBUILD times out.
    

Problem conclusion

  • Code has been changed to adjust the serialization scheme
    between mainline DBET updaters and the SCA REBUILD process.
    
    For the timing window when the SCA REBUILD tries to obtain the
    DBET hash lock while a mainline DBET updater is in the notify
    exit path, the SCA REBUILD timeout will not be resolved until
    a future enabling APAR, which should be applied only after
    APAR PM69760 has been applied on all data sharing members.
    
    Additional keywords: DB2DSHR SYSPLEXDS
    

Temporary fix

  • *********
    * HIPER *
    *********
    

Comments

APAR Information

  • APAR number

    PM69760

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    910

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-07-27

  • Closed date

    2012-10-09

  • Last modified date

    2013-02-26

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

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

    UK82739 UK82740 UK82741

Modules/Macros

  • DSNIDBAB DSNIDBGC DSNIDBHK DSNIDBMS DSNIDBNG
    DSNIDBNI DSNIDBPL DSNLCMT2 DSNLTBAB DSNLTLCS DSNLTRD  DSNLTRSI
    DSNLTWCP DSN7GJON DSN7LDE1 DSN7LRE1 DSN7LWR1 DSN7TGLM
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UK82739

       UP12/10/31 P F210

  • R810 PSY UK82740

       UP12/10/31 P F210

  • R910 PSY UK82741

       UP12/10/31 P F210

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":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.1","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"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":"9.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
26 February 2013