View Full Version : Abbrüche der ACS Sitzung
holgerscherer
19-03-23, 20:57
... 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.
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.
... es gab auch VW-Käfer Fahrer, die geglaubt haben, sie hätten ein Auto und dass der 10 Liter auf 100 Km gebraucht hat, lag für die am Sprit!
holgerscherer
30-03-23, 23:55
... es gab auch VW-Käfer Fahrer, die geglaubt haben, sie hätten ein Auto und dass der 10 Liter auf 100 Km gebraucht hat, lag für die am Sprit!
jetzt begibst Du Dich auf den Pfad der Esoterik
camouflage
04-04-25, 07:14
Ich nehm das Thema hier nochmals auf. Nachdem der Treshold Timeout an der Firewall herunter geschraubt wurde, traten genau diese Probleme bei CA und ACS auf. Die Sessions verabschiedigten sich nach einer Weile mit CPF5140. Erst mit der Rücksetzung dieser Werte lief wieder alles normal. Stellt sich die Frage, ob man an die IBM i diesbezüglich angleichen kann.
In den Sitzungen gibts ein Sitzungskeepalive, dass eine Sitzung aufrecht halten kann.
Und, auch wenn es anscheinend nichts damit zu tun hat, auf der IBM gibts CHGTELNA, in dem man den Keepalive (Default 120 Minuten!) auf z.B. 5 Minuten runtersetzen kann.
Und zu guter letzt gibts eine zentrale Windows-Einstellung via Registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Tcpip\Parameters\KeepAliveTime
Deren Default steht auch auf 2 Stunden.
Auch sollte man darüber nachdenken, ob man Terminals mit QPADEVnnn vergeben lässt oder echte Sitzungsnamen und Devices generiert (geht auch generisch), da man damit die Systemwerte für Disconnect und Wiederverbinden sowie Jobabbruch (nach 2 Stunden) für DSC-Jobs vernünftig einstellen kann. Nichts ist lässtiger, als nach einem Verbindungsabbruch nicht in derselben Sitzung wieder aufsetzen zu können.
dschroeder
07-04-25, 17:05
Wir haben bei uns sehr viele Anwender, die ihre Profound Sitzungen einfach zuklicken. Da bleiben dann oft auf der IBM i Sitzungs-Jobs bestehen. Es passiert leider auch öfter, dass (z.B. im Homeoffice) die Netzwerkverbindung abbricht und die Sitzungen dann gekappt werden.
Unsere Sitzungsnamen werden per QPADEV... Konvention automatisch generiert. Habe ich dich richtig verstanden: Wenn wir feste Namen vergeben würden, und die User ihre gekappte Sitzung unter ihrem Standardnamen wieder starten würden, dass sie dann ihren übriggebliebenen Job "wiederfinden" würden und dann dort weitermachen könnten, wo sie aufgehört haben?
Das wäre natürlich ein ziemlicher Fortschritt.
Wir haben bei uns sehr viele Anwender, die ihre Profound Sitzungen einfach zuklicken. Da bleiben dann oft auf der IBM i Sitzungs-Jobs bestehen. Es passiert leider auch öfter, dass (z.B. im Homeoffice) die Netzwerkverbindung abbricht und die Sitzungen dann gekappt werden.
Unsere Sitzungsnamen werden per QPADEV... Konvention automatisch generiert. Habe ich dich richtig verstanden: Wenn wir feste Namen vergeben würden, und die User ihre gekappte Sitzung unter ihrem Standardnamen wieder starten würden, dass sie dann ihren übriggebliebenen Job "wiederfinden" würden und dann dort weitermachen könnten, wo sie aufgehört haben?
Das wäre natürlich ein ziemlicher Fortschritt.
... unter cics (weiß garnicht, ob es das auf der as400 noch gibt), hast Du mehr als das: wenn sich derselbe Benutzer am selben Device nach Abbruch anmeldet, kommt er genau dort wieder rein, wo er vorher war. Das erfordert natürlich auch eine Transaktions orientierte Programmierung, sprich: es dürfen keine Sperren gehalten werdne, wenn der Benutzer die Kontrolle bekommt.
D*B
Und das ist auch keine Neuerung oder gar ein Fortschritt sondern funktioniert seit, nach meiner Erinnerung, bereits seit V2R1 (1992) mit den netten 25Kg-Greenscreens und ist ein uralter Hut.
Das funktioniert i.Ü. sogar mit Profound-Sitzungen im Web.
Und mit CICS hat das rein gar nichts zu tun, das ist rein OS/400, IBM i OS, u.s.w.
In CA und ACS kann man die Sitzungsnamen nach bestimmten Kriterien wie PC-Namen auch generisch nummerieren lassen, Also MEINPCS1, MEINPCS2, ....
Mit Druckersitzungen hat man es doch ebenso gehalten.
... bei CICS geht es um die Wiederanlauffähigkeit eines Programms. D.h.: nach Abbruch eines Programms wird das Programm dort wieder aufgenommen, wo es abgebrochen wurde, wenn sich derselbe Benutzer am selben Device anmeldet und das Programm erneut aufruft.
Sicher kann man das per Hand programmieren (Notify Object lässt grüßen), gibt es aber für Dialogprogramme auch fertig (CICS lässt grüßen).
D*B
dschroeder
08-04-25, 10:26
Vielen Dank für eure Antworten.
CICS habe ich für die IBM i noch nicht gehört (das heißt aber nichts). Ich habe das nur von IBM i Großrechnern mal gehört.
Aber egal: Ich werde das mal ausprobieren. Feste Sitzungsnamen vergeben und dann mal sehen, ob ich eine Sitzung so abschießen kann, dass der zugrundeliegendes IBM i Job aktiv bleibt. Und dann mal sehen, ob man sich wieder damit verbinden kann.