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

[langulli]

Hallo,

ich habe ein RPGLE-Programm (HSL276) auf einer Test- und einer Produktiv- AS/400.
Betriebssystemstand:
Testmaschine: V5R4M5 L00
Produktivaschine: V5R4M0 L00
Die Version von o.g. Programm ist auf beiden Rechnern identisch.
Beim CRTBNDRPG sind die jeweiligen Parameter auf beiden Rechnern identisch.
Problem ist:
Das Programm bricht beim WRITE in eine Datei auf der Testmaschine ab ...
Ursache . . . . : RPG-Prozedur HSL276 in Programm MHK/HSL276 hat bei
Anweisung 23000022 einen Dezimaldatenfehler gefunden. Ein gepackter oder
gezonter Wert enthält keine gültigen numerischen Daten. Eine Ziffer und/oder
das Vorzeichen ist ungültig.
...
Was ich in diesem Programm nicht mache ist, die Felder der Datei ,
vor den eigentlichen Feldzuweisungen, zu initialisieren (CLEAR FORMAT ...).
Damit erscheint der Fehler (natürlich) nicht.
Bis jetzt war ich der Meinung, dass dies nicht notwendig ist. Die bisherigen Resultate haben mir recht gegeben:
Beim WRITE werden Felder einer Datei, die nicht explizit angesprochen werden, automatisch, gemäß dem jeweiligen Feldtyp initialisiert. Also mit 0 bei einem
gezonten/gepackten Feld.

Habe ich irgendetwas übersehen?
Das Problem zeigt sich erst seit auf der Testmaschine ein neueres BS (V5R4M5 L00) ist.

Vielen Dank im voraus.

[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.