m204wiki - User contributions [en]

Using system statistics

2026-02-24T22:00:23Z

Goff: /* Description of statistics */

==Overview==

The tables on this page are provided for your use in identifying and tracking statistics that are reported by <var class="product">Model 204</var> in various situations. The offsets, given in decimal and hexadecimal, are to help you locate particular statistics within statistical output. The length is in bytes.

The statistics are collected in the [[Tracking_system_activity_(CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAJRNL|CCAJRNL]] data set, or if allocated, in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAAUDIT and CCAJLOG|CCAJLOG]]. The offsets in the tables below locate each statistic in the corresponding record. To accommodate sites that need to run <var class="product">Model 204</var> around the clock for many days at a time, space for most <var class="product">Model 204</var> statistics is a double word.

==Description of statistics==

The "Statistics with descriptions" table lists the statistics that are collected and that you can evaluate. It also describes the purpose of each statistic followed by the circumstances when you can collect the information and an offset in the journal record. 

To collect several statistics you must preset a parameter to a nonzero value. Statistics that require a parameter are also noted in the "Statistics with descriptions" table. The table in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Setting parameters to collect certain statistics]] lists those statistics with the required parameter. 

Tables, identified by type, later in this topic, describe the layouts of the various journal records.
<table>
<caption style="margin-right:4em">Statistics with descriptions</caption>
<tr class="head">
<th>Statistic </th>
<th>Records...</th>
</tr>

<tr>
<td>APSYLD</td>
<td>Number of APSY loads</td>
</tr>

<tr>
<td>APSYLDD</td>
<td>Number of APSY loads from a dataspace</td>
</tr>

<tr>
<td>APSYLDT</td>
<td>Number of tiny APSY loads</td>
</tr>

<tr>
<td>AUDIT</td>
<td>Number of lines written to the journal and/or the audit trail</td>
</tr>

<tr>
<td>BACKOUTS</td>
<td>Number of BACKOUTs</td>
</tr>

<tr>
<td>BADD</td>
<td>Number of fields added to Table B</td>
</tr>

<tr>
<td>BCHG</td>
<td>Number of fields changed in Table B</td>
</tr>

<tr>
<td>BDEL</td>
<td>Number of fields deleted from Table B</td>
</tr>

<tr>
<td>BLKCFRE</td>
<td>Number of times user held a critical file resource (CFR) exclusively and forced another user to wait

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKI</td>
<td>Percentage of performance samples at which the user was in a server but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKO</td>
<td>Percentage of performance samples at which the user was swapped out to the server data set but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKRLK</td>
<td>Number of times user was the first user identified as blocking another from obtaining a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BXCHNG</td>
<td>Number of value entries changed in the ordered index. This occurs when a record number is added to or removed from an existing value entry.</td>
</tr>

<tr>
<td>BXDELE</td>
<td>Number of value entries deleted from the ordered index</td>
</tr>

<tr>
<td>BXFIND</td>
<td>Number of ordered index searches to locate field name=value pairs in the ordered index</td>
</tr>

<tr>
<td>BXFREE</td>
<td>Number of ordered index pages (nodes) emptied and released from the ordered index</td>
</tr>

<tr>
<td>BXINSE</td>
<td>Number of new value entries inserted into the ordered index</td>
</tr>

<tr>
<td>BXNEXT</td>
<td>Number of value entries touched in the ordered index during a range retrieval</td>
</tr>

<tr>
<td>BXRFND</td>
<td>Number of times the cursor was repositioned in the ordered index during a search</td>
</tr>

<tr>
<td>BXSPLI</td>
<td>Number of Table D pages (nodes) split in the ordered index</td>
</tr>

<tr>
<td>CCATDIFF</td>
<td>Difference between CCATEMP pages allocated and freed by a thread. This is an imperfect indicator of the number of CCATEMP pages a thread has allocated. CCATDIFF is imperfect because it is difficult to fully account for pages allocated or freed on behalf of the system or other users. However, if there is an acute CCATEMP page shortage, threads with high CCATDIFF values are likely culprits.

CCATDIFF is available in Model 204 7.7 and higher.</td>
</tr>

<tr>
<td>CCATDIFH</td>
<td>High water mark of CCATDIFF in a request. This can be useful if a request allocated a lot of CCATEMP pages, causing an acute shortage but then freed those pages.

CCATDIFH is available in Model 204 7.7 and later.</td>
</tr>

<tr>
<td>CDLWAIT</td>
<td>Number of constraint dependency lock waits</td>
</tr>

<tr>
<td>CNCT</td>
<td>Elapsed time in seconds</td>
</tr>

<tr>
<td>COMMITS</td>
<td>Number of <var>COMMIT</var>s</td>
</tr>

<tr>
<td>CPU</td>
<td>Total CPU time consumed in milliseconds. The system CPU statistics include both maintask and subtask CPU usage.</td>
</tr>

<tr>
<td>CPUONZIP</td>
<td>Total CPU time consumed in milliseconds on zIIP engines</td>
</tr>

<tr>
<td>CPUTOTZE</td>
<td>Total CPU time consumed in milliseconds by workloads eligible for offload to zIIP engines</td>
</tr>

<tr>
<td>DEQ</td>
<td>Total number of units of work taken by the MAINTASK and each MP and zIIP subtask, regardless of the queue that the work was taken from. Reported at <var class="product">Model 204</var> termination or in <var>[[MONITOR TASKS command|MONITOR TASKS]]</var> output.

(type Subtask)
</td>
</tr>

<tr>
<td>DEV#</td>
<td>used the MXI interface to hold the IODEV type ( e.g. 7 for IODEV7 )</td>
</tr>

<tr>
<td>DEV5</td>
<td>Output lines to procedures defined during the run</td>
</tr>

<tr>
<td>DEV6</td>
<td>Input lines from included procedures</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly VTAM) 3270s</td>
</tr>

<tr>
<td>DEV8</td>
<td>Input lines from SNA Communications Server 3270s</td>
</tr>

<tr>
<td>DEV9</td>
<td>Page headers or trailers defined in requests</td>
</tr>

<tr>
<td>DEV10</td>
<td>Output lines written to directed output (USE) data sets</td>
</tr>

<tr>
<td>DEV11</td>
<td>Output lines to remote User Language full screen</td>
</tr>

<tr>
<td>DEV12</td>
<td>Input lines from a remote User Language full screen</td>
</tr>

<tr>
<td>DEV13</td>
<td>Output lines to remote SQL</td>
</tr>

<tr>
<td>DEV14</td>
<td>Input lines from remote SQL</td>
</tr>

<tr>
<td>DEV17</td>
<td>Output lines to SQL CRAM IUCU</td>
</tr>

<tr>
<td>DEV18</td>
<td>Input lines from SQL CRAM</td>
</tr>

<tr>
<td>DEV19</td>
<td>Output lines to remote SQL LU62</td>
</tr>

<tr>
<td>DEV20</td>
<td>Input lines from remote SQL LU62</td>
</tr>

<tr>
<td>DEV23</td>
<td>Input lines to CRAM IFAM</td>
</tr>

<tr>
<td>DEV24</td>
<td>Input lines from CRAM IUCU thread</td>
</tr>

<tr>
<td>DEV27</td>
<td>Terminal error messages issued for inbound Distributed Application Facility conversations</td>
</tr>

<tr>
<td>DEV28</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV31</td>
<td><var>IFDISP</var> output lines to IFAM1 programs</td>
</tr>

<tr>
<td>DEV32</td>
<td>Input arguments supplied by certain IFAM1 calls</td>
</tr>

<tr>
<td>DEV37</td>
<td>Output lines to SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV38</td>
<td>Input lines from SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV49</td>
<td>output lines to Remote Command line applications( rate or total)</td>
</tr>

<tr>
<td>DEV50</td>
<td>Lines sent to the printer when ROUTER=CICS</td>
</tr>

<tr>
<td>DEV53</td>
<td>Output lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV54</td>
<td>Input lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV55</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV56</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV57</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV58</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV59</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV60</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV61</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV62</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV63</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM parameter|MONPARM]] system parameter.</td>
</tr>

<tr>
<td>DEV64</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV65</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV66</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV67</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV68</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV69</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly
VTAM) 3270s</td>
</tr>

<tr>
<td>DEV70</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV71</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV72</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV73</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV74</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DIRRCD</td>
<td>Number of records searched in direct searches of Table B</td>
</tr>

<tr>
<td>DKAR</td>
<td>Number of buffers allocated without page read requests</td>
</tr>

<tr>
<td>DKPR</td>
<td>Number of requests for a page (may not require real I/O)</td>
</tr>

<tr>
<td>DKPRF</td>
<td>Number of fast logical page reads. Number of DKPRs that were satisfied by pending or deferred close buffers</td>
</tr>

<tr>
<td>DKRD</td>
<td>Number of physical page reads from Model 204 files</td>
</tr>

<tr>
<td>DKRDL</td>
<td>Number of physical page reads into the below the bar buffer pool</td>
</tr>

<tr>
<td>DKRR</td>
<td> Number of real disk reads for recently requested pages
</td>
</tr>

<tr>
<td>DKSAWB</td>
<td> Anticipatory writes from the bottom of the LRU queue. The page in the buffer is then deleted and no longer available without a re-read. Usually a small statistic and typically only incremented by a few rare events.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWBL</td>
<td> Same as DKSAWB but only incremented for anticipatory writes from below the bar

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWW</td>
<td> Anticipatory writes from the anticipatory write windows set by LDKBMWND and/or LDKBMWNG

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWWL</td>
<td>Same as DKSAWW but only incremented for anticipatory writes from below the bar</td>
</tr>

<tr>
<td>DKSDIR</td>
<td> High-water mark of modified (dirty) buffers found within the DKBM statistics window which is created by the <var>LDKBMW</var> parameter. This parameter is not recommended due to the extremely heavy performance penalty imposed by a non-zero value.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSDIRT</td>
<td> The total of all modified buffers found within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSFBS</td>
<td> Times a buffer was needed, and a scan was necessary, because the oldest free buffer was not immediately available

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIP</td>
<td> The highest number of buffers skipped during any search for a free buffer. A buffer is skipped because it is not immediately available.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIPT</td>
<td> The total of all buffers skipped when looking for a free buffer

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRR</td>
<td> Number of times a page that was expected to be in the buffer pool could not be located, which necessitates a physical I/O to disk

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRRFND</td>
<td>Number of times that a page that was expected to be in the buffer pool was located there, which eliminates the need for a physical I/O</td>
</tr>

<tr>
<td>DKSTBLA</td>
<td> Table A reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLB</td>
<td> Table B reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLC</td>
<td> Table C reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLD</td>
<td> Table D reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DSKTBLE</td>
<td> Table E reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLF</td>
<td> FCT reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTKQC</td>
<td> Times the current Table B page had to be closed to allow a fourth buffer to be opened

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSWRP</td>
<td> The highwater mark of buffers with writes outstanding within the DKBM statistics window, created by the parameter LDKBMW. Rocket Software advises against setting this parameter to a non-zero value due to the extreme performance penalty imposed.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSWRPT</td>
<td> The total number of buffers with outstanding writes within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKUPTIME</td>
<td>Milliseconds of DKUPDT time</td>
</tr>

<tr>
<td>DKWR</td>
<td>Number of physical page writes to <var class="product">Model 204</var> files</td>
</tr>

<tr>
<td>DKWRL</td>
<td>Number of physical page writes from the below the bar pool</td>
</tr>

<tr>
<td>DKWTMICS</td>
<td>Total wait time in microseconds for Disk I/O waits counted by DKWTS.
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DKWTS</td>
<td>Number Disk I/O waits
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DUMP</td>
<td>Writes to <var class="product">Model 204</var> file backups (DUMP command output)</td>
</tr>

<tr>
<td>DUPDTS</td>
<td>Records written to a deferred update data set for the file</td>
</tr>

<tr>
<td>ECCALL</td>
<td>Number of External Call Facility calls</td>
</tr>

<tr>
<td>ECCNCT</td>
<td>External Call Facility - Elapsed time for external program</td>
</tr>

<tr>
<td>ECCTOUT</td>
<td>Number of External Call Facility calls that timed out (program or subtask unavailable)</td>
</tr>

<tr>
<td>ECCWAITM</td>
<td>ECF – Number of calls that waited for module to become available</td>
</tr>

<tr>
<td>ECCWAITS</td>
<td>Number of External Call Facility calls that waited for a subtask to become available</td>
</tr>

<tr>
<td>ECDELETE</td>
<td>Number of EXTERNAL DELETE calls to External Call Facility</td>
</tr>

<tr>
<td>ECLOAD</td>
<td>Number of EXTERNAL LOAD calls to External Call Facility</td>
</tr>

<tr>
<td>ECMODMAX</td>
<td>ECF – Highwater mark of modules loaded</td>
</tr>

<tr>
<td>ECNAMMAX</td>
<td>External Call Facility – High-water mark of call names defined</td>
</tr>

<tr>
<td>ECTSKMAX</td>
<td>External Call Facility – High-water mark of subtasks active</td>
</tr>

<tr>
<td>ECTWAITM</td>
<td>External Call Facility – Elapsed time spent waiting for a module to become available</td>
</tr>

<tr>
<td>ECTWAITS</td>
<td>External Call Facility – Elapsed time spent waiting for a subtask to become available</td>
</tr>

<tr>
<td>ERRPDL</td>
<td>Highwater mark of the system pushdown list</td>
</tr>

<tr>
<td>FBMX</td>
<td>Disk buffer HWM
Obsolete from V7.8, see: [[Release_notes_for_Model_204_version_7.8#BUF_and_FBMX_stats_removed|Model 204 V7.8 Release Notes, BUF and FBMX stats removed]].
</td>
</tr>

<tr>
<td>FBWT</td>
<td>Number of waits for a disk buffer</td>
</tr>

<tr>
<td>FINDS</td>
<td>Number of FIND statements evaluated</td>
</tr>

<tr>
<td>FSCB</td>
<td>High-water mark of bytes used in the FSCB</td>
</tr>

<tr>
<td>FSCBSW</td>
<td>Number of full-screen buffer swaps</td>
</tr>

<tr>
<td>FTBL</td>
<td>Highwater mark of FTBL appearing in CMPL and EVAL lines for requests containing a field name reference in group context. If one or more groups are opened but no field name references are made, the portion of FTBL used by the open groups is not reported.</td>
</tr>

<tr>
<td>GTBL</td>
<td>Highwater mark of GTBL</td>
</tr>

<tr>
<td>GTBLRS</td>
<td>Number of GTBL rearrangements required to add a global object</td>
</tr>

<tr>
<td>GTBLRU</td>
<td>Number of GTBL rearrangements required to add a global string variable</td>
</tr>

<tr>
<td>HEAP</td>
<td>Dynamic memory highwater mark</td>
</tr>

<tr>
<td>HRDRSTRT</td>
<td>number of hard restarts</td>
</tr>

<tr>
<td>IMGCBYTR</td>
<td>Number of bytes of data received from Imagine Transparency brokers for calls to non-transparency code running on the broker (rate or total). The calls can be for transpiled SOUL or COBOL code, or service programs</td>
</tr>

<tr>
<td>IMGCBYTS</td>
<td>Number of bytes of data sent to Imagine Transparency brokers for for calls to non-transparency code running on the broker (rate or total). The calls can be for transpiled SOUL or COBOL code, or IMGCBYTS service programs</td>
<tr>

<tr>
<td>IMGCCPU</td>
<td>Number of seconds of CPU used by Imagine Transparency brokers for calls to non-transparency code running on the broker (rate or total). The calls can be for transpiled SOUL or COBOL code, or service programs</td>
</tr>

<tr>
<td>IMGCREQ</td>
<td>Number of requests sent from M204 to a broker for calls to non-transparency code running on the brokers (rate or total). This is essentially the number of interactions between M204 and the brokers for non-transparency processing (transpiled code and service programs)</td>
</tr>

<tr>
<td>IMGCWT</td>
<td>Number of seconds spent by M204 waiting for a response from the Imagine Transparency brokers for non-transparency requests (transpiled code and service programs) (rate or total). IMGCWT is composed of IMGCCPU (CPU time used on the broker), IMGCWTD (time the broker spent waiting for the Imagine DatabaseStore, mostly for finds and commits), and everything else. The most likely cause of "everything else" is network delays</td>
</tr>

<tr>
<td>IMGCWTD</td>
<td>Number of seconds spent by Imagine Transparency brokers waiting for the Imagine DatabaseStore for non-transparency requests (transpiled code and service programs), mostly for finds and commits (rate or total)</td>
</tr>

<tr>
<td>IMGTBYTR</td>
<td>Number of bytes of data received from Imagine Transparency brokers for transparency requests (rate or total)</td>
</tr>

<tr>
<td>IMGTBYTS</td>
<td>Number of bytes of data sent to Imagine Transparency brokers for transparency requests (rate or total)</td>
</tr>

<tr>
<td>IMGTCPU</td>
<td>Number of seconds of CPU used by Imagine Transparency brokers for transparency requests (rate or total)</td>
</tr>

<tr>
<td>IMGTFDH</td>
<td>Number of finds against Imagine files that could be serialized for duplicate find testing and a duplicate find was found (rate or total). Since Imagine guarantees identical results for identical finds in the same transaction (if no candidate files were updated) the result of the previous find can be used in the case of a duplicate, eliminating an interaction with the broker and all the overhead that entails. The H in IMGTFDH stands for Hits. It can be useful to compare IMGTFDH with IMGTFND (finds sent to the broker) to determine the percentage of finds that were essentially optimized away as duplicates</td>
</tr>

<tr>
<td>IMGTFDS</td>
<td>Number of finds against Imagine files that could be serialized for duplicate find testing (rate or total). A find might not be serializable if it is too complicated or references too many files (in a group). Any find that can't be serialized must be sent to the broker to be processed, even if an identical find has already been done in the same transaction</td>
</tr>

<tr>
<td>IMGTFDU</td>
<td>Number of finds against Imagine files that could be serialized for duplicate find testing, and a duplicate find was found, but could not be used because one or more files in the find had been updated since the previous find (rate or total). In such a case, the find must be sent to the broker to be reprocessed</td>
</tr>

<tr>
<td>IMGTFND</td>
<td>Number of finds against Imagine files that were sent to the broker to be processed (rate or total). This does not include duplicate finds whose results could be reused on M204 (counted by IMGTFDH)</td>
</tr>

<tr>
<td>IMGTREC</td>
<td>Number of Imagine records sent from the broker to M204 (rate or total). This includes "prefetched" records that are counted by IMGTRECP</td>
</tr>

<tr>
<td>IMGTRECP</td>
<td>Number of Imagine records sent from the broker to M204 before they were explicitly accessed (like in a FOR RECORD LOOP), so "prefetched". One example of this is that after a find on the
broker, the first IMGPREF (user parameter) records would be sent back to M204 with the find results</td>
</tr>

<tr>
<td>IMGTREQ</td>
<td>Number of requests sent from M204 to a broker for transparency processing (rate or total). This is essentially the number of interactions between M204 and the brokers for transparency
processing</td>
</tr>

<tr>
<td>IMGTWT</td>
<td>Number of seconds spent by M204 waiting for a response from the Imagine Transparency brokers for transparency requests (rate or total). IMGTWT is composed of IMGTCPU (CPU time used on the broker), IMGTWTD (time the broker spent waiting for the Imagine DatabaseStore, mostly for finds and commits), and everything else. The most likely cause of "everything else" is network delays</td>
</tr>

<tr>
<td>IMGTWTD</td>
<td>Number of seconds spent by Imagine Transparency brokers waiting for the Imagine DatabaseStore for transparency requests, mostly for finds and commits (rate or total)</td>
</tr>

<tr>
<td>IN</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>INCMFS</td>
<td>Input lines from CMS full screen</td>
</tr>

<tr>
<td>INCMIO</td>
<td>Input lines from CMS non-full screen</td>
</tr>

<tr>
<td>INCRAM</td>
<td>Input lines from Remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>INVMFS</td>
<td>Input lines from IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>INVMIF</td>
<td>Input arguments supplied by certain IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>INVMIO</td>
<td>Input lines from IUCV or VMCF non-full screen thread</td>
</tr>

<tr>
<td>INXX</td>
<td>Input lines from QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>ITBL</td>
<td>Highwater mark of ITBL</td>
</tr>

<tr>
<td>IXADD</td>
<td>Number of index entries added to Tables C and D, including attempts to add duplicates</td>
</tr>

<tr>
<td>IXDEL</td>
<td>Number of entries deleted from Tables C and D</td>
</tr>

<tr>
<td>JSCREENS</td>
<td>Counts the number of times Janus Web incremented the SCREENS statistic. Since these may occur outside of request context, they would not necessarily have corresponding Since-Last statistics.</td>
</tr>

<tr>
<td>JWEBERRS</td>
<td>Counts the number of times that Janus Web returned a 4xx status code. Note that these would not be counted in the SCREENS statistic, but it is handy to know that for example a bunch of 404 or 401 errors are occurring.</td>
</tr>

<tr>
<td>LKPOST</td>
<td>Times an MP subtask posted another task to indicate that an MP lock had become available</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>Times MP subtasks invoked z/OS WAIT macros to wait for an available MP lock</td>
</tr>

<tr>
<td>LONGUPDTIME(MS)</td>
<td> Total milliseconds of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LONGUPDTS</td>
<td> Number of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LWTIM</td>
<td>Elapsed time (ms), spent waiting for a multiprocessing lock. Reported for each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals).</td>
</tr>

<tr>
<td>MAXIOX</td>
<td>Number of times <var class="product">Model 204</var> waited for a free database buffer</td>
</tr>

<tr>
<td>MBO</td>
<td>Highwater mark of transaction backout pages

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MCP
</td>
<td>Highwater mark of transaction checkpoint spans

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MOVE</td>
<td>Number of times the scheduler switched from one user to another</td>
</tr>

<tr>
<td>MPHASHD</td>
<td>MP duplicate hash entries found</td>
</tr>

<tr>
<td>MPLKPREM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting due to operating system preemption.

This is the elapsed time between when an MP lock becomes available (lock post) making a task ready to run, and when the task actually gets the CPU. That preemption delay is caused by the operating system dispatching other tasks ahead of this task.

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPLKWTIM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting for MP locks

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPR</td>
<td>Highwater mark of transaction pre-images

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MQAPICNT</td>
<td>MQ/204 – Count of MQ/Series API calls</td>
</tr>

<tr>
<td>MQAPITIM </td>
<td>MQ/204 – Elapsed time of MQSeries API calls</td>
</tr>

<tr>
<td>MQBYTEIN</td>
<td>MQ/204 – Total bytes retrieved (MQGET)</td>
</tr>

<tr>
<td>MQBYTEOU</td>
<td>MQ/204 – Total bytes sent (MQPUT/MQPUT1)</td>
</tr>

<tr>
<td>MQGETS</td>
<td>MQ/204 – Number of MQGETs performed</td>
</tr>

<tr>
<td>MQGWTCNT</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTSUC</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait that succeeded</td>
</tr>

<tr>
<td>MQGWTTIM</td>
<td>MQ/204 – Elapsed time for MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTTSP</td>
<td>MQ/204 – Total wait time specified on MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQHWQU</td>
<td>MQ/204 – High-water mark of queues concurrently in use</td>
</tr>

<tr>
<td>MQHWTASK</td>
<td>MQ/204 – High-water mark of MQ/204 subtasks in use</td>
</tr>

<tr>
<td>MQNUMQM</td>
<td>MQ/204 – Number of distinct queue managers connected</td>
</tr>

<tr>
<td>MQNUMQU</td>
<td>MQ/204 – Number of distinct queues accessed</td>
</tr>

<tr>
<td>MQPUTS</td>
<td>MQ/204 – Number of MQPUTs performed</td>
</tr>

<tr>
<td>MQWTM</td>
<td>Mean queue wait time, the average time a subtask spent waiting for work (waiting for PCBs to come into the offload queue)</td>
</tr>

<tr>
<td>MTDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from the MAINTASK queue and processed it</td>
</tr>

<tr>
<td>MTSDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from an MP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>MTZDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from a zIIP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>NTBL</td>
<td>Highwater mark of NTBL</td>
</tr>

<tr>
<td>OBJSWAP</td>
<td>number of object swaps for Sirius objects</td>
</tr>

<tr>
<td>OFFIN</td>
<td>Count of records read in by the OFFLOAD subtask</td>
</tr>

<tr>
<td>OFFOU</td>
<td>Count of records written to the OFFLOAD stream</td>
</tr>

<tr>
<td>OUT</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>OUTCMFS</td>
<td>Output lines to CMS full-screen thread</td>
</tr>

<tr>
<td>OUTCMIO</td>
<td>Output lines to CMS line-by-line thread</td>
</tr>

<tr>
<td>OUTCRAM</td>
<td>Output lines from remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>OUTPB</td>
<td>Highwater mark of OUTPB</td>
</tr>

<tr>
<td>OUTVMFS</td>
<td>Output lines to IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>OUTVMIF</td>
<td>Output lines to IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>OUTVMIO</td>
<td>Output lines to IUCV or VMCF line-by-line threads</td>
</tr>

<tr>
<td>OUTXX</td>
<td>Output lines to QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>PBRSFLT</td>
<td>Number of private buffer reservation faults</td>
</tr>

<tr>
<td>PCPU</td>
<td>Percentage of time <var class="product">Model 204</var> was given the CPU when it wanted CPU time. In an MP environment, system PCPU is the sum of CPU time in all tasks divided by the sum of elapsed time in all tasks.</td>
</tr>

<tr>
<td>PDL</td>
<td>Highwater mark of the pushdown list</td>
</tr>

<tr>
<td>PETIM</td>
<td>Elapsed time (ms), spent waiting due to OS preemption. Reported for the MAINTASK and each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals)</td>
</tr>

<tr>
<td>PNDGTIME</td>
<td>Milliseconds of unnecessary broken time</td>
</tr>

<tr>
<td>PR</td>
<td>Real time consumed, in milliseconds. PCPU = CPU / PR.</td>
</tr>

<tr>
<td>QTBL</td>
<td>Highwater mark of QTBL</td>
</tr>

<tr>
<td>RCV</td>
<td>Number of blocks needed for subtransaction recovery

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>RECADD</td>
<td>Number of records started in Table B, not including extension records</td>
</tr>

<tr>
<td>RECDEL</td>
<td>Number of records deleted from Table B, not including extension records or records deleted by DELETE RECORDS or IFDSET</td>
</tr>

<tr>
<td>RECDS</td>
<td>Number of records processed by FOR statements, SORT statements, IFGET calls, or IFPOINT calls, or similar SQL record processing</td>
</tr>

<tr>
<td>REDY</td>
<td> Percentage of performance samples at which the user was ready to run (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>REQ</td>
<td>Number of SOUL requests evaluated</td>
</tr>

<tr>
<td>REST</td>
<td>Number of reads from a <var class="product">Model 204</var> file backup (<var>RESTORE</var> command)</td>
</tr>

<tr>
<td>RETRYA</td>
<td>Page retries in Table A</td>
</tr>

<tr>
<td>RETRYC</td>
<td>Page retries in Table C</td>
</tr>

<tr>
<td>RQTM</td>
<td>Elapsed time for the activity being reported, exclusive of terminal I/O time</td>
</tr>

<tr>
<td>RSXCOMP</td>
<td>Number of compactions of the record locking table. If greater than 0, increase <var>LRETBL</var>.</td>
</tr>

<tr>
<td>RUNG</td>
<td> Percentage of performance samples at which the user was running (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SCHDCPU</td>
<td>In MP configuration, total scheduler CPU for the user or request</td>
</tr>

<tr>
<td>SCREENS</td>
<td>Total number of full-screen reads (<var>READ SCREEN</var> statements) evaluated by a SOUL request.</td>
</tr>

<tr>
<td>SFTRSTRT</td>
<td>number of soft restarts.</td>
</tr>

<tr>
<td>SGMTI</td>
<td>Number of input lines from included procedures</td>
</tr>

<tr>
<td>SGMTO</td>
<td>Number of output lines to procedures defined by the user</td>
</tr>

<tr>
<td>SLIC</td>
<td>Number of times that the user was time-sliced by the <var class="product">Model 204</var> scheduler</td>
</tr>

<tr>
<td>SMPLS</td>
<td>Number of performance sample points at which the user was active or total number of performance samples taken at the system level (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SORTS</td>
<td>Number of SOUL <var>SORT</var> statements or SQL sorts evaluated</td>
</tr>

<tr>
<td>SQLI</td>
<td>Remote SQL input highwater mark</td>
</tr>

<tr>
<td>SQLO</td>
<td>Remote SQL output highwater mark</td>
</tr>

<tr>
<td>SQRD</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>SQWR</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>STBL</td>
<td>Highwater mark of STBL</td>
</tr>

<tr>
<td>STCPU</td>
<td>Total amount of time, in milliseconds, that the user has run in an MP offload subtask</td>
</tr>

<tr>
<td>STDEQ</td>
<td>Number of times that an MP subtask took a unit of work from an MP subtask queue and processed it</td>
</tr>

<tr>
<td>STIMERS</td>
<td>Total number of STIMER or STIMERM calls</td>
</tr>

<tr>
<td>STPOST</td>
<td>Times MP subtasks performed real operating system POSTs to send work to the maintask</td>
</tr>

<tr>
<td>STRECDS</td>
<td>Number of records processed by SORT statements or SQL sorts</td>
</tr>

<tr>
<td>STWAIT</td>
<td>Number of times MP subtasks invoked z/OS WAIT macros to wait for work from the maintask</td>
</tr>

<tr>
<td>STZDEQ</td>
<td>Number of times that an MP subtask took a unit of work from a zIIP subtask queue and processed it because the MP subtask was idle</td>
</tr>

<tr>
<td>SVAC</td>
<td>Active servers (an average, included on a performance line)</td>
</tr>

<tr>
<td>SVMX</td>
<td>Highwater mark for servers (0 if no server swapping)</td>
</tr>

<tr>
<td>SVPAGES</td>
<td><code>SVPAGES * 4096</code> is the number of bytes transferred as a result of server reads and writes</td>
</tr>

<tr>
<td>SVRD</td>
<td>Number of server reads</td>
</tr>

<tr>
<td>SVWR</td>
<td>Number of server writes</td>
</tr>

<tr>
<td>SWPG</td>
<td>Percentage of performance samples at which the user was swapping in or out (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>SWT</td>
<td>Times <var class="product">Model 204</var> issued a real WAIT while not in user-switching mode</td>
</tr>

<tr>
<td>TEMX</td>
<td>Highwater mark of CCATEMP pages used in the expansion area</td>
</tr>

<tr>
<td>TFMX</td>
<td>Highwater mark of CCATEMP pages used</td>
</tr>

<tr>
<td>TSMX</td>
<td>Highwater mark of CCATEMP pages used in the small model page pool</td>
</tr>

<tr>
<td>TTBL</td>
<td>Highwater mark of TTBL</td>
</tr>

<tr>
<td>UBUFHWS</td>
<td>Highwater mark, in bytes, of user's Universal Buffer</td>
</tr>

<tr>
<td>UDD</td>
<td>Number of lines written to a directed output (<var>USE</var>) data set</td>
</tr>

<tr>
<td>UPDTTIME(MS)</td>
<td>Number of milliseconds that a file was being updated

UPT(MS) appears as the column header for this statistic on a report
</td>
</tr>

<tr>
<td>UPDTTIME</td>
<td>Number of milliseconds that the user was actively updating at least one file</td>
</tr>

<tr>
<td>USMX</td>
<td>Highwater mark for simultaneous active users (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>USRS</td>
<td>Average number of active users (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>VTBL</td>
<td>Number of VTBL entries at the end of compilation (CMPL) processing or the end of evaluation (EVAL) processing</td>
</tr>

<tr>
<td>WAIT</td>
<td>Number of real operating system waits</td>
</tr>

<tr>
<td>WTCFR</td>
<td>Number of times that the user waited to obtain a critical file resource, either share or exclusive

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTRLK</td>
<td>Number of times that the user waited to obtain a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTSV</td>
<td>Percentage of performance samples at which the user was waiting for a server (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>XTBL</td>
<td>Highwater mark of XTBL</td>
</tr>

<tr>
<td>ZTCPU</td>
<td>The CPU (ms) consumed on a zIIP processor by the MAINTASK, an MP subtask or a zIIP subtask. Reported for each task at <var class="product">Model 204</var> termination and in <var>MONITOR TASKS</var> output (for Model 5 terminals only)</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>The number of times that a zIIP subtask took a unit of work from a zIIP subtask queue and processed it</td>
</tr>
</table>

==Header and trailer entries (Type 0)==

Each journal block begins with a header record and ends with a trailer record.

===Header entries (Type 0)===

Header entries have the format shown in the following table: 
<table>
<caption style="margin-right:6em">Header entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entire journal record, including header and trailer</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Flags used by recovery</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH </td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">4</td>
<td>Binary</td>
<td> Sequence number </td>
</tr>

<tr>
<td>16(10)</td>
<td align="right">10</td>
<td>Binary</td>
<td> System Store Clock Extended (STCKE) value to provide picosecond accuracy on the journal date/time stamp

Bytes 1-9 || byte 16 
</td>
</tr>

<tr>
<td>26(1A)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of header, type 00</td>
</tr>

<tr>
<td>28(1C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Version in hex</td>
</tr>

<tr>
<td>30(1E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Version in EBCDIC</td>
</tr>

<tr>
<td>38(26)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Job name</td>
</tr>

<tr>
<td>46(2E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>JES Job ID</td>
</tr>

<tr>
<td>54(36)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>SMF System ID</td>
</tr>
</table>
<ul>
<li>If the flag byte at offset 3 of type 00 has the X'02' bit on, then it is a header record from <var class="product">Model 204</var> version 7.4.0 or later with its length at offset X'1A'.</li>

<li>If that flag byte has the X'01' bit on, then the header is from version 7.1.0 and is 26 bytes in length. </li>

<li>If neither of those bits is on, then the header is a from a pre-7.1.0 version and is 16 bytes in length.</li>
</ul>

===Recovery flags===

Flags used by recovery can have the value of X'00' or a sum of any of the following: 
<table>
<tr class="head">
<th>Value</th>
<th>Block contains these records...</th>
</tr>

<tr>
<td>X'80'</td>
<td>Type 1</td>
</tr>

<tr>
<td>X'40'</td>
<td>Type 2</td>
</tr>

<tr>
<td>X'20'</td>
<td>Type 3</td>
</tr>

<tr>
<td>X'10'</td>
<td>Type 4</td>
</tr>

<tr>
<td>X'08'</td>
<td>Type 5</td>
</tr>

<tr>
<td>X'04'</td>
<td>Type 6</td>
</tr>
</table>

===Sequence numbers===

The sequence number represents the number of each journal record, starting at 0 and increasing by 1. A merged journal (output of the MERGEJ utility) sequence number consists of a 2-byte hexadecimal number at offset 12(0C), which indicates the input file this journal record came from, and a 2-byte hexadecimal field at offset 14(0E), which indicates the sequence within the INPUT journal.

===Trailer entries (Type 0)===

Trailer entries have the format shown in the following table: 
<table>
<caption>Trailer entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data </td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Recovery entries (Types 1-6)==

Entry types X'01' through X'06' contain information used for recovery. They follow the same general format as all other journal entries. There is no type X'07' journal entry. 

The format of the recovery entries is meaningful only in the context of the <var class="product">Model 204</var> ROLL FORWARD algorithm. However, entry types might be of interest in some statistics gathering applications, as follows: 
<table>
<tr class="head">
<th>Type </th>
<th>Contains recovery information from...</th>
</tr>

<tr>
<td>1 </td>
<td>Discontinuity</td>
</tr>

<tr>
<td>2 </td>
<td> Begin update unit.

More than one type 2 entry can be written for each update unit. The update unit number appears as a 4-byte binary number at offset 16(10).
</td>
</tr>

<tr>
<td>3 </td>
<td> End update unit.

The update unit number appears in the same format and location as the type 2 entry.
</td>
</tr>

<tr>
<td>4</td>
<td>File state information: opened, closed, dumped, file parameter list (FPL) page preimage logged or open at the time of a checkpoint</td>
</tr>

<tr>
<td>5 </td>
<td>Checkpoint</td>
</tr>

<tr>
<td>6 </td>
<td>File update </td>
</tr>
</table>

==System statistics entries (Type 8)==

Cumulative statistics, listed by offset in the [[#System performance statistics|Layout of system subtype X'02' entries]] table, are kept for the entire system. Final, partial, and performance system statistics are written to the journal during <var class="product">Model 204</var> termination in a line that begins with:
ST $$$ SYSTEM='version#'


For additional information about:
<ul>
<li>Using system statistics for performance monitoring, see [[Performance monitoring and tuning]]. </li>

<li>Disk buffer monitor statistics and parameters, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </li>
</ul>

===Final statistics===

The system final statistics line, similar to the following, is produced as part of system termination: 
ST $$$ SYSTEM='5A 'AUDIT=43 OUT=38 IN=14 WAIT=19 ...


===Partial statistics===

Statistics in a system partial statistics line, similar to the following, accumulate from the beginning of the run, if the User 0 <var>[[ACCTIM parameter|ACCTIM]]</var> parameter is nonzero: 
ST $$$ SYSTEM='6.1.0'PARTIAL=3 AUDIT=19 OUT=10 IN=5 WAIT=3 ...


===Performance statistics===

System performance statistic lines, similar to the following, are written if the User 0 <var>[[RPTCNT parameter|RPTCNT]]</var> and <var>[[SMPLTIM parameter|SMPLTIM]]</var> parameters are nonzero: 
ST $$$ SYSTEM='6.1.0' PERFORMANCE=n


The numbers determined at the performance sample points are averaged for the entire run. 

===Entry formats===

System statistics entries have the format shown in the following table: 
<table>
<caption>System statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'08'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:

X'00' = final statistics

X'01' = partial statistics

X'02' = performance statistics

X'04' = additional disk buffer monitor

X'08' = subtask statistics
</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Subtask number if subtype = X'08'; otherwise unused</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Unused</td>
</tr>

<tr>
<td>16(10) to end of journal</td>
<td align="right"> — </td>
<td align="right"> — </td>
<td>

Contents depend on subtypes, shown in tables in the following sections:
<ul>
<li>[[#System final and partial statistics|System final and partial statistics]]</li>

<li>[[#System performance statistics|System performance statistics]]</li>

<li>[[#Additional disk buffer monitor statistics|Additional disk buffer monitor statistics]]</li>

<li>[[#User since-last statistics|User since-last statistics]]</li>
</ul>
</td> </tr>
</table>

==System final and partial statistics==

For subtypes X'00' (final statistics) and X'01' (partial statistics), the layout of the remainder of the entry is shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
The following statistics are data type Binary. However, the length varies — either 4 or 8, to accommodate 64-bit system architecture. 
<table>
<caption>System final and partial statistics</caption>
<tr class="head">
<th>Offset dec(hex) </th>
<th>Length </th>
<th>Description</th>
</tr>

<tr>
<td>16(10) </td>
<td>8 </td>
<td>AUDIT</td>
</tr>

<tr>
<td>24(18) </td>
<td>8 </td>
<td>OUT</td>
</tr>

<tr>
<td>32(20) </td>
<td>8 </td>
<td>IN</td>
</tr>

<tr>
<td>40(28) </td>
<td>8 </td>
<td>OUTXX</td>
</tr>

<tr>
<td>48(30) </td>
<td>8 </td>
<td>INXX</td>
</tr>

<tr>
<td>56(38) </td>
<td>8 </td>
<td>DEV5</td>
</tr>

<tr>
<td>64(40) </td>
<td>8 </td>
<td>DEV6</td>
</tr>

<tr>
<td>72(48) </td>
<td>8 </td>
<td>DEV7</td>
</tr>

<tr>
<td>80(50) </td>
<td>8 </td>
<td>DEV8</td>
</tr>

<tr>
<td>88(58) </td>
<td>8 </td>
<td>DEV9</td>
</tr>

<tr>
<td>96(60) </td>
<td>8 </td>
<td>DEV10</td>
</tr>

<tr>
<td>104(68) </td>
<td>8 </td>
<td>DEV11</td>
</tr>

<tr>
<td>112(70) </td>
<td>8 </td>
<td>DEV12</td>
</tr>

<tr>
<td>120(78) </td>
<td>8 </td>
<td>DEV13</td>
</tr>

<tr>
<td>128(80) </td>
<td>8 </td>
<td>DEV14</td>
</tr>

<tr>
<td>136(88) </td>
<td>8 </td>
<td>OUTTTY</td>
</tr>

<tr>
<td>144(90) </td>
<td>8 </td>
<td>INTTY</td>
</tr>

<tr>
<td>152(98) </td>
<td>8 </td>
<td>DEV17</td>
</tr>

<tr>
<td>160(A0) </td>
<td>8 </td>
<td>DEV18</td>
</tr>

<tr>
<td>168(A8) </td>
<td>8 </td>
<td>DEV19</td>
</tr>

<tr>
<td>176(B0) </td>
<td>8 </td>
<td>DEV20</td>
</tr>

<tr>
<td>184(B8) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>192(C0) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>200(C8) </td>
<td>8 </td>
<td>DEV23</td>
</tr>

<tr>
<td>208(D0) </td>
<td>8 </td>
<td>DEV24</td>
</tr>

<tr>
<td>216(D8) </td>
<td>8 </td>
<td>DEV25</td>
</tr>

<tr>
<td>224(E0) </td>
<td>8 </td>
<td>DEV26</td>
</tr>

<tr>
<td>232(E8) </td>
<td>8 </td>
<td>DEV27</td>
</tr>

<tr>
<td>240(F0) </td>
<td>8 </td>
<td>DEV28</td>
</tr>

<tr>
<td>248(F8) </td>
<td>8 </td>
<td>OUTCRAM</td>
</tr>

<tr>
<td>256(100) </td>
<td>8 </td>
<td>INCRAM</td>
</tr>

<tr>
<td>264(108) </td>
<td>8 </td>
<td>DEV31</td>
</tr>

<tr>
<td>272(110) </td>
<td>8 </td>
<td>DEV32</td>
</tr>

<tr>
<td>280(118) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>288(120) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>296(128) </td>
<td>8 </td>
<td>DEV35</td>
</tr>

<tr>
<td>304(130) </td>
<td>8 </td>
<td>DEV36</td>
</tr>

<tr>
<td>312(138) </td>
<td>8 </td>
<td>DEV37</td>
</tr>

<tr>
<td>320(140) </td>
<td>8 </td>
<td>DEV38</td>
</tr>

<tr>
<td>328(148) </td>
<td>8 </td>
<td>OUTVMIO</td>
</tr>

<tr>
<td>336(150) </td>
<td>8 </td>
<td>INVMIO</td>
</tr>

<tr>
<td>344(158) </td>
<td>8 </td>
<td>OUTVMFS</td>
</tr>

<tr>
<td>352(160) </td>
<td>8 </td>
<td>INVMFS</td>
</tr>

<tr>
<td>360(168) </td>
<td>8 </td>
<td>OUTVMIF</td>
</tr>

<tr>
<td>368(170) </td>
<td>8 </td>
<td>INVMIF</td>
</tr>

<tr>
<td>376(178) </td>
<td>8 </td>
<td>OUTCMIO</td>
</tr>

<tr>
<td>384(180) </td>
<td>8 </td>
<td>INCMIO</td>
</tr>

<tr>
<td>392(188) </td>
<td>8 </td>
<td>OUTCMFS</td>
</tr>

<tr>
<td>400(190) </td>
<td>8 </td>
<td>INCMFS</td>
</tr>

<tr>
<td>408(198) </td>
<td>8 </td>
<td>DEV49</td>
</tr>

<tr>
<td>416(1A0) </td>
<td>8 </td>
<td>DEV50</td>
</tr>

<tr>
<td>424(1A8) </td>
<td>8 </td>
<td>OFFIN</td>
</tr>

<tr>
<td>432(1B0) </td>
<td>8 </td>
<td>OFFOU</td>
</tr>

<tr>
<td>440(1B8) </td>
<td>8 </td>
<td>DEV53</td>
</tr>

<tr>
<td>448(1C0) </td>
<td>8 </td>
<td>DEV54</td>
</tr>

<tr>
<td>456(1C8) </td>
<td>8 </td>
<td>DEV55</td>
</tr>

<tr>
<td>464(1D0) </td>
<td>8 </td>
<td>DEV56</td>
</tr>

<tr>
<td>472(1D8) </td>
<td>8 </td>
<td>DEV57</td>
</tr>

<tr>
<td>480(1E0) </td>
<td>8 </td>
<td>DEV58</td>
</tr>

<tr>
<td>488(1E8) </td>
<td>8 </td>
<td>DEV59</td>
</tr>

<tr>
<td>496(1F0) </td>
<td>8 </td>
<td>DEV60</td>
</tr>

<tr>
<td>504(1F8) </td>
<td>8 </td>
<td>DEV61</td>
</tr>

<tr>
<td>512(200) </td>
<td>8 </td>
<td>DEV62</td>
</tr>

<tr>
<td>520(208) </td>
<td>8 </td>
<td>DEV63</td>
</tr>

<tr>
<td>528(210) </td>
<td>8 </td>
<td>DEV64</td>
</tr>

<tr>
<td>536(218) </td>
<td>8 </td>
<td>DEV65</td>
</tr>

<tr>
<td>544(220) </td>
<td>8 </td>
<td>DEV66</td>
</tr>

<tr>
<td>552(228) </td>
<td>8 </td>
<td>DEV67</td>
</tr>

<tr>
<td>560(230) </td>
<td>8 </td>
<td>DEV68</td>
</tr>

<tr>
<td>568(238) </td>
<td>8 </td>
<td>DEV69</td>
</tr>

<tr>
<td>576(240) </td>
<td>8 </td>
<td>DEV70</td>
</tr>

<tr>
<td>584(248) </td>
<td>8 </td>
<td>DEV71</td>
</tr>

<tr>
<td>592(250) </td>
<td>8 </td>
<td>DEV72</td>
</tr>

<tr>
<td>600(258) </td>
<td>8 </td>
<td>DEV73</td>
</tr>

<tr>
<td>608(260) </td>
<td>8 </td>
<td>DEV74</td>
</tr>

<tr>
<td>616(268) </td>
<td>4 </td>
<td>WAIT</td>
</tr>

<tr>
<td>620(26C) </td>
<td>4 </td>
<td>MPLKWTIM</td>
</tr>

<tr>
<td>624(270) </td>
<td>8 </td>
<td>DKRD</td>
</tr>

<tr>
<td>632(278) </td>
<td>8 </td>
<td>DKWR</td>
</tr>

<tr>
<td>640(280) </td>
<td>4 </td>
<td>SVRD</td>
</tr>

<tr>
<td>644(284) </td>
<td>4 </td>
<td>SVWR</td>
</tr>

<tr>
<td>648(288) </td>
<td>8 </td>
<td>CPU</td>
</tr>

<tr>
<td>656(290) </td>
<td>8 </td>
<td>REQ</td>
</tr>

<tr>
<td>664(298) </td>
<td>8 </td>
<td>MOVE</td>
</tr>

<tr>
<td>672(2A0) </td>
<td>4 </td>
<td>DUMP</td>
</tr>

<tr>
<td>676(2A4) </td>
<td>4 </td>
<td>REST</td>
</tr>

<tr>
<td>680(2A8) </td>
<td>4 </td>
<td>SLIC</td>
</tr>

<tr>
<td>684(2AC) </td>
<td>4 </td>
<td>CNCT</td>
</tr>

<tr>
<td>688(2B0) </td>
<td>4 </td>
<td>FBWT</td>
</tr>

<tr>
<td>692(2B4) </td>
<td>4 </td>
<td>SWT</td>
</tr>

<tr>
<td>696(2B8) </td>
<td>4 </td>
<td>ERRPDL</td>
</tr>

<tr>
<td>700(2BC) </td>
<td>4 </td>
<td>MPLKPREM</td>
</tr>

<tr>
<td>704(2C0) </td>
<td>8 </td>
<td>RECADD</td>
</tr>

<tr>
<td>712(2C8) </td>
<td>8 </td>
<td>RECDEL</td>
</tr>

<tr>
<td>720(2D0) </td>
<td>8 </td>
<td>BADD</td>
</tr>

<tr>
<td>728(2D8) </td>
<td>8 </td>
<td>BDEL</td>
</tr>

<tr>
<td>736(2E0) </td>
<td>8 </td>
<td>BCHG</td>
</tr>

<tr>
<td>744(2E8) </td>
<td>8 </td>
<td>IXADD</td>
</tr>

<tr>
<td>752(2F0) </td>
<td>8 </td>
<td>IXDEL</td>
</tr>

<tr>
<td>760(2F8) </td>
<td>8 </td>
<td>FINDS</td>
</tr>

<tr>
<td>768(300) </td>
<td>4 </td>
<td>SORTS</td>
</tr>

<tr>
<td>772(304) </td>
<td>4 </td>
<td>JSCREENS</td>
</tr>

<tr>
<td>776(308) </td>
<td>8 </td>
<td>RECDS</td>
</tr>

<tr>
<td>784(310) </td>
<td>8 </td>
<td>STRECDS</td>
</tr>

<tr>
<td>792(318) </td>
<td>8 </td>
<td>DKAR</td>
</tr>

<tr>
<td>800(320) </td>
<td>8 </td>
<td>DKPR</td>
</tr>

<tr>
<td>808(328) </td>
<td>4 </td>
<td>DKRR</td>
</tr>

<tr>
<td>812(32C) </td>
<td>4 </td>
<td>FBMX</td>
</tr>

<tr>
<td>816(330) </td>
<td>4 </td>
<td>TFMX</td>
</tr>

<tr>
<td>820(334) </td>
<td>4 </td>
<td>USMX</td>
</tr>

<tr>
<td>824(338) </td>
<td>4 </td>
<td>SVMX</td>
</tr>

<tr>
<td>828(33C) </td>
<td>4 </td>
<td>SFTRSTRT (number of soft restarts)</td>
</tr>

<tr>
<td>832(340) </td>
<td>8 </td>
<td>APSYLD</td>
</tr>

<tr>
<td>840(348) </td>
<td>8 </td>
<td>APSYLDD</td>
</tr>

<tr>
<td>848(350) </td>
<td>4 </td>
<td>APSYLDT</td>
</tr>

<tr>
<td>852(354) </td>
<td>4 </td>
<td>Spare</td>
</tr>

<tr>
<td>856(358) </td>
<td>8 </td>
<td>DKPRF</td>
</tr>

<tr>
<td>864(360) </td>
<td>4 </td>
<td>SMPLS</td>
</tr>

<tr>
<td>868(364) </td>
<td>4 </td>
<td>USRS</td>
</tr>

<tr>
<td>872(368) </td>
<td>4 </td>
<td>SVAC</td>
</tr>

<tr>
<td>876(36C) </td>
<td>4 </td>
<td>RUNG</td>
</tr>

<tr>
<td>880(370) </td>
<td>4 </td>
<td>REDY</td>
</tr>

<tr>
<td>884(374) </td>
<td>4 </td>
<td>BLKI</td>
</tr>

<tr>
<td>888(378) </td>
<td>4 </td>
<td>WTSV</td>
</tr>

<tr>
<td>892(37C) </td>
<td>4 </td>
<td>BLKO</td>
</tr>

<tr>
<td>896(380) </td>
<td>4 </td>
<td>SWPG</td>
</tr>

<tr>
<td>900(384) </td>
<td>4 </td>
<td>PCPU</td>
</tr>

<tr>
<td>904(388) </td>
<td>4 </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>908(38C) </td>
<td>4 </td>
<td>JWEBERRS</td>
</tr>

<tr>
<td>912(390) </td>
<td>8 </td>
<td>STCPU</td>
</tr>

<tr>
<td>920(398) </td>
<td>8 </td>
<td>STDEQ</td>
</tr>

<tr>
<td>928(3A0) </td>
<td>8 </td>
<td>STWAIT</td>
</tr>

<tr>
<td>936(3A8) </td>
<td>4 </td>
<td>STPOST</td>
</tr>

<tr>
<td>940(3AC) </td>
<td>4 </td>
<td>LKWAIT</td>
</tr>

<tr>
<td>944(3B0) </td>
<td>4 </td>
<td>LKPOST</td>
</tr>

<tr>
<td>948(3B4) </td>
<td>4 </td>
<td>RSXCOMP</td>
</tr>

<tr>
<td>952(3B8) </td>
<td>4 </td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>956(3BC) </td>
<td>4 </td>
<td>SCREENS</td>
</tr>

<tr>
<td>960(3C0) </td>
<td>4 </td>
<td>STIMERS</td>
</tr>

<tr>
<td>964(3C4) </td>
<td>4 </td>
<td>HRDRSTRT (number of hard restarts)</td>
</tr>

<tr>
<td>968(3C8) </td>
<td>8 </td>
<td>SVPAGES</td>
</tr>

<tr>
<td>976(3D0) </td>
<td>4 </td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>980(3D4) </td>
<td>4 </td>
<td>COMMITS</td>
</tr>

<tr>
<td>984(3D8) </td>
<td>4 </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>988(3DC) </td>
<td>4 </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>992(3E0) </td>
<td>4 </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>996(3E4) </td>
<td>4 </td>
<td>MPHASHD</td>
</tr>

<tr>
<td>1000(3E8) </td>
<td>4 </td>
<td>CDLWAIT</td>
</tr>

<tr>
<td>1004(3EC) </td>
<td>4 </td>
<td>MQGETS</td>
</tr>

<tr>
<td>1008(3F0) </td>
<td>4 </td>
<td>MQPUTS</td>
</tr>

<tr>
<td>1012(3F4) </td>
<td>4 </td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>1016(3F8) </td>
<td>4 </td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>1020(3FC) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1024(400) </td>
<td>8 </td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>1032(408) </td>
<td>8 </td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>1040(410) </td>
<td>4 </td>
<td>MQHWQU</td>
</tr>

<tr>
<td>1044(414) </td>
<td>4 </td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>1048(418) </td>
<td>4 </td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>1052(41C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1056(420) </td>
<td>8 </td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>1064(428) </td>
<td>8 </td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>1072(430) </td>
<td>8 </td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>1080(438) </td>
<td>4 </td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>1084(43C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1088(440) </td>
<td>8 </td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>1096(448) </td>
<td>4 </td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>1100(44C) </td>
<td>4 </td>
<td>ECLOAD</td>
</tr>

<tr>
<td>1104(450) </td>
<td>4 </td>
<td>ECDELETE</td>
</tr>

<tr>
<td>1108(454) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1112(458) </td>
<td>8 </td>
<td>ECCALL</td>
</tr>

<tr>
<td>1120(460) </td>
<td>4 </td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>1124(464) </td>
<td>4 </td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>1128(468) </td>
<td>4 </td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>1132(46C) </td>
<td>4 </td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>1136(470) </td>
<td>4 </td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>1140(474) </td>
<td>4 </td>
<td>ECCNCT</td>
</tr>

<tr>
<td>1144(478) </td>
<td>4 </td>
<td>ECMODMAX</td>
</tr>

<tr>
<td>1148(47C) </td>
<td>4 </td>
<td>ECNAMMAX</td>
</tr>

<tr>
<td>1152(480) </td>
<td>4 </td>
<td>ECTSKMAX</td>
</tr>

<tr>
<td>1156(484) </td>
<td>4 </td>
<td>GTBLRU</td>
</tr>

<tr>
<td>1160(488) </td>
<td>4 </td>
<td>GTBLRS</td>
</tr>

<tr>
<td>1164(48C) </td>
<td>4 </td>
<td>TSMX</td>
</tr>

<tr>
<td>1168(490) </td>
<td>4 </td>
<td>TEMX</td>
</tr>

<tr>
<td>1172(494) </td>
<td>4 </td>
<td>MAXIOX</td>
</tr>

<tr>
<td>1176(498) </td>
<td>8 </td>
<td>DKRDL</td>
</tr>

<tr>
<td>1184(4A0) </td>
<td>8 </td>
<td>DKWRL</td>
</tr>

<tr>
<td>1192(4A8) </td>
<td>8 </td>
<td>CPUTOTZE</td>
</tr>

<tr>
<td>1200(4B0) </td>
<td>8 </td>
<td>CPUONZIP</td>
</tr>

<tr>
<td>1208(4B8) </td>
<td>4 </td>
<td>MPR
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1212(4BC) </td>
<td>4 </td>
<td>MBO
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1216(4C0) </td>
<td>4 </td>
<td>MCP
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1220(4C4) </td>
<td>4 </td>
<td>RCV
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1224(4C8) </td>
<td>8 </td>
<td>Spare </td>
</tr>

<tr>
<td>1232(4D0) </td>
<td>8 </td>
<td>DKWTMICS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1240(4D8) </td>
<td>8 </td>
<td>DKWTS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1248(4E0) </td>
<td>8 </td>
<td>MTDEQ</td>
</tr>

<tr>
<td>1256(4E8) </td>
<td>8 </td>
<td>MTSDEQ</td>
</tr>

<tr>
<td>1264(4F0) </td>
<td>8 </td>
<td>MTZDEQ</td>
</tr>

<tr>
<td>1272(4F8) </td>
<td>8 </td>
<td>STZDEQ</td>
</tr>

<tr>
<td>1280(500) </td>
<td>8 </td>
<td>ZTDEQ</td>
</tr>
</table>

==System performance statistics==

===Entry format===

For subtype X'02'(system performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. See [[#Description of statistics|Statistics with descriptions]] table for the meaning of each statistic. 
<table>
<caption>Layout of system subtype X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 16(10)</td>
<td>SMPLS</td>
</tr>

<tr>
<td> 20(14)</td>
<td>USRS</td>
</tr>

<tr>
<td> 24(18)</td>
<td>SVAC</td>
</tr>

<tr>
<td> 28(1C)</td>
<td>RUNG </td>
</tr>

<tr>
<td> 32(20)</td>
<td>REDY</td>
</tr>

<tr>
<td> 36(24)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 40(28)</td>
<td>WTSV</td>
</tr>

<tr>
<td> 44(2C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 48(30)</td>
<td>SWPG </td>
</tr>
</table>

==Additional disk buffer monitor statistics==

For subtype X'04' (additional disk buffer monitor statistics), the layout of the entry is shown in the following table. Each statistic in the table is: Length, 8; Data type, Binary.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Disk buffer monitor statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Disk buffer monitor statistic </th>
</tr>

<tr>
<td>16(10)</td>
<td>Spare</td>
</tr>

<tr>
<td>24(18) </td>
<td>DKSTKQC </td>
</tr>

<tr>
<td>32(20) </td>
<td>DKSWRP </td>
</tr>

<tr>
<td>40(28) </td>
<td>DKSWRPT </td>
</tr>

<tr>
<td>48(30) </td>
<td>DKSDIR </td>
</tr>

<tr>
<td>56(38) </td>
<td>DKSDIRT </td>
</tr>

<tr>
<td>64(40) </td>
<td>DKSKIP </td>
</tr>

<tr>
<td>72(48) </td>
<td>Spare </td>
</tr>

<tr>
<td>80(50) </td>
<td>Spare</td>
</tr>

<tr>
<td>88(58) </td>
<td>DKSRR </td>
</tr>

<tr>
<td>96(60) </td>
<td>DKSFBS </td>
</tr>

<tr>
<td>104(68) </td>
<td>DKSKIPT </td>
</tr>

<tr>
<td>112(70) </td>
<td>DKSAWT </td>
</tr>

<tr>
<td>120(78) </td>
<td>DKSAWW</td>
</tr>

<tr>
<td>128(80) </td>
<td>DKSAWWL</td>
</tr>

<tr>
<td>136(88) </td>
<td>DKSAWB </td>
</tr>

<tr>
<td>144(90) </td>
<td>DKSAWBL</td>
</tr>

<tr>
<td>152(98) </td>
<td>DKSRRFND </td>
</tr>

<tr>
<td>160(A0) </td>
<td>DKSTBLF </td>
</tr>

<tr>
<td>168(A8) </td>
<td>DKSTBLA </td>
</tr>

<tr>
<td>176(B0) </td>
<td>DKSTBLB </td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKSTBLC </td>
</tr>

<tr>
<td>192(C0) </td>
<td>DKSTBLD </td>
</tr>

<tr>
<td>200(C8) </td>
<td>Spare </td>
</tr>

<tr>
<td>208(D0) </td>
<td>Spare </td>
</tr>

<tr>
<td>216(D8) </td>
<td>Spare </td>
</tr>

<tr>
<td>224(E0) </td>
<td>Spare </td>
</tr>

<tr>
<td>232(E8) </td>
<td>Spare </td>
</tr>

<tr>
<td>240(F0) </td>
<td>Spare </td>
</tr>

<tr>
<td>248(F8) </td>
<td>Spare </td>
</tr>

<tr>
<td>256(100) </td>
<td>DKSTBLX </td>
</tr>

<tr>
<td>264(108) </td>
<td>DKSTBLE</td>
</tr>

<tr>
<td>272(110)</td>
<td>Spare </td>
</tr>
</table>

==Multiprocessing (MP) subtask statistics==

The following statistics apply only to installations configured for multiprocessing using MP/204. For subtype X'08' (subtask specific statistics), the layout of the entry is shown in the following table.
For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>MP subtask statistics and offsets</caption>
<tr class="head">
<th>MP statistic </th>
<th>Offset dec(hex) </th>
<th>Length</th>
</tr>

<tr>
<td>CPU </td>
<td>16(10) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PR </td>
<td>24(18) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PCPU </td>
<td>32(20) </td>
<td align="right">4</td>
</tr>

<tr>
<td>STWAIT</td>
<td>36(24)</td>
<td align="right">4</td>
</tr>

<tr>
<td>STPOST</td>
<td>40(28)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>44(2C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKPOST</td>
<td>48(30)</td>
<td align="right">4</td>
</tr>

<tr>
<td>SPARE</td>
<td>52(34)</td>
<td align="right">4</td>
</tr>

<tr>
<td>MQWTM</td>
<td>56(38) </td>
<td align="right">8</td>
</tr>

<tr>
<td>DEQ </td>
<td>64(40) </td>
<td align="right">8</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>72(48)</td>
<td align="right">8</td>
</tr>

<tr>
<td>STDEQ </td>
<td>80(50) </td>
<td align="right">8</td>
</tr>

<tr>
<td>LWTIM </td>
<td>88(58) </td>
<td align="right">4</td>
</tr>

<tr>
<td>PETIM</td>
<td>92(5C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>ZCPU</td>
<td>96(60) </td>
<td align="right">8</td>
</tr>
</table>

==User statistics entries (Type 9)==

User lines report on an individual user's activity. These statistics include:
<ul>
<li>Final (logout) and partial statistics</li>

<li>Since-last and ordered index statistics</li>

<li>Performance statistics</li>
</ul>

Each user line starts with the following statistics:
ST $$$ USERID='userid' ACCOUNT='account'


The subtype, in this case PERFORMANCE, follows USERID and ACCOUNT statistics:
ST $$$ USERID='userid' ACCOUNT='account'
PERFORMANCE=n


The format of user statistics entries is shown in the following table:
<table>
<caption>User statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'09'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:
<ul>
<li>X'00' = logout statistics</li>

<li>X'01' = since-last statistics</li>

<li>X'02' = partial statistics</li>

<li>X'04' = performance statistics</li>

<li>X'81' = since-last statistics including conflict statistics</li>

<li>X'41' = user restart forced out a since-last statistics record.</li>

<li>X'C1' = user restart forced out a since last statistics record which included conflict statistics</li>
</ul>
</td></tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>

Account:
<ul>
<li>Second argument of LOGON/LOGIN command</li>

<li>Default is user ID</li>
</ul>
</td>
</tr>

<tr>
<td>26(1A)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>User ID</td>
</tr>

<tr>
<td>36(24)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>Since-last ID =
See the [[#User since-last statistics|Activity types]] table where the possible activity types are listed.</td>
</tr>

<tr>
<td>40(28)</td>
<td align="right">1</td>
<td>Binary</td>
<td>IODEV number (added for MXI)</td>
</tr>

<tr>
<td>41(29)</td>
<td align="right">3</td>
<td>N/A</td>
<td>Unused</td>
</tr>

<tr>
<td>44(2C) to end of journal</td>
<td> </td>
<td>Binary</td>
<td>

Contents depend on subtypes, shown in:
<ul>
<li>[[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table</li>

<li>[[#Since-last in relation to final and partial statistics|Layout of user subtype X'01' and X'81' entries]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table</li>

<li>[[#Layout of performance statistics|Layout of user subtype X'04' entries]] table</li>
</ul>
</td> </tr>
</table>

==User final and partial statistics==

===Final (logout) statistics===

Final (logout) statistics, listed in the [[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table, summarize a user's activities since the last login. A LOGOUT statistics line, such as the following, is written after each logout if the parameter following ACCOUNT is not PARTIAL, LAST, or PERFORMANCE: 
yydddhhmmssnnnsssuuuuu ST $$$ ACCOUNT='NO ACCOUNT' SQRD=5 ...

<ul>
<li><var class="term">yyddd</var> is the year and Julian day.</li>

<li><var class="term">hhmmss</var> is the time of day in hours, minutes, and seconds.</li>

<li><var class="term">nnn</var> is a counter to distinguish lines produced in the same second.</li>

<li><var class="term">sss</var> is the number of the server currently handling the user. Leading zeros are suppressed.
</li>

<li><var class="term">uuuuu</var> is a 5-digit user number associated with the audit trail line. Leading zeros are suppressed.</li>
</ul>

In some cases, the account name appears as "NO USERID NO ACCOUNT". Statistics in this category are not chargeable to any one user and should be considered system overhead.

Final lines are recognized by the absence of an indicator for another type of line.

===Partial statistics===

Optional partial statistics, listed in the "Layout of user subtype X'00' and X'02' entries" table below, can be provided for a run up to a few minutes before a system failure that prevents normal termination and production of final user and system statistics. 

User partial statistics lines, such as the following, are made available for active users: 
ST $$$ ACCOUNT='NO ACCOUNT' PARTIAL=21 ...


Statistics accumulate either:
<ul>
<li>As long as the user is logged in</li>
</ul>

or
<ul>
<li>From the first terminal input to disconnection when a login is not required </li>
</ul>

Partial statistics are requested by setting the time interval, in minutes, between successive partial lines on User 0's parameter line with the <var>ACCTIM</var> parameter. <var>ACCTIM</var> must be nonzero. 

The contents of the statistics portion of the entry, starting at offset <code>40(28)</code>, depends upon the subtype of the entry. 

Partial statistics lines are indicated on the journal by the parameter <code>PARTIAL=n</code>, where <var class="term">n</var> is a counter from the beginning of the run. <code>PARTIAL=n</code> immediately follows the type parameter.

For subtypes X'00' (logout statistics), and X'02' (partial statistics), the layout of the remainder of the entry is shown in the following table. Each statistic in the table is: Length, 4; Data type, Binary. For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Layout of user subtype X'00' and X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>40(28)</td>
<td>CNCT</td>
</tr>

<tr>
<td>44(2C)</td>
<td>DKRD </td>
</tr>

<tr>
<td>48(30)</td>
<td>DKWR </td>
</tr>

<tr>
<td>52(34)</td>
<td>SQRD</td>
</tr>

<tr>
<td>56(38)</td>
<td>SQWR</td>
</tr>

<tr>
<td>60(3C)</td>
<td>SGMTI </td>
</tr>

<tr>
<td>64(40)</td>
<td>SGMTO </td>
</tr>

<tr>
<td>68(44)</td>
<td>SVRD</td>
</tr>

<tr>
<td>72(48)</td>
<td>SVWR </td>
</tr>

<tr>
<td>76(4C)</td>
<td>CPU </td>
</tr>

<tr>
<td>80(50)</td>
<td>REQ </td>
</tr>

<tr>
<td>84(54)</td>
<td>MOVE </td>
</tr>

<tr>
<td>88(58)</td>
<td>DUMP </td>
</tr>

<tr>
<td>92(5C)</td>
<td>REST </td>
</tr>

<tr>
<td>96(60)</td>
<td>SLIC </td>
</tr>

<tr>
<td>100(64)</td>
<td>AUDIT </td>
</tr>

<tr>
<td>104(68) </td>
<td>WAIT </td>
</tr>

<tr>
<td>108(6C)</td>
<td>FBWT </td>
</tr>

<tr>
<td>112(70)</td>
<td>UDD </td>
</tr>

<tr>
<td>116(74)</td>
<td>RECADD </td>
</tr>

<tr>
<td>120(78)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>124(7C)</td>
<td>BADD </td>
</tr>

<tr>
<td>128(80)</td>
<td>BDEL</td>
</tr>

<tr>
<td>132(84)</td>
<td>BCHG </td>
</tr>

<tr>
<td>136(88)</td>
<td>IXADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>FINDS </td>
</tr>

<tr>
<td>148(94)</td>
<td>SORTS</td>
</tr>

<tr>
<td>152(98)</td>
<td>RECDS </td>
</tr>

<tr>
<td>156(9C)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>160(A0)</td>
<td>DKAR </td>
</tr>

<tr>
<td>164(A4)</td>
<td>DKPR </td>
</tr>

<tr>
<td>168(A8)</td>
<td>DKRR </td>
</tr>

<tr>
<td>172(AC)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>UPDTTIME(MS) </td>
</tr>

<tr>
<td>184(B8)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>188(BC)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>192(C0)</td>
<td>SMPLS </td>
</tr>

<tr>
<td>196(C4)</td>
<td>RUNG </td>
</tr>

<tr>
<td>200(C8)</td>
<td>REDY</td>
</tr>

<tr>
<td>204(CC)</td>
<td>BLKI</td>
</tr>

<tr>
<td>208(D0)</td>
<td>WTSV </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BLKO </td>
</tr>

<tr>
<td>216(D8)</td>
<td>SWPG </td>
</tr>

<tr>
<td>220(DC)</td>
<td>PCPU </td>
</tr>

<tr>
<td>224(E0)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>228(E4)</td>
<td>BXCHNG </td>
</tr>

<tr>
<td>232(E8)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>236(EC)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>240(F0)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>244(F4)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>248(F8)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>252(FC)</td>
<td>BXRFND</td>
</tr>

<tr>
<td>256(100)</td>
<td>BXFREE </td>
</tr>

<tr>
<td>260(104)</td>
<td>STCPU </td>
</tr>

<tr>
<td>264(108)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>268(10C)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>272(110)</td>
<td>SCREENS </td>
</tr>

<tr>
<td>276(114)</td>
<td>SVPAGES </td>
</tr>

<tr>
<td>280(118)</td>
<td>PBRSFLT </td>
</tr>

<tr>
<td>284(11C)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>292(124)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQBYTOU</td>
</tr>

<tr>
<td>308((134)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>380(17C)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>384(180)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>388(184)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>392(188)</td>
<td>Spare</td>
</tr>

<tr>
<td>396(18C) </td>
<td>MPR (V7.7 onwards)</td>
</tr>

<tr>
<td>400(190) </td>
<td>MBO (V7.7 onwards)</td>
</tr>

<tr>
<td>404(194)</td>
<td>DEV#</td>
</tr>

<tr>
<td>408(198)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>412(19C)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>CCATDIFF</td>
</tr>

</table>

==User since-last statistics==

===Since-last statistics===

Statistics are kept for each SOUL request, host language interface call, and a number of <var class="product">Model 204</var> system commands. When each request or command completes, a since-last statistics line is written. The line includes the <var>ACCOUNT</var> parameter at the beginning, followed by the <var>IODEV</var> parameter and the <var>LAST</var> parameter.

Several <var>MONITOR</var> commands produce displays containing the user's last or current activity in the <code>FUNC</code> column. When this activity completes, statistics are also written to CCAAUDIT and the activity is described in ST lines as <code>LAST='activity'</code>.

====Syntax====
ST $$$ USERID='userid' ACCOUNT='accountname' IODEV='devicetype' LAST='acty'

Where:

<var class="term">acty</var> can be one of the following: 
<table>
<caption>Activity types</caption>
<tr class="head">
<th>Option</th>
<th>Meaning</th>
</tr>

<tr>
<td>BLDR</td>
<td><var>BLDREUSE</var> command</td>
</tr>

<tr>
<td>BLDX </td>
<td><var>Z</var> command</td>
</tr>

<tr>
<td>CMPL </td>
<td>Compilation of a SOUL request</td>
</tr>

<tr>
<td>CPTB</td>
<td><var>COMPACTB</var> command</td>
</tr>

<tr>
<td>CPTE</td>
<td><var>COMPACTE</var> command</td>
</tr>

<tr>
<td>CPYP </td>
<td><var>COPY PROCEDURE</var> command</td>
</tr>

<tr>
<td>CREA</td>
<td><var>CREATE FILE filename</var> command</td>
</tr>

<tr>
<td>DISP </td>
<td><var>DISPLAY PROCEDURE</var> command</td>
</tr>

<tr>
<td>DUMP </td>
<td><var>DUMP file</var> command</td>
</tr>

<tr>
<td>EDIT </td>
<td>Editing a request</td>
</tr>

<tr>
<td>EVAL </td>
<td>Evaluation of a SOUL request</td>
</tr>

<tr>
<td>EXEC </td>
<td>Execution of an SQL request</td>
</tr>

<tr>
<td>FLDC </td>
<td>Compilation of a FLOD procedure</td>
</tr>

<tr>
<td>FLDE </td>
<td>Evaluation of a FLOD procedure</td>
</tr>

<tr>
<td>IMPC </td>
<td>Implied commit</td>
</tr>

<tr>
<td>INCR</td>
<td><var>IN FILE filename INCREASE DATASETS</var> command</td>
</tr>

<tr>
<td>INIT</td>
<td><var>IN FILE filename INITIALIZE</var> command</td>
</tr>

<tr>
<td>LOAD </td>
<td>Loading a precompiled (ASPY) procedure</td>
</tr>

<tr>
<td>PREP </td>
<td>Compilation of an SQL request</td>
</tr>

<tr>
<td>REST </td>
<td><var>RESTORE file</var> command</td>
</tr>
</table>

===Since-last highwater marks===

The since-last statistics include highwater marks of various work tables used by SOUL requests. Values are reported in terms of the units in which each table is allocated. For example, QTBL is allocated in units of 16 bytes.

===Since-last in relation to final and partial statistics===

Many since-last statistics, such as CNCT, CPU, and DKRD, are also reported on user final and partial statistics lines. (See the [[#Description of statistics|Statistics with descriptions]] table.) The statistics on these lines are roughly equal to the sum of all of the preceding since-last statistics for the user.
Because since-last statistics are not maintained for every <var class="product">Model 204</var> command, final statistics are generally larger.

For subtype X'01' (since-last statistics), the layout of the remainder of the entry begins as shown in the following table.
For the meaning of each statistic in this table and in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table, see the [[#Description of statistics|Statistics with descriptions]] table.
The layout of the end of the entry depends on whether you chose to collect conflict statistics:
<ul>
<li>If you do not collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table.</li>

<li>If you do collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table. When you collect conflict statistics, the subtype changes to X'81'. </li>
</ul>
<table>
<caption>Layout of user subtype X'01' and X'81' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 44(2C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 48(30)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 52(34)</td>
<td>QTBL </td>
</tr>

<tr>
<td> 56(38)</td>
<td>STBL </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>TTBL </td>
</tr>

<tr>
<td> 64(40)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 68(44)</td>
<td>PDL</td>
</tr>

<tr>
<td> 72(48)</td>
<td>FTBL </td>
</tr>

<tr>
<td> 76(4C)</td>
<td>XTBL </td>
</tr>

<tr>
<td> 80(50)</td>
<td>ITBL </td>
</tr>

<tr>
<td> 84(54)</td>
<td>FSCB </td>
</tr>

<tr>
<td> 88(58)</td>
<td>OUTPB </td>
</tr>

<tr>
<td> 92(5C) </td>
<td>HEAP </td>
</tr>

<tr>
<td> 96(60)</td>
<td>SQLI </td>
</tr>

<tr>
<td>100(64)</td>
<td>SQLO</td>
</tr>

<tr>
<td>104(68)</td>
<td>CNCT</td>
</tr>

<tr>
<td>108(6C)</td>
<td>CPU </td>
</tr>

<tr>
<td>112(70)</td>
<td>DKRD </td>
</tr>

<tr>
<td>116(74)</td>
<td>DKWR</td>
</tr>

<tr>
<td>120(78)</td>
<td>UDD </td>
</tr>

<tr>
<td>124(7C)</td>
<td>OUT </td>
</tr>

<tr>
<td>128(80)</td>
<td>SLIC</td>
</tr>

<tr>
<td>132(84)</td>
<td>IN </td>
</tr>

<tr>
<td>136(88)</td>
<td>RECADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>BADD </td>
</tr>

<tr>
<td>148(94)</td>
<td>BDEL </td>
</tr>

<tr>
<td>152(98)</td>
<td>BCHG </td>
</tr>

<tr>
<td>156(9C)</td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>164(A4)</td>
<td>FINDS </td>
</tr>

<tr>
<td>168(A8)</td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC)</td>
<td>RECDS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>PCPU </td>
</tr>

<tr>
<td>184(B8)</td>
<td>RQTM </td>
</tr>

<tr>
<td>188(BC)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>192(CO)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td>196(C4)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>200(C8)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>204(CC)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>208(DO)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>216(D8)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 220(DC)</td>
<td>BXFREE </td>
</tr>

<tr>
<td> 224(E0)</td>
<td>STCPU </td>
</tr>

<tr>
<td> 228(E4)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 232(E8)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 236(EC)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>240(F0) </td>
<td>SVRD </td>
</tr>

<tr>
<td>244(F4)</td>
<td>SVWR</td>
</tr>

<tr>
<td>248(F8) </td>
<td>DKPR </td>
</tr>

<tr>
<td>252(FC)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>256(100)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>260(104)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>264(108)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>268(10C)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>272(110)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>276(114)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>280(118)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>284(11C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>292(124)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>336(150)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>340(154)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>372(174)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>376(178)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>380(17C)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>384(180)</td>
<td>OBJSWAP</td>
</tr>

<tr>
<td>388()184</td>
<td>SIRIUS02</td>
</tr>

<tr>
<td>392(188)</td>
<td>SIRIUS03</td>
</tr>

<tr>
<td>396(18C)</td>
<td>IODEV#</td>
</tr><tr>

<tr>
<td>400(190)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>404(194) </td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>408(198) </td>
<td>CCATDIFF</td>
</tr>

<tr>
<td>412(19C) </td>
<td>RETHWM</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>PREIMAGE</td>
</tr>

<tr>
<td>420(1A4) </td>
<td>MAXDAEM</td>
</tr>
</table>

===Conflict statistics===

Whether you are collecting conflict statistics determines the layout at the end of the entry. Two of the conflict statistics keep track of critical file-resource conflicts, and two keep track of record-locking conflicts. Whether these statistics are collected and journaled depends on settings of the parameters <var>[[CFRLOOK parameter|CFRLOOK]]</var> and <var>[[CFRJRNL parameter|CFRJRNL]]</var>.


These statistics are not displayed with the output of the <code>MONITOR SL</code> command. Instead, you can view them (with all the other since-last statistics) by issuing the <var>MONITOR</var> command with the keyword <var>CONFLICT</var>.

The remainder of the entry depends on the setting of <var>CFRJRNL</var>.

The following table shows the layout when <var>CFRJRNL</var> is set to 0: 
<table>
<caption>Layout of user subtype X'01' entries (CFRJRNL=0)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>422(1A6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>430(1AE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>431(1AF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>

The following table shows the layout when <var>CFRJRNL</var> is set to 1. It reflects the change in offset and that the user subtypes are now X'81' entries. 
<table>
<caption>Layout of user subtype X'81' entries (CFRJRNL=1)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Entry type</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKCFRE stastic</td>
</tr>

<tr>
<td>416(1A0)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKRLK statistic</td>
</tr>

<tr>
<td>420(1A4)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTCFR statistic</td>
</tr>

<tr>
<td>424(1A8)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTRLK statistic</td>
</tr>

<tr>
<td>428(1AC)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>438(1B6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>446(1BE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>447(1BF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>
Note:
The conflict statistics, BLKCFRE, BLKRLK, WTCFR, and WTRLK, are inexact. Although a user might at times conflict with multiple other users, only the first conflict encountered is counted.

==User performance statistics==

Optional performance statistics lines provide information about the operation of the <var class="product">Model 204</var> scheduler during a short period of time. Information about the length of the scheduler queues, the number of active users and servers, and the queue distribution for each user, is obtained by sampling. 

A performance line starts with:
ST $$$ USERID='userid' ACCOUNT='accountname'
PERFORMANCE=n


===Parameters to activate performance statistics===

To request performance statistics, specify the number of samples to take between performance statistics lines (<var>RPTCNT</var> parameter) and the time interval between samples (<var>SMPLTIM</var> parameter) on User 0's parameter line. When you request scheduler and server performance data (<var>SMPLTIM</var> parameter), an asynchronous operating system task, called the performance subtask, is created. Both <var>RPTCNT</var> and <var>SMPLTIM</var> must be nonzero.

===Sampling===

The performance subtask spends most of its time in a wait state. Every <var>SMPLTIM</var> milliseconds, it records the current state of the system. Data from the most recent sample is available at an Online terminal through the <var>MONITOR</var> command, described in [[Controlling system operations (CCAIN)#ONLINE monitoring|ONLINE monitoring]]. 

The number of samples taken during a run (<var>RPTCNT</var>), times the number of users in the run (<var>NUSERS</var>), must be less than 4.2 million. In large systems that run for a very long period of time, the time interval between samples cannot be extremely short. If the limit is exceeded, an OC1 interrupt occurs when the SMPLS statistic value is calculated during the printing of the system statistics, either a performance or final line.

====Layout of performance statistics====

For subtype X'04' (performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. For the description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>Layout of user subtype X'04' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 40(28)</td>
<td>SMPLS </td>
</tr>

<tr>
<td> 44(2C)</td>
<td>RUNG</td>
</tr>

<tr>
<td> 48(30)</td>
<td>REDY </td>
</tr>

<tr>
<td> 52(34)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 56(38)</td>
<td>WTSV </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 64(40)</td>
<td>SWPG </td>
</tr>
</table>

==File statistics entries (Type 10)==

File statistics, summarized in the [[#File statistics journal records layout|File statistics entry formats]] table, are kept for every file opened during a run, including CCAGRP, CCASYS, and CCATEMP. The activity of a file for all users is summarized from the time the file is first opened until the last user issues a <var>CLOSE</var> command. The statistics appear after the last <var>CLOSE</var> command in lines that follow the date and time information (yyyydddhhmmssnnnsssuuuuu) with: 
ST $$$ FILE='filename'


System termination writes file statistics for each file still open at the end of the run.

===Final statistics===

A final statistics line similar to the following is produced when the last user of a file closes the file: 
ST $$$ FILE='PAYABLES'DKRD=25 DKRD=25 DKWR=15 REQ=3 RECADD=6 ...


===Partial statistics===

File partial statistics lines similar to the following are furnished for each open file: 
ST $$$ FILE='PAYABLES'PARTIAL=3 ...


===File statistics journal records layout===

File statistics entries have the format shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>File statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Type of entry</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'0A'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Subtype indicator:
X'00' = file close
X'01' = partial</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td align="right"> 4</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td align="right"> 8</td>
<td> EBCDIC</td>
<td>File name</td>
</tr>

<tr>
<td> 24(18)</td>
<td align="right"> 2</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>
</table>

The following table lists the file statistics and the decimal(hexidecimal) offset. These statistics are data type Binary and eight bytes long.
<table>
<caption>File statistics</caption>
<tr class="head">
<th>File statistic </th>
<th>Offset dec(hex) </th>
</tr>

<tr>
<td>DKRD </td>
<td>26(1A) </td>
</tr>

<tr>
<td>DKWR </td>
<td>34(22) </td>
</tr>

<tr>
<td>REQ </td>
<td>42(2A) </td>
</tr>

<tr>
<td>RETRYA </td>
<td>50(32) </td>
</tr>

<tr>
<td>RETRYC </td>
<td>58(3A) </td>
</tr>

<tr>
<td>DUPDTS </td>
<td>66(42) </td>
</tr>

<tr>
<td>RECADD </td>
<td>74(4A) </td>
</tr>

<tr>
<td>RECDEL </td>
<td>82(52) </td>
</tr>

<tr>
<td>BADD </td>
<td>90(5A) </td>
</tr>

<tr>
<td>BDEL </td>
<td>98(62) </td>
</tr>

<tr>
<td>BCHG </td>
<td>106(6A) </td>
</tr>

<tr>
<td>IXADD </td>
<td>114(72) </td>
</tr>

<tr>
<td>IXDEL </td>
<td>122(7A) </td>
</tr>

<tr>
<td>DIRRCD </td>
<td>130(82) </td>
</tr>

<tr>
<td>BXCHNG </td>
<td>138(8A) </td>
</tr>

<tr>
<td>BXDELE </td>
<td>146(92) </td>
</tr>

<tr>
<td>BXNEXT </td>
<td>154(9A) </td>
</tr>

<tr>
<td>BXFIND </td>
<td>162(A2) </td>
</tr>

<tr>
<td>BXINSE </td>
<td>170(AA) </td>
</tr>

<tr>
<td>BXSPLI </td>
<td>178(B2) </td>
</tr>

<tr>
<td>BXRFND </td>
<td>186(BA) </td>
</tr>

<tr>
<td>BXFREE </td>
<td>194(C2) </td>
</tr>

<tr>
<td>UPDTTIME </td>
<td>202(CA) </td>
</tr>

<tr>
<td>PNDGTIME </td>
<td>210(D2) </td>
</tr>

<tr>
<td>DKUPTIME </td>
<td>218(DA) </td>
</tr>

<tr>
<td>COMMITS </td>
<td>226(E2) </td>
</tr>

<tr>
<td>BACKOUTS </td>
<td>234(EA) </td>
</tr>
</table>

==Text entries (Type 11, Type 13)==

Type 11 (X'0B') and Type 13 (X'0D') entries record most of the actual text of the audit trail.

===Noncontinued text entries, Type 11 (X'0B')===

Each Type 11 journal entry corresponds to one logical entry in the audit trail, even though it might generate more than one line of physical output in the audit trail. 

The format of a Type 11 entry is shown in the following table: 
<table>
<caption>Noncontinued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'0B'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Subtype indicator:

X'01' = LI line

X'02' = LP line

X'03' = LR line

X'04' = CI line

X'05' = QT line

X'08' = CP line

X'10' = OI line

X'20' = OO line

X'40' = LS line

X'80' = CS line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>

===Possibly continued text entries, Type 13 (X'0D')===

Each Type 13 journal entry corresponds to one, or part of one, logical entry in the audit trail. See the [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Example|Types of audit trail lines]] table for a definition of the line types.

The format of a Type 13 entry is shown in the following table: 
<table>
<caption>Possibly continued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0D'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = US line

X'02' = XX line

X'04' = RK line

X'08' = AD line

X'10' = MS line

X'20' = ER line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td> 14(0E)</td>
<td> 2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td> 16(10)</td>
<td> Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>
Note:
Subtype indicator X'80' summed with any subtype means continuation into the next entry. 

==Initialization entries, Type 12 (X'0C')==

One Type 12 journal entry is written as the first nonheader entry in the journal during initialization. It contains basic information about the run being initialized.

The format of a Type 12 entry is shown in the following table:
<table>
<caption>Initialization entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'001A'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0C'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> —</td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 8</td>
<td> EBCDIC</td>
<td>Version ID (for example, 4.2.0G)</td>
</tr>

<tr>
<td> 20(14)</td>
<td> 2</td>
<td> Binary</td>
<td>Spare for the run</td>
</tr>

<tr>
<td> 22(16)</td>
<td> 4</td>
<td> EBCDIC</td>
<td>SMF ID (SYSID parameter) </td>
</tr>
</table>

==Time-stamp entries, Type 14 (X'0E')==

Type 14 entries are used to force time-stamps to the journal. 

The format of a Type 14 entry is shown in the following table: 
<table>
<caption>Time-stamp entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td>2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0E'</td>
</tr>

<tr>
<td>3(3)</td>
<td> 1</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td>4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Merged journal bracketing entries (Type 15)==

Type 15 entries appear only in the output of the MERGEJ utility. See [[System and media recovery#Using the MERGEJ utility|Using the MERGEJ utility]]. 

The format of a Type 15 entry is shown in the following table:
<table>
<caption>Merged journal bracketing entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'002E'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0F'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = begin bracket

X'02' = end bracket
</td>
</tr>

<tr>
<td> 4(4)</td>
<td>12(0C)</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td>2(2)</td>
<td> Binary </td>
<td>Number of journals merged together</td>
</tr>

<tr>
<td> 18(12)</td>
<td>28(1C)</td>
<td>EBCDIC</td>
<td>Text:
<ul>
<li>For subtype X'01' = BEGINNING OF MERGED JOURNAL</li>

<li>For subtype X'02' = END OF MERGED JOURNAL</li>
</ul>
</td></tr>
</table>

==System Management Facilities==

You can write certain statistics to the System Management Facilities (SMF) data set by: 
<ul>
<li>Setting the <var>[[SMFSLRN parameter|SMFSLRN]]</var> and <var>[[SMFLORN parameter|SMFLORN]]</var> parameters on the User 0 command line to activate the SMF feature. (z/OS and z/VM)</li>

<li>Modifying the program that processes the SMF data set to handle the records written by <var class="product">Model 204</var>. (z/VM only)</li>
</ul>

See the [[#z/VM requirements|z/VM requirements]] and the the [[#z/OS requirements|z/OS requirements]] sections for details.

Since-last statistics or logout statistics can be written concurrently with statistics that are written to the journal. Logout statistics are more complete than since-last statistics. Many more since-last records than logout records are usually written. 

If the operating system crashes before a user logs out, the SMF data set has a since-last record for every request run, but no logout record. 

File and system statistics cannot be written to the SMF data set.

During system initialization, <var class="product">Model 204</var> issues a message reporting the SMF system ID, the run's job name, the step name, and the JES ID. For operating systems other than z/OS, the JES ID is blank.

===z/VM requirements===

In the CMS interface to <var class="product">Model 204</var>, you can incorporate a user-written accounting exit that invokes the ACCTEXIT routine to process each statistics record as it is written. The following considerations apply:
<ul>
<li>Take care to preserve the CMS environment in which <var class="product">Model 204</var> is running. Do not change the contents of general registers 13 and 14.</li>

<li>You must specify the <var>SMFLORN</var> and/or <var>SMFSLRN</var> parameters on User 0's parameter line to activate accounting record production.</li>

<li>TEXT file for the ACCTEXIT module must be available on an accessed disk when generating M204CMS using M204GEN. For complete installation procedures, see the <var class="book">Rocket Model 204 z/VM Installation Guide</var>.</li>
</ul>

===z/OS requirements===

To write since-last SMF records in a z/OS environment, activate the SMF feature. 

To activate SMF, set the following parameters on User 0's parameter line: 
<ul>
<li>SMFSLRN — SMF record number for since-last records</li>

<li>SMFLORN — SMF record number for logout records </li>
</ul>

The following considerations apply:
<ul>
<li>Since-last SMF records are written only if the SMFSLRN parameter is set to a non-zero value at the beginning of the run.</li>

<li>Logout SMF records are written only if the SMFLORN parameter is set to a non-zero value at the beginning of the run.</li>

<li>If both parameters are set, each type of record is written.</li>
</ul>

SMF record numbers, which identify the record type to the programs that process the SMF data set, are written as part of the header of the SMF records. The record numbers must be between 128 and 255.

See the "System Management Facility record layout and statistics" section, which follows.

==System Management Facility record layout and statistics==

===SMF logout record layout===

The following table shows the basic format of the <var class="product">Model 204</var> SMF logout record: 
<table>
<caption>Basic format of Model 204 SMF logout record</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length</th>
<th> Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td>2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td>4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td>5(5)</td>
<td> 1</td>
<td>Record number (<var>SMFSLRN</var> or <var>SMFLORN</var>)</td>
</tr>

<tr>
<td>6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td> 1</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: x'4C'
For V7.7: x'4D'
For V7.8: x'4E'
</td>
</tr>

<tr>
<td>58(3A)</td>
<td> 2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable
4-character field retrieved from the SMF control area.

The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.
</li>
</ul>

====Offsets for SMF logout record statistics====

The following table shows the layout of SMF logout record statistics. Each statistic in the table is: Length, 4 (bytes); data type, Binary.
This record has the same statistics in the same order as the CCAJRNL logout record, only the offsets are different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]] table.
<table>
<caption>Offset location of SMF logout record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>60(3C) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 64(40) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 68(44) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 72(48) </td>
<td>SQRD</td>
</tr>

<tr>
<td> 76(4C) </td>
<td>SQWR</td>
</tr>

<tr>
<td> 80(50) </td>
<td>SGMTI</td>
</tr>

<tr>
<td> 84(54) </td>
<td>SGMTO</td>
</tr>

<tr>
<td> 88(58) </td>
<td>SVRD</td>
</tr>

<tr>
<td> 92(5C) </td>
<td>SVWR</td>
</tr>

<tr>
<td> 96(60) </td>
<td>CPU</td>
</tr>

<tr>
<td>100(64) </td>
<td>REQ</td>
</tr>

<tr>
<td>104(68) </td>
<td>MOVE</td>
</tr>

<tr>
<td>108(6C) </td>
<td>DUMP</td>
</tr>

<tr>
<td>112(70) </td>
<td>REST</td>
</tr>

<tr>
<td>116(74) </td>
<td>SLIC</td>
</tr>

<tr>
<td>120(78) </td>
<td>AUDIT</td>
</tr>

<tr>
<td>124(7C) </td>
<td>WAIT</td>
</tr>

<tr>
<td>128(80) </td>
<td>FBWT</td>
</tr>

<tr>
<td>132(84) </td>
<td>UDD</td>
</tr>

<tr>
<td>136(88) </td>
<td>RECADD</td>
</tr>

<tr>
<td>140(8C) </td>
<td>RECDEL</td>
</tr>

<tr>
<td>144(90) </td>
<td>BADD</td>
</tr>

<tr>
<td>148(94) </td>
<td>BDEL</td>
</tr>

<tr>
<td>152(98) </td>
<td>BCHG</td>
</tr>

<tr>
<td>156(9C) </td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td>164(A4) </td>
<td>FINDS</td>
</tr>

<tr>
<td>168(A8) </td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC) </td>
<td>RECDS</td>
</tr>

<tr>
<td>176(B0) </td>
<td>STRECDS</td>
</tr>

<tr>
<td>180(B4) </td>
<td>DKAR</td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKPR</td>
</tr>

<tr>
<td>188(BC) </td>
<td>DKRR</td>
</tr>

<tr>
<td>192(C0) </td>
<td>COMMITS</td>
</tr>

<tr>
<td>196(C4) </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>200(C8) </td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>204(CC) </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>208(D0) </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>212(D4) </td>
<td>SMPLS</td>
</tr>

<tr>
<td>216(D8) </td>
<td>RUNG</td>
</tr>

<tr>
<td>220(DC) </td>
<td>REDY</td>
</tr>

<tr>
<td>224(E0) </td>
<td>BLKI</td>
</tr>

<tr>
<td>228(E4) </td>
<td>WTSV</td>
</tr>

<tr>
<td>232(E8) </td>
<td>BLKO</td>
</tr>

<tr>
<td>236(EC) </td>
<td>SWPG</td>
</tr>

<tr>
<td>240(F0) </td>
<td>PCPU</td>
</tr>

<tr>
<td>244(F4) </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>248(F8) </td>
<td>BXCHNG</td>
</tr>

<tr>
<td>252(FC) </td>
<td>BXDELE</td>
</tr>

<tr>
<td>256(100) </td>
<td>BXNEXT</td>
</tr>

<tr>
<td>260(104)</td>
<td>BXFIND</td>
</tr>

<tr>
<td>264(108)</td>
<td>BXINSE</td>
</tr>

<tr>
<td>268(10C)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td>272(110)</td>
<td>BXFND</td>
</tr>

<tr>
<td>276(114)</td>
<td>BXFREE</td>
</tr>

<tr>
<td>280(118)</td>
<td>STCPU</td>
</tr>

<tr>
<td>284(11C)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>288(120)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>292(124)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>296(128)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>300(12C)</td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>312(138)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>344(158)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>348(15C)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>352(160)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>380(17C)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>384(180)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>388(184)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>392(188)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>400(190)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>404(194)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>408(198)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>412(19C)</td>
<td>Spare </td>
</tr>

<tr>
<td>416(1A0)</td>
<td>Spare</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>Spare</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>Spare</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>Spare</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>Spare</td>
</tr>
</table>

===SMF since-last record layout===

The following table shows the basic format of since-last <var class="product">Model 204</var> SMF records. 
<table>
<caption>Since-last record basic format</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length (bytes)</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td> 5(5)</td>
<td> 1</td>
<td>Record number (SMFSLRN)</td>
</tr>

<tr>
<td> 6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td>1</td>
<td>SMFSLTYP - X'01' if CRFJRNL=1 (conflict counters present)

SMFSLTYP - X'00' if CRFJRNL=0 (conflict counters not present)
</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: <code>x'4C'</code>
For V7.7: <code>x'4D'</code>
For V7.8: <code>x'4E'</code>
</td>
</tr>

<tr>
<td>58(3A)</td>
<td>2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> 4</td>
<td>Since-last type (EVAL CMPL DUMP REST...)</td>
</tr>

<tr>
<td>64(40)</td>
<td> 8</td>
<td>File name</td>
</tr>

<tr>
<td>72(48)</td>
<td>10</td>
<td>Since-last subsystem name</td>
</tr>

<tr>
<td>82(52)</td>
<td>40</td>
<td>Since-last procedure name</td>
</tr>

<tr>
<td>122(7A)</td>
<td>2</td>
<td>Reserved two bytes</td>
</tr>

<tr>
<td>124(7C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable 4-character field retrieved from the SMF control area.</li>

<li>The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.</li>
</ul>

====Offsets for SMF since-last record statistics====

The following table shows the layout of SMF since-last record statistics. Each statistic in the table is: Length, 4 (bytes); Data type, Binary.
This record has the same statistics in the same order as the CCAJRNL user since-last records; only the offsets are
different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]]
table. 
<table>
<caption>SMF since-last record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td> 124(7C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 128(80)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 132(84)</td>
<td>QTBL</td>
</tr>

<tr>
<td> 136(88) </td>
<td>STBL</td>
</tr>

<tr>
<td> 140(8C)</td>
<td>TTBL</td>
</tr>

<tr>
<td> 144(90)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 148(94)</td>
<td>PDL</td>
</tr>

<tr>
<td> 152(98)</td>
<td>FTBL</td>
</tr>

<tr>
<td> 156(9C)</td>
<td>XTBL</td>
</tr>

<tr>
<td> 160(A0)</td>
<td>ITBL</td>
</tr>

<tr>
<td> 164(A4)</td>
<td>FSCB</td>
</tr>

<tr>
<td> 168(A8)</td>
<td>OUTPB</td>
</tr>

<tr>
<td> 172(AC) </td>
<td>HEAP</td>
</tr>

<tr>
<td> 176(B0) </td>
<td>SQLI</td>
</tr>

<tr>
<td> 180(B4) </td>
<td>SQLO</td>
</tr>

<tr>
<td> 184(B8) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 188(BC) </td>
<td>CPU</td>
</tr>

<tr>
<td> 192(C0) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 196(C4) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 200(C8) </td>
<td>UDD</td>
</tr>

<tr>
<td> 204(CC) </td>
<td>OUT</td>
</tr>

<tr>
<td> 208(D0) </td>
<td>SLIC</td>
</tr>

<tr>
<td> 212(D4) </td>
<td>IN</td>
</tr>

<tr>
<td> 216(D8) </td>
<td>RECADD</td>
</tr>

<tr>
<td> 220(DC) </td>
<td>RECDEL</td>
</tr>

<tr>
<td> 224(E0) </td>
<td>BADD</td>
</tr>

<tr>
<td> 228(E4) </td>
<td>BDEL</td>
</tr>

<tr>
<td> 232(E8) </td>
<td>BCHG</td>
</tr>

<tr>
<td> 236(EC) </td>
<td>IXADD</td>
</tr>

<tr>
<td> 240(F0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td> 244(F4) </td>
<td>FINDS</td>
</tr>

<tr>
<td> 248(F8) </td>
<td>SORT</td>
</tr>

<tr>
<td> 252(FC) </td>
<td>RECDS</td>
</tr>

<tr>
<td> 256(100)</td>
<td>STRECDS</td>
</tr>

<tr>
<td> 260(104)</td>
<td>PCPU</td>
</tr>

<tr>
<td> 264(108)</td>
<td>RQTM</td>
</tr>

<tr>
<td> 268(10C)</td>
<td>DIRRCD</td>
</tr>

<tr>
<td> 272(110)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td> 276(114)</td>
<td>BXDELE</td>
</tr>

<tr>
<td> 280(118)</td>
<td>BXNEXT</td>
</tr>

<tr>
<td> 284(11C)</td>
<td>BXFIND</td>
</tr>

<tr>
<td> 288(120)</td>
<td>BXINSE</td>
</tr>

<tr>
<td> 292(124)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td> 296(128)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 300(12C)</td>
<td>BXFREE</td>
</tr>

<tr>
<td> 304(130)</td>
<td>STCPU</td>
</tr>

<tr>
<td> 308(134)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 312(138)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 316(13C)</td>
<td>SCREENS</td>
</tr>

<tr>
<td> 320(140)</td>
<td>SVRD</td>
</tr>

<tr>
<td> 324(144)</td>
<td>SVWR</td>
</tr>

<tr>
<td> 328(148)</td>
<td>DKPR</td>
</tr>

<tr>
<td> 332(14C)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>336(150)</td>
<td>COMMITS</td>
</tr>

<tr>
<td>340(154)</td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>344(158)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>348(15C)</td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>352(160)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>368(170)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>372(174)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>376(178)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>380(17C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>384(180)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>388(184)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>392(188)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>396(18C)</td>
<td>MAPICNT</td>
</tr>

<tr>
<td>400(190)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>404(194)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>408(198)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>412(19C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>444(1BC)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>448(1C0)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>452(1C4)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>456(1C8)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>460(1CC)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>464(1D0)</td>
<td>Sirius</td>
</tr>

<tr>
<td>468(1D4)</td>
<td>Sirius</td>
</tr>

<tr>
<td>472(1D8)</td>
<td>Sirius</td>
</tr>

<tr>
<td>476(1DC)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>480(1E0)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>484(1E4)</td>
<td>Spare</td>
</tr>

<tr>
<td>488(1E8)</td>
<td>Spare</td>
</tr>
</table>

The following table lists the conflict statistics, if <code>CFRJRNL=1</code>:

<table>
<caption>Conflict statistics, if CFRJRNL=1</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td>492(1EC)</td>
<td>BLKCFRE</td>
</tr>

<tr>
<td>496(1F0)</td>
<td>BLKRLK</td>
</tr>

<tr>
<td>500(1F4)</td>
<td>WTCFR</td>
</tr>

<tr>
<td>504(1F8)</td>
<td>WTRLK</td>
</tr>
</table>

[[Category:System management]]
[[Category:System-level capabilities of Model 204]]

Using system statistics

2026-02-24T21:56:46Z

Goff: /* BUF and FMX are obsolete from V78 */

==Overview==

The tables on this page are provided for your use in identifying and tracking statistics that are reported by <var class="product">Model 204</var> in various situations. The offsets, given in decimal and hexadecimal, are to help you locate particular statistics within statistical output. The length is in bytes.

The statistics are collected in the [[Tracking_system_activity_(CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAJRNL|CCAJRNL]] data set, or if allocated, in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAAUDIT and CCAJLOG|CCAJLOG]]. The offsets in the tables below locate each statistic in the corresponding record. To accommodate sites that need to run <var class="product">Model 204</var> around the clock for many days at a time, space for most <var class="product">Model 204</var> statistics is a double word.

==Description of statistics==

The "Statistics with descriptions" table lists the statistics that are collected and that you can evaluate. It also describes the purpose of each statistic followed by the circumstances when you can collect the information and an offset in the journal record. 

To collect several statistics you must preset a parameter to a nonzero value. Statistics that require a parameter are also noted in the "Statistics with descriptions" table. The table in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Setting parameters to collect certain statistics]] lists those statistics with the required parameter. 

Tables, identified by type, later in this topic, describe the layouts of the various journal records.
<table>
<caption style="margin-right:4em">Statistics with descriptions</caption>
<tr class="head">
<th>Statistic </th>
<th>Records...</th>
</tr>

<tr>
<td>APSYLD</td>
<td>Number of APSY loads</td>
</tr>

<tr>
<td>APSYLDD</td>
<td>Number of APSY loads from a dataspace</td>
</tr>

<tr>
<td>APSYLDT</td>
<td>Number of tiny APSY loads</td>
</tr>

<tr>
<td>AUDIT</td>
<td>Number of lines written to the journal and/or the audit trail</td>
</tr>

<tr>
<td>BACKOUTS</td>
<td>Number of BACKOUTs</td>
</tr>

<tr>
<td>BADD</td>
<td>Number of fields added to Table B</td>
</tr>

<tr>
<td>BCHG</td>
<td>Number of fields changed in Table B</td>
</tr>

<tr>
<td>BDEL</td>
<td>Number of fields deleted from Table B</td>
</tr>

<tr>
<td>BLKCFRE</td>
<td>Number of times user held a critical file resource (CFR) exclusively and forced another user to wait

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKI</td>
<td>Percentage of performance samples at which the user was in a server but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKO</td>
<td>Percentage of performance samples at which the user was swapped out to the server data set but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKRLK</td>
<td>Number of times user was the first user identified as blocking another from obtaining a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BXCHNG</td>
<td>Number of value entries changed in the ordered index. This occurs when a record number is added to or removed from an existing value entry.</td>
</tr>

<tr>
<td>BXDELE</td>
<td>Number of value entries deleted from the ordered index</td>
</tr>

<tr>
<td>BXFIND</td>
<td>Number of ordered index searches to locate field name=value pairs in the ordered index</td>
</tr>

<tr>
<td>BXFREE</td>
<td>Number of ordered index pages (nodes) emptied and released from the ordered index</td>
</tr>

<tr>
<td>BXINSE</td>
<td>Number of new value entries inserted into the ordered index</td>
</tr>

<tr>
<td>BXNEXT</td>
<td>Number of value entries touched in the ordered index during a range retrieval</td>
</tr>

<tr>
<td>BXRFND</td>
<td>Number of times the cursor was repositioned in the ordered index during a search</td>
</tr>

<tr>
<td>BXSPLI</td>
<td>Number of Table D pages (nodes) split in the ordered index</td>
</tr>

<tr>
<td>CCATDIFF</td>
<td>Difference between CCATEMP pages allocated and freed by a thread. This is an imperfect indicator of the number of CCATEMP pages a thread has allocated. CCATDIFF is imperfect because it is difficult to fully account for pages allocated or freed on behalf of the system or other users. However, if there is an acute CCATEMP page shortage, threads with high CCATDIFF values are likely culprits.

CCATDIFF is available in Model 204 7.7 and higher.</td>
</tr>

<tr>
<td>CCATDIFH</td>
<td>High water mark of CCATDIFF in a request. This can be useful if a request allocated a lot of CCATEMP pages, causing an acute shortage but then freed those pages.

CCATDIFH is available in Model 204 7.7 and later.</td>
</tr>

<tr>
<td>CDLWAIT</td>
<td>Number of constraint dependency lock waits</td>
</tr>

<tr>
<td>CNCT</td>
<td>Elapsed time in seconds</td>
</tr>

<tr>
<td>COMMITS</td>
<td>Number of <var>COMMIT</var>s</td>
</tr>

<tr>
<td>CPU</td>
<td>Total CPU time consumed in milliseconds. The system CPU statistics include both maintask and subtask CPU usage.</td>
</tr>

<tr>
<td>CPUONZIP</td>
<td>Total CPU time consumed in milliseconds on zIIP engines</td>
</tr>

<tr>
<td>CPUTOTZE</td>
<td>Total CPU time consumed in milliseconds by workloads eligible for offload to zIIP engines</td>
</tr>

<tr>
<td>DEQ</td>
<td>Total number of units of work taken by the MAINTASK and each MP and zIIP subtask, regardless of the queue that the work was taken from. Reported at <var class="product">Model 204</var> termination or in <var>[[MONITOR TASKS command|MONITOR TASKS]]</var> output.

(type Subtask)
</td>
</tr>

<tr>
<td>DEV#</td>
<td>used the MXI interface to hold the IODEV type ( e.g. 7 for IODEV7 )</td>
</tr>

<tr>
<td>DEV5</td>
<td>Output lines to procedures defined during the run</td>
</tr>

<tr>
<td>DEV6</td>
<td>Input lines from included procedures</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly VTAM) 3270s</td>
</tr>

<tr>
<td>DEV8</td>
<td>Input lines from SNA Communications Server 3270s</td>
</tr>

<tr>
<td>DEV9</td>
<td>Page headers or trailers defined in requests</td>
</tr>

<tr>
<td>DEV10</td>
<td>Output lines written to directed output (USE) data sets</td>
</tr>

<tr>
<td>DEV11</td>
<td>Output lines to remote User Language full screen</td>
</tr>

<tr>
<td>DEV12</td>
<td>Input lines from a remote User Language full screen</td>
</tr>

<tr>
<td>DEV13</td>
<td>Output lines to remote SQL</td>
</tr>

<tr>
<td>DEV14</td>
<td>Input lines from remote SQL</td>
</tr>

<tr>
<td>DEV17</td>
<td>Output lines to SQL CRAM IUCU</td>
</tr>

<tr>
<td>DEV18</td>
<td>Input lines from SQL CRAM</td>
</tr>

<tr>
<td>DEV19</td>
<td>Output lines to remote SQL LU62</td>
</tr>

<tr>
<td>DEV20</td>
<td>Input lines from remote SQL LU62</td>
</tr>

<tr>
<td>DEV23</td>
<td>Input lines to CRAM IFAM</td>
</tr>

<tr>
<td>DEV24</td>
<td>Input lines from CRAM IUCU thread</td>
</tr>

<tr>
<td>DEV27</td>
<td>Terminal error messages issued for inbound Distributed Application Facility conversations</td>
</tr>

<tr>
<td>DEV28</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV31</td>
<td><var>IFDISP</var> output lines to IFAM1 programs</td>
</tr>

<tr>
<td>DEV32</td>
<td>Input arguments supplied by certain IFAM1 calls</td>
</tr>

<tr>
<td>DEV37</td>
<td>Output lines to SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV38</td>
<td>Input lines from SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV49</td>
<td>output lines to Remote Command line applications( rate or total)</td>
</tr>

<tr>
<td>DEV50</td>
<td>Lines sent to the printer when ROUTER=CICS</td>
</tr>

<tr>
<td>DEV53</td>
<td>Output lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV54</td>
<td>Input lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV55</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV56</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV57</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV58</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV59</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV60</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV61</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV62</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV63</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM parameter|MONPARM]] system parameter.</td>
</tr>

<tr>
<td>DEV64</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV65</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV66</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV67</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV68</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV69</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly
VTAM) 3270s</td>
</tr>

<tr>
<td>DEV70</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV71</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV72</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV73</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV74</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DIRRCD</td>
<td>Number of records searched in direct searches of Table B</td>
</tr>

<tr>
<td>DKAR</td>
<td>Number of buffers allocated without page read requests</td>
</tr>

<tr>
<td>DKPR</td>
<td>Number of requests for a page (may not require real I/O)</td>
</tr>

<tr>
<td>DKPRF</td>
<td>Number of fast logical page reads. Number of DKPRs that were satisfied by pending or deferred close buffers</td>
</tr>

<tr>
<td>DKRD</td>
<td>Number of physical page reads from Model 204 files</td>
</tr>

<tr>
<td>DKRDL</td>
<td>Number of physical page reads into the below the bar buffer pool</td>
</tr>

<tr>
<td>DKRR</td>
<td> Number of real disk reads for recently requested pages
</td>
</tr>

<tr>
<td>DKSAWB</td>
<td> Anticipatory writes from the bottom of the LRU queue. The page in the buffer is then deleted and no longer available without a re-read. Usually a small statistic and typically only incremented by a few rare events.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWBL</td>
<td> Same as DKSAWB but only incremented for anticipatory writes from below the bar

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWW</td>
<td> Anticipatory writes from the anticipatory write windows set by LDKBMWND and/or LDKBMWNG

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWWL</td>
<td>Same as DKSAWW but only incremented for anticipatory writes from below the bar</td>
</tr>

<tr>
<td>DKSDIR</td>
<td> High-water mark of modified (dirty) buffers found within the DKBM statistics window which is created by the <var>LDKBMW</var> parameter. This parameter is not recommended due to the extremely heavy performance penalty imposed by a non-zero value.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSDIRT</td>
<td> The total of all modified buffers found within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSFBS</td>
<td> Times a buffer was needed, and a scan was necessary, because the oldest free buffer was not immediately available

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIP</td>
<td> The highest number of buffers skipped during any search for a free buffer. A buffer is skipped because it is not immediately available.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIPT</td>
<td> The total of all buffers skipped when looking for a free buffer

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRR</td>
<td> Number of times a page that was expected to be in the buffer pool could not be located, which necessitates a physical I/O to disk

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRRFND</td>
<td>Number of times that a page that was expected to be in the buffer pool was located there, which eliminates the need for a physical I/O</td>
</tr>

<tr>
<td>DKSTBLA</td>
<td> Table A reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLB</td>
<td> Table B reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLC</td>
<td> Table C reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLD</td>
<td> Table D reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DSKTBLE</td>
<td> Table E reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLF</td>
<td> FCT reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTKQC</td>
<td> Times the current Table B page had to be closed to allow a fourth buffer to be opened

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSWRP</td>
<td> The highwater mark of buffers with writes outstanding within the DKBM statistics window, created by the parameter LDKBMW. Rocket Software advises against setting this parameter to a non-zero value due to the extreme performance penalty imposed.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSWRPT</td>
<td> The total number of buffers with outstanding writes within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKUPTIME</td>
<td>Milliseconds of DKUPDT time</td>
</tr>

<tr>
<td>DKWR</td>
<td>Number of physical page writes to <var class="product">Model 204</var> files</td>
</tr>

<tr>
<td>DKWRL</td>
<td>Number of physical page writes from the below the bar pool</td>
</tr>

<tr>
<td>DKWTMICS</td>
<td>Total wait time in microseconds for Disk I/O waits counted by DKWTS.
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DKWTS</td>
<td>Number Disk I/O waits
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DUMP</td>
<td>Writes to <var class="product">Model 204</var> file backups (DUMP command output)</td>
</tr>

<tr>
<td>DUPDTS</td>
<td>Records written to a deferred update data set for the file</td>
</tr>

<tr>
<td>ECCALL</td>
<td>Number of External Call Facility calls</td>
</tr>

<tr>
<td>ECCNCT</td>
<td>External Call Facility - Elapsed time for external program</td>
</tr>

<tr>
<td>ECCTOUT</td>
<td>Number of External Call Facility calls that timed out (program or subtask unavailable)</td>
</tr>

<tr>
<td>ECCWAITM</td>
<td>ECF – Number of calls that waited for module to become available</td>
</tr>

<tr>
<td>ECCWAITS</td>
<td>Number of External Call Facility calls that waited for a subtask to become available</td>
</tr>

<tr>
<td>ECDELETE</td>
<td>Number of EXTERNAL DELETE calls to External Call Facility</td>
</tr>

<tr>
<td>ECLOAD</td>
<td>Number of EXTERNAL LOAD calls to External Call Facility</td>
</tr>

<tr>
<td>ECMODMAX</td>
<td>ECF – Highwater mark of modules loaded</td>
</tr>

<tr>
<td>ECNAMMAX</td>
<td>External Call Facility – High-water mark of call names defined</td>
</tr>

<tr>
<td>ECTSKMAX</td>
<td>External Call Facility – High-water mark of subtasks active</td>
</tr>

<tr>
<td>ECTWAITM</td>
<td>External Call Facility – Elapsed time spent waiting for a module to become available</td>
</tr>

<tr>
<td>ECTWAITS</td>
<td>External Call Facility – Elapsed time spent waiting for a subtask to become available</td>
</tr>

<tr>
<td>ERRPDL</td>
<td>Highwater mark of the system pushdown list</td>
</tr>

<tr>
<td>FBMX</td>
<td>Disk buffer HWM
Obsolete from V7.8, see: [[Release_notes_for_Model_204_version_7.8#BUF_and_FBMX_stats_removed|BUF and FBMX stats removed]].
</td>
</tr>

<tr>
<td>FBWT</td>
<td>Number of waits for a disk buffer</td>
</tr>

<tr>
<td>FINDS</td>
<td>Number of FIND statements evaluated</td>
</tr>

<tr>
<td>FSCB</td>
<td>High-water mark of bytes used in the FSCB</td>
</tr>

<tr>
<td>FSCBSW</td>
<td>Number of full-screen buffer swaps</td>
</tr>

<tr>
<td>FTBL</td>
<td>Highwater mark of FTBL appearing in CMPL and EVAL lines for requests containing a field name reference in group context. If one or more groups are opened but no field name references are made, the portion of FTBL used by the open groups is not reported.</td>
</tr>

<tr>
<td>GTBL</td>
<td>Highwater mark of GTBL</td>
</tr>

<tr>
<td>GTBLRS</td>
<td>Number of GTBL rearrangements required to add a global object</td>
</tr>

<tr>
<td>GTBLRU</td>
<td>Number of GTBL rearrangements required to add a global string variable</td>
</tr>

<tr>
<td>HEAP</td>
<td>Dynamic memory highwater mark</td>
</tr>

<tr>
<td>HRDRSTRT</td>
<td>number of hard restarts</td>
</tr>

<tr>
<td>IMGCBYTR</td>
<td>Number of bytes of data received from Imagine Transparency brokers for calls to non-transparency code running on the broker (rate or total). The calls can be for transpiled SOUL or COBOL code, or service programs</td>
</tr>

<tr>
<td>IMGCBYTS</td>
<td>Number of bytes of data sent to Imagine Transparency brokers for for calls to non-transparency code running on the broker (rate or total). The calls can be for transpiled SOUL or COBOL code, or IMGCBYTS service programs</td>
<tr>

<tr>
<td>IMGCCPU</td>
<td>Number of seconds of CPU used by Imagine Transparency brokers for calls to non-transparency code running on the broker (rate or total). The calls can be for transpiled SOUL or COBOL code, or service programs</td>
</tr>

<tr>
<td>IMGCREQ</td>
<td>Number of requests sent from M204 to a broker for calls to non-transparency code running on the brokers (rate or total). This is essentially the number of interactions between M204 and the brokers for non-transparency processing (transpiled code and service programs)</td>
</tr>

<tr>
<td>IMGCWT</td>
<td>Number of seconds spent by M204 waiting for a response from the Imagine Transparency brokers for non-transparency requests (transpiled code and service programs) (rate or total). IMGCWT is composed of IMGCCPU (CPU time used on the broker), IMGCWTD (time the broker spent waiting for the Imagine DatabaseStore, mostly for finds and commits), and everything else. The most likely cause of "everything else" is network delays</td>
</tr>

<tr>
<td>IMGCWTD</td>
<td>Number of seconds spent by Imagine Transparency brokers waiting for the Imagine DatabaseStore for non-transparency requests (transpiled code and service programs), mostly for finds and commits (rate or total)</td>
</tr>

<tr>
<td>IMGTBYTR</td>
<td>Number of bytes of data received from Imagine Transparency brokers for transparency requests (rate or total)</td>
</tr>

<tr>
<td>IMGTBYTS</td>
<td>Number of bytes of data sent to Imagine Transparency brokers for transparency requests (rate or total)</td>
</tr>

<tr>
<td>IMGTCPU</td>
<td>Number of seconds of CPU used by Imagine Transparency brokers for transparency requests (rate or total)</td>
</tr>

<tr>
<td>IMGTFDH</td>
<td>Number of finds against Imagine files that could be serialized for duplicate find testing and a duplicate find was found (rate or total). Since Imagine guarantees identical results for identical finds in the same transaction (if no candidate files were updated) the result of the previous find can be used in the case of a duplicate, eliminating an interaction with the broker and all the overhead that entails. The H in IMGTFDH stands for Hits. It can be useful to compare IMGTFDH with IMGTFND (finds sent to the broker) to determine the percentage of finds that were essentially optimized away as duplicates</td>
</tr>

<tr>
<td>IMGTFDS</td>
<td>Number of finds against Imagine files that could be serialized for duplicate find testing (rate or total). A find might not be serializable if it is too complicated or references too many files (in a group). Any find that can't be serialized must be sent to the broker to be processed, even if an identical find has already been done in the same transaction</td>
</tr>

<tr>
<td>IMGTFDU</td>
<td>Number of finds against Imagine files that could be serialized for duplicate find testing, and a duplicate find was found, but could not be used because one or more files in the find had been updated since the previous find (rate or total). In such a case, the find must be sent to the broker to be reprocessed</td>
</tr>

<tr>
<td>IMGTFND</td>
<td>Number of finds against Imagine files that were sent to the broker to be processed (rate or total). This does not include duplicate finds whose results could be reused on M204 (counted by IMGTFDH)</td>
</tr>

<tr>
<td>IMGTREC</td>
<td>Number of Imagine records sent from the broker to M204 (rate or total). This includes "prefetched" records that are counted by IMGTRECP</td>
</tr>

<tr>
<td>IMGTRECP</td>
<td>Number of Imagine records sent from the broker to M204 before they were explicitly accessed (like in a FOR RECORD LOOP), so "prefetched". One example of this is that after a find on the
broker, the first IMGPREF (user parameter) records would be sent back to M204 with the find results</td>
</tr>

<tr>
<td>IMGTREQ</td>
<td>Number of requests sent from M204 to a broker for transparency processing (rate or total). This is essentially the number of interactions between M204 and the brokers for transparency
processing</td>
</tr>

<tr>
<td>IMGTWT</td>
<td>Number of seconds spent by M204 waiting for a response from the Imagine Transparency brokers for transparency requests (rate or total). IMGTWT is composed of IMGTCPU (CPU time used on the broker), IMGTWTD (time the broker spent waiting for the Imagine DatabaseStore, mostly for finds and commits), and everything else. The most likely cause of "everything else" is network delays</td>
</tr>

<tr>
<td>IMGTWTD</td>
<td>Number of seconds spent by Imagine Transparency brokers waiting for the Imagine DatabaseStore for transparency requests, mostly for finds and commits (rate or total)</td>
</tr>

<tr>
<td>IN</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>INCMFS</td>
<td>Input lines from CMS full screen</td>
</tr>

<tr>
<td>INCMIO</td>
<td>Input lines from CMS non-full screen</td>
</tr>

<tr>
<td>INCRAM</td>
<td>Input lines from Remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>INVMFS</td>
<td>Input lines from IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>INVMIF</td>
<td>Input arguments supplied by certain IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>INVMIO</td>
<td>Input lines from IUCV or VMCF non-full screen thread</td>
</tr>

<tr>
<td>INXX</td>
<td>Input lines from QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>ITBL</td>
<td>Highwater mark of ITBL</td>
</tr>

<tr>
<td>IXADD</td>
<td>Number of index entries added to Tables C and D, including attempts to add duplicates</td>
</tr>

<tr>
<td>IXDEL</td>
<td>Number of entries deleted from Tables C and D</td>
</tr>

<tr>
<td>JSCREENS</td>
<td>Counts the number of times Janus Web incremented the SCREENS statistic. Since these may occur outside of request context, they would not necessarily have corresponding Since-Last statistics.</td>
</tr>

<tr>
<td>JWEBERRS</td>
<td>Counts the number of times that Janus Web returned a 4xx status code. Note that these would not be counted in the SCREENS statistic, but it is handy to know that for example a bunch of 404 or 401 errors are occurring.</td>
</tr>

<tr>
<td>LKPOST</td>
<td>Times an MP subtask posted another task to indicate that an MP lock had become available</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>Times MP subtasks invoked z/OS WAIT macros to wait for an available MP lock</td>
</tr>

<tr>
<td>LONGUPDTIME(MS)</td>
<td> Total milliseconds of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LONGUPDTS</td>
<td> Number of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LWTIM</td>
<td>Elapsed time (ms), spent waiting for a multiprocessing lock. Reported for each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals).</td>
</tr>

<tr>
<td>MAXIOX</td>
<td>Number of times <var class="product">Model 204</var> waited for a free database buffer</td>
</tr>

<tr>
<td>MBO</td>
<td>Highwater mark of transaction backout pages

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MCP
</td>
<td>Highwater mark of transaction checkpoint spans

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MOVE</td>
<td>Number of times the scheduler switched from one user to another</td>
</tr>

<tr>
<td>MPHASHD</td>
<td>MP duplicate hash entries found</td>
</tr>

<tr>
<td>MPLKPREM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting due to operating system preemption.

This is the elapsed time between when an MP lock becomes available (lock post) making a task ready to run, and when the task actually gets the CPU. That preemption delay is caused by the operating system dispatching other tasks ahead of this task.

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPLKWTIM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting for MP locks

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPR</td>
<td>Highwater mark of transaction pre-images

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MQAPICNT</td>
<td>MQ/204 – Count of MQ/Series API calls</td>
</tr>

<tr>
<td>MQAPITIM </td>
<td>MQ/204 – Elapsed time of MQSeries API calls</td>
</tr>

<tr>
<td>MQBYTEIN</td>
<td>MQ/204 – Total bytes retrieved (MQGET)</td>
</tr>

<tr>
<td>MQBYTEOU</td>
<td>MQ/204 – Total bytes sent (MQPUT/MQPUT1)</td>
</tr>

<tr>
<td>MQGETS</td>
<td>MQ/204 – Number of MQGETs performed</td>
</tr>

<tr>
<td>MQGWTCNT</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTSUC</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait that succeeded</td>
</tr>

<tr>
<td>MQGWTTIM</td>
<td>MQ/204 – Elapsed time for MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTTSP</td>
<td>MQ/204 – Total wait time specified on MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQHWQU</td>
<td>MQ/204 – High-water mark of queues concurrently in use</td>
</tr>

<tr>
<td>MQHWTASK</td>
<td>MQ/204 – High-water mark of MQ/204 subtasks in use</td>
</tr>

<tr>
<td>MQNUMQM</td>
<td>MQ/204 – Number of distinct queue managers connected</td>
</tr>

<tr>
<td>MQNUMQU</td>
<td>MQ/204 – Number of distinct queues accessed</td>
</tr>

<tr>
<td>MQPUTS</td>
<td>MQ/204 – Number of MQPUTs performed</td>
</tr>

<tr>
<td>MQWTM</td>
<td>Mean queue wait time, the average time a subtask spent waiting for work (waiting for PCBs to come into the offload queue)</td>
</tr>

<tr>
<td>MTDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from the MAINTASK queue and processed it</td>
</tr>

<tr>
<td>MTSDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from an MP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>MTZDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from a zIIP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>NTBL</td>
<td>Highwater mark of NTBL</td>
</tr>

<tr>
<td>OBJSWAP</td>
<td>number of object swaps for Sirius objects</td>
</tr>

<tr>
<td>OFFIN</td>
<td>Count of records read in by the OFFLOAD subtask</td>
</tr>

<tr>
<td>OFFOU</td>
<td>Count of records written to the OFFLOAD stream</td>
</tr>

<tr>
<td>OUT</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>OUTCMFS</td>
<td>Output lines to CMS full-screen thread</td>
</tr>

<tr>
<td>OUTCMIO</td>
<td>Output lines to CMS line-by-line thread</td>
</tr>

<tr>
<td>OUTCRAM</td>
<td>Output lines from remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>OUTPB</td>
<td>Highwater mark of OUTPB</td>
</tr>

<tr>
<td>OUTVMFS</td>
<td>Output lines to IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>OUTVMIF</td>
<td>Output lines to IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>OUTVMIO</td>
<td>Output lines to IUCV or VMCF line-by-line threads</td>
</tr>

<tr>
<td>OUTXX</td>
<td>Output lines to QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>PBRSFLT</td>
<td>Number of private buffer reservation faults</td>
</tr>

<tr>
<td>PCPU</td>
<td>Percentage of time <var class="product">Model 204</var> was given the CPU when it wanted CPU time. In an MP environment, system PCPU is the sum of CPU time in all tasks divided by the sum of elapsed time in all tasks.</td>
</tr>

<tr>
<td>PDL</td>
<td>Highwater mark of the pushdown list</td>
</tr>

<tr>
<td>PETIM</td>
<td>Elapsed time (ms), spent waiting due to OS preemption. Reported for the MAINTASK and each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals)</td>
</tr>

<tr>
<td>PNDGTIME</td>
<td>Milliseconds of unnecessary broken time</td>
</tr>

<tr>
<td>PR</td>
<td>Real time consumed, in milliseconds. PCPU = CPU / PR.</td>
</tr>

<tr>
<td>QTBL</td>
<td>Highwater mark of QTBL</td>
</tr>

<tr>
<td>RCV</td>
<td>Number of blocks needed for subtransaction recovery

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>RECADD</td>
<td>Number of records started in Table B, not including extension records</td>
</tr>

<tr>
<td>RECDEL</td>
<td>Number of records deleted from Table B, not including extension records or records deleted by DELETE RECORDS or IFDSET</td>
</tr>

<tr>
<td>RECDS</td>
<td>Number of records processed by FOR statements, SORT statements, IFGET calls, or IFPOINT calls, or similar SQL record processing</td>
</tr>

<tr>
<td>REDY</td>
<td> Percentage of performance samples at which the user was ready to run (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>REQ</td>
<td>Number of SOUL requests evaluated</td>
</tr>

<tr>
<td>REST</td>
<td>Number of reads from a <var class="product">Model 204</var> file backup (<var>RESTORE</var> command)</td>
</tr>

<tr>
<td>RETRYA</td>
<td>Page retries in Table A</td>
</tr>

<tr>
<td>RETRYC</td>
<td>Page retries in Table C</td>
</tr>

<tr>
<td>RQTM</td>
<td>Elapsed time for the activity being reported, exclusive of terminal I/O time</td>
</tr>

<tr>
<td>RSXCOMP</td>
<td>Number of compactions of the record locking table. If greater than 0, increase <var>LRETBL</var>.</td>
</tr>

<tr>
<td>RUNG</td>
<td> Percentage of performance samples at which the user was running (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SCHDCPU</td>
<td>In MP configuration, total scheduler CPU for the user or request</td>
</tr>

<tr>
<td>SCREENS</td>
<td>Total number of full-screen reads (<var>READ SCREEN</var> statements) evaluated by a SOUL request.</td>
</tr>

<tr>
<td>SFTRSTRT</td>
<td>number of soft restarts.</td>
</tr>

<tr>
<td>SGMTI</td>
<td>Number of input lines from included procedures</td>
</tr>

<tr>
<td>SGMTO</td>
<td>Number of output lines to procedures defined by the user</td>
</tr>

<tr>
<td>SLIC</td>
<td>Number of times that the user was time-sliced by the <var class="product">Model 204</var> scheduler</td>
</tr>

<tr>
<td>SMPLS</td>
<td>Number of performance sample points at which the user was active or total number of performance samples taken at the system level (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SORTS</td>
<td>Number of SOUL <var>SORT</var> statements or SQL sorts evaluated</td>
</tr>

<tr>
<td>SQLI</td>
<td>Remote SQL input highwater mark</td>
</tr>

<tr>
<td>SQLO</td>
<td>Remote SQL output highwater mark</td>
</tr>

<tr>
<td>SQRD</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>SQWR</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>STBL</td>
<td>Highwater mark of STBL</td>
</tr>

<tr>
<td>STCPU</td>
<td>Total amount of time, in milliseconds, that the user has run in an MP offload subtask</td>
</tr>

<tr>
<td>STDEQ</td>
<td>Number of times that an MP subtask took a unit of work from an MP subtask queue and processed it</td>
</tr>

<tr>
<td>STIMERS</td>
<td>Total number of STIMER or STIMERM calls</td>
</tr>

<tr>
<td>STPOST</td>
<td>Times MP subtasks performed real operating system POSTs to send work to the maintask</td>
</tr>

<tr>
<td>STRECDS</td>
<td>Number of records processed by SORT statements or SQL sorts</td>
</tr>

<tr>
<td>STWAIT</td>
<td>Number of times MP subtasks invoked z/OS WAIT macros to wait for work from the maintask</td>
</tr>

<tr>
<td>STZDEQ</td>
<td>Number of times that an MP subtask took a unit of work from a zIIP subtask queue and processed it because the MP subtask was idle</td>
</tr>

<tr>
<td>SVAC</td>
<td>Active servers (an average, included on a performance line)</td>
</tr>

<tr>
<td>SVMX</td>
<td>Highwater mark for servers (0 if no server swapping)</td>
</tr>

<tr>
<td>SVPAGES</td>
<td><code>SVPAGES * 4096</code> is the number of bytes transferred as a result of server reads and writes</td>
</tr>

<tr>
<td>SVRD</td>
<td>Number of server reads</td>
</tr>

<tr>
<td>SVWR</td>
<td>Number of server writes</td>
</tr>

<tr>
<td>SWPG</td>
<td>Percentage of performance samples at which the user was swapping in or out (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>SWT</td>
<td>Times <var class="product">Model 204</var> issued a real WAIT while not in user-switching mode</td>
</tr>

<tr>
<td>TEMX</td>
<td>Highwater mark of CCATEMP pages used in the expansion area</td>
</tr>

<tr>
<td>TFMX</td>
<td>Highwater mark of CCATEMP pages used</td>
</tr>

<tr>
<td>TSMX</td>
<td>Highwater mark of CCATEMP pages used in the small model page pool</td>
</tr>

<tr>
<td>TTBL</td>
<td>Highwater mark of TTBL</td>
</tr>

<tr>
<td>UBUFHWS</td>
<td>Highwater mark, in bytes, of user's Universal Buffer</td>
</tr>

<tr>
<td>UDD</td>
<td>Number of lines written to a directed output (<var>USE</var>) data set</td>
</tr>

<tr>
<td>UPDTTIME(MS)</td>
<td>Number of milliseconds that a file was being updated

UPT(MS) appears as the column header for this statistic on a report
</td>
</tr>

<tr>
<td>UPDTTIME</td>
<td>Number of milliseconds that the user was actively updating at least one file</td>
</tr>

<tr>
<td>USMX</td>
<td>Highwater mark for simultaneous active users (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>USRS</td>
<td>Average number of active users (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>VTBL</td>
<td>Number of VTBL entries at the end of compilation (CMPL) processing or the end of evaluation (EVAL) processing</td>
</tr>

<tr>
<td>WAIT</td>
<td>Number of real operating system waits</td>
</tr>

<tr>
<td>WTCFR</td>
<td>Number of times that the user waited to obtain a critical file resource, either share or exclusive

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTRLK</td>
<td>Number of times that the user waited to obtain a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTSV</td>
<td>Percentage of performance samples at which the user was waiting for a server (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>XTBL</td>
<td>Highwater mark of XTBL</td>
</tr>

<tr>
<td>ZTCPU</td>
<td>The CPU (ms) consumed on a zIIP processor by the MAINTASK, an MP subtask or a zIIP subtask. Reported for each task at <var class="product">Model 204</var> termination and in <var>MONITOR TASKS</var> output (for Model 5 terminals only)</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>The number of times that a zIIP subtask took a unit of work from a zIIP subtask queue and processed it</td>
</tr>
</table>

==Header and trailer entries (Type 0)==

Each journal block begins with a header record and ends with a trailer record.

===Header entries (Type 0)===

Header entries have the format shown in the following table: 
<table>
<caption style="margin-right:6em">Header entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entire journal record, including header and trailer</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Flags used by recovery</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH </td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">4</td>
<td>Binary</td>
<td> Sequence number </td>
</tr>

<tr>
<td>16(10)</td>
<td align="right">10</td>
<td>Binary</td>
<td> System Store Clock Extended (STCKE) value to provide picosecond accuracy on the journal date/time stamp

Bytes 1-9 || byte 16 
</td>
</tr>

<tr>
<td>26(1A)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of header, type 00</td>
</tr>

<tr>
<td>28(1C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Version in hex</td>
</tr>

<tr>
<td>30(1E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Version in EBCDIC</td>
</tr>

<tr>
<td>38(26)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Job name</td>
</tr>

<tr>
<td>46(2E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>JES Job ID</td>
</tr>

<tr>
<td>54(36)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>SMF System ID</td>
</tr>
</table>
<ul>
<li>If the flag byte at offset 3 of type 00 has the X'02' bit on, then it is a header record from <var class="product">Model 204</var> version 7.4.0 or later with its length at offset X'1A'.</li>

<li>If that flag byte has the X'01' bit on, then the header is from version 7.1.0 and is 26 bytes in length. </li>

<li>If neither of those bits is on, then the header is a from a pre-7.1.0 version and is 16 bytes in length.</li>
</ul>

===Recovery flags===

Flags used by recovery can have the value of X'00' or a sum of any of the following: 
<table>
<tr class="head">
<th>Value</th>
<th>Block contains these records...</th>
</tr>

<tr>
<td>X'80'</td>
<td>Type 1</td>
</tr>

<tr>
<td>X'40'</td>
<td>Type 2</td>
</tr>

<tr>
<td>X'20'</td>
<td>Type 3</td>
</tr>

<tr>
<td>X'10'</td>
<td>Type 4</td>
</tr>

<tr>
<td>X'08'</td>
<td>Type 5</td>
</tr>

<tr>
<td>X'04'</td>
<td>Type 6</td>
</tr>
</table>

===Sequence numbers===

The sequence number represents the number of each journal record, starting at 0 and increasing by 1. A merged journal (output of the MERGEJ utility) sequence number consists of a 2-byte hexadecimal number at offset 12(0C), which indicates the input file this journal record came from, and a 2-byte hexadecimal field at offset 14(0E), which indicates the sequence within the INPUT journal.

===Trailer entries (Type 0)===

Trailer entries have the format shown in the following table: 
<table>
<caption>Trailer entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data </td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Recovery entries (Types 1-6)==

Entry types X'01' through X'06' contain information used for recovery. They follow the same general format as all other journal entries. There is no type X'07' journal entry. 

The format of the recovery entries is meaningful only in the context of the <var class="product">Model 204</var> ROLL FORWARD algorithm. However, entry types might be of interest in some statistics gathering applications, as follows: 
<table>
<tr class="head">
<th>Type </th>
<th>Contains recovery information from...</th>
</tr>

<tr>
<td>1 </td>
<td>Discontinuity</td>
</tr>

<tr>
<td>2 </td>
<td> Begin update unit.

More than one type 2 entry can be written for each update unit. The update unit number appears as a 4-byte binary number at offset 16(10).
</td>
</tr>

<tr>
<td>3 </td>
<td> End update unit.

The update unit number appears in the same format and location as the type 2 entry.
</td>
</tr>

<tr>
<td>4</td>
<td>File state information: opened, closed, dumped, file parameter list (FPL) page preimage logged or open at the time of a checkpoint</td>
</tr>

<tr>
<td>5 </td>
<td>Checkpoint</td>
</tr>

<tr>
<td>6 </td>
<td>File update </td>
</tr>
</table>

==System statistics entries (Type 8)==

Cumulative statistics, listed by offset in the [[#System performance statistics|Layout of system subtype X'02' entries]] table, are kept for the entire system. Final, partial, and performance system statistics are written to the journal during <var class="product">Model 204</var> termination in a line that begins with:
ST $$$ SYSTEM='version#'


For additional information about:
<ul>
<li>Using system statistics for performance monitoring, see [[Performance monitoring and tuning]]. </li>

<li>Disk buffer monitor statistics and parameters, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </li>
</ul>

===Final statistics===

The system final statistics line, similar to the following, is produced as part of system termination: 
ST $$$ SYSTEM='5A 'AUDIT=43 OUT=38 IN=14 WAIT=19 ...


===Partial statistics===

Statistics in a system partial statistics line, similar to the following, accumulate from the beginning of the run, if the User 0 <var>[[ACCTIM parameter|ACCTIM]]</var> parameter is nonzero: 
ST $$$ SYSTEM='6.1.0'PARTIAL=3 AUDIT=19 OUT=10 IN=5 WAIT=3 ...


===Performance statistics===

System performance statistic lines, similar to the following, are written if the User 0 <var>[[RPTCNT parameter|RPTCNT]]</var> and <var>[[SMPLTIM parameter|SMPLTIM]]</var> parameters are nonzero: 
ST $$$ SYSTEM='6.1.0' PERFORMANCE=n


The numbers determined at the performance sample points are averaged for the entire run. 

===Entry formats===

System statistics entries have the format shown in the following table: 
<table>
<caption>System statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'08'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:

X'00' = final statistics

X'01' = partial statistics

X'02' = performance statistics

X'04' = additional disk buffer monitor

X'08' = subtask statistics
</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Subtask number if subtype = X'08'; otherwise unused</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Unused</td>
</tr>

<tr>
<td>16(10) to end of journal</td>
<td align="right"> — </td>
<td align="right"> — </td>
<td>

Contents depend on subtypes, shown in tables in the following sections:
<ul>
<li>[[#System final and partial statistics|System final and partial statistics]]</li>

<li>[[#System performance statistics|System performance statistics]]</li>

<li>[[#Additional disk buffer monitor statistics|Additional disk buffer monitor statistics]]</li>

<li>[[#User since-last statistics|User since-last statistics]]</li>
</ul>
</td> </tr>
</table>

==System final and partial statistics==

For subtypes X'00' (final statistics) and X'01' (partial statistics), the layout of the remainder of the entry is shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
The following statistics are data type Binary. However, the length varies — either 4 or 8, to accommodate 64-bit system architecture. 
<table>
<caption>System final and partial statistics</caption>
<tr class="head">
<th>Offset dec(hex) </th>
<th>Length </th>
<th>Description</th>
</tr>

<tr>
<td>16(10) </td>
<td>8 </td>
<td>AUDIT</td>
</tr>

<tr>
<td>24(18) </td>
<td>8 </td>
<td>OUT</td>
</tr>

<tr>
<td>32(20) </td>
<td>8 </td>
<td>IN</td>
</tr>

<tr>
<td>40(28) </td>
<td>8 </td>
<td>OUTXX</td>
</tr>

<tr>
<td>48(30) </td>
<td>8 </td>
<td>INXX</td>
</tr>

<tr>
<td>56(38) </td>
<td>8 </td>
<td>DEV5</td>
</tr>

<tr>
<td>64(40) </td>
<td>8 </td>
<td>DEV6</td>
</tr>

<tr>
<td>72(48) </td>
<td>8 </td>
<td>DEV7</td>
</tr>

<tr>
<td>80(50) </td>
<td>8 </td>
<td>DEV8</td>
</tr>

<tr>
<td>88(58) </td>
<td>8 </td>
<td>DEV9</td>
</tr>

<tr>
<td>96(60) </td>
<td>8 </td>
<td>DEV10</td>
</tr>

<tr>
<td>104(68) </td>
<td>8 </td>
<td>DEV11</td>
</tr>

<tr>
<td>112(70) </td>
<td>8 </td>
<td>DEV12</td>
</tr>

<tr>
<td>120(78) </td>
<td>8 </td>
<td>DEV13</td>
</tr>

<tr>
<td>128(80) </td>
<td>8 </td>
<td>DEV14</td>
</tr>

<tr>
<td>136(88) </td>
<td>8 </td>
<td>OUTTTY</td>
</tr>

<tr>
<td>144(90) </td>
<td>8 </td>
<td>INTTY</td>
</tr>

<tr>
<td>152(98) </td>
<td>8 </td>
<td>DEV17</td>
</tr>

<tr>
<td>160(A0) </td>
<td>8 </td>
<td>DEV18</td>
</tr>

<tr>
<td>168(A8) </td>
<td>8 </td>
<td>DEV19</td>
</tr>

<tr>
<td>176(B0) </td>
<td>8 </td>
<td>DEV20</td>
</tr>

<tr>
<td>184(B8) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>192(C0) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>200(C8) </td>
<td>8 </td>
<td>DEV23</td>
</tr>

<tr>
<td>208(D0) </td>
<td>8 </td>
<td>DEV24</td>
</tr>

<tr>
<td>216(D8) </td>
<td>8 </td>
<td>DEV25</td>
</tr>

<tr>
<td>224(E0) </td>
<td>8 </td>
<td>DEV26</td>
</tr>

<tr>
<td>232(E8) </td>
<td>8 </td>
<td>DEV27</td>
</tr>

<tr>
<td>240(F0) </td>
<td>8 </td>
<td>DEV28</td>
</tr>

<tr>
<td>248(F8) </td>
<td>8 </td>
<td>OUTCRAM</td>
</tr>

<tr>
<td>256(100) </td>
<td>8 </td>
<td>INCRAM</td>
</tr>

<tr>
<td>264(108) </td>
<td>8 </td>
<td>DEV31</td>
</tr>

<tr>
<td>272(110) </td>
<td>8 </td>
<td>DEV32</td>
</tr>

<tr>
<td>280(118) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>288(120) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>296(128) </td>
<td>8 </td>
<td>DEV35</td>
</tr>

<tr>
<td>304(130) </td>
<td>8 </td>
<td>DEV36</td>
</tr>

<tr>
<td>312(138) </td>
<td>8 </td>
<td>DEV37</td>
</tr>

<tr>
<td>320(140) </td>
<td>8 </td>
<td>DEV38</td>
</tr>

<tr>
<td>328(148) </td>
<td>8 </td>
<td>OUTVMIO</td>
</tr>

<tr>
<td>336(150) </td>
<td>8 </td>
<td>INVMIO</td>
</tr>

<tr>
<td>344(158) </td>
<td>8 </td>
<td>OUTVMFS</td>
</tr>

<tr>
<td>352(160) </td>
<td>8 </td>
<td>INVMFS</td>
</tr>

<tr>
<td>360(168) </td>
<td>8 </td>
<td>OUTVMIF</td>
</tr>

<tr>
<td>368(170) </td>
<td>8 </td>
<td>INVMIF</td>
</tr>

<tr>
<td>376(178) </td>
<td>8 </td>
<td>OUTCMIO</td>
</tr>

<tr>
<td>384(180) </td>
<td>8 </td>
<td>INCMIO</td>
</tr>

<tr>
<td>392(188) </td>
<td>8 </td>
<td>OUTCMFS</td>
</tr>

<tr>
<td>400(190) </td>
<td>8 </td>
<td>INCMFS</td>
</tr>

<tr>
<td>408(198) </td>
<td>8 </td>
<td>DEV49</td>
</tr>

<tr>
<td>416(1A0) </td>
<td>8 </td>
<td>DEV50</td>
</tr>

<tr>
<td>424(1A8) </td>
<td>8 </td>
<td>OFFIN</td>
</tr>

<tr>
<td>432(1B0) </td>
<td>8 </td>
<td>OFFOU</td>
</tr>

<tr>
<td>440(1B8) </td>
<td>8 </td>
<td>DEV53</td>
</tr>

<tr>
<td>448(1C0) </td>
<td>8 </td>
<td>DEV54</td>
</tr>

<tr>
<td>456(1C8) </td>
<td>8 </td>
<td>DEV55</td>
</tr>

<tr>
<td>464(1D0) </td>
<td>8 </td>
<td>DEV56</td>
</tr>

<tr>
<td>472(1D8) </td>
<td>8 </td>
<td>DEV57</td>
</tr>

<tr>
<td>480(1E0) </td>
<td>8 </td>
<td>DEV58</td>
</tr>

<tr>
<td>488(1E8) </td>
<td>8 </td>
<td>DEV59</td>
</tr>

<tr>
<td>496(1F0) </td>
<td>8 </td>
<td>DEV60</td>
</tr>

<tr>
<td>504(1F8) </td>
<td>8 </td>
<td>DEV61</td>
</tr>

<tr>
<td>512(200) </td>
<td>8 </td>
<td>DEV62</td>
</tr>

<tr>
<td>520(208) </td>
<td>8 </td>
<td>DEV63</td>
</tr>

<tr>
<td>528(210) </td>
<td>8 </td>
<td>DEV64</td>
</tr>

<tr>
<td>536(218) </td>
<td>8 </td>
<td>DEV65</td>
</tr>

<tr>
<td>544(220) </td>
<td>8 </td>
<td>DEV66</td>
</tr>

<tr>
<td>552(228) </td>
<td>8 </td>
<td>DEV67</td>
</tr>

<tr>
<td>560(230) </td>
<td>8 </td>
<td>DEV68</td>
</tr>

<tr>
<td>568(238) </td>
<td>8 </td>
<td>DEV69</td>
</tr>

<tr>
<td>576(240) </td>
<td>8 </td>
<td>DEV70</td>
</tr>

<tr>
<td>584(248) </td>
<td>8 </td>
<td>DEV71</td>
</tr>

<tr>
<td>592(250) </td>
<td>8 </td>
<td>DEV72</td>
</tr>

<tr>
<td>600(258) </td>
<td>8 </td>
<td>DEV73</td>
</tr>

<tr>
<td>608(260) </td>
<td>8 </td>
<td>DEV74</td>
</tr>

<tr>
<td>616(268) </td>
<td>4 </td>
<td>WAIT</td>
</tr>

<tr>
<td>620(26C) </td>
<td>4 </td>
<td>MPLKWTIM</td>
</tr>

<tr>
<td>624(270) </td>
<td>8 </td>
<td>DKRD</td>
</tr>

<tr>
<td>632(278) </td>
<td>8 </td>
<td>DKWR</td>
</tr>

<tr>
<td>640(280) </td>
<td>4 </td>
<td>SVRD</td>
</tr>

<tr>
<td>644(284) </td>
<td>4 </td>
<td>SVWR</td>
</tr>

<tr>
<td>648(288) </td>
<td>8 </td>
<td>CPU</td>
</tr>

<tr>
<td>656(290) </td>
<td>8 </td>
<td>REQ</td>
</tr>

<tr>
<td>664(298) </td>
<td>8 </td>
<td>MOVE</td>
</tr>

<tr>
<td>672(2A0) </td>
<td>4 </td>
<td>DUMP</td>
</tr>

<tr>
<td>676(2A4) </td>
<td>4 </td>
<td>REST</td>
</tr>

<tr>
<td>680(2A8) </td>
<td>4 </td>
<td>SLIC</td>
</tr>

<tr>
<td>684(2AC) </td>
<td>4 </td>
<td>CNCT</td>
</tr>

<tr>
<td>688(2B0) </td>
<td>4 </td>
<td>FBWT</td>
</tr>

<tr>
<td>692(2B4) </td>
<td>4 </td>
<td>SWT</td>
</tr>

<tr>
<td>696(2B8) </td>
<td>4 </td>
<td>ERRPDL</td>
</tr>

<tr>
<td>700(2BC) </td>
<td>4 </td>
<td>MPLKPREM</td>
</tr>

<tr>
<td>704(2C0) </td>
<td>8 </td>
<td>RECADD</td>
</tr>

<tr>
<td>712(2C8) </td>
<td>8 </td>
<td>RECDEL</td>
</tr>

<tr>
<td>720(2D0) </td>
<td>8 </td>
<td>BADD</td>
</tr>

<tr>
<td>728(2D8) </td>
<td>8 </td>
<td>BDEL</td>
</tr>

<tr>
<td>736(2E0) </td>
<td>8 </td>
<td>BCHG</td>
</tr>

<tr>
<td>744(2E8) </td>
<td>8 </td>
<td>IXADD</td>
</tr>

<tr>
<td>752(2F0) </td>
<td>8 </td>
<td>IXDEL</td>
</tr>

<tr>
<td>760(2F8) </td>
<td>8 </td>
<td>FINDS</td>
</tr>

<tr>
<td>768(300) </td>
<td>4 </td>
<td>SORTS</td>
</tr>

<tr>
<td>772(304) </td>
<td>4 </td>
<td>JSCREENS</td>
</tr>

<tr>
<td>776(308) </td>
<td>8 </td>
<td>RECDS</td>
</tr>

<tr>
<td>784(310) </td>
<td>8 </td>
<td>STRECDS</td>
</tr>

<tr>
<td>792(318) </td>
<td>8 </td>
<td>DKAR</td>
</tr>

<tr>
<td>800(320) </td>
<td>8 </td>
<td>DKPR</td>
</tr>

<tr>
<td>808(328) </td>
<td>4 </td>
<td>DKRR</td>
</tr>

<tr>
<td>812(32C) </td>
<td>4 </td>
<td>FBMX</td>
</tr>

<tr>
<td>816(330) </td>
<td>4 </td>
<td>TFMX</td>
</tr>

<tr>
<td>820(334) </td>
<td>4 </td>
<td>USMX</td>
</tr>

<tr>
<td>824(338) </td>
<td>4 </td>
<td>SVMX</td>
</tr>

<tr>
<td>828(33C) </td>
<td>4 </td>
<td>SFTRSTRT (number of soft restarts)</td>
</tr>

<tr>
<td>832(340) </td>
<td>8 </td>
<td>APSYLD</td>
</tr>

<tr>
<td>840(348) </td>
<td>8 </td>
<td>APSYLDD</td>
</tr>

<tr>
<td>848(350) </td>
<td>4 </td>
<td>APSYLDT</td>
</tr>

<tr>
<td>852(354) </td>
<td>4 </td>
<td>Spare</td>
</tr>

<tr>
<td>856(358) </td>
<td>8 </td>
<td>DKPRF</td>
</tr>

<tr>
<td>864(360) </td>
<td>4 </td>
<td>SMPLS</td>
</tr>

<tr>
<td>868(364) </td>
<td>4 </td>
<td>USRS</td>
</tr>

<tr>
<td>872(368) </td>
<td>4 </td>
<td>SVAC</td>
</tr>

<tr>
<td>876(36C) </td>
<td>4 </td>
<td>RUNG</td>
</tr>

<tr>
<td>880(370) </td>
<td>4 </td>
<td>REDY</td>
</tr>

<tr>
<td>884(374) </td>
<td>4 </td>
<td>BLKI</td>
</tr>

<tr>
<td>888(378) </td>
<td>4 </td>
<td>WTSV</td>
</tr>

<tr>
<td>892(37C) </td>
<td>4 </td>
<td>BLKO</td>
</tr>

<tr>
<td>896(380) </td>
<td>4 </td>
<td>SWPG</td>
</tr>

<tr>
<td>900(384) </td>
<td>4 </td>
<td>PCPU</td>
</tr>

<tr>
<td>904(388) </td>
<td>4 </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>908(38C) </td>
<td>4 </td>
<td>JWEBERRS</td>
</tr>

<tr>
<td>912(390) </td>
<td>8 </td>
<td>STCPU</td>
</tr>

<tr>
<td>920(398) </td>
<td>8 </td>
<td>STDEQ</td>
</tr>

<tr>
<td>928(3A0) </td>
<td>8 </td>
<td>STWAIT</td>
</tr>

<tr>
<td>936(3A8) </td>
<td>4 </td>
<td>STPOST</td>
</tr>

<tr>
<td>940(3AC) </td>
<td>4 </td>
<td>LKWAIT</td>
</tr>

<tr>
<td>944(3B0) </td>
<td>4 </td>
<td>LKPOST</td>
</tr>

<tr>
<td>948(3B4) </td>
<td>4 </td>
<td>RSXCOMP</td>
</tr>

<tr>
<td>952(3B8) </td>
<td>4 </td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>956(3BC) </td>
<td>4 </td>
<td>SCREENS</td>
</tr>

<tr>
<td>960(3C0) </td>
<td>4 </td>
<td>STIMERS</td>
</tr>

<tr>
<td>964(3C4) </td>
<td>4 </td>
<td>HRDRSTRT (number of hard restarts)</td>
</tr>

<tr>
<td>968(3C8) </td>
<td>8 </td>
<td>SVPAGES</td>
</tr>

<tr>
<td>976(3D0) </td>
<td>4 </td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>980(3D4) </td>
<td>4 </td>
<td>COMMITS</td>
</tr>

<tr>
<td>984(3D8) </td>
<td>4 </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>988(3DC) </td>
<td>4 </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>992(3E0) </td>
<td>4 </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>996(3E4) </td>
<td>4 </td>
<td>MPHASHD</td>
</tr>

<tr>
<td>1000(3E8) </td>
<td>4 </td>
<td>CDLWAIT</td>
</tr>

<tr>
<td>1004(3EC) </td>
<td>4 </td>
<td>MQGETS</td>
</tr>

<tr>
<td>1008(3F0) </td>
<td>4 </td>
<td>MQPUTS</td>
</tr>

<tr>
<td>1012(3F4) </td>
<td>4 </td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>1016(3F8) </td>
<td>4 </td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>1020(3FC) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1024(400) </td>
<td>8 </td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>1032(408) </td>
<td>8 </td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>1040(410) </td>
<td>4 </td>
<td>MQHWQU</td>
</tr>

<tr>
<td>1044(414) </td>
<td>4 </td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>1048(418) </td>
<td>4 </td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>1052(41C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1056(420) </td>
<td>8 </td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>1064(428) </td>
<td>8 </td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>1072(430) </td>
<td>8 </td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>1080(438) </td>
<td>4 </td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>1084(43C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1088(440) </td>
<td>8 </td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>1096(448) </td>
<td>4 </td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>1100(44C) </td>
<td>4 </td>
<td>ECLOAD</td>
</tr>

<tr>
<td>1104(450) </td>
<td>4 </td>
<td>ECDELETE</td>
</tr>

<tr>
<td>1108(454) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1112(458) </td>
<td>8 </td>
<td>ECCALL</td>
</tr>

<tr>
<td>1120(460) </td>
<td>4 </td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>1124(464) </td>
<td>4 </td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>1128(468) </td>
<td>4 </td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>1132(46C) </td>
<td>4 </td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>1136(470) </td>
<td>4 </td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>1140(474) </td>
<td>4 </td>
<td>ECCNCT</td>
</tr>

<tr>
<td>1144(478) </td>
<td>4 </td>
<td>ECMODMAX</td>
</tr>

<tr>
<td>1148(47C) </td>
<td>4 </td>
<td>ECNAMMAX</td>
</tr>

<tr>
<td>1152(480) </td>
<td>4 </td>
<td>ECTSKMAX</td>
</tr>

<tr>
<td>1156(484) </td>
<td>4 </td>
<td>GTBLRU</td>
</tr>

<tr>
<td>1160(488) </td>
<td>4 </td>
<td>GTBLRS</td>
</tr>

<tr>
<td>1164(48C) </td>
<td>4 </td>
<td>TSMX</td>
</tr>

<tr>
<td>1168(490) </td>
<td>4 </td>
<td>TEMX</td>
</tr>

<tr>
<td>1172(494) </td>
<td>4 </td>
<td>MAXIOX</td>
</tr>

<tr>
<td>1176(498) </td>
<td>8 </td>
<td>DKRDL</td>
</tr>

<tr>
<td>1184(4A0) </td>
<td>8 </td>
<td>DKWRL</td>
</tr>

<tr>
<td>1192(4A8) </td>
<td>8 </td>
<td>CPUTOTZE</td>
</tr>

<tr>
<td>1200(4B0) </td>
<td>8 </td>
<td>CPUONZIP</td>
</tr>

<tr>
<td>1208(4B8) </td>
<td>4 </td>
<td>MPR
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1212(4BC) </td>
<td>4 </td>
<td>MBO
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1216(4C0) </td>
<td>4 </td>
<td>MCP
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1220(4C4) </td>
<td>4 </td>
<td>RCV
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1224(4C8) </td>
<td>8 </td>
<td>Spare </td>
</tr>

<tr>
<td>1232(4D0) </td>
<td>8 </td>
<td>DKWTMICS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1240(4D8) </td>
<td>8 </td>
<td>DKWTS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1248(4E0) </td>
<td>8 </td>
<td>MTDEQ</td>
</tr>

<tr>
<td>1256(4E8) </td>
<td>8 </td>
<td>MTSDEQ</td>
</tr>

<tr>
<td>1264(4F0) </td>
<td>8 </td>
<td>MTZDEQ</td>
</tr>

<tr>
<td>1272(4F8) </td>
<td>8 </td>
<td>STZDEQ</td>
</tr>

<tr>
<td>1280(500) </td>
<td>8 </td>
<td>ZTDEQ</td>
</tr>
</table>

==System performance statistics==

===Entry format===

For subtype X'02'(system performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. See [[#Description of statistics|Statistics with descriptions]] table for the meaning of each statistic. 
<table>
<caption>Layout of system subtype X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 16(10)</td>
<td>SMPLS</td>
</tr>

<tr>
<td> 20(14)</td>
<td>USRS</td>
</tr>

<tr>
<td> 24(18)</td>
<td>SVAC</td>
</tr>

<tr>
<td> 28(1C)</td>
<td>RUNG </td>
</tr>

<tr>
<td> 32(20)</td>
<td>REDY</td>
</tr>

<tr>
<td> 36(24)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 40(28)</td>
<td>WTSV</td>
</tr>

<tr>
<td> 44(2C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 48(30)</td>
<td>SWPG </td>
</tr>
</table>

==Additional disk buffer monitor statistics==

For subtype X'04' (additional disk buffer monitor statistics), the layout of the entry is shown in the following table. Each statistic in the table is: Length, 8; Data type, Binary.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Disk buffer monitor statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Disk buffer monitor statistic </th>
</tr>

<tr>
<td>16(10)</td>
<td>Spare</td>
</tr>

<tr>
<td>24(18) </td>
<td>DKSTKQC </td>
</tr>

<tr>
<td>32(20) </td>
<td>DKSWRP </td>
</tr>

<tr>
<td>40(28) </td>
<td>DKSWRPT </td>
</tr>

<tr>
<td>48(30) </td>
<td>DKSDIR </td>
</tr>

<tr>
<td>56(38) </td>
<td>DKSDIRT </td>
</tr>

<tr>
<td>64(40) </td>
<td>DKSKIP </td>
</tr>

<tr>
<td>72(48) </td>
<td>Spare </td>
</tr>

<tr>
<td>80(50) </td>
<td>Spare</td>
</tr>

<tr>
<td>88(58) </td>
<td>DKSRR </td>
</tr>

<tr>
<td>96(60) </td>
<td>DKSFBS </td>
</tr>

<tr>
<td>104(68) </td>
<td>DKSKIPT </td>
</tr>

<tr>
<td>112(70) </td>
<td>DKSAWT </td>
</tr>

<tr>
<td>120(78) </td>
<td>DKSAWW</td>
</tr>

<tr>
<td>128(80) </td>
<td>DKSAWWL</td>
</tr>

<tr>
<td>136(88) </td>
<td>DKSAWB </td>
</tr>

<tr>
<td>144(90) </td>
<td>DKSAWBL</td>
</tr>

<tr>
<td>152(98) </td>
<td>DKSRRFND </td>
</tr>

<tr>
<td>160(A0) </td>
<td>DKSTBLF </td>
</tr>

<tr>
<td>168(A8) </td>
<td>DKSTBLA </td>
</tr>

<tr>
<td>176(B0) </td>
<td>DKSTBLB </td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKSTBLC </td>
</tr>

<tr>
<td>192(C0) </td>
<td>DKSTBLD </td>
</tr>

<tr>
<td>200(C8) </td>
<td>Spare </td>
</tr>

<tr>
<td>208(D0) </td>
<td>Spare </td>
</tr>

<tr>
<td>216(D8) </td>
<td>Spare </td>
</tr>

<tr>
<td>224(E0) </td>
<td>Spare </td>
</tr>

<tr>
<td>232(E8) </td>
<td>Spare </td>
</tr>

<tr>
<td>240(F0) </td>
<td>Spare </td>
</tr>

<tr>
<td>248(F8) </td>
<td>Spare </td>
</tr>

<tr>
<td>256(100) </td>
<td>DKSTBLX </td>
</tr>

<tr>
<td>264(108) </td>
<td>DKSTBLE</td>
</tr>

<tr>
<td>272(110)</td>
<td>Spare </td>
</tr>
</table>

==Multiprocessing (MP) subtask statistics==

The following statistics apply only to installations configured for multiprocessing using MP/204. For subtype X'08' (subtask specific statistics), the layout of the entry is shown in the following table.
For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>MP subtask statistics and offsets</caption>
<tr class="head">
<th>MP statistic </th>
<th>Offset dec(hex) </th>
<th>Length</th>
</tr>

<tr>
<td>CPU </td>
<td>16(10) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PR </td>
<td>24(18) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PCPU </td>
<td>32(20) </td>
<td align="right">4</td>
</tr>

<tr>
<td>STWAIT</td>
<td>36(24)</td>
<td align="right">4</td>
</tr>

<tr>
<td>STPOST</td>
<td>40(28)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>44(2C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKPOST</td>
<td>48(30)</td>
<td align="right">4</td>
</tr>

<tr>
<td>SPARE</td>
<td>52(34)</td>
<td align="right">4</td>
</tr>

<tr>
<td>MQWTM</td>
<td>56(38) </td>
<td align="right">8</td>
</tr>

<tr>
<td>DEQ </td>
<td>64(40) </td>
<td align="right">8</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>72(48)</td>
<td align="right">8</td>
</tr>

<tr>
<td>STDEQ </td>
<td>80(50) </td>
<td align="right">8</td>
</tr>

<tr>
<td>LWTIM </td>
<td>88(58) </td>
<td align="right">4</td>
</tr>

<tr>
<td>PETIM</td>
<td>92(5C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>ZCPU</td>
<td>96(60) </td>
<td align="right">8</td>
</tr>
</table>

==User statistics entries (Type 9)==

User lines report on an individual user's activity. These statistics include:
<ul>
<li>Final (logout) and partial statistics</li>

<li>Since-last and ordered index statistics</li>

<li>Performance statistics</li>
</ul>

Each user line starts with the following statistics:
ST $$$ USERID='userid' ACCOUNT='account'


The subtype, in this case PERFORMANCE, follows USERID and ACCOUNT statistics:
ST $$$ USERID='userid' ACCOUNT='account'
PERFORMANCE=n


The format of user statistics entries is shown in the following table:
<table>
<caption>User statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'09'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:
<ul>
<li>X'00' = logout statistics</li>

<li>X'01' = since-last statistics</li>

<li>X'02' = partial statistics</li>

<li>X'04' = performance statistics</li>

<li>X'81' = since-last statistics including conflict statistics</li>

<li>X'41' = user restart forced out a since-last statistics record.</li>

<li>X'C1' = user restart forced out a since last statistics record which included conflict statistics</li>
</ul>
</td></tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>

Account:
<ul>
<li>Second argument of LOGON/LOGIN command</li>

<li>Default is user ID</li>
</ul>
</td>
</tr>

<tr>
<td>26(1A)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>User ID</td>
</tr>

<tr>
<td>36(24)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>Since-last ID =
See the [[#User since-last statistics|Activity types]] table where the possible activity types are listed.</td>
</tr>

<tr>
<td>40(28)</td>
<td align="right">1</td>
<td>Binary</td>
<td>IODEV number (added for MXI)</td>
</tr>

<tr>
<td>41(29)</td>
<td align="right">3</td>
<td>N/A</td>
<td>Unused</td>
</tr>

<tr>
<td>44(2C) to end of journal</td>
<td> </td>
<td>Binary</td>
<td>

Contents depend on subtypes, shown in:
<ul>
<li>[[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table</li>

<li>[[#Since-last in relation to final and partial statistics|Layout of user subtype X'01' and X'81' entries]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table</li>

<li>[[#Layout of performance statistics|Layout of user subtype X'04' entries]] table</li>
</ul>
</td> </tr>
</table>

==User final and partial statistics==

===Final (logout) statistics===

Final (logout) statistics, listed in the [[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table, summarize a user's activities since the last login. A LOGOUT statistics line, such as the following, is written after each logout if the parameter following ACCOUNT is not PARTIAL, LAST, or PERFORMANCE: 
yydddhhmmssnnnsssuuuuu ST $$$ ACCOUNT='NO ACCOUNT' SQRD=5 ...

<ul>
<li><var class="term">yyddd</var> is the year and Julian day.</li>

<li><var class="term">hhmmss</var> is the time of day in hours, minutes, and seconds.</li>

<li><var class="term">nnn</var> is a counter to distinguish lines produced in the same second.</li>

<li><var class="term">sss</var> is the number of the server currently handling the user. Leading zeros are suppressed.
</li>

<li><var class="term">uuuuu</var> is a 5-digit user number associated with the audit trail line. Leading zeros are suppressed.</li>
</ul>

In some cases, the account name appears as "NO USERID NO ACCOUNT". Statistics in this category are not chargeable to any one user and should be considered system overhead.

Final lines are recognized by the absence of an indicator for another type of line.

===Partial statistics===

Optional partial statistics, listed in the "Layout of user subtype X'00' and X'02' entries" table below, can be provided for a run up to a few minutes before a system failure that prevents normal termination and production of final user and system statistics. 

User partial statistics lines, such as the following, are made available for active users: 
ST $$$ ACCOUNT='NO ACCOUNT' PARTIAL=21 ...


Statistics accumulate either:
<ul>
<li>As long as the user is logged in</li>
</ul>

or
<ul>
<li>From the first terminal input to disconnection when a login is not required </li>
</ul>

Partial statistics are requested by setting the time interval, in minutes, between successive partial lines on User 0's parameter line with the <var>ACCTIM</var> parameter. <var>ACCTIM</var> must be nonzero. 

The contents of the statistics portion of the entry, starting at offset <code>40(28)</code>, depends upon the subtype of the entry. 

Partial statistics lines are indicated on the journal by the parameter <code>PARTIAL=n</code>, where <var class="term">n</var> is a counter from the beginning of the run. <code>PARTIAL=n</code> immediately follows the type parameter.

For subtypes X'00' (logout statistics), and X'02' (partial statistics), the layout of the remainder of the entry is shown in the following table. Each statistic in the table is: Length, 4; Data type, Binary. For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Layout of user subtype X'00' and X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>40(28)</td>
<td>CNCT</td>
</tr>

<tr>
<td>44(2C)</td>
<td>DKRD </td>
</tr>

<tr>
<td>48(30)</td>
<td>DKWR </td>
</tr>

<tr>
<td>52(34)</td>
<td>SQRD</td>
</tr>

<tr>
<td>56(38)</td>
<td>SQWR</td>
</tr>

<tr>
<td>60(3C)</td>
<td>SGMTI </td>
</tr>

<tr>
<td>64(40)</td>
<td>SGMTO </td>
</tr>

<tr>
<td>68(44)</td>
<td>SVRD</td>
</tr>

<tr>
<td>72(48)</td>
<td>SVWR </td>
</tr>

<tr>
<td>76(4C)</td>
<td>CPU </td>
</tr>

<tr>
<td>80(50)</td>
<td>REQ </td>
</tr>

<tr>
<td>84(54)</td>
<td>MOVE </td>
</tr>

<tr>
<td>88(58)</td>
<td>DUMP </td>
</tr>

<tr>
<td>92(5C)</td>
<td>REST </td>
</tr>

<tr>
<td>96(60)</td>
<td>SLIC </td>
</tr>

<tr>
<td>100(64)</td>
<td>AUDIT </td>
</tr>

<tr>
<td>104(68) </td>
<td>WAIT </td>
</tr>

<tr>
<td>108(6C)</td>
<td>FBWT </td>
</tr>

<tr>
<td>112(70)</td>
<td>UDD </td>
</tr>

<tr>
<td>116(74)</td>
<td>RECADD </td>
</tr>

<tr>
<td>120(78)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>124(7C)</td>
<td>BADD </td>
</tr>

<tr>
<td>128(80)</td>
<td>BDEL</td>
</tr>

<tr>
<td>132(84)</td>
<td>BCHG </td>
</tr>

<tr>
<td>136(88)</td>
<td>IXADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>FINDS </td>
</tr>

<tr>
<td>148(94)</td>
<td>SORTS</td>
</tr>

<tr>
<td>152(98)</td>
<td>RECDS </td>
</tr>

<tr>
<td>156(9C)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>160(A0)</td>
<td>DKAR </td>
</tr>

<tr>
<td>164(A4)</td>
<td>DKPR </td>
</tr>

<tr>
<td>168(A8)</td>
<td>DKRR </td>
</tr>

<tr>
<td>172(AC)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>UPDTTIME(MS) </td>
</tr>

<tr>
<td>184(B8)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>188(BC)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>192(C0)</td>
<td>SMPLS </td>
</tr>

<tr>
<td>196(C4)</td>
<td>RUNG </td>
</tr>

<tr>
<td>200(C8)</td>
<td>REDY</td>
</tr>

<tr>
<td>204(CC)</td>
<td>BLKI</td>
</tr>

<tr>
<td>208(D0)</td>
<td>WTSV </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BLKO </td>
</tr>

<tr>
<td>216(D8)</td>
<td>SWPG </td>
</tr>

<tr>
<td>220(DC)</td>
<td>PCPU </td>
</tr>

<tr>
<td>224(E0)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>228(E4)</td>
<td>BXCHNG </td>
</tr>

<tr>
<td>232(E8)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>236(EC)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>240(F0)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>244(F4)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>248(F8)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>252(FC)</td>
<td>BXRFND</td>
</tr>

<tr>
<td>256(100)</td>
<td>BXFREE </td>
</tr>

<tr>
<td>260(104)</td>
<td>STCPU </td>
</tr>

<tr>
<td>264(108)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>268(10C)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>272(110)</td>
<td>SCREENS </td>
</tr>

<tr>
<td>276(114)</td>
<td>SVPAGES </td>
</tr>

<tr>
<td>280(118)</td>
<td>PBRSFLT </td>
</tr>

<tr>
<td>284(11C)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>292(124)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQBYTOU</td>
</tr>

<tr>
<td>308((134)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>380(17C)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>384(180)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>388(184)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>392(188)</td>
<td>Spare</td>
</tr>

<tr>
<td>396(18C) </td>
<td>MPR (V7.7 onwards)</td>
</tr>

<tr>
<td>400(190) </td>
<td>MBO (V7.7 onwards)</td>
</tr>

<tr>
<td>404(194)</td>
<td>DEV#</td>
</tr>

<tr>
<td>408(198)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>412(19C)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>CCATDIFF</td>
</tr>

</table>

==User since-last statistics==

===Since-last statistics===

Statistics are kept for each SOUL request, host language interface call, and a number of <var class="product">Model 204</var> system commands. When each request or command completes, a since-last statistics line is written. The line includes the <var>ACCOUNT</var> parameter at the beginning, followed by the <var>IODEV</var> parameter and the <var>LAST</var> parameter.

Several <var>MONITOR</var> commands produce displays containing the user's last or current activity in the <code>FUNC</code> column. When this activity completes, statistics are also written to CCAAUDIT and the activity is described in ST lines as <code>LAST='activity'</code>.

====Syntax====
ST $$$ USERID='userid' ACCOUNT='accountname' IODEV='devicetype' LAST='acty'

Where:

<var class="term">acty</var> can be one of the following: 
<table>
<caption>Activity types</caption>
<tr class="head">
<th>Option</th>
<th>Meaning</th>
</tr>

<tr>
<td>BLDR</td>
<td><var>BLDREUSE</var> command</td>
</tr>

<tr>
<td>BLDX </td>
<td><var>Z</var> command</td>
</tr>

<tr>
<td>CMPL </td>
<td>Compilation of a SOUL request</td>
</tr>

<tr>
<td>CPTB</td>
<td><var>COMPACTB</var> command</td>
</tr>

<tr>
<td>CPTE</td>
<td><var>COMPACTE</var> command</td>
</tr>

<tr>
<td>CPYP </td>
<td><var>COPY PROCEDURE</var> command</td>
</tr>

<tr>
<td>CREA</td>
<td><var>CREATE FILE filename</var> command</td>
</tr>

<tr>
<td>DISP </td>
<td><var>DISPLAY PROCEDURE</var> command</td>
</tr>

<tr>
<td>DUMP </td>
<td><var>DUMP file</var> command</td>
</tr>

<tr>
<td>EDIT </td>
<td>Editing a request</td>
</tr>

<tr>
<td>EVAL </td>
<td>Evaluation of a SOUL request</td>
</tr>

<tr>
<td>EXEC </td>
<td>Execution of an SQL request</td>
</tr>

<tr>
<td>FLDC </td>
<td>Compilation of a FLOD procedure</td>
</tr>

<tr>
<td>FLDE </td>
<td>Evaluation of a FLOD procedure</td>
</tr>

<tr>
<td>IMPC </td>
<td>Implied commit</td>
</tr>

<tr>
<td>INCR</td>
<td><var>IN FILE filename INCREASE DATASETS</var> command</td>
</tr>

<tr>
<td>INIT</td>
<td><var>IN FILE filename INITIALIZE</var> command</td>
</tr>

<tr>
<td>LOAD </td>
<td>Loading a precompiled (ASPY) procedure</td>
</tr>

<tr>
<td>PREP </td>
<td>Compilation of an SQL request</td>
</tr>

<tr>
<td>REST </td>
<td><var>RESTORE file</var> command</td>
</tr>
</table>

===Since-last highwater marks===

The since-last statistics include highwater marks of various work tables used by SOUL requests. Values are reported in terms of the units in which each table is allocated. For example, QTBL is allocated in units of 16 bytes.

===Since-last in relation to final and partial statistics===

Many since-last statistics, such as CNCT, CPU, and DKRD, are also reported on user final and partial statistics lines. (See the [[#Description of statistics|Statistics with descriptions]] table.) The statistics on these lines are roughly equal to the sum of all of the preceding since-last statistics for the user.
Because since-last statistics are not maintained for every <var class="product">Model 204</var> command, final statistics are generally larger.

For subtype X'01' (since-last statistics), the layout of the remainder of the entry begins as shown in the following table.
For the meaning of each statistic in this table and in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table, see the [[#Description of statistics|Statistics with descriptions]] table.
The layout of the end of the entry depends on whether you chose to collect conflict statistics:
<ul>
<li>If you do not collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table.</li>

<li>If you do collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table. When you collect conflict statistics, the subtype changes to X'81'. </li>
</ul>
<table>
<caption>Layout of user subtype X'01' and X'81' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 44(2C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 48(30)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 52(34)</td>
<td>QTBL </td>
</tr>

<tr>
<td> 56(38)</td>
<td>STBL </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>TTBL </td>
</tr>

<tr>
<td> 64(40)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 68(44)</td>
<td>PDL</td>
</tr>

<tr>
<td> 72(48)</td>
<td>FTBL </td>
</tr>

<tr>
<td> 76(4C)</td>
<td>XTBL </td>
</tr>

<tr>
<td> 80(50)</td>
<td>ITBL </td>
</tr>

<tr>
<td> 84(54)</td>
<td>FSCB </td>
</tr>

<tr>
<td> 88(58)</td>
<td>OUTPB </td>
</tr>

<tr>
<td> 92(5C) </td>
<td>HEAP </td>
</tr>

<tr>
<td> 96(60)</td>
<td>SQLI </td>
</tr>

<tr>
<td>100(64)</td>
<td>SQLO</td>
</tr>

<tr>
<td>104(68)</td>
<td>CNCT</td>
</tr>

<tr>
<td>108(6C)</td>
<td>CPU </td>
</tr>

<tr>
<td>112(70)</td>
<td>DKRD </td>
</tr>

<tr>
<td>116(74)</td>
<td>DKWR</td>
</tr>

<tr>
<td>120(78)</td>
<td>UDD </td>
</tr>

<tr>
<td>124(7C)</td>
<td>OUT </td>
</tr>

<tr>
<td>128(80)</td>
<td>SLIC</td>
</tr>

<tr>
<td>132(84)</td>
<td>IN </td>
</tr>

<tr>
<td>136(88)</td>
<td>RECADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>BADD </td>
</tr>

<tr>
<td>148(94)</td>
<td>BDEL </td>
</tr>

<tr>
<td>152(98)</td>
<td>BCHG </td>
</tr>

<tr>
<td>156(9C)</td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>164(A4)</td>
<td>FINDS </td>
</tr>

<tr>
<td>168(A8)</td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC)</td>
<td>RECDS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>PCPU </td>
</tr>

<tr>
<td>184(B8)</td>
<td>RQTM </td>
</tr>

<tr>
<td>188(BC)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>192(CO)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td>196(C4)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>200(C8)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>204(CC)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>208(DO)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>216(D8)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 220(DC)</td>
<td>BXFREE </td>
</tr>

<tr>
<td> 224(E0)</td>
<td>STCPU </td>
</tr>

<tr>
<td> 228(E4)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 232(E8)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 236(EC)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>240(F0) </td>
<td>SVRD </td>
</tr>

<tr>
<td>244(F4)</td>
<td>SVWR</td>
</tr>

<tr>
<td>248(F8) </td>
<td>DKPR </td>
</tr>

<tr>
<td>252(FC)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>256(100)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>260(104)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>264(108)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>268(10C)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>272(110)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>276(114)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>280(118)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>284(11C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>292(124)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>336(150)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>340(154)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>372(174)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>376(178)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>380(17C)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>384(180)</td>
<td>OBJSWAP</td>
</tr>

<tr>
<td>388()184</td>
<td>SIRIUS02</td>
</tr>

<tr>
<td>392(188)</td>
<td>SIRIUS03</td>
</tr>

<tr>
<td>396(18C)</td>
<td>IODEV#</td>
</tr><tr>

<tr>
<td>400(190)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>404(194) </td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>408(198) </td>
<td>CCATDIFF</td>
</tr>

<tr>
<td>412(19C) </td>
<td>RETHWM</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>PREIMAGE</td>
</tr>

<tr>
<td>420(1A4) </td>
<td>MAXDAEM</td>
</tr>
</table>

===Conflict statistics===

Whether you are collecting conflict statistics determines the layout at the end of the entry. Two of the conflict statistics keep track of critical file-resource conflicts, and two keep track of record-locking conflicts. Whether these statistics are collected and journaled depends on settings of the parameters <var>[[CFRLOOK parameter|CFRLOOK]]</var> and <var>[[CFRJRNL parameter|CFRJRNL]]</var>.


These statistics are not displayed with the output of the <code>MONITOR SL</code> command. Instead, you can view them (with all the other since-last statistics) by issuing the <var>MONITOR</var> command with the keyword <var>CONFLICT</var>.

The remainder of the entry depends on the setting of <var>CFRJRNL</var>.

The following table shows the layout when <var>CFRJRNL</var> is set to 0: 
<table>
<caption>Layout of user subtype X'01' entries (CFRJRNL=0)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>422(1A6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>430(1AE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>431(1AF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>

The following table shows the layout when <var>CFRJRNL</var> is set to 1. It reflects the change in offset and that the user subtypes are now X'81' entries. 
<table>
<caption>Layout of user subtype X'81' entries (CFRJRNL=1)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Entry type</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKCFRE stastic</td>
</tr>

<tr>
<td>416(1A0)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKRLK statistic</td>
</tr>

<tr>
<td>420(1A4)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTCFR statistic</td>
</tr>

<tr>
<td>424(1A8)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTRLK statistic</td>
</tr>

<tr>
<td>428(1AC)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>438(1B6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>446(1BE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>447(1BF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>
Note:
The conflict statistics, BLKCFRE, BLKRLK, WTCFR, and WTRLK, are inexact. Although a user might at times conflict with multiple other users, only the first conflict encountered is counted.

==User performance statistics==

Optional performance statistics lines provide information about the operation of the <var class="product">Model 204</var> scheduler during a short period of time. Information about the length of the scheduler queues, the number of active users and servers, and the queue distribution for each user, is obtained by sampling. 

A performance line starts with:
ST $$$ USERID='userid' ACCOUNT='accountname'
PERFORMANCE=n


===Parameters to activate performance statistics===

To request performance statistics, specify the number of samples to take between performance statistics lines (<var>RPTCNT</var> parameter) and the time interval between samples (<var>SMPLTIM</var> parameter) on User 0's parameter line. When you request scheduler and server performance data (<var>SMPLTIM</var> parameter), an asynchronous operating system task, called the performance subtask, is created. Both <var>RPTCNT</var> and <var>SMPLTIM</var> must be nonzero.

===Sampling===

The performance subtask spends most of its time in a wait state. Every <var>SMPLTIM</var> milliseconds, it records the current state of the system. Data from the most recent sample is available at an Online terminal through the <var>MONITOR</var> command, described in [[Controlling system operations (CCAIN)#ONLINE monitoring|ONLINE monitoring]]. 

The number of samples taken during a run (<var>RPTCNT</var>), times the number of users in the run (<var>NUSERS</var>), must be less than 4.2 million. In large systems that run for a very long period of time, the time interval between samples cannot be extremely short. If the limit is exceeded, an OC1 interrupt occurs when the SMPLS statistic value is calculated during the printing of the system statistics, either a performance or final line.

====Layout of performance statistics====

For subtype X'04' (performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. For the description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>Layout of user subtype X'04' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 40(28)</td>
<td>SMPLS </td>
</tr>

<tr>
<td> 44(2C)</td>
<td>RUNG</td>
</tr>

<tr>
<td> 48(30)</td>
<td>REDY </td>
</tr>

<tr>
<td> 52(34)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 56(38)</td>
<td>WTSV </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 64(40)</td>
<td>SWPG </td>
</tr>
</table>

==File statistics entries (Type 10)==

File statistics, summarized in the [[#File statistics journal records layout|File statistics entry formats]] table, are kept for every file opened during a run, including CCAGRP, CCASYS, and CCATEMP. The activity of a file for all users is summarized from the time the file is first opened until the last user issues a <var>CLOSE</var> command. The statistics appear after the last <var>CLOSE</var> command in lines that follow the date and time information (yyyydddhhmmssnnnsssuuuuu) with: 
ST $$$ FILE='filename'


System termination writes file statistics for each file still open at the end of the run.

===Final statistics===

A final statistics line similar to the following is produced when the last user of a file closes the file: 
ST $$$ FILE='PAYABLES'DKRD=25 DKRD=25 DKWR=15 REQ=3 RECADD=6 ...


===Partial statistics===

File partial statistics lines similar to the following are furnished for each open file: 
ST $$$ FILE='PAYABLES'PARTIAL=3 ...


===File statistics journal records layout===

File statistics entries have the format shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>File statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Type of entry</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'0A'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Subtype indicator:
X'00' = file close
X'01' = partial</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td align="right"> 4</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td align="right"> 8</td>
<td> EBCDIC</td>
<td>File name</td>
</tr>

<tr>
<td> 24(18)</td>
<td align="right"> 2</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>
</table>

The following table lists the file statistics and the decimal(hexidecimal) offset. These statistics are data type Binary and eight bytes long.
<table>
<caption>File statistics</caption>
<tr class="head">
<th>File statistic </th>
<th>Offset dec(hex) </th>
</tr>

<tr>
<td>DKRD </td>
<td>26(1A) </td>
</tr>

<tr>
<td>DKWR </td>
<td>34(22) </td>
</tr>

<tr>
<td>REQ </td>
<td>42(2A) </td>
</tr>

<tr>
<td>RETRYA </td>
<td>50(32) </td>
</tr>

<tr>
<td>RETRYC </td>
<td>58(3A) </td>
</tr>

<tr>
<td>DUPDTS </td>
<td>66(42) </td>
</tr>

<tr>
<td>RECADD </td>
<td>74(4A) </td>
</tr>

<tr>
<td>RECDEL </td>
<td>82(52) </td>
</tr>

<tr>
<td>BADD </td>
<td>90(5A) </td>
</tr>

<tr>
<td>BDEL </td>
<td>98(62) </td>
</tr>

<tr>
<td>BCHG </td>
<td>106(6A) </td>
</tr>

<tr>
<td>IXADD </td>
<td>114(72) </td>
</tr>

<tr>
<td>IXDEL </td>
<td>122(7A) </td>
</tr>

<tr>
<td>DIRRCD </td>
<td>130(82) </td>
</tr>

<tr>
<td>BXCHNG </td>
<td>138(8A) </td>
</tr>

<tr>
<td>BXDELE </td>
<td>146(92) </td>
</tr>

<tr>
<td>BXNEXT </td>
<td>154(9A) </td>
</tr>

<tr>
<td>BXFIND </td>
<td>162(A2) </td>
</tr>

<tr>
<td>BXINSE </td>
<td>170(AA) </td>
</tr>

<tr>
<td>BXSPLI </td>
<td>178(B2) </td>
</tr>

<tr>
<td>BXRFND </td>
<td>186(BA) </td>
</tr>

<tr>
<td>BXFREE </td>
<td>194(C2) </td>
</tr>

<tr>
<td>UPDTTIME </td>
<td>202(CA) </td>
</tr>

<tr>
<td>PNDGTIME </td>
<td>210(D2) </td>
</tr>

<tr>
<td>DKUPTIME </td>
<td>218(DA) </td>
</tr>

<tr>
<td>COMMITS </td>
<td>226(E2) </td>
</tr>

<tr>
<td>BACKOUTS </td>
<td>234(EA) </td>
</tr>
</table>

==Text entries (Type 11, Type 13)==

Type 11 (X'0B') and Type 13 (X'0D') entries record most of the actual text of the audit trail.

===Noncontinued text entries, Type 11 (X'0B')===

Each Type 11 journal entry corresponds to one logical entry in the audit trail, even though it might generate more than one line of physical output in the audit trail. 

The format of a Type 11 entry is shown in the following table: 
<table>
<caption>Noncontinued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'0B'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Subtype indicator:

X'01' = LI line

X'02' = LP line

X'03' = LR line

X'04' = CI line

X'05' = QT line

X'08' = CP line

X'10' = OI line

X'20' = OO line

X'40' = LS line

X'80' = CS line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>

===Possibly continued text entries, Type 13 (X'0D')===

Each Type 13 journal entry corresponds to one, or part of one, logical entry in the audit trail. See the [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Example|Types of audit trail lines]] table for a definition of the line types.

The format of a Type 13 entry is shown in the following table: 
<table>
<caption>Possibly continued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0D'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = US line

X'02' = XX line

X'04' = RK line

X'08' = AD line

X'10' = MS line

X'20' = ER line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td> 14(0E)</td>
<td> 2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td> 16(10)</td>
<td> Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>
Note:
Subtype indicator X'80' summed with any subtype means continuation into the next entry. 

==Initialization entries, Type 12 (X'0C')==

One Type 12 journal entry is written as the first nonheader entry in the journal during initialization. It contains basic information about the run being initialized.

The format of a Type 12 entry is shown in the following table:
<table>
<caption>Initialization entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'001A'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0C'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> —</td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 8</td>
<td> EBCDIC</td>
<td>Version ID (for example, 4.2.0G)</td>
</tr>

<tr>
<td> 20(14)</td>
<td> 2</td>
<td> Binary</td>
<td>Spare for the run</td>
</tr>

<tr>
<td> 22(16)</td>
<td> 4</td>
<td> EBCDIC</td>
<td>SMF ID (SYSID parameter) </td>
</tr>
</table>

==Time-stamp entries, Type 14 (X'0E')==

Type 14 entries are used to force time-stamps to the journal. 

The format of a Type 14 entry is shown in the following table: 
<table>
<caption>Time-stamp entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td>2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0E'</td>
</tr>

<tr>
<td>3(3)</td>
<td> 1</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td>4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Merged journal bracketing entries (Type 15)==

Type 15 entries appear only in the output of the MERGEJ utility. See [[System and media recovery#Using the MERGEJ utility|Using the MERGEJ utility]]. 

The format of a Type 15 entry is shown in the following table:
<table>
<caption>Merged journal bracketing entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'002E'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0F'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = begin bracket

X'02' = end bracket
</td>
</tr>

<tr>
<td> 4(4)</td>
<td>12(0C)</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td>2(2)</td>
<td> Binary </td>
<td>Number of journals merged together</td>
</tr>

<tr>
<td> 18(12)</td>
<td>28(1C)</td>
<td>EBCDIC</td>
<td>Text:
<ul>
<li>For subtype X'01' = BEGINNING OF MERGED JOURNAL</li>

<li>For subtype X'02' = END OF MERGED JOURNAL</li>
</ul>
</td></tr>
</table>

==System Management Facilities==

You can write certain statistics to the System Management Facilities (SMF) data set by: 
<ul>
<li>Setting the <var>[[SMFSLRN parameter|SMFSLRN]]</var> and <var>[[SMFLORN parameter|SMFLORN]]</var> parameters on the User 0 command line to activate the SMF feature. (z/OS and z/VM)</li>

<li>Modifying the program that processes the SMF data set to handle the records written by <var class="product">Model 204</var>. (z/VM only)</li>
</ul>

See the [[#z/VM requirements|z/VM requirements]] and the the [[#z/OS requirements|z/OS requirements]] sections for details.

Since-last statistics or logout statistics can be written concurrently with statistics that are written to the journal. Logout statistics are more complete than since-last statistics. Many more since-last records than logout records are usually written. 

If the operating system crashes before a user logs out, the SMF data set has a since-last record for every request run, but no logout record. 

File and system statistics cannot be written to the SMF data set.

During system initialization, <var class="product">Model 204</var> issues a message reporting the SMF system ID, the run's job name, the step name, and the JES ID. For operating systems other than z/OS, the JES ID is blank.

===z/VM requirements===

In the CMS interface to <var class="product">Model 204</var>, you can incorporate a user-written accounting exit that invokes the ACCTEXIT routine to process each statistics record as it is written. The following considerations apply:
<ul>
<li>Take care to preserve the CMS environment in which <var class="product">Model 204</var> is running. Do not change the contents of general registers 13 and 14.</li>

<li>You must specify the <var>SMFLORN</var> and/or <var>SMFSLRN</var> parameters on User 0's parameter line to activate accounting record production.</li>

<li>TEXT file for the ACCTEXIT module must be available on an accessed disk when generating M204CMS using M204GEN. For complete installation procedures, see the <var class="book">Rocket Model 204 z/VM Installation Guide</var>.</li>
</ul>

===z/OS requirements===

To write since-last SMF records in a z/OS environment, activate the SMF feature. 

To activate SMF, set the following parameters on User 0's parameter line: 
<ul>
<li>SMFSLRN — SMF record number for since-last records</li>

<li>SMFLORN — SMF record number for logout records </li>
</ul>

The following considerations apply:
<ul>
<li>Since-last SMF records are written only if the SMFSLRN parameter is set to a non-zero value at the beginning of the run.</li>

<li>Logout SMF records are written only if the SMFLORN parameter is set to a non-zero value at the beginning of the run.</li>

<li>If both parameters are set, each type of record is written.</li>
</ul>

SMF record numbers, which identify the record type to the programs that process the SMF data set, are written as part of the header of the SMF records. The record numbers must be between 128 and 255.

See the "System Management Facility record layout and statistics" section, which follows.

==System Management Facility record layout and statistics==

===SMF logout record layout===

The following table shows the basic format of the <var class="product">Model 204</var> SMF logout record: 
<table>
<caption>Basic format of Model 204 SMF logout record</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length</th>
<th> Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td>2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td>4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td>5(5)</td>
<td> 1</td>
<td>Record number (<var>SMFSLRN</var> or <var>SMFLORN</var>)</td>
</tr>

<tr>
<td>6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td> 1</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: x'4C'
For V7.7: x'4D'
For V7.8: x'4E'
</td>
</tr>

<tr>
<td>58(3A)</td>
<td> 2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable
4-character field retrieved from the SMF control area.

The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.
</li>
</ul>

====Offsets for SMF logout record statistics====

The following table shows the layout of SMF logout record statistics. Each statistic in the table is: Length, 4 (bytes); data type, Binary.
This record has the same statistics in the same order as the CCAJRNL logout record, only the offsets are different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]] table.
<table>
<caption>Offset location of SMF logout record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>60(3C) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 64(40) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 68(44) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 72(48) </td>
<td>SQRD</td>
</tr>

<tr>
<td> 76(4C) </td>
<td>SQWR</td>
</tr>

<tr>
<td> 80(50) </td>
<td>SGMTI</td>
</tr>

<tr>
<td> 84(54) </td>
<td>SGMTO</td>
</tr>

<tr>
<td> 88(58) </td>
<td>SVRD</td>
</tr>

<tr>
<td> 92(5C) </td>
<td>SVWR</td>
</tr>

<tr>
<td> 96(60) </td>
<td>CPU</td>
</tr>

<tr>
<td>100(64) </td>
<td>REQ</td>
</tr>

<tr>
<td>104(68) </td>
<td>MOVE</td>
</tr>

<tr>
<td>108(6C) </td>
<td>DUMP</td>
</tr>

<tr>
<td>112(70) </td>
<td>REST</td>
</tr>

<tr>
<td>116(74) </td>
<td>SLIC</td>
</tr>

<tr>
<td>120(78) </td>
<td>AUDIT</td>
</tr>

<tr>
<td>124(7C) </td>
<td>WAIT</td>
</tr>

<tr>
<td>128(80) </td>
<td>FBWT</td>
</tr>

<tr>
<td>132(84) </td>
<td>UDD</td>
</tr>

<tr>
<td>136(88) </td>
<td>RECADD</td>
</tr>

<tr>
<td>140(8C) </td>
<td>RECDEL</td>
</tr>

<tr>
<td>144(90) </td>
<td>BADD</td>
</tr>

<tr>
<td>148(94) </td>
<td>BDEL</td>
</tr>

<tr>
<td>152(98) </td>
<td>BCHG</td>
</tr>

<tr>
<td>156(9C) </td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td>164(A4) </td>
<td>FINDS</td>
</tr>

<tr>
<td>168(A8) </td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC) </td>
<td>RECDS</td>
</tr>

<tr>
<td>176(B0) </td>
<td>STRECDS</td>
</tr>

<tr>
<td>180(B4) </td>
<td>DKAR</td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKPR</td>
</tr>

<tr>
<td>188(BC) </td>
<td>DKRR</td>
</tr>

<tr>
<td>192(C0) </td>
<td>COMMITS</td>
</tr>

<tr>
<td>196(C4) </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>200(C8) </td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>204(CC) </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>208(D0) </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>212(D4) </td>
<td>SMPLS</td>
</tr>

<tr>
<td>216(D8) </td>
<td>RUNG</td>
</tr>

<tr>
<td>220(DC) </td>
<td>REDY</td>
</tr>

<tr>
<td>224(E0) </td>
<td>BLKI</td>
</tr>

<tr>
<td>228(E4) </td>
<td>WTSV</td>
</tr>

<tr>
<td>232(E8) </td>
<td>BLKO</td>
</tr>

<tr>
<td>236(EC) </td>
<td>SWPG</td>
</tr>

<tr>
<td>240(F0) </td>
<td>PCPU</td>
</tr>

<tr>
<td>244(F4) </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>248(F8) </td>
<td>BXCHNG</td>
</tr>

<tr>
<td>252(FC) </td>
<td>BXDELE</td>
</tr>

<tr>
<td>256(100) </td>
<td>BXNEXT</td>
</tr>

<tr>
<td>260(104)</td>
<td>BXFIND</td>
</tr>

<tr>
<td>264(108)</td>
<td>BXINSE</td>
</tr>

<tr>
<td>268(10C)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td>272(110)</td>
<td>BXFND</td>
</tr>

<tr>
<td>276(114)</td>
<td>BXFREE</td>
</tr>

<tr>
<td>280(118)</td>
<td>STCPU</td>
</tr>

<tr>
<td>284(11C)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>288(120)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>292(124)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>296(128)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>300(12C)</td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>312(138)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>344(158)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>348(15C)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>352(160)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>380(17C)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>384(180)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>388(184)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>392(188)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>400(190)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>404(194)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>408(198)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>412(19C)</td>
<td>Spare </td>
</tr>

<tr>
<td>416(1A0)</td>
<td>Spare</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>Spare</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>Spare</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>Spare</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>Spare</td>
</tr>
</table>

===SMF since-last record layout===

The following table shows the basic format of since-last <var class="product">Model 204</var> SMF records. 
<table>
<caption>Since-last record basic format</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length (bytes)</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td> 5(5)</td>
<td> 1</td>
<td>Record number (SMFSLRN)</td>
</tr>

<tr>
<td> 6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td>1</td>
<td>SMFSLTYP - X'01' if CRFJRNL=1 (conflict counters present)

SMFSLTYP - X'00' if CRFJRNL=0 (conflict counters not present)
</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: <code>x'4C'</code>
For V7.7: <code>x'4D'</code>
For V7.8: <code>x'4E'</code>
</td>
</tr>

<tr>
<td>58(3A)</td>
<td>2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> 4</td>
<td>Since-last type (EVAL CMPL DUMP REST...)</td>
</tr>

<tr>
<td>64(40)</td>
<td> 8</td>
<td>File name</td>
</tr>

<tr>
<td>72(48)</td>
<td>10</td>
<td>Since-last subsystem name</td>
</tr>

<tr>
<td>82(52)</td>
<td>40</td>
<td>Since-last procedure name</td>
</tr>

<tr>
<td>122(7A)</td>
<td>2</td>
<td>Reserved two bytes</td>
</tr>

<tr>
<td>124(7C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable 4-character field retrieved from the SMF control area.</li>

<li>The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.</li>
</ul>

====Offsets for SMF since-last record statistics====

The following table shows the layout of SMF since-last record statistics. Each statistic in the table is: Length, 4 (bytes); Data type, Binary.
This record has the same statistics in the same order as the CCAJRNL user since-last records; only the offsets are
different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]]
table. 
<table>
<caption>SMF since-last record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td> 124(7C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 128(80)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 132(84)</td>
<td>QTBL</td>
</tr>

<tr>
<td> 136(88) </td>
<td>STBL</td>
</tr>

<tr>
<td> 140(8C)</td>
<td>TTBL</td>
</tr>

<tr>
<td> 144(90)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 148(94)</td>
<td>PDL</td>
</tr>

<tr>
<td> 152(98)</td>
<td>FTBL</td>
</tr>

<tr>
<td> 156(9C)</td>
<td>XTBL</td>
</tr>

<tr>
<td> 160(A0)</td>
<td>ITBL</td>
</tr>

<tr>
<td> 164(A4)</td>
<td>FSCB</td>
</tr>

<tr>
<td> 168(A8)</td>
<td>OUTPB</td>
</tr>

<tr>
<td> 172(AC) </td>
<td>HEAP</td>
</tr>

<tr>
<td> 176(B0) </td>
<td>SQLI</td>
</tr>

<tr>
<td> 180(B4) </td>
<td>SQLO</td>
</tr>

<tr>
<td> 184(B8) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 188(BC) </td>
<td>CPU</td>
</tr>

<tr>
<td> 192(C0) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 196(C4) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 200(C8) </td>
<td>UDD</td>
</tr>

<tr>
<td> 204(CC) </td>
<td>OUT</td>
</tr>

<tr>
<td> 208(D0) </td>
<td>SLIC</td>
</tr>

<tr>
<td> 212(D4) </td>
<td>IN</td>
</tr>

<tr>
<td> 216(D8) </td>
<td>RECADD</td>
</tr>

<tr>
<td> 220(DC) </td>
<td>RECDEL</td>
</tr>

<tr>
<td> 224(E0) </td>
<td>BADD</td>
</tr>

<tr>
<td> 228(E4) </td>
<td>BDEL</td>
</tr>

<tr>
<td> 232(E8) </td>
<td>BCHG</td>
</tr>

<tr>
<td> 236(EC) </td>
<td>IXADD</td>
</tr>

<tr>
<td> 240(F0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td> 244(F4) </td>
<td>FINDS</td>
</tr>

<tr>
<td> 248(F8) </td>
<td>SORT</td>
</tr>

<tr>
<td> 252(FC) </td>
<td>RECDS</td>
</tr>

<tr>
<td> 256(100)</td>
<td>STRECDS</td>
</tr>

<tr>
<td> 260(104)</td>
<td>PCPU</td>
</tr>

<tr>
<td> 264(108)</td>
<td>RQTM</td>
</tr>

<tr>
<td> 268(10C)</td>
<td>DIRRCD</td>
</tr>

<tr>
<td> 272(110)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td> 276(114)</td>
<td>BXDELE</td>
</tr>

<tr>
<td> 280(118)</td>
<td>BXNEXT</td>
</tr>

<tr>
<td> 284(11C)</td>
<td>BXFIND</td>
</tr>

<tr>
<td> 288(120)</td>
<td>BXINSE</td>
</tr>

<tr>
<td> 292(124)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td> 296(128)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 300(12C)</td>
<td>BXFREE</td>
</tr>

<tr>
<td> 304(130)</td>
<td>STCPU</td>
</tr>

<tr>
<td> 308(134)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 312(138)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 316(13C)</td>
<td>SCREENS</td>
</tr>

<tr>
<td> 320(140)</td>
<td>SVRD</td>
</tr>

<tr>
<td> 324(144)</td>
<td>SVWR</td>
</tr>

<tr>
<td> 328(148)</td>
<td>DKPR</td>
</tr>

<tr>
<td> 332(14C)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>336(150)</td>
<td>COMMITS</td>
</tr>

<tr>
<td>340(154)</td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>344(158)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>348(15C)</td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>352(160)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>368(170)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>372(174)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>376(178)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>380(17C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>384(180)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>388(184)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>392(188)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>396(18C)</td>
<td>MAPICNT</td>
</tr>

<tr>
<td>400(190)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>404(194)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>408(198)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>412(19C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>444(1BC)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>448(1C0)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>452(1C4)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>456(1C8)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>460(1CC)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>464(1D0)</td>
<td>Sirius</td>
</tr>

<tr>
<td>468(1D4)</td>
<td>Sirius</td>
</tr>

<tr>
<td>472(1D8)</td>
<td>Sirius</td>
</tr>

<tr>
<td>476(1DC)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>480(1E0)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>484(1E4)</td>
<td>Spare</td>
</tr>

<tr>
<td>488(1E8)</td>
<td>Spare</td>
</tr>
</table>

The following table lists the conflict statistics, if <code>CFRJRNL=1</code>:

<table>
<caption>Conflict statistics, if CFRJRNL=1</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td>492(1EC)</td>
<td>BLKCFRE</td>
</tr>

<tr>
<td>496(1F0)</td>
<td>BLKRLK</td>
</tr>

<tr>
<td>500(1F4)</td>
<td>WTCFR</td>
</tr>

<tr>
<td>504(1F8)</td>
<td>WTRLK</td>
</tr>
</table>

[[Category:System management]]
[[Category:System-level capabilities of Model 204]]

Checkpoints: Storing before-images of changed pages

2025-09-02T04:58:13Z

Goff: Add tables X and E

==Overview of the Checkpoint facility==

The <var class="product">Model 204</var> Checkpoint facility stores before-images of changed pages, or described another way, saves the image before applying the change to a page. <var class="product">Model 204</var> supports two types of checkpoints: transaction and sub-transaction.
<ul>
<li>Transaction checkpoints are identical to what in pre-V6R1.0 <var class="product">Model 204</var> releases were simply called checkpoints. If a transaction checkpoint is not taken within a certain period because of too much update traffic, that is, times out, the Checkpoint facility tries again at the next interval.</li>

<li>Sub-transaction checkpoints guarantee that a checkpoint is taken at the specified interval, which involves switching back and forth between transaction and sub-transaction checkpoints.</li>
</ul>

You can elect to take only transaction checkpoints by setting the <var>[[CPTYPE parameter|CPTYPE]]</var> parameter to 0, or you can take both transaction and sub-transactions by setting <var>CPTYPE</var> to 1.
<ul>
<li>Transaction checkpoints are saved to CHKPOINT, a sequential data set that contains copies of file pages before updates are applied (before-images, also called preimages) and marker records (checkpoints) that record the date and time when the system is quiescent (no updating activity). </li>

<li>Sub-transaction checkpoints are saved to CHKPNTS, the same type of sequential data set that saves the same information.</li>
</ul>

<var class="product">Model 204</var> would use either CHKPOINT or CHKPNTS during recovery to restore (roll back) the original contents of updated files at a particular checkpoint, usually the most recent.

====For more information====

This page discusses the Checkpoint facility, preimage logging, and dumping the CHKPOINT file with the UTILC utility. 
<ul>
<li>Checkpoints in HLI are discussed in detail in [[HLI: Model 204 recovery and checkpoints]].</li>

<li>[[System and media recovery#Recovery data sets and job control|Recovery data sets and job control]] explains how to use CHKPOINT in the recovery process.</li>

<li>Checkpoint data stream configurations are described in [[Configuring checkpoint and journal data streams]]. </li>
</ul>

==Understanding the Checkpoint facility==

Checkpoint markers and preimage copies of database pages are recorded on a sequential data set called CHKPOINT (and CHKPNTS). Checkpoints taken during a <var class="product">Model 204</var> run mark times when no updates are in progress. Between checkpoints, before-images of <var class="product">Model 204</var> file pages are recorded in a checkpoint file as files are updated. After a system crash, you can roll back the database to its status at the time of a specific checkpoint. Changes made in the files between the time of that checkpoint and the time of the system crash are removed. 

Checkpoints are taken on all files simultaneously to preserve logical file consistency. When file changes are rolled back, all files, regardless of their condition, are automatically restored to a checkpoint. Unless otherwise specified, files are rolled back to the most recent checkpoint.

By using the Checkpoint facility in conjunction with the Roll Back and Roll Forward facilities, you can recover a valid copy of the <var class="product">Model 204</var> database after a system failure. 

===Checkpoint parameters===

You control the operation of the Checkpoint facility by specifying parameters on User 0's parameter line. The following table lists the checkpoint parameters: 
<table class="thJustBold">
<caption>Checkpoint and recovery parameters</caption>
<tr class="head">
<th>Parameter</th>
<th>Meaning</th>
</tr>

<tr>
<th>CPMAX</th>
<td>Maximum number of checkpoints saved during the run. The default is 32767. </td>
</tr>

<tr>
<th>CPTIME</th>
<td>Time in minutes between attempts to take automatic checkpoints. The default is 0.</td>
</tr>

<tr>
<th>CPTO</th>
<td>Amount of time in seconds allowed to quiesce updating User Language users, command users, and online IFAM jobs. The default is 0.</td>
</tr>

<tr>
<th>CPTQ </th>
<td>Amount of time allowed in seconds to quiesce updating batch Host Language Interface jobs. The default is 0.</td>
</tr>

<tr>
<th>CPTS</th>
<td>Time interval for in-flight transactions to complete before going into a sub-transaction wait.</td>
</tr>

<tr>
<th>CPTYPE</th>
<td>Choosing to use transaction-only checkpoints, or both transaction and sub-transaction checkpoints</td>
</tr>

<tr>
<th>CPSORT</th>
<td>Maximum number of times to retry an attempt to take a checkpoint initiated by the start or end of an IFAM2 job.</td>
</tr>

<tr>
<th>FRCVOPT</th>
<td>File recovery options. Settings indicate whether or not a file participates in checkpoint and/or roll forward logging.</td>
</tr>

<tr>
<th>NSUBTKS</th>
<td>Checkpoint facility uses three internal processes called pseudo subtasks (PSTs). The setting of this parameter must reserve at least three slots for checkpoint use, if checkpointing is active. Add another pseudo subtask for asynchronous checkpointing in an environment that supports 31-bit processing. </td>
</tr>

<tr>
<th>RCVOPT</th>
<td>Recovery options. Settings activate the Checkpoint facility and govern checkpoint and journal logging.</td>
</tr>
</table>

===Taking a checkpoint===

The process of taking a checkpoint is activated by one of the following events:
<ul>
<li>Expiration of the specified time between checkpoints (<var>CPTIME</var>)</li>

<li><var>CHECKPOINT</var> command </li>

<li>Host Language Interface <var>IFCHKPT</var> call </li>

<li>Host Language Interface <var>IFSTRT</var> and <var>IFFNSH</var> calls</li>
</ul>
Note:
Only the first <var>IFSTRT</var> call from an IFAM2 job activate/s the CHKPPST pseudo subtask. Subsequent <var>IFSTRT</var>s for the same IFAM2 job do not initiate checkpoint attempts. 

===Checkpoint algorithm===

Once activated, the checkpoint algorithm proceeds as follows: 
<ol>
<li>Prevents any new update units from starting until the checkpoint process is completed. </li>

<li>Waits a preset number of seconds for updating threads to quiesce.

The length of the wait depends on the type of threads that have active update units and the settings of the <var>CPTQ</var> and <var>CPTO</var> parameters.
<ul>
<li>If no update units are active, there is no wait.</li>

<li>If update units are active on batch Host Language Interface threads whose connection to the ONLINE region is initiated with an <var>IFSTRT</var> call, the task waits the number of seconds specified in the <var>CPTQ</var> parameter, or until all such threads have quiesced. </li>

<li>If update units are active on User Language threads or Host Language Interface threads whose connections to the ONLINE region are initiated with an <var>IFDIAL</var> call, the task waits the number of seconds specified in the <var>CPTO</var> parameter, or until all such threads have quiesced. </li>
</ul></li>

<li>Times out the checkpoint if the specified number of seconds passes and update units are still active. </li>

<li>Writes a checkpoint record to the CHKPOINT file. </li>

<li>Allows new update units to begin after a checkpoint is taken or timed out. </li>
</ol>

If checkpoint has timed out, <var class="product">Model 204</var> attempts to take a checkpoint each time an update unit completes.

===Taking asynchronous checkpoints (31-bit)===

Taking asynchronous checkpoints is supported in operating environments with 31-bit processing. This reduces the amount of wait time for preimage writes to the checkpoint data set.

The pseudo subtask CHKPAWW performs the wait for preimage writes. If you are running in 31-bit mode, add one to the value of the NSUBTKS parameter. You might also need to increase the value of the <var>LPDLST</var> parameter. 

===Using the CHECKPOINT command===

If a user issues the <var>CHECKPOINT</var> command to take a checkpoint, control returns immediately to the terminal of the user who issued the command. The terminal does not wait for the checkpoint to complete. When the checkpoint process is complete, a message indicating the status of the checkpoint is issued to the terminal of the user who entered the command. If update units are active, control is returned to the user without taking a checkpoint. 

===Checkpoint processing with IFSTRT or IFFNSH calls===

Whenever the CHKPPST pseudo subtask is activated by a Host Language Interface <var>IFSTRT</var> or <var>IFFNSH</var> call, a nonzero value specified on <var>CPSORT</var> causes the CHKPPST task to loop through the waiting process the number of times specified on <var>CPSORT</var>. New update units must wait for the entire length of the looping process. 

For more information about the effect of <var>CPSORT</var> values on the CHKPPST task, refer to the <var class="book">Rocket Model 204 Host Language Interface Reference Manual</var>. 

===Determining the status of a checkpoint===

Any terminal user can issue the <var>[[CHKMSG command|CHKMSG]]</var> command to obtain a copy of the most recent checkpoint message. Host language users can issue an <var>IFCHKPT</var> call to determine the status of the most recent checkpoint. One of the following checkpoint status information messages is broadcast to the operator's console each time CHKPPST is activated (attempts to take a checkpoint):
*** M204.0843: CHECKPOINT COMPLETED ON date/time


or
*** M204.0843: CHECKPOINT TIMED OUT ON date/time DUE TO USER nn


===Aborting a checkpoint===

If a pending checkpoint causes too great a delay in new request initiation or host language jobs, a user with system manager privileges can issue the <var>[[CHKABORT command|CHKABORT]]</var> command to cause the pending checkpoint to time-out immediately. The <var>CHKABORT</var> command is issued without arguments.

===M204CKPX checkpoint user exit===

The checkpoint user exit, M204CKPX, can be invoked if linked in. This exit runs after the <var>CHECKPOINT</var> records are written, and just before the <code>CHECKPOINT COMPLETED</code> message is issued. All <var class="product">Model 204</var> databases are physically consistent on disk at this time, because all updated pages have been flushed to disk to prepare for checkpoint processing. 

The exit runs before any update users are allowed to run in the Online, which allows users to write an exit that backs up all their database files, between the hours of <code>x</code> and <code>y</code>, all based on the user exit code. 

When the exit abends or completes, the Online releases updating users to run and continues. Because this exit is invoked each time a checkpoint is taken, you must forego any extensive processing until the Online is in a low use period, then back up the files.

====Example====

The following example is a M204CKPX ASSEMBLER exit. You can use the shell of the following program to write your own user exit. If your user exit abends, <var class="product">Model 204</var> tries to continue. All registers can be used. You can safely copy the files because the modified pages have all been flushed to disk and are physically consistent. The Online continues to service read-only users, and updating is suspended until this exit completes. You might want to include your own <code>ESTAE</code> exit macro to deal with abends. 

A sample M204CKPX ASSEMBLER exit:
M204CKPX CSECT
M204CKPX AMODE 31
M204CKPX TITLE 'TEST THE MODEL 204 CHECKPOINT USER EXIT'
X10 EQU 10
X11 EQU 11
X12 EQU 12
X13 EQU 13
X14 EQU 14
X15 EQU 15
STM X14,X12,12(X13) SAVE CALLERS REGISTERS
LR X12,X15 ESTABLISH BASE REGISTER
USING M204CKPX,X12
LA X10,SAVEAREA GET A(LOCAL REGISTER SAVEAREA)
ST X10,8(,X13) CHAIN OUR SAVEAREA TO CALLERS
ST X13,SAVEAREA+4 CHAIN CALLERS SAVEAREA TO OURS
LA X13,SAVEAREA SET A(OUR SAVEAREA)
WTO 'M204CKPX CHECKPOINT EXIT INVOKED, UPDATERS SUSPENDED'

* ********************************************************** *
* * Add code here that calls routines to back up your * *
* * Model 204 databases. * *
* * * *
* DC X'000000000000' TEST TO SEE WHAT HAPPENS WHEN * *
* THE USER EXIT ABENDS * *
* ********************************************************** *
WTO 'M204CKPX EXIT ENDING, UPDATERS WILL BE RELEASED'
L X13,4(,X13) RESTORE CALLERS SAVE AREA ADDRESS
ST X10,16(X13) SET RETURN CODE (R15)
LM X14,X12,12(X13) RESTORE CALLERS REGISTERS
BR X14 RETURN TO CALLER
DS 0D
SAVE AREA DS 18F REGISTER SAVE AREA
LTORG
END


If <var class="product">Model 204</var> detects an abend in the M204CKPX exit, the following message is written to the JES log or is displayed on the z/VM console:
M204.CKPX: ABEND IN M204CKPX IGNORED, ATTEMPTING TO CONTINUE

<blockquote class="note">
Note:
If M204CKPX abends, <var class="product">Model 204</var> attempts to continue processing, but there is no guarantee that it can do so. Further processing might be prevented for one of the following reasons:
<ul>
<li>M204CKPX destroyed storage that <var class="product">Model 204</var> depends on.</li>

<li>Left interrupts disabled, or did not restore the ESTAE or ESPIE macro routines. </li>
</ul></blockquote>

==Overview of sub-transaction checkpoints==

A sub-transaction checkpoint is a checkpoint that can be taken while updating transactions are in progress and un-committed, eliminating checkpoint timeout situations. A sub-transaction checkpoint is a guaranteed checkpoint; it can be taken under almost all updating situations. 

The exceptions are long-running file-update commands, which must run to completion before a transaction or a sub-transaction checkpoint can be taken. Examples of potentially long-running file-update commands are <var>CREATE</var>, <var>INITIALIZE</var>, and <var>REDEFINE FIELD</var>. If any of these commands require an extended period of time to complete, a sub-transaction checkpoint will be postponed. Generally, these commands are issued infrequently in production Onlines.

Guaranteed checkpoints improve recover ability, reduce recovery time, and further improve 24 X 7 availability.

Transaction checkpoints are identical to what in previous <var class="product">Model 204</var> releases were simply called checkpoints.

===Reviewing transaction checkpoints===

At the time a transaction checkpoint is taken, all updates have ended and been written to their respective M204 disk files. A transaction checkpoint is indicated by a date/time stamp record on the checkpoint, journal, and deferred update data sets, and represents a state to which a restart rollback can restore a set of <var class="product">Model 204</var> files, in preparation for using roll forward to reapply later updates.

For a transaction checkpoint to be taken, user threads must end their update units. This can be done with some form of <var>COMMIT</var> or <var>IFCHKPT</var>.

===Introducing sub-transaction checkpoints===

At the time a sub-transaction checkpoint is taken, all updates will not have ended (although a non-zero value of <var>[[CPTS parameter|CPTS]]</var> will give them time to do so and therefore change a sub-transaction checkpoint attempt into a transaction checkpoint). 

A typical update unit is made up of a sequence of sub-transactions. A typical sub-transaction consists of reading a <var class="product">Model 204</var> page to be updated, writing the image of the page to the checkpoint stream, making an update to the page, creating a back out and constraint entries in CCATEMP (in case the update is backed out) and writing the update to the journal stream.

At the time a sub-transaction checkpoint is taken, all sub-transactions will have ended and been written to their respective <var class="product">Model 204</var> disk files. However, there will still be active update units with associated non-zero back out and constraint entries. These are written to the checkpoint stream. So, a sub-transaction checkpoint is indicated by a date/time stamp record on the checkpoint stream, along with all back out and constraint entries for active updates. This is followed by a sub-transaction checkpoint completion record. The checkpoint stream therefore contains a snapshot of active update units at the time of checkpoint. 

For sub-transaction checkpoints only the initial date/time stamp record is written to the journal stream and deferred update data sets. 

===Using sub-transaction checkpoints in recovery===

At restart recovery, the back out and constraint logs from the input restart streams are used recreate the update environment needed to recover transactions interrupted by the original sub-transaction checkpoint. 

Sub-transaction enabled Onlines use two checkpoint streams: CHKPOINT and CHKPNTS. At any given time during the Online run, one stream or the other is the current checkpoint stream — the one to which preimages are written. 

A sub-transaction checkpoint causes the current stream to be switched and checkpoint information written to the beginning of the new stream. If the Online comes down before the sub-transaction checkpoint completes then it is unusable and the previous good checkpoint must be used for restart recovery. 

[[CCATEMP]], <var>[[NDIR parameter|NDIR]]</var>, and <var>[[NFILES parameter|NFILES]]</var> must be the same size or greater than the settings used in the run being recovered.

===Using transaction or sub-transaction checkpoints===

If a transaction checkpoint is taken on an sub-transaction enabled Online then the current checkpoint stream is rewound instead of switched. 
Note: The initialization and termination checkpoints are always transaction checkpoints. The command <code>CHECKPOINT E Q</code> forces the next checkpoint to be a transaction checkpoint. The checkpoint at the end of a roll forward is always a transaction checkpoint.

IFAM SIGNON/SIGNOFF and <var>IFCHKPT</var> checkpoints are always transaction checkpoints. And, there are certain run configurations and checkpoint stream/ and file type configurations, which require all checkpoints to be transaction checkpoints. This means that sub-transaction checkpoints cannot be enabled for those configurations. An example of this is a <code>NUSER=1</code> run. 

==Considerations for implementing sub-transaction checkpoints==

Sites that find they regularly have checkpoints timeout, with no intervening successful checkpoint over a significant duration of time, might consider this option.

The best way to rectify this situation is to attempt to modify the applications that cause checkpoints to timeout by improving the use of the <var>Commit</var> statement. However, this may not be a reasonable approach given time and resource constraints or the nature of the application.

An Online with sub-transaction checkpoints enabled uses multiple KOMMs.

==Implementing sub-transaction checkpoints in your job==

The <var>CPTYPE</var> parameter designates the type of checkpoints to use: 
<ul>
<li><code>CPTYPE=0</code>, the default, indicates that transaction checkpoints are activated. </li>

<li><code>CPTYPE=1</code> indicates that both transaction and sub-transaction checkpoints are activated. </li>
</ul>
Note: <var>CPTYPE</var> is resettable by the system manager.

===Requirements for CPTYPE=1===

To enable sub-transaction checkpoints, you must make the following adjustments to your data sets and <var class="product">Model 204</var> parameters. Otherwise the run terminates with one of the <code>M204.2684</code> messages, for example:
M204.2684 CHECKPOINT CONFIGURATION CONFLICT

<ul>
<li>The data set CHKPNTS must be defined to the job, in addition to CHKPOINT. Rocket Software recommends that you allocate the CHKPNTS data set with the same space parameters as the CHKPOINT data set.

If the CHKPNTS data set is not defined or cannot be opened, an error message is issued during initialization and the job is terminated.</li>

<li>The <var>NUSERS</var> parameter must be greater than one. If <var>NUSERS</var> equals one, then any stream definition for CHKPNTS is ignored and the run is not a sub-transaction enabled run. </li>

<li>If you set <var>CPMAX</var> to greater than one, the following message is issued, and <var class="product">Model 204</var> resets <var>CPMAX</var> to one:
M204:2685 CHKPNTS IS OPEN SO CPMAX SET TO 1
</li>

<li>The <var>DKUPDTWT</var> parameter must be set to zero, which is the default.</li>

<li>You can set the <var>CPTS</var> parameter to establish the number of seconds to delay the start of new updating transactions. A non-zero <var>CPTS</var> time interval gives in-flight transactions a chance to end before they are forced into a sub-transaction wait.

If all transactions end during the <var>CPTS</var> interval, a transaction checkpoint is taken instead of a sub-transaction checkpoint. </li>

<li>The <var>CPTIME</var> parameter is still required to establish the time interval, in minutes, between automatic checkpoints. It must be greater than zero.</li>

<li>Set <var>RCVOPT</var> to nine to enable checkpoints and journals.</li>
</ul>

<var>CPTO</var> and <var>CPTQ</var> can be left in your CCAIN stream even if you set <code>CPTYPE=1</code>. However, they will be ignored unless <var>CPTYPE</var> is reset to 0.

As long as all data sets and parameters are appropriately defined and requirements met within your job, you can reset back and forth between <code>CPTYPE=0</code> and <code>CPTYPE=1</code>.

===Checkpoint definition restrictions for sub-transaction checkpoints===

Both CHKPOINT and CHKPNTS must be present. Each may be defined as a stream but may not contain:
<ul>
<li>A ring stream </li>

<li>More that 16 levels of recursive stream definitions</li>

<li>A CMS formatted file</li>
</ul>

==Before-image logging==

Every updated database page is copied (logged) into the CHKPOINT data set before any change is performed. Whenever a request to update a page is received, <var class="product">Model 204</var> first checks to see if the page was logged since the last checkpoint. If the page has not been logged, the page is logged and the update allowed to proceed. If the page has already been logged, the update proceeds immediately.

You can disable logging of before-images on a file-by-file basis by using the file parameter <var>[[FRCVOPT parameter|FRCVOPT]]</var>. If logging is disabled, the file can be recovered only by using the media recovery procedures. (See [[System and media recovery#Media recovery NonStop/204|Media recovery NonStop/204]] for more information on media recovery.) 

===Creating the CHKPOINT/CHKPNT (and CHKPNTS) data set===

The checkpoint data set is named <code>CHKPOINT</code> in z/OS and z/VM; in z/VSE, use the name <code>CHKPNT</code>. If your site uses the sub-transaction capability as well, that checkpoint data set is named <code>CHKPNTS</code> for all operating systems. 
<blockquote class="note">
Notes:
<ul>
<li>Due to changes in Journal record layouts, CCAJRNL and CHKPOINT/CHKPNT data sets are not compatible with previous releases of <var class="product">Model 204</var>. For details, see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Journal block header information for SWITCH STREAM|Journal block header information for SWITCH STREAM]].</li>

<li>If your site has sub-transaction checkpoints enabled, you must create a CHKPNTS data set in addition to the original checkpoint data set. The following discussion applies equally to creating a CHKPNTS data set.</li>
</ul>
</blockquote>

To create a checkpoint data set: 
<ol>
<li>Include a CHKPOINT (or CHKPNT, and as needed, CHKPNTS) DD statement in the JCL.</li>

<li>Set <var>RCVOPT</var> to include the X'01' bit on User 0's parameter line.</li>
</ol>

A checkpoint data set is a sequential, unblocked data set with a record length equal to the <var class="product">Model 204</var> page size (6184 bytes). You can store it only on disk.

You may define the CHKPOINT and CHKPNTS data sets using parallel streams. The only restriction on CHKPOINT and CHKPNTS stream definitions is that they may not contain CMS data sets. There are no restrictions on the type of steam you can use to define the CCAJRNL and CCAJLOG journals. 

====Calculating disk space required====

You can determine amount of disk space required by the CHKPOINT data set in any given run by using the high water mark of records (page preimages) written to the CHKPOINT data set. You can obtain the high water mark via a User Language request. For example, you may want to include the following procedure as part of your CCAIN input stream just prior to <code>EOJ</code>:
BEGIN
PRINT 'HIGH WATER MARK FOR CHECKPOINT RECORDS' AND -
$CHKPINF(8)
END


Calculate the maximum amount of disk space in use in this run in the CHKPOINT data set by dividing the high water mark of records (page preimages) written to the CHKPOINT data set by the number of pages per track for your device type. To determine pages per track, see [[File size calculation in detail#Data set allocation|Data set allocation]]. 

You can also monitor the size of the CHKPOINT data set using any existing utility appropriate for your operating system. <var>[[MONITOR SIZE command|MONITOR SIZE]] CHKP</var> is a useful command for this purpose.

Generous sizing of the CHKPOINT data set is important, because <var class="product">Model 204</var> terminates whenever the CHKPOINT data set becomes full. For this reason, make the primary extent at least 50% greater than that calculated above. Further, define the data set with a substantial secondary extent, say 25% of the primary extent, and 15 extents of this size should be guaranteed available. For information about configuring the CHKPOINT data set, see [[Configuring checkpoint and journal data streams]].

===Maintaining single volume CHKPOINT data sets===

In Model 204 version 7.6 and earlier, multivolume CHKPOINT data sets are not supported for roll back recovery because BSAM does not support read-backward for those kinds of data sets. If a CHKPOINT data set is written to multiple volumes, then it is necessary to copy the data set onto a single volume before running <var>RESTART ROLL BACK</var> recovery.
In Model 204 version 7.7 and later, multivolume CHKPOINT data sets are supported for roll back recovery because roll back pass 1 and pass 2 both read the recovery data set forward. See [[System and media recovery#ROLL BACK facility|ROLL BACK facility]] for details.

Large CHKPOINT data sets are usually not required when CPMAX=1 is set in CCAIN. This is explained in [[#Limiting the size of CHKPOINT|Limiting the size of CHKPOINT]], below. GDGs (described in [[Configuring checkpoint and journal data streams]]) can be used for the CHKPOINT data set when long-running-update transactions are common.

If checkpoint timeouts (which can require large CHKPOINT data sets) are common, the use of [[#Overview of sub-transaction checkpoints|sub-transaction checkpoints]] is recommended. Sub-transaction checkpoints eliminate checkpoint timeouts and help to keep the size of the CHKPOINT data set to a minimum.


===Limiting the size of CHKPOINT===

<var class="product">Model 204</var> writes to the CHKPOINT data set until the specified maximum number of checkpoints saved (<var>CPMAX</var>) are taken and the next checkpoint is about to be taken. At that point, <var class="product">Model 204</var> rewinds the CHKPOINT data set and takes the next checkpoint. The data previously written to CHKPOINT is overwritten.

If you set <var>CPMAX</var> to one and set <var>CPTIME</var> to less than 15, the CHKPOINT data set will generally be small enough to fit on a single volume and, usually, occupy no more than about 20 cylinders. <var>CPMAX</var> set to one ensures that you keep only the most recent checkpoint and the preimages logged since that checkpoint. When the <var>CPMAX</var>-plus-one checkpoint is about to be taken, the CHKPOINT data set rewinds and the new checkpoint is taken again at the beginning of the data set. This keeps the data set small and ensures faster recovery.

To preserve all checkpoints and all preimages in the CHKPOINT data set, omit <var>CPMAX</var> on User 0's parameter line.

==Obtaining checkpoint information (UTILC)==

The UTILC utility is a standalone batch utility that provides information about the <var class="product">Model 204</var> checkpoint process by interpreting a checkpoint file and printing out checkpoint records in dump format. UTILC is a debugging aid for <var class="product">Model 204</var> users working with Technical Support staff on a specific problem. However, the information provided by UTILC can also be useful for performance analysis and capacity planning. 

Data in a checkpoint data set consists of the record types shown in the following table: 
<table>
<caption>Checkpoint record types</caption>
<tr class="head">
<th> Type code</th>
<th>Contents</th>
</tr>

<tr>
<td>1 (01)</td>
<td>File page preimage</td>
</tr>

<tr>
<td>2 (02)</td>
<td>Checkpoint</td>
</tr>

<tr>
<td>3 (03) </td>
<td>Copy of the roll forward file directory</td>
</tr>

<tr>
<td>4 (04)</td>
<td>Unused</td>
</tr>

<tr>
<td>5 (05)</td>
<td>File Parameter List (FPL) page preimage</td>
</tr>

<tr>
<td>6 (06)</td>
<td>Unused</td>
</tr>

<tr>
<td>7 (07)</td>
<td>Batch (IFAM2) job sign on</td>
</tr>

<tr>
<td>8 (08)</td>
<td>Batch (IFAM2) job sign off</td>
</tr>

<tr>
<td>9 (09)</td>
<td>Deferred update open</td>
</tr>

<tr>
<td>10 (0A)</td>
<td>Discontinuity</td>
</tr>

<tr>
<td>11 (0B)</td>
<td>RESET FISTAT (turn off physically broken bit)</td>
</tr>

<tr>
<td>12 (0C)</td>
<td>Dynamic allocation</td>
</tr>
</table>

===Checkpoint record formats===

In checkpoint records (type 2), the date and time of the checkpoint is stored in the first 8 bytes of the record, offset 0(0), in the format:
00yydddFhhmmssth


Where:
<ul>
<li><var class="term">yyddd</var> is the Julian date.</li>

<li><var class="term">hhmmssth</var> is the time. </li>
</ul>

For example, <code>88.335 15:04:27.88</code> is represented as <code>0088335F15042788</code>.

Each record ends with a 40-byte trailer that includes the 1-byte numeric type code at offset <code>6172 (181C)</code>, followed by the date and time of the posted checkpoint in the format:
yydddFxxxxxxxx


Where:
<ul>
<li><var class="term">yyddd</var> is the Julian date. </li>

<li><var class="term">xxxxxxxx</var> is the millisecond count of the day. </li>
</ul>

Trailer information identifies preimages, record types 1 and 5:
<ul>
<li>First 8 bytes of the trailer, offset <code>6144(1800)</code> from the start of the record, contains the name of the file in EBCDIC.</li>

<li>Last 4 bytes of each preimage record, offset <code>6180(1824)</code> from the start of the record, is a page identifier in the format:
TTPPPPPP


Where:
<ul>
<li><code>TT</code> is a 1-byte table identifier:
<table>
<tr class="head">
<th>Identifier code</th>
<th>Table</th>
</tr>

<tr>
<td align="right">x'00'</td>
<td>File Control Table (FCT)</td>
</tr>

<tr>
<td align="right">x'01'</td>
<td>Table A</td>
</tr>

<tr>
<td align="right">x'02'</td>
<td>Table B</td>
</tr>

<tr>
<td align="right">x'03'</td>
<td>Table C</td>
</tr>

<tr>
<td align="right">x'04'</td>
<td>Table D</td>
</tr>

<tr>
<td align="right">x'2p'</td>
<td>Table X
Where <code>p</code> is the high order nibble of the page number which may range from 0 to 1 inclusive.
</td>
</tr>

<tr>
<td align="right">x'4p'</td>
<td>Table E
Where <code>p</code> is the high order nibble of the page number which may range from 0 to 3 inclusive.
</td>
</tr>
</table>

</li>
<li><code>PPPPPP</code> is a 3-byte hexadecimal table-relative page number.</li>
</ul>
</li>
</ul>

===UTILC input data sets===

You can use only single data sets as input to the UTILC utility. You must process members of concatenated, parallel, or ring streams one at a time. 

===UTILC options===

The following options control the execution and output of UTILC: 
<ul>
<li>FROMDATE and TODATE specify the range of dates for which checkpoint records are printed. FROMDATE and TODATE must be 5-digit Julian dates (for example, 88062).</li>

<li>FROMTIME and TOTIME specify the time range for which checkpoint records are printed. FROMTIME and TOTIME must be in 24-hour clock (hhmmss) format (for example, 151003 = 3:10:03 PM).</li>

<li>RECTYPE specifies the type of records to be printed. For a list of record types, see the [[#Obtaining checkpoint information (UTILC)|"Checkpoint record types" table]]. The default is all record types.

Repeat RECTYPE as necessary. The following example prints all preimages and all File Parameter List page preimages.
RECTYPE=1,RECTYPE=5
</li>

<li>FILENAME specifies the ddname of the file, the name specified in the <var>CREATE</var> command, to be printed. Pages without file names are also printed unless excluded by record type; for example, <var>CHECKPOINT</var> records.</li>

<li>FROMPAGE and TOPAGE specify the range of <var class="product">Model 204</var> file pages printed. Page numbers must be hexadecimal. The following example prints all Table B pages for all files:
FROMPAGE=02000000,TOPAGE=02FFFFFF
</li>

<li>Use the FILENAME option to further restrict printing to selected pages from specific files.</li>

<li><code>TRAILERS=ONLY</code> specifies printing only page trailers.

If you do not specify the <code>TRAILERS=ONLY</code> parameter, entire checkpoint records are printed. 
</li>
</ul>

===UTILC examples===

The following examples provide the job control statements to run UTILC in z/OS, z/VSE, and z/VM environments. Each example shows how to request printing of checkpoint record trailers for the hour between 12:05:13 and 13:05:13 in different operating systems. 

====z/OS====
//UTILC EXEC PGM=UTILC,PARM='FROMTIME=120513,TOTIME=130513,
// TRAILERS=ONLY'
//STEPLIB DD DSN=M204.LOADLIB,DISP=SHR
//CCAPRINT DD SYSOUT=A
//SYSU DD SYSOUT=A
//CHKPOINT DD DSN=M204.CHKPOINT,DISP=OLD


====z/VSE====

The input stream, CHKPNT, for running UTILC is defined in the JCL by DLBL and EXTENT statements or a TLBL statement:
// JOB UTILC PRINT DISK CHECKPOINT FILE
// DLBL CHKPNT,'M204.CHKPOINT.FILE'
// EXTENT SYS001,SYSWK1,,,1390,1000
// EXEC UTILC,SIZE=AUTO,FROMTIME=120513,TOTIME=130513,
// TRAILERS=ONLY
/&


If the input file is on tape, assign the symbolic unit <code>SYS004</code> to the tape drive on which the tape is mounted. The output is printed on the symbolic unit <code>SYSLST</code>:
// JOB UTILC PRINT TAPE CHECKPOINT FILE
// TLBL CHKPNT,'M204.CHKPOINT'
// ASSGN SYS004,X'300'
// EXEC UTILC,SIZE=AUTO,FROMTIME=120513,TOTIME=130513,
// TRAILERS=ONLY
/&


====z/VM====

The following UTILC EXEC procedure runs UTILC. The command format is:
UTILC dsn mode (FROMTIME hhmmss TOTIME hhmmss
TRAILERS=ONLY


Where:
<ul>
<li><var class="term">dsn</var> is the data set name.

For z/OS format data sets, the DSN is specified with spaces instead of periods between the qualifiers.

For CMS data sets, the DSN is specified as filename filetype.
</li>

<li><var class="term">mode</var> specifies the access mode of the disk containing the file to be processed.</li>

<li>For tape files, the DSN and MODE parameters are replaced by the keyword <var>TAPE</var>.

Tape files also require issuing a FILEDEF, and a LABELDEF, if necessary, for the CHKPOINT data set before issuing the UTILC command. For example:
FILEDEF CHKPOINT TAP1 SL VOLID 12345 (RECFM FB LRECL 6184 BLKSIZE 6184
LABELDEF CHKPOINT standard labeldef parameters
UTILC D TAPE
(FROMTIME 120513 TOTIME 130513 TRAILERS=ONLY
</li>
</ul>
Note:
The length of optional parameters you can specify is limited by the z/VM console line length of 130 characters. 

[[Category:System management]]
[[Category:Recovery]]

MBSCAN parameter

2025-02-10T22:06:13Z

Goff: /* Description */

{{Template:MBSCAN parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>-1
<dt>Parameter type
<dd>User
<dt>Where set
<dd>By any user
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204 V9.0</var> or earlier
</dl>

==Description==
Whether <var class="product">Model 204</var> automatically performs a direct search and how many records are searched
For SQL requests and Host Language Interface calls, if MBSCAN is zero, the direct search feature is disabled. If MBSCAN is nonzero, direct searches are always performed.
For User Language, if MBSCAN is -1, all direct searches are performed automatically. If MBSCAN is zero, direct searches are never performed. When MBSCAN is greater than zero, <var class="product">Model 204</var> counts the records that would have to be searched after the inverted conditions have been evaluated. The count is compared to MBSCAN: 
<ul>
<li>
If the count is less than or equal to MBSCAN, the search is performed automatically. </li>
<li>
If the count is greater than MBSCAN, you are told how many records must be searched, and you can choose either to perform the search or to cancel the request. In batch jobs, in application subsystems, or if the value of the <var>[[PROMPT_parameter|PROMPT]]</var> parameter includes the hexadecimal 10 option, this interaction with you does not happen and the request is canceled.</li>
</ul>
MSCAN is typically set for performance reasons. Do not reset it, especially to significantly larger values, without first consulting your DBAs as this may negatively impact overall performance.
[[Category:User parameters]]
[[Category:Parameters]]

COMPOPT parameter

2024-11-24T20:50:18Z

Goff: /* Description */

{{Template:COMPOPT parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>X'00'
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 CCAIN parameters
<dt>Related products
<dd>All
<dt>Introduced
<dd>Before Sirius Mods 6.7
</dl>

==Description==
The system parameter <var>COMPOPT</var> facilitates migration to [[Mixed-case SOUL|mixed-case SOUL]]. <var>COMPOPT</var> is a <var class="product">Model 204</var> bitmask parameter that must be set in the CCAIN (User 0 input) stream. The bits in <var>COMPOPT</var> have the following meanings:
<table class="thJustBold">
<tr><th>X'01'</th>
<td>If on, all procedures start out in <var>[[Sirius Case statement#sirCaseStmt|Sirius Case ToUpper]]</var> mode, whether or not they begin with a mixed-case <var>Begin</var> statement. <var>Sirius Case ToUpper</var> mode translates all unquoted tokens to uppercase, so <var class="product">SOUL</var> statements, keywords, variable names, etc. may be written in mixed case. By setting the <var>COMPOPT</var> X'01' bit, a site is essentially enabling mixed-case SOUL almost everywhere. </td></tr>

<tr><th>X'02'</th>
<td>If on, <var>Sirius Case Leave</var> compiler directives are to be ignored: if <var>Sirius Case ToUpper</var> is in effect, it remains in effect even if a <var>Sirius Case Leave</var> directive is encountered. Setting the <var>COMPOPT</var> X'02' bit along with the X'01' bit enables mixed-case SOUL everywhere, thus ensuring consistent language processing throughout an Online. </td></tr>

<tr><th>X'04'</th>
<td>If on, image or image-item names, either literal or in variables, are to be automatically converted to uppercase before being used in methods or $functions. Since mixed-case SOUL is accomplished by translating unquoted tokens to uppercase, this case conversion for image or image-item names is the runtime equivalent of the compiler mixed-case support.

Setting the <var>COMPOPT</var> X'04' bit enables image and image-item names that appear as literals in SOUL programs to be entered in mixed case. The only time this might be a problem is if there are true mixed-case image or image-item names in an application. A true mixed-case image or image-item name is one written in mixed case, either inside quotation marks (image and image-item names can indeed be put in quotes) or without <var>Sirius Case ToUpper</var> in effect. In general, neither of these is too likely, so true mixed-case image or image-item names are not likely in most applications. </td></tr>

<tr><th>X'08'</th>
<td>Only applicable in Model 204 8.0 to enable transparency mode.
Setting the <var>COMPOPT</var> X'08' bit applies an implicit NAMESAVE to every global image. So, if a large global image did not have NAMESAVE specified, but COMPOPT X’08’ is set, that image's FSCB requirements will go up at runtime. Otherwise, there should be no change to FSCB requirements. The amount of extra space required is 7 bytes for each image item plus the sum of the length of the names of the image items.
If the image is not global, any increase might also increase runtime FSCB usage, and if it’s global it will increase runtime GTBL usage.</td></tr>
</table>

==See also==
<ul>
<li><var>[[SIRCOMP parameter|SIRCOMP]]</var>
</ul>
[[Category:System parameters]]
[[Category:Parameters]]

REGENERATE command

2024-11-20T20:06:18Z

Goff: Add USING ddname

==Summary==
<dl>
<dt>Privileges
<dd>User 0
<dt>Function
<dd>In the event of a media failure, for example, a disk head crash, a REGENERATE command recovers a <var class="product">Model 204</var> file by reapplying some or all of the updates that have been made to the file since the time of the last dump.
</dl>
==Syntax==
REGENERATE [USING ddname] FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th]
| LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th
| CHECKPOINT yy.ddd hh:mm:ss.th}]

For more than one file, specify REGENERATE only once; the remaining syntax is repeated for each file.

Where:
<ul>
<li>
<var class="term">ddname</var> allows an alternate ddname to be used for the input journal to be used by REGENERATE. It is one to eight characters long and defaults to CCAGEN if not specified
</li>

<li>
<var class="term">filename</var> is the name of a <var class="product">Model 204</var> file that is one to eight characters long.
</li>

<li>
A FROM clause determines whether or not REGENERATE processing performs a restore: 
<ul>
<li>
If a FROM clause is present for a file, REGENERATE processing restores that file from the <var class="product">Model 204</var> dump specified in the clause.
</li>

<li>
If a FROM clause is not present for a file, REGENERATE processing assumes that the file was previously restored. 
</li>
</ul>
</li>

<li>
<var class="term">dumpname</var> is the ddname of the dumped file, one to eight characters long, from which to recover.
</li>

<li>
<var>IGNORE</var> lets REGENERATE processing bypass the file parameter list (FPL) update timestamps, so you can run REGEN processing with one CCAGEN at a time, instead of requiring you to concatenate the CCAGEN files.
</li>

<li>
The TO clause options listed in the table below identify the stopping point:
<table>

<tr class="head"> <th>
Option
</th> <th>
Applies updates to the file up to...
</th> </tr>

<tr> <th><var>LAST UPDATE</var></th> <td>All. This is the default. </td> </tr>

<tr> <th><var>LAST CHECKPOINT</var></th>
<td>Last checkpoint on the input journal.
</td> </tr>

<tr> <th nowrap><var>UPDATE number OF id</var></th> <td>And including the update specified by number and id. The ID is the date/time stamp from the END OF UPDATE message, specified in the form: yy.ddd hh:mm:ss.th.</td> </tr>

<tr> <th><var>CHECKPOINT id</var></th>
<td>Specified checkpoint. The ID is specified in the form: yy.ddd hh:mm:ss.th. </td> </tr>
</table>
</li>

<li>
A BEFORE clause specifies a nonspecific stopping point. The BEFORE clause is an alternative to specifying an exact checkpoint ID or update unit number and ending date and time from an audit trail.
If you specify a BEFORE clause, Pass One of REGENERATE processing determines the last complete update or checkpoint before the time specified. Pass Two of REGENERATE processing stops reapplying file updates when it reaches the stopping point identified in Pass One. 
</li>
</ul>
===Syntax notes===
When multiple files are regenerated, each file must be specified on a separate line. The line can begin in any column. The END keyword indicates the end of the list of files.

==Examples==
REGENERATE FILE DB1 FROM DUMPDB1
REGEN FILE DB1 FROM DUMPDB1 TO LAST UPDATE
REGEN FILE DBAUDIT FROM DUMP01 TO LAST -
CHECKPOINT
REGEN FILE DB1 FROM DUMPDB2 TO UPDATE 3 -
OF 88.216 06:28:42.98
REGEN FILE MODFILE FROM DUMPMOD TO -
CHECKPOINT 88.216 01:05:22.99
REGEN
FILE DB1 FROM DUMPDB1 TO LAST CHECKPOINT
FILE DB2 FROM DUMPDB2
FILE DB3 FROM DUMPDB3 TO UPDATE 5 OF -
88.008 05:19:41.27
END

Note: Blank lines are not valid between the REGENERATE and END command.
REGEN FILE ABC FROM DUMPABC /* First run */
.
.
REGEN FILE ABC IGNORE /* A later run */


==Usage notes==
The REGENERATE command lets the system manager use the <var class="product">Model 204</var> media recovery feature to regenerate one or more files. A REGENERATE command is issued in case of a loss of storage integrity caused by a hard system error such as a disk head crash.
The algorithm for identifying starting points, used whether or not a FROM clause is present, is to find the first start of an update unit with a time greater than the last updated time of the file being processed. 
If REGENERATE processing opens a file for which it is not performing a restore, and if that file is marked physically inconsistent, REGENERATE processing for that file is discontinued.
When it processes REGENERATE, <var class="product">Model 204</var> ends any update unit in progress and begins a no-back out-allowed update unit. For more information about <var class="product">Model 204</var> update units, see [[File_integrity_and_recovery#Update_units_and_transactions|Update units and transactions]].
For a single-user (batch) <var class="product">Model 204</var> run, specify a REGENERATE command on User 0's command line. REGENERATE need not be the first command issued. You can intermix User Language procedures and other batch functions with REGENERATE commands.
====Using the IGNORE option====
For example, providing the first journal the first REGEN command might be
REGEN FILE ABC FROM DUMPABC

A second run may provide the second journal and specify: 
REGEN FILE ABC IGNORE

The second run begins where the previous REGEN processing ended and applies the second journal updates.
Note: If you omit a journal, <var class="product">Model 204</var> does not report this to you. Therefore, use the IGNORE option with care.
====Using the TO UPDATE option====
You can specify the TO UPDATE option for a single or multiple file run.
If TO UPDATE <var class="term">nn</var> OF <var class="term">id</var> is specified, it must appear only on the first FILE statement, and no other ‘TO’ options are allowed on subsequent files.
(In Model 204 version 7.6, the new message: <code>M204:1664 "TO UPDATE" only allowed on first line of REGENerate</code> appears any time more than one TO UPDATE is specified, or if TO UPDATE is specified on a line other than the first.)
All additional files are recovered as though they each specified the same 'TO UPDATE' option. The <var class="term">id</var>' timestamp is the END OF TRANSACTION timestamp. Once the 'end of transaction' is reached, further processing stops, all inflight transactions are backed out, and RC=0 is set.

If the update is not found in the journal, then the run stops immediately after pass 1. RC=4 is set. This message is displayed for each file: 
M204.1409: MISSING STOPPING POINT FOR FILE <var class="term">filename</var>
And this message is also displayed:
M204.1435: Error during regenerate

====Using REGENERATE with multiple files====
The number of files you can regenerate in a single run depends upon the settings of these parameters: [[NDIR parameter|NDIR]] (number of directory entries) and [[NFILES parameter|NFILES]] (number of file areas).

[[Category:Commands]]

COMPOPT parameter

2024-10-20T21:20:39Z

Goff: Update to reflect 00982784 fix

{{Template:COMPOPT parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>X'00'
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 CCAIN parameters
<dt>Related products
<dd>All
<dt>Introduced
<dd>Before Sirius Mods 6.7
</dl>

==Description==
The system parameter <var>COMPOPT</var> facilitates migration to [[Mixed-case SOUL|mixed-case SOUL]]. <var>COMPOPT</var> is a <var class="product">Model 204</var> bitmask parameter that must be set in the CCAIN (User 0 input) stream. The bits in <var>COMPOPT</var> have the following meanings:
<table class="thJustBold">
<tr><th>X'01'</th>
<td>If on, all procedures start out in <var>[[Sirius Case statement#sirCaseStmt|Sirius Case ToUpper]]</var> mode, whether or not they begin with a mixed-case <var>Begin</var> statement. <var>Sirius Case ToUpper</var> mode translates all unquoted tokens to uppercase, so <var class="product">SOUL</var> statements, keywords, variable names, etc. may be written in mixed case. By setting the <var>COMPOPT</var> X'01' bit, a site is essentially enabling mixed-case SOUL almost everywhere. </td></tr>

<tr><th>X'02'</th>
<td>If on, <var>Sirius Case Leave</var> compiler directives are to be ignored: if <var>Sirius Case ToUpper</var> is in effect, it remains in effect even if a <var>Sirius Case Leave</var> directive is encountered. Setting the <var>COMPOPT</var> X'02' bit along with the X'01' bit enables mixed-case SOUL everywhere, thus ensuring consistent language processing throughout an Online. </td></tr>

<tr><th>X'04'</th>
<td>If on, image or image-item names, either literal or in variables, are to be automatically converted to uppercase before being used in methods or $functions. Since mixed-case SOUL is accomplished by translating unquoted tokens to uppercase, this case conversion for image or image-item names is the runtime equivalent of the compiler mixed-case support.

Setting the <var>COMPOPT</var> X'04' bit enables image and image-item names that appear as literals in SOUL programs to be entered in mixed case. The only time this might be a problem is if there are true mixed-case image or image-item names in an application. A true mixed-case image or image-item name is one written in mixed case, either inside quotation marks (image and image-item names can indeed be put in quotes) or without <var>Sirius Case ToUpper</var> in effect. In general, neither of these is too likely, so true mixed-case image or image-item names are not likely in most applications. </td></tr>

<tr><th>X'08'</th>
<td>Only applicable in for Model 204 8.0 to enable transparency mode.
Setting the <var>COMPOPT</var> X'08' bit applies an implicit NAMESAVE to every global image. So, if a large global image did not have NAMESAVE specified, but COMPOPT X’08’ is set, that image's FSCB requirements will go up at runtime. Otherwise, there should be no change to FSCB requirements. The amount of extra space required is 7 bytes for each image item plus the sum of the length of the names of the image items.
If the image is not global, any increase might also increase runtime FSCB usage, and if it’s global it will increase runtime GTBL usage.</td></tr>
</table>

==See also==
<ul>
<li><var>[[SIRCOMP parameter|SIRCOMP]]</var>
</ul>
[[Category:System parameters]]
[[Category:Parameters]]

COMPOPT parameter

2024-10-18T04:41:55Z

Goff: NAMESAVE increases to FSCB

{{Template:COMPOPT parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>X'00'
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 CCAIN parameters
<dt>Related products
<dd>All
<dt>Introduced
<dd>Before Sirius Mods 6.7
</dl>

==Description==
The system parameter <var>COMPOPT</var> facilitates migration to [[Mixed-case SOUL|mixed-case SOUL]]. <var>COMPOPT</var> is a <var class="product">Model 204</var> bitmask parameter that must be set in the CCAIN (User 0 input) stream. The bits in <var>COMPOPT</var> have the following meanings:
<table class="thJustBold">
<tr><th>X'01'</th>
<td>If on, all procedures start out in <var>[[Sirius Case statement#sirCaseStmt|Sirius Case ToUpper]]</var> mode, whether or not they begin with a mixed-case <var>Begin</var> statement. <var>Sirius Case ToUpper</var> mode translates all unquoted tokens to uppercase, so <var class="product">SOUL</var> statements, keywords, variable names, etc. may be written in mixed case. By setting the <var>COMPOPT</var> X'01' bit, a site is essentially enabling mixed-case SOUL almost everywhere. </td></tr>

<tr><th>X'02'</th>
<td>If on, <var>Sirius Case Leave</var> compiler directives are to be ignored: if <var>Sirius Case ToUpper</var> is in effect, it remains in effect even if a <var>Sirius Case Leave</var> directive is encountered. Setting the <var>COMPOPT</var> X'02' bit along with the X'01' bit enables mixed-case SOUL everywhere, thus ensuring consistent language processing throughout an Online. </td></tr>

<tr><th>X'04'</th>
<td>If on, image or image-item names, either literal or in variables, are to be automatically converted to uppercase before being used in methods or $functions. Since mixed-case SOUL is accomplished by translating unquoted tokens to uppercase, this case conversion for image or image-item names is the runtime equivalent of the compiler mixed-case support.

Setting the <var>COMPOPT</var> X'04' bit enables image and image-item names that appear as literals in SOUL programs to be entered in mixed case. The only time this might be a problem is if there are true mixed-case image or image-item names in an application. A true mixed-case image or image-item name is one written in mixed case, either inside quotation marks (image and image-item names can indeed be put in quotes) or without <var>Sirius Case ToUpper</var> in effect. In general, neither of these is too likely, so true mixed-case image or image-item names are not likely in most applications. </td></tr>

<tr><th>X'08'</th>
<td>Only applicable in for Model 204 8.0 to enable transparency mode.
Setting the <var>COMPOPT</var> X'08' bit applies an implicit NAMESAVE to every image. So, if a large image did not have NAMESAVE specified, but COMPOPT X’08’ is set, that images FSCB requirements will go up at runtime. Otherwise, there should be no change to FSCB requirements. The amount of extra space required is 7 bytes for each image item plus the sum of the length of the names of the image items.
If the image is not global, any increase might also increase runtime FSCB usage, and if it’s global it will increase runtime GTBL usage.</td></tr>
</table>

==See also==
<ul>
<li><var>[[SIRCOMP parameter|SIRCOMP]]</var>
</ul>
[[Category:System parameters]]
[[Category:Parameters]]

COMPOPT parameter

2024-10-18T03:29:18Z

Goff: Add COMPOPT X'08'

{{Template:COMPOPT parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>X'00'
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 CCAIN parameters
<dt>Related products
<dd>All
<dt>Introduced
<dd>Before Sirius Mods 6.7
</dl>

==Description==
The system parameter <var>COMPOPT</var> facilitates migration to [[Mixed-case SOUL|mixed-case SOUL]]. <var>COMPOPT</var> is a <var class="product">Model 204</var> bitmask parameter that must be set in the CCAIN (User 0 input) stream. The bits in <var>COMPOPT</var> have the following meanings:
<table class="thJustBold">
<tr><th>X'01'</th>
<td>If on, all procedures start out in <var>[[Sirius Case statement#sirCaseStmt|Sirius Case ToUpper]]</var> mode, whether or not they begin with a mixed-case <var>Begin</var> statement. <var>Sirius Case ToUpper</var> mode translates all unquoted tokens to uppercase, so <var class="product">SOUL</var> statements, keywords, variable names, etc. may be written in mixed case. By setting the <var>COMPOPT</var> X'01' bit, a site is essentially enabling mixed-case SOUL almost everywhere. </td></tr>

<tr><th>X'02'</th>
<td>If on, <var>Sirius Case Leave</var> compiler directives are to be ignored: if <var>Sirius Case ToUpper</var> is in effect, it remains in effect even if a <var>Sirius Case Leave</var> directive is encountered. Setting the <var>COMPOPT</var> X'02' bit along with the X'01' bit enables mixed-case SOUL everywhere, thus ensuring consistent language processing throughout an Online. </td></tr>

<tr><th>X'04'</th>
<td>If on, image or image-item names, either literal or in variables, are to be automatically converted to uppercase before being used in methods or $functions. Since mixed-case SOUL is accomplished by translating unquoted tokens to uppercase, this case conversion for image or image-item names is the runtime equivalent of the compiler mixed-case support.

Setting the <var>COMPOPT</var> X'04' bit enables image and image-item names that appear as literals in SOUL programs to be entered in mixed case. The only time this might be a problem is if there are true mixed-case image or image-item names in an application. A true mixed-case image or image-item name is one written in mixed case, either inside quotation marks (image and image-item names can indeed be put in quotes) or without <var>Sirius Case ToUpper</var> in effect. In general, neither of these is too likely, so true mixed-case image or image-item names are not likely in most applications. </td></tr>

<tr><th>X'08'</th>
<td>Only applicable in for Model 204 8.0 to enable transparency mode.

Setting the <var>COMPOPT</var> X'08' bit applies an implicit NAMESAVE to every image. So, if a large image did not have NAMESAVE specified, but COMPOPT X’08’ is set, that images FSCB requirements will go up at runtime. Otherwise, there should be no change to FSCB requirements. </td></tr>
</table>

==See also==
<ul>
<li><var>[[SIRCOMP parameter|SIRCOMP]]</var>
</ul>
[[Category:System parameters]]
[[Category:Parameters]]

SWITCH STREAM command

2024-10-13T22:05:41Z

Goff: Update to reflect PDS8571

==Summary==
<dl>
<dt>Privileges
<dd>System manager
<dt>Function
<dd>You can switch streams — parallel, ring, concatenated, GDG — to the next member at any time.
</dl>

==Syntax==
SWITCH STREAM streamname [RESET]


Where:

<table>
<tr><th>streamname</th>
<td><var>CCAJRNL</var>, <var>CCAJLOG</var>, <var>CHKPOINT</var>, or <var>CHKPNTS</var>. The command is valid only for these streams.</td></tr>

<tr><th><var>RESET</var></th>
<td>This optional parameter causes any disabled parallel GDG members to be reopened during the switch.

Valid only when <var>CCAJLOG</var> or <var>CCAJRNL</var> are defined as a parallel stream defined with GDG members, as in the following example, which specifies two complete copies of CCAJLOG using GDGs as a base:
DEFINE STREAM CCAJLOG … PARALLEL=(P1,P2) …
DEFINE STREAM P1 … GDG=(D1) …
DEFINE STREAM P2 … GDG=(D2) …
DEFINE DATASET D1….
DEFINE DATASET D2… 
Note: <var>RESET</var> of <var>CCAJNRL</var> is only possible as version 8.0 of Model 204. A custom zap may be available for earlier versions.
</td></tr>
</table>

==Usage notes==
<ul>
<li>If you specify:
<ul>
<li>A journal stream (<var>CCAJRNL</var> or <var>CCAJLOG</var>): the currently active data set is closed and the next data set defined to the stream is opened. </li>

<li>A checkpoint stream (<var>CHKPOINT</var> or <var>CHKPNTS</var>): the currently active data set in the stream is closed after the next record is written to the data set.</li>
</ul></li>

<li>If a <code>SWITCH STREAM CCAJRNL</code> command is issued during <code>CHECKPOINT EXTENDED QUIESCE</code> command processing, the journal is switched, a new checkpoint is issued, and the duration of the extended quiesce time-out set in <var>[[CPQZSECS parameter|CPQZSECS]]</var> is reset to its maximum, original value (disregarding the already-elapsed time).</li>

<li>A <code>SWITCH STREAM CCAJRNL RESET</code> command is only allowed during <code>CHECKPOINT EXTENDED QUIESCE</code> command processing. Ie</li>
CHECKPOINT SET E Q
CHECKPOINT
SWITCH STREAM CCAJRNL RESET
CHECKPOINT UNSET E Q


<li>For an extensive discussion about using the <var>SWITCH STREAM</var> command, see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#SWITCH STREAM command|Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)]]. </li> </ul>

==See also==
<ul>
<li>[[DEFINE STREAM command]] </li>
<li>[[COPY STREAM command]] </li>
<li>[[Configuring checkpoint and journal data streams]] </li>
</ul>

[[Category: System manager commands]]
[[Category: Commands]]

SWITCH STREAM command

2024-10-13T21:59:37Z

Goff: Update to reflect PDS8571

==Summary==
<dl>
<dt>Privileges
<dd>System manager
<dt>Function
<dd>You can switch streams — parallel, ring, concatenated, GDG — to the next member at any time.
</dl>

==Syntax==
SWITCH STREAM streamname [RESET]


Where:

<table>
<tr><th>streamname</th>
<td><var>CCAJRNL</var>, <var>CCAJLOG</var>, <var>CHKPOINT</var>, or <var>CHKPNTS</var>. The command is valid only for these streams.</td></tr>

<tr><th><var>RESET</var></th>
<td>This optional parameter causes any disabled parallel GDG members to be reopened during the switch.

Valid only for a <var>CCAJLOG</var> parallel stream defined with GDG members, as in the following example, which specifies two complete copies of CCAJLOG using GDGs as a base:
DEFINE STREAM CCAJLOG … PARALLEL=(P1,P2) …
DEFINE STREAM P1 … GDG=(D1) …
DEFINE STREAM P2 … GDG=(D2) …
DEFINE DATASET D1….
DEFINE DATASET D2… 
</td></tr>
</table>

==Usage notes==
<ul>
<li>If you specify:
<ul>
<li>A journal stream (<var>CCAJRNL</var> or <var>CCAJLOG</var>): the currently active data set is closed and the next data set defined to the stream is opened. </li>

<li>A checkpoint stream (<var>CHKPOINT</var> or <var>CHKPNTS</var>): the currently active data set in the stream is closed after the next record is written to the data set.</li>
</ul></li>

<li>If a <code>SWITCH STREAM CCAJRNL</code> command is issued during <code>CHECKPOINT EXTENDED QUIESCE</code> command processing, the journal is switched, a new checkpoint is issued, and the duration of the extended quiesce time-out set in <var>[[CPQZSECS parameter|CPQZSECS]]</var> is reset to its maximum, original value (disregarding the already-elapsed time).</li>

<li>A <code>SWITCH STREAM CCAJRNL RESET</code> command is only allowed during <code>CHECKPOINT EXTENDED QUIESCE</code> command processing. Ie</li>
CHECKPOINT SET E Q
CHECKPOINT
SWITCH STREAM CCAJRNL RESET
CHECKPOINT UNSET E Q


<li>For an extensive discussion about using the <var>SWITCH STREAM</var> command, see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#SWITCH STREAM command|Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)]]. </li> </ul>

==See also==
<ul>
<li>[[DEFINE STREAM command]] </li>
<li>[[COPY STREAM command]] </li>
<li>[[Configuring checkpoint and journal data streams]] </li>
</ul>

[[Category: System manager commands]]
[[Category: Commands]]

Using system statistics

2024-10-09T23:00:26Z

Goff: Fix JSCREENS and add JWEBERRS

==Overview==

The tables on this page are provided for your use in identifying and tracking statistics that are reported by <var class="product">Model 204</var> in various situations. The offsets, given in decimal and hexadecimal, are to help you locate particular statistics within statistical output. The length is in bytes.

The statistics are collected in the [[Tracking_system_activity_(CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAJRNL|CCAJRNL]] data set, or if allocated, in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAAUDIT and CCAJLOG|CCAJLOG]]. The offsets in the tables below locate each statistic in the corresponding record. To accommodate sites that need to run <var class="product">Model 204</var> around the clock for many days at a time, space for most <var class="product">Model 204</var> statistics is a double word.

==Description of statistics==

The "Statistics with descriptions" table lists the statistics that are collected and that you can evaluate. It also describes the purpose of each statistic followed by the circumstances when you can collect the information and an offset in the journal record. 

To collect several statistics you must preset a parameter to a nonzero value. Statistics that require a parameter are also noted in the "Statistics with descriptions" table. The table in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Setting parameters to collect certain statistics]] lists those statistics with the required parameter. 

Tables, identified by type, later in this topic, describe the layouts of the various journal records.
<table>
<caption style="margin-right:4em">Statistics with descriptions</caption>
<tr class="head">
<th>Statistic </th>
<th>Records...</th>
</tr>

<tr>
<td>APSYLD</td>
<td>Number of APSY loads</td>
</tr>

<tr>
<td>APSYLDD</td>
<td>Number of APSY loads from a dataspace</td>
</tr>

<tr>
<td>APSYLDT</td>
<td>Number of tiny APSY loads</td>
</tr>

<tr>
<td>AUDIT</td>
<td>Number of lines written to the journal and/or the audit trail</td>
</tr>

<tr>
<td>BACKOUTS</td>
<td>Number of BACKOUTs</td>
</tr>

<tr>
<td>BADD</td>
<td>Number of fields added to Table B</td>
</tr>

<tr>
<td>BCHG</td>
<td>Number of fields changed in Table B</td>
</tr>

<tr>
<td>BDEL</td>
<td>Number of fields deleted from Table B</td>
</tr>

<tr>
<td>BLKCFRE</td>
<td>Number of times user held a critical file resource (CFR) exclusively and forced another user to wait

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKI</td>
<td>Percentage of performance samples at which the user was in a server but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKO</td>
<td>Percentage of performance samples at which the user was swapped out to the server data set but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKRLK</td>
<td>Number of times user was the first user identified as blocking another from obtaining a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BXCHNG</td>
<td>Number of value entries changed in the ordered index. This occurs when a record number is added to or removed from an existing value entry.</td>
</tr>

<tr>
<td>BXDELE</td>
<td>Number of value entries deleted from the ordered index</td>
</tr>

<tr>
<td>BXFIND</td>
<td>Number of ordered index searches to locate field name=value pairs in the ordered index</td>
</tr>

<tr>
<td>BXFREE</td>
<td>Number of ordered index pages (nodes) emptied and released from the ordered index</td>
</tr>

<tr>
<td>BXINSE</td>
<td>Number of new value entries inserted into the ordered index</td>
</tr>

<tr>
<td>BXNEXT</td>
<td>Number of value entries touched in the ordered index during a range retrieval</td>
</tr>

<tr>
<td>BXRFND</td>
<td>Number of times the cursor was repositioned in the ordered index during a search</td>
</tr>

<tr>
<td>BXSPLI</td>
<td>Number of Table D pages (nodes) split in the ordered index</td>
</tr>

<tr>
<td>CCATDIFF</td>
<td>Difference between CCATEMP pages allocated and freed by a thread. This is an imperfect indicator of the number of CCATEMP pages a thread has allocated. CCATDIFF is imperfect because it is difficult to fully account for pages allocated or freed on behalf of the system or other users. However, if there is an acute CCATEMP page shortage, threads with high CCATDIFF values are likely culprits.

CCATDIFF is available in Model 204 7.7 and higher.</td>
</tr>

<tr>
<td>CCATDIFH</td>
<td>High water mark of CCATDIFF in a request. This can be useful if a request allocated a lot of CCATEMP pages, causing an acute shortage but then freed those pages.

CCATDIFH is available in Model 204 7.7 and later.</td>
</tr>

<tr>
<td>CDLWAIT</td>
<td>Number of constraint dependency lock waits</td>
</tr>

<tr>
<td>CNCT</td>
<td>Elapsed time in seconds</td>
</tr>

<tr>
<td>COMMITS</td>
<td>Number of <var>COMMIT</var>s</td>
</tr>

<tr>
<td>CPU</td>
<td>Total CPU time consumed in milliseconds. The system CPU statistics include both maintask and subtask CPU usage.</td>
</tr>

<tr>
<td>CPUONZIP</td>
<td>Total CPU time consumed in milliseconds on zIIP engines</td>
</tr>

<tr>
<td>CPUTOTZE</td>
<td>Total CPU time consumed in milliseconds by workloads eligible for offload to zIIP engines</td>
</tr>

<tr>
<td>DEQ</td>
<td>Total number of units of work taken by the MAINTASK and each MP and zIIP subtask, regardless of the queue that the work was taken from. Reported at <var class="product">Model 204</var> termination or in <var>[[MONITOR TASKS command|MONITOR TASKS]]</var> output.

(type Subtask)
</td>
</tr>

<tr>
<td>DEV#</td>
<td>used the MXI interface to hold the IODEV type ( e.g. 7 for IODEV7 )</td>
</tr>

<tr>
<td>DEV5</td>
<td>Output lines to procedures defined during the run</td>
</tr>

<tr>
<td>DEV6</td>
<td>Input lines from included procedures</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly VTAM) 3270s</td>
</tr>

<tr>
<td>DEV8</td>
<td>Input lines from SNA Communications Server 3270s</td>
</tr>

<tr>
<td>DEV9</td>
<td>Page headers or trailers defined in requests</td>
</tr>

<tr>
<td>DEV10</td>
<td>Output lines written to directed output (USE) data sets</td>
</tr>

<tr>
<td>DEV11</td>
<td>Output lines to remote User Language full screen</td>
</tr>

<tr>
<td>DEV12</td>
<td>Input lines from a remote User Language full screen</td>
</tr>

<tr>
<td>DEV13</td>
<td>Output lines to remote SQL</td>
</tr>

<tr>
<td>DEV14</td>
<td>Input lines from remote SQL</td>
</tr>

<tr>
<td>DEV17</td>
<td>Output lines to SQL CRAM IUCU</td>
</tr>

<tr>
<td>DEV18</td>
<td>Input lines from SQL CRAM</td>
</tr>

<tr>
<td>DEV19</td>
<td>Output lines to remote SQL LU62</td>
</tr>

<tr>
<td>DEV20</td>
<td>Input lines from remote SQL LU62</td>
</tr>

<tr>
<td>DEV23</td>
<td>Input lines to CRAM IFAM</td>
</tr>

<tr>
<td>DEV24</td>
<td>Input lines from CRAM IUCU thread</td>
</tr>

<tr>
<td>DEV27</td>
<td>Terminal error messages issued for inbound Distributed Application Facility conversations</td>
</tr>

<tr>
<td>DEV28</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV31</td>
<td><var>IFDISP</var> output lines to IFAM1 programs</td>
</tr>

<tr>
<td>DEV32</td>
<td>Input arguments supplied by certain IFAM1 calls</td>
</tr>

<tr>
<td>DEV37</td>
<td>Output lines to SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV38</td>
<td>Input lines from SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV49</td>
<td>output lines to Remote Command line applications( rate or total)</td>
</tr>

<tr>
<td>DEV50</td>
<td>Lines sent to the printer when ROUTER=CICS</td>
</tr>

<tr>
<td>DEV53</td>
<td>Output lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV54</td>
<td>Input lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV55</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV56</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV57</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV58</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV59</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV60</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV61</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV62</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV63</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM parameter|MONPARM]] system parameter.</td>
</tr>

<tr>
<td>DEV64</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV65</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV66</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV67</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV68</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV69</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly
VTAM) 3270s</td>
</tr>

<tr>
<td>DEV70</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV71</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV72</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV73</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV74</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DIRRCD</td>
<td>Number of records searched in direct searches of Table B</td>
</tr>

<tr>
<td>DKAR</td>
<td>Number of buffers allocated without page read requests</td>
</tr>

<tr>
<td>DKPR</td>
<td>Number of requests for a page (may not require real I/O)</td>
</tr>

<tr>
<td>DKPRF</td>
<td>Number of fast logical page reads. Number of DKPRs that were satisfied by pending or deferred close buffers</td>
</tr>

<tr>
<td>DKRD</td>
<td>Number of physical page reads from Model 204 files</td>
</tr>

<tr>
<td>DKRDL</td>
<td>Number of physical page reads into the below the bar buffer pool</td>
</tr>

<tr>
<td>DKRR</td>
<td> Number of real disk reads for recently requested pages
</td>
</tr>

<tr>
<td>DKSAWB</td>
<td> Anticipatory writes from the bottom of the LRU queue. The page in the buffer is then deleted and no longer available without a re-read. Usually a small statistic and typically only incremented by a few rare events.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWBL</td>
<td> Same as DKSAWB but only incremented for anticipatory writes from below the bar

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWW</td>
<td> Anticipatory writes from the anticipatory write windows set by LDKBMWND and/or LDKBMWNG

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWWL</td>
<td>Same as DKSAWW but only incremented for anticipatory writes from below the bar</td>
</tr>

<tr>
<td>DKSDIR</td>
<td> High-water mark of modified (dirty) buffers found within the DKBM statistics window which is created by the <var>LDKBMW</var> parameter. This parameter is not recommended due to the extremely heavy performance penalty imposed by a non-zero value.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSDIRT</td>
<td> The total of all modified buffers found within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSFBS</td>
<td> Times a buffer was needed, and a scan was necessary, because the oldest free buffer was not immediately available

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIP</td>
<td> The highest number of buffers skipped during any search for a free buffer. A buffer is skipped because it is not immediately available.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIPT</td>
<td> The total of all buffers skipped when looking for a free buffer

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRR</td>
<td> Number of times a page that was expected to be in the buffer pool could not be located, which necessitates a physical I/O to disk

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRRFND</td>
<td>Number of times that a page that was expected to be in the buffer pool was located there, which eliminates the need for a physical I/O</td>
</tr>

<tr>
<td>DKSTBLA</td>
<td> Table A reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLB</td>
<td> Table B reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLC</td>
<td> Table C reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLD</td>
<td> Table D reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DSKTBLE</td>
<td> Table E reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLF</td>
<td> FCT reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTKQC</td>
<td> Times the current Table B page had to be closed to allow a fourth buffer to be opened

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSWRP</td>
<td> The highwater mark of buffers with writes outstanding within the DKBM statistics window, created by the parameter LDKBMW. Rocket Software advises against setting this parameter to a non-zero value due to the extreme performance penalty imposed.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSWRPT</td>
<td> The total number of buffers with outstanding writes within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKUPTIME</td>
<td>Milliseconds of DKUPDT time</td>
</tr>

<tr>
<td>DKWR</td>
<td>Number of physical page writes to <var class="product">Model 204</var> files</td>
</tr>

<tr>
<td>DKWRL</td>
<td>Number of physical page writes from the below the bar pool</td>
</tr>

<tr>
<td>DKWTMICS</td>
<td>Total wait time in microseconds for Disk I/O waits counted by DKWTS.
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DKWTS</td>
<td>Number Disk I/O waits
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DUMP</td>
<td>Writes to <var class="product">Model 204</var> file backups (DUMP command output)</td>
</tr>

<tr>
<td>DUPDTS</td>
<td>Records written to a deferred update data set for the file</td>
</tr>

<tr>
<td>ECCALL</td>
<td>Number of External Call Facility calls</td>
</tr>

<tr>
<td>ECCNCT</td>
<td>External Call Facility - Elapsed time for external program</td>
</tr>

<tr>
<td>ECCTOUT</td>
<td>Number of External Call Facility calls that timed out (program or subtask unavailable)</td>
</tr>

<tr>
<td>ECCWAITM</td>
<td>ECF – Number of calls that waited for module to become available</td>
</tr>

<tr>
<td>ECCWAITS</td>
<td>Number of External Call Facility calls that waited for a subtask to become available</td>
</tr>

<tr>
<td>ECDELETE</td>
<td>Number of EXTERNAL DELETE calls to External Call Facility</td>
</tr>

<tr>
<td>ECLOAD</td>
<td>Number of EXTERNAL LOAD calls to External Call Facility</td>
</tr>

<tr>
<td>ECMODMAX</td>
<td>ECF – Highwater mark of modules loaded</td>
</tr>

<tr>
<td>ECNAMMAX</td>
<td>External Call Facility – High-water mark of call names defined</td>
</tr>

<tr>
<td>ECTSKMAX</td>
<td>External Call Facility – High-water mark of subtasks active</td>
</tr>

<tr>
<td>ECTWAITM</td>
<td>External Call Facility – Elapsed time spent waiting for a module to become available</td>
</tr>

<tr>
<td>ECTWAITS</td>
<td>External Call Facility – Elapsed time spent waiting for a subtask to become available</td>
</tr>

<tr>
<td>ERRPDL</td>
<td>Highwater mark of the system pushdown list</td>
</tr>

<tr>
<td>FBMX</td>
<td>disk buffer hwm</td>
</tr>

<tr>
<td>FBWT</td>
<td>Number of waits for a disk buffer</td>
</tr>

<tr>
<td>FINDS</td>
<td>Number of FIND statements evaluated</td>
</tr>

<tr>
<td>FSCB</td>
<td>High-water mark of bytes used in the FSCB</td>
</tr>

<tr>
<td>FSCBSW</td>
<td>Number of full-screen buffer swaps</td>
</tr>

<tr>
<td>FTBL</td>
<td>Highwater mark of FTBL appearing in CMPL and EVAL lines for requests containing a field name reference in group context. If one or more groups are opened but no field name references are made, the portion of FTBL used by the open groups is not reported.</td>
</tr>

<tr>
<td>GTBL</td>
<td>Highwater mark of GTBL</td>
</tr>

<tr>
<td>GTBLRS</td>
<td>Number of GTBL rearrangements required to add a global object</td>
</tr>

<tr>
<td>GTBLRU</td>
<td>Number of GTBL rearrangements required to add a global string variable</td>
</tr>

<tr>
<td>HEAP</td>
<td>Dynamic memory highwater mark</td>
</tr>

<tr>
<td>HRDRSTRT</td>
<td>number of hard restarts</td>
</tr>

<tr>
<td>IN</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>INCMFS</td>
<td>Input lines from CMS full screen</td>
</tr>

<tr>
<td>INCMIO</td>
<td>Input lines from CMS non-full screen</td>
</tr>

<tr>
<td>INCRAM</td>
<td>Input lines from Remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>INVMFS</td>
<td>Input lines from IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>INVMIF</td>
<td>Input arguments supplied by certain IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>INVMIO</td>
<td>Input lines from IUCV or VMCF non-full screen thread</td>
</tr>

<tr>
<td>INXX</td>
<td>Input lines from QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>ITBL</td>
<td>Highwater mark of ITBL</td>
</tr>

<tr>
<td>IXADD</td>
<td>Number of index entries added to Tables C and D, including attempts to add duplicates</td>
</tr>

<tr>
<td>IXDEL</td>
<td>Number of entries deleted from Tables C and D</td>
</tr>

<tr>
<td>JSCREENS</td>
<td>Counts the number of times Janus Web incremented the SCREENS statistic. Since these may occur outside of request context, they would not necessarily have corresponding Since-Last statistics.</td>
</tr>

<tr>
<td>JWEBERRS</td>
<td>Counts the number of times that Janus Web returned a 4xx status code. Note that these would not be counted in the SCREENS statistic, but it is handy to know that for example a bunch of 404 or 401 errors are occurring.</td>
</tr>

<tr>
<td>LKPOST</td>
<td>Times an MP subtask posted another task to indicate that an MP lock had become available</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>Times MP subtasks invoked z/OS WAIT macros to wait for an available MP lock</td>
</tr>

<tr>
<td>LONGUPDTIME(MS)</td>
<td> Total milliseconds of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LONGUPDTS</td>
<td> Number of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LWTIM</td>
<td>Elapsed time (ms), spent waiting for a multiprocessing lock. Reported for each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals).</td>
</tr>

<tr>
<td>MAXIOX</td>
<td>Number of times <var class="product">Model 204</var> waited for a free database buffer</td>
</tr>

<tr>
<td>MBO</td>
<td>Highwater mark of transaction backout pages

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MCP
</td>
<td>Highwater mark of transaction checkpoint spans

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MOVE</td>
<td>Number of times the scheduler switched from one user to another</td>
</tr>

<tr>
<td>MPHASHD</td>
<td>MP duplicate hash entries found</td>
</tr>

<tr>
<td>MPLKPREM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting due to operating system preemption.

This is the elapsed time between when an MP lock becomes available (lock post) making a task ready to run, and when the task actually gets the CPU. That preemption delay is caused by the operating system dispatching other tasks ahead of this task.

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPLKWTIM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting for MP locks

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPR</td>
<td>Highwater mark of transaction pre-images

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MQAPICNT</td>
<td>MQ/204 – Count of MQ/Series API calls</td>
</tr>

<tr>
<td>MQAPITIM </td>
<td>MQ/204 – Elapsed time of MQSeries API calls</td>
</tr>

<tr>
<td>MQBYTEIN</td>
<td>MQ/204 – Total bytes retrieved (MQGET)</td>
</tr>

<tr>
<td>MQBYTEOU</td>
<td>MQ/204 – Total bytes sent (MQPUT/MQPUT1)</td>
</tr>

<tr>
<td>MQGETS</td>
<td>MQ/204 – Number of MQGETs performed</td>
</tr>

<tr>
<td>MQGWTCNT</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTSUC</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait that succeeded</td>
</tr>

<tr>
<td>MQGWTTIM</td>
<td>MQ/204 – Elapsed time for MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTTSP</td>
<td>MQ/204 – Total wait time specified on MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQHWQU</td>
<td>MQ/204 – High-water mark of queues concurrently in use</td>
</tr>

<tr>
<td>MQHWTASK</td>
<td>MQ/204 – High-water mark of MQ/204 subtasks in use</td>
</tr>

<tr>
<td>MQNUMQM</td>
<td>MQ/204 – Number of distinct queue managers connected</td>
</tr>

<tr>
<td>MQNUMQU</td>
<td>MQ/204 – Number of distinct queues accessed</td>
</tr>

<tr>
<td>MQPUTS</td>
<td>MQ/204 – Number of MQPUTs performed</td>
</tr>

<tr>
<td>MQWTM</td>
<td>Mean queue wait time, the average time a subtask spent waiting for work (waiting for PCBs to come into the offload queue)</td>
</tr>

<tr>
<td>MTDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from the MAINTASK queue and processed it</td>
</tr>

<tr>
<td>MTSDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from an MP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>MTZDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from a zIIP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>NTBL</td>
<td>Highwater mark of NTBL</td>
</tr>

<tr>
<td>OBJSWAP</td>
<td>number of object swaps for Sirius objects</td>
</tr>

<tr>
<td>OFFIN</td>
<td>Count of records read in by the OFFLOAD subtask</td>
</tr>

<tr>
<td>OFFOU</td>
<td>Count of records written to the OFFLOAD stream</td>
</tr>

<tr>
<td>OUT</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>OUTCMFS</td>
<td>Output lines to CMS full-screen thread</td>
</tr>

<tr>
<td>OUTCMIO</td>
<td>Output lines to CMS line-by-line thread</td>
</tr>

<tr>
<td>OUTCRAM</td>
<td>Output lines from remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>OUTPB</td>
<td>Highwater mark of OUTPB</td>
</tr>

<tr>
<td>OUTVMFS</td>
<td>Output lines to IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>OUTVMIF</td>
<td>Output lines to IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>OUTVMIO</td>
<td>Output lines to IUCV or VMCF line-by-line threads</td>
</tr>

<tr>
<td>OUTXX</td>
<td>Output lines to QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>PBRSFLT</td>
<td>Number of private buffer reservation faults</td>
</tr>

<tr>
<td>PCPU</td>
<td>Percentage of time <var class="product">Model 204</var> was given the CPU when it wanted CPU time. In an MP environment, system PCPU is the sum of CPU time in all tasks divided by the sum of elapsed time in all tasks.</td>
</tr>

<tr>
<td>PDL</td>
<td>Highwater mark of the pushdown list</td>
</tr>

<tr>
<td>PETIM</td>
<td>Elapsed time (ms), spent waiting due to OS preemption. Reported for the MAINTASK and each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals)</td>
</tr>

<tr>
<td>PNDGTIME</td>
<td>Milliseconds of unnecessary broken time</td>
</tr>

<tr>
<td>PR</td>
<td>Real time consumed, in milliseconds. PCPU = CPU / PR.</td>
</tr>

<tr>
<td>QTBL</td>
<td>Highwater mark of QTBL</td>
</tr>

<tr>
<td>RCV</td>
<td>Number of blocks needed for subtransaction recovery

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>RECADD</td>
<td>Number of records started in Table B, not including extension records</td>
</tr>

<tr>
<td>RECDEL</td>
<td>Number of records deleted from Table B, not including extension records or records deleted by DELETE RECORDS or IFDSET</td>
</tr>

<tr>
<td>RECDS</td>
<td>Number of records processed by FOR statements, SORT statements, IFGET calls, or IFPOINT calls, or similar SQL record processing</td>
</tr>

<tr>
<td>REDY</td>
<td> Percentage of performance samples at which the user was ready to run (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>REQ</td>
<td>Number of SOUL requests evaluated</td>
</tr>

<tr>
<td>REST</td>
<td>Number of reads from a <var class="product">Model 204</var> file backup (<var>RESTORE</var> command)</td>
</tr>

<tr>
<td>RETRYA</td>
<td>Page retries in Table A</td>
</tr>

<tr>
<td>RETRYC</td>
<td>Page retries in Table C</td>
</tr>

<tr>
<td>RQTM</td>
<td>Elapsed time for the activity being reported, exclusive of terminal I/O time</td>
</tr>

<tr>
<td>RSXCOMP</td>
<td>Number of compactions of the record locking table. If greater than 0, increase <var>LRETBL</var>.</td>
</tr>

<tr>
<td>RUNG</td>
<td> Percentage of performance samples at which the user was running (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SCHDCPU</td>
<td>In MP configuration, total scheduler CPU for the user or request</td>
</tr>

<tr>
<td>SCREENS</td>
<td>Total number of full-screen reads (<var>READ SCREEN</var> statements) evaluated by a SOUL request.</td>
</tr>

<tr>
<td>SFTRSTRT</td>
<td>number of soft restarts.</td>
</tr>

<tr>
<td>SGMTI</td>
<td>Number of input lines from included procedures</td>
</tr>

<tr>
<td>SGMTO</td>
<td>Number of output lines to procedures defined by the user</td>
</tr>

<tr>
<td>SLIC</td>
<td>Number of times that the user was time-sliced by the <var class="product">Model 204</var> scheduler</td>
</tr>

<tr>
<td>SMPLS</td>
<td>Number of performance sample points at which the user was active or total number of performance samples taken at the system level (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SORTS</td>
<td>Number of SOUL <var>SORT</var> statements or SQL sorts evaluated</td>
</tr>

<tr>
<td>SQLI</td>
<td>Remote SQL input highwater mark</td>
</tr>

<tr>
<td>SQLO</td>
<td>Remote SQL output highwater mark</td>
</tr>

<tr>
<td>SQRD</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>SQWR</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>STBL</td>
<td>Highwater mark of STBL</td>
</tr>

<tr>
<td>STCPU</td>
<td>Total amount of time, in milliseconds, that the user has run in an MP offload subtask</td>
</tr>

<tr>
<td>STDEQ</td>
<td>Number of times that an MP subtask took a unit of work from an MP subtask queue and processed it</td>
</tr>

<tr>
<td>STIMERS</td>
<td>Total number of STIMER or STIMERM calls</td>
</tr>

<tr>
<td>STPOST</td>
<td>Times MP subtasks performed real operating system POSTs to send work to the maintask</td>
</tr>

<tr>
<td>STRECDS</td>
<td>Number of records processed by SORT statements or SQL sorts</td>
</tr>

<tr>
<td>STWAIT</td>
<td>Number of times MP subtasks invoked z/OS WAIT macros to wait for work from the maintask</td>
</tr>

<tr>
<td>STZDEQ</td>
<td>Number of times that an MP subtask took a unit of work from a zIIP subtask queue and processed it because the MP subtask was idle</td>
</tr>

<tr>
<td>SVAC</td>
<td>Active servers (an average, included on a performance line)</td>
</tr>

<tr>
<td>SVMX</td>
<td>Highwater mark for servers (0 if no server swapping)</td>
</tr>

<tr>
<td>SVPAGES</td>
<td><code>SVPAGES * 4096</code> is the number of bytes transferred as a result of server reads and writes</td>
</tr>

<tr>
<td>SVRD</td>
<td>Number of server reads</td>
</tr>

<tr>
<td>SVWR</td>
<td>Number of server writes</td>
</tr>

<tr>
<td>SWPG</td>
<td>Percentage of performance samples at which the user was swapping in or out (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>SWT</td>
<td>Times <var class="product">Model 204</var> issued a real WAIT while not in user-switching mode</td>
</tr>

<tr>
<td>TEMX</td>
<td>Highwater mark of CCATEMP pages used in the expansion area</td>
</tr>

<tr>
<td>TFMX</td>
<td>Highwater mark of CCATEMP pages used</td>
</tr>

<tr>
<td>TSMX</td>
<td>Highwater mark of CCATEMP pages used in the small model page pool</td>
</tr>

<tr>
<td>TTBL</td>
<td>Highwater mark of TTBL</td>
</tr>

<tr>
<td>UBUFHWS</td>
<td>Highwater mark, in bytes, of user's Universal Buffer</td>
</tr>

<tr>
<td>UDD</td>
<td>Number of lines written to a directed output (<var>USE</var>) data set</td>
</tr>

<tr>
<td>UPDTTIME(MS)</td>
<td>Number of milliseconds that a file was being updated

UPT(MS) appears as the column header for this statistic on a report
</td>
</tr>

<tr>
<td>UPDTTIME</td>
<td>Number of milliseconds that the user was actively updating at least one file</td>
</tr>

<tr>
<td>USMX</td>
<td>Highwater mark for simultaneous active users (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>USRS</td>
<td>Average number of active users (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>VTBL</td>
<td>Number of VTBL entries at the end of compilation (CMPL) processing or the end of evaluation (EVAL) processing</td>
</tr>

<tr>
<td>WAIT</td>
<td>Number of real operating system waits</td>
</tr>

<tr>
<td>WTCFR</td>
<td>Number of times that the user waited to obtain a critical file resource, either share or exclusive

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTRLK</td>
<td>Number of times that the user waited to obtain a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTSV</td>
<td>Percentage of performance samples at which the user was waiting for a server (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>XTBL</td>
<td>Highwater mark of XTBL</td>
</tr>

<tr>
<td>ZTCPU</td>
<td>The CPU (ms) consumed on a zIIP processor by the MAINTASK, an MP subtask or a zIIP subtask. Reported for each task at <var class="product">Model 204</var> termination and in <var>MONITOR TASKS</var> output (for Model 5 terminals only)</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>The number of times that a zIIP subtask took a unit of work from a zIIP subtask queue and processed it</td>
</tr>
</table>

==Header and trailer entries (Type 0)==

Each journal block begins with a header record and ends with a trailer record.

===Header entries (Type 0)===

Header entries have the format shown in the following table: 
<table>
<caption style="margin-right:6em">Header entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entire journal record, including header and trailer</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Flags used by recovery</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH </td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">4</td>
<td>Binary</td>
<td> Sequence number </td>
</tr>

<tr>
<td>16(10)</td>
<td align="right">10</td>
<td>Binary</td>
<td> System Store Clock Extended (STCKE) value to provide picosecond accuracy on the journal date/time stamp

Bytes 1-9 || byte 16 
</td>
</tr>

<tr>
<td>26(1A)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of header, type 00</td>
</tr>

<tr>
<td>28(1C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Version in hex</td>
</tr>

<tr>
<td>30(1E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Version in EBCDIC</td>
</tr>

<tr>
<td>38(26)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Job name</td>
</tr>

<tr>
<td>46(2E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>JES Job ID</td>
</tr>

<tr>
<td>54(36)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>SMF System ID</td>
</tr>
</table>
<ul>
<li>If the flag byte at offset 3 of type 00 has the X'02' bit on, then it is a header record from <var class="product">Model 204</var> version 7.4.0 or later with its length at offset X'1A'.</li>

<li>If that flag byte has the X'01' bit on, then the header is from version 7.1.0 and is 26 bytes in length. </li>

<li>If neither of those bits is on, then the header is a from a pre-7.1.0 version and is 16 bytes in length.</li>
</ul>

===Recovery flags===

Flags used by recovery can have the value of X'00' or a sum of any of the following: 
<table>
<tr class="head">
<th>Value</th>
<th>Block contains these records...</th>
</tr>

<tr>
<td>X'80'</td>
<td>Type 1</td>
</tr>

<tr>
<td>X'40'</td>
<td>Type 2</td>
</tr>

<tr>
<td>X'20'</td>
<td>Type 3</td>
</tr>

<tr>
<td>X'10'</td>
<td>Type 4</td>
</tr>

<tr>
<td>X'08'</td>
<td>Type 5</td>
</tr>

<tr>
<td>X'04'</td>
<td>Type 6</td>
</tr>
</table>

===Sequence numbers===

The sequence number represents the number of each journal record, starting at 0 and increasing by 1. A merged journal (output of the MERGEJ utility) sequence number consists of a 2-byte hexadecimal number at offset 12(0C), which indicates the input file this journal record came from, and a 2-byte hexadecimal field at offset 14(0E), which indicates the sequence within the INPUT journal.

===Trailer entries (Type 0)===

Trailer entries have the format shown in the following table: 
<table>
<caption>Trailer entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data </td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Recovery entries (Types 1-6)==

Entry types X'01' through X'06' contain information used for recovery. They follow the same general format as all other journal entries. There is no type X'07' journal entry. 

The format of the recovery entries is meaningful only in the context of the <var class="product">Model 204</var> ROLL FORWARD algorithm. However, entry types might be of interest in some statistics gathering applications, as follows: 
<table>
<tr class="head">
<th>Type </th>
<th>Contains recovery information from...</th>
</tr>

<tr>
<td>1 </td>
<td>Discontinuity</td>
</tr>

<tr>
<td>2 </td>
<td> Begin update unit.

More than one type 2 entry can be written for each update unit. The update unit number appears as a 4-byte binary number at offset 16(10).
</td>
</tr>

<tr>
<td>3 </td>
<td> End update unit.

The update unit number appears in the same format and location as the type 2 entry.
</td>
</tr>

<tr>
<td>4</td>
<td>File state information: opened, closed, dumped, file parameter list (FPL) page preimage logged or open at the time of a checkpoint</td>
</tr>

<tr>
<td>5 </td>
<td>Checkpoint</td>
</tr>

<tr>
<td>6 </td>
<td>File update </td>
</tr>
</table>

==System statistics entries (Type 8)==

Cumulative statistics, listed by offset in the [[#System performance statistics|Layout of system subtype X'02' entries]] table, are kept for the entire system. Final, partial, and performance system statistics are written to the journal during <var class="product">Model 204</var> termination in a line that begins with:
ST $$$ SYSTEM='version#'


For additional information about:
<ul>
<li>Using system statistics for performance monitoring, see [[Performance monitoring and tuning]]. </li>

<li>Disk buffer monitor statistics and parameters, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </li>
</ul>

===Final statistics===

The system final statistics line, similar to the following, is produced as part of system termination: 
ST $$$ SYSTEM='5A 'AUDIT=43 OUT=38 IN=14 WAIT=19 ...


===Partial statistics===

Statistics in a system partial statistics line, similar to the following, accumulate from the beginning of the run, if the User 0 <var>[[ACCTIM parameter|ACCTIM]]</var> parameter is nonzero: 
ST $$$ SYSTEM='6.1.0'PARTIAL=3 AUDIT=19 OUT=10 IN=5 WAIT=3 ...


===Performance statistics===

System performance statistic lines, similar to the following, are written if the User 0 <var>[[RPTCNT parameter|RPTCNT]]</var> and <var>[[SMPLTIM parameter|SMPLTIM]]</var> parameters are nonzero: 
ST $$$ SYSTEM='6.1.0' PERFORMANCE=n


The numbers determined at the performance sample points are averaged for the entire run. 

===Entry formats===

System statistics entries have the format shown in the following table: 
<table>
<caption>System statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'08'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:

X'00' = final statistics

X'01' = partial statistics

X'02' = performance statistics

X'04' = additional disk buffer monitor

X'08' = subtask statistics
</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Subtask number if subtype = X'08'; otherwise unused</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Unused</td>
</tr>

<tr>
<td>16(10) to end of journal</td>
<td align="right"> — </td>
<td align="right"> — </td>
<td>

Contents depend on subtypes, shown in tables in the following sections:
<ul>
<li>[[#System final and partial statistics|System final and partial statistics]]</li>

<li>[[#System performance statistics|System performance statistics]]</li>

<li>[[#Additional disk buffer monitor statistics|Additional disk buffer monitor statistics]]</li>

<li>[[#User since-last statistics|User since-last statistics]]</li>
</ul>
</td> </tr>
</table>

==System final and partial statistics==

For subtypes X'00' (final statistics) and X'01' (partial statistics), the layout of the remainder of the entry is shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
The following statistics are data type Binary. However, the length varies — either 4 or 8, to accommodate 64-bit system architecture. 
<table>
<caption>System final and partial statistics</caption>
<tr class="head">
<th>Offset dec(hex) </th>
<th>Length </th>
<th>Description</th>
</tr>

<tr>
<td>16(10) </td>
<td>8 </td>
<td>AUDIT</td>
</tr>

<tr>
<td>24(18) </td>
<td>8 </td>
<td>OUT</td>
</tr>

<tr>
<td>32(20) </td>
<td>8 </td>
<td>IN</td>
</tr>

<tr>
<td>40(28) </td>
<td>8 </td>
<td>OUTXX</td>
</tr>

<tr>
<td>48(30) </td>
<td>8 </td>
<td>INXX</td>
</tr>

<tr>
<td>56(38) </td>
<td>8 </td>
<td>DEV5</td>
</tr>

<tr>
<td>64(40) </td>
<td>8 </td>
<td>DEV6</td>
</tr>

<tr>
<td>72(48) </td>
<td>8 </td>
<td>DEV7</td>
</tr>

<tr>
<td>80(50) </td>
<td>8 </td>
<td>DEV8</td>
</tr>

<tr>
<td>88(58) </td>
<td>8 </td>
<td>DEV9</td>
</tr>

<tr>
<td>96(60) </td>
<td>8 </td>
<td>DEV10</td>
</tr>

<tr>
<td>104(68) </td>
<td>8 </td>
<td>DEV11</td>
</tr>

<tr>
<td>112(70) </td>
<td>8 </td>
<td>DEV12</td>
</tr>

<tr>
<td>120(78) </td>
<td>8 </td>
<td>DEV13</td>
</tr>

<tr>
<td>128(80) </td>
<td>8 </td>
<td>DEV14</td>
</tr>

<tr>
<td>136(88) </td>
<td>8 </td>
<td>OUTTTY</td>
</tr>

<tr>
<td>144(90) </td>
<td>8 </td>
<td>INTTY</td>
</tr>

<tr>
<td>152(98) </td>
<td>8 </td>
<td>DEV17</td>
</tr>

<tr>
<td>160(A0) </td>
<td>8 </td>
<td>DEV18</td>
</tr>

<tr>
<td>168(A8) </td>
<td>8 </td>
<td>DEV19</td>
</tr>

<tr>
<td>176(B0) </td>
<td>8 </td>
<td>DEV20</td>
</tr>

<tr>
<td>184(B8) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>192(C0) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>200(C8) </td>
<td>8 </td>
<td>DEV23</td>
</tr>

<tr>
<td>208(D0) </td>
<td>8 </td>
<td>DEV24</td>
</tr>

<tr>
<td>216(D8) </td>
<td>8 </td>
<td>DEV25</td>
</tr>

<tr>
<td>224(E0) </td>
<td>8 </td>
<td>DEV26</td>
</tr>

<tr>
<td>232(E8) </td>
<td>8 </td>
<td>DEV27</td>
</tr>

<tr>
<td>240(F0) </td>
<td>8 </td>
<td>DEV28</td>
</tr>

<tr>
<td>248(F8) </td>
<td>8 </td>
<td>OUTCRAM</td>
</tr>

<tr>
<td>256(100) </td>
<td>8 </td>
<td>INCRAM</td>
</tr>

<tr>
<td>264(108) </td>
<td>8 </td>
<td>DEV31</td>
</tr>

<tr>
<td>272(110) </td>
<td>8 </td>
<td>DEV32</td>
</tr>

<tr>
<td>280(118) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>288(120) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>296(128) </td>
<td>8 </td>
<td>DEV35</td>
</tr>

<tr>
<td>304(130) </td>
<td>8 </td>
<td>DEV36</td>
</tr>

<tr>
<td>312(138) </td>
<td>8 </td>
<td>DEV37</td>
</tr>

<tr>
<td>320(140) </td>
<td>8 </td>
<td>DEV38</td>
</tr>

<tr>
<td>328(148) </td>
<td>8 </td>
<td>OUTVMIO</td>
</tr>

<tr>
<td>336(150) </td>
<td>8 </td>
<td>INVMIO</td>
</tr>

<tr>
<td>344(158) </td>
<td>8 </td>
<td>OUTVMFS</td>
</tr>

<tr>
<td>352(160) </td>
<td>8 </td>
<td>INVMFS</td>
</tr>

<tr>
<td>360(168) </td>
<td>8 </td>
<td>OUTVMIF</td>
</tr>

<tr>
<td>368(170) </td>
<td>8 </td>
<td>INVMIF</td>
</tr>

<tr>
<td>376(178) </td>
<td>8 </td>
<td>OUTCMIO</td>
</tr>

<tr>
<td>384(180) </td>
<td>8 </td>
<td>INCMIO</td>
</tr>

<tr>
<td>392(188) </td>
<td>8 </td>
<td>OUTCMFS</td>
</tr>

<tr>
<td>400(190) </td>
<td>8 </td>
<td>INCMFS</td>
</tr>

<tr>
<td>408(198) </td>
<td>8 </td>
<td>DEV49</td>
</tr>

<tr>
<td>416(1A0) </td>
<td>8 </td>
<td>DEV50</td>
</tr>

<tr>
<td>424(1A8) </td>
<td>8 </td>
<td>OFFIN</td>
</tr>

<tr>
<td>432(1B0) </td>
<td>8 </td>
<td>OFFOU</td>
</tr>

<tr>
<td>440(1B8) </td>
<td>8 </td>
<td>DEV53</td>
</tr>

<tr>
<td>448(1C0) </td>
<td>8 </td>
<td>DEV54</td>
</tr>

<tr>
<td>456(1C8) </td>
<td>8 </td>
<td>DEV55</td>
</tr>

<tr>
<td>464(1D0) </td>
<td>8 </td>
<td>DEV56</td>
</tr>

<tr>
<td>472(1D8) </td>
<td>8 </td>
<td>DEV57</td>
</tr>

<tr>
<td>480(1E0) </td>
<td>8 </td>
<td>DEV58</td>
</tr>

<tr>
<td>488(1E8) </td>
<td>8 </td>
<td>DEV59</td>
</tr>

<tr>
<td>496(1F0) </td>
<td>8 </td>
<td>DEV60</td>
</tr>

<tr>
<td>504(1F8) </td>
<td>8 </td>
<td>DEV61</td>
</tr>

<tr>
<td>512(200) </td>
<td>8 </td>
<td>DEV62</td>
</tr>

<tr>
<td>520(208) </td>
<td>8 </td>
<td>DEV63</td>
</tr>

<tr>
<td>528(210) </td>
<td>8 </td>
<td>DEV64</td>
</tr>

<tr>
<td>536(218) </td>
<td>8 </td>
<td>DEV65</td>
</tr>

<tr>
<td>544(220) </td>
<td>8 </td>
<td>DEV66</td>
</tr>

<tr>
<td>552(228) </td>
<td>8 </td>
<td>DEV67</td>
</tr>

<tr>
<td>560(230) </td>
<td>8 </td>
<td>DEV68</td>
</tr>

<tr>
<td>568(238) </td>
<td>8 </td>
<td>DEV69</td>
</tr>

<tr>
<td>576(240) </td>
<td>8 </td>
<td>DEV70</td>
</tr>

<tr>
<td>584(248) </td>
<td>8 </td>
<td>DEV71</td>
</tr>

<tr>
<td>592(250) </td>
<td>8 </td>
<td>DEV72</td>
</tr>

<tr>
<td>600(258) </td>
<td>8 </td>
<td>DEV73</td>
</tr>

<tr>
<td>608(260) </td>
<td>8 </td>
<td>DEV74</td>
</tr>

<tr>
<td>616(268) </td>
<td>4 </td>
<td>WAIT</td>
</tr>

<tr>
<td>620(26C) </td>
<td>4 </td>
<td>MPLKWTIM</td>
</tr>

<tr>
<td>624(270) </td>
<td>8 </td>
<td>DKRD</td>
</tr>

<tr>
<td>632(278) </td>
<td>8 </td>
<td>DKWR</td>
</tr>

<tr>
<td>640(280) </td>
<td>4 </td>
<td>SVRD</td>
</tr>

<tr>
<td>644(284) </td>
<td>4 </td>
<td>SVWR</td>
</tr>

<tr>
<td>648(288) </td>
<td>8 </td>
<td>CPU</td>
</tr>

<tr>
<td>656(290) </td>
<td>8 </td>
<td>REQ</td>
</tr>

<tr>
<td>664(298) </td>
<td>8 </td>
<td>MOVE</td>
</tr>

<tr>
<td>672(2A0) </td>
<td>4 </td>
<td>DUMP</td>
</tr>

<tr>
<td>676(2A4) </td>
<td>4 </td>
<td>REST</td>
</tr>

<tr>
<td>680(2A8) </td>
<td>4 </td>
<td>SLIC</td>
</tr>

<tr>
<td>684(2AC) </td>
<td>4 </td>
<td>CNCT</td>
</tr>

<tr>
<td>688(2B0) </td>
<td>4 </td>
<td>FBWT</td>
</tr>

<tr>
<td>692(2B4) </td>
<td>4 </td>
<td>SWT</td>
</tr>

<tr>
<td>696(2B8) </td>
<td>4 </td>
<td>ERRPDL</td>
</tr>

<tr>
<td>700(2BC) </td>
<td>4 </td>
<td>MPLKPREM</td>
</tr>

<tr>
<td>704(2C0) </td>
<td>8 </td>
<td>RECADD</td>
</tr>

<tr>
<td>712(2C8) </td>
<td>8 </td>
<td>RECDEL</td>
</tr>

<tr>
<td>720(2D0) </td>
<td>8 </td>
<td>BADD</td>
</tr>

<tr>
<td>728(2D8) </td>
<td>8 </td>
<td>BDEL</td>
</tr>

<tr>
<td>736(2E0) </td>
<td>8 </td>
<td>BCHG</td>
</tr>

<tr>
<td>744(2E8) </td>
<td>8 </td>
<td>IXADD</td>
</tr>

<tr>
<td>752(2F0) </td>
<td>8 </td>
<td>IXDEL</td>
</tr>

<tr>
<td>760(2F8) </td>
<td>8 </td>
<td>FINDS</td>
</tr>

<tr>
<td>768(300) </td>
<td>4 </td>
<td>SORTS</td>
</tr>

<tr>
<td>772(304) </td>
<td>4 </td>
<td>JSCREENS</td>
</tr>

<tr>
<td>776(308) </td>
<td>8 </td>
<td>RECDS</td>
</tr>

<tr>
<td>784(310) </td>
<td>8 </td>
<td>STRECDS</td>
</tr>

<tr>
<td>792(318) </td>
<td>8 </td>
<td>DKAR</td>
</tr>

<tr>
<td>800(320) </td>
<td>8 </td>
<td>DKPR</td>
</tr>

<tr>
<td>808(328) </td>
<td>4 </td>
<td>DKRR</td>
</tr>

<tr>
<td>812(32C) </td>
<td>4 </td>
<td>FBMX</td>
</tr>

<tr>
<td>816(330) </td>
<td>4 </td>
<td>TFMX</td>
</tr>

<tr>
<td>820(334) </td>
<td>4 </td>
<td>USMX</td>
</tr>

<tr>
<td>824(338) </td>
<td>4 </td>
<td>SVMX</td>
</tr>

<tr>
<td>828(33C) </td>
<td>4 </td>
<td>SFTRSTRT (number of soft restarts)</td>
</tr>

<tr>
<td>832(340) </td>
<td>8 </td>
<td>APSYLD</td>
</tr>

<tr>
<td>840(348) </td>
<td>8 </td>
<td>APSYLDD</td>
</tr>

<tr>
<td>848(350) </td>
<td>4 </td>
<td>APSYLDT</td>
</tr>

<tr>
<td>852(354) </td>
<td>4 </td>
<td>Spare</td>
</tr>

<tr>
<td>856(358) </td>
<td>8 </td>
<td>DKPRF</td>
</tr>

<tr>
<td>864(360) </td>
<td>4 </td>
<td>SMPLS</td>
</tr>

<tr>
<td>868(364) </td>
<td>4 </td>
<td>USRS</td>
</tr>

<tr>
<td>872(368) </td>
<td>4 </td>
<td>SVAC</td>
</tr>

<tr>
<td>876(36C) </td>
<td>4 </td>
<td>RUNG</td>
</tr>

<tr>
<td>880(370) </td>
<td>4 </td>
<td>REDY</td>
</tr>

<tr>
<td>884(374) </td>
<td>4 </td>
<td>BLKI</td>
</tr>

<tr>
<td>888(378) </td>
<td>4 </td>
<td>WTSV</td>
</tr>

<tr>
<td>892(37C) </td>
<td>4 </td>
<td>BLKO</td>
</tr>

<tr>
<td>896(380) </td>
<td>4 </td>
<td>SWPG</td>
</tr>

<tr>
<td>900(384) </td>
<td>4 </td>
<td>PCPU</td>
</tr>

<tr>
<td>904(388) </td>
<td>4 </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>908(38C) </td>
<td>4 </td>
<td>JWEBERRS</td>
</tr>

<tr>
<td>912(390) </td>
<td>8 </td>
<td>STCPU</td>
</tr>

<tr>
<td>920(398) </td>
<td>8 </td>
<td>STDEQ</td>
</tr>

<tr>
<td>928(3A0) </td>
<td>8 </td>
<td>STWAIT</td>
</tr>

<tr>
<td>936(3A8) </td>
<td>4 </td>
<td>STPOST</td>
</tr>

<tr>
<td>940(3AC) </td>
<td>4 </td>
<td>LKWAIT</td>
</tr>

<tr>
<td>944(3B0) </td>
<td>4 </td>
<td>LKPOST</td>
</tr>

<tr>
<td>948(3B4) </td>
<td>4 </td>
<td>RSXCOMP</td>
</tr>

<tr>
<td>952(3B8) </td>
<td>4 </td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>956(3BC) </td>
<td>4 </td>
<td>SCREENS</td>
</tr>

<tr>
<td>960(3C0) </td>
<td>4 </td>
<td>STIMERS</td>
</tr>

<tr>
<td>964(3C4) </td>
<td>4 </td>
<td>HRDRSTRT (number of hard restarts)</td>
</tr>

<tr>
<td>968(3C8) </td>
<td>8 </td>
<td>SVPAGES</td>
</tr>

<tr>
<td>976(3D0) </td>
<td>4 </td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>980(3D4) </td>
<td>4 </td>
<td>COMMITS</td>
</tr>

<tr>
<td>984(3D8) </td>
<td>4 </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>988(3DC) </td>
<td>4 </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>992(3E0) </td>
<td>4 </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>996(3E4) </td>
<td>4 </td>
<td>MPHASHD</td>
</tr>

<tr>
<td>1000(3E8) </td>
<td>4 </td>
<td>CDLWAIT</td>
</tr>

<tr>
<td>1004(3EC) </td>
<td>4 </td>
<td>MQGETS</td>
</tr>

<tr>
<td>1008(3F0) </td>
<td>4 </td>
<td>MQPUTS</td>
</tr>

<tr>
<td>1012(3F4) </td>
<td>4 </td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>1016(3F8) </td>
<td>4 </td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>1020(3FC) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1024(400) </td>
<td>8 </td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>1032(408) </td>
<td>8 </td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>1040(410) </td>
<td>4 </td>
<td>MQHWQU</td>
</tr>

<tr>
<td>1044(414) </td>
<td>4 </td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>1048(418) </td>
<td>4 </td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>1052(41C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1056(420) </td>
<td>8 </td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>1064(428) </td>
<td>8 </td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>1072(430) </td>
<td>8 </td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>1080(438) </td>
<td>4 </td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>1084(43C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1088(440) </td>
<td>8 </td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>1096(448) </td>
<td>4 </td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>1100(44C) </td>
<td>4 </td>
<td>ECLOAD</td>
</tr>

<tr>
<td>1104(450) </td>
<td>4 </td>
<td>ECDELETE</td>
</tr>

<tr>
<td>1108(454) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1112(458) </td>
<td>8 </td>
<td>ECCALL</td>
</tr>

<tr>
<td>1120(460) </td>
<td>4 </td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>1124(464) </td>
<td>4 </td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>1128(468) </td>
<td>4 </td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>1132(46C) </td>
<td>4 </td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>1136(470) </td>
<td>4 </td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>1140(474) </td>
<td>4 </td>
<td>ECCNCT</td>
</tr>

<tr>
<td>1144(478) </td>
<td>4 </td>
<td>ECMODMAX</td>
</tr>

<tr>
<td>1148(47C) </td>
<td>4 </td>
<td>ECNAMMAX</td>
</tr>

<tr>
<td>1152(480) </td>
<td>4 </td>
<td>ECTSKMAX</td>
</tr>

<tr>
<td>1156(484) </td>
<td>4 </td>
<td>GTBLRU</td>
</tr>

<tr>
<td>1160(488) </td>
<td>4 </td>
<td>GTBLRS</td>
</tr>

<tr>
<td>1164(48C) </td>
<td>4 </td>
<td>TSMX</td>
</tr>

<tr>
<td>1168(490) </td>
<td>4 </td>
<td>TEMX</td>
</tr>

<tr>
<td>1172(494) </td>
<td>4 </td>
<td>MAXIOX</td>
</tr>

<tr>
<td>1176(498) </td>
<td>8 </td>
<td>DKRDL</td>
</tr>

<tr>
<td>1184(4A0) </td>
<td>8 </td>
<td>DKWRL</td>
</tr>

<tr>
<td>1192(4A8) </td>
<td>8 </td>
<td>CPUTOTZE</td>
</tr>

<tr>
<td>1200(4B0) </td>
<td>8 </td>
<td>CPUONZIP</td>
</tr>

<tr>
<td>1208(4B8) </td>
<td>4 </td>
<td>MPR
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1212(4BC) </td>
<td>4 </td>
<td>MBO
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1216(4C0) </td>
<td>4 </td>
<td>MCP
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1220(4C4) </td>
<td>4 </td>
<td>RCV
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1224(4C8) </td>
<td>8 </td>
<td>Spare </td>
</tr>

<tr>
<td>1232(4D0) </td>
<td>8 </td>
<td>DKWTMICS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1240(4D8) </td>
<td>8 </td>
<td>DKWTS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1248(4E0) </td>
<td>8 </td>
<td>MTDEQ</td>
</tr>

<tr>
<td>1256(4E8) </td>
<td>8 </td>
<td>MTSDEQ</td>
</tr>

<tr>
<td>1264(4F0) </td>
<td>8 </td>
<td>MTZDEQ</td>
</tr>

<tr>
<td>1272(4F8) </td>
<td>8 </td>
<td>STZDEQ</td>
</tr>

<tr>
<td>1280(500) </td>
<td>8 </td>
<td>ZTDEQ</td>
</tr>
</table>

==System performance statistics==

===Entry format===

For subtype X'02'(system performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. See [[#Description of statistics|Statistics with descriptions]] table for the meaning of each statistic. 
<table>
<caption>Layout of system subtype X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 16(10)</td>
<td>SMPLS</td>
</tr>

<tr>
<td> 20(14)</td>
<td>USRS</td>
</tr>

<tr>
<td> 24(18)</td>
<td>SVAC</td>
</tr>

<tr>
<td> 28(1C)</td>
<td>RUNG </td>
</tr>

<tr>
<td> 32(20)</td>
<td>REDY</td>
</tr>

<tr>
<td> 36(24)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 40(28)</td>
<td>WTSV</td>
</tr>

<tr>
<td> 44(2C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 48(30)</td>
<td>SWPG </td>
</tr>
</table>

==Additional disk buffer monitor statistics==

For subtype X'04' (additional disk buffer monitor statistics), the layout of the entry is shown in the following table. Each statistic in the table is: Length, 8; Data type, Binary.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Disk buffer monitor statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Disk buffer monitor statistic </th>
</tr>

<tr>
<td>16(10)</td>
<td>Spare</td>
</tr>

<tr>
<td>24(18) </td>
<td>DKSTKQC </td>
</tr>

<tr>
<td>32(20) </td>
<td>DKSWRP </td>
</tr>

<tr>
<td>40(28) </td>
<td>DKSWRPT </td>
</tr>

<tr>
<td>48(30) </td>
<td>DKSDIR </td>
</tr>

<tr>
<td>56(38) </td>
<td>DKSDIRT </td>
</tr>

<tr>
<td>64(40) </td>
<td>DKSKIP </td>
</tr>

<tr>
<td>72(48) </td>
<td>Spare </td>
</tr>

<tr>
<td>80(50) </td>
<td>Spare</td>
</tr>

<tr>
<td>88(58) </td>
<td>DKSRR </td>
</tr>

<tr>
<td>96(60) </td>
<td>DKSFBS </td>
</tr>

<tr>
<td>104(68) </td>
<td>DKSKIPT </td>
</tr>

<tr>
<td>112(70) </td>
<td>DKSAWT </td>
</tr>

<tr>
<td>120(78) </td>
<td>DKSAWW</td>
</tr>

<tr>
<td>128(80) </td>
<td>DKSAWWL</td>
</tr>

<tr>
<td>136(88) </td>
<td>DKSAWB </td>
</tr>

<tr>
<td>144(90) </td>
<td>DKSAWBL</td>
</tr>

<tr>
<td>152(98) </td>
<td>DKSRRFND </td>
</tr>

<tr>
<td>160(A0) </td>
<td>DKSTBLF </td>
</tr>

<tr>
<td>168(A8) </td>
<td>DKSTBLA </td>
</tr>

<tr>
<td>176(B0) </td>
<td>DKSTBLB </td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKSTBLC </td>
</tr>

<tr>
<td>192(C0) </td>
<td>DKSTBLD </td>
</tr>

<tr>
<td>200(C8) </td>
<td>Spare </td>
</tr>

<tr>
<td>208(D0) </td>
<td>Spare </td>
</tr>

<tr>
<td>216(D8) </td>
<td>Spare </td>
</tr>

<tr>
<td>224(E0) </td>
<td>Spare </td>
</tr>

<tr>
<td>232(E8) </td>
<td>Spare </td>
</tr>

<tr>
<td>240(F0) </td>
<td>Spare </td>
</tr>

<tr>
<td>248(F8) </td>
<td>Spare </td>
</tr>

<tr>
<td>256(100) </td>
<td>DKSTBLX </td>
</tr>

<tr>
<td>264(108) </td>
<td>DKSTBLE</td>
</tr>

<tr>
<td>272(110)</td>
<td>Spare </td>
</tr>
</table>

==Multiprocessing (MP) subtask statistics==

The following statistics apply only to installations configured for multiprocessing using MP/204. For subtype X'08' (subtask specific statistics), the layout of the entry is shown in the following table.
For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>MP subtask statistics and offsets</caption>
<tr class="head">
<th>MP statistic </th>
<th>Offset dec(hex) </th>
<th>Length</th>
</tr>

<tr>
<td>CPU </td>
<td>16(10) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PR </td>
<td>24(18) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PCPU </td>
<td>32(20) </td>
<td align="right">4</td>
</tr>

<tr>
<td>STWAIT</td>
<td>36(24)</td>
<td align="right">4</td>
</tr>

<tr>
<td>STPOST</td>
<td>40(28)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>44(2C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKPOST</td>
<td>48(30)</td>
<td align="right">4</td>
</tr>

<tr>
<td>SPARE</td>
<td>52(34)</td>
<td align="right">4</td>
</tr>

<tr>
<td>MQWTM</td>
<td>56(38) </td>
<td align="right">8</td>
</tr>

<tr>
<td>DEQ </td>
<td>64(40) </td>
<td align="right">8</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>72(48)</td>
<td align="right">8</td>
</tr>

<tr>
<td>STDEQ </td>
<td>80(50) </td>
<td align="right">8</td>
</tr>

<tr>
<td>LWTIM </td>
<td>88(58) </td>
<td align="right">4</td>
</tr>

<tr>
<td>PETIM</td>
<td>92(5C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>ZCPU</td>
<td>96(60) </td>
<td align="right">8</td>
</tr>
</table>

==User statistics entries (Type 9)==

User lines report on an individual user's activity. These statistics include:
<ul>
<li>Final (logout) and partial statistics</li>

<li>Since-last and ordered index statistics</li>

<li>Performance statistics</li>
</ul>

Each user line starts with the following statistics:
ST $$$ USERID='userid' ACCOUNT='account'


The subtype, in this case PERFORMANCE, follows USERID and ACCOUNT statistics:
ST $$$ USERID='userid' ACCOUNT='account'
PERFORMANCE=n


The format of user statistics entries is shown in the following table:
<table>
<caption>User statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'09'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:
<ul>
<li>X'00' = logout statistics</li>

<li>X'01' = since-last statistics</li>

<li>X'02' = partial statistics</li>

<li>X'04' = performance statistics</li>

<li>X'81' = since-last statistics including conflict statistics</li>

<li>X'41' = user restart forced out a since-last statistics record.</li>

<li>X'C1' = user restart forced out a since last statistics record which included conflict statistics</li>
</ul>
</td></tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>

Account:
<ul>
<li>Second argument of LOGON/LOGIN command</li>

<li>Default is user ID</li>
</ul>
</td>
</tr>

<tr>
<td>26(1A)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>User ID</td>
</tr>

<tr>
<td>36(24)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>Since-last ID =
See the [[#User since-last statistics|Activity types]] table where the possible activity types are listed.</td>
</tr>

<tr>
<td>40(28)</td>
<td align="right">1</td>
<td>Binary</td>
<td>IODEV number (added for MXI)</td>
</tr>

<tr>
<td>41(29)</td>
<td align="right">3</td>
<td>N/A</td>
<td>Unused</td>
</tr>

<tr>
<td>44(2C) to end of journal</td>
<td> </td>
<td>Binary</td>
<td>

Contents depend on subtypes, shown in:
<ul>
<li>[[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table</li>

<li>[[#Since-last in relation to final and partial statistics|Layout of user subtype X'01' and X'81' entries]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table</li>

<li>[[#Layout of performance statistics|Layout of user subtype X'04' entries]] table</li>
</ul>
</td> </tr>
</table>

==User final and partial statistics==

===Final (logout) statistics===

Final (logout) statistics, listed in the [[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table, summarize a user's activities since the last login. A LOGOUT statistics line, such as the following, is written after each logout if the parameter following ACCOUNT is not PARTIAL, LAST, or PERFORMANCE: 
yydddhhmmssnnnsssuuuuu ST $$$ ACCOUNT='NO ACCOUNT' SQRD=5 ...

<ul>
<li><var class="term">yyddd</var> is the year and Julian day.</li>

<li><var class="term">hhmmss</var> is the time of day in hours, minutes, and seconds.</li>

<li><var class="term">nnn</var> is a counter to distinguish lines produced in the same second.</li>

<li><var class="term">sss</var> is the number of the server currently handling the user. Leading zeros are suppressed.
</li>

<li><var class="term">uuuuu</var> is a 5-digit user number associated with the audit trail line. Leading zeros are suppressed.</li>
</ul>

In some cases, the account name appears as "NO USERID NO ACCOUNT". Statistics in this category are not chargeable to any one user and should be considered system overhead.

Final lines are recognized by the absence of an indicator for another type of line.

===Partial statistics===

Optional partial statistics, listed in the "Layout of user subtype X'00' and X'02' entries" table below, can be provided for a run up to a few minutes before a system failure that prevents normal termination and production of final user and system statistics. 

User partial statistics lines, such as the following, are made available for active users: 
ST $$$ ACCOUNT='NO ACCOUNT' PARTIAL=21 ...


Statistics accumulate either:
<ul>
<li>As long as the user is logged in</li>
</ul>

or
<ul>
<li>From the first terminal input to disconnection when a login is not required </li>
</ul>

Partial statistics are requested by setting the time interval, in minutes, between successive partial lines on User 0's parameter line with the <var>ACCTIM</var> parameter. <var>ACCTIM</var> must be nonzero. 

The contents of the statistics portion of the entry, starting at offset <code>40(28)</code>, depends upon the subtype of the entry. 

Partial statistics lines are indicated on the journal by the parameter <code>PARTIAL=n</code>, where <var class="term">n</var> is a counter from the beginning of the run. <code>PARTIAL=n</code> immediately follows the type parameter.

For subtypes X'00' (logout statistics), and X'02' (partial statistics), the layout of the remainder of the entry is shown in the following table. Each statistic in the table is: Length, 4; Data type, Binary. For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Layout of user subtype X'00' and X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>40(28)</td>
<td>CNCT</td>
</tr>

<tr>
<td>44(2C)</td>
<td>DKRD </td>
</tr>

<tr>
<td>48(30)</td>
<td>DKWR </td>
</tr>

<tr>
<td>52(34)</td>
<td>SQRD</td>
</tr>

<tr>
<td>56(38)</td>
<td>SQWR</td>
</tr>

<tr>
<td>60(3C)</td>
<td>SGMTI </td>
</tr>

<tr>
<td>64(40)</td>
<td>SGMTO </td>
</tr>

<tr>
<td>68(44)</td>
<td>SVRD</td>
</tr>

<tr>
<td>72(48)</td>
<td>SVWR </td>
</tr>

<tr>
<td>76(4C)</td>
<td>CPU </td>
</tr>

<tr>
<td>80(50)</td>
<td>REQ </td>
</tr>

<tr>
<td>84(54)</td>
<td>MOVE </td>
</tr>

<tr>
<td>88(58)</td>
<td>DUMP </td>
</tr>

<tr>
<td>92(5C)</td>
<td>REST </td>
</tr>

<tr>
<td>96(60)</td>
<td>SLIC </td>
</tr>

<tr>
<td>100(64)</td>
<td>AUDIT </td>
</tr>

<tr>
<td>104(68) </td>
<td>WAIT </td>
</tr>

<tr>
<td>108(6C)</td>
<td>FBWT </td>
</tr>

<tr>
<td>112(70)</td>
<td>UDD </td>
</tr>

<tr>
<td>116(74)</td>
<td>RECADD </td>
</tr>

<tr>
<td>120(78)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>124(7C)</td>
<td>BADD </td>
</tr>

<tr>
<td>128(80)</td>
<td>BDEL</td>
</tr>

<tr>
<td>132(84)</td>
<td>BCHG </td>
</tr>

<tr>
<td>136(88)</td>
<td>IXADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>FINDS </td>
</tr>

<tr>
<td>148(94)</td>
<td>SORTS</td>
</tr>

<tr>
<td>152(98)</td>
<td>RECDS </td>
</tr>

<tr>
<td>156(9C)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>160(A0)</td>
<td>DKAR </td>
</tr>

<tr>
<td>164(A4)</td>
<td>DKPR </td>
</tr>

<tr>
<td>168(A8)</td>
<td>DKRR </td>
</tr>

<tr>
<td>172(AC)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>UPDTTIME(MS) </td>
</tr>

<tr>
<td>184(B8)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>188(BC)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>192(C0)</td>
<td>SMPLS </td>
</tr>

<tr>
<td>196(C4)</td>
<td>RUNG </td>
</tr>

<tr>
<td>200(C8)</td>
<td>REDY</td>
</tr>

<tr>
<td>204(CC)</td>
<td>BLKI</td>
</tr>

<tr>
<td>208(D0)</td>
<td>WTSV </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BLKO </td>
</tr>

<tr>
<td>216(D8)</td>
<td>SWPG </td>
</tr>

<tr>
<td>220(DC)</td>
<td>PCPU </td>
</tr>

<tr>
<td>224(E0)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>228(E4)</td>
<td>BXCHNG </td>
</tr>

<tr>
<td>232(E8)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>236(EC)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>240(F0)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>244(F4)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>248(F8)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>252(FC)</td>
<td>BXRFND</td>
</tr>

<tr>
<td>256(100)</td>
<td>BXFREE </td>
</tr>

<tr>
<td>260(104)</td>
<td>STCPU </td>
</tr>

<tr>
<td>264(108)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>268(10C)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>272(110)</td>
<td>SCREENS </td>
</tr>

<tr>
<td>276(114)</td>
<td>SVPAGES </td>
</tr>

<tr>
<td>280(118)</td>
<td>PBRSFLT </td>
</tr>

<tr>
<td>284(11C)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>292(124)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQBYTOU</td>
</tr>

<tr>
<td>308((134)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>380(17C)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>384(180)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>388(184)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>392(188)</td>
<td>Spare</td>
</tr>

<tr>
<td>396(18C) </td>
<td>MPR (V7.7 onwards)</td>
</tr>

<tr>
<td>400(190) </td>
<td>MBO (V7.7 onwards)</td>
</tr>

<tr>
<td>404(194)</td>
<td>DEV#</td>
</tr>

<tr>
<td>408(198)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>412(19C)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>CCATDIFF</td>
</tr>

</table>

==User since-last statistics==

===Since-last statistics===

Statistics are kept for each SOUL request, host language interface call, and a number of <var class="product">Model 204</var> system commands. When each request or command completes, a since-last statistics line is written. The line includes the <var>ACCOUNT</var> parameter at the beginning, followed by the <var>IODEV</var> parameter and the <var>LAST</var> parameter.

Several <var>MONITOR</var> commands produce displays containing the user's last or current activity in the <code>FUNC</code> column. When this activity completes, statistics are also written to CCAAUDIT and the activity is described in ST lines as <code>LAST='activity'</code>.

====Syntax====
ST $$$ USERID='userid' ACCOUNT='accountname' IODEV='devicetype' LAST='acty'

Where:

<var class="term">acty</var> can be one of the following: 
<table>
<caption>Activity types</caption>
<tr class="head">
<th>Option</th>
<th>Meaning</th>
</tr>

<tr>
<td>BLDR</td>
<td><var>BLDREUSE</var> command</td>
</tr>

<tr>
<td>BLDX </td>
<td><var>Z</var> command</td>
</tr>

<tr>
<td>CMPL </td>
<td>Compilation of a SOUL request</td>
</tr>

<tr>
<td>CPTB</td>
<td><var>COMPACTB</var> command</td>
</tr>

<tr>
<td>CPTE</td>
<td><var>COMPACTE</var> command</td>
</tr>

<tr>
<td>CPYP </td>
<td><var>COPY PROCEDURE</var> command</td>
</tr>

<tr>
<td>CREA</td>
<td><var>CREATE FILE filename</var> command</td>
</tr>

<tr>
<td>DISP </td>
<td><var>DISPLAY PROCEDURE</var> command</td>
</tr>

<tr>
<td>DUMP </td>
<td><var>DUMP file</var> command</td>
</tr>

<tr>
<td>EDIT </td>
<td>Editing a request</td>
</tr>

<tr>
<td>EVAL </td>
<td>Evaluation of a SOUL request</td>
</tr>

<tr>
<td>EXEC </td>
<td>Execution of an SQL request</td>
</tr>

<tr>
<td>FLDC </td>
<td>Compilation of a FLOD procedure</td>
</tr>

<tr>
<td>FLDE </td>
<td>Evaluation of a FLOD procedure</td>
</tr>

<tr>
<td>IMPC </td>
<td>Implied commit</td>
</tr>

<tr>
<td>INCR</td>
<td><var>IN FILE filename INCREASE DATASETS</var> command</td>
</tr>

<tr>
<td>INIT</td>
<td><var>IN FILE filename INITIALIZE</var> command</td>
</tr>

<tr>
<td>LOAD </td>
<td>Loading a precompiled (ASPY) procedure</td>
</tr>

<tr>
<td>PREP </td>
<td>Compilation of an SQL request</td>
</tr>

<tr>
<td>REST </td>
<td><var>RESTORE file</var> command</td>
</tr>
</table>

===Since-last highwater marks===

The since-last statistics include highwater marks of various work tables used by SOUL requests. Values are reported in terms of the units in which each table is allocated. For example, QTBL is allocated in units of 16 bytes.

===Since-last in relation to final and partial statistics===

Many since-last statistics, such as CNCT, CPU, and DKRD, are also reported on user final and partial statistics lines. (See the [[#Description of statistics|Statistics with descriptions]] table.) The statistics on these lines are roughly equal to the sum of all of the preceding since-last statistics for the user.
Because since-last statistics are not maintained for every <var class="product">Model 204</var> command, final statistics are generally larger.

For subtype X'01' (since-last statistics), the layout of the remainder of the entry begins as shown in the following table.
For the meaning of each statistic in this table and in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table, see the [[#Description of statistics|Statistics with descriptions]] table.
The layout of the end of the entry depends on whether you chose to collect conflict statistics:
<ul>
<li>If you do not collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table.</li>

<li>If you do collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table. When you collect conflict statistics, the subtype changes to X'81'. </li>
</ul>
<table>
<caption>Layout of user subtype X'01' and X'81' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 44(2C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 48(30)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 52(34)</td>
<td>QTBL </td>
</tr>

<tr>
<td> 56(38)</td>
<td>STBL </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>TTBL </td>
</tr>

<tr>
<td> 64(40)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 68(44)</td>
<td>PDL</td>
</tr>

<tr>
<td> 72(48)</td>
<td>FTBL </td>
</tr>

<tr>
<td> 76(4C)</td>
<td>XTBL </td>
</tr>

<tr>
<td> 80(50)</td>
<td>ITBL </td>
</tr>

<tr>
<td> 84(54)</td>
<td>FSCB </td>
</tr>

<tr>
<td> 88(58)</td>
<td>OUTPB </td>
</tr>

<tr>
<td> 92(5C) </td>
<td>HEAP </td>
</tr>

<tr>
<td> 96(60)</td>
<td>SQLI </td>
</tr>

<tr>
<td>100(64)</td>
<td>SQLO</td>
</tr>

<tr>
<td>104(68)</td>
<td>CNCT</td>
</tr>

<tr>
<td>108(6C)</td>
<td>CPU </td>
</tr>

<tr>
<td>112(70)</td>
<td>DKRD </td>
</tr>

<tr>
<td>116(74)</td>
<td>DKWR</td>
</tr>

<tr>
<td>120(78)</td>
<td>UDD </td>
</tr>

<tr>
<td>124(7C)</td>
<td>OUT </td>
</tr>

<tr>
<td>128(80)</td>
<td>SLIC</td>
</tr>

<tr>
<td>132(84)</td>
<td>IN </td>
</tr>

<tr>
<td>136(88)</td>
<td>RECADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>BADD </td>
</tr>

<tr>
<td>148(94)</td>
<td>BDEL </td>
</tr>

<tr>
<td>152(98)</td>
<td>BCHG </td>
</tr>

<tr>
<td>156(9C)</td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>164(A4)</td>
<td>FINDS </td>
</tr>

<tr>
<td>168(A8)</td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC)</td>
<td>RECDS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>PCPU </td>
</tr>

<tr>
<td>184(B8)</td>
<td>RQTM </td>
</tr>

<tr>
<td>188(BC)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>192(CO)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td>196(C4)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>200(C8)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>204(CC)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>208(DO)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>216(D8)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 220(DC)</td>
<td>BXFREE </td>
</tr>

<tr>
<td> 224(E0)</td>
<td>STCPU </td>
</tr>

<tr>
<td> 228(E4)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 232(E8)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 236(EC)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>240(F0) </td>
<td>SVRD </td>
</tr>

<tr>
<td>244(F4)</td>
<td>SVWR</td>
</tr>

<tr>
<td>248(F8) </td>
<td>DKPR </td>
</tr>

<tr>
<td>252(FC)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>256(100)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>260(104)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>264(108)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>268(10C)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>272(110)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>276(114)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>280(118)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>284(11C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>292(124)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>336(150)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>340(154)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>372(174)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>376(178)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>380(17C)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>384(180)</td>
<td>OBJSWAP</td>
</tr>

<tr>
<td>388()184</td>
<td>SIRIUS02</td>
</tr>

<tr>
<td>392(188)</td>
<td>SIRIUS03</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>400(190) </td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>404(194) </td>
<td>CCATDIFF</td>
</tr>

<tr>
<td>408(198) </td>
<td>CCATDIFH</td>
</tr>
</table>

===Conflict statistics===

Whether you are collecting conflict statistics determines the layout at the end of the entry. Two of the conflict statistics keep track of critical file-resource conflicts, and two keep track of record-locking conflicts. Whether these statistics are collected and journaled depends on settings of the parameters <var>[[CFRLOOK parameter|CFRLOOK]]</var> and <var>[[CFRJRNL parameter|CFRJRNL]]</var>.


These statistics are not displayed with the output of the <code>MONITOR SL</code> command. Instead, you can view them (with all the other since-last statistics) by issuing the <var>MONITOR</var> command with the keyword <var>CONFLICT</var>.

The remainder of the entry depends on the setting of <var>CFRJRNL</var>.

The following table shows the layout when <var>CFRJRNL</var> is set to 0: 
<table>
<caption>Layout of user subtype X'01' entries (CFRJRNL=0)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>422(1A6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>430(1AE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>431(1AF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>

The following table shows the layout when <var>CFRJRNL</var> is set to 1. It reflects the change in offset and that the user subtypes are now X'81' entries. 
<table>
<caption>Layout of user subtype X'81' entries (CFRJRNL=1)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Entry type</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKCFRE stastic</td>
</tr>

<tr>
<td>416(1A0)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKRLK statistic</td>
</tr>

<tr>
<td>420(1A4)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTCFR statistic</td>
</tr>

<tr>
<td>424(1A8)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTRLK statistic</td>
</tr>

<tr>
<td>428(1AC)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>438(1B6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>446(1BE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>447(1BF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>
Note:
The conflict statistics, BLKCFRE, BLKRLK, WTCFR, and WTRLK, are inexact. Although a user might at times conflict with multiple other users, only the first conflict encountered is counted.

==User performance statistics==

Optional performance statistics lines provide information about the operation of the <var class="product">Model 204</var> scheduler during a short period of time. Information about the length of the scheduler queues, the number of active users and servers, and the queue distribution for each user, is obtained by sampling. 

A performance line starts with:
ST $$$ USERID='userid' ACCOUNT='accountname'
PERFORMANCE=n


===Parameters to activate performance statistics===

To request performance statistics, specify the number of samples to take between performance statistics lines (<var>RPTCNT</var> parameter) and the time interval between samples (<var>SMPLTIM</var> parameter) on User 0's parameter line. When you request scheduler and server performance data (<var>SMPLTIM</var> parameter), an asynchronous operating system task, called the performance subtask, is created. Both <var>RPTCNT</var> and <var>SMPLTIM</var> must be nonzero.

===Sampling===

The performance subtask spends most of its time in a wait state. Every <var>SMPLTIM</var> milliseconds, it records the current state of the system. Data from the most recent sample is available at an Online terminal through the <var>MONITOR</var> command, described in [[Controlling system operations (CCAIN)#ONLINE monitoring|ONLINE monitoring]]. 

The number of samples taken during a run (<var>RPTCNT</var>), times the number of users in the run (<var>NUSERS</var>), must be less than 4.2 million. In large systems that run for a very long period of time, the time interval between samples cannot be extremely short. If the limit is exceeded, an OC1 interrupt occurs when the SMPLS statistic value is calculated during the printing of the system statistics, either a performance or final line.

====Layout of performance statistics====

For subtype X'04' (performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. For the description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>Layout of user subtype X'04' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 40(28)</td>
<td>SMPLS </td>
</tr>

<tr>
<td> 44(2C)</td>
<td>RUNG</td>
</tr>

<tr>
<td> 48(30)</td>
<td>REDY </td>
</tr>

<tr>
<td> 52(34)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 56(38)</td>
<td>WTSV </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 64(40)</td>
<td>SWPG </td>
</tr>
</table>

==File statistics entries (Type 10)==

File statistics, summarized in the [[#File statistics journal records layout|File statistics entry formats]] table, are kept for every file opened during a run, including CCAGRP, CCASYS, and CCATEMP. The activity of a file for all users is summarized from the time the file is first opened until the last user issues a <var>CLOSE</var> command. The statistics appear after the last <var>CLOSE</var> command in lines that follow the date and time information (yyyydddhhmmssnnnsssuuuuu) with: 
ST $$$ FILE='filename'


System termination writes file statistics for each file still open at the end of the run.

===Final statistics===

A final statistics line similar to the following is produced when the last user of a file closes the file: 
ST $$$ FILE='PAYABLES'DKRD=25 DKRD=25 DKWR=15 REQ=3 RECADD=6 ...


===Partial statistics===

File partial statistics lines similar to the following are furnished for each open file: 
ST $$$ FILE='PAYABLES'PARTIAL=3 ...


===File statistics journal records layout===

File statistics entries have the format shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>File statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Type of entry</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'0A'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Subtype indicator:
X'00' = file close
X'01' = partial</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td align="right"> 4</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td align="right"> 8</td>
<td> EBCDIC</td>
<td>File name</td>
</tr>

<tr>
<td> 24(18)</td>
<td align="right"> 2</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>
</table>

The following table lists the file statistics and the decimal(hexidecimal) offset. These statistics are data type Binary and eight bytes long.
<table>
<caption>File statistics</caption>
<tr class="head">
<th>File statistic </th>
<th>Offset dec(hex) </th>
</tr>

<tr>
<td>DKRD </td>
<td>26(1A) </td>
</tr>

<tr>
<td>DKWR </td>
<td>34(22) </td>
</tr>

<tr>
<td>REQ </td>
<td>42(2A) </td>
</tr>

<tr>
<td>RETRYA </td>
<td>50(32) </td>
</tr>

<tr>
<td>RETRYC </td>
<td>58(3A) </td>
</tr>

<tr>
<td>DUPDTS </td>
<td>66(42) </td>
</tr>

<tr>
<td>RECADD </td>
<td>74(4A) </td>
</tr>

<tr>
<td>RECDEL </td>
<td>82(52) </td>
</tr>

<tr>
<td>BADD </td>
<td>90(5A) </td>
</tr>

<tr>
<td>BDEL </td>
<td>98(62) </td>
</tr>

<tr>
<td>BCHG </td>
<td>106(6A) </td>
</tr>

<tr>
<td>IXADD </td>
<td>114(72) </td>
</tr>

<tr>
<td>IXDEL </td>
<td>122(7A) </td>
</tr>

<tr>
<td>DIRRCD </td>
<td>130(82) </td>
</tr>

<tr>
<td>BXCHNG </td>
<td>138(8A) </td>
</tr>

<tr>
<td>BXDELE </td>
<td>146(92) </td>
</tr>

<tr>
<td>BXNEXT </td>
<td>154(9A) </td>
</tr>

<tr>
<td>BXFIND </td>
<td>162(A2) </td>
</tr>

<tr>
<td>BXINSE </td>
<td>170(AA) </td>
</tr>

<tr>
<td>BXSPLI </td>
<td>178(B2) </td>
</tr>

<tr>
<td>BXRFND </td>
<td>186(BA) </td>
</tr>

<tr>
<td>BXFREE </td>
<td>194(C2) </td>
</tr>

<tr>
<td>UPDTTIME </td>
<td>202(CA) </td>
</tr>

<tr>
<td>PNDGTIME </td>
<td>210(D2) </td>
</tr>

<tr>
<td>DKUPTIME </td>
<td>218(DA) </td>
</tr>

<tr>
<td>COMMITS </td>
<td>226(E2) </td>
</tr>

<tr>
<td>BACKOUTS </td>
<td>234(EA) </td>
</tr>
</table>

==Text entries (Type 11, Type 13)==

Type 11 (X'0B') and Type 13 (X'0D') entries record most of the actual text of the audit trail.

===Noncontinued text entries, Type 11 (X'0B')===

Each Type 11 journal entry corresponds to one logical entry in the audit trail, even though it might generate more than one line of physical output in the audit trail. 

The format of a Type 11 entry is shown in the following table: 
<table>
<caption>Noncontinued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'0B'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Subtype indicator:

X'01' = LI line

X'02' = LP line

X'03' = LR line

X'04' = CI line

X'05' = QT line

X'08' = CP line

X'10' = OI line

X'20' = OO line

X'40' = LS line

X'80' = CS line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>

===Possibly continued text entries, Type 13 (X'0D')===

Each Type 13 journal entry corresponds to one, or part of one, logical entry in the audit trail. See the [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Example|Types of audit trail lines]] table for a definition of the line types.

The format of a Type 13 entry is shown in the following table: 
<table>
<caption>Possibly continued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0D'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = US line

X'02' = XX line

X'04' = RK line

X'08' = AD line

X'10' = MS line

X'20' = ER line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td> 14(0E)</td>
<td> 2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td> 16(10)</td>
<td> Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>
Note:
Subtype indicator X'80' summed with any subtype means continuation into the next entry. 

==Initialization entries, Type 12 (X'0C')==

One Type 12 journal entry is written as the first nonheader entry in the journal during initialization. It contains basic information about the run being initialized.

The format of a Type 12 entry is shown in the following table:
<table>
<caption>Initialization entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'001A'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0C'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> —</td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 8</td>
<td> EBCDIC</td>
<td>Version ID (for example, 4.2.0G)</td>
</tr>

<tr>
<td> 20(14)</td>
<td> 2</td>
<td> Binary</td>
<td>Spare for the run</td>
</tr>

<tr>
<td> 22(16)</td>
<td> 4</td>
<td> EBCDIC</td>
<td>SMF ID (SYSID parameter) </td>
</tr>
</table>

==Time-stamp entries, Type 14 (X'0E')==

Type 14 entries are used to force time-stamps to the journal. 

The format of a Type 14 entry is shown in the following table: 
<table>
<caption>Time-stamp entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td>2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0E'</td>
</tr>

<tr>
<td>3(3)</td>
<td> 1</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td>4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Merged journal bracketing entries (Type 15)==

Type 15 entries appear only in the output of the MERGEJ utility. See [[System and media recovery#Using the MERGEJ utility|Using the MERGEJ utility]]. 

The format of a Type 15 entry is shown in the following table:
<table>
<caption>Merged journal bracketing entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'002E'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0F'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = begin bracket

X'02' = end bracket
</td>
</tr>

<tr>
<td> 4(4)</td>
<td>12(0C)</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td>2(2)</td>
<td> Binary </td>
<td>Number of journals merged together</td>
</tr>

<tr>
<td> 18(12)</td>
<td>28(1C)</td>
<td>EBCDIC</td>
<td>Text:
<ul>
<li>For subtype X'01' = BEGINNING OF MERGED JOURNAL</li>

<li>For subtype X'02' = END OF MERGED JOURNAL</li>
</ul>
</td></tr>
</table>

==System Management Facilities==

You can write certain statistics to the System Management Facilities (SMF) data set by: 
<ul>
<li>Setting the <var>[[SMFSLRN parameter|SMFSLRN]]</var> and <var>[[SMFLORN parameter|SMFLORN]]</var> parameters on the User 0 command line to activate the SMF feature. (z/OS and z/VM)</li>

<li>Modifying the program that processes the SMF data set to handle the records written by <var class="product">Model 204</var>. (z/VM only)</li>
</ul>

See the [[#z/VM requirements|z/VM requirements]] and the the [[#z/OS requirements|z/OS requirements]] sections for details.

Since-last statistics or logout statistics can be written concurrently with statistics that are written to the journal. Logout statistics are more complete than since-last statistics. Many more since-last records than logout records are usually written. 

If the operating system crashes before a user logs out, the SMF data set has a since-last record for every request run, but no logout record. 

File and system statistics cannot be written to the SMF data set.

During system initialization, <var class="product">Model 204</var> issues a message reporting the SMF system ID, the run's job name, the step name, and the JES ID. For operating systems other than z/OS, the JES ID is blank.

===z/VM requirements===

In the CMS interface to <var class="product">Model 204</var>, you can incorporate a user-written accounting exit that invokes the ACCTEXIT routine to process each statistics record as it is written. The following considerations apply:
<ul>
<li>Take care to preserve the CMS environment in which <var class="product">Model 204</var> is running. Do not change the contents of general registers 13 and 14.</li>

<li>You must specify the <var>SMFLORN</var> and/or <var>SMFSLRN</var> parameters on User 0's parameter line to activate accounting record production.</li>

<li>TEXT file for the ACCTEXIT module must be available on an accessed disk when generating M204CMS using M204GEN. For complete installation procedures, see the <var class="book">Rocket Model 204 z/VM Installation Guide</var>.</li>
</ul>

===z/OS requirements===

To write since-last SMF records in a z/OS environment, activate the SMF feature. 

To activate SMF, set the following parameters on User 0's parameter line: 
<ul>
<li>SMFSLRN — SMF record number for since-last records</li>

<li>SMFLORN — SMF record number for logout records </li>
</ul>

The following considerations apply:
<ul>
<li>Since-last SMF records are written only if the SMFSLRN parameter is set to a non-zero value at the beginning of the run.</li>

<li>Logout SMF records are written only if the SMFLORN parameter is set to a non-zero value at the beginning of the run.</li>

<li>If both parameters are set, each type of record is written.</li>
</ul>

SMF record numbers, which identify the record type to the programs that process the SMF data set, are written as part of the header of the SMF records. The record numbers must be between 128 and 255.

See the "System Management Facility record layout and statistics" section, which follows.

==System Management Facility record layout and statistics==

===SMF logout record layout===

The following table shows the basic format of the <var class="product">Model 204</var> SMF logout record: 
<table>
<caption>Basic format of Model 204 SMF logout record</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length</th>
<th> Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td>2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td>4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td>5(5)</td>
<td> 1</td>
<td>Record number (<var>SMFSLRN</var> or <var>SMFLORN</var>)</td>
</tr>

<tr>
<td>6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td> 1</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: x'4C'
For V7.7: x'4D'
For V7.8: x'4E'
</td>
</tr>

<tr>
<td>58(3A)</td>
<td> 2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable
4-character field retrieved from the SMF control area.

The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.
</li>
</ul>

====Offsets for SMF logout record statistics====

The following table shows the layout of SMF logout record statistics. Each statistic in the table is: Length, 4 (bytes); data type, Binary.
This record has the same statistics in the same order as the CCAJRNL logout record, only the offsets are different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]] table.
<table>
<caption>Offset location of SMF logout record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>60(3C) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 64(40) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 68(44) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 72(48) </td>
<td>SQRD</td>
</tr>

<tr>
<td> 76(4C) </td>
<td>SQWR</td>
</tr>

<tr>
<td> 80(50) </td>
<td>SGMTI</td>
</tr>

<tr>
<td> 84(54) </td>
<td>SGMTO</td>
</tr>

<tr>
<td> 88(58) </td>
<td>SVRD</td>
</tr>

<tr>
<td> 92(5C) </td>
<td>SVWR</td>
</tr>

<tr>
<td> 96(60) </td>
<td>CPU</td>
</tr>

<tr>
<td>100(64) </td>
<td>REQ</td>
</tr>

<tr>
<td>104(68) </td>
<td>MOVE</td>
</tr>

<tr>
<td>108(6C) </td>
<td>DUMP</td>
</tr>

<tr>
<td>112(70) </td>
<td>REST</td>
</tr>

<tr>
<td>116(74) </td>
<td>SLIC</td>
</tr>

<tr>
<td>120(78) </td>
<td>AUDIT</td>
</tr>

<tr>
<td>124(7C) </td>
<td>WAIT</td>
</tr>

<tr>
<td>128(80) </td>
<td>FBWT</td>
</tr>

<tr>
<td>132(84) </td>
<td>UDD</td>
</tr>

<tr>
<td>136(88) </td>
<td>RECADD</td>
</tr>

<tr>
<td>140(8C) </td>
<td>RECDEL</td>
</tr>

<tr>
<td>144(90) </td>
<td>BADD</td>
</tr>

<tr>
<td>148(94) </td>
<td>BDEL</td>
</tr>

<tr>
<td>152(98) </td>
<td>BCHG</td>
</tr>

<tr>
<td>156(9C) </td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td>164(A4) </td>
<td>FINDS</td>
</tr>

<tr>
<td>168(A8) </td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC) </td>
<td>RECDS</td>
</tr>

<tr>
<td>176(B0) </td>
<td>STRECDS</td>
</tr>

<tr>
<td>180(B4) </td>
<td>DKAR</td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKPR</td>
</tr>

<tr>
<td>188(BC) </td>
<td>DKRR</td>
</tr>

<tr>
<td>192(C0) </td>
<td>COMMITS</td>
</tr>

<tr>
<td>196(C4) </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>200(C8) </td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>204(CC) </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>208(D0) </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>212(D4) </td>
<td>SMPLS</td>
</tr>

<tr>
<td>216(D8) </td>
<td>RUNG</td>
</tr>

<tr>
<td>220(DC) </td>
<td>REDY</td>
</tr>

<tr>
<td>224(E0) </td>
<td>BLKI</td>
</tr>

<tr>
<td>228(E4) </td>
<td>WTSV</td>
</tr>

<tr>
<td>232(E8) </td>
<td>BLKO</td>
</tr>

<tr>
<td>236(EC) </td>
<td>SWPG</td>
</tr>

<tr>
<td>240(F0) </td>
<td>PCPU</td>
</tr>

<tr>
<td>244(F4) </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>248(F8) </td>
<td>BXCHNG</td>
</tr>

<tr>
<td>252(FC) </td>
<td>BXDELE</td>
</tr>

<tr>
<td>256(100) </td>
<td>BXNEXT</td>
</tr>

<tr>
<td>260(104)</td>
<td>BXFIND</td>
</tr>

<tr>
<td>264(108)</td>
<td>BXINSE</td>
</tr>

<tr>
<td>268(10C)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td>272(110)</td>
<td>BXFND</td>
</tr>

<tr>
<td>276(114)</td>
<td>BXFREE</td>
</tr>

<tr>
<td>280(118)</td>
<td>STCPU</td>
</tr>

<tr>
<td>284(11C)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>288(120)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>292(124)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>296(128)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>300(12C)</td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>312(138)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>344(158)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>348(15C)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>352(160)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>380(17C)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>384(180)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>388(184)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>392(188)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>400(190)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>404(194)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>408(198)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>412(19C)</td>
<td>Spare </td>
</tr>

<tr>
<td>416(1A0)</td>
<td>Spare</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>Spare</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>Spare</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>Spare</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>Spare</td>
</tr>
</table>

===SMF since-last record layout===

The following table shows the basic format of since-last <var class="product">Model 204</var> SMF records. 
<table>
<caption>Since-last record basic format</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length (bytes)</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td> 5(5)</td>
<td> 1</td>
<td>Record number (SMFSLRN)</td>
</tr>

<tr>
<td> 6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td>1</td>
<td>SMFSLTYP - X'01' if CRFJRNL=1 (conflict counters present)

SMFSLTYP - X'00' if CRFJRNL=0 (conflict counters not present)
</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: <code>x'4C'</code>
For V7.7: <code>x'4D'</code>
For V7.8: <code>x'4E'</code>
</td>
</tr>

<tr>
<td>58(3A)</td>
<td>2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> 4</td>
<td>Since-last type (EVAL CMPL DUMP REST...)</td>
</tr>

<tr>
<td>64(40)</td>
<td> 8</td>
<td>File name</td>
</tr>

<tr>
<td>72(48)</td>
<td>10</td>
<td>Since-last subsystem name</td>
</tr>

<tr>
<td>82(52)</td>
<td>40</td>
<td>Since-last procedure name</td>
</tr>

<tr>
<td>122(7A)</td>
<td>2</td>
<td>Reserved two bytes</td>
</tr>

<tr>
<td>124(7C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable 4-character field retrieved from the SMF control area.</li>

<li>The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.</li>
</ul>

====Offsets for SMF since-last record statistics====

The following table shows the layout of SMF since-last record statistics. Each statistic in the table is: Length, 4 (bytes); Data type, Binary.
This record has the same statistics in the same order as the CCAJRNL user since-last records; only the offsets are
different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]]
table. 
<table>
<caption>SMF since-last record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td> 124(7C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 128(80)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 132(84)</td>
<td>QTBL</td>
</tr>

<tr>
<td> 136(88) </td>
<td>STBL</td>
</tr>

<tr>
<td> 140(8C)</td>
<td>TTBL</td>
</tr>

<tr>
<td> 144(90)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 148(94)</td>
<td>PDL</td>
</tr>

<tr>
<td> 152(98)</td>
<td>FTBL</td>
</tr>

<tr>
<td> 156(9C)</td>
<td>XTBL</td>
</tr>

<tr>
<td> 160(A0)</td>
<td>ITBL</td>
</tr>

<tr>
<td> 164(A4)</td>
<td>FSCB</td>
</tr>

<tr>
<td> 168(A8)</td>
<td>OUTPB</td>
</tr>

<tr>
<td> 172(AC) </td>
<td>HEAP</td>
</tr>

<tr>
<td> 176(B0) </td>
<td>SQLI</td>
</tr>

<tr>
<td> 180(B4) </td>
<td>SQLO</td>
</tr>

<tr>
<td> 184(B8) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 188(BC) </td>
<td>CPU</td>
</tr>

<tr>
<td> 192(C0) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 196(C4) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 200(C8) </td>
<td>UDD</td>
</tr>

<tr>
<td> 204(CC) </td>
<td>OUT</td>
</tr>

<tr>
<td> 208(D0) </td>
<td>SLIC</td>
</tr>

<tr>
<td> 212(D4) </td>
<td>IN</td>
</tr>

<tr>
<td> 216(D8) </td>
<td>RECADD</td>
</tr>

<tr>
<td> 220(DC) </td>
<td>RECDEL</td>
</tr>

<tr>
<td> 224(E0) </td>
<td>BADD</td>
</tr>

<tr>
<td> 228(E4) </td>
<td>BDEL</td>
</tr>

<tr>
<td> 232(E8) </td>
<td>BCHG</td>
</tr>

<tr>
<td> 236(EC) </td>
<td>IXADD</td>
</tr>

<tr>
<td> 240(F0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td> 244(F4) </td>
<td>FINDS</td>
</tr>

<tr>
<td> 248(F8) </td>
<td>SORT</td>
</tr>

<tr>
<td> 252(FC) </td>
<td>RECDS</td>
</tr>

<tr>
<td> 256(100)</td>
<td>STRECDS</td>
</tr>

<tr>
<td> 260(104)</td>
<td>PCPU</td>
</tr>

<tr>
<td> 264(108)</td>
<td>RQTM</td>
</tr>

<tr>
<td> 268(10C)</td>
<td>DIRRCD</td>
</tr>

<tr>
<td> 272(110)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td> 276(114)</td>
<td>BXDELE</td>
</tr>

<tr>
<td> 280(118)</td>
<td>BXNEXT</td>
</tr>

<tr>
<td> 284(11C)</td>
<td>BXFIND</td>
</tr>

<tr>
<td> 288(120)</td>
<td>BXINSE</td>
</tr>

<tr>
<td> 292(124)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td> 296(128)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 300(12C)</td>
<td>BXFREE</td>
</tr>

<tr>
<td> 304(130)</td>
<td>STCPU</td>
</tr>

<tr>
<td> 308(134)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 312(138)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 316(13C)</td>
<td>SCREENS</td>
</tr>

<tr>
<td> 320(140)</td>
<td>SVRD</td>
</tr>

<tr>
<td> 324(144)</td>
<td>SVWR</td>
</tr>

<tr>
<td> 328(148)</td>
<td>DKPR</td>
</tr>

<tr>
<td> 332(14C)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>336(150)</td>
<td>COMMITS</td>
</tr>

<tr>
<td>340(154)</td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>344(158)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>348(15C)</td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>352(160)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>368(170)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>372(174)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>376(178)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>380(17C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>384(180)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>388(184)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>392(188)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>396(18C)</td>
<td>MAPICNT</td>
</tr>

<tr>
<td>400(190)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>404(194)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>408(198)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>412(19C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>444(1BC)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>448(1C0)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>452(1C4)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>456(1C8)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>460(1CC)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>464(1D0)</td>
<td>Sirius</td>
</tr>

<tr>
<td>468(1D4)</td>
<td>Sirius</td>
</tr>

<tr>
<td>472(1D8)</td>
<td>Sirius</td>
</tr>

<tr>
<td>476(1DC)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>480(1E0)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>484(1E4)</td>
<td>Spare</td>
</tr>

<tr>
<td>488(1E8)</td>
<td>Spare</td>
</tr>
</table>

The following table lists the conflict statistics, if <code>CFRJRNL=1</code>:

<table>
<caption>Conflict statistics, if CFRJRNL=1</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td>492(1EC)</td>
<td>BLKCFRE</td>
</tr>

<tr>
<td>496(1F0)</td>
<td>BLKRLK</td>
</tr>

<tr>
<td>500(1F4)</td>
<td>WTCFR</td>
</tr>

<tr>
<td>504(1F8)</td>
<td>WTRLK</td>
</tr>
</table>

[[Category:System management]]
[[Category:System-level capabilities of Model 204]]

System statistics displayed in SirMon

2024-10-09T22:52:11Z

Goff: Fix spelling mistake

System statistics provide information about overall performance and
status of the Online system.
Some identically named statistics might also be available on the user, file, subsystem, or task level.
Generally, an identically named statistic for a different context will have a similar meaning to the system context.

In RKWeb, you can display all the system statistics and view their descriptions by selecting <code>Performance > Custom</code> from the <code>Monitor</code> tab, then clicking the System radio button.

<table class="thJustBold">
<tr><th>APSYLD</th>
<td>APSY loads (rate or total).</td></tr>

<tr><th>APSYLDD</th>
<td>APSY loads from dataspace (rate or total).</td></tr>

<tr><th>AUDIT</th>
<td>Audit lines written (rate or total).</td></tr>

<tr><th>BACKOUTS</th>
<td>Number of backed out update units (rate or total).</td></tr>

<tr><th>BADD</th>
<td>Fields added to table B (rate or total).</td></tr>

<tr><th>BCHG</th>
<td>Fields changed in place in table B (rate or total).</td></tr>

<tr><th>BDEL</th>
<td>Fields deleted from table B (rate or total).</td></tr>

<tr><th>BLKI</th>
<td>Performance statistic: Average number of users in a server and waiting for an event to occur. Taken from latest report printed by the performance subtask. BLKI includes PST activity.</td></tr>

<tr><th>BLKIA</th>
<td>Performance statistic: same as BLKI but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>BLKIT</th>
<td>Performance statistic: same as BLKI but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>BLKO</th>
<td>Performance statistic: Average number of users swapped out and waiting for an event to occur. Taken from latest report printed by the performance subtask.</td></tr>

<tr><th>BLKOA</th>
<td>Performance statistic: same as BLKO but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>BLKOT</th>
<td>Performance statistic: same as BLKO but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>BUFF.</th>
<td>Total number of pages in the disk buffer pool currently occupied by pages from all tables in all database files. Equal to <code>BUFFF + BUFFA + BUFFB + BUFFC + BUFFD + BUFFE + BUFFX + BUFFT</code>.</td></tr>

<tr><th>BUFF.G</th>
<td>Total number of above-the-bar pages in the disk buffer pool occupied by pages from all tables in all database files.
Equal to <code>BUFFFG + BUFFAG + BUFFBG + BUFFCG + BUFFDG + BUFFEG + BUFFXG + BUFFTG</code>.
Above-the-bar buffers reside at virtual addresses above two gigabytes and are only used when the <var>[[NUMBUFG parameter|NUMBUFG]]</var> parameter is set to a non-zero value under Model 204 V6R2 or later.</td></tr>

<tr><th>BUFF.L</th>
<td>Total number of below-the-bar pages in the disk buffer pool occupied by pages from all tables in all database files. Equal to <code>BUFFFL + BUFFAL + BUFFBL + BUFFCL + BUFFDL + BUFFEL + BUFFXL + BUFFTL</code>.
Below-the-bar buffers reside at virtual addresses below two gigabytes. BUFF.L has the same value as BUFF. unless the NUMBUFG parameter is set to a non-zero value under Model 204 V6R2 or later.</td></tr>

<tr><th>BUFFA</th>
<td>Total number of pages in the disk buffer pool currently occupied by table A pages from all database files.</td></tr>

<tr><th>BUFFAG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by table A pages from all database files.</td></tr>

<tr><th>BUFFAL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by table A pages from all database files.</td></tr>

<tr><th>BUFFB</th>
<td>Total number of pages in the disk buffer pool currently occupied by table B pages from all database files.</td></tr>

<tr><th>BUFFBG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by table B pages from all database files.</td></tr>

<tr><th>BUFFBL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by table B pages from all database files.</td></tr>

<tr><th>BUFFC</th>
<td>Total number of pages in the disk buffer pool currently occupied by table C pages from all database files.</td></tr>

<tr><th>BUFFCG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by table C pages from all database files.</td></tr>

<tr><th>BUFFCL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by table C pages from all database files.</td></tr>

<tr><th>BUFFD</th>
<td>Total number of pages in the disk buffer pool currently occupied by table D pages from all database files.</td></tr>

<tr><th>BUFFDG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by table D pages from all database files.</td></tr>

<tr><th>BUFFDL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by table D pages from all database files.</td></tr>

<tr><th>BUFFE</th>
<td>Total number of pages in the disk buffer pool currently occupied by Table E pages from all database files.</td></tr>

<tr><th>BUFFEG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by table E pages from all database files.</td></tr>

<tr><th>BUFFEL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by table E pages from all database files.</td></tr>

<tr><th>BUFFF</th>
<td>Total number of pages in the disk buffer pool currently occupied by FCT pages from all database files.</td></tr>

<tr><th>BUFFFG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by FCT pages from all database files.</td></tr>

<tr><th>BUFFFL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by FCT pages from all database files.</td></tr>

<tr><th>BUFFT</th>
<td>Total number of pages in the disk buffer pool currently occupied by CCATEMP pages. Note that in the file buffer usage statistics, CCATEMP pages are indicated as table D.</td></tr>

<tr><th>BUFFTG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by CCATEMP pages. Note that in the file buffer usage statistics, CCATEMP pages are indicated as table D.</td></tr>

<tr><th>BUFFTL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by CCATEMP pages. Note that in the file buffer usage statistics, CCATEMP pages are indicated as table D.</td></tr>

<tr><th>BUFFX</th>
<td>Total number of pages in the disk buffer pool currently occupied by Table X pages from all database files.</td></tr>

<tr><th>BUFFXG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by table X pages from all database files.</td></tr>

<tr><th>BUFFXL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by table X pages from all database files.</td></tr>

<tr><th>BUFM.</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified pages from all tables in all database files. Equal to <code>BUFMF + BUFMA + BUFMB + BUFMC + BUFMD + BUFME + BUFMX</code>.</td></tr>

<tr><th>BUFMA</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMAG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMAL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMB</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMBG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified table B pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMBL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified table B pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMC</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMCG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified table C pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMCL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified table C pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMD</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMDG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified table D pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMDL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified table D pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFME</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMEG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified table E pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMEL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified table E pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMF</th>
<td>Total number of pages in the disk buffer pool currently occupied by FCT pages from all database files. These pages must be written to to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMFG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified FCT pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMFL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified FCT pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMT</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified CCATEMP pages. These pages must be written to disk before they can be flushed from the buffer pool. Not that in the file buffer usage statistics, CCATEMP pages are indicated as table D.</td></tr>

<tr><th>BUFMTG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified CCATEMP pages. These pages must be written to disk before they can be flushed from the buffer pool. Note that in the file usage statistics, CCATEMP pages are indicated as table D.</td></tr>

<tr><th>BUFMTL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified CCATEMP pages. These pages must be written to disk before they can be flushed from the buffer pool. Note that in the file usage statistics, CCATEMP pages are indicated as table D.</td></tr>

<tr><th>BUFMX</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table X pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMXG</th>
<td>Total number of above-the-bar pages in the disk buffer pool currently occupied by modified table E pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFMXL</th>
<td>Total number of below-the-bar pages in the disk buffer pool currently occupied by modified table E pages from all database files. These pages must be written to disk before they can be flushed from the buffer pool.</td></tr>

<tr><th>BUFPAGA</th>
<td>Total number of pages in the disk buffer pool currently occupied by table A pages from all database files.</td></tr>

<tr><th>BUFPAGB</th>
<td>Total number of pages in the disk buffer pool currently occupied by table B pages from all database files except CCATEMP. CCATEMP table B pages are counted under BUFPAGX.</td></tr>

<tr><th>BUFPAGC</th>
<td>Total number of pages in the disk buffer pool currently occupied by table C pages from all database files.</td></tr>

<tr><th>BUFPAGD</th>
<td>Total number of pages in the disk buffer pool currently occupied by table D pages from all database files.</td></tr>

<tr><th>BUFPAGE</th>
<td>Total number of pages in the disk buffer pool currently occupied by pages from all tables in all database files.
Equal to <code>BUFPAGA + BUFPAGB + BUFPAGC + BUFPAGD + BUFPAGF + BUFPAGX</code> plus the number of Table X pages in the buffer pool, which can be obtained with the BUFFX statistic.</td></tr>

<tr><th>BUFPAGF</th>
<td>Total number of pages in the disk buffer pool currently occupied by FCT pages from all database files.</td></tr>

<tr><th>BUFPAGL</th>
<td>Total number of pages in the disk buffer pool currently occupied by table E pages from all database files. The L stands for LOBs, or large objects, which is what is stored in table E.</td></tr>

<tr><th>BUFPAGX</th>
<td>Total number of pages in the disk buffer pool currently occupied by table B pages from CCATEMP. All CCATEMP pages are considered to be in table B.</td></tr>

<tr><th>BUPD</th>
<td>Fields added to or changed in table B (rate or total). Equal to <code>BADD+BCHG</code>.</td></tr>

<tr><th>CCATIO</th>
<td>Physical CCATEMP reads and writes (rate or total). Equal to <code>CCATRD+CCATWR</code>.</td></tr>

<tr><th>CCATLHP</th>
<td>High water mark for percent of "low" CCATEMP pages used. These are pages in the first 64K CCATEMP pages.</td></tr>

<tr><th>CCATLHU</th>
<td>High water mark of number of "low" CCATEMP pages used. These are pages in the first 64K CCATEMP pages.</td></tr>

<tr><th>CCATMHP</th>
<td>High water mark for percent of CCATEMP pages in use.</td></tr>

<tr><th>CCATMHU</th>
<td>High water mark for total number of CCATEMP pages in use.</td></tr>

<tr><th>CCATMLP</th>
<td>The current percentage of "low" CCATEMP pages used. These are pages in the first 64K CCATEMP pages.</td></tr>

<tr><th>CCATMLU</th>
<td>The current number of "low" CCATEMP pages used. These are pages in the first 64K CCATEMP pages.</td></tr>

<tr><th>CCATMPP</th>
<td>Percent of CCATEMP pages in use.</td></tr>

<tr><th>CCATMPT</th>
<td>Total number of CCATEMP pages.</td></tr>

<tr><th>CCATMPU</th>
<td>Total number of CCATEMP pages in use.</td></tr>

<tr><th>CCATMXP</th>
<td>The current percentage of "extended" CCATEMP pages used. These are pages past the first 64K CCATEMP pages.</td></tr>

<tr><th>CCATMXU</th>
<td>The current number of "extended" CCATEMP pages used. These are pages past the first 64K CCATEMP pages.</td></tr>

<tr><th>CCATRD</th>
<td>Physical CCATEMP page reads (rate or total).</td></tr>

<tr><th>CCATWR</th>
<td>Physical CCATEMP page writes (rate or total).</td></tr>

<tr><th>CDLWAIT</th>
<td>Number of constraint dependency lock waits (rate or total).</td></tr>

<tr><th>CFRCDIR</th>
<td>Conflicts on the <code>DIRECT</code> critical file resource in all database files (rate or total). This resource protects the integrity of Table B.</td></tr>

<tr><th>CFRCEXS</th>
<td>Conflicts on the <code>EXISTS</code> critical file resource in all database files (rate or total). This resource protects the integrity of the existence bit map.</td></tr>

<tr><th>CFRCIND</th>
<td>Conflicts on the <code>INDEX</code> critical file resource in all database files (rate or total). This resource protects the integrity of the database indexes.</td></tr>

<tr><th>CFRCONF</th>
<td>Conflicts on all critical file resources in all database files (rate or total).</td></tr>

<tr><th>CFRCREC</th>
<td>Conflicts on the <code>RECENQ</code> critical file resource in all database files (rate or total). This resource protects the integrity of the record enqueueing tables.</td></tr>

<tr><th>CHKPALP</th>
<td>Percent of checkpoint dataset full given the current extent allocation. Interpreting this statistic requires some knowledge of the checkpoint dataset allocation characteristics.
If the checkpoint is allocated <code>SPACE=(CYL,10,10)</code>, and 9 cylinders are filled, CHKPALP will show 90%. If the current extent fills and another is allocated, CHKPALP will drop to around 50%.</td></tr>

<tr><th>CHKPIO</th>
<td>Checkpoint data set writes (rate or total).</td></tr>

<tr><th>CHKPLST</th>
<td>Number of seconds since last checkpoint.</td></tr>

<tr><th>CHKPNCK</th>
<td>Number of checkpoints in the current checkpoint stream. Always less than or equal to <var>[[CPMAX parameter|CPMAX]]</var>. Always displayed as total.</td></tr>

<tr><th>CHKPNUS</th>
<td>Number of user who have enqueued (preventing) checkpoints.</td></tr>

<tr><th>CHKPREC</th>
<td>Number of records written to the checkpoint dataset since the last rewind of the dataset. Always displayed as total.</td></tr>

<tr><th>CHKPTO</th>
<td>Number of checkpoint timeouts since the last successful checkpoint. Always displayed as total.</td></tr>

<tr><th>CHKPTOU</th>
<td>The user number of the user that caused the last checkpoint to timeout (sometimes multiple users will be the cause, but this statistic will only display the last one it finds). Returns a -1 if the last checkpoint was successful.</td></tr>

<tr><th>CNCT</th>
<td>System elapsed time. Seconds since online came up.</td></tr>

<tr><th>CNSCURP</th>
<td>Current number of real primary constraint pages.</td></tr>

<tr><th>CNSMAXP</th>
<td>Parameter - maximum number of constraint pages.</td></tr>

<tr><th>CNSMERG</th>
<td>Number of constraint table merges (rate or total).</td></tr>

<tr><th>CNSMINP</th>
<td>Parameter - minimum number of constraint pages.</td></tr>

<tr><th>CNSNWTS</th>
<td>Number of share enqueue waits for contraints lock (rate or total).</td></tr>

<tr><th>CNSNWTX</th>
<td>Number of exclusive enqueue waits for contraints lock (rate or total).</td></tr>

<tr><th>CNSOVFP</th>
<td>Number of overflow constraints pages.</td></tr>

<tr><th>CNSOVFPH</th>
<td>High water mark for number of overflow constraints pages.</td></tr>

<tr><th>CNSREO</th>
<td>Number of constraints table reorgs (rate or total).</td></tr>

<tr><th>CNSREOC</th>
<td>Number of constraints table reorg checks (rate or total).</td></tr>

<tr><th>CNSSPLT</th>
<td>Number of constraint splits (rate or total).</td></tr>

<tr><th>CNSTWTS</th>
<td>Milliseconds spent waiting on share for constraints lock (rate or total).</td></tr>

<tr><th>CNSTWTX</th>
<td>Milliseconds spent waiting on exclusive for constraints lock (rate or total).</td></tr>

<tr><th>COMMITS</th>
<td>Number of commited update units (rate or total).</td></tr>

<tr><th>CPU</th>
<td>CPU time consumed - stat $functions return milliseconds, SirMon displays seconds (rate or total).</td></tr>

<tr><th>DEV10</th>
<td>Output lines written to directed output (USE) data sets or temporary procedures (rate or total).</td></tr>

<tr><th>DEV11</th>
<td>Output lines to remote User Language in Full Screen mode (rate or total).</td></tr>

<tr><th>DEV12</th>
<td>Input lines from remote User Language in Full Screen mode (rate or total).</td></tr>

<tr><th>DEV21</th>
<td>Output lines to TCAM 3275s (rate or total).</td></tr>

<tr><th>DEV22</th>
<td>Input lines from TCAM 3275s (rate or total).</td></tr>

<tr><th>DEV23</th>
<td>Output lines to IFAM2 or IFAM4 programs (rate or total).</td></tr>

<tr><th>DEV24</th>
<td>Input arguments from certain IFAM2 or IFAM4 calls (rate or total).</td></tr>

<tr><th>DEV25</th>
<td>Output lines to remote BTAM 3270s (rate or total).</td></tr>

<tr><th>DEV26</th>
<td>Input lines from remote BTAM 3270s (rate or total).</td></tr>

<tr><th>DEV27</th>
<td>Terminal error messages issued for inbound Horizon conversations (rate or total).</td></tr>

<tr><th>DEV28</th>
<td>Not used.</td></tr>

<tr><th>DEV31</th>
<td>IFDISP output lines to IFAM1 programs (rate or total).</td></tr>

<tr><th>DEV32</th>
<td>Input arguments supplied by IFAM1 calls (rate or total).</td></tr>

<tr><th>DEV33</th>
<td>Output lines to TCAM 2741s and teletypes (rate or total).</td></tr>

<tr><th>DEV34</th>
<td>Input lines from TCAM 2741s and teletypes (rate or total).</td></tr>

<tr><th>DEV35</th>
<td>Output lines to BTAM 3270s (rate or total).</td></tr>

<tr><th>DEV36</th>
<td>Input lines from BTAM 3270s (rate or total).</td></tr>

<tr><th>DEV37</th>
<td>Output lines to VTAM 2741s and teletypes (rate or total).</td></tr>

<tr><th>DEV38</th>
<td>Input lines from VTAM 2741s and teletypes (rate or total).</td></tr>

<tr><th>DEV49</th>
<td>Output lines to Remote Command Line applications (rate or total).</td></tr>

<tr><th>DEV5</th>
<td>Output lines to to procedures defined during the run (rate or total).</td></tr>

<tr><th>DEV50</th>
<td>Input lines from Remote Command Line applications (rate or total).</td></tr>

<tr><th>DEV51</th>
<td>Not used.</td></tr>

<tr><th>DEV52</th>
<td>Not used.</td></tr>

<tr><th>DEV53</th>
<td>Output lines from an IFAM1 application (rate or total).</td></tr>

<tr><th>DEV54</th>
<td>Input lines from an IFAM1 application (rate or total).</td></tr>

<tr><th>DEV55</th>
<td>Not used.</td></tr>

<tr><th>DEV56</th>
<td>Not used.</td></tr>

<tr><th>DEV57</th>
<td>Not used.</td></tr>

<tr><th>DEV58</th>
<td>Not used.</td></tr>

<tr><th>DEV59</th>
<td>Not used.</td></tr>

<tr><th>DEV6</th>
<td>Input lines from procedures defined during the run (rate or total).</td></tr>

<tr><th>DEV60</th>
<td>Not used.</td></tr>

<tr><th>DEV61</th>
<td>Not used.</td></tr>

<tr><th>DEV62</th>
<td>Not used.</td></tr>

<tr><th>DEV63</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM parameter|MONPARM]]</var> system parameter.</td></tr>

<tr><th>DEV64</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV65</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV66</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV67</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV68</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV69</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV7</th>
<td>Output lines to VTAM 3270s (rate or total).</td></tr>

<tr><th>DEV70</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV71</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV72</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV73</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV74</th>
<td>Misused for UTI stats if X'08' bit set in the <var>MONPARM</var> system parameter.</td></tr>

<tr><th>DEV8</th>
<td>Input lines from VTAM 3270s (rate or total).</td></tr>

<tr><th>DEV9</th>
<td>Page headers or trailers defined in requests (rate or total).</td></tr>

<tr><th>DIRRCD</th>
<td>Number of records scanned in direct searches of table B (rate or total).</td></tr>

<tr><th>DKAR</th>
<td>Buffers allocated without page read request (rate or total).</td></tr>

<tr><th>DKBUFWT</th>
<td>Number of times a thread had to wait for a disk buffer page to become available before continuing processing (rate or total).
A high number for DKBUFWT could be a sign of a too small buffer pool, problems with anticipatory write logic, or application tuning problems.</td></tr>

<tr><th>DKIO</th>
<td>Physical page reads/writes to/from the Model204 database file (rate or total). This value is equal to <code>DKRD + DKWR</code>. Under Model 204 V6R2 or later, this is equal to <code>DKIOL + DKIOG</code>.</td></tr>

<tr><th>DKIOG</th>
<td>Physical page reads/writes to/from the Model204 database file to or from above-the-bar buffers (rate or total). This value is equal to <code>DKRDG + DKWRG</code>.</td></tr>

<tr><th>DKIOL</th>
<td>Physical page reads/writes to/from the Model204 database file to or from below-the-bar buffers (rate or total). This value is equal to <code>DKRDL + DKWRL</code>.
This has the same value as DKIO unless the <var>NUMBUFG</var> system parameter is set to a non-zero value under Model 204 V6R2 or later.</td></tr>

<tr><th>DKPR</th>
<td>Requests for a page in a database file or CCATEMP (rate or total).</td></tr>

<tr><th>DKPRF</th>
<td>Requests for a page in a database file or CCATEMP satisfied by a pending release page, a so-called fast logical page read (rate or total).</td></tr>

<tr><th>DKRD</th>
<td>Physical pages reads from the Model204 database file (rate or total). Under Model 204 V6R2 or later this is equal to <code>DKRDL + DKRDG</code>.</td></tr>

<tr><th>DKRDG</th>
<td>Physical pages reads from the Model204 database file to above-the-bar buffers (rate or total).</td></tr>

<tr><th>DKRDL</th>
<td>Physical pages reads from the Model204 database file to below-the-bar buffers (rate or total). This has the same value as DKRD unless the <var>NUMBUFG</var> system parameter is set to a non-zero value under Model 204 V6R2 or later.</td></tr>

<tr><th>DKRDPRP</th>
<td><code> (DKPR - DKRD) / DKPR * 100</code>. This is the percentage of page requests satisfied by pages already in the 204 buffer pool, and which did not require a physical I/O.
Hence, this is a measure of caching efficiency.
While there is no definite "good" or "bad" number for DKRDPRP, the ideal situation is to have as high a percentage as possible of page requests satisfied by pages in cache (that is, in the buffer pool).</td></tr>

<tr><th>DKRR</th>
<td>Physical reads of database file and CCATEMP pages when the page was recently used (rate or total).</td></tr>

<tr><th>DKSAW</th>
<td>Anticipatory disk buffer writes (rate or total).</td></tr>

<tr><th>DKSAWB</th>
<td>Anticipatory disk buffer writes at bottom of the reuse queue (rate or total). This number will almost always be 0 or very close.</td></tr>

<tr><th>DKSAWBG</th>
<td>Anticipatory disk buffer writes at bottom of the reuse queue (rate or total) for above-the-bar buffers. This number will almost always be 0 or very close.</td></tr>

<tr><th>DKSAWBL</th>
<td>Anticipatory disk buffer writes at bottom of the reuse queue (rate or total) for below-the-bar buffers. This number will almost always be 0 or very close.</td></tr>

<tr><th>DKSAWC</th>
<td>Anticipatory disk buffer writes for CCATEMP pages (rate or total). Obsolete: with 2.2 will always return a 0.</td></tr>

<tr><th>DKSAWG</th>
<td>Anticipatory disk buffer writes (rate or total) for above-the-bar buffers. This number will be zero, unless the <var>NUMBUFG</var> system parameter is set to a non-zero value under Model 204 V6R2 or later.</td></tr>

<tr><th>DKSAWL</th>
<td>Anticipatory disk buffer writes (rate or total) for below-the-bar buffers. This number will be the same as DKSAW, unless the <var>NUMBUFG</var> system parameter is set to a non-zero value under Model 204 V6R2 or later.</td></tr>

<tr><th>DKSAWT</th>
<td>Anticipatory disk buffer writes at top of the reuse queue (rate or total). This number will always be 0 and is only listed for historic reasons.</td></tr>

<tr><th>DKSAWW</th>
<td>Anticipatory disk buffer writes upon "window" entry in the reuse queue (rate or total). This number is the chief component of the DKSAW statistic and will almost always be almost exactly the same value as DKSAW.</td></tr>

<tr><th>DKSCW</th>
<td>"COMMIT" or non-anticipatory disk buffer writes (rate or total). Equal to DKWR - DKSAW since all writes are either anticipatory writes or writes resulting from physical commits.</td></tr>

<tr><th>DKSDIR</th>
<td>High water mark for the number of modified buffers inside the window.</td></tr>

<tr><th>DKSDIRT</th>
<td>Total number of modified buffers inside the window.</td></tr>

<tr><th>DKSFB</th>
<td>Calls to find a buffer (rate or total). Obsolete: this stat will always return 0.</td></tr>

<tr><th>DKSFBS</th>
<td>Scans required because the oldest free buffer was not immediately available (rate or total).</td></tr>

<tr><th>DKSFNU</th>
<td>Number of times page found in buffers not in use (rate or total).</td></tr>

<tr><th>DKSH2M</th>
<td>"Find Buffer Scans" that crossed from the high reuse queue into the medium reuse queue (rate or total). Obsolete with 2.2.</td></tr>

<tr><th>DKSKIP</th>
<td>High water mark of the number of free buffers that were skipped when searching for a buffer that could be reused immediately.</td></tr>

<tr><th>DKSKIPT</th>
<td>Free buffers that were skipped when searching for a buffer that could be reused immediately (rate or total).</td></tr>

<tr><th>DKSM2L</th>
<td>"Find Buffer Scans" that crossed from the medium reuse queue the low reuse queue (rate or total). Obsolete under 2.2</td></tr>

<tr><th>DKSRHC</th>
<td>Number of rehashes required because of disk buffer pool hash cell collisions.</td></tr>

<tr><th>DKSRR</th>
<td>Physical reads of database file and CCATEMP pages when the page was recently used (rate or total).</td></tr>

<tr><th>DKSTBLA</th>
<td>Physical Table A read (rate or total).</td></tr>

<tr><th>DKSTBLB</th>
<td>Physical Table B read (rate or total).</td></tr>

<tr><th>DKSTBLC</th>
<td>Physical Table C read (rate or total).</td></tr>

<tr><th>DKSTBLD</th>
<td>Physical Table D read (rate or total).</td></tr>

<tr><th>DKSTBLE</th>
<td>Physical Table E read (rate or total).</td></tr>

<tr><th>DKSTBLF</th>
<td>Physical Table F read (rate or total).</td></tr>

<tr><th>DKSTKQC</th>
<td>Number of times current page closed because user had four open pages and needed another (rate or total).</td></tr>

<tr><th>DKSUAW</th>
<td>Waits for oldest buffer in buffer pool to be written out (rate or total). Makes up part of DKBUFWT. Obsolete.</td></tr>

<tr><th>DKSWAIT</th>
<td>Number of waits to reuse buffer (rate or total).</td></tr>

<tr><th>DKSWRP</th>
<td>High water mark number of concurrent active anticipatory writes.</td></tr>

<tr><th>DKSWRPT</th>
<td>Total number of currently active anticipatory writes.</td></tr>

<tr><th>DKWR</th>
<td>Physical page writes to Model204 database file (rate or total). Under Model 204 V6R2 or later this is equal to <code>DKWRL + DKWRG</code>.</td></tr>

<tr><th>DKWRG</th>
<td>Physical pages writes to the Model204 database file from above-the-bar buffers (rate or total).</td></tr>

<tr><th>DKWRL</th>
<td>Physical page writes to the Model204 database file from below-the-bar buffers (rate or total). This has the same value as DKWR unless the <var>NUMBUFG</var> system parameter is set to a non-zero value under Model 204 V6R2 or later.</td></tr>

<tr><th>DMPRST</th>
<td>DUMP and RESTORE I/O's (rate or total). Equal to <code>DUMP+REST</code>.</td></tr>

<tr><th>DNSCACHE</th>
<td>The number of entries in the name server cache (the CACHE value on the <var>JANUS NAMESERVER</var> command).</td></tr>

<tr><th>DNSCURNS</th>
<td>The current "go to" nameserver in dotted IP address format with the port number in parentheses. For example: 198.242.244.9(53).</td></tr>

<tr><th>DNSMAXTL</th>
<td>The value of the <var>MAXTTL</var> parameter on the <var>JANUS NAMESERVER</var> command.</td></tr>

<tr><th>DNSRCACH</th>
<td>Number of name lookup requests that found the requested name in the cache (rate or total).</td></tr>

<tr><th>DNSRFAIL</th>
<td>Number of name lookup requests that did not succeed, that is, did not get an IP adress (rate or total).</td></tr>

<tr><th>DNSRSUCC</th>
<td>Number of name lookups requests that succeeded (rate or total).</td></tr>

<tr><th>DNSRTIMO</th>
<td>Number of requests to nameservers that timed out before they got a response. With multiple nameservers, a single request can try several servers and so get several timeouts. But, of course, this is probably pretty rare in practice.</td></tr>

<tr><th>DNSRTOT</th>
<td>Total number of name lookup request (rate or total).</td></tr>

<tr><th>DNSWTIME</th>
<td>Total time spent waiting for responses from nameservers. "Interesting" calculated values might be <code>DNSWTIME/DNSRTOT</code> or <code>DNSWTIME/(DNSRTOT-DNSRCACH)</code>.</td></tr>

<tr><th>DUMP</th>
<td>Writes to a Model204 file backup (rate or total).</td></tr>

<tr><th>ECCALL</th>
<td>Number of External Call Facility calls (rate or total).</td></tr>

<tr><th>ECCNCT</th>
<td>Total amount of time External Call Facility subtasks spent running (rate or total).</td></tr>

<tr><th>ECCPU</th>
<td>Total amount of CPU used by External Call Facility subtasks (rate or total).</td></tr>

<tr><th>ECCTOUT</th>
<td>Number of External Call Facility calls that timed out, that is did not complete in the time period specified on the <code>EXTERNAL PROGRAM</code> statement (rate or total).</td></tr>

<tr><th>ECCWAITP</th>
<td>Number of External Call Facility calls that had to wait for a load module to become available either because it was non-reentrant and it was in use or because the module was being loaded or deleted (rate or total).</td></tr>

<tr><th>ECCWAITS</th>
<td>Number of External Call Facility calls that had to wait for a subtask to become available (rate or total).</td></tr>

<tr><th>ECDELETE</th>
<td>Number of <code>EXTERNAL DELETE</code> statements executed (rate or total).</td></tr>

<tr><th>ECEXCP</th>
<td>Total number of I/O's done by External Call Facility subtasks (rate or total).</td></tr>

<tr><th>ECLOAD</th>
<td>Number of EXTERNAL LOAD statements executed (rate or total).</td></tr>

<tr><th>ECNAMMAX</th>
<td>High water mark of External Call Facility call names defined via <code>EXTERNAL NAME</code> (total).</td></tr>

<tr><th>ECPGMMAX</th>
<td>High water mark of External Call Facility load modules defined via <code>EXTERNAL PROGRAM</code> (total).</td></tr>

<tr><th>ECTSKMAX</th>
<td>High water mark of External Call Facility subtasks in use (total).</td></tr>

<tr><th>ECTWAITP</th>
<td>Amount of time External Call Facility calls that had to wait for a load module to become available either because it was non-reentrant and it was in use or because the module was being loaded or deleted (rate or total).</td></tr>

<tr><th>ECTWAITS</th>
<td>Amount of time External Call Facility programs spent waiting for a subtask to become available (rate or total).</td></tr>

<tr><th>ERRPDL</th>
<td>High water mark of the SYSTEM push-down list.</td></tr>

<tr><th>FBMX</th>
<td>High water mark of the number of active disk buffers. This is an optional statistic.</td></tr>

<tr><th>FBWT</th>
<td>Waits for a free Model204 disk buffer (rate or total). This will always be 0 if the number of buffers is greater than or equal to 4 times the number of servers. Makes up part of DKBUFWT.</td></tr>

<tr><th>FINDS</th>
<td>User Language FIND statements executed (rate or total).</td></tr>

<tr><th>GTBLRS</th>
<td>Number of GTBL rearrangements required to add a non-string global "object", such as an image or screen.</td></tr>

<tr><th>GTBLRU</th>
<td>Number of GTBL rearrangements required to add or expand a string global value with <var>$Setg</var>.</td></tr>

<tr><th>HRDRSTRT</th>
<td>Counts the number of times a hard user restart has occured (rate or total).</td></tr>

<tr><th>IN</th>
<td>Input lines from CCAIN, user zero (rate or total).</td></tr>

<tr><th>INCMFS</th>
<td>Input lines from CMS full screen console - ALTIODEV 47 (rate or total).</td></tr>

<tr><th>INCMIO</th>
<td>Input lines from CMS non-full screen console - ALTIODEV 45 (rate or total).</td></tr>

<tr><th>INCRAM</th>
<td>Input lines from remote User Language threads (BATCH2, etc.) - IODEV 29. (rate or total).</td></tr>

<tr><th>INTTY</th>
<td>Input lines from BTAM teletypes - IODEV 15 (rate or total).</td></tr>

<tr><th>INVMFS</th>
<td>Input lines from VMCF or IUCV full screen threads - IODEV 41 (rate or total).</td></tr>

<tr><th>INVMIF</th>
<td>Input arguments supplied by certain IFAM2 or IFAM4 calls from CMS programs - IODEV 43 (rate or total).</td></tr>

<tr><th>INVMIO</th>
<td>Input lines from IUCV or VMCF non-full screen threads - IODEV 39 (rate or total).</td></tr>

<tr><th>INXX</th>
<td>Input lines from QSAM users - IODEV 3 (rate or total).</td></tr>

<tr><th>IN2265</th>
<td>Not used - IODEV 17 (total only).</td></tr>

<tr><th>IN2741</th>
<td>Input lines from BTAM 2741s - IODEV 13 (rate or total).</td></tr>

<tr><th>IN3275</th>
<td>Input lines from BTAM 3270s - IODEV 19 (rate or total).</td></tr>

<tr><th>IXADD</th>
<td>Index entries added to tables C and D, including attempts to add duplicates (rate or total).</td></tr>

<tr><th>IXDEL</th>
<td>Index entries deleted from tables C and D (rate or total).</td></tr>

<tr><th>IXUPD</th>
<td>Index entries changed in tables C and D (rate or total). Equal to IXADD + IXDEL.</td></tr>

<tr><th>JRNLALP</th>
<td>Percentage of journal dataset full given the current extent allocation. Interpreting this statistic requires some knowledge of the journal dataset allocation characteristics:
<ul>
<li>If the journal is allocated SPACE=(CYL,10,10) and 9 cylinders are filled, JRNLALP will show 90%. </li>

<li>If the current extent fills and another is is allocated, JRNLALP will drop to around 50%. </li>
</ul>
High values may signal that the region is about to switch to another ring member or that a critical "full" condition is pending in the journal.</td></tr>

<tr><th>JRNLIO</th>
<td>Physical journal writes - CCAJRNL I/O's (rate or total).</td></tr>

<tr><th>JSCREENS</th>
<td>Counts the number of times Janus Web incremented the SCREENS statistic. Since these may occur outside of request context, they would not necessarily have corresponding Since-Last statistics (rate or total).</td></tr>

<tr><th>JWEBERRS</th>
<td>Counts the number of times that Janus Web returned a 4xx status code. Note that these would not be counted in the SCREENS statistic, but it is handy to know that for example a bunch of 404 or 401 errors are occurring (rate or total).</td></tr>

<tr><th>LCDKBM</th>
<td>Number of DKBM MP lock conflicts (rate or total).</td></tr>

<tr><th>LCFORT</th>
<td>Number of FORTRAN MP lock conflicts (rate or total).</td></tr>

<tr><th>LCHASH</th>
<td>Number of HASH MP lock conflicts (rate or total).</td></tr>

<tr><th>LCLRUQ</th>
<td>Number of LRUQ MP lock conflicts (rate or total).</td></tr>

<tr><th>LCRCLK</th>
<td>Number of RCLK (record locking) MP lock conflicts (rate or total).</td></tr>

<tr><th>LCTOT</th>
<td>Total number of all types of MP lock conflicts (rate or total).</td></tr>

<tr><th>LCV7IB</th>
<td>Number of V7IB MP lock conflicts (rate or total).</td></tr>

<tr><th>LCV7OB</th>
<td>Number of V7OB MP lock conflicts (rate or total).</td></tr>

<tr><th>LKPOST</th>
<td>Real POST SVCs issued to release MP locks (rate or total).</td></tr>

<tr><th>LKWAIT</th>
<td>Real WAIT SVCs issued to wait for MP locks (rate or total).</td></tr>

<tr><th>LOCAL0</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL1</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL2</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL3</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL4</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL5</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL6</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL7</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL8</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOCAL9</th>
<td>Locally defined stat for $INCSTAT and $SETSTAT. (rate or total).</td></tr>

<tr><th>LOFORT</th>
<td>Number of times FORTRAN MP lock was obtained (rate or total).</td></tr>

<tr><th>LOFORTE</th>
<td>Number of times FORTRAN MP lock was obtained EXC (rate or total).</td></tr>

<tr><th>LOFORTS</th>
<td>Number of times FORTRAN MP lock was obtained SHR (rate or total).</td></tr>

<tr><th>LOGALP</th>
<td>Percent full of log dataset, if it's being used.</td></tr>

<tr><th>LOGIO</th>
<td>Records added to log dataset, if it's being used (rate or total).</td></tr>

<tr><th>LONGUPDT</th>
<td>Number of update units exceeding MAXUD parameter (rate or total).</td></tr>

<tr><th>LONGUTIM</th>
<td>Total duration in milliseconds of update units that exceeded the MAXUD parameter.</td></tr>

<tr><th>LORCLK</th>
<td>Number of times RCLK MP lock was obtained (rate or total).</td></tr>

<tr><th>LORCLKE</th>
<td>Number of times RCLK MP lock was obtained EXC (rate or total).</td></tr>

<tr><th>LORCLKS</th>
<td>Number of times RCLK MP lock was obtained SHR (rate or total).</td></tr>

<tr><th>LOTOT</th>
<td>Number of times any kind of MP lock was obtained (rate or total).</td></tr>

<tr><th>LOTOTE</th>
<td>Number of times any kind of EXC MP lock was obtained (rate or total).</td></tr>

<tr><th>LOTOTS</th>
<td>Number of times any kind of SHR MP lock was obtained (rate or total).</td></tr>

<tr><th>LPCMLW</th>
<td>Number of times CMLW lock posted. (rate or total).</td></tr>

<tr><th>LPCNST</th>
<td>Number of times CNST lock posted. (rate or total).</td></tr>

<tr><th>LPDBCD</th>
<td>Number of times DBCD lock posted. (rate or total).</td></tr>

<tr><th>LPECMM</th>
<td>Number of times ECMM lock posted. (rate or total).</td></tr>

<tr><th>LPECTM</th>
<td>Number of times ECTM lock posted. (rate or total).</td></tr>

<tr><th>LPFILD</th>
<td>Number of times FILD lock posted. (rate or total).</td></tr>

<tr><th>LPFORT</th>
<td>Number of times FORT lock posted. (rate or total).</td></tr>

<tr><th>LPHASH</th>
<td>Number of times HASH lock posted. (rate or total).</td></tr>

<tr><th>LPITS1</th>
<td>Number of times ITS1 lock posted. (rate or total).</td></tr>

<tr><th>LPITS2</th>
<td>Number of times ITS2 lock posted. (rate or total).</td></tr>

<tr><th>LPJRNL</th>
<td>Number of times JRNL lock posted. (rate or total).</td></tr>

<tr><th>LPLIOS</th>
<td>Number of times LIOS lock posted. (rate or total).</td></tr>

<tr><th>LPLRUQ</th>
<td>Number of times LRUQ lock posted. (rate or total).</td></tr>

<tr><th>LPMQCH</th>
<td>Number of times MQCH lock posted. (rate or total).</td></tr>

<tr><th>LPMQST</th>
<td>Number of times MQST lock posted. (rate or total).</td></tr>

<tr><th>LPMQTA</th>
<td>Number of times MQTA lock posted. (rate or total).</td></tr>

<tr><th>LPPAGE</th>
<td>Number of times PAGE lock posted. (rate or total).</td></tr>

<tr><th>LPQMAN</th>
<td>Number of times QMAN lock posted. (rate or total).</td></tr>

<tr><th>LPQUEU</th>
<td>Number of times QUEU lock posted. (rate or total).</td></tr>

<tr><th>LPRCLK</th>
<td>Number of times RCLK lock posted. (rate or total).</td></tr>

<tr><th>LPSIR1</th>
<td>Number of times SIR1 lock posted. (rate or total).</td></tr>

<tr><th>LPSIR2</th>
<td>Number of times SIR2 lock posted. (rate or total).</td></tr>

<tr><th>LPSMFS</th>
<td>Number of times SMFS lock posted. (rate or total).</td></tr>

<tr><th>LPTOTAL</th>
<td>Total something relating to lock posters. (rate or total).</td></tr>

<tr><th>LPTWND</th>
<td>Number of times TWND lock posted. (rate or total).</td></tr>

<tr><th>LPUSR1</th>
<td>Number of times USR1 lock posted. (rate or total).</td></tr>

<tr><th>LPUSR2</th>
<td>Number of times USR2 lock posted. (rate or total).</td></tr>

<tr><th>LPV7IB</th>
<td>Number of times V7IB lock posted. (rate or total).</td></tr>

<tr><th>LPV7OB</th>
<td>Number of times V7OB lock posted. (rate or total).</td></tr>

<tr><th>LSCMLW</th>
<td>Number of times CMLW lock spun. (rate or total).</td></tr>

<tr><th>LSCNST</th>
<td>Number of times CNST lock spun. (rate or total).</td></tr>

<tr><th>LSDBCD</th>
<td>Number of times DBCD lock spun. (rate or total).</td></tr>

<tr><th>LSECMM</th>
<td>Number of times ECMM lock spun. (rate or total).</td></tr>

<tr><th>LSECTM</th>
<td>Number of times ECTM lock spun. (rate or total).</td></tr>

<tr><th>LSFILD</th>
<td>Number of times FILD lock spun. (rate or total).</td></tr>

<tr><th>LSFORT</th>
<td>Number of times FORT lock spun. (rate or total).</td></tr>

<tr><th>LSHASH</th>
<td>Number of times HASH lock spun. (rate or total).</td></tr>

<tr><th>LSITS1</th>
<td>Number of times ITS1 lock spun. (rate or total).</td></tr>

<tr><th>LSITS2</th>
<td>Number of times ITS2 lock spun. (rate or total).</td></tr>

<tr><th>LSJRNL</th>
<td>Number of times JRNL lock spun. (rate or total).</td></tr>

<tr><th>LSLIOS</th>
<td>Number of times LIOS lock spun. (rate or total).</td></tr>

<tr><th>LSLRUQ</th>
<td>Number of times LRUQ lock spun. (rate or total).</td></tr>

<tr><th>LSMQCH</th>
<td>Number of times MQCH lock spun. (rate or total).</td></tr>

<tr><th>LSMQST</th>
<td>Number of times MQST lock spun. (rate or total).</td></tr>

<tr><th>LSMQTA</th>
<td>Number of times MQTA lock spun. (rate or total).</td></tr>

<tr><th>LSPAGE</th>
<td>Number of times PAGE lock spun. (rate or total).</td></tr>

<tr><th>LSQMAN</th>
<td>Number of times QMAN lock spun. (rate or total).</td></tr>

<tr><th>LSQUEU</th>
<td>Number of times QUEU lock spun. (rate or total).</td></tr>

<tr><th>LSRCLK</th>
<td>Number of times RCLK lock spun. (rate or total).</td></tr>

<tr><th>LSSIR1</th>
<td>Number of times SIR1 lock spun. (rate or total).</td></tr>

<tr><th>LSSIR2</th>
<td>Number of times SIR2 lock spun. (rate or total).</td></tr>

<tr><th>LSSMFS</th>
<td>Number of times SMFS lock spun. (rate or total).</td></tr>

<tr><th>LSTOTAL</th>
<td>Total something relating to lock spins. (rate or total).</td></tr>

<tr><th>LSTWND</th>
<td>Number of times TWND lock spun. (rate or total).</td></tr>

<tr><th>LSUSR1</th>
<td>Number of times USR1 lock spun. (rate or total).</td></tr>

<tr><th>LSUSR2</th>
<td>Number of times USR2 lock spun. (rate or total).</td></tr>

<tr><th>LSV7IB</th>
<td>Number of times V7IB lock spun. (rate or total).</td></tr>

<tr><th>LSV7OB</th>
<td>Number of times V7OB lock spun. (rate or total).</td></tr>

<tr><th>LWCMLW</th>
<td>Number of times CMLW lock waited. (rate or total).</td></tr>

<tr><th>LWCNST</th>
<td>Number of times CNST lock waited. (rate or total).</td></tr>

<tr><th>LWDBCD</th>
<td>Number of times DBCD lock waited. (rate or total).</td></tr>

<tr><th>LWECMM</th>
<td>Number of times ECMM lock waited. (rate or total).</td></tr>

<tr><th>LWECTM</th>
<td>Number of times ECTM lock waited. (rate or total).</td></tr>

<tr><th>LWFILD</th>
<td>Number of times FILD lock waited. (rate or total).</td></tr>

<tr><th>LWFORT</th>
<td>Number of times FORT lock waited. (rate or total).</td></tr>

<tr><th>LWHASH</th>
<td>Number of times HASH lock waited. (rate or total).</td></tr>

<tr><th>LWITS1</th>
<td>Number of times ITS1 lock waited. (rate or total).</td></tr>

<tr><th>LWITS2</th>
<td>Number of times ITS2 lock waited. (rate or total).</td></tr>

<tr><th>LWJRNL</th>
<td>Number of times JRNL lock waited. (rate or total).</td></tr>

<tr><th>LWLIOS</th>
<td>Number of times LIOS lock waited. (rate or total).</td></tr>

<tr><th>LWLRUQ</th>
<td>Number of times LRUQ lock waited. (rate or total).</td></tr>

<tr><th>LWMQCH</th>
<td>Number of times MQCH lock waited. (rate or total).</td></tr>

<tr><th>LWMQST</th>
<td>Number of times MQST lock waited. (rate or total).</td></tr>

<tr><th>LWMQTA</th>
<td>Number of times MQTA lock waited. (rate or total).</td></tr>

<tr><th>LWPAGE</th>
<td>Number of times PAGE lock waited. (rate or total).</td></tr>

<tr><th>LWQMAN</th>
<td>Number of times QMAN lock waited. (rate or total).</td></tr>

<tr><th>LWQUEU</th>
<td>Number of times QUEU lock waited. (rate or total).</td></tr>

<tr><th>LWRCLK</th>
<td>Number of times RCLK lock waited. (rate or total).</td></tr>

<tr><th>LWSIR1</th>
<td>Number of times SIR1 lock waited. (rate or total).</td></tr>

<tr><th>LWSIR2</th>
<td>Number of times SIR2 lock waited. (rate or total).</td></tr>

<tr><th>LWSMFS</th>
<td>Number of times SMFS lock waited. (rate or total).</td></tr>

<tr><th>LWTOTAL</th>
<td>Total something relating to lock waiters. (rate or total).</td></tr>

<tr><th>LWTWND</th>
<td>Number of times TWND lock waited. (rate or total).</td></tr>

<tr><th>LWUSR1</th>
<td>Number of times USR1 lock waited. (rate or total).</td></tr>

<tr><th>LWUSR2</th>
<td>Number of times USR2 lock waited. (rate or total).</td></tr>

<tr><th>LWV7IB</th>
<td>Number of times V7IB lock waited. (rate or total).</td></tr>

<tr><th>LWV7OB</th>
<td>Number of times V7OB lock waited. (rate or total).</td></tr>

<tr><th>MODPAGA</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table A pages from all database files. These pages must be written to disk before being flushed from the buffer pool.</td></tr>

<tr><th>MODPAGB</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table B pages from all database files except CCATEMP.
These pages must be written to disk before being flushed from the These pages must be written to disk before being flushed from the buffer pool.
Modified CCATEMP table B pages are counted under the MODPAGX statistic.</td></tr>

<tr><th>MODPAGC</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table C pages from all database files. These pages must be written to disk before being flushed from the buffer pool.</td></tr>

<tr><th>MODPAGD</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table D pages from all database files. These pages must be written to disk before being flushed from the buffer pool.</td></tr>

<tr><th>MODPAGE</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified pages from all tables in all database files.
These pages must be written to disk before being flushed from the buffer pool.
Equal to MODPAGA + MODPAGB + MODPAGC + MODPAGD + MODPAGF + MODPAGX + modfied pages from table X which can be obtained via the BUFMX statistic.</td></tr>

<tr><th>MODPAGF</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified FCT pages from all database files. These pages must be written to disk before being flushed from the buffer pool.</td></tr>

<tr><th>MODPAGL</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table E pages from all database files.
These pages must be written to disk before being flushed from the buffer pool. The L stands for LOBs, or large objects, which is what is stored in table E.</td></tr>

<tr><th>MODPAGX</th>
<td>Total number of pages in the disk buffer pool currently occupied by modified table X pages from CCATEMP. All CCATEMP pages are considered to be in table B. These pages must be written to disk before being flushed from the buffer pool.</td></tr>

<tr><th>MOVE</th>
<td>Thread switches (rate or total).</td></tr>

<tr><th>MPHASHD</th>
<td>Number of MP duplicate hash entries found (rate or total).</td></tr>

<tr><th>MPSTOPS</th>
<td>The number of times Model 204 temporarily disabled multi-processing. A high value for MPSTOPS could indicate suboptimal MP/204 processing.
Note that SirMon itself will sometimes do an MPSTOP to collect certain statistics. MPSTOPS will alwasy be zero for Model 204 versions prior to 7.4, and in non-MP environments (rate or total).</td></tr>

<tr><th>MQAPICNT</th>
<td>Number of MQ Series calls excluding MQGETs with WAIT specified (rate or total).</td></tr>

<tr><th>MQAPITIM</th>
<td>Time spent in MQ Series calls excluding MQGETs with WAIT specified (rate or total).</td></tr>

<tr><th>MQAVTASK</th>
<td>The number of available MQ Series tasks (total).
This number is the maximum number of MQ Series tasks that can be allocated in the region (the value of the MQMXTASK parameter) minus the current number of MQ Series tasks in use (the MQIUTASK statistic).</td></tr>

<tr><th>MQBYTEIN</th>
<td>Number of bytes received by MQ Series MQGET calls (rate or total).</td></tr>

<tr><th>MQBYTEOU</th>
<td>Number of bytes sent by MQ Series MQPUT and MQPUT1 calls (rate or total).</td></tr>

<tr><th>MQCUBUFS</th>
<td>Number of bytes of MQ Series message buffers currently allocated (total).</td></tr>

<tr><th>MQCUQU</th>
<td>Number of bytes of MQ Series queues currently open (total).</td></tr>

<tr><th>MQCUTASK</th>
<td>Current number of MQ Series tasks in the region (total)</td></tr>

<tr><th>MQFRTASK</th>
<td>The number of unused MQ Series tasks (total). This number is the number of MQ Series tasks in the region (the MQCUTASK statistic) minus the current number of MQ Series tasks in use (the MQIUTASK statistic).</td></tr>

<tr><th>MQGETS</th>
<td>Number of MQ Series MQGET calls (rate or total).</td></tr>

<tr><th>MQGWTCNT</th>
<td>Number of MQ Series MQGET calls with WAIT specified (rate or total).</td></tr>

<tr><th>MQGWTSUC</th>
<td>Number of successful MQ Series MQGET calls with WAIT specified (rate or total). Always less than or equal to MQGWTCNT.</td></tr>

<tr><th>MQGWTTIM</th>
<td>Time spent waiting for a response from an MQ Series MQGET call that had a non-unlimited time-limit (rate or total). Always less than or equal to MQGWTTSP.</td></tr>

<tr><th>MQGWTTSP</th>
<td>Wait time specified for all MQ Series MQGET calls that had a non-unlimited time-limit (rate or total). Always greater than or equal to MQGWTTIM.</td></tr>

<tr><th>MQHWBUFS</th>
<td>High water mark of number of bytes of MQ Series message buffers allocated (total).</td></tr>

<tr><th>MQHWQU</th>
<td>High water mark of number of open MQ Series queues (total).</td></tr>

<tr><th>MQHWTASK</th>
<td>High water mark of number of MQ Series tasks in the region (total).</td></tr>

<tr><th>MQINTASK</th>
<td>Initial number of MQ Series tasks in the region as specified by the MQINTASK system parameter (total).</td></tr>

<tr><th>MQIUTASK</th>
<td>Number of MQ Series tasks in use in the region (total).</td></tr>

<tr><th>MQMXTASK</th>
<td>Maximum number of MQ Series tasks in the region as specified by the MQMXTASK system parameter (total).</td></tr>

<tr><th>MQNUMQM</th>
<td>The number of distinct MQ Series queue managers connected to over the course of the run (total).</td></tr>

<tr><th>MQNUMQU</th>
<td>The number of distinct MQ Series queues accessed over the course of the run (total).</td></tr>

<tr><th>MQPUTS</th>
<td>Number of MQ Series MQPUT and MQPUT1 calls (rate or total).</td></tr>

<tr><th>MTDEQ</th>
<td>Number of items taken by MAIN from MAIN queue. Rate or total. Before Model 204 Version 7.4 always returns 0.</td></tr>

<tr><th>MTSDEQ</th>
<td>Number of items taken by MAIN from another task queue. Rate or total. Before Model 204 Version 7.4 always returns 0.</td></tr>

<tr><th>MTZDEQ</th>
<td>Number of items taken by MAIN from zIIP queue. Rate or total. Before Model 204 Version 7.4 always returns 0. To see non-zero results for MTZDEQ you must turn off SCHDOPT x'20'. SCHDOPT x'20' prevents maintask from 'stealing' zIIP work.</td></tr>

<tr><th>NBLKI</th>
<td>Current number of threads blocked (waiting) and in a server.</td></tr>

<tr><th>NBLKO</th>
<td>Current number of threads blocked (waiting) and not in a server.</td></tr>

<tr><th>NJBUFF</th>
<td>Number of journal buffers.</td></tr>

<tr><th>NLOGON</th>
<td>Current number of threads with logged on users.</td></tr>

<tr><th>NOFFQ</th>
<td>Current number of threads blocked (waiting), not in server and not on a queue scanned by the scheduler. These are usually threads waiting for VTAM input.</td></tr>

<tr><th>NREDY</th>
<td>Current number of threads ready to run.</td></tr>

<tr><th>NREDYR</th>
<td>Current number of threads ready to run or running.</td></tr>

<tr><th>NRUNBL</th>
<td>Current number of threads ready to run, running or waiting to be swapped into a server so they could be run. Equal to NLOGON-NWAIT.</td></tr>

<tr><th>NRUNG</th>
<td>Current number of threads running.</td></tr>

<tr><th>NSERVS</th>
<td>Number of servers defined in the online job.</td></tr>

<tr><th>NSWPG</th>
<td>Current number of threads swapping into or out of a server.</td></tr>

<tr><th>NUMBUF</th>
<td>Number of allocated database file page buffers.</td></tr>

<tr><th>NUMBUFG</th>
<td>Number of allocated above-the-bar database file page buffers.</td></tr>

<tr><th>NUSERS</th>
<td>Total number of threads defined to online.</td></tr>

<tr><th>NWAIT</th>
<td>Current number of threads blocked (waiting). Equal to NLOGON-NRUNBL. Same as NWTNG.</td></tr>

<tr><th>NWTCFR</th>
<td>Current number of threads waiting for a critical file resource. Equal to NWT24+NWT25.</td></tr>

<tr><th>NWTCK</th>
<td>Current number of threads waiting to wait for checkpoint I/O. This is the portion of NWT18 associated with the checkpoint data set.</td></tr>

<tr><th>NWTCKIO</th>
<td>Current number of threads waiting for checkpoint I/O. This is NWTCK+NWT16.</td></tr>

<tr><th>NWTCKPC</th>
<td>Current number of threads waiting for checkpoint completion. This is the same as NWT20.</td></tr>

<tr><th>NWTDKIO</th>
<td>Current number of threads waiting for database or CCATEMP disk I/O. This is the same as NWT01.</td></tr>

<tr><th>NWTENQ</th>
<td>Current number of threads waiting for an internal resource or a record lock. This is the same as NWT07.</td></tr>

<tr><th>NWTJR</th>
<td>Current number of threads waiting to wait for journal I/O. This is the portion of NWT18 associated with the journal data set.</td></tr>

<tr><th>NWTJRIO</th>
<td>Current number of threads waiting for journal I/O. This is NWTJR+NWT15.</td></tr>

<tr><th>NWTMISC</th>
<td>Current number of threads waiting for miscellaneous events. This is NWAIT-NWTDKIO-NWTUSER-NWTENQ-NWTJRIO-NWTCKIO -NWTCKPC-NWTCFR.</td></tr>

<tr><th>NWTNG</th>
<td>Current number of threads blocked (waiting). Equal to NLOGON-NRUNBL. Same as NWAIT.</td></tr>

<tr><th>NWTSV</th>
<td>Current number of threads swapped out and waiting for a server.</td></tr>

<tr><th>NWTUNK</th>
<td>Current number of threads waiting for undefined event. Please call Technical Support if you receive a non-zero value of this.</td></tr>

<tr><th>NWTUSER</th>
<td>Current number of threads waiting for user input or for output to reach a user. Equal to NWT02+NWT03+NWT11.</td></tr>

<tr><th>NWT00</th>
<td>Current number of threads in an unspecified wait.</td></tr>

<tr><th>NWT01</th>
<td>Current number of threads waiting for database or CCATEMP disk I/O. This is the same as NWTDKIO.</td></tr>

<tr><th>NWT02</th>
<td>Current number of threads waiting for output to reach a user.</td></tr>

<tr><th>NWT03</th>
<td>Current number of threads waiting for user input.</td></tr>

<tr><th>NWT04</th>
<td>Current number of threads waiting for operator console input.</td></tr>

<tr><th>NWT05</th>
<td>Current number of threads waiting for DUMP writes.</td></tr>

<tr><th>NWT06</th>
<td>Current number of threads waiting for RESTORE reads.</td></tr>

<tr><th>NWT07</th>
<td>Current number of threads waiting for internal resources or for record locks.</td></tr>

<tr><th>NWT08</th>
<td>Current number of threads waiting for a free disk buffer.</td></tr>

<tr><th>NWT09</th>
<td>Current number of threads waiting forever (deactivated).</td></tr>

<tr><th>NWT10</th>
<td>Current number of threads waiting for a pseudo subtask or reactivation (hung terminal).</td></tr>

<tr><th>NWT11</th>
<td>Current number of threads waiting for an IFAM2 or IFAM4 call.</td></tr>

<tr><th>NWT12</th>
<td>Current number of threads waiting for a wakeup.</td></tr>

<tr><th>NWT13</th>
<td>Current number of threads waiting for a server I/O. Note that this will almost always be zero because it does not include users that are being swapped in or out as a result of another wait type or slicing decisions.</td></tr>

<tr><th>NWT14</th>
<td>Not used.</td></tr>

<tr><th>NWT15</th>
<td>Current number of threads waiting for journal writes to complete.</td></tr>

<tr><th>NWT16</th>
<td>Current number of threads waiting for checkpoint writes to complete.</td></tr>

<tr><th>NWT17</th>
<td>Current number of threads waiting for a check on a previous write to the checkpoint data set.</td></tr>

<tr><th>NWT18</th>
<td>Current number of threads waiting for multi-user output arbitration. Number waiting for journal or checkpoint buffer.</td></tr>

<tr><th>NWT19</th>
<td>Current number of threads waiting for checkpoint requests to be acknowledged.</td></tr>

<tr><th>NWT20</th>
<td>Current number of threads waiting for checkpoint completion. This is the same as NWTCKPC.</td></tr>

<tr><th>NWT21</th>
<td>Current number of threads waiting forever (dead user).</td></tr>

<tr><th>NWT22</th>
<td>Current number of threads waiting for VSAM or sequential file input.</td></tr>

<tr><th>NWT23</th>
<td>Current number of threads waiting for user login after a login failure.</td></tr>

<tr><th>NWT24</th>
<td>Current number of threads waiting for exclusive control of a critical file resource.</td></tr>

<tr><th>NWT25</th>
<td>Current number of threads waiting for shared control of a critical file resource.</td></tr>

<tr><th>NWT26</th>
<td>Current number of threads waiting for a VTAM buffer.</td></tr>

<tr><th>NWT27</th>
<td>Current number of threads waiting for interprocess input.</td></tr>

<tr><th>NWT28</th>
<td>Current number of threads waiting for interprocess output to complete.</td></tr>

<tr><th>NWT29</th>
<td>Current number of threads waiting for response from the security interface.</td></tr>

<tr><th>NWT30</th>
<td>Current number of threads waiting in swappable $WAITs.</td></tr>

<tr><th>NWT31</th>
<td>Current number of threads waiting in non-swappable $WAITs.</td></tr>

<tr><th>NWT32</th>
<td>Current number of threads waiting on the DB2 subtask.</td></tr>

<tr><th>NWT33</th>
<td>Current number of threads waiting on replicator service thread.</td></tr>

<tr><th>NWT34</th>
<td>Current number of replicator service threads waiting for work.</td></tr>

<tr><th>NWT35</th>
<td>Current number of threads waiting on replication initialization.</td></tr>

<tr><th>NWT36</th>
<td>Current number of threads waiting on replication UL block startup.</td></tr>

<tr><th>NWT37</th>
<td>Current number of threads waiting on replication recover completion.</td></tr>

<tr><th>NWT38</th>
<td>Current number of threads waiting on a response from a SoftSpy server thread. Same as NWT62.</td></tr>

<tr><th>NWT39</th>
<td>Current number of SoftSpy server threads waiting for input from a user. Same as NWT63.</td></tr>

<tr><th>NWT40</th>
<td>Current number of threads waiting on MQ subtask to be available.</td></tr>

<tr><th>NWT41</th>
<td>Current number of threads waiting on MQ subtask to run.</td></tr>

<tr><th>NWT42</th>
<td>Current number of threads waiting on MQGET with wait time specified.</td></tr>

<tr><th>NWT43</th>
<td>Current number of threads waiting on ECF to LOAD/DELETE a module.</td></tr>

<tr><th>NWT44</th>
<td>Current number of threads waiting on external program to be free.</td></tr>

<tr><th>NWT45</th>
<td>Current number of threads waiting on ECF subtask to be free.</td></tr>

<tr><th>NWT46</th>
<td>Current number of threads waiting on external program to run.</td></tr>

<tr><th>NWT47</th>
<td>Current number of threads with a wait type of 47.</td></tr>

<tr><th>NWT48</th>
<td>Current number of threads with a wait type of 48.</td></tr>

<tr><th>NWT49</th>
<td>Current number of threads with a wait type of 49.</td></tr>

<tr><th>NWT50</th>
<td>Current number of threads waiting for HSM recall of a migrated dataset.</td></tr>

<tr><th>NWT51</th>
<td>Current number of threads waiting for share mode constraints db lock.</td></tr>

<tr><th>NWT52</th>
<td>Current number of threads waiting for share exc. constraints db lock.</td></tr>

<tr><th>NWT53</th>
<td>Current number of threads waiting for sub-tran cp processing to complete for this user.</td></tr>

<tr><th>NWT54</th>
<td>Current number of threads waiting on blocking file command to complete (sub-tran CP postponement).</td></tr>

<tr><th>NWT55</th>
<td>Current number of threads waiting on sub-tran CP CPTS timer.</td></tr>

<tr><th>NWT56</th>
<td>Current number of threads waiting on sub-tran CP scanner array.</td></tr>

<tr><th>NWT57</th>
<td>Current number of threads with a wait type of 57.</td></tr>

<tr><th>NWT58</th>
<td>Current number of threads with a wait type of 58.</td></tr>

<tr><th>NWT59</th>
<td>Current number of threads with a wait type of 59.</td></tr>

<tr><th>NWT60</th>
<td>Current number of threads with a wait type of 60.</td></tr>

<tr><th>NWT61</th>
<td>Current number of threads with a wait type of 61.</td></tr>

<tr><th>NWT62</th>
<td>Current number of threads waiting on a response from a SoftSpy server thread. Same as NWT38.</td></tr>

<tr><th>NWT63</th>
<td>Current number of SoftSpy server threads waiting for input from a user. Same as NWT39.</td></tr>

<tr><th>NWT64</th>
<td>Current number of threads with a wait type of 64.</td></tr>

<tr><th>NWT65</th>
<td>Current number of threads with a wait type of 65.</td></tr>

<tr><th>NWT66</th>
<td>Current number of threads with a wait type of 66.</td></tr>

<tr><th>NWT67</th>
<td>Current number of threads with a wait type of 67.</td></tr>

<tr><th>NWT68</th>
<td>Current number of threads with a wait type of 68.</td></tr>

<tr><th>NWT69</th>
<td>Current number of threads with a wait type of 69.</td></tr>

<tr><th>NWT70</th>
<td>Current number of threads with a wait type of 70.</td></tr>

<tr><th>NWT71</th>
<td>Current number of threads with a wait type of 71.</td></tr>

<tr><th>NWT72</th>
<td>Current number of threads with a wait type of 72.</td></tr>

<tr><th>NWT73</th>
<td>Current number of threads with a wait type of 73.</td></tr>

<tr><th>NWT74</th>
<td>Current number of threads with a wait type of 74.</td></tr>

<tr><th>NWT75</th>
<td>Current number of threads with a wait type of 75.</td></tr>

<tr><th>NWT76</th>
<td>Current number of threads with a wait type of 76.</td></tr>

<tr><th>NWT77</th>
<td>Current number of threads with a wait type of 77.</td></tr>

<tr><th>NWT78</th>
<td>Current number of threads with a wait type of 78.</td></tr>

<tr><th>NWT79</th>
<td>Current number of threads with a wait type of 79.</td></tr>

<tr><th>NWT80</th>
<td>Current number of threads with customer wait code 0.</td></tr>

<tr><th>NWT81</th>
<td>Current number of threads with customer wait code 1.</td></tr>

<tr><th>NWT82</th>
<td>Current number of threads with customer wait code 2.</td></tr>

<tr><th>NWT83</th>
<td>Current number of threads with customer wait code 3.</td></tr>

<tr><th>NWT84</th>
<td>Current number of threads with customer wait code 4.</td></tr>

<tr><th>NWT85</th>
<td>Current number of threads with customer wait code 5.</td></tr>

<tr><th>NWT86</th>
<td>Current number of threads with customer wait code 6.</td></tr>

<tr><th>NWT87</th>
<td>Current number of threads with customer wait code 7.</td></tr>

<tr><th>NWT88</th>
<td>Current number of threads with customer wait code 8.</td></tr>

<tr><th>NWT89</th>
<td>Current number of threads with customer wait code 9.</td></tr>

<tr><th>NWT90</th>
<td>Current number of threads with a wait type of 90.</td></tr>

<tr><th>NWT91</th>
<td>Current number of threads with a wait type of 91.</td></tr>

<tr><th>NWT92</th>
<td>Current number of threads with a wait type of 92.</td></tr>

<tr><th>NWT93</th>
<td>Current number of threads with a wait type of 93.</td></tr>

<tr><th>NWT94</th>
<td>Current number of threads with a wait type of 94.</td></tr>

<tr><th>NWT95</th>
<td>Current number of threads with a wait type of 95.</td></tr>

<tr><th>NWT96</th>
<td>Current number of threads with a wait type of 96.</td></tr>

<tr><th>NWT97</th>
<td>Current number of threads waiting on Fast/Unload request.</td></tr>

<tr><th>NWT98</th>
<td>Current number of threads waiting on MAXAUSER delay.</td></tr>

<tr><th>NWT99</th>
<td>Current number of threads waiting on SirFact quiesce.</td></tr>

<tr><th>NWT100</th>
<td>Current number of threads with a wait type of 100.</td></tr>

<tr><th>NWT101</th>
<td>Current number of threads with a wait type of 101.</td></tr>

<tr><th>NWT102</th>
<td>Current number of threads with a wait type of 102.</td></tr>

<tr><th>NWT103</th>
<td>Current number of threads with a wait type of 103.</td></tr>

<tr><th>NWT104</th>
<td>Current number of threads with a wait type of 104.</td></tr>

<tr><th>NWT105</th>
<td>Current number of threads with a wait type of 105.</td></tr>

<tr><th>NWT106</th>
<td>Current number of threads with a wait type of 106.</td></tr>

<tr><th>NWT107</th>
<td>Current number of threads with a wait type of 107.</td></tr>

<tr><th>NWT108</th>
<td>Current number of threads with a wait type of 108.</td></tr>

<tr><th>NWT109</th>
<td>Current number of threads with a wait type of 109.</td></tr>

<tr><th>OBJSWAP</th>
<td>SOAP ULI objects must be resident in a server area (VTBL and perhaps STBL) before they can be referenced. If a request accesses more objects than were allocated, objects are swapped from the server to CCATEMP. Rate or total.</td></tr>

<tr><th>OFFIN</th>
<td>Number of something (rate or total).</td></tr>

<tr><th>OFFOU</th>
<td>Number of something (rate or total).</td></tr>

<tr><th>OUT</th>
<td>Number of output lines to CCAPRINT - User 0 output.</td></tr>

<tr><th>OUTCMFS</th>
<td>Output lines from CMS full screen console - ALTIODEV 47 (rate or total).</td></tr>

<tr><th>OUTCMIO</th>
<td>Output lines from CMS non-full screen console - ALTIODEV 45 (rate or total).</td></tr>

<tr><th>OUTCRAM</th>
<td>Output lines from remote User Language threads (BATCH2, etc.) - IODEV 29. (rate or total).</td></tr>

<tr><th>OUTTTY</th>
<td>Output lines from BTAM teletypes - IODEV 15 (rate or total).</td></tr>

<tr><th>OUTVMFS</th>
<td>Output lines from VMCF or IUCV full screen threads - IODEV 41 (rate or total).</td></tr>

<tr><th>OUTVMIF</th>
<td>Arguments supplied by certain IFAM2 or IFMA4 calls from CMS programs - IODEV 43 (rate or total).</td></tr>

<tr><th>OUTVMIO</th>
<td>Output lines from VMCF or IUCV non-full screen threads - IODEV 39 (rate or total).</td></tr>

<tr><th>OUTXX</th>
<td>Output lines from QSAM users - IODEV 3 (rate or total).</td></tr>

<tr><th>OUT2265</th>
<td>Not used - IODEV 17 (total only).</td></tr>

<tr><th>OUT2741</th>
<td>Output lines from BTAM 2741s - IODEV 13 (rate or total).</td></tr>

<tr><th>OUT3275</th>
<td>Output lines from BTAM 3270s - IODEV 19 (rate or total).</td></tr>

<tr><th>PBRSFLT</th>
<td>Number of private buffer reserve faults. Each occurrence of this value indicates a user restart (rate or total).</td></tr>

<tr><th>PBUFAVL</th>
<td>Number of private buffers available.</td></tr>

<tr><th>PBUFMAX</th>
<td>Maximum number of private buffers that can be reserved.</td></tr>

<tr><th>PBUFUSE</th>
<td>The number of private buffers currently reserved.</td></tr>

<tr><th>PCPU</th>
<td>Percentage of CPU acquired when requested. This is a measure of how much other work on the CPU is adversely affecting the Online. PCPU of 100 means not at all.</td></tr>

<tr><th>PCPUC</th>
<td>CPU total, in milliseconds - numerator in PCPU calculations.</td></tr>

<tr><th>PCPUR</th>
<td>Runnable time total, in milliseconds - denominator in PCPU calculations.</td></tr>

<tr><th>PRCNPRE</th>
<td>Number of non-precompiled procedures in all active subsystems.</td></tr>

<tr><th>PRCPRE</th>
<td>Number of precompiled procedures in all active subsystems.</td></tr>

<tr><th>PRCPSVW</th>
<td>Number of server writes while running precompiled procedures in all active subsystems since they were started.</td></tr>

<tr><th>PRCRES</th>
<td>Number of resident precompiled procedures in all active subsystems.</td></tr>

<tr><th>PRCRESB</th>
<td>Number of bytes used by resident QTBL for procedures in all active subsystem.</td></tr>

<tr><th>PRCRESE</th>
<td>Number of procedures in all active subsystems that are eligible to use resident QTBL but were not able to obtain the required virtual storage.</td></tr>

<tr><th>PRCSAVE</th>
<td>Number of saved compilations for precompiled procedures in all active subsystems.</td></tr>

<tr><th>PRCSVWR</th>
<td>Number of server writes while running any procedure in all active subsystems.</td></tr>

<tr><th>RECADD</th>
<td>Records started in table B not including extension records (rate or total).</td></tr>

<tr><th>RECDEL</th>
<td>Records deleted from table B not including extension records (rate or total).</td></tr>

<tr><th>RECDS</th>
<td>Records processed by FOR LOOPS, SORTS, IFGETS, or IFPOINTS (rate or total).</td></tr>

<tr><th>RECENQH</th>
<td>High Water Mark (bytes) in record enqueuing table used.</td></tr>

<tr><th>RECENQP</th>
<td>Percent of record enqueueing table currently in use. Equal to 100 * (RECENQU / RECENQT).</td></tr>

<tr><th>RECENQQ</th>
<td>High Water Mark percentage of record enqueuing table used.</td></tr>

<tr><th>RECENQT</th>
<td>Total number of bytes in the record enqueueing table.</td></tr>

<tr><th>RECENQU</th>
<td>Total number of bytes currently in use in the record enqueueing table.</td></tr>

<tr><th>RECNQHH</th>
<td>High Water Mark number of record enqueuing headers used.</td></tr>

<tr><th>REDY</th>
<td>Performance statistic: Average number of users ready to run. Taken from the latest report printed by the performance subtask.</td></tr>

<tr><th>REDYA</th>
<td>Performance statistic: same as REDY but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>REDYT</th>
<td>Performance statistic: same as REDY but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>REQ</th>
<td>Requests executed or streams written to USE output (rate or total).</td></tr>

<tr><th>RESCURR</th>
<td>Number of bytes currently used for resident (shared) QTBL. This is the same as the viewable parameter by the same name.</td></tr>

<tr><th>RESEVAL</th>
<td>Number of evaluations for procedures in any subsystem using resident (shared) QTBL.</td></tr>

<tr><th>RESHIGH</th>
<td>High water mark of the number of bytes used for resident (shared) QTBL. This is the same as the viewable parameter by the same name.</td></tr>

<tr><th>RESP</th>
<td>Percentile response time for last 100 full screen terminal I/O's.
RESP must be requested as RESPxx, where "xx" is a 2-digit percentile.
RESP75 gives the 75th percentile response time, RESP90 gives the 90th percentile, etc. Stat $functions return milliseconds, SirMon displays seconds.</td></tr>

<tr><th>RESPAVG</th>
<td>Average response time for the last 100 full screen I/O's. Stat $functions return milliseconds, SirMon displays seconds.</td></tr>

<tr><th>RESPIND</th>
<td>Relative measure of system responsiveness (1.00 is ideal). This measure can be affected significantly by highly I/O bound batch jobs if there are relatively few users on the system.
See RESP, RESPAVG, and RESPMED for better responsiveness measures.</td></tr>

<tr><th>RESPMED</th><td>Median response time for the last 100 full screen I/O's. Stat $functions return milliseconds, SirMon displays seconds.</td></tr>

<tr><th>RESSIZE</th>
<td>Total number of bytes available for use for resident (shared) QTBL. This is the same as the settable/viewable parameter by the same name.</td></tr>

<tr><th>RESSWCH</th>
<td>Number of evaluations for procedures in any subsystem that had to switch from using resident (shared) QTBL to non-resident QTBL.</td></tr>

<tr><th>REST</th>
<td>Reads from a Model204 backup file resulting from a RESTORE command (rate or total).</td></tr>

<tr><th>RESTHRSH</th>
<td>Server wait threshold for making request resident.</td></tr>

<tr><th>RSXCOMP</th>
<td>Record enqueueing table compactions (rate or total). A non-zero value of RSXCOMP indicates that you should probably increase LRETBL.</td></tr>

<tr><th>RUNG</th>
<td>Performance statistic: Average number of users running. Taken from the latest report printed by the performance subtask.</td></tr>

<tr><th>RUNGA</th>
<td>Performance statistic: same as RUNG but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>RUNGT</th>
<td>Performance statistic: same as RUNG but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>SCHDCPU</th>
<td>Amount of scheduler CPU used by Model 204 in milliseconds. This value will be 0 unless the '1' bit of the SCHDOPT parameter is set (rate or total).</td></tr>

<tr><th>SCRNS</th>
<td>Full screen reads (rate or total) or text Web responses sent.</td></tr>

<tr><th>SDMACT</th>
<td>Current number of active sdaemons - this counts all Janus TCP/IP users as well as background sessions initiated by calls to $COMMBG, $COMMAND and $COMMNDL.</td></tr>

<tr><th>SDMACTH</th>
<td>High water mark for active sdaemons.</td></tr>

<tr><th>SDMACTM</th>
<td>Maximum number of active sdaemons allowed. This will match the NOTERM setting on the sdaemon IODEV (usually it is IODEV 15).</td></tr>

<tr><th>SDMFRE</th>
<td>Number of free (available) sdaemons - SDMACTM - SDMACT.</td></tr>

<tr><th>SDMFREL</th>
<td>Low water mark for number of free (available) sdaemons - SDMACTM - SDMACTH.</td></tr>

<tr><th>SDMUNAV</th>
<td>Number of times an sdaemon was required but unavailable (either for JANUS or a synchronous $COMM request). Does not include number of times an asynchronous $COMMBG request waited to acquire an sdaemon.</td></tr>

<tr><th>SFTRSTRT</th>
<td>Counts the number of times a soft user restart has occured (rate or total).</td></tr>

<tr><th>SLIC</th>
<td>Times users were time sliced (rate or total).</td></tr>

<tr><th>SMPLS</th>
<td>Samples in the last completed performance monitoring report.
SMPLS is used as the numerator in deriving performance monitor stats BLKI, BLKO, REDY, RUNG, SWPG, SVAC, USRS and WTSV. Always 0 if the performance monitoring subtask is not running.</td></tr>

<tr><th>SMPLSC</th>
<td>Performance statistic: same as SMPLS but for report currently being calculated.</td></tr>

<tr><th>SMPLST</th>
<td>Performance statistic: same as SMPLS but calculated since the beginning of the run.</td></tr>

<tr><th>SNAPID</th>
<td>Number of SNAP DUMPs that have occurred in the online.</td></tr>

<tr><th>SORTS</th>
<td>User Language SORT statements evaluated (rate or total).</td></tr>

<tr><th>SRSDEFT</th>
<td>Default timeout value for saved record sets and $lists. Same as the value of the eponymous system parameter.</td></tr>

<tr><th>SRSMAX</th>
<td>Maximum number of saved record sets and/or $lists in the system. Same as the value of the eponymous system parameter.</td></tr>

<tr><th>SRSMAXT</th>
<td>Maximum timeout value allowed for a saved record set or $list. Same as the value of the eponymous system parameter.</td></tr>

<tr><th>SRSMAXU</th>
<td>Maximum number of saved record sets and/or $lists per userid. Same as the value of the eponymous system parameter.</td></tr>

<tr><th>SRSNCUR</th>
<td>Current number of saved record set or $list slots used out of the SRSMAX slots available.</td></tr>

<tr><th>SRSNEXP</th>
<td>Number of saved record sets or $lists that were expired, that is deleted because they had not been referenced withing their timeout time (rate or total).</td></tr>

<tr><th>SRSNFUL</th>
<td>Number of saved record sets or $lists that could not be saved because there were already SRSMAX non-expired saved record sets or $lists
saved in the system and CANCEL or ERROR was in effect for $WEB_SAVE_RECSET or $WEB_SAVE_LIST calls (rate or total).</td></tr>

<tr><th>SRSNHGH</th>
<td>Highwater mark of saved record set or $list slots used out of the SRSMAX slots available.</td></tr>

<tr><th>SRSNRST</th>
<td>Number of record sets or $lists restored via $WEB_REST_RECSET or $WEB_REST_LIST calls (rate or total).</td></tr>

<tr><th>SRSNSAV</th>
<td>Number of record sets or $lists saved via $WEB_SAVE_RECSET or $WEB_SAVE_LIST calls (rate or total).</td></tr>

<tr><th>SRSNSTL</th>
<td>Number of saved record sets or $lists that were stolen, that is deleted before their timeout time, because another user did a $WEB_SAVE_RECSET or $WEB_SAVE_LIST with STEAL
in effect and the maximum saved record sets and $lists (SRSMAX) were already saved.</td></tr>

<tr><th>SRSNSUS</th>
<td>Number of saved record sets or $lists that were stolen, that is deleted before their timeout time, because a userid did a $WEB_SAVE_RECSET or $WEB_SAVE_LIST with USTEAL
in effect and the maximum saved record sets and $lists (SRSMAXUS) were already saved by the userid (rate or total).</td></tr>

<tr><th>SRSNULM</th>
<td>Number of saved record sets or $lists that could not be saved because there were already SRSMAXUS non-expired saved record sets or $lists saved by the userid and UCANCEL or UERROR was
in effect for $WEB_SAVE_RECSET or $WEB_SAVE_LIST calls (rate or total).</td></tr>

<tr><th>SRSSAVG</th>
<td>Average age in seconds of saved record sets or $lists stolen because a user did a $WEB_SAVE_RECSET or $WEB_SAVE_LIST and the system limit of saved record sets and $lists (SRSMAX) had been hit and STEAL was
in effect for the indicated $function calls.</td></tr>

<tr><th>SRSSMIN</th>
<td>Minimum age in seconds of saved record sets or $lists stolen because a user did a $WEB_SAVE_RECSET or $WEB_SAVE_LIST and the system limit of saved record sets and $lists (SRSMAX)
had been hit and STEAL was in effect for the indicated $function calls.</td></tr>

<tr><th>SRSUAVG</th>
<td>Average age in seconds of saved record sets or $lists stolen because a user did a $WEB_SAVE_RECSET or $WEB_SAVE_LIST and the user limit of saved record sets and $lists (SRSMAXUS)
had been hit and USTEAL was in effect for the indicated $function calls.</td></tr>

<tr><th>SRSUMIN</th>
<td>Minimum age in seconds of saved record sets or $lists stolen because a user did a $WEB_SAVE_RECSET or $WEB_SAVE_LIST and the user limit of saved record sets and $lists (SRSMAXUS)
had been hit and USTEAL was in effect for the indicated $function calls.</td></tr>

<tr><th>STCPU</th>
<td>Amount of CPU used by offload subtasks in milliseconds - stat $functions return milliseconds, SirMon displays seconds (rate or total).</td></tr>

<tr><th>STDEQ</th>
<td>Number of work units removed from offload queue by offload subtasks (rate or total).
A high ratio of STDEQ to STCPU could indicate an MP mode switch thrashing situation.
For a 60 MIP processor, a ratio of 2 might be high - faster processors should have lower rations.</td></tr>

<tr><th>STIMERS</th>
<td>Number of operating system STIMERS issued by Model 204 (rate or total).</td></tr>

<tr><th>STORAG</th>
<td>Total number of bytes of virtual storage currently allocated by Model 204.</td></tr>

<tr><th>STORAGH</th>
<td>High water mark for total number of bytes of virtual storage allocated by Model 204.</td></tr>

<tr><th>STORAGI</th>
<td>Total number of bytes of virtual storage allocated by Model 204 during initialization.</td></tr>

<tr><th>STORG24</th>
<td>Total number of bytes of 24 bit ("below the line") virtual storage currently allocated by Model 204.</td></tr>

<tr><th>STORG31</th>
<td>Total number of bytes of 31 bit ("above the line") virtual storage currently allocated by Model 204.</td></tr>

<tr><th>STPOST</th>
<td>Total number of POST SVCs issued to transfer work to/from offload subtasks (rate or total).</td></tr>

<tr><th>STRECDS</th>
<td>Records sorted in SORT statement evaluation (rate or total).</td></tr>

<tr><th>STWAIT</th>
<td>Total number of times offload subtasks issued a WAIT SVC to wait for work from the maintask (rate or total).</td></tr>

<tr><th>STZDEQ</th>
<td>Number of items taken by MP from zIIP queue. Rate or total. Before Model 204 Version 7.4 always returns 0. To see non-zero results for STZDEQ you must turn off SCHDOPT x'40'. SCHDOPT x'40' prevents a subtask from 'stealing' from zIIP.</td></tr>

<tr><th>SVAC</th>
<td>Performance statistic: Average number of active servers. Taken from the latest report printed by the performance subtask.</td></tr>

<tr><th>SVACA</th>
<td>Performance statistic: same as SVAC but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>SVACT</th>
<td>Performance statistic: same as SVAC but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>SVIO</th>
<td>Server reads and writes (rate or total). Equal to SVRD+SVWR.</td></tr>

<tr><th>SVMX</th>
<td>Performance statistic: High water mark of active servers.</td></tr>

<tr><th>SVPAGES</th>
<td>Number of 4K pages of server data swapped in or out by Model204.</td></tr>

<tr><th>SVRD</th>
<td>Server reads (rate or total).</td></tr>

<tr><th>SVWR</th>
<td>Server writes (rate or total).</td></tr>

<tr><th>SWPG</th>
<td>Performance statistic: Average number of users in transit to or from a server. Taken from the latest report printed by the performance subtask.</td></tr>

<tr><th>SWPGA</th>
<td>Performance statistic: same as SWPG but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>SWPGT</th>
<td>Performance statistic: same as SWPG but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>SWT</th>
<td>Number of real waits while not in user switching mode (rate or total).</td></tr>

<tr><th>TCON</th>
<td>TCAM congested queue returns (rate or total).</td></tr>

<tr><th>TCPBACT</th>
<td>Number of active Janus connections.</td></tr>

<tr><th>TCPBBR</th>
<td>Number of bytes read on Janus connections (rate or total).</td></tr>

<tr><th>TCPBBW</th>
<td>Number of bytes written on Janus connections (rate or total).</td></tr>

<tr><th>TCPBNBW</th>
<td>Number of blocked writes on Janus connections.
These are writes that could not be issued immediately but had to wait for notification from the TCPIP address space that sufficient buffer space had been cleared.
Blocked writes can be caused by network bottlenecks or applications that don't immediately accept output data (rate or total).</td></tr>

<tr><th>TCPBNR</th>
<td>Number of reads on Janus connections. (rate or total).</td></tr>

<tr><th>TCPBNW</th>
<td>Number of writes on Janus connections (rate or total).</td></tr>

<tr><th>TCPCON</th>
<td>Current number of active Janus connections.</td></tr>

<tr><th>TCPCONH</th>
<td>High water mark for number of Janus connections.</td></tr>

<tr><th>TCPCONL</th>
<td>Number of licensed Janus connections.</td></tr>

<tr><th>TCPCONM</th>
<td>Smaller of either the number of licensed Janus connections or the number of sdaemons allocated to the online.</td></tr>

<tr><th>TCPFRE</th>
<td>Number of free Janus connections (TCPCONM - TCPCON).</td></tr>

<tr><th>TCPFREL</th>
<td>Low water mark for number of free connections (TCPCONM - TCPCONH)</td></tr>

<tr><th>TCPREF</th>
<td>Number of Janus connections refused due to some limit: MAXCON, licensed connections, or storage.</td></tr>

<tr><th>TFMX</th>
<td>High water mark of CCATEMP pages in use.</td></tr>

<tr><th>TQWT</th>
<td>TCAM write waits (rate or total).</td></tr>

<tr><th>TSMX</th>
<td>Highest CCATEMP page number in use from small model area.</td></tr>

<tr><th>UBCUR</th>
<td>Total number of bytes currently allocated for Universal Buffers.</td></tr>

<tr><th>UBHWM</th>
<td>High water mark for storage allocated for Universal Buffers.</td></tr>

<tr><th>UPTRANS</th>
<td>Number of updating transactions started (rate or total).</td></tr>

<tr><th>USMX</th>
<td>Performance statistic: Highwater mark of logged on users.</td></tr>

<tr><th>USRS</th>
<td>Performance statistic: Average number of simultaneously logged on users. Taken from the latest report printed by the performance monitoring subtask.</td></tr>

<tr><th>USRSA</th>
<td>Performance statistic: same as USRS but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>USRST</th>
<td>Performance statistic: same as USRS but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>UTI>50</th>
<td>Number of user screen requests that came in greater than 50 seconds after the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI0.1</th>
<td>Number of user screen requests that came in less than 0.1 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI0.25</th>
<td>Number of user screen requests that came in between 0.1 and 0.25 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI0.5</th>
<td>Number of user screen requests that came in between 0.25 and 0.5 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI1</th>
<td>Number of user screen requests that came in between 0.5 and 1 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI10</th>
<td>Number of user screen requests that came in between 5 and 10 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI15</th>
<td>Number of user screen requests that came in between 10 and 15 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI2</th>
<td>Number of user screen requests that came in between 1 and 2 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI20</th>
<td>Number of user screen requests that came in between 15 and 20 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI30</th>
<td>Number of user screen requests that came in between 20 and 30 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI5</th>
<td>Number of user screen requests that came in between 2 and 5 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>UTI50</th>
<td>Number of user screen requests that came in between 30 and 50 seconds of the previous Model 204 response (rate or total). Always 0 unless the X'08' bit is set in the system MONPARM parameter.</td></tr>

<tr><th>VTAMBW</th>
<td>VTAM buffer waits (rate or total). Equal to VTAMBWI+VTAMBWO. A non-zero value for VTAMBW means that you should probably consider increasing TERMBUF.</td></tr>

<tr><th>VTAMBWI</th>
<td>VTAM buffer waits for input (rate or total). A non-zero value for VTAMBWI means that you should probably consider increasing TERMBUF.</td></tr>

<tr><th>VTAMBWO</th>
<td>VTAM buffer waits for output (rate or total). A non-zero value for VTAMBWO means that you should probably consider increasing TERMBUF.</td></tr>

<tr><th>VTAMWW</th>
<td>VTAM write waits (rate or total).</td></tr>

<tr><th>WAIT</th>
<td>Real waits (rate or total).</td></tr>

<tr><th>WTSV</th>
<td>Performance statistic: Average number of users waiting for a server. Taken from the latest report printed by the performance monitoring subtask.</td></tr>

<tr><th>WTSVA</th>
<td>Performance statistic: same as WTSV but calculated by weighting samples in the current performance interval with the latest report finished by the performance monitoring subtask.</td></tr>

<tr><th>WTSVT</th>
<td>Performance statistic: same as WTSV but calculated across all performance monitoring samples since the beginning of the run.</td></tr>

<tr><th>ZTDEQ</th>
<td>Number of items taken by zIIP from zIIP queue. Rate or total. Before Model 204 Version 7.4, always returns 0.</td></tr>
</table>

==See also==
{{Template:SirMon topic list}}

[[Category: SirMon]]

Using system statistics

2024-10-09T22:50:59Z

Goff: Add description for JSCREENS and JWEBERRS (copy from SIRMON descritpion)

==Overview==

The tables on this page are provided for your use in identifying and tracking statistics that are reported by <var class="product">Model 204</var> in various situations. The offsets, given in decimal and hexadecimal, are to help you locate particular statistics within statistical output. The length is in bytes.

The statistics are collected in the [[Tracking_system_activity_(CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAJRNL|CCAJRNL]] data set, or if allocated, in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAAUDIT and CCAJLOG|CCAJLOG]]. The offsets in the tables below locate each statistic in the corresponding record. To accommodate sites that need to run <var class="product">Model 204</var> around the clock for many days at a time, space for most <var class="product">Model 204</var> statistics is a double word.

==Description of statistics==

The "Statistics with descriptions" table lists the statistics that are collected and that you can evaluate. It also describes the purpose of each statistic followed by the circumstances when you can collect the information and an offset in the journal record. 

To collect several statistics you must preset a parameter to a nonzero value. Statistics that require a parameter are also noted in the "Statistics with descriptions" table. The table in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Setting parameters to collect certain statistics]] lists those statistics with the required parameter. 

Tables, identified by type, later in this topic, describe the layouts of the various journal records.
<table>
<caption style="margin-right:4em">Statistics with descriptions</caption>
<tr class="head">
<th>Statistic </th>
<th>Records...</th>
</tr>

<tr>
<td>APSYLD</td>
<td>Number of APSY loads</td>
</tr>

<tr>
<td>APSYLDD</td>
<td>Number of APSY loads from a dataspace</td>
</tr>

<tr>
<td>APSYLDT</td>
<td>Number of tiny APSY loads</td>
</tr>

<tr>
<td>AUDIT</td>
<td>Number of lines written to the journal and/or the audit trail</td>
</tr>

<tr>
<td>BACKOUTS</td>
<td>Number of BACKOUTs</td>
</tr>

<tr>
<td>BADD</td>
<td>Number of fields added to Table B</td>
</tr>

<tr>
<td>BCHG</td>
<td>Number of fields changed in Table B</td>
</tr>

<tr>
<td>BDEL</td>
<td>Number of fields deleted from Table B</td>
</tr>

<tr>
<td>BLKCFRE</td>
<td>Number of times user held a critical file resource (CFR) exclusively and forced another user to wait

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKI</td>
<td>Percentage of performance samples at which the user was in a server but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKO</td>
<td>Percentage of performance samples at which the user was swapped out to the server data set but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKRLK</td>
<td>Number of times user was the first user identified as blocking another from obtaining a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BXCHNG</td>
<td>Number of value entries changed in the ordered index. This occurs when a record number is added to or removed from an existing value entry.</td>
</tr>

<tr>
<td>BXDELE</td>
<td>Number of value entries deleted from the ordered index</td>
</tr>

<tr>
<td>BXFIND</td>
<td>Number of ordered index searches to locate field name=value pairs in the ordered index</td>
</tr>

<tr>
<td>BXFREE</td>
<td>Number of ordered index pages (nodes) emptied and released from the ordered index</td>
</tr>

<tr>
<td>BXINSE</td>
<td>Number of new value entries inserted into the ordered index</td>
</tr>

<tr>
<td>BXNEXT</td>
<td>Number of value entries touched in the ordered index during a range retrieval</td>
</tr>

<tr>
<td>BXRFND</td>
<td>Number of times the cursor was repositioned in the ordered index during a search</td>
</tr>

<tr>
<td>BXSPLI</td>
<td>Number of Table D pages (nodes) split in the ordered index</td>
</tr>

<tr>
<td>CCATDIFF</td>
<td>Difference between CCATEMP pages allocated and freed by a thread. This is an imperfect indicator of the number of CCATEMP pages a thread has allocated. CCATDIFF is imperfect because it is difficult to fully account for pages allocated or freed on behalf of the system or other users. However, if there is an acute CCATEMP page shortage, threads with high CCATDIFF values are likely culprits.

CCATDIFF is available in Model 204 7.7 and higher.</td>
</tr>

<tr>
<td>CCATDIFH</td>
<td>High water mark of CCATDIFF in a request. This can be useful if a request allocated a lot of CCATEMP pages, causing an acute shortage but then freed those pages.

CCATDIFH is available in Model 204 7.7 and later.</td>
</tr>

<tr>
<td>CDLWAIT</td>
<td>Number of constraint dependency lock waits</td>
</tr>

<tr>
<td>CNCT</td>
<td>Elapsed time in seconds</td>
</tr>

<tr>
<td>COMMITS</td>
<td>Number of <var>COMMIT</var>s</td>
</tr>

<tr>
<td>CPU</td>
<td>Total CPU time consumed in milliseconds. The system CPU statistics include both maintask and subtask CPU usage.</td>
</tr>

<tr>
<td>CPUONZIP</td>
<td>Total CPU time consumed in milliseconds on zIIP engines</td>
</tr>

<tr>
<td>CPUTOTZE</td>
<td>Total CPU time consumed in milliseconds by workloads eligible for offload to zIIP engines</td>
</tr>

<tr>
<td>DEQ</td>
<td>Total number of units of work taken by the MAINTASK and each MP and zIIP subtask, regardless of the queue that the work was taken from. Reported at <var class="product">Model 204</var> termination or in <var>[[MONITOR TASKS command|MONITOR TASKS]]</var> output.

(type Subtask)
</td>
</tr>

<tr>
<td>DEV#</td>
<td>used the MXI interface to hold the IODEV type ( e.g. 7 for IODEV7 )</td>
</tr>

<tr>
<td>DEV5</td>
<td>Output lines to procedures defined during the run</td>
</tr>

<tr>
<td>DEV6</td>
<td>Input lines from included procedures</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly VTAM) 3270s</td>
</tr>

<tr>
<td>DEV8</td>
<td>Input lines from SNA Communications Server 3270s</td>
</tr>

<tr>
<td>DEV9</td>
<td>Page headers or trailers defined in requests</td>
</tr>

<tr>
<td>DEV10</td>
<td>Output lines written to directed output (USE) data sets</td>
</tr>

<tr>
<td>DEV11</td>
<td>Output lines to remote User Language full screen</td>
</tr>

<tr>
<td>DEV12</td>
<td>Input lines from a remote User Language full screen</td>
</tr>

<tr>
<td>DEV13</td>
<td>Output lines to remote SQL</td>
</tr>

<tr>
<td>DEV14</td>
<td>Input lines from remote SQL</td>
</tr>

<tr>
<td>DEV17</td>
<td>Output lines to SQL CRAM IUCU</td>
</tr>

<tr>
<td>DEV18</td>
<td>Input lines from SQL CRAM</td>
</tr>

<tr>
<td>DEV19</td>
<td>Output lines to remote SQL LU62</td>
</tr>

<tr>
<td>DEV20</td>
<td>Input lines from remote SQL LU62</td>
</tr>

<tr>
<td>DEV23</td>
<td>Input lines to CRAM IFAM</td>
</tr>

<tr>
<td>DEV24</td>
<td>Input lines from CRAM IUCU thread</td>
</tr>

<tr>
<td>DEV27</td>
<td>Terminal error messages issued for inbound Distributed Application Facility conversations</td>
</tr>

<tr>
<td>DEV28</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV31</td>
<td><var>IFDISP</var> output lines to IFAM1 programs</td>
</tr>

<tr>
<td>DEV32</td>
<td>Input arguments supplied by certain IFAM1 calls</td>
</tr>

<tr>
<td>DEV37</td>
<td>Output lines to SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV38</td>
<td>Input lines from SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV49</td>
<td>output lines to Remote Command line applications( rate or total)</td>
</tr>

<tr>
<td>DEV50</td>
<td>Lines sent to the printer when ROUTER=CICS</td>
</tr>

<tr>
<td>DEV53</td>
<td>Output lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV54</td>
<td>Input lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV55</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV56</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV57</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV58</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV59</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV60</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV61</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV62</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV63</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM parameter|MONPARM]] system parameter.</td>
</tr>

<tr>
<td>DEV64</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV65</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV66</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV67</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV68</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV69</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly
VTAM) 3270s</td>
</tr>

<tr>
<td>DEV70</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV71</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV72</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV73</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV74</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DIRRCD</td>
<td>Number of records searched in direct searches of Table B</td>
</tr>

<tr>
<td>DKAR</td>
<td>Number of buffers allocated without page read requests</td>
</tr>

<tr>
<td>DKPR</td>
<td>Number of requests for a page (may not require real I/O)</td>
</tr>

<tr>
<td>DKPRF</td>
<td>Number of fast logical page reads. Number of DKPRs that were satisfied by pending or deferred close buffers</td>
</tr>

<tr>
<td>DKRD</td>
<td>Number of physical page reads from Model 204 files</td>
</tr>

<tr>
<td>DKRDL</td>
<td>Number of physical page reads into the below the bar buffer pool</td>
</tr>

<tr>
<td>DKRR</td>
<td> Number of real disk reads for recently requested pages
</td>
</tr>

<tr>
<td>DKSAWB</td>
<td> Anticipatory writes from the bottom of the LRU queue. The page in the buffer is then deleted and no longer available without a re-read. Usually a small statistic and typically only incremented by a few rare events.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWBL</td>
<td> Same as DKSAWB but only incremented for anticipatory writes from below the bar

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWW</td>
<td> Anticipatory writes from the anticipatory write windows set by LDKBMWND and/or LDKBMWNG

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWWL</td>
<td>Same as DKSAWW but only incremented for anticipatory writes from below the bar</td>
</tr>

<tr>
<td>DKSDIR</td>
<td> High-water mark of modified (dirty) buffers found within the DKBM statistics window which is created by the <var>LDKBMW</var> parameter. This parameter is not recommended due to the extremely heavy performance penalty imposed by a non-zero value.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSDIRT</td>
<td> The total of all modified buffers found within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSFBS</td>
<td> Times a buffer was needed, and a scan was necessary, because the oldest free buffer was not immediately available

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIP</td>
<td> The highest number of buffers skipped during any search for a free buffer. A buffer is skipped because it is not immediately available.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIPT</td>
<td> The total of all buffers skipped when looking for a free buffer

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRR</td>
<td> Number of times a page that was expected to be in the buffer pool could not be located, which necessitates a physical I/O to disk

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRRFND</td>
<td>Number of times that a page that was expected to be in the buffer pool was located there, which eliminates the need for a physical I/O</td>
</tr>

<tr>
<td>DKSTBLA</td>
<td> Table A reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLB</td>
<td> Table B reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLC</td>
<td> Table C reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLD</td>
<td> Table D reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DSKTBLE</td>
<td> Table E reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLF</td>
<td> FCT reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTKQC</td>
<td> Times the current Table B page had to be closed to allow a fourth buffer to be opened

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSWRP</td>
<td> The highwater mark of buffers with writes outstanding within the DKBM statistics window, created by the parameter LDKBMW. Rocket Software advises against setting this parameter to a non-zero value due to the extreme performance penalty imposed.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSWRPT</td>
<td> The total number of buffers with outstanding writes within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKUPTIME</td>
<td>Milliseconds of DKUPDT time</td>
</tr>

<tr>
<td>DKWR</td>
<td>Number of physical page writes to <var class="product">Model 204</var> files</td>
</tr>

<tr>
<td>DKWRL</td>
<td>Number of physical page writes from the below the bar pool</td>
</tr>

<tr>
<td>DKWTMICS</td>
<td>Total wait time in microseconds for Disk I/O waits counted by DKWTS.
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DKWTS</td>
<td>Number Disk I/O waits
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DUMP</td>
<td>Writes to <var class="product">Model 204</var> file backups (DUMP command output)</td>
</tr>

<tr>
<td>DUPDTS</td>
<td>Records written to a deferred update data set for the file</td>
</tr>

<tr>
<td>ECCALL</td>
<td>Number of External Call Facility calls</td>
</tr>

<tr>
<td>ECCNCT</td>
<td>External Call Facility - Elapsed time for external program</td>
</tr>

<tr>
<td>ECCTOUT</td>
<td>Number of External Call Facility calls that timed out (program or subtask unavailable)</td>
</tr>

<tr>
<td>ECCWAITM</td>
<td>ECF – Number of calls that waited for module to become available</td>
</tr>

<tr>
<td>ECCWAITS</td>
<td>Number of External Call Facility calls that waited for a subtask to become available</td>
</tr>

<tr>
<td>ECDELETE</td>
<td>Number of EXTERNAL DELETE calls to External Call Facility</td>
</tr>

<tr>
<td>ECLOAD</td>
<td>Number of EXTERNAL LOAD calls to External Call Facility</td>
</tr>

<tr>
<td>ECMODMAX</td>
<td>ECF – Highwater mark of modules loaded</td>
</tr>

<tr>
<td>ECNAMMAX</td>
<td>External Call Facility – High-water mark of call names defined</td>
</tr>

<tr>
<td>ECTSKMAX</td>
<td>External Call Facility – High-water mark of subtasks active</td>
</tr>

<tr>
<td>ECTWAITM</td>
<td>External Call Facility – Elapsed time spent waiting for a module to become available</td>
</tr>

<tr>
<td>ECTWAITS</td>
<td>External Call Facility – Elapsed time spent waiting for a subtask to become available</td>
</tr>

<tr>
<td>ERRPDL</td>
<td>Highwater mark of the system pushdown list</td>
</tr>

<tr>
<td>FBMX</td>
<td>disk buffer hwm</td>
</tr>

<tr>
<td>FBWT</td>
<td>Number of waits for a disk buffer</td>
</tr>

<tr>
<td>FINDS</td>
<td>Number of FIND statements evaluated</td>
</tr>

<tr>
<td>FSCB</td>
<td>High-water mark of bytes used in the FSCB</td>
</tr>

<tr>
<td>FSCBSW</td>
<td>Number of full-screen buffer swaps</td>
</tr>

<tr>
<td>FTBL</td>
<td>Highwater mark of FTBL appearing in CMPL and EVAL lines for requests containing a field name reference in group context. If one or more groups are opened but no field name references are made, the portion of FTBL used by the open groups is not reported.</td>
</tr>

<tr>
<td>GTBL</td>
<td>Highwater mark of GTBL</td>
</tr>

<tr>
<td>GTBLRS</td>
<td>Number of GTBL rearrangements required to add a global object</td>
</tr>

<tr>
<td>GTBLRU</td>
<td>Number of GTBL rearrangements required to add a global string variable</td>
</tr>

<tr>
<td>HEAP</td>
<td>Dynamic memory highwater mark</td>
</tr>

<tr>
<td>HRDRSTRT</td>
<td>number of hard restarts</td>
</tr>

<tr>
<td>IN</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>INCMFS</td>
<td>Input lines from CMS full screen</td>
</tr>

<tr>
<td>INCMIO</td>
<td>Input lines from CMS non-full screen</td>
</tr>

<tr>
<td>INCRAM</td>
<td>Input lines from Remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>INVMFS</td>
<td>Input lines from IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>INVMIF</td>
<td>Input arguments supplied by certain IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>INVMIO</td>
<td>Input lines from IUCV or VMCF non-full screen thread</td>
</tr>

<tr>
<td>INXX</td>
<td>Input lines from QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>ITBL</td>
<td>Highwater mark of ITBL</td>
</tr>

<tr>
<td>IXADD</td>
<td>Number of index entries added to Tables C and D, including attempts to add duplicates</td>
</tr>

<tr>
<td>IXDEL</td>
<td>Number of entries deleted from Tables C and D</td>
</tr>

<tr>
<td>JSCREENS</td>
<td>Counts the number of times Janus Web incremented the SCREENS statistic. Since these may occur outside of request context, they would not necessarily have corresponding Since-Last statistics.</td>
</tr>

<tr>
<td>JWEBERRS</td>
<td>Counts the number of times that Janus Web returned a 4xx status code. Note that these would not be counted in the SCREENS statistic, but it is handy to know that for example a bunch of 404 or 401 errors are occurring.</td>
</tr>

<tr>
<td>LKPOST</td>
<td>Times an MP subtask posted another task to indicate that an MP lock had become available</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>Times MP subtasks invoked z/OS WAIT macros to wait for an available MP lock</td>
</tr>

<tr>
<td>LONGUPDTIME(MS)</td>
<td> Total milliseconds of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LONGUPDTS</td>
<td> Number of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LWTIM</td>
<td>Elapsed time (ms), spent waiting for a multiprocessing lock. Reported for each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals).</td>
</tr>

<tr>
<td>MAXIOX</td>
<td>Number of times <var class="product">Model 204</var> waited for a free database buffer</td>
</tr>

<tr>
<td>MBO</td>
<td>Highwater mark of transaction backout pages

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MCP
</td>
<td>Highwater mark of transaction checkpoint spans

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MOVE</td>
<td>Number of times the scheduler switched from one user to another</td>
</tr>

<tr>
<td>MPHASHD</td>
<td>MP duplicate hash entries found</td>
</tr>

<tr>
<td>MPLKPREM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting due to operating system preemption.

This is the elapsed time between when an MP lock becomes available (lock post) making a task ready to run, and when the task actually gets the CPU. That preemption delay is caused by the operating system dispatching other tasks ahead of this task.

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPLKWTIM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting for MP locks

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPR</td>
<td>Highwater mark of transaction pre-images

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MQAPICNT</td>
<td>MQ/204 – Count of MQ/Series API calls</td>
</tr>

<tr>
<td>MQAPITIM </td>
<td>MQ/204 – Elapsed time of MQSeries API calls</td>
</tr>

<tr>
<td>MQBYTEIN</td>
<td>MQ/204 – Total bytes retrieved (MQGET)</td>
</tr>

<tr>
<td>MQBYTEOU</td>
<td>MQ/204 – Total bytes sent (MQPUT/MQPUT1)</td>
</tr>

<tr>
<td>MQGETS</td>
<td>MQ/204 – Number of MQGETs performed</td>
</tr>

<tr>
<td>MQGWTCNT</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTSUC</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait that succeeded</td>
</tr>

<tr>
<td>MQGWTTIM</td>
<td>MQ/204 – Elapsed time for MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTTSP</td>
<td>MQ/204 – Total wait time specified on MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQHWQU</td>
<td>MQ/204 – High-water mark of queues concurrently in use</td>
</tr>

<tr>
<td>MQHWTASK</td>
<td>MQ/204 – High-water mark of MQ/204 subtasks in use</td>
</tr>

<tr>
<td>MQNUMQM</td>
<td>MQ/204 – Number of distinct queue managers connected</td>
</tr>

<tr>
<td>MQNUMQU</td>
<td>MQ/204 – Number of distinct queues accessed</td>
</tr>

<tr>
<td>MQPUTS</td>
<td>MQ/204 – Number of MQPUTs performed</td>
</tr>

<tr>
<td>MQWTM</td>
<td>Mean queue wait time, the average time a subtask spent waiting for work (waiting for PCBs to come into the offload queue)</td>
</tr>

<tr>
<td>MTDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from the MAINTASK queue and processed it</td>
</tr>

<tr>
<td>MTSDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from an MP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>MTZDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from a zIIP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>NTBL</td>
<td>Highwater mark of NTBL</td>
</tr>

<tr>
<td>OBJSWAP</td>
<td>number of object swaps for Sirius objects</td>
</tr>

<tr>
<td>OFFIN</td>
<td>Count of records read in by the OFFLOAD subtask</td>
</tr>

<tr>
<td>OFFOU</td>
<td>Count of records written to the OFFLOAD stream</td>
</tr>

<tr>
<td>OUT</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>OUTCMFS</td>
<td>Output lines to CMS full-screen thread</td>
</tr>

<tr>
<td>OUTCMIO</td>
<td>Output lines to CMS line-by-line thread</td>
</tr>

<tr>
<td>OUTCRAM</td>
<td>Output lines from remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>OUTPB</td>
<td>Highwater mark of OUTPB</td>
</tr>

<tr>
<td>OUTVMFS</td>
<td>Output lines to IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>OUTVMIF</td>
<td>Output lines to IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>OUTVMIO</td>
<td>Output lines to IUCV or VMCF line-by-line threads</td>
</tr>

<tr>
<td>OUTXX</td>
<td>Output lines to QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>PBRSFLT</td>
<td>Number of private buffer reservation faults</td>
</tr>

<tr>
<td>PCPU</td>
<td>Percentage of time <var class="product">Model 204</var> was given the CPU when it wanted CPU time. In an MP environment, system PCPU is the sum of CPU time in all tasks divided by the sum of elapsed time in all tasks.</td>
</tr>

<tr>
<td>PDL</td>
<td>Highwater mark of the pushdown list</td>
</tr>

<tr>
<td>PETIM</td>
<td>Elapsed time (ms), spent waiting due to OS preemption. Reported for the MAINTASK and each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals)</td>
</tr>

<tr>
<td>PNDGTIME</td>
<td>Milliseconds of unnecessary broken time</td>
</tr>

<tr>
<td>PR</td>
<td>Real time consumed, in milliseconds. PCPU = CPU / PR.</td>
</tr>

<tr>
<td>QTBL</td>
<td>Highwater mark of QTBL</td>
</tr>

<tr>
<td>RCV</td>
<td>Number of blocks needed for subtransaction recovery

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>RECADD</td>
<td>Number of records started in Table B, not including extension records</td>
</tr>

<tr>
<td>RECDEL</td>
<td>Number of records deleted from Table B, not including extension records or records deleted by DELETE RECORDS or IFDSET</td>
</tr>

<tr>
<td>RECDS</td>
<td>Number of records processed by FOR statements, SORT statements, IFGET calls, or IFPOINT calls, or similar SQL record processing</td>
</tr>

<tr>
<td>REDY</td>
<td> Percentage of performance samples at which the user was ready to run (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>REQ</td>
<td>Number of SOUL requests evaluated</td>
</tr>

<tr>
<td>REST</td>
<td>Number of reads from a <var class="product">Model 204</var> file backup (<var>RESTORE</var> command)</td>
</tr>

<tr>
<td>RETRYA</td>
<td>Page retries in Table A</td>
</tr>

<tr>
<td>RETRYC</td>
<td>Page retries in Table C</td>
</tr>

<tr>
<td>RQTM</td>
<td>Elapsed time for the activity being reported, exclusive of terminal I/O time</td>
</tr>

<tr>
<td>RSXCOMP</td>
<td>Number of compactions of the record locking table. If greater than 0, increase <var>LRETBL</var>.</td>
</tr>

<tr>
<td>RUNG</td>
<td> Percentage of performance samples at which the user was running (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SCHDCPU</td>
<td>In MP configuration, total scheduler CPU for the user or request</td>
</tr>

<tr>
<td>SCREENS</td>
<td>Total number of full-screen reads (<var>READ SCREEN</var> statements) evaluated by a SOUL request.</td>
</tr>

<tr>
<td>SFTRSTRT</td>
<td>number of soft restarts.</td>
</tr>

<tr>
<td>SGMTI</td>
<td>Number of input lines from included procedures</td>
</tr>

<tr>
<td>SGMTO</td>
<td>Number of output lines to procedures defined by the user</td>
</tr>

<tr>
<td>SLIC</td>
<td>Number of times that the user was time-sliced by the <var class="product">Model 204</var> scheduler</td>
</tr>

<tr>
<td>SMPLS</td>
<td>Number of performance sample points at which the user was active or total number of performance samples taken at the system level (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SORTS</td>
<td>Number of SOUL <var>SORT</var> statements or SQL sorts evaluated</td>
</tr>

<tr>
<td>SQLI</td>
<td>Remote SQL input highwater mark</td>
</tr>

<tr>
<td>SQLO</td>
<td>Remote SQL output highwater mark</td>
</tr>

<tr>
<td>SQRD</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>SQWR</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>STBL</td>
<td>Highwater mark of STBL</td>
</tr>

<tr>
<td>STCPU</td>
<td>Total amount of time, in milliseconds, that the user has run in an MP offload subtask</td>
</tr>

<tr>
<td>STDEQ</td>
<td>Number of times that an MP subtask took a unit of work from an MP subtask queue and processed it</td>
</tr>

<tr>
<td>STIMERS</td>
<td>Total number of STIMER or STIMERM calls</td>
</tr>

<tr>
<td>STPOST</td>
<td>Times MP subtasks performed real operating system POSTs to send work to the maintask</td>
</tr>

<tr>
<td>STRECDS</td>
<td>Number of records processed by SORT statements or SQL sorts</td>
</tr>

<tr>
<td>STWAIT</td>
<td>Number of times MP subtasks invoked z/OS WAIT macros to wait for work from the maintask</td>
</tr>

<tr>
<td>STZDEQ</td>
<td>Number of times that an MP subtask took a unit of work from a zIIP subtask queue and processed it because the MP subtask was idle</td>
</tr>

<tr>
<td>SVAC</td>
<td>Active servers (an average, included on a performance line)</td>
</tr>

<tr>
<td>SVMX</td>
<td>Highwater mark for servers (0 if no server swapping)</td>
</tr>

<tr>
<td>SVPAGES</td>
<td><code>SVPAGES * 4096</code> is the number of bytes transferred as a result of server reads and writes</td>
</tr>

<tr>
<td>SVRD</td>
<td>Number of server reads</td>
</tr>

<tr>
<td>SVWR</td>
<td>Number of server writes</td>
</tr>

<tr>
<td>SWPG</td>
<td>Percentage of performance samples at which the user was swapping in or out (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>SWT</td>
<td>Times <var class="product">Model 204</var> issued a real WAIT while not in user-switching mode</td>
</tr>

<tr>
<td>TEMX</td>
<td>Highwater mark of CCATEMP pages used in the expansion area</td>
</tr>

<tr>
<td>TFMX</td>
<td>Highwater mark of CCATEMP pages used</td>
</tr>

<tr>
<td>TSMX</td>
<td>Highwater mark of CCATEMP pages used in the small model page pool</td>
</tr>

<tr>
<td>TTBL</td>
<td>Highwater mark of TTBL</td>
</tr>

<tr>
<td>UBUFHWS</td>
<td>Highwater mark, in bytes, of user's Universal Buffer</td>
</tr>

<tr>
<td>UDD</td>
<td>Number of lines written to a directed output (<var>USE</var>) data set</td>
</tr>

<tr>
<td>UPDTTIME(MS)</td>
<td>Number of milliseconds that a file was being updated

UPT(MS) appears as the column header for this statistic on a report
</td>
</tr>

<tr>
<td>UPDTTIME</td>
<td>Number of milliseconds that the user was actively updating at least one file</td>
</tr>

<tr>
<td>USMX</td>
<td>Highwater mark for simultaneous active users (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>USRS</td>
<td>Average number of active users (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>VTBL</td>
<td>Number of VTBL entries at the end of compilation (CMPL) processing or the end of evaluation (EVAL) processing</td>
</tr>

<tr>
<td>WAIT</td>
<td>Number of real operating system waits</td>
</tr>

<tr>
<td>WTCFR</td>
<td>Number of times that the user waited to obtain a critical file resource, either share or exclusive

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTRLK</td>
<td>Number of times that the user waited to obtain a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTSV</td>
<td>Percentage of performance samples at which the user was waiting for a server (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>XTBL</td>
<td>Highwater mark of XTBL</td>
</tr>

<tr>
<td>ZTCPU</td>
<td>The CPU (ms) consumed on a zIIP processor by the MAINTASK, an MP subtask or a zIIP subtask. Reported for each task at <var class="product">Model 204</var> termination and in <var>MONITOR TASKS</var> output (for Model 5 terminals only)</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>The number of times that a zIIP subtask took a unit of work from a zIIP subtask queue and processed it</td>
</tr>
</table>

==Header and trailer entries (Type 0)==

Each journal block begins with a header record and ends with a trailer record.

===Header entries (Type 0)===

Header entries have the format shown in the following table: 
<table>
<caption style="margin-right:6em">Header entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entire journal record, including header and trailer</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Flags used by recovery</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH </td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">4</td>
<td>Binary</td>
<td> Sequence number </td>
</tr>

<tr>
<td>16(10)</td>
<td align="right">10</td>
<td>Binary</td>
<td> System Store Clock Extended (STCKE) value to provide picosecond accuracy on the journal date/time stamp

Bytes 1-9 || byte 16 
</td>
</tr>

<tr>
<td>26(1A)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of header, type 00</td>
</tr>

<tr>
<td>28(1C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Version in hex</td>
</tr>

<tr>
<td>30(1E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Version in EBCDIC</td>
</tr>

<tr>
<td>38(26)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Job name</td>
</tr>

<tr>
<td>46(2E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>JES Job ID</td>
</tr>

<tr>
<td>54(36)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>SMF System ID</td>
</tr>
</table>
<ul>
<li>If the flag byte at offset 3 of type 00 has the X'02' bit on, then it is a header record from <var class="product">Model 204</var> version 7.4.0 or later with its length at offset X'1A'.</li>

<li>If that flag byte has the X'01' bit on, then the header is from version 7.1.0 and is 26 bytes in length. </li>

<li>If neither of those bits is on, then the header is a from a pre-7.1.0 version and is 16 bytes in length.</li>
</ul>

===Recovery flags===

Flags used by recovery can have the value of X'00' or a sum of any of the following: 
<table>
<tr class="head">
<th>Value</th>
<th>Block contains these records...</th>
</tr>

<tr>
<td>X'80'</td>
<td>Type 1</td>
</tr>

<tr>
<td>X'40'</td>
<td>Type 2</td>
</tr>

<tr>
<td>X'20'</td>
<td>Type 3</td>
</tr>

<tr>
<td>X'10'</td>
<td>Type 4</td>
</tr>

<tr>
<td>X'08'</td>
<td>Type 5</td>
</tr>

<tr>
<td>X'04'</td>
<td>Type 6</td>
</tr>
</table>

===Sequence numbers===

The sequence number represents the number of each journal record, starting at 0 and increasing by 1. A merged journal (output of the MERGEJ utility) sequence number consists of a 2-byte hexadecimal number at offset 12(0C), which indicates the input file this journal record came from, and a 2-byte hexadecimal field at offset 14(0E), which indicates the sequence within the INPUT journal.

===Trailer entries (Type 0)===

Trailer entries have the format shown in the following table: 
<table>
<caption>Trailer entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data </td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Recovery entries (Types 1-6)==

Entry types X'01' through X'06' contain information used for recovery. They follow the same general format as all other journal entries. There is no type X'07' journal entry. 

The format of the recovery entries is meaningful only in the context of the <var class="product">Model 204</var> ROLL FORWARD algorithm. However, entry types might be of interest in some statistics gathering applications, as follows: 
<table>
<tr class="head">
<th>Type </th>
<th>Contains recovery information from...</th>
</tr>

<tr>
<td>1 </td>
<td>Discontinuity</td>
</tr>

<tr>
<td>2 </td>
<td> Begin update unit.

More than one type 2 entry can be written for each update unit. The update unit number appears as a 4-byte binary number at offset 16(10).
</td>
</tr>

<tr>
<td>3 </td>
<td> End update unit.

The update unit number appears in the same format and location as the type 2 entry.
</td>
</tr>

<tr>
<td>4</td>
<td>File state information: opened, closed, dumped, file parameter list (FPL) page preimage logged or open at the time of a checkpoint</td>
</tr>

<tr>
<td>5 </td>
<td>Checkpoint</td>
</tr>

<tr>
<td>6 </td>
<td>File update </td>
</tr>
</table>

==System statistics entries (Type 8)==

Cumulative statistics, listed by offset in the [[#System performance statistics|Layout of system subtype X'02' entries]] table, are kept for the entire system. Final, partial, and performance system statistics are written to the journal during <var class="product">Model 204</var> termination in a line that begins with:
ST $$$ SYSTEM='version#'


For additional information about:
<ul>
<li>Using system statistics for performance monitoring, see [[Performance monitoring and tuning]]. </li>

<li>Disk buffer monitor statistics and parameters, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </li>
</ul>

===Final statistics===

The system final statistics line, similar to the following, is produced as part of system termination: 
ST $$$ SYSTEM='5A 'AUDIT=43 OUT=38 IN=14 WAIT=19 ...


===Partial statistics===

Statistics in a system partial statistics line, similar to the following, accumulate from the beginning of the run, if the User 0 <var>[[ACCTIM parameter|ACCTIM]]</var> parameter is nonzero: 
ST $$$ SYSTEM='6.1.0'PARTIAL=3 AUDIT=19 OUT=10 IN=5 WAIT=3 ...


===Performance statistics===

System performance statistic lines, similar to the following, are written if the User 0 <var>[[RPTCNT parameter|RPTCNT]]</var> and <var>[[SMPLTIM parameter|SMPLTIM]]</var> parameters are nonzero: 
ST $$$ SYSTEM='6.1.0' PERFORMANCE=n


The numbers determined at the performance sample points are averaged for the entire run. 

===Entry formats===

System statistics entries have the format shown in the following table: 
<table>
<caption>System statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'08'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:

X'00' = final statistics

X'01' = partial statistics

X'02' = performance statistics

X'04' = additional disk buffer monitor

X'08' = subtask statistics
</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Subtask number if subtype = X'08'; otherwise unused</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Unused</td>
</tr>

<tr>
<td>16(10) to end of journal</td>
<td align="right"> — </td>
<td align="right"> — </td>
<td>

Contents depend on subtypes, shown in tables in the following sections:
<ul>
<li>[[#System final and partial statistics|System final and partial statistics]]</li>

<li>[[#System performance statistics|System performance statistics]]</li>

<li>[[#Additional disk buffer monitor statistics|Additional disk buffer monitor statistics]]</li>

<li>[[#User since-last statistics|User since-last statistics]]</li>
</ul>
</td> </tr>
</table>

==System final and partial statistics==

For subtypes X'00' (final statistics) and X'01' (partial statistics), the layout of the remainder of the entry is shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
The following statistics are data type Binary. However, the length varies — either 4 or 8, to accommodate 64-bit system architecture. 
<table>
<caption>System final and partial statistics</caption>
<tr class="head">
<th>Offset dec(hex) </th>
<th>Length </th>
<th>Description</th>
</tr>

<tr>
<td>16(10) </td>
<td>8 </td>
<td>AUDIT</td>
</tr>

<tr>
<td>24(18) </td>
<td>8 </td>
<td>OUT</td>
</tr>

<tr>
<td>32(20) </td>
<td>8 </td>
<td>IN</td>
</tr>

<tr>
<td>40(28) </td>
<td>8 </td>
<td>OUTXX</td>
</tr>

<tr>
<td>48(30) </td>
<td>8 </td>
<td>INXX</td>
</tr>

<tr>
<td>56(38) </td>
<td>8 </td>
<td>DEV5</td>
</tr>

<tr>
<td>64(40) </td>
<td>8 </td>
<td>DEV6</td>
</tr>

<tr>
<td>72(48) </td>
<td>8 </td>
<td>DEV7</td>
</tr>

<tr>
<td>80(50) </td>
<td>8 </td>
<td>DEV8</td>
</tr>

<tr>
<td>88(58) </td>
<td>8 </td>
<td>DEV9</td>
</tr>

<tr>
<td>96(60) </td>
<td>8 </td>
<td>DEV10</td>
</tr>

<tr>
<td>104(68) </td>
<td>8 </td>
<td>DEV11</td>
</tr>

<tr>
<td>112(70) </td>
<td>8 </td>
<td>DEV12</td>
</tr>

<tr>
<td>120(78) </td>
<td>8 </td>
<td>DEV13</td>
</tr>

<tr>
<td>128(80) </td>
<td>8 </td>
<td>DEV14</td>
</tr>

<tr>
<td>136(88) </td>
<td>8 </td>
<td>OUTTTY</td>
</tr>

<tr>
<td>144(90) </td>
<td>8 </td>
<td>INTTY</td>
</tr>

<tr>
<td>152(98) </td>
<td>8 </td>
<td>DEV17</td>
</tr>

<tr>
<td>160(A0) </td>
<td>8 </td>
<td>DEV18</td>
</tr>

<tr>
<td>168(A8) </td>
<td>8 </td>
<td>DEV19</td>
</tr>

<tr>
<td>176(B0) </td>
<td>8 </td>
<td>DEV20</td>
</tr>

<tr>
<td>184(B8) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>192(C0) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>200(C8) </td>
<td>8 </td>
<td>DEV23</td>
</tr>

<tr>
<td>208(D0) </td>
<td>8 </td>
<td>DEV24</td>
</tr>

<tr>
<td>216(D8) </td>
<td>8 </td>
<td>DEV25</td>
</tr>

<tr>
<td>224(E0) </td>
<td>8 </td>
<td>DEV26</td>
</tr>

<tr>
<td>232(E8) </td>
<td>8 </td>
<td>DEV27</td>
</tr>

<tr>
<td>240(F0) </td>
<td>8 </td>
<td>DEV28</td>
</tr>

<tr>
<td>248(F8) </td>
<td>8 </td>
<td>OUTCRAM</td>
</tr>

<tr>
<td>256(100) </td>
<td>8 </td>
<td>INCRAM</td>
</tr>

<tr>
<td>264(108) </td>
<td>8 </td>
<td>DEV31</td>
</tr>

<tr>
<td>272(110) </td>
<td>8 </td>
<td>DEV32</td>
</tr>

<tr>
<td>280(118) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>288(120) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>296(128) </td>
<td>8 </td>
<td>DEV35</td>
</tr>

<tr>
<td>304(130) </td>
<td>8 </td>
<td>DEV36</td>
</tr>

<tr>
<td>312(138) </td>
<td>8 </td>
<td>DEV37</td>
</tr>

<tr>
<td>320(140) </td>
<td>8 </td>
<td>DEV38</td>
</tr>

<tr>
<td>328(148) </td>
<td>8 </td>
<td>OUTVMIO</td>
</tr>

<tr>
<td>336(150) </td>
<td>8 </td>
<td>INVMIO</td>
</tr>

<tr>
<td>344(158) </td>
<td>8 </td>
<td>OUTVMFS</td>
</tr>

<tr>
<td>352(160) </td>
<td>8 </td>
<td>INVMFS</td>
</tr>

<tr>
<td>360(168) </td>
<td>8 </td>
<td>OUTVMIF</td>
</tr>

<tr>
<td>368(170) </td>
<td>8 </td>
<td>INVMIF</td>
</tr>

<tr>
<td>376(178) </td>
<td>8 </td>
<td>OUTCMIO</td>
</tr>

<tr>
<td>384(180) </td>
<td>8 </td>
<td>INCMIO</td>
</tr>

<tr>
<td>392(188) </td>
<td>8 </td>
<td>OUTCMFS</td>
</tr>

<tr>
<td>400(190) </td>
<td>8 </td>
<td>INCMFS</td>
</tr>

<tr>
<td>408(198) </td>
<td>8 </td>
<td>DEV49</td>
</tr>

<tr>
<td>416(1A0) </td>
<td>8 </td>
<td>DEV50</td>
</tr>

<tr>
<td>424(1A8) </td>
<td>8 </td>
<td>OFFIN</td>
</tr>

<tr>
<td>432(1B0) </td>
<td>8 </td>
<td>OFFOU</td>
</tr>

<tr>
<td>440(1B8) </td>
<td>8 </td>
<td>DEV53</td>
</tr>

<tr>
<td>448(1C0) </td>
<td>8 </td>
<td>DEV54</td>
</tr>

<tr>
<td>456(1C8) </td>
<td>8 </td>
<td>DEV55</td>
</tr>

<tr>
<td>464(1D0) </td>
<td>8 </td>
<td>DEV56</td>
</tr>

<tr>
<td>472(1D8) </td>
<td>8 </td>
<td>DEV57</td>
</tr>

<tr>
<td>480(1E0) </td>
<td>8 </td>
<td>DEV58</td>
</tr>

<tr>
<td>488(1E8) </td>
<td>8 </td>
<td>DEV59</td>
</tr>

<tr>
<td>496(1F0) </td>
<td>8 </td>
<td>DEV60</td>
</tr>

<tr>
<td>504(1F8) </td>
<td>8 </td>
<td>DEV61</td>
</tr>

<tr>
<td>512(200) </td>
<td>8 </td>
<td>DEV62</td>
</tr>

<tr>
<td>520(208) </td>
<td>8 </td>
<td>DEV63</td>
</tr>

<tr>
<td>528(210) </td>
<td>8 </td>
<td>DEV64</td>
</tr>

<tr>
<td>536(218) </td>
<td>8 </td>
<td>DEV65</td>
</tr>

<tr>
<td>544(220) </td>
<td>8 </td>
<td>DEV66</td>
</tr>

<tr>
<td>552(228) </td>
<td>8 </td>
<td>DEV67</td>
</tr>

<tr>
<td>560(230) </td>
<td>8 </td>
<td>DEV68</td>
</tr>

<tr>
<td>568(238) </td>
<td>8 </td>
<td>DEV69</td>
</tr>

<tr>
<td>576(240) </td>
<td>8 </td>
<td>DEV70</td>
</tr>

<tr>
<td>584(248) </td>
<td>8 </td>
<td>DEV71</td>
</tr>

<tr>
<td>592(250) </td>
<td>8 </td>
<td>DEV72</td>
</tr>

<tr>
<td>600(258) </td>
<td>8 </td>
<td>DEV73</td>
</tr>

<tr>
<td>608(260) </td>
<td>8 </td>
<td>DEV74</td>
</tr>

<tr>
<td>616(268) </td>
<td>4 </td>
<td>WAIT</td>
</tr>

<tr>
<td>620(26C) </td>
<td>4 </td>
<td>MPLKWTIM</td>
</tr>

<tr>
<td>624(270) </td>
<td>8 </td>
<td>DKRD</td>
</tr>

<tr>
<td>632(278) </td>
<td>8 </td>
<td>DKWR</td>
</tr>

<tr>
<td>640(280) </td>
<td>4 </td>
<td>SVRD</td>
</tr>

<tr>
<td>644(284) </td>
<td>4 </td>
<td>SVWR</td>
</tr>

<tr>
<td>648(288) </td>
<td>8 </td>
<td>CPU</td>
</tr>

<tr>
<td>656(290) </td>
<td>8 </td>
<td>REQ</td>
</tr>

<tr>
<td>664(298) </td>
<td>8 </td>
<td>MOVE</td>
</tr>

<tr>
<td>672(2A0) </td>
<td>4 </td>
<td>DUMP</td>
</tr>

<tr>
<td>676(2A4) </td>
<td>4 </td>
<td>REST</td>
</tr>

<tr>
<td>680(2A8) </td>
<td>4 </td>
<td>SLIC</td>
</tr>

<tr>
<td>684(2AC) </td>
<td>4 </td>
<td>CNCT</td>
</tr>

<tr>
<td>688(2B0) </td>
<td>4 </td>
<td>FBWT</td>
</tr>

<tr>
<td>692(2B4) </td>
<td>4 </td>
<td>SWT</td>
</tr>

<tr>
<td>696(2B8) </td>
<td>4 </td>
<td>ERRPDL</td>
</tr>

<tr>
<td>700(2BC) </td>
<td>4 </td>
<td>MPLKPREM</td>
</tr>

<tr>
<td>704(2C0) </td>
<td>8 </td>
<td>RECADD</td>
</tr>

<tr>
<td>712(2C8) </td>
<td>8 </td>
<td>RECDEL</td>
</tr>

<tr>
<td>720(2D0) </td>
<td>8 </td>
<td>BADD</td>
</tr>

<tr>
<td>728(2D8) </td>
<td>8 </td>
<td>BDEL</td>
</tr>

<tr>
<td>736(2E0) </td>
<td>8 </td>
<td>BCHG</td>
</tr>

<tr>
<td>744(2E8) </td>
<td>8 </td>
<td>IXADD</td>
</tr>

<tr>
<td>752(2F0) </td>
<td>8 </td>
<td>IXDEL</td>
</tr>

<tr>
<td>760(2F8) </td>
<td>8 </td>
<td>FINDS</td>
</tr>

<tr>
<td>768(300) </td>
<td>4 </td>
<td>SORTS</td>
</tr>

<tr>
<td>772(304) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>776(308) </td>
<td>8 </td>
<td>RECDS</td>
</tr>

<tr>
<td>784(310) </td>
<td>8 </td>
<td>STRECDS</td>
</tr>

<tr>
<td>792(318) </td>
<td>8 </td>
<td>DKAR</td>
</tr>

<tr>
<td>800(320) </td>
<td>8 </td>
<td>DKPR</td>
</tr>

<tr>
<td>808(328) </td>
<td>4 </td>
<td>DKRR</td>
</tr>

<tr>
<td>812(32C) </td>
<td>4 </td>
<td>FBMX</td>
</tr>

<tr>
<td>816(330) </td>
<td>4 </td>
<td>TFMX</td>
</tr>

<tr>
<td>820(334) </td>
<td>4 </td>
<td>USMX</td>
</tr>

<tr>
<td>824(338) </td>
<td>4 </td>
<td>SVMX</td>
</tr>

<tr>
<td>828(33C) </td>
<td>4 </td>
<td>SFTRSTRT (number of soft restarts)</td>
</tr>

<tr>
<td>832(340) </td>
<td>8 </td>
<td>APSYLD</td>
</tr>

<tr>
<td>840(348) </td>
<td>8 </td>
<td>APSYLDD</td>
</tr>

<tr>
<td>848(350) </td>
<td>4 </td>
<td>APSYLDT</td>
</tr>

<tr>
<td>852(354) </td>
<td>4 </td>
<td>JSCREENS</td>
</tr>

<tr>
<td>856(358) </td>
<td>8 </td>
<td>DKPRF</td>
</tr>

<tr>
<td>864(360) </td>
<td>4 </td>
<td>SMPLS</td>
</tr>

<tr>
<td>868(364) </td>
<td>4 </td>
<td>USRS</td>
</tr>

<tr>
<td>872(368) </td>
<td>4 </td>
<td>SVAC</td>
</tr>

<tr>
<td>876(36C) </td>
<td>4 </td>
<td>RUNG</td>
</tr>

<tr>
<td>880(370) </td>
<td>4 </td>
<td>REDY</td>
</tr>

<tr>
<td>884(374) </td>
<td>4 </td>
<td>BLKI</td>
</tr>

<tr>
<td>888(378) </td>
<td>4 </td>
<td>WTSV</td>
</tr>

<tr>
<td>892(37C) </td>
<td>4 </td>
<td>BLKO</td>
</tr>

<tr>
<td>896(380) </td>
<td>4 </td>
<td>SWPG</td>
</tr>

<tr>
<td>900(384) </td>
<td>4 </td>
<td>PCPU</td>
</tr>

<tr>
<td>904(388) </td>
<td>4 </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>908(38C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>912(390) </td>
<td>8 </td>
<td>STCPU</td>
</tr>

<tr>
<td>920(398) </td>
<td>8 </td>
<td>STDEQ</td>
</tr>

<tr>
<td>928(3A0) </td>
<td>8 </td>
<td>STWAIT</td>
</tr>

<tr>
<td>936(3A8) </td>
<td>4 </td>
<td>STPOST</td>
</tr>

<tr>
<td>940(3AC) </td>
<td>4 </td>
<td>LKWAIT</td>
</tr>

<tr>
<td>944(3B0) </td>
<td>4 </td>
<td>LKPOST</td>
</tr>

<tr>
<td>948(3B4) </td>
<td>4 </td>
<td>RSXCOMP</td>
</tr>

<tr>
<td>952(3B8) </td>
<td>4 </td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>956(3BC) </td>
<td>4 </td>
<td>SCREENS</td>
</tr>

<tr>
<td>960(3C0) </td>
<td>4 </td>
<td>STIMERS</td>
</tr>

<tr>
<td>964(3C4) </td>
<td>4 </td>
<td>HRDRSTRT (number of hard restarts)</td>
</tr>

<tr>
<td>968(3C8) </td>
<td>8 </td>
<td>SVPAGES</td>
</tr>

<tr>
<td>976(3D0) </td>
<td>4 </td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>980(3D4) </td>
<td>4 </td>
<td>COMMITS</td>
</tr>

<tr>
<td>984(3D8) </td>
<td>4 </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>988(3DC) </td>
<td>4 </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>992(3E0) </td>
<td>4 </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>996(3E4) </td>
<td>4 </td>
<td>MPHASHD</td>
</tr>

<tr>
<td>1000(3E8) </td>
<td>4 </td>
<td>CDLWAIT</td>
</tr>

<tr>
<td>1004(3EC) </td>
<td>4 </td>
<td>MQGETS</td>
</tr>

<tr>
<td>1008(3F0) </td>
<td>4 </td>
<td>MQPUTS</td>
</tr>

<tr>
<td>1012(3F4) </td>
<td>4 </td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>1016(3F8) </td>
<td>4 </td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>1020(3FC) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1024(400) </td>
<td>8 </td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>1032(408) </td>
<td>8 </td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>1040(410) </td>
<td>4 </td>
<td>MQHWQU</td>
</tr>

<tr>
<td>1044(414) </td>
<td>4 </td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>1048(418) </td>
<td>4 </td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>1052(41C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1056(420) </td>
<td>8 </td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>1064(428) </td>
<td>8 </td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>1072(430) </td>
<td>8 </td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>1080(438) </td>
<td>4 </td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>1084(43C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1088(440) </td>
<td>8 </td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>1096(448) </td>
<td>4 </td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>1100(44C) </td>
<td>4 </td>
<td>ECLOAD</td>
</tr>

<tr>
<td>1104(450) </td>
<td>4 </td>
<td>ECDELETE</td>
</tr>

<tr>
<td>1108(454) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1112(458) </td>
<td>8 </td>
<td>ECCALL</td>
</tr>

<tr>
<td>1120(460) </td>
<td>4 </td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>1124(464) </td>
<td>4 </td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>1128(468) </td>
<td>4 </td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>1132(46C) </td>
<td>4 </td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>1136(470) </td>
<td>4 </td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>1140(474) </td>
<td>4 </td>
<td>ECCNCT</td>
</tr>

<tr>
<td>1144(478) </td>
<td>4 </td>
<td>ECMODMAX</td>
</tr>

<tr>
<td>1148(47C) </td>
<td>4 </td>
<td>ECNAMMAX</td>
</tr>

<tr>
<td>1152(480) </td>
<td>4 </td>
<td>ECTSKMAX</td>
</tr>

<tr>
<td>1156(484) </td>
<td>4 </td>
<td>GTBLRU</td>
</tr>

<tr>
<td>1160(488) </td>
<td>4 </td>
<td>GTBLRS</td>
</tr>

<tr>
<td>1164(48C) </td>
<td>4 </td>
<td>TSMX</td>
</tr>

<tr>
<td>1168(490) </td>
<td>4 </td>
<td>TEMX</td>
</tr>

<tr>
<td>1172(494) </td>
<td>4 </td>
<td>MAXIOX</td>
</tr>

<tr>
<td>1176(498) </td>
<td>8 </td>
<td>DKRDL</td>
</tr>

<tr>
<td>1184(4A0) </td>
<td>8 </td>
<td>DKWRL</td>
</tr>

<tr>
<td>1192(4A8) </td>
<td>8 </td>
<td>CPUTOTZE</td>
</tr>

<tr>
<td>1200(4B0) </td>
<td>8 </td>
<td>CPUONZIP</td>
</tr>

<tr>
<td>1208(4B8) </td>
<td>4 </td>
<td>MPR
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1212(4BC) </td>
<td>4 </td>
<td>MBO
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1216(4C0) </td>
<td>4 </td>
<td>MCP
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1220(4C4) </td>
<td>4 </td>
<td>RCV
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1224(4C8) </td>
<td>8 </td>
<td>Spare </td>
</tr>

<tr>
<td>1232(4D0) </td>
<td>8 </td>
<td>DKWTMICS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1240(4D8) </td>
<td>8 </td>
<td>DKWTS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1248(4E0) </td>
<td>8 </td>
<td>MTDEQ</td>
</tr>

<tr>
<td>1256(4E8) </td>
<td>8 </td>
<td>MTSDEQ</td>
</tr>

<tr>
<td>1264(4F0) </td>
<td>8 </td>
<td>MTZDEQ</td>
</tr>

<tr>
<td>1272(4F8) </td>
<td>8 </td>
<td>STZDEQ</td>
</tr>

<tr>
<td>1280(500) </td>
<td>8 </td>
<td>ZTDEQ</td>
</tr>
</table>

==System performance statistics==

===Entry format===

For subtype X'02'(system performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. See [[#Description of statistics|Statistics with descriptions]] table for the meaning of each statistic. 
<table>
<caption>Layout of system subtype X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 16(10)</td>
<td>SMPLS</td>
</tr>

<tr>
<td> 20(14)</td>
<td>USRS</td>
</tr>

<tr>
<td> 24(18)</td>
<td>SVAC</td>
</tr>

<tr>
<td> 28(1C)</td>
<td>RUNG </td>
</tr>

<tr>
<td> 32(20)</td>
<td>REDY</td>
</tr>

<tr>
<td> 36(24)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 40(28)</td>
<td>WTSV</td>
</tr>

<tr>
<td> 44(2C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 48(30)</td>
<td>SWPG </td>
</tr>
</table>

==Additional disk buffer monitor statistics==

For subtype X'04' (additional disk buffer monitor statistics), the layout of the entry is shown in the following table. Each statistic in the table is: Length, 8; Data type, Binary.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Disk buffer monitor statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Disk buffer monitor statistic </th>
</tr>

<tr>
<td>16(10)</td>
<td>Spare</td>
</tr>

<tr>
<td>24(18) </td>
<td>DKSTKQC </td>
</tr>

<tr>
<td>32(20) </td>
<td>DKSWRP </td>
</tr>

<tr>
<td>40(28) </td>
<td>DKSWRPT </td>
</tr>

<tr>
<td>48(30) </td>
<td>DKSDIR </td>
</tr>

<tr>
<td>56(38) </td>
<td>DKSDIRT </td>
</tr>

<tr>
<td>64(40) </td>
<td>DKSKIP </td>
</tr>

<tr>
<td>72(48) </td>
<td>Spare </td>
</tr>

<tr>
<td>80(50) </td>
<td>Spare</td>
</tr>

<tr>
<td>88(58) </td>
<td>DKSRR </td>
</tr>

<tr>
<td>96(60) </td>
<td>DKSFBS </td>
</tr>

<tr>
<td>104(68) </td>
<td>DKSKIPT </td>
</tr>

<tr>
<td>112(70) </td>
<td>DKSAWT </td>
</tr>

<tr>
<td>120(78) </td>
<td>DKSAWW</td>
</tr>

<tr>
<td>128(80) </td>
<td>DKSAWWL</td>
</tr>

<tr>
<td>136(88) </td>
<td>DKSAWB </td>
</tr>

<tr>
<td>144(90) </td>
<td>DKSAWBL</td>
</tr>

<tr>
<td>152(98) </td>
<td>DKSRRFND </td>
</tr>

<tr>
<td>160(A0) </td>
<td>DKSTBLF </td>
</tr>

<tr>
<td>168(A8) </td>
<td>DKSTBLA </td>
</tr>

<tr>
<td>176(B0) </td>
<td>DKSTBLB </td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKSTBLC </td>
</tr>

<tr>
<td>192(C0) </td>
<td>DKSTBLD </td>
</tr>

<tr>
<td>200(C8) </td>
<td>Spare </td>
</tr>

<tr>
<td>208(D0) </td>
<td>Spare </td>
</tr>

<tr>
<td>216(D8) </td>
<td>Spare </td>
</tr>

<tr>
<td>224(E0) </td>
<td>Spare </td>
</tr>

<tr>
<td>232(E8) </td>
<td>Spare </td>
</tr>

<tr>
<td>240(F0) </td>
<td>Spare </td>
</tr>

<tr>
<td>248(F8) </td>
<td>Spare </td>
</tr>

<tr>
<td>256(100) </td>
<td>DKSTBLX </td>
</tr>

<tr>
<td>264(108) </td>
<td>DKSTBLE</td>
</tr>

<tr>
<td>272(110)</td>
<td>Spare </td>
</tr>
</table>

==Multiprocessing (MP) subtask statistics==

The following statistics apply only to installations configured for multiprocessing using MP/204. For subtype X'08' (subtask specific statistics), the layout of the entry is shown in the following table.
For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>MP subtask statistics and offsets</caption>
<tr class="head">
<th>MP statistic </th>
<th>Offset dec(hex) </th>
<th>Length</th>
</tr>

<tr>
<td>CPU </td>
<td>16(10) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PR </td>
<td>24(18) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PCPU </td>
<td>32(20) </td>
<td align="right">4</td>
</tr>

<tr>
<td>STWAIT</td>
<td>36(24)</td>
<td align="right">4</td>
</tr>

<tr>
<td>STPOST</td>
<td>40(28)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>44(2C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKPOST</td>
<td>48(30)</td>
<td align="right">4</td>
</tr>

<tr>
<td>SPARE</td>
<td>52(34)</td>
<td align="right">4</td>
</tr>

<tr>
<td>MQWTM</td>
<td>56(38) </td>
<td align="right">8</td>
</tr>

<tr>
<td>DEQ </td>
<td>64(40) </td>
<td align="right">8</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>72(48)</td>
<td align="right">8</td>
</tr>

<tr>
<td>STDEQ </td>
<td>80(50) </td>
<td align="right">8</td>
</tr>

<tr>
<td>LWTIM </td>
<td>88(58) </td>
<td align="right">4</td>
</tr>

<tr>
<td>PETIM</td>
<td>92(5C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>ZCPU</td>
<td>96(60) </td>
<td align="right">8</td>
</tr>
</table>

==User statistics entries (Type 9)==

User lines report on an individual user's activity. These statistics include:
<ul>
<li>Final (logout) and partial statistics</li>

<li>Since-last and ordered index statistics</li>

<li>Performance statistics</li>
</ul>

Each user line starts with the following statistics:
ST $$$ USERID='userid' ACCOUNT='account'


The subtype, in this case PERFORMANCE, follows USERID and ACCOUNT statistics:
ST $$$ USERID='userid' ACCOUNT='account'
PERFORMANCE=n


The format of user statistics entries is shown in the following table:
<table>
<caption>User statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'09'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:
<ul>
<li>X'00' = logout statistics</li>

<li>X'01' = since-last statistics</li>

<li>X'02' = partial statistics</li>

<li>X'04' = performance statistics</li>

<li>X'81' = since-last statistics including conflict statistics</li>

<li>X'41' = user restart forced out a since-last statistics record.</li>

<li>X'C1' = user restart forced out a since last statistics record which included conflict statistics</li>
</ul>
</td></tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>

Account:
<ul>
<li>Second argument of LOGON/LOGIN command</li>

<li>Default is user ID</li>
</ul>
</td>
</tr>

<tr>
<td>26(1A)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>User ID</td>
</tr>

<tr>
<td>36(24)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>Since-last ID =
See the [[#User since-last statistics|Activity types]] table where the possible activity types are listed.</td>
</tr>

<tr>
<td>40(28)</td>
<td align="right">1</td>
<td>Binary</td>
<td>IODEV number (added for MXI)</td>
</tr>

<tr>
<td>41(29)</td>
<td align="right">3</td>
<td>N/A</td>
<td>Unused</td>
</tr>

<tr>
<td>44(2C) to end of journal</td>
<td> </td>
<td>Binary</td>
<td>

Contents depend on subtypes, shown in:
<ul>
<li>[[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table</li>

<li>[[#Since-last in relation to final and partial statistics|Layout of user subtype X'01' and X'81' entries]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table</li>

<li>[[#Layout of performance statistics|Layout of user subtype X'04' entries]] table</li>
</ul>
</td> </tr>
</table>

==User final and partial statistics==

===Final (logout) statistics===

Final (logout) statistics, listed in the [[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table, summarize a user's activities since the last login. A LOGOUT statistics line, such as the following, is written after each logout if the parameter following ACCOUNT is not PARTIAL, LAST, or PERFORMANCE: 
yydddhhmmssnnnsssuuuuu ST $$$ ACCOUNT='NO ACCOUNT' SQRD=5 ...

<ul>
<li><var class="term">yyddd</var> is the year and Julian day.</li>

<li><var class="term">hhmmss</var> is the time of day in hours, minutes, and seconds.</li>

<li><var class="term">nnn</var> is a counter to distinguish lines produced in the same second.</li>

<li><var class="term">sss</var> is the number of the server currently handling the user. Leading zeros are suppressed.
</li>

<li><var class="term">uuuuu</var> is a 5-digit user number associated with the audit trail line. Leading zeros are suppressed.</li>
</ul>

In some cases, the account name appears as "NO USERID NO ACCOUNT". Statistics in this category are not chargeable to any one user and should be considered system overhead.

Final lines are recognized by the absence of an indicator for another type of line.

===Partial statistics===

Optional partial statistics, listed in the "Layout of user subtype X'00' and X'02' entries" table below, can be provided for a run up to a few minutes before a system failure that prevents normal termination and production of final user and system statistics. 

User partial statistics lines, such as the following, are made available for active users: 
ST $$$ ACCOUNT='NO ACCOUNT' PARTIAL=21 ...


Statistics accumulate either:
<ul>
<li>As long as the user is logged in</li>
</ul>

or
<ul>
<li>From the first terminal input to disconnection when a login is not required </li>
</ul>

Partial statistics are requested by setting the time interval, in minutes, between successive partial lines on User 0's parameter line with the <var>ACCTIM</var> parameter. <var>ACCTIM</var> must be nonzero. 

The contents of the statistics portion of the entry, starting at offset <code>40(28)</code>, depends upon the subtype of the entry. 

Partial statistics lines are indicated on the journal by the parameter <code>PARTIAL=n</code>, where <var class="term">n</var> is a counter from the beginning of the run. <code>PARTIAL=n</code> immediately follows the type parameter.

For subtypes X'00' (logout statistics), and X'02' (partial statistics), the layout of the remainder of the entry is shown in the following table. Each statistic in the table is: Length, 4; Data type, Binary. For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Layout of user subtype X'00' and X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>40(28)</td>
<td>CNCT</td>
</tr>

<tr>
<td>44(2C)</td>
<td>DKRD </td>
</tr>

<tr>
<td>48(30)</td>
<td>DKWR </td>
</tr>

<tr>
<td>52(34)</td>
<td>SQRD</td>
</tr>

<tr>
<td>56(38)</td>
<td>SQWR</td>
</tr>

<tr>
<td>60(3C)</td>
<td>SGMTI </td>
</tr>

<tr>
<td>64(40)</td>
<td>SGMTO </td>
</tr>

<tr>
<td>68(44)</td>
<td>SVRD</td>
</tr>

<tr>
<td>72(48)</td>
<td>SVWR </td>
</tr>

<tr>
<td>76(4C)</td>
<td>CPU </td>
</tr>

<tr>
<td>80(50)</td>
<td>REQ </td>
</tr>

<tr>
<td>84(54)</td>
<td>MOVE </td>
</tr>

<tr>
<td>88(58)</td>
<td>DUMP </td>
</tr>

<tr>
<td>92(5C)</td>
<td>REST </td>
</tr>

<tr>
<td>96(60)</td>
<td>SLIC </td>
</tr>

<tr>
<td>100(64)</td>
<td>AUDIT </td>
</tr>

<tr>
<td>104(68) </td>
<td>WAIT </td>
</tr>

<tr>
<td>108(6C)</td>
<td>FBWT </td>
</tr>

<tr>
<td>112(70)</td>
<td>UDD </td>
</tr>

<tr>
<td>116(74)</td>
<td>RECADD </td>
</tr>

<tr>
<td>120(78)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>124(7C)</td>
<td>BADD </td>
</tr>

<tr>
<td>128(80)</td>
<td>BDEL</td>
</tr>

<tr>
<td>132(84)</td>
<td>BCHG </td>
</tr>

<tr>
<td>136(88)</td>
<td>IXADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>FINDS </td>
</tr>

<tr>
<td>148(94)</td>
<td>SORTS</td>
</tr>

<tr>
<td>152(98)</td>
<td>RECDS </td>
</tr>

<tr>
<td>156(9C)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>160(A0)</td>
<td>DKAR </td>
</tr>

<tr>
<td>164(A4)</td>
<td>DKPR </td>
</tr>

<tr>
<td>168(A8)</td>
<td>DKRR </td>
</tr>

<tr>
<td>172(AC)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>UPDTTIME(MS) </td>
</tr>

<tr>
<td>184(B8)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>188(BC)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>192(C0)</td>
<td>SMPLS </td>
</tr>

<tr>
<td>196(C4)</td>
<td>RUNG </td>
</tr>

<tr>
<td>200(C8)</td>
<td>REDY</td>
</tr>

<tr>
<td>204(CC)</td>
<td>BLKI</td>
</tr>

<tr>
<td>208(D0)</td>
<td>WTSV </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BLKO </td>
</tr>

<tr>
<td>216(D8)</td>
<td>SWPG </td>
</tr>

<tr>
<td>220(DC)</td>
<td>PCPU </td>
</tr>

<tr>
<td>224(E0)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>228(E4)</td>
<td>BXCHNG </td>
</tr>

<tr>
<td>232(E8)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>236(EC)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>240(F0)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>244(F4)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>248(F8)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>252(FC)</td>
<td>BXRFND</td>
</tr>

<tr>
<td>256(100)</td>
<td>BXFREE </td>
</tr>

<tr>
<td>260(104)</td>
<td>STCPU </td>
</tr>

<tr>
<td>264(108)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>268(10C)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>272(110)</td>
<td>SCREENS </td>
</tr>

<tr>
<td>276(114)</td>
<td>SVPAGES </td>
</tr>

<tr>
<td>280(118)</td>
<td>PBRSFLT </td>
</tr>

<tr>
<td>284(11C)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>292(124)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQBYTOU</td>
</tr>

<tr>
<td>308((134)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>380(17C)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>384(180)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>388(184)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>392(188)</td>
<td>Spare</td>
</tr>

<tr>
<td>396(18C) </td>
<td>MPR (V7.7 onwards)</td>
</tr>

<tr>
<td>400(190) </td>
<td>MBO (V7.7 onwards)</td>
</tr>

<tr>
<td>404(194)</td>
<td>DEV#</td>
</tr>

<tr>
<td>408(198)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>412(19C)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>CCATDIFF</td>
</tr>

</table>

==User since-last statistics==

===Since-last statistics===

Statistics are kept for each SOUL request, host language interface call, and a number of <var class="product">Model 204</var> system commands. When each request or command completes, a since-last statistics line is written. The line includes the <var>ACCOUNT</var> parameter at the beginning, followed by the <var>IODEV</var> parameter and the <var>LAST</var> parameter.

Several <var>MONITOR</var> commands produce displays containing the user's last or current activity in the <code>FUNC</code> column. When this activity completes, statistics are also written to CCAAUDIT and the activity is described in ST lines as <code>LAST='activity'</code>.

====Syntax====
ST $$$ USERID='userid' ACCOUNT='accountname' IODEV='devicetype' LAST='acty'

Where:

<var class="term">acty</var> can be one of the following: 
<table>
<caption>Activity types</caption>
<tr class="head">
<th>Option</th>
<th>Meaning</th>
</tr>

<tr>
<td>BLDR</td>
<td><var>BLDREUSE</var> command</td>
</tr>

<tr>
<td>BLDX </td>
<td><var>Z</var> command</td>
</tr>

<tr>
<td>CMPL </td>
<td>Compilation of a SOUL request</td>
</tr>

<tr>
<td>CPTB</td>
<td><var>COMPACTB</var> command</td>
</tr>

<tr>
<td>CPTE</td>
<td><var>COMPACTE</var> command</td>
</tr>

<tr>
<td>CPYP </td>
<td><var>COPY PROCEDURE</var> command</td>
</tr>

<tr>
<td>CREA</td>
<td><var>CREATE FILE filename</var> command</td>
</tr>

<tr>
<td>DISP </td>
<td><var>DISPLAY PROCEDURE</var> command</td>
</tr>

<tr>
<td>DUMP </td>
<td><var>DUMP file</var> command</td>
</tr>

<tr>
<td>EDIT </td>
<td>Editing a request</td>
</tr>

<tr>
<td>EVAL </td>
<td>Evaluation of a SOUL request</td>
</tr>

<tr>
<td>EXEC </td>
<td>Execution of an SQL request</td>
</tr>

<tr>
<td>FLDC </td>
<td>Compilation of a FLOD procedure</td>
</tr>

<tr>
<td>FLDE </td>
<td>Evaluation of a FLOD procedure</td>
</tr>

<tr>
<td>IMPC </td>
<td>Implied commit</td>
</tr>

<tr>
<td>INCR</td>
<td><var>IN FILE filename INCREASE DATASETS</var> command</td>
</tr>

<tr>
<td>INIT</td>
<td><var>IN FILE filename INITIALIZE</var> command</td>
</tr>

<tr>
<td>LOAD </td>
<td>Loading a precompiled (ASPY) procedure</td>
</tr>

<tr>
<td>PREP </td>
<td>Compilation of an SQL request</td>
</tr>

<tr>
<td>REST </td>
<td><var>RESTORE file</var> command</td>
</tr>
</table>

===Since-last highwater marks===

The since-last statistics include highwater marks of various work tables used by SOUL requests. Values are reported in terms of the units in which each table is allocated. For example, QTBL is allocated in units of 16 bytes.

===Since-last in relation to final and partial statistics===

Many since-last statistics, such as CNCT, CPU, and DKRD, are also reported on user final and partial statistics lines. (See the [[#Description of statistics|Statistics with descriptions]] table.) The statistics on these lines are roughly equal to the sum of all of the preceding since-last statistics for the user.
Because since-last statistics are not maintained for every <var class="product">Model 204</var> command, final statistics are generally larger.

For subtype X'01' (since-last statistics), the layout of the remainder of the entry begins as shown in the following table.
For the meaning of each statistic in this table and in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table, see the [[#Description of statistics|Statistics with descriptions]] table.
The layout of the end of the entry depends on whether you chose to collect conflict statistics:
<ul>
<li>If you do not collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table.</li>

<li>If you do collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table. When you collect conflict statistics, the subtype changes to X'81'. </li>
</ul>
<table>
<caption>Layout of user subtype X'01' and X'81' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 44(2C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 48(30)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 52(34)</td>
<td>QTBL </td>
</tr>

<tr>
<td> 56(38)</td>
<td>STBL </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>TTBL </td>
</tr>

<tr>
<td> 64(40)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 68(44)</td>
<td>PDL</td>
</tr>

<tr>
<td> 72(48)</td>
<td>FTBL </td>
</tr>

<tr>
<td> 76(4C)</td>
<td>XTBL </td>
</tr>

<tr>
<td> 80(50)</td>
<td>ITBL </td>
</tr>

<tr>
<td> 84(54)</td>
<td>FSCB </td>
</tr>

<tr>
<td> 88(58)</td>
<td>OUTPB </td>
</tr>

<tr>
<td> 92(5C) </td>
<td>HEAP </td>
</tr>

<tr>
<td> 96(60)</td>
<td>SQLI </td>
</tr>

<tr>
<td>100(64)</td>
<td>SQLO</td>
</tr>

<tr>
<td>104(68)</td>
<td>CNCT</td>
</tr>

<tr>
<td>108(6C)</td>
<td>CPU </td>
</tr>

<tr>
<td>112(70)</td>
<td>DKRD </td>
</tr>

<tr>
<td>116(74)</td>
<td>DKWR</td>
</tr>

<tr>
<td>120(78)</td>
<td>UDD </td>
</tr>

<tr>
<td>124(7C)</td>
<td>OUT </td>
</tr>

<tr>
<td>128(80)</td>
<td>SLIC</td>
</tr>

<tr>
<td>132(84)</td>
<td>IN </td>
</tr>

<tr>
<td>136(88)</td>
<td>RECADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>BADD </td>
</tr>

<tr>
<td>148(94)</td>
<td>BDEL </td>
</tr>

<tr>
<td>152(98)</td>
<td>BCHG </td>
</tr>

<tr>
<td>156(9C)</td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>164(A4)</td>
<td>FINDS </td>
</tr>

<tr>
<td>168(A8)</td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC)</td>
<td>RECDS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>PCPU </td>
</tr>

<tr>
<td>184(B8)</td>
<td>RQTM </td>
</tr>

<tr>
<td>188(BC)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>192(CO)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td>196(C4)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>200(C8)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>204(CC)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>208(DO)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>216(D8)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 220(DC)</td>
<td>BXFREE </td>
</tr>

<tr>
<td> 224(E0)</td>
<td>STCPU </td>
</tr>

<tr>
<td> 228(E4)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 232(E8)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 236(EC)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>240(F0) </td>
<td>SVRD </td>
</tr>

<tr>
<td>244(F4)</td>
<td>SVWR</td>
</tr>

<tr>
<td>248(F8) </td>
<td>DKPR </td>
</tr>

<tr>
<td>252(FC)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>256(100)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>260(104)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>264(108)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>268(10C)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>272(110)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>276(114)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>280(118)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>284(11C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>292(124)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>336(150)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>340(154)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>372(174)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>376(178)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>380(17C)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>384(180)</td>
<td>OBJSWAP</td>
</tr>

<tr>
<td>388()184</td>
<td>SIRIUS02</td>
</tr>

<tr>
<td>392(188)</td>
<td>SIRIUS03</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>400(190) </td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>404(194) </td>
<td>CCATDIFF</td>
</tr>

<tr>
<td>408(198) </td>
<td>CCATDIFH</td>
</tr>
</table>

===Conflict statistics===

Whether you are collecting conflict statistics determines the layout at the end of the entry. Two of the conflict statistics keep track of critical file-resource conflicts, and two keep track of record-locking conflicts. Whether these statistics are collected and journaled depends on settings of the parameters <var>[[CFRLOOK parameter|CFRLOOK]]</var> and <var>[[CFRJRNL parameter|CFRJRNL]]</var>.


These statistics are not displayed with the output of the <code>MONITOR SL</code> command. Instead, you can view them (with all the other since-last statistics) by issuing the <var>MONITOR</var> command with the keyword <var>CONFLICT</var>.

The remainder of the entry depends on the setting of <var>CFRJRNL</var>.

The following table shows the layout when <var>CFRJRNL</var> is set to 0: 
<table>
<caption>Layout of user subtype X'01' entries (CFRJRNL=0)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>422(1A6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>430(1AE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>431(1AF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>

The following table shows the layout when <var>CFRJRNL</var> is set to 1. It reflects the change in offset and that the user subtypes are now X'81' entries. 
<table>
<caption>Layout of user subtype X'81' entries (CFRJRNL=1)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Entry type</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKCFRE stastic</td>
</tr>

<tr>
<td>416(1A0)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKRLK statistic</td>
</tr>

<tr>
<td>420(1A4)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTCFR statistic</td>
</tr>

<tr>
<td>424(1A8)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTRLK statistic</td>
</tr>

<tr>
<td>428(1AC)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>438(1B6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>446(1BE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>447(1BF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>
Note:
The conflict statistics, BLKCFRE, BLKRLK, WTCFR, and WTRLK, are inexact. Although a user might at times conflict with multiple other users, only the first conflict encountered is counted.

==User performance statistics==

Optional performance statistics lines provide information about the operation of the <var class="product">Model 204</var> scheduler during a short period of time. Information about the length of the scheduler queues, the number of active users and servers, and the queue distribution for each user, is obtained by sampling. 

A performance line starts with:
ST $$$ USERID='userid' ACCOUNT='accountname'
PERFORMANCE=n


===Parameters to activate performance statistics===

To request performance statistics, specify the number of samples to take between performance statistics lines (<var>RPTCNT</var> parameter) and the time interval between samples (<var>SMPLTIM</var> parameter) on User 0's parameter line. When you request scheduler and server performance data (<var>SMPLTIM</var> parameter), an asynchronous operating system task, called the performance subtask, is created. Both <var>RPTCNT</var> and <var>SMPLTIM</var> must be nonzero.

===Sampling===

The performance subtask spends most of its time in a wait state. Every <var>SMPLTIM</var> milliseconds, it records the current state of the system. Data from the most recent sample is available at an Online terminal through the <var>MONITOR</var> command, described in [[Controlling system operations (CCAIN)#ONLINE monitoring|ONLINE monitoring]]. 

The number of samples taken during a run (<var>RPTCNT</var>), times the number of users in the run (<var>NUSERS</var>), must be less than 4.2 million. In large systems that run for a very long period of time, the time interval between samples cannot be extremely short. If the limit is exceeded, an OC1 interrupt occurs when the SMPLS statistic value is calculated during the printing of the system statistics, either a performance or final line.

====Layout of performance statistics====

For subtype X'04' (performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. For the description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>Layout of user subtype X'04' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 40(28)</td>
<td>SMPLS </td>
</tr>

<tr>
<td> 44(2C)</td>
<td>RUNG</td>
</tr>

<tr>
<td> 48(30)</td>
<td>REDY </td>
</tr>

<tr>
<td> 52(34)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 56(38)</td>
<td>WTSV </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 64(40)</td>
<td>SWPG </td>
</tr>
</table>

==File statistics entries (Type 10)==

File statistics, summarized in the [[#File statistics journal records layout|File statistics entry formats]] table, are kept for every file opened during a run, including CCAGRP, CCASYS, and CCATEMP. The activity of a file for all users is summarized from the time the file is first opened until the last user issues a <var>CLOSE</var> command. The statistics appear after the last <var>CLOSE</var> command in lines that follow the date and time information (yyyydddhhmmssnnnsssuuuuu) with: 
ST $$$ FILE='filename'


System termination writes file statistics for each file still open at the end of the run.

===Final statistics===

A final statistics line similar to the following is produced when the last user of a file closes the file: 
ST $$$ FILE='PAYABLES'DKRD=25 DKRD=25 DKWR=15 REQ=3 RECADD=6 ...


===Partial statistics===

File partial statistics lines similar to the following are furnished for each open file: 
ST $$$ FILE='PAYABLES'PARTIAL=3 ...


===File statistics journal records layout===

File statistics entries have the format shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>File statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Type of entry</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'0A'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Subtype indicator:
X'00' = file close
X'01' = partial</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td align="right"> 4</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td align="right"> 8</td>
<td> EBCDIC</td>
<td>File name</td>
</tr>

<tr>
<td> 24(18)</td>
<td align="right"> 2</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>
</table>

The following table lists the file statistics and the decimal(hexidecimal) offset. These statistics are data type Binary and eight bytes long.
<table>
<caption>File statistics</caption>
<tr class="head">
<th>File statistic </th>
<th>Offset dec(hex) </th>
</tr>

<tr>
<td>DKRD </td>
<td>26(1A) </td>
</tr>

<tr>
<td>DKWR </td>
<td>34(22) </td>
</tr>

<tr>
<td>REQ </td>
<td>42(2A) </td>
</tr>

<tr>
<td>RETRYA </td>
<td>50(32) </td>
</tr>

<tr>
<td>RETRYC </td>
<td>58(3A) </td>
</tr>

<tr>
<td>DUPDTS </td>
<td>66(42) </td>
</tr>

<tr>
<td>RECADD </td>
<td>74(4A) </td>
</tr>

<tr>
<td>RECDEL </td>
<td>82(52) </td>
</tr>

<tr>
<td>BADD </td>
<td>90(5A) </td>
</tr>

<tr>
<td>BDEL </td>
<td>98(62) </td>
</tr>

<tr>
<td>BCHG </td>
<td>106(6A) </td>
</tr>

<tr>
<td>IXADD </td>
<td>114(72) </td>
</tr>

<tr>
<td>IXDEL </td>
<td>122(7A) </td>
</tr>

<tr>
<td>DIRRCD </td>
<td>130(82) </td>
</tr>

<tr>
<td>BXCHNG </td>
<td>138(8A) </td>
</tr>

<tr>
<td>BXDELE </td>
<td>146(92) </td>
</tr>

<tr>
<td>BXNEXT </td>
<td>154(9A) </td>
</tr>

<tr>
<td>BXFIND </td>
<td>162(A2) </td>
</tr>

<tr>
<td>BXINSE </td>
<td>170(AA) </td>
</tr>

<tr>
<td>BXSPLI </td>
<td>178(B2) </td>
</tr>

<tr>
<td>BXRFND </td>
<td>186(BA) </td>
</tr>

<tr>
<td>BXFREE </td>
<td>194(C2) </td>
</tr>

<tr>
<td>UPDTTIME </td>
<td>202(CA) </td>
</tr>

<tr>
<td>PNDGTIME </td>
<td>210(D2) </td>
</tr>

<tr>
<td>DKUPTIME </td>
<td>218(DA) </td>
</tr>

<tr>
<td>COMMITS </td>
<td>226(E2) </td>
</tr>

<tr>
<td>BACKOUTS </td>
<td>234(EA) </td>
</tr>
</table>

==Text entries (Type 11, Type 13)==

Type 11 (X'0B') and Type 13 (X'0D') entries record most of the actual text of the audit trail.

===Noncontinued text entries, Type 11 (X'0B')===

Each Type 11 journal entry corresponds to one logical entry in the audit trail, even though it might generate more than one line of physical output in the audit trail. 

The format of a Type 11 entry is shown in the following table: 
<table>
<caption>Noncontinued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'0B'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Subtype indicator:

X'01' = LI line

X'02' = LP line

X'03' = LR line

X'04' = CI line

X'05' = QT line

X'08' = CP line

X'10' = OI line

X'20' = OO line

X'40' = LS line

X'80' = CS line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>

===Possibly continued text entries, Type 13 (X'0D')===

Each Type 13 journal entry corresponds to one, or part of one, logical entry in the audit trail. See the [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Example|Types of audit trail lines]] table for a definition of the line types.

The format of a Type 13 entry is shown in the following table: 
<table>
<caption>Possibly continued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0D'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = US line

X'02' = XX line

X'04' = RK line

X'08' = AD line

X'10' = MS line

X'20' = ER line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td> 14(0E)</td>
<td> 2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td> 16(10)</td>
<td> Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>
Note:
Subtype indicator X'80' summed with any subtype means continuation into the next entry. 

==Initialization entries, Type 12 (X'0C')==

One Type 12 journal entry is written as the first nonheader entry in the journal during initialization. It contains basic information about the run being initialized.

The format of a Type 12 entry is shown in the following table:
<table>
<caption>Initialization entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'001A'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0C'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> —</td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 8</td>
<td> EBCDIC</td>
<td>Version ID (for example, 4.2.0G)</td>
</tr>

<tr>
<td> 20(14)</td>
<td> 2</td>
<td> Binary</td>
<td>Spare for the run</td>
</tr>

<tr>
<td> 22(16)</td>
<td> 4</td>
<td> EBCDIC</td>
<td>SMF ID (SYSID parameter) </td>
</tr>
</table>

==Time-stamp entries, Type 14 (X'0E')==

Type 14 entries are used to force time-stamps to the journal. 

The format of a Type 14 entry is shown in the following table: 
<table>
<caption>Time-stamp entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td>2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0E'</td>
</tr>

<tr>
<td>3(3)</td>
<td> 1</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td>4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Merged journal bracketing entries (Type 15)==

Type 15 entries appear only in the output of the MERGEJ utility. See [[System and media recovery#Using the MERGEJ utility|Using the MERGEJ utility]]. 

The format of a Type 15 entry is shown in the following table:
<table>
<caption>Merged journal bracketing entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'002E'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0F'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = begin bracket

X'02' = end bracket
</td>
</tr>

<tr>
<td> 4(4)</td>
<td>12(0C)</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td>2(2)</td>
<td> Binary </td>
<td>Number of journals merged together</td>
</tr>

<tr>
<td> 18(12)</td>
<td>28(1C)</td>
<td>EBCDIC</td>
<td>Text:
<ul>
<li>For subtype X'01' = BEGINNING OF MERGED JOURNAL</li>

<li>For subtype X'02' = END OF MERGED JOURNAL</li>
</ul>
</td></tr>
</table>

==System Management Facilities==

You can write certain statistics to the System Management Facilities (SMF) data set by: 
<ul>
<li>Setting the <var>[[SMFSLRN parameter|SMFSLRN]]</var> and <var>[[SMFLORN parameter|SMFLORN]]</var> parameters on the User 0 command line to activate the SMF feature. (z/OS and z/VM)</li>

<li>Modifying the program that processes the SMF data set to handle the records written by <var class="product">Model 204</var>. (z/VM only)</li>
</ul>

See the [[#z/VM requirements|z/VM requirements]] and the the [[#z/OS requirements|z/OS requirements]] sections for details.

Since-last statistics or logout statistics can be written concurrently with statistics that are written to the journal. Logout statistics are more complete than since-last statistics. Many more since-last records than logout records are usually written. 

If the operating system crashes before a user logs out, the SMF data set has a since-last record for every request run, but no logout record. 

File and system statistics cannot be written to the SMF data set.

During system initialization, <var class="product">Model 204</var> issues a message reporting the SMF system ID, the run's job name, the step name, and the JES ID. For operating systems other than z/OS, the JES ID is blank.

===z/VM requirements===

In the CMS interface to <var class="product">Model 204</var>, you can incorporate a user-written accounting exit that invokes the ACCTEXIT routine to process each statistics record as it is written. The following considerations apply:
<ul>
<li>Take care to preserve the CMS environment in which <var class="product">Model 204</var> is running. Do not change the contents of general registers 13 and 14.</li>

<li>You must specify the <var>SMFLORN</var> and/or <var>SMFSLRN</var> parameters on User 0's parameter line to activate accounting record production.</li>

<li>TEXT file for the ACCTEXIT module must be available on an accessed disk when generating M204CMS using M204GEN. For complete installation procedures, see the <var class="book">Rocket Model 204 z/VM Installation Guide</var>.</li>
</ul>

===z/OS requirements===

To write since-last SMF records in a z/OS environment, activate the SMF feature. 

To activate SMF, set the following parameters on User 0's parameter line: 
<ul>
<li>SMFSLRN — SMF record number for since-last records</li>

<li>SMFLORN — SMF record number for logout records </li>
</ul>

The following considerations apply:
<ul>
<li>Since-last SMF records are written only if the SMFSLRN parameter is set to a non-zero value at the beginning of the run.</li>

<li>Logout SMF records are written only if the SMFLORN parameter is set to a non-zero value at the beginning of the run.</li>

<li>If both parameters are set, each type of record is written.</li>
</ul>

SMF record numbers, which identify the record type to the programs that process the SMF data set, are written as part of the header of the SMF records. The record numbers must be between 128 and 255.

See the "System Management Facility record layout and statistics" section, which follows.

==System Management Facility record layout and statistics==

===SMF logout record layout===

The following table shows the basic format of the <var class="product">Model 204</var> SMF logout record: 
<table>
<caption>Basic format of Model 204 SMF logout record</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length</th>
<th> Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td>2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td>4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td>5(5)</td>
<td> 1</td>
<td>Record number (<var>SMFSLRN</var> or <var>SMFLORN</var>)</td>
</tr>

<tr>
<td>6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td> 1</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: x'4C'
For V7.7: x'4D'
For V7.8: x'4E'
</td>
</tr>

<tr>
<td>58(3A)</td>
<td> 2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable
4-character field retrieved from the SMF control area.

The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.
</li>
</ul>

====Offsets for SMF logout record statistics====

The following table shows the layout of SMF logout record statistics. Each statistic in the table is: Length, 4 (bytes); data type, Binary.
This record has the same statistics in the same order as the CCAJRNL logout record, only the offsets are different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]] table.
<table>
<caption>Offset location of SMF logout record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>60(3C) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 64(40) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 68(44) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 72(48) </td>
<td>SQRD</td>
</tr>

<tr>
<td> 76(4C) </td>
<td>SQWR</td>
</tr>

<tr>
<td> 80(50) </td>
<td>SGMTI</td>
</tr>

<tr>
<td> 84(54) </td>
<td>SGMTO</td>
</tr>

<tr>
<td> 88(58) </td>
<td>SVRD</td>
</tr>

<tr>
<td> 92(5C) </td>
<td>SVWR</td>
</tr>

<tr>
<td> 96(60) </td>
<td>CPU</td>
</tr>

<tr>
<td>100(64) </td>
<td>REQ</td>
</tr>

<tr>
<td>104(68) </td>
<td>MOVE</td>
</tr>

<tr>
<td>108(6C) </td>
<td>DUMP</td>
</tr>

<tr>
<td>112(70) </td>
<td>REST</td>
</tr>

<tr>
<td>116(74) </td>
<td>SLIC</td>
</tr>

<tr>
<td>120(78) </td>
<td>AUDIT</td>
</tr>

<tr>
<td>124(7C) </td>
<td>WAIT</td>
</tr>

<tr>
<td>128(80) </td>
<td>FBWT</td>
</tr>

<tr>
<td>132(84) </td>
<td>UDD</td>
</tr>

<tr>
<td>136(88) </td>
<td>RECADD</td>
</tr>

<tr>
<td>140(8C) </td>
<td>RECDEL</td>
</tr>

<tr>
<td>144(90) </td>
<td>BADD</td>
</tr>

<tr>
<td>148(94) </td>
<td>BDEL</td>
</tr>

<tr>
<td>152(98) </td>
<td>BCHG</td>
</tr>

<tr>
<td>156(9C) </td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td>164(A4) </td>
<td>FINDS</td>
</tr>

<tr>
<td>168(A8) </td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC) </td>
<td>RECDS</td>
</tr>

<tr>
<td>176(B0) </td>
<td>STRECDS</td>
</tr>

<tr>
<td>180(B4) </td>
<td>DKAR</td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKPR</td>
</tr>

<tr>
<td>188(BC) </td>
<td>DKRR</td>
</tr>

<tr>
<td>192(C0) </td>
<td>COMMITS</td>
</tr>

<tr>
<td>196(C4) </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>200(C8) </td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>204(CC) </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>208(D0) </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>212(D4) </td>
<td>SMPLS</td>
</tr>

<tr>
<td>216(D8) </td>
<td>RUNG</td>
</tr>

<tr>
<td>220(DC) </td>
<td>REDY</td>
</tr>

<tr>
<td>224(E0) </td>
<td>BLKI</td>
</tr>

<tr>
<td>228(E4) </td>
<td>WTSV</td>
</tr>

<tr>
<td>232(E8) </td>
<td>BLKO</td>
</tr>

<tr>
<td>236(EC) </td>
<td>SWPG</td>
</tr>

<tr>
<td>240(F0) </td>
<td>PCPU</td>
</tr>

<tr>
<td>244(F4) </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>248(F8) </td>
<td>BXCHNG</td>
</tr>

<tr>
<td>252(FC) </td>
<td>BXDELE</td>
</tr>

<tr>
<td>256(100) </td>
<td>BXNEXT</td>
</tr>

<tr>
<td>260(104)</td>
<td>BXFIND</td>
</tr>

<tr>
<td>264(108)</td>
<td>BXINSE</td>
</tr>

<tr>
<td>268(10C)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td>272(110)</td>
<td>BXFND</td>
</tr>

<tr>
<td>276(114)</td>
<td>BXFREE</td>
</tr>

<tr>
<td>280(118)</td>
<td>STCPU</td>
</tr>

<tr>
<td>284(11C)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>288(120)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>292(124)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>296(128)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>300(12C)</td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>312(138)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>344(158)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>348(15C)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>352(160)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>380(17C)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>384(180)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>388(184)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>392(188)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>400(190)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>404(194)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>408(198)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>412(19C)</td>
<td>Spare </td>
</tr>

<tr>
<td>416(1A0)</td>
<td>Spare</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>Spare</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>Spare</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>Spare</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>Spare</td>
</tr>
</table>

===SMF since-last record layout===

The following table shows the basic format of since-last <var class="product">Model 204</var> SMF records. 
<table>
<caption>Since-last record basic format</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length (bytes)</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td> 5(5)</td>
<td> 1</td>
<td>Record number (SMFSLRN)</td>
</tr>

<tr>
<td> 6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td>1</td>
<td>SMFSLTYP - X'01' if CRFJRNL=1 (conflict counters present)

SMFSLTYP - X'00' if CRFJRNL=0 (conflict counters not present)
</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: <code>x'4C'</code>
For V7.7: <code>x'4D'</code>
For V7.8: <code>x'4E'</code>
</td>
</tr>

<tr>
<td>58(3A)</td>
<td>2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> 4</td>
<td>Since-last type (EVAL CMPL DUMP REST...)</td>
</tr>

<tr>
<td>64(40)</td>
<td> 8</td>
<td>File name</td>
</tr>

<tr>
<td>72(48)</td>
<td>10</td>
<td>Since-last subsystem name</td>
</tr>

<tr>
<td>82(52)</td>
<td>40</td>
<td>Since-last procedure name</td>
</tr>

<tr>
<td>122(7A)</td>
<td>2</td>
<td>Reserved two bytes</td>
</tr>

<tr>
<td>124(7C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable 4-character field retrieved from the SMF control area.</li>

<li>The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.</li>
</ul>

====Offsets for SMF since-last record statistics====

The following table shows the layout of SMF since-last record statistics. Each statistic in the table is: Length, 4 (bytes); Data type, Binary.
This record has the same statistics in the same order as the CCAJRNL user since-last records; only the offsets are
different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]]
table. 
<table>
<caption>SMF since-last record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td> 124(7C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 128(80)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 132(84)</td>
<td>QTBL</td>
</tr>

<tr>
<td> 136(88) </td>
<td>STBL</td>
</tr>

<tr>
<td> 140(8C)</td>
<td>TTBL</td>
</tr>

<tr>
<td> 144(90)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 148(94)</td>
<td>PDL</td>
</tr>

<tr>
<td> 152(98)</td>
<td>FTBL</td>
</tr>

<tr>
<td> 156(9C)</td>
<td>XTBL</td>
</tr>

<tr>
<td> 160(A0)</td>
<td>ITBL</td>
</tr>

<tr>
<td> 164(A4)</td>
<td>FSCB</td>
</tr>

<tr>
<td> 168(A8)</td>
<td>OUTPB</td>
</tr>

<tr>
<td> 172(AC) </td>
<td>HEAP</td>
</tr>

<tr>
<td> 176(B0) </td>
<td>SQLI</td>
</tr>

<tr>
<td> 180(B4) </td>
<td>SQLO</td>
</tr>

<tr>
<td> 184(B8) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 188(BC) </td>
<td>CPU</td>
</tr>

<tr>
<td> 192(C0) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 196(C4) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 200(C8) </td>
<td>UDD</td>
</tr>

<tr>
<td> 204(CC) </td>
<td>OUT</td>
</tr>

<tr>
<td> 208(D0) </td>
<td>SLIC</td>
</tr>

<tr>
<td> 212(D4) </td>
<td>IN</td>
</tr>

<tr>
<td> 216(D8) </td>
<td>RECADD</td>
</tr>

<tr>
<td> 220(DC) </td>
<td>RECDEL</td>
</tr>

<tr>
<td> 224(E0) </td>
<td>BADD</td>
</tr>

<tr>
<td> 228(E4) </td>
<td>BDEL</td>
</tr>

<tr>
<td> 232(E8) </td>
<td>BCHG</td>
</tr>

<tr>
<td> 236(EC) </td>
<td>IXADD</td>
</tr>

<tr>
<td> 240(F0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td> 244(F4) </td>
<td>FINDS</td>
</tr>

<tr>
<td> 248(F8) </td>
<td>SORT</td>
</tr>

<tr>
<td> 252(FC) </td>
<td>RECDS</td>
</tr>

<tr>
<td> 256(100)</td>
<td>STRECDS</td>
</tr>

<tr>
<td> 260(104)</td>
<td>PCPU</td>
</tr>

<tr>
<td> 264(108)</td>
<td>RQTM</td>
</tr>

<tr>
<td> 268(10C)</td>
<td>DIRRCD</td>
</tr>

<tr>
<td> 272(110)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td> 276(114)</td>
<td>BXDELE</td>
</tr>

<tr>
<td> 280(118)</td>
<td>BXNEXT</td>
</tr>

<tr>
<td> 284(11C)</td>
<td>BXFIND</td>
</tr>

<tr>
<td> 288(120)</td>
<td>BXINSE</td>
</tr>

<tr>
<td> 292(124)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td> 296(128)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 300(12C)</td>
<td>BXFREE</td>
</tr>

<tr>
<td> 304(130)</td>
<td>STCPU</td>
</tr>

<tr>
<td> 308(134)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 312(138)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 316(13C)</td>
<td>SCREENS</td>
</tr>

<tr>
<td> 320(140)</td>
<td>SVRD</td>
</tr>

<tr>
<td> 324(144)</td>
<td>SVWR</td>
</tr>

<tr>
<td> 328(148)</td>
<td>DKPR</td>
</tr>

<tr>
<td> 332(14C)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>336(150)</td>
<td>COMMITS</td>
</tr>

<tr>
<td>340(154)</td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>344(158)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>348(15C)</td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>352(160)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>368(170)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>372(174)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>376(178)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>380(17C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>384(180)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>388(184)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>392(188)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>396(18C)</td>
<td>MAPICNT</td>
</tr>

<tr>
<td>400(190)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>404(194)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>408(198)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>412(19C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>444(1BC)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>448(1C0)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>452(1C4)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>456(1C8)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>460(1CC)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>464(1D0)</td>
<td>Sirius</td>
</tr>

<tr>
<td>468(1D4)</td>
<td>Sirius</td>
</tr>

<tr>
<td>472(1D8)</td>
<td>Sirius</td>
</tr>

<tr>
<td>476(1DC)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>480(1E0)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>484(1E4)</td>
<td>Spare</td>
</tr>

<tr>
<td>488(1E8)</td>
<td>Spare</td>
</tr>
</table>

The following table lists the conflict statistics, if <code>CFRJRNL=1</code>:

<table>
<caption>Conflict statistics, if CFRJRNL=1</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td>492(1EC)</td>
<td>BLKCFRE</td>
</tr>

<tr>
<td>496(1F0)</td>
<td>BLKRLK</td>
</tr>

<tr>
<td>500(1F4)</td>
<td>WTCFR</td>
</tr>

<tr>
<td>504(1F8)</td>
<td>WTRLK</td>
</tr>
</table>

[[Category:System management]]
[[Category:System-level capabilities of Model 204]]

Using system statistics

2024-10-09T22:03:40Z

Goff: JSCREENS replaces spare at offset 852(354)

==Overview==

The tables on this page are provided for your use in identifying and tracking statistics that are reported by <var class="product">Model 204</var> in various situations. The offsets, given in decimal and hexadecimal, are to help you locate particular statistics within statistical output. The length is in bytes.

The statistics are collected in the [[Tracking_system_activity_(CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAJRNL|CCAJRNL]] data set, or if allocated, in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAAUDIT and CCAJLOG|CCAJLOG]]. The offsets in the tables below locate each statistic in the corresponding record. To accommodate sites that need to run <var class="product">Model 204</var> around the clock for many days at a time, space for most <var class="product">Model 204</var> statistics is a double word.

==Description of statistics==

The "Statistics with descriptions" table lists the statistics that are collected and that you can evaluate. It also describes the purpose of each statistic followed by the circumstances when you can collect the information and an offset in the journal record. 

To collect several statistics you must preset a parameter to a nonzero value. Statistics that require a parameter are also noted in the "Statistics with descriptions" table. The table in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Setting parameters to collect certain statistics]] lists those statistics with the required parameter. 

Tables, identified by type, later in this topic, describe the layouts of the various journal records.
<table>
<caption style="margin-right:4em">Statistics with descriptions</caption>
<tr class="head">
<th>Statistic </th>
<th>Records...</th>
</tr>

<tr>
<td>APSYLD</td>
<td>Number of APSY loads</td>
</tr>

<tr>
<td>APSYLDD</td>
<td>Number of APSY loads from a dataspace</td>
</tr>

<tr>
<td>APSYLDT</td>
<td>Number of tiny APSY loads</td>
</tr>

<tr>
<td>AUDIT</td>
<td>Number of lines written to the journal and/or the audit trail</td>
</tr>

<tr>
<td>BACKOUTS</td>
<td>Number of BACKOUTs</td>
</tr>

<tr>
<td>BADD</td>
<td>Number of fields added to Table B</td>
</tr>

<tr>
<td>BCHG</td>
<td>Number of fields changed in Table B</td>
</tr>

<tr>
<td>BDEL</td>
<td>Number of fields deleted from Table B</td>
</tr>

<tr>
<td>BLKCFRE</td>
<td>Number of times user held a critical file resource (CFR) exclusively and forced another user to wait

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKI</td>
<td>Percentage of performance samples at which the user was in a server but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKO</td>
<td>Percentage of performance samples at which the user was swapped out to the server data set but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKRLK</td>
<td>Number of times user was the first user identified as blocking another from obtaining a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BXCHNG</td>
<td>Number of value entries changed in the ordered index. This occurs when a record number is added to or removed from an existing value entry.</td>
</tr>

<tr>
<td>BXDELE</td>
<td>Number of value entries deleted from the ordered index</td>
</tr>

<tr>
<td>BXFIND</td>
<td>Number of ordered index searches to locate field name=value pairs in the ordered index</td>
</tr>

<tr>
<td>BXFREE</td>
<td>Number of ordered index pages (nodes) emptied and released from the ordered index</td>
</tr>

<tr>
<td>BXINSE</td>
<td>Number of new value entries inserted into the ordered index</td>
</tr>

<tr>
<td>BXNEXT</td>
<td>Number of value entries touched in the ordered index during a range retrieval</td>
</tr>

<tr>
<td>BXRFND</td>
<td>Number of times the cursor was repositioned in the ordered index during a search</td>
</tr>

<tr>
<td>BXSPLI</td>
<td>Number of Table D pages (nodes) split in the ordered index</td>
</tr>

<tr>
<td>CCATDIFF</td>
<td>Difference between CCATEMP pages allocated and freed by a thread. This is an imperfect indicator of the number of CCATEMP pages a thread has allocated. CCATDIFF is imperfect because it is difficult to fully account for pages allocated or freed on behalf of the system or other users. However, if there is an acute CCATEMP page shortage, threads with high CCATDIFF values are likely culprits.

CCATDIFF is available in Model 204 7.7 and higher.</td>
</tr>

<tr>
<td>CCATDIFH</td>
<td>High water mark of CCATDIFF in a request. This can be useful if a request allocated a lot of CCATEMP pages, causing an acute shortage but then freed those pages.

CCATDIFH is available in Model 204 7.7 and later.</td>
</tr>

<tr>
<td>CDLWAIT</td>
<td>Number of constraint dependency lock waits</td>
</tr>

<tr>
<td>CNCT</td>
<td>Elapsed time in seconds</td>
</tr>

<tr>
<td>COMMITS</td>
<td>Number of <var>COMMIT</var>s</td>
</tr>

<tr>
<td>CPU</td>
<td>Total CPU time consumed in milliseconds. The system CPU statistics include both maintask and subtask CPU usage.</td>
</tr>

<tr>
<td>CPUONZIP</td>
<td>Total CPU time consumed in milliseconds on zIIP engines</td>
</tr>

<tr>
<td>CPUTOTZE</td>
<td>Total CPU time consumed in milliseconds by workloads eligible for offload to zIIP engines</td>
</tr>

<tr>
<td>DEQ</td>
<td>Total number of units of work taken by the MAINTASK and each MP and zIIP subtask, regardless of the queue that the work was taken from. Reported at <var class="product">Model 204</var> termination or in <var>[[MONITOR TASKS command|MONITOR TASKS]]</var> output.

(type Subtask)
</td>
</tr>

<tr>
<td>DEV#</td>
<td>used the MXI interface to hold the IODEV type ( e.g. 7 for IODEV7 )</td>
</tr>

<tr>
<td>DEV5</td>
<td>Output lines to procedures defined during the run</td>
</tr>

<tr>
<td>DEV6</td>
<td>Input lines from included procedures</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly VTAM) 3270s</td>
</tr>

<tr>
<td>DEV8</td>
<td>Input lines from SNA Communications Server 3270s</td>
</tr>

<tr>
<td>DEV9</td>
<td>Page headers or trailers defined in requests</td>
</tr>

<tr>
<td>DEV10</td>
<td>Output lines written to directed output (USE) data sets</td>
</tr>

<tr>
<td>DEV11</td>
<td>Output lines to remote User Language full screen</td>
</tr>

<tr>
<td>DEV12</td>
<td>Input lines from a remote User Language full screen</td>
</tr>

<tr>
<td>DEV13</td>
<td>Output lines to remote SQL</td>
</tr>

<tr>
<td>DEV14</td>
<td>Input lines from remote SQL</td>
</tr>

<tr>
<td>DEV17</td>
<td>Output lines to SQL CRAM IUCU</td>
</tr>

<tr>
<td>DEV18</td>
<td>Input lines from SQL CRAM</td>
</tr>

<tr>
<td>DEV19</td>
<td>Output lines to remote SQL LU62</td>
</tr>

<tr>
<td>DEV20</td>
<td>Input lines from remote SQL LU62</td>
</tr>

<tr>
<td>DEV23</td>
<td>Input lines to CRAM IFAM</td>
</tr>

<tr>
<td>DEV24</td>
<td>Input lines from CRAM IUCU thread</td>
</tr>

<tr>
<td>DEV27</td>
<td>Terminal error messages issued for inbound Distributed Application Facility conversations</td>
</tr>

<tr>
<td>DEV28</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV31</td>
<td><var>IFDISP</var> output lines to IFAM1 programs</td>
</tr>

<tr>
<td>DEV32</td>
<td>Input arguments supplied by certain IFAM1 calls</td>
</tr>

<tr>
<td>DEV37</td>
<td>Output lines to SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV38</td>
<td>Input lines from SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV49</td>
<td>output lines to Remote Command line applications( rate or total)</td>
</tr>

<tr>
<td>DEV50</td>
<td>Lines sent to the printer when ROUTER=CICS</td>
</tr>

<tr>
<td>DEV53</td>
<td>Output lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV54</td>
<td>Input lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV55</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV56</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV57</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV58</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV59</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV60</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV61</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV62</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV63</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM parameter|MONPARM]] system parameter.</td>
</tr>

<tr>
<td>DEV64</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV65</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV66</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV67</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV68</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV69</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly
VTAM) 3270s</td>
</tr>

<tr>
<td>DEV70</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV71</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV72</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV73</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DEV74</td>
<td>Misused for UTI stats if X'08' bit set in the MONPARM system parameter.</td>
</tr>

<tr>
<td>DIRRCD</td>
<td>Number of records searched in direct searches of Table B</td>
</tr>

<tr>
<td>DKAR</td>
<td>Number of buffers allocated without page read requests</td>
</tr>

<tr>
<td>DKPR</td>
<td>Number of requests for a page (may not require real I/O)</td>
</tr>

<tr>
<td>DKPRF</td>
<td>Number of fast logical page reads. Number of DKPRs that were satisfied by pending or deferred close buffers</td>
</tr>

<tr>
<td>DKRD</td>
<td>Number of physical page reads from Model 204 files</td>
</tr>

<tr>
<td>DKRDL</td>
<td>Number of physical page reads into the below the bar buffer pool</td>
</tr>

<tr>
<td>DKRR</td>
<td> Number of real disk reads for recently requested pages
</td>
</tr>

<tr>
<td>DKSAWB</td>
<td> Anticipatory writes from the bottom of the LRU queue. The page in the buffer is then deleted and no longer available without a re-read. Usually a small statistic and typically only incremented by a few rare events.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWBL</td>
<td> Same as DKSAWB but only incremented for anticipatory writes from below the bar

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWW</td>
<td> Anticipatory writes from the anticipatory write windows set by LDKBMWND and/or LDKBMWNG

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWWL</td>
<td>Same as DKSAWW but only incremented for anticipatory writes from below the bar</td>
</tr>

<tr>
<td>DKSDIR</td>
<td> High-water mark of modified (dirty) buffers found within the DKBM statistics window which is created by the <var>LDKBMW</var> parameter. This parameter is not recommended due to the extremely heavy performance penalty imposed by a non-zero value.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSDIRT</td>
<td> The total of all modified buffers found within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSFBS</td>
<td> Times a buffer was needed, and a scan was necessary, because the oldest free buffer was not immediately available

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIP</td>
<td> The highest number of buffers skipped during any search for a free buffer. A buffer is skipped because it is not immediately available.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIPT</td>
<td> The total of all buffers skipped when looking for a free buffer

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRR</td>
<td> Number of times a page that was expected to be in the buffer pool could not be located, which necessitates a physical I/O to disk

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRRFND</td>
<td>Number of times that a page that was expected to be in the buffer pool was located there, which eliminates the need for a physical I/O</td>
</tr>

<tr>
<td>DKSTBLA</td>
<td> Table A reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLB</td>
<td> Table B reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLC</td>
<td> Table C reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLD</td>
<td> Table D reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DSKTBLE</td>
<td> Table E reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLF</td>
<td> FCT reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTKQC</td>
<td> Times the current Table B page had to be closed to allow a fourth buffer to be opened

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSWRP</td>
<td> The highwater mark of buffers with writes outstanding within the DKBM statistics window, created by the parameter LDKBMW. Rocket Software advises against setting this parameter to a non-zero value due to the extreme performance penalty imposed.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSWRPT</td>
<td> The total number of buffers with outstanding writes within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKUPTIME</td>
<td>Milliseconds of DKUPDT time</td>
</tr>

<tr>
<td>DKWR</td>
<td>Number of physical page writes to <var class="product">Model 204</var> files</td>
</tr>

<tr>
<td>DKWRL</td>
<td>Number of physical page writes from the below the bar pool</td>
</tr>

<tr>
<td>DKWTMICS</td>
<td>Total wait time in microseconds for Disk I/O waits counted by DKWTS.
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DKWTS</td>
<td>Number Disk I/O waits
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DUMP</td>
<td>Writes to <var class="product">Model 204</var> file backups (DUMP command output)</td>
</tr>

<tr>
<td>DUPDTS</td>
<td>Records written to a deferred update data set for the file</td>
</tr>

<tr>
<td>ECCALL</td>
<td>Number of External Call Facility calls</td>
</tr>

<tr>
<td>ECCNCT</td>
<td>External Call Facility - Elapsed time for external program</td>
</tr>

<tr>
<td>ECCTOUT</td>
<td>Number of External Call Facility calls that timed out (program or subtask unavailable)</td>
</tr>

<tr>
<td>ECCWAITM</td>
<td>ECF – Number of calls that waited for module to become available</td>
</tr>

<tr>
<td>ECCWAITS</td>
<td>Number of External Call Facility calls that waited for a subtask to become available</td>
</tr>

<tr>
<td>ECDELETE</td>
<td>Number of EXTERNAL DELETE calls to External Call Facility</td>
</tr>

<tr>
<td>ECLOAD</td>
<td>Number of EXTERNAL LOAD calls to External Call Facility</td>
</tr>

<tr>
<td>ECMODMAX</td>
<td>ECF – Highwater mark of modules loaded</td>
</tr>

<tr>
<td>ECNAMMAX</td>
<td>External Call Facility – High-water mark of call names defined</td>
</tr>

<tr>
<td>ECTSKMAX</td>
<td>External Call Facility – High-water mark of subtasks active</td>
</tr>

<tr>
<td>ECTWAITM</td>
<td>External Call Facility – Elapsed time spent waiting for a module to become available</td>
</tr>

<tr>
<td>ECTWAITS</td>
<td>External Call Facility – Elapsed time spent waiting for a subtask to become available</td>
</tr>

<tr>
<td>ERRPDL</td>
<td>Highwater mark of the system pushdown list</td>
</tr>

<tr>
<td>FBMX</td>
<td>disk buffer hwm</td>
</tr>

<tr>
<td>FBWT</td>
<td>Number of waits for a disk buffer</td>
</tr>

<tr>
<td>FINDS</td>
<td>Number of FIND statements evaluated</td>
</tr>

<tr>
<td>FSCB</td>
<td>High-water mark of bytes used in the FSCB</td>
</tr>

<tr>
<td>FSCBSW</td>
<td>Number of full-screen buffer swaps</td>
</tr>

<tr>
<td>FTBL</td>
<td>Highwater mark of FTBL appearing in CMPL and EVAL lines for requests containing a field name reference in group context. If one or more groups are opened but no field name references are made, the portion of FTBL used by the open groups is not reported.</td>
</tr>

<tr>
<td>GTBL</td>
<td>Highwater mark of GTBL</td>
</tr>

<tr>
<td>GTBLRS</td>
<td>Number of GTBL rearrangements required to add a global object</td>
</tr>

<tr>
<td>GTBLRU</td>
<td>Number of GTBL rearrangements required to add a global string variable</td>
</tr>

<tr>
<td>HEAP</td>
<td>Dynamic memory highwater mark</td>
</tr>

<tr>
<td>HRDRSTRT</td>
<td>number of hard restarts</td>
</tr>

<tr>
<td>IN</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>INCMFS</td>
<td>Input lines from CMS full screen</td>
</tr>

<tr>
<td>INCMIO</td>
<td>Input lines from CMS non-full screen</td>
</tr>

<tr>
<td>INCRAM</td>
<td>Input lines from Remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>INVMFS</td>
<td>Input lines from IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>INVMIF</td>
<td>Input arguments supplied by certain IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>INVMIO</td>
<td>Input lines from IUCV or VMCF non-full screen thread</td>
</tr>

<tr>
<td>INXX</td>
<td>Input lines from QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>ITBL</td>
<td>Highwater mark of ITBL</td>
</tr>

<tr>
<td>IXADD</td>
<td>Number of index entries added to Tables C and D, including attempts to add duplicates</td>
</tr>

<tr>
<td>IXDEL</td>
<td>Number of entries deleted from Tables C and D</td>
</tr>

<tr>
<td>LKPOST</td>
<td>Times an MP subtask posted another task to indicate that an MP lock had become available</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>Times MP subtasks invoked z/OS WAIT macros to wait for an available MP lock</td>
</tr>

<tr>
<td>LONGUPDTIME(MS)</td>
<td> Total milliseconds of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LONGUPDTS</td>
<td> Number of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LWTIM</td>
<td>Elapsed time (ms), spent waiting for a multiprocessing lock. Reported for each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals).</td>
</tr>

<tr>
<td>MAXIOX</td>
<td>Number of times <var class="product">Model 204</var> waited for a free database buffer</td>
</tr>

<tr>
<td>MBO</td>
<td>Highwater mark of transaction backout pages

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MCP
</td>
<td>Highwater mark of transaction checkpoint spans

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MOVE</td>
<td>Number of times the scheduler switched from one user to another</td>
</tr>

<tr>
<td>MPHASHD</td>
<td>MP duplicate hash entries found</td>
</tr>

<tr>
<td>MPLKPREM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting due to operating system preemption.

This is the elapsed time between when an MP lock becomes available (lock post) making a task ready to run, and when the task actually gets the CPU. That preemption delay is caused by the operating system dispatching other tasks ahead of this task.

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPLKWTIM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting for MP locks

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPR</td>
<td>Highwater mark of transaction pre-images

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MQAPICNT</td>
<td>MQ/204 – Count of MQ/Series API calls</td>
</tr>

<tr>
<td>MQAPITIM </td>
<td>MQ/204 – Elapsed time of MQSeries API calls</td>
</tr>

<tr>
<td>MQBYTEIN</td>
<td>MQ/204 – Total bytes retrieved (MQGET)</td>
</tr>

<tr>
<td>MQBYTEOU</td>
<td>MQ/204 – Total bytes sent (MQPUT/MQPUT1)</td>
</tr>

<tr>
<td>MQGETS</td>
<td>MQ/204 – Number of MQGETs performed</td>
</tr>

<tr>
<td>MQGWTCNT</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTSUC</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait that succeeded</td>
</tr>

<tr>
<td>MQGWTTIM</td>
<td>MQ/204 – Elapsed time for MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTTSP</td>
<td>MQ/204 – Total wait time specified on MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQHWQU</td>
<td>MQ/204 – High-water mark of queues concurrently in use</td>
</tr>

<tr>
<td>MQHWTASK</td>
<td>MQ/204 – High-water mark of MQ/204 subtasks in use</td>
</tr>

<tr>
<td>MQNUMQM</td>
<td>MQ/204 – Number of distinct queue managers connected</td>
</tr>

<tr>
<td>MQNUMQU</td>
<td>MQ/204 – Number of distinct queues accessed</td>
</tr>

<tr>
<td>MQPUTS</td>
<td>MQ/204 – Number of MQPUTs performed</td>
</tr>

<tr>
<td>MQWTM</td>
<td>Mean queue wait time, the average time a subtask spent waiting for work (waiting for PCBs to come into the offload queue)</td>
</tr>

<tr>
<td>MTDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from the MAINTASK queue and processed it</td>
</tr>

<tr>
<td>MTSDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from an MP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>MTZDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from a zIIP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>NTBL</td>
<td>Highwater mark of NTBL</td>
</tr>

<tr>
<td>OBJSWAP</td>
<td>number of object swaps for Sirius objects</td>
</tr>

<tr>
<td>OFFIN</td>
<td>Count of records read in by the OFFLOAD subtask</td>
</tr>

<tr>
<td>OFFOU</td>
<td>Count of records written to the OFFLOAD stream</td>
</tr>

<tr>
<td>OUT</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>OUTCMFS</td>
<td>Output lines to CMS full-screen thread</td>
</tr>

<tr>
<td>OUTCMIO</td>
<td>Output lines to CMS line-by-line thread</td>
</tr>

<tr>
<td>OUTCRAM</td>
<td>Output lines from remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>OUTPB</td>
<td>Highwater mark of OUTPB</td>
</tr>

<tr>
<td>OUTVMFS</td>
<td>Output lines to IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>OUTVMIF</td>
<td>Output lines to IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>OUTVMIO</td>
<td>Output lines to IUCV or VMCF line-by-line threads</td>
</tr>

<tr>
<td>OUTXX</td>
<td>Output lines to QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>PBRSFLT</td>
<td>Number of private buffer reservation faults</td>
</tr>

<tr>
<td>PCPU</td>
<td>Percentage of time <var class="product">Model 204</var> was given the CPU when it wanted CPU time. In an MP environment, system PCPU is the sum of CPU time in all tasks divided by the sum of elapsed time in all tasks.</td>
</tr>

<tr>
<td>PDL</td>
<td>Highwater mark of the pushdown list</td>
</tr>

<tr>
<td>PETIM</td>
<td>Elapsed time (ms), spent waiting due to OS preemption. Reported for the MAINTASK and each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals)</td>
</tr>

<tr>
<td>PNDGTIME</td>
<td>Milliseconds of unnecessary broken time</td>
</tr>

<tr>
<td>PR</td>
<td>Real time consumed, in milliseconds. PCPU = CPU / PR.</td>
</tr>

<tr>
<td>QTBL</td>
<td>Highwater mark of QTBL</td>
</tr>

<tr>
<td>RCV</td>
<td>Number of blocks needed for subtransaction recovery

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>RECADD</td>
<td>Number of records started in Table B, not including extension records</td>
</tr>

<tr>
<td>RECDEL</td>
<td>Number of records deleted from Table B, not including extension records or records deleted by DELETE RECORDS or IFDSET</td>
</tr>

<tr>
<td>RECDS</td>
<td>Number of records processed by FOR statements, SORT statements, IFGET calls, or IFPOINT calls, or similar SQL record processing</td>
</tr>

<tr>
<td>REDY</td>
<td> Percentage of performance samples at which the user was ready to run (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>REQ</td>
<td>Number of SOUL requests evaluated</td>
</tr>

<tr>
<td>REST</td>
<td>Number of reads from a <var class="product">Model 204</var> file backup (<var>RESTORE</var> command)</td>
</tr>

<tr>
<td>RETRYA</td>
<td>Page retries in Table A</td>
</tr>

<tr>
<td>RETRYC</td>
<td>Page retries in Table C</td>
</tr>

<tr>
<td>RQTM</td>
<td>Elapsed time for the activity being reported, exclusive of terminal I/O time</td>
</tr>

<tr>
<td>RSXCOMP</td>
<td>Number of compactions of the record locking table. If greater than 0, increase <var>LRETBL</var>.</td>
</tr>

<tr>
<td>RUNG</td>
<td> Percentage of performance samples at which the user was running (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SCHDCPU</td>
<td>In MP configuration, total scheduler CPU for the user or request</td>
</tr>

<tr>
<td>SCREENS</td>
<td>Total number of full-screen reads (<var>READ SCREEN</var> statements) evaluated by a SOUL request.</td>
</tr>

<tr>
<td>SFTRSTRT</td>
<td>number of soft restarts.</td>
</tr>

<tr>
<td>SGMTI</td>
<td>Number of input lines from included procedures</td>
</tr>

<tr>
<td>SGMTO</td>
<td>Number of output lines to procedures defined by the user</td>
</tr>

<tr>
<td>SLIC</td>
<td>Number of times that the user was time-sliced by the <var class="product">Model 204</var> scheduler</td>
</tr>

<tr>
<td>SMPLS</td>
<td>Number of performance sample points at which the user was active or total number of performance samples taken at the system level (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SORTS</td>
<td>Number of SOUL <var>SORT</var> statements or SQL sorts evaluated</td>
</tr>

<tr>
<td>SQLI</td>
<td>Remote SQL input highwater mark</td>
</tr>

<tr>
<td>SQLO</td>
<td>Remote SQL output highwater mark</td>
</tr>

<tr>
<td>SQRD</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>SQWR</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>STBL</td>
<td>Highwater mark of STBL</td>
</tr>

<tr>
<td>STCPU</td>
<td>Total amount of time, in milliseconds, that the user has run in an MP offload subtask</td>
</tr>

<tr>
<td>STDEQ</td>
<td>Number of times that an MP subtask took a unit of work from an MP subtask queue and processed it</td>
</tr>

<tr>
<td>STIMERS</td>
<td>Total number of STIMER or STIMERM calls</td>
</tr>

<tr>
<td>STPOST</td>
<td>Times MP subtasks performed real operating system POSTs to send work to the maintask</td>
</tr>

<tr>
<td>STRECDS</td>
<td>Number of records processed by SORT statements or SQL sorts</td>
</tr>

<tr>
<td>STWAIT</td>
<td>Number of times MP subtasks invoked z/OS WAIT macros to wait for work from the maintask</td>
</tr>

<tr>
<td>STZDEQ</td>
<td>Number of times that an MP subtask took a unit of work from a zIIP subtask queue and processed it because the MP subtask was idle</td>
</tr>

<tr>
<td>SVAC</td>
<td>Active servers (an average, included on a performance line)</td>
</tr>

<tr>
<td>SVMX</td>
<td>Highwater mark for servers (0 if no server swapping)</td>
</tr>

<tr>
<td>SVPAGES</td>
<td><code>SVPAGES * 4096</code> is the number of bytes transferred as a result of server reads and writes</td>
</tr>

<tr>
<td>SVRD</td>
<td>Number of server reads</td>
</tr>

<tr>
<td>SVWR</td>
<td>Number of server writes</td>
</tr>

<tr>
<td>SWPG</td>
<td>Percentage of performance samples at which the user was swapping in or out (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>SWT</td>
<td>Times <var class="product">Model 204</var> issued a real WAIT while not in user-switching mode</td>
</tr>

<tr>
<td>TEMX</td>
<td>Highwater mark of CCATEMP pages used in the expansion area</td>
</tr>

<tr>
<td>TFMX</td>
<td>Highwater mark of CCATEMP pages used</td>
</tr>

<tr>
<td>TSMX</td>
<td>Highwater mark of CCATEMP pages used in the small model page pool</td>
</tr>

<tr>
<td>TTBL</td>
<td>Highwater mark of TTBL</td>
</tr>

<tr>
<td>UBUFHWS</td>
<td>Highwater mark, in bytes, of user's Universal Buffer</td>
</tr>

<tr>
<td>UDD</td>
<td>Number of lines written to a directed output (<var>USE</var>) data set</td>
</tr>

<tr>
<td>UPDTTIME(MS)</td>
<td>Number of milliseconds that a file was being updated

UPT(MS) appears as the column header for this statistic on a report
</td>
</tr>

<tr>
<td>UPDTTIME</td>
<td>Number of milliseconds that the user was actively updating at least one file</td>
</tr>

<tr>
<td>USMX</td>
<td>Highwater mark for simultaneous active users (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>USRS</td>
<td>Average number of active users (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>VTBL</td>
<td>Number of VTBL entries at the end of compilation (CMPL) processing or the end of evaluation (EVAL) processing</td>
</tr>

<tr>
<td>WAIT</td>
<td>Number of real operating system waits</td>
</tr>

<tr>
<td>WTCFR</td>
<td>Number of times that the user waited to obtain a critical file resource, either share or exclusive

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTRLK</td>
<td>Number of times that the user waited to obtain a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTSV</td>
<td>Percentage of performance samples at which the user was waiting for a server (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>XTBL</td>
<td>Highwater mark of XTBL</td>
</tr>

<tr>
<td>ZTCPU</td>
<td>The CPU (ms) consumed on a zIIP processor by the MAINTASK, an MP subtask or a zIIP subtask. Reported for each task at <var class="product">Model 204</var> termination and in <var>MONITOR TASKS</var> output (for Model 5 terminals only)</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>The number of times that a zIIP subtask took a unit of work from a zIIP subtask queue and processed it</td>
</tr>
</table>

==Header and trailer entries (Type 0)==

Each journal block begins with a header record and ends with a trailer record.

===Header entries (Type 0)===

Header entries have the format shown in the following table: 
<table>
<caption style="margin-right:6em">Header entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entire journal record, including header and trailer</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Flags used by recovery</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH </td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">4</td>
<td>Binary</td>
<td> Sequence number </td>
</tr>

<tr>
<td>16(10)</td>
<td align="right">10</td>
<td>Binary</td>
<td> System Store Clock Extended (STCKE) value to provide picosecond accuracy on the journal date/time stamp

Bytes 1-9 || byte 16 
</td>
</tr>

<tr>
<td>26(1A)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of header, type 00</td>
</tr>

<tr>
<td>28(1C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Version in hex</td>
</tr>

<tr>
<td>30(1E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Version in EBCDIC</td>
</tr>

<tr>
<td>38(26)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Job name</td>
</tr>

<tr>
<td>46(2E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>JES Job ID</td>
</tr>

<tr>
<td>54(36)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>SMF System ID</td>
</tr>
</table>
<ul>
<li>If the flag byte at offset 3 of type 00 has the X'02' bit on, then it is a header record from <var class="product">Model 204</var> version 7.4.0 or later with its length at offset X'1A'.</li>

<li>If that flag byte has the X'01' bit on, then the header is from version 7.1.0 and is 26 bytes in length. </li>

<li>If neither of those bits is on, then the header is a from a pre-7.1.0 version and is 16 bytes in length.</li>
</ul>

===Recovery flags===

Flags used by recovery can have the value of X'00' or a sum of any of the following: 
<table>
<tr class="head">
<th>Value</th>
<th>Block contains these records...</th>
</tr>

<tr>
<td>X'80'</td>
<td>Type 1</td>
</tr>

<tr>
<td>X'40'</td>
<td>Type 2</td>
</tr>

<tr>
<td>X'20'</td>
<td>Type 3</td>
</tr>

<tr>
<td>X'10'</td>
<td>Type 4</td>
</tr>

<tr>
<td>X'08'</td>
<td>Type 5</td>
</tr>

<tr>
<td>X'04'</td>
<td>Type 6</td>
</tr>
</table>

===Sequence numbers===

The sequence number represents the number of each journal record, starting at 0 and increasing by 1. A merged journal (output of the MERGEJ utility) sequence number consists of a 2-byte hexadecimal number at offset 12(0C), which indicates the input file this journal record came from, and a 2-byte hexadecimal field at offset 14(0E), which indicates the sequence within the INPUT journal.

===Trailer entries (Type 0)===

Trailer entries have the format shown in the following table: 
<table>
<caption>Trailer entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data </td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Recovery entries (Types 1-6)==

Entry types X'01' through X'06' contain information used for recovery. They follow the same general format as all other journal entries. There is no type X'07' journal entry. 

The format of the recovery entries is meaningful only in the context of the <var class="product">Model 204</var> ROLL FORWARD algorithm. However, entry types might be of interest in some statistics gathering applications, as follows: 
<table>
<tr class="head">
<th>Type </th>
<th>Contains recovery information from...</th>
</tr>

<tr>
<td>1 </td>
<td>Discontinuity</td>
</tr>

<tr>
<td>2 </td>
<td> Begin update unit.

More than one type 2 entry can be written for each update unit. The update unit number appears as a 4-byte binary number at offset 16(10).
</td>
</tr>

<tr>
<td>3 </td>
<td> End update unit.

The update unit number appears in the same format and location as the type 2 entry.
</td>
</tr>

<tr>
<td>4</td>
<td>File state information: opened, closed, dumped, file parameter list (FPL) page preimage logged or open at the time of a checkpoint</td>
</tr>

<tr>
<td>5 </td>
<td>Checkpoint</td>
</tr>

<tr>
<td>6 </td>
<td>File update </td>
</tr>
</table>

==System statistics entries (Type 8)==

Cumulative statistics, listed by offset in the [[#System performance statistics|Layout of system subtype X'02' entries]] table, are kept for the entire system. Final, partial, and performance system statistics are written to the journal during <var class="product">Model 204</var> termination in a line that begins with:
ST $$$ SYSTEM='version#'


For additional information about:
<ul>
<li>Using system statistics for performance monitoring, see [[Performance monitoring and tuning]]. </li>

<li>Disk buffer monitor statistics and parameters, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </li>
</ul>

===Final statistics===

The system final statistics line, similar to the following, is produced as part of system termination: 
ST $$$ SYSTEM='5A 'AUDIT=43 OUT=38 IN=14 WAIT=19 ...


===Partial statistics===

Statistics in a system partial statistics line, similar to the following, accumulate from the beginning of the run, if the User 0 <var>[[ACCTIM parameter|ACCTIM]]</var> parameter is nonzero: 
ST $$$ SYSTEM='6.1.0'PARTIAL=3 AUDIT=19 OUT=10 IN=5 WAIT=3 ...


===Performance statistics===

System performance statistic lines, similar to the following, are written if the User 0 <var>[[RPTCNT parameter|RPTCNT]]</var> and <var>[[SMPLTIM parameter|SMPLTIM]]</var> parameters are nonzero: 
ST $$$ SYSTEM='6.1.0' PERFORMANCE=n


The numbers determined at the performance sample points are averaged for the entire run. 

===Entry formats===

System statistics entries have the format shown in the following table: 
<table>
<caption>System statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'08'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:

X'00' = final statistics

X'01' = partial statistics

X'02' = performance statistics

X'04' = additional disk buffer monitor

X'08' = subtask statistics
</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Subtask number if subtype = X'08'; otherwise unused</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Unused</td>
</tr>

<tr>
<td>16(10) to end of journal</td>
<td align="right"> — </td>
<td align="right"> — </td>
<td>

Contents depend on subtypes, shown in tables in the following sections:
<ul>
<li>[[#System final and partial statistics|System final and partial statistics]]</li>

<li>[[#System performance statistics|System performance statistics]]</li>

<li>[[#Additional disk buffer monitor statistics|Additional disk buffer monitor statistics]]</li>

<li>[[#User since-last statistics|User since-last statistics]]</li>
</ul>
</td> </tr>
</table>

==System final and partial statistics==

For subtypes X'00' (final statistics) and X'01' (partial statistics), the layout of the remainder of the entry is shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
The following statistics are data type Binary. However, the length varies — either 4 or 8, to accommodate 64-bit system architecture. 
<table>
<caption>System final and partial statistics</caption>
<tr class="head">
<th>Offset dec(hex) </th>
<th>Length </th>
<th>Description</th>
</tr>

<tr>
<td>16(10) </td>
<td>8 </td>
<td>AUDIT</td>
</tr>

<tr>
<td>24(18) </td>
<td>8 </td>
<td>OUT</td>
</tr>

<tr>
<td>32(20) </td>
<td>8 </td>
<td>IN</td>
</tr>

<tr>
<td>40(28) </td>
<td>8 </td>
<td>OUTXX</td>
</tr>

<tr>
<td>48(30) </td>
<td>8 </td>
<td>INXX</td>
</tr>

<tr>
<td>56(38) </td>
<td>8 </td>
<td>DEV5</td>
</tr>

<tr>
<td>64(40) </td>
<td>8 </td>
<td>DEV6</td>
</tr>

<tr>
<td>72(48) </td>
<td>8 </td>
<td>DEV7</td>
</tr>

<tr>
<td>80(50) </td>
<td>8 </td>
<td>DEV8</td>
</tr>

<tr>
<td>88(58) </td>
<td>8 </td>
<td>DEV9</td>
</tr>

<tr>
<td>96(60) </td>
<td>8 </td>
<td>DEV10</td>
</tr>

<tr>
<td>104(68) </td>
<td>8 </td>
<td>DEV11</td>
</tr>

<tr>
<td>112(70) </td>
<td>8 </td>
<td>DEV12</td>
</tr>

<tr>
<td>120(78) </td>
<td>8 </td>
<td>DEV13</td>
</tr>

<tr>
<td>128(80) </td>
<td>8 </td>
<td>DEV14</td>
</tr>

<tr>
<td>136(88) </td>
<td>8 </td>
<td>OUTTTY</td>
</tr>

<tr>
<td>144(90) </td>
<td>8 </td>
<td>INTTY</td>
</tr>

<tr>
<td>152(98) </td>
<td>8 </td>
<td>DEV17</td>
</tr>

<tr>
<td>160(A0) </td>
<td>8 </td>
<td>DEV18</td>
</tr>

<tr>
<td>168(A8) </td>
<td>8 </td>
<td>DEV19</td>
</tr>

<tr>
<td>176(B0) </td>
<td>8 </td>
<td>DEV20</td>
</tr>

<tr>
<td>184(B8) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>192(C0) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>200(C8) </td>
<td>8 </td>
<td>DEV23</td>
</tr>

<tr>
<td>208(D0) </td>
<td>8 </td>
<td>DEV24</td>
</tr>

<tr>
<td>216(D8) </td>
<td>8 </td>
<td>DEV25</td>
</tr>

<tr>
<td>224(E0) </td>
<td>8 </td>
<td>DEV26</td>
</tr>

<tr>
<td>232(E8) </td>
<td>8 </td>
<td>DEV27</td>
</tr>

<tr>
<td>240(F0) </td>
<td>8 </td>
<td>DEV28</td>
</tr>

<tr>
<td>248(F8) </td>
<td>8 </td>
<td>OUTCRAM</td>
</tr>

<tr>
<td>256(100) </td>
<td>8 </td>
<td>INCRAM</td>
</tr>

<tr>
<td>264(108) </td>
<td>8 </td>
<td>DEV31</td>
</tr>

<tr>
<td>272(110) </td>
<td>8 </td>
<td>DEV32</td>
</tr>

<tr>
<td>280(118) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>288(120) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>296(128) </td>
<td>8 </td>
<td>DEV35</td>
</tr>

<tr>
<td>304(130) </td>
<td>8 </td>
<td>DEV36</td>
</tr>

<tr>
<td>312(138) </td>
<td>8 </td>
<td>DEV37</td>
</tr>

<tr>
<td>320(140) </td>
<td>8 </td>
<td>DEV38</td>
</tr>

<tr>
<td>328(148) </td>
<td>8 </td>
<td>OUTVMIO</td>
</tr>

<tr>
<td>336(150) </td>
<td>8 </td>
<td>INVMIO</td>
</tr>

<tr>
<td>344(158) </td>
<td>8 </td>
<td>OUTVMFS</td>
</tr>

<tr>
<td>352(160) </td>
<td>8 </td>
<td>INVMFS</td>
</tr>

<tr>
<td>360(168) </td>
<td>8 </td>
<td>OUTVMIF</td>
</tr>

<tr>
<td>368(170) </td>
<td>8 </td>
<td>INVMIF</td>
</tr>

<tr>
<td>376(178) </td>
<td>8 </td>
<td>OUTCMIO</td>
</tr>

<tr>
<td>384(180) </td>
<td>8 </td>
<td>INCMIO</td>
</tr>

<tr>
<td>392(188) </td>
<td>8 </td>
<td>OUTCMFS</td>
</tr>

<tr>
<td>400(190) </td>
<td>8 </td>
<td>INCMFS</td>
</tr>

<tr>
<td>408(198) </td>
<td>8 </td>
<td>DEV49</td>
</tr>

<tr>
<td>416(1A0) </td>
<td>8 </td>
<td>DEV50</td>
</tr>

<tr>
<td>424(1A8) </td>
<td>8 </td>
<td>OFFIN</td>
</tr>

<tr>
<td>432(1B0) </td>
<td>8 </td>
<td>OFFOU</td>
</tr>

<tr>
<td>440(1B8) </td>
<td>8 </td>
<td>DEV53</td>
</tr>

<tr>
<td>448(1C0) </td>
<td>8 </td>
<td>DEV54</td>
</tr>

<tr>
<td>456(1C8) </td>
<td>8 </td>
<td>DEV55</td>
</tr>

<tr>
<td>464(1D0) </td>
<td>8 </td>
<td>DEV56</td>
</tr>

<tr>
<td>472(1D8) </td>
<td>8 </td>
<td>DEV57</td>
</tr>

<tr>
<td>480(1E0) </td>
<td>8 </td>
<td>DEV58</td>
</tr>

<tr>
<td>488(1E8) </td>
<td>8 </td>
<td>DEV59</td>
</tr>

<tr>
<td>496(1F0) </td>
<td>8 </td>
<td>DEV60</td>
</tr>

<tr>
<td>504(1F8) </td>
<td>8 </td>
<td>DEV61</td>
</tr>

<tr>
<td>512(200) </td>
<td>8 </td>
<td>DEV62</td>
</tr>

<tr>
<td>520(208) </td>
<td>8 </td>
<td>DEV63</td>
</tr>

<tr>
<td>528(210) </td>
<td>8 </td>
<td>DEV64</td>
</tr>

<tr>
<td>536(218) </td>
<td>8 </td>
<td>DEV65</td>
</tr>

<tr>
<td>544(220) </td>
<td>8 </td>
<td>DEV66</td>
</tr>

<tr>
<td>552(228) </td>
<td>8 </td>
<td>DEV67</td>
</tr>

<tr>
<td>560(230) </td>
<td>8 </td>
<td>DEV68</td>
</tr>

<tr>
<td>568(238) </td>
<td>8 </td>
<td>DEV69</td>
</tr>

<tr>
<td>576(240) </td>
<td>8 </td>
<td>DEV70</td>
</tr>

<tr>
<td>584(248) </td>
<td>8 </td>
<td>DEV71</td>
</tr>

<tr>
<td>592(250) </td>
<td>8 </td>
<td>DEV72</td>
</tr>

<tr>
<td>600(258) </td>
<td>8 </td>
<td>DEV73</td>
</tr>

<tr>
<td>608(260) </td>
<td>8 </td>
<td>DEV74</td>
</tr>

<tr>
<td>616(268) </td>
<td>4 </td>
<td>WAIT</td>
</tr>

<tr>
<td>620(26C) </td>
<td>4 </td>
<td>MPLKWTIM</td>
</tr>

<tr>
<td>624(270) </td>
<td>8 </td>
<td>DKRD</td>
</tr>

<tr>
<td>632(278) </td>
<td>8 </td>
<td>DKWR</td>
</tr>

<tr>
<td>640(280) </td>
<td>4 </td>
<td>SVRD</td>
</tr>

<tr>
<td>644(284) </td>
<td>4 </td>
<td>SVWR</td>
</tr>

<tr>
<td>648(288) </td>
<td>8 </td>
<td>CPU</td>
</tr>

<tr>
<td>656(290) </td>
<td>8 </td>
<td>REQ</td>
</tr>

<tr>
<td>664(298) </td>
<td>8 </td>
<td>MOVE</td>
</tr>

<tr>
<td>672(2A0) </td>
<td>4 </td>
<td>DUMP</td>
</tr>

<tr>
<td>676(2A4) </td>
<td>4 </td>
<td>REST</td>
</tr>

<tr>
<td>680(2A8) </td>
<td>4 </td>
<td>SLIC</td>
</tr>

<tr>
<td>684(2AC) </td>
<td>4 </td>
<td>CNCT</td>
</tr>

<tr>
<td>688(2B0) </td>
<td>4 </td>
<td>FBWT</td>
</tr>

<tr>
<td>692(2B4) </td>
<td>4 </td>
<td>SWT</td>
</tr>

<tr>
<td>696(2B8) </td>
<td>4 </td>
<td>ERRPDL</td>
</tr>

<tr>
<td>700(2BC) </td>
<td>4 </td>
<td>MPLKPREM</td>
</tr>

<tr>
<td>704(2C0) </td>
<td>8 </td>
<td>RECADD</td>
</tr>

<tr>
<td>712(2C8) </td>
<td>8 </td>
<td>RECDEL</td>
</tr>

<tr>
<td>720(2D0) </td>
<td>8 </td>
<td>BADD</td>
</tr>

<tr>
<td>728(2D8) </td>
<td>8 </td>
<td>BDEL</td>
</tr>

<tr>
<td>736(2E0) </td>
<td>8 </td>
<td>BCHG</td>
</tr>

<tr>
<td>744(2E8) </td>
<td>8 </td>
<td>IXADD</td>
</tr>

<tr>
<td>752(2F0) </td>
<td>8 </td>
<td>IXDEL</td>
</tr>

<tr>
<td>760(2F8) </td>
<td>8 </td>
<td>FINDS</td>
</tr>

<tr>
<td>768(300) </td>
<td>4 </td>
<td>SORTS</td>
</tr>

<tr>
<td>772(304) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>776(308) </td>
<td>8 </td>
<td>RECDS</td>
</tr>

<tr>
<td>784(310) </td>
<td>8 </td>
<td>STRECDS</td>
</tr>

<tr>
<td>792(318) </td>
<td>8 </td>
<td>DKAR</td>
</tr>

<tr>
<td>800(320) </td>
<td>8 </td>
<td>DKPR</td>
</tr>

<tr>
<td>808(328) </td>
<td>4 </td>
<td>DKRR</td>
</tr>

<tr>
<td>812(32C) </td>
<td>4 </td>
<td>FBMX</td>
</tr>

<tr>
<td>816(330) </td>
<td>4 </td>
<td>TFMX</td>
</tr>

<tr>
<td>820(334) </td>
<td>4 </td>
<td>USMX</td>
</tr>

<tr>
<td>824(338) </td>
<td>4 </td>
<td>SVMX</td>
</tr>

<tr>
<td>828(33C) </td>
<td>4 </td>
<td>SFTRSTRT (number of soft restarts)</td>
</tr>

<tr>
<td>832(340) </td>
<td>8 </td>
<td>APSYLD</td>
</tr>

<tr>
<td>840(348) </td>
<td>8 </td>
<td>APSYLDD</td>
</tr>

<tr>
<td>848(350) </td>
<td>4 </td>
<td>APSYLDT</td>
</tr>

<tr>
<td>852(354) </td>
<td>4 </td>
<td>JSCREENS</td>
</tr>

<tr>
<td>856(358) </td>
<td>8 </td>
<td>DKPRF</td>
</tr>

<tr>
<td>864(360) </td>
<td>4 </td>
<td>SMPLS</td>
</tr>

<tr>
<td>868(364) </td>
<td>4 </td>
<td>USRS</td>
</tr>

<tr>
<td>872(368) </td>
<td>4 </td>
<td>SVAC</td>
</tr>

<tr>
<td>876(36C) </td>
<td>4 </td>
<td>RUNG</td>
</tr>

<tr>
<td>880(370) </td>
<td>4 </td>
<td>REDY</td>
</tr>

<tr>
<td>884(374) </td>
<td>4 </td>
<td>BLKI</td>
</tr>

<tr>
<td>888(378) </td>
<td>4 </td>
<td>WTSV</td>
</tr>

<tr>
<td>892(37C) </td>
<td>4 </td>
<td>BLKO</td>
</tr>

<tr>
<td>896(380) </td>
<td>4 </td>
<td>SWPG</td>
</tr>

<tr>
<td>900(384) </td>
<td>4 </td>
<td>PCPU</td>
</tr>

<tr>
<td>904(388) </td>
<td>4 </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>908(38C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>912(390) </td>
<td>8 </td>
<td>STCPU</td>
</tr>

<tr>
<td>920(398) </td>
<td>8 </td>
<td>STDEQ</td>
</tr>

<tr>
<td>928(3A0) </td>
<td>8 </td>
<td>STWAIT</td>
</tr>

<tr>
<td>936(3A8) </td>
<td>4 </td>
<td>STPOST</td>
</tr>

<tr>
<td>940(3AC) </td>
<td>4 </td>
<td>LKWAIT</td>
</tr>

<tr>
<td>944(3B0) </td>
<td>4 </td>
<td>LKPOST</td>
</tr>

<tr>
<td>948(3B4) </td>
<td>4 </td>
<td>RSXCOMP</td>
</tr>

<tr>
<td>952(3B8) </td>
<td>4 </td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>956(3BC) </td>
<td>4 </td>
<td>SCREENS</td>
</tr>

<tr>
<td>960(3C0) </td>
<td>4 </td>
<td>STIMERS</td>
</tr>

<tr>
<td>964(3C4) </td>
<td>4 </td>
<td>HRDRSTRT (number of hard restarts)</td>
</tr>

<tr>
<td>968(3C8) </td>
<td>8 </td>
<td>SVPAGES</td>
</tr>

<tr>
<td>976(3D0) </td>
<td>4 </td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>980(3D4) </td>
<td>4 </td>
<td>COMMITS</td>
</tr>

<tr>
<td>984(3D8) </td>
<td>4 </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>988(3DC) </td>
<td>4 </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>992(3E0) </td>
<td>4 </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>996(3E4) </td>
<td>4 </td>
<td>MPHASHD</td>
</tr>

<tr>
<td>1000(3E8) </td>
<td>4 </td>
<td>CDLWAIT</td>
</tr>

<tr>
<td>1004(3EC) </td>
<td>4 </td>
<td>MQGETS</td>
</tr>

<tr>
<td>1008(3F0) </td>
<td>4 </td>
<td>MQPUTS</td>
</tr>

<tr>
<td>1012(3F4) </td>
<td>4 </td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>1016(3F8) </td>
<td>4 </td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>1020(3FC) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1024(400) </td>
<td>8 </td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>1032(408) </td>
<td>8 </td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>1040(410) </td>
<td>4 </td>
<td>MQHWQU</td>
</tr>

<tr>
<td>1044(414) </td>
<td>4 </td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>1048(418) </td>
<td>4 </td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>1052(41C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1056(420) </td>
<td>8 </td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>1064(428) </td>
<td>8 </td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>1072(430) </td>
<td>8 </td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>1080(438) </td>
<td>4 </td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>1084(43C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1088(440) </td>
<td>8 </td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>1096(448) </td>
<td>4 </td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>1100(44C) </td>
<td>4 </td>
<td>ECLOAD</td>
</tr>

<tr>
<td>1104(450) </td>
<td>4 </td>
<td>ECDELETE</td>
</tr>

<tr>
<td>1108(454) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1112(458) </td>
<td>8 </td>
<td>ECCALL</td>
</tr>

<tr>
<td>1120(460) </td>
<td>4 </td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>1124(464) </td>
<td>4 </td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>1128(468) </td>
<td>4 </td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>1132(46C) </td>
<td>4 </td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>1136(470) </td>
<td>4 </td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>1140(474) </td>
<td>4 </td>
<td>ECCNCT</td>
</tr>

<tr>
<td>1144(478) </td>
<td>4 </td>
<td>ECMODMAX</td>
</tr>

<tr>
<td>1148(47C) </td>
<td>4 </td>
<td>ECNAMMAX</td>
</tr>

<tr>
<td>1152(480) </td>
<td>4 </td>
<td>ECTSKMAX</td>
</tr>

<tr>
<td>1156(484) </td>
<td>4 </td>
<td>GTBLRU</td>
</tr>

<tr>
<td>1160(488) </td>
<td>4 </td>
<td>GTBLRS</td>
</tr>

<tr>
<td>1164(48C) </td>
<td>4 </td>
<td>TSMX</td>
</tr>

<tr>
<td>1168(490) </td>
<td>4 </td>
<td>TEMX</td>
</tr>

<tr>
<td>1172(494) </td>
<td>4 </td>
<td>MAXIOX</td>
</tr>

<tr>
<td>1176(498) </td>
<td>8 </td>
<td>DKRDL</td>
</tr>

<tr>
<td>1184(4A0) </td>
<td>8 </td>
<td>DKWRL</td>
</tr>

<tr>
<td>1192(4A8) </td>
<td>8 </td>
<td>CPUTOTZE</td>
</tr>

<tr>
<td>1200(4B0) </td>
<td>8 </td>
<td>CPUONZIP</td>
</tr>

<tr>
<td>1208(4B8) </td>
<td>4 </td>
<td>MPR
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1212(4BC) </td>
<td>4 </td>
<td>MBO
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1216(4C0) </td>
<td>4 </td>
<td>MCP
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1220(4C4) </td>
<td>4 </td>
<td>RCV
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1224(4C8) </td>
<td>8 </td>
<td>Spare </td>
</tr>

<tr>
<td>1232(4D0) </td>
<td>8 </td>
<td>DKWTMICS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1240(4D8) </td>
<td>8 </td>
<td>DKWTS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1248(4E0) </td>
<td>8 </td>
<td>MTDEQ</td>
</tr>

<tr>
<td>1256(4E8) </td>
<td>8 </td>
<td>MTSDEQ</td>
</tr>

<tr>
<td>1264(4F0) </td>
<td>8 </td>
<td>MTZDEQ</td>
</tr>

<tr>
<td>1272(4F8) </td>
<td>8 </td>
<td>STZDEQ</td>
</tr>

<tr>
<td>1280(500) </td>
<td>8 </td>
<td>ZTDEQ</td>
</tr>
</table>

==System performance statistics==

===Entry format===

For subtype X'02'(system performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. See [[#Description of statistics|Statistics with descriptions]] table for the meaning of each statistic. 
<table>
<caption>Layout of system subtype X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 16(10)</td>
<td>SMPLS</td>
</tr>

<tr>
<td> 20(14)</td>
<td>USRS</td>
</tr>

<tr>
<td> 24(18)</td>
<td>SVAC</td>
</tr>

<tr>
<td> 28(1C)</td>
<td>RUNG </td>
</tr>

<tr>
<td> 32(20)</td>
<td>REDY</td>
</tr>

<tr>
<td> 36(24)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 40(28)</td>
<td>WTSV</td>
</tr>

<tr>
<td> 44(2C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 48(30)</td>
<td>SWPG </td>
</tr>
</table>

==Additional disk buffer monitor statistics==

For subtype X'04' (additional disk buffer monitor statistics), the layout of the entry is shown in the following table. Each statistic in the table is: Length, 8; Data type, Binary.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Disk buffer monitor statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Disk buffer monitor statistic </th>
</tr>

<tr>
<td>16(10)</td>
<td>Spare</td>
</tr>

<tr>
<td>24(18) </td>
<td>DKSTKQC </td>
</tr>

<tr>
<td>32(20) </td>
<td>DKSWRP </td>
</tr>

<tr>
<td>40(28) </td>
<td>DKSWRPT </td>
</tr>

<tr>
<td>48(30) </td>
<td>DKSDIR </td>
</tr>

<tr>
<td>56(38) </td>
<td>DKSDIRT </td>
</tr>

<tr>
<td>64(40) </td>
<td>DKSKIP </td>
</tr>

<tr>
<td>72(48) </td>
<td>Spare </td>
</tr>

<tr>
<td>80(50) </td>
<td>Spare</td>
</tr>

<tr>
<td>88(58) </td>
<td>DKSRR </td>
</tr>

<tr>
<td>96(60) </td>
<td>DKSFBS </td>
</tr>

<tr>
<td>104(68) </td>
<td>DKSKIPT </td>
</tr>

<tr>
<td>112(70) </td>
<td>DKSAWT </td>
</tr>

<tr>
<td>120(78) </td>
<td>DKSAWW</td>
</tr>

<tr>
<td>128(80) </td>
<td>DKSAWWL</td>
</tr>

<tr>
<td>136(88) </td>
<td>DKSAWB </td>
</tr>

<tr>
<td>144(90) </td>
<td>DKSAWBL</td>
</tr>

<tr>
<td>152(98) </td>
<td>DKSRRFND </td>
</tr>

<tr>
<td>160(A0) </td>
<td>DKSTBLF </td>
</tr>

<tr>
<td>168(A8) </td>
<td>DKSTBLA </td>
</tr>

<tr>
<td>176(B0) </td>
<td>DKSTBLB </td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKSTBLC </td>
</tr>

<tr>
<td>192(C0) </td>
<td>DKSTBLD </td>
</tr>

<tr>
<td>200(C8) </td>
<td>Spare </td>
</tr>

<tr>
<td>208(D0) </td>
<td>Spare </td>
</tr>

<tr>
<td>216(D8) </td>
<td>Spare </td>
</tr>

<tr>
<td>224(E0) </td>
<td>Spare </td>
</tr>

<tr>
<td>232(E8) </td>
<td>Spare </td>
</tr>

<tr>
<td>240(F0) </td>
<td>Spare </td>
</tr>

<tr>
<td>248(F8) </td>
<td>Spare </td>
</tr>

<tr>
<td>256(100) </td>
<td>DKSTBLX </td>
</tr>

<tr>
<td>264(108) </td>
<td>DKSTBLE</td>
</tr>

<tr>
<td>272(110)</td>
<td>Spare </td>
</tr>
</table>

==Multiprocessing (MP) subtask statistics==

The following statistics apply only to installations configured for multiprocessing using MP/204. For subtype X'08' (subtask specific statistics), the layout of the entry is shown in the following table.
For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>MP subtask statistics and offsets</caption>
<tr class="head">
<th>MP statistic </th>
<th>Offset dec(hex) </th>
<th>Length</th>
</tr>

<tr>
<td>CPU </td>
<td>16(10) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PR </td>
<td>24(18) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PCPU </td>
<td>32(20) </td>
<td align="right">4</td>
</tr>

<tr>
<td>STWAIT</td>
<td>36(24)</td>
<td align="right">4</td>
</tr>

<tr>
<td>STPOST</td>
<td>40(28)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>44(2C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKPOST</td>
<td>48(30)</td>
<td align="right">4</td>
</tr>

<tr>
<td>SPARE</td>
<td>52(34)</td>
<td align="right">4</td>
</tr>

<tr>
<td>MQWTM</td>
<td>56(38) </td>
<td align="right">8</td>
</tr>

<tr>
<td>DEQ </td>
<td>64(40) </td>
<td align="right">8</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>72(48)</td>
<td align="right">8</td>
</tr>

<tr>
<td>STDEQ </td>
<td>80(50) </td>
<td align="right">8</td>
</tr>

<tr>
<td>LWTIM </td>
<td>88(58) </td>
<td align="right">4</td>
</tr>

<tr>
<td>PETIM</td>
<td>92(5C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>ZCPU</td>
<td>96(60) </td>
<td align="right">8</td>
</tr>
</table>

==User statistics entries (Type 9)==

User lines report on an individual user's activity. These statistics include:
<ul>
<li>Final (logout) and partial statistics</li>

<li>Since-last and ordered index statistics</li>

<li>Performance statistics</li>
</ul>

Each user line starts with the following statistics:
ST $$$ USERID='userid' ACCOUNT='account'


The subtype, in this case PERFORMANCE, follows USERID and ACCOUNT statistics:
ST $$$ USERID='userid' ACCOUNT='account'
PERFORMANCE=n


The format of user statistics entries is shown in the following table:
<table>
<caption>User statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'09'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:
<ul>
<li>X'00' = logout statistics</li>

<li>X'01' = since-last statistics</li>

<li>X'02' = partial statistics</li>

<li>X'04' = performance statistics</li>

<li>X'81' = since-last statistics including conflict statistics</li>

<li>X'41' = user restart forced out a since-last statistics record.</li>

<li>X'C1' = user restart forced out a since last statistics record which included conflict statistics</li>
</ul>
</td></tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>

Account:
<ul>
<li>Second argument of LOGON/LOGIN command</li>

<li>Default is user ID</li>
</ul>
</td>
</tr>

<tr>
<td>26(1A)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>User ID</td>
</tr>

<tr>
<td>36(24)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>Since-last ID =
See the [[#User since-last statistics|Activity types]] table where the possible activity types are listed.</td>
</tr>

<tr>
<td>40(28)</td>
<td align="right">1</td>
<td>Binary</td>
<td>IODEV number (added for MXI)</td>
</tr>

<tr>
<td>41(29)</td>
<td align="right">3</td>
<td>N/A</td>
<td>Unused</td>
</tr>

<tr>
<td>44(2C) to end of journal</td>
<td> </td>
<td>Binary</td>
<td>

Contents depend on subtypes, shown in:
<ul>
<li>[[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table</li>

<li>[[#Since-last in relation to final and partial statistics|Layout of user subtype X'01' and X'81' entries]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table</li>

<li>[[#Layout of performance statistics|Layout of user subtype X'04' entries]] table</li>
</ul>
</td> </tr>
</table>

==User final and partial statistics==

===Final (logout) statistics===

Final (logout) statistics, listed in the [[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table, summarize a user's activities since the last login. A LOGOUT statistics line, such as the following, is written after each logout if the parameter following ACCOUNT is not PARTIAL, LAST, or PERFORMANCE: 
yydddhhmmssnnnsssuuuuu ST $$$ ACCOUNT='NO ACCOUNT' SQRD=5 ...

<ul>
<li><var class="term">yyddd</var> is the year and Julian day.</li>

<li><var class="term">hhmmss</var> is the time of day in hours, minutes, and seconds.</li>

<li><var class="term">nnn</var> is a counter to distinguish lines produced in the same second.</li>

<li><var class="term">sss</var> is the number of the server currently handling the user. Leading zeros are suppressed.
</li>

<li><var class="term">uuuuu</var> is a 5-digit user number associated with the audit trail line. Leading zeros are suppressed.</li>
</ul>

In some cases, the account name appears as "NO USERID NO ACCOUNT". Statistics in this category are not chargeable to any one user and should be considered system overhead.

Final lines are recognized by the absence of an indicator for another type of line.

===Partial statistics===

Optional partial statistics, listed in the "Layout of user subtype X'00' and X'02' entries" table below, can be provided for a run up to a few minutes before a system failure that prevents normal termination and production of final user and system statistics. 

User partial statistics lines, such as the following, are made available for active users: 
ST $$$ ACCOUNT='NO ACCOUNT' PARTIAL=21 ...


Statistics accumulate either:
<ul>
<li>As long as the user is logged in</li>
</ul>

or
<ul>
<li>From the first terminal input to disconnection when a login is not required </li>
</ul>

Partial statistics are requested by setting the time interval, in minutes, between successive partial lines on User 0's parameter line with the <var>ACCTIM</var> parameter. <var>ACCTIM</var> must be nonzero. 

The contents of the statistics portion of the entry, starting at offset <code>40(28)</code>, depends upon the subtype of the entry. 

Partial statistics lines are indicated on the journal by the parameter <code>PARTIAL=n</code>, where <var class="term">n</var> is a counter from the beginning of the run. <code>PARTIAL=n</code> immediately follows the type parameter.

For subtypes X'00' (logout statistics), and X'02' (partial statistics), the layout of the remainder of the entry is shown in the following table. Each statistic in the table is: Length, 4; Data type, Binary. For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Layout of user subtype X'00' and X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>40(28)</td>
<td>CNCT</td>
</tr>

<tr>
<td>44(2C)</td>
<td>DKRD </td>
</tr>

<tr>
<td>48(30)</td>
<td>DKWR </td>
</tr>

<tr>
<td>52(34)</td>
<td>SQRD</td>
</tr>

<tr>
<td>56(38)</td>
<td>SQWR</td>
</tr>

<tr>
<td>60(3C)</td>
<td>SGMTI </td>
</tr>

<tr>
<td>64(40)</td>
<td>SGMTO </td>
</tr>

<tr>
<td>68(44)</td>
<td>SVRD</td>
</tr>

<tr>
<td>72(48)</td>
<td>SVWR </td>
</tr>

<tr>
<td>76(4C)</td>
<td>CPU </td>
</tr>

<tr>
<td>80(50)</td>
<td>REQ </td>
</tr>

<tr>
<td>84(54)</td>
<td>MOVE </td>
</tr>

<tr>
<td>88(58)</td>
<td>DUMP </td>
</tr>

<tr>
<td>92(5C)</td>
<td>REST </td>
</tr>

<tr>
<td>96(60)</td>
<td>SLIC </td>
</tr>

<tr>
<td>100(64)</td>
<td>AUDIT </td>
</tr>

<tr>
<td>104(68) </td>
<td>WAIT </td>
</tr>

<tr>
<td>108(6C)</td>
<td>FBWT </td>
</tr>

<tr>
<td>112(70)</td>
<td>UDD </td>
</tr>

<tr>
<td>116(74)</td>
<td>RECADD </td>
</tr>

<tr>
<td>120(78)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>124(7C)</td>
<td>BADD </td>
</tr>

<tr>
<td>128(80)</td>
<td>BDEL</td>
</tr>

<tr>
<td>132(84)</td>
<td>BCHG </td>
</tr>

<tr>
<td>136(88)</td>
<td>IXADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>FINDS </td>
</tr>

<tr>
<td>148(94)</td>
<td>SORTS</td>
</tr>

<tr>
<td>152(98)</td>
<td>RECDS </td>
</tr>

<tr>
<td>156(9C)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>160(A0)</td>
<td>DKAR </td>
</tr>

<tr>
<td>164(A4)</td>
<td>DKPR </td>
</tr>

<tr>
<td>168(A8)</td>
<td>DKRR </td>
</tr>

<tr>
<td>172(AC)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>UPDTTIME(MS) </td>
</tr>

<tr>
<td>184(B8)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>188(BC)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>192(C0)</td>
<td>SMPLS </td>
</tr>

<tr>
<td>196(C4)</td>
<td>RUNG </td>
</tr>

<tr>
<td>200(C8)</td>
<td>REDY</td>
</tr>

<tr>
<td>204(CC)</td>
<td>BLKI</td>
</tr>

<tr>
<td>208(D0)</td>
<td>WTSV </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BLKO </td>
</tr>

<tr>
<td>216(D8)</td>
<td>SWPG </td>
</tr>

<tr>
<td>220(DC)</td>
<td>PCPU </td>
</tr>

<tr>
<td>224(E0)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>228(E4)</td>
<td>BXCHNG </td>
</tr>

<tr>
<td>232(E8)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>236(EC)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>240(F0)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>244(F4)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>248(F8)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>252(FC)</td>
<td>BXRFND</td>
</tr>

<tr>
<td>256(100)</td>
<td>BXFREE </td>
</tr>

<tr>
<td>260(104)</td>
<td>STCPU </td>
</tr>

<tr>
<td>264(108)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>268(10C)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>272(110)</td>
<td>SCREENS </td>
</tr>

<tr>
<td>276(114)</td>
<td>SVPAGES </td>
</tr>

<tr>
<td>280(118)</td>
<td>PBRSFLT </td>
</tr>

<tr>
<td>284(11C)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>292(124)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQBYTOU</td>
</tr>

<tr>
<td>308((134)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>380(17C)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>384(180)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>388(184)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>392(188)</td>
<td>Spare</td>
</tr>

<tr>
<td>396(18C) </td>
<td>MPR (V7.7 onwards)</td>
</tr>

<tr>
<td>400(190) </td>
<td>MBO (V7.7 onwards)</td>
</tr>

<tr>
<td>404(194)</td>
<td>DEV#</td>
</tr>

<tr>
<td>408(198)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>412(19C)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>CCATDIFF</td>
</tr>

</table>

==User since-last statistics==

===Since-last statistics===

Statistics are kept for each SOUL request, host language interface call, and a number of <var class="product">Model 204</var> system commands. When each request or command completes, a since-last statistics line is written. The line includes the <var>ACCOUNT</var> parameter at the beginning, followed by the <var>IODEV</var> parameter and the <var>LAST</var> parameter.

Several <var>MONITOR</var> commands produce displays containing the user's last or current activity in the <code>FUNC</code> column. When this activity completes, statistics are also written to CCAAUDIT and the activity is described in ST lines as <code>LAST='activity'</code>.

====Syntax====
ST $$$ USERID='userid' ACCOUNT='accountname' IODEV='devicetype' LAST='acty'

Where:

<var class="term">acty</var> can be one of the following: 
<table>
<caption>Activity types</caption>
<tr class="head">
<th>Option</th>
<th>Meaning</th>
</tr>

<tr>
<td>BLDR</td>
<td><var>BLDREUSE</var> command</td>
</tr>

<tr>
<td>BLDX </td>
<td><var>Z</var> command</td>
</tr>

<tr>
<td>CMPL </td>
<td>Compilation of a SOUL request</td>
</tr>

<tr>
<td>CPTB</td>
<td><var>COMPACTB</var> command</td>
</tr>

<tr>
<td>CPTE</td>
<td><var>COMPACTE</var> command</td>
</tr>

<tr>
<td>CPYP </td>
<td><var>COPY PROCEDURE</var> command</td>
</tr>

<tr>
<td>CREA</td>
<td><var>CREATE FILE filename</var> command</td>
</tr>

<tr>
<td>DISP </td>
<td><var>DISPLAY PROCEDURE</var> command</td>
</tr>

<tr>
<td>DUMP </td>
<td><var>DUMP file</var> command</td>
</tr>

<tr>
<td>EDIT </td>
<td>Editing a request</td>
</tr>

<tr>
<td>EVAL </td>
<td>Evaluation of a SOUL request</td>
</tr>

<tr>
<td>EXEC </td>
<td>Execution of an SQL request</td>
</tr>

<tr>
<td>FLDC </td>
<td>Compilation of a FLOD procedure</td>
</tr>

<tr>
<td>FLDE </td>
<td>Evaluation of a FLOD procedure</td>
</tr>

<tr>
<td>IMPC </td>
<td>Implied commit</td>
</tr>

<tr>
<td>INCR</td>
<td><var>IN FILE filename INCREASE DATASETS</var> command</td>
</tr>

<tr>
<td>INIT</td>
<td><var>IN FILE filename INITIALIZE</var> command</td>
</tr>

<tr>
<td>LOAD </td>
<td>Loading a precompiled (ASPY) procedure</td>
</tr>

<tr>
<td>PREP </td>
<td>Compilation of an SQL request</td>
</tr>

<tr>
<td>REST </td>
<td><var>RESTORE file</var> command</td>
</tr>
</table>

===Since-last highwater marks===

The since-last statistics include highwater marks of various work tables used by SOUL requests. Values are reported in terms of the units in which each table is allocated. For example, QTBL is allocated in units of 16 bytes.

===Since-last in relation to final and partial statistics===

Many since-last statistics, such as CNCT, CPU, and DKRD, are also reported on user final and partial statistics lines. (See the [[#Description of statistics|Statistics with descriptions]] table.) The statistics on these lines are roughly equal to the sum of all of the preceding since-last statistics for the user.
Because since-last statistics are not maintained for every <var class="product">Model 204</var> command, final statistics are generally larger.

For subtype X'01' (since-last statistics), the layout of the remainder of the entry begins as shown in the following table.
For the meaning of each statistic in this table and in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table, see the [[#Description of statistics|Statistics with descriptions]] table.
The layout of the end of the entry depends on whether you chose to collect conflict statistics:
<ul>
<li>If you do not collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table.</li>

<li>If you do collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table. When you collect conflict statistics, the subtype changes to X'81'. </li>
</ul>
<table>
<caption>Layout of user subtype X'01' and X'81' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 44(2C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 48(30)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 52(34)</td>
<td>QTBL </td>
</tr>

<tr>
<td> 56(38)</td>
<td>STBL </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>TTBL </td>
</tr>

<tr>
<td> 64(40)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 68(44)</td>
<td>PDL</td>
</tr>

<tr>
<td> 72(48)</td>
<td>FTBL </td>
</tr>

<tr>
<td> 76(4C)</td>
<td>XTBL </td>
</tr>

<tr>
<td> 80(50)</td>
<td>ITBL </td>
</tr>

<tr>
<td> 84(54)</td>
<td>FSCB </td>
</tr>

<tr>
<td> 88(58)</td>
<td>OUTPB </td>
</tr>

<tr>
<td> 92(5C) </td>
<td>HEAP </td>
</tr>

<tr>
<td> 96(60)</td>
<td>SQLI </td>
</tr>

<tr>
<td>100(64)</td>
<td>SQLO</td>
</tr>

<tr>
<td>104(68)</td>
<td>CNCT</td>
</tr>

<tr>
<td>108(6C)</td>
<td>CPU </td>
</tr>

<tr>
<td>112(70)</td>
<td>DKRD </td>
</tr>

<tr>
<td>116(74)</td>
<td>DKWR</td>
</tr>

<tr>
<td>120(78)</td>
<td>UDD </td>
</tr>

<tr>
<td>124(7C)</td>
<td>OUT </td>
</tr>

<tr>
<td>128(80)</td>
<td>SLIC</td>
</tr>

<tr>
<td>132(84)</td>
<td>IN </td>
</tr>

<tr>
<td>136(88)</td>
<td>RECADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>BADD </td>
</tr>

<tr>
<td>148(94)</td>
<td>BDEL </td>
</tr>

<tr>
<td>152(98)</td>
<td>BCHG </td>
</tr>

<tr>
<td>156(9C)</td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>164(A4)</td>
<td>FINDS </td>
</tr>

<tr>
<td>168(A8)</td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC)</td>
<td>RECDS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>PCPU </td>
</tr>

<tr>
<td>184(B8)</td>
<td>RQTM </td>
</tr>

<tr>
<td>188(BC)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>192(CO)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td>196(C4)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>200(C8)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>204(CC)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>208(DO)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>216(D8)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 220(DC)</td>
<td>BXFREE </td>
</tr>

<tr>
<td> 224(E0)</td>
<td>STCPU </td>
</tr>

<tr>
<td> 228(E4)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 232(E8)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 236(EC)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>240(F0) </td>
<td>SVRD </td>
</tr>

<tr>
<td>244(F4)</td>
<td>SVWR</td>
</tr>

<tr>
<td>248(F8) </td>
<td>DKPR </td>
</tr>

<tr>
<td>252(FC)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>256(100)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>260(104)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>264(108)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>268(10C)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>272(110)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>276(114)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>280(118)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>284(11C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>292(124)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>336(150)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>340(154)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>372(174)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>376(178)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>380(17C)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>384(180)</td>
<td>OBJSWAP</td>
</tr>

<tr>
<td>388()184</td>
<td>SIRIUS02</td>
</tr>

<tr>
<td>392(188)</td>
<td>SIRIUS03</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>400(190) </td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>404(194) </td>
<td>CCATDIFF</td>
</tr>

<tr>
<td>408(198) </td>
<td>CCATDIFH</td>
</tr>
</table>

===Conflict statistics===

Whether you are collecting conflict statistics determines the layout at the end of the entry. Two of the conflict statistics keep track of critical file-resource conflicts, and two keep track of record-locking conflicts. Whether these statistics are collected and journaled depends on settings of the parameters <var>[[CFRLOOK parameter|CFRLOOK]]</var> and <var>[[CFRJRNL parameter|CFRJRNL]]</var>.


These statistics are not displayed with the output of the <code>MONITOR SL</code> command. Instead, you can view them (with all the other since-last statistics) by issuing the <var>MONITOR</var> command with the keyword <var>CONFLICT</var>.

The remainder of the entry depends on the setting of <var>CFRJRNL</var>.

The following table shows the layout when <var>CFRJRNL</var> is set to 0: 
<table>
<caption>Layout of user subtype X'01' entries (CFRJRNL=0)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>422(1A6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>430(1AE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>431(1AF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>

The following table shows the layout when <var>CFRJRNL</var> is set to 1. It reflects the change in offset and that the user subtypes are now X'81' entries. 
<table>
<caption>Layout of user subtype X'81' entries (CFRJRNL=1)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Entry type</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKCFRE stastic</td>
</tr>

<tr>
<td>416(1A0)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKRLK statistic</td>
</tr>

<tr>
<td>420(1A4)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTCFR statistic</td>
</tr>

<tr>
<td>424(1A8)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTRLK statistic</td>
</tr>

<tr>
<td>428(1AC)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>438(1B6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>446(1BE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>447(1BF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>
Note:
The conflict statistics, BLKCFRE, BLKRLK, WTCFR, and WTRLK, are inexact. Although a user might at times conflict with multiple other users, only the first conflict encountered is counted.

==User performance statistics==

Optional performance statistics lines provide information about the operation of the <var class="product">Model 204</var> scheduler during a short period of time. Information about the length of the scheduler queues, the number of active users and servers, and the queue distribution for each user, is obtained by sampling. 

A performance line starts with:
ST $$$ USERID='userid' ACCOUNT='accountname'
PERFORMANCE=n


===Parameters to activate performance statistics===

To request performance statistics, specify the number of samples to take between performance statistics lines (<var>RPTCNT</var> parameter) and the time interval between samples (<var>SMPLTIM</var> parameter) on User 0's parameter line. When you request scheduler and server performance data (<var>SMPLTIM</var> parameter), an asynchronous operating system task, called the performance subtask, is created. Both <var>RPTCNT</var> and <var>SMPLTIM</var> must be nonzero.

===Sampling===

The performance subtask spends most of its time in a wait state. Every <var>SMPLTIM</var> milliseconds, it records the current state of the system. Data from the most recent sample is available at an Online terminal through the <var>MONITOR</var> command, described in [[Controlling system operations (CCAIN)#ONLINE monitoring|ONLINE monitoring]]. 

The number of samples taken during a run (<var>RPTCNT</var>), times the number of users in the run (<var>NUSERS</var>), must be less than 4.2 million. In large systems that run for a very long period of time, the time interval between samples cannot be extremely short. If the limit is exceeded, an OC1 interrupt occurs when the SMPLS statistic value is calculated during the printing of the system statistics, either a performance or final line.

====Layout of performance statistics====

For subtype X'04' (performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. For the description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>Layout of user subtype X'04' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 40(28)</td>
<td>SMPLS </td>
</tr>

<tr>
<td> 44(2C)</td>
<td>RUNG</td>
</tr>

<tr>
<td> 48(30)</td>
<td>REDY </td>
</tr>

<tr>
<td> 52(34)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 56(38)</td>
<td>WTSV </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 64(40)</td>
<td>SWPG </td>
</tr>
</table>

==File statistics entries (Type 10)==

File statistics, summarized in the [[#File statistics journal records layout|File statistics entry formats]] table, are kept for every file opened during a run, including CCAGRP, CCASYS, and CCATEMP. The activity of a file for all users is summarized from the time the file is first opened until the last user issues a <var>CLOSE</var> command. The statistics appear after the last <var>CLOSE</var> command in lines that follow the date and time information (yyyydddhhmmssnnnsssuuuuu) with: 
ST $$$ FILE='filename'


System termination writes file statistics for each file still open at the end of the run.

===Final statistics===

A final statistics line similar to the following is produced when the last user of a file closes the file: 
ST $$$ FILE='PAYABLES'DKRD=25 DKRD=25 DKWR=15 REQ=3 RECADD=6 ...


===Partial statistics===

File partial statistics lines similar to the following are furnished for each open file: 
ST $$$ FILE='PAYABLES'PARTIAL=3 ...


===File statistics journal records layout===

File statistics entries have the format shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>File statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Type of entry</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'0A'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Subtype indicator:
X'00' = file close
X'01' = partial</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td align="right"> 4</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td align="right"> 8</td>
<td> EBCDIC</td>
<td>File name</td>
</tr>

<tr>
<td> 24(18)</td>
<td align="right"> 2</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>
</table>

The following table lists the file statistics and the decimal(hexidecimal) offset. These statistics are data type Binary and eight bytes long.
<table>
<caption>File statistics</caption>
<tr class="head">
<th>File statistic </th>
<th>Offset dec(hex) </th>
</tr>

<tr>
<td>DKRD </td>
<td>26(1A) </td>
</tr>

<tr>
<td>DKWR </td>
<td>34(22) </td>
</tr>

<tr>
<td>REQ </td>
<td>42(2A) </td>
</tr>

<tr>
<td>RETRYA </td>
<td>50(32) </td>
</tr>

<tr>
<td>RETRYC </td>
<td>58(3A) </td>
</tr>

<tr>
<td>DUPDTS </td>
<td>66(42) </td>
</tr>

<tr>
<td>RECADD </td>
<td>74(4A) </td>
</tr>

<tr>
<td>RECDEL </td>
<td>82(52) </td>
</tr>

<tr>
<td>BADD </td>
<td>90(5A) </td>
</tr>

<tr>
<td>BDEL </td>
<td>98(62) </td>
</tr>

<tr>
<td>BCHG </td>
<td>106(6A) </td>
</tr>

<tr>
<td>IXADD </td>
<td>114(72) </td>
</tr>

<tr>
<td>IXDEL </td>
<td>122(7A) </td>
</tr>

<tr>
<td>DIRRCD </td>
<td>130(82) </td>
</tr>

<tr>
<td>BXCHNG </td>
<td>138(8A) </td>
</tr>

<tr>
<td>BXDELE </td>
<td>146(92) </td>
</tr>

<tr>
<td>BXNEXT </td>
<td>154(9A) </td>
</tr>

<tr>
<td>BXFIND </td>
<td>162(A2) </td>
</tr>

<tr>
<td>BXINSE </td>
<td>170(AA) </td>
</tr>

<tr>
<td>BXSPLI </td>
<td>178(B2) </td>
</tr>

<tr>
<td>BXRFND </td>
<td>186(BA) </td>
</tr>

<tr>
<td>BXFREE </td>
<td>194(C2) </td>
</tr>

<tr>
<td>UPDTTIME </td>
<td>202(CA) </td>
</tr>

<tr>
<td>PNDGTIME </td>
<td>210(D2) </td>
</tr>

<tr>
<td>DKUPTIME </td>
<td>218(DA) </td>
</tr>

<tr>
<td>COMMITS </td>
<td>226(E2) </td>
</tr>

<tr>
<td>BACKOUTS </td>
<td>234(EA) </td>
</tr>
</table>

==Text entries (Type 11, Type 13)==

Type 11 (X'0B') and Type 13 (X'0D') entries record most of the actual text of the audit trail.

===Noncontinued text entries, Type 11 (X'0B')===

Each Type 11 journal entry corresponds to one logical entry in the audit trail, even though it might generate more than one line of physical output in the audit trail. 

The format of a Type 11 entry is shown in the following table: 
<table>
<caption>Noncontinued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'0B'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Subtype indicator:

X'01' = LI line

X'02' = LP line

X'03' = LR line

X'04' = CI line

X'05' = QT line

X'08' = CP line

X'10' = OI line

X'20' = OO line

X'40' = LS line

X'80' = CS line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>

===Possibly continued text entries, Type 13 (X'0D')===

Each Type 13 journal entry corresponds to one, or part of one, logical entry in the audit trail. See the [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Example|Types of audit trail lines]] table for a definition of the line types.

The format of a Type 13 entry is shown in the following table: 
<table>
<caption>Possibly continued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0D'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = US line

X'02' = XX line

X'04' = RK line

X'08' = AD line

X'10' = MS line

X'20' = ER line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td> 14(0E)</td>
<td> 2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td> 16(10)</td>
<td> Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>
Note:
Subtype indicator X'80' summed with any subtype means continuation into the next entry. 

==Initialization entries, Type 12 (X'0C')==

One Type 12 journal entry is written as the first nonheader entry in the journal during initialization. It contains basic information about the run being initialized.

The format of a Type 12 entry is shown in the following table:
<table>
<caption>Initialization entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'001A'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0C'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> —</td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 8</td>
<td> EBCDIC</td>
<td>Version ID (for example, 4.2.0G)</td>
</tr>

<tr>
<td> 20(14)</td>
<td> 2</td>
<td> Binary</td>
<td>Spare for the run</td>
</tr>

<tr>
<td> 22(16)</td>
<td> 4</td>
<td> EBCDIC</td>
<td>SMF ID (SYSID parameter) </td>
</tr>
</table>

==Time-stamp entries, Type 14 (X'0E')==

Type 14 entries are used to force time-stamps to the journal. 

The format of a Type 14 entry is shown in the following table: 
<table>
<caption>Time-stamp entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td>2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0E'</td>
</tr>

<tr>
<td>3(3)</td>
<td> 1</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td>4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Merged journal bracketing entries (Type 15)==

Type 15 entries appear only in the output of the MERGEJ utility. See [[System and media recovery#Using the MERGEJ utility|Using the MERGEJ utility]]. 

The format of a Type 15 entry is shown in the following table:
<table>
<caption>Merged journal bracketing entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'002E'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0F'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = begin bracket

X'02' = end bracket
</td>
</tr>

<tr>
<td> 4(4)</td>
<td>12(0C)</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td>2(2)</td>
<td> Binary </td>
<td>Number of journals merged together</td>
</tr>

<tr>
<td> 18(12)</td>
<td>28(1C)</td>
<td>EBCDIC</td>
<td>Text:
<ul>
<li>For subtype X'01' = BEGINNING OF MERGED JOURNAL</li>

<li>For subtype X'02' = END OF MERGED JOURNAL</li>
</ul>
</td></tr>
</table>

==System Management Facilities==

You can write certain statistics to the System Management Facilities (SMF) data set by: 
<ul>
<li>Setting the <var>[[SMFSLRN parameter|SMFSLRN]]</var> and <var>[[SMFLORN parameter|SMFLORN]]</var> parameters on the User 0 command line to activate the SMF feature. (z/OS and z/VM)</li>

<li>Modifying the program that processes the SMF data set to handle the records written by <var class="product">Model 204</var>. (z/VM only)</li>
</ul>

See the [[#z/VM requirements|z/VM requirements]] and the the [[#z/OS requirements|z/OS requirements]] sections for details.

Since-last statistics or logout statistics can be written concurrently with statistics that are written to the journal. Logout statistics are more complete than since-last statistics. Many more since-last records than logout records are usually written. 

If the operating system crashes before a user logs out, the SMF data set has a since-last record for every request run, but no logout record. 

File and system statistics cannot be written to the SMF data set.

During system initialization, <var class="product">Model 204</var> issues a message reporting the SMF system ID, the run's job name, the step name, and the JES ID. For operating systems other than z/OS, the JES ID is blank.

===z/VM requirements===

In the CMS interface to <var class="product">Model 204</var>, you can incorporate a user-written accounting exit that invokes the ACCTEXIT routine to process each statistics record as it is written. The following considerations apply:
<ul>
<li>Take care to preserve the CMS environment in which <var class="product">Model 204</var> is running. Do not change the contents of general registers 13 and 14.</li>

<li>You must specify the <var>SMFLORN</var> and/or <var>SMFSLRN</var> parameters on User 0's parameter line to activate accounting record production.</li>

<li>TEXT file for the ACCTEXIT module must be available on an accessed disk when generating M204CMS using M204GEN. For complete installation procedures, see the <var class="book">Rocket Model 204 z/VM Installation Guide</var>.</li>
</ul>

===z/OS requirements===

To write since-last SMF records in a z/OS environment, activate the SMF feature. 

To activate SMF, set the following parameters on User 0's parameter line: 
<ul>
<li>SMFSLRN — SMF record number for since-last records</li>

<li>SMFLORN — SMF record number for logout records </li>
</ul>

The following considerations apply:
<ul>
<li>Since-last SMF records are written only if the SMFSLRN parameter is set to a non-zero value at the beginning of the run.</li>

<li>Logout SMF records are written only if the SMFLORN parameter is set to a non-zero value at the beginning of the run.</li>

<li>If both parameters are set, each type of record is written.</li>
</ul>

SMF record numbers, which identify the record type to the programs that process the SMF data set, are written as part of the header of the SMF records. The record numbers must be between 128 and 255.

See the "System Management Facility record layout and statistics" section, which follows.

==System Management Facility record layout and statistics==

===SMF logout record layout===

The following table shows the basic format of the <var class="product">Model 204</var> SMF logout record: 
<table>
<caption>Basic format of Model 204 SMF logout record</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length</th>
<th> Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td>2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td>4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td>5(5)</td>
<td> 1</td>
<td>Record number (<var>SMFSLRN</var> or <var>SMFLORN</var>)</td>
</tr>

<tr>
<td>6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td> 1</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: x'4C'
For V7.7: x'4D'
For V7.8: x'4E'
</td>
</tr>

<tr>
<td>58(3A)</td>
<td> 2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable
4-character field retrieved from the SMF control area.

The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.
</li>
</ul>

====Offsets for SMF logout record statistics====

The following table shows the layout of SMF logout record statistics. Each statistic in the table is: Length, 4 (bytes); data type, Binary.
This record has the same statistics in the same order as the CCAJRNL logout record, only the offsets are different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]] table.
<table>
<caption>Offset location of SMF logout record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>60(3C) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 64(40) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 68(44) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 72(48) </td>
<td>SQRD</td>
</tr>

<tr>
<td> 76(4C) </td>
<td>SQWR</td>
</tr>

<tr>
<td> 80(50) </td>
<td>SGMTI</td>
</tr>

<tr>
<td> 84(54) </td>
<td>SGMTO</td>
</tr>

<tr>
<td> 88(58) </td>
<td>SVRD</td>
</tr>

<tr>
<td> 92(5C) </td>
<td>SVWR</td>
</tr>

<tr>
<td> 96(60) </td>
<td>CPU</td>
</tr>

<tr>
<td>100(64) </td>
<td>REQ</td>
</tr>

<tr>
<td>104(68) </td>
<td>MOVE</td>
</tr>

<tr>
<td>108(6C) </td>
<td>DUMP</td>
</tr>

<tr>
<td>112(70) </td>
<td>REST</td>
</tr>

<tr>
<td>116(74) </td>
<td>SLIC</td>
</tr>

<tr>
<td>120(78) </td>
<td>AUDIT</td>
</tr>

<tr>
<td>124(7C) </td>
<td>WAIT</td>
</tr>

<tr>
<td>128(80) </td>
<td>FBWT</td>
</tr>

<tr>
<td>132(84) </td>
<td>UDD</td>
</tr>

<tr>
<td>136(88) </td>
<td>RECADD</td>
</tr>

<tr>
<td>140(8C) </td>
<td>RECDEL</td>
</tr>

<tr>
<td>144(90) </td>
<td>BADD</td>
</tr>

<tr>
<td>148(94) </td>
<td>BDEL</td>
</tr>

<tr>
<td>152(98) </td>
<td>BCHG</td>
</tr>

<tr>
<td>156(9C) </td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td>164(A4) </td>
<td>FINDS</td>
</tr>

<tr>
<td>168(A8) </td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC) </td>
<td>RECDS</td>
</tr>

<tr>
<td>176(B0) </td>
<td>STRECDS</td>
</tr>

<tr>
<td>180(B4) </td>
<td>DKAR</td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKPR</td>
</tr>

<tr>
<td>188(BC) </td>
<td>DKRR</td>
</tr>

<tr>
<td>192(C0) </td>
<td>COMMITS</td>
</tr>

<tr>
<td>196(C4) </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>200(C8) </td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>204(CC) </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>208(D0) </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>212(D4) </td>
<td>SMPLS</td>
</tr>

<tr>
<td>216(D8) </td>
<td>RUNG</td>
</tr>

<tr>
<td>220(DC) </td>
<td>REDY</td>
</tr>

<tr>
<td>224(E0) </td>
<td>BLKI</td>
</tr>

<tr>
<td>228(E4) </td>
<td>WTSV</td>
</tr>

<tr>
<td>232(E8) </td>
<td>BLKO</td>
</tr>

<tr>
<td>236(EC) </td>
<td>SWPG</td>
</tr>

<tr>
<td>240(F0) </td>
<td>PCPU</td>
</tr>

<tr>
<td>244(F4) </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>248(F8) </td>
<td>BXCHNG</td>
</tr>

<tr>
<td>252(FC) </td>
<td>BXDELE</td>
</tr>

<tr>
<td>256(100) </td>
<td>BXNEXT</td>
</tr>

<tr>
<td>260(104)</td>
<td>BXFIND</td>
</tr>

<tr>
<td>264(108)</td>
<td>BXINSE</td>
</tr>

<tr>
<td>268(10C)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td>272(110)</td>
<td>BXFND</td>
</tr>

<tr>
<td>276(114)</td>
<td>BXFREE</td>
</tr>

<tr>
<td>280(118)</td>
<td>STCPU</td>
</tr>

<tr>
<td>284(11C)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>288(120)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>292(124)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>296(128)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>300(12C)</td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>312(138)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>344(158)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>348(15C)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>352(160)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>380(17C)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>384(180)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>388(184)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>392(188)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>400(190)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>404(194)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>408(198)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>412(19C)</td>
<td>Spare </td>
</tr>

<tr>
<td>416(1A0)</td>
<td>Spare</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>Spare</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>Spare</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>Spare</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>Spare</td>
</tr>
</table>

===SMF since-last record layout===

The following table shows the basic format of since-last <var class="product">Model 204</var> SMF records. 
<table>
<caption>Since-last record basic format</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length (bytes)</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td> 5(5)</td>
<td> 1</td>
<td>Record number (SMFSLRN)</td>
</tr>

<tr>
<td> 6(6)</td>
<td> 8</td>
<td>Time and date of this record
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login
4 bytes, time in hundredths of a second from midnight
4 bytes, Julian date, packed decimal
</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td>1</td>
<td>SMFSLTYP - X'01' if CRFJRNL=1 (conflict counters present)

SMFSLTYP - X'00' if CRFJRNL=0 (conflict counters not present)
</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>x'4A'</code> (requires zap 74Z4196)
For V7.5: <code>x'4B'</code> (requires zap 75Z326)
For V7.6: <code>x'4C'</code>
For V7.7: <code>x'4D'</code>
For V7.8: <code>x'4E'</code>
</td>
</tr>

<tr>
<td>58(3A)</td>
<td>2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> 4</td>
<td>Since-last type (EVAL CMPL DUMP REST...)</td>
</tr>

<tr>
<td>64(40)</td>
<td> 8</td>
<td>File name</td>
</tr>

<tr>
<td>72(48)</td>
<td>10</td>
<td>Since-last subsystem name</td>
</tr>

<tr>
<td>82(52)</td>
<td>40</td>
<td>Since-last procedure name</td>
</tr>

<tr>
<td>122(7A)</td>
<td>2</td>
<td>Reserved two bytes</td>
</tr>

<tr>
<td>124(7C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable 4-character field retrieved from the SMF control area.</li>

<li>The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.</li>
</ul>

====Offsets for SMF since-last record statistics====

The following table shows the layout of SMF since-last record statistics. Each statistic in the table is: Length, 4 (bytes); Data type, Binary.
This record has the same statistics in the same order as the CCAJRNL user since-last records; only the offsets are
different. For a description of each statistic, see the [[Using system statistics#Description of statistics|Description of statistics]]
table. 
<table>
<caption>SMF since-last record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td> 124(7C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 128(80)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 132(84)</td>
<td>QTBL</td>
</tr>

<tr>
<td> 136(88) </td>
<td>STBL</td>
</tr>

<tr>
<td> 140(8C)</td>
<td>TTBL</td>
</tr>

<tr>
<td> 144(90)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 148(94)</td>
<td>PDL</td>
</tr>

<tr>
<td> 152(98)</td>
<td>FTBL</td>
</tr>

<tr>
<td> 156(9C)</td>
<td>XTBL</td>
</tr>

<tr>
<td> 160(A0)</td>
<td>ITBL</td>
</tr>

<tr>
<td> 164(A4)</td>
<td>FSCB</td>
</tr>

<tr>
<td> 168(A8)</td>
<td>OUTPB</td>
</tr>

<tr>
<td> 172(AC) </td>
<td>HEAP</td>
</tr>

<tr>
<td> 176(B0) </td>
<td>SQLI</td>
</tr>

<tr>
<td> 180(B4) </td>
<td>SQLO</td>
</tr>

<tr>
<td> 184(B8) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 188(BC) </td>
<td>CPU</td>
</tr>

<tr>
<td> 192(C0) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 196(C4) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 200(C8) </td>
<td>UDD</td>
</tr>

<tr>
<td> 204(CC) </td>
<td>OUT</td>
</tr>

<tr>
<td> 208(D0) </td>
<td>SLIC</td>
</tr>

<tr>
<td> 212(D4) </td>
<td>IN</td>
</tr>

<tr>
<td> 216(D8) </td>
<td>RECADD</td>
</tr>

<tr>
<td> 220(DC) </td>
<td>RECDEL</td>
</tr>

<tr>
<td> 224(E0) </td>
<td>BADD</td>
</tr>

<tr>
<td> 228(E4) </td>
<td>BDEL</td>
</tr>

<tr>
<td> 232(E8) </td>
<td>BCHG</td>
</tr>

<tr>
<td> 236(EC) </td>
<td>IXADD</td>
</tr>

<tr>
<td> 240(F0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td> 244(F4) </td>
<td>FINDS</td>
</tr>

<tr>
<td> 248(F8) </td>
<td>SORT</td>
</tr>

<tr>
<td> 252(FC) </td>
<td>RECDS</td>
</tr>

<tr>
<td> 256(100)</td>
<td>STRECDS</td>
</tr>

<tr>
<td> 260(104)</td>
<td>PCPU</td>
</tr>

<tr>
<td> 264(108)</td>
<td>RQTM</td>
</tr>

<tr>
<td> 268(10C)</td>
<td>DIRRCD</td>
</tr>

<tr>
<td> 272(110)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td> 276(114)</td>
<td>BXDELE</td>
</tr>

<tr>
<td> 280(118)</td>
<td>BXNEXT</td>
</tr>

<tr>
<td> 284(11C)</td>
<td>BXFIND</td>
</tr>

<tr>
<td> 288(120)</td>
<td>BXINSE</td>
</tr>

<tr>
<td> 292(124)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td> 296(128)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 300(12C)</td>
<td>BXFREE</td>
</tr>

<tr>
<td> 304(130)</td>
<td>STCPU</td>
</tr>

<tr>
<td> 308(134)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 312(138)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 316(13C)</td>
<td>SCREENS</td>
</tr>

<tr>
<td> 320(140)</td>
<td>SVRD</td>
</tr>

<tr>
<td> 324(144)</td>
<td>SVWR</td>
</tr>

<tr>
<td> 328(148)</td>
<td>DKPR</td>
</tr>

<tr>
<td> 332(14C)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>336(150)</td>
<td>COMMITS</td>
</tr>

<tr>
<td>340(154)</td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>344(158)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>348(15C)</td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>352(160)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>368(170)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>372(174)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>376(178)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>380(17C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>384(180)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>388(184)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>392(188)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>396(18C)</td>
<td>MAPICNT</td>
</tr>

<tr>
<td>400(190)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>404(194)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>408(198)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>412(19C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>444(1BC)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>448(1C0)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>452(1C4)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>456(1C8)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>460(1CC)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>464(1D0)</td>
<td>Sirius</td>
</tr>

<tr>
<td>468(1D4)</td>
<td>Sirius</td>
</tr>

<tr>
<td>472(1D8)</td>
<td>Sirius</td>
</tr>

<tr>
<td>476(1DC)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>480(1E0)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>484(1E4)</td>
<td>Spare</td>
</tr>

<tr>
<td>488(1E8)</td>
<td>Spare</td>
</tr>
</table>

The following table lists the conflict statistics, if <code>CFRJRNL=1</code>:

<table>
<caption>Conflict statistics, if CFRJRNL=1</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td>492(1EC)</td>
<td>BLKCFRE</td>
</tr>

<tr>
<td>496(1F0)</td>
<td>BLKRLK</td>
</tr>

<tr>
<td>500(1F4)</td>
<td>WTCFR</td>
</tr>

<tr>
<td>504(1F8)</td>
<td>WTRLK</td>
</tr>
</table>

[[Category:System management]]
[[Category:System-level capabilities of Model 204]]

System and media recovery

2024-08-20T08:07:24Z

Goff: /* Data sets required for the MERGEJ utility */

==Overview==

Hardware, software, or media failures compromise database integrity. The recovery facilities of <var class="product">Model 204</var> detect and correct integrity problems that can affect some or all <var class="product">Model 204</var> files in Online or Batch updating jobs.

This page discusses individual transaction and database recovery facilities provided by <var class="product">Model 204</var> in the event of application, system, or media failure. However, the importance of a reliable, well-maintained backup plan cannot be overemphasized; see the [[#Preparing for media recovery|Preparing for media recovery]] section.

This page describes the SOUL statements, <var class="product">Model 204</var> commands and parameters that are coordinated and used by the recovery facilities. The recovery facilities include:
For system recovery:
<ul>
<li>Transaction Back Out</li>

<li>RESTART recovery, which utilizes:
<ul>
<li><var>ROLL BACK</var> processing</li>

<li><var>ROLL FORWARD</var> processing</li>
</ul></li>
</ul>

For media recovery:
<ul>
<li>NonStop/204 for file backups</li>

<li>Processing for <var>REGENERATE</var> and <var>REGENERATE ONEPASS</var> commands, applying updates that have occurred since the file's last backup:
<ul>
<li><var>ROLL FORWARD</var> processing</li>

<li>UTILJ utility</li>

<li>MERGEJ utility</li>
</ul></li>
</ul>

Other topics related to <var class="product">Model 204</var> recovery are discussed in the following places:
<table>
<tr class="head">
<th>Topic</th>
<th>Discussed in...</th>
</tr>

<tr>
<td>Keeping an audit trail by recording and printing system activity</td>
<td>[[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)]] </td>
</tr>

<tr>
<td>Recovering application subsystem definitions (CCASYS)</td>
<td>[[System requirements for Application Subsystems]] </td>
</tr>

<tr>
<td>Storing preimages of changed pages and checkpoints</td>
<td>[[Performance monitoring and tuning]] </td>
</tr>

<tr>
<td>Handling CCATEMP, the system scratch file, after a system crash</td>
<td>[[Using the system scratch file (CCATEMP)]]</td>
</tr>

<tr>
<td>Using the system statistics</td>
<td>[[Using system statistics]]</td>
</tr>
</table>

===Consulting other Model 204 documentation===

You can also consult:
<ul>
<li>The <var>[[CHECKPOINT command|CHECKPOINT]]</var> command can request either a transaction checkpoint or a sub-transaction checkpoint. The options are <var>TRAN</var>, the default, for a transaction checkpoint and <var>SUBTRAN</var> for a sub-transaction checkpoint.</li>

<li>The <var>[[MONITOR command|MONITOR]]</var> command has a <var>SUBTRAN</var> option to display the status of sub-transaction checkpoints. </li>

<li>[[File integrity and recovery#Error recovery features|Error diagnosis]]</li>

<li>[[Transaction back out|Methods for maintaining transaction efficiency]]</li>

<li>Discussion of [[File integrity and recovery#Update units and transactions|update units]]</li>

<li>[[Host Language Interface (HLI)]] and <var class="book">[[Media:M204 HLIReference V75.pdf|Rocket Model 204 Host Language Interface Reference Manual]]</var> for:
<ul>
<li>Details regarding Host Language Interface calls, IFAM1, IFAM2, and IFAM4 applications</li>

<li>Transaction behavior</li>
</ul></li>

<li>[[Record retrievals]] and [[Record loops|transaction efficiency]]</li>
</ul>

==Preparing for media recovery==

To use media recovery effectively, an installation must establish procedures for backing up files on a regular basis and for archiving and maintaining CCAJRNL files that contain a complete history of file activity. 

Media recovery requires the following preparation:
<ul>
<li>Install the MERGEJ utility.

Installation and link-editing of MERGEJ is discussed in the installation guide for your operating system.
</li>

<li>Dump <var class="product">Model 204</var> files on a regular basis.

Use the <var class="product">Model 204</var> DUMP command or any other DASD management utility.
Note: If your <var class="product">Model 204</var> backups are not done using a <var class="product">Model 204</var> DUMP command, you must make certain that no one is updating the <var class="product">Model 204</var> file at the same time the backup is being performed. If you use a backup from a <var class="product">Model 204</var> dump file, updates made to the file since the dump are reapplied by the ROLL FORWARD facility of the <var>REGENERATE</var> command using single, concatenated, or merged journals as input.
</li>

<li>Produce and archive journals. You must maintain a complete record of update activity in the form of archived CCAJRNLs, in all types of <var class="product">Model 204</var> runs (Online, Batch, and RESTART recovery).
Note: In a z/VSE environment, the use of concatenated journals for regeneration is not supported. 
</li>

<li>Run the UTILJ utility against any journal that does not have an end-of-file marker before using the MERGEJ utility. See [[#Using the UTILJ utility|Using the UTILJ utility]]. </li>

<li>Merge any overlapping journals needed for a media recovery run by running the [[#Using the MERGEJ utility|MERGEJ utility]].</li>

<li>If you are running media recovery, you must ensure that all files that were in deferred update mode during part or all of the time period you specify in the <var>REGENERATE</var> command are still in deferred update mode during the media recovery run. This might require larger deferred update data sets than those in the original run. </li>
</ul>

==Recovery features==

<var class="product">Model 204</var> protects the physical and logical consistency of files at all stages of processing using the following features.

===Handling error diagnosis===

Error diagnostic features, described in [[File integrity and recovery#Error recovery features|Error recovery features]], ensure data integrity by command syntax checking, compiler diagnostics, error recovery routines for data transmission from user terminals, and maintaining and checking trailers on each table page.

===Handling Transaction Back Out===

Logical consistency of individual updates to a <var class="product">Model 204</var> file is protected by the Transaction Back Out facility, which is activated by the <var>FRCVOPT</var> and <var>FOPT</var> parameters. Transaction back out locks records until an update is completed. If the update is not completed, the effect of the incomplete transaction on file data is automatically reversed.

===Handling a system recovery===

<var class="product">Model 204</var> system recovery procedures involve the following functions:
<table>
<tr class="head">
<th>Facility</th>
<th>Description</th>
</tr>

<tr>
<td>Checkpoint facility</td>
<td>Logs preimages of pages, which are copies of pages before changes are applied, to the CHKPOINT data set.</td>
</tr>

<tr>
<td>Journal facility</td>
<td>Contains incremental changes that reflect updates to database files; see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)]].</td>
</tr>

<tr>
<td>RESTART recovery</td>
<td>In the event of a system failure, the restart facility is invoked by the <var>RESTART</var> command. This invokes the ROLL BACK facility and, optionally, the ROLL FORWARD facility. </td>
</tr>

<tr>
<td>ROLL BACK facility</td>
<td>Rolls back all <var class="product">Model 204</var> files to a particular checkpoint — that is, undoes all of the changes applied to the files since the last checkpoint.</td>
</tr>

<tr>
<td nowrap>ROLL FORWARD facility</td>
<td>Rolls each file forward as far as possible — that is, reapplies all complete updates and committed transactions that were undone by the ROLL BACK facility. </td>
</tr>
</table>

System recovery is initiated by the <var>[[RESTART command|RESTART]]</var> command, which invokes either the ROLL BACK facility, the ROLL FORWARD facility, or both. 

In the event of a system failure, you can restore all files. Any <var class="product">Model 204</var> file that was being updated at the time of a system failure is flagged. Subsequently, whenever the file is opened, the following message is issued:
M204.1221: filename IS PHYSICALLY INCONSISTENT


Once recovery procedures are executed, any discrepancies in the files are corrected and the message is no longer issued. 

===Handling a media recovery===

In the event of media or operational failure, you can restore individual files from previously backed-up versions. Restoration of the files and reapplication of the updates are invoked by the <var>[[REGENERATE command|REGENERATE]]</var> and <var>[[REGENERATE ONEPASS command|REGENERATE ONEPASS]]</var> commands. 

When recovery procedures are completed, status reports are produced for each file participating in the recovery.

==Understanding transaction back out==

Transaction back out, also called TBO, protects the logical and physical consistency of individual transactions. Individual updates performed by SOUL statements or corresponding Host Language calls can be reversed automatically or explicitly, when: 
<ul>
<li>A request is canceled</li>

<li>A file problem or runtime error is detected</li>

<li>A user is restarted</li>

<li>Requested by a SOUL or Host Language Interface program via the <var>[[Data recovery#Manual backout|Backout]]</var> statement or <var>IFBOUT</var> call respectively</li>
</ul>

Transaction back out is enabled on a file-by-file basis by specifications made on the <var>FRCVOPT</var> and <var>FOPT</var> file parameters.

===Making updates permanent===

A commit is the process of ending a transaction and making the transaction updates permanent. A commit is performed by issuing: 
<ul>
<li><var>Commit</var> statement </li>

<li><var>Commit Release</var> statement </li>

<li>Host Language Interface <var>IFCMMT</var> call </li>
</ul>

Any event that ends a transaction such as end-of-request processing is an implicit commit. 

===Transaction boundaries===

For SOUL updates, a transaction begins with the first evaluation of an updating statement in a given request. One request can execute multiple transactions. 

SOUL transactions are ended by any one of the following events: 
<ul>
<li>A <var>Backout</var> statement, the transaction is ended after the back out is complete</li>

<li>A <var>Commit</var> statement</li>

<li>A <var>Commit Release</var> statement</li>

<li>End of a subsystem procedure, unless overridden in the subsystem definition</li>

<li>A <var>CLOSE FILE</var> command or any file updating command, such as <var>RESET</var> or <var>REDEFINE</var>, following an <var>END MORE</var> command</li>

<li>Return to terminal command level using the <var>END</var> command or, for nested procedures, the end of the outermost procedure </li>
</ul>

In an application subsystem environment, also called Subsystem Management facility, you can make transactions span request boundaries by using the <code>AUTO COMMIT=N</code> option in the subsystem definition. 

Once a transaction ends, another transaction begins with the next evaluation of an updating statement.

===Updates that can be backed out===

For files that have transaction back out enabled, you can back out all [[SOUL]] or Host Language Interface updates that are not yet committed. You can initiate back out only on active or incomplete transactions. 

===Updates that cannot be backed out===

The updates that you cannot back out include:
<ul>
<li>The following commands:
ASSIGN
BROADCAST FILE
CREATE
DEASSIGN
DEFINE
DELETE
DESECURE
INITIALIZE
REDEFINE
RENAME
RESET
SECURE
</li>

<li>The following Host Language Interface calls:
IFDFLD
IFDELF
IFINIT
IFNFLD
IFRFLD
IFRPRM
IFSPRM
</li>

<li>Procedure definitions (<var>PROCEDURE</var> command) </li>

<li>Procedure edits</li>

<li>Any file update that has been committed </li>

<li>Any update to a file that does not have transaction back out enabled</li>
</ul>

See [[HLI: Transactions]] for a discussion of Host Language Interface transaction behavior. 

===Back out mechanism===

Transaction back out logically reverses transactions by applying compensating updates to files participating in the transaction. For example, the logical reversal or back out of a <var>Store Record</var> statement is equivalent to processing a <var>Delete Record</var> statement. 

Compensating updates for incomplete transactions are stored temporarily in a back out log in CCATEMP and then deleted when the transaction is committed or backed out.

===Lock-pending-updates locking mechanism===

Transaction back out utilizes an additional locking mechanism, called lock-pending-updates, to assure data integrity and transaction independence. A record in the process of being updated in one transaction is inaccessible by other transactions until the updating transaction commits or is backed out. 

The lock-pending-updates (LPU) lock is separate from other record locks and can be enabled without transaction back out. The LPU lock is:
<ul>
<li>Always exclusive</li>

<li>Placed on each record as soon as it is updated by a transaction</li>

<li>Held until the transaction commits</li>

<li>Released by:</li>

<li>SOUL <var>Backout</var>, <var>Commit</var>, and <var>Commit Release</var> statements</li>

<li>Host Language Interface <var>IFBOUT</var>, <var>IFCMMT</var>, and <var>IFCMTR</var> calls</li>

<li>All implied commits or automatic back outs of the transaction</li>
</ul>
Note:
The SOUL <var>Release Records</var> statement does not release the LPU lock. 

===Back out and constraint logs===

A back out log of compensating updates and a constraints log, which assures availability of resources freed by active transactions, are built in CCATEMP and freed when the update ends or is backed out. Sufficient storage space must be allocated for CCATEMP to accommodate the back out and constraints logs. Inadequate space can terminate the run.

===Understanding the back out log===

All pages not used by any other operation in CCATEMP can be used for back out logging. A minimum of one page is required.

The number of pages needed in CCATEMP depends on the number of concurrent transactions and the size of each transaction. More information about calculating CCATEMP space is given in [[Using the system scratch file (CCATEMP)#Sizing CCATEMP|Sizing CCATEMP]].

Rocket Software recommends that you keep transactions short with frequent COMMIT statements. Short transactions minimize the CCATEMP space used, allow more frequent checkpoints, reduce record contention from lock-pending-updates locking, and reduce overhead for all updating users by keeping the back out and constraints logs small.

===Understanding the constraints log===

The constraints log is a dynamic hashed database that resides in a few virtual storage pages with any extra space needed residing in CCATEMP. In this database there are primary pages and overflow pages, also called extension records. When a primary page fills up, additional records go on to overflow pages that are chained from the primary page. When a primary page become too full, a process is evoked which splits the page into two pages. This process continues to the maximum-allowed number of primary pages at which point the splitting process stops and the overflow page chain is allowed to grow as large as required. 

As the constraints database contracts, this process is reversed. Those pages with only a few records are merged together or compacted. This process continues until only one page remains.

The resources freed by User Language statements, such as Table B space, record numbers, and Table C hash cells, cannot be reused by other active transactions until the transaction that freed the space ends. Before constrained resources can be used, any new transactions needing those resources must search the constraints log.

The constraints log uses specially formatted pages with approximately 300 records per page. CCATEMP space considerations for constraint logging are the same as for logged back out images, which is described in [[#Understanding the back out log|Understanding the back out log]].

All CCATEMP pages not used by any other operation are available for constraints logging. A minimum of one page is required. 

===Optimizing the constraints log performance===

The parameters <var>[[CDMINP2X parameter|CDMINP2X]]</var> and <var>[[CDMAXP2X parameter|CDMAXP2X]]</var> optimize the constraints log performance. The constraints log is used in transaction back out. The constraints log uses several pages that are permanently allocated in storage; when those pages become full, additional CCATEMP pages are allocated. 

The number of permanently allocated pages is controlled by the <var>CDMINP2X</var> parameter. Allocating more pages in storage saves time, because disk read-writes are not necessary and CPU time spent accessing pages is lower.
Note: However, the permanent allocation of too many pages (thousands) may waste the virtual storage, because unused pages may not be reused while unused CCATEMP pages may be reused for other purposes.

<var class="product">Model 204</var> uses the constraints log efficiently by merging or splitting pages to keep amount of data per page within certain limits. This saves space used by the constraints log, but requires additional CPU time. The <var>CDMAXP2X</var> parameter specifies the maximum number of pages to keep in compacted form. 

Note: When the number of pages used in the constraints log exceeds <var>CDMAXP2X</var> setting, additional pages are not compacted. Compaction saves space and in some cases CPU time for finding records in the constraints log, but requires additional CPU time for the compaction itself. Using too many compacted pages (thousands) may negatively affect performance.

===Disabling transaction back out===

By default, transaction back out is enabled for all <var class="product">Model 204</var> database files.

You can disable transaction back out and lock-pending-updates using the following file parameter settings. 
<table>
<tr class="head">
<th>To disable... </th>
<th>Set...</th>
</tr>

<tr>
<td>Back out mechanism </td>
<td><var>FRCVOPT</var> X'08' bit on</td>
</tr>

<tr>
<td>Lock-pending-updates </td>
<td><var>FOPT</var> X'02' bit on</td>
</tr>
</table>

You can specify these settings when the file is created or with the <var>RESET</var> command.

Because lock-pending-updates are required for transaction back out, setting the <var>FOPT</var> X'02' bit on automatically turns on the <var>FRCVOPT</var> X'08' bit.

===Disadvantages to disabling transaction back out===

The following considerations apply to transaction back out:
<ul>
<li>If transaction back out is disabled, you cannot back out updates.</li>

<li>Transaction back out provides a mechanism for recovery from file-full conditions.</li>

<li>You cannot define fields with the <var>[[File design#UNIQUE and NON-UNIQUE attributes|UNIQUE and NON-UNIQUE attributes]]</var> or <var>AT MOST ONE</var> attribute in files that do not have transaction back out enabled. </li>
</ul>

==ROLL BACK facility==

The ROLL BACK facility is activated by the <var>ROLL BACK</var> argument of the <var>RESTART</var> command. ROLL BACK processing removes changes applied to files by restoring copies of file pages as they existed before updates, called preimages, from the CHKPOINT data stream. All preimages logged after the last or specified checkpoint are restored. 

The ROLL BACK facility, in conjunction with the [[#ROLL FORWARD facility|ROLL FORWARD facility]] is used for recovery of the entire database when: 
<ul>
<li>Abnormal termination occurs in Online, Batch 204, IFAM1 or IFAM4
Note:
For IFAM1 only the ROLL BACK facility is available; the ROLL FORWARD facility is not supported for IFAM1</li>

<li>Operating system or partition abends</li>
</ul>

===ROLL BACK processing===

The CHKPOINT stream created in the failed run is processed as input and called the RESTART stream during ROLL BACK processing, which consists of two passes through the RESTART stream.

For maximum efficiency, CCATEMP should have at least 33 pages.

====ROLL BACK processing, Pass 1====

In Pass 1, ROLL BACK processing scans the RESTART stream from the beginning, looking for the last checkpoint taken in the failed Online or for the checkpoint, if specified, in the <var>RESTART</var> command.

For each file in deferred update mode, the deferred update stream is opened and repositioned at the appropriate checkpoint record.
<ol>
<li>The system builds a directory of files opened in deferred update mode or changed after the specified checkpoint. IDs of gaps in recovery information of a particular file (discontinuities) that occurred after the last checkpoint are also noted in the file directory.

A discontinuity is an event that overrides all other file update events and cannot be rolled across. For example, if you add two new records to a file, close the file, and then issue a <var>CREATE</var> command on that file, it does not matter that new records were added. They were destroyed when the file was created. If you run recovery across this discontinuity, recovery notices the discontinuity and does not apply the two new records to the file. Recovery ignores them as useless.

The following processes cause discontinuities: <var>CREATE FILE</var>, <var>CREATEG</var>, <var>INITIALIZE</var>, a file updated by a second job, <var>RESET FISTAT</var>, <var>RESTORE</var>, <var>RESTOREG</var>, <var>RESET FRCVOPT</var>, <var>REGENERATE</var>, <var>ROLL BACK</var>, <var>ROLL FORWARD</var>, and system initialization.
</li>

<li>When the end of the checkpoint stream is reached, the files named in the file directory are opened. The <var>[[NFILES parameter|NFILES]]</var> and <var>[[NDIR parameter|NDIR]]</var> parameter settings must be large enough to accommodate these opens. </li>

<li>After the files and deferred update streams are opened, a list of files that you cannot recover and a list of files that you can roll back are displayed on the operator's console.</li>

<li>Files that cannot be recovered will be listed following the message:
M204.0145: THE FOLLOWING FILES CANNOT BE RECOVERED


This table lists the possible reasons:

<table>
<tr class="head">
<th>Reason for failure</th>
<th>Meaning</th>
</tr>

<tr>
<td>DEFERRED UPDATE CHKP MISSING</td>
<td>The scan of the deferred update data set did not locate the checkpoint used for ROLL BACK processing.</td>
</tr>

<tr>
<td>DEFERRED UPDATE READ ERROR</td>
<td>The scan of the deferred update data set cannot be completed because of a read error. </td>
</tr>

<tr>
<td>DEFERRED UPDATES MISSING</td>
<td>Deferred update data set cannot be opened.</td>
</tr>

<tr>
<td>MISSING</td>
<td>File cannot be opened.</td>
</tr>

<tr>
<td nowrap>ROLL BACK INFORMATION IS OBSOLETE</td>
<td>File was modified by a <var class="product">Model 204</var> job after the last update in the run being recovered.</td>
</tr>

<tr>
<td>IS ON A READ-ONLY DEVICE</td>
<td>(CMS environment only) File is on a device for which <var class="product">Model 204</var> has read-only access. </td>
</tr>
</table></li>

<li>If a list of files that cannot be recovered is displayed, the <var>ERROR</var> clause of the <var>ROLL BACK</var> portion of the <var>RESTART</var> command is examined:
<table>
<tr class="head">
<th>Error clause </th>
<th>Means</th>
</tr>

<tr>
<td><var>ERROR CONTINUE</var> </td>
<td>The listed files are ignored and recovery proceeds for other files.</td>
</tr>

<tr>
<td><var>ERROR STOP</var> </td>
<td>The recovery run terminates. Errors can be corrected and recovery run again.</td>
</tr>

<tr>
<td><var>ERROR OPERATOR</var> or
 no error clause</td>
<td>The message <code>SHOULD RESTART CONTINUE?</code> is displayed on the operator console.
<ul>
<li>Yes (<code>Y</code>) response has the same effect as an <var>ERROR CONTINUE</var> clause. </li>

<li>No (<code>N</code>) response has the same effect as an <var>ERROR STOP</var> clause. </li>
</ul></td></tr>
</table></li>

<li>After the list of files that you can roll back is displayed, you can open any unlisted files for retrieval.</li>
</ol>

====ROLL BACK processing, Pass 2====

In Pass 2:
<ul>
<li>In Model 204 version 7.6 and earlier, ROLL BACK processing reapplies page images to the files by reading the CHKPOINT stream backward.</li>
<li>In Model 204 version 7.7 and later, roll back pass 1 reads the recovery data set forward, and roll back pass 2 begins at the checkpoint and reads the recovery dataset forward (not backward), applying the preimages. This allows the CHKPOINT (and CHKPNTS) to support LARGE datasets (up to 16 million tracks). Duplicate records are not written, so the checkpoint remains smaller and less likely to fill.</li>
</ul>

ROLL BACK processing stops at the specified checkpoint and notifies the operator. Files with discontinuities are not rolled back beyond the discontinuity. If ROLL FORWARD processing is not used, the files are closed and made available for general use.

==ROLL FORWARD facility==

If ROLL BACK processing was successful, the ROLL FORWARD facility is activated by the ROLL FORWARD argument of the RESTART command. ROLL FORWARD processing reapplies the file updates from the recovery data set CCARF to files rolled back by ROLL BACK processing. CCARF is the journal file, CCAJRNL, from the run being recovered. 

If ROLL BACK processing is successful, the CCARF journal stream (CCAJRNL from the run being recovered) is opened. 

The ROLL FORWARD facility is available for Online, Batch 204, and IFAM4 jobs.

===RESTART ROLL FORWARD recovery is version specific===

ROLL FORWARD recovery is not compatible with <var class="product">Model 204</var> journals from previous releases. If you attempt ROLL FORWARD processing using a journal created under a previous release, processing is terminated with the following error:
M204.2501: RELEASE INCOMPATABILITY


ROLL BACK processing remains compatible with previous releases. Rocket Software recommends that you backup all files prior to installing the current release. Also, since the format of all update journal records is now eight bytes larger than in previous releases, the journal may need additional space.

The amount of data lost due to a system crash is minimized by the journal buffer being forced out upon the completion of every update unit (COMMIT). An update unit is a sequence of operations allowed to update the database.

After the operator is notified that ROLL FORWARD processing is complete, terminal users can open the recovered files for updating.

===Logging ROLL FORWARD processing===

To enable ROLL FORWARD logging in the Online, the following requirements must be met:
<ul>
<li>CCAJRNL output stream must be present</li>

<li>SYSOPT setting must include the 128 option</li>

<li>ROLL FORWARD logging option must be set on the RCVOPT parameter (X'08') </li>

<li>CHKP and JRIO object modules must be present in the link-edit of the <var class="product">Model 204</var> program to be run</li>

<li>To control ROLL FORWARD logging on a file basis, use the <var>[[FRCVOPT parameter|FRCVOPT]]</var> file parameter </li>
</ul>

===Message for the Operator===

While ROLL FORWARD is processing, the following message is issued:
M204.1992: RECOVERY: PROCESSING ROLL FORWARD BLOCK# blocknumber date-timestamp


The message gives the processing sequence number and date-time stamp. It is issued at the Operator's console for each occurrence of a minute change in the date-time stamp of the CCARF update records.

You could receive a maximum of 24 such messages in a 24-hour period.

===ROLL FORWARD processing===

ROLL FORWARD processing consists of one pass of CCARF and performs the following steps:
<ol>
<li>Reads the journal stream, CCARF, starting from the ROLL BACK checkpoint. For each file you are recovering, ROLL BACK processing determines the start points for rolling the file forward.

The start point is normally the last checkpoint. However, if a discontinuity is detected for the file between the last checkpoint and the end of CCARF, the start point is just after the last discontinuity record.
</li>

<li>Maintains transaction and constraints logs for each transaction as it is reapplied.</li>

<li>Builds a Transaction Control Block for each concurrent transaction in the original run to keep track of each transaction back out and constraints log. This allows ROLL FORWARD processing to back out transactions that were backed out in the original run.</li>

<li>Issues messages indicating what actions are taken for all recovered files, as the CCARF data set is processed.</li>

<li>Reapplies file updates from the starting point in each file. </li>

<li>Closes recovered files.</li>

<li>Closes CCARF.</li>

<li>Takes a new checkpoint and allows new updates to begin.</li>

<li>Issues the following message:

*** RECOVERY IS NOW COMPLETE ***
</li>
</ol>

===ROLL FORWARD file types===

For system recovery purposes, <var class="product">Model 204</var> files can be categorized according to the processing algorithm applied to determine the stopping point of the ROLL FORWARD processing. Each file type is handled differently during the roll forward phase of recovery.The ROLL FORWARD algorithm is determined by the specified file recovery option, <var>FRCVOPT</var>: 

<dl>
<dt>Roll-forward-all-the-way files (FRCVOPT=X'09')
<dd>
Recovery of roll-forward-all-the-way files ignores update unit boundaries. For these files, ROLL FORWARD processing applies all individual updates that have been logged to CCAJRNL. This minimizes the loss of work during ROLL FORWARD processing by sacrificing logical consistency.</dd>

<dt>Transaction back out files (FRCVOPT X'08' bit off)
<dd>
For transaction back out files, ROLL FORWARD processing initially reapplies all individual updates that have been logged to the journal, just as it does for roll-forward-all-the-way files. When the end of the journal is reached, any incomplete transactions are backed out.

Because the lock pending updates mechanism acquires an exclusive enqueue on records updated by a transaction until the transaction either commits or is backed out, concurrent transactions running against the same files are logically independent of one another. </dd>
</dl>

===Journal data set in ROLL FORWARD logging===

The journal data set is used as the log for ROLL FORWARD processing. If ROLL FORWARD logging is active for a file (based on the values of the <var>RCVOPT</var> system parameter and the <var>FRCVOPT</var> file parameter), each change made to the file is logged at the time it is made. In addition to the change entries, important events such as checkpoints and discontinuities are also logged on the journal.
Along with update unit boundaries, detailed in [[File integrity and_recovery#Update units and transactions|Update units and transactions]],
these special markers are used to determine where the process of rolling forward should begin and end for each file. 

The journal buffer is written out to disk or tape by the completion of every update unit that corresponds to a User Language request or host language program. This minimizes the amount of ROLL FORWARD data that can be lost during a system crash, and ensures that the commit of a transaction is always reflected on disk, in the CCAJRNL data set, at the time of the commit. 

===File discontinuities===

The ability to share files between two distinct copies of <var class="product">Model 204</var> can create an operational problem. If correct operating procedures are not followed, the use of checkpoint and roll forward facilities might result in a loss of file integrity under certain circumstances. 

For example, suppose that one file is updated by two or more jobs. In "Checkpoint data set discontinuity," below:
<ul>
<li>204A is an Online job that has file A opened for update at points t0, t2, and t4 on the chart.</li>

<li>204B is a batch job submitted to update file A. </li>
</ul>

Checkpoint data set discontinuity

[[File:16chkptDisc.png|602px]] 

Suppose that a system crash occurs at t5 and the most recent checkpoint occurred at t1. File A can be rolled back to t4; at this point, physical consistency is guaranteed, because the file was just opened. File A cannot be rolled back any further than t4, because older preimages might partially, but not completely, undo updates from 204B. There is a gap, or discontinuity, in 204A's checkpoint data set that prevents rolling back file A beyond t4.

====Resolving discontinuities====

To resolve the problem presented by this discontinuity, <var class="product">Model 204</var> writes a discontinuity record on the checkpoint data set when OPEN processing recognizes that another job has updated the file. <var class="product">Model 204</var> does not roll back changes to a file across a discontinuity record.

In "Checkpoint data set discontinuity" above, if a crash occurs at t5, <var class="product">Model 204</var> restarts by processing job 204A's checkpoint data set from beginning to end and then reverses to restore preimages. On this reverse pass, file A is restored to its state at t4; the discontinuity record stops file A from being rolled back to the checkpoint at t1. All other files are rolled back to the checkpoint at t1. 

====Resolving logical inconsistencies====

When files are rolled back to different points, the possibility exists for logical inconsistencies to appear in the database. <var class="product">Model 204</var> provides an option that prevents a second job (204B in the example) from updating a file that already has been updated by another job that is still running (204A). Through enqueuing, 204A retains shared control of file A even when file A is closed. 204B can open file A for retrievals but not updates. Use the <var>FRCVOPT</var> parameter to indicate whether the file is held or released when it is closed. 

====How discontinuities occur====

Besides the two-job update case just described, a discontinuity is produced by any operation that does not write a complete set of preimages for the pages it updates. Several commands, including <var>CREATE</var>, <var>INITIALIZE</var>, <var>REGENERATE</var>, and <var>RESTORE</var>, cause discontinuities. Some of these commands rewrite the entire file, making preimages impractical, or, in the case of <var>CREATE</var>, impossible. The <var>REGENERATE</var> command logs a discontinuity record, because roll forward logging is automatically turned off during media recovery. 

===Understanding update units===

An update unit is any sequence of operations that is allowed to update one or more files.
See [[File integrity and recovery#Update units and transactions|Update units and transactions]]
for a complete description of update units. Update units include update operations that can be backed out (back out update units or transactions) and update operations that cannot be backed out. Each update unit is assigned a unique ID by the system. This update ID is written to the audit trail when the update unit starts and ends. See [[#Reporting facilities|Reporting facilities]] for the text of the messages issued to the audit trail at these times. 

====Update unit boundaries====

The boundaries of a complete update unit depend on a number factors: whether or not the update unit can be backed out, the updating commands or statements involved, the kinds of operations and/or situations involved in the update, and special events like hard restarts or request cancellations. A detailed listing of the beginnings and ends of update units is found in [[Using HLI and batch configurations]]. 

===Determining the starting point for ROLL FORWARD processing===

Normally, ROLL FORWARD processing begins reapplying updates at the checkpoint selected by ROLL BACK processing. However, if a discontinuity occurred for a file between the last checkpoint and the time of the crash (see [[#File discontinuities|File discontinuities]]), the file cannot be rolled back to the checkpoint. ROLL FORWARD processing cannot reapply any updates to the file between the checkpoint and the discontinuity, although updates that occurred after the discontinuity can be reapplied. Simply stated, ROLL FORWARD processing starts where ROLL BACK processing stopped for each file. 

===ROLL FORWARD processing and user hard restarts===

Restarts that occur during active transactions cause a request cancellation and can optionally cause a back out. A user hard restart occurs when a serious error is encountered during the processing of a user's request or command. Such errors include physical I/O errors in a file or physical inconsistencies in the database. The user is logged out and all files are closed. Those files are marked physically inconsistent. They cannot be used again until you clear the condition.

====Repairing physically inconsistent files====

Most of the methods for fixing a physically inconsistent, broken file, such as using the <var>INITIALIZE</var> command or running a batch job, produce a discontinuity. One method, resetting the physically inconsistent flag in <var>FISTAT</var>, actually does not fix the file but does make it available for use, presumably so that its contents can be dumped in some form for reloading. To extract the contents of a broken file successfully, you might need to make further changes to the file to avoid the broken areas. 

====Update units and hard restarts====

A hard restart normally leaves an update unit that cannot be backed out incomplete. (Restart during a transaction can optionally cause the transaction to be backed out.) If the system crashes after a hard restart but before RESTART recovery is initiated. the restarted update unit is used as the ROLL FORWARD stopping point for the files involved. If one or more of the files is cleared by a discontinuity before the system crash, that file is no longer part of the restarted update unit. Nothing is reapplied to the file until after the discontinuity. For files that are not cleared, the restarted update unit remains incomplete. 

===Back outs during ROLL FORWARD processing===

For transaction back out files, a transaction can be backed out during ROLL FORWARD processing for two reasons:
<ul>
<li>Transactions that are backed out in the original run are also backed out during ROLL FORWARD processing. In the original run, individual updates are logged to the journal as they occur. If the transaction is backed out instead of committed, this is reflected in the journal. During ROLL FORWARD processing, the individual updates are reapplied based on the journal entries logged for them by the original run. If ROLL FORWARD processing encounters a back out record on the journal, it proceeds to back out all the individual updates it reapplied since the transaction began.</li>

<li>Transactions that are still incomplete (that is, uncommitted at the time of the crash) when the end of the journal is reached are automatically backed out by ROLL FORWARD processing. </li>
</ul>

===Logging ROLL FORWARD processing===

To accomplish transaction back outs during ROLL FORWARD processing, <var class="product">Model 204</var> maintains transaction back out and constraint logs for each active transaction during Pass 2 of ROLL FORWARD processing. ROLL FORWARD transaction back out and constraint logs are built in CCATEMP, just as they were in the original run. Thus, ROLL FORWARD processing requires as much CCATEMP space for transaction back out and constraint logging as the original run. Insufficient CCATEMP space terminates recovery. 

In addition, ROLL FORWARD processing builds a special transaction control block for each possible concurrent transaction in the original run to keep track of each transaction's transaction back out and constraint log. This requires that additional storage be allocated during Pass 2 of ROLL FORWARD processing. Add this storage to SPCORE for recovery runs. The formula for calculating this additional storage is:
16 + NUSERS * 48 + (NFILES/8 rounded up to the nearest multiple of 4) = bytes of additional storage required


Where:

<var>NUSERS</var> and <var>NFILES</var> are taken from the original run. 

For example, recovery of a <var class="product">Model 204</var> run with <code>NUSERS=100</code> and <code>NFILES=50</code> requires allocation of the following additional bytes of storage during ROLL FORWARD, Pass 2:
16 + 100(48 + 50/8 rounded up to the nearest multiple of 4) = 5616


==RESTART recovery considerations for sub-transaction checkpoints==

If you are recovering a job that was using sub-transaction checkpoints, the RESTART process is going to need all the checkpoint information from that job. Therefore, in addition to the RESTART data set definition for the CHKPOINT data set from the failed job, you must add a RESTARTS data set definition that points to the CHKPNTS data set from the failed job. 

If you run RESTART recovery as a single-user job step ahead of your Online, do not add <code>CPTYPE=1</code>. The recognition of a RESTARTS data set is the indicator that the <code>CPTYPE=1</code> job is being recovered.

===Considering Roll Back and Roll Forward===
<ul>
<li>ROLL BACK

When RESTART rolls back to a sub-transaction checkpoint it then backs out any updates that had not committed when the sub-transaction checkpoint was taken.
</li>

<li>ROLL FORWARD

The roll forward process is the same as rolling forward from a transaction checkpoint.
</li>

<li>Running ROLL BACK and ROLL FORWARD as separate steps.

You can run a RESTART ROLL BACK and subsequently request just a RESTART ROLL FORWARD, however, in the case of sub-transaction checkpoint the ROLL BACK process will always occur even if you previously rolled back.</li>
</ul>

===For RESTART ROLL BACK only processing===

RESTART ROLL BACK processing requires RCVOPT=8, even if ROLL FORWARD is not specified. Roll back only to a sub-transaction checkpoint is available, so this type of recovery requires journaling of information for subsequent secondary recovery, it needed. In addition, GDGs are supported for CHKPOINT during recovery, which allows for unlimited size recovery checkpoints.

If at CHKPOINT open during RESTART ROLL BACK processing there is no CHKPOINT defined for the job, the job displays the following message and waits for a response from the operator.
OO /// UNABLE TO OPEN CHKPOINT, REPLY RETRY OR CANCEL


==Restarting after a system failure==

To restart <var class="product">Model 204</var> or an IFAM4 application after a system failure issue a <var>RESTART</var> command that is the first command immediately following the last user (IODEV) parameter line in the CCAIN input stream. The ROLL BACK and ROLL FORWARD arguments activate the ROLL BACK and ROLL FORWARD facilities used for file recovery.

The following considerations apply to using the RESTART command:
<ul>
<li>The checkpoint ID of the TO clause in the RESTART command must correspond exactly to the checkpoint ID displayed in a CHECKPOINT COMPLETED message from the <var class="product">Model 204</var> run being recovered. The option to specify the checkpoint is useful in an environment in which checkpoints are coordinated with Host Language Interface program checkpoints.</li>

<li>Files broken as a consequence of a user hard restart can be fixed by rolling back to a checkpoint prior to the current RESTART command.

If the ROLL FORWARD option is also requested, the recovered file contains all the updates completed before the user restart. This method of fixing files requires running RESTART recovery after the end of the run that broke the files and before the files are updated by any other run.
</li>

<li>To run the ROLL FORWARD facility, sufficient space must be available in spare core, SPCORE, for special control blocks that are allocated when ROLL FORWARD processing begins and freed when it is completed.

One other block is allocated, with a size given by:
16 + (36 * NUSERS)


where the value of <var>NUSERS</var> is from the run that crashed, not from the recovery run. 
</li>
</ul>

==Reporting recovery status==

The final status of each file that participated in recovery is reported at the conclusion of recovery processing, when you issue the <var>STATUS</var> command. The effects of the most recent recovery on an individual file are reported when the file is opened with update privileges.

===Reporting facilities===

Update unit ID numbers and audit trail messages help you determine exactly which updates were being made when a system crash occurred and which updates were not reapplied by RESTART recovery. 

====UPDTID user parameter====

The view-only, user parameter, <var>UPDTID</var>, lets applications determine the current update unit number. The update unit number is a sequential number that provides a unique identifier for each update unit in a <var class="product">Model 204</var> run. The update ID is incremented for each update unit. When an update unit is active, <var>UPDTID</var> contains the update ID, otherwise it contains zero. Applications can use this parameter to keep track of the most recent update unit started by each user. 

====Audit trail messages====

At the beginning and end of each update unit, The following messages are written to the audit trail:
*** M204.0173: START OF UPDATE <var class="term">n</var> AT <var class="term">hh:mm:ss.th</var>


and:
*** M204.0172: END OF UPDATE <var class="term">n</var> AT <var class="term">hh:mm:ss.th</var>


Message <code>M204.0173</code> is issued for every update unit. The default destination of both messages is the audit trail. The system manager can use the MSGCTL command to change the destination of these messages. 

===Reporting ROLL FORWARD processing===

<var class="product">Model 204</var> lists each update unit that ROLL FORWARD processing automatically backed out or partially reapplied, because the update unit was incomplete when the end of the journal was reached. The message is in the following format:
<var>***</var> M204.1200: ROLL FORWARD {BACKED OUT | PARTIALLY REAPPLIED} UPDATE <var class="term">n</var> FOR THE FOLLOWING FILES:


Where:

<var class="term">n</var> is the update ID. 

A second message lists the files updated by the update unit:
*** M204.1214: <var class="term">filename</var>


===Final status of files affected by RESTART recovery===

For files that are rolled back and not rolled forward a message in the following format is issued:
*** M204.0621: ROLLED BACK TO {CHECKPOINT | DISCONTINUITY} OF day month


For each file rolled forward, either or both of the following messages is issued:
*** M204.0622: UPDATE <var class="term">n</var> OF <var class="term">day month year hh:mm:ss.th</var>
WAS HIGHEST UPDATE FULLY REAPPLIED TO <var class="term">filename</var> BY [ROLL FORWARD | REGENERATE]

*** M204.0622: UPDATE <var class="term">n</var> OF <var class="term">day month year hh:mm:ss.th</var>
WAS LOWEST UPDATE {BACKED OUT | PARTIALLY REAPPLIED} TO<var> filename</var> BY [ROLL FORWARD | REGENERATE]


Where:

<var class="term">n</var> is the update ID. 
Note:
For update units backed out or partially reapplied, only the lowest update ID is reported. A complete list of such update units for a particular file can be obtained from the message M204.1200 described above. Those messages are available only in the recovery run, CCAAUDIT.

===Opening files and their status reports===

At the end of recovery, the X'10' bit of the <var>FISTAT</var> parameter is set to indicate that the file was recovered. Subsequently, when you open a file, messages report the effects of the most recent RESTART recovery, until you reset <var>FISTAT</var> to X'00'. The status reported during open processing is as follows:
*** M204.1203: <var class="term">filename</var> WAS LAST UPDATED ON <var class="term">day month year hh:mm:ss.th </var>

*** M204.1238: RECOVERY OF <var class="term">filename</var> WAS LAST REQUIRED ON <var class="term">day month year hh:mm:ss.th</var>

*** M204.0621: ROLL BACK TO {CHECKPOINT | DISCONTINUITY} OF <var class="term">day month year hh:mm:ss.th</var>


or:
*** M204.0622: UPDATE <var class="term">n</var> OF <var class="term">day month year hh:mm:ss.th</var> WAS {HIGHEST | LOWEST}
UPDATE {FULLY REAPPLIED | BACKED OUT | PARTIALLY REAPPLIED} TO <var class="term">filename</var> BY ROLL FORWARD


===Suppressing status reporting===

You can suppress recovery status messages when files are opened by resetting the X `10' bit of the <var>FISTAT</var> file parameter to zero with the <var>RESET</var> command.

===Requesting status reports===

Use the <var>[[STATUS command: Listing file recovery information|STATUS]]</var> command to obtain reports on the recovery status of a file in the same job that executes the <var>RESTART</var> or <var>REGENERATE</var> command.

The command is issued in the following form and applies to all operating systems:
STATUS filename


where <var class="term">filename</var> identifies a file opened during the current run by a user or a <var>RESTART</var> command.

If a user with system manager or system administrator privileges issues the <var>STATUS</var> command, you can omit the file name to list status information for all files opened during the run.

One or two lines of information are listed for each file, in the form:
filename: current-status
RESTART-status


Where:
<ul>
<li><var class="term">current-status</var> indicates special conditions that can affect discontinuities and future recovery of the file.

The values of current status are CLOSED, DEFERRED, ENQUEUED, OPEN, and UPDATED.
</li>

<li><var class="term">RESTART-status</var> indicates a file that participated in recovery in the current run.

The values of <var class="term">RESTART-status</var> are listed in the following table:
<table>
<caption>RESTART command status values</caption>
<tr class="head">
<th>Status</th>
<th>Description</th>
</tr>

<tr>
<td>BEING RECOVERED</td>
<td>The file is in the recovery process when the STATUS command is issued. </td>
</tr>

<tr>
<td>NOT RECOVERED </td>
<td>The file cannot be opened until the RESTART command ends. One of the following reasons is given:
<table>
<tr><td nowrap>DEFERRED UPDATE CHKP MISSING</td>
<td>The scan of the deferred update stream did not locate the checkpoint used for ROLL BACK processing</td></tr>

<tr><td>DEFERRED UPDATE READ ERROR</td>
<td>The scan of the deferred update stream not completed because of a read error.</td></tr>

<tr><td>DEFERRED UPDATES MISSING</td>
<td>The deferred update stream could not be opened.</td></tr>

<tr><td>MISSING</td>
<td>The file could not be opened.</td></tr>

<tr><td>OBSOLETE</td>
<td>The file was updated by a <var class="product">Model 204</var> job after the last update in the run being recovered.</td></tr>

<tr><td>IS ON A READ-ONLY DEVICE</td>
<td>The file is on a device for which <var class="product">Model 204</var> has read-only access.</td></tr>
</table></td></tr>

<tr>
<td>ROLLED BACK TO CHECKPOINT... </td>
<td>The file was rolled back to the checkpoint taken at the given date and time. The file was not rolled forward.</td>
</tr>

<tr>
<td>ROLLED BACK TO DISCONTINUITY...</td>
<td>The file was rolled back to the discontinuity occurring at the given date and time. The file was not rolled forward.</td>
</tr>

<tr>
<td>ROLLED FORWARD TO UPDATE... </td>
<td>The file was rolled forward. The last update reapplied by roll forward had the specified ID and originally ended at the given date and time.</td>
</tr>

<tr>
<td>REGENERATED TO CHECKPOINT... </td>
<td>The file was recovered using media recovery (<var>REGENERATE</var>). Updates were reapplied up to the time of the checkpoint given.</td>
</tr>

<tr>
<td>REGENERATED TO UPDATE...</td>
<td>The file was recovered using media recovery (<var>REGENERATE</var>). Updates were reapplied up to and including the specified update.</td>
</tr>
</table></li>
</ul>

==Recovery data sets and job control==

===Data sets required for RESTART recovery===

The data sets required for z/OS, z/VM, and z/VSE for RESTART recovery are listed in the following table: 
<table>
<caption>RESTART recovery data sets</caption>
<tr class="head">
<th>Model 204 file name</th>
<th>Required...</th>
</tr>

<tr>
<td>CCAJRNL</td>
<td>When running RESTART recovery as a separate job step (recommended), CCAJRNL is not required, unless FRCVOPT=8.

When running RESTART recovery in the same step that brings up the Online (not recommended), CCAJRNL is required for logging all updates (RCVOPT=8) that will occur in the Online.
</td></tr>

<tr>
<td> CCARF</td>
<td>When restarting the system. For ROLL FORWARD processing, the CCARF stream must be the same as the CCAJRNL stream from the run being recovered. </td>
</tr>

<tr>
<td>CHKPOINT</td>
<td>For taking checkpoints (RCVOPT=1) and for logging preimages of updated file pages.</td>
</tr>

<tr>
<td> RESTART</td>
<td>When restarting the system. For ROLL BACK processing, the RESTART stream must be the same as the CHKPOINT stream of the run being recovered.

(For z/VSE only) The RESTART file is used as a direct access file. DLBL code DA must be specified.
</td></tr>
</table>

===Sample z/OS JCL for a recovery run===

The JCL for the original run specifies the following data sets:
//CHKPOINT DD DSN=M204.CHKP1,DISP=OLD
//CCAJRNL DD DSN=M204.JRNL1,DISP=OLD


The JCL of the recovery run with roll forward is as follows:
//RESTART DD DSN=M204.CHKP1,DISP=OLD
//CCARF DD DSN=M204.JRNL1,DISP=OLD

//CHKPOINT DD DSN=M204.CHKP2,DISP=OLD
//CCAJRNL DD DSN=M204.JRNL2,DISP=OLD

Note: When performing a RESTART recovery, the RESTART and CCARF streams must be provided as input to an ONLINE or BATCH204 configuration.

The RESTART stream is the CHKPOINT stream from the run being recovered. Although created as a sequential output file, the RESTART stream is treated as a direct access file if on disk.

You must provide a new CHKPOINT stream for checkpoint output generated during the restart process. CCAJRNL is optional in a RESTART-only job step with NUSERS=1.

===Sample z/VSE JCL for recovery===

The following considerations apply to the required JCL statements in a z/VSE environment:
<ul>
<li>If checkpoint and journal data sets are disk resident, they are used as sequential output files that do not require allocation with the ALLOCATE utility.</li>

<li>You must provide DLBL and EXTENT statements for any recovery or restart streams that are disk resident.</li>

<li>ASSGN statements might be necessary. </li>

<li>TLBL statement is required instead of DLBL and EXTENT statements if magnetic tape is substituted for a disk file:</li>

<li>The DOS file name specified on the TLBL statement must take the form of a programmer logical unit number (SYSnnn) and must be the same as the programmer logical unit number on the ASSGN statement for the tape drive used as the input or output device.</li>

<li>You must specify the programmer logical unit number in the FILENAME parameter of a DEFINE DATASET command for the corresponding <var class="product">Model 204</var> internal file name.</li>

<li>The DEFINE DATASET commands for recovery or restart files on tape must precede the User 0 parameter line in the CCAIN input stream. Each file must be referred to by its <var class="product">Model 204</var> internal name. </li>

<li>When recovering <var class="product">Model 204</var> with RESTART processing, you must provide the RESTART and CCARF streams as input to an ONLINE or BATCH204 configuration.</li>

<li>The RESTART stream is a CHKPNT stream from the run being recovered. Although created as a sequential output file, the RESTART stream is treated as a direct access file if on disk.</li>

<li>You must provide a new CHKPNT stream for checkpoint output generated during the restart process. CCAJRNL is optional in a RESTART-only job step with NUSERS=1.</li>

<li>The lack of a DLBL statement with DA specified in the CODES parameter results in an error message from z/VSE during the processing of the RESTART command.</li>

<li>The following message results from treating the CHKPNT stream as a direct access file when it is used as input to the restart process:
M204.0139: EOF ASSUMED IN FIRST PASS OF RESTART DATASET


You can ignore the message.
</li>
</ul>

===z/VSE example 1: checkpoint and journal files on disk (FBA)===

The number of blocks and tracks used in this example are arbitrary values.
//JOB MODEL204
.
.
.
// DLBL CHKPNT,`MODEL204.CHKPOINT.FILE',99/365,SD
// EXTENT SYS021,SYSWK1,,,1000,13000
// ASSGN SYS021,DISK,VOL=SYSWK1,SHR
// DLBL CCAJRNL,`MODEL204.JOURNAL.FILE.1',99/365,SD
// EXTENT SYS021,SYSWK1,,,14000,13000
.
.
.
// EXEC ONLINE, SIZE=AUTO
PAGESZ=6184,RCVOPT=9,...
.
.
/*
/&


===z/VSE example 2: checkpoint and journal files on tape===
// JOB MODEL204
.
.
// TLBL SYS041,`M204.CHKPOINT',99/365
// ASSGN SYS041,TAPE
// TLBL SYS040,`M204.JOURNAL',99/365
// ASSGN SYS040,TAPE
.
.
// EXEC ONLINE,SIZE=AUTO
DEFINE DATASET CCAJRNL WITH SCOPE=SYSTEM FILENAME=SYS040
DEFINE DATASET CHKPNT WITH SCOPE=SYSTEM FILENAME=SYS041
PAGESZ=6184,RCVOPT=9,...
.
.
/*
/&


===z/VSE example 3: recovery-restart from disk===

In the following example, all files are on disk. The checkpoint, journal, and restart streams are on FBA devices. The ROLL FORWARD stream is on a CKD device. The number of blocks and tracks are arbitrary values.
// JOB MODEL204 RESTART
.
.
// DLBL RESTART,'MODEL204.CHKPOINT.FILE',,DA
// EXTENT SYS021,SYSWK1,,,1000,13000
// ASSGN SYS021,DISK,VOL=SYSWK1,SHR
// DLBL CHKPNT,'MODEL204.CHKPOINT.FILE.2',99/365,SD
// EXTENT SYS023,SYSWK2,,,2000,13000
// ASSGN SYS023,DISK,VOL=SYSWK3,SHR
// DLBL CCAJRNL,'MODEL204.JOURNAL.FILE.3',99/365,SD
// EXTENT SYS023,SYSWK3,,,13000,13000
// DLBL CCARF,'MODEL204.JOURNAL.FILE.2',99/365,SD
// EXTENT SYS022,SYSWK2,,,30,300
// ASSGN SYS022,DISK,VOL=SYSWK2,SHR
.
.
// EXEC ONLINE,SIZE=AUTO
PAGESZ=6184,RCVOPT=9,...
.
.
RESTART ROLL BACK ERROR STOP ROLL FORWARD
/*
/&
PAGESZ=6184


===z/VSE example 4: recovery-restart from tape===

The following example illustrates checkpoint and journal streams on disk, and restart and roll forward streams on magnetic tape. Checkpoint and journal streams are on FBA devices.
// JOB MODEL204
.
.
// DLBL CHKPNT,'MODEL204.CHKPOINT.FILE',99/365/SD
// EXTENT SYS021,SYSWK1,,,1000,13000
// ASSGN SYS021,DISK,VOL=SYSWK1,SHR
// DLBL CCAJRNL,'MODEL204.JOURNAL.FILE.1',99/365,SD
// EXTENT SYS023,SYSWK2,,,11000,13000
// ASSGN SYS023,DISK,VOL=SYSWK3,SHR
// TLBL SYS040,M204.JOURNAL.2'
// ASSGN SYS040,TAPE
// TLBL SYS041,'M204.CHKPOINT'
// ASSGN SYS041,TAPE
.
.
// EXEC ONLINE,SIZE=AUTO
DEFINE DATASET CCARF WITH SCOPE=SYSTEM FILENAME=SYS040
DEFINE DATASET RESTART WITH SCOPE=SYSTEM FILENAME=SYS041
PAGESZ=6184,RCVOPT=9,...
.
.
RESTART ROLL BACK ERROR STOP ROLL FORWARD
/*
/&

Note: <var class="product">Model 204</var> files for which the DEFINE DATASET command was used to relate the <var class="product">Model 204</var> internal file name to a z/VSE file name can be recovered with the RESTART facility, only if the DEFINE DATASET command precedes the User 0 parameter line in the CCAIN input stream. 

===Statements required for z/VM recovery===

Use the following FILEDEF statements in the Online run for which you want to provide recovery:
FILEDEF CHKPOINT mode DSN M204 chkp1
FILEDEF CCAJRNL mode DSN M204 jrnl1


The following FILEDEF statements are required for a recovery run requesting ROLL BACK and ROLL FORWARD processing:
FILEDEF RESTART mode DSN m204 chkp1
FILEDEF CCARF mode DSN m204 jrnl1
FILEDEF CHKPOINT mode DSN m204 chkp2
FILEDEF CCAJRNL mode DSN m204 jrnl2


The following considerations apply:
<ul>
<li>Do not store CCAJRNL and CHKPOINT on CMS minidisks. If the service machine crashes, CMS data sets are lost.</li>

<li>You cannot use a tape checkpoint data set as the restart data set during recovery.</li>

<li>Checkpoint and journal data set sequencing in the ONLINE EXEC can allow for multiple generations of recovery data sets. Modify FILEDEFs for journal and checkpoint. Add FILEDEFs for the old journal and checkpoint, as shown in the following example. </li>
</ul>

===z/VM recovery examples===
<ul>
<li>The statements below first determine the last set of CHKPOINT and CCAJRNL files used and then increment the next set by 1.
LISTFILE RESTART SEQ* A (EXEC
EXEC CMS &STACK
&READ VARS &FN &FT &FM
&SEQ=&&SUBSTR &FT 4
</li>

<li>The following statements calculate the next sequence number, assuming five sets of recovery data sets:
&SEQX=&SEQ
&SEQ =&SEQ+1
&IF &SEQ GT 5 &SEQ=1
</li>

<li>This statement creates a recovery control data set from the service machine:
XEDIT RESTART SEQ0
</li>

<li>Insert this line and file the data set:
*** DO NOT DELETE THIS DATA SET, IT IS ESSENTIAL TO MODEL 204 RECOVERY
</li>

<li>Rename the control file for the next run and enter the FILEDEFs, as follows:
RENAME &FN &FT &FM = SEQ &SEQ
FILEDEF CCAJRNL M DSN M204 CCAJRNL SEQ&SEQ
FILEDEF CCARF M DSN M204 CCAJRNL SEQ&SEQX
FILEDEF CHKPOINT M DSN M204 CHKPOINT SEQ&SEQ
FILEDEF RESTART M DSN M204 CHKPOINT SEQ&SEQX
</li>
</ul>

==Handling recovery failures==

Recovering from failure during recovery is possible only if the cause of the original failure is corrected. A serious error encountered during RESTART recovery results in a message describing the error, followed by a message indicating that the run is aborted.

===Determining the cause of the error===

When a recovery run aborts, the cause of the error can be determined by examining the job step return code and messages written to CCAAUDIT: 
<ul>
<li>If the <var>RESTART</var> command does not complete normally and the <var class="product">Model 204</var> run stays up, the return code is 52.</li>

<li>If the <var class="product">Model 204</var> run is terminated during evaluation of RESTART recovery, the job abends with a code of 999. </li>
</ul>

Once the cause of the error is eliminated, the recovery job can be run.

===Correcting errors===

Use the following strategies to correct errors:
<ul>
<li>If the error is an I/O error on either the RESTART or CCARF recovery streams, use IEBGENER or a similar sequential copy utility to copy the affected stream to another volume. Then rerun recovery using the copy.</li>

<li>If the problem cannot be corrected, but involves only one file, remove the file from the recovery run and recover it separately. </li>
</ul>

===Automated secondary recovery: reuse JCL===

You do not need to alter your JCL when you run RESTART recovery multiple times. Occasionally, when RESTART processing is underway, it might be interrupted: 
<ul>
<li>During ROLL BACK processing</li>

<li>During ROLL FORWARD processing</li>
</ul>

If the interruption occurs:
<ul>
<li>During ROLL BACK processing, you resubmit the job.</li>

<li>During ROLL FORWARD processing, you resubmit the job. Make no changes to the RESTART or CHKPOINT data sets.

<var class="product">Model 204</var> determines whether this is a primary or secondary recovery run and uses the appropriate file: RESTART or CHKPOINT for ROLL BACK recovery.
</li>
</ul>
<blockquote class="note">
Note special requirement for z/VSE: To take advantage of the automation of secondary recovery, you must include <code>CHKPNTD</code> in your primary recovery job. <code>CHKPNTD</code> uses the same data set name as CHKPNT, but specifies <code>DA</code> rather than <code>SD</code>. Specify CCAJRNL, CCARF and RESTART as always. For example:
// DLBL CHKPNTD,MODEL204.CHKPOINT.FILE.2,0,DA
// EXTENT SYS023,SYSWK2,,,2000,13000
// DLBL CHKPNT,MODEL204.CHKPOINT.FILE.2,0,SD
// EXTENT SYS023,SYSWK2,,,2000,13000
// ASSGN SYS023,DISK,VOL=SYSWK3,SHR


If you do not include <code>CHKPNTD</code>, you must run secondary recovery.
</blockquote>

====CHKPNTD data set under z/VSE====

When a CHKPNTD data set is defined to take advantage of the automation of secondary recovery, <var class="product">Model 204</var> can verify whether or not the CHKPNT data set is large enough for ROLL FORWARD processing.

If the CHKPNT data set is too small, <var class="product">Model 204</var> issues the following error message and terminates before any actual recovery processing begins:
M204.2605: CHKPOINT TOO SMALL FOR ROLL FORWARD - number1 BLOCKS REQUIRED; number2 FOUND


===Sizing the checkpoint data sets correctly===

For z/OS sites, <var class="product">Model 204</var> verifies that the new CHKPOINT data set is large enough to contain all the information that needs to be written to the CHKPOINT file during ROLL FORWARD processing. If the new CHKPOINT data set is too small, <var class="product">Model 204</var> issues the following error message and terminates before any actual recovery processing begins:
M204.2605: CHKPOINT TOO SMALL FOR ROLL FORWARD - number1 BLOCKS REQUIRED; number2 FOUND


In Model 204 version 7.6 and earlier, the CHKPOINT data set must also be a single-volume data set due to BSAM limitations regarding read-backward. In Model 204 version 7.7 and later, the CHKPOINT data set can be a multi-volume data set because the data set is always read forward.

If you use sub-transaction checkpoints, as well as transaction checkpoints, define the CHKPNTS data set to match the CHKPOINT data set.

===Rerunning RESTART recovery after a successful recovery===

If, for any reason, you want to force a rerun of your successful recovery job, you must define a new CHKPOINT data set. If you rerun your recovery job without a new CHKPOINT data set, recovery will be bypassed and the following message is displayed:
M204.0143: NO FILES CHANGED AFTER LAST CP, RESTART BYPASSED


===ROLL BACK processing===

The ROLL BACK process ends with a checkpoint.

When ROLL BACK processing is completed, the following messages are displayed:
M204.0158: END OF ROLLBACK
M204.0843: CHECKPOINT COMPLETED ON yy.ddd hh:mmss.th


====CHKPOINT data set required====

Changing the point at which the checkpoint is taken has the following impact. The CHKPOINT data set is required for any RESTART recovery processing, because the ROLL BACK facility needs the CHKPOINT data set to write the end-of-processing ROLL BACK checkpoint. 

If you do not define a CHKPOINT data set, the following message is issued:
M204.1300: RESTART COMMAND REQUIRES CHECKPOINT LOGGING - RUN TERMINATED


===Operational changes to ROLL FORWARD processing===

====Tracking the application of updates====

As the CCARF data set is processed by ROLL FORWARD, the following messages are printed each time a new journal block is read in which the hour in the date-time stamp at the beginning of the journal block is one hour (or more) greater than the hour in the last <code>M204.1992</code> message printed. For example,
M204.1992: RECOVERY: PROCESSING ROLL FORWARD BLOCK# 0000001B 01.235 16:31:32.43
M204.1992: RECOVERY: PROCESSING ROLL FORWARD BLOCK# 00001C57 01.235 17:00:23.34
M204.1992: RECOVERY: PROCESSING ROLL FORWARD BLOCK# 00002F05 01.235 18:00:12.38


These messages are intended to provide an indication that ROLL FORWARD processing is progressing and help you estimate when recovery will complete. The ROLL FORWARD <code>BLOCK#</code> is the sequential number (from the beginning of CCARF) of the journal block read at that point during ROLL FORWARD processing.

====ROLL FORWARD processing can be run separately====

ROLL FORWARD processing can be invoked subsequent to a successful ROLL BACK process in a separate job or job step by issuing the following command: 
RESTART ROLL FORWARD


The following message does not indicate that the full ROLL BACK processing is occurring; this message indicates that the correct starting point for ROLL FORWARD processing is being located. 
M204.2512: ROLL BACK WILL USE THE FOLLOWING dataset: RESTART | CHKPOINT


If <var class="product">Model 204</var> detects that a successful ROLL BACK process did not occur, it forces a full ROLL BACK process and all the standard ROLL BACK messages are displayed.

====Setting RCVOPT when running ROLL BACK and ROLL FORWARD separately====

When running ROLL BACK-only, Rocket Software recommends setting the <var>[[RCVOPT parameter|RCVOPT]]</var> parameter to 0. If you then run a subsequent ROLL FORWARD-only step, the ROLL BACK processing will be suppressed. If you do run ROLL BACK-only with <var>RCVOPT</var> set including 1, do not set <var>CPMAX</var> TO 0 OR 1.
<ul>
<li>If you run ROLL BACK-only with an <var>RCVOPT</var> setting that does include X'01' and the <var>CPMAX</var> parameter is set to 0 or 1, a subsequent ROLL FORWARD-only request must process ROLL BACK again to find the correct checkpoint for ROLL FORWARD processing to locate and apply the ROLL FORWARD updates.</li>

<li>If in your ROLL BACK-only step <var>RCVOPT</var> included X'01' and the <var>CPMAX</var> parameter was set greater than one, you can suppress the ROLL BACK processing on a ROLL FORWARD-only step by supplying the ROLL BACK TO checkpoint ID information that was previously rolled back to. Issue a <var>RESTART</var> command, as shown in the following syntax:
RESTART ROLL BACK TO yy.ddd hh:mm:ss. ROLL FORWARD


ROLL FORWARD-only processing uses this information to locate the correct ROLL FORWARD starting point in the CCARF data set. 

If you do not provide the checkpoint ID information, then the ROLL BACK processing is automatically triggered to locate the correct starting point for ROLL FORWARD processing.
</li>

<li>Under the previously noted conditions, if you do not provide the checkpoint ID information, then the ROLL BACK processing is automatically triggered to locate the correct starting point for ROLL FORWARD processing.</li>

<li>Also, if running a ROLL BACK-only process, the CCARF file definition is no longer required.</li>
</ul>

ROLL FORWARD processing, in any context, requires the <var>RCVOPT</var> X'01' bit. <var>CPMAX</var> should be set to a value that meets your site's need. Your current RESTART configuration should reflect whether you take the <var>CPMAX</var> default value or set some other value.

====Finding checkpoint in journal====

Locating the checkpoint record rolled back to in ROLL BACK processing is done using the NOTE/POINT facility provided for BSAM data sets. The NOTE/POINT facility allows direct access to a single record in a file of any size. This eliminates the potentially long delay currently encountered between the end of ROLL BACK processing and the beginning of ROLL FORWARD processing. The NOTE/POINT facility handles all forms of CCARF data sets, including ring streams, parallel streams, and single sequential data sets.
Note special requirement for z/VSE: IBM restricts the NOTE/POINT facility for sequential data files under z/VSE. 

==RESTART recovery requirements - CCATEMP, NFILES, NDIR==

Checkpoint information that is logged can include data for RESTART recovery that must be relocated back to the same CCATEMP pages and using the same internal file numbers during RESTART recovery that were used during the Online run. Therefore, in a RESTART job or step the CCATEMP size, <var>NDIR</var> and <var>NFILES</var> must be equal to or greater than the values after initialization of the job being recovered. 

The RESTART value for: 
<ul>
<li><var>NFILES</var> must be greater than or equal to the value for NFILES specified in the Online.</li>

<li><var>NDIR</var> must be greater than or equal to the value for NDIR specified in the Online.</li>

<li><var>TEMPPAGE</var> (CCATEMP) in RESTART must be greater than or equal to the value for TEMPPAGE specified in the Online. </li>
</ul>

If not properly set for RESTART, you will receive the following error message that specifies the required value and initialization is terminated. Reset the parameter to the value indicated in the message and resubmit the RESTART job.
M204.0144 parameter=value BUT MUST BE AT LEAST value (reason)


==Recovering deferred update mode files==

Under the z/OS and z/VM operating systems, files that were in deferred update mode at the time of a crash can be recovered using the ROLL BACK facility either alone or in conjunction with the ROLL FORWARD facility. Checkpoint markers are written on every open, deferred update data set. 

===How recovery works for deferred update files===

For each file being recovered, ROLL BACK processing opens the file's deferred update data set(s) for input. Each deferred update data set is scanned for a marker that corresponds to the last checkpoint. The data set is then changed from input to output, so that changes made during ROLL FORWARD processing are written over changes that were backed out. At the end of recovery, files in deferred update mode are not closed. Changes made during the new run are added to the old deferred update data set. 

If ROLL BACK processing cannot open the file's deferred update data set, or if the deferred data set or data sets do not contain the correct checkpoint marker, the file is not recovered.

===Deferred update recovery not supported under z/VSE===

Support for recovery of files in deferred update mode is not implemented under the z/VSE operating system.

==Recovering dynamically allocated data sets==

The <var>RESTART</var> command, by default, dynamically reallocates and recovers any <var class="product">Model 204</var> files or deferred update data sets that were dynamically allocated in the run that is being recovered. 

===How recovery works for dynamically allocated data sets===

Dynamically allocated data sets normally are closed and freed after recovery processing. Therefore, it is necessary to reallocate the data sets after recovery completes. However, if a dynamically allocated file were opened in deferred update mode in the run that is being recovered, the file in deferred update mode remains allocated and open after recovery completes. Any deferred update data sets that were dynamically allocated also remain allocated and open. This ensures that any further deferred updates after recovery do not overwrite previous records in the deferred update data set.

===Bypassing dynamic file allocation===

If RESTART recovery processing determines that no files need to be recovered, dynamic allocation is bypassed, which saves CPU and wall clock time. 

==Media recovery==

You can perform media recovery using the <var>REGENERATE</var> or <var>REGENERATE ONEPASS</var> command in a Batch204 job or a single-user Online.

Media recovery procedures are useful for restoring a file when:
<ul>
<li>Hardware error occurs on the storage media</li>

<li>Data set is accidentally deleted</li>

<li>ROLL FORWARD processing fails for an individual file</li>
</ul>

Media recovery can automatically restore from a dump of the file, or can allow the restore to be done using any desired technique prior to running media recovery. 

Media recovery is initiated by the <var>REGENERATE</var> or <var>REGENERATE ONEPASS</var> command in the CCAIN input stream. Processing reapplies updates made to single or multiple files since the time of a backup of those files. 

File regeneration cannot occur across discontinuities or across <var class="product">Model 204</var> release boundaries.

===Phases of a media recovery run===

A media recovery run consists of the following phases:
<ol>
<li>Phase 1 — The <var>REGENERATE</var> or <var>REGENERATE ONEPASS</var> command is parsed for syntax errors. If an error is encountered, the command is rejected and no processing is performed.</li>

<li>Phase 2 — All files for which dump files are specified in the <var>REGENERATE</var> or <var>REGENERATE ONEPASS</var> command are restored. This step is performed only if media recovery is performing the restore. </li>

<li>Phase 3 — The input journal file is processed in one or two passes.</li>
</ol>

===Input journal processing for the REGENERATE command===

The last phase of media recovery is performed in two passes as follows:
<ul>
<li>Pass 1 — The input journal is scanned for the starting and stopping point of all participating files:</li>

<li>If any errors are detected, processing terminates for the files affected by the error.</li>

<li>If any files remain to be processed after Pass 1 is completed, the input journal is closed and reopened.</li>

<li>If the <var>REGENERATE</var> command <var>BEFORE</var> clause is used, the last complete update or checkpoint taken before the time specified is determined.</li>

<li>Pass 2 — The input journal is reread and updates that were originally made between the starting and stopping points are reapplied to the files. </li>
</ul>

===Input journal processing for the REGENERATE ONEPASS command===

As the journal records are read, the updates are applied:
<ul>
<li>The input journal is scanned for the starting and stopping point of all participating files. If any errors are detected, processing terminates for the files affected by the error.
</li>

<li>The input journal is read and updates that were originally made between the starting and stopping points are reapplied to the files. </li>
</ul>

If <var>ONEPASS</var> is specified for a <var>REGENERATE</var> command and the file being regenerated has been recovered within the supplied journals, the regeneration fails with the following error:
M204.2629: ONEPASS DISALLOWED ACROSS FILE RECOVERY


The file is deactivated and contains all updates as of the time of the recovery. If regeneration is desired across a recovery, two passes of the journal are required.

<var>REGENERATE</var> processing has no back out capability. In <var>ONEPASS</var>, each update is applied as read from the journal. This causes a problem if a file is rolled back. The way two passes works is that it reads the entire journal and then sets starting and stopping points for the second pass. This way the updates that are unneeded can be omitted as <var>REGENERATE</var> processing reads past them.

===Running REGENERATE with the IGNORE argument===

Using the <var>IGNORE</var> argument with a <var>REGENERATE</var> command bypasses the file parameter list (FPL) update timestamps. This allows you to run <var>REGENERATE</var> processing with one CCAGEN at a time, instead of requiring a single concatenated journal. If necessary, you can run single CCAGEN data sets one at a time in multiple <var>REGENERATE</var> steps. 

For example, the first <var>REGENERATE</var> command may be as follows and provide the first journal:
REGENERATE FILE abc FROM dumpabc


A subsequent run may provide the second journal and specify:
REGENERATE FILE abc IGNORE


The second run picks up from where the first <var>REGENERATE</var> processing ended and applies the second journal updates. 

Previously, you had to concatenate all journals into one data set or specify using a concatenated <code>CCAGEN DD</code> statement. 
Attention: If you omit a journal, it is not reported. Therefore, use the new option with care.

The <var>IGNORE</var> keyword is not valid with the <var>FROM</var> option.


===Number of files that can be regenerated===

The number of files that can be regenerated in a single run depends on the settings of the following parameters on User 0's parameter line:
<ul>
<li><var>NDCBS</var>, the number of data sets associated with the files being regenerated.</li>

<li><var>NDIR</var>, the number of file directory entries, must be at least as large as the number of files to be regenerated in a single media recovery run.</li>

<li><var>NFILES</var>, the number of file save areas to allocate, must be at least as large as the number of files to be regenerated in a single media recovery run.</li>
</ul>

Additional files might be needed if the run performs functions in addition to the <var>REGENERATE</var> operation.

===Using the REGENERATE or the REGENERATE ONEPASS command===

====Choosing to use REGENERATE or REGENERATE ONEPASS====

If you must regenerate across a recovery process, two passes of the journal are required. You must build <var>REGENERATE</var> commands. In this case, a <var>REGENERATE ONEPASS</var> command will terminate with an error.

====Specifying a starting point====

The starting point for reapplying updates to a file is the first start of an update unit with a time greater than the last updated time of the file being processed.
<ul>
<li>You can request a specific or nonspecific stopping point as an option of the <var>REGENERATE</var> command. </li>

<li>You can request only a specific stopping point as an option of the <var>REGENERATE ONEPASS</var> command.</li>
</ul>

====Specifying a stopping point====

To request a specific stopping point, use the <var>TO</var> clause of the <var>REGENERATE</var> or <var>REGENERATE ONEPASS</var> command. If you do not indicate a stopping point, all updates in the input journal are applied.

====Not specifying a stopping point====

To request a nonspecific stopping point, use the <var>BEFORE</var> clause of the <var>REGENERATE</var> command. The <var>BEFORE</var> clause uses the last complete update or checkpoint that occurred before the specified time as the stopping point for reapplying file updates. You cannot use a <var>BEFORE</var> clause with a <var>REGENERATE ONEPASS</var> command.

====Using a FROM clause====

When a <var>REGENERATE</var> or <var>REGENERATE ONEPASS</var> command is issued without a <var>FROM</var> clause, the command assumes that the file was previously restored. The following validity checking occurs:
<ul>
<li>Physical consistency — If a file is marked physically inconsistent, processing is discontinued.</li>

<li>Release boundary — If a file was created prior to <var class="product">Model 204</var>, Release 9.0, processing is discontinued. </li>
</ul>

The following error messages pertain to the <var>REGENERATE</var> command <var>FROM</var> option:
M204.1711: 'FROM' CLAUSE REQUIRED FOR FILES CREATED PRE R9
M204.1426: INVALID 'FROM 'CLAUSE
M204.1708: REGENERATE DID NOT PERFORM RESTORE


===Required data sets for media recovery===

The STEPLIB, CCAIN, and CCAPRINT data sets are required for media recovery.

<code>DB1</code> through <code>DBn</code>, where n is a number corresponding to the last file to be recovered, define the file data sets to be recovered.

If an <code>INCREASE DATASETS</code> command is issued during the recovered time interval, data sets added to the file by the INCREASE also must be specified.

<code>DUMPDB1</code> through <code>DUMPDBn</code>, where n is a number corresponding to the last file to be recovered, define the dumped versions of the file data sets to be recovered.

The name specified for the file to be regenerated must match the name of the dump file. 

If the run completes successfully, <var class="product">Model 204</var> displays the message:
*** M204.1437: REGENERATE IS NOW COMPLETE


Possible error and database inconsistency conditions are described in [[Media recovery]].

===Example: z/OS media recovery run===

This example shows the z/OS JCL required to invoke a media recovery run:
//REGEN JOB REGEN,MSGLEVEL=(1,1)
//M204 EXEC PGM=BATCH204,PARM='SYSOPT=136'
//STEPLIB DD DSN=LOCAL.M204.LOADLIB,DISP=SHR
//CCAJRNL DD DSN=REGEN.CCAJRNL,DISP=(NEW,CATLG,CATLG),
// VOL=SER=WORK,UNIT=DISK,SPACE=(TRK,(5))
//CCAGEN DD DSN=LOCAL.M204.JOURNAL.840228,DISP=SHR
// DD DSN=LOCAL.M204.JOURNAL.840229,DISP=SHR
// DD DSN=LOCAL.M204.MERGED.JOURNAL.840302,DISP=SHR
//CCAAUDIT DD SYSOUT=A
//CCAPRINT DD SYSOUT=A
//CCASNAP DD SYSOUT=A
//CCATEMP DD DISP=NEW,UNIT=WORK,SPACE
//CCASTAT DD DSN=LOCAL.M204.CCASTAT,DISP=SHR
//CCAGRP DD DSN=LOCAL.M204.CCAGRP,DISP=SHR
//TAPE2 DD DSN=M204.DB1.DEFERF,DISP=SHR
//TAPE3 DD DSN=M204.DB1.DEFERV,DISP=SHR

//DB1 DD DSN=LOCAL.M204.DB1,DISP=SHR
//DB2 DD DSN=LOCAL.M204.DB2,DISP=SHR
//DB3 DD DSN=LOCAL.M204.DB3,DISP=SHR
//DB4 DD DSN=LOCAL.M204.DB4,DISP=SHR
//DUMPDB1 DD DSN=DUMP.DB1,DISP=SHR
//DUMPDB2 DD DSN=DUMP.DB2,DISP=SHR
//DUMPDB3 DD DSN=DUMP.DB3,DISP=SHR
//CCAIN DD
* NFILES=10,NDIR=10,LAUDIT=1,SPCORE=10000
*
* OPEN THE FILE IN DEFERRED UPDATE MODE
* BEFORE THE REGENERATE COMMAND
*

OPEN DB1,TAPE2,TAPE3

REGENERATE
FILE DB1 FROM DUMPDB1
FILE DB2 FROM DUMPDB2 TO LAST CHECKPOINT
FILE DB3 FROM DUMPDB3 TO UPDATE 3 OF 83.216 06:28:42:98
FILE DB4 TO CHECKPOINT 83.216 01:05:22:99
END
EOJ


==Media recovery NonStop/204==

Media recovery restores an individual <var class="product">Model 204</var> file, not the entire database as discussed in [[#ROLL BACK facility|ROLL BACK facility]], from a backed up version of the file. 

You can use third-party software to backup <var class="product">Model 204</var> files. Third-party backups run independently of <var class="product">Model 204</var>, while the Online remains running and responsive to non-updating activity. This provides a greater ability to run <var class="product">Model 204</var> in a nonstop 24*7 mode.

The following describes the functionality and facilities that allow you to develop, integrate, and manage your third-party software backup methodology.

===Managing third-party backups===

As third-party software is unaware of <var class="product">Model 204</var> file management, it must be assured that when a file is being backed up that the file is logically and physically consistent. An external backup of a file taken when Online updates are occurring is unreliable and must not be used in any subsequent attempt to restore or recover the file. To assure file integrity, all updating must cease and remain stopped until the backup processing is complete. 

====Understanding an extended quiesce====

You can create a period of time during which files cannot be updated. By using a set of commands, two CCAIN parameters, and a set of $functions, you can create an interval, after a checkpoint is taken, during which updating is stopped. This interval is called the extended quiesce interval or, simply, an extended quiesce.

SOUL file updating requests go into a bumpable wait when the system is in the extended quiesce state. If the users in such a wait are bumped, their threads are restarted with the following message:
M204.2546:SOFT RESTART OF USER DUE TO BUMP WHILE IN EXTENDED QUIESCE


File commands that start update units remain in a nonbumpable, swappable wait until the extended quiesce ends. File updating IFAM threads remain in nonbumpable, swappable waits during extended quiesce.

====Signing on IFAM threads during an extended quiesce====

When single or multicursor IFAM threads signs on to <var class="product">Model 204</var>, they issue the following message: <code>M204.0962 SIGN ON, JOB NAME = XXXXXXXX'</code>. During an extended quiesce, IFAM2 threads (IODEV=23) cannot sign on to <var class="product">Model 204</var>. If these threads try to sign on during extended quiesce, they are placed in a swappable wait of type 20. The sign-on messages are not displayed. The wait ends when the extended quiesce terminates. Then, the waiting threads can sign on. When signing on is complete, the <var>MONITOR</var> and <var>IFAMSTAT</var> commands can display their status. 

====Coordinating an external backup====

External backups must be taken only during an extended quiesce. The duration of the extended quiesce depends on when a <code>CHECKPOINT END EXTENDED QUIESCE</code> command is issued or, on the values of the parameters, <var>[[CPQZSECS parameter|CPQZSECS]]</var> and <var>[[CPQZACTN parameter|CPQZACTN]]</var>.


You can create and manage an extended quiesce with the following System Manager <var>[[CHECKPOINT command|CHECKPOINT]]</var> commands: 
<ul>
<li><code>CHECKPOINT SET Extended Quiesce</code>

When issued, this command places the Online into an extended quiesce immediately after the next successful checkpoint. 
</li>

<li><code>CHECKPOINT UNSET Extended Quiesce</code>

The <var>UNSET</var> option reverses the effect of the <var>SET</var> option.
</li>

<li><code>CHECKPOINT END Extended Quiesce</code>

This command terminates an extended quiesce.
</li>
</ul>

====Ring stream journals and extended quiesce====

If a ring stream journal is in use, an off-loading is automatically attempted at the beginning of the extended quiesce. If off-loading is successful, the next ring stream member is made active. At the end of the extended quiesce, a checkpoint is taken and a checkpoint record is written on the active journal member. If a subsequent RESTART recovery is required, the active journal member will contain a checkpoint record.

===Programming a third-party backup===

The automated submission of third-party backup jobs requires a SOUL interface to the internal extended quiesce data structures. This is provided primarily by using the ECB-related $functions, <var>$Ecbdget</var>, <var>$Ecbdset</var>, <var>$Post</var>, <var>$Unpost</var>, and <var>$Wait</var> as well as the named ECBs used for extended quiesce: CPQZ and QZSIG. Both ECBs are defined internally to the checkpoint subsystem. 
<ul>
<li>The CPQZ ECB is automatically posted at the start of an extended quiesce and automatically unposted at the end of an extended quiesce.

By specifying CPQZ as a keyword, you can use the <var>$EcbDGet</var> and <var>$EcbDSet</var> functions to write and read up to 255 bytes of data to and from a checkpoint-maintained internal area. This data area is cleared automatically at the end of extended quiesce.
</li>

<li>A SOUL thread can post the QZSIG ECB by issuing a <var>$Post</var> function only during an extended quiesce.

Another SOUL thread can wait on the posting of the QZSIG ECB, but only during an extended quiesce interval. Outside an extended quiesce, the QZSIG ECB is unposted. 
</li>
</ul>

===Programming a wait for extended quiesce===

The following procedure demonstrates the use of the extended quiesce and the named ECBs to submit and control a third-party back-up job.
PROCEDURE WAIT.FOR.EXTENDED.QUIESCE
BEGIN
IF $SETG('HDRCTL',$VIEW('HDRCTL')) THEN
PRINT 'GTBL NOT SET - BACKUP WILL NOT BE SUBMITTED'
STOP
ELSE
PRINT '$WAIT CPQZ ' with $WAIT('CPQZ')
END IF
END
R HDRCTL 3
USE $JOB
DISPLAY BACKUP.MODEL204.DATABASE.FILES.JOB
R HDRCTL ?&HDRCTL
BEGIN
PRINT '$WAIT QZSIG - WAIT UNTIL BACKUP COMPLETES ' -
WITH $WAIT('QZSIG')
IF $ECBDGET('CPQZ') = 'GOOD BACKUP' THEN
PRINT 'BACKUP SUCCESSFUL'
ELSE
PRINT 'BACKUP UNSUCCESSFUL'
END IF
END
CHECKPOINT END EXTENDED QUIESCE
END PROCEDURE


Once the extended quiesce starts, the previous SOUL request continues to the <code>$WAIT('QZSIG')</code> function call and waits for third-party back-up job to end.

===Submitting a backup===

In the following procedure, <code>BACKUP.MODEL204.DATABASE.FILES.JOB</code>, the <code>BACKUP</code> step executes an IEFBR14 — essentially a no-operation. However, this job could be the submission of any third-party backup software that meets your backup requirements. The subsequent BATCH2 steps are executed depending upon the condition code from the step named <code>BACKUP</code>: 
PROCEDURE BACKUP.MODEL204.DATABASE.FILES.JOB
//PLACE A SITE-VALID JOBCARD HERE
//BACKUP EXEC PGM=IEFBR14,COND=EVEN
//DD1 DD DISP=SHR,DSN=YOURDATASET.TOBACKUP
//* ITFAILED STEP IF BACKUP DID NOT END WITH CONDITION CODE 0
//* EOJ THE ONLINE
//ITFAILED EXEC PGM=BATCH2,PARM='CRIOCHNL',COND=(0,EQ,BACKUP)
//STEPLIB DD DSN=MODEL204.LOADLIB,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//CCAOUT DD SYSOUT=*
//CCAIN DD *
LOGIN SUPERKLUGE
PIGFLOUR
BEGIN
PRINT 'PASS INFO TO $WAIT QZSIG WAITER ' -
WITH $ECBDSET('CPQZ','BAD BACKUP')
PRINT '$POST QZSIG - WAKE UP $WAIT QZSIG WAITER ' -
WITH $POST('QZSIG')
END
EOD
EOJ
LOGOUT
//* ITWORKED STEP IF BACKUP DID COMPLETE WITH CONDITION CODE 0
//* END THE EXTENDED QUIESCE IN THE ONLINE
//ITWORKED EXEC PGM=BATCH2,PARM='CRIOCHNL',COND=(0,NE,BACKUP)
//STEPLIB DD DSN=MODEL204.LOADLIB,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//CCAOUT DD SYSOUT=*
//CCAIN DD *
LOGIN SUPERKLUGE
PIGFLOUR
BEGIN
PRINT 'PASS INFO TO $WAIT QZSIG WAITER ' -
WITH $ECBDSET('CPQZ','GOOD BACKUP')
PRINT '$POST QZSIG - WAKE UP $WAIT QZSIG WAITER ' -
WITH $POST('QZSIG')
END
LOGOUT
/*
//
END PROCEDURE


===Managing the extended quiesce===

In the previous example, should a CPQZSECS time-out cause a CPQZACTN argument to issue an internal <code>CHECKPOINT END EXTENDED QUIESCE</code> command, the ending of the extended quiesce is delayed until the thread, which issued the <code>$WAIT('QZSIG')</code>, drops out of wait (wait type 48). The <code>$WAIT('QZSIG')</code> can be satisfied by one of the following:
<ul>
<li>Have another thread issue a <code>$POST('QZSIG')</code> function call</li>

<li>Bump the thread in wait 48</li>

<li>Issue an <code>EOJ</code> command</li>
</ul>

Use of the <code>$WAIT('QZSIG')</code> function is an aid to prevent the inadvertent ending of an extended quiesce while a third-party backup job is running.
Note: A <code>$POST('QZSIG')</code> function call can be issued only once per extended quiesce. A <var>$ECBDSET</var> function call may not be issued after a <code>$POST('QZSIG')</code> function has been issued.

The previous code examples perform no backups and are not intended as full representations of what you can or should use as your backup strategy.

====BATCH2 backup requirements====

To use a BATCH2 connection to notify or signal the Online as to how to proceed when your backup processing is complete, the Online needs:
<ul>
<li>BATCH2 IODEV definition</li>

<li>CRAM installed and activated</li>

<li>CRIOCHNL defined in the CCAIN stream, if it is not using the default CRIOCHNL name.</li>
</ul>

===Delayed ending for extended quiesce or status message===

During an extended quiesce, the following message is displayed on the operator's console every minute, or the CPQZSECS time limit if it is less than 60.
M204.2610. SYSTEM ENTERED EXTENDED QUIESCE AT: mm/dd/yy hh:mm:ss, ALL FILE UPDATING REMAINS SUSPENDED
{- END EXTENDED QUIESCE PROCESSING IS DELAYED WITH nnnn USER(S) IN WAIT TYPE 47, mmmm USER(S) IN WAIT TYPE 48}


When the extended quiesce ends, one of the versions of M204.2613 message is displayed on the operators console.
M204.2613. SYSTEM ENTERED EXTENDED QUIESCE AT: mm/dd/yy hh:mm:ss,
SYSTEM EXITED EXTENDED QUIESCE AT: mm/dd/yy hh:mm:ss, REASON = reason-text


where <var class="term">reason-text</var> is one of the following:
<ul>
<li><var>END COMMAND ISSUED BY USER: nnnnnn</var></li>

<li><var>EOJ COMMAND</var></li>

<li><var>CPQZACTN TIME OUT ACTION</var></li>

<li><var>CHKPPST RESTART</var></li>

<li>Issuing a <var>CHKMSG</var> or <var>MONITOR CHECKPOINT</var> command during extended quiesce displays the <code>M204.2610</code> message, in addition to other <var>CHKMSG</var> or <var>MONITOR CHECKPOINT</var> command information. </li>

<li>Issuing a <var>CHKMSG</var> or <var>MONITOR CHECKPOINT</var> command after an extended quiesce ends displays a <code>M204.2613</code> message with other checkpoint information.</li>
</ul>

If an extended quiesce is to end, because either a <code>CHECKPOINT END EXTENDED QUIESCE</code> command was issued, or X'40' is specified for ENDEQ as the CPQZACTN argument at CPQZSECS time-out, and there is a SOUL thread in a <code>$WAIT('QZSIG')</code> wait, the <code>M204.2610</code> message is repeated on the operators console every minute as follows:
M204.2610. SYSTEM ENTERED EXTENDED QUIESCE AT: yy/ddd hh:mm:ss, ALL FILE UPDATING REMAINS SUSPENDED
- END EXTENDED QUIESCE PROCESSING IS DELAYED WITH nnnn USER(S) IN WAIT TYPE 48.


This form of the <code>M204.2610</code> message can also be displayed with the <var>CHKMSG</var> or <var>MONITOR CHECKPOINT</var> commands.

==Using the UTILJ utility==

Use the standalone, batch utility, UTILJ, for the following purposes: 
<ul>
<li>Create end-of-file (EOF) markers on journal data sets that were never closed because of a system failure</li>

<li>Obtain information about the contents of journal data sets for performance analysis, capacity planning, and determining the optimal number and size of journal buffers</li>

<li>As a debugging utility when working with Rocket Software Technical Support </li>
</ul>

===UTILJ and stream configurations===

Because the UTILJ utility processes only single data sets, the following considerations apply:
<ul>
<li>When creating EOF markers, copy members of concatenated, parallel, or ring streams using the <var>[[COPY STREAM command|COPY STREAM]]</var> command. Here, recovery data streams are discussed.</li>

<li>When generating reports, process members of concatenated, parallel, or ring streams one at a time. To report on the contents of a concatenated stream, use regular z/OS concatenation.
</li>
</ul>

===UTILJ options===

The following options control the execution and output of the UTILJ utility:
<table>
<caption>UTILJ utility options</caption>
<tr class="head">
<th>Option </th>
<th>Specifies </th>
<th>Description </th>
</tr>

<tr>
<td>DISPDUPS </td>
<td>To override the suppression of duplicate output lines when displaying hexadecimal output. </td>
<td> </td>
</tr>

<tr>
<td>EOF </td>
<td>Input is a journal without an end-of-file marker </td>
<td>You cannot specify other options with the EOF option. You must have write access to the device containing the journal to be repaired, except in z/VSE environments. See also [[#EOF option|EOF option]].</td>
</tr>

<tr>
<td>FDIR </td>
<td>File directory number of the run creating the journal </td>
<td>Prints all information related to the specified file unless further qualified by other parameters such as FROMTIME, TOTIME, and RECTYPE.</td>
</tr>

<tr>
<td>FILENAME </td>
<td>DDNAME of the file, the name specified in the CREATE command, to be printed </td>
<td>All file-related entries are printed unless further qualified by other parameters, such as FROMTIME, TOTIME, and RECTYPE.</td>
</tr>

<tr>
<td>FORMAT </td>
<td>Both report types 1 and 2 are to be printed </td>
<td>This option is retained for compatibility with previous releases. </td>
</tr>

<tr>
<td>FROMDATE and TODATE </td>
<td>Range of dates for which journal records are printed </td>
<td>Must be 5-digit Julian dates such as 02062. For behavior, see the "From-to date-time option combinations" table, below.</td>
</tr>

<tr>
<td>FROMTIME and TOTIME </td>
<td>Time range for which journal records are printed </td>
<td>Must be in 24-hour clock (hhmmss) format such as 151003 = 3:10:03 P.M. For behavior, see the "From-to date-time option combinations" table.</td>
</tr>

<tr>
<td>RECTYPE </td>
<td>Type of records </td>
<td>Repeat RECTYPE as necessary. The default is all record types. For information about journal record types, see [[Using system statistics]].</td>
</tr>

<tr>
<td>REPORT </td>
<td>Type of report to print </td>
<td>Discussed separately in [[#UTILJ REPORT options|UTILJ REPORT options]].</td>
</tr>

<tr>
<td>START </td>
<td>Update unit number with which to begin printing. </td>
<td> </td>
</tr>

<tr>
<td>STOP </td>
<td>Update unit number at which to end printing.</td>
<td> </td>
</tr>

<tr>
<td>SUBTYPE </td>
<td>Subtype of the records printed </td>
<td>

Typically, this option is used with RECTYPE = 6 to restrict the type of ROLL FORWARD entries printed.

SUBTYPE values can be found in [[Using system statistics]], where journal layouts are documented. UTILJ expects a SUBTYPE value to be entered in decimal format, and so, for example, a SUBTYPE of x'81' (since-last statistics including conflict statistics) should be entered using its decimal value, SUBTYPE=129.
</td>
</tr>
</table>

====EOF option====

The EOF option writes an end-of-file marker at the appropriate place. The UTILJ utility reads each block of the CCAJRNL data set until it encounters an I/O error or a validation error, such as a time stamp out of sequence. The journal is then physically closed, causing an end-of-file marker to be written.

A journal that is part of a normal <var class="product">Model 204</var> run that has an end-of-file marker present is not affected when used as input to the UTILJ utility.

====From-to date-time options====

The following table describes the behavior of UTILJ, depending on the combination of the from-to-date options and from-to-time options. 
<table>
<caption>From-to date-time option combinations</caption>
<tr class="head">
<th>Option present </th>
<th>And option absent </th>
<th>Read input journal...</th>
</tr>

<tr>
<td>FROMDATE / TODATE </td>
<td>FROMTIME / TOTIME </td>
<td>From beginning to end; process any record with a date in the range of FROMDATE to TODATE inclusive ignoring the time.</td>
</tr>

<tr>
<td>FROMTIME / TOTIME </td>
<td>FROMDATE / TODATE </td>
<td>From beginning to end; process any record with a time in the range of FROMTIME to TOTIME inclusive ignoring the date.</td>
</tr>

<tr>
<td>FROMTIME </td>
<td>TOTIME </td>
<td>As if TOTIME was 2359</td>
</tr>

<tr>
<td>TOTIME </td>
<td>FROMTIME </td>
<td>As if FROMTIME was 0000</td>
</tr>

<tr>
<td>FROMDATE </td>
<td>TODATE </td>
<td>From beginning to end; process any record with a date greater than or equal to FROMDATE value until the end of the input journal.</td>
</tr>

<tr>
<td>TODATE</td>
<td>FROMDATE</td>
<td>From beginning to end; process all records from beginning of the journal with a date less than or equal to TODATE value.</td>
</tr>
</table>

===UTILJ REPORT options===

UTILJ reports have a 2-line header, as shown in the following example, that reflects the circumstances of your site.
UTILJ UTILITY - VERSION 7.1.0D
DATE/TIME OF RUN: 03/31/2009 00:18:48


The REPORT options for the UTILJ utility are:
<table>
<tr class="head">
<th>Option</th>
<th>Prints...</th>
</tr>

<tr>
<td align="right">1</td>
<td>Only audit trail information, no hexadecimal</td>
</tr>

<tr>
<td align="right">2</td>
<td>Individual journal records formatted in hexadecimal only</td>
</tr>

<tr>
<td align="right">4</td>
<td>Journal blocks in hexadecimal only</td>
</tr>

<tr>
<td align="right">8</td>
<td>Histogram showing the size ranges of the blocks written in a run</td>
</tr>
</table>

====Using CCAJLOG and option 1====

If CCAJLOG is in use, Report option 1 selects no output since audit information is absent from the CCAJRNL.

====Using Options 2, 4, and 8====

A histogram is particularly useful when there are frequent small updates or in a read-only environment where the buffer is written infrequently.

Report option values are hexadecimal and can be summed. For example, to combine options 2 and 8, specify REPORT=A (not 10, which generates an invalid function error).

The default is <code>REPORT=F</code>, specifying to print all report types. 

For example:
BLOCKSIZE RANGE IN BYTES COUNT
6144 - 6655 224
5632 - 6143 1020
5120 - 5631 196
4608 - 5119 212
4096 - 4607 224
3584 - 4095 252
3072 - 3583 264
2560 - 3071 372
2048 - 2559 676
1536 - 2047 1300
1024 - 1535 2600
512 - 1023 5128
0 - 511 25244
TOTAL # BLOCKS 37712
DCB BLOCKSIZE IS 6749

<ul>
<li><code>BLOCKSIZE RANGE IN BYTES</code> is the breakdown of all block sizes, up to the largest block written. Unused space in the buffer is not listed.</li>

<li><code>COUNT</code> is the number of blocks in that BLOCKSIZE range read during the scan of CCAJRNL.</li>

<li><code>TOTAL # BLOCKS</code> is the number of blocks read during the scan of CCAJRNL.</li>

<li><code>DCB BLOCKSIZE</code> is the size of each journal buffer. In this example, the buffer is the default size, 6749 bytes. </li>
</ul>

===UTILJ return codes===

The return codes in the following table apply to the UTILJ utility: 
<table>
<caption>UTILJ return codes</caption>
<tr class="head">
<th>Return code</th>
<th>Description</th>
</tr>

<tr>
<td align="right">0</td>
<td>Normal return </td>
</tr>

<tr>
<td align="right">16</td>
<td>OPEN failed for CCAPRINT </td>
</tr>

<tr>
<td align="right">20</td>
<td>OPEN failed for CCAJRNL </td>
</tr>

<tr>
<td align="right">24</td>
<td>I/O error occurred reading or writing CCAJRNL</td>
</tr>

<tr>
<td align="right">28</td>
<td>CCAJRNL contains one or more corrupted journal blocks</td>
</tr>
</table>

Return code 28 is issued whenever a corrupted journal block is detected while reading CCAJRNL. The following message is also printed at the end of LISTING:
**** THIS CCAJRNL CONTAINS ONE OR MORE CORRUPTED JOURNAL BLOCKS - PLEASE CONTACT CCA CUSTOMER SUPPORT


This is a serious error that must be brought to the immediate attention of Technical Support.

===z/VSE considerations===

In z/VSE, print or copy options are specified through a control statement from SYSIPT:
<ul>
<li>Omission of the control statement produces a hexadecimal dump.</li>

<li>The control statement format is free form, with continuation from one input statement to the next specified by a comma immediately following the last parameter on the statement to be continued. </li>

<li>The input stream defined in the JCL can be either a DLBL and EXTENT or a TLBL for file name CCAJRNL.

If the input file is on tape, symbolic unit SYS004 must be assigned to the tape drive on which the tape is mounted. 
</li>

<li>The EOF option also requires an output stream, which must be defined in the JCL by either a DLBL and EXTENT or a TLBL for file name CCARF.

If the output file is on tape, symbolic unit SYS005 must be assigned to the tape drive on which the tape is mounted.
</li>
</ul>

===UTILJ examples===

The following examples provide the JCL to run UTILJ and illustrate how to request the printing of journal information for the hour between 12:05:13 and 13:05:13.

====z/OS UTILJ example====
//UTILJ EXEC PGM=UTILJ,PARM='FROMTIME=120513,TOTIME=130513'
//STEPLIB DD DSN=M204.LOADLIB,DISP=SHR
//CCAPRINT DD SYSOUT=A
//SYSUDUMP DD SYSOUT=A
//CCAJRNL DD DSN=M204.JOURNAL,DISP=OLD


====z/VSE UTILJ example====

In this example, UTILJ transfers journal streams between disk and tape media, or prints the journal in hexadecimal format. You can select only one option for each execution of UTILJ:
// JOB UTILJ PRINT A JOURNAL IN HEX DUMP AND FORMATTED MODE
// DLBL CCAJRNL,'CCAJRNL.FILE',0
// EXTENT SYS001,SYSWK1,,,1000,390
// EXEC UTILJ,SIZE=AUTO
REPORT=2,
FROMTIME=120513,TOTIME=130513
/*
/&

// JOB UTILJ COPY A JOURNAL FROM DISK TO TAPE
// DLBL CCAJRNL,'CCAJRNL.FILE',0
// EXTENT SYS001,SYSWK1,,,1000,390
// TLBL CCARF,'CCAJRNL.BACKUP'
// ASSGN SYS005,X'300'
// EXEC UTILJ,SIZE=AUTO
REPORT=2,
FROMTIME=120513,TOTIME=130513
EOF
/*
/&


====CMS UTILJ example====

Use the UTILJ EXEC procedure to run the UTILJ utility under CMS:
UTILJ destination dsn mode (FROMTIME 120513 TOTIME 130513

Where:
<ul>
<li>destination specifies the location of the print report where T=user terminal, and D = user A-DISK. A-DISK is the default. The report appears on the disk as:
UTILJ NEWLST A
</li>

<li>dsn is the data set name. For z/OS format data sets, the DSN is specified with spaces instead of periods between the qualifiers. A z/OS format journal data set is specified in the FILEDEF with spaces between the qualifiers. For CMS files, the DSN is specified as file name and filetype.</li>

<li>mode specifies the access mode of the disk containing the journal file to be processed.</li>
</ul>

For tape files, the DSN and MODE parameters are replaced by the keyword TAPE. Tape files also require issuing a FILEDEF (and a LABELDEF, if necessary) for the checkpoint data set before issuing the UTILJ command. For example:
FILEDEF CCAJRNL TAP1 SL VOLID 12345 (RECFM U LRECL 0 BLKSIZE 6176
LABELDEF CCAJRNL standard labeldef parameters
UTILJ D TAPE (FROMTIME 120513 TOTIME 130513


==Using UTILJ to analyze problems==

UTILJ lets you dump records from CCAJRNL for ease in debugging problems. If you call Technical Support for assistance in debugging problems, you may be asked to run JCL similar to the following.
//UTILJ EXEC PGM=UTILJ,PARM='FROMTIME=123500,TOTIME=124500'
//STEPLIB DD DISP=SHR,DSN=xxxxxxxxxx.LOADLIB
//SYSUDUMP DD SYSOUT=*
//CCAPRINT DD SYSOUT=*
//CCAJRNL DD DISP=SHR,DSN=xxxxxxx.CCAJRNL
//CCAOUT DD DSN=xxxxxxxxxx.CCAOUT,
// DISP=(NEW,CATLG,CATLG),UNIT=3390,
// SPACE=(TRK,(500,100),RLSE)
//


===Defining CCAOUT for additional diagnostics===

You can allocate a CCAOUT DD in z/VM or z/OS. The CCAOUT data set that is created makes it easy for developers and/or Technical Support to inspect journal data.

When CCAOUT is specified, only the date and time option pairs — FROMDATE/TODATE and FROMTIME/TOTIME are valid for controlling data into CCAOUT. If the FROMTIME/TOTIME parameters are used to limit the number of journal records extracted, the CCAOUT data set will typically be much smaller than the CCAJRNL data set.

If CCAOUT is specified, journal records are not written to CCAPRINT. Journal records are unblocked and written individually to CCAOUT in hexadecimal format. Allocate a CCAOUT DD only when you are selecting a subset of a journal for subsequent UTILJ or recover processing by Rocket Software.

To extract a single file's worth of entries from a larger journal, specify the <code>FILENAME=filename</code> option for UTILJ. This option selects all journal records that are associated with filename for copying into the CCAOUT DD.

==Using the MERGEJ utility==

===Merging overlapping journal files===

The MERGEJ utility, available in z/OS, z/VSE, and z/VM environments, is used to merge journals produced by different <var class="product">Model 204</var> runs into a single file. Journals created by jobs that ran concurrently and journals that do not contain EOF markers must be merged before being used as input for a media recovery run. (For information on the creation of EOF markers, see the [[#Using the UTILJ utility|Using the UTILJ utility]] section). 

Journal files run against MERGEJ can be individual files or the output of a previous MERGEJ run.
Note: Journals that do not overlap do not need to be merged. In this case, the individual journals can be concatenated for input to recovery and MERGEJ would not be required.

===MERGEJ support for journal types===

The MERGEJ utility can determine the journal type being merged. If the data set type is unknown, MERGEJ sets a return code of 2 and issues the following warning message. 
*** WARNING: UNKNOWN DATASET TYPE: PLEASE SPECIFY TYPE VIA PARAMETER SETTING OF JRNL, JLOG OR BOTH.


A merged journal may contain audit information (CCAJLOG) and/or recovery (CCAJRNL) information. A data set containing only:
<ul>
<li>Recovery information cannot be used with AUDIT204. </li>

<li>A data set containing only messages and audit information cannot be used for REGENERATE or RESTART.</li>
</ul>

If the MERGEJ utility attempts to use CCAJRNL or CCAJLOG data sets that are not the first data set for each DD respectively (such as, GDG members for CCAJRNL that are the fourth, sixth, and so on, data sets), the initial record is not present and the type of data, JRNL or JLOG, cannot be determined. The MERGEJ utility terminates with a return code of 2 indicating unknown data set type.

To inform the MERGEJ utility as to the type of data to be processed set the PARM parameter to <code>JRNL</code>, <code>JLOG</code>, or <code>BOTH</code>. For example, in z/OS specify: 
EXEC PGM=MERGEJ,PARM=BOTH


====Examining PARM arguments====

The "Return codes from Merge/Audit/Regen" table below shows what happens with various combinations of the PARM value on the MERGEJ job and the types of input (JLOG and/or JRNL). Following the "Return codes from Merge/Audit/Regen" table, the messages listed in the Message column are fully expanded. The value of the PARM statement (using <code>BOTH</code>, <code>JRNL</code>, or <code>JLOG</code>) is how the merged journal is marked. 
<ul>
<li>A merged journal marked as <code>BOTH</code> can be read by both Audit204 and REGEN.</li>

<li>A merged journal marked as <code>JRNL</code> and used as input to Audit204 always gets a return code of 20 and message:
M204.2515: NON-MESSAGE DATASET IS INVALID FOR CCAJRNL.
</li>

<li>A merged journal marked as <code>JLOG</code> and used as input to regenerate always gets a return code of 4 and message:
M204.2515: MESSAGES ONLY DATASET IS INVALID FOR CCAGEN
</li>
</ul>
<table>
<caption>Return codes from Merge/Audit/Regen</caption>
<tr class="head">
<th> </th>
<th>PARM</th>
<th>INPUT</th>
<th>M</th>
<th>A</th>
<th>R</th>
<th>Step</th>
<th>Message</th>
</tr>

<tr>
<td>A</td>
<td>BOTH </td>
<td>JLOG1/JRNL1</td>
<td align="right">0</td>
<td align="right">0</td>
<td align="right">0</td>
<td>R)</td>
<td>
Regenerated file updates from first run
</td>
</tr>

<tr>
<td>A1</td>
<td>BOTH </td>
<td>JLOG2/JRNL</td>
<td align="right">0</td>
<td align="right">0</td>
<td align="right">0</td>
<td>R)</td>
<td>
Regenerated file updates from first run
</td>
</tr>

<tr>
<td>B</td>
<td>BOTH </td>
<td>JLOG1/JLOG2</td>
<td align="right">2</td>
<td align="right">0</td>
<td align="right">4</td>
<td>M)</td>
<td>
** ...PARM=BOTH ... ONLY JLOG...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
2128: THERE WERE NO UPDATES TO FILE ...
</td>
</tr>

<tr>
<td>C</td>
<td>BOTH </td>
<td>JRNL1/JRNL2</td>
<td align="right">2</td>
<td align="right">0</td>
<td align="right">0</td>
<td>M)</td>
<td>
** ...PARM=BOTH ... ONLY JRNL...
</td>
</tr>

<tr>
<td>D</td>
<td>JRNL </td>
<td>JRNL1/JRNL2</td>
<td align="right">0</td>
<td align="right">20</td>
<td align="right">0</td>
<td>A)</td>
<td>
2515: NON-MESSAGE...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
Regenerated file updates from both runs
</td>
</tr>

<tr>
<td>E</td>
<td>JRNL </td>
<td>JLOG1/JLOG2</td>
<td align="right">2</td>
<td align="right">20</td>
<td align="right">4</td>
<td>M)</td>
<td>
** ...PARM=JRNL ... ONLY JLOG...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>A)</td>
<td>
2515: NON-MESSAGE...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
2128: THERE WERE NO UPDATES TO FILE ...
</td>
</tr>

<tr>
<td>F</td>
<td> JRNL </td>
<td>JLOG1/JRNL2</td>
<td align="right">2</td>
<td align="right">20</td>
<td align="right">4</td>
<td>M)</td>
<td>
** ...PARM=JRNL ... BUT ALSO JLOG...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>A)</td>
<td>
2515: NON-MESSAGE...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
1406: MISSING JOURNAL WAS DETECTED ...
</td>
</tr>

<tr>
<td>G</td>
<td>JLOG </td>
<td>JLOG1/JRNL2</td>
<td align="right">2</td>
<td align="right">0</td>
<td align="right">4</td>
<td>M)</td>
<td>
* ...PARM=JLOG ... BUT ALSO JRNL...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
2515: MESSAGES ONLY...
</td>
</tr>

<tr>
<td>G1</td>
<td>JLOG </td>
<td>JRNL1/JLOG2</td>
<td align="right">2</td>
<td align="right">0</td>
<td align="right">4</td>
<td>M)</td>
<td>
** ...PARM=JLOG ... BUT ALSO JRNL...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
2515: MESSAGES ONLY...
</td>
</tr>

<tr>
<td>H</td>
<td>JLOG </td>
<td>JLOG1/JLOG2</td>
<td align="right">0</td>
<td align="right">0</td>
<td align="right">4</td>
<td>R)</td>
<td>
2515: MESSAGES ONLY...
</td>
</tr>

<tr>
<td>I</td>
<td>JLOG </td>
<td>JRNL1/JRNL2</td>
<td align="right">2</td>
<td align="right">0</td>
<td align="right">4</td>
<td>M)</td>
<td>
** ...PARM=JLOG ... BUT ONLY JRNL...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
2515: MESSAGES ONLY...
</td>
</tr>

<tr>
<td>J</td>
<td>None</td>
<td>JRNL1/JLOG1</td>
<td align="right">0</td>
<td align="right">0</td>
<td align="right">0</td>
<td>R)</td>
<td>
Regenerated file using JRLN1
</td>
</tr>

<tr>
<td>K</td>
<td>None</td>
<td>JLOG1/JLOG2</td>
<td align="right">0</td>
<td align="right">0</td>
<td align="right">4</td>
<td>R)</td>
<td>
2515: MESSAGES ONLY...
</td>
</tr>

<tr>
<td>L</td>
<td>None</td>
<td>JRNL1/JRNL2</td>
<td align="right">0</td>
<td align="right">20</td>
<td align="right">0</td>
<td>A)</td>
<td>
2515: NON-MESSAGE...
</td>
</tr>

<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td>R)</td>
<td>
Regenerated file using JRNL1
</td>
</tr>
</table>

The complete messages listed in the the "Return codes from Merge/Audit/Regen" table, Message column: 
** WARNING: PARM=BOTH SPECIFIED BUT ONLY JLOG INPUT WAS FOUND.

** WARNING: PARM=JLOG SPECIFIED BUT ALSO JRNL INPUT WAS FOUND.

** WARNING: PARM=JRNL SPECIFIED BUT ONLY JLOG INPUT WAS FOUND.

M204.1406: MISSING JOURNAL WAS DETECTED BETWEEN dd mmm yyyy hh:mmth AND dd mmm yyyy hh:mmth FOR FILE filename

M204.2128: THERE WERE NO UPDATES TO FILE filename IN CCAGEN

M204.2515: NON-MESSAGE DATASET IS INVALID FOR CCAJRNL

M204.2515: MESSAGES ONLY DATASET IS INVALID FOR CCAGEN


===MERGEJ considerations===

Keep the following considerations in mind when using MERGEJ: 
<ul>
<li>If a previously merged file is combined with individual journal files, the merged file must be the first input file specified (SORTIN01).</li>

<li>When the MERGEJ utility is run, the following error conditions are detected:
<table>
<tr class="head">
<th>Error condition </th>
<th>MERGEJ behavior</th>
</tr>

<tr>
<td>Missing input journal file(s) </td>
<td>Terminates without performing a merge.</td>
</tr>

<tr>
<td>Missing output journal file </td>
<td>Terminates without performing a merge.</td>
</tr>

<tr>
<td>I/O error on input or output data sets </td>
<td>Terminates without performing a merge.</td>
</tr>

<tr>
<td>Merged journal used as input for other than the SORTIN01 data set (SORTIN1 for DOS) </td>
<td>Terminates without performing a merge.</td>
</tr>

<tr>
<td>Sequence error: a journal file not closed properly and the EOF marker is missing </td>
<td>Assumes the presence of an EOF marker and proceeds with processing.</td>
</tr>
</table></li>
</ul>

You cannot use streams as input to MERGEJ, with the exception of GDG streams — see [[#Using MERGEJ with GDG streams|Using MERGEJ with GDG streams]].

Use the COPY command to copy journal streams into individual data sets before using them as input to the MERGEJ utility. 

===Data sets required for the MERGEJ utility===

To run the MERGEJ utility, you must define the following data sets:
<ul>
<li>z/OS and CMS operating systems</li>

<li>SORTIN01 through SORTINnn, sequentially numbered, not to exceed SORTIN99 with Model 204 V7.8 and above or 32 for releases up to /including Model 204 V7.7, which define the journal files from the original updating <var class="product">Model 204</var> runs being recovered as input to the MERGEJ utility</li>

<li>SORTOUT to define the single output file</li>

<li>Standard IBM or IBM-compatible SORTLIB and SORTMSGS data sets </li>

<li>For the z/VSE operating system</li>

<li>SORTIN1 through SORTINn, sequentially numbered, not to exceed SORTIN9, which define the journal files from the original updating <var class="product">Model 204</var> runs being recovered as input to MERGEJ</li>

<li>SORTOUT to define the single output file</li>

<li>DLBL and LIBDEF statements pointing to the library and sublibrary containing the IBM or IBM-compatible SORT or MERGE program</li>
</ul>

Each SORTIN data set should represent the entire journal for a single job. For example, if Job1 creates Journal1, Journal2, and Journal3, and Job 2 creates Journal4, the following illustrates how the SORTIN data sets should be set up:
//SORTIN01 DD DSN=LOCAL.M204.JOURNAL1,DISP=SHR
// DD DSN=LOCAL.M204.JOURNAL2,DISP=SHR
// DD DSN=LOCAL.M204.JOURNAL3,DISP=SHR
//SORTIN02 DD DSN=LOCAL.M204.JOURNAL4,DISP=SHR


The following examples illustrate further operating system-specific considerations.

===z/OS MERGEJ example===
// EXEC PGM=MERGEJ
//STEPLIB DD DSN=LOCAL.M204.LOADLIB,DISP=SHR
//SORTLIB DD DSN=SYS1.SORTLIB,DISP=SHR
//SORTOUT DD DSN=LOCAL.M204.MERGED.JOURNAL.J840302,DISP=OLD
//SORTIN01 DD DSN=LOCAL.M204.JOURNAL.840301,DISP=SHR
//SORTIN02 DD DSN=LOCAL.M204.JOURNAL.840302,DISP=SHR


===z/VSE MERGEJ example===
// JOB MERGEJ
// DLBL M204LIB,'M204.PROD.LIBRARY'
// EXTENT ,volser
// LIBDEF PHASE,SEARCH=M204LIB.R210
// TLBL SORTOUT
// ASSGN SYS020,cuu
// DLBL SORTIN1,'M204.CCAJRNL.1',,SD
// EXTENT SYSnnn,balance of extent information
// DLBL SORTIN2,'M204.CCAJRNL.2',,SD
// EXTENT SYSnnn,balance of extent information
// TLBL SORTIN3
// ASSGN SYS023,cuu
// DLBL SORTIN4,'M204.CCAJRNL.4',,SD
// EXTENT SYSnnn,balance of extent information
// TLBL SORTIN5
// ASSGN SYS025,cuu
// TLBL SORTIN6
// ASSGN SYS026,cuu
// EXEC MERGEJ,SIZE=(AUTO,xxK)
/*
/&


===Using MERGEJ in z/VSE===

In z/VSE, use the MERGEJ utility:
<ul>
<li>If using tape for the SORTOUT or any of the SORTINx data sets, the SYS number is fixed.</li>

<li>You must set the SYS number of the SORTOUT data set to 020, for example:

// ASSGN SYS020,cuu
</li>

<li>You must set the SYS number of the SORTIN data set to 020 plus the number of the SORTIN data set. For example, <code>SORTIN1 = SYS021</code>, <code>SORTIN5 = SYS025</code>, and <code>SORTIN9 = SYS029</code>.</li>

<li>The <code>SIZE</code> parameter on the // EXEC card is mandatory. </li>

<li><code>AUTO</code> specification reserves storage for the MERGEJ program.</li>

<li><code>xxK</code> reserves storage for the SORT program, which is dynamically loaded during execution. To determine the amount of additional storage needed for the sort program, refer to the <var class="book">IBM SORT/MERGE Programmer's Guide</var> or equivalent manual if using a sort package other than IBM. </li>

<li>You can use conditional job control. The return code is set on the program termination.</li>
</ul>

===Using MERGEJ in CMS===

In CMS, the MERGEJ EXEC runs the MERGEJ utility. The command format is:
MERGEJ fileid / fileid / ... / outfileid

Where:
<ul>
<li><var class="term">fileid</var> specifies the file identifier and mode of a journal file.

A file identifier can be either the name of a data set on a variable-format disk or the name and type of a file on a CMS-format disk. If you specify a data set name, insert a white space to separate the qualifiers.
</li>

<li><var class="term">outfileid</var> is a CMS file that specifies the identifier and mode of the file that is to contain the merged journal file. </li>
</ul>

The <var>MERGEJ</var> command requires the availability of a dynamically invoked <var>SORT</var> command. The number of journal files that can be merged with one <var>MERGEJ</var> command is a function of the capacity of the SORT/MERGE utility used. For example:
MERGEJ JOURNAL F /JOURNAL F/ MERGED JOURNAL A


===Using MERGEJ with GDG streams===

If the journal is defined as a GDG stream in the Online run, each generation created during the run is considered only a part of the journal. The complete journal consists of all the generations that were produced during that run.

When you run MERGEJ, each SORTINnn DD should consist of a complete journal. For example, if the complete journal from the first run consists of generations 54 and 55 and the complete journal from the second run consists of generations 56 through 58, the following would be used as input to MERGEJ:
//* complete journal from Tuesday:
//SORTIN01 DD DISP=SHR,DSN=xxx.CCAJRNL.G0054V00
// DD DISP=SHR,DSN=xxx.CCAJRNL.G0055V00
//* complete journal from Wednesday:
//SORTIN02 DD DISP=SHR,DSN=xxx.CCAJRNL.G0056V00
// DD DISP=SHR,DSN=xxx.CCAJRNL.G0057V00
// DD DISP=SHR,DSN=xxx.CCAJRNL.G0058V00


[[Category:System management]]
[[Category:Recovery]]

RESTORE command

2024-08-15T22:55:08Z

Goff: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>File manager plus ad hoc updates
<dt>Function
<dd>Restores a <var class="product">Model 204</var> file from a dumped version of that file
</dl>

==Syntax==
RESTORE [option] FROM ddname [NBUFF I/Obuffers]


Where:
<table>
<tr>
<th>option</th>
<td>A decimal value. Options can be summed. The options are:
<table>

<tr class="head"> <th>Option</th>
<th>Meaning</th> </tr>

<tr> <th align="right"><var>128</var></th>
<td>The size of a file data set or the number of data sets in a file is being changed. </td> </tr>

<tr> <th align="right"><var>64</var></th>
<td>The name of a file is being changed.</td> </tr>
</table>
</td></tr>

<tr>
<th>ddname</th>
<td>The name of the data set from which the <var class="product">Model 204</var> file is being restored. If the <code>FROM ddname</code> clause points to a data set that was not created by the <var class="product">Model 204</var> <var>DUMP</var> command, the following error messages is issued:
M204.2711: <var class="term">ddname</var> IS NOT A DUMP DATASET, CANNOT RESTORE INTO <var class="term">ddname2</var>
</td>
</tr>
<tr>
<th>I/Obuffers</th>
<td>
Optionally sets the number of sequential I/O buffers RESTORE can use. For example:
RESTORE 192 FROM TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
</td>
</tr>
</table>

==Example==
OPEN CEN
M204.0620: FILE CEN OPENED
M204.1203: FILE CEN WAS LAST UPDATED ON hh:mm:ss
RESTORE 192 FROM DUMPCEN 
M204.0500: FILE CEN: RESTORING FROM DUMP OF 88.262 SEP 19 14.24.29
M204.1760: FILE CEN: RESTORE BEGINNING AT 14.29.06
M204.1761: FILE CEN: RESTORE COMPLETED AT 14.29.24


==Usage notes==
<ul>
<li>The <var>RESTORE</var> command restores a <var class="product">Model 204</var> file from a dumped version of that file. <var>RESTORE</var> takes a sequential data set produced by a <var>[[DUMP command|DUMP]]</var> command and turns it into a <var class="product">Model 204</var> file again.
Note: Before using the <var>RESTORE</var> (or <var>[[REGENERATE command|REGENERATE]]</var>) command, you need to have <var>DUMP</var> copies of the files. <var>DUMP</var> processing updates the file while making a backup copy (to a target media). Otherwise, when you do a media recovery using either <var>RESTORE</var> (which does not include journals) or <var>REGENERATE</var> (to include journals), the backup copy does not incorporate all updates, and you cannot detect this.</li>

<li>The <var>RESTORE</var> command can be issued only in file context. (That is, the current default must be a file, not a group.) The file must be opened with file manager privileges and privileges to update with ad hoc requests.</li>

<li>If an external security interface is active, the user ID issuing the command is checked for the proper data set usage authorization. If the authorization check fails, the attempt is logged as a security violation and the command is not executed. Under a security interface, you must have READ privileges to read a file specified by this command. For more information, refer to the [[:Category:Security interfaces|Security interfaces]] pages.</li>

<li>If a file is skewed, the file can only be transferred from one device type to another through the <var class="product">Model 204</var> DUMP/RESTORE facility. File skewing is an obsolete feature.</li>

<li>When <var>RESTORE</var> has finished processing, it automatically closes all private or semi-public files. Public files remain open.</li>

<li>When it processes <var>RESTORE</var>, <var class="product">Model 204</var> ends any [[File integrity and recovery#Update units and transactions|update unit]] in progress and begins a non-backoutable update unit. </li>

<li>After <var class="product">Model 204</var> starts to restore a file, it displays a message showing the date and time the file was dumped. [[File dumping and restoring]] discusses the <var>RESTORE</var> options, along with a full presentation of <var>DUMP</var>, <var>RESTORE</var>, and their use in moving, renaming, and changing the size of files.</li>

<li>Although the <var>DUMP</var> command copies the <code>FILE BROADCAST</code> message with the FPL, the <var>RESTORE</var> command leaves the current <var>[[BROADCAST command: Sending a file message|BROADCAST]]</var> message in the file. For example:</li>
OPEN FPLJUNK
BROADCAST FILE BROADCAST MESSAGE NUMBER ONE
DUMP TO DUMPFPL
OPEN FPLJUNK
BROADCAST FILE BROADCAST MESSAGE NUMBER TWO
RESTORE FROM DUMPFPL
OPEN FPLJUNK
<broadcast message number two> is displayed.
</li>
</ul>

[[Category: File manager commands]]
[[Category:Commands]]

DUMP command

2024-08-15T22:54:48Z

Goff: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>File manager
<dt>Function
<dd>Backs up a <var class="product">Model 204</var> file to a sequential data set
</dl>

==Syntax==
DUMP TO ddname [NBUFF I/Obuffers]


Where
<table>
<tr>
<th>ddname</th>
<td>Is the name of the sequential dataset to which the file is written.</td>
</tr>
<tr>
<th>I/Obuffers</th>
<td>
Optionally sets the number of sequential I/O buffers DUMP can use. For example:
DUMP TO TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
</td>
</tr>
</table>

===Syntax notes===
<var>DUMP</var> must be issued in file context (that is, the current default must be a file, not a group).

==Example==
OPEN PEOPLE
M204.0620: FILE PEOPLE OPENED
M204.1203: FILE PEOPLE WAS LAST UPDATED ON hh:mm:ss
DUMP TO DUMPPEOP
M204.1760: FILE PEOPLE: DUMP BEGINNING AT hh:mm:ss
M204.1761: FILE PEOPLE: DUMP COMPLETED AT hh:mm:ss
CLOSE PEOPLE


==Usage notes==
The <var>DUMP</var> command copies an open <var class="product">Model 204</var> file to a sequential data set that is located on either a magnetic tape or a direct access device. <var>DUMP</var> backs up a file so that the dumped version is available in case of a system or media failure. The dumped version can subsequently be restored using either the <var>[[RESTORE command|RESTORE]]</var> command or the <var>[[REGENERATE command|REGENERATE]]</var> command.
Note: Use the DUMP command before using either the REGENERATE or the RESTORE command. DUMP updates the file while making a backup copy (to a target media). Otherwise, when you do a media recovery using either REGENERATE (to include journals) or RESTORE (without journals), the backup copy does not incorporate all updates, but you cannot detect this.

If a file is skewed, the file can be transferred from one device type to another only through the <var class="product">Model 204</var> DUMP/RESTORE facility. File skewing is an obsolete feature.

Dump files can be accessed and updated during execution of the <var>DUMP</var> command. After the <var>DUMP</var> command has been issued, the <var>DUMP</var> waits until all existing transactions that might update the file are complete and the existing copy of the file is in a consistent state. At that point the <var>DUMP</var> begins. If a subsequent user request updates the file being dumped, preimages of database pages to be updated are dumped before the update is allowed. The dumped copy matches the state of the file at the time the <var>DUMP</var> begins.

If updates are not complete when the <var>DUMP</var> command for a file is issued, you receive a message that the file is still in use. The DUMP can be canceled at this juncture. If errors are detected during the file dump, the dump is ended. A message to this effect is displayed.

Job level enqueuing is not affected by this facility. A BATCH204 job cannot be started to dump files that are being updated in another <var class="product">Model 204</var> job. Use of the <var>DUMP</var> command from any <var class="product">Model 204</var> job requires exclusive access to the file by that copy of <var class="product">Model 204</var>.

If an external security interface is active, the user ID issuing the command is checked for the proper data set usage authorization. If the authorization check fails, the attempt is logged as a security violation and the command is not executed. 

With a security interface, you must have <var>WRITE</var>, <var>ALTER</var>, or <var>UPDATE</var> privileges to use the DUMP command with sequential data sets. For more information, refer to the [[:Category:Security interfaces|Security interfaces]] pages. 

When it processes <var>DUMP</var>, <var class="product">Model 204</var> ends any [[File integrity and recovery#Update units and transactions|update unit]] in progress and begins a non-backoutable update unit. 

The <var>DUMP</var>, <var>RESTORE</var>, and <var>REGENERATE</var> commands and their use in dumping, restoring, and regenerating files are explained in [[File dumping and restoring]] and [[Media recovery]].

[[Category: File manager commands]]
[[Category:Commands]]

REGENERATE command

2024-08-14T23:14:19Z

Goff: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>User 0
<dt>Function
<dd>In the event of a media failure, for example, a disk head crash, a REGENERATE command recovers a <var class="product">Model 204</var> file by reapplying some or all of the updates that have been made to the file since the time of the last dump.
</dl>
==Syntax==
REGENERATE FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th]
| LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th
| CHECKPOINT yy.ddd hh:mm:ss.th}]

For more than one file, specify REGENERATE only once; the remaining syntax is repeated for each file.

Where:
<ul>
<li>
<var class="term">filename</var> is the name of a <var class="product">Model 204</var> file that is one to eight characters long.
</li>

<li>
A FROM clause determines whether or not REGENERATE processing performs a restore: 
<ul>
<li>
If a FROM clause is present for a file, REGENERATE processing restores that file from the <var class="product">Model 204</var> dump specified in the clause.
</li>

<li>
If a FROM clause is not present for a file, REGENERATE processing assumes that the file was previously restored. 
</li>
</ul>
</li>

<li>
<var class="term">dumpname</var> is the ddname of the dumped file, one to eight characters long, from which to recover.
</li>

<li>
<var>IGNORE</var> lets REGENERATE processing bypass the file parameter list (FPL) update timestamps, so you can run REGEN processing with one CCAGEN at a time, instead of requiring you to concatenate the CCAGEN files.
</li>

<li>
The TO clause options listed in the table below identify the stopping point:
<table>

<tr class="head"> <th>
Option
</th> <th>
Applies updates to the file up to...
</th> </tr>

<tr> <th><var>LAST UPDATE</var></th> <td>All. This is the default. </td> </tr>

<tr> <th><var>LAST CHECKPOINT</var></th>
<td>Last checkpoint on the input journal.
</td> </tr>

<tr> <th nowrap><var>UPDATE number OF id</var></th> <td>And including the update specified by number and id. The ID is the date/time stamp from the END OF UPDATE message, specified in the form: yy.ddd hh:mm:ss.th.</td> </tr>

<tr> <th><var>CHECKPOINT id</var></th>
<td>Specified checkpoint. The ID is specified in the form: yy.ddd hh:mm:ss.th. </td> </tr>
</table>
</li>

<li>
A BEFORE clause specifies a nonspecific stopping point. The BEFORE clause is an alternative to specifying an exact checkpoint ID or update unit number and ending date and time from an audit trail.
If you specify a BEFORE clause, Pass One of REGENERATE processing determines the last complete update or checkpoint before the time specified. Pass Two of REGENERATE processing stops reapplying file updates when it reaches the stopping point identified in Pass One. 
</li>
</ul>
===Syntax notes===
When multiple files are regenerated, each file must be specified on a separate line. The line can begin in any column. The END keyword indicates the end of the list of files.

==Examples==
REGENERATE FILE DB1 FROM DUMPDB1
REGEN FILE DB1 FROM DUMPDB1 TO LAST UPDATE
REGEN FILE DBAUDIT FROM DUMP01 TO LAST -
CHECKPOINT
REGEN FILE DB1 FROM DUMPDB2 TO UPDATE 3 -
OF 88.216 06:28:42.98
REGEN FILE MODFILE FROM DUMPMOD TO -
CHECKPOINT 88.216 01:05:22.99
REGEN
FILE DB1 FROM DUMPDB1 TO LAST CHECKPOINT
FILE DB2 FROM DUMPDB2
FILE DB3 FROM DUMPDB3 TO UPDATE 5 OF -
88.008 05:19:41.27
END

Note: Blank lines are not valid between the REGENERATE and END command.
REGEN FILE ABC FROM DUMPABC /* First run */
.
.
REGEN FILE ABC IGNORE /* A later run */


==Usage notes==
The REGENERATE command lets the system manager use the <var class="product">Model 204</var> media recovery feature to regenerate one or more files. A REGENERATE command is issued in case of a loss of storage integrity caused by a hard system error such as a disk head crash.
The algorithm for identifying starting points, used whether or not a FROM clause is present, is to find the first start of an update unit with a time greater than the last updated time of the file being processed. 
If REGENERATE processing opens a file for which it is not performing a restore, and if that file is marked physically inconsistent, REGENERATE processing for that file is discontinued.
When it processes REGENERATE, <var class="product">Model 204</var> ends any update unit in progress and begins a no-back out-allowed update unit. For more information about <var class="product">Model 204</var> update units, see [[File_integrity_and_recovery#Update_units_and_transactions|Update units and transactions]].
For a single-user (batch) <var class="product">Model 204</var> run, specify a REGENERATE command on User 0's command line. REGENERATE need not be the first command issued. You can intermix User Language procedures and other batch functions with REGENERATE commands.
====Using the IGNORE option====
For example, providing the first journal the first REGEN command might be
REGEN FILE ABC FROM DUMPABC

A second run may provide the second journal and specify: 
REGEN FILE ABC IGNORE

The second run begins where the previous REGEN processing ended and applies the second journal updates.
Note: If you omit a journal, <var class="product">Model 204</var> does not report this to you. Therefore, use the IGNORE option with care.
====Using the TO UPDATE option====
You can specify the TO UPDATE option for a single or multiple file run.
If TO UPDATE <var class="term">nn</var> OF <var class="term">id</var> is specified, it must appear only on the first FILE statement, and no other ‘TO’ options are allowed on subsequent files.
(In Model 204 version 7.6, the new message: <code>M204:1664 "TO UPDATE" only allowed on first line of REGENerate</code> appears any time more than one TO UPDATE is specified, or if TO UPDATE is specified on a line other than the first.)
All additional files are recovered as though they each specified the same 'TO UPDATE' option. The <var class="term">id</var>' timestamp is the END OF TRANSACTION timestamp. Once the 'end of transaction' is reached, further processing stops, all inflight transactions are backed out, and RC=0 is set.

If the update is not found in the journal, then the run stops immediately after pass 1. RC=4 is set. This message is displayed for each file: 
M204.1409: MISSING STOPPING POINT FOR FILE <var class="term">filename</var>
And this message is also displayed:
M204.1435: Error during regenerate

====Using REGENERATE with multiple files====
The number of files you can regenerate in a single run depends upon the settings of these parameters: [[NDIR parameter|NDIR]] (number of directory entries) and [[NFILES parameter|NFILES]] (number of file areas).

[[Category:Commands]]

REGENERATE command

2024-08-14T23:13:30Z

Goff: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>User 0
<dt>Function
<dd>In the event of a media failure, for example, a disk head crash, a REGENERATE command recovers a <var class="product">Model 204</var> file by reapplying some or all of the updates that have been made to the file since the time of the last dump.
</dl>
==Syntax==
REGENERATE [FROM ddname] FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th]
| LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th
| CHECKPOINT yy.ddd hh:mm:ss.th}]

For more than one file, specify REGENERATE only once; the remaining syntax is repeated for each file.

Where:
<ul>
<li>
<var class="term">filename</var> is the name of a <var class="product">Model 204</var> file that is one to eight characters long.
</li>

<li>
A FROM clause determines whether or not REGENERATE processing performs a restore: 
<ul>
<li>
If a FROM clause is present for a file, REGENERATE processing restores that file from the <var class="product">Model 204</var> dump specified in the clause.
</li>

<li>
If a FROM clause is not present for a file, REGENERATE processing assumes that the file was previously restored. 
</li>
</ul>
</li>

<li>
<var class="term">dumpname</var> is the ddname of the dumped file, one to eight characters long, from which to recover.
</li>

<li>
<var>IGNORE</var> lets REGENERATE processing bypass the file parameter list (FPL) update timestamps, so you can run REGEN processing with one CCAGEN at a time, instead of requiring you to concatenate the CCAGEN files.
</li>

<li>
The TO clause options listed in the table below identify the stopping point:
<table>

<tr class="head"> <th>
Option
</th> <th>
Applies updates to the file up to...
</th> </tr>

<tr> <th><var>LAST UPDATE</var></th> <td>All. This is the default. </td> </tr>

<tr> <th><var>LAST CHECKPOINT</var></th>
<td>Last checkpoint on the input journal.
</td> </tr>

<tr> <th nowrap><var>UPDATE number OF id</var></th> <td>And including the update specified by number and id. The ID is the date/time stamp from the END OF UPDATE message, specified in the form: yy.ddd hh:mm:ss.th.</td> </tr>

<tr> <th><var>CHECKPOINT id</var></th>
<td>Specified checkpoint. The ID is specified in the form: yy.ddd hh:mm:ss.th. </td> </tr>
</table>
</li>

<li>
A BEFORE clause specifies a nonspecific stopping point. The BEFORE clause is an alternative to specifying an exact checkpoint ID or update unit number and ending date and time from an audit trail.
If you specify a BEFORE clause, Pass One of REGENERATE processing determines the last complete update or checkpoint before the time specified. Pass Two of REGENERATE processing stops reapplying file updates when it reaches the stopping point identified in Pass One. 
</li>
</ul>
===Syntax notes===
When multiple files are regenerated, each file must be specified on a separate line. The line can begin in any column. The END keyword indicates the end of the list of files.

==Examples==
REGENERATE FILE DB1 FROM DUMPDB1
REGEN FILE DB1 FROM DUMPDB1 TO LAST UPDATE
REGEN FILE DBAUDIT FROM DUMP01 TO LAST -
CHECKPOINT
REGEN FILE DB1 FROM DUMPDB2 TO UPDATE 3 -
OF 88.216 06:28:42.98
REGEN FILE MODFILE FROM DUMPMOD TO -
CHECKPOINT 88.216 01:05:22.99
REGEN
FILE DB1 FROM DUMPDB1 TO LAST CHECKPOINT
FILE DB2 FROM DUMPDB2
FILE DB3 FROM DUMPDB3 TO UPDATE 5 OF -
88.008 05:19:41.27
END

Note: Blank lines are not valid between the REGENERATE and END command.
REGEN FILE ABC FROM DUMPABC /* First run */
.
.
REGEN FILE ABC IGNORE /* A later run */


==Usage notes==
The REGENERATE command lets the system manager use the <var class="product">Model 204</var> media recovery feature to regenerate one or more files. A REGENERATE command is issued in case of a loss of storage integrity caused by a hard system error such as a disk head crash.
The algorithm for identifying starting points, used whether or not a FROM clause is present, is to find the first start of an update unit with a time greater than the last updated time of the file being processed. 
If REGENERATE processing opens a file for which it is not performing a restore, and if that file is marked physically inconsistent, REGENERATE processing for that file is discontinued.
When it processes REGENERATE, <var class="product">Model 204</var> ends any update unit in progress and begins a no-back out-allowed update unit. For more information about <var class="product">Model 204</var> update units, see [[File_integrity_and_recovery#Update_units_and_transactions|Update units and transactions]].
For a single-user (batch) <var class="product">Model 204</var> run, specify a REGENERATE command on User 0's command line. REGENERATE need not be the first command issued. You can intermix User Language procedures and other batch functions with REGENERATE commands.
====Using the IGNORE option====
For example, providing the first journal the first REGEN command might be
REGEN FILE ABC FROM DUMPABC

A second run may provide the second journal and specify: 
REGEN FILE ABC IGNORE

The second run begins where the previous REGEN processing ended and applies the second journal updates.
Note: If you omit a journal, <var class="product">Model 204</var> does not report this to you. Therefore, use the IGNORE option with care.
====Using the TO UPDATE option====
You can specify the TO UPDATE option for a single or multiple file run.
If TO UPDATE <var class="term">nn</var> OF <var class="term">id</var> is specified, it must appear only on the first FILE statement, and no other ‘TO’ options are allowed on subsequent files.
(In Model 204 version 7.6, the new message: <code>M204:1664 "TO UPDATE" only allowed on first line of REGENerate</code> appears any time more than one TO UPDATE is specified, or if TO UPDATE is specified on a line other than the first.)
All additional files are recovered as though they each specified the same 'TO UPDATE' option. The <var class="term">id</var>' timestamp is the END OF TRANSACTION timestamp. Once the 'end of transaction' is reached, further processing stops, all inflight transactions are backed out, and RC=0 is set.

If the update is not found in the journal, then the run stops immediately after pass 1. RC=4 is set. This message is displayed for each file: 
M204.1409: MISSING STOPPING POINT FOR FILE <var class="term">filename</var>
And this message is also displayed:
M204.1435: Error during regenerate

====Using REGENERATE with multiple files====
The number of files you can regenerate in a single run depends upon the settings of these parameters: [[NDIR parameter|NDIR]] (number of directory entries) and [[NFILES parameter|NFILES]] (number of file areas).

[[Category:Commands]]

File size calculation in detail

2024-06-11T22:06:18Z

Goff: /* Computing the file size multiplier (N) */

<div class="toclimit-3">
==Overview==

Trying to do a precise file size for a Model 204 file is difficult because:
<ul>
<li>The flexibility of Model 204 makes the knowledge of the detail needed unlikely

<li>During the application design process, it is highly likely that the data structures and field attributes will change

<li>Model 204 performs so well that there is no advantage to having such precise sizes
</ul>


Rocket Software recommends a more flexible, ad-hoc approach, as discussed in [[File sizing introduction]].

What follows is detail which is unlikely ever to be done more than once by a file manager. That said, the detail provided is useful and may be referred to to help in the ad-hoc design approach.

==The detailed design process==

After choosing the fields and field attributes for a file, you need to calculate how much disk space the file requires and then to allocate the space. After being calculated, the values of file parameters are set when the file is created. Before you can calculate the space, you need to know:
<ul>
<li>Types of fields in the input data for the file (such as ORDERED or FRV)</li>
<li>Number of fields that the average record contains</li>
<li>Number of records you expect to be in file</li>
</ul>

Use this information to calculate the file parameters, and then use the file parameters to calculate the expected disk space. 

This topic contains:
<ul>
<li>Detailed instructions to help you calculate the file parameters and disk space</li>
<li>Information about allocating disk space for your operating system </li>
<li>Complete space estimation example using the steps shown in the first section of this topic </li>
<li>Space calculation and file parameter worksheets to help you calculate file sizes for your data.</li>
</ul>

This topic shows you how to find the total number of <var class="product">Model 204</var> pages you need for a file, that is, to resolve the following equation:
Number of pages = ASIZE + BSIZE + CSIZE + DSIZE + ESIZE + XSIZE + 8

Note: The <var class="product">Model 204</var> Dictionary/204 FILEMGMT subsystem facility can automatically calculate file spacing allocations, as described in [[ Managing file and table size with FILEMGMT#File sizing overview|File sizing overview]].

===Testing your file design===

The detail of the process still necessitates that the final sizing be validated. You should still load a representative sample of your records into a test file (and, for larger files, at least one segment's worth). This allows you to test the accuracy of space calculations and parameter settings before loading the entire file. 

===Using constants===

Many of the formulas used to calculate parameters contain a constant (for example, 1.1 in the formula for ATRPG) multiplied by an expression. The constants generally allow for inaccuracies in knowledge about data in the file and for file expansion. If you know in advance what values are going to be stored, and that the amount of data in the file will remain static, you can reduce the multipliers (to a minimum value of 1).

====Model 204 usable page size constant====

The standard <var class="product">Model 204</var> page size is 6184 bytes. Although <var class="product">Model 204</var> has accepted other page sizes in previous releases (to accommodate hardware no longer supported by IBM), the 6184-byte size is currently the only valid page size. Therefore, the calculation for usable page size is:
6184 - 40 = 6144


==Sizing Table A==

Table A is an internal file dictionary in which character strings and their corresponding codes are recorded. Table A contains the following information:
<table>
<tr class="head">
<th>This section</th>
<th>Contains... </th>
</tr>

<tr>
<td>Attribute</td>
<td>Field names of all fields in the file.</td>
</tr>

<tr>
<td nowrap>FEW-VALUED</td>
<td>Character string values of all fields with the FEW-VALUED field attribute, and either the CODED attribute or the FRV (for-each-value) attribute. Values for fields that have both the CODED and FRV attributes appear only once, as do values used for more than one field. </td>
</tr>

<tr>
<td nowrap>MANY-VALUED</td>
<td>Character string values of all fields that have the MANY-VALUED attribute and either the CODED attribute or the FRV attribute. </td>
</tr>
</table>

The Table A parameters you need as part of the total <var class="product">Model 204</var> number of pages are as follows: 
<table>
<tr class="head">
<th>This attribute</th>
<th>Specifies the number of Table A...</th>
</tr>

<tr>
<td>ATRPG</td>
<td>Attribute pages </td>
</tr>

<tr>
<td>FVFPG</td>
<td>FEW-VALUED pages</td>
</tr>

<tr>
<td>MVFPG</td>
<td>MANY-VALUED pages</td>
</tr>
</table>

ASIZE, the total size of Table A, is calculated by <var class="product">Model 204</var>.

After it has been allocated, Table A cannot be expanded. However, because Table A is always small in relation to the rest of the file, be generous when allocating space.

===Computing ASTRPPG (character strings per Table A page)===

Before you can compute the Table A parameters, you need to know ASTRPPG, which is the number of character strings per Table A page. First, estimate the average length (L) of all character strings you will store in Table A. After you compute L, you can compute ASTRPPG.

====Computing L (the length of each string)====

In computing L, the length of each string must include system overhead. Increase the basic character string lengths using the following rules: 
<ol>
<li>For each CODED or FRV value, add 3 bytes. </li>
<li>For each field name, regardless of attributes, add 2 bytes. In addition:</li>
<ul>
<li>If the field has any of the following attributes, add 1 more byte: OCCURS, LEVEL, FLOAT, UPDATE IN PLACE, or ORDERED. </li>
<li>If the field is OCCURS, add 2 more bytes.</li>
<li>If the field is LEVEL, add 1 more byte.</li>
<li>If the field is FLOAT, add 1 more byte.</li>
<li>If the field is ORDERED, add 4 more bytes.</li>
<li>If the field is UNIQUE, add 1 more byte. </li>
<li>If the field is NUMERIC RANGE, it requires a number of auxiliary field names. For each NUM RANGE field, add:
((4 + field_name_length) * (# of digits of the longest value + 3)) bytes
</li>
</ul>
<li>Next, examine the data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Represents...</th>
</tr>

<tr>
<td>A</td>
<td>Number of field names</td>
</tr>

<tr>
<td>B</td>
<td>Number of FEW-VALUED FRV or FEW-VALUED CODED values</td>
</tr>

<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or MANY-VALUED CODED values</td>
</tr>

<tr>
<td>D </td>
<td>Maximum number of digits in a NUM RANGE field + 3</td>
</tr>

<tr>
<td>S </td>
<td>Sum of all D's for all NUMERIC RANGE fields</td>
</tr>

<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C</td>
</tr>

<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or FEW-VALUED CODED value and value overhead</td>
</tr>

<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or MANY-VALUED CODED values and value overhead</td>
</tr>

<tr>
<td>N</td>
<td>Space needed by field names and names overhead</td>
</tr>
</table>
</li>

<li>Then, compute L, where:
L = (V + N + W) / T
</li>
</ol>

====Computing ASTRPPG (character strings per Table A page)====

After you have estimated the length of the average character string for this file, you can compute ASTRPPG as follows:
ASTRPPG = 6144 / L


The default value of ASTRPPG is 400, which corresponds to an average string length plus overhead of 15 bytes.

===Computing ATRPG (the number of attribute pages)===

ATRPG specifies the number of pages to be assigned to the attribute section of Table A. Compute ATRPG as follows:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>N </td>
<td>Total amount of space consumed by field names</td>
</tr>

<tr>
<td>A </td>
<td>Number of field names</td>
</tr>

<tr>
<td>S </td>
<td>Number of extra NUMERIC RANGE fields (as computed above for ASTRPPG)</td>
</tr>
</table>

Next, compute the following equations:
ATRPG = 1.1 * (N / 6144 - (ASTRPPG * 2) - 2) )

ATRPG = 1.1 * (A + S) / ASTRPPG


Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for ATRPG.

ATRPG has a default value of 1 (its minimum value), which allows as many as 400 field names when the default value of ASTRPPG (400) is also used. 

====ATRPG multiplier====

The multiplier of 1.1 in the ATRPG formula allows room for adding field names that were not originally part of the file, as well as for redefining field names. When the REDEFINE command is used, one or two bytes can be added to or deleted from a Table A entry, if the LEVEL or UPDATE option is changed. The amount of overhead required for a redefined field is computed according to the rules for the original definition (see ASTRPPG above). When you delete a field definition, all but two bytes are made available for reuse. 

If you are sure that field names will not be added to a file, you can use a multiplier closer to 1. The size of the multiplier is important if ATRPG comes out to be just over one page. A one-page attribute section of Table A provides much better performance than a multiple-page section. This performance difference can be seen in the amount of disk I/O required to compile a User Language request or [[Media:M204 HLIReference V75.pdf|Host Language Interface]] call that refers to many fields. 
Note:
The product of ATRPG and ASTRPPG must not exceed 4000.

===Computing FVFPG (the number of FEW-VALUED pages)===

FVFPG specifies the number of pages to be assigned to the FEW-VALUED section of Table A. The number of FEW-VALUED pages depends upon the total number of distinct values to be taken on by the various FEW-VALUED fields that are either CODED or FRV. 

Examine your data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>V </td>
<td>Total amount of space consumed by FEW-VALUED fields.</td>
</tr>

<tr>
<td>B </td>
<td>Number of FEW-VALUED values (as computed for ASTRPPG). </td>
</tr>
</table>
FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

FVFPG = 1.2 * B / ASTRPPG


Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for FVFPG. FVFPG must not exceed 65,535. FVFPG has a default value of 1, which is its minimum value. Even if the file has no FEW-VALUED fields, set FVFPG to 1 to avoid error conditions caused by incorrect or unforeseen field definitions in the future.

Like the attribute section of Table A, the FEW-VALUED section is most effective when it is very small. The value sections of Table A are accessed most heavily by retrieving or updating CODED fields. CODED fields are retrieved as a result of User Language PRINT and arithmetic statements or IFGET calls. 

====Keeping FVFPG small====

If FVFPG is larger than two pages, you might want to reevaluate the choice of FEW-VALUED fields to reduce the number of distinct values. If you cannot reduce the number of distinct values, try to redesign the FEW- and MANY-VALUED sections of Table A so that one of the sections is one page, if possible. Sometimes moving a field from one section to the other can reduce the size of one section to less than a page. 

===Computing MVFPG (the number of MANY-VALUED pages)===

MVFPG specifies the number of pages to be assigned to the MANY-VALUED section of Table A. The number of MANY-VALUED pages depends upon the total number of distinct values to be taken on by the various MANY-VALUED fields that are either CODED or FRV. 

Examine your data to estimate the following:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>W</td>
<td>Total amount of space consumed by MANY-VALUED fields</td>
</tr>

<tr>
<td>C</td>
<td>Number of MANY-VALUED values (as computed for ASTRPPG) </td>
</tr>
</table>
MVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)

MVFPG = 1.2 * B / ASTRPPG


Round up to the nearest integer and use the <var class="term">larger</var> of the two numbers for MVFPG. MVFPG must not exceed 65,535. MVFPG has a default value of 1, which is its minimum value.

As discussed in the preceding description of FVFPG, <var class="product">Model 204</var> achieves the best performance when either the FEW-VALUED or MANY-VALUED section of Table A is small. If both MVFPG and FVFPG are larger than two pages, place most of the fields in one of the sections or the other so that either the FEW-VALUED section or the MANY-VALUED section is one page.

===ASIZE (Table A size)===

ASIZE is calculated by <var class="product">Model 204</var> and is the sum of the ATRPG, MVFPG, and FVFPG parameters. Because each of these parameters has a default value of 1, the default value of ASIZE is 3. 

==Sizing Table B==

Table B consists of either the full logical records-a base record, plus extension(s) (that contain the values of all VISIBLE fields), or if Table X is enabled, the visible fields in the base record. This section discusses Table B by itself, and the Table X impact is discussed in the next section.

Either way, to size the data are correctly, you need a good idea of what an average record will look like after all of the data has been loaded. More precisely, you need to know, <var class="term">for each record type in the file</var>:
<ul>
<li>Number of fields in the average record</li>
<li>Number of records </li>
</ul>

When calculating Table B space, remember that some fields can be missing entirely in some records and can occur more than once in others. 

To calculate the total disk space you need for a file, you need to know the size of Table B: the BSIZE parameter. To calculate BSIZE, you need:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>R</td>
<td>Average record size</td>
</tr>

<tr>
<td>BRECPPG</td>
<td>Number of records per Table B page</td>
</tr>
</table>

Instructions for calculating these parameters are discussed in this section.

====Estimating space for hash key files====

The method for calculating Table B space is the same for all file organizations. Because Table B cannot be expanded in a hash key file, Table B calculations for hash key files must be based on the total number of records that the file will ultimately contain. The final count of records is less critical for ordinary and sorted Table B organizations. Refer to the pages on sorted and hash key files, [[Sorted files]] and [[Hash key files]], respectively, for the settings of the FILEORG, BPGPMSTR, BPGPOVFL, and BEXTOVFL parameters.

====Achieving the best performance====

<var class="product">Model 204</var> achieves the fullest use of Table B space when different record types are uniformly distributed on each Table B page. Uniformly distributing record types also increases retrieval speed when related records of different types are processed together.

===Storing records on Table B pages===

The following conditions must be met before a new record is stored on a Table B page:
<ul>
<li>Record number must be available. </li>

<li>Basic record overhead must be available without using any reserved space. In a sorted or hash key file, the sort or hash key, unless it is preallocated, must also fit without using the reserved space.</li>

<li>If any fields are preallocated, the space for all such fields must be available on the page. Preallocated fields can extend into reserved space. </li>
</ul>

===Computing R (the average record size)===

Before calculating BSIZE, you need to compute <var>R</var>, the Table B space required for the average record, according to these rules:
<ol>
<li>Start with five bytes of basic overhead for the record (or eight bytes for overflow records in sorted files).</li>

<li>Ignore any field that has the INVISIBLE attribute.</li>

<li>Compute the space needed for non-preallocated fields (fields that do <var class="term">not</var> have an OCCURS clause) as follows:
<ul>
<li>For each compressible occurrence of each BINARY field, add six bytes. Leading zeros or nonnumeric characters override the compress option.</li>
<li>For each occurrence of each CODED field, add six bytes. </li>
<li>For each occurrence of each NON-CODED field, add three bytes plus the average length of the values of that field. </li>
<li>For each occurrence of each FLOAT field, add two bytes plus the defined LENGTH for the values of that field. </li>
</ul></li>

<li>Compute the space needed for preallocated fields as follows:
<ul>
<li>For each CODED or BINARY field, add (4 * <var class="term">n</var>) bytes, where <var class="term">n</var> is the number of occurrences.</li>

<li>For each field defined with the LENGTH option (including FLOAT fields), add (<var class="term">m</var> * <var class="term">n</var>) bytes, where <var class="term">m</var> is the length and <var class="term">n</var> is the number of occurrences. </li>
</ul></li>

<li>Add 30 bytes for each occurrence of a non-preallocated BLOB or CLOB field descriptor. If the BLOB or CLOB field is preallocated, add 27 bytes for each occurrence of a BLOB or CLOB field descriptor.</li>
</ol>

The total number of bytes used by all preallocated fields in one record must be less than the page size and must leave space on the page for the basic record overhead.

===Computing BRECPPG (the number of records per Table B page)===

BRECPPG specifies the maximum number of logical records that <var class="product">Model 204</var> will store on one Table B page. Compute BRECPPG as follows:
BRECPPG = 1.1 * (6144 - 4) / R


BRECPPG has a default value of 256, which corresponds to an average record length of 26 bytes.

Calculating BRECPPG accurately is important, because it can affect the way storage is utilized in Tables B, C, and D, which in turn affects efficient <var class="product">Model 204</var> operation. If you estimate that fewer records fit on a page than actually do fit, you might waste a great deal of storage space (although the resulting unused space per page allows you to add new fields to existing records and, in hash key and unordered files, to create new records). 

By estimating that more records fit than actually do fit, performance can be adversely affected in two ways:
<ul>
<li>One or more extension records per page might be created. Extension records are described on [[#Computing BRESERVE (reserved Table B space)|Computing BRESERVE (reserved Table B space)]], the other parameter that affects their creation. </li>

<li>Record numbers might be wasted. Record numbers are assigned sequentially, starting with 0 for the first record on the first page of Table B. Each page has BRECPPG numbers allocated to it. If fewer than BRECPPG records actually fit on the page, the extra record numbers are wasted.

Wasted record numbers do not take space in Table B, but in certain cases they can affect inverted retrieval speeds and the sizes of Tables C and D. Wasted record numbers are a concern if they cause you to increase the size of the file size multiplier, described in [[#Tables C and D indexing structure|Tables C and D indexing structure]]. For small files (under 50,000 records), wasted record numbers have no effect. 
</li>
</ul>

===Computing BSIZE (Table B size)===

BSIZE specifies the number of pages to be assigned to Table B. Compute BSIZE using the following equation: 
BSIZE = 1.2 * Total-Number-of-Records / BRECPPG


Round the result up to an integer. You can change the value of BSIZE (except in a hash key file) with the INCREASE and DECREASE commands.

BSIZE has a default value of 5, which corresponds to 1280 record slots if the BRECPPG default is taken.

BSIZE cannot exceed 16,777,216, nor can the product of BRECPPG and BSIZE exceed 16,777,216, the maximum number of record slots. 

===Computing BRESERVE (reserved Table B space)===

BRESERVE reserves a number of bytes on each Table B page for the expansion of records on that page. <var class="product">Model 204</var> allows you to add fields to records virtually without limit. Reserved space is used for new fields, if it is available on the page. Otherwise, an extension record is created in the next available space in Table B. Thus, records are infinitely expandable, subject only to Table B space limitations (BSIZE). 

For example, suppose that an estimated six records fit on a 6144-byte page and reserved space is 17 bytes. If <var class="product">Model 204</var> has loaded five records that are each 1200 bytes long, it begins a sixth record on the same page because the amount of space left (144 bytes) is greater than the reserved space. Only the first few fields of the sixth record fit on the page. The extra fields are placed on another page in an extension record, which uses up another record number.

While extension records are transparent to the user, access to the fields in extensions can be much less efficient than access to fields contained in the basic portions of records. To avoid extension records during initial file loading, set BRESERVE to the average record length (<var>R</var>). That is:
BRESERVE = <var>R</var>


If, in the example above, you set reserved space to 1200, only five records are placed on the page. The fifth record begins with 1344 bytes remaining on the page. Fields are added, crossing the reserved space boundary, until the record is complete. The sixth record then begins on a new page, avoiding an extension record.

====Sizing BRESERVE to avoid extension records====

If all the records in the file are less than about 1000 bytes, set BRESERVE to the average record length. If you set BRESERVE to the maximum record length (and at least one complete record fits on each Table B page), <var class="product">Model 204</var> does not build extension records unless new fields are added or inserted, or variable-length fields are changed to be longer. 

For files in which you initially load skeleton records and add the bulk of the fields later, set BRESERVE to a value much higher than the average record length. You can reset BRESERVE after some or all of the records have been loaded.

Too many extension records can have a serious negative impact on performance. However, for very large records, or for files in which the size of records varies dramatically, you might need to have some extension records and set BRESERVE to a smaller value.

The default value of BRESERVE is 17, which can be changed any time when the file is not being updated by another user. 

==Sizing Tables B and X==

===Creating a file with a Table X===

A file has Table X allocated when XSIZE greater than zero is designated at file create.

In the following example, when XSIZE is set greater than zero, Table X is established for the VEHICLES file. 
CREATE FILE VEHICLES
PARAMETER FILEORG=X'24" */Unordered, RRN file organization/*
PARAMETER BSIZE=128
PARAMETER BRESERVE=100 */100 free bytes are required to store /*
*/a new record on page /*
PARAMETER BREUSE=30 */when 30% or more page space is free, /*
*/put page on reuse queue /*
PARAMETER XSIZE=600
PARAMETER XRESERVE=800 */800 free bytes are required to store /*
*/a new record for Table X on page /*
PARAMETER XREUSE=15 */when 15% or more page space is free, /*
*/put page on reuse queue /*
END


===Considerations for Table X===

If you want to add a Table X to a <var class="product">Model 204</var> file created prior to V7R21.0, you must re-create the file and reload it in V7R1.0 or later.

You can implement Table X for files created in V7R1.0 or later that are unordered or entry order, but Table X is not supported for sort key and hash key files. 

When you issue a VIEW TABLES command against a file that does not have a Table X, the [[Table X (File architecture)#Parameters related to the use of Table_X|Table X parameters]] are displayed with zero values.

If XAUTOINC is set to a non zero value, <var class="product">Model 204</var> will automatically increase Table X as needed, when the file is opened by the first user. 

===Preallocated fields===

Preallocated fields can reside only in Table B records. <var class="product">Model 204</var> will never store them in Table X. 

<var class="product">Model 204</var> will store non-preallocated fields in Table B records. However, when a given Table B record has no more room for additional non-preallocated fields, those fields will be stored in Table X extension records. The fields stored in Table X records have exactly the same format and therefore space requirements as fields stored in Table B records.

===Dividing data between Tables B and X===

The requirement is simply to have enough data storage using either Table B alone or Table B and Table X:
<ul>
<li>When XSIZE is set to 0, Table B must be sized such that it can contain all visible fields in all records. </li>

<li>When XSIZE is greater than 0, the total size of Table B and Table X must be such that each visible field in all records will be stored in Table B or Table X. </li>
</ul>

There are many possible combinations of BSIZE and XSIZE that meet this requirement. So, for a file with a Table X, there is no one formula for determining a unique BSIZE or XSIZE, but there are a number of approaches you can take. 
<ul>
<li>If you have records with a generally consistent size you may be able to keep most of your data in Table B and have only a small Table X for the occasional overflow.</li>

<li>If you have wildly divergent size records, size Table B so that the vast majority of the smaller size records fit in Table B so only the largest ones create extensions. </li>

<li>If you have records which start small, and then increase dramatically over time, consider very small (perhaps even only large enough to handle the preallocated fields) in Table B, with the rest as extensions.</li>
</ul>

But, as long as you understand first the overall size you would need if you were only storing the data in Table B, splitting it into the two parts is straightforward. (And if <var>[[RECRDOPT parameter|RECRDOPT]]</var> is set to one, then sizing of Table B is trivial — how many records do you expect to have?)

===Table X overhead===

The purpose of Table X is to free page slots in Table B that might have been used for extension records. There could be a performance side effect with using Table X. By experimenting with different values of <var>[[XRECPPG_parameter|XRECPPG]]</var>, it might be possible to reduce the size of record extension chains: that is, have fewer but larger extension records instead of many smaller extension records. Having fewer extension records would potentially reduce I/O normally required to read in very large records, such as those with many extensions.

===Sizing tables with XSIZE greater than zero===

Setting a default for XSIZE depends on the difference in the size of your records. The more variation in the length of your records, the more likely that you will have extension records and, therefore, need more Table X pages. Rocket Software recommends the following: if the size of your records varies by 10%, then allocate 10% of the pages in Table B for Table X.

If XSIZE is greater than 0, the following formula can be used to size Table B:
BSIZE=1.2 *(total number of base records) / BRECPPG


And the following formula can be used to size Table X:
XSIZE=1.2 *(total number of extension records) / XRECPPG

Note: Table X slots are always reused after extension records are deleted. Table B slots are reused only for Reuse Record Number (RRN) files.

==Tables C and D indexing structure==

Tables C and D comprise the indexing structure of a <var class="product">Model 204</var> file. Only fields defined with the KEY, NUMERIC RANGE, or ORDERED attribute generate entries within the indexing structure:
<table>
<tr class="head">
<th>Entries in...</th>
<th>Are made for each distinct value of... </th>
</tr>

<tr>
<td>Table C</td>
<td>KEY or NUMERIC RANGE field.</td>
</tr>

<tr>
<td>Table D</td>
<td>ORDERED field, and for each record that contains a particular value of a KEY, NUMERIC RANGE, or ORDERED field, if that value occurs in more than one record in the file. </td>
</tr>
</table>

The two indexes are:
<table>

<tr>
<td>Hashed Index</td>
<td>Composed of Table C, which indexes KEY and NUMERIC RANGE fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Table C entries.</td>
</tr>

<tr>
<td nowrap>Ordered Index</td>
<td>Stored in Table D, is composed of the Ordered Index B-tree, which indexes ORDERED fields, plus a secondary index (located in Table D) containing Table B record numbers pointed to by Btree entries.</td>
</tr>
</table>

In addition to these tables, some free space might be available to the file on unassigned pages in a free-space pool.

====FRV attribute entries====

In addition, Tables C and D contain extra entries for fields that have the FRV attribute. However, the space for these entries generally is insignificant in relation to the other entries, and so formulas for calculating FRV entries are not provided. To allow for FRV entries and to compensate for imprecise knowledge of data values and their distribution, the following formulas result in generous space estimates. 

===Computing the file size multiplier (N)===

To minimize disk storage space and to optimize record retrieval techniques, the records in Table B are divided into internal file segments that are transparent to the user. The maximum number of records stored in one file segment is 49,152 (that is, eight times a page size of 6144). 

Both Table C and Table D space estimation formulas depend upon the file size multiplier <var>N</var>, which represents the number of internal file segments. Use the following equation to calculate <var>N</var>:
N = Number-of-Records-in-the-File / 8 * Page-size


Round the result up to an integer. If BRECPPG is set too high or if a large number of extension records exists, there can be fewer actual records per segment. In this case, base <var>N</var> on the number of record numbers used in the file (EXTNADD + MSTRADD), rather than on the number of records actually stored.

For space estimation purposes, the records are considered to be distributed evenly among the segments. If the records are not distributed evenly, make separate estimates for each segment individually.

==Sizing Table C==

===Table C organization===

Table C is a hashed table divided into entries of seven bytes each. Table C entries store index information for fields that have the KEY or the NUMERIC RANGE attributes. <var class="product">Model 204</var> creates a chain of entries in Table C for each value stored in a KEY field and several chains of entries for each value stored in a NUMERIC RANGE field. 

====Table C property entries====

The head of each chain is called the property entry. The property entry identifies the field name = value pair that is indexed by the other entries in the chain. <var class="product">Model 204</var> places one entry in the chain for each segment of the file containing records that have the field name = value pair identified in the property entry. 

For example, <code>PROJECT</code>, a 4-segment file, contains a field named <code>STAGE</code>. <code>STAGE</code> is defined with the <var>KEY</var> attribute. One of the values stored in the field <code>STAGE</code> is <code>PLANNING</code>. In the first and second segments of the <code>PROJECT</code> file, there are records containing the field name = value pair, <code>STAGE = PLANNING</code>.

Therefore, in Table C of the <code>PROJECT</code> file, there is a chain of three entries:
<ul>
<li>Property entry for <code>STAGE = PLANNING</code></li>
<li>Entry for the first segment of the <code>PROJECT</code> file</li>
<li>Entry for the second segment of the <code>PROJECT</code> file </li>
</ul>

====Storing segment and property entries====

<var class="product">Model 204</var> attempts to store segment entries on the same page as the property entry. When this is not possible, <var class="product">Model 204</var> continues chains of entries in Table C across Table C page boundaries, ensuring uniform use of the pages in Table C by reducing the likelihood of one page filling while other pages are relatively empty.

===Computing CSIZE===

The CSIZE parameter specifies the number of pages to be assigned to Table C. After it has been allocated, the size of Table C cannot change until you re-create the file. 

Compute CSIZE as follows:
<ol>
<li>Place the distinct values of each KEY or NUMERIC RANGE field into one of two categories:
<ul>
<li>Category <var class="term">u </var>contains those field name = value pairs that usually appear in only one record in the file, such as Social Security number.</li>

<li>Category <var class="term">n</var> contains those field name = value pairs that occur in more than one record in the file, such as the values of SEX or AGE. For simplicity, field name = value pairs in this category are assumed to occur in records in every segment. This is the worst-case assumption and results in slightly high estimates. </li>
</ul></li>

<li>Then let <var>V</var>u = total number of pairs in category <var class="term">u</var> and <var>V</var>n= total number of pairs in category <var class="term">n</var>.

For fields that have both the KEY and NUMERIC RANGE attributes, count the values twice, as if there were two distinct fields. Calculate the number of extra entries required for NUMERIC RANGE retrieval fields. For each NUMERIC RANGE field:
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul></li>

<li>Let <var>Vr</var> = total number of extra entries required for all NUMERIC RANGE retrieval fields.

When calculated this way, <var>Vr </var>is the maximum number of extra entries required. You can reduce this number slightly if some digits never take on all the values between 0 and 9. For example, in a 3-digit age field, the first digit never goes above 1. Refining the estimate of <var>Vr</var> is usually unimportant because <var>Vr</var> is usually outweighed by <var>Vn</var>. 

Compute:
CSIZE = 1.2 * ((14 * VU) + 7 * (N +1)(VN + VX)) / (6144 -4)


Round up to the nearest integer. Do not reduce the multiplier, even if you can determine the exact number of entries required in Table C, because it is not possible to use all the space available. CSIZE must not exceed 16,777,216. CSIZE has a default value of 1. 
</li>
</ol>

==Sizing Table D==

===Table D data===

Table D contains a number of different types of data. The principal types are:
<ul>
<li>Ordered Index B-tree pages</li>
<li>Lists or bit patterns of indexing information for KEY, NUMERIC RANGE, and ORDERED fields that appear in multiple records</li>
<li>Existence bit pattern pages: bit patterns that specify which records currently exist in the file segment</li>
<li>Preallocated field record descriptions</li>
<li>Text of stored procedures</li>
<li>Procedure names and aliases (procedure dictionary)</li>
<li>Access Control Table (ACT) pages</li>
<li>Sorted file group index pages, if the file is a sorted file </li>
<li>Reserved area: a pool of pages kept available for transaction back out use. The size of the reserved area is controlled by the DPGSRES file parameter. </li>
</ul>

In most files, indexing entries constitute the major portion of the table, but in files that have very few KEY, NUMERIC RANGE, and ORDERED fields, procedures can overshadow the indexing data.

====Data storage in Table D====

Table B record locating information is stored in Table D record number lists and bit patterns for Ordered Index fields and for KEY and NUMERIC RANGE field name = value pairs that occur in more than one record in the file. 

Record list pages contain <var class="product">Model 204</var> record numbers for a given file segment, stored in 2-byte entries. Lists that grow too large are converted into bit patterns. Bit pattern pages are <var class="product">Model 204</var> pages where each bit on the usable page represents a single record number for a given file segment.

=====Computing DSIZE=====

The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area:
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES


Where:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>OIT </td>
<td>Size of the Ordered Index</td>
</tr>

<tr>
<td>IT </td>
<td>Size of index list space</td>
</tr>

<tr>
<td>F </td>
<td>Number of preallocated fields</td>
</tr>

<tr>
<td>P </td>
<td>Number of procedures</td>
</tr>

<tr>
<td>K </td>
<td>Number of blocks of pages required for the procedure dictionary</td>
</tr>

<tr>
<td>PDSIZE </td>
<td>Size of the procedure dictionary</td>
</tr>

<tr>
<td>Q </td>
<td>Number of pages required for the Access Control Table (ACT)</td>
</tr>

<tr>
<td>DPGSRES </td>
<td>Size of the Table D reserved area</td>
</tr>
</table>

The space requirements of the principal components of Table D are discussed in the following sections.

===Calculating the size of the Ordered Index (OIT)===

====About Ordered Index space====

The Ordered Index is stored in Table D. Record location information is stored on list or bit pattern pages when an ORDERED field value occurs a greater number of times than the IMMED parameter allows to be held locally in a segment of the Ordered Index B-tree. The space requirements for these list pages are the same as for the KEY field lists, and are discussed in detail on [[#Computing the total index list space (IT)|Computing the total index list space (IT)]]. The Ordered Index B-tree space calculations follow. 

The following formulas yield an approximation for the total amount of space used by the Ordered Index B-tree structure. The formula variables are field specific; you need to calculate the space for each field in the Ordered Index.

=====Estimating Ordered Index space (OI) for each ORDERED field=====

For each field in the file that has the <var>ORDERED</var> attribute, the number of Table D pages required for the section of the Ordered Index B-tree structure that indexes the field is estimated as follows. 
<ol>
<li>Estimate the following numbers:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>NE </td>
<td>Number of distinct values (or elements) in the field</td>
</tr>

<tr>
<td>N </td>
<td>Number of segments in the file</td>
</tr>
</table></li>

<li>Estimate the average length (<code>AV</code>).

First estimate the average length of the distinct values stored in the <var>ORDERED</var> field. For numeric values of <var>ORDERED NUMERIC</var> fields, the average length of the numeric values is 8. Compute the following:
AV = estimated av. length of ORDERED values + 1
</li>

<li>Divide the <var>ORDERED</var> values into categories. To estimate space for the Ordered Index, perform separate calculations on each of the following categories of distinct field value:
<table>
<tr class="head">
<th>This category</th>
<th>Equals values that occur in...</th>
</tr>

<tr>
<td>A</td>
<td>

One and only one record in the file.

ValA = the number of values in category A
</td>
</tr>

<tr>
<td>B</td>
<td>

More than one record in the file and in a number of records per segment less than or equal to the setting of the field's <var>IMMED</var> parameter. 

ValB = the number of values in category B
</td>
</tr>

<tr>
<td>C</td>
<td>

A greater number of records per segment than the setting of the field's <var>IMMED</var> parameter. 

ValC = the number of values in category C
</td>
</tr>
</table>
</li>

<li>For each category of distinct values, use the following appropriate formula:
<ul>
<li>Calculate category A.

Total length of the Ordered Index entries placed in category A is:
ENa = ValA * (AV + 3)

</li>

<li>Calculate category B.

For the values in category B, first estimate the average number of records per segment that has one of the values in category B. 

Let <var>AB</var> represent the average number of records per segment with one of the values in category B. <var>AB</var> is between 1 and the value of the <var>IMMED</var> parameter for that field.

The total length of the Ordered Index entries placed in category B is:
ENb = ValB * (AV + (2 * AB) + (2 * N))


If <code>(AV + (2 + AB) + (2 * N))</code> is greater than 3000, substitute 3000.</li>

<li>Calculate category C.</li>

The total length of the Ordered Index entries placed in category C is:
ENc = ValC * (AV + (5 * N))

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

<li>Calculate OIB.

Assuming that the values of the ORDERED field are distributed evenly over the segments of the file, the estimated total length of all the Ordered Index entries is:
OIB = ENa + ENb + ENc


If the values are not evenly distributed, estimate ENa, ENb, and ENc (as appropriate) for each segment in which the values occur.
Note:
The value calculated as OIB should roughly correspond to the value of the <var>[[OINBYTES parameter|OINBYTES]]</var> parameter after the file is fully loaded. <var>OINBYTES</var> is a file table parameter that displays the current number of Ordered Index B-tree entry bytes. </li>
</ol>

===Estimating leaf page overhead (LOa)===

To estimate the actual amount of overhead space on each leaf page, first calculate the amount of overhead expected on each leaf page, then the minimum amount of overhead necessary for each leaf page, and use the larger of the two. 
<ol>
<li>Calculate the expected leaf page overhead (LOe)

The amount of overhead expected on each leaf page, <code>LOe</code>, depends on the usual mode of updating used when updating the ORDERED field:
<ul>
<li>If most updates are in deferred update mode (using either the deferred update feature or the File Load utility), then use the setting of the field's LRESERVE parameter to calculate <var>LOe</var>:
LOe = 6144 * (LRESERVE / 100)
</li>

<li>If you expect most updates to be in non-deferred update mode then use the setting of the field's SPLITPCT parameter to calculate <var>LOe:</var>
LOe = 6144 *( (100 - SPLITPCT) / 100)
</li>
</ul></li>

<li>Calculate the minimum leaf page overhead

To determine the minimum amount of overhead for each leaf page, <var>LOmin</var>, first calculate the average number of bytes per Ordered Index entry:
AE = DIB / NE

Then calculate <var>LOmin</var> using the following formula:
LOmin = 2 * (6144 / AE)
</li>

<li>Estimate leaf page overhead (<var>LOa</var>)

The estimate of the overhead for each leaf page, <var>LOa</var>, is the larger of <var>LOe</var> and <var>LOmin:</var>
LOa = <var class="term">max</var>(LOe, LOmin)
</li>
</ol>

===Estimating the number of required leaf pages (LP)===

The number of leaf pages required for the ORDERED field is:
LP = OIB / (6144 - 24 - LOa)


Round up to the nearest integer. 

===Calculating the size of the index for each ORDERED field===

The number of Table D pages required for the ORDERED field's section of the Ordered Index B-tree is:
OI = (LP * 1.01) rounded up to the nearest integer


This formula assumes conservatively that the number of intermediate pages is 1% of <code>LP</code>. 

===Calculating the total size of the Ordered Index (OIT)===

If there is more than one ORDERED field in the file, the total number of pages required for the Ordered Index B-tree is the sum of the pages required for each ORDERED field.
OIT = OI1 + OI2 + ... + OIn


===Computing the total index list space (IT)===

If a record number list grows to exceed the available space on a Table D list page, but is still less than 30% of the Table D page, the list is moved to a Table D page that has enough space to hold the list. If a list grows longer than 30% of a Table D list page, it is converted into a bit pattern. Bit patterns are not converted back to lists. 

<var class="product">Model 204</var> deletes empty lists. If a Table D list page becomes empty because the lists originally stored on the page have been deleted, moved onto another page, or converted into bit patterns, <var class="product">Model 204</var> makes the empty page available for reuse.

The amount of Table D space used by index lists depends primarily upon how many records contain a particular field name = value pair and how many of those records are in each file segment. Field name = value pairs that were placed in category u for Table C estimates do not take up any space in Table D. 

====Calculating DRESERVE====

Before you can calculate the index list space, you need to choose a value for the DRESERVE parameter, which is the percentage of space reserved for expansion of current record number lists. If a list grows into the DRESERVE section of the current page for lists, the next new list goes on a new page. If more space becomes available on the current page before a list grows into the DRESERVE section of the page, a new list can be started in the newly available space. New lists cannot start in the DRESERVE section of the Table D page. 

The default value of DRESERVE is 15%. 

====Calculating I (the index list space)====

Compute<var> I</var>, the amount of space required for index lists for each segment, according to the following rules: 
<ol>
<li>If <code>N</code>, the file size multiplier, is greater than 1, consider the total number of records in the file to be divided evenly into segments.</li>

<li>For each segment of the file, take each KEY and/or NUMERIC RANGE field name = value pair that occurs in more than one record in the file, and each ORDERED field name = value pair that occurs in a greater number of records than the setting of the field's IMMED parameter, and place it in one of the following categories:
<table>
<tr class="head">
<th>This category</th>
<th>Equals field name = value pairs that occur in...</th>
</tr>

<tr>
<td>A</td>
<td>More than one record but fewer than 2 percent of the records in the segment. For files with a page size of 6184 (6144 usable), field name = value pairs in this category occur in fewer than approximately 1000 records in the segment.</td>
</tr>

<tr>
<td>B</td>
<td>Two percent or more of the records in the segment. Their record numbers are stored on bit pattern pages. </td>
</tr>
</table>

Fields that have both the KEY and NUMERIC RANGE, or KEY and ORDERED attributes have their values counted twice, as if there were two distinct fields. It is possible that different values of the same field might not be in the same category. 

For example, if DEPT = PERSONNEL is contained in 5000 records of a segment, it is placed in category B, whereas DEPT = SECURITY might occur in only 100 records in the segment and, therefore, be placed in category <var>A</var>. If the distribution of values is not known, then assume that all values of a field occur equally in each segment. 

Each pair placed in category <var>A</var> requires the following number of bytes:
T = 2 + (2 * (Number of Records Containing the Pair))

<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>X </td>
<td>Total number of bytes available on a Table D page. <var>X</var> depends on the DRESERVE parameter, which defaults to 15% and represents the percentage of reserved space per page. The default value of <var>X</var> is 5222, calculated as follows:
X = 6144 * (1 - (DRESERVE / 100) )
</td>
</tr>
</table>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>A </td>
<td>Total number of pages required by the category A pairs for the segment, where:
A = T / X</td>
</tr>
</table>
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>B </td>
<td>Total number of pages required by pairs in category B. Each field name = value pair in category B requires 1 page for the segment. <var>B</var> is equal to the number of pairs in the category.</td>
</tr>
</table>
</li>

<li>Calculate the number of extra values per segment for NUMERIC RANGE fields. For each field:
<ul>
<li>Determine the maximum number of significant digits the field will have. Include digits on both sides of the decimal point.</li>
<li>Multiply by 10.</li>
<li>Add 2. </li>
</ul></li>
</ol>

If the field appears in fewer than 2% of the records, each extra value just calculated requires the following number of bytes:
T' = 2 + (2 * (Number of Records Containing the Field))


If the NUMERIC RANGE field appears in 2% or more of the segment's records, the number of pages required is:
B' = number of extra values


The extra space required for all NUMERIC RANGE fields is computed as follows. First, let:
T" = sum of all the values of <var>T</var>'
B" = sum of all the values of B'


Then, the total number of pages required is:
C = (T" / X) + B"


Thus, the amount of index list space, <var>I</var>, for each segment is:
I = A + B + C


The total number of pages required for index lists and bit patterns for the entire file is equal to the sum of the totals (<var>IT</var>) for each segment, plus the number of existence bit pattern pages. Because there is one existence bit pattern page per file segment, the number of existence bit pattern pages is equal to <var>N</var>, the number of segments. The total number of pages for index lists and bit patterns can thus be represented by the following equation:
IT = A1 + B1 + C1 + ... + AN< + BN + CN + N


===Calculating F (the number of pages for preallocated fields)===

If any preallocated fields are defined in a file, one Table D page is used to store a record description of the arrangement of fields in the block of storage preallocated in each record. The record description uses 36 bytes of fixed overhead and 8 bytes for each preallocated field. The maximum number of preallocated fields on a 6144-byte record description page is, therefore, 763. 

Let <var>F</var> be the number of Table D pages required for the record description. <var>F</var> is always either 0 or 1.

===Calculating P (the number of procedures)===

[[Procedures]] are stored in Table D. In most cases, the text of each procedure requires one page. A very long procedure might require more than one page. Let:
P = total number of procedures


===Sizing the procedure dictionary===

Procedure names and aliases are stored in a procedure dictionary in Table D. Like procedure text, the procedure dictionary associates a procedure name or alias with information about the location of the procedure's text, and with a class, if the procedure is secured. 

The procedure dictionary is allocated in blocks of one or more contiguous pages. When <var class="product">Model 204</var> verifies a procedure name, it begins searching on a random page in the first block. If the name is not found on that page, the remaining pages in the same block are searched. If the name is still not found, <var class="product">Model 204</var> searches the pages in the second block, and so on. 

====Storing new procedure names====

If <var class="product">Model 204</var> does not find the name (that is, if this is a new procedure name), it stores the new name in the first block in which it can find space. <var class="product">Model 204</var> allocates a new block when it cannot find space for a new name in any of the preceding blocks. Space used by deleted names is reused. 

=====Choosing a PDSIZE=====

There are two possible paths you can take in choosing a PDSIZE:
<ul>
<li>Have one large block containing many pages. Because name searches always begin with the first block, this increases the likelihood of finding a name on the first page read. However, as the pages fill up, <var class="product">Model 204</var> might allocate a new block when space still exists on the old block.</li>

<li>Have a number of smaller blocks with fewer pages. Although it might take <var class="product">Model 204</var> longer to find the procedure name, there is less impact on Table D when a new block is allocated.</li>
</ul>

When choosing PDSIZE, take into account the percentage of procedure and alias names known or anticipated when you design the file. The fewer aliases your site uses, the smaller the PDSIZE you can use. 

=====Computing PDSTRPPG=====

PDSTRPPG specifies the maximum number of procedure entries per procedure dictionary page. The actual number of procedure entries per page is a function of the length of the names and aliases. The size of an entry is:
L + 34 for a procedure
L + 7 for an alias


Where: 

<code>L</code> is the length of the procedure or alias name. 

First, estimate <code>S</code>, the average entry size. Then compute <var>PDSTRPPG</var> as follows:
PDSTRPPG = 6144 / S


The default value of <var>PDSTRPPG</var> is 128. Its maximum is 256.

=====Computing PDSIZE (the size of the procedure dictionary)=====

The procedure dictionary is allocated in blocks of one or more contiguous pages. PDSIZE specifies the number of pages in a single block. If you know most of the procedure names when you create the file, use the following formula:
PDSIZE = 1.4 * P / PDSTRPPG


PDSIZE has a default value of 3.

If <var>K</var> is the number of blocks of pages, then (<var>K</var> * PDSIZE) is the total number of pages required for the procedure dictionary.

===Sizing the access control table (ACT)===

The access control table (ACT) contains entries that map user classes and procedure classes into privileges. It is used for procedure security purposes. The ACT is allocated from Table D, one page at a time, as needed. No space is allocated until <var class="product">Model 204</var> encounters the first SECURE command. The maximum number of pages possible for the ACT is five. 

====Determining LET (the total length of procedure class entries)====

The ACT is organized by user class in ascending order. For each user class, you need to determine:
NPCLASS = number of procedure class subentries


Then, compute <code>LE</code>, the length of the entries for each user class as follows:
LE = 4 + (2 * NPCLASS)


Thus, if user class 05 has privilege definitions set for 8 different procedure classes, the length of its entry is 20 bytes. 

Then, the total length of the user class entries is:
LET = LE1 + LE2 + ... + LEn


Additional space required for a SECURE command depends upon whether an entry already exists for the particular user class in question, and upon whether subentries exist for the procedure classes in question. If the entry already exists, 2 bytes are needed for each new procedure class mapped to that user class. If the subentries already exist for the procedure classes, no additional space is required. 

====Determining Q (the number of pages required for the ACT)====

<var>Q,</var> the number of pages required for the ACT is always between 0 and 5 and is calculated by <var class="product">Model 204</var>. To determine how many pages <var class="product">Model 204</var> will probably use for the ACT: 
Q = LET / 6144


====Reorganizing the ACT====

If there is no room on an ACT page to add a new user class entry or subentry, <var class="product">Model 204</var> reorganizes the entire ACT. During this automatic reorganization, N + 1 pages are allocated from Table D, where <code>N</code> is the number of pages in the ACT before reorganization. The new pages need not be contiguous. Existing user class entries are redistributed across the new pages in an effort to leave some free space on each ACT page. After reorganizing, the original <code>N</code> pages are released.
Note:
If the ACT reaches five pages and redistributing user class entries does not produce enough space for the new entry, the entry is not added. If the old entries cannot be redistributed successfully in five pages, the ACT is left in its original state and the new entry is not added.

===Sizing the reserved area===

====Using reserved Table D pages====

<var class="product">Model 204</var> keeps a specified number of Table D pages available, primarily for transaction back out use. When a page is successfully allocated from this area, the file is marked full; processing continues, and the following warning message is issued:
M204.2486 FILENAME: TABLED FULL. PAGE ALLOCATED FROM TABLED RESERVE AREA


Marking the file full prevents other users from starting requests that update Table D, making it more likely that all requests in progress complete normally. (Only nonupdate requests can examine data in files marked full. Users attempting to update files marked full are restarted.) 

In a transaction back out file, the last half of the reserved section is reserved for use during transaction back out. If an ordinary transaction attempts to get a page from the second half of the reserved area, the allocation attempt fails with a Table D full error, which causes transaction back out to be initiated. During back out any free Table D page can be used. 

For transaction back out files, the DELETE RECORDS and FILE RECORDS statements establish constraints that place the pages they delete during normal processing into the reserved area, temporarily enlarging the second half of the reserved area until the transaction commits. 

When no space is available in Table D, including the reserved area, either the request is canceled or the user is restarted. The file is marked broken only if it has been updated and transaction back out is impossible or unsuccessful.

The DPGSRES parameter controls the size of the Table D reserved area. To compute DPGSRES, you first need to know the value of <var>DEST</var>, which is the estimate of the value of the total amount of space required for Table D, not including the reserved area space.

====Calculating DEST (estimated Table D size)====

<code>DEST</code> is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, and the ACT:
DEST = OIT + IT + F + P + (K * PDSIZE) + Q

====Setting DPGSRES (the size of the reserved area)====

You can reset the <var>[[DPGSRES_parameter|DPGSRES]]</var> parameter and <var>[[VIEW command|VIEW]]</var> it as one of the <var>TABLES</var> parameters. It can be set to 0, or any other value up to 32767. 

For files containing only procedures, set <var>DPGRES</var> to 0 to avoid wasting Table D space. For files that are not transaction back out files, Set <var>DPGRES</var> low to avoid wasting Table D space. 

====Calculating DPGSRES====

Unless you specify some other value, the <var>[[CREATE command: File|CREATE FILE]]</var> command sets <var>DPGSRES</var> to:
DPGSRES = <var class="term">min</var>(DEST/50 + 2, 40)


That is, <var>DPGSRES</var> is either <code>(DEST/50 + 2)</code> or 40, whichever is smaller. Since
<code>DEST/50 + 2 = 40</code> when <code>DEST = 1900</code>:
If DEST < 1900, DPGSRES = DEST/50 + 2


and:
If DEST >= 1900, DPGSRES = 40


===Computing DSIZE===

The total amount of space required for Table D is the sum of the space computed for the Ordered Index pages, the index lists, the preallocated field record descriptions, the procedure texts, the procedure dictionary, the ACT, and the reserved area.
DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES


or:
DSIZE = DEST + DPGSRES


You can change the value of DSIZE using the INCREASE and DECREASE commands. DSIZE cannot exceed 16,777,216. The default value of DSIZE is 15. 

==Sizing Table E==

The following parameters pertain to Table E sizing:
<ul>
<li><var>[[ESIZE parameter|ESIZE]]</var> — The number of file pages in Table E.</li>

<li><var>[[EHIGHPG parameter|EHIGHPG]]</var> — The highest active Table E page. The first page in Table E is page zero.</li>

<li><var>[[EPGSUSED_parameter|EPGSUSED]]</var> — The number of Table E pages currently in use.</li>
</ul>

===Storing Large Object data===

Each instance of a Large Object field occupies an integral number of Table E pages.

The rules of use, and sizing, are quite different depending on whether the <var>[[FILEORG parameter|FILEORG]]</var> X'100' bit is set. For these differences, see:

[[Table E (File architecture)|Table E]]

[[Table E and FILEORG X'100' files (File architecture)|Table E FILEORG X'100']]

[[Table E and non-FILEORG X'100' files (File architecture)|Table E non X'100']]

====ESIZE for FILEORG X'100' files====

Set ESIZE as the number of Data pages.

To calculate the number of Data pages: Average the BLOB/CLOB length, divide by 6140 (The usable page size of 6144 less the 4 byte chain pointer) and round up. Then, multiply by the total number of Large Object fields (and probably add a percentage for growth (based on your knowledge of the data and application).

Additional considerations:

<ul>
<li>If you have <var>[[Field design#BLOB.2C CLOB.2C and MINLOBE attributes|MINLOBE]]</var> set, ignore large objects smaller than this number.</li>

<li>Be sure to take that (along with the large object header) into account when sizing Tables B and X.</li>
</ul>


For more detail on the large object architecture, see [[Table E and FILEORG X'100' files (File architecture)|Table E for FILEORG X'100']] files.

====ESIZE for non FILEORG X'100' files====

'''Characteristics:'''
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages. </li>

<li>Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.</li>

<li>Large Object data of 6145 bytes requires two Table E pages. </li>
</ul>

The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored, then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.

If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG — even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data.

Note:
Even if the number of free pages (ESIZE minus EPGSUSED) is sufficient, it might not be possible to obtain the required Table E space. The free pages must also be contiguous. 

'''Sizing:'''

Set ESIZE as the number of Data pages, plus the number of Bitmap pages plus two.

<ol>
<li>To calculate the number of Data pages: Average the BLOB/CLOB length, add 6144, and divide by 6144. Then, round down the result and multiply by the number of Large Object fields.
First calculation: (Avg.-BLOB-len + 6144) / 6144 = result

Second calculation: 1st Round up result

Data pages = round-up-result * No.-of-BLOBs
</li>

<li>To calculate the number of Bitmap pages: Add 17 to (Data pages / 49152) and add 1. Then, round up the result.
17 + (Data-pages / 49152) + 1 = 2nd result

Bitmap pages = 2nd round up result
</li>

<li>Calculate ESIZE.
ESIZE = Data pages + bitmap pages
</li>
</ol>


Generally speaking, the cost of finding free space in Table E non X'100' files is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.

If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you store the Large Object data in an individual file (or files), plus an indexed field to cross-reference the Large Object field to the data in other files (or make the file an x'100' file). This enables you to size, manage, and reorganize the Large Object data independently of your other files. This approach is particularly beneficial if you are new to using Large Object fields and find it difficult to accurately determine the Large Object data space requirement in advance.

For more detail on the large object architecture, see [[Table E and non-FILEORG X'100' files (File architecture)|Table E for non FILEORG X'100' files]].

===Managing Large Object data===

If a file was originally created with ESIZE=0, this can be changed only by recreating the file. Otherwise, you issue an <code>INCREASE TABLEE</code> or <code>DECREASE TABLEE</code> command to change the size of Table E — subject to the standard restrictions that apply to the INCREASE and DECREASE commands.

==Data set allocation==

After you have finished the preceding calculations, you can allocate data sets for the <var class="product">Model 204</var> file. 

===Minimum number of pages required===

The minimum number of pages required for the file is equal to:
8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE


You can allocate more disk space. When the file is created, any pages not assigned to the File Control Table (always eight pages) or Tables A through D are designated free space and can be used later to expand Tables B, D, and E. 

===Allocating disk space===

Allocate disk space in either tracks or cylinders, without specifying a secondary allocation. The "Disk space requirements" table can help you to determine how many pages <var class="product">Model 204</var> stores on each track for your device type. The page size for all devices is 6184 bytes. 
<div id="Disk space requirements"></div>
<table>
<caption>Disk space requirements</caption>
<tr class="head">
<th>Device type</th>
<th>Pages/tracks</th>
<th>Tracks/cylinder</th>
</tr>

<tr>
<td align="right">3330</td>
<td align="right">2</td>
<td align="right">19</td>
</tr>

<tr>
<td align="right">3340</td>
<td align="right">1</td>
<td align="right">12</td>
</tr>

<tr>
<td align="right">3350</td>
<td align="right">3</td>
<td align="right">30</td>
</tr>

<tr>
<td align="right">3375</td>
<td align="right">5</td>
<td align="right">12</td>
</tr>

<tr>
<td align="right">3380</td>
<td align="right">7</td>
<td align="right">15</td>
</tr>

<tr>
<td align="right">3390</td>
<td align="right">8</td>
<td align="right">15</td>
</tr>

<tr>
<td>FACOM 6421</td>
<td align="right">4</td>
<td align="right">20</td>
</tr>
</table>

For example, a file that you calculate to need 1275 pages requires at least 183 tracks on a 3380 device.

====Support for FBA devices====

<var class="product">Model 204</var> also supports fixed-block-architecture devices (3370s) under the z/VM/SP and z/VSE operating systems; FBA devices require 13 blocks per page.

====Guidelines for allocating data sets====

The space can be allocated in one or more data sets on one or more disk packs as you see fit. 

Keep the number of data sets small, if core is a problem. 

In a heavily used file, you can greatly improve efficiency by distributing the tables into several data sets on several volumes, each maintained on different channels and control units.

===Allocating data sets===

====z/OS example====

To allocate z/OS data sets, use the IBM utility IEFBR14. For example:
//JOB IEFBR14 DELETE AND CREATE
//STEP1 EXEC PGM=IEFBR14
//PEOPLE DD DSN=M204.FILE.PEOPLE,DISP=(NEW,CATLG),
// SPACE=(TRK,183),UNIT=3380
//


The choice of data set names is, of course, entirely yours, as is the decision whether or not to catalog.

If a large enough piece of contiguous space is available on the disk, a slight improvement can be made by allocating the data set on contiguous tracks. For example:
SPACE=(TRK,183,,CONTIG)


====z/VSE example====

The ALLOCATE utility provided with <var class="product">Model 204</var> is used to preallocate database files, the CCATEMP file, the CCAGRP file, and the CCASERVR files. It can allocate one or more of these files, as specified in control statements, during one execution. For each file referenced in the ALLOCATE control statements, provide a DLBL and EXTENT with complete information. The utility opens each of these files as output data sets to make entries into the volume table of contents.

====z/VM example====

For variable format (z/OS and z/VSE) z/VM minidisks that have been initialized using the INITIAL parameter of the M204UTIL command, allocate data sets with the ALLOCATE parameter of the M204UTIL command. An example follows:
ACCESS 201 M
M204UTIL ALLOC M204 FILE PEOPLE M (P 183 TRK


The minidisk where the allocation is to be performed must be accessed before issuing M204UTIL ALLOCATE from z/VM. M204UTIL ALLOCATE does not catalog data sets.
For further description of M204UTIL, see [[Defining the runtime environment (CCAIN)]].

====ALLOCATE control statement====

The ALLOCATE control statement format is as follows:
ALLOCATE FILE(filename1 filename2 ... filenameN)


The statement is free form and can begin in any column. You can have any number of ALLOCATE control statements in the input to the utility. Continuation from one input record to the next is indicated by a dash (minus sign) after the last parameter on the input record being continued. There is no limitation on the number of continuation statements.

The parameters <var class="term">filename1</var> through <var class="term">filenameN</var> refer to the filenames on the DLBL statements in the job control stream. If a filename referenced in the ALLOCATE control does not have a corresponding DLBL statement in the JCL, an error message is written in the output audit trail.

Comment statements beginning with an asterisk in column 1 can be interspersed with the ALLOCATE control statements.

The ALLOCATE utility also runs in a mode compatible with earlier releases. If the control statements are omitted, the utility attempts to allocate a single file with a filename of NEWFILE. A DLBL and EXTENT for NEWFILE must be provided in the JCL used to run the utility.

The following sample ALLOCATE utility job stream shows that the file PEOPLE with 183 tracks of space beginning at relative track number 1000 is allocated:
 // JOB ALLOCATE MODEL 204 FILE
// DLBL M204CL,'M204.CORE.IMAGE.LIBRARY'
// EXTENT,volser
// LIBDEF CL,SEARCH=M204CL
// DLBL PEOPLE,'M204.FILE.PEOPLE',99/365
// EXTENT SYS001,SYSWK1,,,1000,183
// EXEC ALLOCATE,SIZE=AUTO
ALLOCATE FILE(PEOPLE)
/*
/&


==Space estimation example==

To perform a simple space calculation, assume that a simple personnel file of 90,000 records has the characteristics listed in the [[#Personnel file characteristics sample data|Personnel file characteristics sample data]] table. 

All fields are <var>UPDATE IN PLACE</var>. <code>SSN</code> is given the <var>CODED</var> attribute so that numbers that start with a zero can be stored in coded form in the preallocated space. All other <code>SSN</code> values are stored as 4-byte binary. Because only a small number of values start with a zero, <code>SSN</code> does not have any effect on Table A space estimates.
<div id="Personnel file characteristics sample data"></div>
<table style="width:80%">
<caption>Personnel file characteristics sample data</caption>
<tr class="head">
<th>
Field name</th>
<th>
Options</th>
<th>Average value length</th>
<th>Comments on distribution of KEY and NUMERIC RANGE values</th>
</tr>

<tr>
<td>FULL_NAME</td>
<td>NON-KEY 
NON-CODED</td>
<td>20</td>
<td>-</td>
</tr>

<tr>
<td>LAST_NAME</td>
<td nowrap>ORDERED CHAR 
IMMED 2 LRES 15 
INVISIBLE 
NON-KEY</td>
<td>11</td>
<td>-</td>
</tr>

<tr>
<td>SSN</td>
<td>KEY
NON-FRV 
BINARY 
CODED 
FEW-VALUED
OCCURS 1</td>
<td>9</td>
<td>Unique to each record.</td>
</tr>

<tr>
<td>AGE</td>
<td>KEY 
NUM RANGE 
FRV 
FEW-VALUED 
NON-CODED 
OCCURS 1 
LENGTH 2</td>
<td>2</td>
<td>55 possible values, evenly distributed (18-72).</td>
</tr>

<tr>
<td>SALARY</td>
<td>NON-KEY 
NUM RANGE 
NON-CODED</td>
<td>5</td>
<td>20,000 possible values, evenly distributed.</td>
</tr>

<tr>
<td>DEPT</td>
<td>KEY 
CODED 
FRV 
FEW-VALUED</td>
<td>10</td>
<td>

10 values.

Values for Personnel Dept. occur only in the first 40,000 records. Values for Accounting Dept. occur only in the last 10,000 records. The other 8 values occur evenly in the remaining 5000 records in segment 1 and the remaining 35,000 records in segment 2.
</td>
</tr>
</table>

==Sample Table A calculations==

===Calculating ASTRPPG===
<table>
<caption>FRV or CODED values</caption>
<tr class="head">
<th>Field</th>
<th># of Values</th>
<th>Space</th>
<th>Overhead</th>
<th>Total</th>
</tr>

<tr><td>AGE</td><td>55</td><td>2*55=110</td><td>3*55=165</td><td>110+165=275</td></tr>

<tr><td>DEPT</td><td>10</td><td>10*10=100</td><td>3*10=30</td><td>100+ 30=130</td></tr>
<tr class="head"><td></td><th>B=65</th><td colspan=2></td><th>V=405</th></tr>
</table>
 
<table>
<caption>Field names</caption>
<tr class="head">
<th>Field</th>
<th>LEN + 2[[#fldnames-fn1|[1]]]</th>
<th>ANY + UP[[#fldnames-fn2|[2]]]</th>
<th>COD/FRV</th>
<th>OCC</th>
<th>LVL</th>
<th>FLOAT</th>
<th>ORD</th>
<th>UNIQ</th>
<th>NR</th>
<th>Total</th>
</tr>

<tr>
<td>FULL_NAME</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>

<tr>
<td>LAST_NAME</td>
<td align="right">9</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">4</td>
<td> </td>
<td> </td>
<td align="right">16</td>
</tr>

<tr>
<td>SSN</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3[[#fldnames-fn3|[3]]]</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">11</td>
</tr>

<tr>
<td>AGE</td>
<td align="right">5</td>
<td align="right">3</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">35</td>
<td align="right">49</td>
</tr>

<tr>
<td>SALARY</td>
<td align="right">8</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">80</td>
<td align="right">91</td>
</tr>

<tr>
<td>DEPT</td>
<td align="right">6</td>
<td align="right">3</td>
<td align="right">3</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td align="right">12</td>
</tr>

<tr class="head">
<td colspan="10"></td><th>N = 191</th>
</tr>
</table>

<div id="fldnames-fn1"></div>
:1   LEN is the length of the field name.

<div id="fldnames-fn2"></div>
:2   ANY refers to the two bytes required from page 3-5. UP refers to the one byte required for UPDATE IN PLACE fields.

<div id="fldnames-fn3"></div>
:3   Because only a small number of values in SSN start with a zero, this field does not have any effect on Table A space estimates.

Calculations
A = 6
D(AGE) = 2 + 3 = 5
D(SALARY) = 5 + 3 = 8
S = 5 + 8 = 13
T = A + B + S = 6 + 65 + 13 = 84
L = average length of character strings = (V + N)/T = (405 + 191)/84 = 7.0 = 7

ASTRPPG = 6144/L = 6144/7 = 877.7 = 877 (rounded down)


===Calculating ATRPG===

The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>N</td>
<td>Total space consumed by field names including overhead.</td>
</tr>

<tr>
<td>A</td>
<td>Number of field names.</td>
</tr>

<tr>
<td>S</td>
<td>Number of extra NUMERIC RANGE fields.</td>
</tr>
</table>

ASTRPG = 1.1 * N/(6144 - (ASTRPPG * 2) -2)
= 1.1 * 191/(6144 - (877 * 2) -2)
= 1.1 * 191/4388 = 0.04 = 1 (rounded up)


Or:
ASTRPG = 1.1 * (A + S)/ASTRPG
= 1.1 * (6+ 13)/877
= 0.02 = 1 (rounded up)


===Calculating FVFPG===

The following numbers are estimated as part of ASTRPPG:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>V</td>
<td>Total space consumed by FEW-VALUED fields including overhead</td>
</tr>

<tr>
<td>B</td>
<td>Number of FEW-VALUED fields</td>
</tr>
</table>
FVFPG = 1.2 * V/(6144 - (ASTRPPG * 2) -2)
= 1.2 * 405/(6144 - (877 * 2) -2)
= 1.2 * 405/4388 = 0.11 = 1 (rounded up)


Or:
FVFPG = 1.2 * B/ASTRPPG = 1.2 * 65/877 = 0.08 = 1 (rounded up)


===Calculating MVFPG===

There are no MANY-VALUED, FRV, or CODED fields, but a minimum of one page must be allocated to each Table A section. Therefore:
 MVFPG = 1


==Sample Table B calculations==
<table>
<tr class="head">
<th>Field</th>
<th>Bytes required per record</th>
</tr>

<tr>
<td>FULL NAME</td>
<td>23</td>
</tr>

<tr>
<td>SSN</td>
<td> 4</td>
</tr>

<tr>
<td>AGE </td>
<td> 2</td>
</tr>

<tr>
<td>SALARY</td>
<td> 8</td>
</tr>

<tr>
<td>DEPT</td>
<td> 6</td>
</tr>

<tr>
<td>Overhead</td>
<td> 5</td>
</tr>

<tr class="head">
<td></td>
<th>R = 48</th>
</tr>
</table>

===Calculating BRECPPG===
BRECPPG = 1.1 * (6144 - 4)/R = 1.1 * 6140/48 = 140.7 = 141 (rounded up)


===Calculating BRESERVE===

<var>BRESERVE</var> is equal to <code>R</code>, above. Therefore:
BRESERVE = R = 48


===Calculating BSIZE===
BSIZE = 1.2 * (Total # of Records)/BRECPPG
= 1.2 * 90000/141 = 765.9 = 766 (rounded up)


==Calculating the file size multiplier example==
N = (# of Records in the file)/(8 * 6144)
= 90000/49152 = 1.83 = 2 (rounded up)


==Sample Table C calculations==
<table>
<tr class="head">
<th>Field name</th>
<th>Vu pairs</th>
<th>Vn pairs</th>
<th>Vr entries</th>
</tr>

<tr>
<td>SSN</td>
<td align="right">90000</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>AGE (KEY)</td>
<td> </td>
<td align="right">55</td>
<td> </td>
</tr>

<tr>
<td>AGE (NUM RANGE)</td>
<td> </td>
<td align="right">55</td>
<td align="right">22</td>
</tr>

<tr>
<td>SALARY</td>
<td> </td>
<td align="right">20000</td>
<td align="right">52</td>
</tr>

<tr>
<td>DEPT</td>
<td> </td>
<td align="right">10</td>
<td> </td>
</tr>

<tr>
<td>TOTAL</td>
<td align="right">90000</td>
<td align="right">20120</td>
<td align="right">74</td>
</tr>
</table>

===Calculating CSIZE===
CSIZE = 1.2 * ((14*Vu) + 7 * (N+1)(Vn+Vr)) / (6144-4)
= 1.2 * ((14*90000) + 7 * (3)(20120+74)) / 6140 = 330 (rounded up)


==Sample Table D calculations==

===Calculating Ordered Index space===

The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>NE </td>
<td>Number of distinct values stored in the field.</td>
</tr>

<tr>
<td>AB </td>
<td>Average number of records per value per segment..</td>
</tr>

<tr>
<td>OIB </td>
<td>Total Ordered Index B-tree entry lengths.</td>
</tr>

<tr>
<td>LOa </td>
<td>Leaf page overhead.</td>
</tr>

<tr>
<td>LP</td>
<td>Leaf node pages.</td>
</tr>

<tr>
<td>OI </td>
<td>Ordered entry B-tree pages for the field.</td>
</tr>
</table>

 
<table>
<tr class="head">
<th rowspan="2">Field name</th>
<th colspan="3">Values in: </th>
</tr>

<tr>
<th>Category A</th>
<th>Category B</th>
<th>Category C</th>
</tr>

<tr>
<td>LAST NAME</td>
<td align="right">60000</td>
<td align="right">5000</td>
<td align="right">500</td>
</tr>
</table>

====Calculating total Ordered Index B-tree entry lengths====

AV = Average Value Length + 1 = 11 + 1 = 12

NE = 65500

ENa = Category A * (AV + 3) = 60000 * (12 + 3) = 900000

AB = 2

ENb = Category B * (AV + (2 * AB) + (2 * N))
= 5000 * (12 + (2 * 2) + (2 * 2)) = 100000

ENc = Category C * (AV + (5 * N)) = 500 * (12 + (5 * 2)) = 11000


====Calculating Ordered Index B-tree overhead====

The final values for LOe, LP, and OI are rounded up:
LOe = 6144 * (LRESERVE/100) = 6144 * (15/100) = 922

AE = OIB / NE = 1011000 / 65500 = 15

LOmin = 2 * (6144 / AE) = 2 * (6144 / 15) = 819

LOa = max(LOe, LOmin) = max(922, 819) = 922

LP = OIB / (6144 - 24 - LOa) = 1011000 / (6144 - 24 - 922) = 195

OI = LP * 1.01 = 195 * 1.91 = 197


===Calculating index list space===

This example assumes 2 segments containing 45,000 records each. 
<table>
<tr class="head">
<th>If a field name = value pair appears in...</th>
<th> It falls into category... </th>
</tr>

<tr>
<td>Fewer than 900 (0.02 * 45000) records</td>
<td>A</td>
</tr>

<tr>
<td>More than 900 records</td>
<td>B</td>
</tr>
</table>

For each value, the number of category A bytes required (<code>T'</code>) is calculated using the following equation:
T'= 2 + (2 * (Number of Records Containing the Pair))


The number of category B pages required for each field is equal to the number of distinct values of that field. For each <var>NUMERIC RANGE</var> value, the extra number of pages required equals ten times the number of significant digits, plus two.

The following calculations use these variables:
<table>
<tr class="head">
<th>Value</th>
<th>Equals...</th>
</tr>

<tr>
<td>T </td>
<td>Category A bytes</td>
</tr>

<tr>
<td>A </td>
<td>Total number of pages in Category A</td>
</tr>

<tr>
<td>B </td>
<td>Total number of pages (or values) in Category B</td>
</tr>

<tr>
<td>C </td>
<td>Total number of extra numeric range pages</td>
</tr>
</table>

<table>
<caption>Values for segment 1</caption>
<tr class="head">
<th>Field name</th>
<th>Number of distinct values</th>
<th>Records per value</th>
<th>Category A bytes</th>
<th>Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>

<tr>
<td>AGE (KEY)</td>
<td>55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>AGE (NR)</td>
<td>55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td>22</td>
</tr>

<tr>
<td>SALARY (NR)</td>
<td>20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td>52</td>
</tr>

<tr>
<td>LAST NAME</td>
<td>498</td>
<td>5</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>(ORD CHAR)</td>
<td>2</td>
<td>1500</td>
<td> </td>
<td>2</td>
<td> </td>
</tr>

<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>PERS</td>
<td>1</td>
<td>40000</td>
<td> </td>
<td>1</td>
<td> </td>
</tr>

<tr>
<td>ACCT</td>
<td>0</td>
<td>0</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>Other values</td>
<td>8</td>
<td>625</td>
<td>8(2+2(625))</td>
<td> </td>
<td> </td>
</tr>

<tr class="head">
<td colspan=3> </td>
<th>T1 = 326216</th>
<th>B1 = 3</th>
<th>C1 = 74</th>
</tr>
</table>

====Calculations for segment 1====
X = 6144 * (1-(DRESERVE / 100)) = 6144 * 0.85 = 5222

A1 = T1 / X = 326216 / 5222 = 63 (Rounded up)


<table>
<caption>Values for segment 2</caption>
<tr class="head">
<th>Field name</th>
<th>Number 
of distinct values</th>
<th>Records per value</th>
<th>Category A bytes</th>
<th>Category B bytes</th>
<th>Extra NUM RANGE pages</th>
</tr>

<tr>
<td>AGE (KEY)</td>
<td>55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>AGE (NR)</td>
<td>55</td>
<td>818.2</td>
<td>55(2+2(818.2))</td>
<td> </td>
<td>22</td>
</tr>

<tr>
<td>SALARY</td>
<td>20000</td>
<td>2.25</td>
<td>20000(2+2(2.25))</td>
<td> </td>
<td>52</td>
</tr>

<tr>
<td>LAST NAME</td>
<td>498</td>
<td>5</td>
<td>498(2+(2*5))</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>(ORD CHAR)</td>
<td>2</td>
<td>1500</td>
<td> </td>
<td>2</td>
<td> </td>
</tr>

<tr>
<td>DEPT</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>PERS</td>
<td> </td>
<td>0</td>
<td>0</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>ACCT</td>
<td>1</td>
<td>10000</td>
<td> </td>
<td>1</td>
<td> </td>
</tr>

<tr>
<td>Other values</td>
<td>8</td>
<td>4375</td>
<td> </td>
<td>8</td>
<td> </td>
</tr>

<tr class="head">
<td colspan=3></td>
<th>T2 = 316200</th>
<th>B2 = 11</th>
<th>C2 = 74</th>
</tr>
</table>

====Calculations for segment 2====
A2 = T1 / X = 316200 / 5222 = 60.5 = 61 (Rounded up)


===Total index list space===
IT = A1 + B1 + C1 + A2 + B2 + C2 + 2
= 63 + 3 + 74 + 61 + 11 + 74 + 2 = 288


===Determining F (space required for preallocated fields)===

If you have defined any preallocated fields in a file, <var class="product">Model 204</var> uses one Table D page for the record description. Because two of the fields in this example are preallocated (have the OCCURS attribute):
F = 1


===Calculating space required for procedures===

The file holds approximately 50 procedures with 20-character names. This examples does not use procedure security. The calculations in this section use the following variables:
<table>
<tr class="head">
<th>This value</th>
<th>Equals...</th>
</tr>

<tr>
<td>P </td>
<td>Number of procedures.</td>
</tr>

<tr>
<td>S </td>
<td>Average size of procedure entry.</td>
</tr>

<tr>
<td>K </td>
<td>Number of blocks of pages.</td>
</tr>

<tr>
<td>Q </td>
<td>Number of pages required for ACT.</td>
</tr>
</table>

P = 50

S = Name length + Overhead = 20 + 34 = 54

PDSTRPPG = 6144 / s = 6144 / 54 = 113.7 = 113 (Rounded down)

PDSIZE = 1.4 (P/PDSTRPPG) = 1.4 * (50/113) = 0.61 = 1 (Rounded up)

K = 1

Q = 0


===Calculating space required for reserved area===
DEST = OIT + IT + F + P + (K * PDSIZE) + Q
= 197 + 288 + 1 + 50 + 1 + 0 = 537

DPGSRES = min(DEST/50 + 2, 40) = min(537/50 + 2, 40)
= 13 (rounded up)


===Calculating DSIZE===
DSIZE = DEST + DPGSRES = 537 + 13 = 550


==Sample Table E calculations==

===Sizing Table E===

You can set the <var>ESIZE</var> parameter when the file is created to the default of 0, meaning that no Large Object data can be stored in the file. If you plan to have Large Object data in the file, you must set the ESIZE to a minimum value of 20. 

When you initialize a file with ESIZE set to 20 or greater, the first 17 pages of Table E are used for Table E internal structures. Immediately after initialization the other Table E parameters are: <code>EHIGHPG=16</code> and <code>EPGSUSED=17</code>.

Each time you store another Large Object the data begins on the next available Table E page. There is no reuse capability for Table E. So, you must estimate in advance the size of the Large Object data and how many pages you will need.

===Calculating Table E size===
<ul>
<li>The first page of Table E is reserved for the existence bitmap of page map page numbers. </li>

<li>The next fifteen pages of Table E are reserved for the page map pages.</li>

<li>The seventeenth page is the first bitmap page. Subsequent bitmap pages are allocated as needed and are therefore intermingled with the Large Object data pages. </li>
</ul>

Use the following steps and formulas to determine how many Table E pages you need:
<ol>
<li>
Calculate the pages-to-hold-data as:

For each Large Object field, add the Large Object field data bytes to 6139, then divide by 6140 and multiply by the number of Large Object fields. For example, if a Large Object field is 7000 bytes, it will require two Table E pages. Using this calculation, determine the total pages-to-hold-data.

Example: 5,000 Large Object fields with a length of 7000:
7000/6144 rounded up = 2 pages multiplied by 5,000 fields = 10,000 pages-to-hold-data
</li>

<li>Calculate the pages-to-hold-bitmaps as:
17 + (pages-to-hold-data /49152) + 1
</li>

<li>Calculate the ESIZE setting you need as:
pages-to-hold-data + pages-to-hold-bitmaps + 2
</li>
</ol>

==Calculating sample total file size==

The total file size for this example is:
File-size = 8 + ASIZE + BSIZE + CSIZE + DSIZE
= 8 + 3 + 766 + 330 + 550
= 1657 pages (237 tracks on a 3380)


==Space calculation worksheet==

This worksheet lists all the equations used in this topic to calculate the number of pages needed for a <var class="product">Model 204</var> file. 
1. Model 204 Usable Page Size constant = 6144


===Calculate Table A size===

Use the following variables in Equations 2 through 6:
<table>
<tr class="head">
<th>Value</th>
<th>Equals...</th>
</tr>

<tr>
<td>A</td>
<td>Number of field names. </td>
</tr>

<tr>
<td>B </td>
<td>Number of FEW-VALUED FRV or CODED values. </td>
</tr>

<tr>
<td>C </td>
<td>Number of MANY-VALUED FRV or CODED values.</td>
</tr>

<tr>
<td>D </td>
<td>Maximum number of digits in a NUMERIC RANGE field + 3. </td>
</tr>

<tr>
<td>S</td>
<td>Sum of all D's for all NUMERIC RANGE fields. </td>
</tr>

<tr>
<td>T </td>
<td>Total number of strings: A + B + S + C. </td>
</tr>

<tr>
<td>V </td>
<td>Space needed by FEW-VALUED FRV or CODED values and value overhead. </td>
</tr>

<tr>
<td>W</td>
<td>Space needed by MANY-VALUED FRV or CODED values and value overhead. </td>
</tr>

<tr>
<td>N </td>
<td>Space needed by field names and names overhead. </td>
</tr>
</table>

<ul>
<li>L represents the length of each string:
2. L = (V + N + W) / T
</li>

<li>The ASTRPPG parameter represents the character strings per Table A page:
3. ASTRPPG = 6144 / L 
</li>

<li>The ATRPG parameter represents the number of attribute pages:
4. ATRPG = 1.1 * N / (6144 - (ASTRPPG * 2) - 2)


or
ATRPG = 1.1 * (A + S) / ASTRPPG
</li>

<li>The FVFPG parameter represents the number of FEW-VALUED pages:
5. FVFPG = 1.2 * V / (6144 - (ASTRPPG * 2) - 2)


or
FVFPG= 1.2 * (B / ASTRPPG)
</li>

<li>The MVFPG parameter represents the number of MANY-VALUED pages:
6. MVFPG = 1.2 * (V / (6144 - (ASTRPPG * 2) - 2) )


or
MVFPG = 1.2 * (B / ASTRPPG)
</li>

<li>The ASIZE parameter represents the size of Table A:
7. ASIZE = ATRPG + FVFPG + MVFPG (calculated by Model 204)
</li>
</ul>

===Calculate Table B size===

Use the following variable in Equations 8 through 10:
<table>
<tr class="head">
<th>Value</th>
<th>Equals...</th>
</tr>

<tr>
<td>R</td>
<td>Average record size. </td>
</tr>
</table>

<ul>
<li>The BRECPPG parameter represents table records per page:
8. BRECPPG = 1.1 * 6140 / R
</li>

<li>The BSIZE parameter represents the size of Table B:
9. BSIZE = 1.2 * (Total-number-of-records / BRECPPG)

10. BRESERVE = Reserved Table B space
</li>
</ul>

===Calculate Table C size===
<ul>
<li>The N variable represents the file size multiplier:
11. N = Number-of-records-in-the-file / (8 * Page-size)

12. VU = total number of pairs in category U

13. VN = total number of pairs in category N

14. VR = total number of extra entries for all NUM RANGE retrieval fields
</li>

<li>The CSIZE parameter represents the size of Table C:
15. CSIZE = 1.2 * ((14 * VU) + 7 * (N+1)(VN + VR)) / 6140
</li>
</ul>

===Calculate Table D size===

====Estimate the size of the Ordered Index====
<ul>
<li>Use the following variables in Equations 16 through 24:
<table>
<tr class="head">
<th>Value</th>
<th>Equals...</th>
</tr>

<tr>
<td>NE</td>
<td>Total number of distinct values in the ORDERED field</td>
</tr>

<tr>
<td>N</td>
<td>Number of segments in the file</td>
</tr>
</table>

16. AV = the estimated av. length of ORDERED values + 1

17. ValA = number of values in Category A

18. ValB = number of values in Category B

19. ValC = number of values in Category C
</li>

<li>ENa = The total length of the Ordered Index entries placed in category A:
20. ENa = ValA * (AV + 3)
</li>

<li>ENb = The total length of the Ordered Index entries placed in category B:
21. ENb = ValB * (AV + (2 * AB) + (2 * N)
</li>

<li>ENc = The total length of the Ordered Index entries placed in category C:
22. ENc = ValC * (AV + (5 * N))
</li>

<li>The OIB parameter represents the total length of all Ordered Index entries:
23. IB = ENa + ENb + ENc =
</li>

<li>The value of LOe represents the expected leaf page overhead:
24. LOe = 6144 * (LRESERVE / 100)


Or:
LOe = 6144 * ((100 - SPLITPCT) / 100)
</li>

<li>The value of AE represents the average number of bytes per Ordered Index entry:
25. AE = OIB / EN
</li>

<li>The value of LOmin represents the minimum leaf page overhead:
26. LOmin = 2 * 6144 / AE
</li>

<li>The value of LOa represents the leaf page overhead:
27. LOa = max(LOe, LOmin)
</li>

<li>The value of LP represents the number of leaf pages required:
28. LP = OIB / (6120 - LOa)
</li>

<li>The value of OI represents the size of the Ordered Index for each field:
29. OI = (LP * 1.01)
</li>

<li>OIT = Total size of the Ordered Index:
30. OIT = OI1 + OI2 + ... + OI<var class="term">n </var>
</li>
</ul>

====Calculate index list space====
:31. DRESERVE = % of space reserved for Table D expansion

<ul>
<li>The value of T represents the number of bytes required for category A fieldname = value pairs:
32. T = 2 + (2 * (no. of records with fieldname=value pair))
</li>

<li>The value of X represents the total number of bytes available per Table D page:
33. X = 6144 * (1 - (DRESERVE / 100))
</li>

<li>The value of A represents the total number of pages required by the category A pairs for the segment:
34. A = T / X

35. B = total number of pages required by pairs in category B
</li>

<li>The value of T' represents the extra bytes required for NUMERIC RANGE fields:
36. T' = 2 + (2 * (Number of Records Containing the Field))

37. B' = number of extra values

38. T" = sum of all values of T'

39. B" = sum of all values of B'
</li>

<li>The value of C represents the total extra pages required:
40. C = (T" / X) + B
</li>

<li>The value of I represents the index list space for each segment:
41. I = A + B + C
</li>

<li>The value of IT represents the total index list space required:
42. IT = A1 + B1 + C1 + ... + An + Bn + Cn + N
</li>
</ul>

====Calculate space for preallocated fields====
:43. F = number of Table D pages for preallocated fields


====Calculate the size of the procedure dictionary====
:44. P = total number of procedures


:45. S = average size of procedure entry


<ul>
<li>PDSTRPPG = the maximum number of procedure entries per procedure dictionary page:
46. PDSTRPPG = 6144 / S

47. PDSIZE = 1.4 * P / PDSTRPPG
</li>
</ul>

====Calculate the size of the ACT====
<ul>
<li>The value of LE represents the length of entries for each user class:
48. LE = 4 + (2 * NPCLASS)
</li>

<li>The value of LET represents the total length of the user class entries:
49. LET = LE1 + LE2 + ... + LE<var class="term">n</var>
</li>

<li>The value of Q represents the number of pages required for the ACT:
50. Q = LET / 6144
</li>
</ul>

====Calculate the final size of Table D====
:51. DEST = OIT + IT + F + P + (K * PDSIZE) + Q


:52. If DEST < 1900, DPGSRES = DEST/50 + 2


:Or, if <code>DEST >= 1900</code> and <code>DPGSRES = 40</code>:
:53. DSIZE = OIT + IT + F + P + (K * PDSIZE) + Q + DPGSRES

:or:
:DSIZE = DEST + DPGSRES


===Calculate the final size for Table E===

Calculate <var>ESIZE</var>, <var>EHIGHPG</var>, and <var>EPGSUSED</var> as described above in [[#Sizing Table E|Sizing Table E]].

===Calculate the total pages required===
Total pages required = 8 + ASIZE + BSIZE + CSIZE + DSIZE + ESIZE


==File description worksheet==

Use the following sample worksheet when compiling a list of parameters to be set during file creation. Values for many of the parameters are computed from the formulas shown in this topic.
Other parameters are discussed in their [[List of Model 204 parameters#List of parameters|individual M204wiki pages]].

File Description Sheet

File Name ____________________________________________

Record Security Field Name ___________________________

Sort/Hash Key Field Name _____________________________

Parameter Value Parameter Value

FILEORG ____________ CSIZE ____________
FOPT ____________ DRESERVE ____________
FRCVOPT ____________ DPGSRES ____________
ASTRPPG ____________ PDSIZE ____________
ATRPG ____________ PDSTRPPG ____________
FVFPG ____________ DSIZE ____________

MVFPG ____________ DAUTOINC ____________
OPENCTL ____________
BRECPPG ____________ PRIVDEF ____________
BRESERVE ____________ PRCLDEF ____________
BPGPMSTR ____________ SELLVL ____________
BPFPOVFL ____________ READLVL ____________
BEXTOVFL ____________ UPDTVL ____________
BREUSE ____________ ADDLVL ____________
BSIZE ____________ ESIZE ____________
BAUTOINC ____________
BRLIMSZ ____________ XSIZE ____________
RECROPT ____________ XAUTOINC ____________



</div> 

[[Category:Model 204 files]]

SIRFACT command

2022-11-22T23:54:33Z

Goff: needed a space

<div class="toclimit-2">
Note: This is a <var class="product">[[Sirius Mods]]</var>-only command prior to Version 7.5 of <var class="product">[[Model 204]]</var>.

The <var>SIRFACT</var> command invokes the <var class="product">[[SirFact]]</var> post hoc debugging facility.
<var>SIRFACT</var> has a set of several subcommands that lets you tailor, trap early,
and otherwise maximize the error information dumped for <var class="product">Model 204</var> debugging purposes.

<var>SIRFACT</var> commands can also be issued
as operator commands, that is, on the Online virtual console under VM or
as the response to the <var>HALT</var> message under z/OS.

===SIRFACT command syntax===
SIRFACT subcomm operands 
Where:
<ul>
<li><var class="term">subcomm</var> is one of the subcommands listed in the table below.

<li><var class="term">operands</var>
is one or more operands specific to the <var>SIRFACT</var> subcommand that is being invoked.
</ul>

The <var>SIRFACT</var> subcommands are summarized below and described in detail
in the sections that follow.

You invoke a subcommand with the <code>SIRFACT</code> prefix (for example, <var>SIRFACT CANCEL</var>, <var>SIRFACT MAXDUMP</var>).

<table class="thJustBold">
<caption>SIRFACT subcommand summary</caption>
<tr><th>CANCEL</th>
<td>Indicates which return codes from $functions should result in request cancellation. Can be abbreviated <var>CAN</var>.</td></tr>

<tr><th>DISPLAY</th>
<td>Shows the currently active <var>SIRFACT</var> subcommands. Can be abbreviated <var>DISP</var>.</td></tr>

<tr><th>DUMP</th>
<td>Indicates which request cancellations should cause a <var class="product">SirFact</var> dump to be taken and where the dump is to go.</td></tr>

<tr><th>IGNORE</th>
<td>Indicates which request cancellation error messages are not to produce <var class="product">SirFact</var> dumps. Can be abbreviated <var>IGN</var>.</td></tr>

<tr><th>MAXDUMP</th>
<td>Places limits on the number of <var class="product">SirFact</var> dumps that will be taken. Thedefault system limit is 0 so a <var>SIRFACT MAXDUMP</var>
must be issued to get any SirFact dumps. Can be abbreviated <var>MAXD</var>.</td></tr>

<tr><th>NOCANCEL</th>
<td>Indicates that certain return codes from $functions should not result in request cancellation. Cancels out the effect of a <var>SIRFACT CANCEL</var> command. Can be abbreviated <var>NOCAN</var>.</td></tr>

<tr><th>NODUMP</th>
<td>Indicates that certain request cancellations should not result in <var class="product">SirFact</var> dumps being produced. Cancels out the effect of a <var>SIRFACT DUMP</var> command.</td></tr>

<tr><th>NOIGNORE</th>
<td>Indicates that certain request cancellation error messages are to produce <var class="product">SirFact</var> dumps. Cancels out the effect of a <var>SIRFACT IGNORE</var> command. Can be abbreviated <var>NOIGN</var>.</td></tr>

<tr><th>QUIESCE</th>
<td>Facilitates updates of APSY subsystem procedures while the subsystem is up and in use.</td></tr>

<tr><th>RECNDUMP</th>
<td>Establishes the number of record numbers from each found set or [[$lists|$list]] to be dumped. Can be abbreviated <var>RECND</var>.</td></tr>

<tr><th>RESUME</th>
<td>Stops the effect of a <var>SIRFACT QUIESCE</var> command and returns the subsystem to normal operation.</td></tr>

<tr><th>SNAP</th>
<td>Requests that a <var class="product">SirFact</var> dump be taken for another thread.</td></tr>
</table>

Some <var>SIRFACT</var> subcommands make use of the wildcard characters
asterisk (<code>*</code>), question mark (<code>?</code>), and
double quotation mark (<code>"</code>):
<table class="thJustBold">
<tr><th>?</th>
<td>Represents any single character.</td></tr>

<tr><th>*</th>
<td>Represents any string of characters.</td></tr>

<tr><th>"</th>
<td>The escape flag that allows special characters to bypass wildcard translation.</td></tr>
</table>

The following examples illustrate the use of the wildcard characters:
<ul>
<li>This command requests a display of all the <var>SIRFACT CANCEL</var> subcommands in
effect for $functions that begin with the letters "$LIST":
<nowiki>SIRFACT DISPLAY CAN $LIST*
</nowiki> </li>

<li>This command indicates that a <var class="product">SirFact</var> dump should be created for any request
cancellation errors that occur in a subsystem with a name that is seven
characters long and ends in the letters "CUST":
<nowiki>SIRFACT DUMP DUMPROC DUMP.+T SUBSYS ???CUST
</nowiki> </li>

<li>This command indicates that a <var class="product">SirFact</var> dump should be created for any request
cancellation errors that occur for user <code>?WEIRD</code>.
The double-quote (<code>"</code>) is required to prevent the question
mark (<code>?</code>) from being interpreted as a wildcard character:
<nowiki>SIRFACT DUMP DUMPROC DUMP.+T USER "?WEIRD
</nowiki> </li>
</ul>

==SIRFACT CANCEL==
The <var>SIRFACT CANCEL</var> subcommand requires a parameter that indicates
the $function to which it applies, followed by return codes that should
be intercepted and cause request cancellation when returned by the function.

===Syntax===
SIRFACT CANCEL function returncodes

<table>
<tr><th>function</th>
<td>The name of the function to which the command applies. This name cannot contain wildcard characters.</td></tr>

<tr><th>returncodes</th>
<td>A blank delimited set of return codes that will be intercepted and cause request cancellation.</td></tr>
</table>

The subcommand <var>CANCEL</var> can be abbreviated to <var>CAN</var>.

===Examples===
This command causes cancellation of any request that gets a return code of 1 from <var>$Setg</var>:
SIRFACT CANCEL $SETG 1


This command causes cancellation of any request that gets a return code
of -3, -5, -6, or -7 from <var>$ListAdd</var>:
SIRFACT CAN $LISTADD -3 -5 -6 -7


See also [[#Sample settings per $function|Sample settings per $function]], below. 

===Usage===
<ul>
<li>The rationale for <var>SIRFACT CANCEL</var> is that certain return codes from certain
$functions indicate programming errors or severe environmental
problems (return code 1 from <var>$Setg</var>, for example), so these codes should result in
immediate request cancellation, even in ad hoc or development procedures.
For example, a return code of -6 from <var>$Listloc</var>, indicating an invalid $list identifier, suggests a severe problem in a program.
Even in an ad hoc procedure, there is little reason to go on after such an error.

There is a distinction, however, between cancelling the request and creating
a <var class="product">SirFact</var> dump for the error.
A dump would generally not be desirable
for errors in ad hoc or development procedure errors.
Because of this, the creation of dumps is controlled by a different <var>SIRFACT</var> subcommand,
the <var>SIRFACT DUMP</var> subcommand ([[#dump|SIRFACT DUMP]]).
This subcommand limits the creation of dumps to specific subsystems, procedures, or users. </li>

<li>It is strongly recommended that the collection of <var>SIRFACT CANCEL</var> commands in the development and test regions match
the collection in production.
Otherwise, things that work in development might not work in test or production and vice versa.
It can't be overemphasized that <var>SIRFACT CANCEL</var> should be used for return codes
that indicate programming errors or severe environmental
problems that are as invalid in development as in production.
In the rare cases where such a return code might be considered "normal"
or at least acceptable in a chunk of code, the <var>[[SirFact SOUL statements#SirFact statement|SirFact]]</var> statement can be used to temporarily disable <var class="product">SirFact</var>
$function error trapping for a specific user. </li>

<li>A <var>SIRFACT CAN</var> can be disabled with a <var>SIRFACT NOCAN</var> command for the same function. </li>

<li>If multiple <var>SIRFACT CANCEL</var>s (or <var>NOCANCEL</var>s) are issued
for the same $function, only the last one is used.
So the following would only trap return codes of -6 from <var>$Listloc</var>:
SIRFACT CAN $LISTLOC -5
SIRFACT CAN $LISTLOC -6


To trap return codes of -5 and -6 from <var>$Listloc</var>, you must issue: 
SIRFACT CAN $LISTLOC -5 -6
</li>

<li>The implementation of <var>SIRFACT CANCEL</var> is very efficient and should
cause no measurable performance degradation in the execution
of functions for which return codes are being trapped.
Performance of the <var class="product">SirFact</var> error trapping is certainly significantly more efficient
than testing for the same errors using <var class="product">SOUL</var>. </li>

<li>Whether or not a <var class="product">SirFact</var> dump is produced for an error trapped
by the <var>SIRFACT CANCEL</var> command, these trapped errors are always
accompanied by a message indicating the procedure and line number
in which the error occurred, as well as the name of the function causing
the error and the function arguments.

<var class="product">SirFact</var> will use any one of
several mechanisms to collect the procedure and line number information,
each of them having some cost in either QTBL, STBL, VTBL, or CCATEMP space.
For a discussion of the costs and tradeoffs of the various
approaches, see the [[SirFact system parameters#factprm|SIRFACT parameter]]. </li>

<li>It is strongly recommended that you set SIRFACT CANCEL as aggressively as possible.
If a <var>SIRFACT CANCEL</var> should cause a problem with "dirty" use of $functions, the preferred solution
is to clean up the use of the $functions.

The next best solution is to
wrap the "dirty" function calls in a <var>SIRFACT OFF</var>/<var>SIRFACT ON</var> bracket. 

Eliminating the <var>SIRFACT CANCEL</var> for a value is the least preferable solution, because:
<ul>
<li>It reduces the benefit of <var>SIRFACT CANCEL</var> to encourage good programming practices.</li>

<li>It eliminates the ability of <var>SIRFACT CANCEL</var> to catch unintentional misuses of $functions.</li>
</ul></li>
</ul>

===Sample settings per $function===
The following is a list of "reasonable" <var>SIRFACT CANCEL</var> commands for most Onlines:
<nowiki>SIRFACT CAN $BLDPROC 1
SIRFACT CAN $DATECHG *
SIRFACT CAN $DATECNV *
SIRFACT CAN $DATEDIF 99999999
SIRFACT CAN $EDIT '' '#'
SIRFACT CAN $INCRG 1 2
SIRFACT CAN $LSTPROC 4
SIRFACT CAN $RDPROC 2
SIRFACT CAN $SETG 1
SIRFACT CAN $UNBIN ''
SIRFACT CAN $UNFLOAT ''
SIRFACT CAN $UNPACK ''
SIRFACT CAN $LISTADD -3 -5 -6 -7
SIRFACT CAN $LISTADDI -3 -5 -6 -8
SIRFACT CAN $LISTCNT -5 -6
SIRFACT CAN $LISTCPY -3 -5 -6
SIRFACT CAN $LISTDEL -5
SIRFACT CAN $LISTFIND -5 -6 -7 -8
SIRFACT CAN $LISTILN -5 -6 -7
SIRFACT CAN $LISTIMG -5 -6 -8
SIRFACT CAN $LISTINF -5 -6 -7 -9
SIRFACT CAN $LISTINFI -5 -6 -7 -8
SIRFACT CAN $LISTINS -3 -5 -6 -7 -9
SIRFACT CAN $LISTINSI -3 -5 -6 -8 -9
SIRFACT CAN $LISTLOC -3 -5 -6 -7 -9
SIRFACT CAN $LISTLUP -3 -5 -6 -7 -9
SIRFACT CAN $LISTMOVE -5 -6
SIRFACT CAN $LISTOVL -5 -6 -7 -9
SIRFACT CAN $LISTREM -5 -6 -7
SIRFACT CAN $LISTRST -13
SIRFACT CAN $LISTSAV -3 -5 -13
SIRFACT CAN $LISTSAVE -3 -5 -13
SIRFACT CAN $LISTSAVL -3 -5 -6
SIRFACT CAN $LISTSRT -3 -5 -6 -10 -12
SIRFACT CAN $LISTSORT -3 -5 -6 -10 -12
SIRFACT CAN $LISTSUB -3 -5 -6 -7 -9
SIRFACT CAN $LIST_GLOBAL -3 -14 -15
SIRFACT CAN $LIST_CONV_ITEM -5 -6 -7
SIRFACT CAN $LIST_COPY_ITEMS -3 -5 -6 -7 -8
SIRFACT CAN $LIST_DIFF_ITEM -3 -5 -6 -7
</nowiki>

===Special-case settings===
As might be apparent from the examples above, there are a few $functions
for which the return values are special-cased.
These are:
<table>
<tr><th><var>$Datechg</var></th>
<td>On errors, this function will return a number of asterisks (*) equal to the length of the second parameter (the output format). <var class="product">SirFact</var>
interprets a <code>SIRFACT CANCEL $DATECHG '*'</code> to require request cancellation for any <var>$Datechg</var> call that returns one or more asterisks.</td></tr>

<tr><th><var>$Datecnv</var></th>
<td>On errors, this function will return a number of asterisks (<tt>*</tt>) equal to the length of the first parameter (the input format). <var class="product">SirFact</var>
interprets a <code>SIRFACT CANCEL $DATECNV '*'</code> to require request cancellation for any <var>$Datecnv</var> call that returns one or more asterisks.</td></tr>

<tr><th><var>$Edit</var></th>
<td>On errors, this function will return a number of hashes (<tt>#</tt>) equal to the length of the second parameter (the edit mask). <var class="product">SirFact</var>
interprets a <code>SIRFACT CANCEL $EDIT '#'</code> to require request cancellation for any <var>$Edit</var> call that returns one or more hashes.</td></tr>

<tr><th><var>$Listinf</var></th>
<td><var>$Listinf</var> always returns a string value. To indicate an error, <var>$Listinf</var> returns a 2-digit string containing -5, -6, -7, or -9.
Yet, in theory at least, these values could also be reasonable values of $list items. <var>SIRFACT CANCEL</var> provides a work-around for this design flaw in <var>$Listinf</var>, because <var>SIRFACT CANCEL</var> will
not cause request cancellation when a cancellation value is actually a value in a $list item. <var>SIRFACT CANCEL</var> will only cause cancellation when the return value is truly the result of an error.</td></tr>
</table>

==SIRFACT DISPLAY==
The <var>SIRFACT DISPLAY</var> subcommand displays many of the <var>SIRFACT</var> subcommands currently in effect.

===Syntax===
SIRFACT DISPLAY [subcom [subset]]


<var>DISPLAY</var> can be abbreviated to <var>DISP</var>.

<table>
<tr><th>subcom</th>
<td>The name of the class of subcommands to which the display is to apply.

<var>SIRFACT DISPLAY</var> with no <var class="term">subcom</var> value displays all <var>SIRFACT</var> commands from the subcommand classes listed below that are currently in effect. 

Valid values for <var class="term">subcom</var> are: 
<table>
<tr><th><var>CANCEL</var></th>
<td>Displays active <var>SIRFACT CANCEL</var> commands. Can be abbreviated <var>CAN</var>.

<var>CANCEL</var> can be followed by a <var class="term">subset</var> value that can contain wildcards indicating the $functions for which <var>SIRFACT CANCEL</var> settings are to be displayed.
<var>SIRFACT NOCANCEL</var> commands are not displayed because these simply eliminate the <var>SIRFACT CANCEL</var>s for the specified $functions.</td></tr>

<tr><th><var>DUMP</var></th>
<td>Displays active <var>SIRFACT DUMP</var> and <var>NODUMP</var> commands.</td></tr>

<tr><th><var>IGNORE</var></th>
<td>Displays active <var>SIRFACT IGNORE</var> commands. Can be abbreviated <var>IGN</var>.

<var>IGNORE</var> can be followed by a <var class="term">subset</var> that can contain wildcards indicating the messages for which <var>SIRFACT IGNORE</var> settings are to be displayed.
<var>SIRFACT NOIGNORE</var> commands are not displayed because these simply eliminate the <var>SIRFACT IGNORE</var>sfor the specified messages.</td></tr>

<tr><th><var>MAXDUMP</var></th>
<td>Displays active <var>SIRFACT MAXDUMP</var> commands. Can be abbreviated <var>MAXD</var>.

<var>MAXDUMP</var> can be followed by a <var class="term">subset</var> indicating the type of limitto be displayed. This can be <var>TOTAL</var> or <var>USER</var>. 

A <code>SIRFACT DISPLAY MAXDUMP</code> output line is followed by a comment line that reports the number of <var class="product">SirFact</var> dumps taken since the <var class="product">Model 204</var> Online initialization. For example: 
SIRFACT DISPLAY MAXDUMP
SIRFACT MAXDUMP TOTAL 20
<nowiki>*</nowiki> 11 Number of dumps taken
</td></tr>

<tr><th><var>RECNDUMP</var></th>
<td>Displays active <var>SIRFACT RECNDUMP</var> command. Can be abbreviated <var>RECND</var>.</td></tr>
</table></td></tr>

<tr><th>subset</th>
<td>A string indicating which values of the indicated subcommand should be displayed.
For <code>SIRFACT DISPLAY CANCEL</code> and <code>SIRFACT DISPLAY IGNORE</code>, <var class="term">subset</var> can contain wildcard characters. For <code>SIRFACT DISPLAY MAXDUMP</code>, it must be a specific limit type.

<var class="term">subset</var> is ignored for <code>SIRFACT DISPLAY DUMP</code> and <code>SIRFACT DISPLAY RECNDUMP</code>.</td></tr>
</table>

===Usage===
The display format for the <var>SIRFACT DISPLAY</var> command repeats the format
of the <var>SIRFACT</var> commands that are used to set <var>SIRFACT</var> controls.
As such, they can be captured (for example with a <var>USE</var> statement) for subsequent reuse.

If no <var>SIRFACT</var> controls are in effect at all or for the
specific subcommand and subset requested, <var>SIRFACT DISPLAY</var> simply
returns without issuing any messages.

Examples of valid <var>SIRFACT DISPLAY</var> commands follow:
SIRFACT DISPLAY
SIRFACT DISPLAY CANCEL
SIRFACT DISPLAY CAN $LIST*
SIRFACT DISPLAY CANCEL $EDIT
SIRFACT DISPLAY DUMP
SIRFACT DISPLAY IGNORE
SIRFACT DISPLAY IGN MSIR.*
SIRFACT DISPLAY MAXDUMP
SIRFACT DISPLAY MAXD USER


==SIRFACT DUMP==
The <var>SIRFACT DUMP</var> subcommand indicates where <var class="product">SirFact</var> dumps are to
be taken and for which environments dumps are to be taken.
All <var class="product">SirFact</var> dumps are taken to procedures.

Information contained in a <var class="product">SirFact</var> dump is easily viewed using the
<code>FACT</code> subsystem, described in [[SirFact FACT subsystem]].
You can also use a set of $functions, as described in [[SirFact $functions]].

===Syntax===
SIRFACT DUMP procfile procname [criteria]


<table>
<tr><th>procfile</th>
<td>The name of the procedure file to which dumps are to be taken. If the procedure file is not open at the time a <var class="product">SirFact</var> dump is to be taken, the procedure file
is opened with the privileges required to create the dump (X'1239') and then closed after the dump.
If the procedure file is already open it must be open with the privileges required to take the dump, or the dump will not be taken.</td></tr>

<tr><th>procname</th>
<td>The name of the procedure to be created in <var class="term">procfile</var> for the <var class="product">SirFact</var> dump. <var class="term">procname</var> can be a simple literal string or it can contain special
substitution strings consisting of a plus sign (<tt>+</tt>) followed by a single character indicating what should be substituted into the dump procedure name.

Because <var class="product">SirFact</var> will never overwrite a procedure with the required procedure name, the use of substitution strings in <var class="term">procname</var> is strongly encouraged.
Procedure name substitution strings are described in greater detail in [[#procins|Procedure name substitutions]].</td></tr>

<tr><th>criteria</th>
<td>A list of blank-delimited selection criteria that indicate to which "environments" the <var>SIRFACT DUMP</var> command is to apply.
All these environments can also be specified on a <var>SIRFACT NODUMP</var> command and have the same meaning for that command. If <var class="term">criteria</var> is not specified, the <var>SIRFACT DUMP</var> (or <var>SIRFACT NODUMP</var>) command
applies to any request that receives a request cancellation message that is not being "ignored" by <var class="product">SirFact</var> ([[#ignore|SIRFACT IGNORE]]). Valid selection criteria are:
<table>
<tr><th><var>FILE</var></th>
<td>The procedure file to which the <var>DUMP</var> rule applies. The file name can contain wildcard characters. <var>FILE</var> refers to the file in which the outer procedure being evaluated resides, whether or not the I<var>NCLUDE</var> was done in gr-
oup context.</td></tr>

<tr><th><var>IODEV</var></th>
<td>The <var>IODEV</var> number to which the <var>DUMP</var> rule applies.</td></tr>

<tr><th nowrap>msg number</th>
<td>The <var class="product">Model 204</var> message number to which the <var>DUMP</var> rule applies. This message number must start with either a <code>M204.</code> for standard <var class="product">Model 204</var>
error messages, <code>MSIR.</code> for <var class="product">SirMods</var> error messages or <code>USER.</code> for site-specific error messages. The message number could also be <code>SNAP</code>,
which means that the rule applies to <var class="product">SirFact</var> dumps taken as a result of <var>SIRFACT SNAP</var> commands. For example,
this sends all dumps for subscript range errors to file <code>SUBSERR</code>:
SIRFACT DUMP SUBSERR OUCH.+P.+T M204.0553

And this sends all dumps resulting from <var>SIRFACT SNAP</var> commands to file <code>FACTSNAP</code>:
SIRFACT DUMP FACTSNAP OOCH.+P.+T SNAP
</td></tr>

<tr><th><var>PROC</var></th>
<td>The procedure name to which the <var>DUMP</var> rule applies. The procedure name can contain wildcard characters.
<var>PROC</var> refers to the outer procedure being evaluated, not the Included procedure in which the error occurred.</td></tr>

<tr><th><var>SUBSYS</var></th>
<td>The APSY subsystem to which the <var>DUMP</var> rule applies. The subsystem can contain wildcard characters.</td></tr>

<tr><th><var>USER</var></th>
<td>The userid to which the <var>DUMP</var> rule applies. The userid can contain wildcard characters.</td></tr>
</table>

For a <var>DUMP</var> rule to apply to an error being handled by <var class="product">SirFact</var>, the error time environment must match all criteria specified in the <var>SIRFACT DUMP</var> command.</td></tr>
</table>

===Usage===
<ul>
<li><var class="product">SirFact</var> dumps are taken for any request cancellation message that is not being "ignored" ([[#ignore|SIRFACT IGNORE]]) if the following criteria are met:
<ul>
<li><var>SIRFACT MAXDUMP</var> has been set. </li>

<li>None of the <var>SIRFACT MAXDUMP</var> limits has been exceeded. </li>

<li>There is a <var>SIRFACT DUMP</var> command for which the current thread matches all criteria. </li>

<li>The dump procedure file as determined by the appropriate <var>SIRFACT DUMP</var>
command is already open with the correct privileges (any superset
of X'1239') or can be opened with the correct privileges. </li>

<li>The output procedure as determined by the appropriate <var>SIRFACT DUMP</var> command does not already exist. </li>
</ul></li>

<li>Dumps are taken for request cancellations resulting from <code>M204.1332: LONG REQUEST</code> messages,
even though technically this message is not a request cancellation message.
Note that the dump will only be taken if the user is not given a chance
to continue with a <code>DO YOU REALLY WANT TO CONTINUE?</code> message,
that is, if the <var>[[PROMPT parameter|PROMPT]]</var> X'10' bit is set, if the request is running in
an application subsystem, or the request is running on a batch thread. </li>

<li><var class="product">SirFact</var> dumps can be terminated if there is insufficient space in the dump procedure file to hold the dump.
In this case, the partial dump will be deleted because it is essentially useless. </li>
</ul>

===Procedure name substitutions===
The dump procedure name specified in the <var>SIRFACT DUMP</var> command can
contain the special character plus (<tt>+</tt>) followed by a single character indicating a substitution string.
The following characters cause the following substitutions to take place:
<table class="thJustBold">
<tr><th>+</th>
<td>A literal plus.</td></tr>

<tr><th>1-9</th>
<td>A single digit sequence number as in <code>+2</code> or <code>+6</code>. <var class="product">SirFact</var> tries sequence numbers from 0 through the indicated number
until it finds one that creates a procedure name that doesn't already exist in the target proc file.</td></tr>

<tr><th>D</th>
<td>The date that the error happened in YYYYMMDD format.</td></tr>

<tr><th>F</th>
<td>The file (not group) that contains the evaluating outer proc.</td></tr>

<tr><th>J</th>
<td>The jobname of the job in which the error occurred.</td></tr>

<tr><th>M</th>
<td>The number of the message that caused the request cancellation, or the word <code>SNAP</code> if the dump was caused by a <var>SIRFACT SNAP</var> command.
The substituted message number does not include the period. So for example, if the request cancellation was caused by a <code>MSIR.0491</code>, a <code>+M</code> would be replaced by a <code>MSIR0491</code>.</td></tr>

<tr><th>P</th>
<td>The name of the evaluating outer procedure.</td></tr>

<tr><th>S</th>
<td>The name of the current subsystem.</td></tr>

<tr><th>T</th>
<td>The date and time that the error happened in YYYYMMDDHHMISS format.</td></tr>

<tr><th>U</th>
<td>The userid that encountered the error.</td></tr>
</table>
Any other characters following a plus are simply dropped.

For example, if this is the <var>SIRFACT DUMP</var> command:
SIRFACT DUMP FACTDUMP DUMP.+P.+T

And a <var class="product">SirFact</var> trapped error happens in procedure <code>PRE.BADLY.CODED</code> at
14:22:31 on May 12, 2001, the dump procedure name is <code>DUMP.PRE.BADLY.CODED.20010512142231</code>.
If the <var>SIRFACT DUMP</var> command is:
SIRFACT DUMP FACTDUMP DUMP.+J.+2

And a <var class="product">SirFact</var> trapped error happens in job <code>DEVONLN</code>,
<var class="product">SirFact</var> tries to take the dump to procedure <code>DUMP.DEVONLN.00</code>.
If that procedure already exists, it tries to take the dump to
<code>DUMP.DEVONLN.01</code>, and so on.
If <var class="product">SirFact</var> gets all the way to <code>DUMP.DEVONLN.99</code> without finding a procedure that doesn't already
exist, the dump is not taken.

Because most of the substitution characters in a dump are likely to occur in multiple dumps, it is recommended that most
<var>SIRFACT DUMP</var> rules have a procedure name that contains a <code>+1</code>,
<code>+2</code>, <code>+3</code>, or a <code>+T</code>.

===Managing SirFact dumps===
<ul>
<li>Multiple <code>SIRFACT DUMP</code> commands might apply to a particular situation.
For example, say the following two commands are in effect:
<nowiki>SIRFACT DUMP DUMPCUST DUMP-+P-+2 SUBSYS CUSTOMER
SIRFACT DUMP JUNKDUMP DUMP-+S-+P PROC *JUNK
</nowiki>
If a request cancellation occurs in procedure <code>PCUST-MISCJUNK</code> in
subsystem <code>CUSTOMER</code>, both
<var>SIRFACT DUMP</var> commands seem applicable.
In such cases, <var class="product">SirFact</var>
will always use the last applicable <var>SIRFACT DUMP</var> rule. In
this example, the <var class="product">SirFact</var> dump is taken to procedure
<code>DUMP-CUSTOMER-PCUST-MISCJUNK</code> in file <code>JUNKDUMP</code>.

Because <var class="product">SirFact</var>
uses the last applicable <var>SIRFACT DUMP</var> rule, these rules should be
specified in most general first, most specific last order.
For example, this
requests that most dumps would go to file <code>SIRFACTD</code> but dumps for
subsystem <code>INVENTORY</code> would go to file <code>INVDUMP</code>, except for those in
procedures the end in <code>WIDGET</code>, which would go to file <code>WIDGETD</code>: 
SIRFACT DUMP SIRFACTD DMP.+P-+T
SIRFACT DUMP INVDUMP DMP.+P-+T SUBSYS INVENTORY
SIRFACT DUMP WIDGETD DMP.+P-+T SUBSYS INVENTORY PROC *WIDGET


If a <var>SIRFACT DUMP</var> command has criteria that are a superset of previous
<var>SIRFACT DUMP</var> commands, those previous criteria are discarded.
For example, in this sequence,
the last <var>SIRFACT DUMP</var> command would always supersede the previous
two. When <var class="product">SirFact</var> encounters that last command, it discards the
previous two, so a <code>SIRFACT DISPLAY DUMP</code> will only show the
last <var>SIRFACT DUMP</var> command. 
<nowiki>SIRFACT DUMP JUNKDUMP +P.+1.DUMP SUBSYS INVENTORY
SIRFACT DUMP DUMPDATA +P.+1.DUMP SUBSYS INVENTORY
SIRFACT DUMP IDUMP +P.+1.DUMP SUBSYS I*
</nowiki>

An unqualified <var>SIRFACT DUMP</var> command,
that is, one with just the procedure file and name, supersedes
all previous <var>SIRFACT DUMP</var> commands. </li>

<li><var class="product">SirFact</var> dumps are synchronous on a thread level but asynchronous on a system level.
This means that the user or thread for which a <var class="product">SirFact</var>
dump is being taken will not be able to do anything while the dump is
being taken, but other users or threads will continue to run.
This is different from CCASNAPs (and SYSMDUMPs), which stop the entire Online
while they are being taken.
In any case, even very large <var class="product">SirFact</var> dumps
should only take a few seconds to complete so should not have a severe
negative impact on performance for either the affected user or any other user. </li>

<li><var class="product">SirFact</var> dumps do not log roll-forward information for
the dump procedures, even if the procedure file to which the dump
is going is configured to log roll-forward information (the <var>[[FRCVOPT parameter|FRCVOPT]]</var> X'04' bit is not set).
This will not interfere with the roll-forward
logging for any other data going to the dump procedure file, and it will
not cause any recovery problems. It simply means that if the system
crashes after a <var class="product">SirFact</var> dump, and the procedure file is rolled back
to a checkpoint before the <var class="product">SirFact</var> dump in recovery, the dump will be lost. </li>

<li>Checkpoint logging is performed on the dump procedure file as indicated by <var>FRCVOPT</var>.
If no checkpoint logging is being performed on the dump
procedure file (<var>FRCVOPT</var> X'20' bit set), then there is no danger
of losing a <var class="product">SirFact</var> dump because of a roll-back during recovery. But
there is a very real chance of the file being left physically
broken after an inopportune system crash.
This might still be an acceptable
risk: without checkpoint logging <var class="product">SirFact</var> dumps will be extremely
fast and have very little impact on system performance, and
the procedure dictionary and Table D allocations are fairly tolerant of physical inconsistencies.

This latter point means that should the
system crash and a <var class="product">SirFact</var> dump procedure file be left physically
inconsistent, most of the information in that file could be recovered
after resetting <var>FISTAT</var> — though after doing so, the file should be reorganized
or reinitialized after moving the dump procedures elsewhere.
It is considerably more questionable to depend on being able to do this if procedure deletions
are being mixed with <var class="product">SirFact</var> dump creation.
Because of this, it is
recommended that <var class="product">SirFact</var> dump procedure file cleanup happen when
<var class="product">SirFact</var> dumps are unlikely (perhaps as part of a batch cycle) if the dump procedure file is being run with recovery turned off. </li>

<li>While <var class="product">SirFact</var> dumps are very useful, it is probably not
critical if a few are lost because of a system crash (in fact the
system crash itself would probably cause greater damage), so it might
make sense to run with recovery completely turned off for the <var class="product">SirFact</var>
dump procedure file with no formal strategy for recovering from a system crash.

Note: Because of the unusual nature of <var class="product">SirFact</var> dumps, it is
strongly recommended that no other data be stored in files that are to
receive <var class="product">SirFact</var> dumps. </li>
</ul>

==SIRFACT IGNORE==
The <var>SIRFACT IGNORE</var> subcommand indicates which request cancellation
error messages are not to produce <var class="product">SirFact</var> dumps.

===Syntax===
SIRFACT IGNORE msg


Where:
<table>
<tr><th>msg</th>
<td>The message number of the request cancellation message for which dumps are to be suppressed. The message number must include the message prefix
(<code>M204</code> for standard <var class="product">Model 204</var> messages, <code>MSIR</code> for Sirius messages, and <code>USER</code> for user messages).</td></tr>
</table>

===Usage===
<ul>
<li>Usually a request cancellation error message is indicative of
a programming error or a severe environmental problem.
In the case of a programming error, it is very useful to get a <var class="product">SirFact</var>
dump to determine the cause of the error.

In case of a severe environmental problem, it
might be helpful to get a <var class="product">SirFact</var> dump to determine the cause of
the environmental problem (for example, a <var>SIRFACT CANCEL</var> intercepted <var>$Setg</var>
error). But more often than not, a dump would not be particularly
helpful, especially for problems that affect structures that are shared among many users. </li>

<li>There are even a few request cancellation messages that are actually a normal part of operation!
A successful <var>VTAM TRANSFER</var>, for example, results in the cancellation
of the request that initiated the <var>TRANSFER</var>. </li>

<li>The <var>SIRFACT IGNORE</var> command makes it possible to suppress
<var class="product">SirFact</var> dumps for messages for which the dumps would either be undesirable or useless.
Examples of such error messages are:
M204.0441 CCATEMP FULL
M204.0443 TABLE D FULL
M204.1229 TABLE B FULL -- INSERTS
M204.1230 TABLE B FULL -- APPENDS
M204.1231 TABLE B FULL -- SPILLS
M204.1270 TABLE C FULL - PROPERTY ENTRY
M204.1272 TABLE C FULL - PAGE ENTRY
M204.1273 TABLE C FULL - REDEFINE
M204.1808 ERROR IN EXECUTING TRANSFER STATEMENT
M204.1899 TRANSFER STATEMENT COMPLETE, ...
MSIR.0517 Cancelling request because of $SIRPARM LISTFC setting (CCATEMP full)


Certainly, if CCATEMP or a file table fills up and <var class="product">SirFact</var> dumps
were not being suppressed for the associated message, a flood of
<var class="product">SirFact</var> dumps could occur as user after user trips over the same problem.
To prevent getting <var class="product">SirFact</var> dumps for these messages, simply issue
the following commands during Online initialization: 
SIRFACT IGNORE M204.0441
SIRFACT IGNORE M204.0443
SIRFACT IGNORE M204.1229
SIRFACT IGNORE M204.1230
SIRFACT IGNORE M204.1231
SIRFACT IGNORE M204.1270
SIRFACT IGNORE M204.1272
SIRFACT IGNORE M204.1273
SIRFACT IGNORE M204.1808
SIRFACT IGNORE M204.1899
SIRFACT IGNORE MSIR.0517


There might be other request cancellation errors for which
a site might want to suppress <var class="product">SirFact</var> dumps.
Among these might be: 
M204.0452 TTBL FULL
M204.0562 REQUEST TOO LONG - table
M204.0574 REQUEST TOO LONG - VTBL
M204.0577 QTBL FULL -- DIRECT SEARCH
M204.2126 USER'S PUSHDOWN LIST OVERFLOWED
</li>

<li><var class="product">[[Introduction to SoftSpy|SoftSpy]]</var> can issue some request cancellation errors which occur on the
SoftSpy server thread; to ignore these errors, use the following command:
<nowiki>SIRFACT IGNORE M204.0000
</nowiki></li>
</ul>

==SIRFACT MAXDUMP==
The <var>SIRFACT MAXDUMP</var> command establishes limits on the number
of <var class="product">SirFact</var> dumps to be taken.
The default for the maximum dumps for
the entire system is 0, so at least one <var>SIRFACT MAXDUMP</var> command
must be issued to get any <var class="product">SirFact</var> dumps.

===Syntax===
SIRFACT MAXDUMP [type] limit


Where:

<table>
<tr><th>type</th>
<td>The type of limit being established. It can be one of the following values:
<table>
<tr><th><var>USER</var></th>
<td>Maximum <var class="product">SirFact</var> dumps to be taken in a single user logon. The default is no limit.</td></tr>

<tr><th><var>TOTAL</var></th>
<td>Maximum <var class="product">SirFact</var> dumps to be taken in the entire Online. The default is 0, so a <code>SIRFACT MAXUMP TOTAL</code> must be issued to get any <var class="product">SirFact</var> dumps.</td></tr>
</table>

If <var class="term">type</var> is not specified, it is assumed to be <var>TOTAL</var>, so <code>SIRFACT MAXDUMP 20 </code>is the same as <code>SIRFACT MAXDUP TOTAL 20</code>.
</td></tr>

<tr><th>limit</th>
<td>The maximum number of dumps to be taken for the indicated type.</td></tr>
</table>

===Usage===
<ul>
<li>A <var>SIRFACT MAXDUMP</var> should be issued at the start of any Online run for which you want <var class="product">SirFact</var> dumps.
If for some reason an application
or environmental error is causing a "flood" of <var class="product">SirFact</var> dumps,
further dumps can be prevented with a <code>SIRFACT MAXDUMP 0</code>.
This should not be a concern if a reasonable limit
is set by a <var>SIRFACT MAXDUMP</var> at the start of the run. </li>

<li>You can view the number of <var class="product">SirFact</var> dumps taken
since the <var class="product">Model 204</var> Online initialization by issuing
a <code>[[#sfdisp|SIRFACT DISPLAY|SIRFACT DISPLAY MAXDUMP]]</code> command. </li>
</ul>

==SIRFACT QUIESCE==
<var>SIRFACT QUIESCE</var> facilitates updates of application subsystem procedures while the subsystem is up and in use.
This subcommand gets all subsystem users into a "quiescent" state
where they are not likely to block procedure update operations
or compile inconsistent copies of inner and outer subsystem procedures.
Users are quiescent if they are
evaluating a pre-compiled request (as determined by the request's
prefix not its true pre-compilability) or between procedures in the subsystem driver loop.

When <var>SIRFACT QUIESCE</var> is issued:
<ul>
<li>Any user that is going to switch to the
next procedure in the subsystem driver is stopped until the subsystem is resumed. </li>

<li>Any user that exits a pre-compiled procedure is stopped at end of request. </li>

<li>Other users continue to run until they encounter one of the preceding two points. </li>

<li>A user that is evaluating a pre-compiled request or that is between procedures
is already considered quiesced. </li>
</ul>

===Syntax===
SIRFACT QUIESCE subsys [WAIT sec] [BUMP]


Where:
<table>
<tr><th>subsys</th>
<td>The name of the subsystem to be quiesced.</td></tr>

<tr><th>sec</th>
<td>The number of seconds to wait for the subsystem to be quiesced.
If the subsystem quiesces before this time, <var>SIRFACT QUIESCE</var>
returns at that point. If the subsystem is not quiesced after <var class="term">sec</var> seconds, SIRFACT QUIESCE returns with a message stating that the subsystem is not yet quiesced, unless <code>BUMP</code> was specified.

The wait time cannot be set to 0. The default wait time is 3 seconds.</td></tr>

<tr><th><var>BUMP</var></th>
<td>A <var class="product">Model 204</var> <var>BUMP</var>, issued for any users still not quiescedafter<var class="term">sec</var> seconds. After bumping these users, <var>SIRFACT QUIESCE</var> waits another second for these users to notice the bump.

Bumped users do not actually disappear from the system: The <var>BUMP</var> sets the user's next procedure to the application subsystem error procedure, but the error procedure does not run because in a quiescing subsystem,
users do not go to the next procedure.</td></tr>
</table>

===Usage===
<ul>
<li>If a <var>SIRFACT QUIESCE</var> does not completely quiesce
a subsystem, it is quite likely that it will still allow for safe update and
replacement of subsystem procedures — any user that hasn't
quiesced within a reasonably long time will probably not cause or encounter any problems during an update operation.
This is especially true if the
X'40' bit of <var>SIRFACT</var> is set (see [[SirFact system parameters#factprm|The SIRFACT parameter]]).
The <var>BUMP</var> option of <var>SIRFACT QUIESCE</var> offers further assurance that no subsystem users
will impede or threaten procedure updates. </li>

<li><var>SIRFACT QUIESCE</var> can be issued multiple times by one or multiple users for the same subsystem.
In either case, only a single invocation of the <var>SIRFACT QUIESCE</var> inverse operation, <var>SIRFACT RESUME</var>, is necessary to
stop the quiescing and resume normal operation of the subsystem.
If a user is waiting for the return from <var>SIRFACT QUIESCE</var>, another user
can cancel the quiesce and cause the first user to return immediately
(with a warning message) by issuing a <var>SIRFACT RESUME</var> for the same subsystem. </li>

<li><var>SIRFACT QUIESCE</var> is valuable for doing application subsystem maintenance.
Such maintenance probably requires appropriate settings of
the <var>[[SirFact system parameters#sirapsy|SIRAPSYF]]</var> parameter and of the <var>[[SIRFACT parameter|SIRFACT]]</var> parameter. </li>
</ul>

==SIRFACT RESUME==
<var>SIRFACT RESUME</var> counters the effect of <var>[[#quiesce|SIRFACT QUIESCE]]</var>:
<var>SIRFACT QUIESCE</var> renders a currently operating subsystem safe for updates by waiting for and stopping users until
no users are inside a non-pre-compiled procedure or compiling precompiled procedures.
<var>SIRFACT RESUME</var> stops this quiescing and returns the subsystem to normal operation.

===Syntax===
SIRFACT RESUME subsys


===Usage===
<ul>
<li>If a user is waiting for the return from <var>SIRFACT QUIESCE</var>, another user
can cancel the quiesce and cause the first user to return immediately
(with a warning message) by issuing a <var>SIRFACT RESUME</var> for the same subsystem. </li>

<li><var>SIRFACT QUIESCE</var> can be issued multiple times by one or multiple users for the same subsystem.
In either case, only a single invocation of the <var>SIRFACT QUIESCE</var> inverse operation, <var>SIRFACT RESUME</var>, is necessary to
stop the quiescing and resume normal operation of the subsystem. </li>
</ul>

==SIRFACT RECNDUMP==
The <var>SIRFACT RECNDUMP</var> establishes the number of record numbers from each found set or $list (from <var>LIST</var> option of <var>[[SirFact_FACT_subsystem#dcmd|Display]]</var> command) to be dumped.
By default, <var class="product">SirFact</var> dumps two record numbers from each found set or $list, the first and the last.
Note that <var class="product">SirFact</var> does not actually dump the records in any found set or
$list unless a record in a found set or $list is the current record in an
active <var>FOR EACH RECORD</var> loop, in which case that single record is dumped.

===Syntax===
SIRFACT RECNDUMP num


The maximum <var class="term">num</var> value for <var>SIRFACT RECNDUMP</var> is 256, and the minimum is 1.

===Usage===
<ul>
<li>The count of records in a found set or $list is always dumped.

If a found set or $list contains fewer or the same number of records as
the <var>SIRFACT RECNDUMP</var> value, the entire found set or list is dumped.
If a found set or $list contains more records than the <var>SIRFACT RECNDUMP</var>
value, the first <code>(num+1)/2</code> and last <code>num/2</code> record numbers in the found set or $list are dumped. 

For example, if <var>SIRFACT RECNDUMP</var> is 1, only the first record number
in a found set or $list will be dumped. If the value is 32, the first
16 and last 16 will be dumped. And if the value is 127, the first 64 and
last 63 will be dumped. </li>

<li>The cost of a large <var>SIRFACT RECNDUMP</var> value is a somewhat
larger dump if a request has many large found sets or $lists, though
the cost is only about 6 bytes per record dumped per found set or $list.

For example, if there are 20 large found sets and $lists in a request
that is dumped, a <var>RECNDUMP</var> value of 100 would make the dump <code>98*20*6</code>
or 11,760 bytes bigger than a dump with the default <var>RECNDUMP</var> value of 2. 

The cost to keeping <var>RECNDUMP</var> small is that potentially useful information is lost about the records in a found set or a $list. </li>
</ul>

==SIRFACT SNAP==
The <var>SIRFACT SNAP</var> command requests that a <var class="product">SirFact</var> dump is to be taken
for another thread.
This can be useful if a thread is looping or hung.

===Syntax===
SIRFACT SNAP usernum | userid [FORCE]


The <var>SIRFACT SNAP</var> command must be followed by either a user number or a userid.
If a userid is specified, the userid must only be logged in on a single
thread or <var class="product">SirFact</var> will not take the dump for the thread.
If a userid is logged in on multiple threads, the dump must be requested
by user number.

The optional <var>FORCE</var> parameter indicates that the <var class="product">SirFact</var> dump is
to be taken for the thread, even if the thread holds one or more critical file resource locks.
By default, <var class="product">SirFact</var> will not take a dump for another thread
on a <var>SIRFACT SNAP</var> command while the thread holds any critical
file resource locks, though it will try to wait a little bit
(less than 3 seconds) for a window in which the thread being
snapped does not hold any critical file resource locks.

===Usage===
<ul>
<li>There are certain cases where a <var>SIRFACT SNAP</var> command might fail
for a looping thread:
<ul>
<li>The most likely is when <var class="product">SirFact</var> is
unable to find a time when the thread being snapped does not
hold a critical file resource lock.
This behavior can be overridden by the specification of the <var>FORCE</var>
parameter on the <var>SIRFACT SNAP</var> command. </li>

<li><var class="product">SirFact</var> will also not take a dump for a thread if that thread
is waiting on journal or checkpoint I/O.
As with critical file resources locks, <var class="product">SirFact</var> will try several
times over the course of a few seconds to break in on the thread
to be snapped when it is not waiting on checkpoint or journal I/O,
but if it fails, it gives up. </li>
</ul>

In most such failure cases, the <var>SIRFACT SNAP</var> command can be retried
until it succeeds.
If a few consecutive <var>SIRFACT SNAP</var> commands fail, the chances of
success might be improved by setting the target thread's priority to <code>LOW</code>. </li>

<li>The <var>SIRFACT SNAP</var> command can be useful in diagnosing looping
thread problems or problems where a user is presented with
incorrect output.
In both cases, Help desk personnel or a system manager can
get a <var class="product">SirFact</var> dump for the thread with the problem, then do whatever is necessary to get the thread back on track. </li>

<li><var>SIRFACT</var> snaps can be taken for non-evaluating threads, even the
one issuing the <var>SIRFACT SNAP</var> command, though the dump in such
cases will have little besides GTBL. </li>
</ul>

</div> 

==See also==
{{Template: SirFact topic list}}

[[Category:System administrator commands]]
[[Category:Operator commands]]
[[Category:Commands]]
[[Category:SirFact]]

The Sir2000 APPDATE command

2022-11-14T20:42:33Z

Goff: Remover spurious line feed

==Overview==
The <var>APPDATE</var> command provides control over the operation of date and time oriented SOUL $functions. It supports a system-wide or user-level clock that is used to obtain date and time values. It can be used to control the default handling of errors detected by datetime $functions, allowing the logging of error messages and request cancellation. The <var>APPDATE</var> command allows you to control these defaults at a user and system level, significantly reducing your effort to detect some date errors.

For application testing, the <var>APPDATE</var> clocks are preferred to the Model 204 <var>[[SYSDATE parameter|SYSDATE]]</var> parameter, which is much less flexible and which greatly complicates the ability to do things such as share procedure files or read-only data files in the testing environment.

See [[#Values affected by the APPDATE clocks|Values affected by the APPDATE clocks]] for a list of the values that are affected by the <var>APPDATE</var> command. See [[#APPDATE command usage notes|APPDATE command usage notes]] for descriptions of several common testing scenarios and how to use <var>APPDATE</var> to handle them, including testing the effect of changing the date into the future for any of the following:

<ul>
<li>A single user's session </li>
<li>All users' sessions </li>
<li>All users' sessions except selected ones </li>
<li>All users of a given [[APSY]] </li>
<li>All users of all APSYs, except selected APSYs </li>
</ul>

In most contexts when describing <var>APPDATE</var>, these Sir2000 User Language Tools pages speak of a "date and time" or simply of a "time" (which is the same thing). Generally, for Y2K testing, you are only concerned about setting a "date," that is, setting the clock to a particular day.

<var>APPDATE</var> addresses many of the needs to test a SOUL application at some
date in the future, notably beyond the end of the 1900s. <var>APPDATE</var> lets you make these tests with your current version of Model 204, and without modifying the Model 204 internal date-related data structures, such as the File Parameter List, page trailers, and the Procedure Dictionary. <var>APPDATE</var> does not affect any file level operations such as recovery or DUMP, or the ability to open a file with different application date settings.

The system-wide and user-level clocks specified by the <var>APPDATE</var> command are called APPDATE clocks. In order to use these clocks, you must set the date (and optionally the time) of the system level or the user level clock. The syntax associated with setting these APPDATE clocks is described in [[#Setting the clocks with the APPDATE command|Setting the clocks with the APPDATE command]].

Another important component in a testing environment, or indeed in a production
environment, is the ability to detect unanticipated errors. The <var>APPDATE</var> command with a <var>DATE_ERR</var> clause and the <var>$Sir_Date_Err</var> function allow you to change the default error handling of arguments to date and time oriented $functions. The syntax associated with <var>DATE_ERR</var> is described in [[#Error handling control with DATE_ERR|Error handling control with DATE_ERR]].

A single invocation of the <var>APPDATE</var> command can set <var>APPDATE</var> values or display <var>APPDATE</var> values. If you want to examine the <var>APPDATE</var> values in effect, use the syntax described in [[#Examining the APPDATE information|Examining the APPDATE information]]. The detailed explanation of setting <var>APPDATE</var> values is described separately for clock values
and datetime argument error handling, but for a single level you can specify both clock values and error handling, in that order, in a single command.

The complete syntax of the <var>APPDATE</var> command is shown in [[#Complete syntax of the APPDATE command|Complete syntax of the APPDATE command]].

==Setting clocks with the APPDATE command==

The two <var>APPDATE</var> clocks (user and system) effectively run in parallel with the internal clock, that is, the time that Model 204 obtains from the CPU.

Note: The <var>SYSDATE</var> parameter cannot be specified if the <var>APPDATE</var> command is used. 

When you set either of the clocks, you are actually setting the amount that the clock runs ahead of the internal clock. You do that by specifying either of these: 
<ul>
<li>The current time of the clock being set </li>

<li>The time that would be current when the internal clock is at some specific reference time </li>
</ul>

In addition to the time setting of the clocks, you control which clock an application uses. This is determined primarily by the "state" of the <var>USER</var> clock:

<table class="thJustBold">
<tr class="head"><th>State</th><th>Meaning</th></tr>

<tr><th>INTERNAL</th>
<td>Applications use the <var>INTERNAL</var> clock. </td></tr>

<tr><th>ON</th>
<td>Applications use the <var>USER</var> clock. </td></tr>

<tr><th nowrap>OFF (the default) </th>
<td>Applications use the <var>INTERNAL</var> clock unless the
<var>SYSTEM</var> clock is on (the default <var>SYSTEM</var> clock is off). </td></tr>
</table>

The clock used to satisfy an application request for date or time is determined as shown in the following figure:

Source of date returned to $function
 *----------------------------------------------------------*
* Application code requests date *
* (datetime $functions) *
*----------------------------------------------------------*
|
|-> Gets date/time from the USER clock if it is ON
| (example: APPDATE USER ON 2001/01/01)
|
|-> Else from SYSTEM clock if it is ON and USER clock is OFF
| example: APPDATE USER OFF (default)
| and APPDATE SYSTEM ON 1999/12/31
|
|-> Else from INTERNAL clock:
example: APPDATE USER INTERNAL
or
APPDATE USER OFF
and APPDATE SYSTEM OFF
or
APPDATE USER OFF
and APPDATE SYSTEM INTERNAL 

===APPDATE syntax to set USER or SYSTEM clock===

The time of the <var>USER</var> or <var>SYSTEM</var> clock may be set by the <var>APPDATE</var> command:

APPDATE [USER|SYSTEM] [ON|OFF|INTERNAL] -
targdate [targtime] -
[AT refdate [reftime]] 

===APPDATE syntax to change state of USER or SYSTEM clock===

Whether or not a particular clock is used can be controlled by the <var>APPDATE</var> command, without changing the time of the <var>USER</var> or <var>SYSTEM</var> clock:

APPDATE [USER|SYSTEM] { ON|OFF|INTERNAL } 

===Syntax terms===
<table class="thJustBold">
<tr><th>USER | SYSTEM</th>
<td>Optional specification of which clock is being modified. Defaults to <var>USER</var>. The <var>USER</var> clock specifies the running user's <var>APPDATE</var> clock. The <var>SYSTEM</var> clock specifies the <var>APPDATE</var> clock used for any user with an <var>APPDATE</var> <var>USER</var> clock that is <var>OFF</var>. </td></tr>

<tr><th>ON | OFF | INTERNAL</th>
<td>Optional. <code>APPDATE USER ON</code> indicates that the user clock is used by the current user. <code>APPDATE SYSTEM ON</code> indicates that the system clock is used by all users whose user clock is <var>OFF</var>. <var>OFF</var> and <var>INTERNAL</var> both indicate that the specified clock is not visible.

If the user-level clock is set to <var>ON</var>, SOUL $function values are obtained from the user-level clock. 

If the user-level clock is set to <var>INTERNAL</var>, SOUL $function values are obtained from the internal clock. 

If the user-level clock is set to <var>OFF</var>, SOUL $function values depend on the setting of the system-wide clock: if it is <var>ON</var>, they are obtained from the system-wide clock; otherwise (it is <var>OFF</var> or <var>INTERNAL</var>) they are obtained from the internal clock. 

If this phrase is omitted in an <var>APPDATE</var> command that sets the time of a
clock, the state of that clock is set to <var>ON</var>. 

You can specify <var>ON</var>, <var>OFF</var>, or <var>INTERNAL</var> without a date, in which case the date/time in a clock is not changed, but the visibility of the corresponding clock is affected. </td></tr>

<tr><th nowrap>targdate [targtime] [AT refdate [reftime]]</th>
<td><var class="term">targdate</var> is required;, the rest are optional. These phrases allow you to specify the date and time of the application clock. The dates are specified in YYYY/MM/DD format, and the times are specified in HH:MI:SS format. 
The application clocks continue to run so that they are a constant difference from the internal date and time. This difference is the difference between the target datetime, as specified by <var class="term">targdate</var> and the optional <var class="term">targtime</var>, and the reference datetime. The reference datetime can be omitted, in which case the reference datetime is the datetime when the <var>APPDATE</var> command is issued. 

If <var class="term">reftime</var> is specified, <var class="term">targtime</var> must also be. If <var class="term">targtime</var> is specified, then either <var class="term">refdate</var> must be omitted or <var class="term">reftime</var> must be specified. If <var class="term">targtime</var> is omitted, the clock is shifted the number of days between <var class="term">targdate</var> and <var class="term">refdate</var>. </td></tr>
</table>

A successful <code>APPDATE SYSTEM</code> command has an immediate effect upon the date/time returned by SOUL $functions for all threads that have user-level clocks set or defaulted to the <var>OFF</var> state. 

The default value of the system-wide clock and all user-level clocks is <var>OFF</var>, with the same datetime as the internal clock. Hence, if the only command you issue is <code>APPDATE SYSTEM yyyy/mm/dd</code>, you will immediately shift the value returned as the current date by SOUL $functions. The <var>APPDATE</var> <var>USER</var> clock is reset to <var>OFF</var>, with the same time as the <var>INTERNAL</var> clock, when a user logs off. 

==Error handling control with DATE_ERR==
The <var>APPDATE</var> command with the <var>DATE_ERR</var> keyword and the <var>[[$Sir_Date_Err]]</var> function let you decide what default action the system takes if an error is detected by a datetime $function. This lets you control validation of dates in your applications, significantly reducing your effort to detect and correct date errors.

<var>APPDATE DATE_ERR</var> and <var>$Sir_Date_Err<var> detect the following errors:
<ul>
<li>Invalid datetime format specification </li>
<li>Datetime string not matching format </li>
<li>Datetime out of range for the format </li>
<li>Invalid CENTSPAN value </li>
<li>Datetime out of range for CENTSPAN/SPANSIZE combination </li>
</ul>

You can set the default error handling for all $functions in the system with an <code>APPDATE SYSTEM DATE_ERR</code> command. You can override this setting for an individual user with
an <code>APPDATE USER DATE_ERR</code> command. You can override both settings for the duration of a SOUL request with the <var>$Sir_Date_Err</var> function. If you are using the Sirius datetime $functions, you can also supply a parameter on the individual
function call to control error handling, overriding the default set by <var>$Sir_Date_Err</var> or <var>APPDATE</var>. 

The processing performed when a datetime function encounters an error is determined
using the precedence indicated in the following figure:

Datetime $function argument error handling 
 *----------------------------------------*
* Datetime $function argument error *
*----------------------------------------*
|
|-> IGNORE is error handling handling arg:
| return error value
|
|-> REPORT is error handling arg:
| issue message, return error value
|
|-> Error handling supplied, and not OFF:
| issue message, cancel request
|
++ Else OFF is error handling arg, or none:
|
|-> $SIR_DATE_ERR('REPORT') last invoked:
| issue message, return error value
|
|-> $SIR_DATE_ERR('IGNORE') last invoked:
| return error value
|
|-> $SIR_DATE_ERR('CANCEL') last invoked:
| issue message, cancel request
|
++ Else error handling controlled by APPDATE:
|
|-> USER DATE_ERR REPORT:
| issue message, return error value
|
|-> USER DATE_ERR IGNORE:
| return error value
|
|-> USER DATE_ERR CANCEL:
| issue message, cancel request
|
|-> USER DATE_ERR OFF (default) and
| SYSTEM DATE_ERR REPORT
| issue message, return error value
|
|-> USER DATE_ERR OFF (default) and
| SYSTEM DATE_ERR IGNORE
| return error value
|
|-> USER DATE_ERR OFF (default) and
| SYSTEM DATE_ERR CANCEL
| issue message, cancel request
|
++ Else error handling not affected
| by Sir2000 User Language Tools:
|
+---> return error value 

===Setting default error handling with the APPDATE command===
The <var>APPDATE</var> command may be used to set and change the default for processing performed when a datetime $function detects an error.
APPDATE [USER|SYSTEM] DATE_ERR -
[OFF | CANCEL | REPORT | IGNORE] -
[DEBUG | NODEBUG]

<table class="thJustBold">
<tr><th>USER | SYSTEM</th>
<td>Optional specification of the scope for the current command, defaults to USER. The USER error handling overrides the SYSTEM error handling. Both USER and SYSTEM error handling are initially OFF. </td></tr>

<tr><th>OFF | CANCEL | REPORT | IGNORE</th>
<td>This is optional. OFF indicates that there is no default error handling at the
given level. CANCEL indicates that the default error handling at the given level is issuing an error message describing the error and cancelling the User Language request. REPORT indicates that the default error handling at the given level is issuing an error message describing the error and returning an error indicator. IGNORE indicates that the default error handling at the given level is returning an error indicator. </td></tr>

<tr><th nowrap>DEBUG | NODEBUG</th>
<td>If DEBUG is specified, any datetime error message produced at the given level (user or system) will include the name of the procedure file, the procedure name, and the line number within the procedure for the affected $function invocation.

If neither DEBUG nor NODEBUG is specified, then OFF, CANCEL, REPORT, or IGNORE must be specified, in which case the default DEBUG/NODEBUG setting is determined from the following table: 
<table class="thJustBold">
<tr><th>CANCEL</th>
<td>DEBUG </td></tr>

<tr><th>REPORT</th>
<td>DEBUG</td></tr>

<tr><th>IGNORE</th>
<td>NODEBUG</td></tr>

<tr><th>OFF</th>
<td>There is no DEBUG/NODEBUG setting at the level.</td></tr>
</table>

Since the initial DATE_ERR setting is OFF, there is no DEBUG/NODEBUG
setting, at both SYSTEM and USER levels. </td></tr>
</table>

Both the USER and SYSTEM level defaults can be overridden by the setting of the
<var>$Sir_Date_Err</var> function, which in turn is overridden by supplying a non-default value
for the error handling argument, if a $Sir_Datexxx $function is in use. The
<var>$Sir_Date_Err</var> error handling is initially OFF. If <code>$Sir_Date_Err('OFF')</code> is in effect,
the USER level handling controls default error handling, unless it is OFF, in which case the SYSTEM level controls the default. 
Note: The <var>APPDATE</var> command and <var>$Sir_Date_Err</var> set only the default datetime argument error handling. This will affect the standard SOUL date $functions, and it will affect the $Sir_Datexxx and Sir2000 $functions if they are coded without the error handling argument. 

===Setting default error handling with the $Sir_Date_Err function===
<var>[[$Sir_Date_Err]]</var> provides the ability to set or override default datetime $function error handling at the request level:
%s string len 8
%s = $sir_date_er('REPORT') 

The effect of a <var>$Sir_Date_Err</var> invocation persists until the end of the SOUL request, at which time its setting is reset to <var>OFF</var>. Note that <var>$Sir_Date_Err</var> only sets
the default datetime argument error handling. It will affect the standard SOUL date $functions, and
it will affect the $Sir_Datexxx $functions if they are coded without the error handling argument. 

==Examining the APPDATE information==
The Sir2000 User Language Tools provide mechanisms for displaying and saving the
state of the <var>APPDATE</var> clocks and various DATE_ERR switches. Thus, it is possible for applications to retrieve the current states, temporarily change the states and then restore the previous states.

===APPDATE DISPLAY command===
The following form of the <var>APPDATE</var> command allows you to view the setting of either the USER or SYSTEM clock, and to view the error handling setting:
APPDATE DISPLAY [ALL|USER|SYSTEM]


<table class="thJustBold">
<tr><th nowrap>ALL | USER | SYSTEM</th>
<td>This is optional. It specifies to display the current time and error handling setting for all levels, or to display either the USER or SYSTEM level in a form that is equivalent to the <var>APPDATE</var> command which set it.

ALL is the default and prints the current internal time, the
clock ON|OFF|INTERNAL settings for both USER and
SYSTEM, the DATE_ERR settings of both USER and
SYSTEM, what the current times would be for the clocks if
they were in effect, and an indication of which clock and
which error handling setting is active for the current user.
Following this is the display of the USER and SYSTEM levels
in the "command setting" form, that is, the command that was
issued to set the level. </td></tr>
</table>

<code>APPDATE DISPLAY ALL</code> is not suitable for placing in a global and re-invoking; you should use <code>APPDATE DISPLAY {USER | SYSTEM}</code> for that purpose. The display
format of <code>APPDATE DISPLAY ALL</code> is shown in the following example:

 LEVEL CLOCK STATE/DATE_ERR CURRENT CLOCK
-------- ----------------------- ------------------------
INTERNAL 1997/05/14 11:27:51
SYSTEM ON/OFF 2000/01/02 11:27:51 (@)
USER OFF/CANCEL DEBUG 1997/05/14 11:27:51 (*)
SYSTEM CLOCK ACTIVE (@); USER LEVEL IS ERROR HANDLING DEFAULT (*)
COMMAND SETTINGS:
APPDATE SYSTEM ON 2000/01/01 AT 1997/05/13 DATE_ERR OFF
APPDATE USER OFF 1997/05/13 AT 1997/05/13 DATE_ERR CANCEL DEBUG 

The <code>APPDATE DISPLAY {USER | SYSTEM}</code> forms of the command produce results in the form of a legal <var>APPDATE</var> command that would set the levels to their current
values. For example, the following lines would result from invocations of the <code>APPDATE DISPLAY USER</code> and <code>APPDATE DISPLAY SYSTEM</code> commands in the same context as above:

APPDATE SYSTEM ON 2000/01/01 AT 1997/05/13 DATE_ERR OFF
APPDATE USER OFF 1997/05/13 AT 1997/05/13 DATE_ERR CANCEL DEBUG 

===Retrieving last non-null $Sir_Date_Err setting===

You can call <var>$Sir_Date_Err</var> with no argument or with the null string, and it will return a character string indicating the most recent valid and non-null value specified in a call to <var>$Sir_Date_Err</var> during the current request. 

For example:

%s string len 8
%s = $sir_date_err( <no argument> | '' ) 

Such a call will return one of the following strings: 
<ul>
<li>'OFF' </li>
<li>'CANCEL' </li>
<li>'REPORT' </li>
<li>'IGNORE' </li>
</ul>

==Privileges, disabling, and pre-User 0 APPDATE command==
The <code>APPDATE SYSTEM</code> form of the command can be issued only by User 0 (user zero, that is, in the CCAIN input stream) or by a user with system manager privileges;
<code>APPDATE USER</code> and <code>APPDATE DISPLAY</code> can be issued by any user. <code>APPDATE SYSTEM</code> can also be used in the CCAIN input stream before the User 0 parameter line,
so that the system-wide <var>APPDATE</var> clock and error handling can be set prior to any calculations performed by an IODEV 3 thread. Neither <code>APPDATE USER</code> nor <code>APPDATE DISPLAY</code> may be used before the User 0 parameter line.

An <code>APPDATE RESTRICT</code> command can be used to prohibit any issuance of the
<var>APPDATE</var> command except prior to the User 0 parameter line. This could be used if you do not want anyone to change the <var>APPDATE</var> settings after initialization of the Model 204 run. The <code>APPDATE RESTRICT</code> command itself can only be issued before the User 0 parameter line. 

You can also disable or restrict the <var>APPDATE</var> command by applying a customization zap. You might use a customization zap like the following if, for example, you wanted to disallow the use of the <var>APPDATE</var> command in a production load module: 
 * If you apply the following zap, any APPDATE
* command will cause an error message to be
* issued and the command otherwise is ignored.
*
* Note: this example assumes you have no other
* customization zaps; if you do, include those
* bits in the VER and REP data.
*
NAME ONLINE SIRK$
VER 070E 00
REP 070E 80
* ------------- End of zap -------------------- 

Or a zap like the following, if you want to only allow one system-wide <var>APPDATE</var> setting for the entire Model 204 run:

 * If you apply the following zap, the APPDATE
* command is only allowed prior to the user zero
* parameter line, and any other use of APPDATE
* will cause an error message to be issued and
* the command otherwise is ignored.
*
* Note: this example assumes you have no other
* customization zaps; if you do, include those
* bits in the VER and REP data.
*
NAME ONLINE SIRK$
VER 070E 00
REP 070E 40
* ------------- End of zap --------------------

Note: Lines are not sent to the Model 204 audit trail for commands (and subsequent error messages) issued prior to the User 0 parameter line. Output is sent to CCAPRINT for such commands, however. 

==Complete syntax of the APPDATE command==
The detailed explanation of setting <var>APPDATE</var> values is described separately for clock values (see [[#Setting clocks with the APPDATE command|Setting clocks with the APPDATE comman]]) and
datetime argument error handling (see [[#Error handling control with DATE_ERR|Error handling control with DATE_ERR]]). However, for the USER or SYSTEM level you can specify both clock values and error handling, in that order, in a single command.

===Syntax===

The complete syntax of the <var>APPDATE</var> command is shown below: 

APPDATE { Level Clock_set [Err_set] | Level Err_set | Display | RESTRICT } 

===Syntax terms===
<table>
<tr><th>Level</th>
<td>USER | SYSTEM </td></tr>

<tr><th>Clock_set</th>
<td><var class="term">Clock_state</var> | [<var class="term">Clock_state</var>] <var class="term">Date_times</var> </td></tr>

<tr><th>Clock_state</th>
<td>ON | OFF | INTERNAL </td></tr>

<tr><th>Date_times</th>
<td>{ <var class="term">targdate</var> [AT <var class="term">refdate</var>]
| <var class="term">targdate targtime</var> [AT <var class="term">refdate reftime</var>] } </td></tr>

<tr><th>Err_set </th>
<td>DATE_ERR { [OFF|CANCEL|REPORT|IGNORE] | [DEBUG|NODEBUG] } 
Note: {<var>OFF|CANCEL|REPORT|IGNORE</var>} or {<var>DEBUG|NODEBUG</var>} must be specified with <var>DATE_ERR</var>.</td></tr>

<tr><th>Display </th>
<td>DISPLAY [ALL | USER | SYSTEM] </td></tr>
</table>

As discussed in [[#Privileges, disabling, and pre-User 0 APPDATE command|Privileges, disabling, and pre-User 0 APPDATE command]]: 
<ul>
<li>An <code>APPDATE SYSTEM</code> command must be issued in the User 0 input stream or by a system manager; an error message is produced if <code>APPDATE SYSTEM</code> is processed in other contexts. </li>

<li>An <code>APPDATE RESTRICT</code> command must be issued in the User 0 input stream; an error message is produced if <code>APPDATE RESTRICT</code> is processed in other contexts. </li>

<li>The <var>APPDATE</var> command can also be completely disabled, or restricted to the User 0 input stream before the User 0 parameter line, by using a customization zap. </li>

<li>Issuing an <var>APPDATE</var> command in a disabled or restricted context produces an error message but does no checking or processing of the command. </li>
</ul>

==Values affected by the APPDATE clocks==
The active <var>APPDATE</var> clock affects the value returned by the following SOUL $functions:
<ul>
<li><var>$Date</var>, <var>$DateJ</var>, <var>$DateP</var> </li>

<li><var>$DateDif</var>, <var>$DateCnv</var>, and <var>$DayI</var> (when obtaining the year for handling the <var>CENTSPLT</var> argument) </li>

<li><var>$Time</var> </li>

<li><var>$Sir_Date</var>, <var>$Sir_DateN</var>, <var>$Sir_DateND</var>, <var>$Sir_DateNM</var>, <var>$Sir_DateS</var>, <var>$SirTime</var>, and <var>$Web_Date</var> </li>

<li><var>$Web_Last_Modified</var> (when ensuring last-modified date isn't future) </li>

<li><var>$Sir_DateChg</var>, <var>$Sir_DateChk</var>, <var>$Sir_DateCnv</var>, <var>$Sir_DateDif</var>, <var>$Sir_Date2N</var>, <var>$Sir_Date2ND</var>, <var>$Sir_Date2NM</var>, <var>$Sir_Date2NS</var>, <var>$Db_RpcParam</var>, <var>$Srv_Bind</var>, and <var>$Srv_Parmset</var> (when obtaining the year for relative <var>CENTSPAN</var> handling) </li>
</ul>

The only Model 204 command affected by the <var>APPDATE</var> clock is the <var>RESET</var> command for changing the <var>CENTSPLT</var> user parameter. In this case, the <var>BASECENT</var> parameter, which is calculated using the current time, obtains the current time from the active
<var>APPDATE</var> clock. The resulting value of <var>BASECENT</var> can be used to interpret 2-digit years passed to the following SOUL $functions: 
<ul>
<li><var>$DateDif</var>, <var>$DateCnv</var>, and <var>$DayI</var>, if neither the <var>CENTSPLT</var> nor <var>DEFCENT</var> arguments are provided </li>

<li><var>$DateChg</var> and <var>$DateChk</var> </li>
</ul>

Finally, the default value of <var>DEFCENT</var> is taken from the active <var>APPDATE</var> clock if the <var>APPDATE</var> command is issued before the User 0 parameter line.


==APPDATE command usage notes==
<ol>
<li>One kind of application testing is simply to see what happens when dates into the
21st century are returned by SOUL $functions. This can be done in
isolation by issuing a command such as the following:
APPDATE USER 2000/01/01 

This can be simply issued by the user before entering the application, or it can be
issued in the startup or logon proc of the application.</li>

<li>If your application stores results that are retrieved later by the application, you should probably put a command such as the following into the startup proc:
APPDATE USER 2000/01/01 AT 1997/05/01 

This indicates that the application clock will run ahead of the internal date and time so that on the 1st of May, 1997, the application clock will show the 1st of January, 2000. Your application can thus run as if it were "shifted" ahead in time, and the shift amount will be consistent, even if you bring down the online and bring it up again. It is recommended that you place it in the startup procedure in case any dates are referenced in it.</li>

<li>If you want all applications (except those "shielded" as in item 5, below) to use the same clock, you need not change any applications but simply code before the User 0 parameter line:
APPDATE SYSTEM 2000/01/01 AT 1997/05/01 

Note that this also changes the default <var>DEFCENT</var>; see item 6, below. </li>

<li>If you have an application that must use the internal date and time, even if the system-wide application clock is ON, you should enter a command such as the
following in the startup procedure:
APPDATE USER INTERNAL 

This could be needed by an application that examines internal datetime values,
such as those found in the audit trail. A robust application will preserve the
<var>APPDATE</var> value and can do this using the <var>[[$CommndL]]</var> function, since an [[Sdaemons|sdaemon]] thread initiated with $COMMxxx copies the application clock of its invoker. </li>

<li>A good date for <var>APPDATE</var> testing might be <code>2000/02/29</code>, since that is a valid date, but <code>1900/02/29</code> is not. </li>

<li>The use of the <var>APPDATE</var> command is to establish a clock for all application-level operations. It does not affect static values that had been established prior to the <var>APPDATE</var> command. This is relevant to the value of the <var>BASECENT</var> parameter and the default value of the <var>DEFCENT</var> user parameter, as follows:
<ul>
<li>If the <var>DEFCENT</var> parameter has not been set, its value is the first two digits of the year during Model 204 initialization. An <code>APPDATE SYSTEM ON ...</code> command issued before the User 0 parameter line affects the default value of <var>DEFCENT</var>. All other invocations of the <var>APPDATE</var> command leave <var>DEFCENT</var> unaffected. </li>

<li>The <var>BASECENT</var> parameter is calculated based on the current time whenever the <var>CENTSPLT</var> parameer is set. This current time is taken from the active <var>APPDATE</var> clock, but subsequent invocations of the <var>APPDATE</var> command do not affect the <var>BASECENT</var> parameter. </li>
</ul></li>

<li>The <var>APPDATE</var> command does not affect the date and time printed on header 0 of each output page. </li>

<li>The <var>APPDATE</var> command and the use of the Model 204 <var>SYSDATE</var> parameter are mutually exclusive. </li>

<li><var>$Command</var>, <var>$CommBg</var>, and <var>$CommndL</var> (see [[List_of_$functions]]) provide a mechanism for passing a unit of work to an sdaemon or background thread that is different from the thread that issues the request.

When the requested unit of work receives control, the <code>APPDATE USER</code> settings from the thread that invoked the $function will be in effect. If an <code>APPDATE USER</code> command is issued in the sdaemon thread, its effect is not reflected back to the invoking thread. </li>

<li>The current application date used by <var>#DATExxx</var> functions in [[FUEL]] is set to the active <var>APPDATE</var> clock when the <var>$FunLoad</var> function is used. </li>
</ol>

==See also==
{{Template:Sir2000 topic list}}

[[Category: Sir2000 User Language Tools]]

M204.2290

2022-05-11T23:06:04Z

Goff: Fix z/OS manual name

{{Template:M204.2290 skeleton}}


The <var class="term">token</var> socket function did not complete successfully. 

Response: Contact the System Manager. 

System manager response: Refer to the <var class="book">TCP/IP Programmer's Reference</var> for z/VM, or the: <var class="book">z/OS Communications Server, IP Sockets Application Programming Interface Guide and Reference, Appendix B. Socket call error return codes</var> to determine the meaning of the <var class="term">token2</var>. If the problem is a buffer shortage, see your TCP/IP systems programmer. Otherwise, contact [[Contacting Rocket Software Technical Support|Technical Support]], and have available the audit trail.

{{Template:M204.2290 footer}}

Sessions

2022-03-21T21:20:00Z

Goff: less awkward wording

<var class="product">SOUL</var> provides several $functions to support sessions.
A '''session''' is a workstream that might extend beyond a
<var class="product">Model 204</var> login session and might even be transferred among multiple
<var class="product">Model 204</var> threads or users.
Sessions are especially useful for web applications that require some
context to be maintained over multiple web requests, each of which
requires a login and logout.
Sessions do not, of course, survive the cycling of the Online in which
they were established, and they cannot be passed between Onlines.

Sessions are a collection of data structures that are accessible while
the session is open and that persist as long as the session persists.
These data structures include session <var>$lists</var>, session <var>Longstrings</var>, and
session <var>XmlDocs</var>.
Sessions can also contain objects, that is, instances of a class.

Sessions can be created with <var>[[$Session_Create]]</var>, re-opened with <var>[[$Session_Open]]</var>,
closed with <var>[[$Session_Close]]</var>, and deleted with <var>[[$Session_Delete]]</var>.
Only a single session may be open at a time on a thread, and any session
that is open when a user logs off is automatically closed.
A session can only be open on a single thread at any given time.

Sessions are owned by a specific user, or they are public (in which case
they are considered to be "owned by *", that is, owned by all users).
Non-privileged users can only create, access, and delete public sessions
and those owned by themselves, that is, by their own user IDs.
Privileged, that is system manager or system administrator users, can
create, access, and delete public sessions and those owned by any user.

To reestablish a session between logins (or within a login), each session
requires an identifier called a '''session ID'''.
The session ID is established when the session is created, and it can be changed as needed.
A session ID must be unique for a user ID, or for an entire Online if the
session is public.

Inactive sessions, that is, those that haven't been opened in a long time,
are considered '''timed out''' and are eligible for deletion.
The inactivity time for a timeout can be set at session creation time
and changed whenever the session is closed.

Arguments on <var>$Session_xxx</var> calls, and some system parameters, control the timeout value of sessions. One of these parameters, <var>[[SESMAXTO parameter|SESMAXTO]]</var>, can be reset to ensure that all sessions have a timeout value no greater than the new value of <var>SESMAXTO</var>; this can result in immediate timeout of some sessions.

There are several system parameters that control the availability
and behavior of the session feature:
<table>
<tr><th><var>SESNPRV</var>
</th><td>The maximum number of private sessions that can be active. Setting this value allocates about 160 bytes of virtual storage for each possible session. The default value for <var>SESNPRV</var> is 0, which means that no private sessions can be created.
</td></tr>

<tr><th><var>SESNPUB</var>
</th><td>The maximum number of public sessions that can be active. Setting this value allocates about 160 bytes of virtual storage for each possible session. The default value for <var>SESNPUB</var> is 0, which means that no public sessions can be created.
</td></tr>

<tr><th><var>SESUMAX</var>
</th><td>The maximum number of private sessions that can be active for a single owner (user ID). The default value for <var>SESUMAX</var> is 0, which means that a given user ID can only have one session active at a time.
</td></tr>

<tr><th><var>SESOPT</var>
</th><td>A bitmask parameter that controls the behavior of the session feature. The meaning of the bits are:
<table class="thJustBold">
<tr><th>X'01' </th>
<td>Clean up timed-out sessions. If this bit is on and the X'02' bit is off, every <var>$Session_Create</var>, <var>$Session_Open</var>, <var>$Session_Close</var>, and <var>$Session_Delete</var> call cleans up timed-out sessions. This cleanup could occur well after the timeout occurred if $Sessionxxx calls are relatively infrequent.

Use this option for cleaning up a timed-out session when it is not worth incurring the overhead of having a <var>PST</var> to do the cleanups. Since timed out sessions are now always immediately cleaned up, this bit is irrelevant. </td></tr>

<tr><th>X'02' </th>
<td>Create a <var>PST</var> to clean up timed-out sessions. If this bit is on, a <var>PST</var> is attached in the Online whenever there is an active but not open session. If a session times out, the <var>PST</var> immediately deletes the session, freeing up the <var>CCATEMP</var> pages used by the session.

Use this option if cleaning up sessions very quickly is worth the (probably slight) cost of having a <var>PST</var> to do the cleanup. </td></tr>
</table>

The default value for <var>SESOPT</var> is 0, which means that timed out sessions are not cleaned up and, in fact, can still be opened after timeout, if they are yet to be deleted. Under the default settings, sessions are only deleted when they are timed out, a new private or public sessions is being created, and the maximum like-typed (private or public) sessions are active. In this case, the oldest like-typed session is deleted. 

Since a PST is now attached whenever there are any active sessions in an Online, this bit is irrelevant. The attached <var>PST</var> always actively deletes any timed-out sessions immediately. </td></tr>

<tr><th><var>SESDEFTO</var> </th>
<td>Sets the default timeout value for a session if one is not specified in the <var>$Session_Create</var> call. The default value for <var>SESDEFTO</var> is 900, which indicates a default timeout of 900 seconds, or 15 minutes. If a session is not re-opened within the timeout value of the <var>$Session_Close</var>, it is considered timed-out and liable to deletion under control of the <var>SESOPT</var> flags, or immediately. The <var>SESDEFTO</var> setting can be overridden in many of the <var>$Sessionxxx</var> functions.
</td></tr>

<tr><th><var>SESDEFOW</var></th>
<td>Sets the default open wait-time value for a session if one is not specified in the <var>$Session_Open</var> call. The default value for <var>SESDEFTO</var> is 0, which means a <var>$Session_Open</var> call will not wait if the request session is in-use, that is, open by another thread.
If a session is still in-use after the open wait time, a return code of 2 is set by <var>$Session_Open</var> to indicate the problem.

The <var>SESDEFOW</var> setting can be overridden in the <var>$Session_Open</var> call. </td></tr>
</table>

Sessions can contain both system and <var class="product">SOUL</var> objects.
When a session is closed, any objects associated with a session name,
by [[Global and session objects#Binding global/session names to a variable|the Session keyword]] on a variable declaration or by a
<var>[[Global and session objects#setsession|SetSession]]</var> method in the object class, "follow the closed session" and become logically owned by the session <var>PST</var>.

In addition, any objects accessible indirectly from a session name
also "follow the session."
That is, if an object can be accessed by a session name and that
object contains a reference to another object, the latter object
also "follows the session" when the session is closed.
Because determining which objects can be accessed directly or
indirectly from a session name is very much like object
[[Global and session objects#Managing object storage|garbage collection]],
a <var>$Session_Close</var> causes garbage
collection to be performed for the invoking thread.

Many of the data structures associated with sessions are also
associated with system-wide resources such as <var>CCATEMP</var> pages,
virtual storage, record locks, <var class="product">Janus</var> threads, file locks, and so on.
When a session is closed but not deleted, these resources are
considered to be "owned" by the session <var>PST</var>; where possible, <var class="product">[[SirMon]]</var> tries to indicate this ownership.

==See also==
<ul>
<li>[[Global and session objects|"Global and session objects"]]
</ul>

[[Category:Overviews]]

ONLINE monitoring

2021-11-10T04:30:46Z

Goff: /* Wait type values */

You can monitor the status and performance of an ONLINE system, including SNA Communications Server interfaces, with the MONITOR command. See [[MONITOR command]] for complete command syntax.


MONITOR provides a series of formatted or unformatted displays of system and user statistics about all or a selected set of active users. You can update the displays on a periodic basis, but do not update them more frequently than every five seconds. 

==Unformatted displays==

Unformatted displays show all the nonzero cumulative system or user statistics in a format similar to that provided in the journal: 

<ul>
<li> Series of terms appears in name=value format.</li>

<li> Journal header is not displayed.</li>

<li> Each user is identified by user number.</li>

<li> Account name appears at the beginning of the user's display.
</li>
</ul>

==Formatted displays==

Formatted displays show basic system information, followed by specified user information in labelled columns. 


Basic system information includes the number of:

<ul>
<li> Active users (USR)</li>

<li> Active servers (SVR)</li>

<li> Open buffers (BUF)</li>

<li> Open files (FLS) </li>

<li> A file open as part of one or more permanent groups is followed by an asterisk (*).</li>

<li> Two pound signs (##) indicate that the user has more files open than can fit into the internal buffer used to hold open file names.</li>

<li> System percentage of CPU time (PCPU).</li>

<li> Statistics from the last system performance line written to the journal. If performance monitoring is active and performance lines are being written to the journal, all statistics are shown. Otherwise, only open buffers, open files, and system PCPU are shown.
</li>
</ul>


Specified user information is described in the next section.

==User information in formatted displays==

User information is viewable in the following types of formatted displays:

<ul>
<li> Basic display (default)</li>

<li> User since-last statistics</li>

<li> User performance data</li>

<li> Open files
</li>
</ul>


The following sections describe these types of formatted displays.

===Basic display===

USER SVR USERID P CUR SLICE AGE FUNC CNCT CPU SEQIO QUE WT FLGS
0 SAM S 48 0.075 0 0.041 3 BLKO 04 40
1 1 MARY S 49 0.075 EVAL 266 0.152 36 REDY


Where:

<ul>
<li>USER is the user number.</li>
<li>SVR is the server number.</li>
<li>USERID is the user ID.</li>
<li>P is user priority (P).</li>
<li>CUR is current priority.</li>
<li>SLICE is current CPU time slice.</li>
<li>AGE is user pre-aged priority.</li>
<li>FUNC is the last function to set the since-last parameter.</li>
<li>CNCT is connect time.</li>
<li>CPU is CPU time.</li>
<li>SEQIO is the sequential I/O operations performed.</li>
<li>QUE is the [[#QUE values|current scheduler queue]].</li>
<li>WT is the [[#Wait state values|user wait state]].</li>
<li>FLGS is the sum of the [[#Status flag values|status flag values]].</li>
</ul>

====QUE values====
<table>
<tr class="head">
<th>

QUE value 
</th>
<th>

Means user is...
</th>
</tr>

<tr>
<td>

RUNG 
</td>
<td>

Running.
</td>
</tr>

<tr>
<td>

BLKI 
</td>
<td>

Blocked in server, visible to the scheduler.
</td>
</tr>

<tr>
<td>

OFFI 
</td>
<td>

Blocked in server, invisible to the scheduler.
</td>
</tr>

<tr>
<td>

BLKO 
</td>
<td>

Blocked out of server, visible to the scheduler.
</td>
</tr>

<tr>
<td>

OFFO 
</td>
<td>

Blocked out of server, invisible to the scheduler.
</td>
</tr>

<tr>
<td>

WTSV 
</td>
<td>

Waiting for a server.
</td>
</tr>

<tr>
<td>

REDY 
</td>
<td>

Ready or running.
</td>
</tr>

<tr>
<td>

SWPG 
</td>
<td>

Being swapped in or out.
</td>
</tr>

<tr>
<td>

WTUS 
</td>
<td>

Server waiting for user.
</td>
</tr>

<tr>
<td>

MOVE
</td>
<td>

Moving between queues.
</td>
</tr>
</table>

Tip: As of version 7.7, by summing RUNG, BLKI, BLKO, WTSV, REDY, and SWPG, you can approximate USRS (average active users).

Note: Prior to version 7.7, OFFQ was used instead of OFFI and OFFO.

====Wait type values====
<table>
<tr class="head">
<th>

Wait
</th>
<th>

Description
</th>
</tr>

<tr>
<td>

00
</td>
<td>

Unspecified.
</td>
</tr>

<tr>
<td>

01
</td>
<td>

Disk I/O.
</td>
</tr>

<tr>
<td>
02
</td>
<td>

Sequential user I/O — output.
</td></tr>

<tr>
<td>
03
</td>
<td>

Sequential user I/O — input.
</td></tr>

<tr>
<td>
04
</td>
<td>

Operator's console input (WTOR).
</td></tr>

<tr>
<td>
05
</td>
<td>
Restore reads (BSAM).
</td></tr>

<tr>
<td>

06
</td>
<td>

Dump writes (BSAM). 
</td></tr>

<tr>
<td>
07
</td>
<td>
Enqueue waits (record or noncritical resource).
</td></tr>

<tr>
<td>
08
</td>
<td>

Buffer waits.
</td></tr>

<tr>
<td>
09
</td>
<td>
Wait almost forever (deactivated user).
</td></tr>

<tr>
<td>
10
</td>
<td>
Waits for a pseudo subtask, or waits for reactivation (hung terminal).
</td></tr>

<tr>
<td>
11
</td>
<td>
Waits for an IFAM2 or IFAM4 call.
</td></tr>

<tr>
<td>
12
</td>
<td>
Waits for a wakeup.
</td></tr>

<tr>
<td>
13
</td>
<td>
Server I/O.
</td></tr>

<tr>
<td>
15
</td>
<td>
Writes to the journal data set, CCAJRNL.
</td></tr>

<tr>
<td>
16
</td>
<td>
Checkpoint writes to CHKPOINT data set.
</td></tr>

<tr>
<td>
17
</td>
<td>
Waits for check on previous write.
</td></tr>

<tr>
<td>
18
</td>
<td>
Waits for a checkpoint DECB to free up or waiting for multiuser output arbitration.
</td></tr>

<tr>
<td>
19
</td>
<td>
Waits for a checkpoint request.
</td></tr>

<tr>
<td>
20
</td>
<td>
Waits for a checkpoint completion.
</td></tr>

<tr>
<td>
21
</td>
<td>
Wait forever (dead user).
</td></tr>

<tr>
<td>
22
</td>
<td>
VSAM or sequential file input.
</td></tr>

<tr>
<td>
23
</td>
<td>
User waiting due to excessive login failures.
</td></tr>

<tr>
<td>
24
</td>
<td>
Waits for exclusive control of critical file resource.
</td></tr>

<tr>
<td>
25
</td>
<td>
Waits for share control of critical file resource.
</td></tr>

<tr>
<td>
26
</td>
<td>
Waits for SNA Communications Server buffer, input or output.
</td></tr>

<tr>
<td>
27
</td>
<td>
Waits for interprocess input.
</td></tr>

<tr>
<td>
28
</td>
<td>
Waits for interprocess output.
</td></tr>

<tr>
<td>
29
</td>
<td>
User waiting for the security interface.
</td></tr>

<tr>
<td>
30
</td>
<td>
User(s) waiting, with <code>$Wait(nn,'SWAP')</code>, for a user-defined ECB to be posted by a <var>$Post</var> function from a different user.
</td></tr>

<tr>
<td>
31
</td>
<td>
User(s) waiting, with <code>$Wait(nn,'NOSWAP')</code>, for a user-defined EDB to be posted by a <var>$Post</var> function from a different user.
</td></tr>

<tr>
<td>
32
</td>
<td>
User waiting for DB2 subtask.
</td>
</tr>

<tr>
<td>
33-36
</td>
<td>
Reserved for future development.
</td>
</tr>

<tr>
<td>
37
</td>
<td>
User waiting for recovery to complete.
</td>
</tr>

<tr>
<td>
38
</td>
<td>
Reserved for future development.
</td>
</tr>

<tr>
<td>

39
</td>
<td>
Reserved for future development.
</td>
</tr>

<tr>
<td>

40
</td>
<td>
Waiting for an MQSeries subtask to become available.
</td>
</tr>

<tr>
<td>

41
</td>
<td>
Waiting for a MQ subtask to run.
</td>
</tr>

<tr>
<td>

42
</td>
<td>
MQSeries MQGET operations with wait time specified.
</td>
</tr>

<tr>
<td>

43
</td>
<td>
ECF to load or delete a module. 
</td>
</tr>

<tr>
<td>
44
</td>
<td>
External module to become free. 
</td>
</tr>

<tr>
<td>
45
</td>
<td>
ECF subtask to become free.
</td>
</tr>

<tr>
<td>
46
</td>
<td>
External module to run.
</td>
</tr>

<tr>
<td>
47
</td>
<td>
User(s) waiting, with <code>$Wait('CPQZ')</code>, for the extended quiesce ECB to be posted by the successful completion of a <var class="product">Model 204</var>, system-wide checkpoint.
</td>
</tr>

<tr>
<td>
48
</td>
<td>
User(s) waiting, with <code>$Wait('QZSIG')</code>, for the end of extended quiesce.
</td></tr>

<tr>
<td>
49
</td>
<td>
User(s) waiting, at end of extended quiesce, for count of <code>$Wait('CPQZ')</code> and <code>$Wait('QZSIG')</code> users to go to zero.
</td></tr>

<tr>
<td>
50
</td>
<td>
User is waiting for HSM to recall an archived data set.
</td></tr>

<tr>
<td>
51
</td>
<td>
User is waiting for a share lock on the internal constraints database. 
The constraints database is used to ensure that there is sufficient space on table B pages and in table D to be able to back out active transactions as needed.
</td></tr>

<tr>
<td>
52
</td>
<td>

User is waiting for an exclusive lock on the internal constraints database. 

The constraints database is used to ensure that there is sufficient space on table B pages and in table D to be able to back out active transactions as needed.
</td></tr>

<tr>
<td>
53
</td>
<td>
User is waiting for a subtransaction checkpoint to complete.
</td></tr>

<tr>
<td>
54
</td>
<td>
Checkpoint PST waiting on a blocking file update to complete to try to do a transaction checkpoint.
</td></tr>

<tr>
<td>
55
</td>
<td>
Checkpoint PST doing a timed wait to try to do a transaction checkpoint.
</td></tr>

<tr>
<td>
56
</td>
<td>
Checkpoint PST waiting on users to complete subtransactions.
</td></tr>

<tr>
<td>
57
</td>
<td>
Means a daemon thread waiting for its master thread.
This change is enabled in V7.8 or V7.7 with the application of zap 77z410.
</td></tr>

<tr>
<td>
58
</td>
<td>
Means a master thread waiting for one of its daemon threads.
This change is enabled in V7.8 or V7.7 with the application of zap 77z410.
</td></tr>

<tr>
<td>
80-89
</td>
<td>
Customer (site-specific) wait types.
</td></tr>

<tr>
<td>
97
</td>
<td>
Waiting for a Fast/Unload request running in a real subtask.
</td></tr>

<tr>
<td>
98
</td>
<td>
In a <var>[[MAXAUSER parameter|MAXAUSER]]</var> wait.
</td></tr>

<tr>
<td>
99
</td>
<td>
Waiting for a <var>[[SIRFACT command|SIRFACT QUIESCE]]</var> to be completed (with a <var>SIRFACT RESUME</var>).
</td></tr>
</table>

====Status flag values====
<table>
<tr class="head">
<th>

Flag
</th>
<th>

Description of wait...
</th>
</tr>

<tr>
<td>

40
</td>
<td>

User's wait is swappable. If another user needs this user's server area, the waiter may be written out.</td>
</tr>

<tr>
<td>20</td>
<td>User is waiting for an internal ECB (that is, the ECB is posted only by <var class="product">Model 204</var>, not by the operating system). This can happen, for example, if the waiting user is waiting to access a record to which someone else is preventing access. </td>
</tr>

<tr>
<td>10</td>
<td>ECB to be posted is of the short form (1 byte in length) and is an internal ECB (posted by M204). </td>
</tr>

<tr>
<td>8</td>
<td>More than one user is allowed to wait for the ECB that this user is waiting for. </td>
</tr>

<tr>
<td>4</td>
<td>User can be bumped.</td>
</tr>

<tr>
<td>2</td>
<td>User can be interrupted with an urgent message.</td>
</tr>

<tr>
<td>1</td>
<td>A time limit was specified for the user's wait. For example, if a waiting user is in a record locking conflict situation, it is a timed wait until the request ends and a record locking conflict message is issued, or an <var>ON</var> unit in the code takes control.</td>
</tr>
</table>

====V7.7 layout change====
From V7.7 onwards (with zaps 77Z478 or 78Z023, 78Z026) the AGE column in the basic display output has been replaced with a column, headed LOG, which shows the logon type of each user, as in the following example:

20.149 MAY 28 13.02.36 PAGE 8
USER SVR FLS PCPU SMPLS RUNG REDY BLKI WTSV BLKO SWPG
6 0.290

USER SVR USERID P CUR SLICE LOG FUNC CNCT CPU SEQIO QUE WT FLGS
0 SUPERKLUGE H 252 0.030 CCA DISP 0 0.001 596 OFFO 4 60
7 4 JIMV S 62 0.030 SUB EVAL 10 0.001 9 OFFI 3 66
8 2 ZORRO S 4 0.030 PDG EVAL 93 0.003 36 OFFI 3 66
9 5 TSJRD H 104 0.030 ESM 123 0.001 74 RUNG
10 1 CCAD01 H 110 0.030 CCA 13 0.001 52 OFFI 3 66
31 VT75DIED 0.000 0 0.000 0 2 20
32 VT75READ 0.000 253954 0.013 0 3 00
33 VT75ERRS 0.000 0 0.000 0 2 20
34 CHKPPST 0.000 0 0.001 0 12 20
35 CHKPAWW 0.000 5509 0.000 0 12 20
36 MQDELDTP 0.000 0 0.000 0 12 00
>

Possible values that are shown in the LOG column (logon type) are as follows
<table>
<tr class="head">
<th>Value</th>
<th>Meaning</th>
</tr>
<tr><td>CCA</td><td>CCASTAT userid</td></tr>
<tr><td>ESM</td><td>userid validated by an External Security Manager - ACF2, RACF, or TopSecret</td></tr>
<tr><td>SUB</td><td>Subsystem controlled logon</td></tr>
<tr><td>GST</td><td>Guest - neither logged on via CCASTAT nor by an ESM</td></tr>
<tr><td>PDG</td><td>Logon pending due to errors (e.g. invalid password)</td></tr>
</table>

===User since-last statistics===

User since-last statistics (SL option) show current activity.


If the user is between activities or performing an activity that does not initialize since-last statistics, the display is cumulative.


Statistics displayed are CPU, DKRD, DKWR, UDD, OUT, SLIC, FINDS, RECDS, PCPU, RQTM, SUBSYSTEM, PROC-FILE, PROC, and the pseudo subtask's user ID, account name, and user number. (Refer to the [[#Description of statistics|Statistics with descriptions]] table for statistic definitions, and to [[#Pseudo subtasks|Pseudo subtasks]].) 

===User performance data===

The PERFORMANCE option shows data last written to the journal. The following information is included:

<ul>
<li> Number of samples used to compute percentages</li>

<li> percentage of time the user is in each of the scheduler queues</li>
</ul>


See [[#Priority scheduling|Priority scheduling]].

===Open files===

This display is a list of files a user has open.

==MONITOR examples==

These examples show several variations of the MONITOR command.


The following command specifies a single nonrepeating formatted display of basic information for the system and all active users:

MONITOR


The following command, MONITOR ACTIVE, specifies a single nonrepeating formatted display of basic information for the system and active users, excepting OFFO and OFFI users. (OFFO and OFFI are state-of-queue statuses meaning that the Scheduler does not have to evaluate those users not in the queue. Prior to version 7.7, OFFQ was used instead of OFFO and OFFI.)
The MONITOR ACTIVE command is used to reduce the amount of terminal output.

MONITOR ACTIVE


The following commands specify a display of the cumulative system statistics, which is updated every minute:

MONITOR STATISTICS 60
MONITOR STAT EVERY 60
MONITOR SYSTEM STATISTICS 60


The following command specifies a single display of the cumulative user statistics for users 1, 3, and 5, if they are active:

MONITOR (1,3,5) STATISTICS


The following commands specify a single formatted display of basic system information and basic, since-last, performance, and file information for each active user. Pseudo subtask's user ID, account name, and user number are displayed for SL (since-last) statistics:

MONITOR ALL
MONITOR USERS ALL
MONITOR BASIC SL PERFORMANCE FILE
MONITOR SL FILE PERF


The following commands specify a display of basic formatted information for the system and users 1, 2, 5, and 7, if they are active. The display is repeated continually 75 seconds after it completes. The user must press Enter to display the refreshed version, or enter *CANCEL to terminate the display:

MONITOR (1,2,5,7) 75
MONITOR (1,2,5,7) BASIC EVERY 75


The following command specifies an unformatted display of the following information:

<ul>
<li> Number of active users</li>

<li> Number of compactions of the record locking table</li>

<li> Current number of bytes used in the record locking table</li>

<li> Current high-water mark for the number of bytes used in the record locking table</li>

<li> Current number of headers used in the record locking table</li>

<li> Current high-water mark for the number of headers used in the record locking table</li>

<li> Required LRETBL setting (high-water mark) for the current system load</li>
</ul>

MONITOR ENQ


The following command specifies a formatted display of the number of pages from tables of each file that are currently located in the disk buffers: 

MONITOR DISKBUFF


The following command specifies information about SNA Communications Server's use of output buffers and waits for threads:

MONITOR VTAM


==MONITOR LINK example==


The following command specifies information about a network entity:

MONITOR LINK HEADQTRS


For more information about the MONITOR command for network monitoring, see <var class="product">Model 204</var> Horizon: Intersystem Processing.


In this example, HEADQTRS is the specified network entity for which the Online system operation is being monitored. The following statistics are provided:

 LOCAL ID MAXSES BNDSES IBWTS OBWTS CONVS FLGS TRAN/PROTO
-------- ------ ------ ----- ----- ----- ---- ----------
BOSTACB 4 2 0 0 2 A VTAM/LU62

USER PROCESS SENDS RECVS FLGS PROCESSGRP
----- -------- ----- ----- ---- ----------
3 PROCESS1 5 4 BI DENVER OBSOLETE
4 PROCESS1 5 4 BI DENVER


Where:

<ul>
<li> LOCAL ID is the SNA Communications Server ACB name (BOSTACB).</li>

<li> MAXSES is the maximum number of sessions allowed on this link (4).


The limit is established by the SESSIONS parameter of the DEFINE LINK command.

<li> BNDSES indicates the number of currently bound sessions (2).</li>

<li> IBWTS indicates the number of input buffer waits (0) by inbound conversations.


The input buffer availability is controlled by the actual number of input buffers established by the INBUFNO parameter of the DEFINE LINK command. An input buffer is used on the inbound side when a conversation is being established. If IBWTS is high, and you observe delays while opening inbound processes, then increase INBUFNO.</li>

<li> OBWTS indicates the number of output buffer waits (0).


Note: OBWTS is always zero when the communication protocol is
LU 6.2 (output buffers are not used).</li>

<li> CONVS indicates the number of active conversations (2).</li>

<li> FLGS indicates the status of the link status (A). Possible values for FLGS are:

<table class="thJustBold">
<tr><th>A</th> <td>Active</td></tr>

<tr><th>S</th> <td>Stopped</td></tr>

<tr><th>C</th> <td>Closed</td></tr>
</table></li>

<li> TRAN indicates the transport mechanism: SNA Communications Server or terminal (TERM). In this case TRAN is SNA Communications Server. </li>

<li> PROTO indicates the communication protocol (LU 6.2). Possible values for PROTO are:

<table class="thJustBold">
<tr><th>MSTR</th> <td>Master (for TPROCESS)</td></tr>

<tr><th>XFER</th> <td>Transfer (for TPROCESS)</td></tr>

<tr><th>IMS61</th> <td>IMS LU 6.1</td></tr>

<tr><th>LU 6.2</th> <td>LU 6.2 </td></tr>
</table>


The second line of statistics is a detail line for each bound session.

<ul>
<li> USER provides the external user number (3, 4). A blank occurs if a conversation is not active.</li>

<li> PROCESS indicates the process name (PROCESS1). If a conversation is not active, a blank appears.</li>

<li> SENDS indicates the number of physical sends for each conversation
(5, 5).</li>

<li> RECVS indicates the number of physical receives for each conversation
(4, 4).</li>

<li> FLGS indicates the status of the session (BI, BI). The session status flags are:
<table class="thJustBold">
<tr><th>B </th>
<td>bound </td>
</tr>

<tr>
<th>F </th>
<td>first speaker </td>
</tr>

<tr>
<th>I </th>
<td>inbound </td>
</tr>

<tr>
<th>O </th>
<td>outbound </td>
</tr>

<tr>
<th>L </th>
<td>local bid in progress </td>
</tr>

<tr>
<th>R </th>
<td>remote bid accepted </td></tr>
</table></li></ul>

<li> PROCESSGRP provides the process group name (DENVER). In this example, user 3 is running with an OBSOLETE process group: the process group was stopped and a DEFINE PROCESSGROUP command was issued to change the process group definition for subsequent usage. User 4 is running with the most recent version of the process group definition. </li>
</ul>

==MONITOR PROCESSGROUP example==

The following command specifies reports concerning a specific process group:

MONITOR PROCESSGROUP 


In this example, two PROCESSGROUP reports are produced. The first report is for an active conversation. The second report reflects the stopping and redefinition of the active conversation, which is allocated to another conversation (OBSOLETE with the same process name). Until the conversation with the obsolete process group ends, separate reports are produced for each process group to reflect the more current set of attributes.

 MONITOR PROCESSGROUP DENVER

LINKNAME REMOTEID BNDSES INCONVS OTCONVS FLGS
-------- -------- ------ ------- ------- ----
HEADQTRS DENVACB 2 1 0 A

USER PROCESS SENDS RECVS FLGS
----- -------- ----- ----- ----
4 PROCESS1 5 4 BI

MONITOR PROCESSGROUP DENVER

LINKNAME REMOTEID BNDSES INCONVS OTCONVS FLGS
-------- -------- ------ ------- ------- ----
HEADQTRS DENVACB 2 1 0 AX

USER PROCESS SENDS RECVS FLGS
----- -------- ----- ----- ----
3 PROCESS1 5 4 BI


Where:

<ul>
<li><var>LINKNAME</var> names the associated link (<code>HEADQTRS</code>).</li>

<li><var>REMOTEID</var> provides the Remote LU name (<code>DENVACB</code>).</li>

<li><var>BNDSES</var> indicates the number of bound sessions (2).</li>

<li><var>INCONVS</var> indicates the number of active inbound conversations (1).</li>

<li><var>OTCONVS</var> indicates the number of active outbound conversations (0).</li>

<li><var>FLGS</var> indicates the status of the processgroup (<code>A</code>). The processgroup status flags are:
<table class="thJustBold">
<tr>
<th>A </th>
<td>Active </td>
</tr>

<tr>
<th>S </th>
<td>Stopped </td>
</tr>

<tr>
<th>X </th>
<td>Obsolete </td>
</tr>
</table></li>
</ul>


The second line of statistics is a detail line for each active conversation.

<ul>
<li><var>USER</var> indicates the external user number (4).</li>

<li><var>PROCESS</var> provides the name of the program as it is known to network users (<code>PROCESS1</code>).</li>

<li><var>SENDS</var> indicates the number of physical sends (5).</li>

<li><var>RECVS</var> indicates the number of physical receives (4).</li>

<li><var>FLGS</var> indicates the status of the session status (<code>BI</code>). Status flags are:
<table class="thJustBold">
<tr>
<th>B </th>
<td>Bound </td>
</tr>

<tr>
<th>F </th>
<td>First speaker </td>
</tr>

<tr>
<th>I </th>
<td>Inbound </td>
</tr>

<tr>
<th>O </th>
<td>Outbound </td>
</tr>
</table></li>
</ul>

==MONITOR PROCESS example==

The following command specifies information about a particular process:

MONITOR PROCESS PROCESS1


In this example, two inbound conversations invoked from PROCESSGROUP DENVER (users 3 and 4) are in progress with the process named <code>PROCESS1</code>. The conversation ID (CID) that was assigned in the SOUL <var>OPEN PROCESS</var> statement is <code>PROGRAM1</code>.

MONITOR PROCESS PROCESS1

USER CID PROCESSGRP STARTED SENDS RECVS FLGS STATE
----- -------- ---------- ----------- ----- ----- ---- ------
3 PROGRAM1 DENVER 88349135723 5 4 BI RECV
4 PROGRAM1 DENVER 88349135803 5 4 BI RECV

<ul>
<li><var>USER</var> indicates the external user number (<code>3</code>, <code>4</code>).</li>

<li><var>CID</var> provides the conversation ID (<code>PROGRAM1</code>).</li>

<li><var>PROCESSGRP</var> indicates the name of the processgroup (<code>DENVER</code>).</li>

<li><var>STARTED</var> provides the Julian date and time the conversation began (<code>88349</code> and <code>13:57:23</code>).</li>

<li><var>SENDS</var> indicates the number of physical sends (<code>5</code>, <code>5</code>).</li>

<li><var>RECVS</var> indicates the number of physical receives (<code>4</code>, <code>4</code>).</li>

<li><var>FLGS</var> indicates the status of the session (<code>BI</code>). Status flags are:
<table class="thJustBold">
<tr>
<th>B </th>
<td>Bound </td>
</tr>

<tr>
<th>F </th>
<td>First speaker </td>
</tr>

<tr>
<th>I </th>
<td>Inbound </td>
</tr>

<tr>
<th>O </th>
<td>Outbound </td>
</tr>
</table></li>

<li><var>STATE</var> indicates the state of the conversation (<code>RECV</code>). Conversation states can be:

:ACCEPT
:CLOSE
:CONFCLS
:CONFIRM
:CONFSND
:INITIAL
:RECV
:SEND
</li>
</ul>

==MONITOR DISKBUFF example==

You can use the <var>[[MONITOR command: Disk buffers|MONITOR DISKBUFF]]</var> commands to analyze the buffer pool utilizations:

<ul>
<li><var>MONITOR DISKBUFF</var> output shows buffer usage combining above and below the bar buffers.</li>

<li><var>MONITOR DISKBUFFG</var> output shows buffer pool usage for only above the bar buffers.</li>

<li><var>MONITOR DISKBUFFL</var> output shows buffer pool usage for only below the bar buffer usage.</li>
</ul>


Use these commands throughout the day across varied types of daily and event processing to evaluate your buffer allocations.

===Using MONITOR DISKBUFF commands===

You can see the types of pages that are in your buffer pools at any point in time using the <var>MONITOR DISKBUFF</var> command. The output of this command displays the types of pages that are in buffers and how many of each type.

MONITOR DISKBUFF

FILENAME FCT TBLA TBLB TBLC TBLD TBLE TBLX *TOTAL*
-------- --- ------ ------ ------ ------ ------ ------ -------
CCATEMP 0 40 0 0 0 0 0 40
PROC1 1 0 0 0 11 0 0 12
FILETBLX 1 1 10 0 2 0 2 16
TESTZ 1 1 11 0 3 185 0 201
*TOTAL* 3 42 21 0 16 185 2 269


[[Category:System management]]
[[Category:Model 204 operational issues]]

RECLOCKO parameter

2021-11-09T02:58:06Z

Goff: /* Description */

{{Template:RECLOCKO parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>X'03'
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 CCAIN parameters
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">[[Sirius Mods]]</var> 8.1
</dl>

==Description==
This parameter enhances <var class="product">Model 204</var> handling of record locking conflicts. The meaning of the bits are:
<table>
<tr><td>X'01'</td>
<td>Issue message [[MSIR.1055 (caught) record locking conflict with user (unum) (uname) for file (file) record number (recnum)|MSIR.1055]] for any untrapped record locking conflicts. <code>MSIR.1055</code> provides information about the user that holds the lock and the file and record number for which there's a conflict. The additional messages <code>MSIR.1056</code> and <code>MSIR.1057</code> provide further information about the lock conflict.

A record locking conflict is considered untrapped if both of these are true: 
<ul>
<li>The conflict is not inside a [[Try block#Try and Catch|Try block]] with a <code>Catch RecordLockingConflict</code> clause. </li>

<li>There is no <code>On Record Locking Conflict</code> or <code>On Find Conflict</code> that would be driven by the conflict.</li>
</ul></td></tr>

<tr><td>X'02'</td>
<td>Issue message [[MSIR.1055 (caught) record locking conflict with user (unum) (uname) for file (file) record number (recnum)|MSIR.1055]] for any trapped record locking conflicts. <code>MSIR.1055</code> provides information about the user that holds the lock, as well as the file and record number for which there's a conflict. The additional messages <code>MSIR.1056</code> and <code>MSIR.1057</code> provide further information about the lock conflict.

A record locking conflict is considered trapped if either of these is true: 
<ul>
<li>The conflict is inside a <var>Try</var> block with a <code>Catch RecordLockingConflict</code> clause. </li>

<li>There is an <code>On Record Locking Conflict</code> or <code>On Find Conflict</code> that would be driven by the conflict.</li>
</ul></td></tr>

<tr><td>X'04'</td>
<td>Note: This setting is ignored as of version 7.5 of <var class="product">Model 204</var>. The information that follows here and the comments in the "Usage notes," below, is relevant only to Sirius customers who have not upgraded to <var class="product">Model 204</var> V7.5. 

Maintain extra information in the record locking table. This information is provided in message <code>MSIR.1056</code> or <code>MSIR.1057</code>, following <code>MSIR.1055</code>, which is issued after a record locking conflict (depending on the X'01' and X'02' bits of <var>RECLOCKO</var>), and it can be useful in determining the cause of a record locking conflict. The extra information collected by setting this bit is also available in <var>[[RecordLockingConflict class|RecordLockingConflict]]</var> objects. 

Setting this bit increases the record locking table space requirements. See the usage notes below for more information.</td></tr>
<tr><td>X'08'</td>
<td>Include the record locking table in any SVC dumps. Requires zap 78z131.
</td></tr>
</table>

==== Usage notes ====
<ul>
<li>The default value for <var>RECLOCKO</var> is X'03', which means that all record locking conflicts will result in <code>MSIR.1055</code> messages being issued to provide information about any record locking conflict. Since record locking conflicts should be relatively rare, there would seem to be little cost to always issuing these messages. </li>
<li>In Model 204 version 7.5 and later, the <code>MSIR.1056</code> and <code>MSIR.1057</code> messages appear if the X'01' or X'02' bit is set. In version 7.4 and earlier, these messages do not appear unless the X'04' bit is set.</li>

<li>If both the X'01' and X'02' bits are off, neither message <code>MSIR.1055</code>, <code>MSIR.1056</code>, nor <code>MSIR.1057</code> is issued. </li>
</ul>

----
Note: The X'04' bit of <var>RECLOCKO</var> is ignored as of version 7.5 of <var class="product">Model 204</var>. The comments below are relevant only to Sirius customers who have not upgraded to <var class="product">Model 204</var> V7.5 or later:

<ul>
<li>Setting the <var>RECLOCKO</var> X'04' bit increases recording locking table space requirements, so it should probably be accompanied by an increase in <var>[[LRETBL parameter|LRETBL]]</var>. While a 33% increase in table usage is theoretically possible, the actual increase would probably be significantly less than that, more on the order of 5% to 10%. Since the record locking table is in 64-bit storage, the cost of an increase in <var>LRETBL</var> is an increase in 64-bit storage usage, which should not affect the availability of 31-bit storage. </li>

<li>If the <var>RECLOCKO</var> X'04' bit is set and the conflict is with a single record or recordset lock, message <code>MSIR.1056</code> is issued after an <code>MSIR.1055</code>. <code>MSIR.1056</code> indicates whether the lock being conflicted with is a record or a recordset, whether it is locked share or exclusive, the time the lock was originally obtained, and the user number of the user that originally obtained the lock. The latter could be different from the current user that holds the lock in the case of session objects. The time the lock was obtained can be used to determine what request was running when the record was locked. </li>

<li>If the <var>RECLOCKO</var> X'04' bit is set and the conflict is with a pending update lock, message <code>MSIR.1056</code> is issued after an <code>MSIR.1055</code>, and it indicates that the conflict is with an exclusive pending update lock (pending update locks are always exclusive). A pending update lock is held by <var class="product">Model 204</var> for all updated records in [[Transaction back out|TBO]] files so that users cannot see the partially updated record and so that no other user can update the record until the transaction is committed or backed out. </li>

<li>If the X'04' bit is off, then neither <code>MSIR.1056</code> nor <code>MSIR.1057</code> is issued, whether X'01' or X'02' is on or not. </li>
</ul>


[[Category:System parameters]]
[[Category:Parameters]]

Release notes for Model 204 version 7.8

2020-05-11T05:07:15Z

Goff: Fix typo DEBUGL to DEBUGUL

These release notes list the enhancements and other changes contained in Model 204 version 7.8, which is still in development. Until the commercial release of the software, Rocket reserves the right to add to, remove, or change anything described herein.

==Overview==
These release notes contain installation and features information for the Rocket Model 204 version 7.8 release.
Before beginning your installation, please read through this information about product installation and changes.

==New in this release==
The table below cites some highlights of Model 204 version 7.8. For a full list of features, refer to the Table of Contents.
See also the [[#Compatibility issues|Compatibility]] section for possible issues.
<table>
<tr class="head"><th>Category</th>
<th>Feature</th></tr>
<tr>
<td>SOUL</td>
<td>
<ul>
<li>The new [[#AmIndependent method|AmIndependent]] method returns TRUE for daemons spawned by [[RunIndependently (Daemon subroutine)|RunIndependently]].
</li>
<li>The Object class now supports the [[#Support for copying Object class objects|copy and deepCopy methods]].
</li>
</ul>
</td></tr>

<tr>
<td>Janus Web</td>
<td>
<ul>
<li>[[#Web Sockets|Janus Web Sockets]] are now supported.</li>
</ul>
</td></tr>

<tr>
<td nowrap>Networking</td>
<td>
Note: The two-phase commit and commit exits features are licensed and purchased separately from Model 204.
<ul>
<li>Two-phase commit. A Model 204 online can now be configured to use two-phase commit (2PC). The Janus internal socket API is used for the calls to the coordinator. JANUS commands are used for all 2PC configuration. A new JANUS port type has been added: 2PC.</li>
<li>[[Application_Subsystem_development#Commit_exits|Commit exits]] are now supported. The commit exit runs within the APSY, which is defined by the <var>[[Application_Subsystem_development#COMMITX parameter|COMMITX]]</var> parameter and uses normal APSY processing. </li>
</ul></td></tr>

<tr>
<td>ECF tables</td>
<td>
<ul>
<li>The new <var>[[#DISPLAY ECF|DISPLAY ECF]]</var> command and <var>[[#Managing ECF tables more efficiently|EXTERNAL REMOVE]]</var> statement enable more efficient management of [[#Managing ECF tables more efficiently|ECF tables]].</li>
</ul>
</td></tr>
<tr>
<td>Performance</td>
<td>
<ul>
<li>[[#MP/204 offload improvements|MP/204 offload improvements]] -- application code for these SOUL statements is now fully offloadable:
<ul>
<li><var>File Records In/On</var></li>
<li><var>Remember</var></li>
<li><var>Position</var></li>
<li><var>Sort Values</var></li>
<li><var>Reset Header/Trailer</var></li>
<li><var>Find and Print Count</var></li>
<li><var>Find All Values</var></li>
<li><var>For Each Value</var></li>
</ul>
</li>
</ul>
</td></tr>

<tr>
<td>Security</td>
<td>
<ul>
<li>CA-Top Secret can [[#CA-Top Secret can disallow CCASTAT logins|disallow CCASTAT logins]].</li>
<li>[[#DEFUSER can specify a jobname not authorized to access M204|DEFUSER]] can specify a jobname not authorized to access M204.</li>
</ul>
</td></tr>

<tr>
<td nowrap>System enhancements</td>
<td>
<ul>
<li>The <var>[[MONITOR command|MONITOR <var>USERS</var>]]</var> command output displays [[#New wait types for daemon/master waits|two new wait types]].</li>
</ul></td></tr>

<tr>
<td nowrap>AUDIT204 enhancements</td>
<td>
<ul>
<li>The new TIMEHH parameter on the <var>[[#FORMAT command|FORMAT]]</var> command of the AUDIT204 utility provides greater time stamp precision.</li>
</ul></td></tr>

<tr>
<td nowrap>New commands</td>
<td>
<ul>
<li><var>[[#DISPLAY ECF|DISPLAY ECF]]</var> displays details from ECF tables, or the current status of users accessing ECF modules.</li>
</ul></td></tr>

<tr>
<td nowrap>New parameters</td>
<td>
<ul>
<li><var>[[#ENQTIME|ENQTIME]]</var> specifies the number of milliseconds waited for each record locking retry wait.</li>
<li><var>[[#EVALOPT|EVALOPT]]</var> controls the cancellation of a request on truncation of string data.</li>
<li><var>[[#MAXPRE, MAXBOUT, MAXSUBT|MAXPRE, MAXBOUT, and MAXSUBT]]</var> can be used to cancel a runaway transaction and prevent it from filling the checkpoint data set.</li>
<li><var>[[#NLDAPBUF|NLDAPBUF]]</var> allows the number of LDAP buffers allocated during startup to be set in CCAIN.</li>
<li><var>[[#SERV4G|SERV4G]]</var> allows testing of server tables that span a 4-gigabyte boundary.</li>
<li><var>[[#WEBDFLT|WEBDFLT]]</var> changes the default JANUS WEB ALLOW rule back to ALLOW.</li>
</ul></td></tr>

<tr>
<td nowrap>Janus and TN3270 debuggers</td>
<td>
<ul>
<li>The debuggers can now view or watch the values of [[#Access to exposed variables|variables exposed to local routines/methods]].</li>
<li>When execution pauses, the debuggers now [[#Subroutine or method display|display the subroutine or method]] being executed.</li>
</ul></td>
</tr>

<tr>
<td nowrap>User/system statistics</td>
<td>
<ul>
<li><var>[[#MPR, MBO, MCP, and RCV|MPR, MBO, MCP, and RCV]]</var> provide high water mark transaction information in conjunction with the <var>[[#MAXPRE, MAXBOUT, MAXSUBT|MAXPRE, MAXBOUT, and MAXSUBT]]</var> parameters.
</li>
<li>[[#DKWTS and DKWTMICS|New system statistics]] DKWTS (DisK WaiTs) and DKWTMICS (DisK WaiT MICroSeconds) collect data to provide rough disk I/O service time numbers.</li>
</ul></td></tr>
</table>

==Operating system and hardware requirements==

===Operating system requirements===

<ul>
<li>IBM z/OS versions supported:
<ul>
<li>All IBM supported releases up to and including z/OS 2.3. (For z/OS 2.2, see [[IBM z/OS 2.2 PTF requirement]].)</li>
Version 1.07 is sufficient for all functionality except for the following features:
<ul>
<li>zHPF support requires version [[IBM z/OS 2.1 compatibility issue|2.1]].</li>
<li>Large (1 MB) page support requires version 1.9.</li>
<li>Extended address volumes (EAV) requires version 1.12.</li>
</ul>
</li>
</ul>
On z/OS, Model 204 release 7.8 operates as an APF authorized load module, as required by many 7.8 features. 
To run Model 204 unauthorized, [[Contacting Rocket Software Technical Support|contact Technical Support]].

<li>IBM z/VM versions supported:
<ul>
<li>All IBM supported releases up to and including z/VM 6.4.</li>
</ul>
</li>

<li>IBM z/VSE versions supported:
<ul>
<li>All IBM supported releases up to and including z/VSE 6.1.</li>
</ul>
</li>
</ul>

===Hardware requirements===

In general, Model 204 version 7.8 requires the IBM z/890 or above processor.
However, the IBM z10 or above processor is required for the following features:
<ul>
<li>large (1 MB) page support</li>
<li>IBM's High Performance FICON (zHPF) support</li>
</ul>

===Connect★ compatibility with Model 204===

Connect★ version 7.5 or 7.7 is compatible with Model 204 version 7.8.

For more information on Connect★ installation, see the [[:Category:Connect*|Connect★ wiki pages]].

==SOUL (User Language) enhancements==
===AmIndependent method===
The <var>AmIndependent</var> method returns TRUE for daemons spawned by <var>[[RunIndependently_(Daemon_subroutine)|RunIndependently]]</var>. (The action of <var>[[AmDaemon_(Daemon_property)|AmDaemon]]</var> remains unchanged.)

The following table shows the values returned by <var>AmIndependent</var> versus <var>AmDaemon</var> for different daemon types:
<table>
<th>Type</th>
<th>AmDaemon</th>
<th>AmIndependent</th>
<tr>
<td>$COMBG</td>
<td>False</td>
<td>False</td>
</tr>
<tr>
<td>Independent daemon</td>
<td>False</td>
<td>True</td></tr>
<tr>
<td>Other daemon</td>
<td>True</td>
<td>False</td>
</tr>
<tr>
<td>Web, etc.</td>
<td>False</td>
<td>False</td>
</tr></table>

===EndsWith function===
The [[EndsWith (String function)|EndsWith String function]] determines if one string ends with the characters in another. This is analogous to the [[StartsWith and IsStartOf (String functions)|StartsWith function]] except, of course, it checks the end of a string rather than the start.

The following code snippet:
printText {~="War and Peace":endsWith("Peace")}
printText {~="War and Peace":endsWith("War")}

displays:
"War and Peace":endsWith("Peace")=True
"War and Peace":endsWith("War")=False


===$ProcOpn===
<var>[[$ProcOpn|$ProcOpn]]</var> now supports the opening of a procedure with an all-numeric name, and including a leading zero, such as:

%result = $procOpn('0123', 'MYFILE')

Support for such procedure names was initially introduced at V7.7, and this feature of <var>$ProcOpn</var> is enabled in V7.7 with the application of zap 77z054.

===Allow parentheses to surround a boolean enumeration object===
The following sample code:
 begin
variables are undefined
%isValid is boolean initial (True)
if (%isValid) then
print 'in IF'
end if
end 

will now compile and run successfully, since this syntax:

if (%isValid) then 

is logically equivalent to this:

if %isValid then 

Prior to V7.8 the presence of parentheses surrounding the boolean enumeration object would have caused a compilation error. This change is enabled in V7.7 with the application of zap 77z370.

===Support for copying Object class objects===
The Object class now supports the copy and deepCopy methods. For example, an Object object can be copied as follows:
 begin
%x is object object
%y is object object
%y = new
%x = %y:copy
end 

This change is enabled in v7.7 with the application of zap 77z076, and within V7.6 with the application of zap 76z412.

===Assignment of enumeration values to method variables===
Enumeration values can now be assigned to method variables whose result is an enumeration. So, for example, the following code:
 begin
enumeration colour
public
value red
value white
value blue
end public
end enumeration
%func is function getColour is enumeration colour
local function getColour is enumeration colour
return blue
end function
%func = getColour
%func = (colour):red
printText {~=%(Local):(%func)}
end 

will produce this result:

 %(Local):(%func)=red 

whereas previously this line:

 %func = (colour):red 

would have been rejected with this message:

MSIR.0993: Assignment invalid: mismatch between method and method variable 

This change is enabled in V7.7 with the application of zap 77z128.

===Optional output method parameters===
Prior to this release output parameters could not be optional or have default values. In this release output parameters can be specified as <var>Optional</var>, and a default value can be specified with <var>Default</var>. One related change is that if a <var>Len</var> value is specified with <var>Optional</var> or <var>Default</var> <var>Output</var>, it indicates the length of the hidden target for the output parameter if none was passed. For all other <var>Output</var> parameters, <var>Len</var> is meaningless, just as it was before Model 204 V7.8. The following is an example of the use of an optional output parameter:
function getRemote( -
%target is string len 32, %errorReason is string len 80 optional output -
) is float
...

In this example, if <code>%errorReason</code> is not specified in a call and then set to a value longer than 80 bytes it will be truncated to 80 bytes. However, if a string of a different length is passed, the length of that string will determine truncation behavior.

==External Call Facility enhancements==
===Managing ECF tables more efficiently===
There are two new features to help manage ECF tables more efficiently, avoid conditions where the table can fill, and prevent the definition of further entities.

The first feature is the new <var>DISPLAY ECF</var> command, which displays the contents of ECF tables and also the current status of users accessing ECF modules. See more details of the <var>[[#DISPLAY ECF|DISPLAY ECF]]</var> command below.

The second feature is a new <var>EXTERNAL REMOVE</var> statement with the following syntax:

EXTERNAL REMOVE modulename

This statement causes the entry for the named module to be removed from the module table. The table entry is then placed on a free chain of entries and can be reused by issuing the <var>[[External_Call_Facility#External_Module_statement|EXTERNAL MODULE]]</var> statement. This allows the module table to be managed with redundant entries removed, without having to recycle the ONLINE.

An <var>EXTERNAL REMOVE</var> statement will return <code>$status/$statusd</code> values of <code>0/0</code>, and most other status values that can be returned by the <var>EXTERNAL REMOVE</var> statement are already documented in the ECF return codes table. If an <var>EXTERNAL REMOVE</var> is attempted against a module that is currently being called (in use), then <code>$status/$statusd</code> will return the values <code>20/1</code> (module unavailable).

==System enhancements==

===New wait types for daemon/master waits===

Two new wait types, viewable on the <var>[[MONITOR_command|MONITOR]] USERS</var> command output, have been implemented as follows:

<code>57</code> - Means a daemon thread waiting for its master thread 
<code>58</code> - Means a master thread waiting for one of its daemon threads

This change is enabled in V7.7 with the application of zap 77z410.

===Snap formatting changes===
Date/time stamps in the page headers of snaps will now be shown in normal format, rather than in Julian format as in previous versions. So in the following example, a particular snap header under v7.7 or previous versions would show as:

SNAPID 1 19226.060155 M204.0022: Bug .. nnnnn PAGE 1 

whereas the same snap header under v7.8 would show as:

SNAPID 1 2019/08/14 06:01:06 M204.0022: Bug .. nnnnn PAGE 1 

Also, due to improvements in handling trailing blanks in snap output, a snap generated under v7.8 should be marginally smaller than the same snap generated under previous versions, assuming the same <var>[[SNAPCTL parameter|SNAPCTL]]</var> settings.

===Call stack trace for problem diagnosis===
A call stack trace is now provided to help diagnose and resolve common errors. To enable the stack trace, do either of the following:
<ul>
<li>Set the <var>[[SIRFACT parameter|SIRFACT]] X'01'</var> bit.</li>
<li>Set the <var>[[DEBUGUL parameter|DEBUGUL]]</var> parameter. Note that the <var>DEBUGUL</var> approach will introduce extra QTBL overhead. (<var>DEBUGUL</var> provides a similar facility with an include trace of procedures leading to the error, but this might not be potentially as useful as the call trace.)
</li>
</ul>

The call stack trace can assist in diagnosing run-time errors that might occur, as illustrated by the following "Variable too small for result" and "MBSCAN exceeded" examples.

====Variable too small for result====
When the stack trace is enabled, a "variable too small" error results in the following message:

M204.2966: Error at line n, procedure ''procname'' in file ''procfile''

which identifies the line within a procedure where the error is occurring, in addition to the usual message:

M204.0552: Variable too small for result

Any subsequent M204.2966 messages indicate the point in the code from where the code in error was called. For example, a stack of three subroutine calls leading to a "variable too small" error might result in the following messaging:
M204.0552: Variable too small for result M204.2966: Error at line 978, procedure DOCOOLSTUFF in file COOLFILE
M204.2966: Called from line 1215, procedure FOOBAR.CLASS in file CLASSES
M204.2966: Called from line 378, procedure SILLY.CLASS in file CLASSES
M204.2966: Called from line 187, procedure P.ROCKANDROLL in file APSYFILE


This information should help in diagnosing the problem.

If the error occurs within a command level program rather than a procedure, then the M204.2966 message is replaced by an M204.2967 message, and a similar error condition to the above with a preceding call stack might be audited as follows:
 M204.0552: Variable too small for result
M204.2967: Error at line 14 of command level program
M204.2967: Called from line 5 of command level program
M204.2967: Called from line 3 of command level program 

If neither <var>SIRFACT X'01'</var> nor <var>DEBUGUL</var> is set, then the "variable too small" error produces the following messages:
 M204.0552: Variable too small for result
M204.2968: Error: no debug info 

====MBSCAN exceeded====
Similarly to the handling of the "variable too small for result" error, the call stack can also be used to diagnose errors where the value of <var>[[MBSCAN parameter|MBSCAN]]</var> is exceeded as a result of a direct search of Table B records.
Again, under V7.8, with either the <var>SIRFACT X'01'</var> bit set or <var>DEBUGUL</var> set, if a long request occurs as a result of exceeding <var>MBSCAN</var>, then initially the following message is produced, as before:
M204.0569: File ''filename'', Find: Table B records to be searched = ''nnnn''
followed by a DYRWT prompt message. If the user replies 'N' to the prompt, or if the request is run in an environment (such as a batch job) where the default response is 'N', the following message is produced after the M204.0569 message:
Cancelling request: M204.2969: MBSCAN (''mm'') exceeded, records to be searched = ''nnnn''

where ''mm'' is the current setting of <var>MBSCAN</var>. The M204.2969 message is followed by M204.2966 messages displaying the call stack trace. Thus, if the following code is run from procedure MYPROC.MBSCAN against the demo database, with an <var>MBSCAN</var> setting of 10:
 b
call sub1
sub1: subroutine
fd1:
in clients fd city = ONTARIO
end find
fr fd1
pai
print
end for
end subroutine
end 

then the following messages are produced, assuming any prompts are responded to with an 'N':
 M204.0569: File CLIENTS, Find: Table B records to be searched = 3415
Cancelling request: M204.2969: MBSCAN (10) exceeded, records to be searched = 3415
M204.2966: Error at line 6, procedure MYPROC.MBSCAN in file MYPROC
M204.2966: Called from line 3, procedure MYPROC.MBSCAN in file MYPROC 

===appendJournalData===
The <var>[[AppendJournalData_(Stringlist_function)|AppendJournalData]]</var> function is now more tolerant of an outstanding BUMP request. Previously, if <var>AppendJournalData</var> was called to inadvertently retrieve a large amount of journal data, typically when called implicitly from within SirScan, then any outstanding BUMP request wouldn't be honored until all of the data had been retrieved, at which point the BUMP request would be completed, and all data would be lost.

Now, the <var>AppendJournalData</var> process checks for outstanding BUMP requests before each track I/O is executed, thus avoiding excessive I/Os against the journal and long waits for the BUMP of such a process to complete.

==Editor enhancements==
The [[Model 204 full-screen editor#exit|Model 204 editor]] has been enhanced to not hold a lock on a procedure being edited. Instead the timestamp of the procedure on disk is compared against that of the edited procedure when it was loaded or last saved. If different, the save is not allowed. New commands <var>SSAVE</var>, <var>EEND</var>, and <var>GGO</var> are available to force the save in this situation.
In addition, the <var>GO</var> command no longer updates the procedure on disk before <var>INCLUDE</var>ing it if it has not been modified in the editor.
==AUDIT204 enhancements==
===FORMAT command===
TIMEHH is a new parameter used with the FORMAT command of the [[Tracking_system_activity_(CCAJRNL,_CCAAUDIT,_CCAJLOG)#AUDIT204_utility|AUDIT204]] utility. It indicates that timestamps, printed at the beginning of each line of output, should include hundredths of a second. Requires no other arguments.
NOTE: This parameter and the 78 version (or later) of AUDIT204 may be used against a 77 (or later) CCAJRNL.
For example:
//CCAIN DD *
FORMAT YEARFORM 4
TIMEHH
TYPE ER MS LI

==Recovery enhancements==
===Media Recovery in a multi-user environment===
It is now possible to perform media recovery by issuing the <var>REGENERATE</var> command to roll forward selected files in a multi-user environment, with the media recovery being carried out by different users with system manager privileges. The new USING option allows for the specification of a ddname for the input journal stream to be used by the <var>REGENERATE</var> command. Previously media recovery was restricted to single user batch jobs, using the CCAGEN ddname for the input journal. For more details, see the <var>[[#REGENERATE|REGENERATE]]</var> command below.

===MERGEJ now supports up to 99 input journals===
The MERGEJ utility, used to merge journals with overlapping timestamps prior to running Media Recovery, now supports up to 99 input SORTINnn journals to be merged. For this release it is still the case that any previously merged journal must be defined as SORTIN01 to the MERGEJ run, and thus that the MERGEJ run can not accept more than one previously merged journal as input.

==Security enhancements==
===CA-Top Secret can disallow CCASTAT logins===
The [[CA-Top_Secret_interface|CA-Top Secret]] interface now recognizes the <code>DEFACID=</code>, setting and does not allow CCASTAT logins in the online if <code>DEFACID</code> is set to null. (There is no attempt to log on M204USR.) Therefore, to disallow CCASTAT logons, set DEFACID=, in [[CA-Top_Secret_interface#Preparing_a_TOPSPARM_parameter_module_with_TOPSGEN|TOPSPARM]]. CCASTAT will be opened because it contains file and group passwords, but it will not be used for logons if CCASTAT logons are not allowed.

===CUSTOM=11 and mixed cased input===
The <var>[[CUSTOM_parameter|CUSTOM]]</var> parameter <var>CUSTOM=11</var> setting no longer requires that a <var>*LOWER</var> command be issued prior to a <var>LOGCTL</var> command (to add or change a password) to preserve mixed case input. Prior to this release, with <var>CUSTOM=11</var> in place, *LOWER had to be issued before a <var>LOGCTL</var> command, otherwise any mixed case password strings would automatically be translated into uppercase. This change is enabled in V7.7 with the application of zap 77z108.

===DEFUSER can specify a jobname not authorized to access M204===
When specifying DEFUSER=JOBNAME and VALIDAT=LOGON in the RACFGEN parms for an ONLINE, if the specified jobname (the owning id for the ONLINE job) isn't authorized to use Model 204 via RACF, any LOGIN commands specifying no userid will now succeed (previously such a LOGON would have failed). This enables users to submit jobs with USE $JOB, whereby the string USER=jobname will be added to the submitted JCL. This in turn is useful if the specified jobname has dataset access privileges to datasets required by the submitted jobs, even if the jobname itself isn't authorized to use M204.

==Janus product enhancements==

===Web API calls available on transactional daemons===
Transactional daemons can now use the Janus Web API, mostly $functions that begin with <var>$web</var>. The new [[$Web_Api|$web_api function]] makes it possible to test if the Janus Web API is available, whether on a Janus Web Server thread or one of its transactional daemons.

===Web Sockets===
Web Sockets are now supported in Janus Web Server.

The Web Socket protocol provides various advantages over the HTTP protocol:
<ul>
<li>Web Sockets allow full-duplex communication.</li>
<li>Efficient framing of payload data uses minimal overhead.</li>
<li>The Web Socket protocol is end-user extensible.</li>
<li>Most importantly, Web Sockets can be deployed completely within an existing HTTP/HTTPS framework.</li>
</ul>

To implement Web Sockets, you must enable the Janus Web port for Web Socket upgrades with the new <var>WEBSOCKET</var> parameter. The WEBSOCKET option can be specified on either the port definition or the JANUS WEB rule for the URL.
Likewise, an individual Janus Web rule can either allow or disallow Web Socket connections with the <var>WEBSOCKET</var> and <var>NOWEBSOCKET</var> parameters, respectively.

For details on implementing Web Sockets, see the [[WebSocket_(Socket_function)|WebSocket]] wiki page.

===$Web_Form_Parm_Binary===
Janus Web now defers ASCII to EBCDIC translation of form parameter values until a value is requested. This makes it possible to retrieve the exact values sent by the client rather than a translated version. This is important if a form parameter value is UTF-8 encoded and contains non-7-bit ASCII characters (for example if a form parameter contains XML). The [[$Web_Form_Parm_Binary]] function returns the exact value sent by a client for a form parameter with no character translation.

===Janus Web Server access rule===
The automatic <var>[[JANUS WEB ALLOW]]</var> rule, which allowed any user to access the port without requiring a login, is changed for non-SSL ports to the following:
JANUS WEB portname DISALLOW *


This rule requires a system administrator to explicitly define <var>ALLOW</var> rules to enable users to access non-SSL ports.
The rule applies unless overridden by user-added rules.

<blockquote class="note">
Note: To revert from this change in the JANUS DEFINE default and make the default
non-SSL <var>ALLOW</var> rule as it was in version 7.5 and earlier (<code>ALLOW *</code>), turn on the 1 bit of the <var>[[WEBDFLT parameter|WEBDFLT]]</var> parameter: 
RESET WEBDFLT=1
</blockquote>

===Increase in pending accepts for Janus BPX ports===
The default number of pending accepts for Janus BPX server ports has been increased from 3 to 12, thus reducing the likelihood that a pending accept may fail with the message

MSIR.0019 Connection request rejected for port (port), MAXCON exceeded

The actual number of pending accepts to be supported on the port can be set with the new parameter MAXPEND, set on the <var>[[JANUS_DEFINE|JANUS DEFINE]]</var> command, where MAXPEND can vary from 3 up to a maximum value of 32. The change to the default value is enabled in V7.7 with the application of zap 77z269.

===TCP listen backlog increased===

The [[Program_Communication_facilities#LISTEN_call|TCP listen]] backlog has been increased from 16 to 1024 under z/OS.

This update tells the TCP stack to queue up a maximum of 1024 such requests before dropping any. This increased backlog reduces, or in most cases eliminates, the likelihood of a connection request drop, other than in exceptional circumstances, such as a denial of service attack. This change is enabled in V7.7 with the application of zap 77z340.

===Defer the freeing of XMLSCREEN input XML===

The freeing of <var>[[XMLSCREEN_and_NOXMLSCREEN_(JANUS_DEFINE_parameters)|XMLSCREEN]]</var> input XML is now deferred until the next Read Screen or session termination. This means that if an application error is detected, the input XML can be retrieved with [[$Web_Input_Content|$Web_Input_Content]] and then logged for problem analysis.

Prior to this release the XML received from the client was freed immediately after being used to set the input data for a Read Screen, rendering it unavailable for problem determination.

This change is enabled in V7.7 with the application of zap 77z368.

===XMLSCREEN and Janus Web Legacy blank stripping===

xmlScreens and Janus Web Legacy screens now adhere to the same standard as standard screen processing in terms of stripping leading blanks from input fields defined as [[Full-screen_feature#DEBLANK_or_NODEBLANK_option|DEBLANK]] (either explicitly or implicitly).

This change is enabled in V7.7 with the application of zap 77z400.

===SSL input buffer size===

The default value of <var>[[SSLIBSIZE_(JANUS_DEFINE_parameter)|SSLIBSIZE]]</var> has been increased to 16384 + 128, or 16512. This size should ensure correct communication with all TLS spec compliant applications. It is the maximum size allowed unless you use <var>[[CUSTOM_parameter#Using_CUSTOM.3D.2818.29|CUSTOM=18]]</var>.

This change is enabled in V7.7 with the application of zap 77z415.

===Increasing LDAP buffers===

The number of LDAP buffers allocated at startup can now be changed by setting the <var>NLDAPBUF</var> parameter in CCAIN. See below for details on <var>[[#NLDAPBUF|NLDAPBUF]]</var>.

===Increase URL length returned with $web_form_action===
With this release the maximum Janus Web Server incoming URL that can be handled by <var>$web_form_action</var> is increased from 512 bytes to 1280 bytes. This change is enabled in V7.7 with the application of zaps 77z424 and 77z448.

===Maximum RBSIZE setting increased===
The maximum value for RBSIZE, set on the <var>[[JANUS DEFINE|JANUS DEFINE]]</var> command, is now increased to 16777215 (previously the maximum was 65534). RBSIZE specifies the RPC or Request Buffer size. On a Web port, the Janus request buffer holds browser request information such as header data, cookies, and form data. On other port types, it holds RPC input and output parameters. This change is enabled in V7.7 with the application of zap 77z427.

===Limiting the production of MSIR.0019 and MSIR.0020 messages===
The production of the following messages

MSIR.0019 Connection request rejected for port (port), MAXCON exceeded

MSIR.0020 Connection request rejected for port (port), no SDAEMONS available

is now limited to a maximum of one each per time interval set by the <var>[[MAXAUSEW_parameter|MAXAUSEW]]</var> parameter ( minimum seconds between <var>[[MAXAUSER_parameter|MAXAUSER]]</var> warnings, which defaults to 10 seconds ). This avoids flooding the journal / jlog with these messages in situations where the number of connections on a port has been exceeded ( MSIR.0019 ), or the the number of available daemon threads has been exceeded ( MSIR.0020 ).

This change is available in V7.8 with the application of zap 78z011, and within V7.7 with the application of 77z466

==Debugger enhancements==
These enhancements apply to the Janus and TN3270 debuggers.

===Access to exposed variables===
The debuggers can now view or watch the values of variables exposed to local routines/methods. Previously, any attempts to access an exposed variable would have displayed "%varname has no value" in the debugger session. This feature is enabled in V7.7 with the application of zap 77z363.

===Subroutine or method display===
When execution pauses for a break point or runtime error, the subroutine or method being executed is indicated in the status area. In addition, the source code line information available by right-clicking on a source line now also indicates the subroutine or method.

==Performance enhancements==

===MP/204 offload improvements===
Application code issuing the following SOUL statements will be fully offloadable:
<ul>
<li><var>File Records In/On</var></li>
<li><var>Remember</var></li>
<li><var>Position</var></li>
<li><var>Sort Values</var></li>
<li><var>Reset Header/Trailer</var></li>
<li><var>Find and Print Count</var></li>
<li><var>Find All Values</var></li>
<li><var>For Each Value</var></li>
</ul>
The above improvements are enabled in V7.7 with the application of zaps 77z419 and 77z420.

Also, [[JANUS WEB|Janus Web rules]] scanning will be offloadable. In addition, the scan for persistent web sessions ([[$Web_Form_Done]] and [[Janus Web Legacy Support]]) will be offloadable. While the rendezvous with the persistent thread will still be maintask-only, stateless requests will not need to go back to the maintask to be processed and, even for persistent requests, the persistent session lookup will be offloadable. These changes should provide better scalability for MP/204 sites with heavy Janus Web activity.

===X3270OUT exit offloadable===
When running MP/204 (AMPSUBS>0) and using the [[Coding_SNA_Communications_Server_conversion_exit_routines#X3270OUT_.28convert_output_from_3270_format.29|X3270OUT]] exit to convert a 3270 output data stream to the appropriate device protocol, the exit can now run in parallel mode to improve performance. This change is enabled in V7.7 with the application of zap 77z313.

The X3270OUT exit must be written to be re-entrant.

===Internal performance improvements===
A number of internal performance and optimisation improvements have been made in this release. these include

<ul>
<li>Sampling buffer pool pages rather than carrying out a full scan of large buffer pools ( NUMBUFG > 200000 ) when calculating BUFFnnn stats for SirMon</li>
<li>Optimising group and file closure, in particular providing relief on exit from APSYs where a lerga number of groups may be in use, and where the groups may comprise a large number of file members</li>
<li>Improved handling of timer queues, particularly in an MP/204 environment</li>
<li>More aggressive prioritisation of journal and checkpoint I/O, in order to reduce user waits for such I/), and to reduce related waits on critical file resources
</ul>

==New and changed commands==
===MONITOR IODEV===
This new command displays the total number, the current usage and the maximum number of each IODEV type. If the Model 204 parameters include telnet threads (TNDEV parameter), the specified IODEV will actually execute as a daemon thread (SDAEMDEV parameter). For that reason, both the telnet and daemon IODEVs will be incremented and the telnet IODEV will appear with an appended '*'. 
M IODEV 
Iodev Total Active ( % ) Maximum ( % )
1 1 1 100% 1 100%
7 300 100 33% 150 50%
11 4 0 0% 1 25%
15 500 50 10% 80 16%
25 1 0 0% 0 0%
27 10 0 0% 0 0%
29 10 1 10% 1 10%
51 5 0 0% 0 0%
21* 1 1

===DISPLAY ECF===
DISPLAY ECF {{ M | N | U } like ?} 

This new command displays details from ECF tables, or the current status of users accessing ECF modules.

<code>D ECF M</code> displays the contents of the module table. For example: D ECF M
Module Loadlib Address:Length Loaded@ Lastused@ #Calls Flags
QATUM13C PROGLIB 2FB91FB8:00000028 19023:121506 19023:121506 00000001
QATUM13B PROGLIB 2FE65000:00009C18 19023:121506 19023:121506 00000001
QATUM13A PROGLIB 2FE6EC18:00001CD8 19023:121506 19023:121506 00000001

(flags may be D=deleted; S=shared; H=halted; I=Idle)

<code>D ECF N</code> displays contents of the name table. For example: D ECF N
Module Logical-call-name
QATUM13C MOD_QATUM13C
QATUM13B MOD_QATUM13B
QATUM13A MOD_QATUM13A 

<code>D ECF U</code> displays details of users currently accessing ECF modules. This is also the default option, and so <code>D ECF</code> will display the same output as <code>D ECF U</code>. For example:
 D ECF U
User# Userid Module Parmlen
00002 ADMIN --none--
00003 ADMIN COBSAMP1 00000002
00004 ADMIN COBSAMP1 00000002 

<code>D ECF <var class="term">function</var> LIKE <var class="term">?</var> </code> (where <var class="term">?</var> is a valid pattern) displays details for entities that match the specified pattern. The function is either M (modules), N (names), or U (users), and it defaults to U. So for example:

D ECF U L A
or
D ECF U L A*

displays details of ECF users whose names begin with A.

===REGENERATE===
The <var>[[REGENERATE command|REGENERATE]]</var> command can now be run in a multi-user environment by multiple users with system manager privileges. A new option USING is provided to specify the ddname of the input journal, so that the full syntax is now as follows:
 REGENERATE [USING ddname] FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th] | LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th | CHECKPOINT yy.ddd hh:mm:ss.th} ]

The default for the using ddname is CCAGEN, but any ddname may be used to allocate an input journal and used. For example:
 ALLOCATE REGEN1 WITH SCOPE=SYSTEM DSN=PROD1.GDGJ OLD SEQUENTIAL GEN=+2
REGENERATE USING REGEN1 FILE TEST

It is the user's responsibility to ensure that the file being regenerated is not in use, and so prior to usage, <var>BUMP FILE</var> and <var>STOP FILE</var> should be used to isolate usage against the file. If the file is in use, the REGEN will fail with these messages:
 M204.1430: Failed to open file TEST
M204.1436: Stopped processing file TEST 

$STATUS will now be set for <var>REGENERATE</var> with the following values:
<blockquote>
0 - Success 
1 - No files were processed 
2 - At least one file stopped processing 
4 - A serious error occurred, REGEN failed
</blockquote>

Similarly, <var>[[SETGRC command|SETGRC]]</var> may be used to get the return code and error message.

==New and changed parameters==

===COMMITX===
The commit exit runs within the APSY defined by the <var>COMMITX</var> parameter and uses normal APSY processing.

The new parameter <var>COMMITX</var> is settable from User 0's parameter line or by the system manager. It can be reset at any time by the system manager.

Setting/Resetting the parameter sends a DYRWT message to the issuer and requires a Yes or No response (unless set/reset by user0).

If <var>COMMITX</var> is specified, all APSY subsystems participate by default but any can be exempted.

===ECMSUBS===
This maximum value may now be reset dynamically by a system manager. If the value is raised, new tasks will be added as needed up to the value specified. If the value is lowered, idle subtasks will be detached before they are activated until the new maximum is established.

===ECMODS===
The new minimum value for ECMODS, the allowable number of ECF modules, is 1. Prior to V7.8 the minimum value was 0. This change is enabled in V7.7 with the application of zap 77z306.

===ECNAMES===
The new minimum value for ECNAMES, the allowable number of ECF module names, is 1. Prior to V7.8 the minimum value was 0. This change is enabled in V7.7 with the application of zap 77z306.

===ECPSIZE===
The new minimum value for ECPSIZE, the initial storage allocation for ECF parameters, is 1024. Prior to V7.8 the minimum value was 0. This change is enabled in V7.7 with the application of zap 77z306.

===ENQTIME===
Millisecond duration of automatic record locking retry wait.

Prior to this change, if record locking conflicts occur frequently in a busy online, any user with a non-zero value for <var>[[ENQRETRY parameter|ENQRETRY]]</var> will wait at least 3 seconds before the conflict is dealt with. This can degrade overall system performance.

The <var>[[ENQTIME parameter|ENQTIME]]</var> parameter specifies the number of milliseconds waited for each record locking retry wait. <var>ENQTIME</var> can be between 1 and 60000, corresponding to a minimum of 1 millisecond and a maximum of 1 minute. The default value of <var>ENQTIME</var> is 3000 (3 seconds).

For example, with <code>ENQTIME = 100</code> and <code>ENQRETRY = 7</code>, after a record locking conflict occurs the thread will retry 7 times with wait intervals of .1 seconds, and so within at most .7 seconds either the lock becomes available or the conflict triggers an On unit or cancels the request.

The <var>ENQTIME</var> parameter may also be reset with $ResetN.

This new parameter is enabled in V7.7 with the application of zap 77z299.

===EVALOPT===
The new <var>EVALOPT</var> parameter controls the cancellation of a request on truncation of string data. The default value is 0, and currently there is just one setting, 1, which means "cancel a request if truncation of string data occurs."

For example, with the default of 0 in place, the following code %x is string len 1
%y is string len 2
%y = 'ab'
%x = %y
printtext {~} = {%x} 

would cause silent truncation, and give the result
%x = a 

If <var>EVALOPT</var> is set to 1, then the above code produces the following message:
M204.0552: Variable too small for result 

and the request is cancelled.

===LFSCB===
<var>LFSCB</var>, the length of the full screen buffer, now has a new minimum value of 8 (the previous minimum was 0). This change is enabled in v7.7 with the application of zap 77z042, and within V7.6 with the application of zap 76z393.

===MAXPRE, MAXBOUT, MAXSUBT===
Introduced in zap 77z257.
The new <var>MAXPRE</var>, <var>MAXBOUT</var>, and <var>MAXSUBT</var> parameters can be used to cancel a runaway transaction and prevent it from filling the checkpoint data set.
<ul>
<li><var>MAXPRE</var>: Maximum number of pre-images per transaction. </li>
<li><var>MAXBOUT</var>: Maximum number of backout pages per transaction. </li>
<li><var>MAXSUBT</var>: Maximum number of subtransaction checkpoints that a transaction can span.</li></ul>

Each new parameter defaults to unlimited. 
If a parameter value is set, a transaction is cancelled if that value is exceeded, and the following message is displayed:
M204.0524: Maximum number (num) of parameter exceeded.
where num is the value set for parameter (<var>MAXPRE</var>, <var>MAXBOUT</var>, or <var>MAXSUBT</var>).

===MQMXTASK===
This maximum value may now be reset dynamically by a system manager. If the value is raised, new tasks will be added as needed up to the value specified. If the value is lowered, idle subtasks will be detached before they are activated until the new maximum is established.

===NLDAPBUF===
This new parameter allows the number of LDAP buffers allocated during startup to be set in CCAIN. The default value is 2, and the settable value can range from 0 to 65535.

===PUPDTH (new minimum value)===
If a user sets the <var>[[PUPDTH parameter|PUPDTH]]</var> parameter to 0, it will now automatically be increased to 1, its minimum value.

===SERV4G===
This parameter allows testing of server tables that span a 4-gigabyte boundary. For example, if <var>SERV4G</var> is <code>X'FFFFF000'</code>, each ATB server will begin at <code>XX_FFFFF000</code>. If <var>SERV4G</var> is <code>X'FFFF0000'</code>, each ATB server will begin at <code>XX_FFFF0000</code>. <code>XX</code> is determined by the storage available on the system. The parameter is set in CCAIN.

The contents of the ATB server are specified by using the <var>[[SERVGA parameter|SERVGA]]</var> parameter.

For example, if you want VTBL to span the 4G boundary, you can use these settings: <code>SERV4G=X'FFFFF000'</code>, <code>SERVGA=X'00040000'</code>, and <code>LVTBL=200 (6400 bytes, X'1900')</code>. This will force each server's VTBL to begin at <code>XX_FFFFF000</code> and end at <code>XX+1_00000900</code>.
===SIRTERM===
The <var>[[SIRTERM parameter|SIRTERM]]</var> (Sirius terminal options) parameter settings have changed.
The changes to <var>SIRTERM</var> allow a user to preclude a reset to a Model that is not supported by the terminal emulator in use.

The X'01' setting (MODEL 6 support) is no longer used.

The X'02' setting (Write Structured Field Query Support) now supports MODEL 6 terminals by default.

The new X'08' setting always issues a Write Structured Field Query for Terminal Model Resets for terminals connected to Model 204 through VTAM or TELNET, provided that X'02' has been set. This precludes Terminal Model RESETs to Models that are not supported by the terminal emulator in use.

===WEBDFLT===
At V7.7, the default access rule for non-SSL ports was changed from ALLOW * to DISALLOW *, meaning that unless any ALLOW rules were in place resulting in a login/password prompt, the port couldn't be accessed. The new <var>[[WEBDFLT_parameter|WEBDFLT]]</var> parameter may be set to 1 for reversion to the old default of ALLOW *. This new parameter is enabled in V7.7 with the application of zap 77z090.

<var>RESET WEBDFLT</var> requires system administrator privileges. It is recommended to reset the 1 bit of <var>WEBDFLT</var> to zero after issuing a series of <var>JANUS DEFINE</var> commands which need <var>WEBDFLT=1</var>, as in the CCAIN input stream.

==New and changed statistics==
===MPR, MBO, MCP, and RCV===
Introduced in zap 77z257.
These statistics provide high water mark transaction information. (Since-last values will not be available until V78 GA.)
They are useful in conjunction with the <var>[[#MAXPRE, MAXBOUT, MAXSUBT|MAXPRE, MAXBOUT, and MAXSUBT]]</VAR> parameters. 

User/system statistics:
<ul>
<li>MPR: High water mark of transaction pre-images. </li>
<li>MBO: High water mark of transaction backout pages. </li>
<li>MCP: High water mark of transaction chkpoint spans. </li>
</ul>
System statistics:
<ul>
<li>RCV: Number of blocks needed for subtransaction recovery </li>
</ul>
Notes: M204.0843 now displays the RCV statistic for subtransaction checkpoints.
The size of recovery checkpoint must be greater than the sum of the last RCV value plus the number of records in [[System_and_media_recovery#RESTART_recovery_considerations_for_sub-transaction_checkpoints|RESTART and RESTARTS]].


===DKWTS and DKWTMICS===
Introduced in zap 77z7289.
The new system statistics DKWTS (DisK WaiTs) and DKWTMICS (DisK WaiT MICroSeconds) collect data to provide rough disk I/O service time numbers.

DKWTS shows the number of disk I/O waits. DKWTMICS shows the total wait time for those waits in microseconds. Dividing the difference in DKWTMICS by the difference in DKWTS over an interval provides the average disk I/O wait time in microseconds.

Notes:
<ul>
<li>The wait time does include internal Model 204 scheduler delays, so on a CPU bound Model 204 system, the service times calculated from DKWTS and DKWTMICS are likely to be an overestimate of actual service times.</li>

<li>DKWTS and DKWTMICS are not available in SirMon; use <var>[[MONITOR_command|MONITOR]] SYSTEM STATISTICS</var> to view these statistics.</li></ul> 

==Compatibility issues==
===$ListNew cannot be used in Initial clause===
It is now a compilation error if <var>$ListNew</var> is attempted to be used in the <var>Initial</var> clause of a
[[Using_variables_and_values_in_computation#Declare_statements_for_.25variables|declaration statement]].
This change is propagated by zap maintenance to versions 7.5 (zap 75Z487), 7.6 (zap 76Z514), and 7.7 (zap 77z281) of Model 204.

<blockquote class="note">Note: Strictly speaking, this would not be considered a compilation error, because previously although <code>.. Initial($ListNew)</code> did not produce a compilation error, in almost all circumstances it would produce a snap if the initialized %variable were used with some other <var>$Listxxx</var> invocation.</blockquote>

===Restricting the use of the CUSTOM=38 setting===
The <var>[[CUSTOM parameter|CUSTOM=38]]</var> parameter setting, introduced at V7.5, inadvertently provided System Manager privileges to all users via the <var>RESET</var> command. This <var>CUSTOM</var> setting is now restricted to the <var>RESET</var> of the <var>LAUDIT</var> parameter.

===Disabling of Closure support===
Due to a non-trivial backward incompatibility issue related to Closure support, introduced in V7.7, this feature, which can best be described as exposed methods assigned to method variables, has been disabled in this release. This change was also made to V7.7 with application of zap 77z119.

===Password delimiter enforced===
When using <var>IFSTRTN</var> to log on to a Model 204 online from an IFAM2 application, both the logonid and password must be followed by a semicolon, which is the delimiter. For example:

CALL IFSTRTN(RC,'logonid;password;'...)

If a semicolon does not follow the password string, the following message will now be issued:

M204.2964: Password missing or too long 

Previously, a semicolon following the password was not required and the first blank served as a password delimiter. However, as of V7.7, embedded blanks are valid password characters and a semicolon is now required to delimit the password.

This change is enabled in V7.7 with the application of zap 77z231.

===PAGESZ parameter validated===
Previously it was possible to set the <var>PAGESZ</var> parameter to any value, although Model 204 internally supports one page size of 6184, and any deviation from this value would have led to problems during file creation. The value of this parameter is now controlled, such that setting it to any value other than 6184 will generate an M204.1149 message with the parameter being reset to 6184.

===ECPRIV and the IDCAMS facility===
At V7.7 a security loophole was closed, whereby all ECF modules were run under external-authorizer profile of the calling user. Previously any ECF tasks were run under the owning job's external-authorizer profile, and in order for certain sites to retain that ability, a new setting of <var>ECPRIV</var>, value 4, was introduced to retain the ability to run ECF tasks using the job's security profile.

The <var>ECPRIV</var> 4 setting potentially introduced a security loophole when calling the IDCAMS interface, based upon what the IDCAMS utility is able to do at a system level. Consequently as of this release, the <var>ECPRIV</var> 4 setting will be ignored when calling the IDCAMS facility via ECF, and such IDCAMS processes will always use the calling user's security profile. Any existing jobs that use ECF to call the IDCAMS utility with the <var>ECFPRIV</var> 4 bit set should be checked to ensure that the calling user's security profile still satisfies the job's requirements.

===TCPOPTS is view-only===
In previous versions the <var>TCPOPTS</var> parameter, which identifies the type of IP addressing in use (v4 or v6), was resettable, although it was always documented as a view-only parameter. The parameter is now handled as a view-only parameter, and any attempts to reset the parameter will result in the following message:

 M204.1123: Parameter TCPOPTS not reset

===ZHPF command can only be issued by a system manager===
In previous versions it was possible to issue the <var>ZHPF</var> command without being logged on. From this release onwards, a user must be logged on with system manager privileges in order to issue this command.

Additionally, the command output will now only display results for currently open files.

This change is enabled in v7.7 with the application of zap 77z264.

===Terminal MODEL reset failure===
If a reset of the terminal <var>MODEL</var> parameter fails due to an undersized output page buffer, then in addition to the existing messages that inform the user of this failure:
 M204.1875 UNABLE TO RESET MODEL TO %C
M204.1123: Parameter MODEL not reset

the following message will now be issued:

 M204.1008: LOUTPB must be increased to at least <number> 

where <number> is the minimum value of <var>LOUTPB</var> necessary to support the terminal model.

This change is enabled in V7.7 with the application of zap 77z309.

===BUF and FBMX stats removed===
Unnecessary scans of the buffer pool have been eliminated from most forms of the MONITOR command ( other than MONITOR DISKBUFF itself ), and this provides performance gain when running these commands. However, as a result of this the BUF stat on the MONITOR command output, and the FBMX stat reported in the system final stats block have been removed. These stats were of extremely limited value, and their elimination should not cause any problems for system management. This change is implemented in V7.8 via zap 78z077, and in V7.7 by zap 77z463.

==Notes for system manager and installer==
===CRAM SVC installation is deprecated===
The CRAM SVC installation has been deprecated as of version 7.5. Installation of CRAM-XDM is described as part of the [[Model 204 installation]].
===Authorization and maintenance zaps===
When you download Rocket M204 product object files, all relevant authorization keys and all current maintenance zaps are pre-applied to the object files as part of the download process.

==New products==
===Janus Two-Phase Commit===
[[Janus Two-Phase Commit]] support makes it possible to create global transactions where updates on multiple Model 204 Onlines or <var>Imagine</var> can be atomically committed or backed out.

===Commit Exit===
The [[Application_Subsystem_development#Commit_exits|Commit exit]] product allows for the invocation of specified APSY code when an an APSY TBO transaction executes its first explicit or implicit COMMIT. The feature is controlled by the new COMMITX parameter.

==New and changed messages==

See [[New and updated messages in Model 204 version 7.8|New and updated messages in Model 204 version 7.8]] for details.

[[Category: Release notes]]

Using system statistics

2019-05-13T08:11:12Z

Goff:

==Overview==

The tables on this page are provided for your use in identifying and tracking statistics that are reported by <var class="product">Model 204</var> in various situations. The offsets, given in decimal and hexadecimal, are to help you locate particular statistics within statistical output. The length is in bytes.

The statistics are collected in the [[Tracking_system_activity_(CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAJRNL|CCAJRNL]] data set, or if allocated, in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Introducing CCAAUDIT and CCAJLOG|CCAJLOG]]. The offsets in the tables below locate each statistic in the corresponding record. To accommodate sites that need to run <var class="product">Model 204</var> around the clock for many days at a time, space for most <var class="product">Model 204</var> statistics is a double word.

==Description of statistics==

The "Statistics with descriptions" table lists the statistics that are collected and that you can evaluate. It also describes the purpose of each statistic followed by the circumstances when you can collect the information and an offset in the journal record. 

To collect several statistics you must preset a parameter to a nonzero value. Statistics that require a parameter are also noted in the "Statistics with descriptions" table. The table in [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Setting parameters to collect certain statistics]] lists those statistics with the required parameter. 

Tables, identified by type, later in this topic, describe the layouts of the various journal records.
<table>
<caption style="margin-right:4em">Statistics with descriptions</caption>
<tr class="head">
<th>Statistic </th>
<th>Records...</th>
</tr>

<tr>
<td>APSYLD</td>
<td>Number of APSY loads</td>
</tr>

<tr>
<td>APSYLDD</td>
<td>Number of APSY loads from a dataspace</td>
</tr>

<tr>
<td>APSYLDT</td>
<td>Number of tiny APSY loads</td>
</tr>

<tr>
<td>AUDIT</td>
<td>Number of lines written to the journal and/or the audit trail</td>
</tr>

<tr>
<td>BACKOUTS</td>
<td>Number of BACKOUTs</td>
</tr>

<tr>
<td>BADD</td>
<td>Number of fields added to Table B</td>
</tr>

<tr>
<td>BCHG</td>
<td>Number of fields changed in Table B</td>
</tr>

<tr>
<td>BDEL</td>
<td>Number of fields deleted from Table B</td>
</tr>

<tr>
<td>BLKCFRE</td>
<td>Number of times user held a critical file resource (CFR) exclusively and forced another user to wait

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKI</td>
<td>Percentage of performance samples at which the user was in a server but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKO</td>
<td>Percentage of performance samples at which the user was swapped out to the server data set but blocked from running and waiting for an external event to occur (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BLKRLK</td>
<td>Number of times user was the first user identified as blocking another from obtaining a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>BXCHNG</td>
<td>Number of value entries changed in the ordered index. This occurs when a record number is added to or removed from an existing value entry.</td>
</tr>

<tr>
<td>BXDELE</td>
<td>Number of value entries deleted from the ordered index</td>
</tr>

<tr>
<td>BXFIND</td>
<td>Number of ordered index searches to locate field name=value pairs in the ordered index</td>
</tr>

<tr>
<td>BXFREE</td>
<td>Number of ordered index pages (nodes) emptied and released from the ordered index</td>
</tr>

<tr>
<td>BXINSE</td>
<td>Number of new value entries inserted into the ordered index</td>
</tr>

<tr>
<td>BXNEXT</td>
<td>Number of value entries touched in the ordered index during a range retrieval</td>
</tr>

<tr>
<td>BXRFND</td>
<td>Number of times the cursor was repositioned in the ordered index during a search</td>
</tr>

<tr>
<td>BXSPLI</td>
<td>Number of Table D pages (nodes) split in the ordered index</td>
</tr>

<tr>
<td>CCATDIFF</td>
<td>Difference between CCATEMP pages allocated and freed by a thread. This is an imperfect indicator of the number of CCATEMP pages a thread has allocated. CCATDIFF is imperfect because it is difficult to fully account for pages allocated or freed on behalf of the system or other users. However, if there is an acute CCATEMP page shortage, threads with high CCATDIFF values are likely culprits.

CCATDIFF is available in Model 204 7.7 and higher.</td>
</tr>

<tr>
<td>CCATDIFH</td>
<td>High water mark of CCATDIFF in a request. This can be useful if a request allocated a lot of CCATEMP pages, causing an acute shortage but then freed those pages.

CCATDIFH is available in Model 204 7.7 and later.</td>
</tr>

<tr>
<td>CDLWAIT</td>
<td>Number of constraint dependency lock waits</td>
</tr>

<tr>
<td>CNCT</td>
<td>Elapsed time in seconds</td>
</tr>

<tr>
<td>COMMITS</td>
<td>Number of <var>COMMIT</var>s</td>
</tr>

<tr>
<td>CPU</td>
<td>Total CPU time consumed in milliseconds. The system CPU statistics include both maintask and subtask CPU usage.</td>
</tr>

<tr>
<td>DEQ</td>
<td>Total number of units of work taken by the MAINTASK and each MP and zIIP subtask, regardless of the queue that the work was taken from. Reported at <var class="product">Model 204</var> termination or in <var>[[MONITOR TASKS command|MONITOR TASKS]]</var> output.

(type Subtask)
</td>
</tr>

<tr>
<td>DEV5</td>
<td>Output lines to procedures defined during the run</td>
</tr>

<tr>
<td>DEV6</td>
<td>Input lines from included procedures</td>
</tr>

<tr>
<td>DEV7</td>
<td>Output lines to SNA Communications Server (formerly VTAM) 3270s</td>
</tr>

<tr>
<td>DEV8</td>
<td>Input lines from SNA Communications Server 3270s</td>
</tr>

<tr>
<td>DEV9</td>
<td>Page headers or trailers defined in requests</td>
</tr>

<tr>
<td>DEV10</td>
<td>Output lines written to directed output (USE) data sets</td>
</tr>

<tr>
<td>DEV11</td>
<td>Output lines to remote User Language full screen</td>
</tr>

<tr>
<td>DEV12</td>
<td>Input lines from a remote User Language full screen</td>
</tr>

<tr>
<td>DEV13</td>
<td>Output lines to remote SQL</td>
</tr>

<tr>
<td>DEV14</td>
<td>Input lines from remote SQL</td>
</tr>

<tr>
<td>DEV17</td>
<td>Output lines to SQL CRAM IUCU</td>
</tr>

<tr>
<td>DEV18</td>
<td>Input lines from SQL CRAM</td>
</tr>

<tr>
<td>DEV19</td>
<td>Output lines to remote SQL LU62</td>
</tr>

<tr>
<td>DEV20</td>
<td>Input lines from remote SQL LU62</td>
</tr>

<tr>
<td>DEV23</td>
<td>Input lines to CRAM IFAM</td>
</tr>

<tr>
<td>DEV24</td>
<td>Input lines from CRAM IUCU thread</td>
</tr>

<tr>
<td>DEV27</td>
<td>Terminal error messages issued for inbound Distributed Application Facility conversations</td>
</tr>

<tr>
<td>DEV28</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV31</td>
<td><var>IFDISP</var> output lines to IFAM1 programs</td>
</tr>

<tr>
<td>DEV32</td>
<td>Input arguments supplied by certain IFAM1 calls</td>
</tr>

<tr>
<td>DEV37</td>
<td>Output lines to SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV38</td>
<td>Input lines from SNA Communications Server 2741s and Teletypes</td>
</tr>

<tr>
<td>DEV49</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV50</td>
<td>Lines sent to the printer when ROUTER=CICS</td>
</tr>

<tr>
<td>DEV53</td>
<td>Output lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV54</td>
<td>Input lines from an IFAM1 application</td>
</tr>

<tr>
<td>DEV55</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV56</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV57</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV58</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV59</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV60</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV61</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV62</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV63</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV64</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV65</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV66</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV67</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV68</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV69</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV70</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV71</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV72</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV73</td>
<td>Reserved</td>
</tr>

<tr>
<td>DEV74</td>
<td>Reserved</td>
</tr>

<tr>
<td>DIRRCD</td>
<td>Number of records searched in direct searches of Table B</td>
</tr>

<tr>
<td>DKAR</td>
<td>Number of buffers allocated without page read requests</td>
</tr>

<tr>
<td>DKPR</td>
<td>Number of requests for a page (may not require real I/O)</td>
</tr>

<tr>
<td>DKPRF</td>
<td>Number of fast logical page reads. Number of DKPRs that were satisfied by pending or deferred close buffers</td>
</tr>

<tr>
<td>DKRD</td>
<td>Number of physical page reads from Model 204 files</td>
</tr>

<tr>
<td>DKRDL</td>
<td>Number of physical page reads into the below the bar buffer pool</td>
</tr>

<tr>
<td>DKRR</td>
<td> Number of real disk reads for recently requested pages
</td>
</tr>

<tr>
<td>DKSAWB</td>
<td> Anticipatory writes from the bottom of the LRU queue. The page in the buffer is then deleted and no longer available without a re-read. Usually a small statistic and typically only incremented by a few rare events.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWBL</td>
<td> Same as DKSAWB but only incremented for anticipatory writes from below the bar

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWW</td>
<td> Anticipatory writes from the anticipatory write windows set by LDKBMWND and/or LDKBMWNG

Offset: the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSAWWL</td>
<td>Same as DKSAWW but only incremented for anticipatory writes from below the bar</td>
</tr>

<tr>
<td>DKSDIR</td>
<td> High-water mark of modified (dirty) buffers found within the DKBM statistics window which is created by the <var>LDKBMW</var> parameter. This parameter is not recommended due to the extremely heavy performance penalty imposed by a non-zero value.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSDIRT</td>
<td> The total of all modified buffers found within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSFBS</td>
<td> Times a buffer was needed, and a scan was necessary, because the oldest free buffer was not immediately available

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIP</td>
<td> The highest number of buffers skipped during any search for a free buffer. A buffer is skipped because it is not immediately available.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSKIPT</td>
<td> The total of all buffers skipped when looking for a free buffer

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRR</td>
<td> Number of times a page that was expected to be in the buffer pool could not be located, which necessitates a physical I/O to disk

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSRRFND</td>
<td>Number of times that a page that was expected to be in the buffer pool was located there, which eliminates the need for a physical I/O</td>
</tr>

<tr>
<td>DKSTBLA</td>
<td> Table A reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLB</td>
<td> Table B reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLC</td>
<td> Table C reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLD</td>
<td> Table D reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DSKTBLE</td>
<td> Table E reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTBLF</td>
<td> FCT reads causing real I/O

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSTKQC</td>
<td> Times the current Table B page had to be closed to allow a fourth buffer to be opened

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].
</td>
</tr>

<tr>
<td>DKSWRP</td>
<td> The highwater mark of buffers with writes outstanding within the DKBM statistics window, created by the parameter LDKBMW. Rocket Software advises against setting this parameter to a non-zero value due to the extreme performance penalty imposed.

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKSWRPT</td>
<td> The total number of buffers with outstanding writes within the DKBM statistics window

Offset: see the [[#Additional disk buffer monitor statistics|Disk buffer monitor statistics table]].

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>DKUPTIME</td>
<td>Milliseconds of DKUPDT time</td>
</tr>

<tr>
<td>DKWR</td>
<td>Number of physical page writes to <var class="product">Model 204</var> files</td>
</tr>

<tr>
<td>DKWRL</td>
<td>Number of physical page writes from the below the bar pool</td>
</tr>

<tr>
<td>DKWTMICS</td>
<td>Total wait time in microseconds for Disk I/O waits counted by DKWTS.
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DKWTS</td>
<td>Number Disk I/O waits
As of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>DUMP</td>
<td>Writes to <var class="product">Model 204</var> file backups (DUMP command output)</td>
</tr>

<tr>
<td>DUPDTS</td>
<td>Records written to a deferred update data set for the file</td>
</tr>

<tr>
<td>ECCALL</td>
<td>Number of External Call Facility calls</td>
</tr>

<tr>
<td>ECCNCT</td>
<td>External Call Facility - Elapsed time for external program</td>
</tr>

<tr>
<td>ECCTOUT</td>
<td>Number of External Call Facility calls that timed out (program or subtask unavailable)</td>
</tr>

<tr>
<td>ECCWAITM</td>
<td>ECF – Number of calls that waited for module to become available</td>
</tr>

<tr>
<td>ECCWAITS</td>
<td>Number of External Call Facility calls that waited for a subtask to become available</td>
</tr>

<tr>
<td>ECDELETE</td>
<td>Number of EXTERNAL DELETE calls to External Call Facility</td>
</tr>

<tr>
<td>ECLOAD</td>
<td>Number of EXTERNAL LOAD calls to External Call Facility</td>
</tr>

<tr>
<td>ECMODMAX</td>
<td>ECF – Highwater mark of modules loaded</td>
</tr>

<tr>
<td>ECNAMMAX</td>
<td>External Call Facility – High-water mark of call names defined</td>
</tr>

<tr>
<td>ECTSKMAX</td>
<td>External Call Facility – High-water mark of subtasks active</td>
</tr>

<tr>
<td>ECTWAITM</td>
<td>External Call Facility – Elapsed time spent waiting for a module to become available</td>
</tr>

<tr>
<td>ECTWAITS</td>
<td>External Call Facility – Elapsed time spent waiting for a subtask to become available</td>
</tr>

<tr>
<td>ERRPDL</td>
<td>Highwater mark of the system pushdown list</td>
</tr>

<tr>
<td>FBWT</td>
<td>Number of waits for a disk buffer</td>
</tr>

<tr>
<td>FINDS</td>
<td>Number of FIND statements evaluated</td>
</tr>

<tr>
<td>FSCB</td>
<td>High-water mark of bytes used in the FSCB</td>
</tr>

<tr>
<td>FSCBSW</td>
<td>Number of full-screen buffer swaps</td>
</tr>

<tr>
<td>FTBL</td>
<td>Highwater mark of FTBL appearing in CMPL and EVAL lines for requests containing a field name reference in group context. If one or more groups are opened but no field name references are made, the portion of FTBL used by the open groups is not reported.</td>
</tr>

<tr>
<td>GTBL</td>
<td>Highwater mark of GTBL</td>
</tr>

<tr>
<td>GTBLRS</td>
<td>Number of GTBL rearrangements required to add a global object</td>
</tr>

<tr>
<td>GTBLRU</td>
<td>Number of GTBL rearrangements required to add a global string variable</td>
</tr>

<tr>
<td>HEAP</td>
<td>Dynamic memory highwater mark</td>
</tr>

<tr>
<td>IN</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>INCMFS</td>
<td>Input lines from CMS full screen</td>
</tr>

<tr>
<td>INCMIO</td>
<td>Input lines from CMS non-full screen</td>
</tr>

<tr>
<td>INCRAM</td>
<td>Input lines from Remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>INVMFS</td>
<td>Input lines from IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>INVMIF</td>
<td>Input arguments supplied by certain IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>INVMIO</td>
<td>Input lines from IUCV or VMCF non-full screen thread</td>
</tr>

<tr>
<td>INXX</td>
<td>Input lines from QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>ITBL</td>
<td>Highwater mark of ITBL</td>
</tr>

<tr>
<td>IXADD</td>
<td>Number of index entries added to Tables C and D, including attempts to add duplicates</td>
</tr>

<tr>
<td>IXDEL</td>
<td>Number of entries deleted from Tables C and D</td>
</tr>

<tr>
<td>LKPOST</td>
<td>Times an MP subtask posted another task to indicate that an MP lock had become available</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>Times MP subtasks invoked z/OS WAIT macros to wait for an available MP lock</td>
</tr>

<tr>
<td>LONGUPDTIME(MS)</td>
<td> Total milliseconds of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LONGUPDTS</td>
<td> Number of 'too long' update units

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>LWTIM</td>
<td>Elapsed time (ms), spent waiting for a multiprocessing lock. Reported for each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals).</td>
</tr>

<tr>
<td>MAXIOX</td>
<td>Number of times <var class="product">Model 204</var> waited for a free database buffer</td>
</tr>

<tr>
<td>MBO</td>
<td>Highwater mark of transaction backout pages

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MCP
</td>
<td>Highwater mark of transaction checkpoint spans

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MOVE</td>
<td>Number of times the scheduler switched from one user to another</td>
</tr>

<tr>
<td>MPLKPREM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting due to operating system preemption.

This is the elapsed time between when an MP lock becomes available (lock post) making a task ready to run, and when the task actually gets the CPU. That preemption delay is caused by the operating system dispatching other tasks ahead of this task.

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPLKWTIM</td>
<td> Total elapsed time in milliseconds, across the maintask and all subtasks, the Online spent waiting for MP locks

Only collected in MP/204 systems.
</td>
</tr>

<tr>
<td>MPR</td>
<td>Highwater mark of transaction pre-images

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>MQAPICNT</td>
<td>MQ/204 – Count of MQ/Series API calls</td>
</tr>

<tr>
<td>MQAPITIM </td>
<td>MQ/204 – Elapsed time of MQSeries API calls</td>
</tr>

<tr>
<td>MQBYTEIN</td>
<td>MQ/204 – Total bytes retrieved (MQGET)</td>
</tr>

<tr>
<td>MQBYTEOU</td>
<td>MQ/204 – Total bytes sent (MQPUT/MQPUT1)</td>
</tr>

<tr>
<td>MQGETS</td>
<td>MQ/204 – Number of MQGETs performed</td>
</tr>

<tr>
<td>MQGWTCNT</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTSUC</td>
<td>MQ/204 – Number of MQGETs with nonzero, non-unlimited wait that succeeded</td>
</tr>

<tr>
<td>MQGWTTIM</td>
<td>MQ/204 – Elapsed time for MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQGWTTSP</td>
<td>MQ/204 – Total wait time specified on MQGETs with nonzero, non-unlimited wait</td>
</tr>

<tr>
<td>MQHWQU</td>
<td>MQ/204 – High-water mark of queues concurrently in use</td>
</tr>

<tr>
<td>MQHWTASK</td>
<td>MQ/204 – High-water mark of MQ/204 subtasks in use</td>
</tr>

<tr>
<td>MQNUMQM</td>
<td>MQ/204 – Number of distinct queue managers connected</td>
</tr>

<tr>
<td>MQNUMQU</td>
<td>MQ/204 – Number of distinct queues accessed</td>
</tr>

<tr>
<td>MQPUTS</td>
<td>MQ/204 – Number of MQPUTs performed</td>
</tr>

<tr>
<td>MQWTM</td>
<td>Mean queue wait time, the average time a subtask spent waiting for work (waiting for PCBs to come into the offload queue)</td>
</tr>

<tr>
<td>MTDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from the MAINTASK queue and processed it</td>
</tr>

<tr>
<td>MTSDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from an MP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>MTZDEQ</td>
<td>The number of times that the MAINTASK took a unit of work from a zIIP subtask queue and processed it because the MAINTASK was idle</td>
</tr>

<tr>
<td>NTBL</td>
<td>Highwater mark of NTBL</td>
</tr>

<tr>
<td>OFFIN</td>
<td>Count of records read in by the OFFLOAD subtask</td>
</tr>

<tr>
<td>OFFOU</td>
<td>Count of records written to the OFFLOAD stream</td>
</tr>

<tr>
<td>OUT</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>OUTCMFS</td>
<td>Output lines to CMS full-screen thread</td>
</tr>

<tr>
<td>OUTCMIO</td>
<td>Output lines to CMS line-by-line thread</td>
</tr>

<tr>
<td>OUTCRAM</td>
<td>Output lines from remote User Language threads (IODEV 29)</td>
</tr>

<tr>
<td>OUTPB</td>
<td>Highwater mark of OUTPB</td>
</tr>

<tr>
<td>OUTVMFS</td>
<td>Output lines to IUCV or VMCF full-screen thread</td>
</tr>

<tr>
<td>OUTVMIF</td>
<td>Output lines to IFAM2 or IFAM4 calls from CMS programs</td>
</tr>

<tr>
<td>OUTVMIO</td>
<td>Output lines to IUCV or VMCF line-by-line threads</td>
</tr>

<tr>
<td>OUTXX</td>
<td>Output lines to QSAM users (IODEV 3)</td>
</tr>

<tr>
<td>PBRSFLT</td>
<td>Number of private buffer reservation faults</td>
</tr>

<tr>
<td>PCPU</td>
<td>Percentage of time <var class="product">Model 204</var> was given the CPU when it wanted CPU time. In an MP environment, system PCPU is the sum of CPU time in all tasks divided by the sum of elapsed time in all tasks.</td>
</tr>

<tr>
<td>PDL</td>
<td>Highwater mark of the pushdown list</td>
</tr>

<tr>
<td>PETIM</td>
<td>Elapsed time (ms), spent waiting due to OS preemption. Reported for the MAINTASK and each MP and zIIP subtask at <var class="product">Model 204</var> termination or in MONITOR TASKS output (only on Model 5 terminals)</td>
</tr>

<tr>
<td>PNDGTIME</td>
<td>Milliseconds of unnecessary broken time</td>
</tr>

<tr>
<td>PR</td>
<td>Real time consumed, in milliseconds. PCPU = CPU / PR.</td>
</tr>

<tr>
<td>QTBL</td>
<td>Highwater mark of QTBL</td>
</tr>

<tr>
<td>RCV</td>
<td>Number of blocks needed for subtransaction recovery

As of V7.7, with zap 77z257 applied.
</td>
</tr>

<tr>
<td>RECADD</td>
<td>Number of records started in Table B, not including extension records</td>
</tr>

<tr>
<td>RECDEL</td>
<td>Number of records deleted from Table B, not including extension records or records deleted by DELETE RECORDS or IFDSET</td>
</tr>

<tr>
<td>RECDS</td>
<td>Number of records processed by FOR statements, SORT statements, IFGET calls, or IFPOINT calls, or similar SQL record processing</td>
</tr>

<tr>
<td>REDY</td>
<td> Percentage of performance samples at which the user was ready to run (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>REQ</td>
<td>Number of SOUL requests evaluated</td>
</tr>

<tr>
<td>REST</td>
<td>Number of reads from a <var class="product">Model 204</var> file backup (<var>RESTORE</var> command)</td>
</tr>

<tr>
<td>RETRYA</td>
<td>Page retries in Table A</td>
</tr>

<tr>
<td>RETRYC</td>
<td>Page retries in Table C</td>
</tr>

<tr>
<td>RQTM</td>
<td>Elapsed time for the activity being reported, exclusive of terminal I/O time</td>
</tr>

<tr>
<td>RSXCOMP</td>
<td>Number of compactions of the record locking table. If greater than 0, increase <var>LRETBL</var>.</td>
</tr>

<tr>
<td>RUNG</td>
<td> Percentage of performance samples at which the user was running (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SCHDCPU</td>
<td>In MP configuration, total scheduler CPU for the user or request</td>
</tr>

<tr>
<td>SCREENS</td>
<td>Total number of full-screen reads (<var>READ SCREEN</var> statements) evaluated by a SOUL request.</td>
</tr>

<tr>
<td>SGMTI</td>
<td>Number of input lines from included procedures</td>
</tr>

<tr>
<td>SGMTO</td>
<td>Number of output lines to procedures defined by the user</td>
</tr>

<tr>
<td>SLIC</td>
<td>Number of times that the user was time-sliced by the <var class="product">Model 204</var> scheduler</td>
</tr>

<tr>
<td>SMPLS</td>
<td>Number of performance sample points at which the user was active or total number of performance samples taken at the system level (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>SORTS</td>
<td>Number of SOUL <var>SORT</var> statements or SQL sorts evaluated</td>
</tr>

<tr>
<td>SQLI</td>
<td>Remote SQL input highwater mark</td>
</tr>

<tr>
<td>SQLO</td>
<td>Remote SQL output highwater mark</td>
</tr>

<tr>
<td>SQRD</td>
<td>Number of terminal input lines</td>
</tr>

<tr>
<td>SQWR</td>
<td>Number of terminal output lines</td>
</tr>

<tr>
<td>STBL</td>
<td>Highwater mark of STBL</td>
</tr>

<tr>
<td>STCPU</td>
<td>Total amount of time, in milliseconds, that the user has run in an MP offload subtask</td>
</tr>

<tr>
<td>STDEQ</td>
<td>Number of times that an MP subtask took a unit of work from an MP subtask queue and processed it</td>
</tr>

<tr>
<td>STIMERS</td>
<td>Total number of STIMER or STIMERM calls</td>
</tr>

<tr>
<td>STPOST</td>
<td>Times MP subtasks performed real operating system POSTs to send work to the maintask</td>
</tr>

<tr>
<td>STRECDS</td>
<td>Number of records processed by SORT statements or SQL sorts</td>
</tr>

<tr>
<td>STWAIT</td>
<td>Number of times MP subtasks invoked z/OS WAIT macros to wait for work from the maintask</td>
</tr>

<tr>
<td>STZDEQ</td>
<td>Number of times that an MP subtask took a unit of work from a zIIP subtask queue and processed it because the MP subtask was idle</td>
</tr>

<tr>
<td>SVAC</td>
<td>Active servers (an average, included on a performance line)</td>
</tr>

<tr>
<td>SVMX</td>
<td>Highwater mark for servers (0 if no server swapping)</td>
</tr>

<tr>
<td>SVPAGES</td>
<td><code>SVPAGES * 4096</code> is the number of bytes transferred as a result of server reads and writes</td>
</tr>

<tr>
<td>SVRD</td>
<td>Number of server reads</td>
</tr>

<tr>
<td>SVWR</td>
<td>Number of server writes</td>
</tr>

<tr>
<td>SWPG</td>
<td>Percentage of performance samples at which the user was swapping in or out (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>SWT</td>
<td>Times <var class="product">Model 204</var> issued a real WAIT while not in user-switching mode</td>
</tr>

<tr>
<td>TEMX</td>
<td>Highwater mark of CCATEMP pages used in the expansion area</td>
</tr>

<tr>
<td>TFMX</td>
<td>Highwater mark of CCATEMP pages used</td>
</tr>

<tr>
<td>TSMX</td>
<td>Highwater mark of CCATEMP pages used in the small model page pool</td>
</tr>

<tr>
<td>TTBL</td>
<td>Highwater mark of TTBL</td>
</tr>

<tr>
<td>UBUFHWS</td>
<td>Highwater mark, in bytes, of user's Universal Buffer</td>
</tr>

<tr>
<td>UDD</td>
<td>Number of lines written to a directed output (<var>USE</var>) data set</td>
</tr>

<tr>
<td>UPDTTIME(MS)</td>
<td>Number of milliseconds that a file was being updated

UPT(MS) appears as the column header for this statistic on a report
</td>
</tr>

<tr>
<td>UPDTTIME</td>
<td>Number of milliseconds that the user was actively updating at least one file</td>
</tr>

<tr>
<td>USMX</td>
<td>Highwater mark for simultaneous active users (reported only if the performance subtask is active)</td>
</tr>

<tr>
<td>USRS</td>
<td>Average number of active users (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>VTBL</td>
<td>Number of VTBL entries at the end of compilation (CMPL) processing or the end of evaluation (EVAL) processing</td>
</tr>

<tr>
<td>WAIT</td>
<td>Number of real operating system waits</td>
</tr>

<tr>
<td>WTCFR</td>
<td>Number of times that the user waited to obtain a critical file resource, either share or exclusive

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTRLK</td>
<td>Number of times that the user waited to obtain a record lock

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>WTSV</td>
<td>Percentage of performance samples at which the user was waiting for a server (reported only if the performance subtask is active)

Parameter setting required: see [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Setting parameters to collect certain statistics|Parameters to set to collect certain statistics]].
</td>
</tr>

<tr>
<td>XTBL</td>
<td>Highwater mark of XTBL</td>
</tr>

<tr>
<td>ZTCPU</td>
<td>The CPU (ms) consumed on a zIIP processor by the MAINTASK, an MP subtask or a zIIP subtask. Reported for each task at <var class="product">Model 204</var> termination and in <var>MONITOR TASKS</var> output (for Model 5 terminals only)</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>The number of times that a zIIP subtask took a unit of work from a zIIP subtask queue and processed it</td>
</tr>
</table>

==Header and trailer entries (Type 0)==

Each journal block begins with a header record and ends with a trailer record.

===Header entries (Type 0)===

Header entries have the format shown in the following table: 
<table>
<caption style="margin-right:6em">Header entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entire journal record, including header and trailer</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Flags used by recovery</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH </td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">4</td>
<td>Binary</td>
<td> Sequence number </td>
</tr>

<tr>
<td>16(10)</td>
<td align="right">10</td>
<td>Binary</td>
<td> System Store Clock Extended (STCKE) value to provide picosecond accuracy on the journal date/time stamp

Bytes 1-9 || byte 16 
</td>
</tr>

<tr>
<td>26(1A)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of header, type 00</td>
</tr>

<tr>
<td>28(1C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Version in hex</td>
</tr>

<tr>
<td>30(1E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Version in EBCDIC</td>
</tr>

<tr>
<td>38(26)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Job name</td>
</tr>

<tr>
<td>46(2E)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>JES Job ID</td>
</tr>

<tr>
<td>54(36)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>SMF System ID</td>
</tr>
</table>
<ul>
<li>If the flag byte at offset 3 of type 00 has the X'02' bit on, then it is a header record from <var class="product">Model 204</var> version 7.4.0 or later with its length at offset X'1A'.</li>

<li>If that flag byte has the X'01' bit on, then the header is from version 7.1.0 and is 26 bytes in length. </li>

<li>If neither of those bits is on, then the header is a from a pre-7.1.0 version and is 16 bytes in length.</li>
</ul>

===Recovery flags===

Flags used by recovery can have the value of X'00' or a sum of any of the following: 
<table>
<tr class="head">
<th>Value</th>
<th>Block contains these records...</th>
</tr>

<tr>
<td>X'80'</td>
<td>Type 1</td>
</tr>

<tr>
<td>X'40'</td>
<td>Type 2</td>
</tr>

<tr>
<td>X'20'</td>
<td>Type 3</td>
</tr>

<tr>
<td>X'10'</td>
<td>Type 4</td>
</tr>

<tr>
<td>X'08'</td>
<td>Type 5</td>
</tr>

<tr>
<td>X'04'</td>
<td>Type 6</td>
</tr>
</table>

===Sequence numbers===

The sequence number represents the number of each journal record, starting at 0 and increasing by 1. A merged journal (output of the MERGEJ utility) sequence number consists of a 2-byte hexadecimal number at offset 12(0C), which indicates the input file this journal record came from, and a 2-byte hexadecimal field at offset 14(0E), which indicates the sequence within the INPUT journal.

===Trailer entries (Type 0)===

Trailer entries have the format shown in the following table: 
<table>
<caption>Trailer entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'00'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data </td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Recovery entries (Types 1-6)==

Entry types X'01' through X'06' contain information used for recovery. They follow the same general format as all other journal entries. There is no type X'07' journal entry. 

The format of the recovery entries is meaningful only in the context of the <var class="product">Model 204</var> ROLL FORWARD algorithm. However, entry types might be of interest in some statistics gathering applications, as follows: 
<table>
<tr class="head">
<th>Type </th>
<th>Contains recovery information from...</th>
</tr>

<tr>
<td>1 </td>
<td>Discontinuity</td>
</tr>

<tr>
<td>2 </td>
<td> Begin update unit.

More than one type 2 entry can be written for each update unit. The update unit number appears as a 4-byte binary number at offset 16(10).
</td>
</tr>

<tr>
<td>3 </td>
<td> End update unit.

The update unit number appears in the same format and location as the type 2 entry.
</td>
</tr>

<tr>
<td>4</td>
<td>File state information: opened, closed, dumped, file parameter list (FPL) page preimage logged or open at the time of a checkpoint</td>
</tr>

<tr>
<td>5 </td>
<td>Checkpoint</td>
</tr>

<tr>
<td>6 </td>
<td>File update </td>
</tr>
</table>

==System statistics entries (Type 8)==

Cumulative statistics, listed by offset in the [[#System performance statistics|Layout of system subtype X'02' entries]] table, are kept for the entire system. Final, partial, and performance system statistics are written to the journal during <var class="product">Model 204</var> termination in a line that begins with:
ST $$$ SYSTEM='version#'


For additional information about:
<ul>
<li>Using system statistics for performance monitoring, see [[Performance monitoring and tuning]]. </li>

<li>Disk buffer monitor statistics and parameters, see [[Performance monitoring and tuning#Disk buffer monitor statistics and parameters|Disk buffer monitor statistics and parameters]]. </li>
</ul>

===Final statistics===

The system final statistics line, similar to the following, is produced as part of system termination: 
ST $$$ SYSTEM='5A 'AUDIT=43 OUT=38 IN=14 WAIT=19 ...


===Partial statistics===

Statistics in a system partial statistics line, similar to the following, accumulate from the beginning of the run, if the User 0 <var>[[ACCTIM parameter|ACCTIM]]</var> parameter is nonzero: 
ST $$$ SYSTEM='6.1.0'PARTIAL=3 AUDIT=19 OUT=10 IN=5 WAIT=3 ...


===Performance statistics===

System performance statistic lines, similar to the following, are written if the User 0 <var>[[RPTCNT parameter|RPTCNT]]</var> and <var>[[SMPLTIM parameter|SMPLTIM]]</var> parameters are nonzero: 
ST $$$ SYSTEM='6.1.0' PERFORMANCE=n


The numbers determined at the performance sample points are averaged for the entire run. 

===Entry formats===

System statistics entries have the format shown in the following table: 
<table>
<caption>System statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'08'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:

X'00' = final statistics

X'01' = partial statistics

X'02' = performance statistics

X'04' = additional disk buffer monitor

X'08' = subtask statistics
</td>
</tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Subtask number if subtype = X'08'; otherwise unused</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Unused</td>
</tr>

<tr>
<td>16(10) to end of journal</td>
<td align="right"> — </td>
<td align="right"> — </td>
<td>

Contents depend on subtypes, shown in tables in the following sections:
<ul>
<li>[[#System final and partial statistics|System final and partial statistics]]</li>

<li>[[#System performance statistics|System performance statistics]]</li>

<li>[[#Additional disk buffer monitor statistics|Additional disk buffer monitor statistics]]</li>

<li>[[#User since-last statistics|User since-last statistics]]</li>
</ul>
</td> </tr>
</table>

==System final and partial statistics==

For subtypes X'00' (final statistics) and X'01' (partial statistics), the layout of the remainder of the entry is shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
The following statistics are data type Binary. However, the length varies — either 4 or 8, to accommodate 64-bit system architecture. 
<table>
<caption>System final and partial statistics</caption>
<tr class="head">
<th>Offset dec(hex) </th>
<th>Length </th>
<th>Description</th>
</tr>

<tr>
<td>16(10) </td>
<td>8 </td>
<td>AUDIT</td>
</tr>

<tr>
<td>24(18) </td>
<td>8 </td>
<td>OUT</td>
</tr>

<tr>
<td>32(20) </td>
<td>8 </td>
<td>IN</td>
</tr>

<tr>
<td>40(28) </td>
<td>8 </td>
<td>OUTXX</td>
</tr>

<tr>
<td>48(30) </td>
<td>8 </td>
<td>INXX</td>
</tr>

<tr>
<td>56(38) </td>
<td>8 </td>
<td>DEV5</td>
</tr>

<tr>
<td>64(40) </td>
<td>8 </td>
<td>DEV6</td>
</tr>

<tr>
<td>72(48) </td>
<td>8 </td>
<td>DEV7</td>
</tr>

<tr>
<td>80(50) </td>
<td>8 </td>
<td>DEV8</td>
</tr>

<tr>
<td>88(58) </td>
<td>8 </td>
<td>DEV9</td>
</tr>

<tr>
<td>96(60) </td>
<td>8 </td>
<td>DEV10</td>
</tr>

<tr>
<td>104(68) </td>
<td>8 </td>
<td>DEV11</td>
</tr>

<tr>
<td>112(70) </td>
<td>8 </td>
<td>DEV12</td>
</tr>

<tr>
<td>120(78) </td>
<td>8 </td>
<td>DEV13</td>
</tr>

<tr>
<td>128(80) </td>
<td>8 </td>
<td>DEV14</td>
</tr>

<tr>
<td>136(88) </td>
<td>8 </td>
<td>OUTTTY</td>
</tr>

<tr>
<td>144(90) </td>
<td>8 </td>
<td>INTTY</td>
</tr>

<tr>
<td>152(98) </td>
<td>8 </td>
<td>DEV17</td>
</tr>

<tr>
<td>160(A0) </td>
<td>8 </td>
<td>DEV18</td>
</tr>

<tr>
<td>168(A8) </td>
<td>8 </td>
<td>DEV19</td>
</tr>

<tr>
<td>176(B0) </td>
<td>8 </td>
<td>DEV20</td>
</tr>

<tr>
<td>184(B8) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>192(C0) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>200(C8) </td>
<td>8 </td>
<td>DEV23</td>
</tr>

<tr>
<td>208(D0) </td>
<td>8 </td>
<td>DEV24</td>
</tr>

<tr>
<td>216(D8) </td>
<td>8 </td>
<td>DEV25</td>
</tr>

<tr>
<td>224(E0) </td>
<td>8 </td>
<td>DEV26</td>
</tr>

<tr>
<td>232(E8) </td>
<td>8 </td>
<td>DEV27</td>
</tr>

<tr>
<td>240(F0) </td>
<td>8 </td>
<td>DEV28</td>
</tr>

<tr>
<td>248(F8) </td>
<td>8 </td>
<td>OUTCRAM</td>
</tr>

<tr>
<td>256(100) </td>
<td>8 </td>
<td>INCRAM</td>
</tr>

<tr>
<td>264(108) </td>
<td>8 </td>
<td>DEV31</td>
</tr>

<tr>
<td>272(110) </td>
<td>8 </td>
<td>DEV32</td>
</tr>

<tr>
<td>280(118) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>288(120) </td>
<td>8 </td>
<td>Spare</td>
</tr>

<tr>
<td>296(128) </td>
<td>8 </td>
<td>DEV35</td>
</tr>

<tr>
<td>304(130) </td>
<td>8 </td>
<td>DEV36</td>
</tr>

<tr>
<td>312(138) </td>
<td>8 </td>
<td>DEV37</td>
</tr>

<tr>
<td>320(140) </td>
<td>8 </td>
<td>DEV38</td>
</tr>

<tr>
<td>328(148) </td>
<td>8 </td>
<td>OUTVMIO</td>
</tr>

<tr>
<td>336(150) </td>
<td>8 </td>
<td>INVMIO</td>
</tr>

<tr>
<td>344(158) </td>
<td>8 </td>
<td>OUTVMFS</td>
</tr>

<tr>
<td>352(160) </td>
<td>8 </td>
<td>INVMFS</td>
</tr>

<tr>
<td>360(168) </td>
<td>8 </td>
<td>OUTVMIF</td>
</tr>

<tr>
<td>368(170) </td>
<td>8 </td>
<td>INVMIF</td>
</tr>

<tr>
<td>376(178) </td>
<td>8 </td>
<td>OUTCMIO</td>
</tr>

<tr>
<td>384(180) </td>
<td>8 </td>
<td>INCMIO</td>
</tr>

<tr>
<td>392(188) </td>
<td>8 </td>
<td>OUTCMFS</td>
</tr>

<tr>
<td>400(190) </td>
<td>8 </td>
<td>INCMFS</td>
</tr>

<tr>
<td>408(198) </td>
<td>8 </td>
<td>DEV49</td>
</tr>

<tr>
<td>416(1A0) </td>
<td>8 </td>
<td>DEV50</td>
</tr>

<tr>
<td>424(1A8) </td>
<td>8 </td>
<td>OFFIN</td>
</tr>

<tr>
<td>432(1B0) </td>
<td>8 </td>
<td>OFFOU</td>
</tr>

<tr>
<td>440(1B8) </td>
<td>8 </td>
<td>DEV53</td>
</tr>

<tr>
<td>448(1C0) </td>
<td>8 </td>
<td>DEV54</td>
</tr>

<tr>
<td>456(1C8) </td>
<td>8 </td>
<td>DEV55</td>
</tr>

<tr>
<td>464(1D0) </td>
<td>8 </td>
<td>DEV56</td>
</tr>

<tr>
<td>472(1D8) </td>
<td>8 </td>
<td>DEV57</td>
</tr>

<tr>
<td>480(1E0) </td>
<td>8 </td>
<td>DEV58</td>
</tr>

<tr>
<td>488(1E8) </td>
<td>8 </td>
<td>DEV59</td>
</tr>

<tr>
<td>496(1F0) </td>
<td>8 </td>
<td>DEV60</td>
</tr>

<tr>
<td>504(1F8) </td>
<td>8 </td>
<td>DEV61</td>
</tr>

<tr>
<td>512(200) </td>
<td>8 </td>
<td>DEV62</td>
</tr>

<tr>
<td>520(208) </td>
<td>8 </td>
<td>DEV63</td>
</tr>

<tr>
<td>528(210) </td>
<td>8 </td>
<td>DEV64</td>
</tr>

<tr>
<td>536(218) </td>
<td>8 </td>
<td>DEV65</td>
</tr>

<tr>
<td>544(220) </td>
<td>8 </td>
<td>DEV66</td>
</tr>

<tr>
<td>552(228) </td>
<td>8 </td>
<td>DEV67</td>
</tr>

<tr>
<td>560(230) </td>
<td>8 </td>
<td>DEV68</td>
</tr>

<tr>
<td>568(238) </td>
<td>8 </td>
<td>DEV69</td>
</tr>

<tr>
<td>576(240) </td>
<td>8 </td>
<td>DEV70</td>
</tr>

<tr>
<td>584(248) </td>
<td>8 </td>
<td>DEV71</td>
</tr>

<tr>
<td>592(250) </td>
<td>8 </td>
<td>DEV72</td>
</tr>

<tr>
<td>600(258) </td>
<td>8 </td>
<td>DEV73</td>
</tr>

<tr>
<td>608(260) </td>
<td>8 </td>
<td>DEV74</td>
</tr>

<tr>
<td>616(268) </td>
<td>4 </td>
<td>WAIT</td>
</tr>

<tr>
<td>620(26C) </td>
<td>4 </td>
<td>MPLKWTIM</td>
</tr>

<tr>
<td>624(270) </td>
<td>8 </td>
<td>DKRD</td>
</tr>

<tr>
<td>632(278) </td>
<td>8 </td>
<td>DKWR</td>
</tr>

<tr>
<td>640(280) </td>
<td>4 </td>
<td>SVRD</td>
</tr>

<tr>
<td>644(284) </td>
<td>4 </td>
<td>SVWR</td>
</tr>

<tr>
<td>648(288) </td>
<td>8 </td>
<td>CPU</td>
</tr>

<tr>
<td>656(290) </td>
<td>8 </td>
<td>REQ</td>
</tr>

<tr>
<td>664(298) </td>
<td>8 </td>
<td>MOVE</td>
</tr>

<tr>
<td>672(2A0) </td>
<td>4 </td>
<td>DUMP</td>
</tr>

<tr>
<td>676(2A4) </td>
<td>4 </td>
<td>REST</td>
</tr>

<tr>
<td>680(2A8) </td>
<td>4 </td>
<td>SLIC</td>
</tr>

<tr>
<td>684(2AC) </td>
<td>4 </td>
<td>CNCT</td>
</tr>

<tr>
<td>688(2B0) </td>
<td>4 </td>
<td>FBWT</td>
</tr>

<tr>
<td>692(2B4) </td>
<td>4 </td>
<td>SWT</td>
</tr>

<tr>
<td>696(2B8) </td>
<td>4 </td>
<td>ERRPDL</td>
</tr>

<tr>
<td>700(2BC) </td>
<td>4 </td>
<td>MPLKPREM</td>
</tr>

<tr>
<td>704(2C0) </td>
<td>8 </td>
<td>RECADD</td>
</tr>

<tr>
<td>712(2C8) </td>
<td>8 </td>
<td>RECDEL</td>
</tr>

<tr>
<td>720(2D0) </td>
<td>8 </td>
<td>BADD</td>
</tr>

<tr>
<td>728(2D8) </td>
<td>8 </td>
<td>BDEL</td>
</tr>

<tr>
<td>736(2E0) </td>
<td>8 </td>
<td>BCHG</td>
</tr>

<tr>
<td>744(2E8) </td>
<td>8 </td>
<td>IXADD</td>
</tr>

<tr>
<td>752(2F0) </td>
<td>8 </td>
<td>IXDEL</td>
</tr>

<tr>
<td>760(2F8) </td>
<td>8 </td>
<td>FINDS</td>
</tr>

<tr>
<td>768(300) </td>
<td>4 </td>
<td>SORTS</td>
</tr>

<tr>
<td>772(304) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>776(308) </td>
<td>8 </td>
<td>RECDS</td>
</tr>

<tr>
<td>784(310) </td>
<td>8 </td>
<td>STRECDS</td>
</tr>

<tr>
<td>792(318) </td>
<td>8 </td>
<td>DKAR</td>
</tr>

<tr>
<td>800(320) </td>
<td>8 </td>
<td>DKPR</td>
</tr>

<tr>
<td>808(328) </td>
<td>4 </td>
<td>DKRR</td>
</tr>

<tr>
<td>816(330) </td>
<td>4 </td>
<td>TFMX</td>
</tr>

<tr>
<td>820(334) </td>
<td>4 </td>
<td>USMX</td>
</tr>

<tr>
<td>824(338) </td>
<td>4 </td>
<td>SVMX</td>
</tr>

<tr>
<td>828(33C) </td>
<td>4 </td>
<td>SFTRSTRT (number of soft restarts)</td>
</tr>

<tr>
<td>832(340) </td>
<td>8 </td>
<td>APSYLD</td>
</tr>

<tr>
<td>840(348) </td>
<td>8 </td>
<td>APSYLDD</td>
</tr>

<tr>
<td>848(350) </td>
<td>4 </td>
<td>APSYLDT</td>
</tr>

<tr>
<td>852(354) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>856(358) </td>
<td>8 </td>
<td>DKPRF</td>
</tr>

<tr>
<td>864(360) </td>
<td>4 </td>
<td>SMPLS</td>
</tr>

<tr>
<td>868(364) </td>
<td>4 </td>
<td>USRS</td>
</tr>

<tr>
<td>872(368) </td>
<td>4 </td>
<td>SVAC</td>
</tr>

<tr>
<td>876(36C) </td>
<td>4 </td>
<td>RUNG</td>
</tr>

<tr>
<td>880(370) </td>
<td>4 </td>
<td>REDY</td>
</tr>

<tr>
<td>884(374) </td>
<td>4 </td>
<td>BLKI</td>
</tr>

<tr>
<td>888(378) </td>
<td>4 </td>
<td>WTSV</td>
</tr>

<tr>
<td>892(37C) </td>
<td>4 </td>
<td>BLKO</td>
</tr>

<tr>
<td>896(380) </td>
<td>4 </td>
<td>SWPG</td>
</tr>

<tr>
<td>900(384) </td>
<td>4 </td>
<td>PCPU</td>
</tr>

<tr>
<td>904(388) </td>
<td>4 </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>908(38C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>912(390) </td>
<td>8 </td>
<td>STCPU</td>
</tr>

<tr>
<td>920(398) </td>
<td>8 </td>
<td>STDEQ</td>
</tr>

<tr>
<td>928(3A0) </td>
<td>8 </td>
<td>STWAIT</td>
</tr>

<tr>
<td>936(3A8) </td>
<td>4 </td>
<td>STPOST</td>
</tr>

<tr>
<td>940(3AC) </td>
<td>4 </td>
<td>LKWAIT</td>
</tr>

<tr>
<td>944(3B0) </td>
<td>4 </td>
<td>LKPOST</td>
</tr>

<tr>
<td>948(3B4) </td>
<td>4 </td>
<td>RSXCOMP</td>
</tr>

<tr>
<td>952(3B8) </td>
<td>4 </td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>956(3BC) </td>
<td>4 </td>
<td>SCREENS</td>
</tr>

<tr>
<td>960(3C0) </td>
<td>4 </td>
<td>STIMERS</td>
</tr>

<tr>
<td>964(3C4) </td>
<td>4 </td>
<td>HRDRSTRT (number of hard restarts)</td>
</tr>

<tr>
<td>968(3C8) </td>
<td>8 </td>
<td>SVPAGES</td>
</tr>

<tr>
<td>976(3D0) </td>
<td>4 </td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>980(3D4) </td>
<td>4 </td>
<td>COMMITS</td>
</tr>

<tr>
<td>984(3D8) </td>
<td>4 </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>988(3DC) </td>
<td>4 </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>992(3E0) </td>
<td>4 </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>996(3E4) </td>
<td>4 </td>
<td>Spare</td>
</tr>

<tr>
<td>1000(3E8) </td>
<td>4 </td>
<td>CDLWAIT</td>
</tr>

<tr>
<td>1004(3EC) </td>
<td>4 </td>
<td>MQGETS</td>
</tr>

<tr>
<td>1008(3F0) </td>
<td>4 </td>
<td>MQPUTS</td>
</tr>

<tr>
<td>1012(3F4) </td>
<td>4 </td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>1016(3F8) </td>
<td>4 </td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>1020(3FC) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1024(400) </td>
<td>8 </td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>1032(408) </td>
<td>8 </td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>1040(410) </td>
<td>4 </td>
<td>MQHWQU</td>
</tr>

<tr>
<td>1044(414) </td>
<td>4 </td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>1048(418) </td>
<td>4 </td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>1052(41C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1056(420) </td>
<td>8 </td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>1064(428) </td>
<td>8 </td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>1072(430) </td>
<td>8 </td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>1080(438) </td>
<td>4 </td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>1084(43C) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1088(440) </td>
<td>8 </td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>1096(448) </td>
<td>4 </td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>1100(44C) </td>
<td>4 </td>
<td>ECLOAD</td>
</tr>

<tr>
<td>1104(450) </td>
<td>4 </td>
<td>ECDELETE</td>
</tr>

<tr>
<td>1108(454) </td>
<td>4 </td>
<td>Spare </td>
</tr>

<tr>
<td>1112(458) </td>
<td>8 </td>
<td>ECCALL</td>
</tr>

<tr>
<td>1120(460) </td>
<td>4 </td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>1124(464) </td>
<td>4 </td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>1128(468) </td>
<td>4 </td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>1132(46C) </td>
<td>4 </td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>1136(470) </td>
<td>4 </td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>1140(474) </td>
<td>4 </td>
<td>ECCNCT</td>
</tr>

<tr>
<td>1144(478) </td>
<td>4 </td>
<td>ECMODMAX</td>
</tr>

<tr>
<td>1148(47C) </td>
<td>4 </td>
<td>ECNAMMAX</td>
</tr>

<tr>
<td>1152(480) </td>
<td>4 </td>
<td>ECTSKMAX</td>
</tr>

<tr>
<td>1156(484) </td>
<td>4 </td>
<td>GTBLRU</td>
</tr>

<tr>
<td>1160(488) </td>
<td>4 </td>
<td>GTBLRS</td>
</tr>

<tr>
<td>1164(48C) </td>
<td>4 </td>
<td>TSMX</td>
</tr>

<tr>
<td>1168(490) </td>
<td>4 </td>
<td>TEMX</td>
</tr>

<tr>
<td>1172(494) </td>
<td>4 </td>
<td>MAXIOX</td>
</tr>

<tr>
<td>1176(498) </td>
<td>8 </td>
<td>DKRDL</td>
</tr>

<tr>
<td>1184(4A0) </td>
<td>8 </td>
<td>DKWRL</td>
</tr>

<tr>
<td>1192(4A8) </td>
<td>8 </td>
<td>CPUTOTZE</td>
</tr>

<tr>
<td>1200(4B0) </td>
<td>8 </td>
<td>CPUONZIP</td>
</tr>

<tr>
<td>1208(4B8) </td>
<td>4 </td>
<td>MPR
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1212(4BC) </td>
<td>4 </td>
<td>MBO
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1216(4C0) </td>
<td>4 </td>
<td>MCP
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1220(4C4) </td>
<td>4 </td>
<td>RCV
 as of V7.7 with 77z257 applied
</td>
</tr>

<tr>
<td>1224(4C8) </td>
<td>8 </td>
<td>Spare </td>
</tr>

<tr>
<td>1232(4D0) </td>
<td>8 </td>
<td>DKWTMICS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1240(4D8) </td>
<td>8 </td>
<td>DKWTS
 as of V7.7, with 77z339 applied
</td>
</tr>

<tr>
<td>1248(4E0) </td>
<td>8 </td>
<td>MTDEQ</td>
</tr>

<tr>
<td>1256(4E8) </td>
<td>8 </td>
<td>MTSDEQ</td>
</tr>

<tr>
<td>1264(4F0) </td>
<td>8 </td>
<td>MTZDEQ</td>
</tr>

<tr>
<td>1272(4F8) </td>
<td>8 </td>
<td>STZDEQ</td>
</tr>

<tr>
<td>1280(500) </td>
<td>8 </td>
<td>ZTDEQ</td>
</tr>
</table>

==System performance statistics==

===Entry format===

For subtype X'02'(system performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. See [[#Description of statistics|Statistics with descriptions]] table for the meaning of each statistic. 
<table>
<caption>Layout of system subtype X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 16(10)</td>
<td>SMPLS</td>
</tr>

<tr>
<td> 20(14)</td>
<td>USRS</td>
</tr>

<tr>
<td> 24(18)</td>
<td>SVAC</td>
</tr>

<tr>
<td> 28(1C)</td>
<td>RUNG </td>
</tr>

<tr>
<td> 32(20)</td>
<td>REDY</td>
</tr>

<tr>
<td> 36(24)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 40(28)</td>
<td>WTSV</td>
</tr>

<tr>
<td> 44(2C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 48(30)</td>
<td>SWPG </td>
</tr>
</table>

==Additional disk buffer monitor statistics==

For subtype X'04' (additional disk buffer monitor statistics), the layout of the entry is shown in the following table. Each statistic in the table is: Length, 8; Data type, Binary.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Disk buffer monitor statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Disk buffer monitor statistic </th>
</tr>

<tr>
<td>16(10)</td>
<td>Spare</td>
</tr>

<tr>
<td>24(18) </td>
<td>DKSTKQC </td>
</tr>

<tr>
<td>32(20) </td>
<td>DKSWRP </td>
</tr>

<tr>
<td>40(28) </td>
<td>DKSWRPT </td>
</tr>

<tr>
<td>48(30) </td>
<td>DKSDIR </td>
</tr>

<tr>
<td>56(38) </td>
<td>DKSDIRT </td>
</tr>

<tr>
<td>64(40) </td>
<td>DKSKIP </td>
</tr>

<tr>
<td>72(48) </td>
<td>Spare </td>
</tr>

<tr>
<td>80(50) </td>
<td>Spare</td>
</tr>

<tr>
<td>88(58) </td>
<td>DKSRR </td>
</tr>

<tr>
<td>96(60) </td>
<td>DKSFBS </td>
</tr>

<tr>
<td>104(68) </td>
<td>DKSKIPT </td>
</tr>

<tr>
<td>112(70) </td>
<td>DKSAWT </td>
</tr>

<tr>
<td>120(78) </td>
<td>DKSAWW</td>
</tr>

<tr>
<td>128(80) </td>
<td>DKSAWWL</td>
</tr>

<tr>
<td>136(88) </td>
<td>DKSAWB </td>
</tr>

<tr>
<td>144(90) </td>
<td>DKSAWBL</td>
</tr>

<tr>
<td>152(98) </td>
<td>DKSRRFND </td>
</tr>

<tr>
<td>160(A0) </td>
<td>DKSTBLF </td>
</tr>

<tr>
<td>168(A8) </td>
<td>DKSTBLA </td>
</tr>

<tr>
<td>176(B0) </td>
<td>DKSTBLB </td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKSTBLC </td>
</tr>

<tr>
<td>192(C0) </td>
<td>DKSTBLD </td>
</tr>

<tr>
<td>200(C8) </td>
<td>Spare </td>
</tr>

<tr>
<td>208(D0) </td>
<td>Spare </td>
</tr>

<tr>
<td>216(D8) </td>
<td>Spare </td>
</tr>

<tr>
<td>224(E0) </td>
<td>Spare </td>
</tr>

<tr>
<td>232(E8) </td>
<td>Spare </td>
</tr>

<tr>
<td>240(F0) </td>
<td>Spare </td>
</tr>

<tr>
<td>248(F8) </td>
<td>Spare </td>
</tr>

<tr>
<td>256(100) </td>
<td>DKSTBLX </td>
</tr>

<tr>
<td>264(108) </td>
<td>DKSTBLE</td>
</tr>

<tr>
<td>272(110)</td>
<td>Spare </td>
</tr>
</table>

==Multiprocessing (MP) subtask statistics==

The following statistics apply only to installations configured for multiprocessing using MP/204. For subtype X'08' (subtask specific statistics), the layout of the entry is shown in the following table.
For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>MP subtask statistics and offsets</caption>
<tr class="head">
<th>MP statistic </th>
<th>Offset dec(hex) </th>
<th>Length</th>
</tr>

<tr>
<td>CPU </td>
<td>16(10) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PR </td>
<td>24(18) </td>
<td align="right">8</td>
</tr>

<tr>
<td>PCPU </td>
<td>32(20) </td>
<td align="right">4</td>
</tr>

<tr>
<td>STWAIT</td>
<td>36(24)</td>
<td align="right">4</td>
</tr>

<tr>
<td>STPOST</td>
<td>40(28)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKWAIT</td>
<td>44(2C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>LKPOST</td>
<td>48(30)</td>
<td align="right">4</td>
</tr>

<tr>
<td>SPARE</td>
<td>52(34)</td>
<td align="right">4</td>
</tr>

<tr>
<td>MQWTM</td>
<td>56(38) </td>
<td align="right">8</td>
</tr>

<tr>
<td>DEQ </td>
<td>64(40) </td>
<td align="right">8</td>
</tr>

<tr>
<td>ZTDEQ</td>
<td>72(48)</td>
<td align="right">8</td>
</tr>

<tr>
<td>STDEQ </td>
<td>80(50) </td>
<td align="right">8</td>
</tr>

<tr>
<td>LWTIM </td>
<td>88(58) </td>
<td align="right">4</td>
</tr>

<tr>
<td>PETIM</td>
<td>92(5C)</td>
<td align="right">4</td>
</tr>

<tr>
<td>ZCPU</td>
<td>96(60) </td>
<td align="right">8</td>
</tr>
</table>

==User statistics entries (Type 9)==

User lines report on an individual user's activity. These statistics include:
<ul>
<li>Final (logout) and partial statistics</li>

<li>Since-last and ordered index statistics</li>

<li>Performance statistics</li>
</ul>

Each user line starts with the following statistics:
ST $$$ USERID='userid' ACCOUNT='account'


The subtype, in this case PERFORMANCE, follows USERID and ACCOUNT statistics:
ST $$$ USERID='userid' ACCOUNT='account'
PERFORMANCE=n


The format of user statistics entries is shown in the following table:
<table>
<caption>User statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td>2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'09'</td>
</tr>

<tr>
<td>3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td> Subtype indicator:
<ul>
<li>X'00' = logout statistics</li>

<li>X'01' = since-last statistics</li>

<li>X'02' = partial statistics</li>

<li>X'04' = performance statistics</li>

<li>X'81' = since-last statistics including conflict statistics</li>

<li>X'41' = user restart forced out a since-last statistics record.</li>

<li>X'C1' = user restart forced out a since last statistics record which included conflict statistics</li>
</ul>
</td></tr>

<tr>
<td>4(4)</td>
<td align="right">4</td>
<td nowrap>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>

Account:
<ul>
<li>Second argument of LOGON/LOGIN command</li>

<li>Default is user ID</li>
</ul>
</td>
</tr>

<tr>
<td>26(1A)</td>
<td>10(0A)</td>
<td>EBCDIC</td>
<td>User ID</td>
</tr>

<tr>
<td>36(24)</td>
<td align="right">4</td>
<td>EBCDIC</td>
<td>Since-last ID =
See the [[#User since-last statistics|Activity types]] table where the possible activity types are listed.</td>
</tr>

<tr>
<td>40(28)</td>
<td align="right">1</td>
<td>Binary</td>
<td>IODEV number (added for MXI)</td>
</tr>

<tr>
<td>41(29)</td>
<td align="right">3</td>
<td>N/A</td>
<td>Unused</td>
</tr>

<tr>
<td>44(2C) to end of journal</td>
<td> </td>
<td>Binary</td>
<td>

Contents depend on subtypes, shown in:
<ul>
<li>[[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table</li>

<li>[[#Since-last in relation to final and partial statistics|Layout of user subtype X'01' and X'81' entries]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table</li>

<li>[[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table</li>

<li>[[#Layout of performance statistics|Layout of user subtype X'04' entries]] table</li>
</ul>
</td> </tr>
</table>

==User final and partial statistics==

===Final (logout) statistics===

Final (logout) statistics, listed in the [[#Partial statistics|Layout of user subtype X'00' and X'02' entries]] table, summarize a user's activities since the last login. A LOGOUT statistics line, such as the following, is written after each logout if the parameter following ACCOUNT is not PARTIAL, LAST, or PERFORMANCE: 
yydddhhmmssnnnsssuuuuu ST $$$ ACCOUNT='NO ACCOUNT' SQRD=5 ...

<ul>
<li><var class="term">yyddd</var> is the year and Julian day.</li>

<li><var class="term">hhmmss</var> is the time of day in hours, minutes, and seconds.</li>

<li><var class="term">nnn</var> is a counter to distinguish lines produced in the same second.</li>

<li><var class="term">sss</var> is the number of the server currently handling the user. Leading zeros are suppressed.
</li>

<li><var class="term">uuuuu</var> is a 5-digit user number associated with the audit trail line. Leading zeros are suppressed.</li>
</ul>

In some cases, the account name appears as "NO USERID NO ACCOUNT". Statistics in this category are not chargeable to any one user and should be considered system overhead.

Final lines are recognized by the absence of an indicator for another type of line.

===Partial statistics===

Optional partial statistics, listed in the "Layout of user subtype X'00' and X'02' entries" table below, can be provided for a run up to a few minutes before a system failure that prevents normal termination and production of final user and system statistics. 

User partial statistics lines, such as the following, are made available for active users: 
ST $$$ ACCOUNT='NO ACCOUNT' PARTIAL=21 ...


Statistics accumulate either:
<ul>
<li>As long as the user is logged in</li>
</ul>

or
<ul>
<li>From the first terminal input to disconnection when a login is not required </li>
</ul>

Partial statistics are requested by setting the time interval, in minutes, between successive partial lines on User 0's parameter line with the <var>ACCTIM</var> parameter. <var>ACCTIM</var> must be nonzero. 

The contents of the statistics portion of the entry, starting at offset <code>40(28)</code>, depends upon the subtype of the entry. 

Partial statistics lines are indicated on the journal by the parameter <code>PARTIAL=n</code>, where <var class="term">n</var> is a counter from the beginning of the run. <code>PARTIAL=n</code> immediately follows the type parameter.

For subtypes X'00' (logout statistics), and X'02' (partial statistics), the layout of the remainder of the entry is shown in the following table. Each statistic in the table is: Length, 4; Data type, Binary. For the meaning of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table.
<table>
<caption>Layout of user subtype X'00' and X'02' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>40(28)</td>
<td>CNCT</td>
</tr>

<tr>
<td>44(2C)</td>
<td>DKRD </td>
</tr>

<tr>
<td>48(30)</td>
<td>DKWR </td>
</tr>

<tr>
<td>52(34)</td>
<td>SQRD</td>
</tr>

<tr>
<td>56(38)</td>
<td>SQWR</td>
</tr>

<tr>
<td>60(3C)</td>
<td>SGMTI </td>
</tr>

<tr>
<td>64(40)</td>
<td>SGMTO </td>
</tr>

<tr>
<td>68(44)</td>
<td>SVRD</td>
</tr>

<tr>
<td>72(48)</td>
<td>SVWR </td>
</tr>

<tr>
<td>76(4C)</td>
<td>CPU </td>
</tr>

<tr>
<td>80(50)</td>
<td>REQ </td>
</tr>

<tr>
<td>84(54)</td>
<td>MOVE </td>
</tr>

<tr>
<td>88(58)</td>
<td>DUMP </td>
</tr>

<tr>
<td>92(5C)</td>
<td>REST </td>
</tr>

<tr>
<td>96(60)</td>
<td>SLIC </td>
</tr>

<tr>
<td>100(64)</td>
<td>AUDIT </td>
</tr>

<tr>
<td>104(68) </td>
<td>WAIT </td>
</tr>

<tr>
<td>108(6C)</td>
<td>FBWT </td>
</tr>

<tr>
<td>112(70)</td>
<td>UDD </td>
</tr>

<tr>
<td>116(74)</td>
<td>RECADD </td>
</tr>

<tr>
<td>120(78)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>124(7C)</td>
<td>BADD </td>
</tr>

<tr>
<td>128(80)</td>
<td>BDEL</td>
</tr>

<tr>
<td>132(84)</td>
<td>BCHG </td>
</tr>

<tr>
<td>136(88)</td>
<td>IXADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>FINDS </td>
</tr>

<tr>
<td>148(94)</td>
<td>SORTS</td>
</tr>

<tr>
<td>152(98)</td>
<td>RECDS </td>
</tr>

<tr>
<td>156(9C)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>160(A0)</td>
<td>DKAR </td>
</tr>

<tr>
<td>164(A4)</td>
<td>DKPR </td>
</tr>

<tr>
<td>168(A8)</td>
<td>DKRR </td>
</tr>

<tr>
<td>172(AC)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>UPDTTIME(MS) </td>
</tr>

<tr>
<td>184(B8)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>188(BC)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>192(C0)</td>
<td>SMPLS </td>
</tr>

<tr>
<td>196(C4)</td>
<td>RUNG </td>
</tr>

<tr>
<td>200(C8)</td>
<td>REDY</td>
</tr>

<tr>
<td>204(CC)</td>
<td>BLKI</td>
</tr>

<tr>
<td>208(D0)</td>
<td>WTSV </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BLKO </td>
</tr>

<tr>
<td>216(D8)</td>
<td>SWPG </td>
</tr>

<tr>
<td>220(DC)</td>
<td>PCPU </td>
</tr>

<tr>
<td>224(E0)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>228(E4)</td>
<td>BXCHNG </td>
</tr>

<tr>
<td>232(E8)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>236(EC)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>240(F0)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>244(F4)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>248(F8)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>252(FC)</td>
<td>BXRFND</td>
</tr>

<tr>
<td>256(100)</td>
<td>BXFREE </td>
</tr>

<tr>
<td>260(104)</td>
<td>STCPU </td>
</tr>

<tr>
<td>264(108)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>268(10C)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>272(110)</td>
<td>SCREENS </td>
</tr>

<tr>
<td>276(114)</td>
<td>SVPAGES </td>
</tr>

<tr>
<td>280(118)</td>
<td>PBRSFLT </td>
</tr>

<tr>
<td>284(11C)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>292(124)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQBYTOU</td>
</tr>

<tr>
<td>308((134)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>380(17C)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>384(180)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>388(184)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>392(188)</td>
<td>Spare</td>
</tr>

<tr>
<td>396(18C) </td>
<td>MPR (V7.7 only)</td>
</tr>

<tr>
<td>400(190) </td>
<td>MBO (V7.7 only)</td>
</tr>

<tr>
<td>404(194)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>408(198)</td>
<td>ZTDEQ</td>
</tr>

</table>

==User since-last statistics==

===Since-last statistics===

Statistics are kept for each SOUL request, host language interface call, and a number of <var class="product">Model 204</var> system commands. When each request or command completes, a since-last statistics line is written. The line includes the <var>ACCOUNT</var> parameter at the beginning, followed by the <var>IODEV</var> parameter and the <var>LAST</var> parameter.

Several <var>MONITOR</var> commands produce displays containing the user's last or current activity in the <code>FUNC</code> column. When this activity completes, statistics are also written to CCAAUDIT and the activity is described in ST lines as <code>LAST='activity'</code>.

====Syntax====
ST $$$ USERID='userid' ACCOUNT='accountname' IODEV='devicetype' LAST='acty'

Where:

<var class="term">acty</var> can be one of the following: 
<table>
<caption>Activity types</caption>
<tr class="head">
<th>Option</th>
<th>Meaning</th>
</tr>

<tr>
<td>BLDR</td>
<td><var>BLDREUSE</var> command</td>
</tr>

<tr>
<td>BLDX </td>
<td><var>Z</var> command</td>
</tr>

<tr>
<td>CMPL </td>
<td>Compilation of a SOUL request</td>
</tr>

<tr>
<td>CPTB</td>
<td><var>COMPACTB</var> command</td>
</tr>

<tr>
<td>CPYP </td>
<td><var>COPY PROCEDURE</var> command</td>
</tr>

<tr>
<td>CREA</td>
<td><var>CREATE FILE filename</var> command</td>
</tr>

<tr>
<td>DISP </td>
<td><var>DISPLAY PROCEDURE</var> command</td>
</tr>

<tr>
<td>DUMP </td>
<td><var>DUMP file</var> command</td>
</tr>

<tr>
<td>EDIT </td>
<td>Editing a request</td>
</tr>

<tr>
<td>EVAL </td>
<td>Evaluation of a SOUL request</td>
</tr>

<tr>
<td>EXEC </td>
<td>Execution of an SQL request</td>
</tr>

<tr>
<td>FLDC </td>
<td>Compilation of a FLOD procedure</td>
</tr>

<tr>
<td>FLDE </td>
<td>Evaluation of a FLOD procedure</td>
</tr>

<tr>
<td>IMPC </td>
<td>Implied commit</td>
</tr>

<tr>
<td>INCR</td>
<td><var>IN FILE filename INCREASE DATASETS</var> command</td>
</tr>

<tr>
<td>INIT</td>
<td><var>IN FILE filename INITIALIZE</var> command</td>
</tr>

<tr>
<td>LOAD </td>
<td>Loading a precompiled (ASPY) procedure</td>
</tr>

<tr>
<td>PREP </td>
<td>Compilation of an SQL request</td>
</tr>

<tr>
<td>REST </td>
<td><var>RESTORE file</var> command</td>
</tr>
</table>

===Since-last highwater marks===

The since-last statistics include highwater marks of various work tables used by SOUL requests. Values are reported in terms of the units in which each table is allocated. For example, QTBL is allocated in units of 16 bytes.

===Since-last in relation to final and partial statistics===

Many since-last statistics, such as CNCT, CPU, and DKRD, are also reported on user final and partial statistics lines. (See the [[#Description of statistics|Statistics with descriptions]] table.) The statistics on these lines are roughly equal to the sum of all of the preceding since-last statistics for the user.
Because since-last statistics are not maintained for every <var class="product">Model 204</var> command, final statistics are generally larger.

For subtype X'01' (since-last statistics), the layout of the remainder of the entry begins as shown in the following table.
For the meaning of each statistic in this table and in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table, see the [[#Description of statistics|Statistics with descriptions]] table.
The layout of the end of the entry depends on whether you chose to collect conflict statistics:
<ul>
<li>If you do not collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'01' entries (CFRJRNL=0)]] table.</li>

<li>If you do collect conflict statistics, the end of the entry is described in the [[#Conflict statistics|Layout of user subtype X'81' entries (CFRJRNL=1)]] table. When you collect conflict statistics, the subtype changes to X'81'. </li>
</ul>
<table>
<caption>Layout of user subtype X'01' and X'81' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 44(2C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 48(30)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 52(34)</td>
<td>QTBL </td>
</tr>

<tr>
<td> 56(38)</td>
<td>STBL </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>TTBL </td>
</tr>

<tr>
<td> 64(40)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 68(44)</td>
<td>PDL</td>
</tr>

<tr>
<td> 72(48)</td>
<td>FTBL </td>
</tr>

<tr>
<td> 76(4C)</td>
<td>XTBL </td>
</tr>

<tr>
<td> 80(50)</td>
<td>ITBL </td>
</tr>

<tr>
<td> 84(54)</td>
<td>FSCB </td>
</tr>

<tr>
<td> 88(58)</td>
<td>OUTPB </td>
</tr>

<tr>
<td> 92(5C) </td>
<td>HEAP </td>
</tr>

<tr>
<td> 96(60)</td>
<td>SQLI </td>
</tr>

<tr>
<td>100(64)</td>
<td>SQLO</td>
</tr>

<tr>
<td>104(68)</td>
<td>CNCT</td>
</tr>

<tr>
<td>108(6C)</td>
<td>CPU </td>
</tr>

<tr>
<td>112(70)</td>
<td>DKRD </td>
</tr>

<tr>
<td>116(74)</td>
<td>DKWR</td>
</tr>

<tr>
<td>120(78)</td>
<td>UDD </td>
</tr>

<tr>
<td>124(7C)</td>
<td>OUT </td>
</tr>

<tr>
<td>128(80)</td>
<td>SLIC</td>
</tr>

<tr>
<td>132(84)</td>
<td>IN </td>
</tr>

<tr>
<td>136(88)</td>
<td>RECADD </td>
</tr>

<tr>
<td>140(8C)</td>
<td>RECDEL </td>
</tr>

<tr>
<td>144(90)</td>
<td>BADD </td>
</tr>

<tr>
<td>148(94)</td>
<td>BDEL </td>
</tr>

<tr>
<td>152(98)</td>
<td>BCHG </td>
</tr>

<tr>
<td>156(9C)</td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0)</td>
<td>IXDEL </td>
</tr>

<tr>
<td>164(A4)</td>
<td>FINDS </td>
</tr>

<tr>
<td>168(A8)</td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC)</td>
<td>RECDS </td>
</tr>

<tr>
<td>176(B0)</td>
<td>STRECDS </td>
</tr>

<tr>
<td>180(B4)</td>
<td>PCPU </td>
</tr>

<tr>
<td>184(B8)</td>
<td>RQTM </td>
</tr>

<tr>
<td>188(BC)</td>
<td>DIRRCD </td>
</tr>

<tr>
<td>192(CO)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td>196(C4)</td>
<td>BXDELE </td>
</tr>

<tr>
<td>200(C8)</td>
<td>BXNEXT </td>
</tr>

<tr>
<td>204(CC)</td>
<td>BXFIND </td>
</tr>

<tr>
<td>208(DO)</td>
<td>BXINSE </td>
</tr>

<tr>
<td>212(D4)</td>
<td>BXSPLI </td>
</tr>

<tr>
<td>216(D8)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 220(DC)</td>
<td>BXFREE </td>
</tr>

<tr>
<td> 224(E0)</td>
<td>STCPU </td>
</tr>

<tr>
<td> 228(E4)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 232(E8)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 236(EC)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>240(F0) </td>
<td>SVRD </td>
</tr>

<tr>
<td>244(F4)</td>
<td>SVWR</td>
</tr>

<tr>
<td>248(F8) </td>
<td>DKPR </td>
</tr>

<tr>
<td>252(FC)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>256(100)</td>
<td>COMMITS </td>
</tr>

<tr>
<td>260(104)</td>
<td>BACKOUTS </td>
</tr>

<tr>
<td>264(108)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>268(10C)</td>
<td>LONGUPDTS </td>
</tr>

<tr>
<td>272(110)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>276(114)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>280(118)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>284(11C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>288(120)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>292(124)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>296(128)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>300(12C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>312(138)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>336(150)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>340(154)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>344(158)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>348(15C)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>352(160)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>356(164)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>360(168)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>372(174)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>376(178)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>380(17C)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>384(180)</td>
<td>OBJSWAP</td>
</tr>

<tr>
<td>388()184</td>
<td>SIRIUS02</td>
</tr>

<tr>
<td>392(188)</td>
<td>SIRIUS03</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>400(190) </td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>404(194) </td>
<td>Spare</td>
</tr>

<tr>
<td>408(198) </td>
<td>Spare</td>
</tr>
</table>

===Conflict statistics===

Whether you are collecting conflict statistics determines the layout at the end of the entry. Two of the conflict statistics keep track of critical file-resource conflicts, and two keep track of record-locking conflicts. Whether these statistics are collected and journaled depends on settings of the parameters <var>[[CFRLOOK parameter|CFRLOOK]]</var> and <var>[[CFRJRNL parameter|CFRJRNL]]</var>.


These statistics are not displayed with the output of the <code>MONITOR SL</code> command. Instead, you can view them (with all the other since-last statistics) by issuing the <var>MONITOR</var> command with the keyword <var>CONFLICT</var>.

The remainder of the entry depends on the setting of <var>CFRJRNL</var>.

The following table shows the layout when <var>CFRJRNL</var> is set to 0: 
<table>
<caption>Layout of user subtype X'01' entries (CFRJRNL=0)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>422(1A6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>430(1AE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>431(1AF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>

The following table shows the layout when <var>CFRJRNL</var> is set to 1. It reflects the change in offset and that the user subtypes are now X'81' entries. 
<table>
<caption>Layout of user subtype X'81' entries (CFRJRNL=1)</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Entry type</th>
</tr>

<tr>
<td>412(19C)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKCFRE stastic</td>
</tr>

<tr>
<td>416(1A0)</td>
<td align="right">4</td>
<td> Binary</td>
<td>BLKRLK statistic</td>
</tr>

<tr>
<td>420(1A4)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTCFR statistic</td>
</tr>

<tr>
<td>424(1A8)</td>
<td align="right">4</td>
<td> Binary</td>
<td>WTRLK statistic</td>
</tr>

<tr>
<td>428(1AC)</td>
<td align="right">10</td>
<td>EBCDIC</td>
<td>Subsystem name</td>
</tr>

<tr>
<td>438(1B6)</td>
<td align="right">8</td>
<td>EBCDIC</td>
<td>Procedure file name</td>
</tr>

<tr>
<td>446(1BE)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Length of following procedure name</td>
</tr>

<tr>
<td>447(1BF)</td>
<td>LAUDPROC</td>
<td>EBCDIC</td>
<td>Procedure name</td>
</tr>
</table>
Note:
The conflict statistics, BLKCFRE, BLKRLK, WTCFR, and WTRLK, are inexact. Although a user might at times conflict with multiple other users, only the first conflict encountered is counted.

==User performance statistics==

Optional performance statistics lines provide information about the operation of the <var class="product">Model 204</var> scheduler during a short period of time. Information about the length of the scheduler queues, the number of active users and servers, and the queue distribution for each user, is obtained by sampling. 

A performance line starts with:
ST $$$ USERID='userid' ACCOUNT='accountname'
PERFORMANCE=n


===Parameters to activate performance statistics===

To request performance statistics, specify the number of samples to take between performance statistics lines (<var>RPTCNT</var> parameter) and the time interval between samples (<var>SMPLTIM</var> parameter) on User 0's parameter line. When you request scheduler and server performance data (<var>SMPLTIM</var> parameter), an asynchronous operating system task, called the performance subtask, is created. Both <var>RPTCNT</var> and <var>SMPLTIM</var> must be nonzero.

===Sampling===

The performance subtask spends most of its time in a wait state. Every <var>SMPLTIM</var> milliseconds, it records the current state of the system. Data from the most recent sample is available at an Online terminal through the <var>MONITOR</var> command, described in [[Controlling system operations (CCAIN)#ONLINE monitoring|ONLINE monitoring]]. 

The number of samples taken during a run (<var>RPTCNT</var>), times the number of users in the run (<var>NUSERS</var>), must be less than 4.2 million. In large systems that run for a very long period of time, the time interval between samples cannot be extremely short. If the limit is exceeded, an OC1 interrupt occurs when the SMPLS statistic value is calculated during the printing of the system statistics, either a performance or final line.

====Layout of performance statistics====

For subtype X'04' (performance statistics), the layout of the remainder of the entry is shown in the following table.
Each statistic in the table is: Length, 4; Data type, Binary. For the description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>Layout of user subtype X'04' entries</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td> 40(28)</td>
<td>SMPLS </td>
</tr>

<tr>
<td> 44(2C)</td>
<td>RUNG</td>
</tr>

<tr>
<td> 48(30)</td>
<td>REDY </td>
</tr>

<tr>
<td> 52(34)</td>
<td>BLKI </td>
</tr>

<tr>
<td> 56(38)</td>
<td>WTSV </td>
</tr>

<tr>
<td> 60(3C)</td>
<td>BLKO </td>
</tr>

<tr>
<td> 64(40)</td>
<td>SWPG </td>
</tr>
</table>

==File statistics entries (Type 10)==

File statistics, summarized in the [[#File statistics journal records layout|File statistics entry formats]] table, are kept for every file opened during a run, including CCAGRP, CCASYS, and CCATEMP. The activity of a file for all users is summarized from the time the file is first opened until the last user issues a <var>CLOSE</var> command. The statistics appear after the last <var>CLOSE</var> command in lines that follow the date and time information (yyyydddhhmmssnnnsssuuuuu) with: 
ST $$$ FILE='filename'


System termination writes file statistics for each file still open at the end of the run.

===Final statistics===

A final statistics line similar to the following is produced when the last user of a file closes the file: 
ST $$$ FILE='PAYABLES'DKRD=25 DKRD=25 DKWR=15 REQ=3 RECADD=6 ...


===Partial statistics===

File partial statistics lines similar to the following are furnished for each open file: 
ST $$$ FILE='PAYABLES'PARTIAL=3 ...


===File statistics journal records layout===

File statistics entries have the format shown in the following table.
For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>File statistics entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Type of entry</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right"> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Type indicator = X'0A'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>Subtype indicator:
X'00' = file close
X'01' = partial</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right"> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td align="right"> 4</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td align="right"> 8</td>
<td> EBCDIC</td>
<td>File name</td>
</tr>

<tr>
<td> 24(18)</td>
<td align="right"> 2</td>
<td align="right"> — </td>
<td>Unused</td>
</tr>
</table>

The following table lists the file statistics and the decimal(hexidecimal) offset. These statistics are data type Binary and eight bytes long.
<table>
<caption>File statistics</caption>
<tr class="head">
<th>File statistic </th>
<th>Offset dec(hex) </th>
</tr>

<tr>
<td>DKRD </td>
<td>26(1A) </td>
</tr>

<tr>
<td>DKWR </td>
<td>34(22) </td>
</tr>

<tr>
<td>REQ </td>
<td>42(2A) </td>
</tr>

<tr>
<td>RETRYA </td>
<td>50(32) </td>
</tr>

<tr>
<td>RETRYC </td>
<td>58(3A) </td>
</tr>

<tr>
<td>DUPDTS </td>
<td>66(42) </td>
</tr>

<tr>
<td>RECADD </td>
<td>74(4A) </td>
</tr>

<tr>
<td>RECDEL </td>
<td>82(52) </td>
</tr>

<tr>
<td>BADD </td>
<td>90(5A) </td>
</tr>

<tr>
<td>BDEL </td>
<td>98(62) </td>
</tr>

<tr>
<td>BCHG </td>
<td>106(6A) </td>
</tr>

<tr>
<td>IXADD </td>
<td>114(72) </td>
</tr>

<tr>
<td>IXDEL </td>
<td>122(7A) </td>
</tr>

<tr>
<td>DIRRCD </td>
<td>130(82) </td>
</tr>

<tr>
<td>BXCHNG </td>
<td>138(8A) </td>
</tr>

<tr>
<td>BXDELE </td>
<td>146(92) </td>
</tr>

<tr>
<td>BXNEXT </td>
<td>154(9A) </td>
</tr>

<tr>
<td>BXFIND </td>
<td>162(A2) </td>
</tr>

<tr>
<td>BXINSE </td>
<td>170(AA) </td>
</tr>

<tr>
<td>BXSPLI </td>
<td>178(B2) </td>
</tr>

<tr>
<td>BXRFND </td>
<td>186(BA) </td>
</tr>

<tr>
<td>BXFREE </td>
<td>194(C2) </td>
</tr>

<tr>
<td>UPDTTIME </td>
<td>202(CA) </td>
</tr>

<tr>
<td>PNDGTIME </td>
<td>210(D2) </td>
</tr>

<tr>
<td>DKUPTIME </td>
<td>218(DA) </td>
</tr>

<tr>
<td>COMMITS </td>
<td>226(E2) </td>
</tr>

<tr>
<td>BACKOUTS </td>
<td>234(EA) </td>
</tr>
</table>

==Text entries (Type 11, Type 13)==

Type 11 (X'0B') and Type 13 (X'0D') entries record most of the actual text of the audit trail.

===Noncontinued text entries, Type 11 (X'0B')===

Each Type 11 journal entry corresponds to one logical entry in the audit trail, even though it might generate more than one line of physical output in the audit trail. 

The format of a Type 11 entry is shown in the following table: 
<table>
<caption>Noncontinued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Type indicator = X'0B'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right">1</td>
<td>Binary</td>
<td>Subtype indicator:

X'01' = LI line

X'02' = LP line

X'03' = LR line

X'04' = CI line

X'05' = QT line

X'08' = CP line

X'10' = OI line

X'20' = OO line

X'40' = LS line

X'80' = CS line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td align="right">4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td>12(0C)</td>
<td align="right">2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td>14(0E)</td>
<td align="right">2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td>16(10)</td>
<td>Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>

===Possibly continued text entries, Type 13 (X'0D')===

Each Type 13 journal entry corresponds to one, or part of one, logical entry in the audit trail. See the [[Tracking system activity (CCAJRNL, CCAAUDIT, CCAJLOG)#Example|Types of audit trail lines]] table for a definition of the line types.

The format of a Type 13 entry is shown in the following table: 
<table>
<caption>Possibly continued text entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0D'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = US line

X'02' = XX line

X'04' = RK line

X'08' = AD line

X'10' = MS line

X'20' = ER line
</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td>Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 2</td>
<td>Binary</td>
<td>Server number</td>
</tr>

<tr>
<td> 14(0E)</td>
<td> 2</td>
<td>Binary</td>
<td>User number</td>
</tr>

<tr>
<td> 16(10)</td>
<td> Variable</td>
<td>EBCDIC</td>
<td>Text of audit trail entry</td>
</tr>
</table>
Note:
Subtype indicator X'80' summed with any subtype means continuation into the next entry. 

==Initialization entries, Type 12 (X'0C')==

One Type 12 journal entry is written as the first nonheader entry in the journal during initialization. It contains basic information about the run being initialized.

The format of a Type 12 entry is shown in the following table:
<table>
<caption>Initialization entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'001A'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0C'</td>
</tr>

<tr>
<td> 3(3)</td>
<td> 1</td>
<td> —</td>
<td>Unused</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td> 8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>

<tr>
<td> 12(0C)</td>
<td> 8</td>
<td> EBCDIC</td>
<td>Version ID (for example, 4.2.0G)</td>
</tr>

<tr>
<td> 20(14)</td>
<td> 2</td>
<td> Binary</td>
<td>Spare for the run</td>
</tr>

<tr>
<td> 22(16)</td>
<td> 4</td>
<td> EBCDIC</td>
<td>SMF ID (SYSID parameter) </td>
</tr>
</table>

==Time-stamp entries, Type 14 (X'0E')==

Type 14 entries are used to force time-stamps to the journal. 

The format of a Type 14 entry is shown in the following table: 
<table>
<caption>Time-stamp entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'000C'</td>
</tr>

<tr>
<td>2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0E'</td>
</tr>

<tr>
<td>3(3)</td>
<td> 1</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td>4(4)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Julian date = 0CYYDDDF</td>
</tr>

<tr>
<td>8(8)</td>
<td> 4</td>
<td> Unsigned packed data</td>
<td>Time = HHMMSSTH</td>
</tr>
</table>

==Merged journal bracketing entries (Type 15)==

Type 15 entries appear only in the output of the MERGEJ utility. See [[System and media recovery#Using the MERGEJ utility|Using the MERGEJ utility]]. 

The format of a Type 15 entry is shown in the following table:
<table>
<caption>Merged journal bracketing entry formats</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Length</th>
<th>Data type</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td> Binary</td>
<td>Length of entry = X'002E'</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 1</td>
<td> Binary</td>
<td>Type indicator = X'0F'</td>
</tr>

<tr>
<td> 3(3)</td>
<td align="right"> 1</td>
<td> Binary</td>
<td>

Subtype indicator:

X'01' = begin bracket

X'02' = end bracket
</td>
</tr>

<tr>
<td> 4(4)</td>
<td>12(0C)</td>
<td>  —</td>
<td>Unused</td>
</tr>

<tr>
<td> 16(10)</td>
<td>2(2)</td>
<td> Binary </td>
<td>Number of journals merged together</td>
</tr>

<tr>
<td> 18(12)</td>
<td>28(1C)</td>
<td>EBCDIC</td>
<td>Text:
<ul>
<li>For subtype X'01' = BEGINNING OF MERGED JOURNAL</li>

<li>For subtype X'02' = END OF MERGED JOURNAL</li>
</ul>
</td></tr>
</table>

==System Management Facilities==

You can write certain statistics to the System Management Facilities (SMF) data set by: 
<ul>
<li>Setting the <var>[[SMFSLRN parameter|SMFSLRN]]</var> and <var>[[SMFLORN parameter|SMFLORN]]</var> parameters on the User 0 command line to activate the SMF feature. (z/OS and z/VM)</li>

<li>Modifying the program that processes the SMF data set to handle the records written by <var class="product">Model 204</var>. (z/VM only)</li>
</ul>

See the [[#z/VM requirements|z/VM requirements]] and the the [[#z/OS requirements|z/OS requirements]] sections for details.

Since-last statistics or logout statistics can be written concurrently with statistics that are written to the journal. Logout statistics are more complete than since-last statistics. Many more since-last records than logout records are usually written. 

If the operating system crashes before a user logs out, the SMF data set has a since-last record for every request run, but no logout record. 

File and system statistics cannot be written to the SMF data set.

During system initialization, <var class="product">Model 204</var> issues a message reporting the SMF system ID, the run's job name, the step name, and the JES ID. For operating systems other than z/OS, the JES ID is blank.

===z/VM requirements===

In the CMS interface to <var class="product">Model 204</var>, you can incorporate a user-written accounting exit that invokes the ACCTEXIT routine to process each statistics record as it is written. The following considerations apply:
<ul>
<li>Take care to preserve the CMS environment in which <var class="product">Model 204</var> is running. Do not change the contents of general registers 13 and 14.</li>

<li>You must specify the <var>SMFLORN</var> and/or <var>SMFSLRN</var> parameters on User 0's parameter line to activate accounting record production.</li>

<li>TEXT file for the ACCTEXIT module must be available on an accessed disk when generating M204CMS using M204GEN. For complete installation procedures, see the <var class="book">Rocket Model 204 z/VM Installation Guide</var>.</li>
</ul>

===z/OS requirements===

To write since-last SMF records in a z/OS environment, activate the SMF feature. 

To activate SMF, set the following parameters on User 0's parameter line: 
<ul>
<li>SMFSLRN — SMF record number for since-last records</li>

<li>SMFLORN — SMF record number for logout records </li>
</ul>

The following considerations apply:
<ul>
<li>Since-last SMF records are written only if the SMFSLRN parameter is set to a non-zero value at the beginning of the run.</li>

<li>Logout SMF records are written only if the SMFLORN parameter is set to a non-zero value at the beginning of the run.</li>

<li>If both parameters are set, each type of record is written.</li>
</ul>

SMF record numbers, which identify the record type to the programs that process the SMF data set, are written as part of the header of the SMF records. The record numbers must be between 128 and 255.

See the "System Management Facility record layout and statistics" section, which follows.

==System Management Facility record layout and statistics==

===SMF logout record layout===

The following table shows the basic format of the <var class="product">Model 204</var> SMF logout record: 
<table>
<caption>Basic format of Model 204 SMF logout record</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length</th>
<th> Description</th>
</tr>

<tr>
<td>0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td>2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td>4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td>5(5)</td>
<td> 1</td>
<td>Record number (<var>SMFSLRN</var> or <var>SMFLORN</var>)</td>
</tr>

<tr>
<td>6(6)</td>
<td> 8</td>
<td>Time and date</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td> 1</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>X'4A'</code> (requires zap 74Z4196)
For V7.5: <code>X'4B'</code> (requires zap 75Z326)
For V7.6: <code>X'4C'</code>
</td>
</tr>

<tr>
<td>58(3A)</td>
<td> 2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable
4-character field retrieved from the SMF control area.

The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.
</li>
</ul>

====Offsets for SMF logout record statistics====

The following table shows the layout of SMF logout record statistics. Each statistic in the table is: Length, 4 (bytes); data type, Binary.
This record has the same statistics in the same order as the CCAJRNL logout record, only the offsets are different. For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>Offset location of SMF logout record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Statistic</th>
</tr>

<tr>
<td>60(3C) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 64(40) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 68(44) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 72(48) </td>
<td>SQRD</td>
</tr>

<tr>
<td> 76(4C) </td>
<td>SQWR</td>
</tr>

<tr>
<td> 80(50) </td>
<td>SGMTI</td>
</tr>

<tr>
<td> 84(54) </td>
<td>SGMTO</td>
</tr>

<tr>
<td> 88(58) </td>
<td>SVRD</td>
</tr>

<tr>
<td> 92(5C) </td>
<td>SVWR</td>
</tr>

<tr>
<td> 96(60) </td>
<td>CPU</td>
</tr>

<tr>
<td>100(64) </td>
<td>REQ</td>
</tr>

<tr>
<td>104(68) </td>
<td>MOVE</td>
</tr>

<tr>
<td>108(6C) </td>
<td>DUMP</td>
</tr>

<tr>
<td>112(70) </td>
<td>REST</td>
</tr>

<tr>
<td>116(74) </td>
<td>SLIC</td>
</tr>

<tr>
<td>120(78) </td>
<td>AUDIT</td>
</tr>

<tr>
<td>124(7C) </td>
<td>WAIT</td>
</tr>

<tr>
<td>128(80) </td>
<td>FBWT</td>
</tr>

<tr>
<td>132(84) </td>
<td>UDD</td>
</tr>

<tr>
<td>136(88) </td>
<td>RECADD</td>
</tr>

<tr>
<td>140(8C) </td>
<td>RECDEL</td>
</tr>

<tr>
<td>144(90) </td>
<td>BADD</td>
</tr>

<tr>
<td>148(94) </td>
<td>BDEL</td>
</tr>

<tr>
<td>152(98) </td>
<td>BCHG</td>
</tr>

<tr>
<td>156(9C) </td>
<td>IXADD</td>
</tr>

<tr>
<td>160(A0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td>164(A4) </td>
<td>FINDS</td>
</tr>

<tr>
<td>168(A8) </td>
<td>SORTS</td>
</tr>

<tr>
<td>172(AC) </td>
<td>RECDS</td>
</tr>

<tr>
<td>176(B0) </td>
<td>STRECDS</td>
</tr>

<tr>
<td>180(B4) </td>
<td>DKAR</td>
</tr>

<tr>
<td>184(B8) </td>
<td>DKPR</td>
</tr>

<tr>
<td>188(BC) </td>
<td>DKRR</td>
</tr>

<tr>
<td>192(C0) </td>
<td>COMMITS</td>
</tr>

<tr>
<td>196(C4) </td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>200(C8) </td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>204(CC) </td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>208(D0) </td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>212(D4) </td>
<td>SMPLS</td>
</tr>

<tr>
<td>216(D8) </td>
<td>RUNG</td>
</tr>

<tr>
<td>220(DC) </td>
<td>REDY</td>
</tr>

<tr>
<td>224(E0) </td>
<td>BLKI</td>
</tr>

<tr>
<td>228(E4) </td>
<td>WTSV</td>
</tr>

<tr>
<td>232(E8) </td>
<td>BLKO</td>
</tr>

<tr>
<td>236(EC) </td>
<td>SWPG</td>
</tr>

<tr>
<td>240(F0) </td>
<td>PCPU</td>
</tr>

<tr>
<td>244(F4) </td>
<td>DIRRCD</td>
</tr>

<tr>
<td>248(F8) </td>
<td>BXCHNG</td>
</tr>

<tr>
<td>252(FC) </td>
<td>BXDELE</td>
</tr>

<tr>
<td>256(100) </td>
<td>BXNEXT</td>
</tr>

<tr>
<td>260(104)</td>
<td>BXFIND</td>
</tr>

<tr>
<td>264(108)</td>
<td>BXINSE</td>
</tr>

<tr>
<td>268(10C)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td>272(110)</td>
<td>BXFND</td>
</tr>

<tr>
<td>276(114)</td>
<td>BXFREE</td>
</tr>

<tr>
<td>280(118)</td>
<td>STCPU</td>
</tr>

<tr>
<td>284(11C)</td>
<td>STDEQ</td>
</tr>

<tr>
<td>288(120)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td>292(124)</td>
<td>SCREENS</td>
</tr>

<tr>
<td>296(128)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>300(12C)</td>
<td>PBRSFLT</td>
</tr>

<tr>
<td>304(130)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>308(134)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>312(138)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>316(13C)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>320(140)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>324(144)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>328(148)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>332(14C)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>336(150)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>340(154)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>344(158)</td>
<td>MQAPICNT</td>
</tr>

<tr>
<td>348(15C)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>352(160)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>364(16C)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>368(170)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>372(174)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>376(178)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>380(17C)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>384(180)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>388(184)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>392(188)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>396(18C)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>400(190)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>404(194)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>408(198)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>412(19C)</td>
<td>Spare </td>
</tr>

<tr>
<td>416(1A0)</td>
<td>Spare</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>Spare</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>Spare</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>Spare</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>Spare</td>
</tr>
</table>

===SMF since-last record layout===

The following table shows the basic format of since-last <var class="product">Model 204</var> SMF records. 
<table>
<caption>Since-last record basic format</caption>
<tr class="head">
<th>Offset(hex)</th>
<th>Length (bytes)</th>
<th>Description</th>
</tr>

<tr>
<td> 0(0)</td>
<td> 2</td>
<td>Length of record</td>
</tr>

<tr>
<td> 2(2)</td>
<td> 2</td>
<td>Zeros</td>
</tr>

<tr>
<td> 4(4)</td>
<td> 1</td>
<td>System configuration</td>
</tr>

<tr>
<td> 5(5)</td>
<td> 1</td>
<td>Record number (SMFSLRN)</td>
</tr>

<tr>
<td> 6(6)</td>
<td> 8</td>
<td>Time and date</td>
</tr>

<tr>
<td>14(E)</td>
<td> 4</td>
<td>System identification</td>
</tr>

<tr>
<td>18(12)</td>
<td> 8</td>
<td>Job name</td>
</tr>

<tr>
<td>26(1A)</td>
<td> 8</td>
<td>Time and date of login</td>
</tr>

<tr>
<td>34(22)</td>
<td> 10</td>
<td>Login user ID</td>
</tr>

<tr>
<td>44(2C)</td>
<td> 10</td>
<td>Login account</td>
</tr>

<tr>
<td>54(36)</td>
<td> 2</td>
<td>Binary user number</td>
</tr>

<tr>
<td>56(38)</td>
<td>1</td>
<td>SMFSLTYP - X'01' if CRFJRNL=1 (conflict counters present)

SMFSLTYP - X'00' if CRFJRNL=0 (conflict counters not present)
</td>
</tr>

<tr>
<td>57(39)</td>
<td> 1</td>
<td>Model 204 version number in hex:
For V7.4: <code>X'4A'</code> (requires zap 74Z4196)
For V7.5: <code>X'4B'</code> (requires zap 75Z326)
For V7.6: <code>X'4C'</code>
</td>
</tr>

<tr>
<td>58(3A)</td>
<td>2</td>
<td>Unused (reserved)</td>
</tr>

<tr>
<td>60(3C)</td>
<td> 4</td>
<td>Since-last type (EVAL CMPL DUMP REST...)</td>
</tr>

<tr>
<td>64(40)</td>
<td> 8</td>
<td>File name</td>
</tr>

<tr>
<td>72(48)</td>
<td>10</td>
<td>Since-last subsystem name</td>
</tr>

<tr>
<td>82(52)</td>
<td>40</td>
<td>Since-last procedure name</td>
</tr>

<tr>
<td>122(7A)</td>
<td>2</td>
<td>Reserved two bytes</td>
</tr>

<tr>
<td>124(7C)</td>
<td> </td>
<td>Binary fullwords of statistics</td>
</tr>
</table>
<ul>
<li>Statistics depend upon the record number.</li>

<li>The SMF system identification field (offset 16) is the site-definable 4-character field retrieved from the SMF control area.</li>

<li>The SMF control area field contains the CPU identification string that is stored at system IPL time, and it can be used to determine on which CPU <var class="product">Model 204</var> is running in a multi-CPU environment.</li>
</ul>

====Offsets for SMF since-last record statistics====

The following table shows the layout of SMF since-last record statistics. Each statistic in the table is: Length, 4 (bytes); Data type, Binary.
This record has the same statistics in the same order as the CCAJRNL user since-last records; only the offsets are different. For a description of each statistic, see the [[#Description of statistics|Statistics with descriptions]] table. 
<table>
<caption>SMF since-last record statistics</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td> 124(7C)</td>
<td>NTBL</td>
</tr>

<tr>
<td> 128(80)</td>
<td>GTBL</td>
</tr>

<tr>
<td> 132(84)</td>
<td>QTBL</td>
</tr>

<tr>
<td> 136(88) </td>
<td>STBL</td>
</tr>

<tr>
<td> 140(8C)</td>
<td>TTBL</td>
</tr>

<tr>
<td> 144(90)</td>
<td>VTBL</td>
</tr>

<tr>
<td> 148(94)</td>
<td>PDL</td>
</tr>

<tr>
<td> 152(98)</td>
<td>FTBL</td>
</tr>

<tr>
<td> 156(9C)</td>
<td>XTBL</td>
</tr>

<tr>
<td> 160(A0)</td>
<td>ITBL</td>
</tr>

<tr>
<td> 164(A4)</td>
<td>FSCB</td>
</tr>

<tr>
<td> 168(A8)</td>
<td>OUTPB</td>
</tr>

<tr>
<td> 172(AC) </td>
<td>HEAP</td>
</tr>

<tr>
<td> 176(B0) </td>
<td>SQLI</td>
</tr>

<tr>
<td> 180(B4) </td>
<td>SQLO</td>
</tr>

<tr>
<td> 184(B8) </td>
<td>CNCT</td>
</tr>

<tr>
<td> 188(BC) </td>
<td>CPU</td>
</tr>

<tr>
<td> 192(C0) </td>
<td>DKRD</td>
</tr>

<tr>
<td> 196(C4) </td>
<td>DKWR</td>
</tr>

<tr>
<td> 200(C8) </td>
<td>UDD</td>
</tr>

<tr>
<td> 204(CC) </td>
<td>OUT</td>
</tr>

<tr>
<td> 208(D0) </td>
<td>SLIC</td>
</tr>

<tr>
<td> 212(D4) </td>
<td>IN</td>
</tr>

<tr>
<td> 216(D8) </td>
<td>RECADD</td>
</tr>

<tr>
<td> 220(DC) </td>
<td>RECDEL</td>
</tr>

<tr>
<td> 224(E0) </td>
<td>BADD</td>
</tr>

<tr>
<td> 228(E4) </td>
<td>BDEL</td>
</tr>

<tr>
<td> 232(E8) </td>
<td>BCHG</td>
</tr>

<tr>
<td> 236(EC) </td>
<td>IXADD</td>
</tr>

<tr>
<td> 240(F0) </td>
<td>IXDEL</td>
</tr>

<tr>
<td> 244(F4) </td>
<td>FINDS</td>
</tr>

<tr>
<td> 248(F8) </td>
<td>SORT</td>
</tr>

<tr>
<td> 252(FC) </td>
<td>RECDS</td>
</tr>

<tr>
<td> 256(100)</td>
<td>STRECDS</td>
</tr>

<tr>
<td> 260(104)</td>
<td>PCPU</td>
</tr>

<tr>
<td> 264(108)</td>
<td>RQTM</td>
</tr>

<tr>
<td> 268(10C)</td>
<td>DIRRCD</td>
</tr>

<tr>
<td> 272(110)</td>
<td>BXCHNG</td>
</tr>

<tr>
<td> 276(114)</td>
<td>BXDELE</td>
</tr>

<tr>
<td> 280(118)</td>
<td>BXNEXT</td>
</tr>

<tr>
<td> 284(11C)</td>
<td>BXFIND</td>
</tr>

<tr>
<td> 288(120)</td>
<td>BXINSE</td>
</tr>

<tr>
<td> 292(124)</td>
<td>BXSPLI</td>
</tr>

<tr>
<td> 296(128)</td>
<td>BXRFND</td>
</tr>

<tr>
<td> 300(12C)</td>
<td>BXFREE</td>
</tr>

<tr>
<td> 304(130)</td>
<td>STCPU</td>
</tr>

<tr>
<td> 308(134)</td>
<td>STDEQ</td>
</tr>

<tr>
<td> 312(138)</td>
<td>SCHDCPU</td>
</tr>

<tr>
<td> 316(13C)</td>
<td>SCREENS</td>
</tr>

<tr>
<td> 320(140)</td>
<td>SVRD</td>
</tr>

<tr>
<td> 324(144)</td>
<td>SVWR</td>
</tr>

<tr>
<td> 328(148)</td>
<td>DKPR</td>
</tr>

<tr>
<td> 332(14C)</td>
<td>SVPAGES</td>
</tr>

<tr>
<td>336(150)</td>
<td>COMMITS</td>
</tr>

<tr>
<td>340(154)</td>
<td>BACKOUTS</td>
</tr>

<tr>
<td>344(158)</td>
<td>UPDTTIME(MS)</td>
</tr>

<tr>
<td>348(15C)</td>
<td>LONGUPDTS</td>
</tr>

<tr>
<td>352(160)</td>
<td>LONGUPDTIME(MS)</td>
</tr>

<tr>
<td>356(164)</td>
<td>MQGETS</td>
</tr>

<tr>
<td>360(168)</td>
<td>MQPUTS</td>
</tr>

<tr>
<td>364(16C)</td>
<td>UBUFHWS</td>
</tr>

<tr>
<td>368(170)</td>
<td>MQHWTASK</td>
</tr>

<tr>
<td>372(174)</td>
<td>MQBYTEIN</td>
</tr>

<tr>
<td>376(178)</td>
<td>MQBYTEOU</td>
</tr>

<tr>
<td>380(17C)</td>
<td>MQHWQU</td>
</tr>

<tr>
<td>384(180)</td>
<td>MQNUMQU</td>
</tr>

<tr>
<td>388(184)</td>
<td>MQNUMQM</td>
</tr>

<tr>
<td>392(188)</td>
<td>MQAPITIM</td>
</tr>

<tr>
<td>396(18C)</td>
<td>MAPICNT</td>
</tr>

<tr>
<td>400(190)</td>
<td>MQGWTTIM</td>
</tr>

<tr>
<td>404(194)</td>
<td>MQGWTCNT</td>
</tr>

<tr>
<td>408(198)</td>
<td>MQGWTTSP</td>
</tr>

<tr>
<td>412(19C)</td>
<td>MQGWTSUC</td>
</tr>

<tr>
<td>416(1A0)</td>
<td>ECLOAD</td>
</tr>

<tr>
<td>420(1A4)</td>
<td>ECDELETE</td>
</tr>

<tr>
<td>424(1A8)</td>
<td>ECCALL</td>
</tr>

<tr>
<td>428(1AC)</td>
<td>ECCWAITM</td>
</tr>

<tr>
<td>432(1B0)</td>
<td>ECCWAITS</td>
</tr>

<tr>
<td>436(1B4)</td>
<td>ECTWAITM</td>
</tr>

<tr>
<td>440(1B8)</td>
<td>ECTWAITS</td>
</tr>

<tr>
<td>444(1BC)</td>
<td>ECCTOUT</td>
</tr>

<tr>
<td>448(1C0)</td>
<td>ECCNCT</td>
</tr>

<tr>
<td>452(1C4)</td>
<td>GTBLRU</td>
</tr>

<tr>
<td>456(1C8)</td>
<td>GTBLRS</td>
</tr>

<tr>
<td>460(1CC)</td>
<td>FSCBSW</td>
</tr>

<tr>
<td>464(1D0)</td>
<td>Sirius</td>
</tr>

<tr>
<td>468(1D4)</td>
<td>Sirius</td>
</tr>

<tr>
<td>472(1D8)</td>
<td>Sirius</td>
</tr>

<tr>
<td>476(1DC)</td>
<td>ZTCPU</td>
</tr>

<tr>
<td>480(1E0)</td>
<td>ZTDEQ</td>
</tr>

<tr>
<td>484(1E4)</td>
<td>Spare</td>
</tr>

<tr>
<td>488(1E8)</td>
<td>Spare</td>
</tr>
</table>

The following table lists the conflict statistics, if <code>CFRJRNL=1</code>:

<table>
<caption>Conflict statistics, if CFRJRNL=1</caption>
<tr class="head">
<th>Offset dec(hex)</th>
<th>Description</th>
</tr>

<tr>
<td>492(1EC)</td>
<td>BLKCFRE</td>
</tr>

<tr>
<td>496(1F0)</td>
<td>BLKRLK</td>
</tr>

<tr>
<td>500(1F4)</td>
<td>WTCFR</td>
</tr>

<tr>
<td>504(1F8)</td>
<td>WTRLK</td>
</tr>
</table>

[[Category:System management]]
[[Category:System-level capabilities of Model 204]]