1. Overview
Create and toss limits in OpenEdge databases determine whether a record block remains on or is removed from the Record Manager (RM) chain. These thresholds are essential for managing space efficiency and performance in storage areas.
Introduced in OpenEdge 10.0B, new PROUTIL utilities allow administrators to set and display these limits for Table, BLOB, and CLOB objects, either online or offline.
2. RM Chain Behavior
The RM chain is a list of blocks in a storage area eligible for record creation. Blocks on this chain are considered active and available for storing new records. When a block no longer meets the criteria defined by the create or toss limits, it is removed from the chain.
3. Create Limit
- Definition: Minimum free space required in a block to allow creation of a new record.
- Behavior: After a record is created, if the remaining space is less than the create limit, the block is no longer eligible for new record creation.
- Excludes: Slot overhead (defined by records-per-block in the .st file).
- Defaults:
- 1KB block size: 75 bytes
- 2KB, 4KB, 8KB block sizes: 150 bytes
- Constraints:
- Must be ≥ 32 bytes
- Must be < Toss Limit
- Must be < (Block Size − 128 bytes)
- Tip: Pad the create limit to allow for record growth and reduce fragmentation.
4. Toss Limit
- Definition: Minimum free space required for a block to remain on the RM chain.
- Behavior: If free space drops below this limit, the block is removed from the RM chain and reserved for updates to existing records.
- Defaults:
- 1KB block size: 150 bytes
- 2KB, 4KB, 8KB block sizes: 300 bytes
- Constraints:
- Must be ≥ 1 byte
- Must be > Create Limit
- Must be < (Block Size − 128 bytes)
- Note: Toss limit reserved space is for updates of any records in the block — not per record.
5. Evaluation Timing
When a user attempts to create or update a record, the system limits how much time it spends searching for a block with available space. This behavior is controlled by the -recspacesearchdepth parameter, which has a maximum value of 100. This means the system will scan up to 100 blocks on the RM (Record Management) chain to find one with enough space to perform the operation.
As each block is evaluated, it may be removed from the RM chain if it fails certain criteria—specifically, the create limit or toss limit. In the worst-case scenario, if all scanned blocks are unsuitable, up to 100 blocks could be removed from the chain.
If no blocks with sufficient space are found within the -recspacesearchdepth limit, the system stops scanning the RM chain and instead pulls blocks from the empty chain, if any are available.
6. Versioning and Behavior
- Persistence:
- PROCOPY/PROREST: Limits are preserved.
- Dump & Load: Limits are based on the target database at load time.
- New Objects: Default limits apply until explicitly changed.
- Initial Utility Behavior: Early versions of PROUTIL did not validate input, which was corrected in OpenEdge 10.2B.
7. Setting Limits
Area-Level (Type I and Type II Areas)
proutil <dbname> -C setAreaCreateLimit <area-number> <limit>
proutil <dbname> -C setAreaTossLimit <area-number> <limit>
Object-Level (Type II Areas Only)
proutil <dbname> -C setTableCreateLimit <table-name> <limit>
proutil <dbname> -C setTableTossLimit <table-name> <limit>
proutil <dbname> -C setlobcreatelimit <LOB-id> <limit>
proutil <dbname> -C setlobtosslimit <LOB-id> <limit>
8. Viewing Limits
To view current toss and create limits:
proutil <dbname> -C dispTossCreateLimits <area-number>
This displays:
- Object Number
- Object Type (1 = Table, 3 = LOB)
- Toss Limit
- Create Limit
For more detail, refer to the article: How to understand the Create limit and Toss Limit of a Storage Area.
9. Best Practices
- Re-evaluate limits after schema changes.
- Tune limits based on actual record sizes and application behavior.
- Use chanalys to assess the impact of limit changes:
proutil <dbname> -C chanalys [area]
Trade-offs:
- Low create limit → fragmentation
- High create limit → wasted space
- Low toss limit → long RM chains
- High toss limit → slow space allocation
Example: Lower the create limit to 32 bytes before loading historical data to maximize packing, then reset to optimized values post-load.
10. Recommendations
Use default values unless:
- RM chains are excessively long
- Area growth is unexplained
- Fragmentation is high
Tuning the create and toss limits in OpenEdge is not a one-size-fits-all process.
There are no predefined formulas or universal calculations to determine the ideal values for every database or application workload. Instead, it is a trial-and-error process that typically involves:
- Setting initial values based on defaults or educated guesses.
- Observing system behavior using tools like
dbanalys, chanalys, and performance metrics. - Adjusting limits incrementally based on observed fragmentation, block reuse, and RM chain length.
- Repeating the cycle until a balance is achieved between space efficiency and performance.
This iterative approach is necessary because:
- Record sizes and growth patterns vary across applications.
- Storage area configurations (e.g., block size, RPB) influence how space is consumed.
- Application behavior (e.g., frequent updates vs. inserts) affects block reuse dynamics
