Release Notes
				    for
		 RAID Array 200 Software V2.2 for OpenVMS


File Descriptions

DEC-AXPVMS-SWXCR-V0102--3.PCSI          PCSI installable Extended Utilities
                                        for OpenVMS V6.1
DEC-AXPVMS-SWXCR-V0300--1.PCSI          PCSI installable GUI and Extended
                                        Utilities for OpenVMS V6.2 and later
INVOKE_PCSI.COM                         Installation file for the utilities


Utilities Provided with this Kit

This kit contains an extended command line utility, SWXCR, used for
monitoring the RAID array and performing parity checks on its
devices. SWXCR is supported on OpenVMS version 6.1 and higher.  A GUI based
RAID management utility, SWXCRMGR, is supported on OpenVMS version 6.2 and
higher.  Prior to installing the extended utilities on systems running
OpenVMS V6.1, you should install the SWXCR kit found on the OpenVMS V6.1
distribution media.


Performing Rebuilds with the SWXCRMGR

When performing rebuilds across multiple controllers with the GUI, rapidly
changing back and forth between controllers can cause the utility to
crash. The utility crash does not otherwise affect system operation and all
rebuilds will continue. We recommend not switching controllers after the
last rebuild has started until all rebuilds complete.


SWXCRMGR Does Not Report Automatic Rebuilds

The GUI does not report rebuilds that the controller automatically
initiates. If an automatic rebuild is occurring the GUI will mark the drive
as WOL. Do not start a second rebuild on a controller that is currently
doing an automatic rebuild.  


Canceling a Parity Check or Rebuild with the SWXCRMGR

You can cancel a parity check or rebuild that is in progress by reselecting
the Parity Check or Rebuild function from the Management menu, and then
clicking the cancel button on the main window.  


VMScluster Support

VMScluster support is provided for users of OpenVMS V6.2 and
later. Previous version of these utilities would not operate properly in a
cluster environment when the SYSGEN parameter DR_UNIT_BASE number was
non-zero. However, in a cluster environment, multiple servers could not
both be set to zero. SWXCR Utilities have been modified so that they will
operate properly when DR_UNIT_BASE is non-zero.

The modifications made to the utilities affect the SWXCR Monitor, the
SWXCR Parity Check utility, and the SWXCR Manager.

The DR_UNIT_BASE number on any given node in a VMScluster environment
should be set at least eight apart from all DR_UNIT_BASE numbers on other
nodes in the VMScluster environment, in order to avoid naming conflicts.


SWXCRMGR

The SWXCRMGR program has been modified to allow examination of controllers
on systems that have non-zero DR_UNIT_BASE values.


SWXCR MONITOR

The process name is changed from SWXCR$MON_DRx (where `x' is the controller
letter of the device specified in the `SWXCR MONITOR' command), to a name
composed as follows:

  "SW$" + DECnet-node-name + "$" + allocation-class + controller-letter

 For example, if the user types the following command:

     $ SWXCR MONITOR DRA10

on node ASTRO, where the allocation class is set to 5, the process name
will be set to:

     SW$ASTRO$5A

This naming convention, used above for the process name, is propagated to
the log file name and the mailbox name, as well.

Using the example above, the log file name would be:

     SW$ASTRO$5A.LOG

and the mailbox name would be:

     SW$ASTRO$5A_MBX

Note that when you are running SWXCR MONITOR in a VMScluster environment,
only those controllers that are local to the current node can be monitored
from that node.  In order to monitor a controller connected to a different
node in the cluster, you must log into that particular node and start a new
monitor process for that particular controller.  If you attempt to monitor
a controller which is not local to the current node in the cluster, an
error is returned.


SWXCR CHECK

In a VMScluster environment, you may only perform a parity check operation
on a device that is local to the node from which you are operating. In
order to perform a parity check (with our without repair) on a logical
drive associated with a controller connected to a different node in the
cluster, you must log into that particular node and then issue the
appropriate "SWXCR CHECK" command. If you attempt to perform a check
operation on a logical drive unit that is not local to the current node in
the cluster, an error is returned.