Storing diagnostic information (CCASNAP) - Revision history

JAL: typo

2016-07-26T20:14:32Z

typo

← Older revision		Revision as of 20:14, 26 July 2016
Line 1:		Line 1:
	==Overview==		==Overview==
	<p>		<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>		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. </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>

DCameron: /* Overview */

2016-07-25T11:48:53Z

Overview

← Older revision		Revision as of 11:48, 25 July 2016
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>

ELowell: 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"

2016-07-20T21:58:12Z

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"

← Older revision	Revision as of 21:58, 20 July 2016
(No difference)

ELowell: deleted CCAMDMP info - deprecated - moved it to "CCAMDMP data sets" page

2016-07-20T21:55:56Z

deleted CCAMDMP info - deprecated - moved it to "CCAMDMP data sets" page

@@ Line 283: / Line 283: @@
 <p>
 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 <var class="product">Model&nbsp;204</var> address space. This is described in [[SNAPCTL parameter]]. </p>
 [[Category:System management]]
 [[Category:Auditing and problem determination]]

JALWiccan: Automatically generated page update

2014-11-06T17:08:16Z

Automatically generated page update

← Older revision		Revision as of 17:08, 6 November 2014
Line 347:		Line 347:
	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. </p>		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. </p>

	[[Category:System ~~Manager~~]]		[[Category:System management]]
	[[Category:Auditing and problem determination]]		[[Category:Auditing and problem determination]]

JAL at 21:07, 29 October 2014

2014-10-29T21:07:35Z

← Older revision		Revision as of 21:07, 29 October 2014
Line 348:		Line 348:

	[[Category:System Manager]]		[[Category:System Manager]]
			[[Category:Auditing and problem determination]]

Admin: 1 revision: converted system mgr pages

2014-10-17T20:27:49Z

1 revision: converted system mgr pages

← Older revision	Revision as of 20:27, 17 October 2014
(No difference)

JAL at 20:06, 29 August 2014

2014-08-29T20:06:09Z

New page

==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 <var>SNAPCTL</var> parameter and the <var>MSGCTL</var> 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 <var>[[SNAPCTL parameter|SNAPCTL]]</var> parameter in the User 0 input stream. <var>SNAPCTL</var> specifies the actions taken when <var class="product">Model 204</var> encounters an error that requests a SNAP.

A user with system manager privileges can set <var>SNAPCTL</var> on the User 0 parameter line or reset it with the <var>[[RESET command|RESET]]</var> 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 <var>SNAPCTL</var> parameter settings correspond to settings available on the <var>MSGCTL</var> command, which are summarized in the "MSGCTL command options" table below, <var>SNAPCTL</var> processing takes precedence.

==Handling error messages with MSGCTL command==

The <var>[[MSGCTL command|MSGCTL]]</var> command specifies the action performed by <var class="product">Model 204</var> for each <var class="product">Model 204</var> error message.

<table class="thJustBold">
<caption>MSGCTL command options</caption>
<tr class="head">
<th>Option</th>
<th>Performs this action...</th>
</tr>

<tr>
<th>AUDIT</th>
<td>Puts the specified message on the audit trail as an <var>AD</var> line.</td>
</tr>

<tr>
<th>COUNT</th>
<td>Increments, by one, the message count whenever this message is issued. If the message count exceeds the value of the <var>ERMX</var> parameter, the user's session and processing are stopped. </td>
</tr>

<tr>
<th>DUMPALL</th>
<td>Dumps the entire <var class="product">Model 204</var> region</td>
</tr>

<tr>
<th>NOACTION</th>
<td>Ignores the original option that was assigned the message and returns to main processing.</td>
</tr>

<tr>
<th>NOAUDIT</th>
<td>Suppresses the auditing of a specific error message.</td>
</tr>

<tr>
<th>NODUMP</th>
<td>Does not generate a dump </td>
</tr>

<tr>
<th>SNAP</th>
<td>Produces a SNAP</td>
</tr>

