1) Analyze SQL timeouts on your system to determine whether operating system PTFs or QAQQINI setting changes are necessary. The process of SQL trying, timing out and retrying is significant, directly affecting the end user response times.

2) Research and understand "Access Plans". If your application software is running an SQL request hundreds of thousands of times per day with an access plan being rebuilt each time, request elapsed time will be suffering. An access plan should be built once, stored and reused by these thousands of requests.

3) Get educated about the difference between dynamic SQL and static SQL. The performance implications of dynamic SQL is significant for high volume applications. The code that performed fine in a test environment with 10,000 records may be costing your business hundreds of thousands of hardware dollars now that it is running in Production with millions of transactions.

4) Ensure that all "Open Data Paths" are reusable and are actually getting reused. An application opening and closing a database file for each insert of a record is completely unacceptable from a performance standpoint. You may need to recompile your stored procedures or COBOL and RPG programs that use imbedded SQL. Understand the difference between closing an open data path at the end of a call to a module versus at the end of the job. This is a compiler option.

5) Give the operating system a chance to run code more efficiently. Running programs on a Production system with "Debugging Views" of *ALL and "Optimization Level" of *NONE is basically saying that you don't care about performance. This is telling the operating system that you want to debug your code on a Production system. Security auditors ought to care about this one. How about DBGVIEW(*NONE) and OPTIMIZE(*ALL) so that the compiler can try to get your code to perform optimally.

6) Never allow your application to dynamically rebuild "Access Paths" or dynamically sort large volumes of data. Sure if it's a one time process, running in the middle of the night, it would be OK. If it is a recurring process, running thousands of times per day, permanent logical files or indexes with access path maintenance of *IMMED is near always the better option.

7) Watch out for the impact of SQL "Data Conversion". Passing matching data types into an SQL request is much better than letting the operating system possibly perform a conversion for each record processed.