HP Archive Backup System for OpenVMS Guide to Operations

Architecture
11.1 The Server Process
11.1.1.2 Becoming a DB Server
Note: The DECnet node name is terminated at the "::" if present.
Valid TCP/IP node names: nabsco-12.cxo.dec.com
nabsco-12[.cxo.dec.com]:
nabsco-12[.cxo.dec.com]:2501
nabsco-12[.cxo.dec.com]:2501-2510
Because the database server list is processed from left to right one can control the order by which
server nodes are tried and which network to use. Choosing a network at this point is unrelated to
how the node’s transport is defined in the MDMS database.The requesting node and the contacted
node must have the network for this server entry enabled otherwise the contact fails and
the server continues on with the next entry in the list. The failed attempt is logged in the MDMS
server logfile (“MDMS$LOGFILE_LOCATION:MDMS$LOGFILE_.LOG” or
“MDMS$LOGFILE_LOCATION:MDMS$LOGFILE_DBSERVER.LOG”).
The MDMS server tries to match an entry in the database server list with one of its own network
name definitions. The network name definitions are obtained by retrieving the following values
or translating logicals:
• SCSNODE sysgen parameter
• SYS$NODE for DECnet, stripping off the trailing “::”
• SYS$NODE_FULLNAME for DECnet-Plus, stripping off the trailing “::”
• {UCX|TCPIP}$INET_HOST and {UCX|TCPIP}$INET_DOMAIN for TCP/IP, concatenating
the two strings using a dot “.” in between
• MDMS$SERVER, if none of the above are available
If the server finds a match it tries to open the database files. If it successfully opens all the database
files it declares itself the database server. Because the files are opened for exclusive write
and shared read, no other MDMS server can open the database files after that.
A server remains to be a database server until it exits. At this point the database files are closed
and the domain is without a database server until the next server has successfully opened the
database files.
If the server finds the files already open it continues on with the search for a DB server.
11.1.1.3 Finding another DB Server
When contacting another server, the server passes all its network names on to the other node. If
the other node happens to be a DB server it verifies that the requesting node is defined in the
MDMS database. Only when all the node’s network names are defined in the node’s object the
DB server grants access to the requesting node. Otherwise the DB server returns a
MDMS_NODENOTENA (“node not in database or not fully enabled”).
Once the node is granted access to the DB server the node updates its setting from the database.
At this point the TRANSPORT setting of the node is in use. For example it is possible that a
server contacted the DB server via DECnet but when it updates its TRANSPORT setting it is
only allowed to use TCPIP. So from that point on this server only uses TCPIP to “talk” to the DB
server.
Typically all nodes in a domain have the same definition of MDMS$DATABASE_SERVER in
their MDMS$SYSTARTUP.COM. But the definitions do not have to match. For example each
node could list itself first in the list to give a more round-robin behavior.
11-2 Architecture