Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site nicmad.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!uwvax!astroatc!nicmad!brown
From: brown@nicmad.UUCP
Newsgroups: net.micro.cbm
Subject: Re: (old) Sequential file problem
Message-ID: <577@nicmad.UUCP>
Date: Wed, 19-Mar-86 17:51:15 EST
Article-I.D.: nicmad.577
Posted: Wed Mar 19 17:51:15 1986
Date-Received: Sat, 22-Mar-86 02:17:36 EST
References: <687@ark.UUCP>
Reply-To: brown@nicmad.UUCP (Mr. Video)
Organization: Nicolet Instrument Corp. Madison WI
Lines: 31

In article <687@ark.UUCP> lesmem@vu44.UUCP (Lesmeister Marco) writes:
>
>The question is this :
>
>	How can I write data to a sequential file and overwrite the old
>	file with the same name, when I don't know for sure if there is
>	a file with that name.
>	I know now that there is a problem when I use the '@' option
>	and there is no file to overwrite, but how do I solve this.

I am going to give this answer, which many of you will probably argue
about, but it DOES work.  I will explain why after I said it.

Yes, use the @ option, but use it as follows:   @0:FILENAME,S,(W or R)

The general rule, to get around the BAM problem, is to ALWAYS use the
0: as part of any drive operation.  When you save the program, use
the SAVE @0:PRGNAME.  That is what I am doing right now and haven't had any
trouble.

The COMPUTE! magazines did an article about this problem, and they found that
by using the drive 0: option, you can keep the 1541 from screwing up.

Send all flames to /dev/null
-- 

              ihnp4------\
            harvard-\     \
Mr. Video      seismo!uwvax!nicmad!brown
              topaz-/     /
             decvax------/