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:
- remote debug
- full-screen mode using a dedicated terminal
- batch
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:
- 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.
- 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.
- 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.
- 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.
- Compile or assemble your program, as described in Preparing your program for debugging, with the following exceptions:
- For COBOL programs, if the PROGRAM TYPE is SUB and other users
might run the stored procedure while you are debugging it, you cannot
debug this program.
- For Enterprise PL/I programs, also specify the RENT compiler option.
- 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:
- 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;
- 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.
|
This information center is powered by Eclipse technology. (http://www.eclipse.org)