From: ADVAX::A_VESPER "Andy V" 20-SEP-1984 15:24 To: REX::MINOW Subj: fseek error Line 94 of FSEEK is: CLR V$BCNT(r4) ; force $$get to read the record FPUT contains CALL $$FLSH ; flush previous record $$FLSH has a sequence: MOV V$RBSZ(r4),r1 ; get buffer size SUB V$BCNT(r4),r1 ; r1 := byte actually in buffer BNE 15$ ; Flush if there's data ... 15$: CALL $$PUT ; write it out Thus, the bug seems to be that FSEEK assumes you are reading the file and clears V$BCNT to ensure $$GET actually gets a record. (I think the comment should say $$GETC, not $$GET because $$GET always gets a record). I think that the following fix will work. Change line 94 in FSEEK to: BIT #VF$WRT!VF$APN,V$FLAG(r4) ; reading or writing? BNE 998$ ; writing CLR V$BCNT(r4) ; reading BR 999$ 998$: MOV V$RBSZ(r4),V$BCNT(r4) ; writing -- free count := buffer size MOV V$BASE(r4),V$BPTR(r4) ; pointer := buffer address 999$: I will make this change and test it out today or tomorow. By the way -- reading $$FLSH (IOFLSH.MAC) I noticed the following sequence: MOV V$BASE(r4),r0 ; get record buffer address BNE 10$ ; br if there is a buffer CALL $$ABUF ; get a buffer [MARK] BNE 10$ ; continue if ok ; ; No buffer space available -- we must exit back to original caller ; CLR R0 ; return zero (or NULL) JMP CRET$ ; return to original caller I think the line marked with [MARK] should be: BCC 10$ ; continue if OK Because the two exit sequences from $$ABUF (IOABUF.MAC) are: Success: mov V$RBSZ(r4),(r4) ;Set V$BCNT -- all bytes free clc ;Return C-bit off return ;Got it this time. Failure: bis #VF$ERR,V$FLAG(r4) ;Set error code in fdb, too sec ;Return C-bit on return ;r0 == 0 Both sequences return status of Z = 0 (in PSW) and thus the original line will always branch. Do you see any side-effects from these changes? Thanks, Andy V Thu 20-Sep-1984 15:22 Mill Time -- Andy Vesper MLO 5-2/U12 DTN (22)3-9005