Question posted 3/2/09 by Gary Rubbert
Details:

We have applications that use DB2 tables in multiple regions. Some programs need to be bound to DB2A, while others need to be bound to DB2B. The programs are in one baseline library (SRC), and all create LDB and /or LDC, and DBR library types out of the compile.
*The goal is to bind programs only where and when needed.
What are our options? Trying to automate and not seperate the SRC by DB2 regions.

#ChangeManZMF
#oldforumpost
#post3cf4c74d5a

Comment posted 3/18/09 by Gary Rubbert

Got one answer from the support ticket. Just realized that this is an official Serena Site.

---

Question posted 3/2/09 by Gary Rubbert
Details:

We have applications that use DB2 tables in multiple regions. Some programs need to be bound to DB2A, while others need to be bound to DB2B. The programs are in one baseline library (SRC), and all create LDB and /or LDC, and DBR library types out of the compile.
*The goal is to bind programs only where and when needed.
What are our options? Trying to automate and not seperate the SRC by DB2 regions.

#ChangeManZMF
#oldforumpost
#post3cf4c74d5a

Comment posted 3/4/09 by George Pipka

Hi Gary,
did you ever get an answer to this question, or would you like me to provide one?

---

Question posted 3/2/09 by Gary Rubbert
Details:

We have applications that use DB2 tables in multiple regions. Some programs need to be bound to DB2A, while others need to be bound to DB2B. The programs are in one baseline library (SRC), and all create LDB and /or LDC, and DBR library types out of the compile.
*The goal is to bind programs only where and when needed.
What are our options? Trying to automate and not seperate the SRC by DB2 regions.

#ChangeManZMF
#oldforumpost
#post3cf4c74d5a

George, do you have an answer to the above question.

Thanks,

Dan Lysne

---

Question posted 3/2/09 by Gary Rubbert
Details:

We have applications that use DB2 tables in multiple regions. Some programs need to be bound to DB2A, while others need to be bound to DB2B. The programs are in one baseline library (SRC), and all create LDB and /or LDC, and DBR library types out of the compile.
*The goal is to bind programs only where and when needed.
What are our options? Trying to automate and not seperate the SRC by DB2 regions.

#ChangeManZMF
#oldforumpost
#post3cf4c74d5a

Dan,

Did you get an answer to this?

---

Question posted 3/2/09 by Gary Rubbert
Details:

We have applications that use DB2 tables in multiple regions. Some programs need to be bound to DB2A, while others need to be bound to DB2B. The programs are in one baseline library (SRC), and all create LDB and /or LDC, and DBR library types out of the compile.
*The goal is to bind programs only where and when needed.
What are our options? Trying to automate and not seperate the SRC by DB2 regions.

#ChangeManZMF
#oldforumpost
#post3cf4c74d5a

We had similar problems but we did a totally custom Bind process written in Rexx and disabled the original bind process.

---

Question posted 3/2/09 by Gary Rubbert
Details:

We have applications that use DB2 tables in multiple regions. Some programs need to be bound to DB2A, while others need to be bound to DB2B. The programs are in one baseline library (SRC), and all create LDB and /or LDC, and DBR library types out of the compile.
*The goal is to bind programs only where and when needed.
What are our options? Trying to automate and not seperate the SRC by DB2 regions.

#ChangeManZMF
#oldforumpost
#post3cf4c74d5a

I have come across this situation before, and set up a DB2BINDS REXX program, of which it had a BINDREST (Bind Restrictions) DD that contains control cards to restrict DB2 BINDs for certain DB2 DBRMs to specific DB2 environments.

