This is odd.

When I run the following code as part of a larger more complex piece of code:

DOSFILENAME=C:\BACK\SCHEDULE.W01"

OSWRITE "" TO DOSFILENAME

and C:\BACK\SCHEDULE.W01 already exists the code will not null the file. If I do the following:

DOSFILENAME=C:\BACK\SCHEDULE.W01"

OSWRITE " " TO DOSFILENAME

Five spaces get written to the front of the file overwriting the first 5 characters of the file. I would expect to end up with a file containing just 5 spaces. .

However if I try and create a simple test function using the above to do this it works fine.

What the heck might cause OSWRITE to behave like this?

Here is why:

DosFilename=C:\BACK\SCHEDULE.W01"

Osopen DosFilename To File.Dos Then

Oswrite  "  " To DosFilename

Osclose DosFilename

End

Return

If the file is already open using Osopen then the Oswrite does not delete the file and write the new characters but just writes the new characters at the beginning of the file.

Has it always worked like this?

Jim ..

To the best of my knowledge this has been a problem in OI from the start. Never was in AREV. One way around the stray bytes in an existing file is OSBWRITE VAR … where VAR is null and the byte position is 0 (zero). You will also find that OSDELETE is unreliable as well.

Don M.

C3 Inc.

Don,

You will also find that OSDELETE is unreliable as well.

How so? This is how we've been working around the issue and haven't had any problems yet.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don ..

Client using win NT server with Win2000 service. There is a server connected via Wan which is where we create export files for processing. Every so often, we get stray characters in the first 5 bytes of the file. The following scenario is not reliable:

CHKFILE:

OSOPEN OUTFILE_VAR TO OUTFILE THEN

* file exists

 OSDELETE OUTFILE

 GOTO CHKFILE

END ELSE

 OSWRITE "" TO OUTFILE

• file created

END

So ..

OSOPEN OUTFILE_VAR TO OUTFILE THEN

• ask about overwrite

END

* unconditional write

POS=0

NULLVAR="

OSBWRITE NULLVAR TO OUTFILE AT POS

This seems to work consistently

Don M.

Don,

I can't remember having seen the symptom you describe, but neither have I (my clients) got your setup.

But I also have an OSCLOSE OUTFILE_VAR before the OSDELETE. You could try and see if it makes any difference.

- Oystein -

Oystein ..

I think I recall seeing something liket that ..

Here's my code snippet:

BEGIN CASE

       CASE OPT=1'

     	    OSCLOSE FVAR

          OSDELETE DEVICE:PATH:FILENAME

          GOTO CHK.FILE

       CASE OPT=2'

          OSCLOSE FVAR

          MSG(@WINDOW,'Insert New Diskette|Press OK when ready')

          GOTO CHK.FILE

  END CASE

END ELSE

  OSBWRITE "" TO DEVICE:PATH:FILENAME AT 0

  OSCLOSE FVAR	;* DEALLOCATE SPACE  04/12/2000 NETWARE BUG

* next re-open the file for use

…..

I thought I did that .. just wasn't sure…

Anyway, it MOSTLY works. I get tempted to just do a DOS delete on the sucker if it's there ..

Don M

Thanks for all the replies.

I have re-written the code to close the file after the open that checks for existence of the file.

Then I null it with an OSWRITE.

Then I re-open it for normal writing and this seems to work.

View this thread on the Works forum...