[net.micro] Microsoft BASIC problem

klick (08/20/82)

I have recently purchased a 2-year old Vector Graphics computer (S-100 CP/M).
In experimenting with a friend's program using random access files from
Microsoft BASIC (Version 5), I found out about a serious problem.
The EOF function doesn't seem to work properly.  If you are using random
access, but happen to be reading records in sequence, EOF appears to work.
However, when you are reading and writing random-access records in sequence,
EOF=-1 is returned when the record being read is entirely in the buffer from
the last operation.  (Obviously, this does not occur if the record
length is greater than or equal to the buffer size - 128 bytes in this case.)
An interesting sidelight is that even though EOF=-1 is returned, the GET
is successful - if you disregard EOF and just keep track of the number of
records in the file, you can get around the problem.
However, I would prefer that EOF worked.  Please mail me any info on correcting
this problem.

                              Thanks in advance,
                                 Vickie Klick
                                 ...!ihlpb!klick

mcmanis.mark@Usc-Eclc@sri-unix (08/21/82)

From: Mark Moulding <mcmanis.mark@Usc-Eclc>

Actually, the fact that MBASIC doesn't see EOF marks ( or physical EOF) in
random file mode is not really a bug after all.  First, since in random
mode the usual data that goes into the file is binary representations of
numbers and such-like, a ^Z (ascii EOF) is likely to appear at any time.
More important, however, is that it is possible to write (and subsequently
read) non-contiguous random records.  (e.g., I could do a PUT to records
1,10, and 100 on a file that I'd just created, and therefore empty.)  Thus,
there really isn't any true EOF.  Incedentally, if you try to read a record
(randomly) that hasn't been written, MBASIC is kind enough to fill the file
buffer with all zeros, thus causing all number conversions to return zero.

I agree, however, that it would be handy to have an easy way of finding the
last record.  (The function LOF is also of no use for this job.)  About the
simplest way seems to be to dedicate the first record as the file maintenance
record (which you'd probably need in any reasonable sized program anyway), 
and keep in it a pointer to the first free record.

					Mark
-------