A ConfigDB dry-run launcher for reviewing database changes

Show me the SQL before changing the database

The supplied ConfigDB launcher includes -l -e -r: log the configuration, execute SQL and request restoration. For reviewing a pending configuration, we can create a separate launcher that keeps -l and removes both -e and -r.

Use with care: this tool is not fully tested. Initial smoke testing on a disposable Maximo Manage 9.2.204 / DB2 11.5 instance generated the expected SQL without applying the tested changes, as checked in the application and directly against the database. It appears to work for those cases, but that does not establish the behaviour of every configuration change. Test it on a disposable environment with a recoverable database backup before relying on it.

The main ConfigDB guide covers normal execution and configuration requirements. This post focuses on the separate review launcher.

Why remove both flags?

CommonShell initialises execute to false. Its parser sets it to true when -e is present. The normal SQL helper logs statements when -l is enabled, then checks execute before executing them. The shared stored-procedure helpers also check that field.

Removing -e therefore gives those helpers a logging-only path. ConfigDB still connects, reads metadata and runs its configuration-generation logic; it does not simulate the schema changes or prove that the generated SQL will execute successfully.

-r needs to go too. It invokes RestoreFromBackup, whose inspected loadMaximoTable implementation includes a direct SQL execution and commit path outside the shared execution check. Leaving restoration enabled would undermine the purpose of this launcher if eligible unrestored tables already existed.

Removing both flags disables execution through the shared SQL helpers and excludes the automatic restore stage. These findings come from the supplied ConfigDB, CommonShell, RestoreFromBackup and TextSearch bytecode and are supported by the local test below. The test confirms the observed attribute-change behaviour; it does not establish that every configuration helper or external call is free of side effects.

Download the separate launcher

Download configdb-dry-run.sh and place it directly in tools/maximo, alongside configdb.sh and commonenv.sh:

maximo/tools/maximo/
  commonenv.sh
  configdb.sh
  configdb-dry-run.sh

The download follows the supplied POSIX shell launcher, including its argument capture, environment loading, JVM options and classpath. The Java command has just two built-in arguments removed:

- psdi.configure.ConfigDB -l -e -r -k../../applications/maximo/properties
+ psdi.configure.ConfigDB -l -k../../applications/maximo/properties

The header comments identify the review copy. The original launcher remains available for the normal apply procedure.

Run it like the supplied launcher

Start in tools/maximo, because the original wrapper's environment and Java paths depend on that directory. For example:

cd /opt/IBM/SMP/maximo/tools/maximo
sh configdb-dry-run.sh -h

This invokes ConfigDB's verified Java help path after the launcher's environment setup. Use -h, rather than --help.

For the first review run, create a writable output directory and use attached option values:

mkdir -p /tmp/configdb-review
sh configdb-dry-run.sh -d/tmp/configdb-review -opending-change.log

These are example installation and container paths. The launcher depends on the installed SMP classes, libraries, properties and Java runtime. Save the script with LF line endings.

Original argument handling still applies

This copy retains the supplied wrapper's argument handling rather than adding its own parser. Use attached values such as -d/tmp/configdb-review; separated forms such as -d /tmp/configdb-review are not converted. Its unquoted argument forwarding also retains the original limitations around filenames containing spaces.

Do not pass -e or -r, including attached variants such as -efalse or -rfalse. They are removed from the built-in command, but this wrapper still forwards caller-supplied arguments. It does not reject them. Keep specialised upgrade and text-search flags out of this initial experiment too.

The supplied dirname %0 environment-loading line is retained for comparison with the original. It relies on the expected working directory rather than reliably locating the script. If your installed launcher needs environment or runtime adjustments, apply the same established adjustments to this copy before testing.

Smoke testing

On 27 October 2026, the launcher was run against a disposable local Maximo Manage 9.2.204 instance using DB2 11.5, with two pending changes:

Increase ASSET.DESCRIPTION to 250 characters. Its Same As relationship to ITEM.DESCRIPTION propagated the pending length change to the related attributes.
Add ASSET.CBTEST. The generated SQL describes this new column as VARCHAR(50).

ConfigDB reported no-execute mode, then completed without errors:

BMXAA7495I - BMXAA7495I - ConfigDB is running in no-execute mode. Database updates will not be performed.
...
BMXAA6820I - ConfigDB completed without errors.

The generated log included the intended ASSET changes:

alter table asset alter column DESCRIPTION set data type  varchar (250)
;
alter table asset add cbtest varchar (50)
;

It also included the linked ITEM change:

alter table item alter column DESCRIPTION set data type  varchar (250)
;

The wider impact was visible too: the log proposed length changes for related columns across tables including AMCREWWOTL, CONTLINEASSET, CONTRACTLINE, INVOICELINE, LOCATIONS and WPITEM. It also proposed the DESCRIPTION change and CBTEST addition on A_ASSET. Reviewing the output therefore exposed more than the two edits initially made in Database Configuration.

After the run, checks in the application and directly at database level confirmed that the proposed changes had not been applied: the description length change was not applied to the physical database and the new CBTEST column was not created.

“Altering table” describes the proposed work

The console still printed messages such as Altering table ASSET, followed by metadata-refresh and index-rebuild messages. In this no-execute run, those progress messages accompanied SQL generation; they were not evidence that the statements had executed. The log likewise contained UPDATE and COMMIT statements as proposed output.

The no-execute message, generated SQL and independent application/database checks together support the result. A successful completion message alone would not establish it.

This test covers the reported length change, its Same As propagation and a new attribute on one disposable DB2-backed Manage instance. Other configuration types, Manage releases and database platforms have not been verified here.

I Build Maximo. First, I'd like to see what it plans to build.

Settings

Keyboard shortcuts