 | Level: Introductory Peggy Rader (peggyr@us.ibm.com), IBM DB2 for OS/390 and z/OS development, San Jose, CA
27 Mar 2003 Peggy Rader briefly describes your options for debugging Java stored procedures on DB2 UDB for z/OS and provides a hint for making it work with the IBM SDK 1.3.1.
© 2003 International Business Machines Corporation.
All rights reserved.
The IBM Distributed Debugger provides a GUI interface for debugging JavaTM stored procedures on DB2® Universal DatabaseTM for Linux, UNIX®, and Windows®. This option is not available for debugging DB2 interpreted Java stored procedures on DB2 for z/OSTM. There are two alternatives that you can use to debug DB2 Java stored procedures on z/OS.
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).
Figure 1. The JAVAERR. TXT and JAVAOUT. TXT HFS files
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 //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
.
|
Rate this page
| |
