We have 2 Alpha 255s running version 7.2 of Open VMS. One of the system drives had the system files accidently deleted. The original O/S media is not immediately available. We would like to simply replace the deleted files with the files from our second system. So we removed the system drive from the bad system and placed it in the data drive slot on our good system with the drive re-jumpered as a secondary drive. However, the system always hangs during boot with the second system drive installed. We would like to know if there is anyway to successfully boot our Alpha with the other Alphas system drive in a secondary slot.

You can have a lot of systemdisks on a single system. I have different VMS-versions on separate disks on a single system. You choose at boottime what disk to use. >>> SHOW DEVICE >>> BOOT 'device' -FLAG 'root',0 If you have a shared systemdisk, every system has its own directory (root). <SYS0>, <SYS1>, <SYS2>,.......... For a single system its SYS0 >>> BOOT 'device' -FLAG 0,0 Where in the boot is the system hanging ?

Prasm, First things first. Determine the actual SCSI ID of the new boot device (and at the same time the ID of the drive with the damaged system components). To do this, enter the command SHOW DEVICES at the >>> console prompt (if I have mistyped the command, use the HELP command from the console to clarify the syntax). There is no such thing as "primary" and secondary" boot devices on most Alphas. There is a way to set the default boot device, and that likely should stay at the value it is presently set to. Once you have identified the SCSI ID of the new drive, do a BOOT 'devicename' -flag 0,0 (or other appropriate system root number as Hakan stated). The above will have problems if you have inadvertently set the two disks to the same SCSI ID (this is actually not improbable, many sites use SCSI ID 0 for system disks). Once you have done this, you may be able to recover the disk without a full image restore, depending on the degree of damage. Alternatively, you may be able to recover the file OTHER than the system files and then do a full image. There are a variety of ways to recover from this situation, depending upon the details of the situation. I hope that the above is helpful. - Bob

<quote> you may be able to recover the disk without a full image restore, depending on the degree of damage. Alternatively, you may be able to recover the file OTHER than the system files and then do a full image. </quote> If your damage is NOT in any [SYSnn...] directory, this can be true. If not, damage is LARGE and the only feasable solution is re-creating the system disk by making an image backup from your second (good) disk. The reason: Most VMS files reside in SYS$SYSDEVICE:[VMS$COMMON...] and each of the files - including the directories - are _entered_ into the node-specific directory [SYSnn] and below. Recreating this structure by hand is a HUGE, errorprone task. Back to your issue: the SCSI ID of that second disk MUST NOT BE the same as the one of that system's systemdisk. You _may_ screw up your good disk as well! Willem Grooters