Install IBM z components - Precisely Data Integrity Suite

Implementation of the Db2 Log Reader Capture agent requires a number of environment specific activities that often involve people and resources from different parts of an organization. This section describes those activities so that the internal procedures can be initiated to complete those activities prior to the actual setup and configuration of the SQData capture components.

Install and configure IBMz components
1. Identify source and target system and datastore:
  Configuration of the Capture Agents, Engines and their Controller Daemon's require identification of the system and type of datastore that will be the source of and target for the captured data. Once this information is available, requests for ports, accounts and the necessary file and database permissions for the Engines that will run on each system should be submitted to the responsible organizational units.
2. Confirm and install replication related APARS (Authorized Program Analysis Reports):
  
  The Db2 Capture Agent utilizes Db2 logging and LogReader IFI calls. This functionality evolves over time as customers and IBM identify problems. IBM initially creates a problem management report (PMR) when a problem is identified. Next an APAR is issued containing symptoms and workarounds to document and track its resolution. Eventually IBM may produce a program temporary fix (PTF) to replace the service in error, and the APAR is closed.
  
  Precisely recommends requesting from IBM the list of replication related APAR's associated with your installed version of Db2 to make that your system is up to date.
3. Modify z/OS PROCLIB (Procedure Library) members:
  Modify the members of the PROCLIB as required for your environment to set the supporting system dataset names (that is, Language Environment, IMS, VSAM, Db2, etc.) Each member contains instructions on the necessary modifications.
4. Verify product is linked
  
  The product should have been linked as part of the base product installation using JCL similar to sample member SQDLINKA. Verify that the return code from this job was 0.
5. Bind the Db2 package
  
  The Db2 Capture Agent and Apply Engines that access Db2 tables require a Db2 Package/Plan in order to access the Db2 system catalogs to obtain information regarding the tables being processed. A common database request module (DBRM) SQDDDB2D is shipped as part of the product distribution.
  
  Note: Once the Bind is complete, authorization for its use must be granted for started task and job user-ids, see the step prepare-db2-for-capture.
6. Verify APF authorization of LOADLIB
  Execution of the SQData on z/OS requires APF authorization of the product's Load Library, which is normally made a permanent part of the IPL APF authorization procedure as part of the base product installation. Verify that SQData is on the list of currently APF authorized files using the z/OS ISPF/SDSF facility. First, enter "/D PROG, APF" at the SDSF command prompt to generate the list. Next, enter "LOG" at the SDSF command prompt. Scroll to the bottom of the log to display the results of the previous command and then back up and to the right to view the complete listing of the command.
Progress package installation on Db2ZOS database server:
Learn how the Db2 driver manages package creation automatically and how to explicitly create or copy Db2 packages when needed.
Use the following links to install the packages:
- https://prd-cloud-platform-dis-downloads.s3.amazonaws.com/Progress_ZOS_bnd_lst_files.zip
- https://prd-cloud-platform-dis-downloads.s3.amazonaws.com/Progress_ZOS_CNTLFILE_AND_DBRMFILE.zip
1. Automatic Db2 Package Creation
  
  The Db2 driver automatically creates all required Db2 packages the first time it connects to a database. By default, these packages contain 200 dynamic sections and are created in the NULLID collection (or library).
  
  Note: The initial connection may take a few minutes due to the number and size of packages being created. This delay only occurs during the first connection. Once the packages are created, the driver writes the following message to the standard output: DB2 packages created.
2. When to Explicitly Create Db2 Packages
  In most cases, you do not need to manually create Db2 packages, as the driver handles this automatically. However, if you need to explicitly create packages (for example, for advanced configuration or deployment scenarios), you can do so using one of the following methods:
  - Running the appropriate Db2 package creation list file for your operating system on the database server.
  - Copying existing Db2 packages to your environment.
  Note: The user ID used to create Db2 packages must have BINDADD privileges on the database. Consult your database administrator to ensure you have the necessary permissions.
3. Explicitly Creating Db2 Packages
  To explicitly create Db2 packages, bind the appropriate package creation list files for your operating system on your database server. Binding these files will replace any existing packages with new ones containing 200 dynamic sections in the NULLID collection.
  1. Install the list (.lst) and bind (.bnd) files to a directory on the database server.
  2. Open the Db2 command-line utility from the directory where you placed the list and bind files.
  3. Connect to the target database using the following command:
```
connect to database_name user authorization_name using password                    
```
    Replace database_name with the name of your database, authorization_name with your user name, and password with your password.
  4. Bind the list file using the following command:
