[comp.os.vms] Problem with F$PARSE

MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (07/19/88)

Gentle Readers,

I am writing a command procedure under VMS V4.7, batch, SYSTEM account, which
periodically polls the running system, looking for evidence of software
failure.  For example, it looks through directories for files which should not
normally exist.  If it encounters a problem, it sends notification to one or
more locations.

The directory searches have been producing bizarre output.  I reduced the code
to a minimum and showed it and its output to the Customer Support Center, and
they are clueless. I'm attaching it here.  In brief, an F$PARSE call appears to
stop returning a value after it has been called with identical arguments a
number of times.

Any assistance will be greatly appreciated.

Ed

--------------------------------------------------------------------------------
$LOOP:
$       CALL SUBR
$       GOTO LOOP
$
$SUBR:
$       SUBROUTINE
$       FILESPEC = F$PARSE ("SYS$SYSTEM", "*.*;*")
$       INSTANCE = F$SEARCH (FILESPEC)
$       SHOW SYMBOL FILESPEC
$       SHOW SYMBOL INSTANCE
$       ENDSUBROUTINE
--------------------------------------------------------------------------------
  FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
  INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
  FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
  INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
[...total of 36 repetitions]
  FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
  INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
[37th repetition and all afterwards: F$PARSE returns null value]
  FILESPEC = ""
  INSTANCE = ""
  FILESPEC = ""
  INSTANCE = ""
[...this is repeated apparently without end]
--------------------------------------------------------------------------------

LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/22/88)

	...[D]irectory searches [I've been using] have been producing bizarre
	output.  I reduced the code to a minimum and showed it and its output
	to the Customer Support Center, and they are clueless. I'm attaching
	it here.  In brief, an F$PARSE call appears to stop returning a value
	after it has been called with identical arguments a number of times.

	----------------------------------------------------------------------
	$LOOP:
	$       CALL SUBR
	$       GOTO LOOP
	$
	$SUBR:
	$       SUBROUTINE
	$       FILESPEC = F$PARSE ("SYS$SYSTEM", "*.*;*")
	$       INSTANCE = F$SEARCH (FILESPEC)
	$       SHOW SYMBOL FILESPEC
	$       SHOW SYMBOL INSTANCE
	$       ENDSUBROUTINE
	----------------------------------------------------------------------
	  FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
	  INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
	  FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
	  INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
	[...total of 36 repetitions]
	  FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
	  INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
	[37th repetition and all afterwards: F$PARSE returns null value]
	  FILESPEC = ""
	  INSTANCE = ""

It looks as if a GOSUB/RETURN sequence discards pending wildcard context;
every time you use F$SEARCH, you get a new search, from the first match.  If
you simply embed the loop in the subroutine, it works correctly.

As to why it stops after a while:  I'd guess that the wildcard context is
being lost, not closed.  After 37 repetitions, some DCL resource necessary to
open new wildcard searches is used up.

I tried using an explicit stream id, that is, I changed the F$SEARCH call
to:
	$       INSTANCE = F$SEARCH (FILESPEC,1)

but that didn't seem to change anything.

I also thought the problem might be that FILESPEC was being re-computed each
time - F$SEARCH compares the spec passed to it with the one it was working on
before to determine whether to continue the present stream or start a new one,
and it might have been comparing the string instance, not the string value.
However, moving the F$PARSE out of the loop - and even replacing it with just
a simple string - changed nothing.

It looks as if the stream id is "implicitly qualified" by the currently active
subroutine, in such a way that new invokations of the subroutine appear
distinct.

Sounds like a bug to me!  Either SPR now, or wait until you can try this out
on V5.
							-- Jerry

ijah400%ivax.DECnet@GOLD.BACS.INDIANA.EDU ("IVAX::IJAH400") (07/23/88)

"The Sysco Kid (McGuire,Ed)" <MCGUIRE%GRIN1.BITNET@CUNYVM.CUNY.EDU> writes:
< Gentle Readers,
<...
<                   I'm attaching it here.  In brief, an F$PARSE call appears to
< stop returning a value after it has been called with identical arguments a
< number of times.
<...
< ------------------------------------------------------------------------------
< $LOOP:
< $       CALL SUBR
< $       GOTO LOOP
< $
< $SUBR:
< $       SUBROUTINE
< $       FILESPEC = F$PARSE ("SYS$SYSTEM", "*.*;*")
< $       INSTANCE = F$SEARCH (FILESPEC)
< $       SHOW SYMBOL FILESPEC
< $       SHOW SYMBOL INSTANCE
< $       ENDSUBROUTINE
< ------------------------------------------------------------------------------
<   FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
<   INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
<   FILESPEC = "SYS$SYSROOT:[SYSEXE]*.*;*"
<   INSTANCE = "SYS$SYSROOT:[SYSEXE]AUTOGEN.PAR;23"
<...

CALL sets up a whole new procedure context, like @filespec does.  In other
words, don't use CALL anywhere where @filespec wouldn't work either.
Try using GOSUB/RETURN instead, e.g.:

$       FILESPEC = F$PARSE ("SYS$SYSTEM", "*.*;*")
$LOOP:
$       GOSUB SUBR
$	IF INSTANCE .EQS. "" THEN EXIT
$       GOTO LOOP
$
$SUBR:
$       INSTANCE = F$SEARCH (FILESPEC)
$       SHOW SYMBOL FILESPEC
$       SHOW SYMBOL INSTANCE
$	RETURN

     - Jim Harvey
     ijah400@indyvax (bitnet) or ijah400%ivax.decnet@gold.bacs.indiana.edu