Debugging with Db2 stored procedures

Code Debug TSO, a testing and debugging product, supports the debugging of Db2 stored procedures using the DB2 Stored Procedure option. Operation of the product requires the stored procedure to reside on an OS/390 or z/OS system. The client can be either local (OS/390 or z/OS) or remote.

This section provides more information about the following topics:

• Overview of Db2 stored procedure support
• Starting an Code Debug TSO Db2 stored procedure debugging session using Batch Connect
• Debugging a Db2 stored procedure
• Specifying the JCL
• Editing the JCL
• Debugging a client application and a Db2 stored procedure together
• Db2 stored procedure security considerations
• Foreground debugging of Db2 stored procedures

Db2 stored procedure requirements

Code Debug TSO Db2 Stored Procedure support requires:

• Db2 Version 6.1 or above.
• Workload Manager (WLM) managed stored procedures.
• Installation of Code Debug TSO Batch Connect if this feature is to be used for debugging stored procedures. (See  Milestone-7-Configuring-Batch-Connect-support in the Code Debug TSO and Code Debug IMS Installation and Configuration Space.)
• Installation of Code Debug TSO Stored Procedure support (See  Milestone-10-Configuring-Db2-Stored-Procedure-support in the Code Debug TSO and Code Debug IMS Installation and Configuration Space).

Overview of Db2 stored procedure support

To debug a stored procedure, you must first inform Code Debug TSO which stored procedure you want to debug. The stored procedure will be submitted with a predefined Application Environment for Code Debug TSO’s use.

Next, the client application (the program that calls the stored procedure) must be started. The client can be local to OS/390 (such as batch, IMS, or CICS) or remote (such as Windows, Windows NT, OS/2, Unix, Powerbuilder, or Visual Basic).

After the client application begins executing and invokes the stored procedure, Code Debug TSO intercepts the request from Db2 to WLM to schedule the stored procedure to be executed. Code Debug TSO will then direct WLM to use the previously submitted stored procedure with the Code Debug TSO application environment.

Code Debug TSO Stored Procedure support can use either foreground debugging or Code Debug’s Batch Connect feature. After the client application has made the call to the stored procedure, the user can debug the stored procedure in their TSO address space or initiate a Batch Connect debugging session by attaching to the stored procedure. The source for the stored procedure will be displayed and execution will be paused at the entry to the stored procedure.

From this point, all available Code Debug TSO commands may be used for debugging the stored procedure. You can step through the entire stored procedure until it returns control through WLM, sending back requested values and return codes to the invoking (client) program. At this point, either the debugging session will terminate or a second invocation of the stored procedure can begin. When setting up the debugging session, you were required to enter how many times the stored procedure will be intercepted by Code Debug TSO (this is specified in the Maximum Number of Tests field). If you entered 1, the debugging session ends after the first invocation of the stored procedure has completed. If you entered a number greater than 1, Code Debug TSO will wait for the next call to the stored procedure to restart the debugging session.

After the debugging session is finished, you will be positioned in the Code Debug TSO session log and a TEST COMPLETED message will be displayed. At this point, you would normally enter the GO command, instructing Code Debug TSO to clean up the environment and terminate the stored procedure address space.

As an alternative, you can at any time issue the EXIT command, which instructs Code Debug TSO to end the test immediately. Be aware that because this action prematurely ends the test (the application epilog code is not executed), this is treated as an abend. If the EXIT command is issued at any point other than after the Code Debug TEST COMPLETED message has been received, any Db2 table updates may be rolled back during this period, and the stored procedure will not return requested values and return codes to the invoking (client) program.

Starting an Code Debug TSO Db2 stored procedure debugging session using Batch Connect

Code Debug TSO consists of specific menus and screens accessed through ISPF. During your debugging session, Code Debug TSO screens are viewed on a TSO terminal.

