View Full Version : CA und gui läuft nicht mehr nach 20 Minuten
tfroehlich
03-12-15, 08:06
Hallo zusammen,
wir haben das Problem, das ein User von Außerhalb auf unser System zugreift über VPN
Seine AS400/Sitzungen frieren nach 20 Minuten ein, wenn er nichts mit den jeweiligen Sitzungen macht.
Dann geht leider nichts mehr.
Hat jemand eine Idee , an welcher Einstellung im CA oder auf der i-series liegen könnte?
Gruss
Thomas
camouflage
03-12-15, 08:27
Hallo Thomas,
Friert nur CA ein oder kommt der ganze VPN Verkehr zum erliegen?
Ich würde mir mal die Keep Alive Werte anschauen.
Wie immer:
KeepAlive-Einstellungen.
Dazu gibt es mehrere Beiträge im Forum:
- TCP-KeepAlive (Windows-Einstellungen)
- 5250-KeepAlive (in der 5250-Sitzung per Editor)
- CHGTELNA auf der AS/400 (Default hier 2 Stunden bei *CALC)
tfroehlich
03-12-15, 09:09
Hallo zusammen,
im chgtelna steht der Parameter auf 28800. Somit dürfte dieser kein problem darstellen.
Ich werde mal in den CA-Sitzungen mal die Parameter überprüfen.
Vielen Dank erstmal für Eure Unterstützung.
Gruss
Thomas
So einen ähnlichen Effekt hatten wir in einem Projekt vor Jahren auch; die Ursache konnte nie eindeutig geklärt werden. Wir haben uns mit einem DOS-Fenster und einem darin ewig laufenden "ping host -t" beholfen. Das war zwar auch kein 100%iges Heilmittel, aber viel besser.
Bei CHGTELNA und 28800 prüft also die AS/400 alle 28800 Sekunden, ob eine Sitzung noch aktiv ist.
Wenn du das in Ordnung findest, dann kannst du das ja so lassen.
Dies führt aber auch dazu, dass bei einer tatsächlichen Unterbrechung die AS/400 den Job erst nach 28800 (bzw. nach dem letzten Intervall) Sekunden trennt (DSCMSG) oder killt (ENDJOB).
Zur Erinnerung: 28800 Sekunden = 8 Stunden!
Da ist es dann kein Wunder dass das VPN nach 20 Minuten Leerlauf keine Aktivität feststellt.
Empfehlenswert ist her z.B. 60!
Die AS/400 schickt somit an jede Sitzung alle 60 Sekunden einen "Telnet"-Ping.
D.h., bei einer echten Trennung wird der Job nach spätestens 1 Minute geparkt (DEVRCYACN = *DSCMSG) und man kann sich bei gleicher Sitzung (also nicht QPADEV) auch wieder verbinden.
Wenn man allerdings eine schlechte Verbindung hat, kann dies zu häufiger Trennung führen.
Zusätzlich gibt es ja auch das TCP Keepalive bei CHGTCPA, Default 2 Minuten.
Wobei ich denke, dass dieser (laut Definition) von TELNET übersteuert wird.
Die Qualität der Verbindung muss man halt prüfen ob die KeepAlive's zu häufigerer Trennung führen obwohl keine Trennung vorliegt.
Das ist der Nachteil von "zustandslosen" Verbindungen wie eben TCP.
tfroehlich
03-12-15, 10:09
Hallo Herr Fuerchau,
zu meiner "Verteidigung" muss ich sagen, dass die Maschiene von einem Systemhaus eingerichtet worden ist.
Ich werde Ihre Hinweise darauf mal überprüfen lassen.
Gruss
Thomas
Vor den TELNA-Keepalive's hatte ich auch ein kleines VB6-Programm gemacht, dass alle Minute einen ODBC-SQL ausgeführt hat. Allerdings hatte ich das Gefühl, dass dies auch nicht so viel gebracht hatte.
holgerscherer
03-12-15, 21:04
Vor den TELNA-Keepalive's hatte ich auch ein kleines VB6-Programm gemacht, dass alle Minute einen ODBC-SQL ausgeführt hat. Allerdings hatte ich das Gefühl, dass dies auch nicht so viel gebracht hatte.
Das Ganze ist nur Gebastel, das Problem dürfte zu 95% eine Firewall-Regel im VPN sein, die inaktive Sitzungen aus der internen Tabelle löscht. Wenn danach noch Traffic auf dem IP/Port-Paar kommt, wird das ignoriert.
In der Regel findet sich da etwas zum Thema Connection-Timeouts in der Firewall resp. dem VPN-Router.
Das mit den Keepalives kann auch eventuell nicht funktionieren, weil
a) der Verbindungsaufbau vom Client kommt, aber
b) die Keepalives vom PC
Da ist mancher Verbindungsmonitor etwas irritiert, oder ignoriert das einfach.
-h
tfroehlich
08-12-15, 14:30
Guten Tag zusammen,
danke für Eure Hinweise.
Ich werde die Firewall etc von unserem Netzwerkadmin überprüfen lassen.
Ich halte Euch auf dem Laufenden, wenn das Problem gelöst ist.
Gruss
Thomas