PDA

View Full Version : Problem mit Symbol-Scannern



ubas
04-11-03, 15:02
Hallo,
habe folgendes Problem. Wir setzen Funk-Scanner der Fa. Symbol vom Typ PTC-960SL. Sie sind mit IP-Adressen konfiguriert und laufen auf unserer 810 (Rel. 5.2) als virtuelle Einheiten. Aus mir unerklärlichen und nicht nachzuvollziehenden Gründen verabschieden sich diese Scanner nach unterschiedlichen Zeiten, bzw. auch dann wenn man sie einfach unabgemeldet liegenläßt. Die Funkantennen wurden schon geprüft und sind o.k.! Die Jobprotokolle weisen folgende Fehler, mit denen ich nichts anfangen kann, auf:
CPF5140 Escape 70 04.11.03 08:03:17,801592 QWSGET QSYS 30B8 MDE01R SPEDPGM 1343
Message . . . . : Sitzung durch Anforderung von Einheit QPADEV0001 gestoppt.
Ursache . . . . : Die Abmeldeanforderung wurde entweder dadurch verursacht,
daß der Benutzer das System abgeschaltet hat, daß ein Einheitenfehler
auftrat oder daß die Inaktivitätsüberwachung der ASCII-Steuereinheit
abgelaufen ist.Fehlerbeseitigung: Die Dateien schließen und die Einheit
abhängen (Befehl VRYCFG). Tritt der Fehler nochmals auf, mit dem Befehl
ANZPRB (Problem analysieren) die Problemanalyse starten.
RPG1251 Sender copy 99 04.11.03 08:03:17,806592 QRGXMSG QSYS 00BE QRGXMSG QSYS 00BE
Message . . . . : Permanenter E/A-Fehler aufgetreten (C G S D F).
Ursache . . . . : In Anweisung 39900 des RPG-Programms MDE01R in Bibliothek
SPEDPGM wurde ein permanenter (nicht behebbarer) Datei-, Sitzungs- oder
Einheitenfehler gefunden. Die Sitzung, die Einheit und/oder das Programm
wurden/wurde gestoppt. Bestimmen Sie anhand des Werts für den
über-/untergeordneten Rückkehrcode den spezifischen Fehler, der aufgetreten
ist. Ist der übergeordnete Rückkehrcode 80, ist ein System- oder Dateifehler
aufgetreten und eine Programmiereraktion zum Beheben des Fehlers
Verschiedene Einstellungen unter CFGTCP führten auch nicht zum Erfolg. Kann mir jemand weiterhelfen?

Fuerchau
04-11-03, 16:47
Die AS/400 prüft ständig, ob das Device verfügbar ist. Die erwartete Antwortzeit kann man leider nicht konfigurieren.
Reagiert (antwortet) das Terminal nicht in dieser Zeit, geht die AS/400 von einer Unterbrechung aus.
Die Antwort muss ca. in 100ms kommen (geschätzt).

Sven Schneider
04-11-03, 19:57
Der Parameter TCPKEEPALV in CHGTCPA reicht allein nicht aus.

Zusätzlich den Parameter TIMMRKTIMO beim CMD CHGTELNA anpassen.

siehe auch Online-Hilfe zum Befehl CHGTELNA.

Noch ein Tip :
Am besten ist man bedient, wenn das MDE-Gerät auf Basis von Windows/Windows CE/Pocket PC oder Linux läuft.
Hier kann man den 5250-Client von Mochasoft verwenden.
Dieser kann automatisch über einen Config-Parameter Keep Alive Pakete an den Telnet-Server AS/400 senden, auch wenn man keine Eingabe in der Sitzung vornimmt.
Der DOS-5250-Client von Mochasoft kann das leider nicht.
(Dein PTC-960SL läuft ja unter DOS)

Sven

Fuerchau
05-11-03, 09:34
@Sven

dies scheint nicht unbedingt die Ursache zu sein, da der Defaultwert der Einstellung ca. 2 Stunden beträgt. Selbst wenn man dort z.b. 30 Sekunden einträgt (meine Empfehlung), heißt das nur, dass die AS/400 alle 30 Sekunden einen Ping auf den Port absetzt um eine Unterbrechung festzustellen.

Die Bestätigung des Pings muss aber trotzdem unter 1 Sekunde zurückkommen sonst wird der Job getrennt.

Sven Schneider
05-11-03, 10:31
@Baldur,

der Standardwert für TCP Keep Alive beträgt 120 Minuten, das ist korrekt.
Der Telnet-Server hat aber einen eigenen Sitzungs-Keep Alive Parameter und der steht standardmäßig auf *CALC - bedeutet 600 Sekunden.
D.h. wenn nach 10 Minuten keine Antwort kommt, fliegt der Job raus.

Kann man auch einfach ausprobieren.
- Telnet-Sitzung starten.
- Anmelden
- Telnet-Sitzung "Hart" beenden (Windows X rechts oben)
Der Job bleibt dann noch ca. 10 Minuten aktiv.

Das gleiche passiert, wenn ein Netzwerk (mit Routern und Switches, Wireless Lan, vielleicht noch Firewall) nicht korrekt konfiguriert ist.
Dann kommen die Telnet Keep-Alive Pakete niemals beim Client an, d.h. der Client hat keine Chance zu reagieren.

Hier helfen nur zwei Dinge :
- Netzwerk und deren Komponenten korrekt konfigurieren - das können leider nur wenige Netzwrk-Firmen, wenn es um die Besonderheiten des Telnet5250-Dienstes (sitzungsorientiert) geht

oder

- Telnet Sitzungs Keep Alive hoch setzten, aber auf die Gefahr, das dann wirklich abgestürzte Sitzungen ebenso lange aktiv bleiben


Sven

Sven

Fuerchau
05-11-03, 12:35
Nun das ist so irgendwie nicht ganz korrekt. Was weiß ich warum aber anscheinend gibts da zu viele Möglichkeiten.

Wir haben auch bei CA z.B. das Problem der hängenden Sitzung.
Wenn ich nur 1 Sitzung abwürge (das Kreuz bzw. ALT+F4 reicht da nicht , da 5250 einen Kill sendet und der Job beendet wird) die Sitzung dann wieder starte, bleibt der Job ewig hängen.
CA kann aber das Terminal nicht wieder verbinden da für ihn belegt. Ich muss also die Sitzung schließen bis der Job (automatisch oder manuell) weg ist.

Was das Beenden des Jobs angeht, gibts das verschiedene Möglichkeiten. Das Sitzungskeepalive macht tatsächlich ein Ping mit Antwort < 1 Sekunde.
Warum ?
Nun der Job fliegt nach MAXIMAL der eingestellten Zeit raus und nicht grundsätzlich.
Will heißen, wenn der letzte Ping gerade vor n-1 Sekunden durchgeführt wurde, ist der Job quasi sofort weg. Man weiß allerdings nie, wann man dran war.

Was das Wiederverbinden angeht, so haben wir den Sitzungskeepalive auf 30 Sekunden, damit der Job nach max. 30 Sekunden auch unterbrochen wird.
Den QDEVRCYACN auf *DSCMSG und den QDSCJOBITV auf 60. Ich habe also nach einer Unterbrechung 60 Minuten Zeit mich erneut anzumelden und den Job an der unterbrochenen Stelle fortzusetzen.