Fixed utility devices

For fixed utility devices, XRC always reads data from the storage control using this device, thus eliminating application contention for devices. The following recommendations apply to these devices:

Select dedicated fixed utility devices that are not used for any other purpose.
Ensure that the device is not reserved by other applications. This is not a concern on 2105 subsystems; it only applies for non-2105 (3990 subsystems, for example).
Ensure that the first device added to a session for a particular storage control be a fixed utility device.
Define the fixed utility device as a single cylinder device if a storage control is an IBM® 2105 ESS. Specify a single fixed utility device per storage control session.

Under certain conditions, you may want to remove potential interference between the primary system and the SDM. You can do this by defining a dedicated (fixed) utility device address per storage control session. Fixed utility devices are preferred if:

You have a few volumes available to select from
You are running in a channel-extender environment
You want to isolate the SDM I/O to a single primary volume for ease of monitoring, tracing, or debugging
You want to isolate the SDM I/O so it does not interfere with any primary system I/O

In a channel-extender configuration, it is highly recommended that you define fixed rather than floating utility devices for the following reasons:

With a channel-extended configuration, telecommunication links tend to be the most vulnerable. If they fail, it is essential that you do not leave a production volume in the status of an XRC utility device. If an application attempts to reserve a primary volume that is currently being used as a utility device, message IEA482I is written to the system log (SYSLOG). The application program will not be able to proceed until the storage control session is suspended.
The channel extender definition and error recovery are at a device level. Error recovery works better if a single device is used by the SDM to read the updates for each storage control session because of the method that is used to communicate errors to IOS.
You can vary all nonutility devices offline to the SDM so that your Resource Management Facility (RMF™) device activity report contains only the utility device status.
You can define utility devices on additional paths to improve resilience and performance.

To move from floating to fixed utility devices, it is not necessary to end or suspend an XRC session. You can issue the XSET UTILITY(FIX) command, and then issue the XADDPAIR command for the designated XRCUTL device (even if the device is already in the session).

Table 1 describes device utility support when the XSET command is specified with UTILITY(FIX) and the XADDPAIR command with a secondary volser of XRCUTL is specified.

Table 1. Specifying UTILITY(FIX) and the XADDPAIR command with a secondary volser specifies as XRCUTL
If . . .	Then . . .
The primary volser is not in the session.	It is added and it becomes the fixed utility device.
The primary volser is already in the session, its secondary volser is XRCUTL, and there is no outstanding XDELPAIR command issued against it.	The primary volser becomes the fixed utility device.
The primary volser is already in the session, its secondary volser is XRCUTL and there is an outstanding XDELPAIR command issued against it.	The XADDPAIR command is rejected, with return code 4027.
The primary volser is already in the session and its secondary volser is not XRCUTL.	The XADDPAIR command is rejected, with return code 489.