Preparing Db2 for z/OS for InfoSphere CDC for z/OS

An InfoSphere® CDC for z/OS® address space uses Db2® for z/OS facilities that require Db2 Authorization. Accordingly, the person performing the installation must ensure that InfoSphere CDC has controlled access to the Db2 subsystem and to the InfoSphere CDC metadata that is kept in the Db2 Subsystem. Controlled access requires the definition of a security identifier for the use of the InfoSphere CDC address space, using whatever security and access control facility (such as RACF®, ACF2 or Top Secret) that is installed on the server. If the metadata for InfoSphere CDC for z/OS is to be owned by a security identifier different from the one used by the address space, then this security identifier must be created as well. These security identifiers will then be specified in the CHCMDMBD, CHCMDMUT, CHCGRNTA, and CHCBNDPL jobs to assign ownership to the InfoSphere CDC metadata tables and Db2 Plans, and to GRANT Db2 authority to the InfoSphere CDC address space. The person performing the installation will need to assign as many security identifiers as there will be executing instances of InfoSphere CDC. If the metadata is to be owned by separate security identifiers, then twice as many security identifiers as executing instances of InfoSphere CDC must be assigned. Only one InfoSphere CDC for z/OS address space can use an assigned security identifier, within the same Db2 Subsystem or Data Sharing Group of Db2 Subsystems. Similarly, only one InfoSphere CDC for z/OS address space can use a given set of metadata tables. Each instance must have its own set of metadata tables. If the security identifier of an InfoSphere CDC for z/OS address space does not match the security identifier that owns its metadata tables, then an alias must be created in Db2, namely CREATE ALIAS <AddressSpaceUserId>.PLAN_TABLE FOR <MetadataUserId>.PLAN_TABLE

Assigning one or more security identifiers must be performed by the administrator of the access control facility in use at the installation. Once a security identifier has been assigned for a single instance of an address space, it must be substituted for the <CHCUserID> substitution placeholder in the sample jobs.

You may use the same name for both the InfoSphere CDC execution security identifier and as the owner qualification of InfoSphere CDC's metadata tables, as specified in the CHCMDMUT sample job, but each instance of InfoSphere CDC for z/OS must have its own set of metadata tables. An attempt by two or more instances of InfoSphere CDC for z/OS to use the same set of metadata tables will cause InfoSphere CDC's initialization to fail for all but the first instance.

Security identifiers that will be creating, administrating or operating source subscriptions will require SELECT access to every table in the subscriptions for which they are responsible. Security identifiers that will be creating, administrating or operating target subscriptions will require INSERT, UPDATE and DELETE access to every table in the subscriptions for which they are responsible. Most often, this access will be controlled by SQL GRANT and REVOKE statements, which will modify the Db2 catalog tables. However, if there exists a Db2 ACM (Access Control Module) Exit, InfoSphere CDC can be configured to automatically load and use that exit to determine which security identifiers have access to which tables, just as Db2 itself does. If the Db2 ACM Exit is in use, then security identifiers must be given access to the Db2 tables they will need using RACF, ACF2, Top Secret or whatever other facility is employed by the Db2 ACM Exit. If the Db2 ACM Exit indicates that it cannot determine what access a security identifier has to a table, InfoSphere CDC will fall back on the information in the Db2 catalog tables, just as Db2 itself does.

The Db2 ACM Exit is an executable named DSNX@XAC, which must be made accessible in the STEPLIB concatenation used by InfoSphere CDC for z/OS. The STEPLIB DD statement in the CHCPROC sample JCL must be modified to concatenate the DB2-owned data set where the DSNX@XAC module is located; this will allow InfoSphere CDC to search for and find the DSNX@XAC module during startup. If the exit is found, InfoSphere CDC for z/OS will present a complete description of the module it found in messages to the system log.

Initial install—Obtain a new security identifier for use by InfoSphere CDC and perhaps a second security identifier to own the metadata.

Upgrade—Determine whether the security identifier already in use by an executing copy of the previous release of InfoSphere CDC for z/OS can be used by the new installation. The security identifier used by the previous release can be used by the new installation if the new installation displaces the previous release, and the two releases will not be run concurrently.

The CHCGRNTA sample job uses a program called DSNTIAD. This program is distributed with Db2 for z/OS as a sample program, and will have been generated during the Db2 installation process. If it is no longer accessible, and cannot be regenerated using the JCL created during the installation of Db2, then consult a Db2 Administrator about executing the SQL contained in these jobs using Db2 SPUFI (or some other interactive SQL interface) instead.

Due to the nature of the changes that the CHCMDMBD, CHCMDMUT, CHCGRNTA, and CHCBNDPL jobs will make to the Db2 Subsystem, it may be required that a Db2 Administrator run these jobs.

During the configuration of replication activities, InfoSphere CDC for z/OS must determine how the Db2 application tables that are the source or target of replication activities are defined. This information is available in the Db2 System Catalogue Tables. InfoSphere CDC for z/OS accesses the Db2 System Catalogue Tables using standard SQL to obtain the definitions of the subject Db2 application tables. In this respect, the Db2 System Catalogue Tables are treated as (read-only) application data by InfoSphere CDC. In particular, access and performance considerations that normally apply to application data tables also apply to the Db2 System Catalogue Tables with respect to the accesses performed by InfoSphere CDC. Some of these considerations are:

The Db2 System Catalogue may require reorganization to ensure that the indexes can be efficiently accessed. The Db2 Administrator should be able to determine if this is the case, and if so, attend to it.
The RUNSTATS utility should be run against the Db2 System Catalogue table spaces to ensure that current statistics are available to the Db2 Optimizer when the InfoSphere CDC for z/OS Db2 Plans are being bound. It should also be run against the table space that contains the InfoSphere CDC metadata, after the metadata tables have been created, and before the InfoSphere CDC Db2 Plans have been bound. From time to time, as the amount of data being stored changes, the RUNSTATS utility should be rerun and the InfoSphere CDC Db2 Plans rebound. This will ensure the most efficient access to the Db2 System Catalogue table spaces and the InfoSphere CDC metadata tables.

Backup and restore considerations

InfoSphere CDC stores most of its metadata in Db2 tables. The installation jobs create a table space that will contain these metadata tables, and this table space should be dedicated to the exclusive use of InfoSphere CDC. Still, from DB2's perspective, the metadata tables and their containing table space are application data. It is your responsibility to ensure that proper procedures are in place to back up and restore the table space in preparation for any situation where the contents of the table space may be lost or compromised.