Abbrüche der ACS Sitzung

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

[BenderD]

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]

... 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]

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.

[Fuerchau]

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]

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.

[BenderD]

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

[Fuerchau]

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.

[BenderD]

... 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]

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.

[dschroeder]

So, ich habe mal einen Test durchgeführt, der leider nicht zum Erfolg geführt hat:

1. Ich habe eine Genie-Sitzung mit einem festen Namen erzeugen können. Dazu habe ich im Link einfach ?workstnid=SCHRO97001 eingegeben. Das hat wunderbar geklappt.
2. Dann habe ich auf der IBM ein Programm aufgerufen, das eine längere SQL Abfrage macht und dabei den Bildschirm längere Zeit blockiert.
3. Während der Blockades des Bildschirms habe ich den Browser Tab geschlossen. Dabei kam es tatsächlich dazu, dass die Sitzung im Browser weg war, aber der entsprechende interaktive Job auf der IBMi noch vorhanden war.
4. Dann habe den Browser-Link mit dem festen Sitzungsnamen nochmal aufgerufen. Ich hatte gehofft, dass ich jetzt mit dem alten Job wiederverbunden werde. Aber leider kam nur folgende Fehlermeldung (die IP habe ich unkenntlich gemacht):

An exception has occurredException:CPF87D7Message:Virtuelle Einheit kann nicht automatisch ausgewählt werden.Help:Ursache . . . . : Eine virtuelle Einheit kann von VTM/FM nicht automatisch ausgewählt werden. Erscheint in einem der Felder *N, bedeutet dies, dass die Informationen nicht verfügbar oder nicht zutreffend sind. Wird *VTAPI für die Client-IP-Adresse angezeigt, dann wurde eine Virtual Terminal API verwendet, die keine IP-Netzwerkadresse bereitgestellt hat. Die Anforderung wurde von der Client-IP-Adresse 1xx.xx.x.xx der anfordernden Einheit SCHRO9701 empfangen. Eine der folgenden Situationen ist vermutlich eingetreten: - Der QAUTOVRT-Wert wurde überschritten. - Der bei der Erstellung angegebene Einheitentyp war für dieses System nicht korrekt. - Die Einheit SCHRO9701 wird gerade verwendet. Fehlerbeseitigung: Eine der folgenden Maßnahmen durchführen und die Anforderung wiederholen: - Die zulässige Anzahl für automatisch ausgewählte virtuelle Einheiten erhöhen (Systemwert QAUTOVRT). - Einen anderen Einheitentyp für die zu erstellende virtuelle Einheit angeben. - Einen anderen Einheitennamen auswählen. - Den Client mit der IP-Adresse 1xx.xx.x.xx, der die Anforderung stellt, lokalisieren und die automatische Verbindungswiederholung für den Client inaktivieren. - Beim Anzeigen der Nachrichtenwarteschlange QSYSOPR in der Anzeige "Zusätzliche Nachrichteninformationen" die Taste "F9=Nachrichtendetails anzeigen" drücken, um festzustellen, welcher Job diese Nachricht gesendet hat. Anschließend mit dem Befehl DSPJOBLOG (Jobprotokoll anzeigen) für den Befehl feststellen, ob zusätzliche Nachrichten im Jobprotokoll vorhanden sind, die Aufschluss über die Fehlerursache geben. Technische Beschreibung . . . . . . . : Diese Nachricht wird vom XPF-Servermodul VTM/FM gesendet, wenn es keine virtuelle Einheit auswählen kann.

Hat jemand eine Idee?