Ergänzend zu Birgitta sei noch folgendes hinzugefügt:
Wie auch von Dieter schon des öfteren erwähnt, verwende ich natürlich kein native IO, wenn ich eine Tabelle mit SQL erstelle. Somit erklärt sich die Diskrepanz zwischen Birgitta und mir:

Wenn ich die Tabelle mit ILERPG beschreibe, kann ich in das ID-Feld reinschreiben was ich will, es wird immer ein Satz mit der nächsten Nummer erstellt.
Also muss der Compiler an Hand der Tabelleninformationen ggf. das Id-Feld ausschließen oder SQL prüft bereits vor dem Write die Zulässigkeit der Verwendung dieses Feldes.
Sowas schließ dann z.B. einen einfachen Insert aus einer Struktur aus, ich muss grundsätzlich mit einer View ohne ID-Feld arbeiten auch wenn ich dann in die tatsächliche Tabelle einfüge (nur wegen der Tipparbeit).

Nun komme ich aber in meinen Augen zu einem fatalen Fehler:
Birgitta erwähnte den CPYF mit FMTOPT(*MAP *DROP).
Auf diese Verwendung wäre ich gar nicht gekommen, da diese ja eigentlich nur bei abweichende Definitionen erforderlich ist.
Also habe ich dies ausprobiert und ich muss zugeben, es funktioniert.
Allerdings mit einer fatalen Auswirkung:
Die Datensätze aus der Quelle werden mit der ID der Quelle übertragen, es wird also keine ID aus dem Ziel neu vergeben.
Habe ich keinen Unique-Key definert (weil ich dachte, ALWAYS wäre ausreichend) erhalte ich nun Doppelte ID's. Mit einem Unique-Key kann ich die Daten aber nicht kopieren.

D.h., der CPYF kopiert auf einer tieferen Ebene die Daten als der Zugriff per RPG, da ja hier eine Nummer grundsätzlich vergeben wird.

Erst wenn ich mir tatsächlich eine View ohne das ID-Feld anlege und dann aus dieser View als Quelle ins Ziel mit *MAP/*DROP kopiere erhalte ich auch tatsächlich neue ID's.

Also ist trotz der Definition der ID als GENERATE ALWAYS nicht sichergestellt, dass es keine doppelten ID's gibt.

Von der Manipulation der ID mit Reset würde ich sowieso abraten.
Bei einer 32-Bit Ganzzahl bekomme ich bei ca. 58000 Sätzen täglich ca. 100 Jahre weit.
Bei einer 64-Bit Ganzzhal habe ich eine Reserve für die nächsten 100 Jahre von ca. 252 Billionen Sätze pro Tag. Da platzt ja eher die AS/400 als dass es einen Grund zum Rücksetzen der ID gibt. Auch nicht bei einem CLRPFM, denn wer weiß wo die ID schon in irgendeiner Form weitergegeben ist.