Verbindungsprobleme

[Mordox]

Da gibts ggf. einen Timeout in der VPN-Verbindung.
Das 2. Problem ist ggf. die Internetverbindung selber.
Wenn man keine statische IP vom Provider bekommt (beantragt hat), wird das Netz alle 24 Stunden unterbrochen und ggf. eine neue IP vergeben. Da man nicht weiß, wann die Internetleitung tatsächlich aufgebaut wurde, ist auch der Zeitpunkt der Unterbrechung kaum feststellbar.
Die AS/400 kommt damit nicht zurecht, sie benötigt auf jeden Fall eine permanente, nicht unterbrochene Verbindung.

Für SNAoverIP wird auf der Ethernet-Leitung auch ein virtueller Controller und Device angelegt die ja auf Aktiv stehen müssen.
Kommt es nun zur Unterbrechnung, gehen diese ggf. auf RCYPND (je nach Einstellung).
SNA verlangt aber auch eine statische (also permanente) Verbindung um Problemlos zu funktionieren.

Stelle über deinen Provider also sicher, dass der VPN-Tunnel auch tatsächlich wie eine Standleitung zur Verfügung steht !

Hallo Fuerchau,

das mit der einmaligen Unterbrechung alle 24 Stunden ist mir klar. Das dürfte hier auch nicht das Problem sein, da mehrere Benutzer gleichzeitig mittel PASTHR auf die andere Maschine durchgreifen. Bei den Usern, welche permanent (zeitgleich) auf der anderen Maschine arbeiten kommt es auch nicht zu der Fehlersituation. NUR wenn ein Benutzer über ca 1 h nichts macht, taucht das Problem auf (auch während andere Benutzer zeitgleich ohne abbruch arbeiten können)....

Auch die virtuellen Controler bzw. Devices haben keinen anscheinend keine Fehler....

Grüße
Andreas

[RobertMack]

... ob da evtl. der PC einschläft (Systemsteuerung, Energieoptionen)?

[Mordox]

... ob da evtl. der PC einschläft (Systemsteuerung, Energieoptionen)?

schön wärs, aber leider ist da auch mein arbeitsplatz von betroffen und irgendwas tue ich immer auf der kiste.....

[Fuerchau]

Versuchs mal über "CHGTELNA TIMMRKTIMO(30)".

Zeitüb. d. Sitzungs-Keep-Alive (TIMMRKTIMO) - Hilfetext

Gibt die Anzahl der Sekunden zwischen Verbindungsüberprüfungen an. TCP
testet jede TELNET-Verbindung im angegebenen Zeitintervall. Erhält TCP
keine Antwort, wird die Verbindung von TCP beendet.

Dieser Parameter bestimmt, wie häufig die Sitzungsverbindung überprüft
wird. Bei Angabe eines hohen Werts kann es länger dauern, bis eine
verlorengegangene Verbindung festgestellt wird. Bei Angabe eines
niedrigeren Werts wird die Sitzung häufiger getestet, aber wenn der Wert
zu niedrig festgelegt wird, können normale Verzögerungen im Netz dazu
führen, dass Verbindungen als verloren angesehen werden.

Der Hilfetext für den Befehl CHGTCPA (Parameter TCPKEEPALV) enthält eine
Erklärung zu Keep-Alive. Es sollte beachtet werden, dass TCPKEEPALV in
Minuten, TIMMRKTIMO aber in Sekunden definiert ist.


TCP Keep Alive (TCPKEEPALV) - Hilfetext

Gibt die Zeitdauer in Minuten an, die TCP wartet, bevor
eine Sonde an die andere Seite einer Verbindung gesendet
wird. Die Sonde wird gesendet, wenn die Verbindung im
Leerlauf ist, selbst wenn keine zu sendenden Daten
vorhanden sind.

Die Übertragung von Keep Alive-Paketen wird durch
individuelle Socket-Anwendungen über die Socket-Auswahl
SO_KEEPALIVE gesteuert. Weitere Informationen enthält
Sockets-Programmierinformationen im iSeries Information
Center unter
http://www.ibm.com/eserver/iseries/infocenter.

Irgendwo muss man halt Pseudo-Traffic erzeugen.

[Mordox]

Versuchs mal über "CHGTELNA TIMMRKTIMO(30)".

Zeitüb. d. Sitzungs-Keep-Alive (TIMMRKTIMO) - Hilfetext

