View Full Version : CPE3406 was ist das ?
Moin zusammen,
ein move in einem CLLE von einem IFS Objekt in eine /QNTC/Server/Freigabe/Pfad
löst ab und zu einen CPDB055 aus. Dieser verweist auf die Fehlernummer 3406.
CPE3406 besagt: Die Operation hätte dazu geführt, das der Prozeß ausgesetzt worden wäre.
Fehlerbeseitigung: Eine Recource ist vorübergehend nicht verfügbar. Den Vorgang zu einem späteren Zeitpunkt wiederholen.
Prozeß ausgesetzt ... was ist gemeint?
Da der Move in Schleife läuft und 1-n Dateien überträgt, ist es kaum denkbar das es ein 'Netzwerk' -Fehler ist.
Die Meldung kommt ab uns zu, bei einer (beliebigen) Datei.
Einer ne Idee was ich prüfen kann?
Danke
Robi
holgerscherer
20-11-24, 09:52
error code hat nix mit msgid zu tun.
fürs QNTC gibts einige PTF. ich vermute, Kiste ist auf 7.2? Dann wirds Zeit... ;-)
Nachtrag - dürfte ähnlich dem hier sein:
https://www.ibm.com/mysupport/s/defect/aCI3p0000008mQN/dt282024?language=en_US
Ach Holger ....
Lt. dem cpdb055 muß ich, um festzustellen wa der fehler ist, bei einem 4 Stelligen fehlercode
ein dspmsgd CPE + Fehlercode machen.
Das gib es öfter mal ...
Bisher nur selten so Cryptisch
V7R5M0
holgerscherer
22-11-24, 17:36
Ach Holger ....
Lt. dem cpdb055 muß ich, um festzustellen wa der fehler ist, bei einem 4 Stelligen fehlercode
ein dspmsgd CPE + Fehlercode machen.
Das gib es öfter mal ...
Bisher nur selten so Cryptisch
V7R5M0
QNTC ist der kryptische Code für den Ewigen Protokollkrieg zwischen Microsoft und denjenigen, die SMB interpretieren müssen... ich würde da die Finger von lassen.
Häufigste Ursache ist die Angabe einer CCSID peim Kopieren.
QNTC unterstützt keine CCSID, somit muss erst lokal ins IFS mit CCSID und dann per CPY binär ins QNTC übertragen werden.
ok, etwas ausfürlicher ....
Einige, seit ca 12 Jahren über alle Kisten mit alle Releasen laufende Pgmme
erzeugen seit 14.11. sporadisch o.a. Fehler wenn sie Daten im QNTC ablegen müssen.
Natürlich! wurde beim Hoster nix geändert. Weder HW noch SW seitig.
Einer der Prozesse ist entstanden, da die Programme teilweise im Nachpgm laufen und der (die) /QNTC Server ab und an nachts nicht erreichbar (geplant und ungeplant) waren.
Also haben wir die PC-Server-Pfad-Struktur automatisch im IFS nachgebildet.
Alle Prozesse legen ihre Daten im IFS ab.
Und (z.B.) ein Prozess versucht alle 15 Minuten die Dateien (PDF/Excel/TXT/XML/...) zu übertragen.
Das läuft (lief) immer stabil
Einen Zugriff der Sachbearbeiter über gemappte Laufwerk(e) auf das IFS gibt es nicht und soll es nicht geben. Ist so!
Beim Ablegen der Daten im QNTC bekommen wir nun sporadisch o.a. Fehler. Für 1-5 Dateien wärend die anderen Dateien fehlerfrei funktionieren. Beim Lauf 15 Minuten später werden die fehlerhaften dann (meistens) übertragen so das es definitiv nicht an der Datei an sich liegt.
Meine Vermutung geht in Richtung 'Wackelkontakt' im Kabel, Router, Switch, o.ä.
Ich hatte gehofft das die Meldung irgend einen Hinweis gibt.
Da ich mit HW nix am Hut habe, weis ich nicht wirklich wie wir da jetz herangehen können.
So, jetz noch einer ne Idee, ausser Power und QNTC ist eine doofe Kombination?
Danke
Nun ja, es gibt eben auch Wackelkontakte in der Software, ggf. parallele Zugriffe gleichzeitig auf das Ziel.
Gerne sind da auch Virenscanner im Spiel. Bitdefender ist da gerne ein Kandidat.
Hier könnte auch ein Auschluss des Verzeichnisses im Virenscanner erfolgen, wenn Clients nur lesend und nur der Copyjob schreibend zugreifen.
Wenn sich der Fehler aber automatisch behebt, würde ich das pragmatischer sehen:
Tritt der Fehler auf, die Wartezeit auf 1 Minute verkürzen.
Tritt kein Fehler auf, dann halt wieder 15 Minuten warten.
Nachtrag:
Da Virescanner häufig auf Dateiendungen reagieren kann man auch eine 2-Phasen-Copy erstellen:
1. Kopieren mit Endung "tempIBMi".
2. Rename in die korrekte Endung, da jetzt der Virenscanner erst die Wahrheit erfährt.
das ist z.Zt. der Ansatz.
Ich befürchte aber, wenn da was 'Wackelt', das es schlimmer und irgendwann ganz kaputt wird.
Dem ist entgegen zu wirken.
Die Art und Weise, wie welche Clients zugreifen, hat sich definitiv nicht geändert.
Vierenscanner weis ich nicht.
Parallele Zugriffe sicher mal. Aber nicht mehr oder anders als vorher.
mal sehen was die Lötkolben Informatiker feststellen.
Suchen nach CPE3406 findet EWOULDBLOCK und „recv() socket api“ als Hinweis. Es stehen vielleicht nicht sofort alle Daten der Datei auf Anhieb bereit!? Im Internet mit recv() ist sowas normal. Da muß man mehrmals nachfassen bis man alles hat.
Moin,
Es stehen vielleicht nicht sofort alle Daten der Datei auf Anhieb bereit!?
das kann ich nicht 100% beantworten.
Aber da es u.a. in einem 'einfachen' MOVE aus dem IFS ins /QNTC/Server/freigabe/Pfad/ vorkommt, denke ich nicht das da Daten fehlen.
Auch das andere Prozesse mit diesem Fehler ohne Änderung seit mehr als 12 Jahren laufen spricht m.e. dagegen.