LENQTBL and (deprecated) LRESTBL parameters: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (Automatically generated page update)
 
(adding Usage section and text that seems to have been missed during wiki conversion)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
The <var>LRESTBL</var> parameter is an alias for <var>LENQTBL</var>.
<var>LRESTBL</var> is deprecated &mdash; use <var>LENQTBL</var> instead.
==Summary==
==Summary==
<dl>
<dl>
Line 10: Line 13:
<dd>All
<dd>All
<dt>Introduced
<dt>Introduced
<dd><var class="product">Model 204 V6.1</var> or earlier
<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 INCLUDEs contribute to filling up this table. </p>
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>
<p>
<p>Algorithm for estimating the value of LENQTBL:</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 one added at the end accounts for the maximum number of permanent procs (APSY or non-APSY) that can be in EVAL  per user.</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 <var>LENQTBL</var> suffices, although there might be cases where you need a larger or a smaller <var>LENQTBL</var> value. </p>
<p>Algorithm for corresponding storage requirements:</p>
 
<p>The total amount of storage required for the resource enqueuing table is:</p>
===Algorithm for estimating the value of LENQTBL===
<p>length of user entries + length of system header + length of file headers,</p>
<p>
<p>that is:</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, when:</p>
<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>then the calculation is as follows:</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]]
 
==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.

Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=LENQTBL_and_(deprecated)_LRESTBL_parameters&oldid=102462"