🚀 go-pugleaf

Reader Note:  The following file is 200+ lines long, including a refresher on
"the question", attributions, and "the answers."  Read at your own risk!

My apologies for taking so long to post this reply... a client asked me to do a
4-month task in 6 weeks.  How could I resist taking their money!? (though the
project involved total commitment for the past 4 weeks)

*** The Question Was... ***

I had previously asked a question of the net regarding bypassing a disk in the
normal boot sequence.  For example, a valid system exists on DUA0, DUA1, and
DUA2... suppose for an indefinite time I wanted to boot off of DUA2, but be
able to return to booting off of DUA0 (or DUA1, the same principles apply) at a
later date.

As a little "boot tutorial," the MicroVAX (and I assume most other VAXen)
performs the following sequence after power-up diagnostics (paraphrased from
MicroVAX II Technical Manual):
   (1)  Locates 64K of good RAM
   (2)  Copies the primary bootstrap program called VMB from ROM to RAM
   (3)  Branches to the VMB program
   (4)  VMB searches for an operating system in the following order:
        (a) Removable volumes, in order of:
             (1)  DUcu (disk) devices, in controller and volume order (DUA0, 
                  DUA1, DUB0, DUB1, for example)
             (2)  MUcu (tape) devices, in a similar manner
             (3)  PRcu (PROMs) devices
             (4)  XQcu (Ethernet) devices
        (b) Non-removable (fixed) devices, in the same order as above.

How does the VMB determine if there is an operating system on a device?  I have
not found the "definitive answer", but believe it to be the presence of a file
named either [SYSEXE]SYSBOOT.EXE or [SYS0.SYSEXE]SYSBOOT.EXE (I'm not sure of
the order).  Several answers below depend on this tidbit of knowledge!

*** Attributions ***

Before revealing the answers, I give many thanks to the following folks who
provided suggestions.  I have purposely NOT put names with their respective
replies to minimize flames.  Please remember: try these at your own risk,
preferably on fully-backed-up systems. If you have disastrous results, you're
welcome to report them here, but PLEASE do not flame the contributors!

Some of these folks have responded with suggestions to the draft copy of this
message, and to them I offer special kudos.  My apologies if some of the
changes were not implemented... typos and (inadvertant!) misinformation may
still exist herein, for which only I may be chastised.

davidc@montagar.lonestar.org  David L. Cathey
dmatthews@uap.umd.edu         Dr. David Matthews
FORREST@RIGEL.TAMU.EDU        Bob Forrest
jaapjl@tab00.larc.nasa.gov    J Lee Jaap
KIRSCHT@SYSJJ.MDCBBS.COM      KORBEN KIRSCHT
leichter@lrw.com              JERRY LEICHTER (via repost/forward of message)
M.A.Scott@bnr.co.uk           Mike Scott
mark@infocomm.com             Mark Pizzolato 
MJR059@IPL.JPL.NASA.GOV       Malcolm J. Rayfield
RBRYSON@LANDO.HNS.COM         Rob Bryson

*** The Answers Were... ***

Answers and methods varied in complexity and applicability, and fell into 4
general answer categories.   I'll go over each of these in more detail below. 
Unfortunately, I have not had the opportunity to try each of these, but will
report any successes (and failures!) as time allows.  

  (1) Put the unwanted boot disks off line
  (2) Prevent the system from automatically selecting a boot device
  (3) Put a special program on the first-selected boot device to
      select the actual boot device
  (4) "Hide" the boot program from each disk that you do not want 
      to boot from.

A 5th choice was suggested, and is provided at the VERY bottom of this message. 
Basically, it amounts to storing the boot device in the hardware's NVRAM, but
this method is not supported on the MicroVAX.

And now, specifics of each method and my evaluation of each.  Please note that
these are my PERSONAL evaluations, and your own circumstances may vary.

*** (1)  Put unwanted disks off line ***

On a MicroVAX, press the button on each disk that you do NOT want booted from
to disable the drive.  After booting begins (you should see the familiar
"VAX/VMS 5.n" message), you can re-enable each disk so that they can be
properly mounted by the selected STARTUP routine.

This is okay for a one-time deal, but if you want the system to consistently
reboot frmo some other disk (like when the power goes down in the middle of the
night!), it's not reliable (since I assume you would want to put the other
disks back on line after booting has begun, and a power-reset boot would select
the first disk in the selection sequence).

*** (2) Manually select the boot device ***

This involves (for the MicroVAX II) flipping the "console enable switch" in the
back of the machine, which causes the system prompt ">>>" to appear on the
console prior fully booting.  Then, of course, the operator would enter a boot
command such as:   >>> B DUA2   

This has the same drawbacks as category 1, but does at least prevent the system
from fully booting with the "wrong" disk if the power resets.  Unfortunately,
if you're not there to enter the BOOT command, then the system dutifully waits
for you to arrive and do so!

*** (3) Force the selection of boot device from the first available device ***

