RECLOCKO parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
 
(20 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{Template:RECLOCKO parameter subtitle}}
==Summary==
==Summary==
<dl>
<dl>
Line 10: Line 11:
<dd>All
<dd>All
<dt>Introduced
<dt>Introduced
<dd><var class="product">Sirius Mods</var> 8.1
<dd><var class="product">[[Sirius Mods]]</var> 8.1
</dl>
</dl>
==Description==
==Description==
This parameter enhances <var class="product">Model 204</var> record lock conflict handling. The meaning of the bits are:
This parameter enhances <var class="product">Model&nbsp;204</var> handling of record locking conflicts. The meaning of the bits are:
<table>
<table>
<tr>
<tr><td>X'01'</td>
<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.
<td>Issue message MSIR.1055 for any untrapped record locking conflicts. MSIR.1055 provides information about the user that holds the lock and the file and record number for which there's a conflict. In addition, if the X'04' bit of RECLOCKO is set, MSIR.1055 would be followed by an MSIR.1056 or MSIR.1057 message that provides further information about the lock conflict.<br/><br/>
<p>
A record locking conflict is considered untrapped if it is not inside a Try block with a <code>Catch RecordLockingConflict</code> clause and if there is no <code>On Record Locking Conflict</code> or <code>On Find Conflict</code> that would be driven by the conflict.</td>
A record locking conflict is considered untrapped if <i>both</i> of these are true: </p>
</tr>
<ul>
<tr>
<li>The conflict is not inside a [[Try block#Try and Catch|Try block]]  with a <code>Catch RecordLockingConflict</code> clause. </li>
<td>X'02'</td>
 
<td>Issue message MSIR.1055 for any trapped record locking conflicts. MSIR.1055 provides information about the user that holds the lock and the file and record number for which there's a conflict. In addition, if the X'04' bit of RECLOCKO is set, MSIR.1055 would be followed by an MSIR.1056 or MSIR.1057 message that provides further information about the lock conflict.<br/><br/>
<li>There is no <code>On Record Locking Conflict</code> or <code>On Find Conflict</code> that would be driven by the conflict.</li>
A record locking conflict is considered trapped if it is inside a Try block with a <code>Catch RecordLockingConflict</code> clause or if there is an <code>On Record Locking Conflict</code> or <code>On Find Conflict</code> that would be driven by the conflict.</td>
</ul></td></tr>
</tr>
 
<tr>
<tr><td>X'02'</td>
<td>X'04'</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.
<td>Maintain extra information in the record locking table. This information is provided in message MSIR.1056 or MSIR.1057 following MSIR.1055 which is issued after a record locking conflict (depending on the X'01' and X'02' bits of RECLOCKO) and can be useful in determining the cause of a record locking conflict. The extra information collected by setting this bit is also available in [[RecordLockingConflict_class|RecordLockingConflict objects]].<br/><br/>
<p>
Setting this bit increases the record locking table space requirements. See the usage notes below for more information.</td>
A record locking conflict is considered trapped if <i>either</i> of these is true: </p>
</tr>
<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><p class="note"><b>Note:</b> This setting is ignored as of version 7.5 of <var class="product">Model&nbsp;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&nbsp;204</var> V7.5. </p>
<p>
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. </p>
<p>
Setting this bit increases the record locking table space requirements. See the usage notes below for more information.</p></td></tr>
<tr><td>X'80'</td>
<td>Include the record locking table in any SVC dumps.  Requires zap <b>78z131</b>.
</td></tr>
</table>
</table>
==== Usage notes: ====


==== Usage notes ====
<ul>
<ul>
<li>The default value for RECLOCKO is X'03' which means that all record locking conflicts will result in MSIR.1055 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>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>Setting RECLOCKO X'04' increases recording locking table space requirements so should probably be accompanied by an increase in LRETBL. While a 33% increase in table usage is theoretically possibly, the actual increase would probably be significant 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 LRETBL is an increase in 64-bit storage usage and shouldn't affect the availability of 31-bit storage.
<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 RECLOCKO X'04' is set and the conflict is with a single record or recordset lock, message MSIR.1056 is issued after an MSIR.1055 and indicates whether the lock being conflicted with is a record or a recordset, whether it's 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>If RECLOCKO X'04' is set and the conflict is with a pending update lock, message MSIR.1056 is issued after an MSIR.1055 and 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 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>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>
</ul>
----
<p class="note"><b>Note:</b> The X'04' bit of <var>RECLOCKO</var> is ignored as of version 7.5 of <var class="product">Model&nbsp;204</var>. <br />The comments below are relevant only to Sirius customers who have not upgraded to <var class="product">Model&nbsp;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>
</p>
[[Category:System parameters]]
[[Category:System parameters]]
[[Category:Parameters]]
[[Category:Parameters]]

Latest revision as of 20:54, 17 February 2022

Record locking options

Summary

Default value
X'03'
Parameter type
System
Where set
User 0 CCAIN parameters
Related products
All
Introduced
Sirius Mods 8.1

Description

This parameter enhances Model 204 handling of record locking conflicts. The meaning of the bits are:

X'01' Issue message MSIR.1055 for any untrapped record locking conflicts. MSIR.1055 provides information about the user that holds the lock and the file and record number for which there's a conflict. The additional messages MSIR.1056 and MSIR.1057 provide further information about the lock conflict.

A record locking conflict is considered untrapped if both of these are true:

  • The conflict is not inside a Try block with a Catch RecordLockingConflict clause.
  • There is no On Record Locking Conflict or On Find Conflict that would be driven by the conflict.
X'02' Issue message MSIR.1055 for any trapped record locking conflicts. MSIR.1055 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 MSIR.1056 and MSIR.1057 provide further information about the lock conflict.

A record locking conflict is considered trapped if either of these is true:

  • The conflict is inside a Try block with a Catch RecordLockingConflict clause.
  • There is an On Record Locking Conflict or On Find Conflict that would be driven by the conflict.
X'04'

Note: This setting is ignored as of version 7.5 of Model 204. The information that follows here and the comments in the "Usage notes," below, is relevant only to Sirius customers who have not upgraded to Model 204 V7.5.

Maintain extra information in the record locking table. This information is provided in message MSIR.1056 or MSIR.1057, following MSIR.1055, which is issued after a record locking conflict (depending on the X'01' and X'02' bits of RECLOCKO), 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 RecordLockingConflict objects.

Setting this bit increases the record locking table space requirements. See the usage notes below for more information.

X'80' Include the record locking table in any SVC dumps. Requires zap 78z131.

Usage notes

  • The default value for RECLOCKO is X'03', which means that all record locking conflicts will result in MSIR.1055 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.
  • In Model 204 version 7.5 and later, the MSIR.1056 and MSIR.1057 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.
  • If both the X'01' and X'02' bits are off, neither message MSIR.1055, MSIR.1056, nor MSIR.1057 is issued.

Note: The X'04' bit of RECLOCKO is ignored as of version 7.5 of Model 204.
The comments below are relevant only to Sirius customers who have not upgraded to Model 204 V7.5 or later:

  • Setting the RECLOCKO X'04' bit increases recording locking table space requirements, so it should probably be accompanied by an increase in LRETBL. 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 LRETBL is an increase in 64-bit storage usage, which should not affect the availability of 31-bit storage.
  • If the RECLOCKO X'04' bit is set and the conflict is with a single record or recordset lock, message MSIR.1056 is issued after an MSIR.1055. MSIR.1056 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.
  • If the RECLOCKO X'04' bit is set and the conflict is with a pending update lock, message MSIR.1056 is issued after an MSIR.1055, 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 Model 204 for all updated records in 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.
  • If the X'04' bit is off, then neither MSIR.1056 nor MSIR.1057 is issued, whether X'01' or X'02' is on or not.