Spool bleibt in RMTOUTQ auf SND stehen.

[Flappes]

Hallo,

wir haben bei einem Kunden das Problem, das Spools in einer Remote-Outq auf SND stehen bleiben. Nach meheren Minuten läuft der Druck ohne zutun automatisch los.
Im Joblog des Druckjobs taucht die Meldung auf:
TCP342F - Verbindung wurde vom fernen Host-System unerwarteterweise beendet.
TCP3701 - Sendeanforderung für Spool-Datei XYZ ist fehlgeschlagen.

Hierbei handelt es sich um Etikettendrucker mit integrierter Netzwerkkarte.

Folgendes noch zur Information.
Früher wurde das Etikett, über eine Software eines Drittanbierters erstellt, und die erzeugte PRTF hatte den Typ *USERASCII
Nun wird die Spool direkt mit den Steuercodes des Drucker erzeugt, und an den Drucker gesendet. Mehrmals am Tag bleiben nun die Spools mit dieser Meldung stehen.
An den Parametern der OUTQ wurde nichts verändert.

Betriebssystem ist V7R2 mit CumTape 18032 und Hyper LVL 122

Hat hier jemand eine Idee ??

[Fuerchau]

Und nun ist der Spool nicht mehr *USERASCII?
Dann sollte ja auch ein anderes WSCST im Einsatz sein, dass zumindest die Codewandlung EBCDIC-ASCII durchführt.
Klappt der Druck denn überhaupt schon mal?
Vielleicht sendet die AS/400 zu schnell und der vorherige Druck ist noch nicht fertig?
Was Unterscheidet euren neuen Datenstrom vom vorherigen?
Seid ihr sicher, dass ihr das genauso wie die vorherige Software leistet?

[Flappes]

Nein die neue Spool ist eine *SCS und kann auch mit Auswahl 5 angezeigt werden.
Hier kann man in Klarschrift die Steuercodes für den Sato-Drucker lesen.
Es ist eine normale Spool wie wir sie auch bspw für die Zebra-Drucker verwenden, allerdings eine andere Syntax für die Positionierung, was aber für das Kommunikationsproblem egal sein sollte, da es ja nur der Inhalt ist.

Das Etikett kommt auch sauber raus. Und zwar ohne das jemand eingreift, also nach einer Zeit von ca. 2-3 Minuten.

Die bisherige OUTQ war wie folgt konfiguriert:
CHGOUTQ OUTQ(PRTXXX)
RMTSYS(*INTNETADR)
RMTPRTQ(‚RAW‘)
AUTOSTRWTR(1)
CNNTYPE(*IP)
DESTTYPE(*OTHER)
TRANSFORM(*YES)
MFRTYPMDL(*IBM2381)
WSCST(*NONE)
INTNETADR(‚1.1.1.1‘)
DESTOPT('XAIX XAUTOQ')

Normalerweise arbeiten wir mit Zebra-Druckern, diese konfiguriere ich immer wie folgt.
Dies läuft bei all unseren Kunden problemlos
CRTOUTQ OUTQ(PRTXXX)
RMTSYS(*INTNETADR)
RMTPRTQ(‚portLF1‘)
AUTOSTRWTR(1)
CNNTYPE(*IP)
DESTTYPE(*OTHER)
TRANSFORM(*YES)
MFRTYPMDL(*WSCST)
WSCST(QWPDEFAULT)
INTNETADR(‚1.1.1.1‘)
DESTOPT(QWPDEFAULT)

Beide Varianten machen aber das gleiche Problem.

[Fuerchau]

Vielleicht fehlt euch ja nur irgendeine Init- oder Abschluss-Sequenz für den Drucker, die normalerweise im WSCST steht.
Ggf. wartet der Drucker auf eine "Ich habe fertig"-Meldung und steht auf Timeout, so dass Folgeaufträge halt nicht angenommen werden.
Vielleicht hilft da das Druckerandbuch.
Zebra hat ja auch eine "Ende-Etikett"-Sequenz.

[Flappes]

Ja das Etikett hat eine Start und Ende-Sequenz, sonst würde das Etikett ja nicht vorgeschoben.
Die Steuercodes zwischen Zebra und Sato sind sich auch sehr ähnlich.

Was mir jetzt aufgefallen ist, es passiert wenn der Drucker eine gewisse Zeit keinen Druckauftrag bekommen hat.
Und die Zeit Zwischen der Meldung mit der beendeten Verbindung, und das die Spool gesendet wurde liegt immer bei 30 Sekunden

[holgerscherer]

Und die Zeit Zwischen der Meldung mit der beendeten Verbindung, und das die Spool gesendet wurde liegt immer bei 30 Sekunden

Das klingt ein wenig danach, als braucht der Drucker nach einer Schlafenszeit etwas Kaffee... Gibt es in der Konfig-Oberfläche des Druckers einen Timeout?

-h