Take advantage of z/OS SRB performance boost during GEOPARM reload

After giving the request a comprehensive review, we have determined that we cannot include it as a candidate in an upcoming release because it won?t be pursued within our planning cycle.

Interesting

Using extra engines is a good idea so long as the activation process doesn't slow things down.

Could certainly use the extra boost.

We would not load a new GEOPARM to remove a link, but it could still be useful when loading GEOPARM in larger environments.

I support this request. Boost needed for both GEOPARM and Hyperswap Enable operations.

Not just for GEOPARM reload but a general comment: A general approach to improve the duration of critical GDPS functions (dasd config, hyperswap, gdps monitors etc.) would be valuable. Not just SRB boost but any other solution would be helpful on this.

Application availability is very important. However, solutions to address these concens should also not affect the GDPS and DASD availability either.
i.e, hyperswap should not take longer, beacuse more gdps functions are made ziip eligibile and now it has to switch between GCP and ZIIPs more frequently.

Fully supportive.

This would be a huge advantage in helping the config run through quicker and reducing "downtime" when the actions call for stop secondary before new config has to be run. If I may add something to this, perhaps the monitor2 that runs directly after the geoparm config can be included in this in order to get to a green OK state in the shortest amount of time.

Good suggestion ... SRB is already being used in other critical recovery scenarios like 'CF Datasharing Member Recovery' and 'Sysplex Partitioning'.

However we rarely reload the GEOPARM, an improvement would always be welcome.

Moving tasks to SRB, as I understand, won't reduce the number of service units required to execute all instructions to put the port offline and also won't prevent impact on application service tasks since SRBs are high priority. Anyway, sounds as a good idea doing something to reduce impact and eventually the implementation might come to be done in a good way.

We voted for this RFE because we have similar effects on the Controlling System when running Monitor2. So Monitor2 could be another candidate for SRB. Perhaps it will be enough if SRB is active only for a few minutes in these cases, but it will help a lot.

We always try to reload the GEOPARM during times of low activities. To use SRB in this situation would give us more flexibility regarding the time window of the reload.

Bigger environments could certainly use the extra boost.

SRB Boost, usage of zIIPs, or whatever the solution, an improvement here would be welcome.

Faster GEOPARM reload would give more comfortable during maintenance of all kind (GDPS upgrade, SA upgrade...)

This is important for for our larger environments to prevent impact to other applications.

We rarely load GEOPARM and would never do so for a broken FCP link / would always block at the switch during failure analysis.

Important for High Availbility in a bigger environment