Graphical debugging makes procedural SQL debugging on IBM i even easier

Transcription

1 Graphical debugging makes procedural SQL debugging on IBM i even easier Kent Milligan IBM Systems and Technology Group ISV Enablement February 2014 Copyright IBM Corporation, 2014

2 Table of contents Abstract...1 Introduction...1 Debugging procedural SQL with the IBM i graphical debugger...1 SQL *SOURCE debug view... 1 Graphical IBM i system debugger... 4 Components of the debug interface... 5 Debugger requirements for client and server... 7 Graphically debugging procedural SQL... 7 Debugging SQL and Java procedures with IBM Data Studio...11 Data Studio introduction and setup Setup for stored procedures Starting the debugger Using the debugger Debugging imported stored procedures Summary...24 Resources...25 About the author...26 Trademarks and special notices...27

3 Abstract This white paper describes how to use two graphical debugging solutions for IBM DB2 for i SQL procedures that run on the IBM i platform. These two tools are: the IBM i graphical debugger (part of the IBM Toolbox for Java) and IBM Data Studio (formerly known as IBM DB2 Developers Workbench and IBM DB2 Development Center). Introduction IBM DB2 for i first simplified the debugging of SQL procedures, functions, and triggers in the IBM OS/400 Version 5 Release 2 (V5R2) operating system with the introduction of the SQL *SOURCE Debug View. (Refer to the article entitled Graphical Debugger Makes Procedural SQL Debug Even Easier, published in the iprodeveloper March 2003 issue at: In conjunction with the IBM i System Debugger, which is packaged with the IBM Toolbox for Java, this debug view greatly simplified the debugging of SQL procedural objects. Starting with the DB2 for i V5R4 release, developers also have another option when they need to graphically debug SQL procedures. These new debug capabilities are provided by the IBM Data Studio product. IBM Data Studio is a visual tool that supports the entire DB2 family across all IBM platforms for the rapid development of DB2 business objects. IBM Data Studio only supports the debugging of SQL and Java stored procedures. Debugging procedural SQL with the IBM i graphical debugger This section explains how you can debug procedural SQL by using the IBM i graphical system debugger. SQL *SOURCE debug view SQL procedures were first introduced in OS/400 V4R2, and they always have invoked C code since their arrival. The usage of C code in the background is not an issue for RPG and COBOL programmers until there is a need to debug an SQL procedure, a function, or a trigger. Instead of showing the original SQL procedural statements, the IBM i debugger (STRDBG - Start Debug) shows the generated C code that is used to implement the original SQL procedural statements. 1

4 Example 1 shows the source of an SQL CREATE PROCEDURE statement. By default, this is not the code that a developer might see using the IBM i debugger. CREATE PROCEDURE kmtest.pp2() LANGUAGE SQL SET OPTION DBGVIEW=*LIST BEGIN DECLARE x INT; DECLARE y INT; SET x = 0; SET y = -9; SET y = ABSVAL( (x + 1) * y); END Example 1: Source of an SQL stored procedure Figure 1 shows the C-based debug view that programmers are presented by default when using either the traditional green-screen debugger or the graphical system debugger. Figure 1: The default C-based debug view for an SQL stored procedure 2

5 With the arrival of the *SOURCE debug view in OS/400 V5R2, programmers have a way to work with the original SQL source in debug mode instead of the complex C code that is generated by DB2 for i. You can create the SQL *SOURCE debug view in one of two ways: One method is to specify the *SOURCE debug option in the source of the SQL procedure, function, or trigger. This method is demonstrated by specifying DBGVIEW=*SOURCE in the SET OPTION clause (refer to Example 2). An alternative method is to specify a *SOURCE value for the DBGVIEW parameter on the RUNSQLSTM (Run SQL Statements) CL command. CREATE PROCEDURE myschema.ship_it(in ordnum INTEGER, IN ordtype CHAR(1), IN ordweight dec(3,2)) LANGUAGE SQL SET OPTION DBGVIEW =*SOURCE sp: BEGIN DECLARE ratecalc DECIMAL(5,2); /* Check for international order */ IF ordtype='i' THEN SET ratecalc = ordweight * 5.50; INSERT INTO wwshipments VALUES(ordnum,ordweight,ratecalc); ELSE SET ratecalc = ordweight * 1.75; INSERT INTO shipments values(ordnum,ordweight,ratecalc); END IF; END Example 2: Specifying DBGVIEW=*SOURCE on the SET OPTION clause With the *SOURCE debug view specified, DB2 creates an extra SQL source-level debug view as it generates the C program. If the procedure name on the CREATE PROCEDURE statement is qualified with a schema (or library) name, then the debug view is created in the same library as the C program object. In Example 2, both the debug view and C program for the procedure are created in the myschema library. If the procedure name is unqualified, the SQL source-level debug view is stored in the QTEMP library and only the job that created the SQL procedure, function, or trigger is able to use the *SOURCE debug view. There are several other nuances with the SQL source-level debug that you need to be aware of. One is that the comments are not saved in the *SOURCE debug view. Another is that, when stepping through the *SOURCE debug view in debug mode, the step might stay on the same SQL statement for several steps if that SQL statement required multiple lines of generated C code to implement. The final nuance is accessing the value of the SQL variables and parameters during the debug session. The EVAL command is still used, but the variable and parameter name must be prefixed with a label and be entered in capital letters. For parameters, the label name is the procedure name EVAL SHIP_IT.ORDNUM shows the value of the first input parameter of the procedure (refer to Figure 4). The variables use the label specified on the BEGIN statement; therefore, EVAL SP.RATECALC is the command to run in the debug session to display the variable value in Figure 4. If the variable contains a character string, then the variable name must contain an asterisk (*) as a prefix (for example, EVAL *PROC.CHARVAR). 3

6 Graphical IBM i system debugger The graphical system debugger, which is part of the IBM Toolbox for Java, lets you debug programs that run on the IBM i operating system. This state-of-the-art debugger includes an integrated call stack window, breakpoint groups, variable monitors and a local-variables display. In addition to the new capabilities, you can use the graphical debugger, without any training, to debug practically any scenario that you can debug using the green-screen interface (STRDBG). The graphical debugger supports the following IBM Integrated Language Environment (ILE) languages: ILE C and C++ ILE RPG ILE COBOL ILE CL Java Because SQL procedures, functions, and triggers are implemented by DB2 for i as generated ILE C code, the graphical debugger also supports them including support for the *SOURCE SQL debug view. Note: You can also use the Original Program Model (OPM), RPG, and COBOL programs with the graphical debugger if you specify *LSTDBG or *SRCDBG on the compilation and if you specify OPMSRC(*YES) when starting the debug session. The graphical debugger comprises four components: Client-based debug manager Client-based debug interface Host-based debug hub Host-based debug server Use the debug manager to register users with the debug hub for graphical debug on a particular system. It acts as a convenient start point for debug sessions. There is only one debug manager for a given client. The debug interface also runs on the client and provides the actual debug interface. This is the interface you use to set breakpoints, step through programs, inspect variables, and so on. There is one debug interface instance for every job that is being debugged on the IBM i system. The debug interface can debug programs that run in existing jobs on the system or use the system debugger to launch and then debug programs in a system batch job. You can set up the system debugger to start automatically or manually from a workstation command prompt, or even by using the debug-manager interface. As mentioned, the debug hub (QTESDBGHUB) is the server-side component that keeps track of the users who are currently registered for debugging; it also starts debug-server jobs on their behalf. Using the Start Debug (STRDBG) CL command from an emulation session notifies the debug hub to see if the user who is running the command is registered with the debug manager. The debug hub also verifies that the command that is being run is from the same TCP/IP address as the debug manager. If these conditions are met, the graphical system-debug application is started instead of the traditional debug environment. The debug server is a TCP/IP server job that the debug hub starts when a request to debug is issued. The server job then services the job that is being debugged and issues appropriate debugger APIs and commands. If the user is registered through graphical debug by the debug manager and enters the 4

7 STRDBG command, the debug server runs in the same job where STRDBG was issued. Otherwise, the debug server runs its own job and then uses the STRSRVJOB command to service another job to be debugged. Components of the debug interface Figure 2 shows the debug interface window with a series of tabbed areas. Each tab provides a different view of the overall debug environment. The debug interface is a multiple document window; therefore, you can view more than one source file at the same time. Most compilers are capable of presenting several views of the source code. You can use each debug view (for example, compiler listing or statement listing) during the debug session. The Programs tab lists the current program or Java class files that are currently under debugging. You can save the program objects and breakpoint information to an environment file. To eliminate repetitive setup of breakpoints for a program, you can load the saved environment file into a future debug session. The Breakpoints tab enables the manipulation and listing of all program breakpoints. You can specify conditions and thread-specific information when defining a breakpoint. In addition, you can group breakpoints together logically, and you can assign a name and color to these groups. You can disable or re-enable the breakpoints in a group with a single click. The Monitors tab keeps track of the variables or expressions that are not found in the local program scope. You can establish a monitor by highlighting a variable or expression in a source-code window. The value of each monitor is updated at each breakpoint or debug step. Figure 2: The debug interface window has a series of tabbed areas 5

8 The Locals tab (refer to Figure 3) displays the local variables that are associated with the program that you are currently debugging. The children of the structured variables are organized in a tree hierarchy. For SQL procedures, functions, and triggers, the SQL variables and parameters are organized under each label. As with monitored variables, you can edit locals directly from this panel. Figure 3: The Locals tab displays the local variables associated with the program currently being debugged The Console tab (refer to Figure 4) allows users to directly enter the same debug commands (for example, EVAL) that they use on the green-screen debugger interface. The graphical debugger supports all of the green-screen debug commands. Figure 4: The Console tab allows users to enter the same debug commands used on the green-screen debugger interface 6

9 The Call Stack tab displays the call stack that is associated with the program in debug mode. You can visit any call level in the call stack by clicking on the tab or a pull-down menu. The Thread tab displays all active threads in the program. If the code that the thread is running is in debug mode, the program information, including line numbers, are displayed. You can access any source code that is running in a thread by clicking on the tab or a pull-down menu. Debugger requirements for client and server To run the graphical system debugger, the client system must meet the following hardware and software requirements. Hardware: Processor: 400 to 500 MHz Memory: 128 MB (minimum) to 256 MB (recommended) Software: IBM Toolbox for Java (V5R4 or later) - The easiest way to install the IBM Toolbox for Java is to install the IBM System i Navigator product (V5R4 or later) on your PC. (This product was formerly named IBM iseries Navigator). You can find more information about installing System i Navigator at: j2enableopsnav.htm - The graphical debugger class files contained in the IBM Toolbox for Java can be manually installed with the instructions provided at the following URL: j2enableopsnav.htm One of the following environments: - Java 2 Platform (Standard Edition [J2SE] or Enterprise Edition [J2EE] V1.4 or later) - Java 2 Runtime Environment (JRE), Standard Edition V1.4 or later jhall.jar (one of the JAR files in JavaHelp) Note: You can download the software from the Sun Microsystems Java website at: java.sun.com/downloads/index.html On the IBM i system, you must start the host debug server by issuing the following system command: STRTCPSVR *DBG Graphically debugging procedural SQL Here are the basic steps to get the graphical debugger up and running for an SQL stored procedure. These steps assume usage of the System i Navigator client (IBM i V5R4 or later). The graphical debugger can be started manually from a client, but the usage of System i Navigator greatly simplifies the process. 1. Create the SQL procedure with the *SOURCE debug view. In this case, the source code for the SQL procedure in Example 2 has been created in an System i Navigator Run SQL Script session. The Set Option clause is used in the procedure to cause the SQL source-level debug view to be built during the creation of the stored procedure. 7

10 You can also store the procedure source code in a source physical-file member. The member can be used by the RUNSQLSTM command to create the SQL procedure with the source-level debug view. Here is a sample RUNSQLSTM command: RUNSQLSTM SRCFILE(MYLIB/MYSRC) SRCMBR(SPTEST) COMMIT(*NONE) NAMING(*SQL) 2. After the SQL procedure has been created, an System i Navigator Run SQL Script session needs to be active to start the debug mode. You can initiate a debug session by clicking Run Debugger, as shown in Figure 5. Figure 5: Starting a debug session 8

11 3. The Debugger task causes the Start Debug dialog box to open on the client (refer to Figure 6). Figure 6: The Start Debug dialog window opens on the client System i Navigator automatically fills in the job information for the server job that is used by the Run SQL Script session for running and debugging the stored procedure. In prior releases, the user had to enter the job information. Fill in the library and the program name of the procedure. In this example, the library name is myschema and the procedure name is ship_it. When the procedure name is 10 characters or lesser, the program and the procedure name are the same. If the procedure name is longer than 10 characters (for example, testprocedure), you need to look up the program name that is 9

12 associated with the stored procedure. You can use the SPECIFIC clause to control the program name for a stored procedure with a long name. Refer to the article, DB2 UDB for iseries Long and Short Idenitifiers, at the IBM developerworks website (ibm.com/developerworks/db2/library/techarticle/milligan/0108milligan.html) for more details on using the SPECIFIC clause. 4. Click OK to start the IBM i graphical debugger on the client and load the SQL source-level debug view for the SHIP_IT stored procedure (refer back to Figure 2). 5. Set a breakpoint with a single left-click on Line 5 (IF ORDTYPE= I ). An enabled breakpoint is indicated by the arrow demonstrated in Figure 3. Now that you have set a breakpoint, click the Resume arrow on the tool bar. 6. Return to your System i Navigator Run SQL Script session and issue the following SQL CALL statement: CALL MYSCHEMA.SHIP_IT(33, I, 5.1) The debug client then takes control at the breakpoint specified in the previous step. Figure 3 shows how the highlighting is used to indicate where execution stopped for the breakpoint. 7. To view the contents of the ORDTYPE input parameter to determine which leg of the IF statement will run, click in the lower-left corner of the Console tab and enter the following EVAL command in the Command window: EVAL *SHIP_IT.ORDTYPE The contents of this variable are then displayed in the Console window as demonstrated in Figure 4. You can display all of the procedure parameter values by entering the following EVAL command in the Console window: EVAL SHIP_IT When using the graphical debugger over the normal debug views, variable values are automatically displayed by moving the cursor over a variable name in a line of code. This flyover display of variables is not available with the *SOURCE debug view for SQL procedures, functions, and triggers. 8. To view the calculated shipping rate before the stored procedure ends, right-click line 11 and select Run to Cursor. This allows the debugger to run all of the code up to line 11. When line 11 is reached, you can issue the following command in the Console window to display the computed shipping rate: EVAL SP:RATECALC 9. To complete running the SHIP_IT stored procedure, click the Resume arrow on the toolbar. If this SQL routine contained a character string variable (for example, DECLARE z CHAR(5)), the following EVAL command can be used to display the contents of the variable: EVAL *SP.Z :S 5 For more information on the graphical IBM i System Debugger, open the debugger tool help by pressing F1. The IBM i Information Center also contains information on the debugger just search the website ( for graphical debugger. The IBM i Information Center uses System i5 debugger as the official name of the graphical debugger. 10

13 Debugging SQL and Java procedures with IBM Data Studio This section describes how to debug SQL and Java procedures by using the IBM Data Studio tool. Debugging of SQL and Java procedures requires Data Studio V3.1.1 or later. At the time of publishing this paper, the Data Studio debugger does not yet support the debug of DB2 for i SQL user-defined functions. IBM plans to add this support in a future release. The following website has a listing of the Data Studio features that are supported with DB2 for i databases. ibm.com/support/docview.wss?uid=swg Data Studio introduction and setup As mentioned earlier, the IBM Data Studio is a graphical development tool that is based on the Eclipse technology and supports the creation of DB2 business objects across the IBM DB2 family. Data Studio supports a wide variety of features for the application developer, from browsing and editing data in tables to visually building SQL statements. This section focuses on using the debug functions for SQL procedures. You can find information about the general usage of the Data Studio tool in the white paper entitled IBM DB2 for i and Data Studio, found at: ibm.com/partnerworld/wps/servlet/contenthandler/whitepaper/i5os/db2_workbench/support IBM i developers can download Data Studio from the following website: ibm.com/developerworks/downloads/im/data/ Setting up the connection properly is the key setup step for using the debug capabilities of Data Studio: 1. When you first start Data Studio, you need to establish a new database connection for your development project. This connection configuration is done with the dialog box shown in Figure 7. 11

14 Figure 7: Dialog box for setting up a connection Identify the type of DB2 server where your procedure will reside. In this example, the blue highlight bar (shown on the left side of the screen capture) indicates the selection of DB2 for i. 2. Select the JDBC driver (shown on the right side of the screen capture). This is an important step because the default driver, AS/400 Toolbox for Java, does not work if your goal is to use the Data Studio debugger. The Data Studio product and Toolbox JDBC driver work together well for editing and creating DB2 for i SQL objects, such as stored procedures, but not for stored procedure debugging. Instead, you must use the IBM Data Server Driver for JDBC and SQL (also known as the DB2 JCC or DB2 Universal JDBC driver) when debugging stored procedures. The IBM Data Server Driver for JDBC is also a Type-4 JDBC driver (as is the Toolbox JDBC driver). In contrast, the Data Server Driver for JDBC driver is not included with the IBM i operating systems, but it is included with the Data Studio download along with a DB2 Connect license that enables access of DB2 for i servers from Data Studio. 12

15 3. Identify the DB2 for i database server. You need to set the database entry field with the local database name on your server. You can obtain this database name by running the IBM i Display Database Relational Database Entries (DSPDBRDIRE) command and using the name of the *LOCAL entry. The host is the TCP/IP host name of the IBM i server that is being accessed. In this example, the local database and TCP/IP host names are the same. Setup for stored procedures The first section of this white paper discusses how the SQL *SOURCE debug view is a key enabler for the IBM i graphical debugger. With the Data Studio, graphical SQL source-level debugging is performed without the *SOURCE debug view. In fact, you cannot use the Data Studio debugger on any SQL procedural object that is created with this debug view. As with the IBM i debugger, the Data Studio graphical debugger also requires that you create the stored procedure with special attributes to make the procedure eligible to debug. You add these attributes to the procedure with the ALLOW DEBUG MODE clause or the CURRENT DEBUG MODE special register. 13

16 Example 3 shows the same SQL procedure used for the debug example in the first half of this white paper. However, notice that the ALLOW DEBUG MODE clause now replaces the DBGVIEW clause. A syntax error is returned when the ALLOW DEBUG MODE clause is specified in conjunction with the DBGVIEW option. Thus, Java and SQL procedures that need to be debugged with Data Studio must be created with the ALLOW DEBUG MODE clause, without any DBGVIEW option, as shown in Example 3. CREATE PROCEDURE myschema.ship_it(in ordnum INTEGER, IN ordtype CHAR(1), IN ordweight dec(3,2)) LANGUAGE SQL ALLOW DEBUG MODE sp: BEGIN DECLARE ratecalc DECIMAL(5,2); /* Check for international order */ IF ordtype='i' THEN SET ratecalc = ordweight * 5.50; INSERT INTO wwshipments VALUES(ordnum,ordweight,ratecalc); ELSE SET ratecalc = ordweight * 1.75; INSERT INTO shipments values(ordnum,ordweight,ratecalc); END IF; END Example 3: Creating the procedure with the ALLOW DEBUG MODE clause (and without the DBQVIEW option) The CURRENT DEBUG MODE special register provides a different alternative if you do not want to include debug clauses in your Create Procedure statements. With this approach, you can drop the ALLOW DEBUG MODE clause from the Create Procedure statement if the special register is set to the ALLOW value before creating the procedure. Here is an example of setting the debug mode special register: SET CURRENT DEBUG MODE=ALLOW Setting the special register to ALLOW means that any SQL or Java stored procedure created after this assignment is eligible to be debugged by the Data Studio graphical debugger. When using the Data Studio to create a procedure, you can also enable the debug mode by selecting the Enable debugging check box on the Deploy Routines interface, as shown in Figure 8. 14

17 Figure 8: Enabling debug mode Selecting this check box causes Data Studio to set the debug mode special register to the value of ALLOW before creating the stored procedure on the selected server. This ensures that a debug view of the stored procedure will exist on the server even if the ALLOW DEBUG MODE clause is missing from the stored procedure source code. As shown in Figure 9, the SHIP_IT stored procedure source does include the debug clause. The SHIP_IT procedure source code is displayed in the IBM SQL and Routine Development perspective, which you can use to edit, create, and run the SQL procedure. 15

18 Figure 9: Data Studio SQL and Routine Development perspective Starting the debugger Now that the stored procedure has been created within Data Studio, it is time to start the debug process. The easiest way to start the debugger is by going to the Data Project Explorer pane in the upper-left corner; right-clicking the debug task, and clicking Debug on the stored procedure object within your project. Figure 10 shows this debug launch technique. 16

19 Figure 10: An easy way to launch the debug process 17

20 After the debug task is started for a stored procedure, the dialog box (as shown in Figure 11) is opened so that you can specify the debug settings for this routine invocation. The primary settings that can be changed on this interface are the values of the input parameters that will be passed on the call of the stored procedure. The Run and Performance Options tab only has a setting that enables the changes made to the database to be automatically committed after the invoked routine completes. Figure 11: Debug routine settings interface If you want to change the input parameter values, click in the Value column for the parameter. From this interface, you can retrieve values from a file that you want to test, so that you do not have to manually type in these values each time that you need to run and debug a specific test. With the configuration now in place, the debugger is started by clicking Debug. After clicking Debug, Data Studio automatically switches into the Debug perspective that is shown in Figure

21 Figure 12: Debug perspective Using the debugger The first line of the stored procedure is highlighted (refer to Figure 12) when the Data Studio debugger has control of the stored procedure execution. The first time you run the Data Studio debugger on your system, it might take some time for the debugger to gain control, because a job (QSQDBGMGR) has to be started on the IBM i system to support Data Studio debug sessions. After the Data Studio debugger has control, you can step through the procedure and set breakpoints. You can set and clear breakpoints by double-clicking in the left margin. After you have set a breakpoint, a small dot is displayed in the left margin. The breakpoint indicator in Figure 12 is circled for your reference. The top line in the Debug view (circled in the Debug tab in Figure 12) is where you can control the execution of the stored procedure. Clicking the green arrow with the yellow bar causes the stored procedure to resume execution after a breakpoint has been reached. The yellow arrows provide various step executions (for example, Step Into and Step Over). The Variables view in the upper-right corner (circled in the Variables tab in Figure 12) is where you can access the value of the procedures variables. Because Figure 12 displays the initial debug view before the stored procedure starts running, the Variables view contains only two variables, SQLCODE and SQLSTATE, initialized to zeroes by DB2. As execution of the stored procedure progresses, the Data Studio debugger automatically adds variables to this view. This dynamic nature of the Variables view, which is demonstrated in Figure 13, displays the Debug view after a breakpoint has been reached on the SET statement. Now that a couple of lines of the stored 19

22 procedure have run, you can see that the Variables view shows several more variables including the values of the input parameters of the SQL procedure (ORDNUM, ORDWEIGHT, and ORDNUM). You can also use the Variables view to set watches on variables or even change their values you can access both of these functions by right-clicking the variable name. Monitoring and accessing the variables and parameters within a stored procedure is much easier with the Data Studio debugger, as compared to the IBM i graphical debugger. Figure 13 also shows how the Data Studio debugger highlights the next line of code to be run. You can also deduce that a breakpoint has been reached from the left margin where an arrow points to the small circle that represents a defined breakpoint. Figure 13: The Debug view after reaching a breakpoint on the SET statement Debugging imported stored procedures Until now, the focus of the white paper has been on the use of the debugger with a stored procedure that has been created with the Data Studio toolset. However, it is possible that the stored procedures are created from a different interface. For example, the source for all of the stored procedures might reside in the source physical file members on your IBM i system, and the procedures are created with the Run SQL Statements (RUNSQLSTM) system command. You can use the Data Studio graphical debugger to debug stored procedures that have been created from other interfaces and tools assuming that they were all created with the ALLOW DEBUG MODE clause or with the Debug Mode special register enabled. 20

23 21

24 Figure 14 highlights the import process. You can initiate the import process from the Database Explorer view at the lower-left corner of the Data Studio Data perspective: 1. Select the database connection for the server (that is, CTCV7R1) where the stored procedure resides. 2. Select the schema (or library) where the stored procedure is created. The schema in this example is KMILL. With the schema now identified, the procedure can be selected from the Stored Procedures folder view under the schema. 3. The easiest way to import the selected stored procedure into Data Studio is to drag the procedure (follow the arrow) to the Stored Procedures folder that is in the Data Project Explorer view. Figure 14: The import process 22

25 After the procedure has been imported into the projects view, you can use the Data Studio on the imported stored procedure just as you do for any stored procedure created with Data Studio. You can double-click the stored procedure to open the Edit view of the source or right-click the procedure and start the Data Studio debugger. 4. Figure 15 shows the Edit view for an imported stored procedure. Figure 15 also shows one nuance that Data Studio has with both the Edit and Debug views for imported stored procedures. Notice that the ALLOW DEBUG MODE clause is missing from the source of the imported TPROC1 stored procedure. In this case, TPROC1 was created on the IBM i server with the ALLOW DEBUG MODE in the original source, but Data Studio does not have the ability to include that clause for imported stored procedures. Generally, when using Data Studio for imported procedures, it will display only those Create Procedure language clauses (that is, ALLOW DEBUG MODE) that are supported by all of the IBM DB2 products. The COMMIT ON RETURN YES clause is another example of a clause that you can include when creating the procedure on DB2 for i, but it is not visible when you import the procedure into Data Studio. 23

26 Figure 15: The Edit view for an imported stored procedure Summary This white paper has provided an introduction to the capabilities of the IBM i graphical debugger and the IBM Data Studio debugger. This can help developers in understanding the capabilities of each debugger and how to begin using them. The problem-determination process for stored procedures is greatly simplified with either of these debuggers. 24

27 Resources The following websites provide useful references to supplement the information contained in this paper: IBM i Information Center IBM i graphical debugger documentation n.htm Debug IBM i programs graphically ibm.com/developerworks/ibmi/library/i-debug/index.html IBM i on IBM PartnerWorld ibm.com/partnerworld/i IBM Redbooks ibm.com/redbooks Article: DB2 UDB for iseries Long and Short Identifiers ibm.com/developerworks/db2/library/techarticle/milligan/0108milligan.html IBM Data Studio ibm.com/software/products/us/en/data-studio/ IBM Data Studio download ibm.com/developerworks/downloads/im/data/ IBM developerworks forums: - Data Studio: ibm.com/developerworks/community/forums/html/forum?id= IBM i: ibm.com/developerworks/community/forums/html/forum?id= DB2 for i: ibm.com/developerworks/community/forums/html/forum?id= White paper: IBM DB2 for i and Data Studio ibm.com/partnerworld/wps/servlet/contenthandler/whitepaper/i5os/db2_workbench/support The Sun Microsystems Java website java.sun.com/downloads/index.html 25

28 About the author Kent Milligan is a DB2 technology specialist in IBM ISV Solutions and Strategy Enablement. Kent spent many years of his IBM career as a member of the DB2 development group in Rochester, Minnesota. He speaks and writes regularly on various IBM i relational database topics. 26

29 Trademarks and special notices Copyright IBM Corporation References in this document to IBM products or services do not imply that IBM intends to make them available in every country. IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other company, product, or service names may be trademarks or service marks of others. Information is provided "AS IS" without warranty of any kind. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Information concerning non-ibm products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-ibm list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-ibm products. Questions on the capability of non-ibm products should be addressed to the supplier of those products. All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction. Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be 27

30 given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here. Photographs shown are of engineering prototypes. Changes may be incorporated in production models. Any references in this information to non-ibm websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk. 28