Nov 16 ’12

Planning Your Upgrade to DB2 10 for z/OS

by Willie Favero in Enterprise Tech Journal

Has DB2 10 for z/OS been on your mind lately? Are you thinking it’s time to start putting together a DB2 10 migration plan? If yes, that’s great. However, if upgrading isn’t yet on your to-do list, why not? DB2 10 became Generally Available (GA) on Oct. 22, 2010. It’s definitely not new anymore. In fact, the number of licenses being shipped is higher than previous versions. DB2 10 is stable and customer reports have been extremely positive.

Maybe the age and the future of available service for the DB2 version you’re running should be a migration catalyst? Both DB2 Version 8 and DB2 9 have been around awhile. DB2 9 went GA on March 16, 2007, and DB2 V8 dates back to March 26, 2004. It saw its End of Service (EoS) on April 30, 2012; DB2 9 is scheduled for EoS on June 27, 2014.

Skip-Level Migration 

If you haven’t yet started, it’s time to formulate a DB2 10 upgrade plan. Remember, planning and migrating are two different tasks. Even if implementing DB2 10 immediately isn’t right for you, there are still numerous tasks you can complete in preparation for that effort—things that will help position your DB2 system for a successful upgrade to DB2 10 when the time is right. 

Most of the steps required to move to DB2 10 are pretty much the same whether you’re on DB2 V8 or DB2 9. If you’re on V8, you must decide if your next DB2 migration will be to DB2 9 or DB2 10. If there are new functions in DB2 10 that you’re interested in, can you afford to wait to complete two full migrations before you can use those functions? Skip-level migration, moving from V8 directly to DB2 10, can get you where you want to be sooner than later.

The opposite is also true, however. If there’s functionality you need now in DB2 9, can you wait through an extended migration, one that will likely take longer than a single version migration, to get that new functionality? 

That brings us to another question: Are you doing a skip-level migration for the right reasons? You don’t skip migrating to DB2 9 to get to DB2 10 because you think it will be faster than going to each version individually. You aren’t going to save yourself much time that way. 

It’s nice that skip-level migration is a tested feature. It was part of the DB2 10 beta. You aren’t the first to try it. A good percentage of migrations to DB2 10 have come from V8. You need only understand the impact of a skip-level migration. You’re getting all the new stuff and getting rid of some of the old stuff in a process that previously would have taken you two complete migrations. Consider, too, the learning curve. There’s definitely a lot to absorb when you skip over an entire version of DB2.

What things can be completed regardless of the migration strategy? What can be performed now so it won’t interfere with what must be completed when a DB2 10 migration occurs? 

Upgrade Prerequisites

Any DB2 upgrade has prerequisites. Usually, the prerequisites can just be completed, no matter when you plan to start the actual upgrade. First, determine the minimum requirements necessary for an upgrade to DB2 10 for z/OS. Some of the requirements, such as operating system level and machine type, aren’t usually things you can just “take care of” over a weekend. You should build a pre-plan covering what must be completed before you can implement a migration plan 

The absolute bare minimum requirement for a move to DB2 10 for z/OS is a processor that supports z/Architecture running in 64-bit mode; for example, the z890, z990, z9, z10, z196, z114, or newer System z processors. That processor must have at least one Logical Partition (LPAR) running with z/OS 1.10 or above and must have adequate real storage to support the combined requirements of DB2 10, z/OS, and Data Facility Storage Management System (DFSMS), along with access methods, telecommunications, batch, and other customer applications. Caution: DB2 10 will likely require an increase in real storage over whatever you were using for DB2 V8 or DB2 9.

There may be other hardware and software requirements you should be aware of, depending on what you plan to use in DB2 10. Refer to the most recent DB2 10 Program Directory (GI10-8892) for a complete list of installation requirements and additional recommendations and considerations, including migration/fallback Authorized Program Analysis Reports (APARs). Especially helpful are APAR II14474 for a DB2 V8 to DB2 10 migration and APAR II14477 for a DB2 9 to DB2 10 migration. Note: You can use your favorite Internet search program to locate any APAR by number. In almost all cases, specifying just the APAR number is sufficient. 

Although z/OS 1.10 is the minimum operating system level required for DB2 10, it may not be the level you actually start at. For example, DB2 10 can take advantage of improved open, close, allocation, and de-allocation functions in z/OS 1.12. Consider, too, that z/OS 1.10 went out of service on Sept. 30, 2011, z/OS 1.11 will be going out of service on Sept. 30, 2012, and z/OS 1.12 has been GA since Sept. 24, 2010.

If migrating from a previous version of DB2, there are also minimum levels that can be used as a starting point. DB2 10 has two starting points from which a migration can be launched. DB2 10 supports a migration from a DB2 9 that’s running in New Function Mode (NFM). DB2 10 also supports a skip-level migration from a DB2 V8 running in NFM.

DB2 10 uses a newer Internal Resource Lock Manager (IRLM), IRLM 2.3, than previous DB2s. DB2 V8 and DB2 9 both currently use IRLM 2.2 so an IRLM upgrade is required. You should consider resizing the IRLM. One of the more significant changes in DB2 10 is the restructure of the DB2 catalog. Part of the restructuring is the use of row-level locking for many catalog tables. This new use of row-level locking by the catalog could result in an increase in the storage size of the DB2 10 IRLM. Also, be aware that the IRLM is installed into the same System Modification Program (SMP) zone of the IRLM used by IMS.