```
bind @ list_file grant public                    
```
    Replace list_file with the name of the list file you want to bind.
4. Copying Db2 Packages
  If you need to copy existing Db2 packages (for example, to a mainframe environment), follow these steps:
  1. Install CNTLFILE.XMIT and DBRMFILE.XMIT files.
  2. Log on to the mainframe system where you will bind the packages. Pre-allocate two sequential datasets using the following parameters:
    - DSORG=PS
    - RECFM=FB
    - LRECL=80
    - BLKSIZE=3120
    Example dataset names:
    - userid.CNTLFILE.XMIT
    - userid.DBRMFILE.XMIT
  3. FTP to the mainframe system using the same user ID and password as above.
  4. Set the transfer mode to binary by typing BIN.
  5. Upload the cntlfile.xmit and dbrmfile.xmit files using the PUT command. Ensure these files replace the datasets you created in step 2.
  6. From ISPF option 6 or TSO Ready mode, issue the following commands to create the partitioned datasets containing the JCL and distribution packages:
```
RECEIVE INDS('userid.CNTLFILE.XMIT')
RECEIVE INDS('userid.DBRMFILE.XMIT')                    
```
  7. By default, the datasets userid.DDJDBC.CNTL and userid.DDJDBC.DBRMLIB are created. Edit the job userid.DDJDBC.CNTL(BIND) and follow the instructions in that job to bind the packages for the Connect for JDBC Db2 driver and grant execute privileges to users as needed.
  Note:
  - Always ensure you have the necessary privileges before attempting to create or bind Db2 packages.
  - Consult your database administrator if you are unsure about any of the steps or required permissions.
  - For more information, refer to the official Db2 documentation for your platform.
Progress package installation on Db2LUW database server
Learn how the Db2 driver manages package creation automatically and how to explicitly create or update Db2 packages if needed.
Note: Use the following link to install the package https://prd-cloud-platform-dis-downloads.s3.amazonaws.com/Progress_LUW_bnd_lst_files.zip
1. Automatic Db2 Package Creation:
  The Db2 driver automatically creates all required Db2 packages the first time it connects to a database. By default, these packages:
  - Contain 200 dynamic sections
  - Are created in the NULLID collection (or library)
  Note: The initial connection may take a few minutes because the driver must create several large packages. This delay only occurs during the first connection. Once the packages are created, the driver writes the following message to the standard output: DB2 packages created.
2. When to Explicitly Create Db2 Packages
  In most cases, you do not need to manually create Db2 packages, as the driver handles this automatically. However, you may need to explicitly create or update packages in the following situations:
  - You want to pre-create packages to avoid delays during the first connection.
  - You need to update existing packages with new versions.
  - Your organization requires manual package management for security or compliance reasons.
3. Prerequisites
  Before creating Db2 packages manually, ensure you have the following:
  - Access to the appropriate list (*.lst) and bind (*.bnd) files for your operating system.
  - BINDADD privileges on the target database. Consult your database administrator to confirm your privileges.
  - Access to the Db2 command-line utility on the database server.
4. Steps to Explicitly Create Db2 Packages:
  1. Install the List and Bind Files: Copy the required *.lst and *.bnd files to a directory on the database server.
  2. Start the Db2 Command-Line Utility: Open a terminal or command prompt and navigate to the directory where you placed the files.
  3. Connect to the Database: Use the following command to connect to your database:
```
connect to database_name user authorization_name using password                    
```
    Replace database_name with the name of your database, authorization_name with your user name, and password with your password.
  4. Bind the List File: Execute the following command to create or update the Db2 packages:
```
bind @list_file grant public                    
```
    Replace list_file with the name of the list file you want to bind. This command will create packages with 200 dynamic sections in the NULLID collection. If packages already exist, they will be replaced.
  Note: The user ID performing the bind operation must have BINDADD privileges on the database.
5. Troubleshooting
  If you encounter issues during package creation:
  - Verify that you have the correct privileges (BINDADD) on the database.
  - Ensure you are using the correct list and bind files for your operating system.
  - Check for error messages in the command-line output for more details.

Set up zFS and network configuration

Configure zFS variable directories, reserve TCP/IP ports, and authorize zFS user and Started Task IDs for system communication.

Create zFS variable directories

