Engineering Corner: New DMSII Enhancements in AB Suite 6.1

Agile Business Suite (AB Suite®) 6.1 includes a number of updates and enhancements to the DMSII database. Among them are new capabilities that help to minimize database reorganizations, add flexibility and scalability to the reorganization process, and increase the database’s overall scalability and flexibility.

Here’s how…

Minimizing Database Reorganizations

The DMSII MIGRATEDB feature allows you to add or delete DISJOINT data sets, as well as their spanning sets and subsets, without stopping the database for a reorganization. However, these additions or deletions must be the only changes to the database structures – if you add sets or subsets to an existing data set, the database must be reorganized.

By default, AB Suite 6.1 on MCP will automatically attempt to use MIGRATEDB for database changes whenever possible, with the following structure restrictions:

• Incompatible with RDB enabled
• Incompatible if the added or deleted data sets contain a link item or structure of a link item
• Incompatible for a build where DMSII XL is enabled for the first time

The deployment process uses the DMSII DASDL compiler output to determine the validity of the DMSII MIGRATEDB option. If the DASDL says it is not appropriate, the deployment will continue without MIGRATEDB.

A Build Preview output summary will indicate whether MIGRATEDB will be used for the deployment. If the deployment proceeds with MIGRATEDB, two additional status messages will appear:

• “MIGRATEDB will be used to apply these changes”
• “MIGRATEDB in progress Job = <job number>”

Though MIGRATEDB is enabled by default, you may disable it on the Application Builder server using the command “MIGRATEDB+/-.”

Database Reorganization Scalability and Flexibility

A single DMSII Reorganization can touch a maximum of 300 structures, which includes any actual structure changes, as well as any implicitly included “fixups,” such as the reorganization of associated sets/subsets in a changed data set.

For a large AB Suite application the limits of a single DMSII reorganization may be an issue when a change is made to an attribute and many persistent attributes inherit the change. Fortunately, AB Suite 6.1 on MCP provides automatic Staged Reorganizations, which support an almost unlimited number of user and “fixup” structure changes in a single deployment. The need for a Staged Reorganization is determined during the deployment process. If required, the process determines the number of stages needed to apply all changes and allocates the changes to those stages – while staying within the 290 structure changes per stage limit. The multiple reorganizations are managed by the deployment process. The application software is installed when the last reorganization completes. Note that a Build Preview will detail the scope and stages as appropriate.

If the Staged Reorganization feature is not desirable for a particular application, you can disable it from the Application Builder via the “WAITIFSTAGE+/-” command.

If a Staged Reorganization is required for the deployment, and the Reorganization Type selected is neither “Offline” nor “Offline No Post Dump” – or the “WAITIFSTAGE” command is enabled – then you’ll be prompted to confirm the Staged Reorganization.

It’s important to understand that the Staged Reorganization process cannot handle database changes that are simultaneously applied to most or all structures. For example, setting the segment configuration property Extended Edition to “True” will apply the “DMSII EXTENDED” option to all structures. This may result in DMSII implicitly reorganizing every data set and set/subset. If you’ve globally enabled the “EXTENDED” option, and the number of structures impacted by the change exceeds the Staged Reorganization threshold, the Build Preview summary will include an XE warning. Should you continue with an actual deployment, the same XE warning will be shown in the client log.

For more details, please refer to the Agile Business Suite Runtime for ClearPath MCP Administration Guide.

General Database Scalability and Flexibility Improvements

Aside from the Staged Reorganization feature, AB Suite 6.1 includes additional enhancements aimed at improving DMSII scalability and flexibility.

For instance:

• You can now specify a value up to 545,755,813,887 for the population of an Ispec or vanilla class, though there are some restrictions:
  • • The population of a Direct data set is limited to 268,435,455
  • • Data sets with populations exceeding 268,435,455 must be sectioned
  • • Sets and subsets whose populations exceed 268,435,455 must be sectioned
• Overlaygoal may now be specified to 8 decimal places
• The ResidentLimit, DumpStamp, and AddressCheck properties may now be specified as “<default>,” which means they will assume the DMSII default values

Please email us at ABSuite@unisys.com if you have any questions about these new capabilities or need help incorporating them into your environment.

Share this article: