Debugging stored procedures on DB2 z/OS with Data Studio

Debugging stored procedures on DB2 z/OS withData Studio Developer, Part 2: Configure thestored procedure debug session manager on z/OSSkill Level: Intermediate

Emily Zhang ([email protected])Advisory Software EngineerIBM

Tom Miller ([email protected])Senior Software EngineerIBM

19 Mar 2009

Learn step-by-step how to configure the Unified Debugger session manager for useon a z/OS® system, and learn how to use routines to manage the session manager.Proper setup of the session manager on z/OS can facilitate using IBM Data StudioDeveloper to debug stored procedures on DB2® for z/OS servers.

Introduction

This article follows the previous article on using the stored procedure debugger fromData Studio Developer. That article, for simplicity, focused on a configuration inwhich the Unified Debugger session manager was configured on the client or onanother server in the network. This article describes how to set up and operate theUnified Debugger session manager on the z/OS server, which can improvedebugging performance.

The following section provides a quick introduction to the session manager, and itoffers a quick review of debugging.

Learning about the Unified Debugger session manager

Configure the stored procedure debug session manager on z/OS© Copyright IBM Corporation 2009. All rights reserved. Page 1 of 27

mailto:[email protected]

mailto:[email protected]

http://www.ibm.com/developerworks/data/library/techarticle/dm-0811zhang/

http://www.ibm.com/legal/copytrade.shtml

IBM Data Studio Developer incorporates a Unified Debugger client. The Data StudioDeveloper supports debug of language SQL and language Java™ storedprocedures. When you debug a stored procedure within Data Studio Developer, youuse a technology called the Unified Debugger. The Unified Debugger has threecomponents, as shown in Figure 1: the debug server, the debug client, and thesession manager.

Figure 1. Unified Debugger framework

In this framework, the debug client talks to the session manager, and the debugserver talks to the session manager. The session manager is in the middle,facilitating communication between the separated client and server components tomanage the overall debug session. For more information about the UnifiedDebugger, see the previous article.

The session manager is an important component central to the Unified Debuggerframework. The session manager is a process that must be running somewhere inthe network (at the client, at the connected DB2 server, or somewhere else in thenetwork) before you can debug stored procedures with Data Studio Developer.When the session manager is running, it behaves like a network daemon,coordinating communication between a debug client and a DB2 server using TCP/IPconnections. You have the flexibility to run it anywhere on the network. If you do nothave the session manager set up correctly on z/OS, your debug experience with

developerWorks® ibm.com/developerWorks

Configure the stored procedure debug session manager on z/OSPage 2 of 27 © Copyright IBM Corporation 2009. All rights reserved.



Data Studio Developer can be impacted, requiring additional manual intervention.

Understanding session manager capability and availability onDB2 z/OS

The Unified Debugger is fundamentally a DB2 V9-based technology. Therefore, DB2V9 servers can use the full range of the Unified Debugger capabilities, features, andcomponents. The session manager is an independent Unified Debugger component,and it is distributed with the various new client and DB2 server products releasedsince 2006. While the earlier DB2 V8 releases can use a subset of the UnifiedDebugger server component (known formerly in V8 as the SQL Debugger), DB2 V8does not include the session manager, nor does it include the capability to launchthe session manager.

Table 1 shows a summary of the Unified Debugger features and session manageravailability on the different DB2 levels.

Table 1. Comparing features for different DB2 for z/OS versionsDB2 V9 for z/OS DB2 z/OS v8 (with PTF

UK25860 applied)

The Unified Debugger can debugboth LANGUAGE SQL andLANGUAGE JAVA storedprocedures.

The Unified Debugger can debugLANGUAGE SQL storedprocedures.

The Unified Debugger sessionmanager program (db2dbgm.jar)is distributed along with the DB2base feature.

No session manager program isdistributed on the platform. Thesession manager program can becopied to this platform from thedebug client distribution and runmanually.

TheDBG_RUNSESSIONMANAGERsupport routine is provided(requires started task setup of theDB2UDSMD daemon).

