topic Re: F$ENV("PROCEDURE") in detached process in Operating System - OpenVMS

F$ENV("PROCEDURE") in detached process

Teofil Smolowicz — Mon, 07 Apr 2008 11:16:06 GMT

F$ENV("PROCEDURE") called in detached process
gives only NAME.TYPE instead of expected full file.spec. OpenVMS version V7.3-2. Please explain why.
Test comproc: (TMP.COM)
$ write sys$output f$env("procedure")
Interactive test:
$ @tmp
USER$DISK:[EDTTSZ]TMP.COM;50
Detached process test:
$ run /input=tmp.com /out=tmp.log sys$system:loginout
%RUN-S-PROC_ID, identification of created process is 000DB60D
$ type tmp.log
$ write sys$output f$env("procedure")
TMP.COM

Re: F$ENV("PROCEDURE") in detached process

Wim Van den Wyngaert — Mon, 07 Apr 2008 11:25:27 GMT

In detached sys$login is not defined (and sys$scratch neither). And your input file is sys$login:tmp.com.

try specifying the full path and it will work.

Wim

Re: F$ENV("PROCEDURE") in detached process

Jan van den Ende — Mon, 07 Apr 2008 12:07:00 GMT

Teofil,

Wim said it.

But if you WANt or NEED a DCL environment in your detached process, then
RUN SYS$SYSTEM:LOGINOUT.EXE/INPUT=/OUTPUT=/ERROR=
hth

Proost.

Have one on me.

jpe

Re: F$ENV("PROCEDURE") in detached process

Teofil Smolowicz — Mon, 07 Apr 2008 12:21:30 GMT

Both SYS$LOGIN and SYS$SCRATCH are defined.
New test with this com.proc.
$ set nover
$ show log sys$login
$ show log sys$scratch
$ write sys$output f$env("procedure")
Run command:
$ run /input=tmp.COM /out=tmp.log sys$system:loginout
%RUN-S-PROC_ID, identification of created process is 0008A863
$ type tmp.log
$ set nover
"SYS$LOGIN" = "USER$DISK:[EDTTSZ]" (LNM$JOB_81975300)
"SYS$SCRATCH" = "USER$DISK:[EDTTSZ]" (LNM$JOB_81975300)
TMP.COM

Note that ANAL /SYS (sho proc /id=/chan)
displays full filespec input file.
Other tests show that f$env("PROCEDURE") just takes the value of /INPUT for despatched processes.

Re: F$ENV("PROCEDURE") in detached process

Teofil Smolowicz — Mon, 07 Apr 2008 12:27:00 GMT

... detached processes , not "despatched processes" should be, of course / t.

Re: F$ENV("PROCEDURE") in detached process

Jan van den Ende — Mon, 07 Apr 2008 12:30:19 GMT

Teofil,

>>>
Other tests show that f$env("PROCEDURE") just takes the value of /INPUT for despatched processes.
<<<

... which is exactly what you ask of it!

Try this TMP.COM

$! TMP.COM
$ @:
You will see that NOW you get NOT TMP.COM, but the @-ed COM file. This is exactly what f$ENVIR("PROCEDURE") is documented to do: return the currently executing command procedure.

Proost.

Have one on me.

jpe

Re: F$ENV("PROCEDURE") in detached process

Teofil Smolowicz — Mon, 07 Apr 2008 12:50:18 GMT

The help says: (help lex f$env atr)
"File specification of the current command
procedure."
It is what I expected: file specification.
Interactive does it, batch does it. Why not detached?
In the future I'll use
f$sear(f$env("procedure"))
instead for only f$env("procedure")

Thank you for your answers.
Regards --- Teofil

Re: F$ENV("PROCEDURE") in detached process

Wim Van den Wyngaert — Mon, 07 Apr 2008 13:01:54 GMT

You are right : it's when you run loginout with /detached that you don't get sys$login.

But it's still solved when you specify the full path name.

Wim

Re: F$ENV("PROCEDURE") in detached process

Wim Van den Wyngaert — Mon, 07 Apr 2008 13:08:03 GMT

It seems that if you do @, the correct thing is displayed.

But in detached, it displays exactly what you passed as input file name.

E.g. @xxxxx:tmp will show xxxxx:tmp (not xxxxx:tmp.com !).

Wim

Re: F$ENV("PROCEDURE") in detached process

Wim Van den Wyngaert — Mon, 07 Apr 2008 13:13:45 GMT

In the future I'll use
f$sear(f$env("procedure"))
instead for only f$env("procedure")

Be sure that your default dir hasn't changed.

Wim

Re: F$ENV("PROCEDURE") in detached process

Teofil Smolowicz — Mon, 07 Apr 2008 13:16:52 GMT

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

Re: F$ENV("PROCEDURE") in detached process

Teofil Smolowicz — Mon, 07 Apr 2008 13:32:17 GMT

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

Re: F$ENV("PROCEDURE") in detached process

Jon Pinkley — Mon, 07 Apr 2008 15:04:33 GMT

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

Re: F$ENV("PROCEDURE") in detached process

Robert_Boyd — Mon, 07 Apr 2008 17:26:47 GMT

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

Re: F$ENV("PROCEDURE") in detached process

Wim Van den Wyngaert — Tue, 08 Apr 2008 06:11:40 GMT

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

I use the solution f$parse of Robert.

Wim

Re: F$ENV("PROCEDURE") in detached process

Teofil Smolowicz — Tue, 08 Apr 2008 07:52:33 GMT

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