Actually no, none of them worked unfortunately :-(
How did you test them? Just wondering if there might be VAX quirks which
means that they may actually be OK...
I plugged the disks into the SCSI cable that was in my VAXstation 4000
Model 60. The disks would not show a size in the SH DEV command. There was
another disk on the cable, so if not properly terminated I would have
expected neither disk to be recognised, but the existing disk was
recognised. I could boot off the existing disk but could not mount the
other disks in any way (fatal drive error, or media offline were the
errors).
I will however check the termination just to be sure it isn't that.
Yes, do double-check the termination - that the bus is terminated, and that
the termination is at the ends (I've seen cases where someone plugs a new
device in 'downstream' of an existing drive, where it's the existing drive
itself that's set up to terminate the bus, and that can cause weird things
to happen).
Make sure that there aren't any SCSI ID conflicts - although I'd expect
nothing to really work in that situation.
Are the 'new' drives definitely spinning? Some SCSI devices expect a 'start
unit' command to be sent before they'll spin up (it's typically a
jumper-configurable option) and I've no idea if a VAX does that by default.
A VAX normally expects to have to command drives to spin up.
I have heard of problems with older SCSI disks which claimed to support bad
block replacement or other optional features which the disks did not implement
properly. This often didn't get noticed in lightweight applications but when
exercised by as OS like VMS, problems became apparant. Some disks also did not
implement commands to disable the broken features. The response from DEC was
to have VMS attempt to recognise the disks which did not do the right thing
and fail to mount them, probably with "fatal drive error" or similar. The
disks being tested here might be broken as designed.
Later versions of VMS may have some SCSI tools in SYS$ETC which could be used
to interrogate the disks.
Regards,
Peter Coghlan.