No support is available for debugclients to launch the sessionmanager at the connected server.

This is similar to DB2 for Linux,UNIX, and Windows® V9 andDB2 for i V5R4.

This is similar to DB2 for Linux,UNIX, and Windows V8 FP15.

Debugging with Data Studio Developer

The previous article went into detail about debugging stored procedures. Here is abrief review before delving into how to set up the session manager.

ibm.com/developerWorks developerWorks®



To debug stored procedures, the SQL or Java stored procedure must meet thefollowing conditions:

• It must be visible in the Data Project Explorer. You can create a newstored procedure in the Data Development project, or you can copy ordrag a stored procedure from the Data Source Explorer (formerly knownas the Database Explorer) to the Data Project Explorer.

• It must be enabled for debugging.

To determine if the stored procedure is enabled for debugging, right-click on thestored procedure. The debug menu is available as an option, as shown in Figure 2.

Figure 2. Procedure with debug enabled

If your server connection supports the Unified Debugger, but the Debug menu optionis grayed out, you must deploy the stored procedure with the debug option.Right-click the stored procedure, and select Deploy. When launching the DeployRoutines wizard, you need to check the Enable debugging check box on theRoutine Options page as shown in Figure 3.




Figure 3. Deploy Routines wizard

When you have this checkbox checked, a successful deployment causes the debugmode setting to be reflected in the DB2 catalog.

After you deploy for debugging, configure the DB2 Stored Procedure Debuggerpreferences to set up debugger-related preferences, including the location of thesession manager to use for debug sessions. To show the preferences page, selectWindow > Preferences from the top menu bar, then expand Run/Debug and selectDB2 Stored Procedure Debugger.

One important pointIf you plan to debug LANGUAGE JAVA stored procedures on a DB2V9 server, you should use the same session manager for all thedebug clients that will be debugging LANGUAGE JAVA storedprocedures on that DB2 server. The default session managerlocation at the connected server is recommended in this case.

If you select the checkbox for Run the session manager on each connected




server, Data Studio Developer looks for a session manager running at theconnected server, and if one is not found, it requests a session manager to be run atthat location (DB2 V9 for z/OS only). Alternatively, you can manually run a sessionmanager somewhere and identify that location under the Use already runningsession manager section.

Figure 4. Debugger preference page

As you can see, there are different ways to arrange a session manager to use fordebugging. This article helps you further exploit these options on the z/OS platform.




Setting up the session manager as a daemon on a z/OS server

To seamlessly use the session manager with Data Studio Developer at a connectedDB2 z/OS V9 server, you must define a daemon named DB2UDSMD to the z/OSsystem. On z/OS, a daemon is represented by a started task, which is a special typeof task that can be launched by the z/OS system command START. The definition ofthe started task DB2UDSMD is like that of other familiar system daemons, such asFTPD and TELNETD. The started task has its own JCL to run the session managerJava program (db2dbgm.jar). The started task is also associated to a specialsecurity system definition that ties the JCL to a designated user ID.

Following are the steps to set up the started task.

Step 1: Define the started task JCL to RACF

Define the started task DB2UDSMD to the security system on z/OS using JCL. Youwill need to specify a user ID to be associated with the started task. In addition,because the started task will be running a Java program from OMVS, you mustdefine an OMVS segment definition for that user, including UID and home directory.Finally, you need to activate the started task definition in current memory. Listing 1shows an example.

Listing 1. Defining the started task to RACF

//UDBG1 JOB ('RACF'),CLASS=A,MSGCLASS=A,MSGLEVEL=1,// USER=********, PASSWORD=*******//*--------------------------------------------------------------------//* Define the Unified Debugger Session Manager Started Task toRACF.//* A security manager ID must be used to perform thedefinitions.//*//* The STARTED task is defined by a RACF profile namedDB2UDSMD.**//* USRT005 will be the ID associated with this Started Task.//* Since the task will run a java program from OMVS, alsoassign an//* OMVS segment definition to the user (UID, home dir, etc.)//* Finally, activate the STARTED task definition in currentmemory.//*--------------------------------------------------------------------//RACFDEF EXEC TSOBATCH//SYSTSIN DD *ALTUSER USRT005 OMVS( UID(5) HOME('/u/usrt005')

