F$ENV("PROCEDURE") in detached process

[Teofil Smolowicz]

You've used the magic word "correct".
T.

[Teofil Smolowicz]

The discussion gave me an idea how to solve the issue.

[Jon Pinkley]

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1138609

See attachment to replay dated Jun 22, 2007 17:00:12 GMT which has PPF.MAR (saved as .txt)

This will allow you to determine the filename associated with process permanent files, like sys$output, syst$input, or files openned with DCL.

I was surprised by the behavior you documented, but I was able to reproduce your results.

For more interesting results try the following input file:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ show log/proc
$ show log/job
$ show default
$ write sys$output f$environment("procedure")
$ write sys$output f$search(f$environment("procedure"))
$ ! following will need to removed or modified to see the effects of PPF
$ mcr utility:ppf sys$input
$ show sym /loc %%%_file_name
$ mcr utility:ppf sys$output
$ show sym /loc %%%_file_name
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Here are my findings:

default directory of the deteched process is set to the current default directory of process doing the run (this is why f$search works)
If your default directory is different than the directory that input command procedure is in, the specified name for the input file must use only names that are available after your login.com runs. Otherwise the input file will not be able to be found.

For example the following will not work:

$! assume input file in in your sys$login directory, and you current default directory is set to a subdirectory of your login directory e.g. [.itrc]
$ define inp sys$login:
$ run /input=inp:tmp.com /out=tmp.log sys$system:login.com

This will be what is in tmp.log

Error opening primary input file SYS$INPUT
Error in device name or inappropriate device type for operation


Wim's suggestion of f$search(f$environment("procedure")) seems to work any time that the input file can be found, at least in the limited testing I did. I can think of some cases where it is possible that it would not work correctly, where PPF sys$input would, but those would be race conditions where a new version of the tmp.com file was created between the run and the execution (I didn't reproduce this error case, although I see no reason it would not be a possibility, especially if the system was busy, and if run /prio=0 was specified.)

The downside of PPF: Not standard part of VMS. Works only for the file specified by /input. i.e. if tmp.com did an @abc, and in abc, and in abc.com there was an f$environment(procedure),

other threads with info about PPF.MAR

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1139459

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1198047

I am slso attaching a log of some of the testing I did.

Jon

[Robert_Boyd]

Why not use

/input='f$parse("tmp.com",,,"NO_CONCEAL")'

?

Properly done this will guarantee that the complete file spec will be passed to the detached process.

Robert

[Wim Van den Wyngaert]

It wasn't my suggestion Jon. He came up with it himself.

I use the solution f$parse of Robert.

Wim

[Teofil Smolowicz]

Robert,
Your f$parse call does not work! One "," is missing. ;-) Otherwise, an idea is good.

Thanks, all of you guys, for your contribution.
Teofil