SNDNETF, SNDNETSPLF via QSNADS

[SL]

Hallo Forum,
wir haben 2 AS400 Systeme (825 und 810). Wir haben am Wochenende auf der 810 ein Releasewechsel von V5R2 nach V5R3 durchgeführt, seitdem funktioniert SNDNETSPLF sowie SNDNETF nicht mehr via QSNADS. Die Maschinen führen den Befehl einwandfrei aus aber es kommt nichts, weder von der 810 zu 825 oder umgekehrt. Lediglich die Meldung "Datei xxx an Benutzer 1 gesendet; an 0 nicht gesendet". Im WRKDSTQ ist alles gestartet, QSNADS auf beiden Maschinen wurde schon mehrmals beendet und neu gestartet. An den Warteschlangeeinträge etc wurde nichts verändert. Vor dem Releasewechsel lief es noch einwandfrei. Da sich mehrere Programme dahinter verbergen brauche ich die Übertragung via QSNADS. SNDTCPSPLF zum Beispiel funzt!!? Irgend jemand nen Tip an welcher Schraube man noch drehen oder wo man noch suchen kann?

Danke.
Gruß Stefan

[Fuerchau]

Prüfe mal per WRKDIRE die Einträge auf beiden Systemen (sind für SNADS erforderlich).
Mittels DSPDSTLOG mal auf Fehler untersuchen.

Klappt denn STRPASTHR (ANYNET erforderlich) ? Wenn STRPASTHR nicht funktioniert, klappt auch kein SNADS.

[SL]

Prüfe mal per WRKDIRE die Einträge auf beiden Systemen (sind für SNADS erforderlich).
Mittels DSPDSTLOG mal auf Fehler untersuchen.

Klappt denn STRPASTHR (ANYNET erforderlich) ? Wenn STRPASTHR nicht funktioniert, klappt auch kein SNADS.

Alle Einträge sind im WRKDIRE vorhanden. SPLPASTHR funzt einwandfrei. Im Protokoll steht auch nichts ungewöhnliches.

*ORG *NRM 23.05.05 12:28:29 DVxx USER S4405917 2112
*RTR *NRM 23.05.05 12:28:30 QMSFUSER S4405917 2112
*SND *NRM 23.05.05 12:28:30 S44AB260 USER S4405917 2112

[Fuerchau]

Auf der Gegenseite muss zum *SND-Eintrag ein *RCV-Eintrag passen.
Über WRKNETF *ALL wird nichts angezeigt ?

Wer löst den RCVNETF denn aus ?
Macht das ein Batchprogramm ?

Normalerweise erhält der User, an den gesendet wurde eine Nachricht die mit DSPMSG angezeigt werden kann. Tauchen diese Nachrichten auf ?

Mach mal einen SNDNETSPLF und prüfe ob dieser dann in der Defaultwarteschlange des Zielusers auftaucht.

[SL]

Genau das ja das Problem. Das Batchprogramm habe ich derzeit deaktiviert. Ich starte den SNDSPLF manuell von Hand und genau die angesprochene DSPMSG Anzeige taucht nicht wie sonst immer auf! Weder im WRKNETF *all weder in WRKDSTQ ist was zu finden. Auf beiden Maschinen keine Einträge diesbezüglich. Eine TCP Verbindung ist ja da, wie man an dem funktionierenden SNDTCPSLF erkennen kann. Der eigentlich Weg von QSNADS und STRPASTHR ist aber die Verbindung zwischen den beiden Maschine via TokenRing. Es wurde ja nichts an den Einträgen verändert und die Einträge sind bei Überprüfung auch alle da. Ich frage mich wo die Spools beispielsweise landen (SNDSPLF) wenn sie auf der Gegenseite nichts ankommen? Egal in welcher Richtung von 810->825 oder von 825->810. In beiden Fällen verschwindet der Spool scheinbar ins Nirwana.

[Fuerchau]

TokenRing auf V5R3 ???

Wenn die Systeme über IP verbunden sind (Ethernet) dann stelle die Verbindung auf ANYNET (SNAoverIP) um.

[Bruno Jakob]

Wir haben eine 825 und eine 520. Beide auf 5.3. Beide u.a. auch Token Ring. STRPASTHR (verwenden wir normalerweise nicht) geht hier auch ohne Anynet. Und QSNADS läuft ohne Probleme.

Wie ist denn der Konfigurationsstatus der Controller und Devices? Evtl. nochmal abhängen, anhängen.

Geben die Joblogs im Subsystem QSNADS was her?

Bruno

[SL]

Hallo,
ich habe heute Nacht beide Maschinen in den dedizierten Zustand versetzt und ALLES noch mal durchgestartet. Leider ohne Erfolg, es tut sich weiterhin wie oben beschrieben nichts. Ich befürchte das mir erst mal nichts anderes übrig bleibt als bis kommenden Sonntag zu warten, dann wird die 825 auch auf V5R3 umgestellt. Bis dahin muß ich mir wohl mit SNDTCPSPLF helfen oder gar ganz umstellen!? Garantiert läuft aber nachdem beide Release identisch sind alles wieder.
Ich berichte.
Bis dahin erst mal danke für die schnellen Antworten :-)
Gruß Stefan

[holly]

Genau das ja das Problem. Das Batchprogramm habe ich derzeit deaktiviert. Ich starte den SNDSPLF manuell von Hand und genau die angesprochene DSPMSG Anzeige taucht nicht wie sonst immer auf! Weder im WRKNETF *all weder in WRKDSTQ ist was zu finden. Auf beiden Maschinen keine Einträge diesbezüglich. Eine TCP Verbindung ist ja da, wie man an dem funktionierenden SNDTCPSLF erkennen kann. Der eigentlich Weg von QSNADS und STRPASTHR ist aber die Verbindung zwischen den beiden Maschine via TokenRing. Es wurde ja nichts an den Einträgen verändert und die Einträge sind bei Überprüfung auch alle da. Ich frage mich wo die Spools beispielsweise landen (SNDSPLF) wenn sie auf der Gegenseite nichts ankommen? Egal in welcher Richtung von 810->825 oder von 825->810. In beiden Fällen verschwindet der Spool scheinbar ins Nirwana.

Sie landen in der Verteilerwarteschlange :
mal mit WRKDSTQ anzeigen lassen. Sollte sie nicht auf warten stehen mit "2" senden.
Gruß Holger

[Frank Hildebrandt]

Hallo,

ein Kunde von mir hatte das gleiche Problem bei 5.3. In der Nachrichtenwarteschlange vom QSYSOPR stand immer eine Fehlermeldung, dass der Job QMSF abnormal beendet wurde. Also wenn Du im Subsystem QSYSWRK keine QMSF Jobs hast und und beim QSYSOPR etwas ähnliches protokolliert wurde, dann musst Du Dich an IBM wenden. Die haben hierfür ein PTF. Frag mich aber nicht wie die Nummer ist.

Frank

[KM]

Das Problem mit QMSF hatte ich auch schon. Da half ein ENDMSF und ein darauffolgender STRMSF MSGOPT(*CLEAR).

Gruß,
KM

[SL]

isch werd bekloppt ... dat wars ... :-) :-) :-)

STRMSF *clear eingegeben, hat allerdings fast 20 Minuten den Bildschirm blockiert, aber sofort danach lief wieder alles wie gewohnt. Super Tip. Wär ich nie drauf gekommen. So ganz versteh ich auch den Zusammenhang nicht, ist aber erstmal zweitrangig. Nochmals vielen Dank.

Gruß Stefan