Full Function 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 that support a new installation of ZMF. Before running INITIAL1, remove the step which allocates the I/A dataspace LDS (stepname IADSP).
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).
STARTJC—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.
DB2OPTN/R—This sample job creates the full function ZMF Db2 option admin tables, binds the related packages, and binds the plan for full function ZMF Db2 option support. DB2OPTNR is for P-sites, and DB2OPTN is for all other types of sites.
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 for Db2 for I/A—The ZMF subsystem must be started up. 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 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 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.

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 at the same time as migrating to this latest release of ZMF.

Yo will also likely already have the ZMF Db2 option tables in place (depending on which release of ZMF you are migrating from).

And you will also have a default Db2 subsystem already defined as the first in the list of subsystems in global admin for the ZMF Db2 option, physical subsystems.

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 to alter 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. (This must be run after CIMALTR4, if applicable.)
CIMALTR6—This sample job alters the ERO CIM table for migration from versions prior to ZMF v8.2 patch 1. (This 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.2 patch 1. (This must be run after HSTALTR4, if applicable.)
DB2OPTN/R—This sample job creates the full function ZMF Db2 option admin tables, binds the related packages, and binds the plan for full function ZMF Db2 option support. DB2OPTNR is for P-sites, and DB2OPTN is for all other types of sites. If you already have the tables in place, remove the TABLES step from the job (i.e., do not drop/create your tables).
DB2ADMGT—This sample JCL shows how to reformat an existing CMNADMIN_GENERAL table to support ZMF versions 8.2.0 or greater. You don’t need to run it unless you are migrating from a version earlier than 8.2.0.
DB2ALTER—This sample JCL shows how to add the columns to an existing CMNADMIN_NAMED table to support ZMF version 8.2 patch 4 or greater. You don’t need to run it unless you are migrating from a version earlier than 8.2 patch 4.
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 for Db2 for I/A—The ZMF subsystem must be started up and the global parms updated 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 takes effect only after a restart of the ZMF started task.

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 (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 which 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.

After you are satisfied, you can delete the now redundant I/A LDS and log dataset.