Consistent Read from Secondary - decision making in response to poor performance/hardware health changes

Our current understanding is that to exploit the DS8K's consistent read from secondary function, IOS currently sends some queries out at Hyperswap enable time in order to determine at the LCU boundary whether reads should be directed to the PPRC primary or secondary devices.     GDPS config loads only happen a couple times a year and activities that result in a Hyperswap disable/enable also occur infrequently – sometimes many weeks will pass between these events.

 Our physical PPRC primary and secondary subsystems are generally equidistant from the LPARs, under 150 meters because we have zHyperlink attachment to every DASD subsystem from every CPU.     Because distance is less of a factor for us than it might be for other customers, we are interested in the possibility of z/OS IOS making more frequent decisions about what subsystem gets reads in response to poor performance and changes in hardware health.  

 A decision about whether PPRC prim or sec should get read I/Os could be for the purpose of load balancing during times of intense stress.    For example, for a couple days each month (month end processing) we might see that unusually high spikes of read I/O is pushing the PPRC primary DASD subsystem over the limit, resulting in poor response times.    We generally have 70% reads/30% writes – but during times of extremely intense read activity the PPRC secondary may be performing better because it is only having to deal with the writes for Metro/Global Mirror & so it might be more appropriate for it to handle some more reads if IOS determines the PPRC primary has started underperforming.  

 Alternatively, IOS could have made a historical decision that the PPRC secondary should get the reads for a certain LCU but then the PPRC secondary could start underperforming because of a change in its own DASD health or connectivity.   There may be value in IOS re-evaluating which SITE should get reads in response to SEVERE and MODERATE HEALTH ALERTS observed in z/OS such as a DA card failure or perhaps a DASD cluster quiesce/failover event where half the cache has become temporarily unavailable for use on a primary or secondary DASD subsystem.   Alternatively a sick-but-not-dead switch, or host adapter, or FICON cable could emerge involving either the PPRC primary or PPRC secondary where response time has increased and in those cases we wonder if IOS could step in to determine that “the other SITE is now performing better for this LCU” and make a decision to change redirect I/O.