Storing diagnostic information (CCASNAP): Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (ELowell moved page Storing diagnostic information (CCASNAP and CCAMDMP) to Storing diagnostic information (CCASNAP): Sections on CCAMDMP (which is deprecated) have been moved to a new page, "CCAMDMP data sets")
Line 1: Line 1:
==Overview==
==Overview==
<p>
<p>
The CCASNAP file stores the contents of SNAP dumps, which identify program or file integrity problems. In the case of a severe error, you can also use the SYSUDUMP file.        </p>
The CCASNAP dataset stores the contents of SNAP dumps, which identify program or file integrity problems. In the case of a severe error, you can also use the SYSUDUMP or SYSMDUMP dataset.        </p>
<p>
<p>
System dumps are normally indicated by the user abend code 2749. Dumps are also generated before snaps to preserve subtask information. </p>
System dumps are normally indicated by the user abend code 2749. Dumps are also generated before snaps to preserve subtask information. </p>
Line 8: Line 8:
<p>
<p>
The last section of this page explains how to create multiple SYSMDUMP data sets in z/OS environments.</p>
The last section of this page explains how to create multiple SYSMDUMP data sets in z/OS environments.</p>
 
==SNAPCTL parameter==
==SNAPCTL parameter==
<p>
<p>

Revision as of 11:48, 25 July 2016

Overview

The CCASNAP dataset stores the contents of SNAP dumps, which identify program or file integrity problems. In the case of a severe error, you can also use the SYSUDUMP or SYSMDUMP dataset.

System dumps are normally indicated by the user abend code 2749. Dumps are also generated before snaps to preserve subtask information.

This page summarizes the SNAPCTL parameter and the MSGCTL command, which produce SNAPs. Requirements for producing dumps in z/OS, z/VSE, and z/VM systems are discussed.

The last section of this page explains how to create multiple SYSMDUMP data sets in z/OS environments.

SNAPCTL parameter

In z/OS and CMS environments, you can generate SNAP dumps using the SNAPCTL parameter in the User 0 input stream. SNAPCTL specifies the actions taken when Model 204 encounters an error that requests a SNAP.

A user with system manager privileges can set SNAPCTL on the User 0 parameter line or reset it with the RESET command. Settings allow a range of options from taking a complete SNAP to taking no SNAP and from producing no dump to a complete region dump.

Although SNAPCTL parameter settings correspond to settings available on the MSGCTL command, which are summarized in the "MSGCTL command options" table below, SNAPCTL processing takes precedence.

Handling error messages with MSGCTL command

The MSGCTL command specifies the action performed by Model 204 for each Model 204 error message.

MSGCTL command options
Option Performs this action...
AUDIT Puts the specified message on the audit trail as an AD line.
COUNT Increments, by one, the message count whenever this message is issued. If the message count exceeds the value of the ERMX parameter, the user's session and processing are stopped.
DUMPALL Dumps the entire Model 204 region
NOACTION Ignores the original option that was assigned the message and returns to main processing.
NOAUDIT Suppresses the auditing of a specific error message.
NODUMP Does not generate a dump
SNAP Produces a SNAP
SNAPALL Similar to SNAP
SNAPPDL Produces a SNAP that includes registers, module link map, allocated storage map, pushdown list trace, KOMM, disk buffers containing file pages held by the current user, and patch information
SNAPSEL Produces a SNAP similar to that of SNAPPDL along with additional specified output, such as table disk buffers

Introducing message types

By design each Model 204 message is assigned a type — AD, ER, MS, or RK — and assigned separately whether the message is counted or not. When the occurrence of a counted message equals the ERMX parameter value, processing stops and the user stopped.

The message types — AD, ER, MS, or RK — are mutually exclusive. Usually, the ER messages are counted and the other message types are not. Each processing option is handled independently of other options, as each option is designed to manage a single function.

On a message by message basis, use the MSGCTL command to change message processing options to more precisely accommodate the needs of your site and applications.

Adjusting error messages at your site

Using the MSGCTL command options, you can manipulate the message type and whether the message is counted. Using the option:

  • With the AUDITxx and NOAUDITxx options, you can manipulate the type of message and where it appears in the audit trail.
  • With the COUNT or NOCOUNT option, you can manipulate whether the message counts toward the ERMX total.

Caution: Rocket Software strongly recommends the you do not apply the NOCOUNT option to messages that are part of SOUL compilation processing. Counting errors typically terminate the compilation process. In instances where you make compilation errors NOCOUNT, compilation is not terminated. Failure to stop compilation can result in invalid information being made available to the evaluation process resulting in subsequent snaps.

Modifying message type

You can modify the assigned message type as shown in the following table.

Message type Option applied Reverts to...
AD NOAUDITAD MS
ER NOAUDITER RK
MS NOAUDITMS Not be audited (NOAUDIT)
RK NOAUDITRK AD

The NOAUDITxx option processes only a message of type xx. However, the NOAUDIT option can process any message type. Conversely, AUDITxx can process any message type and results in the message becoming type xx.

For example, consider the M204.1030 INVALID COMMAND message, which is designed as a counted, ER type message.

  • If at your site you turn off all auditing and journaling for that message, you would issue the following command:

    MSGCTL M204.1030 NOAUDIT

    The message would no longer appear on the audit trail. However, it would still be a counted error and appear at the user terminal.

  • Suppose at your site you issue the following command:

    MSGCTL M204.1030 NOAUDIT NOCOUNT

    The message would no longer appear on the audit trail and it would not be counted toward the maximum number of errors (ERMX). However, it would still appear at the user terminal.

