From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM"  4-APR-1994 08:20:12.90
To:	EVERHART
CC:	
Subj:	Re: Remote boot of VAXstation 4000 VLC???

X-Newsgroups: comp.os.vms
From: meadowsj@atc.boeing.com (Joe Meadows)
Subject: Re: Remote boot of VAXstation 4000 VLC???
Message-Id: <CnK5Cn.L5D@bcsaic.boeing.com>
Organization: Boeing Computer Services
Date: Fri, 1 Apr 1994 01:55:34 GMT
Lines: 67
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET

>While not an answer to your question, I do recall this problem some years
>ago on an earlier VAXstation (a 3100, I believe).  A regular shutdown
>actually caused the cpu to go into a tigh infinite loop, waiting for the
>user to press Halt.  Of course, since it was still "executing", TRIGGER
>didn't work!  Now, if you could find a way for OPCRASH - or some other
>system component that is run during a shutdown - to actually do a HALT, it
>might work.  One drawback I recall is that screensaver then wouldn't work,
>and you'd burn in (out?) your screen after doing this a while.  Talk to
>DEC support or someone with more info than me for how to make it work.
>Good luck.  Post a solution for us, too; I'm curious if they now have a
>workaround for this.

I missed the original article, but can add to the above commentary.

There are two fairly simple methods for causing a workstation to
"halt" on shutdown. One is to patch SYS$LOADABLE_IMAGES:EXCEPTION.EXE.
For instance, for VMS V5.4-1 - V5.5-2:

	$  PATCH SYS$COMMON:[SYS$LDR]EXCEPTION.EXE
	PATCH> REPLACE/INSTRUCTION 4022 = 'BRB 4022'
	NEW> 'HALT'
	NEW> EXIT
	PATCH> UPDATE
	PATCH> EXIT

This method is of course 'unsupported' (I haven't verified this, but
for VMS 6.0, the address appears to be at 42C2, i.e. change the
replace command to REPLACE/INSTRUCTION 42C2 = 'BRB 42C2'). We used it
on a large VAXcluster and it worked very well, your mileage (and
support) may vary. Don't forget to save a copy of the original; in
case of a foobar, for returning to normal before an O.S. patch or
upgrade, or in case DEC makes you return to a "supported"
configuration before helping you out with any problems you may
encounter (most likely completely unrelated problems, but...). For the
macro impaired, this replaces the section of code where the CPU is
just executing a very tight loop (a branch 'BRB' to itself), with a
Halt instruction.

Alternatively (and supported by DEC), you can muck with NCP. Rather than
describe it, I'll show an example first, then describe it...

	a) $ MCR NCP SET NODE 'workstation' load file mom$load:read_addr.sy
	b) log in to workstation and tell it to reboot (instead of shutdown)
	c) wait for it to shutdown, as it reboots, it will load
	   the above mentioned program (instead of VMS), which is a program
	   that simply displays the nodes ethernet address and then _halts_.
	   Effectively, we've shutdown the system (all the way to >>>)
	d) when you are ready to allow the workstation to reboot, do:
	   $ MCR NCP CLEAR NODE 'workstation' LOAD FILE

Hmm, I think the example was worth a thousand words, so maybe I won't
describe it any more fully.  This convoluted procedure works -
assuming you have set the load file on the volatile database of every
node that might possibly perform the load for the workstation - i.e.
those with their service circuit enabled and the node characteristics
defined such that they could boot the thing. Oh, and assuming you're booting
over the network, rather than off a local disk.

It has the major drawback of only working when you ask it to. If a machine
crashes (rather than being told to do a reboot) for instance, it will hang
with the "Press halt to ..whatever.." message. Some people prefer this though,
or at least they prefer the idea that DEC supports it.

This ought to go in the FAQ, not because it gets asked so often, but because
so many people don't know to ask, assuming it can't be done.

Cheers,