View Full Version : Releasewechsel V4R5 auf V5R1 SNDNETSPLF
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
17-03-03, 12:26
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
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
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.
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
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.
Hallo,
hast du nach dem Releasewechsel alle Gruppen-PTFs installiert? Also CUM-Tape, Datenbank- und Hiper-PTFs?
Gruss
Ina
PaulPanther
18-03-03, 16:07
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
31-03-03, 08:48
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
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