Remove the restriction on dropping a table in an explicitly created universal table space

We have converted most of the Segmented & Partitioned Tablespaces in our ERP Dev region to Universal Tablespaces. But, later started facing some issues due to the conversion as UTS are not supported by the ERP application. All the Table changes are done from ERP application. In that process, DB2 Tables are dropped & re-created. But, with UTS, Tablespace has to be dropped not the Table. ERP application doesn't handle that.

Getting the following error message when ERP application issues DROP TABLE statement on the Table in UTS.
Lookup Error - DB2 Database Error: ERROR [42917] [IBM][DB2] SQL0669N A system required index cannot be dropped explicitly.

So, we have to first make changes on application side and then make changes on DB2 side. This has become more time consuming and problematic.
And, another issue is, the Data migration tool we use right now can't migrate data from non-UTS to UTS and vice-versa. And, even the IBM DB2 Recovery Expert Tool we are going to use shortly doesn't support non-UTS to UTS and vice-versa data recovery.


So, we have to either convert all Tablespaces in QA & Prod also to UTS (which doesn't look suitable to us right now due to the DB2 restriction on Table dropping in UTS), or fallback to Segmented/Partitioned Tablespaces in Dev reion.
Unfortunately, there seems no simple and easy way to fall back, other than dropping & recreating all Tablespaces.

We cant go with Implicit Tablespaces, as we need Tables for long time.And, once the Table is dropped, all the image copy entries are deleted from SYSIBM.SYSCOPY (Image copy datasets will exist in Tape) as the Implicit Tablespace also will be dropped. This behavior is not at all suitable to us.
In our ERP setup, we do Data migration very frequently (2-3 times a week sometimes) for application testing. This involves unloading data from 3000+ Tables in Prod and load the same to multiple environments in Dev/QA regions. The tool we use for Data migration right now, generates the JCLs based on the details in SYSIBM.SYSCOPY Table. Even IBM DB2 Recovery Expert for z/OS tool (we'll be using this for Data Migrations) generates Object Recovery plans based on the details in SYSIBM.SYSCOPY Table. So, the data in SYSCOPY Table is very critical to our DBA activities.


If IBM can remove the restriction on dropping the Table in explicitly created UTS, we can continue with UTS. Right now, we are facing many issues after getting the Tablespaces converted to UTS in Dev region.