30000 CPYF am Tag!?

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