Storing diagnostic information (CCASNAP)

Overview

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.

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.

As an alternative, z/OS users can use an extended version of the SYSMDUMP facility to take up to ten unformatted dumps of the Model 204 address space. This is described in the following section. The asynchronous dump option is faster that the SYMDUMP option, which is faster than the CCASNAP option.

Allocating SYSMDUMP data sets

To allocate multiple SYSMDUMP data sets, insert one to ten DD statements with ddnames CCAMDMP0, CCAMDMP1, and so on. The following rules apply to the use of CCAMDMP data sets:

• Only empty CCAMDMP (0 - 9) data sets are selected for SYSMDUMP processing. At any time during the run, each data set contains at most one dump. This prevents SYSMDUMP processing from destroying or overwriting previous dump data sets.
• Use of tape data sets is not supported. The CCAMDMP data sets must be preallocated on disk devices.
• If the CCAMDMP allocations are DISP=SHR, then you can clear, copy, or analyze any of the data sets without bringing down the Model 204 Online.
• If an error occurs while allocating a CCAMDMP data set, allocation is not attempted again for the remainder of the run.
• If all CCAMDMP data sets are full, then SYSMDUMP processing terminates and either SYSUDUMP or SYSABEND is used for further ABDUMP processing, if either of these is specified in the JCL. Use of SYSUDUMP or SYSABEND statements in case of overflow is not recommended, however. These auxiliary data sets are more likely to fill up spool space than to provide important diagnostic information.
• CCAMDMP and SYSMDUMP DD statements are incompatible. If a SYSMDUMP statement is present, then the CCAMDMP statements are ignored, and multiple dump data sets cannot be created.
• Note that CCAMDMP data sets must be allocated on single extents.

Number of CCAMDMP data sets

The optimum number of CCAMDMP data sets is normally equal to the value of the SNAPLIM parameter.

CCAMDMP data set DCB characteristics

DCB characteristics of CCAMDMP data sets must be the same as those recommended for the standard z/OS SYSMDUMP facility, shown in the following table:

CCAMDMP DCB characteristics

System	Organization	Record format	LRECL	BLKSIZE
z/OS	PS	FB or F	4160	4160

Space allocation

To estimate the space required for each CCAMDMP data set, add four megabytes to the size of the Model 204 address space. For example, a 20M address space needs 24M, or about 40 cylinders on a 3380 disk device.

Size of Model 204 address space

The address space actually used in a Model 204 run can depend on several factors in addition to the REGION parameter. For more information on this topic, refer to the IBM z/OS documentation.

Coordinating use of CCAMDMP and CCASNAP data sets

You can allocate both CCAMDMP and CCASNAP data sets in a Model 204 run. An advisable setting for CCASNAP is SNAPPDL. The CCASNAP data set is then useful for quick diagnosis, while the CCAMDMP data sets provide more complete information.

Processing CCAMDMP data sets

You can process CCAMDMP data sets allocated in share mode using standard utilities such as IEBGENER. To archive and clear a dump data set, for example, copy it to tape, then copy a null file to the disk data set.