PROGRAM('/bin/sh') )RDEFINE STARTED DB2UDSMD.** STDATA(USER(USRT005))SETROPTS RACLIST(STARTED) REFRESH

END

Step 2: Create the environment settings




Next, create a file in the HFS to hold the environment settings that are used whenthe Unified Debugger session manager runs as a started task on z/OS. Name thefile something recognizable, such as DB2UDSMDenvironment.

Place the file DB2UDSMDenvironment in the home directory of the ID you selectedfor the started task in Step 1. At a minimum, this file must specify the values forENV, PATH, and CLASSPATH. The default location for the session manager jar filein the HFS that is distributed with DB2 for z/OS V9 is/usr/lpp/db2910_base/classes/db2dbgm.jar.

In Listing 2 shows the full content of a sample file DB2UDSMDenvironment saved inUSRT005’s home directory. You can use this file as a template to write your ownjob.

Listing 2. Sample environment file settings for session manager

//UDBG2 JOB 'USER=$$USER','<USERNAME:JOBNAME>',CLASS=A,// MSGCLASS=A,MSGLEVEL=(1,1), REGION=4096K,// USER=USRT005,PASSWORD=*******//*--------------------------------------------------------------------//* Create a file in the HFS to hold the Environment settingsused when//* the Unified Debugger Session Manager runs as a Started Taskon z/OS//*//* USRT005 is the ID associated with the Started Task.//* Place the file in that users home directory.//* Name the file DB2UDSMDenvironment//*--------------------------------------------------------------------//*--------------------------------------------------------------------//* Create a file in the HFS from inline data using COPY//*--------------------------------------------------------------------//OCOPY EXEC PGM=IKJEFT01,DYNAMNBR=30//SYSTSPRT DD SYSOUT=*//HFSOUT DD PATH='/u/usrt005/DB2UDSMDenvironment',// PATHOPTS=(OWRONLY,OCREAT,OAPPEND,OTRUNC),// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIROTH)//INLINE DD *#----------------------------------------------------------------------# Environment settings for running the Unified Debugger SessionManager# * _BPX_BATCH_SPAWN=NO# * _BPX_SHAREAS=YES# Arrange for the JVM to run in the same address space.This avoids# launching 2 additional address spaces for the StartedTask.# * ENV=# Reference this file. Insulates from PATH and CLASSPATHchanges# present in etc/profile.# * PATH=# The location of the desired JAVA release, and systembinaries.# * CLASSPATH=# The location of the UDBG Session Manager jar file# * JAVA_COMPILER=NONE# Disable the JIT. The Started Task runs the SessionManager only# one time, so disabling this saves space that will not be




used.#----------------------------------------------------------------------_BPX_BATCH_SPAWN=NO_BPX_SHAREAS=YESENV=/u/usrt005/DB2UDSMDenvironmentPATH=/usr/lpp/java150/J5.0/bin:/binCLASSPATH=/usr/lpp/db2/db2910_base/classes/db2dbgm.jarJAVA_COMPILER=NONE//SYSTSIN DD *OCOPY INDD(INLINE) OUTDD(HFSOUT) TEXT//

Step 3: Create the started task JCL

Create the started task JCL for the Unified Debugger session manager, and place itin the system proclib. This JCL must be named DB2UDSMD. This JCL runs theUnified Debugger session manager on z/OS in response to a START command. Inthe example, USRT005 is the ID associated with this started task, as defined in theRACF started class profile DB2UDSMD.**. Listing 3 shows an example of thestarted task JCL.

Listing 3. Sample job to create the started task JCL

