RE: statistics on a job using RUNSQLSTM

<Alan>
When I tried to run it yesterday - it was going for over an hour (more
close to 2) before I killed it I couldn't see anything that showed me
it was moving I couldn't see anything that was slowing it down When I
signed in this morning, I submitted it again - just to see what would
happen And it finished in less than 2 minutes.
</Alan>

If both runs ran aginst the same data, with the same settings (parameters), it looks like the query engine did use diffrent ways to retrieve the data. As a conclusion of this, toys like visual explain won't help!
I've seen similar behaviour for complex joins (multiple files) with where clauses for (nearly) all files. The quick answer often was, to split the query into multiple parts, extracting the data file by file and joining afterwards. If this doesn't help, or your constellation is diffrent, you need a look to the running query. The problem with database monitor is: you would have to start it, before the query and it produces lots of overhead (for the admin, not the machine). The debug strategy is much more easy and it will work in most cases - the diagnostic messages will be sufficient to understand the diffrence for both runti,e scenarios. BTW: it was a silly idea to freeze the debug support!!!

D*B