Before starting the session, prepare your programs (precompile, compile, and link edit) with the BMC AMI Common Shared Services (CSS) language processor. You can use the Code Debug TSO online facilities to prepare your programs. For more information about BMC AMI Common Shared Services , see the Common Shared Services User/Reference Guide.

Once you have a valid load module and DDIO data set for the stored procedure, log on to TSO and invoke Code Debug TSO. Use the procedures that are in effect at your site. These procedures will include the following steps:

1. From the Code Debug TSO Primary Menu (following figure), select option 4 (Stored Procedures) and press Enter.
   Code Debug TSO Primary Menu  

    -----------  BMC AMI DevX Code Debug for TSO 17.02 - PRIMARY MENU  ------------
   OPTION  ===>                                                                   
                                                                                  
            0  DEFAULTS      - Specify defaults                                   
            1  PREPARE       - Prepare programs for debugging                     
            2  TSO           - Debug programs interactively under TSO             
            3  BATCH         - Debug programs interactively under batch           
            4  STORED PROC   - Debug DB2 Stored Procedures interactively          
            5  UTILITIES     - Perform utility functions                          
            F  FADB2         - Invoke File-AID for DB2                            
            FA FILE-AID      - Invoke File-AID for MVS                            
            FI FILE-AID/IMS  - Invoke File-AID for IMS                            
            C  CODE COVERAGE - Code Coverage Reports and Utilities                
            T  TUTORIAL      - Display information about Code Debug TSO           
            X  EXIT          - Exit primary menu                                  
                                                                                  
      Profile ===> DEFAULT  - *** NO DESCRIPTION ***                              
                                                                                  
      For Online Technical Support Reference: https://support.bmc.com             
          COPYRIGHT (C) 2016, Compuware Corporation. All rights reserved.         
          COPYRIGHT (C) 2016, 2020, 2023 BMC Software, Inc. All rights reserved.  
                                   (800) 538-7822                                 
   
              Press ENTER to process  or  enter END command to terminate          

   Important

   The Code Debug TSO Process DB2 Stored Procedures screen is displayed.

2. On the Process DB2 Stored Procedures screen, type SETUP on the command line and press Enter to display the Code Debug TSO Setup Menu screen.
3. Specify an A (All) in the OPTION field of the Setup Menu screen and press Enter to display each of the screens in succession and review your setup selections. Note the following:
   • Load libraries: Base Code Debug load libraries not already defined during installation. Verify that the order of concatenation is correct. Help libraries are also listed on this screen.
   • DDIO Data set Files: The library name should be the data set name of the DD CWPDDIO in your Code Debug compile step. The field designations are User Libraries and Installation Libraries.
   • Test script libraries.
   • Test session log data set.
   • Test session script data set.
   • Db2 system names and DSNLOAD data sets.
   • Code Coverage data sets and session parameters (if installed at your site).
   • Test session document data set—used for diagnostic purposes under the direction of Code Debug Technical Support. Disposition after test as D.

   • Extended setup options.

     Important

     As you view the individual screens, you may encounter the message:

     Changes made to this list override installed defaults
4. If everything is correct, press PF3 from the Setup Menu to return to the Process DB2 Stored Procedures screen (see Code Debug TSO Process DB2 Stored Procedures Screen).
5. Fill in the schema name, the stored procedure name or UDF, Db2 subsystem name, and maximum number of tests for the stored procedure that you wish to debug. The stored procedure name can be a stored procedure, trigger, or UDF. In the case of a UDF, the procedure name should be used in the Stored Procedure Name or UDF field. In the case of triggers, the trigger must use triggered SQL that invokes a stored procedure. So, on the CREATE TRIGGER you should include the SQL that calls the stored procedure.
6. Fill in the client end userID, PC account code, or IP address of the computer. You may also enter an asterisk (*) to match on anything.
7. Set the User Supplied WLM JCL field to N (No) to make Code Debug retrieve the JCL defined for the stored procedure. Set User Supplied WLM JCL to Y (Yes) if you wish to specify your own JCL to execute the stored procedure. When specifying Y, an additional Select Job Step screen will be displayed where you must enter the data set that contains the JCL. (This JCL must execute the WLM server.)
8. Convert and Submit the JCL: The Select Job Step screen is used to specify how you want each job step to execute (in interactive or unattended mode), and if you want Code Coverage to be active or not. When a job step is selected for interactive debugging, the source for that step is displayed at your terminal.
   When a step is selected to run in unattended mode, you cannot interact with the step from your terminal. If you want to debug the step, Code Debug debugging commands must be read from a test script and the output results from the test session are written to the session log.
   You can submit the job from this screen, or you can edit the JCL. When you submit the job, the Batch Connect JCL scanner automatically converts each step to execute in the specified mode (interactive or unattended).