This method was suggested from several sources, and most likely will work from
ANY VAX machine.  It involves writing a program (two examples with instructions
UNTESTED BY ME are included at the end of this message) to be called
[SYS0.SYSEXE]SYSBOOT.EXE.  The purpose of this program is to overlay an area of
the primary boot program (remember? It's called VMB) with the name of the
desired boot device, and then jumps back to the VMB to continue looking for
boot devices.  

If you have SEVERAL devices in the boot selection sequence, this allows you to
avoid "hiding" the boot directory on all "intermediate" devices by putting the
"direct selection" on the first device, pointing directly to the desired
device.

If you already have a system built on DUA0, for example, you may have to follow
the advice of answer category 4 first (moving the bootable directory SYS0 to
another directory) before doing this.

*** (4) "Hide" the bootable system ***

This involves two steps.  In my original posting I had performed one step, but
not the other, which caused the system to hang.

   Step 1.  Rename SYS0 to something else, like SYS1:
              $ RENAME DUA0:[000000]SYS0.DIR SYS1.DIR
   Step 2.  Remove the link which points [SYSEXE]SYSBOOT.EXE and
            [SYS0.SYSEXE]SYSBOOT.EXE to the same physical file:
              $ SET FILE /REMOVE DUA0:[SYSEXE]SYSBOOT.EXE; /LOG

Having accomplished this, VMB will bypass this disk when selecting an
"operating system from which to boot."  The same operation can be performed on
any of the disks in the boot selection sequence to cause them to be bypassed.

If you decide, at a later date, that you'd like to boot once more from DUA0,
there are two possibilities:

  (1) You only want to boot from DUA0 once (for an alternate system test, for
      example).  Assume you renamed SYS0 to SYS1 above. Put the system into 
      console mode, and (for MicroVAXen) eneter the following:
             >>> BOOT /10000000 DUA0 
      This should look vaguely familiar, IF you do full system backups!  For
      booting standalone backup, you normally BOOT /E0000000, which selects
      [SYSE] as the boot directory.  The first digit of the register parameter
      apparently is appended to "SYS" to arrive at the boot directory for
      disk devices.
  (2) You want to restore DUA0 as the default boot device "forever" (until you
      change your mind!).  I assume (having not tested this theory) that you
      must undo both steps from above, i.e.,
      (a) Rename [000000]SYS1.EXE to [000000]SYS0.EXE
      (b) Restore the link from [SYSEXE]SYSBOOT.EXE to [SYS0.SYSEXE]SYSBOOT.EXE
          with a command like:
            $ SET FILE [SYS0.SYSEXE] /ENTER=[SYSEXE]SYSBOOT.EXE

*** Code for Category 3 Answer ***

Following is the text, exactly as it was sent to me, of one of two methods of
accomplishing the "directed boot" option.  The second method offered
essentially the same result using a slightly different methodology.
============== direct quote =============
Leave your DUA1 system in [SYS1...], create DUA1:[SYS0] and DUA1:[SYS0.SYSEXE]
and put a special SYSBOOT.EXE in DUA1:[SYS0.SYSEXE].  The source is at the end
of this message.  When the system tries to boot from DUA1: (DUA0: disabled) the
special SYSBOOT.EXE will change the registers to the values that B DUA2 would
have generated. It then restarts the boot program now in RAM.

This program can also be used to force a boot from the Ethernet by changing
the 'DUA2' to 'XQA0'.  Usually the program would go on DUA0:, but you have that
disabled.

SYSBOOT.MAR follows

	.TITLE		SYSBOOT
; This program makes a MicroVax II boot from the a different device on powerup.
; LINK with /SYSTEM=0 then COPY/CONTIGUOUS to DUA1:[SYS0.SYSEXE]
;
	.PSECT		CODE,CON,EXE,PIC,NOWRT
	MOVL		#^A'DUA2',R0		; New boot device
	MOVQ		^X20(R11),R1		; Restore VMB R1 and R2
	MOVQ		^X28(R11),R3		; Restore VMB R3 and R4
	MOVL		^X30(R11),R5		; Restore VMB R5
	MOVL		^X10(R11),R10		; Restore VMB R10
	MOVL		^X18(R11),AP		; Restore VMB AP
	MOVAL		^X200(R11),SP		; VMB start address
	MOVL		^X14(R11),R11		; Restore VMB R11
	JMP		(SP)			; Restart VMB
	.END
============== direct quote =============
*** (5) Alternatives Not Considered Here ***

Looking for primarily an EXTERNAL method of changing the selected boot device,
I did not consider the suggestion to re-cable the desired drive to the first
slot (DUA0).  Another suggestion to swap the unit address plugs on the drives
was rejected, since these do not exist on the MicroVAX (though that suggestion
DOES come in handy for use on the SA82s at the college).

Here is the text of another answer.  I did not consider this method, because
the MicroVAX II only supports single digit TEST commands (according to the
manual, anyway) and does not support the storage of boot device selections in
NVRAM.  This method apparently WILL work for other VAXen models.  Consult your
hardware guide for details.
===========
	I think you want to try "TEST 51" at the console (>>>) prompt.  This
is used to change the default boot device.  If this is not set, then the auto
boot sequence is done to locate a boot device.

	It should go something like this (at least on a MV2000, and the MVII
is very similar):

	>>> TEST 51
	.... ? >>> [DUA2]
	>>>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
David L. Cathey		                |INET: davidc@montagar.lonestar.org
Montagar Software Concepts              |UUCP: ...!texsun!montagar!davidc
P. O. Box 260772, Plano TX  75026-0772  |Fone: (214)-618-2117
====================
Please report the results of your efforts to use these techniques to the net...
"We are all in this together..."
-----
Ray Harwood           |Data Basix           |Adjunct Faculty, East Campus,
Voice: (602)721-1988  |PO Box 18324         |   Pima Community College
FAX:   (602)721-7240  |Tucson, AZ 85731     |Instructor in Ada and Pascal
CompuServe: 76645,1370|AppleLink: DATA.BASIX|Internet: rharwood@east.pima.edu