Submit in batch fails

[John Gillings]

Willem,

OK, so the filespec looks OK from this node.

Is this a cluster? Perhaps the queue manager is running on another node, and has a different view of devices or logical names?

[Willem Grooters]

All symbols used in the filespec used in the SUBMIT command are set within the procedure itself. Actually, it's just one: "here", derived from:

$ me=f$environment("procedure")
$ here=f$parse(me,,,"DEVICE")+f$parse(me,,,"DIRECTORY")

so a difference in f$mode() is not the problem here. As stated before, using the immediate output of f$environment has been used, both with, and without, "NO_CONCEAL" option in f$parse, without result.

And as the logfile output shows - with VERIFY enabled - all symbol translations are done - and properly.

LinkCount=1 holds for all files - even in SYS$LOGIN, which is another disk. Second, this is a 7.3-2 system.
So that isn't the cause either.

This is, indeed, a cluster. The queue used in the SUBMIT command is a logical, referring to a local queue, set autostart on that node only, not on both nodes:

Node1> sho log sys$batch
"SYS$BATCH" = "SYS$BATCH_NODE1" (LNM$SYSTEM_TABLE)

and

Node2> sho log sys$batch
"SYS$BATCH" = "SYS$BATCH_NODE2" (LNM$SYSTEM_TABLE)

Apart from the node name, the queue definitions are equal:

Nodex> sho queue/full sys$batch
Batch queue SYS$BATCH_NODEx, idle, on NODEx::
/AUTOSTART_ON=(NODEx::) /BASE_PRIORITY=4 /JOB_LIMIT=4 /OWNER=DEV
/PROTECTION=(S:M,O:D,G:R,W:S)
...

so if I submit the procedure to SYS$BATCH on node1, it will execute on node1 - and not on node2. That would, I think, rule out a difference in logicals and disks.
Nevertheless, I checked logicals on both systems; The device in the SUBMIT command refers the same device on both systems; this is a shadowed disk, that resides on a SAN; WWID's are the same on both systems (as it should be)

[Willem Grooters]

BTW: the queue mamager runs on this node only; not on the other node in the cluster.

[Willem Grooters]

node, nor queue matters. I tried the same SUBMIT command on the other system, and on another queue. Not any problem submitting it interactively, but in batch, it fails.

[Willem Grooters]

Got it:
somewhere in the login sequence, the definition of SYS$OUTPUT is reversed - which, of course, causes a loop:

> sho log sys$output
"SYS$OUTPUT" = "_NODE11$TNA972:" (LNM$PROCESS_TABLE)
> show log _NODE1$TNA972
"_NODE1$TNA972" = "SYS$OUTPUT" (LNM$PROCESS_TABLE)
1 "SYS$OUTPUT" = "_NODE1$TNA972:" (LNM$PROCESS_TABLE)

In batch, this leads to:

> sho log sys$output
"SYS$OUTPUT" = "_DSA7:" (LNM$PROCESS_TABLE)
> show log _DSA7
"_DSA7" = "SYS$OUTPUT" (LNM$PROCESS_TABLE)

Quite possible that SUBMIT doesn't like the circular reference (though SYS$INPUT and SY$OUTPUT refer to this device as well).

We're still investigating where this definition comes from. In the mean time, the workaround is:

$ oops=F$parse(";",me,,,"NO_CONCEAL") - ";"
$ if oops .nes. ""
$ then
$ oopsdev="_"+f$element(0,":",oops)
$ deass/process 'oopsdev'
...

Now submit succeeds.

[AEFAEF]

The question author wrote:

> Got it:
> somewhere in the login sequence, the definition of SYS$OUTPUT is reversed - which, of course, causes a loop:
>
> > sho log sys$output
> "SYS$OUTPUT" = "_NODE11$TNA972:" (LNM$PROCESS_TABLE)
> > show log _NODE1$TNA972
> "_NODE1$TNA972" = "SYS$OUTPUT" (LNM$PROCESS_TABLE)
> 1 "SYS$OUTPUT" = "_NODE1$TNA972:" (LNM$PROCESS_TABLE)

How can this be a loop as the equvialence name for SYS$OUTPUT is a terminal one?

$ show logical/full sys$output
"SYS$OUTPUT" [super,confine] = "_NODEX$NTA3:" [concealed,terminal] (LNM$PROCE
SS_TABLE)

(Terminal equivalence names are not translated.)

> In batch, this leads to:
>
> > sho log sys$output
> "SYS$OUTPUT" = "_DSA7:" (LNM$PROCESS_TABLE)
> > show log _DSA7
> "_DSA7" = "SYS$OUTPUT" (LNM$PROCESS_TABLE)

Still a terminal equivalence name, though not a concealed one:

$ SET NOVERIFY
Running FELDMAN's LOGIN.COM at 2009-07-10 19:19:46.99
$ show logical/full sys$output
"SYS$OUTPUT" [super,confine] = "_DSA1:" [terminal] (LNM$PROCESS_TABLE)
FELDMAN job terminated at 10-JUL-2009 19:19:47.08

So how can you get a loop from this?

>
> Quite possible that SUBMIT doesn't like the circular reference (though SYS$INPUT and SY$OUTPUT refer to this device as well).
>
> We're still investigating where this definition comes from. In the mean time, the workaround is:
>
> $ oops=F$parse(";",me,,,"NO_CONCEAL") - ";"

What is "me"?

> $ if oops .nes. ""
> $ then
> $ oopsdev="_"+f$element(0,":",oops)
> $ deass/process 'oopsdev'
> ...
>
> Now submit succeeds.

AEFAEF

[AEFAEF]

I wrote:

"

[...]

Still a terminal equivalence name, though not a concealed one:

$ SET NOVERIFY
Running FELDMAN's LOGIN.COM at 2009-07-10 19:19:46.99
$ show logical/full sys$output
"SYS$OUTPUT" [super,confine] = "_DSA1:" [terminal] (LNM$PROCESS_TABLE)
FELDMAN job terminated at 10-JUL-2009 19:19:47.08

So how can you get a loop from this?

[...]

"

Never mind. I was still thinking of the interactive case, I guess. I was thinking of SYS$OUTPUT going to DSA1 and stopping. Of course, one can use DSA1 and get into a loop. OK. Silly me. Need more sleep! Sorry to bother you.

AEFAEF