5250 über WLAN: Verhalten bei Unterbrechungen

[Fuerchau]

Nun ja, ich kenne mittlerweile 2 (von mir angepasste) Anwendungen, die im Lager und der Kommissionierung mit eben diesen CE-Terminals im 16x24-Zeilenmodus sehr gut zurechtkommen.

Nicht immer ist das moderne auf diesen kleinen Bildschirmen auch anwenderfreundlich.

Wenn man den Bildschirm mit WEB-Anwendungen schön bunt macht, wirds auch nicht unbedingt besser.

Ausserdem war ein gewaltiger Vorteil durch den Einsatz von 5250 erreichbar.

Ich habe einfach die bestehenden 5250-Dialoge mittels Aufrufparameter auf die wesentlichen Eingabefelder beschränkt, so dass der Rest des vorhandenen Programmes im "Standard" funktioniert.

Moderne Lösungen setzen da leider auch häufig moderne Anwendungen voraus.
Wenn die Anwendung allerdings schon einige Jahre auf dem Buckel hat, wird es doch meist schwieriger, vorhandene Dialoge als echte Clientanwendung für den Scanner neu zu entwickeln.

Ausserdem kann man die 5250-Anwendungen auch ohne Scanner schön direkt an der AS/400 testen.
Ich benötige keinen Scanner oder CE-Emulatoren und war mit der Entwicklung auch erheblich schneller.

Aber das ist ja alles Ansichtssache, Kosten/Nutzen gegen die Moderne auszuspielen.

[grunzheini]

Ich würde diese Thema gerne nochmal aufleben lassen, da wir das gleiche Problem habe wie ChrisB.
Wir arbeiten mit einem "normalen" PC über 5250 Emulation (Client Access) über Wlan auf unserer I5.
Nun kommt es auch zu diesen Unterbrechungen, welche warscheinlich durch den wechsel der AP-Bereiche kommt, denn der Empfang ist bis auf ganz wenige Aussnahmen hervoragend o. sehr gut.

Genügt es nun, wenn ich beim Anmelden in die Start Routine diesen Befehl einbaue?
CHGJOB DEVRCYACN(*DSCMSG)

Oder muss ich trotzdem noch den Systemwert QDSCJOBITV anpacken?

Ich will ja nur, dass der Job, bei dem aus welchem Grund auch immer die Verbindung verloren ging, wieder aufgenommen wird und der Mitarbeiter (fast)ohne Probleme weiterarbeiten kann.

Wir wollen auch keinen extra Server aufstellen, der das verwaltet, da es sich nur um einen PC handelt, der so auf die i5 zugreift.

Danke schonmal

[Fuerchau]

Normalerweise reicht *DSCMSG, aber was machst du, wenn der User sich dann mal nicht anmeldet ?

QDSCJOBITV

Zeitintervall, ehe ein unterbrochener Job beendet wird. Gibt die
Zeitspanne (in Minuten) an, die ein interaktiver Job unterbrochen
werden kann, ehe er beendet wird. Ein interaktiver Job kann mit dem
Befehl DSCJOB, nach einer bestimmten Zeit der Inaktivität
(Systemwerte QINACTIV und QINACTMSGQ) oder aufgrund eines
E/A-Fehlers bei der betreffenden Datenstation (Systemwert
QDEVRCYACN) unterbrochen werden.

Eine Änderung dieses Systemwerts wird sofort wirksam. Der
Vorgabewert ist 240 Minuten.

D.h., wenn nach 240 Minuten keine erneute Anmeldung erfolgt, fliegt derJob endgültig raus.

Das Ganze funktioniert natürlich nur, wenn
a) die AS/400 die Unterbrechung überhaupt mitbekommt
b) der PC den gleichen Devicenamen wieder verwendet

Für die Erkennung der Sitzungsunterbrechung ist CHGTELNA:

Zeitüb. d. Sitzungs-Keep-Alive (TIMMRKTIMO) - Hilfetext

