| first of all, you can't put tapes on the shared SCSI bus, because
they'll rewind/unwind should a bus reset occur, hence they are not
supported.
Second, KZPDA is not supported in a multihost configuration.
/cmos
|
| Hello!
Thanks for your reply and I would like to clarify some issues and answer your
queries too.
1. The KZPDAs are not multi-host. The KZPDA is connected to a bay with
3 RZ29Bs and TLZ09. A DWZZA is in slot 0 chained to a TZ877. The other
system has the same set up but the 2 systems do not share these devices.
2. We are using 2 as the allocation class for both systems.
SHOW DEV shows: Remarks SHown in console prompt
$2$DKA500: CDROM DKA500
$2$DKB0: HSZ04#1 JBOD DKC0
$2$DKB2: HSZ40#1 JBOD DKC2
$2$DKB3: HSZ40#1 JBOD DKC3
$2$DKB100: HSZ40#1 RAID0 DKC100
$2$DKB301: HSZ40#1 RAID0 DKC301
$2$DKB302: HSZ40#1 RAID0 DKC302
$2$DKC100: KZPDA DKB100
$2$DKC200: KZPDA DKB200
$2$DKC300: KZPDA DKB300
$2$DKD0: HSZ04#2 JBOD DKD0
$2$DKD1: HSZ40#2 JOBD DKD1
$2$DKD2: HSZ40#2 JBOD DKD2
$2$DKD3: HSZ40#2 JBOD DKD3
$2$DKD100: HSZ40#2 RAID0 DKD100
$2$DKD301: HSZ40#2 RAID0 DKD301
$2$DKD302: HSZ40#2 RAID0 DKD302
DKC100, DKC200, and DKC300 are the disks in question here. The above info are
seen
on both systems. Only one set of these disks can be accessed under VMS.
You will notice that the disks on controller B under console prompt becomes C
under VMS while those in controller C under console changed to B under VMS. Is
this normal? It is somewhat confusing too.
Can we change the controller ID for KZPDA to another so we can use all the
disks?
There is only 1 available slot on the bay connected to KZPDA hence we can not
simply move the disks around to have unique SCSI IDs.
Regards.
Noel
[Posted by WWW Notes gateway]
|
| First the easy one:
The fact that the console sees a different device name from VMS is a
normal occurrance. The reason is that the console and VMS use somewhat
different algorithms for locating the hardware, so what the console sees
will differ from what VMS sees, especially as the configuration gets
more complex. What the console shows as device names is irrelevant
here. (And, yes, it is confusing. Many people have tried for many
years to fix this, to no avail. At this point it's kind of like Don
Quixote and the windmill....)
Now for the harder one.
Each system sees its own set of DKCxxx disks. Because the allocation
class on each system is 2, each system names these disks as $2$DKCxxx.
When you put these systems into a cluster, you now have two different
devices with the same name, which doesn't work. VMS treats the second
instance of the device as a second path to the first device, and,
because of the timing of device discovery, each system may make a
different choice about which device is the real device.
So, you have to change the names of one set of DKCxxx devices. There
are only two ways to do this.
1) Re-arrange the order of the controllers in one system. This may not
be possible for you, due to the needs of the other controllers or the
rest of the system configuration. It also introduces a difference in
otherwise identical configurations, which makes supporting them that
much more difficult. So the reccommended solution is...
2) Assign a different port allocation class to each set of KZPDA
controllers. This will give each set a different name, distinguishing
them and making both sets available to VMS. One set will be known as,
say, $3$DKCxxx and the other as $4$DKCxxx.
Port allocation classes requires V7.1, or the Redhawk kit for V6.2.
They are described in the OpenVMS Cluster Systems Manual for V7.1.
|