The following general tasks are involved in the update process:
-
The modified database description is first recompiled using the DASDL compiler. The entire database must be redescribed. The tables in Update, Reorganization, and Modeling Capabilities and Limitations detail the changes that can be made during the update process.
The UPDATE statement is inserted in front of the database description. This statement instructs the DASDL compiler to update the existing database description, creating a new description file.
Disjoint data sets, sets, and subsets can be declared in any order. They need not be declared in the same order as in the original DASDL. Data items must remain in the original order since their order affects the record format.
Following a syntactically correct compilation, the new database description is compared to the old description. If all changes are valid, the timestamp is transferred from the old description file to the new description file so that existing user programs can be run without recompilation.
-
The DMSUPPORT library and other database software are then recompiled using the new description file. If the ZIP compiler control option is set, the DMSUPPORT library and any other database software are compiled automatically.
Note: DASDL copies the old DMSUPPORT to DMSUPPORT/<database name>/<update level - 1> or DMSUPPORT/<database name>/<update level - 1>/<timestamp> if DMSUPPORT/<database name>/<update level - 1> exists. This copy is only available if all of the following are valid: If the current user does not have permission to copy the file, DASDL emits a security warning message. In addition, if the DMSUPPORT code file is specified without the usercode included, DASDL assumes that the old DMSUPPORT code file is under the current running usercode.-
The update level is increased due to a DASDL UPDATE.
-
Reorganization is not required.
-
The ZIP compiler control option is set.
-
The DMSUPPORT file is not in the permanent directory.
-
-
The new description file created by the DASDL compilation becomes the current database description only after the SYSTEM/DMCONTROL program or a Reorganization program created with the BUILDREORG UPDATE option has used the description file to create a control file with the UPDATE option.
If the DMCONTROL compiler control option is set, the SYSTEM/DMCONTROL program is executed automatically to create a control file.
The update process does not require physical changes to database files or records. Thus, the Reorganization program need not be run after the update process. However, it is advisable to run the Reorganization program when a new set or automatic subset is added because the update process does not insert existing data set records in the new set or subset. New sets or subsets can be generated from the data set.
In general, user programs need not be recompiled following the update process. However, some programs can require modification. For example, when a data set is deleted, all references to the data set must be eliminated from existing programs.
Special handling is required for bound programs when the database is declared in such a way as to be accessible to more than one component. In this case, all components of the program that access the database must be compiled with the same level description file. Refer to the Binder Programming Reference Manual for details on the requirements for the recompilation and rebinding of program components.
Remaps are handled differently from data sets. When changes are to be made to a data set, the Reorganization program must be used. Because remaps are logical structures, they can be changed at any time using the update process. However, when remaps are changed, the old structure description is invalidated, and user programs must be recompiled to continue using the remaps. If a program is run and remaps have changed since the program was last compiled, a VERSIONERROR #2 error is returned to the user program.
In many cases, when the data set is reorganized, the remap need not be changed to match it and user programs that invoke the remaps need not be recompiled. These cases include adding items, deleting items, replacing filler items, and changing physical attributes. When existing item attributes change, the corresponding remap items must match the data set items according to the rules for remaps listed under “Remaps Specification” in Using Remaps and Logical Databases for Security and Data Independence.
