Using Db2 Distributed Data Facility Support

To create Xchange DDF requests, first enter the DDF primary command on the Simulated Date Time Settings screen as described in Primary Commands. A screen is displayed in date/time offset format as shown in the following figure:

Simulated Date Time Settings Screen for DDF Support

-------------------- Simulated Date Time Settings ---------- Process Complete
COMMAND ===>                                                  SCROLL ===> CSR
                                                              System ID: AC12
Line Commands: H - Set and Hold R - Reset D - Delete
Status Codes: Q - Queued P - Pending * - Error
                                                         - Constants -
Filter:        **** ************ ******** ********   **** ** **   *
                DB2   Correlation   Resource
C/S Owner     SSID      ID          Name    UserId     Days Hrs Mins Ind
_ Q PPRJET0   D14E PPRJET0O____ XGBCHDB2 PPRJET0    0030 __ __   +
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __ _
_            ____ ____________ ________ ________   ____ __ __   _
_            ____ ____________ ________ ________   ____ __ __   _
_            ____ ____________ ________ ________   ____ __ __   _
_            ____ ____________ ________ ________   ____ __ __   _
_            ____ ____________ ________ ________   ____ __ __ _
******************************* BOTTOM OF DATA ********************************

Create Xchange requests as you would using the ISPF interface with Date/Time offset, but use the Db2 request fields to specify the criteria that will be used at execution time to see whether a Db2 Date/Time request is eligible for exchange.

After entering a DDF request, you can press PF3 to return to the standard Simulated Date Time Settings Screen for the ISPF Interface screen. Queued DDF requests are displayed without a specific date and time. Completed DDF request messages are displayed with their simulated date/time calculated at execution from the Constants field values entered on the DDF screen. The Correlation ID field appears in the Jobname field and the first 4 bytes of the Stepname field if necessary. The Resource Name appears in the Procstep field. =DDF appears in the first four positions of the Program field and the Db2 subsystem ID, if specified, appears in the last four positions to uniquely identify these requests.

Unlike other Set and Hold requests that become queued and completed, a DDF request remains queued and active until it is deleted or Xchange is cycled.

Tip

The DDF screen remains unchanged and displays only requests, not messages.

Simulated Date Time Settings Screen Showing a DDF Request

BMC AMI DevX Xchange ---- Simulated Date Time Settings ---- Row 1 to 14 of 14
COMMAND ===>                                                 SCROLL ===> CSR
                                                             System ID: AC12
Type Legal on the command line for Copyright/Trade Secret Notice Information
Line Commands: S - Set H - Set and Hold R - Reset D - Delete A - Set Active
Status Codes: Q - Queued P - Pending A - Active E - Executing * - Error
               C - Completed N - Not Active
Filter:        ******** ******** ******** ******** **** ** ** ** ** **
C/S Owner     Jobname Stepname Procstep Program   YYYY/MM/DD HH:MM:SS Jobno
_ Q PPRJET0   PPRJET0X ________ XGBCHDB2 =DDFD14E ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_           ________ ________ ________ ________ ____ __ __ __ __ __
_           ________ ________ ________ ________ ____ __ __ __ __ __
_           ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __
_            ________ ________ ________ ________ ____ __ __ __ __ __

******************************* BOTTOM OF DATA ********************************

Db2 DDF Request Fields

Use the Db2 request fields to specify the criteria that will be used at execution time to see whether a Db2 Date/Time request is eligible for exchange. The Owner field and the S portion of the C/S field are display-only. You can type data into all other fields. The Filter row contains a series of mask fields, each corresponding to the column directly following it.

Tip

Only those fields unique to Xchange’s DDF support are described in this section. For descriptions of other fields, see Fields.

Filter DB2 SSID

The initial value is all asterisks, which directs Xchange to display all DDF requests for which the rest of the request entry fields match their corresponding masks. This mask is saved upon exit and restored upon entry.

An asterisk represents a single wildcard character in the position of the DB2 SSID where it is placed. For example, masks D*** and **0* would each result in the display of all DDF requests associated with DB2 SSID D801 assuming the rest of the request entry fields match their masks. However the masks D* , *01 , and *01*, would each result in the display of no DDF requests for DB2 SSID D801, even if the rest of the request entry fields match their masks. Any character is valid in this field.

Filter Correlation ID

The mask for the Correlation ID field. The initial value is all asterisks, which directs Xchange to display all DDF requests for which the rest of the request entry fields match their corresponding masks. This mask is saved upon exit and restored upon entry.

An asterisk represents a single wildcard character in the position of the correlation ID where it is placed. For example, masks TST********* and ***JOB****** would each result in the display of all DDF requests associated with correlation ID TSTJOB01 — assuming the rest of the request entry fields match their masks. However the masks TST* , *JOB01 , and *JOB* would each result in the display of no DDF requests for correlation ID TSTJOB01, even if the rest of the request entry fields match their masks. Any character is valid in this field.

Filter Resource Name

The mask for the Resource Name field. The initial value is all asterisks, which directs Xchange to display all DDF requests for which the rest of the request entry fields match their corresponding masks. This mask is saved upon exit and restored upon entry.

An asterisk represents a single wildcard character in the position of the resource name where it is placed. For example, masks PRGM**** and ****0001 would each result in the display of all DDF requests for resource name PRGM0001 — assuming the rest of the request entry fields match their masks. However the masks PRGM* and *0001 would each result in the display of no DDF requests for resource name PRGM0001, even if the rest of the request entry fields match their masks. Any character is valid in this field.

Filter UserId

The mask for the UserId field. The initial value is all asterisks, which directs Xchange to display all DDF requests for which the rest of the request entry fields match their corresponding masks. This mask is saved upon exit and restored upon entry.

An asterisk represents a single wildcard character in the position of the user ID where it is placed. For example, masks ID****** and **10**** would each result in the display of all DDF requests for user ID ID10T — assuming the rest of the request entry fields match their masks. However the masks ID* and *10* would each result in the display of no DDF requests for user ID ID10T , even if the rest of the request entry fields match their masks. Any character is valid in this field.

DB2 SSID

The DB2 SSID identifies the Db2 subsystem to which the request is restricted. All characters are translated to uppercase for evaluation.

Correlation ID

The Correlation ID is a Db2 field that identifies the thread executed by Db2. For batch jobs, this is generally the Jobname. For other environments, please see to the appropriate IBM Db2 Administration Guide. All characters are translated to uppercase for evaluation.

Resource Name

The Resource Name is a Db2 field that identifies the resource plan. For batch jobs, this is generally the 8-byte Plan Name used in the Db2 Bind process. For other environments, please see to the appropriate IBM Db2 Administration Guide. All characters are translated to uppercase for evaluation.

UserId

The UserId is optional. If this field is left blank, the userID of the requester is used. If input to this field is an asterisk wildcard character, Resource Name must be DISTSERV and the requester must be defined as an Xchange Administrator or an error message will be displayed. A trailing asterisk is permitted, but an embedded asterisk is not. This field is not validated to ensure it is a valid user ID. In addition to the selection criteria in use today, if the User Id of the Db2 DDF job or service matches that of the request and it meets existing security criteria, a Date/Time substitution will occur.