This portal is to open public enhancement requests against IBM System Storage products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
It's kinda rare for that to happen though. But is it possible that for some of the volumes all tracks were update? That is the only explanation I can think of which would cause the Recover for the SGC session to actually work for some volumes but not others. Cause normally, all the volumes would fail the SGC recover because all the volumes are already FC targets and a volume get be the target to two different sources at the same time.
If the above is the case, like I said, I don't think CSM will be able to stop the recover on SGC, because there wouldn't be a relationship on the hw. And if it's not the case, then we may need to pursue this as a defect so we can better figure out what might have caused the corruption you mentioned.
The practice volume was flashed from a MMGMP session with options "NoCopy", "Prevent Reflash of Practice volume after Flash or Recover", and "Fail Flash if target is online (CKD only)"
With the NoCopy option there is no background copy so the hardware relationship is always present ?
The only way I believe an SGC Recovery action could end up corrupting an H3 practice volume, is if the practice volume was not flashed with the persistent option. This means as soon as the background copy completes the relationship is no longer on the hardware. That means that the volume is no longer a target and there's nothing on the hardware itself for CSM to check to confirm that it's still "in-use".
So when do you no longer consider the H3 practice volumes "in-use" such that the SGC recovery can be run? Is it when ALL of the FCs for the practice session have finished the background copy? Or is something else?
If you would like a discussion on this RFE please feel free to setup a meeting. I would be more than happy to discuss the scenario so that we can meet your needs.