//UDBG3 JOB 'USER=$$USER','<USERNAME:JOBNAME>',CLASS=A,// MSGCLASS=A,MSGLEVEL=(1,1), REGION=4096K,// USER=********,PASSWORD=*******//*--------------------------------------------------------------------//* Create the Started Task JCL for DB2UDSMD. A START commandwill then//* be able to launch the Unified Debugger Session Manager onz/OS.//* USRT005 is the ID associated with the Started Task, asdefined in//* the RACF STARTED class profile DB2UDSMD.**//*--------------------------------------------------------------------//*--------------------------------------------------------------------//* Use IEBUPDTE to write a JCL member into SYS1.PROCLIB//*--------------------------------------------------------------------//WRITEJCL EXEC PGM=IEBUPDTE,PARM=NEW//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSUT2 DD DISP=SHR,DSN=SYS1.PROCLIB//SYSIN DD DATA./ ADD NAME=DB2UDSMD//DB2UDSMD PROC PORT=4553,TIMEOUT=60//*//* DB2 Unified Debugger Session Manager DAEMON FOROPENEDITION//*//* This JCL assumes no .profile exists for the user.//*//* Environment settings (PATH, CLASSPATH) come from STDENVfile.//*//DB2UDSMD EXEC PGM=BPXBATCH,DYNAMNBR=128,REGION=0M,TIME=1440,// PARM='SH date;java com.ibm.db2.psmd.mgr.Daemon-timeout// &TIMEOUT -port &PORT -log /dev/null;date'//STDOUT DD PATH='/tmp/DB2UDSMD.stdout',// PATHOPTS=(OWRONLY,OCREAT,OAPPEND,OTRUNC),




// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIROTH)//STDERR DD PATH='/tmp/DB2UDSMD.stdout',// PATHOPTS=(OWRONLY,OCREAT,OAPPEND,OTRUNC),// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIROTH)//STDENV DD PATH='/u/usrt005/DB2UDSMDenvironment',// PATHOPTS=ORDONLY// PATHOPTS=ORDONLY./ ENDUP/*

You can use the code in Listing 3 to create your file by following these steps:

1. Replace the STDOUT, STDERR, and STDENV paths. Note that STDENVrefers to the HFS file created in Step 2.

2. Ensure the ID assigned to the started task in Step 1 has the properprivileges to read and write the files for STDOUT and STDERR.

3. Change the default values for PORT and TIMEOUT.

Step 4: Test

You can test the completion of Steps 1-3 by issuing this START command at thez/OS console: START DB2UDSMD,TIMEOUT=1 Wait a couple of minutes to allowsufficient time for the started task to launch, the session manager program toinitialize, and a minute of inactivity before it shuts down. After the started taskDB2UDSMD ends, review the contents of the HFS file specified in STDOUT in thestarted task JCL. Listing 4 shows an example of good results.

Listing 4. Example of successful HFS file results

Mon Mar 2 12:48:32 PST 2009args[0]: -timeoutargs[1]: 1args[2]: -portargs[3]: 4553args[4]: -logargs[5]: /dev/nullCode Level: 070418Debug Session Manager started on IP: 9.30.88.135 - port: 4553idleTimeOut: 1Mon Mar 2 12:49:37 PST 2009

Using the session manager support routines

The Unified Debugger provides the following DB2 stored procedures for supportingsession manager operations:




• DBG_LOOKUPSESSIONMANAGER: Discover the default sessionmanager network address.

• DBG_PINGSESSIONMANAGER: Detect an active session managersomewhere on the network.

• DBG_RUNSESSIONMANAGER: Launch a session manager at theconnected DB2 server system using the started task definitions describedearlier.

These stored procedures are installed during Unified Debugger setup on a DB2z/OS server by running the DB2 provided post-installation job DSNTIJSD. Afterinstallation, you can view and run these stored procedures using Data StudioDeveloper. The procedures are listed under the SYSPROC schema in the DataSource Explorer, as shown in Figure 5.

Figure 5. DBG procedures under SYSPROC schema in Data Source Explorer




The following sections describe the procedures in more detail.

