SQL/MX 3.2.1 Management Manual (H06.26+, J06.15+)

You can also use SHOWDDL to display information about DDL locks. An example SHOWDDL
output would include:
-- WARNING: A DDL lock exists on the following object, SHOWDDL
may be inaccurate
--
CREATE TABLE CAT.SCH.CUSTOMER
For more information, see the SQL/MX Reference Manual.
Performing Recovery on Failed Utility Operations
If the utility request fails to complete successfully, the request must be recovered to a known good
state (resumed or cancelled), which removes the DDL lock and resets all flags. Most utilities respond
to a request failure by invoking their own internal recovery procedure. If the utility’s internal recovery
procedure does not succeed, you must manually recover the utility request. For all utilities but
MODIFY, you perform a RECOVER operation on the affected SQL/MX object. For MODIFY, you
perform a RECOVER operation on the affected table or index if an inactive DDL lock is present
and perform a FUP RELOAD operation if the MODIFY request completes but its ORSERV process
does not complete and is not running. At the very least, a process with the same process ID stored
in the metadata exists. For more information, see “Recovering a Failed MODIFY Request and
Resetting Flags” (page 186). For more information, see the SQL/MX Reference Manual.
If a structure changing operation is attempted while an active or inactive DDL lock is present, error
1134 is returned:
1134 A concurrent utility or DDL operation is being performed on object object-name, its parent, or one of its
dependencies. That operation must complete before the requested operation can run.
For more information, see the SQL/MX Messages Manual.
If the DDL lock is active, you must wait until the utility operation completes before you can re-run
the original request. If the DDL lock is inactive, you must perform a RECOVER operation against
the table or index name specified in the 1134 error. If you attempt to perform a RECOVER operation
while the utility operation is still running, the RECOVER operation fails. Otherwise, RECOVER
completes and removes the inactive DDL lock.
If the RECOVER operation fails, you must identify and correct the cause for its failure. For example,
RECOVER might fail because of the unavailability of a system that contains a partition from the
table or index being acted on. You would have to wait until the remote system is available before
you could re-run RECOVER to cancel or resume the operation.
When the RECOVER operation has completed successfully, you can perform the other structure
changing operations.
If you attempt to drop or alter an object that a utility operation is using, error 1250 is returned:
1250 Operation cannot be performed on object object-name because a utility operation (operation-type) associated with
DDL_LOCK lock-name is currently running.
For more information, see the SQL/MX Messages Manual.
Structure Changing Operations That Can Run With Active or Inactive DDL Locks
Present
Structure changing operations are sometimes allowed to run even with active or inactive DDL locks
present. Examples include:
• Creating a view on a table with an active or inactive DDL lock
• Dropping a view on table with an active or inactive DDL lock
• Creating or dropping views on table that has dependent indexes with active or inactive locks
DDL Lock Considerations for MODIFY, import, POPULATE INDEX, DUP, FASTCOPY, and PURGEDATA 183