- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Interactive and Batch F$Env("Procedure") Return Di...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-29-2004 03:20 AM
тАО12-29-2004 03:20 AM
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
$ Exit
$ @ 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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-29-2004 03:35 AM
тАО12-29-2004 03:35 AM
SolutionAh, 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-29-2004 03:40 AM
тАО12-29-2004 03:40 AM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-29-2004 07:00 AM
тАО12-29-2004 07:00 AM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-29-2004 07:12 AM
тАО12-29-2004 07:12 AM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-29-2004 09:36 AM
тАО12-29-2004 09:36 AM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-29-2004 03:08 PM
тАО12-29-2004 03:08 PM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-30-2004 12:29 AM
тАО12-30-2004 12:29 AM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-30-2004 08:42 AM
тАО12-30-2004 08:42 AM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-04-2005 10:59 PM
тАО01-04-2005 10:59 PM
Re: Interactive and Batch F$Env("Procedure") Return Different Results
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.