Gibt die Anzahl der Sekunden zwischen
Verbindungsüberprüfungen an. TCP testet jede
TELNET-Verbindung im angegebenen Zeitintervall. Erhält TCP
keine Antwort, wird die Verbindung von TCP beendet.

Dieser Parameter bestimmt, wie häufig die
Sitzungsverbindung überprüft wird. Bei Angabe eines hohen
Werts kann es länger dauern, bis eine verlorengegangene
Verbindung festgestellt wird. Bei Angabe eines niedrigeren
Werts wird die Sitzung häufiger getestet, aber wenn der
Wert zu niedrig festgelegt wird, können normale
Verzögerungen im Netz dazu führen, dass Verbindungen als
verloren angesehen werden.

Der Hilfetext für den Befehl CHGTCPA (Parameter
TCPKEEPALV) enthält eine Erklärung zu Keep-Alive. Es
sollte beachtet werden, dass TCPKEEPALV in Minuten,
TIMMRKTIMO aber in Sekunden definiert ist.

[grunzheini]

Danke für die schnelle Antwort.

Ich werd das ganze jetzt mal testen und bischen rumspielen damit.
Werde dann meine Erfahrungen wieder schreiben!

Danke Fuerchau !

[grunzheini]

Ich ahbe schon ein Problem.
Ich habe das jetzt mal mit meinem PC simuliert.

1. Sitzung angemeldet
Device ist DSP54

2. CHGJOB DEVRCYACN(*DSCMSG)
mit JOBNAME,USER + JOB-Nr.

3. Netzwerkkabel kurz gezogen.

Jetzt seh ich den Job zwar noch als aktive auf der i5, aber das Device ist ja nun blockiert und die 5250 bekommt darauf keine Verbindung.

Und es dauert recht lange, bis der Job auf DSC geht.
Ich habe die Prüfzeit TIMMRKTIMO auf 10 Sekunden stehen und scheint sich nicht
darauf auszuwirken, wie schnell der Job disconectet wird.

Hab ich da was nicht verstanden?
Muss ich den Wert von QINACTIV auch runter setzen? Wenn ja, wie wirkt sich das auf andere JObs aus, an denen eine kurze Zeit keine Eingabe erfolgt?
Werden diese auch disconnectet?

...Mir raucht der Kopf...
Ich glaube es ist zeit fürs Wochenende...

[Fuerchau]

QINACTITV hat mit getrennten Jobs gar nichts zu tun sondern mit aktiven, die nix tun.

Ob die AS/400 merkt, dass das Terminal weg ist, hängt leider von mehreren Faktoren ab und kann mitunter länger dauern.
Insbesonders wenn auch noch NAT im Spiel ist und ggf. auf die Überwachung ein Zwischenserver antwortet.
Über NETSTAT->3 kannst du prüfen, ob deine IP für Telnet aufgeführt wird oder nicht.

Ob der Wiederanlauf klappt, kannst du auch mit Systemanfrage+80 (Job unterbrechen) probieren.

Was ggf. gar nicht klappt, sind Serverkonstrukte wie z.B. HOB.
D.h., die AS/400 kennt den Endpunkt gar nicht sondern nur den Server, der seine Clients selber verwaltet.

TIMMRKTIMO funktioniert meines Wissens nach fast nur mit iSeries-5250 und nicht mit Mocha o.ä.

[fb@bruegge.biz]

Hallo,

ich vewende für genau diese Art der Anwendung ein kleines C Proramm, welches die TPC/IP Verbindung hält und die keepalives beantwortet.

Das Programm läuft 1x im Batch und lauscht auf einem anderen Port als 23 und leitet dann die Anforderungen an den Port 23 weiter.

Das Programm ist bei einigen Kunden sehr, sehr störungsfrei in Betrieb.

Wenn sie Interesse haben, kontaktieren sie mich bitte.

fb@bruegge.biz