The renaming cycle of BRENAME/BALTER enables datenbase objects in existing databases to be renamed. To do this, only the structure information of the DBDIR, DBCOM and COSSD database files needs to be modified. When names of user realms are changed, some structure information in the relevant realms is also changed.
However, the actual user data (records and tables in the user realms) are neither checked nor changed in the renaming cycle. Consequently only changes which leave the physical database structure unchanged are permitted in the renaming cycle.
The activities which are required during renaming are divided into three sections:
preparatory measures
renaming process
follow-up activities.
Preparatory measures
In contrast to the restructuring, in a renaming cycle the After Image Logging may remain activated. Only if the name of a realm is to be changed you have to deactivate the afterimage logging with the BMEND utility (see the "Recovery, Information and Reorganization" manual, BMEND)
Renaming process
This is a process that resembles the creation of a database:
BRENAME prepares the DBDIR to accept a new SIA
New DDL and SSL definitions are then compiled and the new SIA is entered in the DBDIR
BALTER checks the renaming and updates the structure information
The following measures can be taken in a BRENAME/BALTER renaming cycle:
Changing item names in record types
Changing the types of items in record types
Subdivision of an existing item into multiple adjacent individual items
Conversion of an existing item into a vector
Conversion of one or more consecutive items into a repeating group
Grouping of multiple adjacent individual items into a new item
Conversion of a vector into a new individual item
Combination of a repeating group into one or more consecutive individual items
Changing of record names
Changing of set names
Changing of realm names
In a renaming cycle between BRENAME and BALTER BMEND cannot be executed.
The renaming cycle of BRENAME/BALTER cannot be combined with the renaming cycle of BCHANGE/BALTER.
Names of SEARCH keys in the DDL/SSL source of the schema enable the declarations of the SEARCH keys of the DDL and SSL compilers to be allocated unambiguously. As with restructuring (BCHANGE/BALTER cycle), these names can be changed without the schema or subschema description in the SIA or SSIA changing. Consequently such changes in the renaming cycle are not taken account either in the analysis or in BALTER’s REPORT outputs.
Figure 33: Restructuring process
Follow-up activities
The following activities must be performed after renaming:
Adapting the subschemas to the changed schema
Adapting DB application programs to the new schema
If required, generating new SSITAB modules for CALL-DML programs using the BCALLSI utility routine
If required, updating access rights
If required, adapting, compiling and linking application programs
If required, copying changed database files and activating the After Image Logging again with BMEND.
A logging gap occurs because of the renaming cycle (see the “Database Operation” manual, Media recovery). After the renaming cycle you must therefore establish a new basis for media recovery by copying the modified files together with the unmodified files. You must then use BMEND to activate After Image Logging again.
Changing stored data
The user data are not changed in a renaming cycle. If renaming entails semantic changes to the user data, any necessary changes to the stored data must, for example, be executed using special application programs. This can take place in normal database operation either before or after the renaming cycle (see section "Adapting user data").