The following section describes the steps required to create a practically usable UDS/SQL database from the database copy (copy name NEW) generated by BPGSIZE:
Declare the converted database as the original database.
Check the consistency of the database if required and output database information.
Reorganize and adapt the converted database:
Reorganize hash areas of the converted database.
Adjust the size of realms in the converted database (if required).
Update the probable position pointers (PPP).
Extend the record population for record types where more than 16 777 215 records are to be stored in the future.
Check the consistency of the database if required and output database information.
Turn on AFIM logging (if desired) and/or online backup capability, and back up the usable database to tape.
In order to perform the above activities, you will need, among other things, the BMEND, BCHECK, BPSIA, BSTATUS, BPRECORD and BREORG utility routines (described in the “Recovery, Information and Reorganization” manual) and possibly also the BCHANGE and BALTER utility routines described in chapter "Restructuring the database (BCHANGE, BALTER)" of this manual.
Declaring the converted database as the original database
Following the conversion with BPGSIZE, you will need to declare the database copy (copy name NEW) that was created by BPGSIZE as the original database. This can be optionally done by using the BS2000 command MODIFY-FILE-ATTRIBUTES (to recatalog the database) or the BS2000 command COPY-FILE (to copy the database). You can then process the converted database.
If you want to be able to extend the realms of the database online, then you can fulfill the requirements for this now:
A realm that is to be extendable online must have enough space available at the time of the extension. This requirement is fulfilled when at the time of the extension the realm either has a sufficient number of file pages available or the option of online realm extension is available (see the “Database Operation” manual, Online realm extension). Storage space is assigned when the realm file is created with the BS2000 command
CREATE-FILE (see section "Preparing database creation"). You can change the storage space assignment after creation with the MODIFY-FILE-ATTRIBUTES command.
Now you can work with the converted database.
Checking the database consistency and displaying database information
Before you start reorganizing and adapting the converted database, you may use the BCHECK utility routine to check its consistency, but make sure that you take the runtimes for BCHECK into account.
You can then use the BPSIA, BSTATUS and BPRECORD utility routines to obtain relevant database information as a guideline for the required reorganization and adaptation measures.
After you have completed the reorganization and adaptation measures, you can repeat the BCHECK run and also the BPSIA, BSTATUS, and BPRECORD runs if desired.
Since the BCHECK run may take some time, this can also be done independently of the measures to adapt the database at a later stage.
Reorganizing and adapting the converted database
Reorganizing hash areas of the converted database
BPGSIZE fills pages of the converted realm with records and tables to the maximum possible extent without transferring any empty pages to it. This means that a converted realm will initially have no free space for the addition of new data. On the other hand, when the hash areas are converted by BPGSIZE, each direct and indirect CALC page of an original realm is mapped on a one-to-one basis to a CALC page in the converted realm that is approximately double or four times its original size (if conversion to a larger page format is involved).
The BREORG utility routine (REORGANIZE-CALC statement) can be used to reduce the storage space required for hash areas in the converted realm and to thus create space for the addition of new data.
Example
/REMARK **** REORGANIZING HASH AREAS ****
/START-UDS-BREORG
//SPECIFY-SCHEMA SCHEMA-NAME=schema name
//REORGANIZE-CALC RECORD-NAME=rec-name-1, -
CALC-RECORD=*WITHIN-POPULATION(REALM=*ALL, -
POPULATION=1000), -
CALC-SEARCHKEY=*KEY-POPULATION(KEY-REF=*ALL, -
POPULATION=1000)
//REORGANIZE-CALC RECORD-NAME=rec-name-2, -
CALC-RECORD=*WITHIN-POPULATION(REALM=*ALL, -
POPULATION=15000), -
CALC-SEARCHKEY=*KEY-POPULATION(KEY-REF=*ALL, -
POPULATION=150000)
.
.
.
//END
Adjusting the size of converted realms
If the additional space regained from reorganizing the hash areas is not sufficient, you will need to extend the realm in question by using the MODIFY-REALM-SIZE statement of the BREORG utility routine.
Note that if the space required to store new data in the converted realm is less than the already available amount, the MODIFY-REALM-SIZE statement could also be used to reduce the realm after reorganizing the hash areas.
When adjusting the realm size, the DBDIR (database directory) and DBCOM (database compiler realm) realms, in particular, should also be taken into account.
Updating probable position pointers (PPP)
Pointer arrays that are created as probable position pointers (PPP) are not updated by BPGSIZE when converting the database. After the conversion, you can use the SIA report of the BPSIA utility routine to determine which probable position pointers (PPP) are inaccurate (see PPP-BITS in the output of CALC/KEY/CALC-SEARCH-KEY INFORMATION) and then correct them selectively for each access path with the REORGANIZE-SET statement of the BREORG utility routine. Sets in which records are relocated must be reorganized first. Such sets are defined in the SSL with MODE IS LIST (see the "Design and Definition" manual).
Note that since the BREORG runs to update the probable position pointers may take a relatively long time, this BREORG runs could also be completed later independently of the steps required to prepare the database for DB operation.
Example
/REMARK **** UPDATING PPPs ****
/START-UDS-BREORG
/SPECIFY-SCHEMA SCHEMA-NAME=schema-name
//REORGANIZE-SET SET-NAME=set-name-1,OWNER-SELECTION=ALL,FILLING=UNCHANGED
//REORGANIZE-SET SET-NAME=set-name-2,OWNER-SELECTION=ALL,FILLING=UNCHANGED
.
.
.
//REORGANIZE-SET SET-NAME=set-name-n,OWNER-SELECTION=ALL,FILLING=UNCHANGED
//ENDUpdating the probable position pointers is faster if you use the REORGANIZE-POINTERS statement (see the section entitled ’Reorganizing the database with BREORG’ in the “Recovery, Information and Reorganization" manual).
/START-UDS-BREORG
//SPECIFY-SCHEMA SCHEMA-NAME=schema-name
//REORGANIZE-POINTERS REALM-NAME=realm-name-1
//REORGANIZE-POINTERS REALM-NAME=realm-name-2
.
.
.
//REORGANIZE-POINTERS REALM-NAME=realm-name-n,
//ENDThe following schema names and set names are used to update the probable position pointers (PPP) of the DBDIR and DBCOM:
Schema name | Set name | |
DBDIR | PRIVACY-AND-IQF-SCHEMA | USERGROUP-USERID |
DBCOM | COMPILER-SCHEMA | NAME-TABLE |
Example
/REMARK **** REORGANIZING THE DBDIR **** /START-UDS-BREORG //SPECIFY-SCHEMA SCHEMA-NAME=PRIVACY-AND-IQF-SCHEMA //REORGANIZE-SET SET-NAME=USERGROUP-USERID,OWNER-SELECTION=ALL //END /REMARK **** REORGANISATION VON DBCOM **** /START-UDS-BREORG //SPECIFY-SCHEMA SCHEMA-NAME=COMPILER-SCHEMA //REORGANIZE-SET SET-NAME=NAME-TABLE,OWNER-SELECTION=ALL //END
Extending the record set population
If the converted database was created from an original database with a 2-Kbyte format, you will need to extend the record population for record types that are expected to have more than the maximum number of 16 777 215 records allowed for 2-Kbyte databases. The record population can be extended by using the MODIFY-RECORD-POPULATION statement of the BREORG utility routine.
Turning on AFIM logging and online backup capability, saving the prepared database
If you want to operate the converted database with AFIM logging, you can turn on AFIM logging for the converted database with the BMEND utility routine.
If you want to be able to back up the converted database online in the future, use the BMEND utility routine to turn on online backup capability.
Make sure that you create a consistent backup copy of the converted database before restarting any database operations.