Abbrüche der ACS Sitzung

[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/grund...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.

[Robi]

Ach Dieter, du kennst das doch sicher...

Wir wollen nur "das Beste"...
Und solange M$ keine Emulation hat wird halt IBM genommen.

[BenderD]

... zunächst geht es doch nur um Fehlereingrenzung. Wenn das mit Mocha nicht passiert, dann ist der Lieferant am Zug.

[Fuerchau]

Bei einem Profound-Webbildschirm gibts gar keine Break-Messages.

[BenderD]

... wenn die session abkackt, gibt es auch keine Breakmessage mehr.
Erinnert mich irgendwie an Lotus Smart Suite, da ist Freelance Graphics abgeschmiert und hat die in angefangene Arbeit unrettbar verhexelt, wenn man dasselbe Format zweimal geändert hat. Die Antwort von IBM war: "known problem, patch not available,workaround: you must not change a format twice!"

[Andreas_Prouza]

Ich würde hier einen Packet(TCP)-Sniffer nehmen.
Wenn das Verhalten reproduzierbar ist dann ist es umso besser für die Packetanalyse.
Die Packetsammlung am besten sowohl am PC als auch auf der IBM i (TRCCNN).
Bei beiden sollte man einen Filter auf die IP machen um nicht zu viel Datenmüll zu sammeln.
Sobal die Verbundung verloren geht, die Packetanalysen auf beiden Systemen beenden und dann geht's weiter zur Analyse.
Da sieht man dann wann zuletzt beide miteinander kommuniziert haben und wer als erster die Packete ablehnt und vor allem warum.
Z.B. könnte es sein, dass die IBM i nach einer Zeit ein RESET Packet schickt, da sie meint, die Verbindung wäre nicht mehr vorhanden usw.

Habe einen Kunden der mich immer wieder wegen solchen Themen kontaktiert, bei dem die Windows/Netzwerk-Profis meinen, es müsse ein IBM i Problem sein, da die Kiste eine Blackbox ist die an allem Schuld sein muss.
Nach RICHTIGER Analyse des Netzwerks und Auswertung der Daten, war bis jetzt die IBM i tatsächlich nie das Problem, sondern Windows. (Windows Update hat was entfernt was vorher benötigt war; MS hatte Teile aus dem TCP-Layer aus Windows herausgenommen und in die Verantwortung der Netzwerkkarten-Hersteller gelegt, die nicht alle nachgezogen hatten usw.)
Soll nicht heißen, dass die IBM i immer ausgeschlossen ist von Fehlern, jedoch hatte ich dort noch die wenigsten Probleme.

Ich hoffe das Hilft etwas weiter.

lg Andreas

[KingofKning]

Na ja, mit Wireschark den Verkehr mitschneiden ist zwar schön und nett, bringt aber vermutlich nichts weil Du dafür wirklich Profis brauchst die das auswerten können.

Du müßtest ja auch die Variante haben wo es läuft um das zu vergleichen.

Also das ganze mal auf der grünen Wiese mit einer andern I und einem PC aufbauen und sich langsam rantasten.
Ist aber auch sehr aufwendig.
Für den der es Analysieren darf ist das eine Goldgrube ;-)

GG 3009

[holgerscherer]

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

auch unordentliche clients haben hier probleme. grund düfte die paketgröße im netzwerk sein oder eine zwangs- segmentierung wenn der swich oder die vmware- server large packets machen.