© 2003 International Business Machines Corporation. All rights reserved.

The IBM Distributed Debugger provides a GUI interface for debugging Java^TM stored procedures on DB2® Universal Database^TM for Linux, UNIX®, and Windows®. This option is not available for debugging DB2 interpreted Java stored procedures on DB2 for z/OS^TM. There are two alternatives that you can use to debug DB2 Java stored procedures on z/OS.

• Create comparable DB2 z/OS DDL and SQL on a DB2 on Windows or UNIX; then use the Distributed Debugger as described in the DB2 Stored Procedure Builder (V7 client) or Development Center (V8 client) online help, under Remotely debugging stored procedures. When the debugging of the Java stored procedure is successfully completed, copy and paste (install) the Java stored procedure to DB2 for z/OS.

  This method is recommended when possible as it provides the most comprehensive information for Java stored procedure debugging.

• Write System.out.println, System.err.println lines in your Java code to STDOUT and STDERR. This is the alternative that I describe in this tip.

The IBM Software Development Kit (SDK) 1.3.1 doesn't recognize the default USS Directory structure to locate the STDOUT and STDERR files. This is solved in the SDK 1.4.1.

To make this process work with the SDK 1.3.1 on z/OS, add the following two DD statements to your WLM PROC where your Java stored procedure executes. The two HFS files described in the DD statement PATH parameter must exist on your HFS file system. These two files are appended to if not manually cleared out between debugging sessions as a result of the OAPPEND option.

 
//JAVAOUT  DD    PATH='/u/DB7P/javasp/JAVAOUT.TXT', 
// PATHOPTS=(ORDWR,OCREAT,OAPPEND), 
// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIWGRP,SIROTH,SIWOTH) 
//JAVAERR  DD    PATH='/u/DB7P/javasp/JAVAERR.TXT', 
// PATHOPTS=(ORDWR,OCREAT,OAPPEND), 
// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIWGRP,SIROTH,SIWOTH) 

• JAVAOUT maps to STDOUT
• JAVAERR maps to STDERR

The above JAVAOUT and JAVAERR statements are used by the JVM and the associated user ID of the JVM is used for the read/write operations, not the user ID associated with the WLM PROC or the userid associated with the stored procedure that is being called. Therefore, granting read/write access is required in the PATHOPTS for all users.

The PATHOPTS' OAPPEND option on JAVAOUT and JAVAERR is included so that these files do not get cleaned up immediately or upon JVM startup. You will need to periodically delete these two files to keep them from growing without bounds.

Figure 1 shows the z/OS HFS files that correspond to the HFS files in the WLM PROC above (in an FTP client).

After the IBM SDK 1.4.1 is installed and used on z/OS, you can remove these statements and the STDOUT and STDERR will redirect to the location of your Java WLM Execution PROC, //JAVAENV DD WORK_DIR parameter, or to the default directory. If you do not remove the statements from your Java WLM Execution PROC, the //JAVAOUT, //JAVAERR DD datasets will continue to provide output and will override the SDK 1.4.1 settings.

The default value of WORK_DIR will be /tmp/java. This directory must exist at the time the Java stored procedure tries to read or write to STDOUT or STDERR, otherwise the files, STDOUT or STDERR will not be created.

The mapping for these two files will be:

• <WORK_DIR>/server_stdout.txt maps to STDOUT.
• <WORK_DIR>/server_stderr.txt maps to STDERR.

With the IBM SDK 1.4.1, you may want to continue using the //JAVAOUT and //JAVAERR DD datasets in the WLM PROC, or alternatively you may want to include the WORK_DIR parameter in the //JAVAENV DD dataset within the WLM PROC that executes the Java stored procedure. Operating in this manner overrides the default location of the /tmp/java directory. I recommend this when multiple developers are debugging multiple Java stored procedures that execute out of multiple WLM PROCs, concurrently. The WLM PROC would include a WORK_DIR parameter in the //JAVAENV DD dataset, pointing to a different HFS directory to help isolate debugging information for different applications.

About the author

Peggy Rader is a Senior Software Engineer at the IBM Silicon Valley Lab in San Jose, California. You can reach Peggy at peggyr@us.ibm.com .

Comments (Undergoing maintenance)

---

---

Back to top

Trademarks  |  My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help