The DMSII MigrateDB feature allows you to add or delete disjoint data sets, their spanning sets and their subsets without bringing down the database (no reorganization is required). But, these additions or deletions must be the only changes for the next database reorganization. This means there can be no other database structure changes. This feature does not support adding sets or subsets to an existing data set; in such cases, continue to use reorganization.
By default, AB Suite 7.0 MCP Runtime Deployment automatically attempts to use MIGRATEDB for database structure additions or deletions, whenever possible. For AB Suite, the structure restrictions that apply to MIGRATEDB are:
it cannot be used if RDB is enabled.
it cannot be used if one or more datasets being added/deleted either contain a link item or a structure of link item.
it cannot be used in the same generate as XL is enabled (XL setting is managed by the deployment infrastructure based on the number of database structures).
it is recommend that Migratedb should be explicitly disabled (See MARC: NA APPL_BLD_nn HELP MIGRATEDB) in situations where DataBridge will be active during a potential Migratedb database update deployment. This will avoid possible contention for exclusive access to the DB Control file by SYSTEM/DMCONTROL.
The deployment process uses the DMSII DASDL output to determine the validity of the DMSII MIGRATEDB for this deployment, if the DASDL says the MIGRATEDB is not appropriate, the deployment continues without the MIGRATEDB. No user intervention is required.
A Build Preview output indicates in its summary whether MIGRATEDB is used for the deployment.
If the deployment proceeds with MIGRATEDB, two status messages are returned to the client.
MIGRATEDB is used to apply these DB changes.
This message appears when the deployment has determined that MIGRATEDB can be used to apply these database additions/deletions.
MIGRATEDB in progress Job = <job number>
This message appears when the compilation of the DMSII software with the MIGRATEDB setting is started in the Generate WFL.
If a deployment fails because it incorrectly evaluated the changes to the database and tried to use the MIGRATEDB option with an incompatible set of database changes, it is possible to disable MIGRATEDB from the Application Builder server. The Application Builder command MIGRATEDB can be used to disable or enable the MIGRATEDB feature for a specific application (the default is enabled). (Refer to MIGRATEDB in ClearPath MCP Application Builder Commands).
Note: If you are not using the default compilers for DMALGOL or DASDL with your application build, or your Runtime Transfer deployment (transfer), you must put the DMALGOL compiler and the DMSII software that you are using under a usercode that is accessible to the application build or transfer. Then, enter this usercode in the DMSII Usercode segment configuration property, for the configuration that you use to build the application or configure the transferred application. Also, enter the pack on which the software is located in the DMSII Pack segment configuration property, for the configuration that you use to build the application or configure the transferred application. This is essential for MigrateDB to work when builds and transfers do not use the default DMSII software or DMALGOL compiler.