Creating Db2 for z/OS data sharing group provisioning services

• Enable Cloud Provisioning Software Services in the z/OSMF server, certifying that the domain to be used has enough systems (LPARs) for the number of members in the data sharing group. IBM Cloud Provisioning and Management currently does not support more than one member of the same data sharing group in the same LPAR.

• Enable a network resource pool (NRP) in the z/OSMF server, with sufficient dynamic virtual IP address (DVIPA) and port allocation ranges for the number of instances provisioned. For example, a two-way data sharing group requires 3 DVIPAs and 3 ports. That is, each n-way data sharing group requires the following network resources:

  • n + 1 DVIPAs: one distributed dynamic virtual IP address (DDVIPA) for the group and one specific DVIPA for each member.

  • n + 1 TCP/IP ports: one TCP/IP port for the group and one specific RESYNCH port for each member.

• Provide the SMP/E Db2 product target libraries, with the the following Db2 12 APARs applied: PH09857; and if Db2 REST services will be enabled on the provisioned Db2 subsystems, APARs PI70652 and PI96649.

• Certify that the SMP/E Db2 product target libraries for SDSNEXIT, SDSNLINK, SDSNLOAD, SDSNLOD2 and IRLM RESLIB are APF-authorized Note: SDSNLOD2 is a PDSE data set, which contains JDBC and SQLJ DLLs. Although DB2 does not require that SDSNLOD2 be APF-authorized, be aware that if this data set is in a STEPLIB data set concatenation of an address space that does need APF authorization, SDSNLOD2 must also be APF-authorized. The provisioning template concatenates SDSNLOD2 when verifying JDBC local connection (Type-2) in Optional Features.

• Provide data set names, including for host languages (see Section 7: Host language data sets, in the dsntivin and dsntivia files.)

• Verify installation, and provide directories where indicated, for the following installed FMIDs:

  • JDBCC12 for Db2 JDBC/SQLJ. All variables must be set in Section 6: Db2 Java properties, in the dstnivin file.

  • JDBCC17 for Db2 ODBC. The following variables must be set in Section 7: Host language data sets, in the dstnivin file: CCOMP, CPPAUTCL, LELKED, LEPLMSGL, and LERUN.

  • HDDA211 for z/OS Application Connectivity.

  • HDBCC1K for Db2 Utilities Suite for z/OS.

• Define sufficient coupling facility (CF) structures for all possible provisioned data sharing group instances, following the naming conventions and the sizing for a medium configuration, as described in Coupling facility structure size allocation.

• Provide a range of DVIPAs and TCP/IP ports to be used under the Network Resource Pool (NRP).

• Provide the Db2 authorization IDs in the following table for Section 4: Db2 authorization IDs in the dsntivin file:

• Define RACF STARTED class profiles to all potential provisioned Db2 subsystem instances associating an ID to be used by each Db2 address space.

• Define RACF DSNR class profiles to control access to any provisioned Db2 subsystem from another environment, such as CICS, IMS, TSO, RRS, BATCH, DDF and REST services.

• Define RACF SERVER class profiles to control access to any provisioned Db2 subsystem because they will use stored procedures in a WLM-established address space.

• Define SMS constructs, such as SMS classes and storage groups, for Db2 provisioning. The SMS storage groups can be per instance or shared by all potential provisioned Db2 instances.The storage administrator can decide if image copy data sets and archive log data sets are to share the SMS storage groups with other Db2 data sets.

• Together with the security administrator, provide access authorization to all prefixes in the following table to the Db2 IDs, including the ID that executes the steps of the Db2 provisioning workflow.

• Define ACS routines to be used to determine the SMS classes and storage groups for data sets allocation during a Db2 subsystem provisioning.

• Define USERCATs and ALIASes, associating them to their specific SMS storage group. Important: The provisioning process determines the groupname value. You must do the definition work for all potential instances. If you are allowing 2 instances of a data sharing group, then you must have 2 sets of definitions below, corresponding to the 2 groupname(s) that can be generated. For example: DSNZ0SYS, DSNZ1SYS, an so on.

(1) The groupname here precedes the following names:

• The instantiated member name, as the prefix in all aliases. For example: DSNZ0.DZ00.*, where DSNZ0 is the groupname, and DZ00 is the instantiated member name.

• The group attach name, as the prefix for IVP data sets, which are allocated only when provisioning the originating member. For example DSNZ0.DZ0G.*, where DSNZ0 is the groupname, and DZ0G is the group attach name.

The following table indicates the steps that are excuted by the provisioning workflow for the originating member and for additional members of the data sharing group.

The following actions are available from z/OSMF Cloud Provisioning Software Services for the provisioned Db2 data sharing group:

The deprovision workflow removes all definitions and data sets related to the deprovisioned Db2 data sharing group. To deprovision a data sharing group, the sample template completes the following high-level actions:

The JDBC enablement optional feature requires connection to the provisioned Db2 subsystem to perform the BIND for the JDBC packages as well as to verify a remote connection (JCC-Type-4).

When connecting, a user ID and password must be passed to the connection statement. Instead of sending clear text passwords, the sample template uses generated RACF PassTickets. Users of the application can then use the PassTickets to authenticate within a RACF-secured network. This procedure prevents the need to store password credentials within the z/OSMF environment.

You must certify that the ID used to execute the workflows has the RACF authority to generate PassTickets to others.

To enable the usage of RACF PassTicket by the sample template, take the following actions:

1. Activate the RACF PassTicket class, by issuing the following commands:

SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA) SETROPTS GENERIC(PTKTDATA)

1. Define RACF profiles for the application in PTKTDATA, by issuing the following commands:

RDEFINE PTKTDATA <applName> SSIGNON(KEYMASKED(<key>)) 
APPLDATA('NO REPLAY PROTECTION')

In the preceding example: <applName> is the name of the application that requests and uses the PassTickets. Provisioned Db2 subsystems accept TCP/IP connections only, therefore we should use the value of the the IPNAME as <applName>.

<key> is a session key with the value of 16 hexadecimal digits (for an 8-byte or 64-bit key). The session key must be identical to the key in the PassTicket definition in each RACF instance. The key for each application must be the same on all subsystems in the configuration.

APPLDATA('NO REPLAY PROTECTION') is the option that you can use to permit reuse of the same PassTicket multiple times.

The following example shows these commands for provisioning two Db2 data sharing groups, each with two-way data sharing. As described in the Naming Convention section, the group name of the data sharing group being provisioned is used for the IPNAME value. Because we expect two data sharing group instances to be provisioned with two members each, you can activate them all in one single job, considering that they will be all under the same RACF database.

//STEP01 EXEC PGM=IKJEFT01                                                     
//SYSTSPRT DD SYSOUT=*                                                         
//SYSTSIN DD *                                                                 
  RDEL PTKTDATA (DSNZ1)                                                        
  RDEL PTKTDATA (DSNZ0)                                                        
  RDEL PTKTDATA (DZ00)                                                         
  RDEL PTKTDATA (DZ01)                                                         
  RDEL PTKTDATA (DZ10)                                                         
  RDEL PTKTDATA (DZ11)                                                         
  RDEL PTKTDATA (IRRPTAUTH.DZ*.*)                                              
RDEF PTKTDATA DSNZ0 -                                          
 SSIGNON(KEYMASKED(E001193519561977)) -                        
 UACC(NONE) APPLDATA('NO REPLAY PROTECTION')                   
RDEF PTKTDATA DSNZ1 -                                          
 SSIGNON(KEYMASKED(E001193519561977)) -                        
 UACC(NONE) APPLDATA('NO REPLAY PROTECTION')                   
RDEF PTKTDATA DZ00 -                                           
 SSIGNON(KEYMASKED(E001193519561977)) -                        
 UACC(NONE) APPLDATA('NO REPLAY PROTECTION')                   
RDEF PTKTDATA DZ01 -                                           
 SSIGNON(KEYMASKED(E001193519561977)) -                        
 UACC(NONE) APPLDATA('NO REPLAY PROTECTION')                   
RDEF PTKTDATA DZ10 -                                           
 SSIGNON(KEYMASKED(E001193519561977)) -                        
 UACC(NONE) APPLDATA('NO REPLAY PROTECTION')                   
RDEF PTKTDATA DZ11 -                                           
 SSIGNON(KEYMASKED(E001193519561977)) -                        
 UACC(NONE) APPLDATA('NO REPLAY PROTECTION')                   
RDEFINE PTKTDATA IRRPTAUTH.DZ*.*                               
PERMIT IRRPTAUTH.DZ*.* CLASS(PTKTDATA) ID(WFexecutorID) ACCESS(UPDATE)     
SETROPTS RACLIST(PTKTDATA) REFRESH                                  
RDEFINE PTKTDATA IRRPTAUTH.DSNZ*.*                                  
PERMIT IRRPTAUTH.DSNZ*.* CLASS(PTKTDATA) ID(WFexecutorID) ACCESS(UPDATE)   
SETROPTS RACLIST(PTKTDATA) REFRESH                                    

The following tables show the authorizations required for certain steps of the sample template. All other steps run under the authorization ID that executes the workflow. You can specify the authorization ID that executes the workflow in the AGEXECID variable in section 4 of the dsntivin and dsntivia input variable files. If the AGEXECID value is blank, the sign-on ID executes the steps.