Dwight,

We have been doing this for a few months.

Configuration:

3 R30s, each running one instance of ADSM. At present, only one server is in
semi-production, the two others are used for testing and development.

1 3494, with 8 3590. each 3590 visible from all three platforms.

Setting up issues:

In our environment, finding the right set of scsi cables allowing to do this
type of connection is tricky, especially as we wanted to use IBM approved
cables, which come only with specific lenghts.

It helps a lot to get all three platforms using the same /dev/rmt* names for
the same device, and to enforce this between re-boots. One of the thing we do
here is to run, as part of the boot procs, one job that rmdev -d all drives,
then redefine them with the right addresses.

All three RS6000 run their own lmcpd, speaking to the robot.

We use separate scratch and private categories for each ADSM server.

usage issues:

Be very carefull about how you use check-in. We try to keep specific range of
tapes for each of the server, but this implies that we always make check-ins
for specific volumes, instead of using search=yes.

The servers do not lock tape drives which are defined to them, unless there is
a tape mounted on them. This means that it is  possible to have the same tape
drive defined in several servers. (I consider this as a bug, but understand
that some people have asked for this specific behaviour. What is needed is a
server parameter describing wether ADSM should lock drives or not). This
implies that you have two choices:

1) You define some/all of your tape drives in several/all servers, either
intentionally or by accident. However, if the same drive is accessed by two
servers at the same time, the first one will grab the drive and lock it, mount
the tape, use it. Meanwhile the second server will have a mount request
pending, until the first server dismount the tape. Depending of the type of
activity, the time allowed before the tape is dismounted, etc, this second
server request might be stuck for a VERY long time period.

2) You make sure that only specific drives are attached to specific servers, in
which case the previous problem do not occur. This implies that you loose
flexibility in your drive allocation. It is of course possible to transfer
a drive from one server to another "by hand", by deleting/defining your drive
definitions, but make sure that you update your device class mount limits
accordingly. On that subject, remember that the minimum mount limit value for a
device class is 1 (not 0), which also means that you should always leave at
least one drive on each server. (we have opened a DCR on this subject, but have
not seen anything back yet).

We have been using this second method, with success (some problems do appear
from time to time, but not related to this issue of robot sharing.)

I hope this helps. Have fun!

--
Regards
Regards

+-------------------+----------------------------------+---------------------+
| Francis Dequenne  | Systems Section                  |      /~~\  /~~\     |
| ECMWF             | e-mail: fdequenne AT ecmwf DOT int      |     /    \/    
\    |
| Shinfield Park    | Tel:    (+44 1734) 499361        |   ECMWF             |
| Reading           | Fax:    (+44 1734) 869450        |   ECMWF             |
| Berkshire RG2 9AX | Telex:  (+44 1734) 847908        |     \    /\    /    |
| United Kingdom    |                                  |      \__/  \__/     |
+-------------------+----------------------------------+---------------------+