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. |