1. Common Tuning Opportunities
I got the tee shirt
Andrew com

2. Common Tuning Opportunities
COBOL
File I/O
CICS
DB2

3. COBOL - Table initialization
Do we have to initialize?
Keeping a count of rows
Rewriting data anyway
COBOL Initialize is fast
Table to Table copy is fastest
05 COBOL-TABLE-INIT
````````````````````````````````
100-MAIN
INITIALIZE COBOL-TABLE-INIT
````````````````````````````````````````````
MOVE COBOL-TABLE-INIT TO COBOL-TABLE-ORIGINAL

4. COBOL - Inspect verb It’s expensive
It’s more expensive when using COBOL reserved words (low-values, spaces)
Use a literal instead ‘ ‘

6. COBOL – Mismatched Data Types
In:
Arithmetic
Counters
Compares
Forces a conversion of working storage items, sometime multiple conversions
Get the compile listing PMAP (pseudo assembler) and see exactly what’s going on.

7. File I/O - Buffering QSAM VSAM
We’re finding buffering isn’t helping anymore. The DASD and Tape hardware are compensating for bad buffering & blksize(ymmv)
VSAM
Sequential – data buffers (1/2*CIs per CA +1)
Direct
Index buffers (Total CIs – Sequence set CIs +1)
Batch LSR (JCL or SMS) – advanced buffering, caches the whole index and LRR data CIs.

8. File I/O – OPEN/CLOSE Repetitively opening and closing files
SVC 19 & 20 (may also include SVCs 18,26,48,56,99,120, 130)

9. File I/O – Inserts High Wait Time and High CA splits
Is the input file sorted correctly?
Is the VSAM file in the right order?
It’s better to insert at the end of file.

10. File I/O – Read or update the same data
Look at the number of EXCPs compared to number of records.
Number of Logical Operations (read, update) vs. number of records
We’ve seen very unusual numbers
Hundreds of thousands of reads to VSAM files that contain a few thousand records
Batch LSR is a good band aid but fixing the logic is the real solution.

11. CICS – Memory Management
Module with Getmain / Freemain Descriptors
SVC 120
Use the CPU attribution report to determine what modules / transactions are causing the modules to be invoked

12. CICS – Auxiliary Trace High CPU to Trace Domain modules(DFHTRPX)
We turn them on to debug a problem, then never turn them off
They can be dynamically turned on/off (CETR)

13. CICS – Monitors High CPU time to modules associated with CICS monitors
Monitors are not bad
Sometimes turning certain options on, is
Contact the Vendor to discuss

14. DB2 – Access Path Table Space scan generally bad
# matching index columns vs predicates
Stage 1 vs Stage 2 predicates

15. DB2 - Reading Data Repetitively
Same as the File I/O, some programs read the same data over and over (reference data), rather than reading it once and storing locally.
Will probably get a DB2 buffer hit so the SQL runs fast but still incur the CPU overhead of going to DB2

18. DB2 – Improper Cursor Usage
Reading a whole table with singleton selects
Probably a place that a table space scan would be better
The number or executions on the select matches the number of rows in the table
Using a cursor when only one row is returned
The number of Opens = the number of Fetches = the number of Closes
Incurring the overhead of setting up a cursor when all or most of the time, only one row is returned

20. DB2 – Lack of Joins Especially in shops that migrated from IMS to DB2
Two or more separate SQL statement that are run the exact same number of times
Look for common columns
Using the joins can significantly reduce the number of calls to DB2

22. DB2 – Full Runstats
Still see a lot of objects that do not have current Runstats, especially tables that have been set up for distributed application
DB2 has gotten better in choosing the correct access path if you give it the right information to make the decision

24. DB2 – Compression See a lot of large tables without DB2 compression.
It’s not your father’s compression

26. DB2 – Useless SQL Mostly in DB2 DDF
Thousands of executions in a 15 min period
Distributed app trying to keep a thread or connection open ?
SELECT COUNT(*) FROM SYSIBM.SYSTABLES
SELECT CURRENT DATE FROM SYSIBM.SYSDUMMY1

28. DB2 – Monitors
PDT Modules – CA Detector