Automation Considerations When Using Virtual Control File Based Communication Methodologies

Products

• MIM Resource Sharing (MIM)
• MIM Data Sharing (MII)
• MIM Tape Sharing (MIA)
• MIM Message Sharing (MIC)
• OPS/MVS Event Management & Automation

Issue/Introduction

MIM's Virtual Control File (VCF) communication methodologies provide high performance, the ability to span sysplex environments (CTCONLY and CTCDASD only), and provides alternate master system eligibility in the event of fail over - making it a reliable, versatile, and preferred communication medium for many user environments where the MIMplex resides in/or extends upon SYSPLEX boundaries.   

Customers who utilize automation packages, like OPS/MVS Event Management and Automation for z/OS, can configure their environment to aid in quickly recycling the MIMplex environment so to maximize maintenance windows where the MIM Restart Manager Feature cannot be exploited. Such events include, but are not limited to:

• Upgrading MIM initialization or communication methodology parameters
• Upgrading z/OS product releases
• Applying IBM RSU levels
• Any other action where either the operating system, vendor, or environment protocol requires a system to be IPL'd

While automation can expedite the completion of these events. users should review their current MIMplex environment and parameters and automation rules to minimize the potential for issues resulting from automation or user errors. One of these events relates to VCF Migration. This document will:

• Review the VCF Migration process
• Provide Best Practices to eliminate needless VCF Migrations
• Provides sample to illustrate a successful VCF Migration
• Discuss automating these events
• Review published interfaces between the MIM and OPS/MVS Products

VCF Migration ensures the most preferred active VCF Master system is the VCF MASTER. As part of migrating from a VCF MASTER to another preferred master system, a process called a "Global Copy Process" is performed. depending on available CPU and system enqueue activity, this process can take a few seconds to almost a minute in active MIMplex environments. 

While MIM is fully able to perform this event without user intervention, the goal of this article is to limit the number of required VCF migrations. In order to do so, please review the recommendations below:

 

Resolution

Instructions:

Review IPL Order

In order to limit the number of VCF Migrations, it's recommended to IPL MIMplex systems in the reverse order of the GLOBALVALUE MOSTPREFERRED MASTER list. For example, if the list contained (GK03, GK62, and GK13) and system GK03 was the master, the IPL order should be GK13, GK62, and finally GK03. This will limit the number of VCF migrations to "2" - one to migrate from GK03 to GK62 and the other to migrate back once MIM on GK03 has resynchronized with the active MIMplex

Note that if this order cannot be followed, just ensure the last system to be recycled is the most preferred VCF MASTER system.

Ensure MIMplex Synchronization Completes

When IPLing the most preferred master system, a VCF migration to the next most preferred master system will be performed. Depending on your communication methodology, you will see the following messages:

In environments where CTCONLY or XCF communication is utilized:

Current VCF Master System:
                                                   
MIM0399I migration INITIATED to system JF62 due to (either local shutdown or MIGRATE command)
MIM0377I VCF migration IN PROGRESS - MASTER=JF62                
MIM0901I system JF03 leaving XCF group MIM###                    
MIM0242I system JF03 VCF deactivation    COMPLETE                


Next Eligible Master System:

MIM0377I VCF migration IN PROGRESS - MASTER=JF62              
MIM0911I system JF03 reported INACTIVE in XCF group MIM###    
MIM0242I system JF62 VCF deactivation    COMPLETE              
MIM0342I system JF62 VCF activation      COMPLETE - MASTER=JF62
MIM0116I system JF03 FREED from file VCF                      
MIM0241I VCF migration COMPLETE    - MASTER=JF62   

In environments where CTCDASD communication is utilized, the MIMplex is migrated first to a DASD control file, then back to the VCF on the second active most eligible system:

Current VCF Master System:

MIM0399I migration INITIATED to system JF62 due to local shutdown
MIM0377I VCF migration IN PROGRESS - MASTER=JF62                
MIM0242I system JF03 VCF deactivation    COMPLETE                


Next Eligible Master System:

MIM0242I system JF62 VCF deactivation    COMPLETE              
MIM0088I migration to file 02 IN PROGRESS                      
MIM0116I system JF03 FREED from file 02                        
MIM0080I migration to file 02 COMPLETE                        
MIM0911I system JF03 reported INACTIVE in XCF group MIM###    
MIM0377I VCF migration IN PROGRESS - MASTER=JF62              
MIM0342I system JF62 VCF activation      COMPLETE - MASTER=JF62
MIM0241I VCF migration COMPLETE    - MASTER=JF62               

Regardless of your communication methodology, it's extremely important to let this process complete before terminating MIM on the most preferred master system. Failure to do so will result in MIMplex wide delays until VCF Recovery is performed and completed. 

Automation Notes

• MIM will automatically ensure that the most preferred system is the current VCF master via the MIM "MOSTPREFERRED=YES" parameter. Using automation to check the current VCF master system or issue MIM MIGRATE commands to perform VCF migrations is not needed.
  
  
• If automation is being used to trigger shutdown events on other systems, wait until the MIM0241I message is issued on the new VCF master system before shutting down any other system. Do not terminate MIM on any system during this process. If you feel MIM is hung during VCF Migration, contact MIM Support. 
  
  
• It is okay to code an automation rule to report and alert users of a VCF migration event that occurs outside of a maintenance window. To do so, your rule can issue either the MIM DISPLAY SYSTEMS command or MIM DISPLAY I/O command to check the current MASTER system. OPS/MVS customers can contact OPS/MVS support for assistance with this or to request a sample rule.
  
  

Utilize Automation Product Features

MIM for z/OS provides seamless integration with OPS/MVS in several areas, including product state management, health check status management, and individual automation event management.

You do not need to do anything for MIM for z/OS to enable the product interface to OPS/MVS and you do not need to issue any MIM for z/OS initialization statement or commands to activate the interface. If MIM for z/OS and OPS/MVS are active in the same z/OS image, MIM for z/OS automatically communicates MIM for z/OS automation events to OPS/MVS.

 

Overall:

Automation can be a powerful, effective tool used to expedite maintenance outage times and eliminate operator driven processes. However, users need to code automation with care to ensure that it does not negatively impact product features like MIM's VCF migration process. With MIM, VCF Migration can performed automatically by the product or manually via the MIGRATE command.

Ensuring user automation does not take any negative action that would impact this critical MIM process will greatly aide in decreasing times in problem resolution and maintenance window outages.