Abbrüche der ACS Sitzung

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

[Fuerchau]

Eine Wiederverbindung ist erst möglich, wenn der Job in den Status DSC (Disconnected) gewechselt ist.
Zusätzlich muss man den Job bei Abbruch von Anfragenachrichten auf *DSCMSG stellen. Die Einstellung weiß ich im moment nicht.

Und zu guter letzt:
Das funktioniert nur, wenn der Job gerade eine E/A-Operation (EXFMT, WRITE forced) auf dem Screen durchführt. Denn nur dann gibts die Nachricht, die nicht beantwortet werden kann, da der Job ja vom Client getrennt ist.

Für deinen Fall wird der Job erst disconnected, wenn der SQL durch ist und eine Bildschirmaus-/eingabe erfolgt.

[dschroeder]

Irgendwie klappt das bei mir nicht. Ich schaffe es nicht, einen Job in einen DSCMSG Status zu bekommen. Ich habe versucht, den Job mit CGHJOB zu ändern, so dass DEVRCYACN(*DSCMSG) ist. Danach habe ich den Fehler produziert. Aber der Status ist weiter einfach *ACTIVE. Im Programmstapel kann ich sehen, dass der Job auf einem EXFMT steht.
Aber ein Wiederverbinden klappt nicht. Fehlermeldung siehe oben.

[Fuerchau]

Du hast oben geschrieben, dass du das mit Genie (Profound?) und nicht mit ACS machst.
Desweiteren, da TCP-Verbindungen Stateless sind, es also keine Überwachung gibt, musst du u.U. die Sitzungskeepalive (Default 120 Minuten!) anpassen:
a) CHGTCPA z.B. auf 2 Minuten.
b) Einstellungen in den Clientsitzungen
c) Windows Default Keepalive https://microsoft.github.io/CSS-Exch...SettingsCheck/
Das hat mit Exchange direkt nichts zu tun.

[dschroeder]

Ich tue mich da etwas schwer, so einfach in den TCP Einstellungen Änderungen durchzuführen. Bei uns steht der TCPKEEPALV auf 15. Heißt das, dass ich einfach 15 Minuten warten müsste, damit der Job den Status *DSCMSG bekommt?
Ich versuche das mal.