I/O Avoidance: Old-School Turbo Charger
Actual I/O to disk or tape is expensive: it slows everything down, and ups your CPU usage. Techniques to avoid I/O have been around for decades: turbo-charging applications accessing datasets.
In this edition, we're going to take a fresh look at I/O avoidance for non-VSAM datasets, and show how old-school techniques can still speed things up.
In our first technical article, we review blocksize: is it still a thing after all this time?
In our second technical article we list five I/O avoidance techniques that are easy to implement, but still missed by many sites.
Finally, in our opinion article David Stephens argues that "Do Something" is always better than "Do Nothing" when managing z/OS.
We hope you enjoy this issue.
technical: Five I/O Avoidance Features That Every Site Should Use
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.
technical: Is Blocksize Still a Thing for Sequential Datasets?
For decades, anyone working with z/OS has been interested in I/O avoidance: reducing I/Os to improve performance. In particular, blocksize has been the favourite tool for I/O avoidance. But the z/OS of today is very different to the MVS/XA I started with in the 1980s. And disks hardware is a lot better too. So, is blocksize still a thing?
Well, it is. Mostly.
opinion: Two Opposing Strategies for Systems Administration: Do Nothing or Do Something
Is it really better to minimise change, and do nothing?