Interactive and Batch F$Env("Procedure") Return Different Results

[Jeffery D. Urmann]

Hello OpenVMS Guru`s,

We`re running OpenVMS v7.3-1 on an Alpha 2100 4/275. A Command Procedure uses the lexical function F$Environment("Procedure"). When run interactively, it returns the correct (expected) disk location. When run from a batch job, it translates the disk information to something else.

The batch job appears to translate Sys$Common to Disk$ plus the volume label plus :[SYSCOMMON.

I hope the example below is a better explaination than the words above:

$ Show Default !location of Command Procedure
SYS$COMMON:[SYSMGR.ACCOUNTING]
$ Show Logical Sys$Common
"SYS$COMMON" = "$1$DKA0:[SYS0.SYSCOMMON.]"

$ Create 42.Com !Command Procedure
$ File = F$Environment("Procedure")
$ Show Symbol File
$ Exitzed

$ @ 42 !execute interactively
FILE = "SYS$COMMON:[SYSMGR.ACCOUNTING]42.COM;1"

$ Submit 42 /NoPrinter /Log ! submit to batch

FILE = DISK$HFA$SYSTEM1:[SYSCOMMON.SYSMGR.ACCOUNTING]42.COM;1

Yes, I know I can simply move the File to another location, but...

Why? Is this a bug? Is this a configuration error? Is this because batch views concealed, terminal logicals (Sys$Common) differently (certainly didn`t translate it correctly)? Is this expected behavior?

Please advise.

Enjoy,

--Jeff

[Hein van den Heuvel · Accepted solution]

Ah, yes. Funny you should ask that just now as we happen to indirectly discuss this recently in: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=760035

The reason is that the bach queue relies on FILE IDs, not file locations (in order to deal with temp files, and post-submit edits). F$ENV then uses a FILE-ID to NAME function to re-construct what migth have been the original name.
This in turn relies on proper BACKLINKs in directories.

The behaviour you see results from the jiggery pokery done with the multiple file entries for the one physical VMS$COMMON.DIR directory.

A solution could be to put the command file in the system specific sys$manager directory... or to reset back links. I forgot the optimal procedure for that, and it is probably no longer interesting now you know the problem. You can probably fix is clever RENAMEs or ANAL/DISK/REPAIR.

HINT: Consider passing the file name as argument for jobs requiring re-submitting themselves.


Hein.

[Hein van den Heuvel]

Argh... hate to re-reply in such short timespan. But here is a potential solution.
Sounds scary, and you do want to verify (with DIR/FILE) on your own system, but the solution may well be:


$ RENAME DUA0:[000000]VMS$COMMON.DIR;1 DUA0:[000000]OLDVMS.DIR;1
$ CREATE/DIR DUA0:[VMS$COMMON]
$ RENAME DUA0:[OLDVMS]*.* DUA0:[VMS$COMMON]
$ SET FILE/REMOVE DUA0:[SYS0]SYSCOMMON.DIR;1
$ SET FILE/ENTER=DUA0:[SYS0]SYSCOMMON.DIR;1 DUA0:[000000]VMS$COMMON.DIR;1

[HP Internal folks: VMSnotes_V5 topic 2500]

Hein.

[Jeffery D. Urmann]

Hein,

Thanx for such a quick reply.

While your explaination makes sense, I`m not yet convinced that this behavior is not a bug. I believe that the BACKLINKs are proper. Since VMS knows about the "jiggery pokery", why does Batch mung it?

Enjoy,

--Jeff

[Jeffery D. Urmann]

How do I correct the points awarded? Points above should be 7 instead of 10 and 3 instead of 0. Sorry for the newbie noise.

[Hein van den Heuvel]

Jeff>> Thanx for such a quick reply.

No problem, I just happened to be passing by :-).

Jeff>> I`m not yet convinced that this behavior is not a bug. I believe that the BACKLINKs are proper.

As you probably know, you can see the backlinks with:
PIPE DUMP/HEAD/BLOC=COUN=0 somefile | SEAR SYS$PIPE link
The is only one, numeric, backlink per file.
But there may be more than one directories pointing to the file. There may be multiple 'valid' pointers (as in, easy to reach through normal lookups), but some backlinks may have become dead-ends.

Consider the following silly scenario:
$ crea/dir [.tmp.a]
$ crea/dir [.tmp.b]
$ cre [.tmp.a]a.com
$write sys$output f$env("procedure")
Exit
$ set file/ent=[.tmp.b]b.com [.tmp.a]a.com
$ subm/noprint/log=a.tmp [.tmp.a]a.com
Job A (queue _BATCH, entry 366) started on _BATCH
$ subm/noprint/log=b.tmp [.tmp.b]b.com
Job A (queue _BATCH, entry 367) started on _BATCH

Please Notice how the defaulted job name became A... the original file name, where I submitted b.com

Now for the silly part

$ set file/nodir [.tmp]a.dir.
$ dele [.tmp]a.dir.
$ set prot [.tmp]a.dir.
$ dele [.tmp]a.dir.
$ subm/noprint/log=x.tmp [.tmp.b]b.com
Job (queue _BATCH, entry 368) started on _BATCH
$ sea *.tmp [
******************************
U$1:[HEIN]A.TMP;1

U$1:[HEIN.TMP.A]A.COM;1
******************************
U$1:[HEIN]B.TMP;1

U$1:[HEIN.TMP.A]A.COM;1

******************************
U$1:[HEIN]X.TMP;1

U$1:[?]A.COM;1

>> Since VMS knows about the "jiggery pokery", why does Batch mung it?

I used those words, copied from a 1989 internal note. And in fact, that VAX/VMS V5 timeframe is the last time I saw reports on this.

Batch has no chance to do it right, given that it uses file-id's.

>>> How do I correct the points awarded? Points above should be 7 instead of 10 and 3 instead of 0.

Apparently you can not fix points.
No big deal. Not to worry.
In fact it is great to see a 'newby' figure out the rules and try to do the right thing.

best wishes for the new year,
Hein.

[John Gillings]

Hein's explanation is correct, and the DCL to fix the backlinks is right MOST of the time, but there are rare circumstances where it's not possible to sequence the RENAMEs so that the backlinks are fixed correctly.

A safer way to fix backlinks is with DFU:

DFU> VERIFY/FIX SYS$SYSDEVICE

This will fix all possible combinations of incorrect backlinks.

If the original architect of VMS system disks had only chosen to call "VMS$COMMON.DIR" "SYSCOMMON.DIR" instead, there wouldn't have ever been a problem!

[Jan van den Ende]

Just for completeness:

The wrong backlink indeed _IS_ a bug.
It also describes your VMS as having already some history :-)

Somewhere in the V5-V6 timeframe BACKUP/IMAGE had some problems with /ENTERed directory names.
It always used the (alphabetically) first occurrence, whether originally created or /ENTERed.
And upon restore the FIRST occurrence was created as having the backlink pointer.
And since SYS0 comes before VMS$COMMON, the backlink pointed wrong.

The bug has long since been repaired, but MANY system disks that result from a restore of such saveset show this phenomenon. Any backup/restores or upgrades thereafter just left it as found.
... and since for normal operation it is not really important, it tends to stay unrepaired.

But woe to the system manager that should use this disk in a cluster-environment where for some reason the SYS0 root is removed!!

HTH

Proost.

Have one on me.

Seasonal greetings to all!

Jan

[Jeffery D. Urmann]

Thanx to all,

After removing the egg from my face, I see that the BACKLINKS are WRONG. So this is what crow tastes like.

I`ve been the local DECUS librarian for about fifteen years and I just now learn of DFU. What a great addition to my toolbelt. Thank you!

Speaking of DECUS... Whatever happened to DECUS anyway. Oh ya, palmer. Am I suppose to say that out loud. Sorry. 8)

Thanx again.

Enjoy,

--Jeff

[Aleksander Sinigoj]

The 42.com procedure invoked in batch mode shuld be compared to your terminal input in interactive mode.

To reproduce the same environment in batch you shuld builda a new procedure that runs 42.com and then submit it.

$ create 42b.com
$ @42.com
^Z
$ submit 42b.com /noprint

if you type the commands in interactive mode you get the terminal name as a result.

You can also consider to check f$enviroment("depth") - the DCL nesting depth - which is in your case 1 in interactive mode and 0 in batch.