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.
The following procedures need to be performed for both installing and migrating DB2.
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.
The three modes of migration provide
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:
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:
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