Writing Database Procedures › Methods for Invoking Procedures › DBSTUB2 Invocation Method

DBSTUB2 Invocation Method

The DBSTUB2 invocation method is valid for calling a program written in COBOL or PL/I compiled with any compiler supported by CA IDMS. Usage of this method is optional and not recommended when the program is compiled with an LE-compliant compiler because of performance. This program is an assembler front end that is linked separately from the procedure it calls. The DBSTUB2 program must be linked as the name specified in the Schema CALL statement. The database procedure must be linked as a second name and defined to DC in the SYSGEN.

DBSTUB2 is written with DC system mode calling convention. It runs in MPMODE=CALLER which means multiple task threads can be running through it at the same time and this code must be totally reentrant.

Once DBSTUB2 gains control it activates the real procedure with a #LINK command. IDMS/DC will setup and call the program in user mode.

When the procedure ends, control is returned to DBSTUB2.

This method violates the principal of maintaining control of the CPU. One or more #WAITs can occur during the execution of the #LINK. This increases the likelihood of deadlocks or performance problems.

Following is a sample of DBSTUB2 that calls the CHECKIT database procedure. However, in this case DBSTUB2 has been linked as CHECKIT and the COBOL CHECKIT has been linked as CHECKIT2.

DBSTUB2  TITLE 'Example DB procedure'
         #MOPT CSECT=DBSTUB2,ENV=SYS
*
*    The following code shows how a database procedure might call
*    a program written in a high level language like COBOL II.
*
*    The name in the Schema CALL statement must be this module.
*    The module this program #LINKs must be defined in the DC
*    SYSGEN.  In this example the CHECKIT database procedure
*    would have been renamed to CHECKIT2 and this procedure
*    would be called CHECKIT.
*
*    By #LINKing the DB procedure, the current system mode
*    environment is preserved.  The #LINKed subprogram is setup
*    and called based on how it is defined to DC.  For example
*    a COBOL program would get called as a quasi-reentrant with
*    DC allocating the private copy of WORKING-STORAGE for it.
*
*    ON Entry:  R1 points to the procedure parmlist
*
         USING CSA,R10
STUBEP1  #START MPMODE=CALLER
*        #GETSTK  =8,REG=R11     get 8 words for plist
         USING LWA,R11
*
         LM    R3,R7,0(R1)        get db parameters
         #LINK PGM='CHECKIT2',PARMS=((R3),(R4),(R5),(R6),(R7)),              X
                PLIST=SYSPLIST     link to DB procedure
 *
          #RTN                     return to the DBMS
          LTORG
 LWA      DSECT                    local work area
 SYSPLIST DS    8F                 PLIST for #LINK
          COPY  #CSADS
          END

Following is how DBSTUB2 would be linked.

INCLUDE OBJLIB(DBSTUB2)
ENTRY   STUBEP1
MODE    AMODE(31),RMODE(ANY)
NAME    CHECKIT(R)

CHECKIT would get linked:

INCLUDE OBJLIB(CHECKIT)
ENTRY   CHECKIT
MODE    AMODE(31),RMODE(ANY)
NAME    CHECKIT2(R)

In Conclusion

The methods described in this section solve the problem of calling database procedures that are not reentrant or are written in COBOL or PL/I and compiled with a non-LE-compliant compiler. The overhead of using the methods will be high. DBSTUB1 will have less overhead than DBSTUB2. For performance reasons, we recommend avoiding these methods by writing database procedures as fully reentrant assembler programs. The second best option is to write a database procedure in COBOL or PL/I and compile it with an LE-compliant compiler.