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.
| 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.