DBG_LOOKUPSESSIONMANAGER

DBG_LOOKUPSESSIONMANAGER is used to show the default session managernetwork address from the perspective of the DB2 server. This is a convenient routine




to call from Data Studio Developer. It requires no inputs, and it always returns the IPaddress of the server and the default session manager listening port for every call.The Unified Debugger assigns 4553. This is the information you need to manage asession manager at the connected DB2 server using other Unified Debugger supportroutines.

Figure 6. Look up the default session manager address

DBG_PINGSESSIONMANAGER

DBG_PINGSESSIONMANAGER is used to test for the existence of a runningsession manager. It is an active routine that contacts or pings a session manager atthe specified IP address and listening port. This can be any session managerrunning on the network, not just the one running at the connected DB2 server.

This is the most important session manager support routine, because it validatesactual communication with a session manager across the network from theperspective of the DB2 server. This is the same communication pathway that isexercised during debugging of stored procedures.

Figure 7 shows how to use DBG_PINGSESSIONMANAGER to test for a runningsession manager at the default host address and port obtained usingDBG_LOOKUPSESSIONMANAGER.

Figure 7. Specify parameters of DBG_ PINGSESSIONMANAGER




After running this procedure successfully, check the Parameters tab in the SQLResults view. If the output parameter XMLREPLY has no value, the ping to that hostIP failed, as shown in Figure 8.

Figure 8. Unsuccessful ping of a session manager

An unsuccessful ping means that either no session manager is running at that IPlistening on that port, or there is a network connectivity issue reaching that IPaddress. Because the example involves pinging a session manager at the same IPaddress as the connected DB2 server, you can rule out network connectivity issues.So, you can determine with certainty if there is a session manager running at theconnected DB2 server, listening on the designated port.

DBG_RUNSESSIONMANAGER




DBG_RUNSESSIONMANAGER is used to launch the session manager at theconnected DB2 server. It is an active routine that uses the local operating systemfacilities to start the session manager as a new system task. On z/OS, a STARTcommand performs this event but requires definition of the DB2UDSMD started task.

The inputs to DBG_RUNSESSIONMANAGER are the desired listening port and atime interval for the session manager to remain active while waiting for a debugsession to manage. The example in Figure 9 shows use of the default listening portvalue 4553 and 30 minutes of idle wait time. (Note that the IP address is implied,which is the same host address that DBG_LOOKUPSESSIONMANAGER returned.)

Figure 9. Specify parameters of DBG_RUNSESSIONMANAGER

On z/OS, the DBG_RUNSESSIONMANAGER stored procedure is really just avehicle to issue the system command START DB2UDSMD. The return code fromthe START command is buried within the BLOB output parameter XMLREPLY. (Thisoutput is intended for programs rather than direct user consumption. If you want, youcan dig for the return code specification in the hexadecimal notation, starting atposition 141. Look for 72633D223022, which reflects the six binary characters ofrc=“0”.)

To see enough characters to discover the return code, complete the following steps:

1. Switch to Display result in text mode by clicking on the icon shown inFigure 10.

Figure 10. Run session manager result




This changes the display as shown in Figure 11.

Figure 11. Run session manager result Text mode display

2. Scroll to the right to get to the correct position (141) to see the returncode, as shown in Figure 12.

Figure 12. Run session manager result Text mode display rc=”0”




Getting a zero return code from the START command is important, but it is not anindication of a running session manager. Issuing the START command is likepressing the launch button for a rocket. If everything is in good working order, theengines ignite, the rocket leaves the launch pad, and the rocket delivers the satelliteinto orbit where the satellite unfurls its antenna and begins communication. Similarly,the session manager is not assured to be ready for use immediately after callingDBG_RUNSESSIONMANAGER. It takes a period of time for the new system task tostart, for the Java environment to be established, and for the session managerprogram to load and initialize.

