CPE3406 was ist das ?

[Robi]

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]

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/defe...language=en_US

[Robi]

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]

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.

[Fuerchau]

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.

[Robi]

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

[Fuerchau]

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.

[Robi]

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.

[Pikachu]

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.

[Robi]

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.

[Fuerchau]

Nun ja, da die Daten übers Netz müssen, und dieser Vorgang schon eine Weile dauert, kann bei einem Zugriff der Inhalt durchaus nicht komplett sein, da die Übertragung ja noch läuft.
Gerade PDF's oder XLS/X können schon mal größer sein.
Wenn dann z.B. der Virenscanner zugreift, könnte eine kurzfristige Sperre auf der Datei gesetzt werden, da sie ja bei Virenbefall nicht geöffnet werden darf.
Andererseits läuft aber die Übertragung noch und kann dann plötzlich nicht mehr schreiben.

Auch ein User kann per Zufall eine XLS/PDF öffnen, die dann unvollständig ist.
Daher speichern ja Programme wie Office Dateien erst mal mit einer temporären Endung und anschließender Umbenennung um diesen Konflikten aus dem Weg zu gehen.
Manchmal auch mit dem Hidden-Attribut, dass dann nach der Umbenennung entfernt wird.

Deshalb ja auch mein Vorschlag, das beim Copy auf QNTC ebenso zu machen.

Auch wenn ihr nichts geändert habt, kann es ja die Gegenseite tun.
Ein Sicherheitsupdate kann da schon mal reichen.

[Pikachu]

Vielleicht habt ihr das?

SE75750: OSP-WAIT-MSGCPDB055 Five minute wait in QNTC operation.

Occasionally, operations in the QNTC file system hang for
approximately five minutes. The operation will eventually end
with message MSGCPDB055 (Communication error on session to
network server). The error code is 3406. This only occurs when
using SMB2 or higher dialect.