9. Connect to the Job: If you submit the job with the RUN command, you are automatically connected to the job steps that were specified to execute in interactive mode. If you submit the job with the SUBMIT command, you must use either the CONNECT or STATUS command to connect your terminal to the job steps selected for interactive debugging.
10. Edit the JCL: Optionally, you can access the Edit Facility from the Process Execute JCL screen or Select Job Step screen to view and confirm the JCL conversion or to make changes to the JCL.
11. Once the debugging session is submitted, Code Debug TSO waits for the stored procedure to be called by the client application. After the stored procedure has been called, you can connect to it with Code Debug TSO.
12. View the Code Debug TSO source display on the TSO terminal.
13. Debug the stored procedure using any of the Code Debug TSO debugging commands.
14. At the end of the test, type GO or EXIT and press Enter. EXIT is a premature end to the test and will cause an abend. Db2 updates may be rolled back during this period.
15. If you enter a number greater than 1 in the Maximum Number of Tests field, Code Debug TSO will wait until the next time the stored procedure is called, and then return you again to the source.

Debugging a Db2 stored procedure

From the Code Debug TSO primary menu, select OPTION 4 (STORED PROC) to debug a Db2 stored procedure. Press Enter and the Code Debug TSO Process DB2 Stored Procedures screen shown in following figure is displayed.

Code Debug TSO Process DB2 Stored Procedures Screen

After the required information is entered, the JCL needed to execute the stored procedure must be submitted.

The SEtup command displays the Setup Menu screen from which you can select screens for specifying load libraries, DDIO data sets, and so on.

The fields on the Process DB2 Stored Procedures test screen are:

Schema Name

Used to supply the schema name associated with the stored procedure. Code Debug  will use this name, along with the stored procedure name, to resolve the Workload Manager (WLM) application environment and the load module name. Your site’s Db2 administrator or WLM System Support specialist should be able to provide the schema and stored procedure names that have been defined to WLM and Db2. Beginning with Db2 8.1, the schema name can be up to 128 bytes long.

Stored Procedure Name or UDF

Used to identify the OS/390 Db2 stored procedure to be debugged using Code Debug TSO. Beginning with Db2 8.1, the stored procedure name can be up to 128 bytes long.

Client End UserID or PC Account Code or IP Address

Enter whichever of the following is appropriate for your test:

• The ID of the user executing the client program that calls the stored procedure. If the client is a batch job, specify the user ID assigned to the job. Code Debug will not trap the stored procedure if the client calling it is associated with a different user ID.
• The TCP/IP address where a network call of the stored procedure is done. An example would be a Db2 UDB on the PC.
• The Db2 accounting code of the PC used to execute the client program. If Db2 UDB is installed and appropriately configured on the PC, the accounting code can be set at the DOS prompt by entering DB2SET DB2ACCOUNT=xxxxxx where xxxxxx is the desired code. This will cause the account code to be passed to the mainframe when calling the stored procedure.
• An asterisk (*). This will match on anything.

This field is required.

DB2 Subsystem Name

The name of the Db2 Subsystem which this stored procedure is running under. This field is required.

Maximum Number of Tests