Understanding MSGCTL command options

NOACTION option

The NOACTION option suppresses almost all error message processing. When an error is generated, Model 204 checks an indicator flag to determine if that error message needs to be processed and whether the processing options have been changed via MSGCTL processing. If an error is found to have no processing requirements — that is, NOACTION — processing returns immediately to the next instruction. NOACTION has no effect on the following messages:

  • Counted messages that occur during compilation
  • Initialization, start up, and restart
  • Termination

The decreased number of instructions necessary to process the NOACTION option versus the NOAUDIT option results in a large CPU processing reduction.

Caution: If you allow SOUL programs to continue processing past an error that has been suppressed with the NOACTION option of the MSGCTL command, you must expect abends, incorrect database results, recovery errors, the inability to recover or other unpredictable consequences. Rocket Software strongly recommends that you consider carefully the circumstances, before you introduce the NOACTION option.

AUDITxx options

These options can be used for any message type — AUDITER, AUDITRK, AUDITAD, and AUDITMS — to change the current message type to another xx type message and its related processing options.

The NOAUDIT option functions for a message of any type, suppressing the auditing of the designated message.

NOAUDITxx options

The NOAUDITxx options function only for a message of that designated xx type.

Option Changes message type To message type
NOAUDITER ER RK
NOAUDITRK RK AD
NOAUDITAD AD MS
NOAUDITMS MS NOAUDIT

Independent option assignment

For example, message M204.1030: INVALID COMMAND is designated to be processed as both a counting error and an ER type message.

To turn off auditing and journaling for this message, issue the following command:

MSGCTL M204.1030 NOAUDIT

The message will no longer be written to the journal or the audit trail. However, it remains a counting error and appears on the user's terminal.

To change this message so that it is also not a counting error, issue the following command:

MSGCTL M204.1030 NOAUDIT NOCOUNT

Again, the message will no longer be written to the journal or audit trail, and now it is not be counted toward the ERMX limit. However, it still appears on the user's terminal.

Using the SNAPFAIL and SNAPFLIM parameters

The snap formatter is capable of recovering first-level as well as second-level errors without disabling the Online. The errors in question are program exceptions in unexpected places. For example, when the snap formatter assumes a pointer is valid, but it is not. This avoids a 4095 ABEND, followed by a RECURSIVE ENTRY TO ESTAE, which would bring down the Online.

The parameters, SNAPFAIL and SNAPFLIM, identify snap failures that have happened and set a limit on the number of failed snaps.

At the completion of recovery from a failed snap, one of the following M204.1449 messages is sent to the operator and CCAJRNL or CCAJLOG, as well as saved in the VIEW ERRORS table.

  • The following error message increases the value of SNAPFAIL by one:

    M204.1449: ERROR WHILE PROCESSING CCASNAP

  • The following error message indicated that snap formatting has been disabled, because the value of SNAPFAIL equals the value of SNAPFLIM:

    M204.1449: ERROR WHILE PROCESSING CCASNAP, CCASNAPS DISABLED

Both versions of message 1449 sets the Online and Batch return codes to 100.

Diagnostic information files on z/OS, z/VSE, and z/VM

z/OS

In a z/OS environment, the CCASNAP and SYSUDUMP files are normally specified as SYSOUT type data sets:

//CCASNAP DD SYSOUT=A //SYSUDUMP DD SYSOUT=A

z/VSE

In a z/VSE environment, SNAP output prints on the logical unit SYSLST. Output appears on the output report in the order in which it is generated.

z/VM

You can dynamically create a VMDUMP of the Model 204 service virtual machine using the z/VM Control Program VMDUMP command, if you detect a serious Model 204 error. The dump file is sent to the virtual machine designated as the target for VMDUMPs, as defined in the SYSTEM CONFIG file.

A FILEDEF for CCASNAP is required to produce VMDUMP. VMDUMP files are generated depending on the setting of the Model 204 SNAPCTL option. You can specify the DUMMY operand in the file definition for CCASNAP, which is adequate to cause VMDUMP production. If you define CCASNAP as other than DUMMY, Model 204 generates formatted SNAP information that augments the VMDUMP.

You can define CCASNAP as one of the following:

  • CMS file:

    FILEDEF CCASNAP DISK ONLINE CCASNAP A

  • Service machine virtual printer:

    FILEDEF CCASNAP PRINTER

Some Model 204 problems require a manual VMDUMP of the service virtual machine. The following command is required when Model 204 requests a VMDUMP:

VMDUMP 0-END DCSS SYSTEM FORMAT M204/CMS

You can omit the DCSS operand if no saved segments are associated with the virtual machine. To enter a VMDUMP command from the service virtual machine console, prefix it with the Control Program command (#CP). Dump the associated spool files to magnetic tape using the Control Program SPTAPE command after the Model 204 dump files are created. Submit the tape and any supporting documentation, such as the Model 204 audit trail, to Technical Support for analysis.

Using unformatted system dumps (z/OS)

For large Onlines, in the event of an error that results in a snap, you may find that the amount of diagnostic information written to CCASNAP is excessively large and takes a long time to write. In such cases, z/OS users can use the system asynchronous dump option to take a high-speed, unformatted dump of the Model 204 address space. This is described in SNAPCTL parameter.