EMPTY blocks in Type II variable and fixed variable extents which do not get used

Areas which only have a variable extent, where data have grown into the variable extent, the highwater mark is at the variable extent size
Areas which have a fixed and variable extent, where data have grown into the variable extent, the highwater mark is short by just less than one cluster size represented by EMPTY blocks.
Areas which have a fixed and variable extent, roughly one clustersize of EMPTY blocks never get used
_AreaStatus, PROSTRCT statistics and PROUTIL dbanalys all show roughly one clustersize of EMPTY blocks never get used in variable and fixed variable extents

Example: Each Area contains an identical table definition with 100000 records (# = extent size after record creation)
     

The EMPTY blocks that remain 'unused' are as a result of the interaction between the physical vs logical addressability of blocks. 

• The actual physical size of the extents as defined in the .st file
• The logically addressable blocks within the Area, defined by the cluster size and the need for an Extent Header in each database extent.

Extent Header:

• Every database extent contains an extent header, primarily used for date validations across the extents of the database. 
• The extent header is not an addressable block for user data and therefore not part of any cluster allocated to a database objects. 
• The first object of the first extent of each data Area is the Area Control Object (ACO), otherwise known as the Master Control Object.
• The extent block is however considered part of the Area Control Object
• Each subsequent extent in an Area, is created with an appropriate physical size but the addressable blocks are: extentsize -1, because of the extent header block in each extent.
• When this is a Type II Area, this results in the need to extend the Area as the number of empty blocks is not large enough to allocate a cluster for the Area. 
• As new extents are added, the number of "unusable" empty blocks decreases as these can be used as the extent header block.
• The side effects of this mechanism are magnified with large cluster sizes in Type II Storage Areas since allocation is performed in Cluster-sized chunks vs Block by Block (Type I extents) and therefore do not exactly match the physical size of the extents. 

Example: An Area with 8 Block Cluster Size

1.  Add a variable extent to an empty database
 
# dbname.st
b .
d .
d "Area8":8,64;8 .

The Block allocation for Area 8 results in the following:

Extent #   Block #   # blocks    Description
  1          0-7        (8)          Area Control Object (including Extent Header)
  1          8-15       (8)          Empty Blocks
 

• The minimum extent size is 16 Blocks
• Block #0 is an Extent Header Block that is considered part of the Area Control Object’s 8 Block Cluster.
• There are 8 Empty Blocks in Extent #1 which can be allocated to a new database object since it matches the Area’s Cluster Size (8)

2.  Add the variable extent twice to Area 8
 
# add.st
d "Area8":8,64;8 .

After adding variable extents, the Block allocation for Area 8 results in the following:

Extent #   Block #   # blocks    Description
  1          0-7        (8)          Area Control Object (including Extent Header)
  1          8-15       (8)          Empty Blocks

  2          16         (1)          Extent Header
  2          17-31      (15)         Empty Blocks

  3          32         (1)          Extent Header
  3          33-47      (15)         Empty Blocks
 

• Each of the 3 Extents are 16 Blocks long
• 32 physical blocks were added to the database where only 30 of theses are Addressable Empty Blocks
• Allocation is performed in cluster sized chunks, there are only 3 clusters worth of addressable blocks that can be used by a database object without needing to extend the database. At this point:
  • Due to the cluster size allocation there are 6 Empty Blocks that cannot be used by a database object.
  • Due to the physical size of the extents there are only 2 additional clusters worth of addressable blocks that can be used by a database object (clusters cannot span extents).

Understanding the above, the amount of physical space is therefore different in an area with one variable extent and an area with two extents that store the same amount of user data. Large cluster sizes in Type II Storage Areas magnify the EMPTY blocks that remain 'unused' as a result of the interaction between the physical vs logical addressability of blocks in cluster-sized chunks.

Example: The following database structure contains identical tables with the same amount of data in each Area

#  Area 1 with a fixed and variable extent

d "Area1":7,64;512 . f 8192 #  8192 KB
d "Area1":7,64;512 . # 4096 KB

The Block allocation for Area 1 results in the following:

Extent #   Block #   # blocks    Description
 7:1       0-511      (512)          Area Control Object (including Extent Header)
                                     Blocks 8-511 are free blocks for the ACO
 7:1       512-1023   (512)          1 cluster allocated to the Data Object (user data)

 7:2       1024       (1)            Extent Header
 7:2       1025-2560  (1536)         More User data in Data Object
                                     3 more clusters allocated to the Data Object (user data)
 7:2       2561-3071  (511)          Empty blocks (less than 1 cluster 512)


#  Area 2 with only a variable extent 

d "Area2":8,64;512 . # 10240 KB

The Block allocation for Area 2 results in the following: 

Extent #   Block #   # blocks    Description
 8:1       0-511      (512)          Area Control Object (including extent header)
                                     Blocks 8-511 are free blocks for the ACO
 8:1       512-2559   (2048)         Data Object(obj data + data used/allocated)
                                     4 clusters allocated to the Data Object (user data)