Close im RPG

[mkasmika]

Hallo Forum,

ich verstehe die AS/400 nicht mehr .

In einer Anwendung erstelle ich eine Datei in der QTEMP.
Daraufhin erfolgt der
eval Var_Command = 'OVRDBF FILE(USPL1P) '
'TOFILE(QTEMP/USPL1P) '
'OVRSCOPE(*JOB) '
Anscließend der Open

Das Programm läuft und die Daten werden in die Datei
in der QTEMP geschrieben.
Zum Schluss Programms kommt der Close.
Der Close verursacht folgende Fehlermeldung

Zeiger für angegebene Position nicht gesetzt.
Interner Fehler im Umwandlungsprogramm oder in einer Unterroutine.
Anwendungsfehler. RNX9998 nicht überwacht durch SP100R bei Anweisung *N,
Instruktion X'0000'.

Daraufhin habe ich das Close Statement ausgesternt.
da nur noch der SETON LR erfolgt. Es erfolgt aber die gleiche Fehlermeldung.

Habe ich etwa eine Macke des OS400 getroffen ?

Hat jemand etwas ähnliches erlebt ?

Das komische ist, das die Anwendung unt V4R4 einwandfrei
funktioniert und der Fehler bei einem V5R1 auftritt.

Gruss an alle Michael

[Fuerchau]

Close ist nur nötig bei Dateien mit USROPN (bzw. UC bei RPGIV).

Wie wird die Datei erstellt ?
Werden auch tatsächlich per WRITE Daten ausgegeben ?

Vielleicht gab es einen Antworteintrag bei V4R4 in WRKRPYLE um diesen Fehler zu umgehen ?

[mkasmika]

Hallo Baldur,

es gibt keinen Eintrag in der Systemantwortliste.
Die Datei ist USROPN definiert.
Die Daten werden korrekt mit WRITE in die Datei geschrieben.

M.E. kann es eigentlich nicht am Close liegen, da der Fehler
auch aufrtitt wenn man keinen expliziten Close angibt.

Unter v4R4 sind auch keine Meldungen im Joblog die auf einen Fehler hindeuten.
Gruss Michael

Close ist nur nötig bei Dateien mit USROPN (bzw. UC bei RPGIV).

Wie wird die Datei erstellt ?
Werden auch tatsächlich per WRITE Daten ausgegeben ?

Vielleicht gab es einen Antworteintrag bei V4R4 in WRKRPYLE um diesen Fehler zu umgehen ?

[B.Hauser]

Hallo Michael,

sind alle PTFs installiert?

Wir hatten bei unseren Kunden teilweise auch solche unerklärlichen Abbrüche, z.B. bei einem einfachen CHAIN.
Gerade für die letzten beiden RPG-Release gab es massenhaft PTFs.

Ansonsten funktionniert UsrOpn und Close unter V5R1 ohne Probleme.

Birgitta

[mkasmika]

Hi Birgitta,

die Idee mit PTF's kam mir auch und ich habe im Operating
nachgefragt ob in letzter Zeit PTF's eingespielt wurden.
Das ist nicht der Fall.

Seltsamerweise muss ich noch dazu sagen das die Version
vom März 2004 mit der gleichen funktionsart ohne Probleme klappte.

Gruss Michael

[
QUOTE=B.Hauser]Hallo Michael,

sind alle PTFs installiert?

Wir hatten bei unseren Kunden teilweise auch solche unerklärlichen Abbrüche, z.B. bei einem einfachen CHAIN.
Gerade für die letzten beiden RPG-Release gab es massenhaft PTFs.

Ansonsten funktionniert UsrOpn und Close unter V5R1 ohne Probleme.

Birgitta[/QUOTE]

[mk]

die Idee mit PTF's kam mir auch und ich habe im Operating
nachgefragt ob in letzter Zeit PTF's eingespielt wurden.
Das ist nicht der Fall.

Seltsamerweise muss ich noch dazu sagen das die Version
vom März 2004 mit der gleichen funktionsart ohne Probleme klappte.

Gruss Michael

[
QUOTE=B.Hauser]Hallo Michael,

