9.1 GB disk on vaxstation 4000/90 VMS 5.5-2?
Robert Deininger
Hello All,
I'm wondering if it is possible to make a 9.1 GB disk work on a
vaxstation 4000/90 running VMS 5.5-2. (Yeah, I know we should upgrade
VMS. The first intended job of this drive is to give us space to do a
series of upgrades without chomping the existing system disk in the
process. But first, it needs to _work_.)
I want to use the new drive as a NON-system disk. It's a Quantum Atlas
II, sold to us as compatible with our machine and OS version. The console
program recognizes the drive as a SCSI disk, but reports the size as
514.20 MB.
After booting VMS, any attempt to $MOUNT/FOREIGN or $INIT this drive gives:
%xxxxx-F-DRVERR, fatal drive error
This looks pretty final to me. I don't know of any switches or
adjustments that might fix it. Do I need to send it back?
I'm pretty sure there are no problems with SCSI IDs/cables/termination
etc. The two older SCSI drives in the system continue to work fine with
the new drive in place.
In case it matters, the machine identifies itself as follows:
>>> show config
KA49-A V1.3-0BC-V4.4 71 MHZ
Thanks for any advice you can give.
...I just ran across the week-old thread "Can't INIT IBM 1080 MB drive",
and reading it didn't make me more optimistic. The error counter on the
new drive DOES get incremented the first time I try to access it. I'll
fiddle with ANALYZE/ERROR tomorrow and look for the two evil bits, but I
think I already know what I'll find. Ugghh!
-- Robert
dein...@legs5.phy.bnl.gov
Michael Moroney
In article <deininger-240...@legsmac1.phy.bnl.gov>,
dein...@legs5.phy.bnl.gov (Robert Deininger) wrote:
> Hello All,
>
> I'm wondering if it is possible to make a 9.1 GB disk work on a
> vaxstation 4000/90 running VMS 5.5-2. (Yeah, I know we should upgrade
> VMS. The first intended job of this drive is to give us space to do a
> series of upgrades without chomping the existing system disk in the
> process. But first, it needs to _work_.)
V5.5-2 cannot handle drives larger than ~8.5 GB. V6.0 and later can handle
into the terabyte range.
You'll have to find some way to upgrade to at least 6.0 before using it.
Also the VMS SCSI drivers for some early versions tend to choke on certain
non-DEC drives. (the two evil bits you mention) (V7.1 is much better regarding
this)
> I want to use the new drive as a NON-system disk. It's a Quantum Atlas
> II, sold to us as compatible with our machine and OS version. The console
The drive is certainly not compatible with the OS version of V5.5-2.
-Mike
Glenn C. Everhart
re: 9gb disk on vms 5.5-2...
Run something that sends packack to the disk (io$_packack that is). You
need phjy_io to do this btw.
If sho dev/full shows a legal geometry (ie trk*sect*cyl .GE. maxblocks)
and if maxblocks looks to cover the disk, you can use vddriver and
its /lbn:nnn/len:mmm to use the disk in pieces. Don't let any of the
pieces be larger than about 8GB for VMS 5.5-2; there are only 24 bits
of block number the filesystem can handle there. (6.0 and above
fixed that.) Given this, presuming it works, you can operate.
If the geometry comes out wrong, try bashing it in kernel with
some suitable bash tool (I use zapmem that someone posted awhile back)
to reflect the actual maxblocks and some geometry or other that is
big enough...doesn't matter what. If the device is online after the
packack, dkdriver may then still accept I/O and you can use
the vddriver tricks to use it in parts. If it is offline, see if
the error log says what is wrong. You could be hosed or ther e
may be hope. Depends on scsi parameters for the most part. You may have
to run something, for example, to turn off awre/arre on the drive
or play some similar tricks. It's been a while since I hacked on a
5.5-2 dkdriver and dkdriver has changed a WHOLE WHOLE LOT since
then
Glenn Everhart
Stephen Hoff Hoffman
In article <deininger-240...@legsmac1.phy.bnl.gov>, dein...@legs5.phy.bnl.gov (Robert Deininger) writes:
: I'm wondering if it is possible to make a 9.1 GB disk work on a
:vaxstation 4000/90 running VMS 5.5-2. (Yeah, I know we should upgrade
:VMS. The first intended job of this drive is to give us space to do a
:series of upgrades without chomping the existing system disk in the
:process. But first, it needs to _work_.)
Then you need to upgrade to at least OpenVMS VAX V6.0. (V7.1
is the current release.)
OpenVMS VAX versions prior to V6.0 do not support disks larger
than 8.5 GB, as a data or a system disk. With V6.0 and later,
1 TB disks are supported, subject to system console limitations
or other platform- or interface-specific limits.
Third-party devices are not generally supported by OpenVMS, save
for those sites with specific DIGITAL support contracts.
: I want to use the new drive as a NON-system disk. It's a Quantum Atlas
:II, sold to us as compatible with our machine and OS version.
It's not compatible.
:This looks pretty final to me. I don't know of any switches or
:adjustments that might fix it. Do I need to send it back?
You could upgrade to V6.0 or later.
You *might* then get this to work, but -- given your experience
so far -- it would appear like you will be responsible for at
least some of the integration and testing work with this drive.
You may/will also have thermal restrictions, and may/will have
drive firmware oddities. (V6.2 and later releases are typically
better at handling third-party drives.)
:...I just ran across the week-old thread "Can't INIT IBM 1080 MB drive",
:and reading it didn't make me more optimistic. The error counter on the
:new drive DOES get incremented the first time I try to access it. I'll
:fiddle with ANALYZE/ERROR tomorrow and look for the two evil bits, but I
:think I already know what I'll find. Ugghh!
Also acquire a copy of the OpenVMS Frequently Asked Questions (FAQ).
This question -- and many others -- is answered there.
ftp://ftp.digital.com/pub/Digital/dec-faq/vms
ftp://rtfm.mit.edu/pub/usenet/news.answers/dec-faq/vms
The MIT site has a slightly more recent copy of the FAQ -- updates to
the FAQ and the FAQ site are currently blocked behind the FAQ Author's
current schedule of `real work'.
-------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering h*ff...@xdelta.enet.dec.c*m
headers and addresses munged to avoid automated spammers: junk-e-mail