HP Archive Backup System for OpenVMS Guide to Operations

11
Architecture
11.1 The Server Process
This chapter describes in more technical details the ABS and MDMS infrastructure and implementation.
Each OpenVMS node participating in an MDMS Domain runs a generic process called
MDMS$SERVER.
Each MDMS server process can implement 3 functions:
• Current access to the database, the database server
• Forwarding a user request to the current database server
• Executing remote requests on behalf of the database server
Domain
All nodes communicating with the same database server belong to the same MDMS Domain.
Each MDMS Domain has its own database. Typically you have only one MDMS Domain in
your network. But the architecture allows to setup more than one domain. However, one has to
make sure that none of the nodes and none of the MDMS objects (i.e jukeboxes) are used in
more than one domain.
11.1.1 The Database (DB) Server
11.1.1.1 Database
MDMS keeps all its permanent settings in files in a location defined by logical MDMS$DATA-
BASE. The summary of these files are called the MDMS Database.
Each MDMS server needs access to the MDMS database before it is fully functional. The server
translates logical name MDMS$DATABASE_SERVERS which contains a list of potential database
server nodes. This logical is defined in MDMS$SYSTARTUP.COM and contains the network
names of other servers. Because the server has not yet accessed the database it cannot use
an MDMS node name.
While scanning through the database servers list the server tries to contact the remote server
using the appropriate network for a given network name:
• DECnet, if only alphanumeric characters, e.g. “STAR”
• DECnet-Plus, if network name contains “:.”, e.g. “VMS:.STAR”
• TCP/IP, if network name contains just dots “.” and a possible colon “:” followed by a number
range, e.g. “star.vms.com” or “star.vms.com:2501-2510”
Following are examples of valid TCPIP and DECnet names.
Valid DECnet node names: DEC:.CXO.FARMS[::]
NABSCO[::]
- Phase IV
- Phase V
Architecture 11–1