If all systems are in good working order, the launch progresses through all thesestages without hesitation. The amount of time this takes can vary widely based onother activity on the z/OS system, but it should ordinarily be a matter of seconds. Totell if the session manager came up, call DBG_PINGSESSIONMANAGER again.Wait 5 to 30 seconds before making that second call, looking for any value returnedin the output parameter XMLREPLY that indicates that the session manager launchwas successful and it is now up and ready to service debug sessions, as shown inFigure 13.

Figure 13. Ping session manager after running session manager




Running the session manager manually on a z/OS system

This article described how to set up the session manager on a z/OS system, definingit as an ordinary network daemon capable of being started by system facilities andcapable of being managed at the connected DB2 server by a Data Studio Developerclient. For greater flexibility, you will now see how to manually run the sessionmanager on a z/OS system. It is similar to running the session manager manuallyanywhere on the network, including on your own workstation.

The session manager is a Java program (db2dbgm.jar), so it can be executedanywhere a suitable Java runtime environment exists. A z/OS system with Java JRE1.5 is ideal. The example here is based on a z/OS system with DB2 for z/OS V8installed, a configuration where there is no session manager .jar file alreadydistributed on the z/OS system.

To get started, gather the following things:

• A copy of the session manager .jar file, db2dbgm.jar. You can use thecopy distributed with Data Studio Developer.

• The path to the Java JRE binaries on the target z/OS system. Use thesame value you used in Step 2 of the started task setup. It should be thesame for all users of any given z/OS system. Ultimately, you need to getthis directory from the z/OS system administrators.




• The IP address of the target z/OS system. You can get this by runningSYSPROC.DBG_LOOKUPSESSIONMANAGER at the DB2 for z/OS V8server. Obtaining the IP address this way can also validate that therequired Unified Debugger setup on the V8 DB2 server has beenperformed.

• Have an ID with a home directory that can log on to the z/OS UNIXSystem Services (USS) environment. The example uses usrt003.

• A terminal session to log on to the z/OS UNIX System Servicesenvironment. The example uses telnet from a workstation commandwindow.

Complete the following steps to run the session manager manually.

Step 1: Use FTP to transfer a binary copy of the session manager .jar file toyour home directory

Figure 14 shows the series of FTP commands to copy the db2dbgm.jar file to z/OS.

Figure 14. FTP to transfer db2dbgm.jar to server




Step 2: Using telnet, logon to your user ID to verify the copied sessionmanager .jar file and Java availability.

1. Enter telnet <server-ip>Note that some installations might require a second parameter on thetelnet command. Specify the telnet listening port if it is not the defaultvalue 23 on the z/OS system.

2. Enter your user ID and password when prompted.

3. Change to your home directory, and verify that the session manager .jarfile is there.

4. Enter the command to have Java identify itself, specifying the fulldirectory pathway to the Java JRE, along with the fullversion option, asshown in Figure 15.

Figure 15. Telnet to server

Step 3: Manually run the session manager Java program.

You can run db2dbgm.jar by issuing one long command. It is probably more familiarto see into delivered in several separate commands, as shown here:




export PATH=/usr/lpp/java150/J5.0/bin:$PATHexport CLASSPATH=./db2dbgm.jarjava com.ibm.db2.psmd.mgr.Daemon –port 4554 –timeout 1

The example shows a timeout value of 1 second for the verification step. Normallyyou would use a larger value, such as 30 seconds (or 0 for infinity) so you can returnto Data Studio Developer to debug stored procedures and use the session managerthat is already running. As long as you remain logged on to your UNIX® SystemServices ID, you can run the session manager again if it times out by reentering theJava command.

Figure 16. Telnet run session manager

To interrupt or cancel the running session manager, use Ctrl-C. You might need todo this if you entered an infinite time out (-timeout 0) and then wish to log off.

Consider writing a shell script to make execution of the session manager from yourID easier. You can approach this easily by using a text editor at your workstation to




write the script file content and giving it an appropriate file name, such as runsm.sh.Then use FTP to transfer that text file to your z/OS USS home directory.

Listing 5 shows a sample shell script. Be sure to specify the proper path to the JavaJRE binaries as they exist on your z/OS system.