sind alle PTFs installiert?

Wir hatten bei unseren Kunden teilweise auch solche unerklärlichen Abbrüche, z.B. bei einem einfachen CHAIN.
Gerade für die letzten beiden RPG-Release gab es massenhaft PTFs.

Ansonsten funktionniert UsrOpn und Close unter V5R1 ohne Probleme.

Birgitta[/QUOTE][/QUOTE]

[mk]

Huch da waren die Finger wieder zu schnell.


Für alle die es interessiert kommt hier die Lösung:

in den RPG Programm wird mit Entry Parametern und
viel mit API's gearbeitet. Bei einer API wurde eine falsche
Empfangslänge( größer als die Empfänger Datenstruktur) angegeben. Die Daten werden korrekt von System übertragen.
Anscheinend arbeitet OS400 in der Version V5R1 aber intern
mit anderen Pointern als die V4R4 Version.
Dadurch kam es zu dem kuriosen Close Problem.


Danke an alle die sich mit dem Problem beschäftigt haben.

Gruss Michael

[Fuerchau]

Das kann ich so nicht stehen lassen !
Wenn bei API's die Parameter korrekt übergeben werden, kann es auch bei zukünftigen Releasen keine Probleme geben. Bei allen API's wird die Länge des verfügbaren Puffers angegeben, die natürlich nicht den tatsächlichen Puffer übersteigen darf.
Bei Ergänzungen in neuen Releasen werden die Daten dann halt abgeschnitten. Deshalb gibt es ja fast immer das Feld "Bytes-Avaliable", in dem die verfügbare Länge der Information abgelegt wird.

Das gleiche gilt auch für ENTRY-Parameter !
Die Schnittstellen zwischen rufendem und gerufenem Programm müssen immer übereinstimmen, da es sonst immer zu Pufferüberschreibungen kommen kann.

[mk]

Hallo Bladur,

ich wollte ja nur die Lösung posten.

Es ist mir klar, das wenn man alles richtig macht es auch funktioniert.
In diesem konkteten Fall war es aber so das in dem Feld für die Empfangslänge 1500 Bytes angegeben war. Die API Empfängerstruktur aber nur 1480 Stellen empfangen kann.
Das PGM ist auf V4R4 ohne Fehler kompiliert und funktionierte. Bei dem V5r1 kam der Close Fehler.
Nachdem ich die Empfängervariable für das API auf 1480 geändert habe funktioniert das Pgm ohne Probleme mit V5R1.
gruss Michael

[Fuerchau]

Was ich sagen wollte, ist genau das was eingetreten ist.
Wie kommt man dazu eine Länge von 1500 anzugeben wenn nur 1480 verfügbar sind ?

Ich hoffe dass du nicht noch mehr solche Programme hast, da nicht alle Fehler die daraus resultieren, zu Abstürzen führen.
Manchmal sucht man sich da nähmlich zu Tode, da eine Pufferüberschreibung ggf. nur zu unerklärlichen Daten bzw. Pgm-Ablauf führt.

Bestes Beispiel war da sogar mal Brain-XPPS. Im rufenden Programm war eine Struktur nur 1 Mal definiert (OCCURS), im gerufenen aber 2 Mal (die berühmten Filehandler).
Nun trat allerdings ganz selten ein ungeklärtes Phänomen auf, da das Upro nur selten auf die 2. Struktur zugriff bzw. bei den sog. Test-Chains in Struktur 2 niemals Daten vorkommen sollten und somit die Felder nicht verändert wurden.
Aber so 1 mal alle paar Wochen war dann halt doch mal ein Satz da und die im aufrufenden Prgramm nachfolgenden Daten wurden zerstört.
Um diesen Fehler zu finden brauchte ich 3,5 Jahre !!!

[mk]

Hallo Baldur,

3,5 Jahre habe ich zum Glück nicht benötigt.

Da allerdings die SW nicht von mir stammt, ist es manchmal
sehr mühsam die Fehler anderer zu finden.

Aber eigentlich kann man sich auf eines verlassen.
Die Maschine hat immer Recht.

Gruss Michael