Rational Developer for System z, Version 7.6

Preparing a DB2 stored procedures program

This topic describes the information you need to collect and the steps you must take to prepare a DB2® stored procedure for debugging with Debug Tool. Debug Tool can debug stored procedures where PROGRAM TYPE is MAIN or SUB; the preparation steps are the same.

Before you begin, verify that you can use the supported debugging modes. Debug Tool can debug stored procedures written in assembler, C, C++, COBOL and Enterprise PL/I in any of the following debugging modes:

Read DB2 Application Programming and SQL Guide, section "Using Stored procedures for client/server processing", to verify that your stored procedure complies with the format and restrictions described in that section.

To prepare a DB2 stored procedure, do the following steps:

  1. Verify that your DB2 system administrator has completed the tasks described in section "Preparing your environment to debug a DB2 stored procedures" of Debug Tool Customization Guide. The DB2 system administrator must define the address space where the stored procedure runs, give DB2 programs the appropriate RACF® read authorizations, and recycle the address space so that the updates take effect.
  2. For stored procedures of program type SUB, verify that when your system programmer or DB2 system administrator defines the WLM address space, he sets the value for NUMTCB to 1. NUMTCB specifies the maximum number of Task Control Blocks (TCBs) that can run concurrently in a WLM address space. If the stored procedure might run in a TCB other than the one it was started in, you will not able to debug that stored procedure. Setting the value of NUMTCB to 1 ensures that the stored procedure is not run in a different TCB.
  3. When you define your stored procedure, verify that you specify the correct value for the LANGUAGE parameter and the PROGRAM TYPE parameter. For C, C++, COBOL or Enterprise PL/I, the PROGRAM TYPE can be either MAIN or SUB. For assembler, the PROGRAM TYPE must be MAIN.
  4. Determine if other users might run the stored procedures while you are debugging it. If other users might run the store procedure, you might not be able to debug it.
  5. Compile or assemble your program, as described in Preparing your program for debugging, with the following exceptions:
  6. Determine which of the following methods your site uses to specify the TEST runtime options:
    Through the Language Environment EQADDCXT exit routine
    Prepare a copy of the EQADDCXT user exit as described in Specifying the TEST runtime options through the Language Environment user exit.
    Through the DB2 catalog
    Define the RUNOPTS field of the DB2 catalog to include the desired TEST runtime options by doing the following steps:
    1. Write the stored procedure. In the following example, the stored procedure is a COBOL program called SPROC1, the type is SUB, it runs in a WLM address space called WLMENV1, and it is debugged in remote debug mode:
      create procedure sproc1
         language cobol
         external name sproc1
         parameter style general
         wlm environment wlmenv1
         run options 'TEST(,,,TCPIP&9.112.27.99%8001:*)'
         program type sub;
    2. Verify that the stored procedure is defined correctly by entering the DB2 SQL SELECT command. For example, you can enter the following command:
      select * from sysibm.sysroutines;
      If you need to update the definition, use the following command:
      alter procedure sproc1 run options 'TEST(,,,TCPIP&9.112.27.21%8001:*)';
      An example of an update that requires you to use the alter procedure command is to update the TCP/IP address of the workstation where the remote debug session would be started.

Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)