"writeboot" question for Alpha

[Robert Young_13]

in reading about writeboot, you can rewrite the system boot block if it becomes corrupted.

BUT THEN HOW do you get the system up in the first place, in order to execute the command? There is no option to designate a "target' disk for the action, so it appears that using a second system disk is not one of the options. 

It seems that you are in an endless loop of some sort, going nowhere past.

So i must be mising something basic/ Any help or explanation will be appreciated.

[Maurizio De Tommaso_]

And if you boot the "OpenVMS Alpha Operating System" kit from CDrom  (preferable same OS version) ?

Select "Execute DCL commands and procedures" from OpenVMS installation menu and, when you get the "$$$" prompt, you should be able to run "writeboot" utility.

[Hoff]

I might guess that you're familiar with BIOS and Windows, and unfamiliar with a console environment that isn't clad in clownshoes.  

To manage a corrupt bootblock on VMS — which is rare, particularly now that folks aren't running Windows NT on Alpha and writing "harmless signatures" all over the place — you can select and boot another disk such as the CD or DVD distribution media, exit the distribution disk menu to DCL, MOUNT the target disk and then ANALYZE /REPAIR the disk or whatever, and then SET BOOTBLOCK from there if needed.    Or WRITEBOOT, if you're using the older tools.

With SRM, you BOOT whatever disk contains your alternate bootable disk or your distribution CD, or whatever.  

Console boot command examples and troubleshooting.

More than you ever wanted to know about the boot block and related structures is latent in this document.

[Robert Young_13]

Part of the problem is digging into 20 yr old manuals. It was not clear exaclty how you went about writing to the specific "system" disk you want to repair...the manuals simply state that it writes to "the system disk"...but it was not clear and sounded almost as if you would then be writing to the disk you just booted from...which made no sense since you are having problems that prevent a boot to begin with. I suspected you had to come up on a second bootable disk of some kind, but it was not clear how you then told it WHICH disk to try to  repair....

[Hoff]

Ok, I don't know which 20-year-old manuals are being read here, nor why you're pondering something that very seldom happens — corrupted boot blocks — nor where you're going with any of this.

The basics of the boot blocks are intentionally the same across the versions and the environments, though there are some implementation details here.

OpenVMS generally manages its boot blocks just fine including during a BACKUP /IMAGE restoration, and — barring errant writes to logical block zero (LBN 0), or somebody that's manually restoring a BACKUP non-/IMAGE backup — there's usually little need to even ponder this particular aspect of the operating system environment.

OpenVMS doesn't generally involve custom-tailored or custom-installed environments; where an installation of OpenVMS VAX won't boot another VAX system.  In general, a VAX system disk will usually boot any other VAX, an Alpha system disk will boot any Alpha, and an Itanium disk will boot any Itanium.   Yes, there are some wrinkles, given the variety of hardware involved.  You might have to use the default parameter settings, and you'll want to use a recent operating system version (as support for systems was added over time) and you'll need the appropriate boot media (ancient VAX systems don't have CD-ROM, for instance), and newer VMS distros might not fit onto the older storage devices due to capacity limits, but otherwise the VMS distribution should boot the target system.

As for which disk, the default is the current disk, and both of the common tools (WRITEBOOT.EXE and SET BOOTBLOCK /

SYS$SETBOOT.EXE on more recent releases) permit the user to specify the target disk.  (n.b.  I happen to know the author of the SET BOOTBLOCK / SYS$SETBOOT.EXE code quite well, should you have any questions.)