Using Fault Analyzer
- Introduction
- Real-time analysis
  - Dump suppression
    - Fault Analyzer and CICS global user exits
  - Fault history file selection
  - Controlling the real-time analysis with options
  - JCL DD statements
  - The real-time analysis report
  - The SYSLOG summary
  - Using the program SNAP interface (IDISNAP)
  - Invoking Fault Analyzer from a Java try-catch block
    To capture the current Java™ state from a Java program, Fault Analyzer can be invoked to create a history file fault entry, along with an associated MVS™ SVC dump.
  - Invoking Fault Analyzer from Java dump events
  - Using the Fault Analyzer Java wrapper utility
    Fault Analyzer Java wrapper utility wraps a callable Java application in a try-catch block by using the FA Java class.
  - Using the Fault Analyzer JVMTI Agent
    Fault Analyzer provides a JVMTI (JVM Tool Interface) agent. The agent runs inside a Java™ Virtual Machine (JVM) and can inspect the state of the running Java application.
  - Dump registration processing
  - Real-time exclusion processing
  - Recovery fault recording
  - Using SLIP,COMP=0C4 with Fault Analyzer
  - Extended minidump data set (XDUMP)
  - Abend traps can prevent fault analysis
  - Capturing and displaying the abending job JCL
    When the JCLcapture option is in effect during real-time processing, Fault Analyzer attempts to obtain the JCL and save it in the fault entry. This feature is available with JES2 only.
- The Fault Analyzer ISPF interface
- Performing batch reanalysis
- Performing interactive reanalysis
- Performing CICS system abend dump analysis
- Formatting a CICS auxiliary trace data set
- Performing Java analysis
- The Fault Analyzer report
- Using non-ISPF interfaces to access Fault Analyzer history files

Fault Analyzer and CICS global user exits

If Fault Analyzer is installed in the CICS® XPCABND global user exit (GLUE), and transaction abend analysis completes successfully (either an LE or non-LE application), then Fault Analyzer passes the appropriate return code to CICS® to suppress the transaction dump. The implication of this passing is that any subsequent dump-related CICS® GLUE, for example XDUREQ, is then not invoked by CICS®.

If your environment is such that you require subsequent CICS® dump GLUEs to always be called, or if you require CICS® transaction dumps to always be written, you should do one of the following:

Code a Fault Analyzer End Processing user exit and set the ENV.SUPPRESS_DUMP flag to 'N'.
Set the RetainCICSDump option to ALL. See RetainCICSDump for more details.

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.