Recommendations and guidelines for mismatch resolution

The mismatch resolution dialog allows you to resolve mismatches that occur if several users modify multiple local copies of the same configuration either in connected mode or in stand-alone mode. Depending on the changes, the Physical Mismatch Resolution dialog may get very voluminous and requires a careful selection of the changes that should be taken into the MCF. Therefore, it is strongly recommended to plan the changes between the co-workers. The following guidelines and recommendations assist you in taking advantage from working in parallel using the MCF mismatch resolution.

To avoid rework after the mismatch resolution, note the following guidelines:

• Rename complete objects, for example, controller labels or string labels, only in connected mode and when no other configuration work is done in parallel. The same is true for the renaming of panel IDs or device types. This is recommended because the comparison of configurations is based on the contents of the key columns in the exported files from the HCM Export Data… function. Therefore, a renamed object is interpreted as both a deleted old and an added new object, thus resulting in an unexpected amount of mismatches.
• Converter labels are implicitly assigned with a name that includes a sequence number when connecting a parallel to a serial interface. Since the Physical Mismatch Resolution dialog shows a modification for matching labels, it is recommended to apply unique names to the converter labels in a configuration.
• Avoid to perform changes on controllers or strings when working in parallel or in stand-alone mode, for example, rearranging controller channel or device interfaces, or reassigning units or devices. HCM may not be able to resolve such a mismatch properly. The same is true for modifying connections between controllers and strings, as well as for changing the physical description file (PDF) of a controller.
• Before working in stand-alone mode, first connect to the host to download the latest version of the MCF configuration.
• After having finished work in stand-alone mode, do not defer reconnecting to the host in order to put the changes into the MCF.

Therefore, when performing mismatch resolution, respect the following recommendations:

• If a connection is selected, make sure that also the connecting objects (with matching interface types) are included in the target configuration. Otherwise, the connection cannot be established.
• Carefully review the Summary page displayed by the Physical Mismatch Resolution dialog, especially for mismatches that are not successfully resolved. If this is due to an inconsistent selection, press the Discard Resolution button and correct the current selection.

Consider, for example, a straight connection between a controller and a channel path: the controller and the connection may exist in the master configuration, but not in the local configuration. This results in one mismatch for the controller and a separate mismatch for the connection. The user might now select the connection to be included into the local configuration, but not the controller. This selection is inconsistent: when trying to establish the connection, HCM fails on this particular mismatch because one of the two objects to be connected is not present in the local configuration (the controller that was de-selected). This is listed on the dialog's Summary page as a failed mismatch with the reason indicated such as ‘object not found <controller interface name>’.

The following changes may be done in stand-alone mode and later included smoothly in the MCF:

• creation, deletion and modifications of physical-only connections between processors, switches, crossbar switches, and controllers
• inclusion and modification of cables in the configuration
• definitions of cabinets and general boxes
• inclusion of patchports into physical connections
• definition and modifications of user fields

You can use mismatch resolution for efficient work in the following scenario of a configuration file that includes two sites, A and B:

1. The system programmer responsible for the I/O configuration of site A performs changes working directly with the MCF in host-connected mode.

   At the same time, the hardware planner of site A defines cables for the physical connections in stand-alone mode. Afterwards, the hardware planner connects to the host and updates the MCF via the Physical Mismatch Resolution dialog.

2. Now, the system programmer who is responsible for the I/O configuration of site B performs changes in connected mode, based on the previous changes that are contained in the MCF. The hardware planner of site B may perform physical-only changes in stand-alone mode and include them later in the MCF via mismatch resolution when the system programmer has finished his work.