Listing 5. Sample shell script (runsm.sh)

#! /bin/sh# Script to manually run the Unified Debugger Session Manager# when located in the current directory# Syntax:# . runsm.sh port timeout log# Defaults are:# . runsm.sh 4554 30 /dev/null## Locate Java on the system from environment variable JAVA_HOMEexport JAVA_HOME=${JAVA_HOME:-/usr/lpp/java150/J5.0/bin}## Start with an empty log file, when specifiedif test "${3:-/dev/null}" != "/dev/null"then if test -f $3then if test -w $3

then echo Removing existing logfile "$3"rm -f $3

fifi

fiecho 'Running Unified Debugger Session Manager (use Ctrl-C tocancel)'date$JAVA_HOME/java -cp ./db2dbgm.jar com.ibm.db2.psmd.mgr.Daemon \-port ${1:-4554} -timeout ${2:-30} -log ${3:-/dev/null}date# end script

When the session manager is active, return to Data Studio Developer to configurethe stored procedure debugger preferences by clicking Window > Preferences.Then expand the Run/Debug menu, and select DB2 Stored Procedure Debugger,as shown in Figure 17.

Figure 17. Set up debug preferences




Even though you manually ran the session manager on z/OS, because you did it atthe same z/OS system where your connected DB2 server is installed, you can useeither setting on the stored procedure debugger preferences. Just be sure toproperly identify the actual port and IP address displayed by your manually startedsession manager.

Click OK to close the preferences page. You are ready to start debugging.




Gathering a session manager trace for IBM Service

The session manager has a trace capability that IBM Service might ask you tocapture to help diagnose problems while debugging stored procedures with theUnified Debugger. The session manager trace file is activated by specifying a filename for the log option when the session manager Java program is executed. Thelog option requires a file name. In the example, the log option is specified, but with aspecial file name (/dev/null) that is a placeholder for no real file at all. (You can alsoremove the log option entirely from the Java command line to prevent any trace fileactivity. Do not leave the log option on the command line without a filename.Remove both parts.)

To activate the session manager trace for IBM Service, you need to add or changethe log option to reference a readable and writeable file on the system. The sessionmanager appends trace records to the log file as long as it is running, so plan youradjustment carefully. You should initiate tracing with a new or relatively empty file,and limit the active trace to only the period of time needed to capture the activity fordiagnosis. Thus it might be easiest to gather a session manager trace from amanually started session manager, rather than a session manager running from theformal started task JCL. However, the trace facility can be activated from eithervenue.

Summary

Debugging stored procedures using Data Studio Developer can be done easily withthe Unified Debugger technology. The session manager is the central component ofthe debug technology, so running it on your terms will improve your productivity. Youcan choose where and how to use the session manager on z/OS with Data StudioDeveloper.

This article described how to set up and operate the debug session manager onz/OS. Because the example showed you how to launch the session manageryourself using the session manager support routines at the connected DB2 server,people doing stored procedure debugging can use either of the following optionslisted on the Data Studio Developer Debug preferences:

• Run the session manager on each connected server. Data StudioDeveloper discovers the session manager you launched at the connectedDB2 server the same way you confirm the successful launch, by using theDBG_PINGSESSIONMANAGER routine.

• Use the already running session manager. By specifying here the host IPaddress obtained from DBG_LOOKUPSESSIONMANAGER and the portvalue used with DBG_RUNSESSIONMANAGER, Data Studio Developer




uses the session manager you launched yourself, after usingDBG_PINGSESSIONMANAGER to confirm that the specified sessionmanager location is responding to communication.

This article also described how to manage the session manager yourself on thez/OS system by writing a shell script that contains the appropriate commands.

Finally, this article described how to specify a log file for session manager trace, incase you need to provide it to IBM Service while working with you on a problem.

Acknowledgments

We would like to thank Kathy Zeidenstein and other reviewers for their help duringreview of this article.




Resources

Learn

