Tracked down another elusive, aggravating bug that exists back to MDOS221 and perhaps earlier. 

DATE:  APRIL 13 2009

SYMPTOMS:
When writing to a FIXED, RELATIVE file and the records are out of sequence,
records are written to an incorrect location within the file. 


PROBLEM:  [L8\RW-P2, L8\GETAUS]
Within the floppy DSR is a routine called GETAUS.  This routine identifies the
PHYSICAL sector which contains the record you wish to write.  It also allocates
new clusters based on free disk capacity.  (Clusters are three bytes in length and
contain a starting sector and maximum sector offset. Multiple clusters results
in file fragmentation. See HFDC manual page 63, Data chain pointer blocks.)

The GETAUS routine assumes the specified record is to be placed in the
first sector of a newly-obtained cluster.  Diskette capacity below 400K is
unaffected.

However, when  a disk exceeds the 400K threshold, sectors are no longer
equivalent to allocation units.  A 720K diskette requires 2 sectors per allocation 
unit, a 1.44MB disk 4 sectors per allocation unit.   

Test:
1. OPEN #1:"DSK1.TEST",INTERNAL,FIXED 254, RELATIVE
Opens a file TEST on DSK1.  No records are reserved. 
2. PRINT #1, REC 1:"RECORD 1" :: CLOSE #1
Print to record #1 and close file

RESULT: 
IF the file is opened on a 360K disk, the test succeeds.  However, on a 720K
diskette, the record is NOT written to record 1; instead, it is written to record
0!  Why?  At the time of the write, no clusters had been allocated. GETAUS
allocated two sectors (remember - 2 sectors per AU) but did not account for
the record number in its final calculations.  So, the routine returned the sector
number of the START of the cluster, which corresponds to record 0. 

FIX:
FILE: L8\RW-P2; FIXFIL routine
existing:
       BL   @GETAUS           get physical sector number from offset
       DATA BADOPC            disk full, all clusters used...

modified:
* after "mov  r6,@pathnm+4" modify as follows:
     MOV  R5,@TESCHR5
     MOV  R8,@TESCHR8
     BL   @GETAUS
     DATA BADOPC
     MOV  @PATHNM+4,R6
     MOV  @TESCHR5,R5
     MOV  @TESCHR8,R8
     BL     @GETAUS
     DATA BADOPC

* add to start of FIXFIL routine:

TESCHR5  DATA 0
TESCHR8  DATA 0

Though not the best fix, it does effectively solve the problem without 
modifying the base routine.  During the first pass, the cluster is allocated, 
during the second pass, the proper sector is identified based on the requested
cluster.

Further investigation is required to understand why GETAUS is flawed in the Geneve
DSR but not in the HFDC DSR.

Final note: HFDC DSR tests confirm the HFDC EPROM is unaffected by this
bug. 

Tim