The actual database transformation using BTRANS24 is performed offline on a consistent database state. Transformation must be performed under the user ID of the database. You start database transformation with the TRANSFORM-DATABASE statement.
Check run
A check is implicitly conducted before transformation. Only if this check indicates that all the prerequisites for database transformation are fulfilled are the modifications made. If any prerequisites are not satisfied then the database is not transformed. The database continues to be consistent. The database is also consistent if BTRANS24 aborts for any reason whatsoever up to this point.
Logging
To facilitate version migration from UDS/SQL V2.3 and earlier versions, all the changes made by BTRANS24 are performed with Alogging provided that this is active. Like all modifying utility routines that support Alogging, BTRANS24 first generates a checkpoint for AFIM logging. If recovery is necessary, for example because of a disk crash in a subsequent session with a version higher than UDS/SQL V2.3, then the database can be restored to the state of the last save copy using the following tools and resources:
the BMEND in UDS/SQL V2.3 or the version previously used by means of
UPDATE-DATABASE...DEADLINE=BREAKPOINTthe ALOG files created before conversion
the BTRANS24 ALOG file
the ALOG files created during subsequent operation with a version higher than UDS/SQL V2.3
Transformation
BTRANS24 makes the following changes:
A new DB layout version that is incompatible with earlier versions is entered in the DBDIR.
The required DBTT anchor pages are created in the realms.
For each record type, the ACTKEY of the first new DBTT- anchor table page is entered in the SIA.
The new DB_LAYOUT_VERSION is entered in the ACT_KEY0 and ACT_KEYN of each realm.
If there is a realm present with realm layout version '002.00' then the administration tables for FPA extents are created in ACT_KEY0. Any unused data areas belonging to ACT_KEY0 are deleted.
Data areas are initialized in ACT_KEY0 for the restartable monitoring of online DBTT extensions
Overall, only very few changes are required in the database. As a result, the utility routine BTRANS24 executes quickly.
The utility routine cannot be restarted during the modification phase. In the event of a crash, it is necessary to recommence from a backup state possibly updated on the basis of ALOG files.
The COSSD and the SSIAs in the DBDIR are not modified. The criterion for subschema modification does not change. It is therefore not necessary to recompile or relink applications.