Leider ist die Dokumentation diesbezüglich unvollständig, daher kann ich nur berichten, was mir passiert ist.
Meine Definition GENERATED ALWAYS führt beim Insert halt dazu, dass dieser abgewiesen wird.
Die SQL-Meldung besagt eben auch, dass entweder die Spalte weggelassen oder OVERRIDING USER VALUES angegeben werden muss.
Der Sonderwert DEFAULT ist in diesem Zusammenhang auch nicht erklärt.
Ich kann allerdings einen externen Dienstleister nicht verklickern, dass er die Spalte einfach weglassen oder beim Insert DEFAULT angeben soll, da dieses (wieder mal) nicht standard ist.
Das Attribut HIDDEN würde dieses zwar lösen, wenn dieses Feld nicht existentiell für die Anwendung wäre.
OVERRIDING USER VALUES kann ich aber leider nicht bereits beim CREATE TABLE angeben, was mir am meisten Sinn geben würde.

GENERATED BY DEFAULT habe ich auch versucht. Beim Insert mit NULL gibt es ebenso einen Fehler, auch hier half nur weglassen.

Da du nun auf den Begriff "DEFAULT" beim Insert hinweist stellt sich mir die Frage, wie ich diesen
a) im ILE/RPG
b) beim CPYF
c) beim simplen "insert into ziel select * from quelle"
angebe.
Da ich die Daten auch mal retten und wieder zurückspielen musste konnte ich per
create table as select * from quelle
die Daten retten (wobei hier die Definition des Zieles an hand des Ergebnisses und nicht der Quelltabelle verwendet wurde).
Beim umgekehrten Weg "insert into ziel select * from quelle" bzw. beim CPYF handelte ich mir einen Fehler ein. Es half dann nur der Weg "insert into ziel overriding user values select * from quelle".

Ich lasse mich gerne überzeugen wenn du mir eine Lösung bringst, die folgende Bedingung erfüllt:

- sichtbare Identity-Spalte
- generate always (also unabhängig davon ob das Feld mit oder ohne Inhalt angegeben wurde)

so dass ich die Tabelle mit einem simplen SQL-Insert, CPYF oder ILE/RPG/COBOL-Write verwenden kann.
So wie es im Moment definiert ist, muss ich zuviele Klimmzüge machen damit der Wert funktioniert. Da ist der Trigger erheblich einfacher und schneller zu realisieren. Ins besonders, wenn dieser die doppelten Schlüssel bei Überlauf (falls überhaupt) selber behandeln kann und ggf. die Lücken füllt. SQL weist da ganz einfach per Fehler ab wenn ein Unique-Key oder Primary-Key definiert ist.

Hier das Handbuch V7R1:

If neither OVERRIDING SYSTEM VALUE nor OVERRIDING USER VALUE is
specified:
v A value cannot be specified for a ROWID, identity, or row change timestamp
column that is defined as GENERATED ALWAYS.
v A value can be specified for a ROWID, identity, or row change timestamp
column that is defined as GENERATED BY DEFAULT. If a value is specified
that value is assigned to the column. However, a value can be inserted into a
ROWID column defined BY DEFAULT only if the specified value is a valid
row ID value that was previously generated by DB2 for z/OS or DB2 for i.
When a value is inserted into an identity or row change timestamp column
defined BY DEFAULT, the database manager does not verify that the
specified value is a unique value for the column unless the identity or row
change timestamp column is the sole key in a unique constraint or unique
index. Without a unique constraint or unique index, the database manager
can guarantee unique values only among the set of system-generated values
as long as NO CYCLE is in effect.
If a value is not specified the database manager generates a new value.

von der Verwendung des Begriffes/Wertes "DEFAULT" ist hier nicht die Rede.