Validating WSLs
Validating a WSL enables you to generate a report about the syntax and the impact to other objects.
About this task
Before you run a WSL, you might want to have the syntax of the SQL statements checked and assess the impact that running the WSL would have on objects.
The impact analysis portion of the validate report lists the impact to the objects by these categories:
- Implicitly dropped objects
- Existing objects that are implicitly dropped but not re-created by the WSL.
- Explicitly dropped objects
- Existing objects that are explicitly dropped but not re-created by the WSL.
- Recreated objects
- Existing objects that are implicitly or explicitly dropped and re-created by the WSL.
- Altered objects
- Existing objects that are altered by the WSL.
- Created objects
- Objects that did not exist and are created by the WSL.
- Temporary objects
- Objects that did not exist and are created and then dropped by the WSL.
Each affected object is included in only one of these categories.
After the initial validation, you can add custom validation rules for objects from Object Compare, CM Analyze, and CM Batch functions. To perform a custom validation, you must write the REXX exec that is used to perform the validation. You can specify the name of your REXX exec on the Options for Change Functions panel (ADB2PCO). The name of your REXX exec is then stored in your profile shared pool. During the validation process, the REXX exec name will be added to the JCL as the value for the STMTEXIT parameter. The REXX exit cannot connect to Db2, because the connection between Db2 Admin Tool and Db2 is already active.
- Statement type
- Object type
- Object qualifier
- Object name
The custom validation function will continue processing until all validations are complete and all errors are reported. Validation errors are written to a separate DD file called VALOUT and use the data set name prefix that you specify. An example of a data set name is SYSADM.E344.VALOUT. Each error message from the REXX exec consists of a return code followed by a colon and the message string, as shown in the example below.
'08:Changes in database not allowed'The return string from the REXX exec is saved to the VALOUT DD in the format shown in the example below.
SUPPLEMENTAL VALIDATE WORK STATEMENT LIST REPORT
================================================
Prepared on DSN7 (DB2 Release 720) by NBRON at 2006-07-08 10:48
for NBRON.WLIST.VALIDATE(SAMPLE)
ADB3036E RC=08 An error occurred while processing the ALTER DB statement:
CHANGES IN DATABASE NOT ALLOWEDIf an object does not require validation, or if there are no errors, the REXX exec returns the code '00'.
Procedure
To validate a WSL:
What to do next
- For Object Compare and CM Analyze, use the STMTEXIT parameter. The value for this
parameter can be found on the Options for Change Functions panel (ADB2PCO). You can
manually update that value by changing it in the JCL, then submitting the
JCL.
//ADBWL DD DISP=SHR, // DSN=SYSADM.WSL //CAT DD DSN=&&CATOUT2, // DCB=(LRECL=16800,RECFM=VB,DSORG=PS), // SPACE=(TRK,(15,15),RLSE), // UNIT=SYSDA, // DISP=(NEW,PASS) //ADBUEXEC DD DISP=SHR,DSN=SPF.PRODUCT.ISPTLIB //ADBUEXE1 DD DISP=SHR,DSN=SPF.PRODUCT.ISPTLIB //VALOUT DD SYSOUT=* //IN DD * DB2SYS = DSNB, DB2ALOC = DB2SERV = DSNB DB2AUTH = 'S22957' DB2REL = 1115 ADBTEST = YES, PLAN = ADB, ADBASUSR = , ADBASUSB = NO, SRCWSLST = TEST3, SRCWSLIB = SYSADM.WSL, STMTEXIT = TEST /* /* - For CM Batch, use the VALIDATION_STMTEXIT parameter. This parameter does not have a
default
value.
//* DB2 ADMIN ISPF BATCH //* //T03REG EXEC GOCCM,SSID=DSNB,PLAN=ADBDEV,GRP=UB2DEV0,USRGRP=S45801 //GOCCM.PARMS DD * ACTION_IMPORT_CHANGE='N' ACTION_ANALYZE_CHANGE='Y' CHANGE_OWNER='S22957' CHANGE_NAME='IMPORT_DSTCHANGE' PDS_FOR_WSL='SYSADM.WSL' VALIDATE_STMTEXIT='TEST' CHANGE_COMMENT='' ;