HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

F$ENV("PROCEDURE") in detached process

 
SOLVED
Go to solution

F$ENV("PROCEDURE") in detached process

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
15 REPLIES
Wim Van den Wyngaert
Honored Contributor

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

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
Wim
Jan van den Ende
Honored Contributor

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

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
Don't rust yours pelled jacker to fine doll missed aches.

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

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

... detached processes , not "despatched processes" should be, of course / t.
Jan van den Ende
Honored Contributor

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

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
Don't rust yours pelled jacker to fine doll missed aches.

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

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
Wim Van den Wyngaert
Honored Contributor

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

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
Wim
Wim Van den Wyngaert
Honored Contributor
Solution

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

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
Wim
Wim Van den Wyngaert
Honored Contributor

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

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
Wim

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

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

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

The discussion gave me an idea how to solve the issue.
Jon Pinkley
Honored Contributor

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

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
it depends
Robert_Boyd
Respected Contributor

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

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
Master you were right about 1 thing -- the negotiations were SHORT!
Wim Van den Wyngaert
Honored Contributor

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

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

I use the solution f$parse of Robert.

Wim
Wim

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

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