Core ZMF Db2 Option, with 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 later time 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 which will 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 which 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.
CMNDB2RM—This sample job creates the main ERO tables.
CMNDB2RA—This sample job creates the ERO audit tables.
CMNDB2RP—This sample job binds the ERO packages.
CMNDB2RB—This sample job binds the ERO plans.
CMNDB2RG—This sample job grants the relevant Db2 authorities for ERO.
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 in the list of physical subsystems defined to 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 wish 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 is in 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

We recommended 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, run the following jobs:

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.
CIMALTR4—This sample job alters the ERO CIM table for migration from versions prior to ZMF v7.1.2.
HSTALTR4—This sample job alters the ERO HST table for migration from versions prior to ZMF v7.1.2.
CIMALTR5—This sample job alters the ERO CIM table for migration from versions prior to ZMF v8.1.2. (It must be run after CIMALTR4, if applicable.)
CIMALTR6—This sample job alters the ERO CIM table for migration from versions prior to ZMF v8.2patch1. (It must be run after CIMALTR4 & CIMALTR5, if applicable.)
HSTALTR5—This sample job alters the ERO HST table for migration from versions prior to ZMF v8.2patch1. (It must be run after HSTALTR4, if applicable.)
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 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 set this in previous upgrades). Update the Global parms to indicate that you wish 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 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.

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. When 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.
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.