[net.micro.cbm] Relative file bugs!!!

elg@usl.UUCP (Eric Lee Green) (08/04/86)

At LAST! Finally, I found the relative file bug that's been driving me
batty!

Bug: If you try reading from the error channel right after you did a
relative file write, it corrupts the disk (1541) or blows the
directory track on BOTH drives (8050). It has no effect on the
SFD-1001 (gee, is Commodore aware of this bug, and fixed it?).

Re-create:
  position buffer to record 10, byte 10.
  print your variable
  input from the error channel
  position buffer to record 10, byte 20, etc.

  BOOM!!!! (somewhere in the process, haven't tracked down where).

I am just SOOO sick and tired of fighting relative file "features"! Is
there some book that gives more information about these "features"? No
don't tell me about the manual that comes with drive, I'm not in the
mood for jokes right now...

   Eric Green (Bayou Telecommunications Software ML guru, USL student)

-- 
-- Computing from the Bayous, --
      Eric Green {akgua,ut-sally}!usl!elg
         (Snail Mail P.O. Box 92191, Lafayette, LA 70509)

grwalter@watmath.UUCP (Fred Walter) (08/05/86)

A couple of relative file hints :

	1) send the record number not just once but twice 
	2) pause for ~1/5th second after doing 1) before doing anything
	   else involving the disk drive
	   (this may not be as necessary but it can't hurt)
	3) if you write data to the disk pause for about 1 second before 
	   doing anything else involving the disk drive

These cut down on relative file screw-ups alot. (This from previous
experience in BASIC and assembler relative file handling).

Another thing that can (and will) cause problems is having two disk
drives online at the same time - even if their unit numbers are different.

Relative files aren't that hard ... but if you can't get them to work
I could mail you a basic program that I have written that works
(and which is being used alot) which would show you how you could do
your relative file handling. (If enough people were interested in a
relative file handling example I could post ...)

			fred

UUCP  : {allegra|clyde|linus|decvax|utzoo|ihnp4}!watmath!grwalter
CSNET : grwalter%watmath@waterloo.csnet
ARPA  : grwalter%watmath%waterloo.csnet@csnet-relay.arpa

cbcscmst@cs1.UUCP (Michael Steven Temkin) (08/06/86)

I have a question for anyone out there who can answer it,
listen up Commodore.  A long time ago there was an advertisement in some
magazines about the SFD-1001 by Commodore, I never saw it
in stores, nor have I heard anything since.  Does this drive
still (if ever) exist, where can I find one, how much
are they, and are they 1541 compatible?  The above referenced article mentioned it and I would appreciate some help.

Thanx,

-- 
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
				Mike Temkin
				{inhp4,psivax,ttidca}!csun!cs1!cbcscmst
Ours is not to question why...Or is it?
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

drg@briar.UUCP (Don Gentner) (08/06/86)

In an article in RUN or Compute's Gazette a year or so ago (I could get
the reference if you're interested), it was claimed that some relative
file bugs could be avoided if you also positioned the pointer AFTER a
read or write.  I never checked this out myself, having memories of
earlier unhappy encounters with relative files.  It's amazing that such
a potentially useful feature was so badly done and documented.
				Don Gentner
				philabs!gentner

kjg@psuecl.BITNET (08/09/86)

     After reading the reply about the relative file errors I wanted to add
this:   The latest issue of Transactor Sept. 1986 vol 7, issue 2;  has a
very good article about the relative file problems.  The article is entitled
"Transcribe 64 a REl file copier utility"  this article is about and provides
 the software codes for a relative file copy utility.  However, the meat of the
article is about the relative file problems and fixes and procedures.  It might
be interesting reading to anyone working with these type of files.


Ken Goodnow