Re: DSA 7.22.UC1/HPUX 10.20

Ian, First, if you think you saw this before, you did; the original post went out on 2/20. This sort of showed back up today, along with a note from "Administrator_at_LLCS-MAXIM @ lendlease.com.au" stating that the message wasn't deliverable. So instead it apparantly reposted it to the world in a fit of pique. Sigh. Anyway, it (only the other day) turned out to be a bug, and I have an answer for this. The sqexplain.out didn't indicate anything too weird, so some further checking isolated it to the query being run from esql/cobol. The same thing (striped from sqexplain.out and onstat -g sql) ran right smartly in dbaccess and esql/c, but became "dumb" in esql/cobol. (no cobol jokes, please; we have too many lines of source to switch.) The problem turned out to be a bug in esql/cobol; regardless of the setting of PDQPRIORITY it will allocate but a single thread to run the query. (I checked the onstat -g mgm output and it *IS* being set at the engine level, oddly enough. Weird.) Thanks, David Ian Goddard wrote: >David Coburn wrote: >> >> Hi. I have an odd problem here. DSA 7.22.UC1 is demonstrably >> slower on my HP 9000/K420. I have an EMC disk array with 56Gb >> attached, 4 cpu's and 1Gig real memory. Disk I/O screems >> during insert/update, performance is beyond reproach during >> index builds, etc. The problem is that queries are slow. This >> wouldn't be much of a problem, except that we're replacing an >> old Unisys running 7.10.UC5 that should be 5-7 times *slower* >> than the HP, based on the usual metrics. Queries, though, that >> take sometimes hours longer to complete. >> >> We've checked all the usual suspects. Indexes are in place, > >Agreed - it hould run a bit quick - but your list of usual suspects >didn't include the results of setting sqexplain on. > >Ian