Submit in batch fails

[Willem Grooters]

This is part of a procedure :[].COM:

$ if f$mode() .eqs. "BATCH" .and. f$environment("DEPTH") .eq. 0 .and. action .eqs. "REQUEUE"
$ then
$ submit/hold/log='CmdLogdir'/keep/noprint/queue='quenam' -
/param=("''prcnam'", "''quenam'", "''action'") -
/name="START_''prcnam'" -
'here'Proc.COM
$ endif

All symbols are properly set and correct. The file does exists;

When this code is executed from the batch procedure, SUBMIT is unexpectedly failing:

$ if f$mode() .eqs. "BATCH" .and. f$environment("DEPTH") .eq. 0 .and. action .eqs. "REQUEUE"
$ then
$ submit/hold/log=:[]/keep/noprint/queue=SYS$BATCH -
/param=("WG", "SYS$BATCH", "REQUEUE") -
/name="START_WG" -
:[].COM
%SUBMIT-E-INVFILSPE, invalid file specification :[].COM;36
%SUBMIT-F-CREJOB, error creating job
-SYSTEM-S-NORMAL, normal successful completion

and the job is not submitted.

However, entering the exact statement in an interactive session, submits the job. But when released, the same error occurrs.

The file mentioned (including version) does exist on the specified location.

I used the same construct in other procedures on the same system without a problem, so why is this one failing?

[Hoff]

Occam's Razor says that the DCL symbols are not as expected, or the file does not exist, or the RMS syntax is unsupported by the version, or that there are a mix of local and global symbols, or the device is not mounted from the host dealing with the queue.

Insert some diagnostics into the DCL code, and verify that the file is present and accessible.

And in general, I usually trim the file version number off of any SUBMIT-related file processing specification as it tends to lead to problems when somebody edits the DCL procedure; the file is either missing (if a PURGE was directly or indirectly invoked) or an older version is activated.

[Jess Goodman]

Is SUBMIT redefined (either as a DCL command symbol or as a logical name) for batch processes to run something other than SYS$SYSTEM:SUBMIT.EXE ?

The error messages displayed do not appear to be from VMS's SUBMIT. SUBMIT.EXE would display the CREJOB message first, and the final NORMAL message shouldn't be there. I'm not even sure how to get SUBMIT.EXE to output INVFILSPE.

My theory might seem like a long shot, but I redefine SUBMIT for batch processes at my site to run a replacement submit program I wrote. Among other designed differences, my program checks for /USER=username and then ignores it if the process is running under that username. For us this cuts way down on SYSUAF contention and it prevents bogus errors for users without CMKRNL.

[Jess Goodman]

Ok, forget my last theory. I was just able to reproduce the error messages your post shows by attempting to submit a process permanant file:

$ open/read junk login.com
$ submit junk/queue=junkq
%SUBMIT-E-INVFILSPE, invalid file specification JUNK:.;
%SUBMIT-F-CREJOB, error creating job
-SYSTEM-S-NORMAL, normal successful completion

The INFILSPE message from my example displays the logical name from the OPEN, instead of the full file specification shown in your post, so your problem can't be exactly what I did. But it might be worth checking if there is a CLOSE command needed before the SUBMIT.

[Jess Goodman]

Here's a way I just found to get the a full file specification to show up in the error message:

$ OPEN/WRITE DSKC JUNK.COM
$ SUBMIT DSKC:[GOODMAN]LOGIN.COM;36
%SUBMIT-E-INVFILSPE, invalid file specification DSKC:[GOODMAN]LOGIN.COM;36
%SUBMIT-F-CREJOB, error creating job
-SYSTEM-S-NORMAL, normal successful completion

[Hoff]

Which is a file that doesn't exist. In this case, triggered by a logical name redirection. (The OPEN /WRITE is one path around creating a logical name, and a DEFINE can get there, too.)

These cases of misdirection can usually be identified with an f$search or an f$file or other such DCL just prior to the SUBMIT to verify the input.

I tend to display the result of the f$file NOCONCEAL knob for these cases, just before the SUBMIT command.

[John Gillings]

Willem,

It looks to me like there's something wrong with the symbol. It would help if you included the exact text of the error message. Preceding the failing command with $ SHOW SYMBOL HERE would also assist in debugging.
If that is the exact text of the message then why is symbol "here" set to ":[]"?

For self resubmission, I use:

$ self=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))

...
$ SUBMIT/whatever 'self'

this will continue to work regardless of name changes to the procedure, and will always select the latest version of the procedure.

If your code is working in interactive mode, but failing in batch mode, the most likely reason is bad back links on the disk. Use DFU to check and/or fix. Is this a system disk? Try:

$ DUMP/HEAD/BLOCK=COUNT:0 SYS$SYSDEVICE:[000000]VMS$COMMON.DIR

Confirm that the filename is "VMS$COMMON.DIR" and the "Back link file identification" is (4,4,0).

[Willem Grooters]

Company rules prescibes removal of any identifying information; but I checked, and doublechecked, that symbols and logicals are correct.

I added some extra information to show the submitted file does actualluy exist and has the right attributes, and shows SUBMIT has not been re-defined in some way:

$ if f$mode() .eqs. "BATCH" .and. f$environment("DEPTH") .eq. 0 .and. action .eqs. "REQUEUE"
$ then
$ if f$search("''here'.COM") .nes. ""
$ then
$ show symbol/local/global submit
$ show log/full submit
$ dir /full 'here'.COM
$ submit/hold/log='logdir'/keep/noprint/queue='quenam' -
/param=("''prcnam'", "''quenam'", "''action'") -
/name="START_''prcnam'" -
'here'.COM
$ else
$ write sys$output "File NOT FOUND????????"
$ goto eoj
$ endif
$ endif

and the result is similar:

$ if f$mode() .eqs. "BATCH" .and. f$environment("DEPTH") .eq. 0 .and. action .eqs. "REQUEUE"
$ then
$ if f$search(":[].COM") .nes. ""
$ then
$ show symbol/local/global SUBMIT
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
$ show log/full SUBMIT
%SHOW-S-NOTRAN, no translation for logical name SUBMIT
$ dir /full :[].COM;0

Directory :[]

.COM;38 File ID: (104528,8,0)
Size: 7/101 Owner: [,]
Created: 9-JUL-2009 11:20:11.09
Revised: 9-JUL-2009 11:20:11.10 (1)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 101, Extend: 0, Global buffer count: 0, No version limit
Record format: Variable length, maximum 0 bytes, longest 98 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWE, Group:, World:
Access Cntrl List: (IDENTIFIER=,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
Client attributes: None

Total of 1 file, 7/101 blocks.
$ submit/hold/log=:[.V2008B.GKB.LOG]/keep/noprint/queue=SYS$BATCH -
/param=("GKB_WG", "SYS$BATCH", "REQUEUE") -
/name="_WG" -
:[].COM
%SUBMIT-E-INVFILSPE, invalid file specification :[].COM;38
%SUBMIT-F-CREJOB, error creating job
-SYSTEM-S-NORMAL, normal successful completion
$ErrExit:

[Willem Grooters]

John,

DUMP/HEADER shows backlink is (4,4,0) and filename is VMS$COMMON.DIR.
So that looks Ok to me.

DFU is not allowed in this environment :(

[Willem Grooters]

@John:

Just noticed you mentioning the system disk. No, the procedure runs from another disk (in other words: is not SYS$SSYDEVICE:).
I cannot imagine that it would matter that this disk is shadowed, or would it?