30000 CPYF am Tag!?

[V_P]

Hallo zusammen,

ich habe folgendes Anliegen:

In unseren System laufen parallel ca. 300 Dauer-Jobs, welche insgesamt ca. 30 000 mal am Tag mit CPYF eine neue Teildatei (z.B. S12345) in der gleichen Datei ("Tagesdatei" z.B. D20050912) erstellen.

Die erstellten Teildateien werden weiterhin von andere 5 Jobs, welche auch permanent laufen, benutzt bzw. mit CPYF in den temporären Bereich kopiert. Vor CPYF wird eine *EXCL-Sperre der jeweiligen Teildatei mit ALCOBJ erzwungen. Erst dann wird kopiert. Am Ende wird die Teildatei mit DLCOBJ wieder frei gegeben.

Diese Programmen wurden noch vor "meiner Zeit" geschrieben. Also wurde ich gerne diesen Prozess ein weinig optimieren.

Denn aufgrund von *EXCL-Sperre stehen die Jobs öfters auf Status LCKW und die Verarbeitung dauert dementsprechend länger.

Meine Optimierungsidee ist, um LCKW-Situationen zu vermeiden, den ALCOBJ-Befehl zu deaktivieren.

Und jetzt die Frage:

Weiß vielleicht jemand, ob es zu Problemen kommen kann, wenn mehrere hunderte Jobs gleichzeitig auf eine und derselbe Datei (!aber auf unterschiedliche Teildateien!) mit CPYF zugreifen?

Vielen Dank im voraus

Gruß

Vladimir

[Fuerchau]

Das ist eigentlich überhaupt kein Problem.
Du musst halt nur sicherstellen, dass ggf. die gleiche Teildatei nicht mehrfach verarbeitet wird.
Der ALCOBJ erlaubt auch die Sperre einer Teildatei, es muss also nicht die gesamte Datei gesperrt werden. Vielleicht hilft dir das ja schon.

Übrigens:
Der CPYF macht ja auch nichts anderes, als die Daten zu lesen, wie jedes andere Programm auch. Und da greifen ja auch hunderte Job's gleichzeitig zu.

[V_P]

Erstmal Danke für die schnelle Antwort.

Ich habe gelesen dass beim CPYF eine *EXCL-Sperre auf TOFILE-Datei erfolgt.
D. h. dass unsere 300 Dauer-Jobs jedesmal beim Erstellen einer neuen Teildatei die gesamte "Tagesdatei" sperren.
Was mir Sorgen macht, ist das Verhalten der anderen 5 Jobs, welche die erstellten Teildateien mit CPYF in den temporären Bereich kopieren.
Es könnte doch sein, dass es mal ein CPYF aufgrund von Timeout fehlschlägt, oder?

[Fuerchau]

Der CPYF sperrt nur die Teildatei exclusiv wenn MBROPT(*REPLACE) angegeben ist (intern wird ein CLRPFM durchgefürt).
Macht man aber selber erst einen ADDPFM und einen CPYF MBROPT(*ADD), ist diese Sperre nicht erforderlich.

[V_P]

Sie haben recht.
Ich denke, das war die Ursache. In unseren Programmen steht bei allen CPYF - MBROPT(*REPLACE), obwohl die zu erstellende Teildatei auf keinem Fall existieren kann. (es wird vorher geprüft.)
Also werde ich es auf MBROPT(*ADD) ändern und ALCOBJ beim anderen CPYF rausnehmen. Dies sollte das Problem mit LCKW lösen.

Vielen Dank für die "Aufklärung"

[Fuerchau]

Vergess aber den ADDPFM nicht !

[V_P]

Ich habe es gerade ausprobiert. Es klappt auch ohne ADDPFM!
Oder verstehe ich was falsch!?

[Fuerchau]

Dann steht wohl CRTFILE(*YES) im Kommando.
Ich würde das aber trotzdem trennen. Wenn der ADDPFM (durch den CPYF) nämlich fehlschlägt, wird auch nichts kopiert.
Während des ADDPFM wird kurzfristig eine EXCL-Sperre benötigt.
Also lieber:
ADDPFM
MONMSG ...
CPYF ...
MONMSG ...

[V_P]

Also, ich konnte folgenden Befehl fehlerfrei ausführen:
====================================
CPYF FROMFILE(*LIBL/D20050909)
TOFILE(*LIBL/D20050912)
FROMMBR(S50000)
TOMBR(STEST1)
MBROPT(*ADD)
FROMRCD(1)
FMTOPT(*NOCHK)
====================================
Beide Dateien mit MAXMBRS(*NOMAX) sind vorhanden.
Die Teildatei STEST1 ist nicht vorhanden.

Ich verstehe nicht, wozu ich noch einen ADDPFM einfügen soll.
Denn wenn ADDPFM schon fehlschlägt, dann wird wohl darauf folgender CPYF mit aller größter Wahrscheinlichkeit auch auf die Nase fallen!?

[Fuerchau]

Das ist schon korrekt.
Die Frage ist eher die "Schönheit" eines Programmes.
Um unterschiedliche Fehler zu bearbeiten muss man halt etwas tiefer einsteigen.
CPYF liefert im Fehlerfall EINE Esc-Nachricht.
Per Diagnose-Nachricht VOR der der ESC-Nachricht kann ich dann entscheiden:
- Zieldatei/Teildatei nicht angelegt
- Keine Sperre erhalten
- Keine Daten kopiert
usw.

Drösele ich die Logik auf, habe ich zwar die gleiche Funktion, aber dokumentarischer:

RTVMBRD ... NBRCURRCD(&NBR)
IF (&NBR > 0) CMD(DO)
ADDPFM ...
MONMSG CPF.... CMD(GOTO FEHLADD)
CPYF ...
MONMSG CPF.... CMD(GOTO FEHLCPY)
ENDDO

Klar, mit CPYF /MONMSG CPF0000 kann ich das auch alles erledigen.

[V_P]

Jetzt verstehe ich was Sie meinen.

Es ist aber leider so, dass ich aufgrund von Performance-Probleme die Optimierung der Programme vorhabe.
Und d.h. je weniger Operationen/Zugriffe an physikalischen Dateien, desto performanter läuft das Programm. (Jeden neuen Zeilencode muss ich mal 30.000 pro Tag multiplizieren!)

Aber Sie haben natürlich recht, Ihre Logik wäre sicherer.

Nochmal Danke für die ausführliche Diskussion.

[Fuerchau]

Aus Performancegründen ist die Einzelschrittverarbeitung absolut zu vernachlässigen !
Du erledigst ja nur im Einzelnen, was der CPYF auch tut !
Der Aufruf eines CMD's aus dem CLP bewegt sich im Micro-Sekundenbereich, also unter 1 Millisekunde.
Ausserdem, wer sagt denn, dass der CPYF nicht intern auch ADDPFM aufruft ?
Es ist also unerheblich, wer diesen Befehl aufruft.
Und im Sinne von Optimieren hilft der RTVMBRD sicherlich mehr, da ein Member erst gar nicht erstellt wird, wenn nichts zum Kopieren da ist.