DCL command 'SUBMIT' exit status check

[Joost van der Knaap]

Hi all,

This concerns a DCL script that resubmits itself.
I would like to verify the exit status of the submit command executed by the script.

Relevant code:
$ PIPE 'SUBMITCMD' | (read sys$pipe p9 ; DEF/JOB P9 &P9)
$ RESULT = f$trnlnm("P9")
$ IF F$LOCATE ("Job CDRC",RESULT) .NES. F$LENGTH(RESULT)
$ THEN
$ CALL LOGTHIS "''RESULT'" "IN"
$ ELSE
$ CALL LOGTHIS "''RESULT'" "ER"
$ ENDIF

Where IN and ER reflect the severity (IN = informational, ER = error). I'm wondering if the test conditions are sufficient. This should depend on whether or not the return messages of SUBMIT can also start with 'Job CDRC' for any kind of failure. I don't think it does, as I expect failures to be logged in system messages formatting (%facility-s-identification, text).

Is there a list of possible exit messages for SUBMIT?

[Craig A]

Joost

Can you not just check $STATUS of the SUBMIT?

$ SUBMIT <script>
$ STATUS := '$STATUS'
$ IF STATUS
$ THEN
$ ! Success processing
$ ELSE
$ ! Failure processing
$ ENDIF

Craig

[Joost van der Knaap]

Hi Craig,

I could, but I would like to log the exact message.

[Craig A]

Joost

Can you please explain what you are ultimately trying to achieve?

You could redirect sys$output to a temporary logfile and then interrogate that:

$ DEFINE/USER SYS$OUTPUT SUBMIT.LIS
$ DEFINE/USER SYS$ERROR SUBMIT.LIS
$ SUBMIT <script>

Craig

[Joost van der Knaap]

Goal 1: Differentiate between success and failure of SUBMIT.
Status: Fully met?

Goal 2: Be able to see in the log why a SUBMIT command failed.
Status: Fully met through subroutine LOGTHIS

Goal 3 (ultimate): solution combining goal 1 and goal 2.
Status: Fully met?

As you said, goal 1 can be achieved through $STATUS, but then I would not capture the error reason to feed it to the LOGTHIS subroutine.

The main reason why I started this thread was to learn whether or not I have already met goal 1 by checking the return string for the text 'Job CDRC'. The docs on system error messages and on the SUBMIT command I've found haven't convinced me that there couldn't be an error condition that would result in a string that passes the F$LOCATE check.

I kind of like the method of storing the returned string as a logical instead of a temporary logfile.

[Craig A]

Joost

Can you not just pass SUBMIT.LIS through to the subroutine LOGTHIS to do something useful with it?

Craig

[Joseph Huber_1 · Accepted solution]

Why not combine status check and output logging ?
Instead
$ IF F$LOCATE ("Job CDRC",RESULT) .NES. F$LENGTH(RESULT)
use
$if f$integer($SEVERITY).eq.1

and leave anything else as is, but do not derive success/error from a particular output string.

[Joseph Huber_1]

In addition:
if You really want to log the full submit error message in a separate log-file, then a single read is not enough: those usually are two lines, example:

MPIW10_HUB>pipe submit xyz | (read sys$pipe p9 ; DEF/JOB P9 &P9)
MPIW10_HUB>sh log p9
"P9" = "%SUBMIT-F-OPENIN, error opening DISK$HUBER:[HUBER.SOURCES.C]xyz.COM; as input" (LNM$JOB_81838080)
MPIW10_HUB>submit xyz
%SUBMIT-F-OPENIN, error opening DISK$HUBER:[HUBER.SOURCES.C]xyz.COM; as input
-RMS-E-FNF, file not found

The single read from pipe only gets the %SUBMIT-F line, the important second line giving the reason (-RMS-E-FNF...) is not logged!

[Craig A]

Also, if it wer me, I'd be performing validation of certain things before doing the actual SUBMIT:

Username (if /USER I BEING USEd)
Filename - F$SEARCH
Queue - Exist? in started state?

Craig

[Joost van der Knaap]

@Joseph:
Thanks for suggesting f$integer($SEVERITY). I didn't even try that as I thought it would no longer relate to SUBMIT due to the stuff that happens between it and the IF statement.

@Craig:
Valid points. In my case resubmitting is pretty much the first thing it does so I can be reasonably sure the file still exists as does the user.