<tr>
<th>SNAPALL</th>
<td>Similar to <var>SNAP</var></td>
</tr>

<tr>
<th>SNAPPDL</th>
<td>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</td>
</tr>

<tr>
<th>SNAPSEL</th>
<td>Produces a SNAP similar to that of <var>SNAPPDL</var> along with additional specified output, such as table disk buffers</td>
</tr>
</table>

===Introducing message types===

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

The message types — <var>AD</var>, <var>ER</var>, <var>MS</var>, or <var>RK</var> — are mutually exclusive. Usually, the <var>ER</var> 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 <var>MSGCTL</var> 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 <var>MSGCTL</var> command options, you can manipulate the message type and whether the message is counted. Using the option:
<ul>
<li>With the <var>AUDIT</var>xx and <var>NOAUDIT</var>xx options, you can manipulate the type of message and where it appears in the audit trail. </li>

<li>With the <var>COUNT</var> or <var>NOCOUNT</var> option, you can manipulate whether the message counts toward the <var>ERMX</var> total. </li>
</ul>
Caution: Rocket Software strongly recommends the you do not apply the <var>NOCOUNT</var> option to messages that are part of SOUL compilation processing. Counting errors typically terminate the compilation process. In instances where you make compilation errors <var>NOCOUNT</var>, 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.
<table>

<tr class="head">
<th>Message type </th>
<th>Option applied </th>
<th>Reverts to...</th>
</tr>

<tr>
<td>AD </td>
<td>NOAUDITAD </td>
<td>MS</td>
</tr>

<tr>
<td>ER </td>
<td>NOAUDITER </td>
<td>RK</td>
</tr>

<tr>
<td>MS </td>
<td>NOAUDITMS </td>
<td>Not be audited (NOAUDIT)</td>
</tr>

<tr>
<td>RK </td>
<td>NOAUDITRK </td>
<td>AD</td>
</tr>
</table>

The <var>NOAUDIT</var>xx option processes only a message of type <var class="term">xx</var>. However, the <var>NOAUDIT</var> 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 <code>M204.1030 INVALID COMMAND</code> message, which is designed as a counted, <var>ER</var> type message. 
<ul>
<li>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. </li>

<li>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 (<var>ERMX</var>). However, it would still appear at the user terminal. </li>
</ul>

===Understanding MSGCTL command options===

====NOACTION option====

The <var>NOACTION</var> option suppresses almost all error message processing. When an error is generated, <var class="product">Model 204</var> checks an indicator flag to determine if that error message needs to be processed and whether the processing options have been changed via <var>MSGCTL</var> processing. If an error is found to have no processing requirements — that is, <var>NOACTION</var> — processing returns immediately to the next instruction. <var>NOACTION</var> has no effect on the following messages:
<ul>
<li>Counted messages that occur during compilation</li>

<li>Initialization, start up, and restart</li>

<li>Termination</li>
</ul>

The decreased number of instructions necessary to process the <var>NOACTION</var> option versus the <var>NOAUDIT</var> 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 <var>NOACTION</var> option of the <var>MSGCTL</var> 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 <var>NOACTION</var> option.

====AUDITxx options====

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

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

====NOAUDITxx options====

The <var>NOAUDIT</var>xx options function only for a message of that designated <var class="term">xx</var> type.
<table>
<tr class="head">
<th>Option </th>
<th>Changes message type </th>
<th>To message type </th>
</tr>

<tr>
<td>NOAUDITER </td>
<td>ER </td>
<td>RK</td>
</tr>

<tr>
<td>NOAUDITRK</td>
<td>RK</td>
<td>AD</td>
</tr>

<tr>
<td>NOAUDITAD </td>
<td>AD </td>
<td>MS</td>
</tr>

<tr>
<td>NOAUDITMS </td>
<td>MS </td>
<td>NOAUDIT</td>
</tr>
</table>

====Independent option assignment====

