f$verify(0) from a program

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