We also have the same problem with one of our files. We have a program
that logs records to two flat files (One serves as a backup and is on
seperate drives) from multiple sources. Several other programs read
through the main log file and every so often they hit a block of nulls and
abort.
Interesting twist 1: We never see the block of nulls in the backup file,
and our recovery is to overwrite the primary file with the backup.
Interestign twist 2: Some times a couple of the reading programs will have
successfully read past the problem area, when a program hits the area and
aborts. This seams to indicate the error occurs when transaction manager
posts the data two disc?
We have been seeing this problem for a long time (>5 years). It usually
happens less then once a month. We cannot reproduce the problem. We have
checked CPU load, disk fragmentation, memory manager activity, and anything
else we could think of but cannot find any pattern corrsponding to when it
happens. We can not reproduce this on demand, and are unable to give any
data to HP to help us track down the problem. Since we are writing the
same record to the two files, with the main file getting written to first,
traps, debug statements or anything else seems moot.
I would be interested if any else has seen this behavior, even if it
happened only once over the past several years.
Andy
At 06:05 PM 7/28/99 -0600, ABOOTORAB,MICHAEL (HP-PaloAlto,ex1) wrote:
>Hi,
>
>We have a software bug that is commonly known among our programmers as
>black hole and I have been told its been going on for more than 4 years.
>
>This is how the problem occurs :
>
>A COBOL program reads in 2 files and after doing some editing writes the
>result to output.
>
>Occasionally output file contains null records ( black holes!)
>
>The last time this problem occurred I noticed that there exactly 8 null
>records,
>I also noticed that the output file has a blocking factor of 8.
>My solution to this problem is to change the blocking factor and it will
>never happen again ( We have proven that our program is not causing this).
>
>I am wondering if this has happened to anybody or if anyone can explain it.
>
>The file equations are :
>
>file in1 = file1
>file in2 = file2
>
>where file1 and file2 are :
>
> SIZE TYP EOF LIMIT R/B SECTORS #X MX
>
> 600B FA 220804 3300000 1 518192 * 32 file1
> 600B FA 2514082 6000000 1 5893280 * 32 file2
>
>
>file out = out1;REC=-600,8,F,ASCII;DEV=DISC;DISC=4000000,32,1;SAVE {
>notice blk of 8)
>
>RUN PROG1;XL='XL'
>
>Thanks
>Michael
>
|
