SQL/MX 3.2 Management Manual (H06.25+, J06.14+)

must perform a RECOVER operation on the affected SQL/MX object to restore the utility operation
to a known good state.
Consequences of a Failed Utility Operation
If a failure, such as an unavailable resource or TMF failure, prevents a utility operation from
completing successfully, the utility responds by attempting to perform its own internal recovery
procedure for the purpose of completing the request or, if necessary, rolling back the operation to
the known good state from which it began.
The utility’s own recovery procedure can fail because of circumstances beyond its control. For
example, the utility’s recovery procedure might fail because TMF is down.
If the utility’s own recovery procedure is unable to complete or roll back the failed utility operation,
the utility operation returns an error. You can use this error information to isolate the cause for the
failure and ensure that it is corrected.
When the cause of the failure is fixed, you should perform a RECOVER command—or in the case
of some failed MODIFY operations, a FUP RELOAD command—to cancel or resume the utility
operation.
Using a Query to Obtain DDL Lock and Process ID Information
You can issue a query to read the metadata and generate a list of DDL locks on a given object or
set of objects. This query example retrieves information about the DDL locks and the MXCMP
process IDs associated with the catalog SAMDBCAT and the schema SALES:
set schema samdbcat.definition_schema_version_schema version>;
select substring (o.object_name from 1 for 15) as lock_name,
o.object_type as type,
l.operation,
l.status,
substring (l.process_id from 1 for 25) as process_id
from objects o, ddl_locks 1
where l.object_uid = o.object_uid and o.schema_uid =
(select schema_uid
from nonstop_sqlmx_<sys name>.system_schema.schemata
where schema_name = 'SALES' and cat_uid =
(select cat_uid
from nonstop_sqlmx_<sys name>.system_schema.catsys
where cat_name = 'SAMDCAT'
)
)
for read uncommitted access
order by l.object_uid;
PROCESS_ID
-----------------
STATUS
-----------
OPERATION
---------
TYPE
----
LOCK_NAME
---------------
\15.$:2:619:15659164IMLKCUSTOMER_LOCK
You can use the TACL command STATUS process-name to determine whether the process ID
returned by the query is running or is nor present. If the named process is running, the returned
lock information is for an active DDL lock. If the named process is not present, the returned lock
information is for an inactive DDL lock.
This and other information returned by the query can be used to determine whether you need to
perform a RECOVER or a FUP RELOAD operation on a MODIFY request. For more information,
see the “Using RECOVER or FUP RELOAD to Recover a Failed MODIFY Operation and Reset the
Flag” (page 185).
While a DDL lock is active, the utility operation that holds the lock is assumed to be running.
180 Reorganizing SQL/MX Tables and Maintaining Data