By Julian Stuhler, Director, Triton Consulting Ltd

Whether your business is planning to implement DB2 10 for z/OS in a matter of months or years, there’s no getting away from the amount of preparation work that can and indeed, should be done sooner rather than later. 

This article offers a checklist of 23 areas to be worked on in preparation for the move to DB2 10 Conversion Mode.  Some of these changes require a full or partial outage but if you are able to implement most or all of them as part of your routine maintenance activities, you will greatly reduce the risk and elapsed time of the actual upgrade process.  This is even more important if you are considering a skip-release upgrade from DB2 V8 to DB2 10. 

Please note this checklist of tasks is designed as a brief ‘aide memoir’ – click on the following link to access my whitepaper ‘How to Have A Happy DB2 10 CM Day’ for more detailed information on each of the sections below.  In addition, for a full list of the pre-requisites for DB2 10, please refer to the DB2 10 for z/OS Installation and Migration Guide.  A couple of version-specific pre-migration checklists are available online – see here for the V8 to DB2 10 version and here for the DB2 9 DB2 10 version.  

Triton Consulting can provide courses or consultancy tailored to your specific requirements related to the upgrade, see our website at http://www.triton.co.uk/

Please note that the points below apply equally to customers upgrading from DB2 V8 or DB2 V9 unless indicated.

1.       Remove DB2-Managed Stored Procedures (V8 Only): Customers moving from V8 must ensure that any remaining DB2-managed stored procedures are converted to WLM-managed stored procedures prior to the upgrade. 

2.       Remove DB2 Text / AIV Extenders (V8 Only): Support for the DB2 Text Extender and the DB2 Audio, Image and Video (AIV) Extender was removed in DB2 9: any applications using this functionality must be amended. 

3.       Reformat BSDS (V8 Only): Make the change to the new BSDS format in advance of the new migration by using the DSNJCNVB utility (requires the DB2 subsystem to be stopped)

4.       Remove Legacy Java Drivers (V8 Only): Amend any Java applications which use the old Java Legacy driver, which may require code changes and/or re-running the program preparation process where SQLJ is being used.

5.       Convert to PDSEs for DB2 Load Libraries (V8 Only): If you are considering skip-release migration check that your load libraries are all defined as PDSEs. 

6.       Get To New Function Mode: Make sure you’re in New Function Mode (NFM) before you begin your DB2 10 upgrade, especially if you’ve been in Conversion Mode.

7.       Run Pre-Migration Jobs: Check any potential inconsistencies via the DB2 10 pre-migration checker job, known as DSNTIJPM, or access DSNTIJPA now before you have your DB2 libraries. 

8.       Convert 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.

9.       Remove DB2 XML Extender: If you’re using the XML Extender on DB2 9, action your migration to the superior pureXML functionality.  For DB2 8 customers, you may need a ‘big bang’ application release using pureXML to coincide with the DB2 10 upgrade.

10.   Remove Private Protocol: For the past several releases, IBM has continued to enhance the functionality of DRDA, while the old ‘private protocol’ method of DB2 to DB2 communication has been functionally stablised.  Version 10 finally removes support for private protocol so identify any programs that use it before your upgrade.

11.   Remove DBRMs Bound Into Plans: DB2 10 no longer supports DBRMs bound directly into plans so identify them and bind them into packages referenced by the plan.

12.   Positive People Prepare Packages Pre-Emptively:  Each new DB2 release typically brings with it a firm recommendation to rebind your plans/packages at some point in the implementation cycle, in order to take advantage of optimiser enhancements.  Part of your DB2 preparation should include identifying any pre-Version 6 packages and rebinding them in advance to avoid any nasty surprises when DB2 does it for you on CM day. 

13.   Create a DB2 Performance Baseline: Prior to any upgrade you should have a good picture of your current critical transactions and batch processes.  Most DB2 performance monitors allow you to create and populate a ‘performance warehouse’ that stores detailed and summarised information about the performance of key processes.  Spend time creating a historical baseline to compare to after your entry to CM.

14.   Application Considerations: DB2 10 introduces some changes that may require application changes.  Research the full list documented in the DB2 Installation and Migration Guide and make any changes well in advance of your implementation.  DB2 V8 will take longer than DB2 V9 due to two releases-worth of changes.

15.   Set Up SMS Environment For Catalog/Directory: DB2 10 makes extensive changes to the DB2 Catalog and Directory tablespaces, most of which will be migrated to new Partition by Growth Universal Tablespaces (PBG UTS) to improve concurrency and manageability.  Before beginning your upgrade, establish the necessary SMS definitions to allow the catalog and directory pagesets to move under SMS control during ENFM (Enabling New Function Mode). 

16.   Health Check Your Catalog & Directory: Check your catalog and directory for internal consistency before attempting a version upgrade; there are a number of utilities you can use to check these pagesets.  A reorg of the catalog is also worthwhile to speed up the catalog migration steps.

17.   Change EXPLAIN Table Format: DB2 10 introduces some optional new columns to the explain tables – your tables must be at least at V8 format.    Also, DB2 10 does not tolerate EBCDIC explain tables so any of these will need to be converted to Unicode.

18.   Review Real Storage Requirements: The significant virtual storage constraint relief provided by DB2 10 will allow you to increase performance-critical parameters such as the size of the local statement cache.  It is critical to overall performance that paging to auxiliary storage is minimised so increase in virtual storage must be backed by real storage in your LPAR.  Plan for the increased storage requirements and be aware of the implications.

19.   Clean Up Your ZPARMs: IBM provides a handy utility to generate a new 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 10 Conversion Mode.

20.   Apply the DB2 10 Fallback SPE: The DB2 10 fallback SPE must be applied to all members of the data sharing group prior to any attempt to move to CM: apply it to one member at a time to maintain availability within a data sharing group, and each system needs to have been stopped and restarted at least once since the SPE was applied.

21.   Check DB2 Tool Compatibility: Work with vendors of tools and utilities to ensure that each one at least tolerates (and ideally fully exploits) DB2 10.  Most DB2 9 customers can implement tool upgrades in advance of the DB2 10 upgrade, but some tools don’t support Version 8 and DB2 10 within a single release.

22.   Test, Test, Test: Make sure you practice the entire upgrade/fallback process in a ‘sandpit’ system and let developers, DBAs and systems programmers become familiar with the new functions and features.  It’s even more important if you are conducting a skip-release upgrade from DB2 V8 that you conduct regression testing with a realistic production-like workload.

23.   Organise DB2 10 Education: Ensure you and your colleagues are fully up to speed on the new facilities and features in DB2 10.  There is a wealth of technical information on the internet and at various DB2 conferences.  IBM offer free Migration Planning Workshops and Triton Consulting provide courses and consultancy tailored to your specific requirements and issues.