Abbrüche der ACS Sitzung

[Robi]

Moin zusammen

wir haben seid einiger Zeit bei einem Kunden folgendes Problem.

Die ACS Sitzung geht manchmal auf Status DSC und landet dabei im Signon CPF5140
Nach der Wiederanmeldung versucht das System dich genau dort weiter arbeiten zu lassen, wo du warst als du rausgeflogen bist. (klappt in der Anwendung, im System nicht).
Das geschied nur, wenn die Sitzung gerade nicht verwendet wird.
Wenn 3 oder mehr Sitzungen aktiv sind passiert das quasi regelmäßig (die 1. Sitzung fliegt raus)
Bei 2 Sitzungen nicht ganz so oft und bei nur einer, auch aber selten (1-2 mal / Tag)

Für die Netzwerker mussten wir die IP der Sitzung und die Abbruch-Zeit ermitteln.
Dabei fällt auf, (habe ich mich nie damit beschäftigt) das die Sitzungen des Users alle die gleiche IP haben. (Startpgm ermittelt IP und schreibt diese in eine Datei)

Hat jemand eine Idee, iSeries oder Netzwerker, an welchen Schraube wir noch drehen können? TCP Einstellungen in der i und Keep alive (o.ä) in der Sitzungskonfiguration sind alle überprüft und sollten weder Ursache noch Lösung sein.

Danke
Robi

[Fuerchau]

Dass der Client dieselbe IP hat ist logisch, jedoch der Client-Port ist immer ein anderer.
Bzgl. der Einstellung auf der i meinst du CHGTELNA?
Der Sitzungskeepalive steht bei *CALC auf 2 Stunden, d.h., die i merkt erst nach 2 Stunden eine Unterbrechung.
Im ACS steht zur Hilfe für Keepalive nicht viel, daher vermute ich mal, dass damit die Antwort auf die i-Anfrage (s.o.) beantwortet wird.
Zeitlimit für Inaktivität bedeutet, dass ACS die Verbindung dann aktiv trennt.

[Robi]

Das ist bekannt,
ich schrieb ja, an diesen Werten kann es nicht liegen!

[Fuerchau]

Dann ist euer Netz instabil. Bei IP kann es immer mal zu Unterbrechungen kommen.
IP ist kein aktives Protokoll mit ständigen Pollrequest wie früher bei den alten Protokollen.
Um zu wissen ob einer noch da ist, kann man im Socket KeepAlive aktivieren.
Allerdings überwachen auch Firewalls aktive Sitzungen. Auch hier kann man einen Timeout konfigurieren.

https://www.msxfaq.de/netzwerk/grundlagen/tcp_session_timeout.htm

[Robi]

Die Netzwerker bestreiten das!
Es ist halt auffällig, das (fast) immer nur eine Sizung eines Anwenders rausfliegt und je mehr Sitzungen er hat, umso regelmäßiger. (auch wenn das mathematisch logisch ist, irgenwas anderes muß da sein)
Die Netzwerker haben auch schon alle Einstellungen geprüft und/oder anders eingestellt. Die sagen der Cut geht von der i aus, alle Entwicker und die Firma die die Kiste hosted kennen diese Verhalten VON der i nicht.

[Fuerchau]

Das ist immer dasselbe Problem, auf Windows kann es sowas nicht geben.
Ich lese allerdings häufig, wenn man den PC neu aufsetzt, dass die Probleme auf einmal weg sind.

[Robi]

Jain ...
betrifft nicht einen PC, betrifft > 90 Arbeitsplätze, größtenteils in einer VMWare Umgebung.
Von dehnen arbeiten mind. 90 % auch in der Windows oder einer Oracle Welt.
Außerdem sind, im selben Netz, > 70 Arbeitsplätze ohne iSeries Anbindung (Win/Oracle)

Nur die 5250 Emulation ist betroffen

[Fuerchau]

Das lässt sich dann tatsächlich nur tracen, ob und wann und mit welchen Timern die Pakete gesendet werden. Allerdings ist das natürlich bei dieser Vielzahl heftig. GGf. mal einen PC gezielt raussuchen.
Es ist auch die Frage, ob solche Pakete z.B. durch Firewalls rausgefiltert werden, da sie auch missbraucht werden können (brute force für Überlastungen).
Somit könnte u.U. die Keepalive-Zeit auf der IBM i auf 10 Stunden hochgesetzt werden, was natürlich Jobs sperrt, wenn echte Abbrüche auftreten.
Ich hatte mal so in den 90ern ein Mini-Programm für den Client geschrieben, dass 1x pro Minute einen ODBC-SQL absetzte. Dies hielt die Verbindung tatsächlich aufrecht, da die Firewall das ja durchlies.

https://www.msxfaq.de/netzwerk/grundlagen/http_keep-alive.htm

[Robi]

so, die neuste Erkenntnis:
Dieser abbruch passiert immer dann, wenn die Sitzung länger (5 Minuten?) nicht benutzt wurde und eine Brkmsg gesendet bekommt. Bei den Entwicklern aus einer Umwandlung oder bei den Anwendern nach einem Mail versand oder einer Excel erstellung.
Warum diese MSG zum Abbruch führt ist noch nicht klar, aber das ist ein Ansatz!

[BenderD]

... da würde ich doch mal testen, ob das mit einem ordentlichen 5250 Client auch passiert.