Add an Integrity Checker rule or fix to check and align MAXTABLE.STORAGEPARTITION with the CR configuration when inconsistencies are detected.

If MAXTABLE.STORAGEPARTITION contains an invalid or value that does not correspond to an actual tablespace in the environment, the script framework may attempt to create zx* tables in that invalid tablespace and fail with SQLCODE -204. This is common in customer environments converted from SQL Server to DB2 where the Maximo metadata was not fully aligned to DB2 tablespaces. The problem is reproducible whenever MAXTABLE.STORAGEPARTITION differs from what the CR configures as the environment’s actual tablespaces.

Request:

Please implement safeguards in the dbchange framework to avoid this failure class:

Validate that the storage partition name resolved from metadata maps to an existing tablespace before issuing any CREATE TABLE for zx* objects. If invalid, either default to the configured tablespace from CR (for example, MAXDATA for data and MAXINDEX for indexes) or fail fast with a clear diagnostic describing the corrective action.

Optionally, add a preflight check so that, before running scripts, MAXTABLE.STORAGEPARTITION values are verified against the current environment and CR, preventing runtime failures. Ensure inserts and zx* table creation use reliable, environment-aware tablespace targets rather than legacy or migrated values left in MAXTABLE.

Document this behavior and provide an integrity checker rule or auto-fix to validate that all tables are aligned with valid storage partitions and tablespaces, and that no invalid partition names are present.

Temporary workaround:

Normalize MAXTABLE.STORAGEPARTITION to the actual tablespace in the environment and that are reflected in the CR configuration.