PM70914: CATMAINT MSGDSNU778I DSNUEXDL - ERROR PROCESSING SQL STATEMENT DSNXISB5 SQLCODEM4732

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Error running V10 Catmaint
    DSNU778I  -ND2A 225 02:49:58.98 DSNUEXDL - ERROR PROCESSING SQL
    STATEMENT -
                   SQL CODE IS: -4732
                   SQLERRP: DSNXISB5
                   SQLERRD: 00000019 00000000 00000000 FFFFFFFF
    .
    .
        SQL MESSAGE TEXT: THE MAXIMUM NUMBER OF ALTERS ALLOWED
         HAS BEEN EXCEEDED FOR TABLE
        SQL STATEMENT:
         ALTER TABLE SYSIBM.SYSAUXRELS ADD "RELCREATED"
                   CHAR(1) NOT NULL WITH DEFAULT.
    .
    KEYWORD ADDED :  DB2MIGV10/K
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of the CATMAINT utility for        *
    *                 release migrations.                          *
    ****************************************************************
    * PROBLEM DESCRIPTION: The DB2 migration process fails with    *
    *                      a SQLCODE4732. This indicates that      *
    *                      there are no available version numbers  *
    *                      for a table being changed during the    *
    *                      migration process.                      *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The DB2 for z/OS migration process is failing because it is
    trying to ALTER a catalog table that has no available version
    numbers (SQLCODE4732).
    
    To correct the problem the subsystem must fall back to the
    release being migrated from so that the version numbers can
    be recycled.
    

Problem conclusion

  • DB2 release migrations will fail if an attempt to alter a
    catalog table fails because there are no available version
    numbers.
    
    DB2 catalog tables cannot be modified outside of the migration
    process (CATMAINT). These table modifications are generally
    done during the same commit scope to keep the number of used
    version numbers to a minimum. As such, there should be no cases
    where we are out of version numbers for catalog objects. But
    we have seen some cases where migrations are failing because
    there are no available version numbers (SQLCODE4732).
    
    We're not sure how the version numbers are being broken at
    this point. But in this APAR we are changing code that will
    fail utility processes that update version numbers when we
    detect that version numbers are going to be broken (ie where
    the SYSTABLESPACE.CURRENT_VERSION number will end up being
    less than SYSTABLESPACE.OLDEST_VERSION).
    
    In addition, we are changing the premigration checkout jobs,
    DSNTIJPM and DSNTIJPA, to add queries that will identify cases
    where the version numbers are bad. The premigration checkout
    jobs are to be run before migration processing begins (ie in
    the release being migrated from). If there is a version
    number problem then the version numbers can be corrected
    prior to the migration process. This will ensure that the
    migration process will not fail due to this problem.
    See the ++HOLD actions for this APAR for further guidance for
    using DSNTIJPM or DSNTIJPA.
    
    The following SELECT statement can be used to determine if
    there are catalog objects that have version number problems:
    
       SELECT SUBSTR(CREATOR,1,8) AS CREATOR,
              SUBSTR(NAME,1,8) AS NAME,
              OLDEST_VERSION,
              CURRENT_VERSION
         FROM SYSIBM.SYSTABLESPACE
        WHERE DBID = 6
          AND (CURRENT_VERSION < OLDEST_VERSION);
    
    If there are table spaces returned with this query then the
    version numbers can be corrected by a REORG of the table space
    and then by running MODIFY RECOVERY with DELETE to recycle
    version numbers. Additional information about version numbers
    can be found in the Utility Guide and Reference and also in
    the Administration Guide.
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PM70914

  • Reported component name

    DB2 OS/390 & Z/

  • Reported component ID

    5740XYR00

  • Reported release

    A10

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-08-14

  • Closed date

    2013-02-01

  • Last modified date

    2013-04-02

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

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

    UK91338 UK91339

Modules/Macros

  •    DSNTIJPA DSNTIJPM DSNUGUVR
    

Fix information

  • Fixed component name

    DB2 OS/390 & Z/

  • Fixed component ID

    5740XYR00

Applicable component levels

  • RA10 PSY UK91338

       UP13/02/16 P F302

  • R910 PSY UK91339

       UP13/02/16 P F302

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.



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

DB2 for z/OS

Software version:

A10

Reference #:

PM70914

Modified date:

2013-04-02

Translate my page

Machine Translation

Content navigation