| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5269.1 | Looks good..but | CSC32::S_DANNEN | Live long and slobber | Wed Mar 26 1997 19:42 | 6 |
| Mike, your configuration looks great. Except that we do not support
SCSI tapes, Floppy's or CDROM on shared SCSI bus (Please correct me
if I am wrong,....anybody!) Could you provide the version of OpenVMS
the customer is intending to run?
/steve
|
| 5269.2 | How about DSSI? | BIGCHZ::EZZELL | Mike Ezzell | Thu Mar 27 1997 08:52 | 11 |
|
> Mike, your configuration looks great. Except that we do not support
> SCSI tapes, Floppy's or CDROM on shared SCSI bus (Please correct me
> if I am wrong,....anybody!) Could you provide the version of OpenVMS
> the customer is intending to run?
Thanks for pointing that out. I thought that we supported tape
on HSZ. Is this only on a non-shared bus?
Perhaps DSSI would be a solution for tapes.
|
| 5269.3 | | STAR::CROLL | | Thu Mar 27 1997 09:11 | 15 |
| There are two reasons for disks only on shared SCSI buses.
The first has to do with port allocation classes -- these are implemented for
disks only. A tape on a shared SCSI bus could, potentially, have different
device names, which would cause corruption problems.
The second has to do with the fact that tapes, floppy drives and CDROM drives
are slow. There are (frequent) SCSI commands to these devices that tie up the
bus for long periods of time, which causes problems on shared SCSI buses.
I don't know how an HSZ50 affects this issue, but I suspect that the "no tapes"
rule caused us to not investigate tapes any further. I'll poke the SCSI experts
to see if there's anything else to say about this...
John
|
| 5269.4 | | EEMELI::MOSER | Orienteers do it in the bush... | Thu Mar 27 1997 13:39 | 18 |
| the major problem with tapes on the shared SCSI bus is the fact that
after a 'bus reset' a tape has to unwind (according to SCSI-2
standard). So if one node is doing the monthly backup and the other a
shutdown/reboot, you'll get a tape rewind in the middle of the backup
which makes this a little unreliable.
Theoretically, a tape on the HSZ50 works just fine (as it is the case
for a supported configuration with single host only). Folks might go
and do that in test systems etc. in order to move data from tape to
disk, but I wouldn't recommend it in a production environment.
Currently there is no way of not letting any bus resets through the
HSZ50. Maybe in the future when SCSI-3 comes along things will change.
re: .3 hmh, I have to test that tape issue and PAC's. I was pretty sure
it was done for both, but then I have been wrong many times before...
/cmos
|
| 5269.5 | 3 CIPCA/4100 now supported. | STAR::BOAEN | LANclusters/VMScluster Tech. Office | Thu Mar 27 1997 15:20 | 11 |
| Your customer can put his tape(s) on a 3rd star if he wants.
We now support 3 CIPCAs on a 4100 under both V6.2-1H3 & V7.1.
A Sales Update article announcing the CIPCA-BA (2 PCI modules)
should be out, or will appear any day now. It has a table with the latest
config. info including this config.
You can contact RawHide product management or CIPCA product mgt. for
confirmation.
Verell
|
| 5269.6 | | STAR::NCARR | Talk dates & features - but never together.... | Thu Mar 27 1997 16:34 | 3 |
| Note that the SPD and Systems & Options Catalogue both say that 4 CIPCAs
are supported in a 4100. However, slot allocations make this impractical in
most cases, so at the next update the number will be reduced to 3.
|
| 5269.7 | Port allocation classes do support tapes.... | STAR::CROLL | | Fri Mar 28 1997 09:29 | 10 |
| I wrote this in .3:
>The first has to do with port allocation classes -- these are implemented for
>disks only. A tape on a shared SCSI bus could, potentially, have different
>device names, which would cause corruption problems.
This is incorrect. SCSI tapes *DO* support port allocation classes. Forgot to
aim before I shot...
sorry for any confusion
|