This field indicates how many times the stored procedure will be intercepted by Code Debug TSO. If a stored procedure is called multiple times and this field is set to 1, only the first iteration will be trapped by Code Debug TSO. Subsequent calls will run outside of Code Debug TSO.

User Supplied WLM JCL

Enter either Y (Yes) or N (No). N indicates that Code Debug TSO will retrieve the Work Load Manager (WLM) JCL from Db2 to run the stored procedure. Y indicates that you will provide the WLM JCL to run the stored procedure. A subsequent panel will be displayed to enter the data set name of the JCL.

Cross-LPAR Submit

Enter either Y (Yes) or N (No). Y indicates that an Code Debug Stored Procedure Intercept will be initiated on each LPAR previously designated for Cross-LPAR Support by the product installer. When the client application invokes the Db2 stored procedure and it is intercepted on one of the designated LPARs, a STATUS message is displayed and the Intercept jobs on the other LPARs are terminated. N indicates that the Stored Procedure Intercept is to be run on the local LPAR only.

Jobcard Information

Enter the jobcard information to be used for the stored procedure test that is executed. If N was entered in the User Supplied WLM JCL field, the JOBCARD will be used for the retrieved stored procedure JCL when the test is submitted.

Accessing the Code Debug TSO Setup Menu Screen

If you type SEtup on the command line of the Process DB2 Stored Procedures screen and press Enter, the Code Debug TSO Setup Menu screen shown in following figure is displayed.

Code Debug TSO Setup Menu Screen

To access the screens containing Load Libraries, DDIO data set, etc., type an A (All) on the command line of the Code Debug TSO Setup Menu screen and press Enter.

Each of the successive screens (Test Script Libraries, Test Session Log Data set, DSNLOAD data sets, etc.) are accessible (in consecutive order) by continuing to press Enter.

Specifying the JCL

If you enter a Y in the User Supplied WLM JCL field of the Code Debug TSO Process DB2 Stored Procedures screen, will be displayed. From the Process Execute JCL screen (following figure), specify the name of the data set that contains the Work Load Manager (WLM) JCL specific to your stored procedure. Type this name in the Data set Name field and press Enter. This JCL must execute the WLM server.

Process Execute JCL Screen 

There are two steps you must perform on the Process Execute JCL screen:

1. Enter the name of the data set containing your execution JCL, either in the ISPF Library field or in the Other Partitioned or Sequential Data set field.
2. Use one of the following primary commands on the command line:

When JCL processing is completed, the job steps in the specified JCL are displayed on the Select Job Step screen shown in following figure.

Code Debug TSO Select Job Step Screen

The Select Job Step screen is used in two ways:

1. Use the I or U line command to specify how you want each job step to execute: in interactive or unattended mode. The JCL will be converted to run with Code Debug TSO in the specified execution mode. See JCL Conversion for information about JCL conversion.
2. Use the RUN or SUBMIT primary command to convert and submit the JCL, the EDIT command to view or edit the JCL, the SETUP command to access and change your job card information, the STATUS command to display the status of submitted jobs, or the END command to exit.

The Line commands are defined as follows:

I (Interactive) testing

Selects the step to run in interactive mode.

U (Unattended) testing

Selects the step to run in unattended mode.

IC (Interactive Code Coverage)

Selects the step to run in interactive mode (with Code Coverage active).

UC (Unattended Code Coverage)

Selects the step to run in unattended mode (with Code Coverage active).

IT (Interactive Test Data Optimization) testing

Selects the step to run in interactive mode (with Code Coverage and TDO active).

UT (Unattended Test Data Optimization) testing

Selects the step to run in unattended mode (with Code Coverage and TDO active).

IF (Interactive System Flow) testing

Selects the step to run in interactive mode (with System Flow active).

UF (Unattended System Flow) testing

Selects the step to run in unattended mode (with System Flow active).

ICF (Interactive Code Coverage/System Flow) testing

Selects the step to run in interactive mode (with Code Coverage and System Flow active).

