LRETBL and (deprecated) LRECLTBL parameters

From m204wiki
Revision as of 14:55, 4 April 2015 by Alex (talk | contribs)
Jump to navigation Jump to search

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 to get the size of the record enqueuing table. The resolution of this formula (NUSERS * LRETBL) + ((NFILES +2) * 32) + 88 is forced to be at least 848, and before Model 204 7.6 or Model 204 7.5 without 75Z308 applied, its maximum 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). Of course, to allocate this big a record locking table it must be allocated above-the-bar which requires the setting of the SYSOPT2 parameter X'40' bit. This update also changed the behavior when a larger record locking table than is allowed is requested. 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. Of course, the storage request can 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.