I forgot to mention a crucial piece of information.

The black holes gets removed from the file a few hours later (some times 8
hrs) and
the values replacing the null are what they are supposed to be !

This suggests that there is some sort of delayed caching going on.

After I posted this message , some one informed me that , HP lab is aware of
this problem and they can actually duplicate it ( I have the engineers name
and will
contact him).

Another e-mail informed me that HP lab has a patch for it(don't think so).
I'll post messages as I get them.

I still think , regardless of the reason, it would be a good idea to
change the blocking factor of the output file to 1.

Any ideas and suggestion is greatly appreciated.

Thanks
Michael Abootorab





Gavin writes:
>Exactly how have you proved that your program is not causing this?

Your files are NM file types (flat ASCII), and your program is NM, and
this if MPE/iX, so the blocking factors should be irrelevant as far as
I know.

I'm afraid I think your program has a bug in it.

Is it compiled with BOUNDS checking on?  Are you *sure* it isn't overrunning
a buffer or array somewhere?  What kind of routines are you getting from
the XL file referenced in the :RUN statement?

I would probably do something like put a breakpoint at FWRITE etc., to
display the actual intrinsic calls being made by the program.  If you
happen to have NetBase on the machine, you can use NetBase Application
Tracing to get a list of the Intrinsics called by the program.

G.