Gibt die Anzahl der Sekunden zwischen Verbindungsüberprüfungen an. TCP
testet jede TELNET-Verbindung im angegebenen Zeitintervall. Erhält TCP
keine Antwort, wird die Verbindung von TCP beendet.

Dieser Parameter bestimmt, wie häufig die Sitzungsverbindung überprüft
wird. Bei Angabe eines hohen Werts kann es länger dauern, bis eine
verlorengegangene Verbindung festgestellt wird. Bei Angabe eines
niedrigeren Werts wird die Sitzung häufiger getestet, aber wenn der Wert
zu niedrig festgelegt wird, können normale Verzögerungen im Netz dazu
führen, dass Verbindungen als verloren angesehen werden.

Der Hilfetext für den Befehl CHGTCPA (Parameter TCPKEEPALV) enthält eine
Erklärung zu Keep-Alive. Es sollte beachtet werden, dass TCPKEEPALV in
Minuten, TIMMRKTIMO aber in Sekunden definiert ist.


TCP Keep Alive (TCPKEEPALV) - Hilfetext

Gibt die Zeitdauer in Minuten an, die TCP wartet, bevor
eine Sonde an die andere Seite einer Verbindung gesendet
wird. Die Sonde wird gesendet, wenn die Verbindung im
Leerlauf ist, selbst wenn keine zu sendenden Daten
vorhanden sind.

Die Übertragung von Keep Alive-Paketen wird durch
individuelle Socket-Anwendungen über die Socket-Auswahl
SO_KEEPALIVE gesteuert. Weitere Informationen enthält
Sockets-Programmierinformationen im iSeries Information
Center unter
http://www.ibm.com/eserver/iseries/infocenter.

Irgendwo muss man halt Pseudo-Traffic erzeugen.

Gute Idee, dieser Parameter war auf *CALC...
hab ihn jetzt auf 30 gestellt und probier einfach mal aus, was passiert!
ich melde mich dann, wenn wir eine verbesserung feststellen (oder auch nicht)
Grüße
Andreas

[Fuerchau]

Bei *CALC habe ich irgendwo mal gelesen, dass dann ca 120 Minuten verwendet wird (finde ich aber nicht mehr).

Ich habe aber ein ähnliches Problem mit ODBC über VPN. Hier beträgt die Timeout-Zeit ca. 5 Minuten. Da aber ein Select durchaus mehr als 5 Minuten benötigen kann (Batchanwendung), bleibt die Verbindung sozusagen hängen: Der Client wartet auf das Ergebnis, laut Joblog der AS/400 wurden aber bereits Sätze zurückgegeben. Beide Prozesse stehen nun auf Empfang.
Man kann aber auf dem gleichen Port keine weitere Anweisung abgeben, da durch die fehlende Antwort die neue Anweisung in eine Queue gestellt wird.
Ich finde nirgendwo eine Timer-Einstellung, der mir diese Port-Verbindung länger aufrecht erhält.

Das Hauptproblem des ganzen IP ist, dass die Timer für jede einzelne Verbindung (also pro Port) gelten.

[Mordox]

Gute Idee, dieser Parameter war auf *CALC...
hab ihn jetzt auf 30 gestellt und probier einfach mal aus, was passiert!
ich melde mich dann, wenn wir eine verbesserung feststellen (oder auch nicht)
Grüße
Andreas

also:
hatte jetzt im hintergrund für eine stunde eine Sitzung auf die andere Maschine aktiv, während ich in einer anderen Session gearbeitet habe. Leider hat die Änderung des Parameters TIMMRKTIMO keinen positiven Effekt, so dass meine Hintergrundsitzung mittlerweile zwar ein Normales Bild zeigt, aber bei einer Eingabe wieder auf SYSTEMWAIT steht und nix vorwärts geht....

Sodale, ich werde jetzt bzw. morgen die IBM-Softwarehotline anrufen....

Trotzdem vielen Dank für Eure Anteilnahme.

Grüße
Andreas

[RobertMack]

Gibt es nicht auch in der Emu die Möglichkeit, einen Keepalive zu setzen (wie z.B. in Mochasoft)?

[Fuerchau]

ClientAccess-5250 benötigt dies nicht, da dieser auf den Telnet-Ping der AS/400 reagiert (siehe TIMMRKTIMO).
Mochasoft reagiert wiederum auf diesen Wert nicht und benötigt daher einen eigenen KeepAlive.

Soviel zum Thema Standard