Was passiert mit offenen Dateien in Serviceprogrammen?

[dschroeder]

Hallo,
ich bin auf ein Serviceprogramm gestoßen, in dem der Programmierer Dateien mit F-Bestimmungen im Main-Teil des Programms deklariert hat. Die Dateien haben nicht das usropn - Schlüsselwort.

Beim Kompilieren gibt der Compiler eine Warnung aus, dass die Dateien beim Programmende nicht geschlossen werden. Soweit ist ja alles klar. Ich könnte das ja einfach beheben, indem ich die Dateien usropn öffne und schließe.

Meine Frage ist aber: Was passiert eigentlich (bzw. was kann passieren), wenn ich das Programm so lasse und die Dateien nicht usropn öffne und schließe? Ist das für die Performance besser oder schlechter? Auf die Dateien wird immer mit einem Key zugegriffen, sodass es kein Initialisierungsproblem wegen des offen gebliebenen Programms geben kann.

[Fuerchau]

Theoretisch ist das unkritisch solange man an den ACTGRP's und LIBL nicht rumspielt.
Der 1. Open erfolgt automatisch und es bleibt bis zum Jobende auf.
Machst du aber z.B. einen RCLACTGRP wird die Datei vom System geschlossen.
Beim erneuten Aufruf des Serviceprogrammes bekommst du nun einen MCH36-Fehler (Speicherzugriff) da der Dateizeiger geschlossen wurde aber der Open nicht erneut durchlaufen wird.
Dies liegt daran, dass die Laufzeit ein internes Flag setzt, und den Open nicht wiederholt.
Ein USROPN hilft hier ebenso wenig, da der manuelle Open wiederum das interne Flag prüft und da dies ja noch gesetzt ist, den Open mit Fehler oder BZ = *on ablehnt.
Das ständige Open/CLose kann allerdings auch wesentlich zur Verlangsamung beitragen.

Aktuell bei einem anderen Kunden gibt es noch folgendes Problem:
Es wird eine LIBL per CHGLIBL gesetzt und anschließend diverse Programme aufgerufen. Dabei werden auch Dateien in Serviceprogrammen verwendet.
Nun wird nach erledigter Arbeit die LIBL wiederum mit CHGLIBL angepasst.
Nun arbeiten aber die Service-Programme mit den zuerst geöffneten Dateien weiter, da sie ja noch geöffnet sind.
Das Chaos ist vorprogrammiert.

D.h., dass man bestimmte Dinge dafür nun mal nicht machen kann.
Bei SQL wird dies ggf. noch gravierender, da man hier auf den realen Open nicht einwirken kann.
Aber vielleicht ist SQL da etwas intelligenter, da hier u.U. durch die LIBL oder besser Current Collection eben die korrekte Tabellen geöffnet werden und somit die Tabelle aus beiden Libs geöffnet ist.

Ein RCLACTGRP verbietet sich da nach meiner persönlichen Erfahrung.

[BenderD]

... dann wird die Datei bei Aktivierung des SRVPGMs automatisch geöffnet und bei der Deaktivierung geschlossen. Dabei ist es egal wodurch die ACTGRP endet (expliziter RCLACTGRP oder impliziter durch ACTGRP *NEW).
Wiederholter Open Close ist unkritisch, da ohnehin lazy close gemacht wird.
RCLACTGRP ist nur kritisch, wenn es noch Programme gibt, die den PROCPTR kennen, die fahren dann in den Wind, dem open close ist das egal, da ja bei erneuter Aktivierung wieder automatisch geöffnet wird.

D*B

[Fuerchau]

"Ein RCLACTGRP verbietet sich da nach meiner persönlichen Erfahrung."
Das hat sich jedenfalls bei mir so ergeben. Hier half tatsächlich nur ein Ab-/Anmelden.

LazyClose?
Den gibts doch nur bei SQL.

[BenderD]

"Ein RCLACTGRP verbietet sich da nach meiner persönlichen Erfahrung."
Das hat sich jedenfalls bei mir so ergeben. Hier half tatsächlich nur ein Ab-/Anmelden.

LazyClose?
Den gibts doch nur bei SQL.

Gesetzt den Fall PGM A hat ACTGRP HUGO und verwendet SRVPGM B, welches ACTGRP OTTO hat. Wenn ich jetzt RCLACTGRP OTTO mache, verweist PGM A weiterhin auf die alten Speicheradressen der Procedures von B, wenn A nun eine Procedure aus B aufruft, gibt es einen MCHCHK.

Für den lazy close will ich meine Hand nicht ins Feuer legen, ich habe seit gefühlt 100 Jahren kein RLA mehr verwendet. Kritisch ist das aber keinesfalls, da der ISAM open ohnehin billig ist. Teuer könnte allerdings bei sequentiellem lesen das überlesen von gelöschten Sätzen sein, dann hat man allerdings eh' ein logisches Problem bei close und reopen.

D*B

[dschroeder]

Vielen Dank für eure ausführlichen Antworten!

Dieter