[Info-vax] test (directory and searchlist)

[Hein RMS van den Heuvel]

On Nov 11, 1:38 pm, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> I'm really surprised that I have seen NO REPLIES to a recent post.  I
> see the post on my local news server, and everything else looks normal.
>
> Please send me an email if you see this post, but only on 11 or 12
> November.
>
> Thanks!

I see this note.
And a couple of days ago I saw the one you are probably referring to
about Directory behavior and search lists.
I did not reply there because it sounded too much like work to give a
proper reply, and vague hand waving is not my style.
I do however have hands on experience with that, and even extended
investigatition time back in 1992 while working of RMS Engineering. I
seem to recall (hand waving!)  that  even back than there was no
concise answer and  in the end we left the code as it was, based on
the old OpenVMS adage... soneone may have come to rely on this
behaviour, no matter how crooked it seems.

We specifically looked into it in the context of the linker seemingly
going crazy if an object was NOT found while processing lots of file
on lots logical names with searchlists (the OpenVMS build
environment).
The linker was not really to blame. It was RMS trying each and every
permutation of each and every search list component references in a
related file spec.. which for the linker, and directory, is every
prior entry passed along.
In the end we gave the linker an option to remember less, and left
directory alone... as you notice.

I _believe_ this is happening:
Say you have provided A:[X], B:[Y] in an RLF (Related File Name Block)
Now RMS is going to look in A:[X], A:[Y], B:[X] and B:[Y]. Surprised?
Making A and B the same string does not make RMS prune the options and
thus it will try and find your file in [X] twice.
Makes sense... as an explanation? Maybe.
Makes sense as a behavior? I don't think so.

IF I recall correctly, the powers that were in place, deemed these
unexpected combined results desirable, and thus we left it, in fear of
'breaking the build' mostly and because few (no) customers complained
as to how it worked.

Hein.