1. IMS performance savings

2. Background IMS is backend system for Standard Life SOA applications Distributed applications Increased CPU consumption in IMS transactions SEP 10 Coincident with Z/OS 1.11- not proven to be the cause Variable, but up to 12% Reduced after IMS V11 upgrade in NOV 10 But came back in Jan 11 Various PMRs open with IBM, various PTFs suggested, but none identified the issue DASD response times fluctuating, affecting IMS WADS IMS input queue time doubled beginning of JAN! Other unexplained SOA performance issues

3. Background Z9 EOS announced prior to Z196 Go for Z10, or wait for Z NEXT? Z9 upgraded in 2010, 2 engines added No further upgrades possible (EOS) Capacity for 2 years? IMS CPU increase blew capacity paln Capacity issue for tax year end APR 11

4. Performance Issues WADS response time critical to IMS PPRC requires acknowledgement from secondary copy before I/O completes. Seeing 12 millisec response times Capacity of SRDF ports too low Not monitored well Actual problem was the CPU busy on the DASD hardware. Box reconfigured to increase SRDF links Monitoring put in place IMS happy again

5. Performance Issues Unattributable performance issues. Everyone says “My bit is OK” IMS transaction responses fine Found to be MQ buffering issue Buffers and pagesets shared between online and batch queues Buffers too small Discovered with IMS log analysis, long program end to message dequeue. CSQP020E =MVMA CSQP1RSW Buffer pool x is too small Other MQ settings running ‘out of the box’ 2 MQ internal traces on, wasting CPU cycles

6. Capacity Issues Used strobe on MPRs to look at CPU attribution But no ‘before’ to compare Immediately saw a lot of cycles involving program load CodeFuncCPU PCT.COMMONXPDSMAN5.59 SVC122Load5.72 SVC120Getmain4.45 SVC18bldl1.53 17.29

7. Capacity Issues Revised program preload lists Switch preload off in one region of each main class Used PDSM SMF records to get loaded module list Rebuilt preload lists 10% CPU reduction in our biggest system Even more in our smaller system CodeFuncBasePreload%change.COMMONXPDSMAN5.594.57-18.25% SVC122Load5.723.58-37.41% SVC120Getmain4.453.58-19.55% SVC18bldl1.531.615.23% 17.2913.34 -22.85%

8. Capacity Issues Still a lot of CPU in PDSMAN Due to a steplib we could not easily get rid of Application lib was in linklist – 79 th in concatonation..hmmm Experimented with program loads in batch Found a way to reduce program load CPU overhead by 40% Add the linklist lib to the steplib of the mpr Define as a private library to LLA, with freeze option (prevents I/O) ProgramFuncBasepreload%changesteplib%change.COMMONXPDSMAN5.594.57-18.25%0.72-87.12% SVC122Load5.723.58-37.41%1.22-78.67% SVC120Getmain4.453.58-19.55%2.88-35.28% SVC18bldl1.531.615.23%1.08-29.41% 17.2913.345.9 -22.85%-65.88%

9. Comparative IMS data Comparing our tax year end peak to the previous peak of the last 6 months The actual savings are much greater than predicted! Metric2/11/20104/4/2011% change IMSA TRANs4,992,4565,551,697+11.2% IMSC TRANS2,996,2313,352,235+11.9% IMSA AVG SERVICE TIME0.11000.0749-32% IMSC AVG SERVICE TIME0.08280.0604-27% IMSA AVG CPU/TRAN0.01530.0114-25% IMSC AVG CPU/TRAN0.005040.0036-28%

10. Further Savings? PWFI may save additional 5-10% Like wait for input, but self tuning, not dedicated regions Highest used programs stay scheduled Reduced L/E rununit start up and termination Application programs MUST be properly reusable Tried it once before and got burned Use log analysis to verify programs that have processed more than one tran in a scheduling Use regression testing tool…