PDA

View Full Version : 30000 CPYF am Tag!?



Seiten : [1] 2

V_P
12-09-05, 16:08
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
12-09-05, 16:12
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
13-09-05, 09:47
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
13-09-05, 11:14
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
13-09-05, 12:17
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" :D

Fuerchau
13-09-05, 12:39
Vergess aber den ADDPFM nicht !

V_P
13-09-05, 12:43
Ich habe es gerade ausprobiert. Es klappt auch ohne ADDPFM!
Oder verstehe ich was falsch!?

Fuerchau
13-09-05, 16:23
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
14-09-05, 08:55
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!? :confused:

Fuerchau
14-09-05, 10:24
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.