topic Re: Conversational Boot in Operating System - OpenVMS

Conversational Boot

Lisa Collins — Thu, 16 Nov 2006 13:37:56 GMT

Recently I had the need to do a conversational boot on an Alpha DS20 running VMS 7.3-1. I used the following instructions that had been given to me:

ctrl P to stop failed boot

>>>SET BOOT_OSFLAGS 0,1
>>>boot

sysboot> set startup_p1 "min"
sysboot> continue

Now I was into the server.I modified my systartup_vms.com and shutdown. To boot back to normal I typed

sysboot> set startup_p1 ""
sysboot> continue

Is there more to it than this? One thing I noticed a few days after going through this procedure is that I was running on only 1 processor instead of two. Would a processor failing to run be caused by the steps I took above (or possibly missing steps?) Any help would be greatly appreciated.

Thank you,
Lisa Collins

Re: Conversational Boot

Bill Hall — Thu, 16 Nov 2006 14:07:59 GMT

Lisa,

The CPU might have failed or the CPU could have been "disabled" at the console. SYSGEN parameters can also be set to disable starting specific CPUs. Something like SMPCPUS or MULTICPROSSING could "turn off" secondary CPUs.

What does the output from a $show cpu/full show you?

Bill

Re: Conversational Boot

Jim_McKinney — Thu, 16 Nov 2006 14:08:10 GMT

Most likely you've got a hardware problem - failed CPU. If you can stand the pain should the system crash, you might "$ START/CPU/ALL" and see if it'll run. Most likely it won't, and most likely it wouldn't result in a crash, but no guarantees.

You should also inspect the system error log for any "CPU" events.

Re: Conversational Boot

Peter Zeiszler — Thu, 16 Nov 2006 17:25:57 GMT

Doing conversational boot should not disable a cpu.

The above mentioned things could be the issue. One other thing to check - LIC LIST /full. Look to make sure one of your additional CPU usage licenses (would be part of OPENVMS-ALPHA) didn't get disabled somehow. I think most CPUs run with 100 units - but honestly don't know if thats just my systems or all.

Does the DS20 run webes or decevent? If those were running it should show up there. I don't know exact commands to extract the details. I usually use the web interface with webes to pull my reports now but I do know there is a command line method.

Re: Conversational Boot

Robert Gezelter — Thu, 16 Nov 2006 19:06:23 GMT

Lisa,

Disabling a processor, unlikely.

A failed processor: possible.

If you can go through a power cycle without too much inconvenience, shut the machine down and see if the self tests show a failed processor.

I would also check the running parameters to make sure that you are somehow not running MIN or some other restricted situation. Use SYSGEN or SYSMAN to check the active, running parameters.

- Bob Gezelter, http://www.rlgsc.com

Re: Conversational Boot

Wim Van den Wyngaert — Fri, 17 Nov 2006 03:07:12 GMT

Don't have a system to test it but found that you can do set cpu x/autostart.
So, you can also do a /noautostart.

May be your startup is doing something specific with that (for your DS20).

Show cpu shows the setting.

And on 7.3 it's not even in the help text.

Wim

Re: Conversational Boot

Lisa Collins — Mon, 04 Dec 2006 12:00:21 GMT

I apologize for the lateness of my reply (I had a long Thanksgiving break) My second CPU is once again working. I wanted to post what ended up happening.

I rebooted the system and the system did not reboot properly. It went into sysboot. Long story short I got back to the >>> prompt and typed SET BOOT_OSFLAGS 0,0 (since it was still set to SET BOOT_OSFLAGS 0,1) and on reboot, both CPU's were working.

Re: Conversational Boot

Jim_McKinney — Mon, 04 Dec 2006 13:14:28 GMT

You should still inspect the system error log for the past month or so for CPU or machine check errors. IMO a sick CPU is worse than a dead one in a production environment - dead ones don't bite.