You must create a DB2CLIST member for each DB2® application plan or package. The DB2CLIST
is a TSO CLIST or REXX procedure that allows you to BIND or FREE the DB2 application. This exec should
contain code to perform the following functions:
- Allow different DB2 Subsystem
names to be assigned to each group
- Allow different DB2 Owner
and Qualifier and other parameters to be assigned to each group
- BIND the application plan or package
- Optionally FREE the application plan or package.
The parameters and logic required are shown in Figure 1.
The DB2CLIST member allows you to specify which DBRMs are bound
into the application plan or package by use of the %INCLUDE statement.
The INCLUDE statement consists of a %INCLUDE keyword followed by the
name of the included DBRM. SCLM parses the DB2CLIST member and keeps
a list of included DBRM names, as well as other accounting information
in the account record for the DB2CLIST member. The INCLUDE directive
and DBRM name must be on the same line. The format of the INCLUDE
statement is:
/* %INCLUDE dbrm-name */
You can look at the names of included DBRMs for a DB2CLIST by browsing
its accounting information:
- Select the Utilities option from the SCLM Main Menu.
- Select the Library option from the SCLM Utilities Menu.
- From the SCLM Library Utility - Entry Panel, enter the DB2 type to be used during Build.
- From the list of members, select the DB2CLIST that you want to
examine and browse its accounting information.
- From the Accounting Record for the DB2CLIST, select the Number
of Includes.
- Finally, you see the list of included DBRMs in the DB2CLIST.
The DB2CLIST is usually built and promoted by using an architecture
definition. Use the SINC or INCLD keyword to reference the member
from an architecture definition as shown previously. The DB2CLIST
member can also be built or promoted directly without using an architecture
member. When the DB2CLIST member is built or promoted directly or
is processed through an INCLD architecture definition keyword, SCLM
uses the defaults defined in the DB2CLIST language definition.
Figure 1. DB2CLIST
generic example/* REXX */
Arg INPARMS
Parse var INPARMS '(' OPTION ' ' '(' GROUP ' '
/*********************************************************************/
/* SPECIFY AN INCLUDE FOR THE DBRM TO BE INCLUDED IN THE DB2 */
/* PACKAGE. SCLM TRACKS DEPENDENCY ON DBRMS WITH THE COMMENTED */
/* OUT INCLUDE STATEMENT. */
/*********************************************************************/
/*** THE INCLUDE STATEMENT MUST REMAIN COMMENTED OUT. ***/
/*********************************************************************/
/* */
/* %INCLUDE SCLMDB2P */
/* */
/*********************************************************************/
/* SET UP THE PARMS FOR A PACKAGE BIND. */
/*********************************************************************/
MEMBER = "SCLMDB2P"
EXPLAIN = "NO"
/*----------------------------------------*/
/* CALL SCLMBIND EXEC TO PERFORM BIND */
/*----------------------------------------*/
PARMS = OPTION GROUP MEMBER EXPLAIN
Address TSO "EX 'SCLMTEST.PROJDEFS.SOURCE(REXXBIND)' '"PARMS"'"
EXITCC = RC
Exit EXITCC
We can see in the above example the following key points
- The DB2CLIST translator will pass in an Option and a Group. The
OPTION will be BIND if the translator is executed at Build time or
at promote time during the COPY phase. The OPTION will be FREE if
the translator is in the PURGE phase of the promote.
- The DBRM name is specified in the commented out %INCLUDE. This
will maintain SCLM dependency between the DBRM member and the DB2CLIST
that needs to be run to do the bind.
- Certain parameters are set up for binding such as EXPLAIN. Other
parameters could also be set up, such as ISOLATION and VALIDATE for
example. If there are bind options that are specific to a particular
member then they can be set here.
- The bind processor is called to do the actual bind and set up
other parameters based on the Group where the bind needs to occur.
The actual bind could be coded in the DB2CLIST but it is better practice
to keep your bind processor separate from the DB2CLIST members. This
means that if any bind options change in future, the DB2CLIST might
not need to be changed, only rebuilt, thus minimizing the changes
required.
- It is possible to include a "Select" on the group and set
group-specific parameters there rather than in the bind processor.
It is also possible to include the bind invocation in the DB2CLIST
but this is not advisable, as if a certain bind parameter changed
then all the DB2CLIST members would need to change.
This is an example of the bind processor:
Figure 2. Bind exec example (Part 1
of 2)/* REXX */
Arg OPT GRP MEMBER EXP
/* Set bind options based on group */
rcode = 0
Select
When (GRP = 'PROD') Then
Do
SUBSYS = 'DI21'
OWNER = 'PRODDBA'
ACTION = 'REP'
VALIDATE = 'RUN'
ISOLATION = 'CS'
EXPLAIN = 'NO'
QUALIFIER = 'PRODDBA'
End
When (GRP = 'TEST') Then
Do
SUBSYS = 'DI21'
OWNER = 'TESTDBA'
ACTION = 'REP'
VALIDATE = 'BIND'
ISOLATION = 'CS'
EXPLAIN = 'NO'
QUALIFIER = 'TESTDBA'
End
When (GRP = 'DEV1') Then
Do
SUBSYS = 'DI21'
OWNER = 'DEV1DBA'
ACTION = 'REP'
VALIDATE = 'BIND'
ISOLATION = 'CS'
EXPLAIN = EXP
QUALIFIER = 'DEV1DBA'
Call Bind_it
End
When (GRP = 'DEV2') Then
NOP /* no bind needed */
Otherwise
NOP /* no bind needed */
End
Exit RCODE
Figure 3. Bind exec example (Part 2 of 2)Bind_it:
If OPT = 'BIND' Then
Do
/* Create a bind control statement as a single long line. */
DB2_Line = "BIND PACKAGE("GRP") MEMBER("MEMBER")" ||,
" OWNER("OWNER")" ||,
" ACTION("ACTION")" ||,
" VALIDATE("VALIDATE")" ||,
" ISOLATION("ISOLATION")" ||,
" EXPLAIN("EXPLAIN")" ||,
" QUALIFIER("QUALIFIER")"
/* Write the bind control statement to the data queue and execute */
/* DB2 to perform the bind. */
queue DB2_Line
queue "End"
Address TSO "DSN SYSTEM("SUBSYS")"
rcode = RC
End
If OPT = 'FREE' Then
Do
/* At this point SCLM passes the from-group information so that */
/* the package at the from-group can be FREEd if required */
End
Return