HP OpenVMS Systems

Ask the Wizard
» 

HP OpenVMS Systems

OpenVMS information
» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems
» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links
» Non-javascript page
» Ask the Wizard
» OpenVMS FAQ

Test Drive OpenVMS
» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:
» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners
» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value
» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links
» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Ask the Wizard Questions

Satellite boot problem

The Question is: 

We have a cluster with 3 VAX and 5 Alpha machines with one
node each serving as the boot node for it's corresponding
architecture.  Strangly, after the most recent shutdown,
the Alpha boot node no longer responds to ethernet boot
requests from it's Alpha satellites.  All VAX nodes and the
single Alpha boot node are booted and in the cluster.
I can see the ethernet boot requests on the VAX boot node
with the following message.

%%%%%%%%%%%  OPCOM  21-DEC-1995 11:15:18.99  %%%%%%%%%%%
             (from node UCDHED at 21-DEC-1995 11:15:17.94)
Message from user DECNET on 
DECnet event 0.7, aborted service request
From node 41.422 (), 21-DEC-1995 11:15:17.94
Circuit SVA-0, Line open error, Ethernet address = 08-00-2B-39-B9-16
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The VAX decnet database only contains load parameters for
the VAX nodes so this is what I expect.  The Alpha boot
node is absolutely silent and seems not to recognize the
boot requests at all.

As a test of the ethernet connection, I add the Alpha decnet
load parameters to the VAX boot node database (which is
responding to the boot request with the above error message).
so that LOAD FILE, and LOAD ASSIST point to the correct
system disk on the unresponsive Alpha boot node. Lo and
behold, the Alpha satellites boot using the VAX boot node
to point to the remote Alpha disk, so the ethernet
connection must be working.  I'm baffled and would be very
interested to discover the source of this behavior.

       Thanks,

The Answer is: 

This really sounds like the Alpha boot node has had MOP service turned off
on it's ethernet circuit.  Execute CLUSTER_CONFIG on this boot node and
make the system a boot server.  Also make sure this system still has the
boot information for it's satellites.