UCF (Unattended Code Coverage/System Flow) testing

Selects the step to run in unattended mode (with Code Coverage and System Flow active).

ITF (Interactive Test Data Optimization/System Flow) testing

Selects the step to run in interactive mode (with Code Coverage, TDO, and System Flow active).

UTF (Unattended Test Data Optimization/System Flow) testing

Selects the step to run in unattended mode (with Code Coverage, TDO, and System Flow active).

blank (Reset I/U/C/T/F)

Blank the line command area and press Enter to remove any line command set on a job step.

The Primary commands are defined as follows:

Edit

Accesses the ISPF edit facility. The JCL is automatically converted and displayed on the ISPF edit screen. You can view and confirm the JCL conversion and make additional modifications to the converted JCL. However, the changes made to the converted JCL will not be saved when you select CANCEL or PF3 (END) from the edit screen. See Editing the JCL for more information and for an example of the ISPF edit screen.

END

Exits without converting the JCL, saving any modifications, or submitting the job, and returns you to the Process Execute JCL screen.

RUN

Converts the steps selected by the I and U line commands to predefined Code Debug TSO steps and submits the JCL. When the job processes successfully, you are automatically connected to the job steps selected to run in interactive mode and the Source screen is displayed.

If the job is a long-running job, the Connect Status screen is displayed showing the job status.

If the JCL is already converted, the RUN command (with a DSNAME) can be entered on any screen except an Code Debug test session screen. See the Command-and-syntax-reference for more information about the RUN command.

SEtup

Displays the Setup Menu from which you can select to view and change the job card and library information, such as the DDIO file (XPSL000n) and the SCRIPT file (XINCLUDE). See Specifying Setup Options for more information.

SUBmit

Converts the steps selected by the I and U commands to Code Debug TSO steps and submits the job. A job submitted with the SUBMIT command is not automatically connected. To connect to a job submitted with the SUBMIT command, you must use the CONNECT or STATUS command. See Connecting to a Job for more information regarding the CONNECT or STATUS command.

STatus

Displays the status of a job. You can connect to the job directly from the Status screen.

The fields displayed on the Select Job Step screen are defined as follows:

Data set

This field is pre-filled with the data set name of the JCL being processed.

PROGRAM

The name of the program to be tested. The PROGRAM name does not necessarily match the EXEC PGM name.

INITSCR

The member name of the script in the INCLUDE library specified on the Setup panel. The INITSCR field can be typed over to specify a test script member, which can then be processed at the beginning of a debugging session.

POSTSCR

The member name of the script in the INCLUDE library specified on the Setup panel. The POSTSCR field can be typed over to specify a test script member which can be processed at the end of a debugging session.

STEPNAME

The job step name.

PROCNAME

The in-stream or cataloged procedure name.

PROCSTEP

The step name within the called procedure.

EXEC PGM

The name of the EXEC program that is executed for the step. XPTSO if I (Interactive) was specified for the step. XPBATCH if U (Unattended) was selected for the step. The field is left blank if the name is the same as the one entered in the PROGRAM field.

Connecting to a job

When you use the RUN command to submit the job, the steps that are selected for interactive debugging are automatically displayed at your terminal.

When you use the SUBMIT command to submit the job, there are two ways to connect to a job: the CONNECT command and the STATUS command.

1. CONNECT Command: You can use the CONNECT command on any screen (except the source display) to connect a VTAM terminal to a job submitted through Code Debug TSO’s Batch Connect facility. You can connect to a job with multiple steps or to a single step job. For information on the CONNECT command syntax, see the Command-and-syntax-reference.
2. STATUS command: The STATUS command is used to display the Status screen containing a list of the active/inactive jobs in the system. The STATUS command can be entered from any screen.

The ATTACH line command on the Status screen is used to connect to a job and display the source of each job step for which the I (Interactive) command was specified. A message is displayed notifying you that the job step selected for testing is executing.

