Hoi, I looked a bit into this. 0. The n00 jobs were run Jan 28, the last three crashed jobs ended very early on Jan 29 (that day was bad for computing). The next batch of jobs n01 (with modified recoilNtp.cc) did not start running before Jan 29 afternoon. I still think that I was careful not to mess up the executables. 1. I started with VubAnalysis ale-012303 and RecoilAnalysis ursl-011403 as the closest tags before running the n00 jobs and ran on csx-bpcock-2002. I could not reproduce the results of n00. (results is p.d. the number of events with IERR < 0). 2. Just to check, I put back in the K-lepton charge correlation test. No reproduction of n00. Again, I think that I was careful back in January, despite the usual high-pressure zone approaching from the east .... 3. I looked at CVS. I see that on Thu Jan 23 07:29:03 2003 someone committed a version of anaQA.cc that re-introduced gRandom->SetSeed(processID); instead of gRandom->SetSeed(randomSeed); into the executable. This is something that had sneaked in previously and had been fixed before (read the commit messages of Nov 28 01:28:41 2002, and also Wed Dec 11 01:28:25 2002) ... I fixed this once again in my commit of Thu Jan 30 00:10:16 2003, but I do not know whether that affected n00. I guess not. Therefore I currently think that n00 was running with a "random" random seed (and the printout in the logfile is not relevant, as you may see when perusing CVS web or the source of the correct tag). I don't know how to find this out without a timestamp of the executable. I think I'll add that as a default dump like the env dump we have in IbuApp. Archaeology is a bit difficult under time-constraints (not from the east, this time), so I may be wrong. But I don't think so. But if you manage to invest your own time and find something else, please post. I still see no reason why n00 should be better than o00 or p00. Cheers, --U.