Fehlerausnahmeroutine *PSSR

[peter.kinne]

Hallo Hubert,

Deine Anmerkung ist berechtigt aber es muss trotzdem sein.

Unsere Dialogprogramme sind "SAA-Like". Also Auswahl 2=Ändern, 4=Löschen, 5=Anzeigen etc.

Es kann also sein, dass der User nicht die Berechtigung zu Ändern hat, aber 5=Anzeigen sei ihm gestattet :-)

Deshalb möchte ich nicht, dass das Programm aus der *PSSR beendet wird, sondern dahin springt, wo die *PSSR angesprungen ist.

Gruß am "heiligen" Sonntag,

Peter

[Fuerchau]

Das hilft dir bei der Verarbeitung leider überhaupt nicht !

Die Dateien werden implizit von RPG in der benötigten Verwendungsart geöffnet (Input, Input/Output, usw.).

Fehlt nun eine Berechtigung, so kann kein Open durchgeführt werden, d.h., selbst wenn READ erlaubt ist und UPDATE nicht, kann die Datei von diesem Programm nicht geöffnet werden, wenn beide Befehle verwendet werden.

D.h., wenn du also die *PSSR mit ENDSR *DETC beendest, kommt halt die CPF5134, da die Datei ja nicht korrekt geöffnet werden kann.

Einzige Lösung:

Trennung der Funktionen in separate RPG-Programme für READ,CHAIN/UPDAT/WRITE/DELET. Dabei ist aber darauf zu achten, dass die Dateien nicht mit SHARE(*YES) verarbeitet werden, da sonst der 1. Open der Datei für alle anderen Programme übernommen wird.

[BenderD]

Hallo,
wie ist es mit user controlled open und abfangen, wenn dieser schief geht und anschliessend zum Lesen öffnen? Zur Begrenzung des Änderungsaufwandes könnte man sows auch generieren.

mfg

Dieter Bender

[peter.kinne]

Hallo Herr Fuerchau,

so wie Sie es schreiben kann ich es in meinen Programmen nicht nachvollziehen.

Die Datei wird im Programm im Modus Update/Add eröffnet.

Wenn ich dann als User OHNE Rechte das Programm starte kann ich mir mit "5" alles ansehen, so oft ich möchte. Und bei "2" kommt beim ersten mal das richtige "Fehlerfenster" von mir. Nur beim zweiten mal "2" kommt der blöde Fehler. Zur Zeit beende ich das Programm über die *PSSR, was ich aber sehr unschön finde.

Gruß

Peter Kinne

[B.Hauser]

Hallo Peter,

wenn Du alle Aktionen im gleichen Programm handelst, hast Du mit der *PSSR-Routine wenig Chancen.

Bei ENDSR gibt es zwar noch andere Aktionen, aber mit denen wirst Du auch nicht weiter kommen:
*DETL: Continue at the beginning of detail lines.
*GETIN :Continue at the get input record routine.
*TOTC:Continue at the beginning of total calculations.
*TOTL:Continue at the beginning of total lines.
*OFL: Continue at the beginning of overflow lines.
*DETC:Continue at the beginning of detail calculations.

Du wirst Dich wohl mit dem Gedanken an einen ILE Condition Handler anfreunden müssen.

Siehe:

Forget To Handle Errors? Use an ILE Condition Handler

Birgitta

[peter.kinne]

Hallo Birgitta,

ich habe mich bereits letze Woche mit den Condition Handler beschäftigt, als Du es das erste Mal angesprochen hast.

Ich habe auch bereits Testprogramme geschrieben. Jedoch ist es auch hier ziemlich aufwendig, die Benutzerprogramme zu registrieren. Meiner Meinung nach ist es viel mehr Tipparbeit. Aber wenn es ohne nicht geht, bleibt mir wohl keine Alternative.

Gruß und schönen Tag,

Peter

[Fuerchau]

RPG prüft intern diverse Stati. Wenn also ein UPDAT/WRITE fehlschlägt, und die Datei im IO-Modus geöffnet sein sollte, geht die RPG-Runtime von einem Dateifehler aus und setzt den internen Status auf undefiniert.

Lösung: nach einem solchen Fehler die Datei einfach schliessen und neu Öffnen (UC in den F-Bestimmungen).

Begründung: Die RPG-Runtime geht davon aus, dass Dateien so verarbeitet werden können wie es in den F-Bestimmungen zugelassen wird.

Auch der ILE-Condition-Handler hilft da nicht weiter und funktioniert natürlich nur auf ILE-Programmen und nicht auf OPM.

[Thimi]

Hallo Peter,

>Deine Anmerkung ist berechtigt aber es muss trotzdem sein.

>Unsere Dialogprogramme sind "SAA-Like". Also Auswahl >2=Ändern, 4=Löschen, 5=Anzeigen etc.

>Es kann also sein, dass der User nicht die Berechtigung zu >Ändern hat, aber 5=Anzeigen sei ihm gestattet :-)

warum prüfst Du nicht die Aktion (2,4,5) bevor Du Das Programm aufrufst???
oder habe ich das Problem nicht verstanden?
Gruss
Thierry

[peter.kinne]

Hallo Thimi,

wir haben das Problem nich nur bei "3" Programmen sondern bei hunderten. Und wer "faul" ist der ist "schlau". Also da Minimax-Prinzip anwenden. Minimaler Aufwand - Maximaler Erfolg. Ich habe keinen Bock alle Programme komplett zu überarbeiten. Bis ich damit fertig bin gibt es wahrscheinlich Rel. 6 oder wir leben auf dem Mond :-)

Ich dachte an eine geschickte COPY-Strecke, die ich maschinell in die Programme schieße.

Gruß

Peter

[vkaelber]

Hallo Peter

Die einzige Lösung liegt darin, vor der User Contolled - Öffnung die Aktion zu prüfen. Je nach Aktion kann dann die Datei im jeweiligen Modus geöffnet werden.
Falls dann ein Fehler auftritt, musst du die Datei wieder schließen und danach die Fehlermeldung im Window ausgeben.
(s. a. vorhergehende Beiträge).
Ob du dies über die *PSSR oder über eine "normale" Routine bearbeitest, ist eigentlich zweitrangig.
Mach doch ein externes Programm, in dem du die aufzurufende Datei auf die Berechtigung prüfst (Übergabe der Werte aus der INFDS-Struktur and das Prüfprogramm).
In der Copystrecke kannst du ja dann abhandeln, was je nach Fall passieren soll.
Du musst den Aufruf allerdings für jede UPDATE-eröffnete Datei durchführen, am besten in der Startroutine.
Versuch' s mal
Gruß
Volker

[Fuerchau]

@vkaelber
RPG erlaubt keine variable Öffnung von Dateien !!
Jede Datei wird in dem Modus geöffnet, wie sie a) definiert ist I/O/U(A) bzw. verwendet wird.
Unterschiedliche Öffnungen bedeutet unterschiedliche logische Dateien mit unterschiedlichen Formatnamen.
Dies geht nur in COBOL, und da habe ich diese Probleme nicht, wenn ich mit "on error" o.ä, arbeite.

@peter
Leider geht das nicht einfach mit einer Copy-Strecke, und da du sowieso alle Programme anpacken musst, dann halt den schweren Weg:

a) "UC" in den F-Bestimmungen
b) OPEN in *INZSR
c) in *PSSR CLOSE/OPEN

Da RPG leider keine Variablen in Datei-/Format-Namen erlaubt heißt das hier: tippen, tippen, tippen .....