IBM Support

PM62437: DBCTL ABENDU3275 WITH CHANGED DBRC AUTHORIZATION AND CICS RESYNC COMMIT THE INDOUBT EEQES.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Here is the sequence of events lead to the problem.
    1) IMS updated a full function database in normal.
    2) A Recoverable Indoubt Structure is created as result of a
       CICS failure. IMS issued DFS0693I to report the Indoubt
       EEQE. For example,
       DFS0693I RIS ESTABLISHED FOR PSB ZSZS22P ,PRTKN=000103B0,
                TOKEN=SCICOB  C8EB3D7BE4FE96B4
    3) DBR the full function database.
    4) Customer manually rename the DB dynamic allocation member
       to point to a copy of the database data set.
    5) STA the full function database with ACCESS=READ
       Because of the changed DB DSN, DBRC treated it as non-
       registered DB and issue DFS3341I to report the situation.
       For example,
       DFS3341I - DATA BASE HC001D01 IS USING DATA SETS NOT
       REGISTERED WITH DBRC
    6) The failed CICS restarted and committed the indoubt EEQE.
       For example,
       DFS0699I RESYNC COMMIT COMPLETE FOR PSB ZSZS22P ,
                PRTKN=00010300, TOKEN= SCICOB  C8EB3D4FBB8F4524
    7) IMS abend u3275 on DBOPEN with DFS030I REASON=0C, RC=16
    .
    The problem here is IMS allows the DBR with existing indoubt
    EEQEs. When the CICS restarted and decide to commit the indoubt
    EEQEs, DBRC must update the database to continue the processes.
    But the database authorization has been changed, hence abend.
    We should not allow the DBR with existing indoubt EEQEs.
    .
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All IMS V10 users who issue /DBRECOVERY      *
    *                 commands against Full Function databases     *
    *                 that have INDOUBT EEQEs.                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: ABENDU3275 occurred during a CICS       *
    *                      restart when trying to access a         *
    *                      database, with INDOUBT EEQEs,           *
    *                      that had its authorization              *
    *                      state changed to READ after being       *
    *                      taken offline with a /DBR DB command.   *
    ****************************************************************
    * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
    ****************************************************************
    Here is the sequence of events that led to the problem.
    1. A full function database was updated but not all changes were
       committed.
    2. A Recoverable Indoubt Structure (RIS) was created as result
       of a CICS failure. Message DFS0693I was issued to report
       the Indoubt EEQE. For example,
       DFS0693I RIS ESTABLISHED FOR PSB PSBname ,PRTKN=000103B0,
                TOKEN=SCICOB  C8EB3D7BE4FE96B4
    3. The database was taken offline with a /DBR DB command.
    4. Customer manually renamed the database dynamic allocation
       member to point to a copy of the database data set. This is
       part of the customer's database reorganization procedure.
       They normally STOP/DEALLOCATE the "production" database and
       make a copy of the database available with READ only access
       using a different dataset.
       Here are the steps to accomplish this:
       - Stop the database with /STO DB
       - Take the database offline with /DBR DB
       - Rename the dynamic allocation member to point to a copy of
         the database data set
       - Start the same database with ACCESS=READ. Now the copy of
         the database, with different data set name (DSN), is
         available for READ access
         Because of the changed database DSN, DBRC treats it as non-
         registered database and issues message DFS3341I to report
         the situation.
         For example,
         DFS3341I - DATA BASE DBname IS USING DATA SETS NOT
         REGISTERED WITH DBRC
       - When the reorganization of the database in the original
         dataset is complete the same sequence of commands is
         executed to make the reorganized database data set
         available to IMS
    5. The failed CICS is restarted and protected conversation work
       from the earlier created RIS is committed.
       For example,
       DFS0699I RESYNC COMMIT COMPLETE FOR PSB PSBname ,
                PRTKN=000103B0, TOKEN=SCICOB  C8EB3D7BE4FE96B44
    6. An ABENDU3275 with message DFS030I REASON=0C, RC=16 is
       received during database open processing because it appears
       to DBRC that the subsystem was not authorized to update the
       database.
    .
    The problem is that IMS allows the database with existing
    indoubt EEQEs to be taken offline with a /DBR command.  When the
    CICS is restarted and attempts to commit the indoubt EEQEs, IMS
    must update the database as part of the process, but the
    database authorization has been changed which causes the
    failure.  IMS should not allow the DBR with existing indoubt
    EEQEs.
    
    Additional keywords: MSGDFS0488I MSGDFS0693I MSGDFS0699I
                         MSGDFS3341I CMDDBR DBRCMD CMDSTA STACMD
                         CMDSTO STOCMD MSGDFS030I RSN0C RC16 RC43
    

