Download TMQ Vol IV.i - tim

Volume IV.i
THE MISOSYS QUARTERLY - Fall
idge, VA: Dear Roy, During last year, we
had a rather abundant correspondence on
the troubles I was having with the XLR8er
board. In summary, out of three 4D's of
1987/1988 vintage, one didn't work correctly and two did. Subsequently, another
went on the blink, leaving only one with
the XLR8er. I continued working that
one.
One of the problems I had last year was
doubling up of the same file on the same
disk with the same name, and this was
covered in TMQ ffl.i., page 67. The patches
you provided for SYS2, SYS 12 and
BACKUP were duly applied by me (and
included in Michel Houde's patches)
together with a system configuration that
includes DELAY.
I am attaching several printouts: A directory of a disk with a repeated file; a
printout from DEVICE (B) showing delay turned on and three printouts from
FED2 showing your patches applied.
I am forced to put this computer with
XLR8er on ice pending any possible solution to file doubling up.
Fm Charles A. Ainsworth: As stated
therein, my letter of March 23 explained
that one of my 4D machines, the last one
with an XLR8er, had gone on the blink
and had been doubling up files on floppy.
You replied on a return copy of my letter
of April 12 "It's really a DOS problem!
I'm looking into it."
I also stated that the machine with the
XLR8er had been put on ice and that I had
to borrow a machine to keep going, but
that's a situation I can't maintain for long.
Now, it's over three months since I advised you of the problem. To date I have
no solution. I can't keep the borrowed
computer any longer. So which way do I
go from here? Seems the only answer will
be to yank and dump the only remaining
XLR8er as I did with the other two I had.
Volume IV.i
concerning my previous note relative to
your multiple identical file names on one
diskette" problem. In my previous note, I
may have been a little hasty in claiming a
DOS problem, but then my initial evidence suggested that. Let me bring you up
to date on my findings.
Your problem, as well as that reported by
a few other folks, seems to occur when a
particular file is opened for writing a large
number of times. Programs which open a
file for output typically use the DOS @IMT
service call. In order to understand the
nature of the problem, let me first provide
a brief dissertation on @INIT. This SVC
first issues an internal call to @OPEN, in
case the file is already in existence. The
OPEN function checks for the availability of the disk first by calling @CKDRV.
If @CKDRV succeeds, OPEN looks for
the file on that disk drive so checked. It
then reports success or failure back to
@INIT. If OPEN can open the file, then
the @INIT request is satisfied. If OPEN
fails to open the file, @INIT then attempts to create a new file. To do that, it
has to find an available diskette, which
may in fact be a single drive if the file
specification included a drive spec. If
@CKDRV succeeds, then INIT creates
the file.
Assume fora moment what would happen
if the first @CKDRV called from OPEN
fails to detect that a specific drive, targeted by the drive spec, did not contain a
diskette even though a diskette was loaded;
CKDRV reports the failure back to OPEN
which reports the failure back to INIT.
INIT then proceeds to create a new file.
Further suppose that the second call to
@CKDRV by @INTT succeeds in detecting the loaded diskette. INIT creates a
second instance of the file specification in
the directory; a multiple file is created.
The above scenario is not fiction; it is
exactly what is happening in these cases
of multiple files.
Okay, in order to confirm that operation,
I ran the following BASIC program:
Fm MISOSYS, Inc: Dear Charles, This
is in response to your letter of June 26th
DOS Subjects
1989
- 27
-
With the "TESTFILE/DAT" previously
created, all the program does is attempt to
open the file, close it, then wait for about
six seconds for the drive to de-select and
turn off the drive motor. It then repeats the
sequence. This bypasses the @INIT sequence, which I first used, but I subsequently narrowed the problem to a failure
of OPEN. Note that during the operation
of the program, the system drive is a
MemDISK so that no disk access need be
made to get the DOS overlays.
Starting from a cold machine, I was generally able to get through one run of 300
without failure. My test machine was a
gate array Model 4P. However, I could
not get through two runs. If I upped the
loop counter tenfold to 3000, I could
never get through a single sequence. Yes,
that is punishing the drive!
Okay, that4P had anXLR8erin it with the
Houde patches which adjusted the
@CKDRV timers to compensate for the
increased speed. So I decided to try another machine, this time a Model 4D
(obviously a gate array). The behavior
was identical to the 4P. Running the same
test program under Model Ill mode LDOS
5.1.4 and LDOS 5.3,1 never got a failure.
That's why I initially suspected the DOS;
Both 6.3 and 6.2 failed the test program
but LDOS 5.1 and LDOS 5.3 worked.
I subsequently used this machine for a
detailed analysis. I dug into all of the code
thatwas executedwithin@CKDRV, tracing through all of the calls into the system
- including the floppy disk driver. The
@CKDRV code uses the sensing of the
index hole to confirm or deny the presence of a rotating diskette in a disk drive.
It is a function of the disk drive to send the
index hole status to the floppy disk controller. The FDC shows (or is supposed to
show) a "1" bit in its status register when-
DOS Subjects