Home > Articles > Home & Office Computing > Mac OS X

  • Print
  • + Share This
This chapter is from the book

Installation and Migration

Installation is the process of preparing DB2 to operate as a z/OS subsystem. Migration is the process of upgrading to a more current release of DB2. Both processes require the same steps. This book does not cover the details of each migration step; if you require more information, refer to the DB2 Version 8 z/OS Installation manual.

Before you begin installing or migrating, plan the amount of direct-access storage and virtual storage you need. Planning and coordinating with other DB2 subsystems is essential if you plan to install the DDF. For more information, refer to the IBM DB2 for z/OS Version 8 Installation Guide. Review what values are needed for the parameters on the installation and migration panels.

Another option for installation is to use the msys (Managed System Infrastructure) for Setup DB2 Customization Center. This reduces the complexity of configuring a DB2 subsystem when installing, migrating to compatibility mode, or enabling new function mode, or enabling data sharing. The msys for Setup workplace provides a GUI tool similar to Windows Explorer, that is used to manage z/OS products. The msys for Setup management directory stores configuration data for all systems.

The DB2 Customization Center can be added to the msys for Setup workplace. When refreshed, it pulls the current DB2 and z/OS settings. These settings can be reviewed and/or changed. An update can be performed to apply the changes. If a CLIST (command list) was previously used to customize a DB2 subsystem, this can be cloned by specifying the name of the output member generated by the CLIST and then performing a refresh to obtain the information.

Once in the DB2 Customization Center, the parameter values can be copied from one DB2 to another. The tasks executed during the update process are equivalent to those performed by the DB2 installation Job Control Language (JCL) jobs. If you wish to have JCL jobs configure DB2 on the host, the DB2 Customization Center can also generate an output member to be used as input to the CLIST.

For more information on the msys for Setup DB2 Customization Center, refer to the z/OS Managed System Infrastructure for Setup Users Guide.

DB2 provides a set of tools that automate the process of installing or migrating. These tools include most of the JCL needed to install and migrate the product. This JCL constitutes the installation and migration jobs. Each of these jobs helps you perform a task when installing or migrating.

DB2 also includes the installation CLIST (command list) to help tailor the installation and migration jobs. This CLIST, also called the migration CLIST, or simply the CLIST, contains the code necessary to tailor the jobs to your needs. With the Interactive Systems Productivity Facility (ISPF) and Interactive Systems Productivity Facility/Program Development Facility (ISPF/PDF), you can use a series of ISPF panels to pass parameter values to the CLIST. The CLIST uses these values to tailor the installation and migration jobs.

DB2 also provides a set of sample programs and procedures that help you determine whether DB2 is functioning correctly. Because it is distributed as object code, DB2 requires few assemblies. An assembly to specify DB2 initialization parameters must be performed but requires only a few seconds.

DB2 allows you to specify many subsystem characteristics during DB2 operation, thereby providing the ability to defer decisions about DB2 characteristics until after the install or migration. Some of these decisions include authorizing users, defining databases and tables, and tuning DB2.

DB2 allows for updating most of the install options without requiring you to reinstall or remigrate. Defaults can be accepted for certain options; after acquiring experience with DB2, you can tailor them to the needs of a particular environment.

New with version 8 is the Managed System Infrastructure for Setup (msys for Setup), which is a z/OS tool that addresses the difficulties in maintaining z/OS. It can help manage all installation and customization tasks for DB2. It can be used with the DB2 Customization Center to update DB2 parameters and generate output that can be used as input to the installation CLIST.

High-Level Overview

The following procedures need to be performed for both installing and migrating DB2.

  1. If using distributed data, install Virtual Telecommunication Access Method (VTAM) and, optionally, TCP/IP.

  2. If planning implementation in a data sharing parallel sysplex environment, examine the additional considerations for the parallel sysplex installation before installing or migrating DB2 to data sharing.

  3. Load the DB2 libraries (do the SMP/E steps).

  4. Execute the additional jobs if you plan to use DB2's call level interface (CLI) or DB2 for z/OS Java Edition. (Refer to the IBM DB2 ODBC Guide and Reference or the Application Programming Guide and Reference for JAVA.)

  5. Customize the installation or migration jobs.

  6. Install or migrate DB2.

  7. Connect the DB2 attachment facilities.

  8. Prepare DB2 for use.

  9. Verify installation or migration.

Version 8 Migration Considerations

