|
HP OpenVMS Systemsask the wizard |
|
The Question is: re :RZ28L SCSI disk on VAXstation 4000? I verified the configuration when I returned back to town. My boot drive is indeed an rz28d 2.10 Gb disk drive and is so far working fine under vms5-5.2 on a vaxstation 3100-10 Thks for the info regarding the vaxstation 4000-60 The Question is: I recently purchased an RZ28L disk drive. It has been installed into a vaxstation 4000-60. At the config prompt it is properly recognized. When the system is booted up we see the disk offline. When we init the disk we get a fatal drive error. Is the rz28l supported in this configuration. I have a 2GB disk installed on a vaxstation 3100 model 10. Not sure of the exact model but it works fine there. I think it may be rz28. ---------------------------------------------------------------------------- ---- The Answer is: You will want to check the error log for additional information on the specific error being reported. There is no VAXstation 3100 model 10, and system disks larger than 1.073 GB do not "work fine" on any member of the VAXstation 3100 series, nor on the MicroVAX 3100 model 10, nor on the MicroVAX 3100 model 20. Data disks can be larger on these systems. (See the OpenVMS FAQ for details, and for other potentially limits.) As for the problem with the RZ28L, some of these disks can be sensitive to the length of the SCSI reset pulse used on the VAXstation 4000 series. This could be a case of SCSI disk settings that are incompatible with an OpenVMS release as old as that referenced here -- both OpenVMS V6.2 and V7.1 have changes to the SCSI disk drivers that improve compatibility with a variety of drive settings, it is best to move to at least V6.2. The most common problem operating with SCSI disks on OpenVMS releases prior to OpenVMS V6.2 is the setting of the ARRE and AWRE bits in the disk mode pages -- older OpenVMS releases require these to be disabled. The Wizard would recommend contacting your local hardware support organization for further assistance. The Answer is :
Please read the OpenVMS Frequently Asked Questions (FAQ) for information
on the topic of the 1.073 GB disk.
The phrase "so far" in your statement is the single most important
phrase in the sentence. The Wizard can assure you that it is only
luck (good or bad, depending on you perspective) which allows this
system to bootstrap. The boot ROMs on all members of the VAXstation
3100 family, on the MicroVAX 3100 models 10 and 20, and on the older
(console VMB versions prior to V6.4) MicroVAX 3100 models 10e and 20e
systems can only address a maximum of 1.073 GB on the system disk.
So, if all the critical boot files, and their headers and directory
paths happen to live below that boundary, the system will -- as you
have found -- bootstrap. Anything which can move any of these core
bootstrap files -- activities such as a system disk BACKUP and restore,
disk defragmentation, a COPY command, the installation of an ECO etc.
-- can render the system unbootable.
Thus far, the behaviour of this limit appears relatively benign,
only preventing certain system disks from bootstrapping. If the
system dump file is partially or fully (re)located above this
threshold, the system disk can be severely corrupted on a system
crash -- the same (address-limited) primitive device drivers used
to read the system disk during bootstrap are also used to write the
crashdump.
Remember that your INDEXF.SYS is, by default, in the middle of the
disk, and files tend to get allocated from side to side towards the
outer edges. So it's just a matter of luck which side your files fall,
and whether or not the dump file has storage allocated above the 1.073
GB "boundary".
One can attempt to "play games" with INITIALIZE and with explicit placement
of files to try to maintain a bootable disk, or with tools such as virtual
disk drivers, but the bottom line is this is not supported -- future
system managers unfamiliar with these "games" could easily be left with
a mysteriously unbootable (or corrupt) system disk after a normal system
activity. Please see the OpenVMS FAQ and elsewhere on the web for further
discussion on this subject.
Now, your problem with the VAXStation 4000/60 and the RZ28. It's possible
that you have an old version of the base system ROM which is issuing a
SCSI bus reset of too short a duration for the particular model of disk.
The part number for the new VAXStation 4000/60 firmware
rev V1.4 is 23-282E8-00(PV20.hex location E59) and 23-283e8-00
(PV21.hex location E68).
If you are already at V1.4, the symptom could also be caused by a
misconfigured SCSI - not terminated, terminated more than twice, external
cable too long, duplicate IDs, etc. If there is any slack in the SCSI
bus cabling, shorten it. If there is any way to reduce the number of
external enclosures, remove them.
Note that the VAXstation 4000/60 predates the RZ28, so the systems were
not originally qualified with those drives. Please contact your local
customer support centre to obtaim the above firmware update (and have
a major credit card or cheque book ready!)
|