Xref: utzoo comp.os.vms:8408 comp.sys.dec:772
Path: utzoo!utgpu!attcan!uunet!ingr!b11!jim
From: jim@b11.UUCP (Jim Levie )
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: LATCP Servers (MOM$LOAD)
Summary: The problem is probably ...
Keywords: DS200, MV_2, LATCP
Message-ID: <253@b11.UUCP>
Date: 2 Sep 88 17:02:15 GMT
References: <8808311604.AA01461@ucbvax.Berkeley.EDU> <544@suned1.UUCP>
Distribution: na
Organization: Far from the halls of Amber
Lines: 28

In article <544@suned1.UUCP>, efb@suned1.UUCP (Everett F. Batey II) writes:
> 
> I have 2 MicroVax 2s (MV2A and MV2B).  Originally MV2A was alone and first
> fed my DS200s their boot loads.  Later I added MV2B.  I thought I had made
> MV2B the boot host, until today when MV2A was off line from the ethernet. 
> I could not reboot a DS200 server till MV2A returned.  All noticeable
> conditions and parameters from SYSGEN (conn LTA0/NOADAPT), NCP, LATCP,
> the DSVCONFIG.DAT databases in MOM$LOAD and the binaries are alike.

Hmm... seems like I've been here before.  I'll guess that when you acquired
the second microvax you copied your system from the MV2A rather than install
everything from scratch.  If this is the case, then the problem lies in the
way the down-line loader task accesses the load image and other information.
It appears that all of the data items that the loader needs are kept as
absolute data in the data bases, even moving the system from one type disk to
another on the same system will prevent loading since the disk name has
changed.

The solution is really fairly simple. Go back to the distribution for the
decserver support and reinstall it.  I usually delete the existing version
first, but that's probably not necessary.


-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 Jim Levie   REMTECH Inc  Huntsville, Al 
 The opinions expressed above are just that.
 Ph.    (205) 536-8581               email: uunet!ingr!b11!jim