C H A P T E R 13 |
Diagnostic Tools |
This chapter describes the tracing and dumping facilities Sun MTP provides. Do not use these facilities unless you are instructed to do so by your authorized service provider. The topics in this chapter include:
The Sun MTP trace facility enables you to selectively trace low-level routines. Use it only under the direction of a technical support engineer. This internal tracing facility increases the amount of shared memory that Sun MTP allocates. Each of the following processes has a trace table allocated for it in shared memory:
The default size of each trace table is 80,000 bytes.
The following formula shows how much shared memory is required for tracing for a Sun MTP region.
(tx-procs + 6) * 80,000 = bytes
Add the number of transaction processors to 6, which is the number of static shared memory processes, and then apply the formula. In the following example, the region has 8 transaction processors, so 14 processes are used to calculate the shared memory requirements.
Sun MTP will allocate 1,120,000 bytes of shared memory for internal tracing.
After you calculate the shared memory requirements for the extended trace facility, you must add that number to the shared memory requirements of your application to get the total shared memory requirement. When starting Sun MTP, provide this value with the -S option to unikixmain.
Use the kixetrace utility to display the Trace Administration Utility menu.
An asterisk (*) is displayed next to any option that is selected.
When the trace facility is first run, the menu always shows Production trace on as selected. This does not mean that production trace is turned on; it is the default. The menu does not indicate the options with which Sun MTP is running.
The kixeformat utility is provided to format internal trace dumps. It should only be used under the direction of your authorized service provider. The Sun Mainframe Transaction Processing Software Reference Guide describes the command format for this utility.
Sun MTP provides two methods for dumping system information that you can use to help determine the cause of problems:
The application dump facility produces a formatted dump file that lists an application's runtime environment under the following circumstances:
The application dump file is written to the $KIXSYS directory and the name of the file is printed in the log file with message number KIX6702I. The dump file name is a combination of the transaction name and a sequence number; for example, AC010000.prt.
The formatted dump file includes the following information:
The application dump facility also writes the following information to unikixmain.err and unikixmain.log:
Although an application dump file is generated by default, you can explicitly enable the dump facility using either of the following options:
To turn off the dump facility, use either of these options:
The unikixmain.log file contains information about the transaction failure. It provides the name of the transaction, the name of the program, and the last four CICS commands executed by the transaction. Each CICS command provides the following information:
The CID# reference helps to locate the CICS command(s) that was executed. This reference number is generated by the kixclt translator. By searching for the CID# reference in the output of the kixclt translator (a *.cbl file for COBOL), you can locate the CICS command that was executed.
When the application dump facility is enabled, entries are written to unikixmain.err and unikixmain.log that look similar those in the following example.
In this example, CID# 00001113 is the command that failed. In the source program, ACCT01.cbl, a search for 0001113 displays the following code:
The dump file generated for a COBOL program looks similar to the example in CODE EXAMPLE 13-1.
When interpreting the information in the dump file, note the following:
The dump file generated for a C program looks similar to the example in CODE EXAMPLE 13-2.
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.