I forced EOF ON at the top of the code file, just in case it was being left off by some other code.
That fixed the problem. Apparently, when EOF is OFF, the APPEND option strips off one too may characters before writing the new data. It makes sense because EOF OFF causes fewer characters to be written to the end of the file when you OUTPUT SCREEN. Here is some code that writes a file correctly using APPEND It uses a nifty trick to drop the EOF after the file is created. SET EOF ON out c:\test.txt write 'Line1' out scr out c:\test.txt append write 'Line2' out scr out c:\test.txt append write 'Line3' out scr -- get rid of EOF after-the-fact SET EOF OFF out c:\test.txt append out scr SET EOF ON RETURN Dennis McGrath -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Rose Sent: Monday, May 14, 2007 9:59 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Weird DOS behavior Sugestions: OUTPUT filespec APPEND WRITE 'message', .var = w SET VAR the " 'message', .var" to a varfirst, then WRITE .varfirst Make it do a miltiple operation first, then the WRITE with a Single operation. RRR ----- Original Message ----- From: "Dennis McGrath" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[email protected]> Sent: Monday, May 14, 2007 6:59 AM Subject: [RBASE-L] - Weird DOS behavior > Has anyone seen this one? > > > > I'm running the latest build of RBDOS 7.5 but this has been a problem > before that version. > > > > I have some logging code that appends data to a log file. > > Each line is created by code like the following: > > OUT logfile.txt > > Write 'something', .vsomethingelse > > OUT SCR > > > > > > Funny thing is sometimes the lines are separate and sometimes they are > not. > > I looked at the file with a hex editor and the problem turns out to be > missing LF (CHAR(10)) characters. > > CR (CHAR(13)) characters are still there. > > > > The code does not change, the computer has not changed. > > Some days it works correctly and some days it does not. > > > > Anyone ever seen this? > > Solution? > > > > Dennis McGrath > > > > !DSPAM:46486c15119791557515124! >
