View Full Version : IFSOPEN fehlercode -1
Hi Forum
Folgendes Problem
Ein Buchungsprogramm benutzt IFSOPEN(Pfad : Flag)
wird dieses Buchungsprogoamm in der 4. Programmebene
(RPG-Menu -> Subfile -> Pflegepgm -> Buchpgm )
aufgerufen, läuft es fehlerfrei
Wird es aus der 8. Programmebene
(RPG-Menu -> Subfile1 -> Pflegepgm1 -> Subfile2 ->Pflegepgm2 -> Subfile3 ->Pflegepgm3 ->Buchpgm )
aufgerufen geht es nur, wenn die Datei im IFS existiert.
Der create schlägt also fehl.
Da das Pflegepgm = Pflegepgm3 ist (also dasselbe) können untersch. parameter nicht die Ursache sein (auch mit DEBUG geprüft)
Die Fehlermeldung lautet :
"Der für das Argument angegebene Wert ist nicht korrekt"
Alles unter V5R2, alles ILE, ohne *DFTACTGRP PGMRelease = V5R1
Hat einer eine Idee ?
Danke
Robi
Hallo,
ohne Source kann man da nur raten. Ich tippe auf abweichende Parameter Deklarationen in dem Aufrufstack.
Dieter Bender
'Ich tippe auf abweichende Parameter Deklarationen in dem Aufrufstack.'
Was heist das ?
der aufruf erfolgt immer über das selbe PGM
--> der selbe parm
der einzige Unterschied (gem. DEBUG alle gleich !!)
ist die Programmebene.
Wie kann ich da etwas abweichend definieren ?
Bitte nochmal helfen
Danke
Robi
Hier ein bischen code
* --- open64 - Access-Modes ---
D O_READONLY S 10I 0 INZ(1)
D O_WRTONLY S 10I 0 INZ(2)
D O_READWRT S 10I 0 INZ(4)
* --- open64 - oflag-values ---
D O_CREATE S 10I 0 INZ(8)
D O_EXCL S 10I 0 INZ(16)
D O_CCSID S 10I 0 INZ(32)
D O_TRUNC S 10I 0 INZ(64)
* --- open64 - status-flags ---
D O_NONBLOCK S 10I 0 INZ(128)
D O_APPEND S 10I 0 INZ(256)
D O_CODEPAGE S 10I 0 INZ(8388608)
D O_TEXTDATA S 10I 0 INZ(16777216)
D O_INHERIT S 10I 0 INZ(134217728)
d xo_pfad s 512 inz
d p1ziel s like(xo_pfad) inz
...
C EVAL X0_PFAD = %TRIM(P1ZIEL) + X'00'
* --- *STMF ÖFFNEN
C EVAL OFLAG = O_READWRT + O_TEXTDATA
C EVAL ERR_ID = IFSOPEN(X0_PFAD : OFLAG )
C IF ERR_ID <=0
C EVAL OFLAG = O_CREATE + O_READWRT + O_TEXTDATA
C EVAL NEWFILE= 'J'
C EVAL ERR_ID = IFSOPEN(X0_PFAD : OFLAG )
C ENDIF
C IF ERR_ID < 0
* fehler
c endif
Hallo,
die entscheidende Frage ist zunächst wie der Prototyp von IFSOPEN aussieht, die Bastelei mit x'00' deutet darauf hin, dass nicht mit OPTION(*STRING) gearbeiet wird. Die zweite spannende Frage ist wo der Pfadname herkommt und wo die entsprechenden Variablen wirklich definiert sind; wenn die nämlich durchgereicht werden und nicht mit Prototyp und VALUE, also per reference gecallt wird, dann kann das im Callstack weiter oben sein.
Der Fehler sieht für mich so aus, dass mit dem Null Terminator was schief geht.
mfg
Dieter Bender
Ich glaube hier ist das Problem an Hand des Hinweises "das selbe Programm" aufzulösen !
Dies deutet für mich auf einen rekursiven Programmaufruf hin (in ILE ja hinzukriegen), so dass die Variablen doppelt verwendet werden.
Verlagere die IFS-Zugriffe in eine eigene Prozedur mit eigenen Variablen so dass eine Rekursion keine Probleme bereitet oder erst gar nicht eintritt. Der Aufruf aus Ebene 8 verwendet ggf. Felder der Ebene 4 (statische Variablen) bzw. wenn Ebene 8 verlassen wird, stimmen die erwarteten Inhalte der Ebene 4 nicht mehr.
Danke
@DBender
Das Coding ist irgentwo abgeschrieben (Internet) es wird schon mit * und Value options(*string) gearbeitet.
das mit dem Hex'00' war in dem Bsp. so
(endekennzeichnung des strings's)
@fuerchau
nein keine rekursion
ganz anderer menüeinstieg.
LÖSUNG (von einem Kollegen gefunden)
In dem 2. IFSOpen ,
wo der oFlag mit Create, readwrite und textdata gefüllt wurde zusätzlich die beiden *NOPASS Parameter Permission und Codepage mit 511 und 819 weggeben.
k.a. warum , aber nun geht's
Danke
Robi