LENQTBL and (deprecated) LRESTBL parameters: Difference between revisions
m (misc cleanup) |
|||
| Line 16: | Line 16: | ||
==Description== | ==Description== | ||
<p>The number of entries in the resource enqueuing table to be allocated for each user</p> | <p> | ||
<p>The resource enqueuing table is used for many purposes. Opening many files concurrently and using nested | The number of entries in the resource enqueuing table to be allocated for each user</p> | ||
<p>The value of LENQTBL defaults to 6. However, if the product of < | <p> | ||
<p>The resource enqueuing table is a volatile structure: its entries can be allocated and deallocated very quickly. As a result, any prediction of its optimum size can only be roughly approximate. Typically, the following formula for sizing LENQTBL suffices, although there might be cases where you need a larger or a smaller LENQTBL value. </p> | The resource enqueuing table is used for many purposes. Opening many files concurrently and using nested <var>INCLUDE</var> commands contribute to filling up this table. </p> | ||
<p>Set LENQTBL to the sum of the following items. | <p> | ||
The value of <var>LENQTBL</var> defaults to 6. However, if the product of <code>[[NUSERS parameter|NUSERS]]*LENQTBL</code> is less than 12, that product is forced to 12 so that the table will be allocated with a minimum of 12 user entries.</p> | |||
<p class="code">LENQTBL = (<i>avg. no. of open permanent groups ( | <p> | ||
</p><p> The | The resource enqueuing table is a volatile structure: its entries can be allocated and deallocated very quickly. As a result, any prediction of its optimum size can only be roughly approximate. Typically, the following formula for sizing <var>LENQTBL</var> suffices, although there might be cases where you need a larger or a smaller <var>LENQTBL</var> value. </p> | ||
===Algorithm for estimating the value of LENQTBL=== | |||
<p>length of user entries + length of system header + length of file headers,</p> | <p> | ||
<p> | Set <var>LENQTBL</var> to the sum of the following items.</p> | ||
<p class="code">(NUSERS * LENQTBL * 32) + 64 + ( | <p class="code">LENQTBL = (<i>avg. no. of open permanent groups ([[Application Subsystem development|APSY]] or non-APSY)</i> | ||
+ <i>avg. no. of open files per user (including files in groups)</i> + 1) </p> | |||
<p> | |||
The 1 added at the end accounts for the maximum number of permanent procedures (APSY or non-APSY) that can be in EVAL per user.</p> | |||
===Algorithm for corresponding storage requirements=== | |||
<p> | |||
The total amount of storage required for the resource enqueuing table is:</p> | |||
<p> | |||
length of user entries + length of system header + length of file headers,</p> | |||
<p> | |||
That is:</p> | |||
<p class="code">(NUSERS * LENQTBL * 32) + 64 + ([[NFILES_parameter|NFILES]] * 124) | |||
</p> | </p> | ||
<p>For example, | <p> | ||
<p>NUSERS = 100</p> | For example, if:</p> | ||
<p>LENQTBL = 12, which is always the minimum allocation</p> | <p> | ||
<p>NFILES = 200</p> | NUSERS = 100</p> | ||
<p> | <p> | ||
LENQTBL = 12, which is always the minimum allocation</p> | |||
<p> | |||
NFILES = 200</p> | |||
<p> | |||
Then the calculation is as follows:</p> | |||
<p class="code">(100 * 12 * 32) + 64 + (200 * 124) = 63,264 bytes | <p class="code">(100 * 12 * 32) + 64 + (200 * 124) = 63,264 bytes | ||
</p> | </p> | ||
[[Category:System parameters]] | [[Category:System parameters]] | ||
[[Category:Parameters]] | [[Category:Parameters]] | ||
Revision as of 14:02, 6 April 2015
The LRESTBL parameter is an alias for LENQTBL. LRESTBL is deprecated — use LENQTBL instead.
Summary
- Default value
- 6
- Parameter type
- System
- Where set
- On User 0's parameter line
- Related products
- All
- Introduced
- Model 204 V2.2 or earlier
Description
The number of entries in the resource enqueuing table to be allocated for each user
The resource enqueuing table is used for many purposes. Opening many files concurrently and using nested INCLUDE commands contribute to filling up this table.
The value of LENQTBL defaults to 6. However, if the product of NUSERS*LENQTBL is less than 12, that product is forced to 12 so that the table will be allocated with a minimum of 12 user entries.
The resource enqueuing table is a volatile structure: its entries can be allocated and deallocated very quickly. As a result, any prediction of its optimum size can only be roughly approximate. Typically, the following formula for sizing LENQTBL suffices, although there might be cases where you need a larger or a smaller LENQTBL value.
Algorithm for estimating the value of LENQTBL
Set LENQTBL to the sum of the following items.
LENQTBL = (avg. no. of open permanent groups (APSY or non-APSY) + avg. no. of open files per user (including files in groups) + 1)
The 1 added at the end accounts for the maximum number of permanent procedures (APSY or non-APSY) that can be in EVAL per user.
Algorithm for corresponding storage requirements
The total amount of storage required for the resource enqueuing table is:
length of user entries + length of system header + length of file headers,
That is:
(NUSERS * LENQTBL * 32) + 64 + (NFILES * 124)
For example, if:
NUSERS = 100
LENQTBL = 12, which is always the minimum allocation
NFILES = 200
Then the calculation is as follows:
(100 * 12 * 32) + 64 + (200 * 124) = 63,264 bytes