30000 CPYF am Tag!?

[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.

[V_P]

Ich denke, ich werde einfach die verschiedene Logiken in der Produktion ausprobieren und die Ergebnisse vergleichen.