The Database Management Utility (DMU) has the following functions:
Garbage Collection
Initiates Database Reorganization of selected DMS structures (Ispec datasets, and Profiles), with the ability to optionally select which Profile to use when ordering the structure.
This includes selected automatically created Database structures, which are structures included in your database to provide standard Agile Business Suite functionality; for example, ROC and Glb.Work storage structures.
Population Change
Changes the number of areas allocated to the whole Event datasets or selected Ispec datasets, and when necessary, automatically adjusts Profiles or Ordinate sets spanning the specified datasets.
This includes selected automatically created Database structures; ROC and Glb.Work storage structures.
DMS II Database Update
Initiates an automatic database software update through a DMU selection. This allows you to perform such tasks as upgrading DMS II software levels with no knowledge of DMS II.
Selecting a DMS II update makes no other changes; it only causes the required update processes to take place.
Making Optimizations with DMU
Within these facilities, DMU enables you to select of a number of DMS II reorganization optimizations that might improve the performance of your DMU processes.
DMU provides the option of extracting keys for a set or subset from the dataset, and sorting them for all sets and subsets created or changed in a DMU population change reorganization.
DMU provides the option for your reorganizations not to be audited.
DMU supports the use of offline reorganization and Reorgdb, rather than the default of online reorganization. Refer to Administering Application Builds and Reports for more information on offline reorganization.
When REORGDB is selected the user is requested, at the appropriate time, to respond to the waiting reorganization job with a <mix #> AX SWAP NOW to resume.
DMU garbage collection creates sets and subsets from their original set or subset, wherever possible.
If a database reorganization occurs as a result of the user’s changes then DMU compiles the associated database accessing utilities (DBInterface and DBILibrary) and so on.
If REORGDB is used, and the application is active, an implicit freeze of user input occurs when the user responds to the SWAP NOW request and an automatic hotswap occurs (to connect to the new DBInterface and DBILibrary) when the REORGDB processing completes.
Restrictions and Limitations of DMU
The following restrictions and limitations apply to DMU:
If population changes are entered, your Specification should also be updated to reflect the new EXPECTED.NO or MONTHLY.VOL values, then rebuilt; otherwise population changes made with DMU are lost.
Due to DMS II limitations, it is not possible to perform reordering on a structure that has just been added. Only when the database description has again been altered in any way and recompiled can a new DMS II structure be reordered during Garbage Collection. To resolve this, use the DMS II Database Update facility to perform an update on your database: this is sufficient to make a new structure available for reordering.
If your DMS II software is equated to different usecodes and packs, DMU will not detect this. DMU only checks the ACCESSROUTINES location and assume the other DMS II non-tailored programs are equated the same way.
For Model Systems, garbage collection is the only available DMU function. Model Systems cannot be independently reorganized or updated, as this could change the DMS II update level.
If you use a database as the base of a model database, you might only apply population changes or DMS version changes if all model databases are at the same DMS release level.
There is a limit of 3,855 Ispecs.