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.
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?
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.