INFSR/PSSR

[Fuerchau]

Naja, LR heißt immer Return mit Deaktivierung.
"Getin" steht auch für Programmanfang, wenn man keine InputPrimary-Datei hat.
Das ist genauso, als wenn man das Programm mit LR=*OFF verlassen und sofort wieder aufgerufen hat.

In einer ILE-Umgebung kann es dann zu massiven Störungen kommen, wenn nicht abgefangene Fehler in einer Unterfunktion (also CALLP eigenes oder Serviceprogramm) verwendet wird.
Ein Aufräumen der Unterfunktionen (z.B. Close lokale Datei)findet nicht statt !!!!!

[Squall]

Ah vielen Dank für die Hilfe. Ich gehe davon aus das der Monitor auch dem ILE-Condition Handler vorzuziehen ist?

Und nochmal zu meiner "konkreteren Frage" wenn er dann wieder zu dem Open springt müsste er die Datei, die ind er Fehlerbehandlung geschlossen wurde, doch wieder öffnen und normal weiterarbeiten, wenn ich alles korrekt verstanden habe, und nicht nocheinmal den Fehler bringen.(was eine Endlosschleifen auslösen würde, die anscheinend egal ob ich *CANCL oder *GETIN[mit close der Datei] bei der Fehlerbehandlung angebe, auftritt. Daher auch meine Verständnissfrage zu den beiden.)

Ich werde es zwar jetzt auf euer anraten mit Monitor ausprobiern aber die Frage reizt mich noch, danke.

Gruß Martin

EDIT: Gibt es bei der Monitor Gruppe auch eine Möglichkeit des "*Getin"? Normalerweise wird ja einfach nach dem ENDMON einfach weitergemacht.

[Fuerchau]

Wenn du nicht mit "Fxxxx IP...", also Input Primary-Datei arbeitest ist *GETIN dein 1. Befehl in der Hauptprozedur.

Implizite Open werden nicht wiederholt, bei IP-Zyklus wird der nächste Satz gelesen.

[Squall]

Aber wie übergebe ich den bei einer Monitorgruppe, beim endmon (anstatt beim return bei infsr/pssr)?

Gruß Martin

[Fuerchau]

Tut mir leid, aber die Frage verstehe ich jetzt nicht.
Monitor/endmon ist wie eine ganz normale IF ELSE ENDIF zu sehen, du entscheidest selbst was du tust.

Du kannst ja auch folgendes kodieren:

do while 1=1
monitor;
read ....;
on-error ;
leave;
endmon;
enddo;

[Squall]

Nun zb bei einer *PSSR Routine kann ich am Ende beim return sagen "return '*GETIN*" damit er dort weitermacht wo er aufgehört hat. Geht das beim Monitor auch irgendwie? (Da der Monitor ja über mehrere Zeilen geht, zb. 1-5, und er nach der Behandlung dann bei, zb Zeile 10, weitermacht. Und ich will aber das er bei zb. Zeile 3 wo der Fehler auftrat weitermacht weil ich den Fehler schon korregiert habe.)

[Fuerchau]

Nun, auch wenn es unüblich ist, geht das mit GOTO und "LABEL TAG", oder, was ich auch schon mal mache:

do while 1=1;
monitor;
tuwas;
on-error *all;
if wiederholbar;
iter;
endif;
leave;
endmon;
leave;
enddo;


So ist das nun mal mit RPG.
In C++/Java fragt auch keiner danach, da sieht das denn so aus:

try {
tuwas;
} catch (Exception e) {
} finally {
};

Da habe ich noch nicht mal die Chance, in den Try-Block hineinzuspringen, deshalb gibts da gleich solche Wege:

int step = 0;
while (1) {
try {
switch (step) {
case 0:
mach 1;
step=1;
case 1:
mach 2;
step=2;
else;
mach ende;
leave;
} // end switch
} catch (exception e) {
if (reproduzierbar) {
step--;
} else {
throw e;
}
} // end catch
} // end while

[Squall]

Hm Goto/Tags wollte ich vermeiden aber das mit dem Leave sieht gut aus. Immer noch nicht eine Ideallösung aber ne bessere wirds wohl nicht geben.

Stimmt Java is in der Hinsicht auch nicht viel besser.

Gruß Martin

[Fuerchau]

Das lass nicht die Java-Fraktion hören.

Fehler gehören in den Bereich "Ausnahmen" und müssen eben gesondert behandelt, also aufgefangen werden.
Das Hauptproblem besteht eben in den Prozedur-Aufrufen !
Solange man noch klassisches RPG betrieb konnte man mit *PSSR ganz gut arbeiten. Zumal ja ein EXSR tatsächlich kein echter Unterprogramm-Aufruf ist sondern eine versteckter GOTO.
Das Programm merkt sich für jede BEGSR genau eine Rücksprung-Adresse. Der EXSR setzt die Adresse, der ENDSR führt den GOTO zu dieser Adresse aus. Ein vorzeitiger Return aus einer BEGSR ist nicht möglich.
Deshalb kommt es ja zu Programm-Endlosschleifen, wenn durch zufällige Rekursion der Rücksprung verändert wird.

