LRETBL and (deprecated) LRECLTBL parameters: Difference between revisions
(Automatically generated page update) |
No edit summary |
||
| (11 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
The <var>LRECLTBL</var> parameter is an alias for <var>LRETBL</var>. | The <var>LRECLTBL</var> parameter is an alias for <var>LRETBL</var>. | ||
<var>LRECLTBL</var> is deprecated — use <var>LRETBL</var> instead. | <var>LRECLTBL</var> is deprecated — use <var>LRETBL</var> instead. | ||
==Summary== | ==Summary== | ||
<dl> | <dl> | ||
| Line 12: | Line 13: | ||
<dd>All | <dd>All | ||
<dt>Introduced | <dt>Introduced | ||
<dd><var class="product">Model 204 | <dd><var class="product">Model 204 V2.2</var> or earlier | ||
</dl> | </dl> | ||
==Description== | ==Description== | ||
<p>The length in bytes of each user's part of the record enqueuing table</p> | <p> | ||
<p>LRETBL is multiplied by the value of the NUSERS parameter to | The length in bytes of each user's part of the [[Defining the runtime environment (CCAIN)#Resource locking|record enqueuing table]].</p> | ||
<p>Space in the record enqueuing table is flexibly shared by the users: an individual user is not restricted to LRETBL bytes of the record enqueuing table (except in batch mode, when NUSERS=1).</p> | <p> | ||
<p>The record enqueuing table contains control information necessary to detect conflicts between users who are trying to update records simultaneously. The amount of space in this table needed by a request is roughly proportional to the number of lists and FIND statements in the request. Each FIND or list requires about 46 bytes per file for files less than or equal to 300,000 records. The space required increases at the rate of 2.25 bytes per segment. </p> | <var>LRETBL</var> is multiplied by the value of the <var>[[NUSERS_parameter|NUSERS]]</var> parameter in the formula to determine the entire size of the record enqueuing table: </p> | ||
<p class="code">(NUSERS * LRETBL) + (([[NFILES_parameter|NFILES]] +2) * 48) + 88 | |||
</p> | |||
<p> | |||
Note that the value of <var>NUSERS</var> used here is the value <b>after</b> any automatic adjustment for the <var>[[FUNTSKN parameter]]</var>. | |||
</p> | |||
<p> | |||
The resolution of this formula is forced to be at least 848. Before Model 204 V7.6, or before Model 204 V7.5 without 75Z308 maintenance applied, the maximum size was 2<sup>31</sup> - 1. In Model 204 7.6 and Model 204 7.5 with 75Z308 applied, the maximum record locking table size was increased to about 2<sup>32</sup> - 1 (4 gigabytes). </p> | |||
<p> | |||
To allocate a record locking table approaching the maximum size, it must be allocated above-the-bar, which requires the setting of the <var>[[SYSOPT2 parameter|SYSOPT2]]</var> parameter X'40' bit. </p> | |||
<p> | |||
The update that changed the maximum size also changed the behavior upon a request for a larger record locking table than is allowed. Before this update, Model 204 would issue an error message and initialization would fail. After the update, the largest possible record locking table is requested. </p> | |||
<p class="note"><b>Note:</b> This storage request might still fail, especially if the request is for a below-the-bar record locking table.</p> | |||
<p> | |||
Space in the record enqueuing table is flexibly shared by the users: an individual user is not restricted to <var>LRETBL</var> bytes of the record enqueuing table (except in batch mode, when <code>NUSERS=1</code>).</p> | |||
<p> | |||
The record enqueuing table contains control information necessary to detect conflicts between users who are trying to update records simultaneously. The amount of space in this table needed by a request is roughly proportional to the number of lists and <var>FIND</var> statements in the request. Each <var>FIND</var> or list requires about 46 bytes per file for files less than or equal to 300,000 records. The space required increases at the rate of 2.25 bytes per segment. </p> | |||
[[Category:System parameters]] | [[Category:System parameters]] | ||
[[Category:Parameters]] | [[Category:Parameters]] | ||
Latest revision as of 23:37, 17 May 2021
The LRECLTBL parameter is an alias for LRETBL. LRECLTBL is deprecated — use LRETBL instead.
Summary
- Default value
- 200
- Parameter type
- System
- Where set
- On User 0's parameter line
- Related products
- All
- Introduced
- Model 204 V2.2 or earlier
Description
The length in bytes of each user's part of the record enqueuing table.
LRETBL is multiplied by the value of the NUSERS parameter in the formula to determine the entire size of the record enqueuing table:
(NUSERS * LRETBL) + ((NFILES +2) * 48) + 88
Note that the value of NUSERS used here is the value after any automatic adjustment for the FUNTSKN parameter.
The resolution of this formula is forced to be at least 848. Before Model 204 V7.6, or before Model 204 V7.5 without 75Z308 maintenance applied, the maximum size was 231 - 1. In Model 204 7.6 and Model 204 7.5 with 75Z308 applied, the maximum record locking table size was increased to about 232 - 1 (4 gigabytes).
To allocate a record locking table approaching the maximum size, it must be allocated above-the-bar, which requires the setting of the SYSOPT2 parameter X'40' bit.
The update that changed the maximum size also changed the behavior upon a request for a larger record locking table than is allowed. Before this update, Model 204 would issue an error message and initialization would fail. After the update, the largest possible record locking table is requested.
Note: This storage request might still fail, especially if the request is for a below-the-bar record locking table.
Space in the record enqueuing table is flexibly shared by the users: an individual user is not restricted to LRETBL bytes of the record enqueuing table (except in batch mode, when NUSERS=1).
The record enqueuing table contains control information necessary to detect conflicts between users who are trying to update records simultaneously. The amount of space in this table needed by a request is roughly proportional to the number of lists and FIND statements in the request. Each FIND or list requires about 46 bytes per file for files less than or equal to 300,000 records. The space required increases at the rate of 2.25 bytes per segment.