Our first test subsystem migration occurred on August 11th followed the next day by another migration and then we let those “burn-in” for over a week before planning any additional migrations. We did not experience any issues with the first two migrations so on August 24th we migrated 5 more test DB2 subsystems.
Problems identified after 5 additional test subsystem migrations.
- -805 SQL Error on common packages DSNTIAD but further research found that the PLAN PKLIST was specified incorrectly and rebinding the PLAN corrected the issues.
- -805 SQL Error on package DSNUTIL.DSNUGSQL due to remote SQL access to a DB2 10 subsystem. We remote bound this new DB2 11 package version to each DB2 10 subsystem to ensure this error did not occur for any other applications.
- Failures S04E level ID error. Noticed error running DB2 utilities but the failure occurred if DB2 attempted to access these particular tablespaces at all. Opened Service Request to IBM and they identified the issue was caused due to old SYSLGRNX entries on some tablespaces which was basically fallout from the Y2K bug. Applied a fix to allow us to run MODIFY to cleanup old rows from SYSLGRNX and then we worked to identify and cleanup the rest of our DB2 subsystems to ensure this issue did not occur on future migrations. I strongly suggest researching this potential issue on all your DB2 subsystems before doing migrations. Working with IBM we had to run some special MODIFY utilities with DIAGNOSE to get entries cleaned up.
We continued our migrations with 5 more on September 7th and the final 5 on September 21st completing our test subsystem migrations (17 total).
Additional problem identified after test subsystem migrations were complete.
- Application reported SQL failures and upon research found they were UNION SQL and eventually determined that during migration some of our zparm UNION_COLNAME_7 values had been set to the default NO instead of YES causing the problem.
At this time our migrations were stable after addressing the above issues and we were ready to start our first production subsystem migrations on September 24th and my next blog post will describe this effort and related issues that caused us to postpone future migration.
