The perils of assuming DDL behaviour in one RDBMS translates to another

Here's the scenario:
Two tables in a DB2 database, SAP expecting a PK constraint to be on TABLEA but instead the constraint and associated index exists on TABLEB.
(The reason behind this is a story for another time).

Solution is simple, drop the constraint on TABLEB and create it on TABLEA.

The DB2 SQL to do this is straightforward and bears more than a passing resemblance to the Oracle equivalent, e.g.

ALTER TABLE SAP.TABLEB DROP CONSTRAINT "TABLEB~0"

ALTER TABLE SAP.TABLEA ADD CONSTRAINT "TABLEA~0" PRIMARY KEY (MANDT, ...)

After obtaining the appropriate approvals, our DB2 novice DBA was sent off to run the SQL and reported back that the DDL had completed successfully.

A quick check showed that the PK constraint did exist on TABLEA but the supporting index had a system generated name and the original constraint still existed on TABLEB.
The novice DB2 DBA had a lot of Oracle experience and had assumed that DB2 would automatically commit DDL.

DB2 does not implicitly commit DDL

At some point in the near future we will be rectifying the constraints on these tables but the immediate problem has been solved. Queries on TABLEA are using the PK index so users are at least happy.

PS:
Schema and table names have been changed to protect the innocent.