Storing diagnostic information (CCASNAP)

Overview

The CCASNAP data set 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 data set.

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.