PFA_COMMON_STORAGE_USAGE Health check parms

At zOS 2.2, new parms e_low, e_med, and e_high result in exceptions based on severity and the number of minutes before the exception will occur for health check PFA_COMMON_STORAGE_USAGE.

(E)SQA is designed to overflow into (E)CSA, so an exhaustion of (E)SQA is not an event that will cause impact to normal operations of zOS. By contrast, an exhaustion of (E)CSA will likely result in an unplanned IPL. Because (E)CSA is a more critical area, a typical tuning practice is to allocate (E)SQA so that it runs at 100%. This results in the largest possible (E)CSA area. The PFA_COMMON_STORAGE_USAGE health check models the exhaustion (reaching 100% utilization) of (E)SQA and writes low, medium, and high severity messages to the syslog. These messages results in computer operations and tech support staff engaging in problem determination for a health check that is reporting common storage to be exhausted at mm/dd/yy date and hh:mm:ss time.

I see value in this health check in monitoring (E)CSA, however I would like to be able to independently enable/disable the health check for (E)SQA. The current implementation of the health check is all or nothing. The check is either enabled and monitoring all common storage areas or it is disabled and not monitoring any common storage areas.

After an IPL, depending on the usage of the system (production verses test), the time of the day of the IPL (peak day time hours verses 02:00 on a Sunday) and the end-user activity after the IPL (high on-line, batch, or testing verses light activity) it could be multiple hours until the (E)SQA usage would reach it's normal operating value (which is 100%). Because of this, the health check will get multiple exceptions - and again, result in multiple areas of staff to engage in unnecessary problem determination. I have attached a text file that illustrates the messages that are written to the SYSLOG on a system that is operating normally.