Version 8 migration is different from all previous DB2 release migrations. You can upgrade only to V8 from V7. Also, the migration process has three modes.

  1. In compatibility ( COMPAT) mode (CM), you install the new DB2 software and do some catalog updates, but no new functions are available to customers when you start DB2. Fallback to prior releases is still possible during this mode. DB2 members in a data sharing group can be migrated one by one to this mode (mix V7/V8).

  2. In enable new-function mode (ENFM), you make extensive changes to the catalog. For the most part, fallback to version 7 is impossible unless a complete restore of the subsystem is performed. To begin this mode, all DB2 members in data sharing have to running in be V8 COMPAT mode.

  3. In new-function mode (NFM), you are fully on DB2 V8 and have all new features. Fallback to version 7 is impossible. All DB2 data sharing members have to be in ENFM mode before you can migrate them.

The three modes of migration provide

  • Reduced risk. During CM, customers can do extensive testing of their existing applications; if fallback needs to occur from CM to V7, you guarantee that no new features are used.

  • More control over doing the migration. Fallback is allowed without users experiencing too many errors (force the fallback SPE).

  • Customer control of new-function usage. Full control is provided over the migration process (timing) and when new functions can be used.

Compatibility Mode

In compatibility mode, you will run the MIGRATE CLIST to generate jobs, with the fallback SPE applied to all members in the data sharing group. Then start DB2 with V8 software, and run the DSNTIJTC job. Many updates are made during this mode to header pages in the directory, Boot Strap Data Set (BSCS), and Shared Communication Area (SCA). Coded Character Set Identifier (CCSID) updates are also performed at this time.

At this point, DB2 uses V8 code internally, 64-bit addressing (only virtual pools), and Unicode for parsing SQL. The V8 catalog is still in Extended Binary Coded decimal interchange format, and full fallback to V7 is allowed. To prevent BIND failures if someone tries to use new V8 features, you can use precompiler option NEWFUN=NO. While running in this mode, users have virtually no new V8 functions available.

The data sharing group permits members to be a mix of V7 and V8 in CM. However, it is best to keep the coexistence period short.

Enable New-Function Mode

Only a few new functions are available in this mode. During ENFM, a restructuring of the DB2 catalog is performed. The DSNTIJNE reorganizes 17 catalog table spaces and one directory table with extra functions (CATENFM). In a data sharing environment, this is a groupwide event because one catalog is shared by all members. It is recommended that this migration period be kept short for all members in the data sharing group.

If you do not have BP8K0, BP16K0, and BP32K buffer pools allocated, it is best to create them in compatibility mode.

At this point, fallback to version 7 is not possible.

During this mode (CATEFNM), many catalog changes are made, such as changing almost every CHAR(8) and CHAR(18) column to VARCHAR(18) and VARCHAR(128) so that DB2 can accept long names, and changing the catalog to use Unicode.

Unicode ordering is different from EBCDIC.

An online REORG of most of the catalog and one directory table space must also occur during this mode. The DSNTIJNE job is then executed in several steps, which include the following actions:

  • ENFM0000. Terminate any pending DSNENFM.* utilities.

  • ENFM0001. Update catalog for new mode (for every table space(18)).

  • ENFMnnnn0. Test for conversion, do DDL Alters (* exclusive locking *).

  • ENFM00001. Delete old data sets.

  • ENFM00003. Define new data sets.

  • ENFM00007. REORG and fix. Change record formats, page sizes, and encoding to Unicode; create new V8 indexes; inline image copy; and switch.

  • ENFM0009. Delete old data sets.

New-Function Mode

At this time, the subsystem is a true V8 system, with all functions available. The DSNTIJNF job signals the end of ENFM (CATENFM COMPLETE), DSNTIJNG builds a new DSNHDECP module (specifies whether to use new functions), and DSNHDECM specifies NEWFUN=YES. The new V8 IVP sample jobs can be run, including all the new functions.

In order to see the mode that DB2 is in during the migration process, you can use the –DISPLAY GROUP command. The attribute for the MODE will give you this information. Values in the MODE field are as follows:

  • C = compatibility

  • E = enabling new function

  • N = new function

The following output shows the result of a –DISPLAY GROUP command showing new-function mode:

DSN7100I  +DSN8 DSN7GCMD
 *** BEGIN DISPLAY OF GROUP(........) GROUP LEVEL(...) MODE(N)
   PROTOCOL LEVEL(2)  GROUP ATTACH NAME(....)
   --------------------------------------------------------------------
   DB2                                    DB2 SYSTEM    IRLM
   MEMBER   ID  SUBSYS CMDPREF   STATUS   LVL NAME      SUBSYS IRLMPROC
   -------- --- ----   --------  -------- --- --------  ----   --------
   ........   0 DSN8   +DSN8     ACTIVE   810 P390      BRLM   BRLMPROC
   --------------------------------------------------------------------
   *** END DISPLAY OF GROUP(........)
   DSN9022I  +DSN8 DSN7GCMD 'DISPLAY GROUP ' NORMAL COMPLETION
   
  • + Share This
  • 🔖 Save To Your Account