Sample DB2 data sharing environment
The most common user of sysplex data sharing support is DB2. This chapter describes the implementation and operation of the DB2 data sharing configuration that is delivered by the 2017 Sysplex Extensions and includes the following topics:
5.1 Setting up the 2017 Sysplex Extensions DB2 data sharing environment
The ADCD system provides the environment to run a DB2 subsystem. However, there were many requests for a pre-packaged DB2 data sharing environment. This package attempts to minimize the time and effort to get this additional functionality up and running.
If the package included the option of turning the ADCD-provided DB2 subsystem into a data sharing group, the implementation effort would be equivalent to a project to migrate from a single DB2 environment into a data sharing one. That is, there would be minimal benefit from the use of the Sysplex Extensions.
Therefore, the package provides a self-contained DB2 data sharing environment based on the DB2 V11 that is provided by ADCD. The 2017 Sysplex Extensions package consists of two new DB2 subsystems, a storage management subsystem (SMS) storage group that contains all of the DB2 databases, DB2 catalogs, logs, archive logs, ICF user catalogs that contain the entries for all these data sets, and so on.
A significant portion of the setup was completed as part of the standard 2017 Sysplex Extensions Parallel Sysplex implementation that is described in Chapter 4, “Installing the 2017 Sysplex Extensions” on page 35. That is, much of the work has already been done. Nevertheless, the sections that follow describe each of the implementation steps so that you can understand the changes that were made for DB2. It is made clear which steps were already completed.
5.1.1 Overview of the DB2 environment
The following information is helpful to understanding the DB2 environment that is delivered by the 2017 Sysplex Extensions:
DB2 Data Sharing Group name: DPDG
DB2 Location name: DPD1LOC
DB2 catalog HLQ: DSNDPDG
DB2 group members: DPD1 (normally on system S0W1) and DPD2 (normally on system S0W2)
Data set names for tailored SDSNSAMP libraries: DSNDPDG.DPDx.SDSNSAMP where n is 1 or 2 for DPD1 or DPD2 respectively.
5.1.2 Implementation
As a starting point for this process, it is assumed that you have already downloaded the DB2001 volume and that you have completed all of the Parallel Sysplex implementation steps that are described in 4.3, “Set up steps for Parallel Sysplex” on page 40. Also, because this package is based on DB2 V11, the ADCD DB2 V11 volumes D2DBB1 and D2DBB2 must be available.
If you want to get your DB2 data sharing environment up and running as quickly as possible, you can skip to “RACF setup for DB2” on page 100. If you want to understand all of the steps that were necessary to prepare the sysplex for DB2 data sharing, continue on with the next section.
SMS setup for DB2 data sharing
|
Note: All of the tasks in this section were completed during the installation of the Sysplex Extensions package, as described in Chapter 4, “Installing the 2017 Sysplex Extensions” on page 35. This description is provided for your information only.
|
Starting with DB2 V10, DB2 requires that certain DB2 data sets are on SMS-managed volumes. Considering this requirement, it is simpler to place all of the DB2-related data sets that are delivered by this package on a single volume in its own SMS Storage group. Configuring the package in this way makes the initial setup a little more complex, but reduces the operational complexity and management on an ongoing basis.
The following changes to SMS are required for DB2:
•Add a Storage Group called DB2FILES and add a volume called DB2001 to the storage group.
•Add a Storage Class called PSADDON.
•Add a Data Class called DPDGDC:
– Set the Data Set Name Type to EXTENDED.
– Set the Extended Addressability to YES.
•Add new entries to your ACS routines by using information from the following members in SYSPLEX.PARALLEL.CNTL:
– ACSDB2DC contains statements that are added to your Data Class ACS routine.
– ACSDB2SG contains statements that are added to your Storage Group ACS routine.
– ACSDB2SC contains statements that are added to your Storage Class ACS Routine.
Add the DB2 user catalog
|
Note: All of the tasks in this section were completed during the installation of the Sysplex Extensions package, as described in Chapter 4, “Installing the 2017 Sysplex Extensions” on page 35. This description is provided for your information only.
|
To access the DB2 related data sets by using the standard catalog search order, you must IMPORT CONNECT the DB2 user catalog into the ADCD master catalog. The IMPCONN job in SYSPLEX.PARALLEL.CNTL does this process for you (that job also imports the CICS user catalog and other user catalogs and aliases).
Parmlib setup for DB2 data sharing
|
Note: All of the tasks in this section were completed during the installation of the Sysplex Extensions package, as described in Chapter 4, “Installing the 2017 Sysplex Extensions” on page 35. This description is provided for your information only.
|
The two new DB2 subsystems must be defined to the system. The IEFSSNPS member that was copied into USER.Z22D.PARMLIB contains definitions for two DB2 subsystems called DPD1 and DPD2. In addition, it includes two entries for the corresponding internal resource lock managers (IRLMs), called DJD1 and DJD2.
In addition to the standard ADCD-provided DB2 software libraries that must be defined to APF, you must add the DSNDPDG.SDSNEXIT data set to APF.
The DB2 software libraries are included in the ADCD-provided PROGAD (APF) and PROGLD (LNKLST) members. So those members are included in the PROG concatenation in the IEASYSPS member. However, this package includes a PROGxx member for the SDSNEXIT library. That member is called PROGPS and is included in the PROG concatenation in IEASYSPS.
|
Important: All of the steps up to this point were completed during the standard Sysplex Extensions installation that is described in Chapter 4, “Installing the 2017 Sysplex Extensions” on page 35.
The steps from this point forward were not completed. Therefore, you must complete these steps.
|
RACF setup for DB2
|
Important: Some of the jobs in this step must run on the S0W2 system. Therefore, ensure that both S0W1 and S0W2 systems are running before proceeding with this step.
|
Several RACF permissions are required to grant access to the new DB2 subsystems. Rather than you having to manually grant all of the accesses by using the RACF ISPF panels, jobs are provided in SYSPLEX.PARALLEL.CNTL to issue the following required RACF commands:
1. Submit the job in the RACFDB21 member to create the RACF profiles used to protect various DB2 interfaces and permit IBMUSER to connect to DB2 from batch jobs.
2. Submit the RACFDB22 job to permit started tasks and batch jobs to connect to DB2. The job then refreshes the RACF profiles on system S0W1.
3. Submit the RACFDB23 and RACFDB24 jobs to add RACF profiles for the WLM environment needed for DB2.
4. Submit the RACFDB25 job to refresh the DB2 RACF profiles on system S0W2.
Take the time to review the job output to verify that all of the commands were processed successfully. A return code 0 for the job does not necessarily mean that all of the commands were processed successfully.
|
Note: The RACF profiles and accesses that are defined by these jobs are acceptable for a single-user development environment. However, if you have users on the system that should not have the provided level of access, adjust the sample jobs.
|
Workload Manager setup for DB2
Although they are not required for the basic DB2 environment that is provided by the 2017 Sysplex Extensions, the DB2 ADMT component issues error messages if the WLM application environments that are used by DB2 are not defined.
These messages can be ignored. However, to suppress those messages, submit the WLMDB21 job in SYSPLEX.PARALLEL.CNTL. This job defines and activates the application environments that are needed for this release’s DB2. This job is a copy of the DB2 installation job DSNTIJRW.
VTAM setup for DB2
The DB2 Distributed Data Facility requires an entry in VTAMLST and an update to the ATCCONPS member to automatically activate the DB2 LU.
The update to ATCCONPS was handled during the 2017 Sysplex Extensions installation, so no further action is required in relation to that member.
However, the DPD1LU and DPD2LU members were not copied to VTAMLST, so you must submit the DB2VTAML job in SYSPLEX.PARALLEL.CNTL now.
After the job completes successfully, issue a RO *ALL,V NET,ACT,ID=DPD&SYSNUM.LU command to activate the DB2 VTAM definitions.
TCP setup for DB2
The section “Other network-related changes” on page 70 mentioned the RESOLVER function and the member that it uses to translate system names to IP addresses. If you do not change the GBLIPNOD member of ADCD.Z22D.TCPPARMS as described in that section, you will observe messages similar to the following when you start DB2 on system S0W2:
DSNL512I -DPD2 DSNLILNR TCP/IP GETADDRINFO(S0W2)
FAILED WITH
RETURN CODE=1 AND REASON CODE=78AE1004
DB2 started task procedures and other proclib members
DB2 and all its associated address spaces require their PROCs to be included in a data set in the JES proclib concatenation. In addition to the procedures for starting all of the DB2 tasks, DSNDPDG.PROCLIB contains the various DB2 procedures that are used for application development.
Submit the DB2PROCS job in SYSPLEX.PARALLEL.CNTL to copy the required members from DSNDPDG.PROCLIB to USER.Z22D.PROCLIB.
You might need to tailor the DB2 procedures that are used for compiling programs (DSNHASM, DSNHC, DSNHICOB, and DSNHPLI), depending on which releases of CICS and IMS you might be using. This release of the zPDT Sysplex Extensions includes the CICS TS 5.2 libraries, but the IMS libraries are commented out.
|
Note: This release of the zPDT Sysplex Extensions does not include the enablement of the CICS to DB2 connection. All of the pieces are in place, and you can connect the CICS regions to the provided DB2 data sharing group. It is hopeful that a future release of the Sysplex Extensions will provide this connection and a sample CICS/DB2 workload.
|
5.2 Controlling the DB2 data sharing group
|
Note: The ADMT part of DB2 uses RRS. Therefore, before you start DB2, ensure that you defined the RRS log streams and that RRS is up and running. Run the D RRS,UR,S command to verify that RRS is active.
|
To start DB2, run a -DPDx START DB2 command, where x is 1 or 2, depending on which DB2 subsystem instance you are starting. Either DB2 can run on either system. However, typically, the assumption is that DPD1 is running on system S0W1, and DPD2 is running on S0W2.
After DB2 starts successfully, first give the VTAMAPPL user ID shutdown authority. To provide this authority, submit the GRANT job in SYSPLEX.PARALLEL.CNTL.
To stop DB2, run the following commands, which are included in the SHUTS0Wn members of USER.Z22D.PARMLIB:
F DPDxADMT,APPL=SHUTDOWN
-DPDx STOP DB2
To access the DB2 ISPF panels, log on to TSO using the ADCD-supplied DBSPROCB logon proc. The IBMUSER and ADCDMST user IDs were defined with SYSADM authority in DB2. You can grant authority to additional IDs as required.
5.3 Maintaining the DB2 environment
DB2 was installed up to Step 20 in the DB2 installation guide (the DSNTIJRT and DSNTIJRV jobs, which enable the DB2 supplied routines).
If you want to change or refer to the DB2 setup jobs, they are contained in the DSNDPDG.DPDx.SDSNSAMP data set. DPD1 was the first subsystem, so it has the full suite of setup jobs. The jobs that are required for DPD2 were only the subset that is required to add a member to a data sharing group.
The SDSNSAMP data set contains the ZPARM jobs that are used for each DB2 subsystem.
If you must rerun the installation/migration clist to make changes to the configuration, the output members from the initial setup are in the DSNDPDG.DPDx.SDSNSAMP data set. The member for DPD1 is called DSNTIDXE, and the member for DPD2 is DSNTIDXF. You must copy these members back to the ADCD-provided DSNB10.SDSNSAMP library before you can run the installation panels. Specify these members as the input on the initial panel.
The DB2 archive log data sets are defined in the DB2 ZPARM as having a retention period of 9999 days, so at some point you need to clean them up to free up space. To do this, complete these steps:
•Do an orderly shutdown of both DB2s.
•Run the DB2CLN1 job in SYSPLEX.PARALLEL.CNTL to get a list of the archive log data sets that are known to DB2.
•Update and submit the DB2CLN2 job to delete the data sets from DB2 bootstrap data sets.
•Manually delete the archive log data sets using IDCAMS DELETE CLUSTER commands. You will need to specify the PURGE option to override the unexpired retention period on the data sets.
5.4 Sample batch job to test DB2 data sharing
It is assumed that you have your own data and programs that you want to import into the data sharing group. However, if you first want to validate the correct functioning of DB2 and DB2 data sharing, this release of the zPDT Sysplex Extensions includes two jobs called DB2IVP1 and DB2IVP2 in the SYSPLEX.PARALLEL.CNTL data set. Although these jobs are simple batch jobs that are based on the IBM-provided DB2 IVP jobs, they are an effective mechanism for verifying that all of the components of the DB2 data sharing environment are working.
To run the jobs, ensure that DB2 is started on both systems and then submit the two jobs. You should see the DB2 group buffer pool structure being allocated.
If you want to use WLM Scheduling Environments to control whether DB2 jobs can be started on a specific system, you can use a Scheduling Environment called DB2AVAIL that is defined in the WLM policy. To use this function, add the SCHENV parameter to the JOB card of your DB2 jobs and use the SDSF SE option to set the status of the DB2AVAIL resource to the wanted setting. An example of the SDSF panel that shows the status of the resource in each member of the sysplex is shown in Figure 5-1.
Figure 5-1 SDSF Scheduling Environment Resource Status window
This example shows that the DB2AVAIL resource has a status of RESET on both systems. When you start DB2 on a system, you can access this panel and change the state of the resource on that system to ON. When you are preparing to stop DB2, you can change the state to OFF, which ensures that no new DB2 jobs are started on that system.
In a real-world system, you connect the use of scheduling environments to your system automation product. For example, when DB2 is started, automation uses a command, such as F WLM,RESOURCE=DB2AVAIL,ON, to enable running DB2 jobs on that system. Before stopping DB2, automation runs a F WLM,RESOURCE=DB2AVAIL,OFF command on that system to stop any other DB2 jobs from being started on that system.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.