SPR: Bug in NFT on Tops-10 7.04
Rich Alderson
on the Living Computer Museum's 2065[1], and ran into an interesting problem
which we thought at first was a dreadfully obscure bug in the MDE.
End-stage testing consisted of using NFT to copy files from the RP06[2] to an
emulated drive, and then from there to a second, to a third, to a fourth. The
copy from the RP06 to an MDE drive proceeded flawlessly; on copying to a second
MDE drive from the first, two files would not copy, with an error message which
said that a "Ludicrous line number" had been detected. On the other hand, the
monitor COPY command, which uses PIP, had no such problem.
This was driving the MDE designer crazy.
Now, the files in question are binaries (one is a copy of the monitor), so
there shouldn't be any line number checking going on. I decided to have a look
at the lowest-level details, to see what each program was doing. Much fun was
had as I built NFT (and its prerequisite, SWIL) and PIP with DDT in them, but
I was finally able to look at what was going on.
NFT was indeed deciding to do an ASCII byte-at-a-time transfer of these files,
and so was looking at bit 35 of each word to see if it were on. It would then
look at a 7-bit byte and decide if it were between 060 and 071, and complain if
not.
The HELP file for NFT didn't say very much, so I located NFT.MAN on a tape at
Trailing Edge, and found that there were switches to change transfers from the
default. /DATAMODE:IMAGE worked just fine. That was the end of a very long
day, so I went home.
The next morning, as I was driving in, I thought about file mode settings in
the RIB, and tried a different experiment. I used PIP (via COPY) to put things
onto an MDE drive from the RP06, then NFT to go from the MDE drive to another.
Hey, presto! It worked! But an NFT copy from the second to a third failed
with the LLN error.
I now knew what was going on, and declared the MDE innocent of wrongdoing and
fit for service. I did try the reverse (using NFT from the MDE to the RP06,
from a good directory on an MDE drive), then RP06 directory to directory, and
also got the LLN error on the latter.
What's happening is that NFT is not setting the file mode on files it creates
when it operates in default mode, and when it finds 0 = ASCII mode on these
later it does the wrong thing in default mode.
I consider this a bug, and would submit it to Colorado Springs, but there's no
one there who gives a rat's fuzzy arse about this kind of thing any longer.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
jmfbahciv
NFT should have preserved the data mode of the file when copying unless
the setting was overridden. suggestion: take a look at the files
that were loaded for the copies. You can find the full file spec
by typing
SET W F
See if the SWITCH.INI or path files, which are used to set up
default switches have something that overrides
those datamodes.
also do a
DIRECT foo.bar/DETAIL of the file you copied in both places.
another trick is to do a binary compare of the first copy
with the second copy.
R FILCOM
TTY:=FIRST.foo,SECOND.foo/B
I don't believe NFT has a bug unless it was introduced with
7.04. I know the version shipped with 7.03 was certified and
didn't have that kind of bug.
/BAH
jmfbahciv
I just took a sniff at your system disk bits. I wish I had KL1026
to compare it with....
The [1,2].UFD file has a mode setting of 0. I do not know
if NFT uses this value when if does a copy; that might
be something to debug.
Do a
DIRECT [1,2].UFD/DETAIL
Then do a similar command for some other UFD that was created after
you did the initial installation. the modes I found was 10 and
17.
How did you create the UFDs on the MDEs?
Also try do do a FIND or search on all the MCOs. ISTR a bug
having to do with mode 0 and UFDs but I would need JMF
to pinpoint which version of the monitor and where the edit
happened.
/BAH
/BAH
John Francis
>Rich Alderson wrote:
>
>I just took a sniff at your system disk bits. I wish I had KL1026
>to compare it with....
I know where the actual KL1026 is - it's one of the bits of DEC hardware
at the Computer History Museum. I don't think 1042 is there, though.
jmfbahciv
/BAH