In the DB2-related skeletons, instead of feeding the DB2 BIND control generated by CMNDB2PL directly to SYSTSIN DD in the DB2 BIND job step that runs PGM=IKJEFT1A, you instead have the DB2 BIND job step (which still runs PGM=IKJEFT1A) invoke a REXX program (DB2BINDS) and feed the BIND control into a different DDNAME, such as BINDCNTL (since the SYSTSIN DD is either DUMMYed-out or used to invoke the DB2BINDS REXX program itself). The DB2BINDS program examines each BIND statement. If the BINDREST DD is allocated and has entries in there, the control cards within BINDREST DD control the DB2BINDS REXX program to "filter-out" BIND statements that are not desired in the target DB2 environment. For the ones that are allowed for a given environment, the DB2BINDS REXX program invokes the DB2 BIND command.

In Application Admin, you set up each target DB2 environment to allow all possible DB2 BINDs that could happen. Thus, CMNDB2PL will generate all possible DB2 BINDs for a given DBRM in a given target environment. But the DB2BINDS REXX program would only filter-through DB2 BINDs that are "allowed" for a given DBRM member name within a given DB2 environment, based on what is specified within BINDREST DD.

Once the BIND control is generated by CMNDB2PL, there is no indication of the DB2 Option's DB2 Logical Names within the BIND control itself. However, within each DB2 Logical Name, there is a DB2 Subsystem ID and a QUALIFIER that is effectively associated with a given DB2 Logical Name. Between these 2 fields, you can determine what BIND control needs to be filtered-out or allowed.

For example, an application may have 3 possible DB2 Logical Names for a PROD installation, which are associated with the following DB2 subsystem ID and QUALIFIER:

• Logical Name 1 - D2P1 for qualifier PROD1
  
• Logical Name 2 - D2P2 for qualifier PROD2A
  
• Logical Name 3 - D2P2 for qualifier PROD2B
  

In the Bind Restrictions file, you can filter-out at the program (i.e. DBRM) member name level:

• DBRM ABC.DBR can be bound to D2P1 for qualifier PROD1, and also D2P2 for qualifier PROD2A and qualifier PROD2B
  
• DBRM XYZ.DBR only needs to be bound to D2P2 for qualifier PROD2B.
  

The BIND Restrictions File, in my case, had a key of Application, DBRM Member Name, and DBRM Library Type (since ZMF now supports multiple DBRM library types). After the key comes an optional "EXCLUSIVE" parameter (which means to only (i.e. exclusively) use the filtration records criteria specified for the DBRM member name, and to not use any non-exclusive BINDREST DD records (usually with wildcards) that would otherwise allow for additional BIND statements to run), and then one or more DB2 subsystem ID and QUALIFIER combinations are specified in which a DB2 BIND is allowed to be done.

Here is a sample:

!
! DB2 BIND Restrictions File
!
! APPL DBRM TYPE DB2 ENVIRONMENT(S)
!
APP1 PROG010 DBR DBP1,SQLPR1A DBP1,SQLPR1B
APP1 PROG010 DBR DBP1,SQLPR1A DBP1,SQLPR1B
APP1 PROG010 DBR DBP2,SQLPR2A DBP2,SQLPR2B
APP1 PROG020 DBR DBP1,SQLPR1*
APP1 PROG020 DBR DBP2,SQLPR2*
APP1 PROG030 DBR DBP*,SQLPR1*
APP1 PROG030 DBR DBP*,SQLPR2*
APP1 PROG040 DBR DBP1,SQLPR1A DBP1,SQLPR1B
APP1 PROG040 DBR DBP2,SQLPR2A DBP2,SQLPR2B
APP1 PROG050 DBR DBP1,SQLPR1A
APP1 PROG050 DBR DBP2,SQLPR2A DBP2,SQLPR2B
APP1 PROG060 DBR DBP2,SQLPR2A
APP1 PROG070 DBR EXCLUSIVE DBP2,SQLPR2A
APP1 PROG080 DBR EXCLUSIVE DBP2,SQLPR2A
APP1 PROG080 DBR EXCLUSIVE DBP2,SQLPR2B
APP1 N* DBR DBP1,SQLPR1A
* * * DBP1,SQLPR1A DBP1,SQLPR1B
VEND * VDB DBP1,SQLPR1A DBP1,SQLPR1B

---