View Full Version : Jobs per RUNRMTCMD gehen nicht auf MSGW
Frank ter Duis
08-01-10, 14:16
Hallo,
in einem CL rufen wir beim RUNRMTCMD ein CL per CALL auf einer entfernten Maschine auf.
RUNRMTCMD CMD(&INTRMP) RMTLOCNAME(&INTTAR *IP) RMTUSER(&INTUSR) RMTPWD(&INTPWD)
Läuft dieses CL auf einen Fehler, steht es nicht auf MSGW sondern beendet sich.
Der "Master" Job läuft ohne Fehlermeldung weiter. Es wird lediglich ein Spool mit dem Fehler erzeugt.
An der RPLY List liegt es wahrschenlich nicht, dort haben wir schon alle Werte Testweise entfernt.
Warum läuft der Remote Job nicht auf MSGW?
Als Workaround, könnte man den Remotejob per SBMJOB submitten, dann muß aber noch im Hauptprogramm auf die Beendigung (per Remote DTAQ o.ä.) des Remotejob gewartet werden. Den Aufwand finde ich noch relativ hoch.
Kann ich dem RUNRMTCMD nicht irgendwie beibringen, das der Remotejob auf MSGW laufen soll?
Danke für Eure Hilfe
Frank
Wie lange soll denn der Job dann warten ?
Ich denke, dass RUNRMTCMD den Job auf dem Zielsystem per CHGJOB auf INQMSGRPY(*DFT) ändert.
Frank ter Duis
08-01-10, 15:07
Wie lange soll denn der Job dann warten ?
Ich denke, dass RUNRMTCMD den Job auf dem Zielsystem per CHGJOB auf INQMSGRPY(*DFT) ändert.
Das glaube ich nicht, da ich bei der RPY List alle Werte entfert habe, und der Job hat sich trotzdem beendet. Und in diesem Fall hatte er in der RPY List keinen Antwortwert.
Bau in das CL-Programm mal ein DSPJOB OUTPUT(*PRINT) ein und suche in der dazu erstellen Spooldatei mal nach INQMSGRPY.
Frank ter Duis
08-01-10, 15:23
Wie ich vermutet habe:
CPI1125 Information 00 08.01.10 14:52:47,084473 QWTPCRJA QSYS 010F *EXT *N
Nachricht . . . : Job 299315/$FTPH12_D/$FTPJOBDD übergeben.
Ursache . . . . : Job 299315/$FTPH12_D/$FTPJOBDD wurde von Job
299050/TERDUIS/QPADEV000T an Jobwarteschlange QBATCH in QGPL übergeben. Job
299315/$FTPH12_D/$FTPJOBDD wurde mit dem Befehl SBMJOB (Job übergeben) mit
den folgenden Jobattributen gestartet: JOBPTY(5) OUTPTY(5) PRTTXT()
RTGDTA(QCMDB) SYSLIBL(QSYS QSYS2 QHLPSYS QUSRSYS)
CURLIB(*CRTDFT) INLLIBL(EFINTD EHGGPL EHGPGM EHGDAT EHGWRK
EDPGM EDDAT EDWRK QGPL QTEMP EDSRC)
INLASPGRP(IASP_H12) LOG(4 00 *SECLVL) LOGCLPGM(*NO) LOGOUTPUT(*JOBEND)
OUTQ(/*DEV) PRTDEV(PRT01) INQMSGRPY(*RQD) HOLD(*NO) DATE(*SYSVAL)
SWS(00000000) MSGQ(QUSRSYS/TERDUIS) CCSID(273) SRTSEQ(*N/*HEX) LANGID(DEU)
CNTRYID(DE) JOBMSGQMX(16) JOBMSGQFL(*WRAP) ALWMLTTHD(*NO) SPLFACN(*KEEP).
Nein, ich meinte in das CL-Programm auf der entfernten Maschine.
Frank ter Duis
08-01-10, 15:30
Nein, ich meinte in das CL-Programm auf der entfernten Maschine.
Das ist von dem Remote Job der entfernten Maschine!
Bau doch mal wie gesagt einen DSPJOB OUTPUT(*PRINT) in das CL-Programm ein. Bei einem SBMJOB kommt die Einstellung für den Parameter INQMSGRPY doch aus der Jobbeschreibung (Standardwert *JOBD).
Frank ter Duis
08-01-10, 15:39
Ich entschuldige mich und behaupte das Gegenteil ;-):
Jobschalter . . . . . . . . . . . . . . . . : SWS 00000000
Antwort auf Anfragenachricht . . . . . . . . : INQMSGRPY *DFT
Abrechnungscode . . . . . . . . . . . . . . : ACGCDE *SYS
Drucktext . . . . . . . . . . . . . . . . . : PRTTXT '
Kann ich diese Verhalten den irgendwie unterdrücken. Als alternative würde ich als ersten Befehl im CL ein CHGJOB machen. Obwohl ich das etwas unglücklich finde.
Das ist aber die einzige Möglichkeit, wenn du auf MSGW gehen willst.
Allerdings wartet in diesem Fall dein Programm auch ewig.
*DFT nimmt die Defaultantwort aus der MSGID und eben nicht aus RPY, wie ich ja sagte !