LENQTBL and (deprecated) LRESTBL parameters: Difference between revisions
No edit summary |
(adding Usage section and text that seems to have been missed during wiki conversion) |
||
(11 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
The <var>LRESTBL</var> parameter is an alias for <var>LENQTBL</var>. | The <var>LRESTBL</var> parameter is an alias for <var>LENQTBL</var>. | ||
<var>LRESTBL</var> is deprecated — use <var>LENQTBL</var> instead. | <var>LRESTBL</var> is deprecated — use <var>LENQTBL</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 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 [[Defining the runtime environment (CCAIN)#Resource locking|resource enqueuing table]] to be allocated for each user</p> | ||
<p>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.</p> | <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 (APSY or non-APSY)</i> + <i>avg. no. of open files per user (including files in groups)</i> + 1) | <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> | Set <var>LENQTBL</var> to the sum of the following items.</p> | ||
<p class="code">(NUSERS * LENQTBL * 32) + 64 + (NFILES * 124) | <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 class="code"><i>length of user entries</i> + <i>length of system header</i> + <i>length of file headers</i></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 | |||
==Usage notes== | |||
If SYSOPT = 1 or 2 (indicating CCASYS/APSY or CCAGRP), add 1 to the value of NFILES used in the formula. If SYSOPT = 3 (indicating both CCASYS/APSY and CCAGRP), add 2. | |||
<p>Use the value of NFILES you set in CCAIN. If you view NFILES after the run initializes, 1 or 2 has already been added, if needed, to reflect the SYSOPT value.</p> | |||
[[Category:System parameters]] | |||
[[Category:Parameters]] | [[Category:Parameters]] |
Latest revision as of 23:19, 29 March 2017
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
Usage notes
If SYSOPT = 1 or 2 (indicating CCASYS/APSY or CCAGRP), add 1 to the value of NFILES used in the formula. If SYSOPT = 3 (indicating both CCASYS/APSY and CCAGRP), add 2.
Use the value of NFILES you set in CCAIN. If you view NFILES after the run initializes, 1 or 2 has already been added, if needed, to reflect the SYSOPT value.