Troubleshooting › How You Respond to Control File Access Delays › Message MIM0100A

Message MIM0100A

CA MIM issues message MIM0100A if it cannot access a DASD control file that it needs to communicate transactions or to store checkpoint information.

Note: The LOCKOUT parameter on the SETOPTION command determines how many seconds CA MIM waits before issuing the MIM0100A message.

The ID for the inaccessible control file, as well as the unit and volume serial number for the device where this control file resides, are shown in this message. The reply ID for this WTOR message is shown at the very beginning of the message.

Take the following steps to resolve problems indicated by this message:

1. Wait to see if the local system can access the control file. CA MIM removes highlighting from the MIM0100A message if the system accesses the control file.

   Is the highlighting removed for the MIM0100A messages?

   Yes

   A temporary lockout occurred. That is, excessive activity or RESERVE requests temporarily prevented CA MIM from accessing its control file. You do not need to take action.

   If temporary lockouts occur often, then consider moving the control file to another volume. Also, you can increase the value for the LOCKOUT parameter on the SETOPTION command, so CA MIM waits longer before issuing MIM0100A messages.

   No

   Go to Step 2.

2. See if an external system has a long RESERVE request for the control file. To do this, see if CA MIM is issuing MIM0061W messages on any other system.

   Are other systems displaying MIM0061W messages?

   Yes

   A task on that external system may have issued a long RESERVE request for the volume where the control file resides. This prevents other systems from accessing the control file.

   To see if this happened, issue a DISPLAY RESERVES command from the system that displays the MIM0061W message. Note that this command is available only when you are running GDIF. In response, CA MIM issues message MIM1017, which lists the name of each job on the system that has an outstanding RESERVE request. Use this information to see whether any job controls the device on which the control file resides. The UCB address of the device is shown in MIM0100A messages.

   When a job has a RESERVE request for this device, you can wait for the job to issue a DEQ request. However, if the job does not issue a DEQ request soon and system performance continues to deteriorate, then cancel the job.

   If no job has a RESERVE request for this device, then go to STEP 3.

   No

   Skip STEP 3 and go directly to STEP 4.

3. See if other systems are dominating the control file. To do this, issue the DISPLAY IO=RESET command on each system that displays the MIM0061W message. Ignore the MIM0039 messages you receive. Wait ten seconds, and then issue a DISPLAY IO command on each system.

   Look at the statistics beneath the LAST RESET field on the last MIM0031 message. For each external system, multiply the number of cycles per second (represented by the CYC field on the RATE line) by the duration of an average cycle (represented by the CYC field on the AVG line). Then, total the values.

   What sum do you get?

   Close to One

   Other systems are dominating the control file. Perform one of these tasks:

   When you are using virtual control files, increase the value for the VCFMINDORM parameter on the SETOPTION command by .5 on each of those other systems.

   When you are not using virtual control files, issue a SETOPTION MODE=GROUPS command on each of those other systems. Also, change the value for the INTERVAL parameter on the SETOPTION command to .2 and change the value for the CYCLES parameter to 5.

   Not Close to One

   Go to Step 4.

4. See if hardware or software failed on an external system. To do this, issue a z/OS D A,L command on each system that is not displaying a MIM0100A message.

   What response do you get?

   None

   A hardware or software failure occurred on that system while the system had an outstanding RESERVE request for the device where the control file resides. You may need to perform a system reset (to clear the channel to the device) and then complete an IPL on that system.

   If you are sure that the system will not recover immediately, then free resources held on that system by issuing a FREE command from any other system. For example, to free resources held on system A1, issue a FREE A1 command from any other system.

   Message IEE104I

   Go to Step 5.

5. See if CA MIM is being dispatched on the inactive system. To do this, issue the z/OS D A,MIMGR command several times from the apparently inactive system (note that MIMGR is the name of the CA MIM started task).

   Does CPU use change from message to message?

   No

   CA MIM is not being dispatched. Do the following:

   1. Determine which task on that system is preventing other tasks from being dispatched.
   2. Correct the error.

   Yes

   Go to Step 6.

6. See if the device on which the control file resides failed. Do this in one of the following ways:
   • Look for MIM0118E or MIM0008E messages on other systems. These messages tell you an I/O error occurred when CA MIM tried to access its control file.
   • Use the z/OS D U command to display status information for this device. Append the address of the device address to this command. For example, issue the command D U,,,3C3,1 to display status information for device 3C3. MIM0100A messages show the UCB address for this device. You can issue this command from any system.
   • Look for z/OS IOS000I messages about this device. This message tells you a hardware failure occurred.

   Did the device fail?

   Yes

   Initiate migration to a DASD control file that resides on a different device. To do this, reply ABANDON to the outstanding MIM0100A message on all systems.

   All systems join the migration process automatically, only if all MIM0100A messages on all systems are cleared.

   No

   Go to Step 7.

7. See if a channel or control unit failed. To do this, go to a system that displays the MIM0100A message. From there, use a z/OS command to obtain status information about the channels and control units connecting the local system to the device where the control file resides. Use a z/OS display command appropriate for your version of z/OS.

   Do any channels or control units have an unusual status (such as BOXED or SUSPENDED)?

   Yes

   The channel or control unit failed. Initiate migration to a DASD control file that resides on another device by issuing a MIGRATE command from any system. For example, to migrate from file 01 to file 02, issue a MIGRATE CF=02 command.

   All systems join the migration process automatically.

   No

   Contact CA Technical Support.