technical: Where Can You Find Mainframe Best Practices?

If you're a z/OS systems programmer, you know that it is best practice to set the IEAOPTxx PARMLIB parameter HIPERDISPATCH to YES: it improves CPU efficiency.

Storage administrators know that it's best practice to avoid IMBED and REPLICATE for catalogs. COBOL programmers know that USAGE DISPLAY should not be used for calculated variables: it affects performance. These "best practices" are guidelines created by experts and validated by experience. They help you avoid mistakes made by others, and are gold, especially if you're not an expert yourself.

But where are these best practices? There's no 'Best Practices for Mainframes' book. Or is there?

IBM Documentation

As the company responsible for IBM Z mainframes and much of the software, you would expect IBM to have a raft of best practices. The good news is that they do; the bad news is that they can be difficult to find.

The first place to look is obvious: IBM's documentation. For example, the z/OS Initialization and Tuning reference documents default values for z/OS PARMLIB. The default IEAOPTxx HIPERDISPATCH parameter value is YES. Most sites will follow these PARMLIB defaults unless there's a good reason. IBM documentation for most of their products includes such defaults.

IBM documentation can also show best practices. For example, the Enterprise COBOL 6.4 Performance Guide discusses USAGE DISPLAY and its effect on performance. The IBM DFSMS Managing Catalogs manual has a section on catalog best practices, including IMBED and REPLICATE.

For decades, careful reading of IBM documentation has been essential for anyone working with mainframes, and it's still the case today.

Other IBM Resources

IBM documentation is far from the only best practices resource provided by IBM. IBM Redbooks also show some best practices. For example, "System z Parallel Sysplex Best Practices" and "Performance Monitoring and Best Practices for WebSphere on z/OS." IBM also has presentations for Share, IBM TechXChange and others that provide some best practices. For example, a Share presentation in 2013 includes best practices for catalogs and IMBED/REPLICATE.

IBM Support is another excellent place for best practices. For example, here you can find best practices for external mainframe cabling, z/OS Connect performance best practices, and best practices for Omegamon monitoring products. They also have a document on catalog best practices mentioning our favourite IMBED and REPLICATE.

The IBM Washington System Centre has produced documents for decades and still does. For example, they have created best practices for z/OS and other IBM subsystems like CICS and Db2. These documents are also found on IBM Support pages.

IBM often publishes other best practices documents, though these can be difficult to find. For example, a search of IBM documents will uncover the IBM Z with z/OS Resilience Best Practices Guide.

IBM products may have other features to help. For example, IBM Systems Automation has best practice automation policies: IBM's recommended automation rules for z/OS, CICS, Db2, and more.

An easier-to-use resource for best practices is the z/OS Health Checker. IBM has checks to verify that your settings and configuration match their best practices. For example, IBM supplies a check to verify the HIPERDISPATCH setting. Even better, IBM documents these checks and provides information on why each check is performed, along with IBM's recommendations.

Another IBM resource is workflows that can be followed in z/OSMF, providing step-by-step instructions on installing or upgrading software. IBM provides some workflows on its GitHub site.

A browse through syslog may also provide some assistance: messages may also highlight when something doesn't follow best practices. For example, CICS issues a DFHFC0935 when opening a VSAM file with SHAREOPTIONS that disable VSAM locking: possibly allowing data corruption.

SYS1.SAMPLIB is an often forgotten source of information and includes sample files with IBM parameter 'starter sets', and JCL to create files with default values. For example, the ARCSTRST member has JCL to define HSM datasets, including a 'starter set' parameter file with IBM defaults. Other IBM products also provide similar samples. For example, the CICS DFHSAMP library member DFHSIT6$ has a sample SIT with IBM defaults.

Elsewhere

From here, the best practices resources become harder to find. Other vendors will have documentation providing similar best practice information to that of IBM. Similarly, other vendors may provide their own z/OS Health Checker checks and accompanying documentation. For example, Broadcom provides documentation for CA Allocate health checks. Other vendors, including BMC and Broadcom, provide z/OSMF workflows for installing and customising some of their products.

Those looking for security best practices have STIGs: Security Technical Implementation Guides from the US Defense Information Systems Agency (DISA). These documents DISA's best practices for security implementation of z/OS and many other products, including ACF2, RACF, and CICS. The Centre for Internet Security (CIS) also has benchmarks with best practices for the configuration of z/OS, CICS, and Db2 for security.

IBM is not the only vendor with presentations about best practices. For example, Broadcom has Share presentations about their products like ACF2 and Top Secret. Other service providers like EPS Strategies also present best practices.

Finally, there are articles such as this one that present recommendations and experiences. Another great example is Cheryl Watson's Tuning Letter.

No Single Source

Perhaps the best source for best practices is senior mainframe experts, though such staff can be harder to find. Another traditional source is each site's standards and procedures created over years by such senior staff.

However, it is probably best practice to research and update best practices. There may not be a single book or international standard, however there are many resources to find best practices. Unfortunately, some searching is required to find them.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.