Missing "DROP PERIOD" possibility

Regular there is a request that we have to read certain data in a consistent state (e.g. likewise moving customer data from one DB2 environment to another) even while concurrent workload is still active and running in parallel against the same set of DB2 objects and tables. To read that data in consistent state we would want to use DB2 temporal feature ("AS OF").

To activate temporal feature we have to:
add three timestamp columns
add period
create history table
add versioning use history table

As we do have the request to read that data consistent frequently, but this only for a relative short period of time. One way would be to activating temporal feature permanently, but that not acceptable for us, because of its additional overhead in several areas, the main one is CPU, performance impact and space allocation. So it is clear that having temporal switched on occasionally is what we want and it is not an option for us to have the temporal functionality permanently switched on for these specific objects.

Therefore we want to activate the temporal feature, read the data with "AS OF" and then deactivate temporal feature again. As we need this only for a short time period there is the need to reset the object changes on these specific tables and undo the temporal feature.

To deactivate temporal feature we have to:
drop versioning - possible today
drop history table - possible today
drop period - not possible today
drop three timestamp columns - this is not not possible, because these columns have "PERIOD" dependency

All these changes have to be done with online schema and the data is concurrently in use.

In summary, all in this scenario works fine, but what is missing is the "DROP PERIOD" to support our business case.