Harddisk replacement in Alphastation 255

[Nadeem Abdul Aziz]

I'am using alphastation 255 for process control configuration and history server . recently i required a backup of running 3.2 GB harddisk . Since these sizes are no more avilable , i tried one 18 gb seagate drive . Backup procedure throguh " backup/image dka100: dka200 was smooth and without error messages . But when i tried to boot with copy i made on dka200 , system stopped responding after " loading network base image....." message and harddisk went on slow , infinite read cycle .I have tried this with many different make and model harddisk but with same results.
When i try same with upto 8.9 gb harddisk , the copy poses no problem .
My question is that is it at all possible to use larger sized harddisk on AS 255 or not .
My operating system is openvms 7.1-1H2 .
Note that when i try to boot the bad 18 GB harddisk on an emulator , it boots perfectly ??


Nadeem Aziz

[Pieter 't Hart]

But when i tried to boot with copy i made on dka200

Do you mean you boot from dka200?
sysgen files probably still point to dka100 wich is not mounted at boot time.
you may need to run interactive boot to configure page/swapfile
or place dka200 in dka100 position to boot from.
(what probably happened with the emulator)

[PDP-Fan]

It is possible that 18GB are simply too big for this old machine. I remember having a similar problem on VAXStations 3100. They will not accept drives bigger than 4GB.

The problem is not the software (VMS can handle Terabyte disks) but the BIOS of the SCSI controller. It is more a hardware problem...

The easiest way to prvent such problems is to look for small disk drives. Or to change the Alphastation to a more modern type.

[Bob Blunt]

The disk size isn't' the limitation, I had an 18G disk in one of the AS255s in our lab.  The system parameters on the saved image backup are probably wrong for your system.  When you try to recover from this failure the next time, first at the console type SHOW BOOT*  and look for:

BOOTDEF_DEV

     and

BOOT_OSFLAGS

BOOT_OSFLAGS will probably have something like "0,0" and you should probably change that to "0,1" for the next time you boot this system.  Instead of booting until it hangs you should get a prompt that says "SYSBOOT>"

At that prompt I'd suggest entering:

USE DEFAULT<CR>

C<CR>

OpenVMS *should* boot but this will be the default configuration for the system parameters.  If the boot completes then you should login to the system and when you get the DCL prompt ($) you should SET DEFAULT SYS$UPDATE and $ @AUTOGEN GETDATA GENPARAMS.  The AUTOGEN command procedure will probably ask you some questions and when it completes enter @AUTOGEN SETPARAMS REBOOT.  This should reset the system parameters based on your AS255's configuration and then, hopefully, it should reboot without a problem.  These settings will not, usually, take any special software requirements into consideration at first.  Some system managers enter those requirements into a file called MODPARAMS.DAT but that sort of discussion might better be directed to the OpenVMS System Management discussion board.

bob

[Bob Blunt]

Now that I've already replied, I've got some other questions for clarification.  You said you have a backup of a 3.2G disk you want to restore?  But then you say that your backup command was:

backup/image dka100: dka200:

What disks are installed on the AS255 and is the backup of the 3.2G disk another disk or is it from tape (or CD)?

An 18G disk should still work fine, generally speaking, but not all "generic" SCSI disks work perfectly with an Alpha and/or OpenVMS.  The brand of disk shouldn't be a problem as long as you're using one that the hardware and/or disk controller supports.  There are many types of SCSI disk available but the on-board SCSI adapter on the AS255 is very probably a "narrow, single-ended" device.  Most SCSI disks can adapt to work with older controllers to some extent but that depends on the disk you're using.  It seems like getting the system to boot as far as you have should be a good indication so I'd still try the recommendations I made in my previous posting.  It certainly won't hurt.  I would suggest the following backup command when restoring to a disk you're overwriting, though:

$ mount/for <destination>

$ backup/image/initialize <source> <destination>

This should allow backup to correctly initialize your disk before starting to restore the source data from the backup.

bob