VMS5: Fatal disk error when mounting 4.5GB hard disk

[Chris Schwartz]

We have a couple of VAXstations, a 4000-90A running VMS6.2 and a 4000-96 running VMS5.5-2. I have a 4.5GB disk and a 9.0GB disk that I can initialize and successfully mount under VMS6 (as DKA400) but not VMS5. The error message is "fatal disk error". I have also tried initializing the disk under VMS6 but it then fails to mount under VMS5 (same error). I am looking to increase the disk capacity of the VMS5 system without upgrading the OS. Is there some way I can achieve this?

[Antoniov.]

What model are your HD?
Support for non Dec/Cpq Disk was not avaiable on VMS V5 and was partially implemnted on VMS V6.
I've got 2 AXP400 and I can mount thirthy party HD on VMS V7.
Dec/Compaq had implemented some legacy control or had not developed a HD drive.
I think you cannot mount theese HD if they aren't Dec/Cpq.
Bye
Antoniov

[Willem Grooters]

It could alos be a limitation of VMS5.5: perhaps there is no support of disks over 4.2 Gb?

[Åge Rønning · Accepted solution]

OpenVMS 5.5-2 has a 24 bit VBN pointer, so the maximum size disk it can address is 8.5 gb. That means NO support for 9GB disk!!

[Chris Schwartz]

Antoniov, Willem, Age,

Thanks for your replies.

Ok, I confess I'm trying non-DEC disks, but they do work under VMS6. The 4.5GB is an IBM DDRS-34560 and the 9GB disks are a Fujitsu MAE3091LP and an IBM DNES-309170. However, we are currently running a Seagate 2GB Hawk ST32430N (which came out of a Dell PC), a 2.4GB Fujitsu M2952SYU, a 2GB Seagate ST32107N (= Conner CFP2107S) and a 1GB Conner CFP1060S under VMS5, and all are non-DEC disks. The original disks were 0.5GB Seagate ST3610N (RZ25L-E) and 1GB Seagate Hawk ST31051N (RZ26N-E).

Why do all these disks work under VMS6 but only some under VMS5? I have seen various articles suggesting an 8.5GB limit, but this does not explain why the 4.5GB disks fail.

(To my way of thinking, DEC recommended disks they had tested because they were willing to provide warranty. These days, most newer disks have better life expectancy than 10 years ago because manufacturing has improved.)

[Stanley F Quayle]

Sounds like you're a candidate for CHARON-VAX (http://www.stanq.com/charon-vax.html). ;-)

When you do the INIT under VMS 6, are you specifying anything like cluster size? If so, the disk will give you an error under VMS 5.

The other posters are correct -- you're going to be out of luck in going with big disks. Can you upgrade to VMS 6 or later? That would solve your problem.

[Chris Schwartz]

Stanley,

Thanks for the tip. For others wishing to view CHARON-VAX site, the above URL works better without the ). at the end.

The commands I use are as follows:

$ init /sys /own=[1,4] AALW03$DKA400 test
%INIT-F-DRVERR, fatal drive error
$ mount /sys /noassist AALW03$DKA400 test
%MOUNT-F-DRVERR, fatal drive error

No special qualifiers there, but I did also try the init with /INDEX=BEGIN without any success.

We have applications which use PSI and X25. I understand this has changed significantly under VMS6. We would probably need to modify and recompile a lot of Fortran and PERL apps. Initially I thought it would be easier to get the 4.5GB disk to work.

[Antoniov.]

Hi Chris,
as you I tryed use no DEC HD with VMS5 (on VAX system), VMS6 and VMS7 (on AXP system).
The trouble will be present also after init; for example I used Quantum Fireball on AXP400; I can init it, I can read and write but sometimes file on Quantum become corrupted. I was made a lot of try and last final solution were MOUNT/SYSTEM/SUB; but at least 1 time for week I hed some problem.
Now I working with theese HD on VMS7 and it seems they work fine (but I don't yet installed them on my customer).
Th HP purchaser tell me always use only Dec certified HD but he doesn't why.

Bye
Antoniov

[ITRC Test-CH]

Hi Chris,
OpenVMS V5.xx supports physical disk drives with a capacity of up to 8.6GB (also described in the SPD for OpenVMS 5.xx). With your 9GB drive or bigger ones you'll get immediately problems.

Regards,
Werner

[Willem Grooters]

Antonio,
One (real and valid) reason is that some disks have a firmware update to be handled properly by VMS. Others don't need that (the burnt-in spec conforms the actual geometry, or can be handled by VMS without change).
This also depends on the VMS version. The newer, the more fexible (that is: the more disks you can handle without special handling)