The Controller Daemon, Capture, Storage and Publisher agents require a predefined zFS directory structure used to store a small number of files. While only the configuration directory is required and the location of the agent and daemon directories is optional, we recommend the structure described below, where <home> and a "user" named <sqdata> could be modified to conform to the operating environment and a third level created for the Controller Daemon (see note below):

/<home>/<sqdata> - The home directory used by the SQData

/<home>/<sqdata>/daemon - The working directory used by the Daemon that also contains two sub directories.

/<home>/<sqdata>/daemon/cfg - A configuration directory that contains two configuration files.

/<home>/<sqdata>/daemon/logs - A logs directory, though not required, is suggested to store log files used by the controller daemon. Its suggested location below must match the file locations specified in the Global section of the sqdagents.cfg file created in the section "Setup Controller Daemon" later in this document.

Additional directories will be create for each Capture/Publisher. The recommended structures is described below:

/<home>/<sqdata>/db2cdc - The working directory for the Db2 Capture and CDCStore Storage agents. The Capture and CDCStore configuration (.cab) Files will be maintained in this directory along with small temporary files used to maintain connections to the active agents.

/<home>/<sqdata>/db2cdc/data - A data directory is required by the Db2 Capture. Files will be allocated in this directory as needed by the CDCStore Storage Agent when transient data exceeds allocated in-memory storage. The suggested location below must match the "data_path" specified in the Storage agent configuration (.cab file) described later in this chapter. A dedicated File System is required in production with this directory as the "mount point".

/<home>/<sqdata>/imscdc - The working directory for the IMS Capture and CDCzLOG Publisher agents. The Capture and Publisher (.cab) Files will be maintained in this directory along with small temporary files used to maintain connections to the active agents.

/<home>/<sqdata>/[vsampub | kfilepub] - The working directory for the VSAM and Keyed File Compare Capture's CDCzLOG Publisher agent. The Publisher configuration (.cab) File will be maintained in this directory along with small temporary files used to maintain connections to the active agents.

Create zFS variable directories notes

Consider changing default umask setting in the /etc/profile file, or in your .cshrc or .login file.

While many zFS File systems are configured with /u as the "home" directory, others use /home, the standard on Linux. References in the Connect CDC SQData JCL and documentation will use /home for consistency. Check with your Systems programmer regarding zFS on your systems.
The User-ID(s) and/or Started Task under which the Capture and the Controller Daemon will run must be authorized for Read/Write access to the zFS directories.
A more traditional "nix" style structure may also be used where "sqdata", the product, would be a sub- directory in the structure "/var/opt/sqdata/" with the daemon and data sub-directory structures inside sqdata.
The BPXPRMxx member used for IPLs should be updated to include the mount point(s) for this zFS directory structure.

JCL similar to the sample member ALLOCZDR included in the distribution should be used to allocate the necessary directories. The JCL should be edited to conform to the operating environment.

