f$verify(0) from a program

[dschwarz]

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. ?

[Karl Rohwedder · Accepted solution]

Insert as 1st line of procedure:

$ tmp = 'F$verify(0)'

regards Kalle

[dschwarz]

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]

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

Wim

[Volker Halle]

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]

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

Wim

[Volker Halle]

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]

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]

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]

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

[x2084]

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]

Perhaps this is just too obvious, but...

Why not just turn verify off right before running the program that does the LIB$SPAWN calls ?

[Jess Goodman]

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)

[John Gillings]

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.