DB2 10 for z/OS: Migration and Planning Considerations

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

 

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.

 

072312Surekha5136 DB210 Fig01-03

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

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/O 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 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 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

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: