IBMDO YOU?Hi, I'm MBO!

Settings

Make the site feel at home on your screen.

Theme

Loading your theme preference.

Keyboard shortcuts

Open search from anywhere, then move through the results without leaving the keyboard.

Open settings
Ctrl,or⌘,
Open search
CtrlKor⌘K
Select a search result
↑↓
Open the selected result
Enter
Close an open dialog
Esc

I Build Maximo

UpdateDB: update the Maximo database from the SMP

Run UpdateDB from the Maximo SMP, understand its XML launcher, help and options, and add explicit support for spaces between options and values.

New application files. The database needs to catch up.

UpdateDB runs the database update process associated with installed Maximo application patches and product options. It is the step that brings database structures, data and version references into line with the installed application files.

IBM's database updates overview explains why the application and database versions must match and why MXServer can refuse to start when they differ.

Running the supplied launcher without arguments starts the update workflow. It is not a preview. Use the installation or upgrade procedure for your exact release, with a verified database backup and the matching application files available for recovery.

This guide is based on the supplied launchers, updatedb.xml, and inspected bytecode for MaximoScript, RunCommand, UpdateDB and MaxInstalling. Parser and launcher behaviour have been inspected; no database update has been executed for this article. No tested Maximo release is claimed.

Find the launcher

The supplied files live under:

maximo/tools/maximo/updatedb.bat
maximo/tools/maximo/updatedb.sh
maximo/tools/maximo/updatedb.xml

Start in tools/maximo. The shell wrapper locates its XML file relative to the script, but the framework also discovers the Maximo installation and loads dependent files. Keeping the expected working directory avoids relying on its fallback path discovery.

Unlike the older ConfigDB wrapper, this batch file does not invoke the database class directly. Both launchers run:

MaximoScript <path to updatedb.xml> <arguments>

The bootstrap loads psdi.tools.shell.RunCommand, which validates the XML-defined arguments and processes the script. The XML then invokes:

psdi.tools.UpdateDB

It also calls the common environment definition and, after the Java command, declares ReconfigSCTemplateQueryLinks, ExtractSCTemplateLabels and WriteReportProperties. Bypassing the XML with a hand-written direct Java command bypasses those declared steps too.

Help: use --help through this wrapper

On Windows:

cd C:\IBM\SMP\maximo\tools\maximo
updatedb.bat --help

On Linux:

cd /opt/IBM/SMP/maximo/tools/maximo
./updatedb.sh --help

These installation paths are examples. Use the actual SMP location.

--help is explicitly recognised by RunCommand.validateScript; it returns to help rendering instead of processing the update script. Bootstrap, environment construction and XML loading happen first, so this still needs a functioning installation.

The underlying UpdateDB.main also has a -h branch that exits with status 0 before setup and connection. That is a different parser layer. For the supplied XML wrapper, use its documented --help rather than assuming that Java's -h is accepted by the wrapper.

Options declared in updatedb.xml

The supplied XML declares the following value-taking options. These descriptions come from that definition; specialised database and upgrade settings must still follow your release's procedure.

Option Purpose in the supplied definition
-a<alias> Database alias; normally derived from mxe.db.url
-d<directory> Output log directory
-f<filename> Properties filename; normally maximo.properties
-k<directory> Properties directory; defaults to ${MAXIMO_HOME}/applications/maximo/properties
-o<filename> Output log filename
-p<password> Database password override
-u<username> Database username override
-n<directory> Input language/subdirectory selection; the definition describes en/script as the normal script location
-v<value> With 1, suppress the customer XML check message on the console
-r<value> With 1, notify DBManage that install mode is true
-s<tablespace> Index storage tablespace
-t<tablespace> Table storage tablespace
-m<multiple> VARCHAR length multiplier for specialised multilingual configurations
-w<directory> Extension-class output directory; defaults to ${MAXIMO_HOME}/applications/maximo/businessobjects/classes
-g<filename> Installation-collected parameters file; defaults to installation.properties

The XML also declares these switches without values:

Switch Purpose in the supplied definition
-y DB2: create columns normally using VARCHAR as VARGRAPHIC
-j Internal build mode, described as "no reset class"
-mt Run regular and multi-tenancy scripts for core and add-on products
-mtonly Run only multi-tenancy scripts for core and add-on products
-lite Run in lite mode

These are not interchangeable with similarly named flags in other tools. In particular, UpdateDB's -r takes a value and describes install mode; ConfigDB's -r requests restoration. The inspected UpdateDB Java implementation also differs from its XML description, as explained below. Do not copy options between launchers by letter alone.

The XML permits extra arguments under the label XMLFILE, but that label alone does not establish a safe single-script execution workflow. Use the documented update procedure rather than treating it as RunScriptFile's -f selector.

What does install mode actually do?

Install mode allows DBC scripts marked for_install_only="true" to run. Outside install mode, the supplied DBC runner skips them. Scripts without that attribute, or with it set to false, pass this check in either mode.

For example, this illustrative DBC opening element marks a script as installation-only:

<script author="Example" scriptname="EXAMPLE_INSTALL_DATA" for_install_only="true">

During a normal update, ScriptRun skips the script body and can log:

This script has data or changes for installation only. You are not running in install mode.

The skip returns normally; it is not itself an execution failure. In install mode, the script proceeds to its remaining checks and execution.

How install mode is selected

UpdateDB reads the BMXAA_INSTALLING marker from MAXVARS. A value of 1 enables install mode, which it passes to the DBC runner. On normal completion, it removes the marker from MAXVARS and MAXVARTYPE and commits the cleanup. Leave this lifecycle to the supported installation or recovery procedure.

Why -r1 does not enable it

The supplied XML describes -r as an install-mode option, but the Java implementation differs: its presence sets checkIfNeeded = true for the preprocessor's update-needed check. It does not set install mode or inspect the attached value, so -r0 selects the same check path. Use the matching preprocessor workflow when required by your installation procedure.

Choosing the other options

Properties, connection and logs

Use -k for the properties directory and -f for the filename within that configuration. -g selects the installation-collected parameters file; it is a different input from maximo.properties. -a, -u and -p provide connection overrides. Check these together so that the update files and target database belong to the same environment. Prefer configured credentials over command-line passwords that can appear in history or process listings.

-d and -o make the output directory and filename explicit. For example, from tools/maximo:

./updatedb.sh -d/tmp/maximo-update -oreviewed-update.log

Create a writable directory first and retain the logs outside an ephemeral container. This example executes the normal update workflow; selecting a log file does not change the work performed.

Table spaces and character storage

-t selects table storage and -s selects index storage. Use table-space names defined for the target database and required by the installation plan; the options do not provision database storage for you.

The DB2 -y switch changes the described character-storage choice from VARCHAR to VARGRAPHIC. -m supplies the specialised VARCHAR length multiplier. These change storage/type assumptions, rather than simply selecting a display language. Do not add them to an existing environment merely because it contains multilingual data; follow the database and language configuration chosen for that installation.

-n selects the input language/subdirectory. It is not a general-purpose path to an arbitrary DBC file, nor does selecting that directory replace the rest of the product update process.

Customer extensions and class output

-v1 sets silentCustXML. It suppresses selected customer-XML console messaging; it does not disable the update, skip all customer-extension processing or make the entire command quiet. Values other than exact 1 do not enable that field in the inspected setup branch.

-w chooses the extension-class output directory. This matters because the workflow can update class files as well as database contents: ensure the intended application tree is available and writable under the installation procedure.

-j sets resetClassOff. The inspected resetClasses method then returns early with a message that resetting maxobject/maxattribute/services is turned off. It is an internal build control, not a general fix for extension-class errors.

Lite mode and multi-tenancy

-lite changes which work is performed. In the inspected class it bypasses class-file updates in UpdateClassFile, skips guarded RMI compilation calls and skips the updateDM call in the main path. It does not mean "preview", "less logging" or "the same update, faster". Use it only as part of the installation or staged upgrade process that expects those omissions.

-mt selects regular scripts followed by multi-tenancy scripts; -mtonly selects only multi-tenancy scripts. The Java setup messages explicitly say not to combine them. They select a script population, not an organisation or site within an ordinary Maximo database. Use the mode required by the installed product and database configuration.

These findings describe the supplied classes, not a tested compatibility guarantee across releases. Check your installed XML and implementation when their descriptions differ.

Attached values and parser layers

RunCommand.validateScript takes the value from the remainder of a single-dash argument. It does not consume the next shell word as that value:

Use:    -oreviewed-update.log
Avoid:  -o reviewed-update.log

