Toss/Create limits for the Type I Areas

Documentation ("OpenEdge Data Management: Database Administration") says about proutil -C setTableTossLimit:

"For a Type II area, SETTABLETOSSLIMIT sets the table toss limit for the specified table. For a Type I area, SETTABLETOSSLIMIT issues a warning that all tables and LOBs in an area must have the same toss limit, and prompts you to confirm setting the toss limit for all tables and LOBs in the area containing the specified table."

The blocks in Type I area are "social", SAT1 has only one RM chain but nevertheless we can have two different Toss/Create limits in the same area:

Proutil -C setTableTossLimit updates the _StorageObject._Toss-Limit for all /existent/ table objects in the specified area. But when we will add new tables into the same area Progress will create for them the _StorageObject records with default values. Maybe it's just a bug. As result when we will create/update/delete the records in these tables Progress will use the _Toss-Limit of the correspondent table. So the different processes at the same time can use the different rules for the same RM chain.

Test that confirms this:

I created a database with SAT1:
d "My Area":7,32;1 .

I created the "t900" table in "My Area" and run:
proenv>proutil mydb -C setTableTossLimit t900 900
Object "t900" is in Type I area 7.
Toss limits for all tables and blobs in this area will be changed.
Do you want to continue? (11538)
y
Toss limit for object number 1 in area 7 set to 900. (12515)
Toss limit set to 900 for all tables and blobs in area 7. (12496)

Then I created the "t300" table in the same area:
proenv>proutil mydb -C dispTossCreateLimits 7
Table object number: 1, Toss Limit: 900, Create limit: 150. (12852)
Table object number: 2, Toss Limit: 300, Create limit: 150. (12852)

Then created a few records in t900 with record size less than Toss Limit of t900:

DEFINE VARIABLE i AS INTEGER     NO-UNDO.
&SCOPED-DEFINE tbl t900
REPEAT i = 1 TO 100:
  CREATE {&tbl}.
  ASSIGN {&tbl}.f = FILL("x", 600).
END.

proenv>proutil mydb -C chanalys "My Area"

          LIST OF RM CHAIN BLOCKS
                free    # free
        dbkey   space   slots   hold
        608     1592    28      0
1 block(s) found in the RM chain.

Then I did exactly the same for the "t300" table:

proenv>proutil mydb -C chanalys "My Area"

          LIST OF RM CHAIN BLOC
                free    # free
        dbkey   space   slots
        1152    2834    30
        704     350     26
        768     350     26
...
18 block(s) found in the RM chain.

proutil mydb -C dbrpr

1. Database Scan Menu
8. Rebuild RM Chain
10. Change Current Working Area

proenv>proutil mydb -C chanalys "My Area"

         LIST OF RM CHAIN BLOCKS
               free    # free
       dbkey   space   slots   hold
       96      312     24      0
       128     350     26      0
       160     350     26      0
       192     350     26      0
...
34 block(s) found in the RM chain.

In other words, proutil -C dbrpr added the blocks of the "t900" table to the RM chain. I.e. dbrpr used the default toss limit or more exactly dbrpr preferred to use the toss limit of the "t300" table (I don't know why it chose "t300"). When I run proutil -C setTableTossLimit to re-set all toss limits to 900 bytes and re-run dbrpr the utility has shrinked the RM chain down to one block.

Conclusion:
1) Don't use Type I areas.
2) If you use them (hopefully for unimportant data) then use the default Toss/Create limits to avoid the ambiguity.

Regards,
George