Verbindungsprobleme

[Mordox]

Hallo liebe i5-Gemeinde,

ich habe mal wieder ein Problem und Ihr seid meine letzte Hoffnung.

Folgendes: Zwei AS/400 sind verbunden mittels eines VPN-Tunnels übers Internet (2mbit Zugang).
Von AS1 (V5R3M0) wird ein STRPASTHR zur AS2 (V5R2M0) aufgebaut und es kann zügig und permanent gearbeitet werden. Auch diverse DDM-Dateien von AS1 zur AS2 bzw. umgekehrt funktionieren fast problemlos.
Allerdings wenn auf einer PASTHR-Sitzung längere Zeit keine Eingabe auf AS2 gemacht wird (ca 1h) hängt sich die Sitzung auf und ist ca für 25 - 30 Minuten gesperrt. Dann bricht der PASTHR aus AS1 zusammen, erzeugt lediglich einen CPF8907 (Übertragunsfehler für Einheit AS2) und auf AS2 bleibt der Job noch längere Zeit aktiv und bricht ab ohne Fehlermeldung.
Bis letzte Woche waren die Maschinen noch mit einer echten "Punkt zu Punkt" Standleitung verbunden und es gab diese Probleme definitv nicht!

Vielleicht kennt von Euch jemand das Problem bzw. kann mir weiterhelfen, wo der Fehler zu suchen ist!

Vielen Dank schon mal!

Andreas

[RobertMack]

Hallo Andreas,

sieh mal nach den Systemwerten QINACTITV und QDSCJOBITV.

Gruß,
Robert

[Mordox]

Hallo Andreas,

sieh mal nach den Systemwerten QINACTITV und QDSCJOBITV.

Gruß,
Robert

Hallo Robert,

bei AS1:
QINACTITV: *NONE
QDSCJOBITV: 240

bei AS2:
QINACTITV: *NONE
QDSCJOBITV: 240

und jetzt bin ich auch nicht schlauer...

Grüßle
Andreas

[Fuerchau]

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 !

[RobertMack]

... zu VPN hab' ich jetzt aber fleißig mitnotiert, danke Kollege F(achbuch)uerchau

;-)

[Fuerchau]

Systemwerte:

QINACTITV

Zeitüberschreitung des interaktiven Jobs. Gibt an, wann das System
bei nicht aktiven interaktiven Jobs eine Maßnahme ergreift. Der
Systemwert QINACTMSGQ bestimmt die jeweils zu treffende Maßnahme.
Weitere Informationen über das Erzwingen des Durchgriffs auf das
Ziel und über TELNET-Sitzungen enthält das Handbuch Work Management.
Lokale Jobs, die gegenwärtig an einem fernen System angemeldet
sind, sind davon nicht betroffen. Beispiel: Eine Datenstation ist
direkt an System A angeschlossen, für das QINACTIV angegeben wurde.
Wenn die Anmeldung an System B mit
iSeries-Datensichtgerätsdurchgriff oder TELNET erfolgt, hat der in
System A gesetzte Wert QINACTIV auf diese Datenstation keine
Auswirkung.

QDEVRCYACN

Aktion für Einheitenwiederherstellung. Gibt an, welche Maßnahme zu
treffen ist, wenn bei einer interaktiven Jobdatenstation ein
E/A-Fehler auftritt.

Eine Änderung dieses Systemwerts gilt für alle Jobs, die nach der
Änderung gestartet werden. Der Vorgabewert ist *DSCMSG.

Aktion

*DSCMSG
Unterbricht den Job. Beim erneuten Anmelden wird eine
Fehlermeldung an das Benutzeranwendungsprogramm gesendet.

*DSCENDRQS
Unterbricht den Job. Beim erneuten Anmelden wird eine
Abbruchsanforderungsfunktion durchgeführt, um die Steuerung des
Jobs auf die letzte Anforderungsebene zurückzusetzen.

*ENDJOB
Beendet den Job. Für den Job wird ein Jobprotokoll erstellt.
Eine Nachricht wird an das Jobprotokoll und das QHST-Protokoll
gesendet. Sie gibt an, dass der Job infolge eines Fehlers
beendet wurde.

*ENDJOBNOLIST
Beendet den Job. Für den Job wird kein Jobprotokoll erstellt. An
das QHST-Protokoll wird die Nachricht gesendet, dass der Job
infolge eines Fehlers beendet wurde.

*MSG
Sendet die E/A-Fehlermeldung an das Anwendungsprogramm des
Benutzers. Das Anwendungsprogramm behebt den Fehler.

QDSCJOBITV

Zeitintervall, ehe ein unterbrochener Job beendet wird. Gibt die
Zeitspanne (in Minuten) an, die ein interaktiver Job unterbrochen
werden kann, ehe er beendet wird. Ein interaktiver Job kann mit dem
Befehl DSCJOB, nach einer bestimmten Zeit der Inaktivität
(Systemwerte QINACTIV und QINACTMSGQ) oder aufgrund eines
E/A-Fehlers bei der betreffenden Datenstation (Systemwert
QDEVRCYACN) unterbrochen werden.

Und dann gibts da noch den Jobwert:

Maßnahme Einheitenwiederherst. (DEVRCYACN) - Hilfetext

Gibt die Wiederherstellungsmaßnahme an, die für den Job ergriffen werden
soll, wenn in der Einheit *REQUESTER für interaktive Jobs ein E/A-Fehler
gefunden wurde. Dieser Parameter kann nur für interaktive Jobs angegeben
werden.

*SAME
Die Datenstations-Wiederherstellungsmaßnahme wird nicht geändert.

*SYSVAL
Der Wert im Systemwert, QDEVRCYACN, wird für die
Einheitenwiederherstellungsmaßnahme für diesen Job verwendet.

*MSG
Das die E/A-Operation anfordernde Anwendungsprogramm erhält eine
Fehlernachricht, dass die E/A-Operation fehlschlug.

*DSCMSG
Der Job wird automatisch unterbrochen. Sobald die Unterbrechung
behoben ist, erhält der Job eine Fehlernachricht über das Auftreten
eines E/A-Fehlers und die Wiederherstellung der Einheit. Obwohl die
Einheit wiederhergestellt wurde, muss die vor dem Fehler angezeigte
Anzeige erneut angezeigt werden.

*DSCENDRQS
Der Job wird automatisch unterbrochen. Sobald die Unterbrechung
behoben ist, wird der Befehl ENDRQS mit der Angabe des vorherigen
Anforderungsprozessors ausgegeben. Falls kein Anforderungsprozessor
vorhanden ist, wird eine Fehlernachricht ausgegeben.

*ENDJOB
Der Job wird mit der Auswahl *IMMED beendet. Für den Job wird ein
Jobprotokoll erstellt.

*ENDJOBNOLIST
Der Job wird mit der Auswahl *IMMED beendet. Für den Job wird kein
Jobprotokoll erstellt.


Dies betrifft alles nur Situationen, in denen tatsächlich ein E/A-Fehler festgestellt wird.
Unter IP gibt es keinen automatischen Ping bzw. KeepAlive, der eine Verbindung aufrecht hält.

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