Use of LOSSCONN with MIM using XCF CF Structures for Control Files

book

Article ID: 194787

calendar_today

Updated On:

Products

CA MIM Resource Sharing (MIM) CA MIM Data Sharing (MII) CA MIM Tape Sharing (MIA) CA MIM Message Sharing (MIC)

Issue/Introduction

We’d like to implement the CF LOSSCONN Recovery Management function in our shop to improve recovery times in the event that we lose one of our coupling facilities.  That function makes it so that the CF will prioritize the most vital CF structures in a serial fashion and one of the structures that is considered vital is the GRS structure.  Since we run MIM instead of GRS, we were wondering if we’d see the same improvements in our shop?  It does appear that we can specifically assign a higher priority to structures in our CFRM policy, so would we need to do that for our MIM structures?  Do you have any documentation available for implementing this function in a shop running MIM instead of GRS?

Thanks,
Pete

Environment

Release : 12.5

Component : MIM

Resolution

MIM is configured to contain multiple CF structures for the Control File. This provides redundancy so that MIM can act immediately in case of problems with the active control file/coupling facility and migrate to one that is available.

Here are the technical details:

MIM uses the IXLLIST macro to LOCK/GET/PUT data into the list structure. If the IXLLIST macro returns a “bad” return code such as “connectivity lost to the CF”, MIM will automatically migrate to the alternate list structure, which presumably is in a different coupling facility. As part of the migration process, MIM will perform a “global copy” where all systems rebuild their internal ENQ/tape drive information.


So, assigning a higher RECPRTY for the MIM structures will have no direct effect as MIM will already be operating on the alternate list structure after a loss of connectivity to the primary.

So it doesn't matter WHY there is a problem, or how it will be repaired. MIM tries to access the control file in XCF, recognizes there's a problem, and migrates over to an alternate that is not having problems. So whether the original is rebuilt via LOSSCONN or any other method, MIM is already off and running before the rebuild happens.