Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!VENUS.YCC.YALE.EDU!LEICHTER
From: LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
Newsgroups: comp.os.vms
Subject: re: Problem with F$PARSE
Message-ID: <8807291337.AA27492@ucbvax.berkeley.edu>
Date: 22 Jul 88 15:00:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 58


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