Editing the JCL

There are two points at which the Batch Connect facility lets you edit your JCL.

1. Primary editing is available by entering the EDIT primary command on the Process Execute JCL screen. An ISPF edit session is invoked and the specified JCL is displayed. If your site security permits, changes will be saved to the original JCL when the edit session ends.
2. Secondary editing is available by entering the EDIT primary command on the Select Job Step screen (following figure). An ISPF edit session is invoked and a temporary copy (45 lines) of JCL as shown in Sample Edit JCL Screen is displayed. JCL statements for those steps selected for testing, using the I (Interactive) or U (Unattended) line commands, are already converted when the edit screen is displayed.
   After any editing is completed, you can submit the job from the Code Debug TSO Select Job Step screen (following figure) with the RUN or SUBmit command.

Select Job Step Screen 

Sample Edit JCL Screen 

Debugging a client application and a Db2 stored procedure together

A specialized technique has been developed that allows for the debugging of a client application which calls a Db2 stored procedure, while using a single TSO userid. Detailed instructions are provided in Debugging a Client Application and Db2 Stored Procedure.

Db2 stored procedure security considerations

Be advised that there are a few security considerations concerning Code Debug TSO Stored Procedure support.

Batch Connect security check

Connection can be made to any job, including production jobs if you permit testing in production Db2 subsystems, as long as your site security grants the authority. The Batch Connect facility is shipped with a default security exit routine that allows connection to a job if the JOBNAME, without the last character, matches the TSO ID of the user attempting to connect to it. When a connection cannot be made, the messages CANNOT CONNECT or SECURITY CHECK FAILED are issued.

The site installer can customize the security exit routine to tailor the security level for certain groups or individuals. When an asterisk (*) is entered in the Jobname field on the Status screen, all jobs that are waiting for connection or being tested under Batch Connect are listed. System programmers are able to connect to a remote job and use the facility as a help desk feature in debugging application programs.

Db2 subsystems to debug

Before Code Debug TSO can be used to debug stored procedures, an Code Debug TSO Stored Procedure activation program must be run on the system (after every IPL). The Db2 subsystems Code Debug TSO will be allowed to intercept are specified to the activation program. See the Code Debug TSO and Code Debug IMS Installation and Configuration Space for details on the execution of the Db2 Stored Procedure activation program.

Optional Security Access Facility (SAF) calls

Optionally, Code Debug TSO will issue SAF (Security Access Facility) calls to your external security package (RACF, ACF2, Top Secret, etc.). This allows your installation to limit the number of individual users who are able to debug Db2 stored procedures being called from whichever client selected. See the Code Debug TSO and Code Debug IMS Installation and Configuration Space for details on how to add additional Db2 stored procedure security.

Security exit

If you have specific security issues not addressed by the aforementioned security procedures, you can optionally code an Code Debug TSO security exit. See the Code Debug TSO and Code Debug IMS Installation and Configuration Space for details on how to add additional Db2 stored procedure security via the ADSRAUSR exit.

Foreground debugging of Db2 stored procedures

In addition to debugging stored procedures in Batch Connect mode as described above, Code Debug enables Db2 stored procedures to be debugged within the TSO address space. This foreground debugging capability eliminates the requirement to install Code Debug TSO Batch Connect.

The following example illustrates how to perform foreground debugging of a stored procedure. For the purposes of this example, assume that an existing test profile is being used and debugging of Db2 stored procedures has been selected on the Environments Menu. Only the stored procedure can be debugged during this session. The driver or client that calls the stored procedure must be debugged in a separate foreground or batch debugging session.