EXSR R1 // Folge-Adresse merken in XR1

BEGSR R1
EXSR R2 // Folge-Adresse merken in XR2
ENDSR // GOTO XR1

BEGSR R2
EXSR R1 // Folge-Adresse merken in XR1 !!!!!
ENDSR // GOTO XR2

Durch tatsächliche Prozeduren ist das genauso zu sehen wie mit Programm-CALL's.

Wenn nun eine Ausnahme zum Aufruf der PSSR führt, kann diese auch in der untersten Stack-Ebene aufgetreten sein !
Da kann man meist nicht einfach die letzte Aktion wiederholen.

[Squall]

Nun ich habe die letzten 2 Jahre Java programmiert, sowohl in meiner Ausbildung als auch in 2 kleinen Projekten. Theoretischt gehöre, bzw gehörte(da ich jetzt erstmal nur RPG programmiere) ich auch mal zu der Fraktion. Ich programmiere lieber Java als RPG/CL/VARPG aber darüber habe ich ja nicht zu entscheiden. Ich versuch das Beste draus zu machen und die guten Seiten der i5 und der Programmierung darauf zu entdecken.

Ja mit Springen ist das immer soeine Sache. Darum will ich ja wenns geht Gotos vermeiden(exsr sind erstmal ausgenommen, um die komme ich nicht herum).

Gruß Martin

Das lass nicht die Java-Fraktion hören.

Fehler gehören in den Bereich "Ausnahmen" und müssen eben gesondert behandelt, also aufgefangen werden.
Das Hauptproblem besteht eben in den Prozedur-Aufrufen !
Solange man noch klassisches RPG betrieb konnte man mit *PSSR ganz gut arbeiten. Zumal ja ein EXSR tatsächlich kein echter Unterprogramm-Aufruf ist sondern eine versteckter GOTO.
Das Programm merkt sich für jede BEGSR genau eine Rücksprung-Adresse. Der EXSR setzt die Adresse, der ENDSR führt den GOTO zu dieser Adresse aus. Ein vorzeitiger Return aus einer BEGSR ist nicht möglich.
Deshalb kommt es ja zu Programm-Endlosschleifen, wenn durch zufällige Rekursion der Rücksprung verändert wird.

EXSR R1 // Folge-Adresse merken in XR1

BEGSR R1
EXSR R2 // Folge-Adresse merken in XR2
ENDSR // GOTO XR1

BEGSR R2
EXSR R1 // Folge-Adresse merken in XR1 !!!!!
ENDSR // GOTO XR2

Durch tatsächliche Prozeduren ist das genauso zu sehen wie mit Programm-CALL's.

Wenn nun eine Ausnahme zum Aufruf der PSSR führt, kann diese auch in der untersten Stack-Ebene aufgetreten sein !
Da kann man meist nicht einfach die letzte Aktion wiederholen.

[BenderD]

Hallo,

ein paara Anmerkungen von der Java Fraktion:

monitor entspricht ziemlich den try catch Blöcken, ist aber im Unterschied zu Java nicht erzwungen und wird vom Compiler nicht unterstützt.

wenn ich nix mache, saust der Fehler den Call stack hoch (analog zu throws), Unterschied ist wieder die fehlende Unterstützung des Compilers, man muss selber rausfieseln, was da hochgesaust kommen kann.

Condition Handler ist eine Möglichkeit hochgereichte Fehler zu packen, wenn man da einen schreibt, ist das immer noch besser als der des Systems (CPF...), aber halt noch kein Fehlerhandling. Da gilt ähnliches wie in Java, je kleiner der try Block, umso leichter ist das Fehlerhandling zu programmieren; je größer der Block, umso aufwändiger ist es erstmal zu ermitteln, was da eigentlich schief gegangen ist.

zum Java Teil des Threads: man kann natürlich nicht in einen try Block reinspringen und das ist auch gut so!!!

zum RPG Teil des Threads: EXSR und Co sind völlig überflüssig!!! Prozeduren können alles, was man da können muss und sind rundherum überlegen und Vorteilhaft (Lesbarkeit, lokale Variablen etc...)

Dieter Bender,
der entsetzt ist, dass 60 Jahre nach der Erfindung der Lochkarte immer noch Leute auf die Idee kommen mit goto zu programmieren.

Nun ich habe die letzten 2 Jahre Java programmiert, sowohl in meiner Ausbildung als auch in 2 kleinen Projekten. Theoretischt gehöre, bzw gehörte(da ich jetzt erstmal nur RPG programmiere) ich auch mal zu der Fraktion. Ich programmiere lieber Java als RPG/CL/VARPG aber darüber habe ich ja nicht zu entscheiden. Ich versuch das Beste draus zu machen und die guten Seiten der i5 und der Programmierung darauf zu entdecken.

Ja mit Springen ist das immer soeine Sache. Darum will ich ja wenns geht Gotos vermeiden(exsr sind erstmal ausgenommen, um die komme ich nicht herum).

Gruß Martin