CPYFRMIMPF und QNTC

[Fuerchau]

Prüfe mal, ob der CPYFRMIMPF auch tatsächlich von der Kopie und nicht weiterhin vom QNTC läuft.

Was der CPYFRMIMPF da so treibt weiß ich nicht (mit dem gibts wohl öfter Probleme), aber der Hauptgrund ist hier die CCSID. QNTC und damit eben die Windows-Server unterstützt keine CCSID. Hier liegt ggf. das Zeitproblem, da CPYFRMIMPF nun irgendwie eine Codewandlung erkennen muss.

Der COPY (oder CPY oder QHS CMD('cp ...')) kopiert einfach binär und das geht mit Leitungsgeschwindigkeit.
Der MKDIR hilft beim 1. Zugriff die langwierige Netzwerk-Suche zu umgehen.

[plinzen]

Also ich hab nun rausgefunden was da passiert ist.
Lag aber nicht an dem CPYFRMIMPF, sondern in einem anderen Programm von dem der CPYFRMIMPF aufgerufen wurde.
Grund war das in diesem anderen Programm ein CHGCURDIR auf die Netzfreigabe gemacht wurde. Und anscheinend wird wenn ich danach mit CPYFRMIMPF oder WRKLNK zugreife die ganze Domäne durchgescannt, weil das CURDIR eine Netzfreigabe ist. Die im Joblog ausgegebenen Meldungen (Sitzungsinitialisierungsfehler bei Netzwerk-Server NB-UBS-AW) kamen immer von PCs zurück, die im Moment nicht eingeschalten waren.

Vielen Dank für die Infos, jetzt müsste ich nur noch wissen, wie ich ein Verzeichnis auf Existenz prüfen kann?

[Fuerchau]

Nur eingeschränkt mit:
CHKOUT <= Objekt sperren
CHKIN <= Objekt wieder freigeben

Es gibt unterschiedliche CPF-Meldungen wenn das Objekt nicht da ist oder nicht gesperrt werden kann.