As Gilda Radner, playing Emily = Latella said “Never mind!”

The way I was testing led me to an erroneous conclusion.

Norm’s remarks below are = correct.

I had actually searched for this = exact string earlier in the execution of the procedure this call is in, =

so it was correct that it returned = a zero length string to me.

I have fixed = it.

Thanks for the = replies.

Mike = Farrell

From: norm.raphael@metso.com [mailto:norm.raphael@metso.com]
Sent: Wednesday, May 07, = 2008 3:01 PM
To: = Info-VAX@Mvb.Saic.Com
Subject: Re: DCL anomaly = with the DCL Lexical f$search

Pls see below.

"Ken Robinson" <kenrbnsn@gmail.com> wrote on 05/07/2008 02:33:31 = PM:

> On Wed, May 7, 2008 at 2:05 PM, <norm.raphael@metso.com> wrote:
> >
> >
> >
> >
> > "Farrell, Michael" <MFarrell@Voltdelta.com> wrote on 05/07/2008 01:46:44 = PM:
> >
> >
> >
> > > Has anyone = encountered this.
> > >
> > > Here's a snippet = from a DCL procedure I am working on:
> > >
> > > $ UPDATE_FILE =3D f$search("''RCV_LOCN'''RCV_FILE'")! = f$search(INPUT_FILE)
> > >
> > > RCV_LOCN has a value = of "S04:[AM_TESTS.MIKES]"
> > > RCV_FILE has a value = of "BSTBOTH_2008103.*"
> > >
> > > When this code is = executed it returns to UPDATE_FILE a null string so
> > > that UPDATE_FILE =3D "".
> > >
> > > This is wrong = because the file it alludes to is there:
> > > Directory S04:[AM_TESTS.MIKES]
> > >
> > > = BSTBOTH_2008103.211436;25
> > > = 6448/7232 = 7-MAY-2008 12:27:59.37
> > > = .
> > > = .
> > > = .
> > >
> > > When I write the = line without the comment, it works properly.
> > >
> > > $ UPDATE_FILE =3D f$search("''RCV_LOCN'''RCV_FILE'")
> > > UPDATE_FILE = =3D " BSTBOTH_2008103.211436;25".
> > >
> > > Why does the "! f$search(INPUT_FILE)" make a difference to the = working
> > > of the f$search = command?
> > >
> > Not on my OpenVMS. = Something else must be going on.
> > > TIA
>
> Doing my own = testing...
>
> OpenVMS V7.3-2
>
> Procedure:
> $ rcv_locn =3D "dis:[krobins9.downloads.testing]"
> $ rcv_file =3D = "test.*"
> $!'f$ver(1)
> $ UPDATE_FILE =3D f$search("''RCV_LOCN'''RCV_FILE'") ! update_file = =3D
> f$search(input_file)
> $ sho sym = update_file
> $ UPDATE_FILE =3D f$search("''RCV_LOCN'''RCV_FILE'") ! update_file = =3D
> f$searh(input_file)
> $ sho sym = update_file
> $ UPDATE_FILE =3D = f$search("''RCV_LOCN'''RCV_FILE'")
> $ sho sym = update_file
> $!'f$ver(0)
>
> Dir output:
> Directory = DIS:[KROBINS9.Downloads.testing]
>
> test.file;1 = test_search.com;2
>
> Total of 2 files.
>
> Command procedure = output:
> $ @test_search
> $!0
> $ UPDATE_FILE =3D f$search("dis:[krobins9.downloads.testing]test.*") = !
> update_file =3D = f$search(input_file)
> $ sho sym = update_file
> UPDATE_FILE =3D "DIS:[KROBINS9.Downloads.testing]test.file;1"
> $ UPDATE_FILE =3D f$search("dis:[krobins9.downloads.testing]test.*") = !
> update_file =3D = f$searh(input_file)
> $ sho sym = update_file
> UPDATE_FILE =3D = ""
> $ UPDATE_FILE =3D f$search("dis:[krobins9.downloads.testing]test.*")<= br> > $ sho sym = update_file
> UPDATE_FILE =3D "DIS:[KROBINS9.Downloads.testing]test.file;1"
>
> Notice that I misspelled f$search in = the second comment and that
> caused a similar problem. Not = good.
>

This is behaving as documented.
The first call of f$search finds the one instance of the wildcarded = filename.
The second call of f$search does not find another instance in the context =
and so it returns the null string.
The third call of f$search starts over.
The comment has nothing to do with anything, but remember that f$nnnn is =
enough for DCL to act on (or f$s, where s is a unique lexical name starting = string)

Try creating six or seven versions of test.file and see what = happens.

> Ken