Retain values in IBM i SQL Table Audit columns when copying rows using SQL INSERT or UPDATE

In V7R3M0, the option of new audit column types were added to tables. These are often, though not exclusively, being implemented for use in temporal tables.
An example of the audit column definitions in a CREATE TABLE for a non-temporal table statement:

CHG_MODE FOR COLUMN CHG_TYPE CHAR(1) CCSID 37
NOT NULL GENERATED ALWAYS AS ( DATA CHANGE OPERATION ),
CHG_CURRUSER FOR COLUMN CHG_USER VARCHAR(18) CCSID 37
NOT NULL GENERATED ALWAYS AS ( USER ) ,

An example of the audit column definitions in a CREATE TABLE for a temporal table statement:

START_TS TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,
END_TS TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,
TS_ID TIMESTAMP(12) GENERATED ALWAYS AS TRANSACTION START ID,

Columns using the GENERATED ALWAYS clause had existed prior to V7R3M0, for identity, rowid and row change timestamp.
If performing an INSERT/SELECT, OVERRIDING SYSTEM VALUE could be used to retain the original values for identity, rowed and row change timestamp, but this isn't possible for the new columns.

However, it is very important for us and our customers that we can retain the information when populating test environments or copying the existing records of a modified table to the new version of a table.

I realize that it is possible to retain the values by using CPYF, but we need to copy the data using INSERT/SELECT or UPDATE/SELECT due to the additional functionality found in SQL that isn't possible with CPYF.

In our case as a change and deployment management product, we generally don't have access to the end-customer's SQL script for creating or replacing a table, particularly in production environments where only the *FILE object is permitted to be deployed from their dev/test environments. This object is then replicated to n libraries in production.

During the replication, if a version of the table already exists, it is moved to a temporary backup library and the new format of the object is moved to the target library.
The columns in the old and new versions of the file are then inspected in order to build the INSERT statement in order to map/transform the existing data from the prior format of the file to the new format of the file.

We perform an SQL INSERT rather than a CPYF for 4 reasons:
1. To automatically handle type changes, such as from numeric to alphanumeric or vice-versa.
2. To allow customer-defined transformation of specific column data during the upgrade to the new version of the file
3. To perform test environment data replication across partitions using DRDA with automatic transformation/encryption of customer-identifying data during the INSERT so that such information is at no time resident on the test systems.
4. To allow for only a couple of seconds of downtime by:
a. ensure journaling is active on the live table or start journaling when not
b. use the INSERT to bring over the n million existing records
c. use INSERT, UPDATE or DELETE to map the transactions recorded in the journal since the initial insert occurred
d. build the indexes/views over the new format of the table
e. lock the original file and then perform the move using MOVOBJ. Since a MOVOBJ occurs, hours of downtime are reduced to a few seconds, but this wouldn't work with all of the column data manipulation using CPYF.