Add DASD device level metrics to Continuous Data Collection (CDC)

Current state:
CDC exports very limited metrics related to the DASD subsystem.
- I/O service times are summarized (averaged) at the SSID level, which includes 32 devices on our systems but may include as many as 64 devices.
o Because of this we can't see the performance of any particular single disk MOD
o Bad performance of a single MOD can be masked by the averaging of the service time over many devices
- DASD queue metrics are sampled with counts for only the top 9 devices being reported in any interval.
o In our system that means we have over 99% of the MOD's with unreported values.
o The sparse nature of the data for any single MOD makes it impossible to build reliable predictive metrics related to queuing
- I/O counts are summarized at the DASD device level (DEVA, DEVB,…) so we have no visibility to how much I/O any particular MOD is supporting

Because the methods of data gathering above are not consistent we don't have I/O, queue and service time data which can be correlated directly in a given sampling interval. We also do not have enough data to accurately analyze some apparent problems in the DASD subsystem so we resort to ‘homegrown' solutions to gather the data and perform tedious manual analysis.

Since we run loosely-coupled systems the DASD subsystem performance must be predictable and reliable. We have seen DASD performance issues cause contention and be the root cause of system outages.

Desired state:
Capture and export the data needed to calculate service time, I/O rate, and disk queue status for every DASD device.
- This will allow us to do the following:
o Build predictive models which describe the expected behavior of the DASD subsystem at all times of the day
o Identify the source (down to a specific device) of performance abnormalities in near real-time
o Monitor the system performance in near real-time to ensure the actual performance is tracking with predicted/expected performance
 This then enables us to take preemptive measures if we see a trend toward unexpected performance or automate reactions to sudden performance issues
The actual calculations do not need to be done in TPF but the data exported should be complete enough to allow an offline process to perform the calculations quickly.