NOT MY JOB, MAN

[Guest.Visitor]

This is the winner for the month... target=_new href="http://teamhouse.tni.net/award.htm"> href="http://teamhouse.tni.net/award.htm">http://teamhouse.tni.net/award.htm

---

......

 
 Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080 
 

[T.Holt]

Great! Brad Stone sent this picture to me in email a few months ago with the question, "Just how lazy are government workers?"

---

On Tuesday, February 23, 1999, 03:57 AM, Bob Hamilton wrote: This is the winner for the month... href="http://teamhouse.tni.net/award.htm"> href="http://teamhouse.tni.net/award.htm"> href="http://teamhouse.tni.net/award.htm"> href="http://teamhouse.tni.net/award.htm">http://teamhouse.tni.net/award.htm

[Guest.Visitor]

Hmmmm. Apparently you had to work with some people who don't have a clue. Tough luck. I'd have at least taken debug *ALLINST traces combined with TRCJOB for each request to see any odd paths... but that's just me. I'd have expected anyone w/ performance experience to do a sampling of instructions over a period of repeated requests... at least a SMTRACE. FWiW, as well to clarify: the ODBC request for open could be significantly different than an interactive SQL. Interactive SQL does not have an option to 'model' other interfaces; instead it just performs what is asked. Mostly the request is OPTIMIZE(*FIRSTIO) type processing for example, whereas almost all ODBC w/out an OPTIMIZE FOR n ROWS would effect OPTIMIZE(*ALLIO). In ODBC there is also CCSID xlation which in normal green-screen environments would not be an issue. So QDBOPEN being slower in ODBC is expected in most cases, however comparison to other actual results I know that four seconds for an open is generally unexpected. One last note... is that the 98% CPU is likely an index build being performed to effect the query results ; a debug joblog collected for the request would give implementation details. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.