solution to RENAMEF losing on LIB:

[Dave Touretzky <Dave.Touretzky at CMU-10A>]

I asked Craig Everhart, a local TOPS-10 wizard, what it would take to
stop LOOKUP from looking on the LIB: device for RENAMEF, without losing
any flexibility (such as setting an ALIAS, or using SFD's.)  His answer
appears below.  (It's long...)


- - - - Begin forwarded message - - - -
Date: Mon, 28 May 79 19:40:00 GMT
Original-Date: Monday, 28 May 1979 1540-EDT
From: Craig.Everhart at CMU-10A
Subject: Re: LIB me alone
To:   DAVE.TOURETZKY at CMU-10A
CC:   Scott.Fahlman at CMU-10A
Message-ID: <28May79 154012 CE10@CMU-10A>
In-Reply-To: DAVE.TOURETZKY's message of 27 May 79 18:40
Origin:  C410CE10 at CMU-10A; 28 May 1979 1542-EDT

The bizarre thing happens when the LOOKUP finds the file on library
scanning; even if there is a library set, if the LOOKUP on the file
finds it without scanning libraries, the RENAME will work.  The problem
is that if it does find it using library search, the RENAME will fail
with some bizarre error -- ill seq of UUOs, I believe.  Doing an ENTER
to go into Update mode on the file will fail similarly.  And, no, there's
no way to ask LOOKUP not to search your libraries.

That's the general problem.  I've never tried to solve it in the context
of SFDs, but the solution generalizes to them.  Basically, if you really
want to know whether the RENAME will fail, you have to look at the place
where the file you found came out to being; you then (by hand) compare
that place with what you know to be the user's default directory path.
If the file is on the default path, you know you got the file without
resorting to library search, so you know the RENAME will fail.  If the
file is NOT on the default path, you got it from searching libraries,
or from searching SYS automatically, or from searching NEW, then SYS,
automatically.

The previous paragraph has an error; the directory path you compare the
file's path to is the default path for the job ONLY if there was no
PPN or path given to the LOOKUP.  If there was such a path, it supersedes
the job's spec entirely.  The bogus thing is that if you give LOOKUP a PPN or
path, the job's library, SYS, and NEW bits stay active.

Therefore, the algorithm is to find the principal path used by the LOOKUP.
This will be either the PPN or path given to the LOOKUP, or the default
path for the job.  Then, find the path where the file really is (with a
PATH. UUO), and see if you could have found the file using the principal
path that the LOOKUP used.  If so, a RENAME will zap the file; if not,
the RENAME will get some obscure error.

Elaboration of the above.  Any core image that does this kind of hackery
might as well find the job's default path at startup; you get this by
giving the PATH. UUO an argument of -1 and remembering the block of
directory info it gives you; this will look like a word of bits, a PPN,
and up to six SIXBIT SFD names.  The useful bit in the word of bits is
a bit called the scan switch.  If this is set to scanning, LOOKUPs that
look for files in the path and don't find it in the leaf directory will
try again in the next directory up the chain, ending in the UFD.  If the
bit is set to no-scanning, the LOOKUP will fail after the file isn't
found in the leaf directory.  Anyway, if the PATH. you give to determine
the job's directory path fails, use GETPPN to find out what the job's
default disk area is.

You can feed the LOOKUP UUO either zero in the directory field (PPN
word), or a PPN, or a pointer to a path block.  To get a path you
can use in the comparison, use the following.  If you gave LOOKUP
a zero (didn't specify a path or PPN), use the job's default path.
If you gave LOOKUP a path block, use it.  If you gave LOOKUP a
PPN, [I think] use a path block consisting of that UFD and NO
SFDs.

After a LOOKUP, you can feed PATH. a channel number, and it will tell
you just where the file that the LOOKUP found is.  This gives you the
requisite other path.

To compare paths, first you check if they're identical from the UFD
to the first zero or the sixth SFD.  If so, you got a match.  If not,
and if scanning is enabled in the path you fed LOOKUP (or job default,
etc., as above), see if the file's path is an initial subsequence of
the path LOOKUP saw.  If so, you match; if not, or if scanning isn't
enabled, you don't match.  If you didn't match, you then know you
found the file through library or SYS or NEW search, and a RENAME
(as well as an ENTER to go into update mode) will fail.

Simplification in the world of no SFDs:
If there are no SFDs in use (as at CMU), this process can be
simplified.  In this case, nobody feeds LOOKUPs pointers to PATH
blocks, since you can achieve the same effect by putting the PPN
word in the place you'd stick a pointer.  Getting the job's default
path amounts to feeding PATH. a -1, but only saving the one word
it returns as the default directory; if this fails, GETPPN will
work, as before.  PATH. given the channel on which a file has been
LOOKUPed, will return the PPN where the file lives; alternately, one
can use an extended LOOKUP, and the PPN word after one of those is
ALWAYS the UFD where the file was found.  (The 4-wd LOOKUPs fail
in this case since they overwrite the PPN with a perversion of the
file size.)  The check for did-LOOKUP-have-to-search-library
then amounts to seeing if the PPN where the file really is is
the same as the PPN: (if gave-LOOKUP-a-PPN then PPN-I-gave-LOOKUP
else job-default-PPN).


This is really a mess, I know.  The case that looks at SFDs is
particularly a mess.  The simplest thing to do may simply be to
try the RENAME and offer some intelligent interpretation for the
funny error code.  However, if you do the more general solution,
you'll be able to say stuff like

	File X.Y[C380ML5P] found on library search -- not deleted

rather than

	File X.Y found on library search -- not deleted

and the user will be perhaps less confused.

		Hope this clarifies your alternatives.

		Craig
- - - - End forwarded message - - - -