Learn everything you need to know to plan your upgrade path.

Editor's Note: This article is an excerpt from the book DB2 10 for z/OS: The Smarter, Faster Way to Upgrade.

This section reviews key migration and planning considerations to take note of in planning for DB 10 for z/OS.

Migration Strategy

As in previous releases, we recommend a short time for mixed-release coexistence in data sharing. A short period for Enable New Function Mode (ENFM) is also highly recommended. Support from vendors may affect the migration staging. One concern for Conversion Mode (CM) is that some new performance improvements cannot be used.

The timing for moving from Test to QA to Production involves more options to consider. There are better controls for preventing the use of new functions, but a long gap between Test and Production levels is not advisable. You now have more granularity in the migration process and can move through mode by mode. Some customers migrate both Test and Production to CM and then change to New Function Mode (NFM) in a short time.

The chart shown in Figure 1.3 summarizes the history of DB2 releases. The top line tracks the year when each release became generally available (GA). The arrows show that the only releases where it was possible to skip a release were from DB2 5 to DB2 7 and from DB2 8 to DB2 10 for z/OS.

The lower part of the chart indicates the steps within the upgrade path from DB2 8 or DB2 9 for z/OS to DB2 10 for z/OS. The double-headed arrows indicate where you can "go back" a step, if necessary.

Figure 1.3: Timeline of DB2 releases and upgrade paths.

Note: If you are migrating from DB2 8, you have a decision to make. Should you go to DB2 9 for z/OS, or skip it and go directly to DB2 10 for z/OS? Once you decide to migrate to DB2 10 for z/OS Conversion Mode 8 (CM8), you can still return to DB2 8. But you cannot then try to migrate to DB2 9 for z/OS CM.

Planning Considerations

In general, the DB2 10 for z/OS migration process is very similar to that for both DB2 8 and DB2 9 for z/OS. It works well, with few customers experiencing problems with migration fallback. The ENFM process in DB2 10 for z/OS runs a lot longer than it did for DB2 9 for z/OS and even longer than it was on DB2 8.

You can migrate to DB2 10 for z/OS CM from either DB2 8 for z/OS NFM or DB2 9 for z/OS NFM. You cannot migrate through either of the following two scenarios:

• Once you migrate forward from V8 NFM to DB2 10 for z/OS CM8, you can always fall back to V8 NFM, but you cannot then migrate forward to DB2 9 for z/OS CM.
• Once you migrate forward from V8 NFM to DB2 9 for z/OS CM, you can always fall back to V8 NFM, but you cannot then migrate forward to DB2 10 for z/OS CM8.

Here are some important Authorized Program Analysis Reports (APARs) to remember:

• Fallback Toleration SPE: APAR PK56922
• Early Code for DB2 V8/V9: APAR PK87280 (supersedes APAR PK61766)
• Information APARs: II14474 V8 to V10 or II14477 V9 to V10

If you are migrating from DB2 8 NFM, the bootstrap data set (BSDS) must be reformatted for the larger number of active/archive log tracking.

For those who operate DB2 Connect, the minimum level supported is DB2 9.1 FP1. DB2 9.7 FP3A is required to support the new DB2 for z/OS functions.

Many customers still use DDF Private Protocol under DB2 8 and DB2 9 for z/OS. There is zero tolerance for DDF Private Protocol in DB2 10 for z/OS. You must absolutely eliminate all use of DDF Private Protocol before starting DB2 10 for z/OS in CM.

Many customers have local plans and packages (CICS, IM, batch, and so on) that have been accidentally mistagged as requiring the use of DDF Private Protocol. These plans and packages, which have been mistagged, will be tolerated. However, if any of these packages really do perform an external call that uses DDF Private Protocol, the call will be prevented and the application will fail immediately.

In DB2 10 for z/OS, database request modules (DBRMs) bound directly into plans are no longer supported. However, if any DBRMs bound into plans are found at execution time, DB2 will automatically trigger AUTOBIND to generate packages on first allocation after entry into DB2 10 for z/OS. We choose a standard collection name to put these packages in, but the recommended best practice is to deal with DBRMs bound directly into plans before migrating to DB2 10 for z/OS. Any old plans and packages bound prior to DB2 V6 will also be invalidated and go through an AUTOBIND.

During ENFM processing on DB2 10 for z/OS, all the new indexes and new table spaces in the DB2 Catalog and Directory will be created as SMS-controlled, requiring extended addressability (EA) and extended format (EF) attributes. Some customers still do not use SMS management for the DB2 Catalog and Directory. Once you get to the ENFM process in DB2 10 for z/OS, the datasets of the DB2 Catalog and Directory must be SMS-managed.

For those of you coming from DB2 8, partitioned data sets extended (PDSEs)—as opposed to partitioned data sets (PDSs)—are required for SDSNLOAD, SDSNLOD2, and ADSNLOAD libraries. The environment created by the DSNTIJSS job is only for DB2 Catalog and Directory data sets, which must be SMS-controlled in DB2 10 for z/OS. Other DB2 subsystem data sets, such as logs and the BSDS, are not accounted for in this environment.

The DSNHDECP module supports the NEWFUN parameter with the following options: V10, V9, or V8. This provides a way of stopping both static and dynamic SQL applications from using new SQL functions.

Many customers have old EXPLAIN table formats. DB2 10 for z/OS brings some changes in this space. First, if you have any plan tables that use a format prior to DB2 8, they will not work with EXPLAIN in DB2 10 for z/OS. The format and the ASCII/EBCDIC Coded Character Set Identifier (CCSID) from previous releases are deprecated in DB2 10 for z/OS. They will fail with an SQLCODE –20008. If you have plan tables in DB2 8 or DB2 9 for z/OS format, you can still use them, but they will generate a warning SQLCODE +20520, regardless of whether they are CCSID EBCDIC or UNICODE.

If you use the DB2 10 for z/OS format, you must use UNICODE as the CCSID. If you try to use CCSID EBCDIC with DB2 10 for z/OS format, you will get the following errors:

• EXPLAIN fails with RC=8 DSNT408I SQLCODE = –878.
• BIND with EXPLAIN fails with RC=8 DSNX200I.

We recommend using the DB2 10 for z/OS extended format of the plan tables with a CCSID value of UNICODE. APAR PK85068 can help you migrate existing plan tables in DB2 8 or DB2 9 for z/OS table format over to the new DB2 10 for z/OS format with a CCSID of UNICODE.

John Campbell is an IBM Distinguished Engineer reporting to the Director for z/OS Development at the IBM Silicon Valley Lab. He has extensive experience of DB2 in terms of systems, database, and application design. John specializes in design for high performance and data sharing. He is one of IBM’s foremost authorities for implementing high-end database/transaction-processing applications.

---

MC Press books written by John Campbell available now on the MC Press Bookstore.

		The Business Value of DB2 for z/OS Find out why DB2 is still going strong and how it is helping businesses to reduce costs and grow. List Price $17.95 Now On Sale
		DB2 10 for z/OS: The Smarter, Faster Way to Upgrade Explore the top 10 reasons to start planning your upgrade today. List Price $16.95 Now On Sale
		DB2 11: The Ultimate Database for Cloud, Analytics, and Mobile Get the DB2 11 info you need, including technical overview, migration planning, and application compatibility. List Price $16.95 Now On Sale