Operating System - OpenVMS
1828340 Members
3114 Online
109976 Solutions
New Discussion

Re: f$verify(0) from a program

 
SOLVED
Go to solution
dschwarz
Frequent Advisor

f$verify(0) from a program

Hi,

we want to do something like this (using fortran):

rtc = lib$spawn('dcl_proc',,mbxname,CLI$M_NOWAIT,,pid)

where mbxname represents a mailbox. This works fine, but with VERIFY on in the caller's environment, we get all the DCL of 'dcl_proc' in the mailbox. With SET NOVERIFY as the first line of 'dcl_proc' we still see that line in the mailbox.

How can we disable the caller's verify flag before calling lib$spawn and set it back to its original value after lib$spawn has completed. ?
13 REPLIES 13
Karl Rohwedder
Honored Contributor
Solution

Re: f$verify(0) from a program

Insert as 1st line of procedure:

$ tmp = 'F$verify(0)'

regards Kalle
dschwarz
Frequent Advisor

Re: f$verify(0) from a program

Ok, that works.
But we have to insert this as the first line in every procedure that will be traeted this way.
Is there a solution that can be implemented in the function which calls lib$spawn ?
Wim Van den Wyngaert
Honored Contributor

Re: f$verify(0) from a program

and
$ tmp='f$verify(tmp)'
as the last statement. Or it will stay off.

Wim
Wim
Volker Halle
Honored Contributor

Re: f$verify(0) from a program

I don't think there is an API available for turning off the DCL image and procedure verification bits from a program.

You could write some routine, which goes into supervisor mode to implement this...

But how about some intermediate DCL-procedure, which handles the verify flags and then calls the desired DCL-procedure, specified as a parameter like:

rtc = lib$spawn('new_proc dcl_proc',,mbxname,CLI$M_NOWAIT,,pid)

new_proc could then turn off verify, call dcl_proc, reset verify and exit.

Volker.
Wim Van den Wyngaert
Honored Contributor

Re: f$verify(0) from a program

But you can do a spawn with f$verify as command to change it (e.g. at startup of the program).

Wim
Wim
Volker Halle
Honored Contributor

Re: f$verify(0) from a program

Wim,

>But you can do a spawn with f$verify as
>command to change it (e.g. at startup of
>the program).

this would not turn off SET VERIFY in the main process, only in the sub-process, which would then exit immediately.

Volker.
Hein van den Heuvel
Honored Contributor

Re: f$verify(0) from a program

How about NOT feeding spawn the command file directly. Give it an input mailbox.
Send the 'f$verify'() first, then (probably!) send an $define sys$input sys$command, then feed it the @'file'?
Just a thought...

Or bulk-edit those command files already.
No big deal, possibly less work than reading these replies.

Hein.
dschwarz
Frequent Advisor

Re: f$verify(0) from a program

Great answers.

I think we will 'Bulk edit' the procedures and give Hein's idea a try.

Thank you very much.
Wim Van den Wyngaert
Honored Contributor

Re: f$verify(0) from a program

Oeps. Volker is right.

But you can pass @x y
and do the F$ver in x.com and then do @y in x.com

fwiw

Wim
Wim
x2084
Trusted Contributor

Re: f$verify(0) from a program

You can append the f$verify to the @ command like in

$ cre huhu.com
$ show time
$ write sys$output "huhu
Exit
$ @huhu
17-DEC-2008 10:50:11
huhu
$ @huhu !'f$verify(1)
$ show time
17-DEC-2008 10:50:31
$ write sys$output "huhu
huhu
$ @huhu !'f$verify(0)
17-DEC-2008 10:50:39
huhu
$
Jess Goodman
Esteemed Contributor

Re: f$verify(0) from a program

Perhaps this is just too obvious, but...

Why not just turn verify off right before running the program that does the LIB$SPAWN calls ?
I have one, but it's personal.
Jess Goodman
Esteemed Contributor

Re: f$verify(0) from a program

And another simple solution - instead of this call:

rtc = lib$spawn('@dcl_proc',,mbxname,CLI$M_NOWAIT,,pid)

Use this call:

rtc = lib$spawn('SET NOVERIFY','dcl_proc',mbxname,CLI$M_NOWAIT,,pid)
I have one, but it's personal.
John Gillings
Honored Contributor

Re: f$verify(0) from a program

If you're going down the bulk edit route, instead of summarily turning verification off with:

$ v='f$verify(0)'

I'd recommend using a modular construct that lets you control verification for a particular procedure externally. This allows for selective debugging, even as the structure of multiple procedures gets highly complex. I start most of my DCL procedures with:

$ verf='F$VERIFY(F$TRNLNM(F$PARSE(F$ENVIRONMENT("PROCEDURE"),,,"NAME")+"_VERIFY"))

By default verification is turned off, but if there's a logical name _VERIFY visible to the process, with value "1", verification will be enabled. The final line is:

$ EXIT %X10000000.OR.F$INTEGER(stat)+(F$VERIFY(verf).AND.0)

This will (silently) restore verification to its previous state, return status "stat" and set the STS$V_INHIB bit to surpress the status code from generating a message.
A crucible of informative mistakes