Bharath's Tech Blog

X‘00E4D5D2’ ABEND code

Using Redirected Recovery component of IBM DB2 Recovery Expert for z/OS v3.2, I created a new Tablespace structure in QA region based on Tablespace structure present in Prod region and migrated data from Prod to QA.

After Data migration is done, I tried the following.

è Online RUNSTATS utility on the Target Tablespace.

It failed with the below error message.

DSNU017I    173 12:57:34.10 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347' CAUSE=X'00E4D5D2'

è Online REORG utility on the Target Tablespace. It failed with below error messages.

DSNU017I    174 09:20:16.00 DSNUGSAT - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E4D5D2'

DSNU016I    174 09:20:17.38 DSNUGBAC - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

è Finally, unloaded the data from Source Tablespace (in Prod) and loaded the same into Target Tablespace (in QA) using LOAD REPLACE (with inline statistics).

This worked perfectly fine.

X’00E4D5D2’ ABEND code is something new which I haven’t seen earlier. So, created PMR to IBM to find out more details about the ABEND code. Got the below response from IBM tech support.

The 00E4D5D2 is an indication of a sanity check that was introduced by APAR PK98262 and sourced into DB2 10.  This sanity check was introduced to fail a utility if it finds versioned data records on a non-data-versioned table. I'm wondering if you refreshed this object with DSN1COPY from another subsystem.  You would get this error if the object from the source system was versioned and your target system is not versioned.  This can happen when customers want to test data from one system on a different system.  They create the object on the target system so it matches the layout of the source system.  But, the source system object had been versioned over time.  Then when you run the RUNSTATS or REORG and you get the 00E4D5D2. The same thing can happen if you use flash copies to migrate data. To correct this situation you can run a REPAIR VERSIONS.  This utility updates the catalog with the information from the header pages.  After running the REPAIR VERSIONS, if this is the situation, the RUNSTATS or REORG should then run as expected. 

After reading the message, checked the Source Tablespace (in Prod), and found that it’s versioned. Tablespace versioning details can be found using the below SQL query.

SELECT

   DBNAME

  ,NAME

  ,OLDEST_VERSION

  ,CURRENT_VERSION

FROM SYSIBM.SYSTABLESPACE

WHERE

   DBNAME='LPALIF' AND

   NAME='TSABNBNC'

WITH UR;

The output of above query is

You can see that OLDEST_VERSION and CURRENT_VERSION are having different values. As the Source Tablespace is versioned, Target Tablespace is also created as versioned. And, this lead to the failure of RUNSTATS and REORG utilities on the Target Tablespace.

In this is the situation, the REPAIR VERSIONS will resolve the issue.  It updates the DB2 catalog with the information from the header pages of the Tablespace. After running the REPAIR VERSIONS utility, the REORG should run successful.
For more details about REORG for fixing versioning, below web link can be referred.

https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.ugref/src/tpc/db2z_effectsrunningreorgtablespace.html