LENQTBL and (deprecated) LRESTBL parameters: Difference between revisions
m (Automatically generated page update) |
m (Dme moved page LENQTBL parameter to LENQTBL (and deprecated LRESTBL) parameters) |
(No difference)
|
Revision as of 16:15, 21 March 2013
Summary
- Default value
- 6
- Parameter type
- System
- Where set
- On User 0's parameter line
- Related products
- All
- Introduced
- Model 204 V6.1 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 INCLUDEs 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.
Set LENQTBL to the sum of the following items.
Algorithm for estimating the value of LENQTBL:
LENQTBL = (avg. no. of open permanent groups (APSY or non-APSY) + avg. no. of open files per user (including files in groups) + 1)
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.
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, when:
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