For example, message <code>M204.1030: INVALID COMMAND</code> is designated to be processed as both a counting error and an <var>ER</var> 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 <var>ERMX</var> 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 <code>RECURSIVE ENTRY TO ESTAE</code>, which would bring down the Online.

The parameters, <var>[[SNAPFAIL parameter|SNAPFAIL]]</var> and <var>[[SNAPLIM parameter|SNAPFLIM]]</var>, 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 <code>M204.1449</code> messages is sent to the operator and CCAJRNL or CCAJLOG, as well as saved in the <var>VIEW ERRORS</var> table. 
<ul>
<li>The following error message increases the value of <var>SNAPFAIL</var> by one:
M204.1449: ERROR WHILE PROCESSING CCASNAP
</li>

<li>The following error message indicated that snap formatting has been disabled, because the value of <var>SNAPFAIL</var> equals the value of <var>SNAPFLIM</var>:
M204.1449: ERROR WHILE PROCESSING CCASNAP, CCASNAPS DISABLED
</li>
</ul>

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 <code>SYSLST</code>. Output appears on the output report in the order in which it is generated.

===z/VM===

You can dynamically create a VMDUMP of the <var class="product">Model 204</var> service virtual machine using the z/VM Control Program VMDUMP command, if you detect a serious <var class="product">Model 204</var> 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 <var class="product">Model 204</var> <var>SNAPCTL</var> 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, <var class="product">Model 204</var> generates formatted SNAP information that augments the VMDUMP. 

You can define CCASNAP as one of the following: 
<ul>
<li>CMS file:
FILEDEF CCASNAP DISK ONLINE CCASNAP A
</li>

<li>Service machine virtual printer:
FILEDEF CCASNAP PRINTER
</li>
</ul>

Some <var class="product">Model 204</var> problems require a manual VMDUMP of the service virtual machine. The following command is required when <var class="product">Model 204</var> requests a VMDUMP:
VMDUMP 0-END DCSS SYSTEM FORMAT M204/CMS


You can omit the <code>DCSS</code> 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 (<code>#CP</code>). Dump the associated spool files to magnetic tape using the Control Program <code>SPTAPE</code> command after the <var class="product">Model 204</var> dump files are created. Submit the tape and any supporting documentation, such as the <var class="product">Model 204</var> audit trail, to [[Contacting Rocket Software Technical Support|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 <var class="product">Model 204</var> 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 <var class="product">Model 204</var> 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 <code>CCAMDMP0</code>, <code>CCAMDMP1</code>, and so on. The following rules apply to the use of CCAMDMP data sets:
<ul>
<li>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.</li>

<li>Use of tape data sets is not supported. The CCAMDMP data sets must be preallocated on disk devices.</li>

<li>If the CCAMDMP allocations are <code>DISP=SHR</code>, then you can clear, copy, or analyze any of the data sets without bringing down the <var class="product">Model 204</var> Online.</li>

<li>If an error occurs while allocating a CCAMDMP data set, allocation is not attempted again for the remainder of the run.</li>

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

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

<li>Note that CCAMDMP data sets must be allocated on single extents. </li>
</ul>

====Number of CCAMDMP data sets====

The optimum number of CCAMDMP data sets is normally equal to the value of the <var>[[SNAPLIM parameter|SNAPLIM]]</var> 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:
<table>
<caption>CCAMDMP DCB characteristics</caption>
<tr class="head">
<th>System</th>
<th>Organization</th>
<th>Record format</th>
<th>LRECL</th>
<th>BLKSIZE</th>
</tr>

<tr>
<td>z/OS</td>
<td>PS</td>
<td>FB or F</td>
<td align="right">4160</td>
<td align="right">4160</td>
</tr>
</table>

====Space allocation====

To estimate the space required for each CCAMDMP data set, add four megabytes to the size of the <var class="product">Model 204</var> 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 <var class="product">Model 204</var> 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 <var class="product">Model 204</var> run. An advisable setting for CCASNAP is <code>SNAPPDL</code>. 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. 

[[Category:System Manager]]