Core ZMF Db2 Option, without ERO, Using Db2 to Host the Baseline I/A Table

New Install

Note that steps 1, 2, and 3 are part of the base ZMF install process. You can save time by following these instructions during that part of your install. However, you can also execute the follow-on step (see below) at some time later if you didn't follow steps 1, 2, and 3 during the base product installation.

INITIAL1—This sample JCL member is customized and run as part of the creation of the vsam master files that support a new installation of ZMF. For this task you should remove the step which allocates the I/A dataspace LDS (stepname IADSP) prior to running INITIAL1.
INITIAL2—This is the job run after INITIAL1. Before running INITIAL2, you need to remove the step that initializes the I/A dataspace LDS (stepname CMNIAIN).
STARTJCL—This sample member forms the basis for your ZMF started task procedure. For this task, you need to edit your ZMF proc to remove the CMNIALOG and CMNIMPCT ddnames prior to attempting to start the ZMF stc for the first time.
CMNDB2IA—This sample JCL member creates the Db2 tables, binds the packages, and binds the plan to enable the baseline I/A table to be hosted by Db2.

Global parms update—The ZMF subsystem must be up and running.

You must ensure that the default Db2 subsystem (i.e. the one that will host the I/A database) is set as the first item in the list of physical subsystems defined for Global ZMF Db2 option admin. This is done via ISPF option A.G.O.2.1 (D10L in the following case):

CMNGD2S0 Db2 Physical Subsystems - Part 1 of 2      Row 1 to 3 of 3
Command ===>                                        Scroll ===> CSR
    Db2
    subsys  Site    Db2 System Load Library
    D10L            DSN1210.SDSNLOAD
    D10L    LOCAL   DSN1210.SDSNLOAD
    D10K    TEST    DSN1110.SDSNLOAD

Then update the Global parms to indicate that you want to use Db2 for baseline I/A. The global parm for this is located (via ISPF option A.G.1) on this panel:

CMNGGP03 Global Parameters - Part 3 of 8
Command ===>

Enter "/" to select option
Baselines
    / Stacked Reverse Delta
    / Panvalet
    User defined
    / Librarian
      Librarian Access Method (LAM)
      Notification Vehicles
    / Email
    / Batch
    Other options
    / Use primary Db2 subsystem for I/A: D10L
      Require CR number
      Require Department
    / Disable installation calendar
    / Allow temporary packages
    / Process participating packages by install date
    / Hierarchical approval process
    / Use global notification file
    / Allow application update to file
      Force display of global notification file
Global notification file . . CMNDEV.CMNSYS.U900DP.GNFFILE

This setting takes effect only after a restart of the ZMF started task. Finally, update global Db2 general parms to indicate that you want to use only core Db2 functions. This is located (via ISPF option A.G.O.2.G) on this panel:

CMNGDPM0                    Global Db2 General Parameters
Command ===>
Enter "/" to select option
    / Use Core Db2 Option Functions Only
    Use Package Name in Db2 PC version
    Force Pkg Name in Db2 PC version

This setting takes effect immediately.

IMPACTD2—This job runs the mass data extraction process for an installation where Db2 has been used for the I/A database. It produces the usual three flat files (i.e., BUNSPACE, CMPSPACE, and RELSPACE.)
CMNDB2IL—This job loads the I/A data from the three flat files into the set of Db2 tables that are hosting the I/A database.
You should take your usual measures to ensure the best access paths are chosen by Db2 for this new data. This would usually include using the RUNSTATS utility, with the INDEX clause, to update the stats for the tablespaces involved (i.e. those created when you ran CMNDB2IA) and then rebinding the packages involved (those you originally bound using sample JCL member CMNDB2IA). As with any collection of Db2 table data, using the RUNSTATS/rebind mechanism is something you should do on a regular basis.

Follow-on step:

If you didn't follow the instructions in steps 1, 2, and 3 during the initial product install, you can now delete the redundant I/A LDS and log dataset and remove references to them from your ZMF stc procedure.

Migration from a prior version of ZMF

If you are migrating from a prior version, you will most likely have the I/A dataspace in place and will be making a conscious decision to convert to using Db2. We recommend that you move to Db2 some time after you have successfully migrated to this latest release of ZMF. However, if you must do this at the same time, then run these tasks.

STARTJCL—This sample member forms the basis for your ZMF started task procedure. For this task, you need to edit your ZMF proc to remove the CMNIALOG and CMNIMPCT ddnames prior to attempting to start the migrated ZMF stc for the first time.
CMNDB2IA—This sample JCL member creates the Db2 tables, binds the packages, and binds the plan to enable the baseline I/A table to be hosted by Db2.
LDSUNLD or IMPACTD2—LDSUNLD is a sample job that unloads your existing I/A dataspace to flat files. IMPACTD2 creates these flat files by running the batch data extract (CMNIA000). Choose one of these in order to create the flat files to be used to load the new Db2 database. Run IMPACTD2 only if you have made application admin changes (e.g. new appls, new baselines) as part of the conversion (this is not recommended). Either job produces the usual three flat files (i.e. BUNSPACE, CMPSPACE, and RELSPACE.)
CMNDB2IL—This job loads the I/A data from the three flat files into the set of Db2 tables that are hosting the I/A database.
You should take your usual measures to ensure the best access paths are chosen by Db2 for this new data. This would usually include using the RUNSTATS utility, with the INDEX clause, to update the stats for the tablespaces involved (i.e. those created when you ran CMNDB2IA) and then rebinding the packages involved (those you originally bound using sample JCL member CMNDB2IA). As with any collection of Db2 table data, using the RUNSTATS/rebind mechanism is something you should do on a regular basis.

Global parms update—The ZMF subsystem must be up and running. You must ensure that the default Db2 subsystem (i.e. the one which will host the I/A database) is set as the first in the list of physical subsystems defined to Global ZMF Db2 option admin. (You have most likely already done this if you have been using a system with a ZMF Db2 option license.)

Update the Global parms to indicate that you want to use Db2 for baseline I/A. The global parm for this is located (via ISPF option A.G.1) on the following panel.

CMNGGP03                Global Parameters - Part 3 of 8
Command ===>
Enter "/" to select option
    Baselines
    / Stacked Reverse Delta
    / Panvalet
      User defined
    / Librarian
      Librarian Access Method (LAM)
    Notification Vehicles
    / Email
    / Batch
    Other options
    / Use primary Db2 subsystem for I/A: D10L
      Require CR number
      Require Department
    / Disable installation calendar
    / Allow temporary packages
    / Process participating packages by install date
    / Hierarchical approval process
    / Use global notification file
    / Allow application update to file
      Force display of global notification file
Global notification file . . CMNDEV.CMNSYS.U900DP.GNFFILE

This setting takes effect only after a restart of the ZMF started task.

Update global Db2 general parms to indicate that you wish to use only core Db2 functions. This is located (via ISPF option A.G.O.2.G) on this panel:

CMNGDPM0                Global Db2 General Parameters
Command ===>
Enter "/" to select option
    / Use Core Db2 Option Functions Only
      Use Package Name in Db2 PC version
      Force Pkg Name in Db2 PC version

This setting takes effect immediately.

After you are satisfied with the core Db2 option functionality, you can drop the now redundant Db2 option admin tables and free the relevant packages using sample job DB2DRPNC.