I am creating a DOS file with a text of a constant size in lines, but not constant line per line in width, with information to bill customers. The file gets large enough (60 MB). The writing to the file is being done with OSBWRITE. I had experienced a strange problem: when writing "record" by "record" (considering each text of constant lenght in lines a record) to the file, the file ended up with missing text. It is possible to check the integrity of the file because each text of each customer has a secuencial number. Then I made up a program to check that after the fixed number of lines should come the next secuencial number. The file created by several runs of the process of generation of the file failed the test in different points. Editing the file I saw that in that point of failure a portion of the last text wrote was repeated (say (n-1)th text), the nth text wasn't present, and the (n+1)th text began, but the length of the nth text wasn't the correct one. So the file was screwed up.

From this forum I read an answer of Steve Smith, pointing a bug in the OSBWRITE with an offsets whose MOD(OFFSET,65536)= 21930. I added logic to test this offsets, but the problem remained. I modified the program to write blocks of 32K to the file, and then it worked!. I tested several times the new version and all the files passed the check.

Is there some problem OSBWRITEing with random (not constant) offsets, that goes away OSBWRITEing blocks of 32K ?

Also, I made up a program to intentionally write before and after the 21930 offset, but worked well in all cases.

Eduardo,

The 21930 bug can also be solved by doing an OSOPEN directly before each read/write.

You might try FLUSH ahead of each file write.

You should have write-behind caching switched off in Windows, if this is possible.

If you post your code we can assist further.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks for the interest.

When the first version of the program failed, I wrote several versions of the code, each one with a different possible way to solve the problem, so I could test them one by one. The two main solutions that I intended to try were:

1. To write text of exactly 32K blocks

2. To open the file before each OSBWRITE/OSBREAD (actually, there wasn't any OSBREAD in the original code, it was added to avoid the 21930 offset).

The 1 was the first tested, and it worked, so because a matter of time, left as the one...

The code is very simple, I reproduce the parts in wich the OS sentences are used here:

 OSWRITE "" TO ARCHIVO_ORIG

 OSWRITE "" TO ARCHIVO_DUPL

 OSWRITE "" TO ARCHIVO_CTRL

* Two files are created, the original and the duplicate of each text,

* the third is a control file

 OSOPEN ARCHIVO_ORIG TO FP_ORIG ELSE ALL_OK=0

 OFFSET_ORIG=0

 OSOPEN ARCHIVO_DUPL TO FP_DUPL ELSE ALL_OK=0

 OFFSET_DUPL=0

* ALL_OK is used to stop the program at the first problem

 BLOQUE_ORIG='

 BLOQUE_DUPL='

* This variables are intended to accumulate text to 32K

…

LOOP

(Here comes some code to loop through the file of clients, and a

 call to a subroutine that makes up the text to write in each file)

  MAKE_TEXT(XXXX,TEXTO_ORIG,TEXTO_DUPL,XX,X,X,X)

  GOSUB WRITE_TO_DOS

REPEAT

RETURN

WRITE_TO_DOS:

SWAP @FM WITH CRLF$ IN TEXTO_ORIG

BLOQUE_ORIG := TEXTO_ORIG

IF LEN(BLOQUE_ORIG) GE 32768 THEN

   DIF_ORIG   =LEN(BLOQUE_ORIG) - 32768

   GRABA_ORIG =BLOQUE_ORIG1,32768

   RESTO_ORIG =BLOQUE_ORIG32769,DIF_ORIG

   OSBWRITE GRABA_ORIG TO FP_ORIG AT OFFSET_ORIG

   ERROR_OS=STATUS()

   IF ERROR_OS EQ 0 THEN

      OFFSET_ORIG=OFFSET_ORIG + 32768

   END ELSE

      GOSUB SHOW_OS_ERROR

      TODO_OK=0

   END

   IF DIF_ORIG ] 0 THEN

      BLOQUE_ORIG=RESTO_ORIG

   END ELSE

      BLOQUE_ORIG='

   END

* Exactly the same code follows, but with the _DUPL in place of _ORIG

RETURN

I will try to test the second solution, to see if the results are

the same. Do I need to test the 21930 offset if I open the file before each OSBWRITE?

]] Do I need to test the 21930 offset if I open the file before each ]] OSBWRITE?

No. A fresh OSOPEN before each OSBREAD should prevent the bug.

Why 21930? In binary it's alternating ones and zeros.

The Sprezzatura Group

World Leaders in all things RevSoft

Steve Smith documented that:

21930 Decimal is used as an I/O error flag in AREV and G2B

(AA55 hex=21930 Decimal=1010101001010101 Binary). Doesn't

happen in OI.

Don Miller

View this thread on the forum...