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 through a VTAM 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)