When you migrate to DB2 10, some functions are removed. You should verify that these functions aren’t being used or take corrective action anytime before starting the DB2 10 migration. One feature receiving more than its share of press finally is the removal of private protocol. Any packages that access a remote location must be bound, specifying the option DBPROTOCOL (DRDA). If it’s still bound with private protocol and attempts to reach a remote location, the application will fail with message DSNT225I.

You can and should also eliminate the ability to bind Database Request Modules (DBRMs) directly into a plan. In DB2 10, all DBRMs are bound into packages and those packages are bound into plans. Plans in DB2 10 will always use packages. If a plan runs in DB2 10 that contains DBRMs bound directly into it, DB2 will automatically create packages from the DBRMs and rebind the plan using those packages. Handling this change before migration would reduce the impact of this change on your migration.

Another change that could be managed before a migration involves AQUIRE (ALLOCATE) and MEMBER options on the BIND and REBIND PLAN commands. DB2 will issue a warning if ACQUIRE (ALLOCATE) is specified and uses ACQUIRE (USE). DB2 will also issue a warning message if the MEMBER option is specified. However, for MEMBER, the specified DBRM is bound into a package and then binds that package into a plan.

You should also determine how to gather information about the performance of your SQL in the current DB2 V8 or DB2 9 environment. Devise a strategy describing how EXPLAIN detail and DB2 accounting and statistics information will be retained for use should an access path regression occur once DB2 10 Conversion Mode (CM) is up and running.

DB2 10 changed some rules for using EXPLAIN. EXPLAIN tables must use Unicode encoding and can’t be in a format older than DB2 V8. Migrating the EXPLAIN tables to a DB2 V8 or DB2 9 format and Unicode conversion can precede any DB2 10 migration. Migration and conversion of the EXPLAIN tables is detailed in APAR PK85068.

You should also be aware of the removal of the AIV Extender, Text Extender, and Net Search Extender, along with Net.Data, effective with DB2 9.

If planning a skip-level migration, you should reformat the Boot Strap Data Set (BSDS) and be aware of the removal of DB2 managed stored procedures and the deprecation of simple table space.

As of DB2 9, Partitioned Data Set Extended (PDSE) is required for certain target and distribution libraries in addition to a few SMP/E libraries.

There are four DB2 target and distribution libraries that must use PDSE in DB2 9 and DB2 10. This change affects you if you’re performing a skip-level upgrade from DB2 V8 to DB2 10. The change is already part of a DB2 V8 to DB2 9 migration. The four data sets are ADSNLOAD, ADSNLOD2, SDSNLOAD, and SDSNLOD2. Everything that must be completed is documented in the DB2 10 Installation and Migration Guide (GC19-2974).

With every new version, new DSNZPARM keywords are introduced, defaults and maximums are changed, and some keywords are eliminated. You will want to note the DSNZPARM keywords that are eliminated. Determine if whatever action the ZPARM controls is being eliminated by the next version of DB2 or if it’s becoming part of the product. If something you use is going away, or something you choose not to use is becoming part of the product, determine how that will affect you and plan appropriately.

When upgrading from V8 to DB2 9, some subsystem parameters—MAX_OPT_ELAP, MORE_UNION_DISTRIBUTION, RELCURHL, STORPROC, SUPPRESS_TS_CONV_WARNING, and TABLES_JOINED_THRESHOLD—will be removed. If migrating to DB2 10 from DB2 9, EDMBFIT, LOGAPSTG, MAX_UTIL_PARTS, OPTIXOPREF, PARTKEYU, and SJMISSKY are removed. If a skip-level migration is performed, all the ZPARMs listed previously will be removed. To learn more, refer to “A First Look: DB2 10 DSNZPARM Changes” in the June/July 2011 z/Journal.


If you’ve been avoiding using DFSMS with DB2 for z/OS, you can’t do so anymore. The DB2 10 catalog and directory must be DFSMS-managed. The SMS environment the DB2 catalog and directory uses must be established before you can begin a migration (or installation) to DB2 10. This is one more migration task you can complete before your actual DB2 10 migration begins. For more information, see “The DB2 Catalog Gets a Makeover” in the December/January 2011 z/Journal.

Regardless of your migration timetable, there are steps you can take to prepare. PM04968 supplies the DB2 10 DSNTIJPM routine to DB2 V8 and DB2 9 as job DSNTIJPA. DSNTILPA can be used to check out DB2 9 and DB2 V8 to ensure they’re suitable for use with DB2 10 for z/OS. The APARs cover all the details about DSNTIJPM. Running this one routine can have a significant effect on the success of your DB2 10 migration.

Education is important, too. Build your DB2 10 and DB2 migration skills as soon as possible. Start by downloading the DB2 10 product documentation from the Web. For example, points to the DB2 10 product library in PDF format (BookManager is no longer supported in DB2 10) and provides links to the Information Center on the Internet. The Information Center contains DB2 product documentation for all active versions in one place. It’s easy to search and easy to read and is an excellent place to get DB2 for z/OS information.

There’s also a free, one-day DB2 Migration Workshop available from IBM. It’s a terrific way to get ready for a DB2 10 migration. Contact your IBM DB2 specialist for information.

If you want to verify that your DB2 is ready to migrate to DB2 10, information is abundantly available. A little planning and pre-migration cleanup can make for a smooth DB2 10 migration.