Performance tuning

This usually means I-O tuning, as a batch run is usually I-O bound. Be aware that if you optimise your I-O and you have little spare CPU capacity you can replace the I-O bottleneck with a CPU bottleneck so make sure you have adequate spare CPU capacity. You also need adequate CPU memory to avoid paging. Before throwing Storage resource at an I-O problem, see if high I-O rates are caused by program inefficiency. For example

  • Unnecessary Processing
    How many jobs produce thousands of lines of print, when the customer only really wants the one line summary at the end?
  • Bad Design
    I'll illustrate this with an example, a subroutine which was called to output data to a file. The subroutine contained the File Open, and File Close commands, so every time a record was processed the file was opened then closed. Once the File Open and File Close commands were moved to the main program, all the subroutine did was write records, and the job runtime reduced by 75%.
  • Sequential Scan
    This is really just an extreme example of bad design. Several years ago, I came across a job which sequentially scanned a large IDMS database, to extract data. The job ran for 36 hours. Once the job was converted to search by keys, it ran for under an hour. It is not unusual to find programs sequentially scanning data, so it is worthwhile investigating the possibility of using key searches, or even building an Alternate Index if appropriate.
    There is also a DB2 equivalent, Watch out for SQL which includes expressions like

    SELECT * FROM tablename , with no WHERE statement.

    This reads in an entire table - loads of I-O needed!

   EADM Advert

Accelerate DB2 Write with zHyperWrite and "EADM™ by Improving DB2 Logs Volumes Response Time:

The main problem with most of the above issues is that fixing them requires Programming resource, which is usually charged out to the customer. If the customer isn't suffering from the problems, he won't want the pay for fixing them! Storage solutions always seem to come free.

If your application uses VSAM files, either native, or as databases, then a number of tuning techniques exist to make them run faster. The article on VSAM buffering gives a few tips on how to do this, including how to use VSAM System Managed Buffering (SMB). An alternative solution is to let a product like EADM or Rocket’s Performance Essential do it all for you.

In the old days, about 10 years ago, IO tuning was a major industry, but modern disk subsystems with large cache front ends have removed a lot of the art from the job. There are one or two things still to watch out for.

z/OS can only schedule one IO to a logical UCB at a time. If applications need to access the same logical disk, then they will queue up to get access. This is called IOSQ. You can almost eliminate IOSQ by using PAV aliases. See the PAV section for PAV details, and the RMF section for IOSQ details. Even if you have PAV installed, it is worth checking from time to time to see if you have IOSQ problems. If you do, then the answer is to add more PAV aliases.
If you do not have PAV, then you will need to identify all your files that are VERY IO intensive, and try to isolate them onto their own volume. Examples that may need to be isolated include; RACF database, catalogs, DB2 and other DBMS log files.

If you see a lot wait times for disks, especially for write IO, then it is possible that your disk cache is not big enough. Most disk subsystems have software that allows you to monitor this.
Another possibility is that you disk channels are too busy. You can check this out by using RMF reports as explained in the RMF section.
Finally, the performance of some disk subsystems can be affected by the way you mix your data. In general, it is a bad idea to fill up part of a subsystem with the same kind of data. For example, most disk subsystems are physically made up of numbers of RAID arrays. It is best to spread data from each application among these arrays, and not reserve an array for each application.

    GFS Advert

EADM (Easy Analyze Disk Mainframe)

EADM creates an I/O profile for your mainframe storage, which can be for all your disks, for a given storage pool, control unit, application or single disk. EADM extracts data from existing RMF and CMF files and builds up a history of 'normal' disk activity. It can then very quickly detect and report on abnormal events, and suggest resolutions.
It will report on deficiencies such as

  • not enough PAV aliases
  • Insufficient disk cache, so causing excessive cache read misses
  • %IOP/SAP busy
  • Could High Performance FICON improve your performance?
  • Does that new subsystem that you just installed really live up to the salesman's claims?

EADM is said to be very easy to install and use. Once set up, reports can be fully automated, take about 5 minutes to process, then the results send to you in Word or HTML format by e-mail.

For more information, Try this link

Other interesting products from Technical Storage include
EAMC (Easy Analyse Mainframe Check) which monitors MSU / MIPS consumption per LPAR.
EATM (Easy Analyse Tape Mainframe) analyses various mainframe tape control files (TMS, TLMS, ControlT, SLS files, MVC files) to build up a normal pattern of tape activity and can alert when capacity is underused, or real capacity in virtualised systems is nearly full.

The effect of Joblib DD statements

This tip originally came from Dave Hollingsworth. If you code a JOBLIB in your JCL, z/OS will search for programs even if they are in SYS1.LINKLIB. Dave quotes IEFBR14 as an example, it occurred in 30,000 jobs in a concatenation of 17 joblib datasets in his site, which meant 510,000 unnecessary accesses. They changed their JCL to use STEPLIBs instead of JOBLIBs and shaved 20 minutes off their batch run. Other potential problem programs include SORT and IEBGENER

back to top