How to make your DB2 program work in a DRDA setup ?

DRDA - Distributed Relational Database Architecture.


Couple of you will have this question - Why do you need the DRDA set up ? The answer will reside on the early pages of your account when it was set up. We cannot go back to those days, but let me try to explain the architecture from a DBA's perspective.


You might have two separate production LPAR's ( APAR & BPAR ) each with a single subsystem ( APAR - ASUB, BPAR - BSUB ). Business decided that from ASUB I should be able to talk to BSUB. If ASUB has the DB2 objects ( database, tablespace, tables ) then BSUB will have a reference using an ALIAS to the object in ASUB.


How to make your DB2 program work in a DRDA setup ?


All I have to do is link the program to the remote object using the below BIND structure on the DB2 PLAN. The program in the form of a DB2 package has to exist in ASUB and BSUB, but the PLAN need not if you are using the below BIND syntax :


 DRDA_BIND_PLAN_Approach1


The above syntax is from APAR, ASUB - PROG001 is mapped on to PLAN001 and the syntax of PLAN001 is tweaked so that it is able to talk to BSUB using DRDA protocol


Note : This PLAN should exist or should be created in the region where you want to execute the program which in our case is ASUB. This plan need not exist in BSUB, however it is mandatory that PROG001 should exist in ASUB as well as BSUB.


Is there any other way ? Yes -

1) The below syntax is from APAR, ASUB - PROG001 is mapped on to PLAN001 - PROG001 accesses the ALIAS which in turn access the TABLE using the DRDA protocol on BSUB


DRDA_ASUB_BIND_PLAN_Approach2


2) The below syntax is from BPAR, BSUB - PROG001 is mapped on to PLAN001 - PROG001 accesses the TABLE and waits for the connection in case PROG001 present in ASUB is executed from APAR


DRDA_BSUB_BIND_PLAN_Approach2


Note : The PLAN names in both the LPAR's are the same, Unlike the previous example in which we only had one PLAN which would establish a connection, In the above example we saw two plans being created that would suffice the DRDA establishment

The BIND note :


Both these programs should have a contoken match else will end up with a -805. In other words, the programmer should not miss any BIND's in the remote/physical region when he is working with DRDA protocol.

2 comments:

  1. Fennen, Odessa (HC Product Support)21 October 2013 at 09:50

    I remember the issues we had on Tops when we went to V10…we did not have the package defined on both subsystems.

    Thanks for making my mind get back to DB2 on Monday morning :)

    ReplyDelete
  2. Well, I am glad and thank you for being an active reader on db2champ Odessa !

    ReplyDelete