View Full Version : CPYTOIMPF und MCH3402
Moin zusammen,
ein CPYTOIMPF (der schon ewig funktioniert) bringt folgenden Fehler:
665
gelöscht wurde (fehlt da noch )
aber auch, direkt im Anschluss:
664
(sorry für die Bilder, aber Text kann ich nicht kopieren)
Das die Ausgangsdatei weg war kann nicht sein, sie ist immer noch da.
Das sie gesperrt war ist extrem unwarscheinlich
Die Zieldatei war sicher NICHT da, der replace ist nur zur Sicherheit
Eine Zieldatei wurde nicht erstellt.
Der Ablauf erzeugt mehrere solcher Ausgaben, der CPYTOIMPF wird jedesmal submittet
Von 30 Dateien, aus diesem Lauf wurden 16 nicht erstellt.
Einer ne Idee?
Ich vermute ja wiedrmal so ein V7R5 Bug, das schlechteste release seit V2R3
danke
der ILEMax
Ich kenne aus der Vergangenheit nur, dass Dateioperationen mit QNTC und einer CCSID ungleich *HEX nie funktionierten, da QNTC keine CCSID kennt.
Klappt es denn ins normale IFS mit anschließendem CPY nach QNTC?
na ja, wenn ich einzelnde dieser Dateien, die nicht funktioniert haben manuell sende, geht es. Und im Ablauf sind ja auch einige Dateien übertragen worden.
Hm, dann mach mal zwischendurch einen DLYJOB 5;-).
Vielleicht ist V7R5 für Windows zu schnell:D.
holgerscherer
25-10-23, 02:32
Ich vermute ja wiedrmal so ein V7R5 Bug, das schlechteste release seit V2R3
das ist eine recht platte Ansage, die ich nicht nachvollziehen kann. Oder hast Du konkrete Beispiele?
Da der CPYFRMIMPF ein uraltes Programm mit temporären Strukturen ist: hast Du mal einen RCLSTG probiert und bist auf aktuellen PTF?
holgerscherer
25-10-23, 02:35
Der Ablauf erzeugt mehrere solcher Ausgaben, der CPYTOIMPF wird jedesmal submittet
Von 30 Dateien, aus diesem Lauf wurden 16 nicht erstellt.
Einer ne Idee?
das hatte ich übersehen - je nach Apparatur schlägt vielleicht eine Parallelisierung zu. Mach die CPYFRMIMPF seriell.
I.d.R. wird ein SBMJOB ja in eine sequentielle Queue/Subsystem (max. 1 Job) submitted, außer wenn man z.B. QCTL verwendet.
In der Jobq ist nur ein Job erlaubt.
Da der Basis- und der Ziel-Dateiname in jedem Job anders ist, darf auch ein parallellauf diesen Fehler nicht verursachen.
Das schlimme ist ja, das der Befehl in Summe sich Fehlerfrei zurück meldet obwohl er nichts gemacht hat.
Dann können wir erst reagieren wenn der Empfänger sich beschwert, das er keine Daten bekommen hat.
Wenn man sich die Meldung ansieht wird ja "CheckCredInternal..." aufgerufen.
Dies ist da wohl die Anmeldeprozedurt (Cred: Credential-Objekt für die Anmeldung), die fehlschlägt.
Das kann man aber prüfen, wenn man den, sonst unnötigen, MKDIR für den Pfad "/QNTC/Freigabe" noch mal aufruft.
Damit wird dann der Anmeldevorgang für den Jobuser noch mal wiederholt, was bei Wiederholung egal ist, aber wenn er fehlschlägt einen Hinweis bringt.
Schließlich sind IFS-Zugriffe ja nicht vererbbar. Es wird immer mit Jobuser und nicht Programm-Owner (adopted authority) zugegriffen.
Wenn das immer noch nicht hilft, kann man auch einen QSH-Befehl LS mit Ausgabe in eine Datei durchführen um die Verbindung zu prüfen. Alternativ klappt ggf. auch der neue SQL-Zugriff mit den IFS-Funktionen nach dem MKDIR.
Danke, aber nein! ich will da nicht hinterher programmieren. Natürlich kann man das 'irgendwie' umgehen, anschließend auf erfolg testen, nochmal machen, ....
Ich habe es abgegeben mit der Empfehlung IBM zu fragen.
@Holger
wir hatten und haben(teilweise) mit V7R5 massive Probleme rund um Zugriffe auf das /QNTC/
Die Samba Version verspringt nach reboot ab und an zurück auf 3, zugriffe werden abgelehnt, 10 Sekunden später funktionieren die, find, LS, netuse, und div. andere Befehle funktionieren mal, mal nicht. Einiges ist mit PTF behoben, einiges haben wir umgestellt. Viel unnötige Arbeit, wenn das Release hier nicht so schauerlich schlampig wäre.
der ILEMax