5250 Sitzungs-Keepalive

[Fuerchau]

Also, ich hab da mal eine Frage:

Per CHGTELNA TIMMRKTIMO(nnn) kann ich die Überwachung von Telnet-Sitzungen (CA-5250) steuern.
Durch Netzwerkprobleme kommt es leider dazu, dass die Antwort in einer bestimmten Zeit nicht eintrifft.
Dies hat zur Folge, dass der Job getrennt wird.

Leider habe ich keine Einstellung gefunden in der man festlegen kann, wie lange die AS/400 im Zweifel auf die Antwort wartet.
Der Timer steuert nur, in welchem Zeitraster aktive Sitzungen abgefragt werden aber nicht, wie lange die AS/400 eben auf die Antwort warten soll.

Diese "Antwortzeit" scheint aber sehr kurz zu sein, so dass es verstärkt zu Jobtrennungen kommt obwohl diese eigentlich nicht erforderlich wäre.

Hat jemand dazu eine Idee ?

[moskito]

... das ist die Frage. Ich habe recht gute Erfahrungen damit, dass man den Systemwert QINACTITV auf "5" setzt, damit wartet die iSeries schon mal 5 Minuten, was recht angenehm ist, vor allem wenn man über das Internet mit der iSeries arbeitet und der ganze Spaß mal schnell zusammen bricht. Nach dem Starten der CA-Sitzung bin ich sofort wieder drin und es geht weiter. Leider gibt es keinen Wert unter 5 Minuten (mir wären 2 Minuten auch lieber).

[Fuerchau]

Könnte sich ggf. erledigt haben. Ich habe den Timer von 5 Sekunden auf 60 Sekunden angehoben.
Ggf. bezieht sich der Timer sowohl auf das Senden als auch auf die Antwort-Zeit.

Ich werde es mal weiter beobachten.

[Fuerchau]

QINACTITV hat damit nichts zu tun sonder nur im Zusammenhang mit QDEVRCYACN (ohne Q im Job).
Der Parameter heißt:
Wenn ein Job unterbrochen wurde (Disconnected, entweder eben mit obigem Sitzungs-Keepalive oder auch mit DSCJOB (Systemanfrage 80)), wird er eben nach dieser Zeit mittels ENDJOB total rausgeschmissen.
Dieser Wert kann z.B. auf 60 Minuten stehen.
Dadurch kann man sich per DSCJOB für max. 60 Minuten zur Mittagspause abmelden und anschließend eben genau da weitermachen.

Nun gibt es aber leider immer noch Kunden (und auch Anwendungen), die hier mit *ENDJOB für DEVRCYACN arbeiten. Der Hintergrund ist das Arbeiten mit nicht benannten Sitzungen (QPADEV*). Hier ist ein Wiederanmelden nahezu unmöglich, da ein Job nur wieder verbunden wird, wenn User und Device identisch sind.
Bei QPADEV's gibts aber meistens ein anderes.

[Fuerchau]

Nur zur Info:
Netzproblem gelöst, ein Windows-Server schickte Millionen von NetBios-Broadcast's !!!

Ach ja, vielleicht weiß es ja jemand:
Das Abschalten des WINS im Netserver führte bei der AS/400 leider nicht zum gewünschten Effekt.
Man hatte eine 2. IP-Adresse zugewiesen auf der auch die AS/400 ihrerseits jede Menge NetBios-Broadcasts für diese IP abschickte.

Vielleicht also noch eine ergänzende Frage:
Wo kann man diese NetBios-Nachrichten denn nun tatsächlich abschalten ?

[holgerscherer]

Nur zur Info:
Netzproblem gelöst, ein Windows-Server schickte Millionen von NetBios-Broadcast's !!!
Wo kann man diese NetBios-Nachrichten denn nun tatsächlich abschalten ?

schau mal, ob (auf allen anwesenden Windows-Möhren) im TCP / erweitert / WINS das "NetBIOS über TCP/IP" aktiviert ist... das ist auch ein Garant dafür, dass jeder Switch ein Dauerblinken gibt. Je nach Umgebung kann auch der Computersuchdienst auf den Workstations abgeschaltet werden. Und im Notfall am Debug-Port vom Switch mal einen Sniffer dranhängen und staunen, wie geschwätzig ein Windows-Netzwerk ist.

-h

[Fuerchau]

Das genau ist ja passiert und die Geschwätzige war laut IP-Adresse eben die AS/400 !
Es muss also noch irgendwo das NetBIOS auf der AS/400 scharf geschaltet sein (NetServer ist es angeblich nicht, ist dort ja ausgeschaltet).