technical: Adventures with Resilience: Looking at Resilience As An External Consultant

z/OS Health Checker

My next port of call is the see what the z/OS Health Checker has. I confirm that checks are enabled, see if checks for some third-party products are enabled, and see if there are any errors. I firmly believe that every site should have a 'clean' z/OS Health Checker result, and am regularly surprised by sites that don't. Some examples:

• At one site, some channels were defined with a slower speed than they could achieve. This could have affected performance if workloads increased.
• At another site, they still had catalogs with IMBED and REPLICATE specified. IBM recommends that these not be specified, as they could impact catalog resilience.
• At a third site, their page datasets were quite full, indicating that the page dataset sizes were not large enough, and the site probably needed more memory.
• In many sites, I've seen checks disabled. I'm a big believer in using every feature available to improve resilience.

Performance

My next step is to look at performance. I like to create a heat chart of the performance index of every WLM service class period, and see if any are regularly higher than 1 (indicating that goals are not being met). This heat chart may look something like this:

I'll then dig deeper into service class periods with a performance index that is regularly higher than 1, or even those that are regularly far below 1.

In one site, I found many service classes and period that never met their goals. In this case, the current performance was OK, and the WLM definitions needed to be modified.

Capacity

I'll often do a very quick 'capacity check'. This starts with a quick look at CPU capacity used in z/OS system using the SMF Type 70 records. I'll also look at the SMF Type 72 to see which subsystems are using the most CPU. This can help determine if CPU provisioning is an issue, and if something needs to be done about it.

I'll check the page datasets to see if they're being used, and if so, how often. I'll also try to get SMF70 and SMF72 statistics for a year, and look at workload growth.

• I've found some sites where the CPU growth has been a concern. In some cases, I've found ways of reducing this. In others, the client has had to buy more CPU.
• In one site, I found that CICS online workloads consumed 80% of the CPU, and had a high priority. So lower priority workloads would regularly wait. Although we found some workloads that could have a lower priority, there wasn't much else we could do. The CICS workloads needed the higher priority, so the client had to look at buying more CPU.

Coupling Facility

Everyone forgets about coupling facilities, so I'll do a quick check. In particular, I'll use RMF Monitor III to check that they're not sharing CPs (or if they are, they're using thin interrupts), their coupling facility memory usage is around 50% of lower, and the coupling facility CPU usage is well below 50%.

Conclusion

Often, I don't have a lot of time to look at resilience. So, I've needed checks that quickly provide initial information about resilience. These can then guide any further digging or analysis. The above steps have worked well.

David Stephens