One customer in Japan is now implementing CSM environment on z/OS to manage FlashCopy and Global Mirror on DS8Ks. They are now using Hitach's shadow images (SI) and universal replicator (UR) and they will replace IBM DS8K's FC and GM with CSM management. Their application team is now using Shadowimage at the local (production) site to testing their application at the release timing on many weekends while system programmer team is doing DR drill 4-5 times per year by using Universal replicator at the remote (DR) site. In other words, they are now doing both using shadowimages at the local site and DR drill at the remote site independently. They want to do the same way after replacing Hitach's SI and UR with DS8K's FC and GM with CSM.
One way to do this under CSM environment is that when the application testing team wants to invoke FC session at the local site, they use CSM active server at that time. In other words, when the application testing team wants to invoke FC session and the system programmer team does takeover CSM active server to the local site to remote site, the application testing team will use CSM at the remote site via GUI or CSMCLI. As the another way, we can always set CSM active server at the remote site. With this way, the application testing team doesn't need to switch their destination CSM server from local to remote to invoke FC session.
However, this customer has a difficulty to do these ways shown above. They will use the same IP address for the production z/OS and CSM running z/OS. So, after GM recovery completes by CSM (former standby) server, they will do IPL their production z/OS and CSM running z/OS. These z/OSs have the same IP address as the local (production) site. Therefore, after IPL of the production and CSM z/OS at the remote site, the application testing team at the local site can't use CSM active server at the remote site. So, the canT7 do the above ways. Therefore, the customer wants to use CSM server as Active server at the local site to invoke FC sessions at the local site and they also want to use CSM server as Active server at the remote site to do takeover the standby CSM and do GM recover. This active/active CSM servers environment is now not supported by CSM.
With the above complicated customer reasons, the customer wants to support the active/active CSM servers environment. They can accept some restrictions, such as returning thier FC sessions to the original FC direction when returning to the original CSM active/standby configuration.
When we tested the above active/active CSM configuration, we found following issue. When we do FC restore on the active CSM server at the local site, another CSM (also active server) at the remote site detects this FC status change and the CSM changes the FC session status on the CSM at the remote site from active to inactive. So, one of our requirement is to have an option to disable this CSM detection function. In addition to this, our request is that IBM supports this configuration with some restrictions.
We understand this enhancement is not easy and it is risky for some customers who don't understand several restrictions. So, we almost agree with the customer to do DR drill (GM recover) by using CSM active server at the local site as well as the application testing team is always using CSM server at the local site. In other words, they don't do takeover CSM at the standby CSM. This DR drill is not perfect, but we believe they can confirm their production system's data recovery procedures.
Because the above DR drill is not perfect, we recommend the customer to do another DR drill once per year or two years while stopping FC invocation at the local site by the application team. This DR drill includes CSM takeover and GM recover at the remote CSM server (former standby) to confirm whole DR recovery procedures.
However, the above two way DR drill doesn't satisfy the customer's original request. So we raised this request.