The underlying Java parser normally splits arguments after two characters, with explicit exceptions for its multi-character upgrade switches. It lowercases option keys before storing them in its parameter map. The wrapper has its own XML validation before Java sees those arguments, so do not assume every option recognised by Java is exposed by updatedb.xml.

For example, Java recognises system-up/system-down variants, while this SMP provides separate updatedbsystemup and updatedbsystemdown launchers and definitions. Those belong to the relevant staged upgrade procedure. They are not general ways to skip an application shutdown.

Run the update

Confirm the configured database and installed patch/product files, then establish the maintenance conditions required by your installation procedure. The inspected normal Java path checks whether MXServer is running and can refuse to proceed. Separate staged-upgrade paths have different checks; their existence does not make an ordinary update safe against an active application.

From tools/maximo, on Windows:

updatedb.bat

On Linux:

./updatedb.sh

Use the supported administrative or update environment for a Manage deployment. A general application pod need not contain the complete toolset, matching update files or writable output directories.

The shell wrapper already forwards arguments using quoted "$@"; the batch wrapper forwards %*. Both default to the bundled Java executable under tools/java/jre/bin and allow MAXIMO_JAVA to select another executable. Preserve the supported Java version for the installed Maximo release.

Accept spaces between options and values

The generated wrapper says not to edit it. Keep it unchanged and put the maximo-spaced-args.sh adapter beside a separate Bash wrapper named updatedb-spaced.sh in tools/maximo:

#!/usr/bin/env bash
 
SCRIPT_DIR=$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd) || exit 1
source "$SCRIPT_DIR/maximo-spaced-args.sh" || exit "$?"
maximo_normalize_args '-a -d -f -k -o -p -u -n -v -r -s -t -m -w -g' "$@" || exit "$?"
set -- "${MAXIMO_NORMALIZED_ARGS[@]}"
 
cd -- "$SCRIPT_DIR" || exit 1
exec sh ./updatedb.sh "$@"

This explicitly names the value-taking arguments from updatedb.xml; no auto mode is needed. --help, -y, -j, -mt, -mtonly and -lite pass through unchanged. The exact-match list uses lowercase options. The helper does not validate whether a chosen update mode is appropriate.

Run the custom wrapper with Bash:

bash updatedb-spaced.sh --help
bash updatedb-spaced.sh -o reviewed-update.log

The second command executes the update workflow. It illustrates argument syntax, not a tested database run. Separate values become attached arguments; already-attached values still work. Missing, empty or dash-leading separate values are rejected by the helper. For a dash-leading value, attach it directly to its option.

The outer wrapper requires Bash arrays. Its exec sh runs the original POSIX shell launcher, which already preserves argument boundaries. Save both helper and custom wrapper with LF line endings. The custom wrapper changes into tools/maximo, so relative paths are interpreted from there.

Before running the actual update, temporarily add these lines immediately after set --:

printf 'Argument: <%s>\n' "$@"
exit 0

Use harmless sample values to inspect the normalization without starting Java. Remove the diagnostic lines afterwards. Shell quoting preserves spaces as far as the original launcher; end-to-end handling of filenames containing spaces by this XML/Java workflow remains untested. Prefer simple output paths until verified in your environment.

The adapter guide provides its shell-level tests and explains the distinction between spaces separating options and values and spaces inside a filename.

Logs and completion checks

Keep the complete console output and update logs. IBM's Running UpdateDB procedure describes script locations and the database version update in MAXVARS after successful completion.

Log descriptions vary: that procedure refers to tools/maximo/logs/Update+Timestamp.log, while the supplied XML describes tools/maximo/log and even calls the default filename Maxinst plus a timestamp. Treat those labels as version-specific documentation, not proof of your actual output location. The inspected Java logger uses its configured output directory and filename; check the paths reported by your run, or select them explicitly with supported -d and -o arguments.

Verify the whole wrapper workflow, including any follow-up steps, rather than treating the last successful SQL statement as completion. Confirm that the expected product/database versions match and perform the application checks required by the upgrade procedure before returning the environment to use.

If a run fails, preserve its logs and identify the failing script and database error before retrying. Do not manually advance version markers to persuade the application to start. The inspected update path includes commits; a later failure or final connection rollback does not establish that all earlier work was undone.

I Build Maximo. The files and the database should agree on which one.

Find the fix

Search articles

Esc

Search titles, technical terms or error codes.