Dezimaldatenfehler bei WRITE in RPGLE in Abhängigkeit des PTF-Standes

[Fuerchau]

Dezimalfehler können bei der Umwandlung als Option automatisch behoben werden.

Aber das Problem ist ggf. ein anderes:

Felder, die nicht angesprochen bzw. verwendet werden, sind im RPG/LE nicht definiert.
Beim WRITE, also hinzufügen von Daten erlaubt die DB aber keine ungültigen Informationen.
Hierzu muss man nochmal auf die Technik von RPG eingehen.
Eine Datei wird mit einem RPG-internen Puffer verwaltet.
Beim Lesen werden die Felder aus dem Puffer gefüllt, beim Schreiben werden die Felder in den Puffer übertragen.
Felder die also nicht referiert werden können somit auch nicht in den Puffer übertragen werden und sind deshalb vom Inhalt undefiniert.

Je nach PTF kann es natürlich nun zu Abweichungen kommen.

Bei einer DDS-beschriebenen Datei waren unerlaubte Daten möglich.
Dieses Problem ist wohl mit dem neuen Stand endgültig behoben.
Siehe hierzu auch Hinweise von Birgitta:
Aus Performancegründen erfolgt eine Validierung der Daten beim WRITE, so dass beim READ keine Prüfung mehr erfolgen muss.
Dies galt bisher für SQL-Tabellen, nun wohl auch für DDS-Dateien.

Lösung:
Definiere eine DS, die alle Felder des Formates enthält:
D DateiDS E DS
Die Felder werden automatisch korrekt initialisiert.

[rr2001]

ist auch die Datenbank auf beiden Systemen ident,
oder stimmt vielleicht die Datei, in welche geschrieben wird,
nicht überein.

[Fuerchau]

@rr2001
Das würde bei DDS nur mit LVLCHK(*NO) funktionieren.

[langulli]

Die DB ist auf beiden Rechnern gleich.
Aber dies spielt m.E. nur eine untergeordnete Rolle, weil ich ja auf beiden Systemen das Programm vor dem Testen umgewandelt habe und nicht eines der Objekte genommen habe, um es auf die andere Maschine zu übertragen.

Aber wenn ich die erste Antwort von oben richtig verstanden habe, finde ich es schon einen Hammer von IBM, so etwas als Fehler zu sehen und diesen abzustellen. Einen WRITE in eine DDS-beschriebene Datei durchzuführen, wo nicht alle Felder explizit angesprochen werden, habe ich über Jahre hinweg immer wieder erfplgreich praktiziert. Was ich von Programmiererkollegen so gehört habe, scheint dies gar nicht so ungewöhnlich zu sein.

[Fuerchau]

Das stimmt ja auch.
Allerdings ist ja nun mal die SQL-Ebene noch darunter (DB2/400).
Und wenn ich neue Daten erstelle und vor allem Dezimalfelder nicht korrekt initialisiere, gabs ja später beim Lesen Dezimalfehler (es sei denn, die Felder wurden auch beim Lesen nicht referiert), die ich bei der Umwandlung mit "Dezimalfehler korrigieren" ignorieren konnte.

Sich darauf zu verlassen, dass langjährige Fehler immer bestehen bleiben, ist meines Erachtens der falsche Weg.

Die Alternative ist eben SQL.
Da kann ich beim Insert nicht benötigte Felder weglassen, wenn diese einen Default haben, NULL erlauben oder per Trigger gefüllt werden.