Problem conclusion

  • GEN:
    KEYWORDS:
    
    *** END IMS KEYWORDS ***
    A new keyword, NODBR, has been added and can be specified in the
    DFSVSMxx member.  When this keyword is specified a /DBR command
    for any database that has an INDOUBT EEQE will not be processed
    and message DFS0488I RC=43 will be issued.
    
    Note:
    While this APAR does not need to be applied to all SYSPLEX
    members at the same time, when sharing a DFSVSMxx member across
    a SYSPLEX, the new keyword will have no effect on SYSPLEX
    members that do not have the APAR applied.
    
    The following parts were changed to allow the user to cause a
    /DBR command to be rejected for a database that has an INDOUBT
    EEQE.
    
    * ISCD *
    Bit SCDNODBR was added to flag SCDDBFLG to indicate the user
    wants to fail a /DBR command for any database that has an
    INDOUBT EEQE.
    
    * DFSDVBI0 *
    Code was added to turn on SCDNODBR if the user specified the
    NODBR keyword in the DFSVSMxx member.
    
    * DFSDBDR0 *
    Code was added to fail the /DBR process and issue message
    DFS0488I RC=43 for any database that has an INDOUBT EEQE if
    the SCDNODBR bit is on.
    
    IMS V10 Messages and Codes Reference, Volume 1, GC18971202,
    will be updated with the following under message DFS0488I:
    
    Add return code
    43 - The named database cannot be processed in response to a
         /DBRECOVERY command because one or more INDOUBT EEQEs
         exist for the database and the NODBR keyword was specified
         in the DFSVSMxx member.
    
    V10 IMS Command Reference, Volume 1, SC18970002, will be
    updated with the following:
    
    Under "Usage notes" for the /DBRECOVERY command add:
    
    The NODBR keyword can be specified in the DFSVSMxx member to
    prevent a /DBRECOVERY command from processing against a database
    that has INDOUBT EEQEs.
    
    V10 IMS System Definition Reference manual, GC18996602,
    will be updated with the following:
    
    Under the section DFSVSMxx in the 'Members of the IMS Proclib
    data set' add section:
    
    "Preventing a /DBRECOVERY command for a database that has
    INDOUBT EEQEs"
    
    >>-NODBR-----------------------------------------------------><
    
    NODBR
        This statement causes a /DBRECOVERY command to fail if the
        command is issued against a database that has INDOUBT EEQEs.
    

Temporary fix

  • *********
    * HIPER *
    *********
    DO NOT /DBR A DATABASE THAT HAS INDOUBT EEQE.
    

Comments

APAR Information

  • APAR number

    PM62437

  • Reported component name

    IMS V10

  • Reported component ID

    5635A0100

  • Reported release

    010

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-04-13

  • Closed date

    2013-01-08

  • Last modified date

    2013-02-04

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

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

    PM74751 PM74753 UK90789 PM81178

Modules/Macros

  • DFSDBDR0 DFSDVBI0 ISCD
    

Publications Referenced
GC18996602SC18970002GC18971202  

Fix information

  • Fixed component name

    IMS V10

  • Fixed component ID

    5635A0100

Applicable component levels

  • R010 PSY UK90789

       UP13/01/15 P F301 Ž

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":"10.1","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":"10.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
04 February 2013