Conversational Boot

[Lisa Collins]

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

[Bill Hall · Accepted solution]

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

[Jim_McKinney]

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.

[Peter Zeiszler]

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.

[Robert Gezelter]

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

[Wim Van den Wyngaert]

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

[Lisa Collins]

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.

[Jim_McKinney]

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.