A PB/CC (4.04.0042) program I've been using for many years has developed some weird problem I have so far not been able to debug.
First a code snippet:
The origin of the contents of DField$() are from a text input file. I read the input file one line at a time, then parse the columns into individual elements of DField$() before using them to set the values of several dozen variables including this one. In this case DField$(j) will have a value of something like "1.000000E-002" before being converted to a number and stored in a floating point variable.
This has worked fine for many hundreds of thousands of lines of input over several years.
Recently I found a situation where PercHA! is assigned a value of zero, even though DField$(j) has an appropriate value (such as "1.000000E-002").
For those rare times when PercHA! is assigned a value of zero, the following code will not detect the zero value:
When executed it will report:
PercHA! is not zero 0
I should point out that this only happens with one or two lines of input from an input file many hundreds of lines long. The way this program works is it reads a line of input, performs some complex math, writes the output, then reads the next line of input and does the whole process again. For the case when this problem occurs, the problem seems to be unrelated to the specific lines of input. By that I mean, if I run it and see the problem with the 37th and 62nd lines of input, and if re-run it I will always see the same problem with those two lines of input. If I then rearrange the input file so that those two lines are now the 1st and 2nd line of input, then the problem will not occur on those two lines, but will occur on some other lines (and not the 37th and 62nd again). So I don't think the problem is related to the input data.
Finally, another example of the odd behavior on the rare occasions when this problem occurs:
When executed will report:
PercHA! is not zero 0
PercHA! is not zero 0
If I replace the first line with
it still has the same behavior.
At this point I am guessing that this code is not the problem, but only the symptom of some other problem, like a memory overrun, or something . . . ? This is a large program with many variables, and it is very actively used (by me and many others over the past 8 yrs, although I wrote it) and we do not normally see anything like this happening.
Does anyone have any ideas about what I should try next? I'm really puzzled.
- Robert
First a code snippet:
Code:
PercHA! = VAL(DField$(j)) / 100!
The origin of the contents of DField$() are from a text input file. I read the input file one line at a time, then parse the columns into individual elements of DField$() before using them to set the values of several dozen variables including this one. In this case DField$(j) will have a value of something like "1.000000E-002" before being converted to a number and stored in a floating point variable.
This has worked fine for many hundreds of thousands of lines of input over several years.
Recently I found a situation where PercHA! is assigned a value of zero, even though DField$(j) has an appropriate value (such as "1.000000E-002").
For those rare times when PercHA! is assigned a value of zero, the following code will not detect the zero value:
Code:
IF (PercHA! = 0.0) THEN PRINT "PercHA! is zero"; PercHA! ELSE PRINT "PercHA! is not zero"; PercHA! END IF
PercHA! is not zero 0
I should point out that this only happens with one or two lines of input from an input file many hundreds of lines long. The way this program works is it reads a line of input, performs some complex math, writes the output, then reads the next line of input and does the whole process again. For the case when this problem occurs, the problem seems to be unrelated to the specific lines of input. By that I mean, if I run it and see the problem with the 37th and 62nd lines of input, and if re-run it I will always see the same problem with those two lines of input. If I then rearrange the input file so that those two lines are now the 1st and 2nd line of input, then the problem will not occur on those two lines, but will occur on some other lines (and not the 37th and 62nd again). So I don't think the problem is related to the input data.
Finally, another example of the odd behavior on the rare occasions when this problem occurs:
Code:
PercHA! = VAL(DField$(j)) / 100! IF (PercHA! = 0.0) THEN PRINT "PercHA! is zero"; PercHA! ELSE PRINT "PercHA! is not zero"; PercHA! END IF PercHA! = PercHA! + 1 IF (PercHA! = 0.0) THEN PRINT "PercHA! is zero"; PercHA! ELSE PRINT "PercHA! is not zero"; PercHA! END IF
PercHA! is not zero 0
PercHA! is not zero 0
If I replace the first line with
Code:
PercHA! = 0.001
At this point I am guessing that this code is not the problem, but only the symptom of some other problem, like a memory overrun, or something . . . ? This is a large program with many variables, and it is very actively used (by me and many others over the past 8 yrs, although I wrote it) and we do not normally see anything like this happening.
Does anyone have any ideas about what I should try next? I'm really puzzled.
- Robert
Comment