The initial problem that causes most organizations to waste a great deal of CPU resources comes from unnecessary calls to the DB2. This is often an innocent mistake, but over time it adds up to be one of the largest undetected performance problems. Why undetected? Simply put, the SQL appears to be 'perfect' and, therefore, no additional tuning efforts are made.

The problem with this is that the SQL is not doing anything but calling DB2 like a common I/O module, and not using advanced SQL syntax for performance. This is not a proper usage of the DB2 engine, and it results in the worst possible performance.

This paper discusses how and why to design SQL that will reduce the number of times calls are made to DB2. We'll look at how to:

• Write SMART (SQL Made to Accurately Reflect Transactions) applications rather than writing applications that act like generic I/O modules to DB2
• Properly tune SMART SQL to further reduce CPU and execute efficiently
• Exploit SQL and application features in DB2 on z/OS version 8 and 9 to help with these efforts.