Skip to content
View All / Upgrading to DB2 11 for z/OS – 22 things to think about NOW

Upgrading to DB2 11 for z/OS – 22 things to think about NOW

As a follow-up to my “DB2 10 upgrade – 23 Things to think about now” blog I’ve created a version for DB2 11.  Once again this is intended for organisations who are planning an upgrade to DB2 11 and would like some guidance on what needs to be done prior to the upgrade.

This checklist offers 22 areas which need to be worked on in preparation for the move to DB2 11.  Some of these changes require a full or partial outage, but if you are able to implement all or most of them as part of your routine maintenance activities, you will greatly reduce the risk and the elapsed time of the actual upgrade process.

Please note that this article relates specifically to preparing for an upgrade to DB2 11 for z/OS. Similar guidance on moving to DB2 10 for z/OS can be found in the previous version, which is still available from the Triton Consulting Downloads page.

In case you didn’t pick up on this last time around, it’s also worth noting that since the DB2 version number hit double-digits, IBM has had to move to a hexadecimal notation for the DB2 version/release code. So DB2 10.1 for z/OS was referred to “A10” in APAR text (and DSNA10 for the standard library prefixes), and DB2 11.1 is therefore known as “B10”.

Here’s the list of things to consider:

  1. Get to New Function Mode – this may sound like stating the obvious but we see many organisations staying on Conversion Mode for extended periods.  Make sure you are in New Function Mode and are completely stable before considering the next step.
  2. Check hardware and software pre-requisites – a full list of the hardware and software pre-reqs are listed in the DB2 11 for z/OS Program Directory, which can be found here.
  3. Check the informational APARs and stay up to date on maintenance – these provide a very useful single point of reference for important migration related maintenance.
  4. Check real and virtual storage availability – allowing for a real storage increase of up to 15% compared to DB2 10 is a good idea although it will likely be less than this.
  5. Apply the DB2 11 fallback SPE – this MUST be applied to ALL members of the data sharing group prior to any attempt to move to DB2 11 CM.
  6. Run pre-migration jobs – the pre-migration checker job, known as DSNTIJPM can be accessed via APAR PM94057 before you have your DB2 11 libraries.  If you run this against your DB2 10 systems early and often you can get detailed list of items needing attention. You should aim to have a clean bill of health before attempting to go to CM.
  7. Convert any remaining simple tablespaces – put in place a firm plan for converting any remaining simple tablespaces to either segmented format or one of the new UTS formats.  The RECOVER utility still supports recovery of simple tablespaces in DB2 9 and beyond, but this won’t protect you from an accidental DROP TABLESPACE.
  8. Create a DB2 Performance Baseline – before you upgrade you should ensure you have a good picture of your current performance.  If you haven’t done this and you experience performance-related complaints or issues following the upgrade how will you be able to tell if there has been any regression?
  9. Clean up your ZPARMS – IBM has provided a handy utility to generate a new DSNTIDxx install CLIST input member based on your current DSNZPARM and bufferpool settings. Job DSNTIJXZ allows you to create a fresh CLIST input member incorporating all of the current settings, ready for you to use when you run the install CLIST in order to move to DB2 11 Conversion Mode.
  10. Health check your catalog and directory – there are a number of utilities to check these critical pagesets for internal consistency.  If you’re one of the many sites that don’t run them on a regular basis then you really should do this before attempting a version upgrade.
  11. Positive people prepare packages pre-emptively – part of your DB2 11 preparation should include identifying any pre-version 9 packages and rebinding them in advance to avoid any nasty surprises when DB2 does it for you on CM day.
  12. Check EXPLAIN Table Format Validity – DB2 11 makes changes to the EXPLAIN tables and you should plan to upgrade all of your tables to the V11 format once you’re in CM
  13. Check for use of Unsupported Stored Procedures and Functions – SYSPROC.DSNAEXP and the DB2 MQ function have been deprecated will not work in DB2 11.
  14. Remove views, MQTs and SQL table functions with period specifications – Due to some changes in the way temporal support is implemented in DB2 11, views, MQTs, and SQL table functions that contain a SYSTEM_TIME or BUSINESS_TIME period specification might return incorrect results in DB2 11 CM, and should be dropped.
  15. REORG TABLESPACE SHRLEVEL NONE on LOB Tablespaces – Don’t forget that in DB2 10 REORG SHRLEVEL NONE support for LOB tablespaces was deprecated.  Once you’re in DB2 11 CM check for them and change them to SHRLEVEL REFERENCE or SHRLEVEL CHANGE before you move to CM in order to avoid unnecessary job failures and/or overnight call-outs.
  16. 10-Byte RBA and LRSN Values – DB2 11 expands RBA and LRSN values from 6 to 10 bytes in order to dramatically increase the addressable log range.  If you have any processes or utilities that parse URID values, these must be prepared to accommodate the new 10 byte values.
  17. Expanded DRDA Client Information – DB2 11 expands the length of several of the DRDA client information fields.  If you have any processes that parse the outputs from these commands you must be prepared to accommodate the expanded field lengths.
  18. Password protection of Active/Archive logs – Previous releases of DB2 allowed the active and archive log datasets to be password protected.  This is no longer supported from DB2 11 onwards, so these passwords should be removed prior to moving to DB2 11 CM.3
  19. Application Incompatibilities – DB2 11 introduces some changes that may require application changes.  You should research the full list documented in the DB2 Installation and Migration Guide.
  20. Check DB2 Tool Compatibility – If you rely on additional tools and utilities to supplement the functionality within the base DB2 product do make sure you talk to your tools vendor(s) well in advance of your upgrade and plan accordingly.
  21. Test, Test, Test – Even if your first “real” DB2 11 upgrade is still many months away, you can and should practice the entire upgrade/fallback process in a “sandpit” DB2 system, and then make it available to allow developers, DBAs and systems programmers to become familiar with the new functions and features.
  22. Plan to Exploit New DB2 11 Function – Take advantage of the time leading up the upgrade to get yourself and your colleagues fully educated on the many new facilities and features within DB2 11.

This article provided a quick overview of the major tasks you can undertake in advance of your actual move to DB2 10 Conversion Mode. If you are able to complete all or most of these you can greatly reduce the elapsed time and risk associated with the actual upgrade, and make your “DB2 11 CM day” a happy one. For a more complete description, please see the full white paper here.

For a full list of the pre-requisites for DB2 11, please refer to the DB2 11 for z/OS Installation and Migration Guide. A handy pre-migration checklist is also available online – see here.

Good luck with your upgrade!