• Use an RSS feed to request notification for the upcoming articles in this series.(Find out more about RSS feeds of developerWorks content.)

• Refer to the IBM Data Studio product page.

• Review Debugging DB2 for z/OS SQL stored procedures with IBM Data StudioDeveloper, the first article in this series, to understand how debugging works,mostly from the developer point of view.

• Take the Tutorial: Get Started with Data Studio Developer (IBM DatabaseMagazine, Q3 2007) for a great overview of Data Studio Developer.

• Look for Redbooks: DB2 9 for z/OS Stored Procedures: Through the CALL andBeyond

• Learn more about Information Management at the developerWorks InformationManagement zone. Find technical documentation, how-to articles, education,downloads, product information, and more.

• Stay current with developerWorks technical events and webcasts.

Get products and technologies

• Download Data Studio Developer Trial Version.

• Download More Data Studio products.

• Build your next development project with IBM trial software, available fordownload directly from developerWorks.

Discuss

• Participate in the discussion forum for this content.

• Read the Data Studio Forum on developerWorks.

• Check out the Data Studio Community Space on developerWorks.

• Follow the Data Studio Team Blog on developerWorks.

• Learn more from the IBM Unified Debugger Space on developerWorks.

• Check out the developerWorks blogs and get involved in the developerWorkscommunity.

About the authors



http://www.ibm.com/developerworks/views/rss/customrssatom.jsp?zone_by=data&type_by=Articles&search_by=Debugging+stored+procedures+on+DB2+with+Data+Studio+Developer%2C+Part&day=1&month=01&year=2008&max_entries=10&feed_by=rss&isGUI=true&Submit.x=45&Submit.y=14

http://www.ibm.com/developerworks/rss/

http://www.ibm.com/software/data/studio/



http://publib.boulder.ibm.com/infocenter/idm/v2r1/topic/com.ibm.datatools.dwb.tutorial.doc/topics/dwb_abstract.html?Open

http://www.redbooks.ibm.com/abstracts/SG247604.html

http://www.redbooks.ibm.com/abstracts/SG247604.html

http://www.ibm.com/developerworks/data/

http://www.ibm.com/developerworks/data/

http://www.ibm.com/developerworks/offers/techbriefings/

http://www.ibm.com/developerworks/downloads/im/datastudiodev/

http://www.ibm.com/developerworks/spaces/datastudio?pageid=649

http://www.ibm.com/developerworks/downloads/

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1086

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1086

http://www.ibm.com/developerworks/spaces/datastudio

http://www.ibm.com/developerworks/blogs/page/datastudioteam

http://www.ibm.com/developerworks/spaces/UnifiedDebugger

http://www.ibm.com/developerworks/blogs/

http://www.ibm.com/developerworks/community

http://www.ibm.com/developerworks/community


Emily ZhangEmily Zhang is an advisory software engineer for IBM's Application DevelopmentTooling organization at Silicon Valley Laboratory in San Jose, CA. She is a memberof the development team for IBM Data Studio. Her areas of expertise include routinetooling development and unified debugger.

Tom MillerTom Miller is a senior software engineer at the IBM Silicon Valley Laboratory in SanJose and an IBM veteran since 1982. Since 2001, Tom has been a member of theDB2 for z/OS Development team, leading the SQL stored procedure technologies.Tom is a member if the IBM Unified Debugger development team, bringing theUnified Debugger technology to Java and SQL procedures on DB2 for z/OS. Prior tohis current assignment, Tom was the QMF Architect.

Trademarks

IBM, developerWorks, DB2, z/OS are trademarks of IBM Corporation in the UnitedStates, other countries, or both.Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in theUnited States, other countries, or both.Microsoft, Windows, Windows NT, and the Windows logo are trademarks of MicrosoftCorporation in the United States, other countries, or both.UNIX is a registered trademark of The Open Group in the United States and othercountries.Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.Other company, product, or service names may be trademarks or service marks ofothers.




Documents

Debugging stored procedures on DB2 z/OS with Data Studio