Releasewechsel V4R5 auf V5R1 SNDNETSPLF

[SL]

HILFEEE! Hallo Forum, wir haben in unserem Hause zwei AS/400 Systeme im Einsatz AS/400-820 und AS/400-730. Am WE haben wir das AS/400-820 von V4R5 auf V5R1 umgestellt. Soweit so gut, allerdings funktioniert seit dem der SNDNETSPLF (in beide Richtungen) mit der anderen Maschine AS/400-730 nicht mehr und hier ist der Releasewechsel erst für nächste Woche geplant, auch von V4R5 auf V5R1. Kann das irgendwie mit den unterschiedlichen Releaseständen zusammen hängen das SNDNETSPLF nicht funktioniert.?
QNADS ist gestartet, die Verteilerwarteschlangen, alles okay, kurios ist das alles normal läuft, die Machine meldet die Spools als gesendet doch sie kommen nie dort an ?? Bin für jeden Tip dankbar.
Gruß SL

[Bodo Roggenkamp]

Hallo,

schau doch mal auf beiden Systemen ins Verteilungsprotokoll. Befehl DSPDSTLOG und evtl. mit Parameter ENTTYP(*ERR) auf fehlerhafte Verteilungen eingrenzen. Du sagst, Verteilerwarteschlange ist Ok. Hätte sonst noch vermutet,(da ja die Meldung kommt, das SPLF gesendet worden ist,) das die Verteilerwarteschlange nicht im Status Wartet bzw. Sendet steht.
Vielleicht findes Du im Protokoll ja einen Hinweis.

Gruss
Bodo

[akorb]

Hallo,

im "Read this first" zum Release V5R1 steht, dass es Probleme geben kann, wenn man SPLF's zu einem System kleiner V5R1 sendet.
Auszug:
The spooled output produced by an application created under V5R1 causes
problems if it is sent to a pre-V5R1 system when both of the following
conditions exist:

* The application uses the CCSID data description specification
parameter in the printer file.
* The application specifies *NOCONVERT as an optional parameter for the
printer file.

Failures occur when displaying these spooled files, or when printing
them using host print transform because there was no Unicode print
support prior to V5R1.

Wir verwenden SNDTCPSPLF. Damit haben wir keine Probleme.

Gruss
akorb

[SL]

Ich habe mal statt einen Spool (SNDNETSPLF) ein SNDNETF gestartet. Selbe Effekt, alles okay, doch nichts kommt an. Im DSPDSTLOG sind keine *ERR vorhanden. Die Vorgäng werden im DSTLOG fehlerfrei protokolliert.
Ein SNDTCPSPLF dagegen funktioniert einwandfrei, nur das nützt im Moment leider gerade nichts, da sämtliche Spoolverteilungen programmiert sind und dann via QSNADS verteilt werden.
Es gibt auch einen neuen Parameter im WRKSYSVAL "QMAXSPLF", der bezieht sich allerdings auf maximale Anzahl pro Job, hab diesem Wert trotzdem mal von '9999' auf '999999' gestellt, leider ohne Erfolg.

[froehlich]

Guten Tag,

vielleicht sind die USER auf beiden Maschinen nicht mehr identisch?
Gegenfrage: Wird bei einer RMTQUTQ ebenfalls der Befehl SNDSPLF intern benutzt?

Gruss Thomas

[SL]

Hallo, ja die User sind alle Identisch, ich habe sogar noch einmal die WRKDIRE alle überprüft. Auf der Produktionsmaschine werden Lieferscheine und Rechnungen generiert, diese werden nach Ausdruck per Programm via QSNADS auf die zweite Maschine gesendet und dort archiviert. Mein Verdacht das es Probleme mit dem Programm geben könnte hatte sich in sofern erledigt sich ja auch nun manuell nichts mehr via QSNADS in beide Richtungen senden läßt obwohl die Maschine ständig behauptet sie tuts. Sie sendet aber es kommt nicht an. So etwas ähnliches ist mir bekannt, allerdings war da die Plattenkapazität der Maschine bei knapp 95% was hier nicht der Fall ist.

[Ina]

Hallo,
hast du nach dem Releasewechsel alle Gruppen-PTFs installiert? Also CUM-Tape, Datenbank- und Hiper-PTFs?

Gruss
Ina

[PaulPanther]

Ich weiss nicht recht, ob das was damit zu tun hat...
... aber lieber einen unnützen Tip zuviel als einen nützlichen zu wenig...

In V5R1 gibt es einen bug in der QSYSWRK Subsystembeschreibung. Der Routing-Entry für den Rexec-Server hat einen falschen Vergleichswert. Das Ergebnis ist ähnlich: Keine Fehlermeldung, kein Hinweis auf den Job...
Den Fehler hatten wir zwar im Zusammenhang mit RUNRMTCMD, aber wer weiss ???

[Bruno Jakob]

Wir haben am Wochenende von 4.5 auf 5.1 umgestellt und der SNDNETF ging auch nicht. Ohne jede Meldung...
Ursache war, dass auf einem der beiden Systeme die QMSF-Jobs beim Starten gleich wieder abgebrochen sind. Ein STRMSF *RESET hat das Problem dann gelöst.

Gruß
Bruno

[rolf]

Hallo SL
Ich würde trotzdem noch die Speicherkapazität des Ziel-Systems prüfen.
Wenn die Disk-Belegung grösser als der Wert des ASP-Threshold ist, empfängt SNADS keine Daten mehr. Wenn das das Problem ist, hast du Meldungen im QSYSOPR, dass die kritische Spreichergrenze erreicht wurde.
Dann kann mittels STRSST, 3, 2, 3, die Grenze verändert werden. Disk aufräumen oder ausbauen sollte trotzdem noch gemacht werden.
Gruss
Rolf

[SL]

Erst mal vielen Dank für die vielen Antworten mit denen ich versucht habe das Problem zu lösen bzw. das Problem einzugrenzen. Tatsache ist das alles wieder rund läuft, ich allerdings nicht mehr so ganz nachvollziehen kann was der Grund dafür war. Ich habe alle Varianten, Tips und Tricks von Euch bis zum IPL durchgezogen. Es hatten sich bis dato tausende von Spools aufgestaut die fast 2 Tage gebraucht haben bis alle übertragen waren. Wo jetzt die Ursache des Problems tatsächlich lag kann ich nicht mehr nachvollziehen. Ich denke allerdings das bei den vielen Versuchen einer von den oben genannten Tips gegriffen haben muß. Nochmals dank.
Gruß SL
p.s. Sollte ich noch was in Erfahrung bringen werde ich es entsprechend anfügen.

[khm]

Hallo SL,

wir haben in der letzten März Woche einen Rel.-Wechsel von V4R5M0 auf V5R1M0 durchgeführt, und zunächst das alte System auf den aktuellesten Stand gebracht (PTF-mäßig). Dann haben wir bei IBM angefragt ob noch aktuellere PTFs vorliegen.

Dann ein CHKPRDOPT für alle Produkte für V4R5M0 sowie ein RCLSTG und RCLDLO durchgeführt.

Nach dem Rel.-Wechsel trat ebenfalls ein SNDNETSPLF-Fehler auf. IBM empfahl folgende PTFs:
SI08105 +SI06054, SI07930, SI07212, SI06926, SI08141.

Seither sind keine Probleme mehr aufgetreten.

Gruß
KHM