DB2 10 CATMAINT failure
agburke 060001QPDN Visits (1911)
Regarding the DB2 for z/OS migration process, customers have seen failures due to ALTERing a catalog table that has no available version numbers (SQLCODE4732).
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,
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.
· PM70914 – DB2 migration fails due to catalog tables having incorrect version numbers