Follow

How to use the runtime's exception core dump to view a snapshot of the data at the time of the exception

Compiler/Runtime/EBP Version 25.5.2 RC2

Runtime coredump:

The runtime has been equipped with a core dump facility that outputs a core dump file when an exception occurs. This file will contain data information at the moment a exception or abend exception was invoked. The location of the dump file will depend on the environment in which the app is running.

Depending on the mode in which the app is being run the coredump file has different naming conventions as well as locations in order to help identify the related app. 

Command Line:

When running from the command line the coredump will get created in the current directory as shown:

The naming format will _SYSUDUMP_<ProcessID>_<UniqueString>

Eclipse IDE:

When running in the Eclipse IDE, the location of the dump file will be in the workdir of the project in which the app is being run. 

 

EBP:

When running in EBP mode, the coredump file is formed as the SYSUDUMP file.

The SYSUDUMP file is located in the [ebp.outputspool] directory by default unless specified otherwise.

The file name is formed with the jobid, proc name( if present) and step name as shown below

OUT<JOBID>.<PROC>.<STEP>.SYSUDUMP.txt => OUT100292_STEP0002_SYSUDUMP

    

If SYSUDUMP is not specified the core dump file will be located in the ebp.outputspool directory.

 

ETP:

In ETP mode, the coredump file name is formed for a transaction using the teminalID, username, taskID and tasknumber as shown.

SYSUDUMP_termID_username_taskid_tasknumber => SYSUDUMP_A004_CICSUSER_init_19

The location where the file is created can be specified by using the property sysudump.dir in deploy.properties

For e.g: sysudump.dir=/home/sjlenus/dumpdir

If the property is not specified then the default location is the tomcat logs folder.

When an application exception occurs the core dump file location will be output to the browser in which the exception info is typically and also in the tomcat logs. 

 

Coredump Usage:

The coredump generated will allow the user to inspect the data in the variables at the moment the exception occurred. It will also show the user the line of execution in the various programs. 

To use the coredump file , one will require the Eclipse IDE and a project containing the programs that were in session. You need not have the same class files/jars that were in use in production but the source files should not have been modified in any form, and the compiler directives should be exactly the same.

Right click the project which contains the programs and select "Run Abend Analyser..."

This will bring up a dialog which will allow you to select the core dump file.  On selection of a core file, the user will be shown a dialog listing all the programs that were in session when the exception occurred. The user can decide whether to load specific ones or all of them. On selection the tool will load in debug mode all the programs that were in session when the exception occurred.

It is important to note that since this is a snapshot, program navigation using debug tools is disabled. Selecting the program in the stack trace will take the user to the line of execution for that program.

The user can inspect the java code by using the regular editor menu of "Goto Java Source"

The user can inspect data by hovering over the data or using the Cobol variables view

The core dump file generated is meant for use by the runtime only. The format of the data stored within it is provided below

[6-bytes ObjectOutputStream header]
[2-bytes indicating length of string constant "STK:"]
[4-bytes string constant "STK:"]
[2-bytes indicating length of stack trace info that follows]
[n1 bytes of Stack trace Info enclosed in square brackets ("[]") where adjacent elements 
  are separated by the characters ", " (comma and space). n1 is provided in the preceding 2 bytes]

   ***The following gets repeated for every program that was active when the exception occurred****    
   [2-bytes length Indicator for program id info that follows]
   [String data "PGM:" + program-id]

   [5-bytes string constant "CMP:V" + 8-bytes compiler version. For e.g. "CMP:V25.11.20"]   (beginning v25.12.1 RC1)
           [OPTIONAL]  
               [2-bytes indicating length of string constant "WRK:"]
               [4-bytes string constant "WRK:"]
               [4-bytes indicating length of working storage memory that follows]
               [n2 bytes of working storage data where n2 is provided in the preceding 4 bytes]
               [2 bytes block data protocol markers]
           
           [OPTIONAL]  
               [2-bytes indicating length of string constant "FIL:"]
               [4-bytes string constant "FIL:"]
               [4-bytes indicating length of file section storage memory that follows]
               [n3 bytes of file section storage data where n3 is provided in the preceding 4 bytes]
               [2 bytes block data protocol markers]                
  
           [OPTIONAL]  
               [2-bytes indicating length of string constant "LNK:"]
               [4-bytes string constant "LNK:"]
               [4-bytes indicating length of linkage storage memory that follows]
               [n4 bytes of linkage storage data where n4 is provided in the preceding 4 bytes]

  
 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk