Re: V5R2 Quality - a related question/issue

Jim,

Thanks again.

Since I could RUNQRY (or SELECT *) on the file, I know the data was in there.  
I don't think that the RPG-open issue is in play here.  I could be totally 
wrong, though.

The restore should not have been a factor, since the records in question were 
added by the application as it was running, and were not there from the 
restore.  Again, the save was ACCPTH(*YES) so the access path(s) should not 
have needed to be rebuilt.

As stated in the original post, I am in a bit of a "fix" regarding this issue.  
We don't have V5R2 in-house yet - this issue arose at the benchmark center in 
Rochester.  The IBM guys in the benchmark center recommmended that I submit 
this as a bug, but I didn't have time to fool with that concurrent with the 
benchmark runs.

I agree - RTVMBRD never has forced anything - but I'm suggesting that perhaps 
it should.  Otherwise, it could be lying, and lying ain't good!!! (grin)

Regards,
Michael

> Michael,
> Is it possible the part of the job stream that added the records did not
> close the file? Could this not have anything to do with restore? The fact
> that the OPNDBF and CLOF suddenly updated RTVMBRD, this seems more of an RPG
> database update problem.
> btw- I have never found that rtvmbrd or dspfd will force any records in a
> buffer to update to disk. They report on whats in the 
> physical file right
> then.
> Please post how this turns out.
> jim