//ALLOCZDR JOB 1,MSGLEVEL=(1,1),MSGCLASS=H,NOTIFY=&SYSUID
//*
//*------------------------------------------------------
//* Allocate zFS Directories for Daemon and CAB Files
//*------------------------------------------------------
//* Note: 1) These directories are use by the Controller Daemon,
//*          CDCStore and CDCzLog based capture agents
//*
//*       2) The 1st, 2nd and 3rd level directories can be changed but
//*          we recommend the 2nd Level be a User named sqdata.
//*
//*       3) Leave /daemon and /daemon/cfg as specified
//*
//*       4) Your UserID may need to be defined as SUPERUSER to
//*          successfully run this Job
//*
//*********************************************************************
//*
//*---------------------------------------------------------------------
//* Delete Existing Directories
//*---------------------------------------------------------------------
//*DELETDIR EXEC PGM=IKJEFT01,REGION=64M,DYNAMNBR=99,COND=(0,LT)
//*SYSEXEC DD DISP=SHR,DSN=SYS1.SBPXEXEC
//*SYSTSPRT DD SYSOUT=*
//*OSHOUT1 DD SYSOUT=*
//*SYSTSIN DD *
//* OSHELL rm -r /home/sqdata
/*
//*--------------------------------------------------------------------
//* Create New ZFS Directories for Controller Daemon & Captures
//*--------------------------------------------------------------------
//CREATDIR EXEC PGM=IKJEFT01,REGION=64M,DYNAMNBR=99,COND=(0,LT)
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD * PROFILE MSGID WTPMSG
MKDIR '/home/sqdata/' + MODE(7,7,5)
MKDIR '/home/sqdata/daemon/' + MODE(7,7,5)
MKDIR '/home/sqdata/daemon/cfg' + MODE(7,7,5)
MKDIR '/home/sqdata/daemon/logs' + MODE(7,7,5)
MKDIR '/home/sqdata/db2cdc/' + MODE(7,7,5)
MKDIR '/home/sqdata/db2cdc/data/' + MODE(7,7,5)
/*
//
MKDIR '/home/sqdata/imscdc/' + MODE(7,7,5)
MKDIR '/home/sqdata/vsampub/' + MODE(7,7,5)
MKDIR '/home/sqdata/kfilepub' + MODE(7,7,5)

Reserve TCP/IP ports
TCP/IP ports are required by the Controller Daemons on source systems and are referenced by the Engines on the target system(s) where captured Change Data will be processed. Once the source systems are known, request port number assignments for use by SQData on those systems. Connect CDC SQData defaults to port 2626 if not otherwise specified.

Identify/Authorize zFS user and started task IDs

z/OS Capture and Publisher processes can operate as standalone batch Jobs or under a Started Task. Once the decision has been made as to which configuration will be employed, a User-ID and/or Name of the Started Task must be assigned. RACF must then be used to grant access to the OMVS zFS file system.

JCL similar to the sample member RACFZFS included in the distribution can be edited to conform to the operating environment, and be used to provide the appropriate authorizations:

//RACFZFS JOB 1,MSGLEVEL=(1,1),MSGCLASS=H,NOTIFY=&SYSUID
                        //*
                        //*----------------------------------------------------------------------
                        //* Sample RACF Commands to Setup zFS Authorization
                        //*-----------------------------------------------------------------------
                        //* Note: 1) The Task/User Names are provided as an example and
                        //*          must be changed to fit your environment
                        //*
                        //*          Started Tasks included:
                        //*          SQDAMAST - z/OS Master Controller
                        //*          SQDDB2C - DB2 z/OS Capture Agent
                        //*          SQDZLOGC - IMS/VSAM LogStream Publisher
                        //*          SQDAEMON - z/OS Listener Daemon
                        //*          <admin_user> - Administrative User
                        //*
                        //*        2) MMAPAREAMAX Parm required only for DB2 CDCStore Capture
                        //*
                        //*        3) The FSACCESS step may be needed if the RACF FSACCESS
                        //*           class is active. See comments in the step.
                        //*
                        //*--------------------------------------------------------------------------
                        //*
                        //RACFZFS EXEC PGM=IKJEFT01
                        //SYSTSPRT DD SYSOUT=*
                        //SYSPRINT DD SYSOUT=*
                        //SYSUADS DD DSN=SYS1.UADS,DISP=SHR
                        //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR
                        //SYSTSIN DD *
                        ADDUSER SQDAMAST DFLTGRP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER SQDAMAST NOPASSWORD NOOIDCARD
                        ALTUSER SQDAMAST NAME('STASK, SQDATA')
                        ALTUSER SQDAMAST DATA('FOR SQDATA CONTACT:<sqdata_contact_name>') 
                        ALTUSER SQDAMAST WORKATTR(WAACCNT('**NOUID**'))
                        CONNECT SQDAMAST GROUP(<stc_group>) OWNER(<owner_name>) 
                        PERMIT 'SQDATA.*' ID(SQDAMAST) ACCESS(READ) GEN
                        
                        ADDUSER SQDDB2C DFLTGRP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER SQDDB2C NOPASSWORD NOOIDCARD
                        ALTUSER SQDDB2C NAME('STASK, SQDATA')
                        ALTUSER SQDDB2C DATA('FOR SQDATA CONTACT:<sqdata_contact_name>') 
                        ALTUSER SQDDB2C WORKATTR(WAACCNT('**NOUID**'))
                        CONNECT SQDDB2C GROUP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER SQDDB2C OMVS(PROGRAM('/bin/sh'))
                        ALTUSER SQDDB2C OMVS(MMAPAREAMAX(262144)) 
                        PERMIT 'SQDATA.*' ID(SQDDB2C) ACCESS(READ) GEN
                        
                        ADDUSER SQDZLOGC DFLTGRP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER SQDZLOGC NOPASSWORD NOOIDCARD
                        ALTUSER SQDZLOGC NAME('STASK, SQDATA')
                        ALTUSER SQDZLOGC DATA('FOR SQDATA CONTACT:<sqdata_contact_name>') 
                        ALTUSER SQDZLOGC WORKATTR(WAACCNT('**NOUID**'))
                        CONNECT SQDZLOGC GROUP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER SQDZLOGC OMVS(PROGRAM('/bin/sh'))
                        PERMIT 'SQDATA.*' ID(SQDZLOGC) ACCESS(READ) GEN
                        
                        ADDUSER SQDAEMON DFLTGRP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER SQDAEMON NOPASSWORD NOOIDCARD
                        ALTUSER SQDAEMON NAME('STASK, SQDATA')
                        ALTUSER SQDAEMON DATA('FOR SQDATA CONTACT:<sqdata_contact_name>') 
                        ALTUSER SQDAEMON WORKATTR(WAACCNT('**NOUID**'))
                        CONNECT SQDAEMON GROUP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER SQDAEMON OMVS(PROGRAM('/bin/sh'))
                        PERMIT 'SQDATA.*' ID(SQDAEMON) ACCESS(READ) GEN
                        
                        ADDUSER <admin_user> DFLTGRP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER <admin_user> NOPASSWORD NOOIDCARD
                        ALTUSER <admin_user> NAME('STASK, SQDATA')
                        ALTUSER <admin_user> DATA('FOR SQDATA CONTACT:<contact_name>') 
                        ALTUSER <admin_user> WORKATTR(WAACCNT('**NOUID**'))
                        CONNECT <admin_user> GROUP(<stc_group>) OWNER(<owner_name>) 
                        ALTUSER <admin_user> OMVS(PROGRAM('/bin/sh'))
                        ALTUSER <admin_user> OMVS(MMAPAREAMAX(262144)) 
                        PERMIT 'SQDATA.*' ID(<admin_user>) ACCESS(READ) GEN
                        
                        SETROPTS GENERIC (DATASET ) REFRESH
                        /*
                        //
                        //*------------------------------------------------------------------------
                        //* SETUP R/W ACCESS TO THE SQDATA ZFS FILE SYSTEM
                        //*
                        //* If the FSACCESS RACF class is not active, do not run this step.
                        //*
                        //* The FSACCESS class provides coarse-grained control to z/OS USS
                        //* file systems at the file system name level. It is inactive by
                        //* default and is not always used.
                        //*
                        //* If your RACF administrator has activated this class, and if any
                        //* protected file system will be accessed by a capture, publisher,
                        //* daemon, admin user, or other user or task, then you will need to
                        //* grant access to the relevant profile(s). Check with your RACF
                        //* administrator to determine if this is required.
                        //*
                        //* The example below shows the RACF commands to define a new profile
                        //* in the FSACCESS class for the DB2 CDCStore file system and grant
                        //* UPDATE permission to the users that will access it.
                        //*--------------------------------------------------------------------------
                        //FSACCESS EXEC PGM=IKJEFT01
                        //SYSTSPRT DD SYSOUT=*
                        //SYSPRINT DD SYSOUT=*
                        //SYSUADS DD DISP=SHR,DSN=SYS1.UADS
                        //SYSLBC DD DISP=SHR,DSN=SYS1.BRODCAST
                        //SYSTSIN DD *
                        SETROPTS GENERIC(FSACCESS)
                        RDEFINE FSACCESS SQDATA.** UACC(NONE)
                        PERMIT SQDATA.** CLASS(FSACCESS) ID(SQDAMAST) ACCESS(UPDATE) 
                        PERMIT SQDATA.** CLASS(FSACCESS) ID(SQDDB2C) ACCESS(UPDATE) 
                        PERMIT SQDATA.** CLASS(FSACCESS) ID(SQDZLOGC) ACCESS(UPDATE) 
                        PERMIT SQDATA.** CLASS(FSACCESS) ID(SQDAEMON) ACCESS(UPDATE) 
                        PERMIT SQDATA.** CLASS(FSACCESS) ID(<admin_user>) ACCESS(UPDATE) 
                        SETROPTS RACLIST(FSACCESS) REFRESH
                        /*
                        //

Identify/Authorize zFS User and Started Task IDs Notes
- The RACFZFS sample JCL includes users SQDDB2C and SQDZLOGC. These sections are only required when using the Db2 CDCSTORE Capture or the IMS/VSAM CDCzLog Publisher agents respectively.
- The Db2 Log Reader Capture avoids "landing" captured data by using memory mapped storage. While Storage is not allocated until memory mapping is active, it is important to specify a value for MMAPAREAMAX using RACF that will accommodate the data space pages allocated for memory mapping of the z/OS UNIX (OMVS) files. Precisely recommends using a value of 262144 (256MB) because the default of 4096 (16MB) will likely cause the capture to fail as workload increases. The RACF ADDUSER or ALTUSER command, included in the sample RACFZFS JCL above, specifies the MMAPAREAMAX limit. You can read more about MMAPAREAMAX process limits and its relationship to MAXPMMAPAREA system limits here https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb200/maxmm.htm.

Prepare Db2 for capture

The Db2 Log Reader Capture requires special user privileges and preparation to access and read the Db2 Recovery Logs using the Db2 Instrumentation Facility Interface (IFI) calls. SQData (version 4) also requires some system tables to be captured to support Schema Evolution.

The following GRANTS are required:

GRANT MONITOR2 TO < sqdata_user>;
GRANT EXECUTE ON PLAN SQDV4000 TO < sqdata_user>;
GRANT SELECT ON SYSIBM.SYSTABLES TO < sqdata_user>;
GRANT SELECT ON SYSIBM.SYSCOLUMNS TO < sqdata_user>;
GRANT SELECT ON SYSIBM.SYSINDEXES TO < sqdata_user>;
GRANT SELECT ON SYSIBM.SYSKEYS TO < sqdata_user>;
GRANT SELECT ON SYSIBM.SYSTABLESPACE TO < sqdata_user>;

Db2 Reorg and Load procedures may need to be updated:

KEEPDICTIONARY=YES parameter must be used by all Db2 REORG and LOAD Utilities. If the CDC process is run asynchronously, for some reason gets behind or is configured to recapture older logs, the proper Compression Dictionary must be available.

Schema evolution requires Data Capture Changes on two (2) catalog tables:

SYSIBM.SYSTABLES

SYSIBM.SYSCOLUMNS

Note:

A common database request module (DBRM) SQDDDB2D ships as part of the product distribution and a Bind must be performed on the SQDV4000 Package and Plan. Use the BINDSQD member in the CNTL Library to bind the Package and Plan to Db2.
Each Db2 table to be captured also requires:
```
ALTER TABLE <schema.tablename> DATA CAPTURE CHANGES;
```

JCL similar to sample member DB2GRANT included in the distribution can be edited to conform to the operating environment, and be used to provide the appropriate Db2 user Authorizations.

//DB2GRANT JOB 1, MSGLEVEL=(1, 1), MSGCLASS=H, NOTIFY=&SYSUID
                        //*
                        //*
                        //* Grant Db2 Authorizations for SQDATA Userid(s)
                        //*-----------------------------------------------------------------
                        //* Note:  MONITOR2 for IFI Calls
                        //*        Execute on the SQDATA PLAN SQDV4000
                        //*        SELECT on Catalog Table SYSIBM.SYSTABLES
                        //*        SELECT on Catalog Table SYSIBM.SYSCOLUMNS
                        //*        SELECT on Catalog Table SYSIBM.SYSINDEXES
                        //*        SELECT on Catalog Table SYSIBM.SYSKEYS
                        //*        SELECT on Catalog Table SYSIBM.SYSTABLESPACE
                        //*-----------------------------------------------------------------
                        //*
                        //DB2GRANT EXEC PGM=IKJEFT01,DYNAMNBR=20
                        //STEPLIB DD DISP=SHR,DSN=DSNC10.SDSNLOAD
                        //SYSTSPRT DD SYSOUT=*
                        //SYSTSIN DD * 
                        DSN SYSTEM(DBCG)
                        RUN PROGRAM(DSNTIAD) PLAN(DSNTIA11) - 
                        LIB('DSNC10.RUNLIB.LOAD')
                        //SYSPRINT DD SYSOUT=*
                        //SYSUDUMP DD SYSOUT=*
                        //SYSIN DD *
                        
                        GRANT MONITOR2                               TO <db2_user>; 
                        GRANT EXECUTE ON PLAN SQDV4000               TO <db2_user>; 
                        GRANT SELECT ON SYSIBM.SYSTABLES             TO <db2_user>; 
                        GRANT SELECT ON SYSIBM.SYSCOLUMNS            TO <db2_user>; 
                        GRANT SELECT ON SYSIBM.SYSINDEXES            TO <db2_user>; 
                        GRANT SELECT ON SYSIBM.SYSKEYS               TO <db2_user>; 
                        GRANT SELECT ON SYSIBM.SYSTABLESPACE         TO <db2_user>;