1. From the Code Debug TSO Primary Menu, select option 2 (TSO) and press Enter. The DB2 Stored Procedure screen (2.12) shown in following figure will be displayed.
   DB2 Stored Procedure Screen (2.12) 

   PROFILE: DB2SP -----------------  DB2 Stored Procedure (2.12)  ----------------
   COMMAND ===>
   
   COMMANDS:  SEtup (Display Setup Menu)
             PROFile (Display Profile List)
   
              Schema Name  ===> XT
   
    Stored Procedure Name
                   or UDF  ===> TRISPTG
   
        Client End UserID
       or PC Account Code
            or IP Address  ===> MFHABC0
       DB2 Subsystem Name  ===> D909  (D901,D909)
   Maximum Number of Tests  ===> 1                 (1 - 9999)
   
           Initial Script  ===>
              Post Script  ===>
   
      File List/JCL Member ===>
            Preview Files? ===> NO
       Code Coverage Test? ===> NO   (YES, NO, TDO)  System Flow? ===> NO
               Press ENTER to process  or  enter END command to terminate

2. Fill in all required fields on the DB2 Stored Procedure screen, then press Enter to start the test. The Test screen shown in following figure will be displayed while waiting for the stored procedure to be intercepted.
   Test Screen During Stored Procedure Testing 

   Profile: STORE --------------------- TEST ----------------------Files Allocated
   COMMAND ===>
   
   
   
   
   
                ************************************************
                *                                              *
                *    Entering CODE DEBUG TSO Test Environment    *
                *                                              *
                ************************************************
                *          TYPE OF TEST: STORED PROCEDURES     *
                *               PROFILE: STORE                 *
                *      STORED PROCEDURE: XT.TRISTPG            *
                *         DB2 SUBSYSTEM: D610                  *
                *                USERID: MFHABC0               *
                ************************************************

   Important

   At this point, you may choose to exit the test. See Exiting an In-Progress Stored Procedure Testfor details.

3. Initiate the client that invokes the stored procedure specified in Step 2.

4. After intercepting the stored procedure, Code Debug will display the source as shown in following figure.
   Source Display for Stored Procedure Test 

   ----------------------------- CODE DEBUG TSO - SOURCE ---------------------------
   COMMAND ===>                                                     SCROLL===> CSR
   
                             BEFORE BREAKPOINT ENCOUNTERED
                                     ---
   000010   01 TST-REC              > 345
   000014   01 TYPE-OF-TRIANGLE     >  ??         INVALID DECIMAL
           ** END **
   
   ------   ----------------------------------------- Before TRISPTG:15/AMODE 31 <>
   ====>> B  PROCEDURE DIVISION   USING  TST-REC
   000016                                TYPE-OF-TRIANGLE.
   000017    VALIDATE-TRIANGLE.
   000018        ADD A B GIVING A-N-B
   000019        ADD A C GIVING A-N-C
   000020        ADD B C GIVING B-N-C
   000021        IF (B-N-C NOT > A) OR (A-N-C NOT > B) OR (A-N-B NOT > C)
   000022           MOVE 4 TO TYPE-OF-TRIANGLE.
   000023    DETERMINE-TYPE.
   000024        IF TYPE-OF-TRIANGLE = 4
   000025           NEXT SENTENCE
   000026        ELSE
   000027           IF (A = B) AND (B = C)
   000028              MOVE 1 TO TYPE-OF-TRIANGLE

   Important

   If you need to prematurely end the test, type EXIT on the command line and press Enter. This will cause a user abend so Db2 can clean up its resources.

5. Enter the GO command (at the GOBACK) for normal test completion. When the test has completed, the Code Debug session log will be displayed. At that point you must enter the GO command again to complete the Db2 stored procedure test.

Exiting an In-Progress Stored Procedure Test

While waiting for a stored procedure to be intercepted, you can press Attention to suspend the test. The message shown in following figure will be displayed, giving you the option of continuing or exiting the test. This gives you a way of escaping the test, if necessary, while the wait for a stored procedure intercept is in progress.

Stored Procedure Intercept In Progress Message

Responding to the message with EXIT forces Code Debug to clean up the current environment and terminate the test. A few error messages similar to those shown in following figure will be displayed as a result.

Error Messages from Stored Procedure Test Exit