There is a sequential file line limit in Basic?

[hotlnc]

Noted.  Thanks. I guess I should have placed my cursor on the # sign. It would have told me what it was...

[hotlnc]

Opps.  I was using an integer to count.  Using a long integer I get better line counts:

As far as I can tell, I'm getting an early End Of File. And always at the same spot. I'm processing 53,313 lines and that is it.

Using a different input file, I can process 51,770 lines and have good results.  The entire file is processed.

I've backed up to qb64-1.1-20160902.48 and got the same results, although this version doesn't like tab characters in the Basic language.

Do you guys have any ideas for me to try?

[Pete]

If one of those lines being read has a CHR$(26) in it, that's what is causing the read to stop. Sequential files read CHR$(26) as end of file, so the file ends, regardless if there are other lines in the file past it.

Try using FOR BINARY instead of FOR INPUT. BINARY is immured to the end of file character reaction. So if the works, that was the problem.

This may not be your problem, but it is something I discovered working with sequential files many years ago, when I included CHR$(26) as an arrow symbol in a help database. As soon as the read encountered it, the file stopped being read.

Pete

[hotlnc]

Thanks for the reply.

Changing "For Input" with "For Binary" made the program run much, much faster.  But same result.

I busted the input file into two parts -- one large; one small. the small one contains the chr$(26) spot.

Running the program on both files, I get good output from the larger, except it is missing the last line of the file.  The second file (about 850 lines) terminated at the same spot it did when it was all one file.

I've replace the listing area around where the there could be an embedded chr$(26), but got same result.

Do you remember how DOS marks the EOF?

 

[Pete]

Here is an example of how CHR$(26) acts differently in SEQUENTIAL vs BINARY file reading...

Code: QB64: [Select]

1. OPEN "forumtest.txt" FOR OUTPUT AS #1
2. PRINT #1, "This is an EOF character test."
3. PRINT #1, "The next line contains a chr$(26)."
4. PRINT #1, "Here is an " + CHR$(26) + " arrow character."
5. PRINT #1, "This concludes the test."
6. CLOSE #1
7.  
8. PRINT "Test #1 - Sequential"
9. OPEN "forumtest.txt" FOR INPUT AS #1
10. DO UNTIL EOF(1)
11.     LINE INPUT #1, a$
12.     PRINT a$
13. LOOP
14. CLOSE #1
15. PRINT
16. PRINT "Test #2 - Binary"
17.  
18. OPEN "forumtest.txt" FOR BINARY AS #1
19. DO UNTIL EOF(1)
20.     LINE INPUT #1, a$
21.     PRINT a$
22. LOOP
23. CLOSE #1
24.  
25.  

[SMcNeill]

If you think the issue is end of file termination, write a routine to check against LOF.

DO
  DO
     LINE INPUT #1, whatever$
     S = SEEK(1) 'know the byte position
  LOOP UNTIL EOF(1)
  IF S < LOF(1) THEN 'If position is less than the file length
     SEEK #1, S + 1 'advance past that termination character
  END IF
LOOP UNTIL S >= LOF(1)

[hotlnc]

Well, it passed your test. My problem is not an issue of an early EOF.

The passed result on your test forces me to look into the program for an error.

And I think I found the problem.

Code: QB64: [Select]

1.             IF (INSTR (MID$ (aIn, 23, 5), "0") = 1) OR (xMacro = 5) THEN    'macro and valid assembly lines only pass this point
2. Should read:
3.             IF VAL (MID$ (aIn, 23, 5)) > 0 OR xMacro = 5 THEN    'macro and valid assembly lines only pass this point
4.  

This is why the program was terminating early -- the line number went from 09999 to 10000 and failed the first conditional INSTR -- there was no ASCII "0" in position #1.
At first I fixed it by replacing "= 1" to "> 0". But that would limit the line number to less than 11111.

So I used the VAL statement and that allows  the number to be larger.

Thanks for the help guys.