MONITOR CFR command: Difference between revisions
m (Automatically generated page update) |
m (minor cleanup) |
||
| Line 6: | Line 6: | ||
<dd>To display each user that currently holds and enqueue on a critical file resource. | <dd>To display each user that currently holds and enqueue on a critical file resource. | ||
</dl> | </dl> | ||
==Syntax== | ==Syntax== | ||
<p class="syntax"><b>M</b>ONITOR CFR | <p class="syntax"><b>M</b>ONITOR CFR | ||
</p> | </p> | ||
<p>The MONITOR command supports the CFR option, so you can display the following information regarding critical resource enqueues. The display consists of: </p> | <p> | ||
The <var>MONITOR</var> command supports the <var>CFR</var> option, so you can display the following information regarding critical resource enqueues. The display consists of: </p> | |||
<ul> | <ul> | ||
<li | <li>User number</li> | ||
</li> | |||
<li | <li>File</li> | ||
</li> | |||
<li | <li>Time of acquisition</li> | ||
</li> | |||
<li | <li>Lock type-share or exclusive.</li> | ||
</ul> | |||
</ | |||
<p> | |||
< | <var>MONITOR CFR</var> output displays the following columns: </p> | ||
<table> | <table> | ||
<tr> <th> | <tr class="head"> | ||
<p>Column heading in display</p> | <th><p>Column heading in display</p></th> | ||
</th> <th> | <th><p>Critical file resource held</p></th> </tr> | ||
<p>Critical file resource held</p> | |||
</th> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>USER</p></var></th> | ||
<p>USER</p> | <td><p>User number of USERID holding the resource</p></td> </tr> | ||
</var></th> <td> | |||
<p>User number of USERID holding the resource</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>USERID</p></var></th> | ||
<p>USERID</p> | <td><p>Identifies the specific user</p></td> </tr> | ||
</var></th> <td> | |||
<p>Identifies the specific user</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>FILE</p></var></th> | ||
<p>FILE</p> | <td><p>Name of file being locked or shared</p></td> </tr> | ||
</var></th> <td> | |||
<p>Name of file being locked or shared</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>RECENQ </p></var></th> | ||
<p>RECENQ </p> | <td><p>Record enqueuing table</p></td> </tr> | ||
</var></th> <td> | |||
<p>Record enqueuing table</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>ALLOCD</p></var></th> | ||
<p>ALLOCD</p> | <td><p>Resource to allocate pages from Table D</p></td> </tr> | ||
</var></th> <td> | |||
<p>Resource to allocate pages from Table D</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>EXIST </p></var></th> | ||
<p>EXIST </p> | <td><p>Existence bitmap</p></td> </tr> | ||
</var></th> <td> | |||
<p>Existence bitmap</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>INDEX </p></var></th> | ||
<p>INDEX </p> | <td><p>Ordered index</p></td> </tr> | ||
</var></th> <td> | |||
<p>Ordered index</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>DIRECT </p></var></th> | ||
<p>DIRECT </p> | <td><p>Table B</p></td> </tr> | ||
</var></th> <td> | |||
<p>Table B</p> | |||
</td> </tr> | |||
<tr> <th><var> | <tr> <th><var><p>ALLOCE</p></var></th> | ||
<p>ALLOCE</p> | <td><p>Resource to allocate pages from Table E</p></td> </tr> | ||
</var></th> <td> | |||
<p>Resource to allocate pages from Table E</p> | |||
</td> </tr> | |||
</table> | </table> | ||
==Usage== | ==Usage== | ||
<p>You can use the MONITOR CFR command to detect critical file resource conflicts in long-running, complex searches against large Ordered Indexes. You can issue a BUMP userid command or STOPU or correct the inefficient program. </p> | <p> | ||
You can use the <var>MONITOR CFR</var> command to detect critical file resource conflicts in long-running, complex searches against large Ordered Indexes. You can issue a <code>BUMP <i>userid</i></code> command or <code>STOPU</code> or correct the inefficient program. </p> | |||
==Example== | ==Example== | ||
The following is typical MONITOR CFR output: | The following is typical <var>MONITOR CFR</var> output: | ||
<p class="code">USER USERID FILE RECENQ ALLOCD EXIST INDEX DIRECT ALLOCE | <p class="code">USER USERID FILE RECENQ ALLOCD EXIST INDEX DIRECT ALLOCE | ||
64 DOGS CCATEMP 190305 190305 190305 190305 190305 190305 | 64 DOGS CCATEMP 190305 190305 190305 190305 190305 190305 | ||
| Line 102: | Line 71: | ||
76 NO USERID CCATEMP S>190305 S>190305 | 76 NO USERID CCATEMP S>190305 S>190305 | ||
</p> | </p> | ||
<p>For example, if | <p> | ||
<p class="code">FD <i>ordered-numeric-field-1</i> IS GT | For example, if you execute a program that includes either of the following SOUL statements, all values of the Ordered Index for the field referenced are checked. Processing the statement holds some critical file resources for the file for a long time; update users are delayed until the search completes.</p> | ||
<p class="code">FD <i>ordered-numeric-field-1</i> IS GT '' | |||
</p> | </p> | ||
<p>or</p> | <p>or</p> | ||
<p class="code">FD <i>ordered-character-field-1</i> IS LIKE *ABC | <p class="code">FD <i>ordered-character-field-1</i> IS LIKE *ABC | ||
</p> | </p> | ||
<p>If at the same time, another user uses a program that includes the following | <p> | ||
If at the same time, another user uses a program that includes the following SOUL syntax, this user is delayed until the previous search completes:</p> | |||
<p class="code">CHANGE <i>ordered-character-field-2</i> TO 'ABC' | <p class="code">CHANGE <i>ordered-character-field-2</i> TO 'ABC' | ||
</p> | </p> | ||
<p class="note"><b>Note:</b> The S> characters before the timestamps indicate a shared lock type.</p> | <p class="note"><b>Note:</b> The <code>S></code> characters before the timestamps indicate a shared lock type.</p> | ||
[[Category: System administrator commands]] | [[Category: System administrator commands]] | ||
[[Category:Commands]] | [[Category:Commands]] | ||
Revision as of 20:15, 11 November 2014
Summary
- Privileges
- System administrator
- Function
- To display each user that currently holds and enqueue on a critical file resource.
Syntax
MONITOR CFR
The MONITOR command supports the CFR option, so you can display the following information regarding critical resource enqueues. The display consists of:
- User number
- File
- Time of acquisition
- Lock type-share or exclusive.
MONITOR CFR output displays the following columns:
Column heading in display |
Critical file resource held |
|---|---|
USER |
User number of USERID holding the resource |
USERID |
Identifies the specific user |
FILE |
Name of file being locked or shared |
RECENQ |
Record enqueuing table |
ALLOCD |
Resource to allocate pages from Table D |
EXIST |
Existence bitmap |
INDEX |
Ordered index |
DIRECT |
Table B |
ALLOCE |
Resource to allocate pages from Table E |
Usage
You can use the MONITOR CFR command to detect critical file resource conflicts in long-running, complex searches against large Ordered Indexes. You can issue a BUMP userid command or STOPU or correct the inefficient program.
Example
The following is typical MONITOR CFR output:
USER USERID FILE RECENQ ALLOCD EXIST INDEX DIRECT ALLOCE 64 DOGS CCATEMP 190305 190305 190305 190305 190305 190305 38 NO USERID ACCT7 S>190305 S>190305 61 NO USERID ACCT0 S>190305 71 NO USERID CCATEMP S>190305 S>190305 76 NO USERID CCATEMP S>190305 S>190305
For example, if you execute a program that includes either of the following SOUL statements, all values of the Ordered Index for the field referenced are checked. Processing the statement holds some critical file resources for the file for a long time; update users are delayed until the search completes.
FD ordered-numeric-field-1 IS GT ''
or
FD ordered-character-field-1 IS LIKE *ABC
If at the same time, another user uses a program that includes the following SOUL syntax, this user is delayed until the previous search completes:
CHANGE ordered-character-field-2 TO 'ABC'
Note: The S> characters before the timestamps indicate a shared lock type.