VMX 6.2 MSCP Loading

[Michael Dingas]

We are migrating our clustered VAX 4000's to a Charon emulator and have xferred sys0 disk to the emulator. The boot process hangs at loading MSCP which we are trying to debug. Question: What is the normal boot sequence and where in this sequence would MSCP attempt to load?

We are trying to eliminate loading MSCP (and any other unnecessary processes) to see how far into the boot process we can get.

[Dean McGorrill · Accepted solution]

hi Michael,
if you don't need to server your disks,
use sysgen and set MSCP_LOAD = 0. you might
want to set vaxc = 0, and bring it up as
a non clustered node. I know nothing about
the emulator, if you can boot it like a
alpha (>>> boot -flag 0,1) you can bring it
into sysboot and set these values. hope
this helps, and curious to the performance.

Dean

[Michael Dingas]

I guess I should warn those who might respond. We have no trained SysAdmin (I know..Say What?). My co-worker and I have inherited an aging VAX system being replaced with the Charon emulator. We have the replacement hardware running and emulator installed. Now we have to figure out how to migrate the old system disks to a new 8x37 Gbyte disk array. So...if I seem perplexed by some replies you'll have to forgive my ignorance.

[Dean McGorrill]

Michael,
You came to the right place, you'll have
lots of replies, reward the guys with points.
I would personally like to learn what Charon
is about. That said, there should be a guide
to use of the emulator, and I'd head to any
section about booting and references to sysboot. on a alpha these tell it to
boot allowing system parameter changes before
a boot..

>>>boot -flag 0,1
.
.
sysboot> set vaxc 0
sysboot> continue

setting vaxc vaxcluster to 0 disables the
cluster software.
try and first get your fledgling emulated system
up w/o the cluster stuff like mscp (mscp which stands for mass storage control protocal (?) it serves local disks to other cluster members)


Dean

[Karl Rohwedder]

How do you know, it hangs on MSCP? Perhaps this was just the last message you see?

If the former systems were clustered and you start just one emulated VAX, perhaps it waits for quorum. Can you post the bootstrap message?

regards Kalle

[Richard Brodie_1]

With boot problems, it's the first message that *doesn't* appear that is usually more interesting. Of course, you need a baseline to compare it with.

If the last thing you see are MSCP messages, you probably have a cluster formation problem of some sort. If you aren't planning on booting the emulated system into the cluster, just setting VAXCLUSTER to 0, as suggested, should fix it.

[Michael Dingas]

First, thanks for the replies. It is much appreciated and I'll assign some points as soon as I have a chance to try the suggestions.

The following is the output at the 'opcom':

%SYS-BOOT-I-SYSBOOT Mapping the SYSDUMP.DMP on the System Disk

%SYS-BOOT-I-SYSBOOT SYSDUMP.DMP on System Disk Successfully mapped

OpenVMS (TM) VAX Version 6.2 | Major version id = 1 Minor version id = 0



%CNXMAN, using remote access method for quorum disk

%SYSINIT, waiting to form or join a VAXcluster system

%VAXcluster-I-LOADSECDB, loading the cluster security database

%MSCPLOAD-I-LOADMSCP, loading the MSCP disk server


At this point it never gets any farther in the boot process.

We have been able to migrate a non-clustered VMS that we used for our initial evaluation of Charon. So we are confident that the emulator is installed correctly. Due to the migration problems we are currently experiencing, our focus is to get our working VAX migrated as a single node with no shared disks and no clustering. Once up and running, we would then modify the migrated system to load disks (some 23 individual drives) and re-establish the cluster. We will have a 2-node cluster node (down from the original 5-nodes) so will retain the quorum disk.

What makes this process tedious is that we are unable to make any system changes on the migrated system since it won't boot. All changes must occur on the real VAX with then necessitates making/transferring another image. Due to hardware limitations, we are transferring the image over a network which takes 4-5 hours. Very slow.

Regarding Charon: It is a certified VAX replacement system, in our case, running on two HP Proliant DL380 servers with an 8x36GByte disk array. Each server will boot to a single system disk located on the array. After we get one server configured/booted, we'll start on the second.

[Art Wiens]

The CHARON-VAX product IS a VAX for all intents and purposes. Pretty well anything you did at a VAX console prompt >>> works on CHARON-VAX.

A few assumptions, that you already have a default boot device setup eg DUA0, if not:

>>> set boot dua0 ! or whatever your system disk device name is

>>> b /r5:00000001 !brings it up "conversationally"

SYSBOOT> set vaxcluster 0
SYSBOOT> continue

You may also want to ensure for the first boot that you don't don't bring the system up fully ... problems could ensue with duplicate IP's or system names or queues that have jobs waiting in them will start etc. so just before you SYSBOOT> continue then:

SYSBOOT> set startup_p1 "MIN"

This should allow enough of VMS to start and you can start making your edits of config files.

Good Luck,
Art

[Michael Dingas]

Well, we have lift-off! Out non-Alpha system wouldn't accept the SET commands previously suggested. There is, however, a USE DEFAULT command that reset clustering parameters and MSCP LOAD to 0. CONTINUEing started the boot process which eventually prompted us to AUTOGEN.

We replied yes which adjusted various parameters (I guess) and the system rebooted. Rebooted to the same problem.

SO...we went back to conversational boot and tried again. This time we opted to not AUTOGEN. The system eventually booted up to the login prompt. SUCCESS!!!!!!!!!!

We were able to login as both SYSTEM and as a user. Now we have to modify the emulators config file and some VMS settings to recognize the 'drives' in the array (which are still being transferred) and then attempt to reform the cluster. Each emulator server has its own config file that will point to a single system disk.

We may need more advice at that point. You guys are great! We finally made some progress and owe it all to ya'll. Have a great day!!!

[Michael Dingas]

The initial MSCP Loading problem was solved by using default parameters from conversational boot.

[Art Wiens]

You can "thanks" by assigning points to the responses you received.

WRT not accepting the set commands, one oddity I've noticed using KEA as the console terminal and being at the SYSBOOT prompt, every command needs to be preceeded by a backspace key (and I'm sure it's a KEA config issue) eg.

>>>b/r5:00000001
(BOOT/R5:1 DUA0)

2..
-DUA0
1..0..


SYSBOOT> <- hit backspace
\
\SET STARTUP_P1 "MIN" <- hit return

SYSBOOT> <- hit backspace
\
\CONTINUE <- hit return


%SYSBOOT-I-SYSBOOT Mapping the SYSDUMP.DMP on the System Disk

Anyways, glad to hear your "up".

Cheers,
Art

[Jur van der Burg]

This has nothing to do with the mscp server. It's always the last message before joining a cluster, so it's a red herring. Your problem is just caused by an improper cluster configuration (network, votes, expected_votes etc.)

Jur (working for the company that brings you Charon).