longpelaexpertise.com.au/ezine/FiveIOAvoidanceFeatures.php?ezinemode=printfriend

LongEx Mainframe Quarterly - November 2023

… and sometimes aren't.

I/O avoidance has been a thing for decades: minimising physical I/Os to improve performance. z/OS and related subsystems have offered many I/O avoidance features for a long time. Many of these are 'free': no cost in CPU, easy to implement, no risk. I love free. However, many of my customers still aren't using some of these features. So, in this article, I'm listing five of them that should absolutely be used, and sometimes aren't.

1. LPA

Remember Link Pack Area? Load re-entrant modules into the LPA so programs can access them fast? Everyone has the basics in LPA, like SYS1.LPALIB, SYS1.SORTLPA. But many sites don't put in everything they can.

For example, many don't have all eligible Language Environment modules in LPA. I've seen some without the SCEELPA library in the LPA list! And this is just the start.

Some LPA-eligible Language Environment modules are in PDSEs, requiring the z/OS PROG to add. SCEERUN2 is one of these. Language Environment has samples in SCEESAMP such as CEEWLPA and EDCWLPA with sample PROG LPA ADD commands for other LPA eligible modules.

How about MQ SCQAUTH? Lots of sites without this in LPA. And CICS SDFHLPA. And don't' forget DLLs: z/OS UNIX programs may get a significant performance from loading these into LPA (yes, you can do it).

Most z/OS systems programmers will tell me that they have modules in the linklist, and this is good enough. However, LPA is faster than the linklist: a load from linklist must still be loaded into the local address space. In some cases (like z/OS UNIX and DLLs), there can be huge numbers of LOADs, so small gains matter. It may be difficult to measure performance benefits, but they will be there.

2. LLA

Stay with me here. Take a look at this output from BMC Strobe:

Strobe* PERFORMANCE PROFILE
  #IEP                                ** MOST INTENSIVELY EXECUTED PROCEDURES **
MODULE    SECTION   PROCEDURE/FUNCTION          CPU TIME PCT   CUMULATIVE PCT
 NAME      NAME         NAME                     SOLO    TOTAL     SOLO    TOTAL
.SVC      SVC 006         PROGRAM MANAGER/LINK  25.82    27.46    25.82    27.46
.NUCLEUS  IEAVEWAT        WAIT SERVICE           6.35     6.97    32.17    34.43

Program loads consume over one quarter of the total CPU. I've seen a few examples of this, particularly if it's a job step that doesn't do very much, or a z/OS UNIX service that does a lot of calls to DLLs and things.

The fact is that program load/link overhead should never be high: IBM solved this years ago: LLA. Most people may think linklist, and this works. But library lookaside (LLA) adds to this and can be used for application program libraries without putting them in the linklist, and without updating STELIB DDs.

Gotta love LLA.

3. VIO

Virtual I/O: z/OS pretending to be a disk but using memory and pages. Been around for longer than I've been working on mainframe. I saw a post on a discussion thread that said that their z/OS site had removed VIO. I was surprised, but not that surprised: I've seen other sites without VIO. But for the life of me, can't think why. Today, memory is cheap, and most sites don't even page. So, why wouldn't you use a free feature to reduce I/Os?

Another site was much smarter. Not only did they use VIO, but coded SMS ACS routines so that all temporary datasets below a set size always went to VIO.

4. TFS

Temporary File Systems: VIO for z/OS UNIX. You can define a mounted file system as a TFS, and the files are in memory. Smart sites use TFS for the /tmp directory. Unfortunately, I see many that use ZFS datasets for /tmp. But don't forget to monitor your TFS filesystem using the FSFULL mount parameter to generate an alert as your TFS fills up.

5. DFSORT

Everyone buys DFSORT or Precisely Syncsort MFX for, well, sorting. But for me, the biggest feature of these products is the I/O features that come with them. DFSORT and friends will outperform anything you can write for I/O. Every time.

So, it makes sense to maximise the use of their I/O features, and there are a lot of options. The simplest is to replace IBMs IEBGENER with their equivalent (ICEGENER for DFSORT, BETRGENR for Syncsort). A drop-in replacement that will transparently improve performance. Unfortunately, I still see sites that haven't done this.

Then there's ICETOOL and the SORT steps themselves. Sites should code less and use sort more. For example, I often see sites with a REXX scanning SMF records one at a time. Much faster to use SORT to reduce the records that the REXX will scan.

Finally, few sites use the E15 (input) and E35 (output) exits. These allow your program (even a COBOL program) to get control once DFSORT has read a record (E15) or just before it writes a record (E35). Or in other words, a COBOL program can use DFSORT for the I/O: always going to be faster.

Conclusion

I decided to limit this list to five, but I could have gone on and on. All these features are free, and all will improve performance. It may be difficult to measure the performance improvement, but it won't be difficult to use them.

David Stephens