The REORGANIZE-CALC statement is used to reorganize CALC areas that belong to a particular record type. These are:
areas created by means of LOCATION MODE CALC
SEARCH KEY USING CALC on record type level
SEARCH KEY USING CALC in singular sets in which the record type is a member
REORGANIZE-CALC | ||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
RECORD-NAME = <record-name>
Name of the record type whose CALC areas are to be reorganized.
CALC-RECORD = NONE
LOCATION MODE CALC areas are not reorganized.
CALC-RECORD = list-poss(6): *WITHIN-POPULATION (...)
The LOCATION MODE CALC areas located in the specified REALM or REALMs are reorganized.
REALM = *ALL
All CALC areas are reorganized.
REALM = <realm-name>
Only the CALC area that is located in the specified REALM is reorganized.
POPULATION = *UNCHANGED
Only the probable position pointers (PPP) are updated.
A PPP update is useful for indirect LOCATION MODE CALC areas.
POPULATION = <integer 1..2147483647>
The affected CALC area is recreated. The number of specified entries is converted into a number of pages, and the number of pages is then rounded up to the next primary number (= size of the hash area in database pages).
In indirect CALC areas, the probable position pointers (PPP) are updated as well.
CALC-SEARCHKEY = NONE
The SEARCH KEY USING CALC areas that belong to the record type are not reorganized.
CALC-SEARCHKEY = list-poss(30): *KEY-POPULATION (...)
The CALC areas of the specified KEYs are reorganized.
KEY-REF = *ALL
All CALC SEARCH KEY areas are reorganized.
KEY-REF = <integer 1..65535>
Only the CALC SEARCH KEY area with the specified KEY REF is reorganized. The KEY REF can be obtained from the BPSIA log.
POPULATION = *STD
The affected CALC area is recreated. If a LOCATION MODE CALC area is present, the new size of the SEARCH KEY USING CALC area is calculated from the LOCATION MODE CALC area, or the sum of the LOCATION MODE CALC areas if distributed CALC areas are involved. If no LOCATION MODE CALC area exists, the size is based on the DBTT size of the record type.
POPULATION = *UNCHANGED
Only a probable position pointer (PPP) update is performed.
POPULATION = <integer 1..2147483647>
The affected CALC area is recreated with the specified size. The calculated number of pages is rounded up to the next primary number. In addition, the probable position pointers (PPP) are also updated.
If the same REALM or the same KEY REF is entered more than once in a list, the last specification applies.
If *ALL is entered for REALM or KEY REF in a list, the *ALL specification is assumed.
Reorganizing LOCATION MODE CALC areas
Records of a record type which is defined with LOCATION MODE IS CALC are usually stored in the database in a hash area. Their address in this hash area can be calculated by the Database Handler from the respective CALC key and the size of the area.
Only table entries consisting of the CALC key, the RSQ and the probable position pointers (PPP) are stored in the “indirect” hash area. Such indirect hash areas are generated for a LOCATION MODE CALC specification if the record type is a member in a set specified using MODE IS LIST or if PLACEMENT OPTIMIZATION or COMPRESSION FOR ALL was specified for it in the SSL.
For reorganization, BREORG calculates the size of the new hash area based on the POPULATION specification and reserves the appropriate number of pages. For each record or table entry, it then determines the address in the newly allocated hash area and relocates it there. After reorganization, the pages of the previous hash area are then available for other purposes.
This makes it possible to change the distribution of the entries in the hash area and so avoid the creation of overflow pages. You should print out an overview of the number and occupancy level of the primary pages and the overflow pages in the newly created hash area after the reorganization.
The number of entries in the DBTT of the record type in question is not altered by BREORG. However, in the case of a direct hash area, it does enter the new physical address of the respective record in column 0 of the DBTT which contains the physical addresses of all records.
Reorganizing CALC SEARCH KEY areas
A CALC SEARCH KEY area does not contain the records themselves, but the table entries. Each entry contains the CALC key, the RSQ (record sequence number) and the probable position pointer (PPP) of the corresponding record.
Three cases must be distinguished when reorganizing CALC SEARCH KEYs:
POPULATION = STD has been specified:
In this case, BREORG determines the new size of the CALC SEARCH KEY area itself. If LOCATION MODE IS CALC has been specified for the record type, this size - or the sum of all areas for a distributed record type is used to determine the population.
Otherwise, the size of the DBTT (number of entries) is used as the value for POPULATION.POPULATION = UNCHANGED has been specified:
BREORG updates the probable position pointers (PPP) of the table entries. The distribution of the table entries in the primary area and overflow pages remains the same.Updating of the probable position pointers may, for example, become necessary if the positions of the records as members of a LIST set have been altered during database processing.
A new value has been specified with POPULATION = INTEGER ...:
BREORG uses the POPULATION specification to calculate the size of the new hash area and reserves an appropriate number of contiguous pages. It then relocates the table entries to the newly-assigned pages and updates their probable position pointers (PPP). Since BREORG recreates the table entries in each case, the relocation results in a new distribution over the primary area and overflow pages.The CALC pages which were originally reserved are deallocated by BREORG during reorganization.
Since the records themselves are not relocated when CALC SEARCH KEY areas are reorganized, the information in the corresponding DBTT remains unchanged.
Determining the size of a new hash area
The number of CALC pages which BREORG newly allocates as a result of the POPULATION specification can be calculated using the following formulas:
- For an indirect hash area
for 2 Kbytes
2018 / (calc-key-length + 7) = entries-per-page 1for 4 Kbytes
3970 / (calc-key-length + 10) = entries-per-page 1for 8 Kbytes
8066 / (calc-key-length + 10) = entries-per-page 1
and
(integer - 1 / entries-per-page) + 1 = no-of-pages 2
For an direct hash area
for 2 Kbytes
2018 / (record-length + calc-key-length + 15)= entries-per-page 1- for 4 Kbytes
3970 / (record-length + calc-key-length + 22) = entries-per-page 1
- for 8 Kbytes
8066 / (record-length + calc-key-length + 22) = entries-per-page 1
and
(integer - 1 / entries-per-page) + 1 = no-of-pages 2- for 8 Kbytes
1 Round down the result
2 If the result is not a primary number, it is rounded up to the next higher primary number
no-of-pages
Number of pages in the hash area
calc-key-length
Length of CALC key (see "CALC INFORMATION")
integer
New quantity of data records as per POPULATION specifications
record-length
Length of the record type (user section and system section) (see "RECORD INFORMATION")
entries-per-page
Number of entries (records or CALC table entries) per page
If the realm which is affected by the reorganization is configured with a secondary allocation = 0, e.g. because you do not want automatic realm extension, you must ensure that sufficient contiguous empty pages (at least no-of-pages pages) are available in this realm!
Since the old hash area can be re-used, it may be viewed as a free area.
If the realm is configured with a secondary allocation > 0, BREORG automatically extends the realm concerned when required.
Execution messages
On executing a REORGANIZE-CALC statement, the results of the CALC reorganization of the record type and/or of the CALC SEARCH KEYs in the set are output as follows:
|
|
record-name
Name of the reorganized record type
set-name
Name of the reorganized set
area ref - page no
Act-key of the first CALC page
number pages
For NEW NR OF PRIMARY BUCKETS: New number of CALC BUCKETS
For NEW NR OF OVERFLOW BUCKETS: New number of overflow pages
number physical io
Number of physical input and output operations