Dynamically resize the CA MIM Control file in a DASDONLY or CTCDASD environment.

Products

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

Issue/Introduction

In a synchronized MIMplex, only the first few blocks of the control file are normally used. The largest usage of control file space usually occurs during MIMplex transition states, such as when a new CA MIM address space is joining an existing MIMplex or when a control file migration is occurring. During these transition states, CA MIM may generate a large volume of transactions to communicate the current status of the resources managed by each component to the systems requiring this information.

 

Environment

Release:  12.5
Component: MIM

Resolution

The CA MIM control file must be large enough to accommodate the number of transactions generated during these transition states. The amount of space required during these transition states depends on the components active in the MIMplex, and also may depend on workload.

If the CA MIM control file is not large enough to accommodate the number of transactions generated during these transitional periods,you may see the following MIM messages indicating problems with control file sizing:

MIM0054W File type - APPROACHING CRITICAL SPACE LIMIT
MIM0055 FILE type - TOO SMALL FOR YOUR SYSTEMS

NOTE: If this control file is a virtual control file, then the value ?VCF? appears in place of the type variable. If this control file is a DASD control file, then its ID appears in place of this variable.

In a MIM environment using a communication methodology of DASDONLY, or CTCDASD, an outage is not required to resize the MIM control file as the MIM control file can be resized dynamically.

For sites using the CA MII (GDIF) component, the DISPLAY GDIF CFSIZE command to estimate how large the control file should be.

The DISPLAY CFSIZE command displays the recommended size of the CA-MIM control file for the GDIF facility. The control file size required by GDIF is dependent on ENQ workload or, more specifically, the peak number of global ENQ resources. This command takes this number and other metrics, which are maintained by GDIF, and calculates the GDIF size required for the control file. GDIF maintains both current and peak metrics; therefore, both current and peak requirements are displayed by the command.

The number of GHBs and GCBs may vary widely by system since the scope of these data structures is local. The current number of global resources and QNAMEs should typically be the same since this information is global in nature. However, this command does not serialize its calculations, so the current numbers may vary across systems, particularly for the more volatile numbers, such as the number of global resources.

The peak numbers are based on peak metrics that are maintained on a system-by system basis. This information is not passed to external systems. Furthermore, the peak numbers are not persistent across product restarts since peak number metrics are reset to zero with each restart of CA-MIM. As CA-MIM runs, the peak numbers increase and become more accurate. This increase in peak numbers and accuracy, coupled with rolling IPLs or product restarts, because the peak numbers to vary across systems. If you execute the command on multiple systems, you should take the highest of all recommended sizes and size your control file based on that number.

When allocating larger control files, it is recommended that the alternate control files be allocated larger then their predecessors. (ie: each file a little larger than the file before it).

The following steps should be taken when allocating the larger control files which will avoid having to cycle the MIM address space:

From one system in the MIMPLEX:

1. Migrate to the backup MIM DASD control file
   
   F MIMGR,MIGRATE CONTROLFILE=01

From all systems in the MIMPLEX:

1. De-allocate the Primary DASD control file - DEALLOCATE DDNAME=MIMTBL00
   
   
2. Rename the Primary DASD control file to something like ...OLD
   
   
3. Allocate a new/larger Primary DASD control file using ALLOCCF JCL.
   
   
4. Allocate to MIM the new Primary DASD control file:
   
   F MIMGR,ALLOCATE DDNAME=MIMTBL00 DSN=XXXX.XXXX.XXXX
   (XXXX.XXXX.XXXX=WHATEVER YOUR MIM CONTROL FILE NAME IS)

From one system in the MIMPLEX:

1. Migrate the Backup DASD control file to the new Primary:
   
   F MIMGR,MIGRATE CONTROLFILE=00

From all systems in the MIMPLEX:

1. De-allocate the Backup DASD control file - DEALLOCATE DDNAME=MIMTBL01
   
   
2. Rename the Backup DASD control file to something like ...OLD
   
   
3. Allocate a new/larger Backup DASD control file using the ALLOCCF JCL.
   
   (Backup DASD control file should be larger then the Primary DASD control file)
   
   
4. Allocate to MIM the new Backup DASD control file:
   
   F MIMGR,ALLOCATE DDNAME=MIMTBL01 DSN=XXXX.XXXX.XXXX
   (XXXX.XXXX.XXXX=WHATEVER YOUR MIM CONTROL FILE NAME IS)