Conference 7.286::digital

A quick look in the OpenVMS Cluster Software SPD (29.78.12) shows the 
following caveats when booting an 8200/8400 into a cluster:

Note 2 - Rack-mount AlphaServer 8200 configurations with CIXCD, KFMSB, and
DEMFA capability are available from Digital CSS.

Note 4 - Each "Yes+Sat" means that this CPU is supported on this interconnect
and can be booted as a satellite node over this interconnect.

Note 5 - Using DEMFA only

Note 3 aplies to the AlphaServer 8200s in general, notes 4 and 5 apply when an
8200 is to be booted across an FDDI.

Bottom line. If you're trying to boot an 8200 (or an 8400 for that matter), 
the only supported FDDI adapter is the DEMFA - NOT the DEFPA.

Hope this helps.
tim moffitt

     You may also want to post this in the HS1XX notes file.
    		SSDEVO::HS1XX_PRODUCT
    

    Thanks for the quick replies (can you tell that quickness is good?)! As
    Tim guessed, we have DEFPAs. It seems that our most viable solultion is
    to replace them with DEMFAs. (We do have KFTIAs and KFTHAs.)
    
    I have some phone calls to make (someone else contacted me off line -
    thanks), and if I'm still not sure I'll drop into the conference
    mentioned in .-1.
    
    Thank you very much. I'm fairly optimistic now.
    
    	BD�

    
    
    DEMFAs are XMI devices...the XMI isn't supported on the 8200...unless
    you goto CSS for a custom. Even though the SPD doesn't say that the
    tulip (DE435/10basaeT on the ITIOP) is a supported device...you can boot 
    over it... Once the system is boot you can switch over to FDDI. My
    understanding of this problem is that it's an open IPMT case (is that
    correct), it is/was being worked...the 8200/8400 console had some problems
    with booting the DEFPA/DEFPZ...and VMS doesn't have a DEFPA/DEFPZ boot
    driver.
    
    	Hope that this helps..
    
    	-Mark-
    

Too bad you're not using 2100's. I've had the same problem with a similar
cluster built around 2100's and an HS241. The storage folks would like to treat
this thing as a black box, but the embedded Alpha 1000's participate as full
OpenVMS cluster members and this complicates the configuration.

THe problem you're having is that the OpenVMS secondary bootstrap doesn't
support the DEFPA (though OpenVMS itself does) , so your MOP boot fails. 

The official answer I got on booting via the DEFPA follows:

___________________________________________________________________________

FDDI boot support:

AlphaServer 2100
   OpenVMS V6.2         DEFEA only 
   OpenVMS V6.2-1H2     DEFEA or DEFPA only
   OpenVMS V7.0         DEFEA only

Neither the AlphaServer 1000 (Mikasa) or AlphaServer 1000a (Noritake)
will boot over FDDI for any current VMS version.  Note that
the AlphaServer 1000 will support booting other systems
over FDDI.

The current list of systems which will boot over FDDI 
(from the V6.2-1H2 Cluster SPD) is:

   AlphaServer 8200, 8400           (DEMFA only)
   DEC 7000, 10000                  (DEMFA only)
   DEC 3000                         (DEFTA only)
   AlphaServer 2100, 2100a          (see above)
 
______________________________________________________________________________

There is another solution. Put EISA Ethernet cards in the Alpha 1000's in the
HS241 (Shhh - they'll tell you it's unsupported). Hook Ethernet between the
8200's and the new Ethernet cards in the Alpha 1000's. Now you can MOP boot
across Ethernet. OpenVMS will path switch to the FDDI link when it comes up.

Of course the 8200's become satellite Cluster members. The 1000's MSCP serve
the disks to the cluster. 

You might also want to drop a note to the HS241 product manager (I don't have
his name handy).

Good Luck
    

    Have you tried the VMScluster & 8200 notesfiles ?
    
    Have you contacted the StorageWorks Technical support group ?
               FDDI servers are their product.
    
    Also, you might like to speak to the VMS product manager for direction,
    (Nick Carr).
    
         Tony.

    
    Oh, & the Business Recovery Service group, this is a speciality area
    for them.
    
    Tony.

    Thanks for the additional pointers, Tony. We're contacting everyone we
    can thing of. We'll get to the bottom of this eventually.
    
    	BD