Message Router Configuration Guide Version 3.0 digital equipment corporation, maynard, massachusetts AA-KR18A-TE First Printing, October 1987 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used and copied only in accordance with the terms of such license. Digital Equipment Corporation assumes no responsibility for the use or reliability of its software on equipment that is not supplied by DIGITAL or its affiliated companies. Copyright (c) 1987 Digital Equipment Corporation. All rights reserved. Please fill in and send us the prepaid reader's comments at the end of this book. It will help us to keep improving our documentation. The following are trademarks of Digital Equipment Corporation: --------------TM |d|i|g|i|t|a|l| -------------- DNA Rainbow ALL-IN-1 LQP RSTS DEC MAILBUS RSX DECmate MASSBUS ULTRIX DECnet Message Router UNIBUS DECset MicroPDP VAX DECstart MicroVAX VAXmate DECUS MicroVMS VMS DECSYSTEM-10 OSAK VOTS DECSYSTEM-20 PDP WPS-PLUS DIBOL Q-BUS WPS-8 ii CONTENTS Preface CHAPTER 1 Configuring Message Router 1.1 Introduction . . . . . . . . . . . . . . . . . . . 1-1 1.2 Planning Your Configuration . . . . . . . . . . . 1-1 1.3 Upgrading from Version 2.0 or 2.1 of Message Router . . . . . . . . . . . . . . . . . . . . . . 1-1 1.3.1 Using Your Version 2.0 or 2.1 Configuration . . 1-2 1.3.2 Minimizing Interruption to Your Electronic Mail System . . . . . . . . . . . . . . . . . . . . . 1-2 1.3.3 Messages in the Version 2.0 or 2.1 System . . . 1-2 1.3.4 Cluster Names . . . . . . . . . . . . . . . . . 1-2 1.3.5 Exception Reporting for Version 2.1 Nodes . . . 1-3 1.4 Reconfiguring Message Router . . . . . . . . . . 1-4 1.4.1 Reconfiguring Message Router When Your System Changes . . . . . . . . . . . . . . . . . . . . 1-4 1.4.2 Reconfiguring Message Router to Recover from Errors . . . . . . . . . . . . . . . . . . . . . 1-5 CHAPTER 2 Planning a Message Router Network 2.1 Network Planning . . . . . . . . . . . . . . . . 2-1 2.2 World Search Nodes . . . . . . . . . . . . . . . . 2-1 2.3 Network Management Node . . . . . . . . . . . . . 2-2 2.4 Directory Service Master Node . . . . . . . . . . 2-3 2.5 Directory Service Population . . . . . . . . . . . 2-3 2.6 Routing . . . . . . . . . . . . . . . . . . . . . 2-4 2.6.1 Default Routing . . . . . . . . . . . . . . . . 2-5 2.6.2 Destination Routing . . . . . . . . . . . . . . 2-7 2.6.3 Area Routing . . . . . . . . . . . . . . . . 2-11 2.7 Clusters . . . . . . . . . . . . . . . . . . . . 2-15 2.8 Network Time . . . . . . . . . . . . . . . . . 2-16 2.9 Default or Customized Message Router Configuration . . . . . . . . . . . . . . . . . 2-16 2.10 Network Planning Checklist . . . . . . . . . . . 2-17 CHAPTER 3 Planning a Default Configuration 3.1 Time Zone Correction . . . . . . . . . . . . . . . 3-1 3.2 Message Router Devices . . . . . . . . . . . . . . 3-1 3.3 MBMANAGER Account Password . . . . . . . . . . . . 3-2 3.4 Enable Exception Reporting . . . . . . . . . . . . 3-2 iii 3.5 Alarm Levels of Free Blocks for Exception Reporting . . . . . . . . . . . . . . . . . . . . 3-3 3.6 Configuration Checklist . . . . . . . . . . . . . 3-3 CHAPTER 4 Planning a Customized Message Router System 4.1 Configuring the Management Service . . . . . . . 4-1 4.1.1 Device for the Management Service . . . . . . . 4-1 4.1.2 Destination for Exception Reports . . . . . . . 4-2 4.1.3 The Time Zone Correction . . . . . . . . . . . . 4-2 4.1.4 Account Passwords . . . . . . . . . . . . . . . 4-2 4.2 Configuring the Directory Service . . . . . . . . 4-3 4.2.1 Directory Service Device . . . . . . . . . . . . 4-4 4.2.2 Exception Reporting for the Directory Service . 4-5 4.2.3 The Directory Service File Locations . . . . . . 4-5 4.2.4 Directory Service Events . . . . . . . . . . . . 4-6 4.2.5 Deferring Updates . . . . . . . . . . . . . . . 4-6 4.2.6 Informing the Operators of Directory Service Errors . . . . . . . . . . . . . . . . . . . . . 4-7 4.2.7 Controlling the Number of Entries in the Cache Database . . . . . . . . . . . . . . . . . . . . 4-7 4.2.8 Restricting the Number of Network Links . . . . 4-8 4.2.9 Running the Directory Service Maintenance Command Procedure . . . . . . . . . . . . . . . 4-8 4.2.10 Running the Directory Service Deferred Update Command Procedure . . . . . . . . . . . . . . . 4-9 4.2.11 Running the Directory Service Cache Refresh Command Procedure . . . . . . . . . . . . . . 4-10 4.3 Configuring the Transfer Service . . . . . . . 4-10 4.3.1 Device for the Transfer Service . . . . . . . 4-12 4.3.2 Exception Reporting for the Transfer Service 4-13 4.3.3 Size of the Error Information File . . . . . . 4-13 4.3.4 Remote-commands Messages . . . . . . . . . . . 4-13 4.3.5 The Transfer Service Maintenance Command Procedure . . . . . . . . . . . . . . . . . . 4-14 4.3.6 Talkers . . . . . . . . . . . . . . . . . . . 4-15 4.3.7 Message File Areas . . . . . . . . . . . . . . 4-16 4.3.8 The Mailbox Directory Location . . . . . . . . 4-17 4.3.9 The Queue File Location . . . . . . . . . . . 4-17 4.3.10 Database Number . . . . . . . . . . . . . . . 4-18 4.3.11 Transfer Service Images . . . . . . . . . . . 4-18 4.3.12 Batch Queue . . . . . . . . . . . . . . . . . 4-18 4.3.13 The Hopcount . . . . . . . . . . . . . . . . 4-18 4.3.14 Handling Rejected Messages . . . . . . . . . . 4-19 4.3.15 Returning Service Messages . . . . . . . . . . 4-19 4.3.16 Area Code . . . . . . . . . . . . . . . . . . 4-20 4.3.17 Sending Messages to Unrecognized Recipients . 4-20 4.3.18 Message Journaling . . . . . . . . . . . . . . 4-21 iv 4.3.19 Destination of Non-delivery Notification Messages . . . . . . . . . . . . . . . . . . . 4-21 4.3.20 Broadcasting Notification Messages to Users . 4-22 4.3.21 Broadcasting Error Messages to Operators' Consoles . . . . . . . . . . . . . . . . . . . 4-23 4.3.22 Message Transaction File . . . . . . . . . . . 4-23 4.3.23 The Transaction File Size . . . . . . . . . . 4-24 4.3.24 Message Transaction File Buffer . . . . . . . 4-24 4.3.25 Active Queue Monitoring . . . . . . . . . . . 4-25 4.3.26 NETSERVER Process Timeout . . . . . . . . . . 4-26 4.3.27 Mailboxes Accessed by Remote User Agents . . . 4-27 4.3.28 Transfer Service Options on Clusters . . . . . 4-27 4.3.28.1 Cluster Aliasing . . . . . . . . . . . . . . 4-27 4.3.28.2 The Transfer Service Database . . . . . . . 4-28 4.3.28.3 Batch Queues . . . . . . . . . . . . . . . . 4-29 4.4 Configuring Exception Reporting . . . . . . . . 4-29 4.4.1 VMSmail Address for Exception Reports . . . . 4-29 4.4.2 Frequency of Exception Reports . . . . . . . . 4-30 4.4.3 Monitoring Exception Reporting . . . . . . . . 4-30 4.5 Configuration Checklist for the Management Service . . . . . . . . . . . . . . . . . . . . 4-30 4.6 Configuration Checklist for the Transfer Service 4-31 4.7 Configuration Checklist for the Directory Service 4-33 4.8 Configuration Checklist for Exception Reporting 4-34 CHAPTER 5 Configuring a Default System 5.1 Configuring Your Network . . . . . . . . . . . . . 5-1 5.2 Starting the Configuration Procedure . . . . . . . 5-2 5.3 Configuring the Management Service . . . . . . . 5-3 5.4 Configuring the Directory Service . . . . . . . . 5-5 5.5 Configuring the Transfer Service . . . . . . . . . 5-6 5.6 Configuring Other MAILBUS Components . . . . . . 5-6 5.7 Completing the Configuration . . . . . . . . . . . 5-6 5.8 Running the Configuration Verification Procedures 5-10 5.8.1 Running the Management Service Configuration Verification Procedure . . . . . . . . . . . . 5-10 5.8.1.1 Management Service CVP Output . . . . . . . 5-11 5.8.2 Running the Directory Service Configuration Verification Procedure . . . . . . . . . . . . 5-11 5.8.2.1 Directory Service CVP Output . . . . . . . . 5-12 5.8.3 Running the Transfer Service Configuration Verification Procedure . . . . . . . . . . . . 5-12 5.8.3.1 Transfer Service CVP Output . . . . . . . . 5-13 CHAPTER 6 Post-configuration Tasks for a Default System 6.1 Tasks for the Directory Service Master Node . . . 6-1 v 6.2 Tasks for the Network Management Node . . . . . . 6-2 6.3 Tasks for Every Node . . . . . . . . . . . . . . . 6-3 CHAPTER 7 Configuring a Customized System 7.1 Configuring Your Network . . . . . . . . . . . . . 7-1 7.2 Starting the Configuration Procedure . . . . . . . 7-2 7.3 Configuring the Management Service . . . . . . . 7-3 7.4 Configuring the Directory Service . . . . . . . . 7-4 7.5 Configuring the Transfer Service . . . . . . . . . 7-4 7.6 Configuring Exception Reporting . . . . . . . . . 7-5 7.7 Configuring Other MAILBUS Components . . . . . . 7-5 7.8 Completing the Configuration . . . . . . . . . . . 7-5 7.9 Running the Configuration Verification Procedures 7-8 7.9.1 Running the Management Service Configuration Verification Procedure . . . . . . . . . . . . . 7-9 7.9.1.1 Management Service CVP Output . . . . . . . . 7-9 7.9.2 Running the Directory Service Configuration Verification Procedure . . . . . . . . . . . . 7-10 7.9.2.1 Directory Service CVP Output . . . . . . . . 7-10 7.9.3 Running the Transfer Service Configuration Verification Procedure . . . . . . . . . . . . 7-11 7.9.3.1 Transfer Service CVP Output . . . . . . . . 7-11 CHAPTER 8 Post-configuration Tasks for a Customized System 8.1 Tasks for the Directory Service Master Node . . . 8-1 8.2 Tasks for the Network Management Node . . . . . . 8-2 8.3 Tasks for Every Node . . . . . . . . . . . . . . . 8-3 APPENDIX A Example Default Configuration APPENDIX B The Default Configuration B.1 Default Parameter Settings . . . . . . . . . . . . B-1 B.2 Default Directory Structure . . . . . . . . . . . B-4 B.3 Message Router Files . . . . . . . . . . . . . . . B-4 APPENDIX C Configuration Questions C.1 Introduction . . . . . . . . . . . . . . . . . . . C-1 C.2 Management Service Questions . . . . . . . . . . . C-1 C.3 Directory Service Questions . . . . . . . . . . . C-1 C.4 Transfer Service Questions . . . . . . . . . . . . C-3 C.5 Exception Reporting Questions . . . . . . . . . . C-5 vi INDEX FIGURES 2-1 An Example of Destination Routing . . . . . . . . 2-9 2-2 An Example of Area Routing . . . . . . . . . . 2-13 B-1 Default Directory Structure . . . . . . . . . . . B-4 TABLES 1-1 Commands for Reconfiguring Message Router . . . . 1-5 B-1 Default Configuration Values . . . . . . . . . . . B-1 B-2 Message Router Files . . . . . . . . . . . . . . . B-5 vii Preface This book describes how to configure Message Router. Intended Audience This book is intended for the person who is planning and configuring a Message Router network. You need to be familiar with how Message Router works, as described in the Introduction to Message Router. Structure of This Book This book is in three parts, and contains eight chapters and three appendixes: o Part I contains four chapters. It describes how to plan a Message Router system: - Chapter 1 gives an overview of planning a Message Router network, and the planning decisions that you must make if you are upgrading or reconfiguring Message Router. - Chapter 2 describes the planning decisions that you must make for your network. - Chapter 3 describes the planning decisions that you must make for each node in your network if you use the default Message Router configuration. - Chapter 4 describes the planning decisions that you must make if you customize the Message Router configuration. ix Preface o Part II contains two chapters. It describes how to configure a default Message Router system: - Chapter 5 describes how to configure Message Router accepting the default configuration. - Chapter 6 describes the post-configuration tasks you must carry out. It also tells you how to start Message Router. o Part III contains two chapters. It describes how to configure a Message Router system that you want to customize to suit the needs of your network: - Chapter 7 describes how to customize Message Router using the configuration procedure. - Chapter 8 describes the post-configuration tasks that you must carry out. These tasks depend on how Message Router is customized. It also tells you how to start Message Router. o Appendix A provides an example printout of a successful default Message Router configuration. o Appendix B lists the default settings of the configuration options, the default directory structure, and the files in a working default system. o Appendix C provides lists of all the possible questions asked in a customized configuration. How to Use This Book Figure 1 shows you how to use this book to plan and configure Message Router for your network. Figure 1: How to Use This Book Figure 1 is not available in this draft. x Preface Associated Documents Before reading this book read the Message Router Release Notes. These release notes are on line. When Message Router is installed, they are copied into SYS$HELP:MR030.RELEASE_NOTES. If Message Router is not yet installed, see the Message Router Installation Guide for information about reading or printing the release notes. You should also read the guide Introduction to Message Router, which explains what Message Router is, and how it interacts with User Agents and Gateways. The Message Router Installation Guide tells you how to install Message Router. Note that the Message Router Configuration Guide assumes that Message Router is already installed on your node. The Message Router Management Guide tells you how to manage a Message Router system. The guide Message Router Management Action Procedures contains the Management Action Procedures (MAPs), which tell you how to recover from errors and exception conditions found by the exception reporting routines. The Message Router Management Reference Manual describes all the tools and utilities associated with Message Router. It also describes how to interpret some of the log and information files produced by Message Router. The Introduction to MAILBUS contains an overview of MAILBUS. The VAX/VMS DCL Concepts Manual contains information about the different formats you use in the configuration procedure to specify a time. You might also find the following guides useful for additional information: o Message Router Programming Guide o ALL-IN-1 Messaging Network Manager's Supplement o VAX/VMS DCL Dictionary o VAX/VMS System Services Reference Manual o VAX/VMS Networking Manual xi Preface Figure 2 shows you how to use the publications provided with Message Router. Figure 2: Message Router Documentation Map ------------------------------------------ |Read the Introduction to Message Router.| ------------------------------------------ | V ------------------------------------------------------ | Read the release notes. See the Message Router | |Installation Guide for details of how to print them.| ------------------------------------------------------ | V ------------------------------------------------ |Read the Message Router Installation Guide for| | details of how to install Message Router. | ------------------------------------------------ | V ------------------------------------------------- |Read the Message Router Configuration Guide for| | details of how to configure Message Router. | ------------------------------------------------- | V ------------------------------------------------------ | Read the Message Router Management Guide for | | details of how to manage Message Router. | | Refer to the Message Router Management Action | | Procedures and the Message Router Management | |Reference Manual for further management information.| ------------------------------------------------------ xii Preface Conventions Used in This Book red print Indicates commands or responses that you type. Unless otherwise stated, press RETURN after each command or response. this typeface Indicates prompts and messages from the system. [] Brackets are used after a configuration question to enclose the default answer. Press RETURN to accept the default. Brackets in a function or DCL command indicate an optional entry. Brackets also denote a directory specification. . Vertical ellipses indicate that the list . can or does contain more text than is . shown. ... Horizontal ellipses indicate that additional text can be entered. Horizontal ellipses in an MB$CONTROL or MB$CONFIG command indicate that you can add to the command line the identifier of any Gateway on your system. 1 Marks the order of steps you must follow 2 to complete a procedure. 3 a Marks steps within a major step in a b procedure. c xiii Part I Planning Your Configuration Chapter 1 Configuring Message Router 1.1 Introduction After you install Version 3.0 of Message Router on a node or VAXcluster, you must configure it before you can use Message Router. This is because the Message Router installation procedure does not have enough information to tailor Message Router to suit your system. The MAILBUS configuration procedure, MB$CONFIG, asks questions about your node and network, and uses your answers to configure the components of MAILBUS that you have on the node. See the Introduction to MAILBUS for more information about MAILBUS. 1.2 Planning Your Configuration Planning the configuration of Message Router involves making planning decisions for the whole network, and for each node and cluster. The configuration of the nodes and clusters in your network is partly determined by the network planning decisions you make. Chapter 2 describes the network planning decisions that you must make before you configure Message Router on any of the nodes in your network. If you are upgrading your network from Message Router Version 2.0 or 2.1, you must also consider the factors described in Section 1.3. If you are reconfiguring an existing Message Router Version 3.0 system, you must also consider the factors described in Section 1.4. 1.3 Upgrading from Version 2.0 or 2.1 of Message Router Read the following sections if you are upgrading from Message Router Version 2.0 or 2.1. 1-1 Configuring Message Router 1.3.1 Using Your Version 2.0 or 2.1 Configuration You cannot preserve your Version 2.0 or 2.1 configuration. If you want to use the same configuration for Version 3.0 as you did for Version 2.0 or 2.1, use the Message Router Version 2.0 initialization utility to print a copy of the configuration settings. You must do this before you configure Version 3.0, because the configuration overwrites the existing configuration with the new default configuration. 1.3.2 Minimizing Interruption to Your Electronic Mail System If you want to upgrade to Message Router Version 3.0 causing as little disruption as possible to your electronic mail system, take the following steps: 1 Plan the configuration for the whole network. 2 If you intend using the Directory Service in your network, upgrade the node that is going to be the Directory Service master node. Then set up the Directory Service nodes list to include the names of all the other nodes in the network. 3 Upgrade the network management node. 4 Upgrade the remaining nodes in the network one at a time. If you intend using the exception reporting routines, when you have upgraded a node, add the name of each node to the exception reporting nodes list on the network management node. 1.3.3 Messages in the Version 2.0 or 2.1 System Any messages in your Version 2.0 or 2.1 system are stored while you install and configure Message Router. They are forwarded when you start the Transfer Service. If you have a large number of messages in transit, you must allow extra space on the disk where you install Message Router. 1.3.4 Cluster Names Cluster aliasing is a means of naming a cluster, so that the cluster is recognized within the network by its cluster name. 1-2 Configuring Message Router If cluster aliasing is enabled for the Transfer Service during configuration, tell your users to use the name of the cluster rather than the name of the node to send mail. When receiving mail, connections from a node in a cluster are identified by the cluster name rather than the individual node name. For the Transfer Service component of Message Router Version 3.0, you must only use cluster aliasing if every node in your Transfer Service network runs Message Router Version 3.0 or later. Cluster aliasing must not be used in a Transfer Service network that contains Message Router Version 2.0 or 2.1. Use cluster aliases with a homogeneous configuration of the Transfer Service. If you have a heterogeneous Transfer Service set up with multiple databases, you should not use cluster aliases. This is because a cluster alias that applies to more than one database gives unpredictable results, because any node can pick up the incoming connection. The Directory Service is a new component of Message Router. In the case of the Directory Service, you must define and enable cluster aliasing. It is not possible to run the Directory Service successfully on individual nodes in the cluster. If your cluster does not currently use an alias, ask your system manager to set one up. You can run Message Router on a cluster with some components using cluster aliases and others not. 1.3.5 Exception Reporting for Version 2.1 Nodes Message Router Version 3.0 contains a command procedure, MB$ER_UPGRADE, which enables a node running Version 3.0 of Message Router to monitor for errors and exception conditions a node running Version 2.1 of Message Router. If you do not want to upgrade all your nodes to Version 3.0 of Message Router, but you want to use the exception reporting routines to monitor all the nodes in your network, complete the following steps: 1 Copy the upgrade command procedure from MB$TOOLS on the node where Message Router Version 3.0 is installed to SYS$UPDATE on the node running Message Router Version 2.1. 2 Log in to the SYSTEM account on the node running Message Router Version 2.1, and type: $ @SYS$UPDATE:MB$ER_UPGRADE 1-3 Configuring Message Router 3 Log in to the MBMANAGER account on the network management node. Use the MBMAN ADD ER NODE command to add the name of the node running Version 2.1 of Message Router to the exception reporting nodes list. See the Message Router Management Guide for information about adding nodes to the exception reporting nodes list. 1.4 Reconfiguring Message Router Read the following sections if you are reconfiguring Message Router Version 3.0. There are two reasons why you might want to reconfigure Message Router: o To accommodate changes in your system o To recover from errors Before you run the MAILBUS configuration procedure, MB$CONFIG, to reconfigure any Message Router component, you must stop all the MAILBUS components on your node. See the Message Router Management Reference Manual for details of how to stop Message Router. See the relevant management guide for details of how to stop any optional MAILBUS components that are on your node. 1.4.1 Reconfiguring Message Router When Your System Changes You can change the way your Message Router system works, without having to reinstall it, by reconfiguring Message Router. Before you make any changes to the configuration of your system, you should read the following chapters of this book: o If you have a default configuration, read Chapters 2 and 3 to see whether the default configuration is still appropriate for your system. If you decide that the default configuration is still suitable for your requirements, read the relevant sections in Chapter 5 and reconfigure Message Router. You need only reconfigure the components that you want to change. Table 1-1 gives the sequence of configuration commands that you should use. 1-4 Configuring Message Router If you decide that you no longer want a default configuration, read Chapter 4. Then reconfigure your system as a customized system, as though you were configuring Message Router for the first time (see Chapter 7 for instructions). o If you have a customized configuration, read Chapter 4 to understand the implications of the changes you want to make. Then read Chapter 7 and reconfigure Message Router. You need only reconfigure the components that you want to change. Table 1-1 gives the sequence of commands that you should use. If your Message Router system is changing to become simpler, you might be able to use the default configuration. Read Section 2.9 and decide whether you can use the default configuration. If so, reconfigure your system as a default system, as though you were configuring Message Router for the first time (see Chapter 5 for instructions). Table 1-1 contains a summary of the configuration commands that you should use when reconfiguring your system: Table 1-1: Commands for Reconfiguring Message Router Default to default SET, ENABLE, RECOVER for each component you want to change Default to customized CREATE, SET, ENABLE, RECOVER for every component Customized to default CREATE, SET, ENABLE, RECOVER for every component Customized to customized SET, ENABLE, RECOVER for each component you want to change 1.4.2 Reconfiguring Message Router to Recover from Errors If an error occurs in Message Router, you might be asked, either in the error description in the Message Router Management Reference Manual or in a MAP, to reconfigure Message Router to recover from the error. When a MAP tells you to reconfigure Message Router, the MAP includes full instructions. 1-5 Chapter 2 Planning a Message Router Network 2.1 Network Planning There are some decisions you have to make about your Message Router network before you can configure it. You must decide: o Which nodes in your network are to be world search nodes o Which node is to be the network management node o Which node is to be the Directory Service master node o How to populate the Directory Service o Which routing method to use o How to configure clusters o The network time o Whether you want a default or customized Message Router configuration o Whether to allow previous versions of Message Router to run in your network 2.2 World Search Nodes A world search node is a node that holds a copy of all the directory entries for the entire network in its permanent database. Because of this, a world search node has a very small cache. 2-1 Planning a Message Router Network You can have more than one world search node in a network. You must have at least one world search node in a network. If your network includes more than one DECnet area, you are recommended to have one world search node in each area. For information about DECnet areas, see the VAX/VMS Networking Manual. A world search node must have the following characteristics: o It is permanently available, that is, it is not connected to the network by a dial-up line o It must have sufficient disk space for a large permanent database file o It must have sufficient CPU capacity to cope with inquiries from other nodes o The connection between the node and the rest of the network should have a wide bandwidth to cope with large volumes of message traffic 2.3 Network Management Node Choose a network management node for your network. The network management node is where the exception reporting nodes list is held. Choose a network management node that has the following characteristics: o It is permanently available, that is, it is not connected to the network by a dial-up line o It has sufficient disk space to receive and keep exception report mail messages o It is central in the network, to reduce the amount of network traffic o It is easily accessible to the network manager o The connection between the node and the rest of the network is reliable You can have more than one network management node, and manage your network in areas. Add to the exception reporting nodes list on each network management node, the names of the nodes that the node is to 2-2 Planning a Message Router Network manage. 2.4 Directory Service Master Node The master node is the node that owns the master copy of the Directory Service template and nodes list. This node must be configured first in your network. For more information about the role of the master node, see the Introduction to Message Router. The configuration procedure offers the name of the node you are configuring as the default master node. This means that if you have already configured the Directory Service on any other node in your network, you cannot accept the default answer. If your network is not going to use the Directory Service, you do not need to choose a Directory Service master node. 2.5 Directory Service Population The Directory Service is a service that Message Router provides for Gateways and User Agents. The Directory Service is not used by Message Router to forward mail messages. Each Gateway and User Agent that uses the Directory Service imposes requirements and constraints on how you use the Directory Service. Ensure that the way in which you use the Directory Service satisfies all the requirements and constraints imposed by the Gateways and User Agents. You must use the Directory Service consistently throughout your network. If more than one Gateway or User Agent uses an attribute, then they must use that attribute identically. For example, suppose in your network you have a Message Router X.400 Gateway (MRX) and a Message Router/S Gateway (MRS). MRX requires a subscriber's given name to be no longer than 16 characters. MRS imposes no requirements on the length of the given name. You might have a further requirement that the name by which a subscriber is usually known, and for which other subscribers search, is longer than 16 characters. To meet these requirements, use two values for the subscriber's given name, the first value meeting the requirements of the products in your network by not exceeding 16 characters, the second value being the given name by which the subscriber is usually known. You might also want to include other values for the given name, perhaps to include common misspellings. 2-3 Planning a Message Router Network Updating the database is expensive, because of the time it takes to collect the information you need and add the entries to the database. You can minimize the number of updates you make by adding to each entry all the attributes you have information for when you create that entry. You should create an entry on the node where you intend managing that entry. You cannot use the MBMAN utility on a node to update an entry on a different node. If necessary, you can move the entry to another node, but moving entries is time-consuming and expensive. Entries in the database must be unique, so that you can update entries using a batch job. Use the SUBID attribute to ensure that entries are unique. If you do not use the SUBID entry, you must supply enough information when selecting an entry to be certain that you select the correct entry. For example, suppose you have two subscribers named John Smith who both work in the same department of a company. Their subscriber entries are: GIVENNAME = John GIVENNAME = John SURNAME = Smith SURNAME = Smith NAME = John Smith NAME = John Smith ORGNAME = DIGITAL ORGNAME = DIGITAL ORGUNIT = Accounts ORGUNIT = Accounts INITIALS = J A S INITIALS = J N S To select one of these entries uniquely, you must specify all the information about the subscriber that is available: MBMAN> SELECT DDS SUBSCRIBER /SURNAME=SMITH - /GIVENNAME=JOHN /ORGNAME=DIGITAL /ORGUNIT=ACCOUNTS /INITIALS=JAS ... If you include the SUBID attribute in all subscriber entries, and assign values of SUBID uniquely, you need only specify SUBID to select an entry uniquely: MBMAN> SELECT DDS SUBSCRIBER /SUBID=135AC743 2.6 Routing If you use default routing, messages can be forwarded to nodes whose names are not in the Transfer Service database. This is because default routing uses the underlying DECnet network, and so messages can be delivered to any node in the DECnet network. See Section 2.6.1 for more information about default routing. 2-4 Planning a Message Router Network By default, the Transfer Service uses default routing. The combination of routing methods that you use depends on the size and complexity of your network and the expected message throughput. The three types of recommended routing methods are: 1 Default routing, the simplest routing method. Default routing relies on the underlying DECnet network and is recommended for systems running DIGITAL User Agents. The message sender has to specify the recipient, the recipient's User Agent or a Gateway, and the destination node of the message. See Section 2.6.1. 2 Destination routing, suitable for a stable network of up to about 30 nodes running the Transfer Service. The message sender has to specify the same address information as for default routing, namely: the recipient, the recipient's User Agent or a Gateway, and the destination node of the message. See Section 2.6.2. 3 Area routing, suitable for a larger network that has either a complex topology, unreliable links, or too many nodes to manage as one area. You can use either of the other two types of routing within each area, depending on its characteristics. The message sender has to specify the destination area as well as the same address information as for the other routing methods. See Section 2.6.3. In the following sections, the term fanout refers to how the Transfer Service can transfer messages through the network. If a message is addressed to several users and part of the route to those users is common, only one copy of the message is sent along that part of the route. After the message has been transferred along the common route, copies of the message "fan out" from that point along different routes to reach their destinations. 2.6.1 Default Routing The simplest routing method you can use on a system is default routing. This method uses the underlying DECnet network to route messages. This means that you do not have to include any remote mailbox entries in the mailbox directory or add any nodes to the nodes list. This method of routing does not take full advantage of Message Router's store-and-forward capability. The message is stored on the sender's node until a route to the destination node is available, and the message is forwarded along the complete route to the destination 2-5 Planning a Message Router Network node. The advantages of default routing are: o Very little planning is necessary because default routing uses the DECnet network to ensure that each node knows about all the other nodes in the DECnet database. o The initial set up of the Transfer Service is simplified. You do not have to add any nodes to the Transfer Service nodes list. o When a new node joins the network, you do not have to add the node to the Transfer Service nodes lists or put any routing information in any of the mailbox directories. o Low cost for routing. Routing messages through DECnet costs less in terms of processor time and disk I/O than routing messages through the Transfer Service. The disadvantages of default routing are: o You cannot use fanout to lower the cost of sending the same message to many recipients along the same route. o You cannot avoid congestion, or lower costs by using specific paths that differ from normal DECnet traffic. o You must manage the network as a whole. o You cannot examine individual node mailboxes because they are not included in the mailbox directory. Instead, you have to use the pseudo-node name of DEFAULT_DECNET when you want to examine any node mailboxes, as in the MRMAN PURGE or DUMP commands. If you are running Message Router with a DIGITAL User Agent, it is recommended that you run your system with default routing. The following entries are made automatically in the Transfer Service database during its configuration providing you have accepted the default routing option during configuration: o Local node mailbox entries in the mailbox directory. If you configure a cluster accepting the option of a cluster-wide configuration, entries are also included for the names of the nodes in the cluster and the cluster alias, if one is defined. 2-6 Planning a Message Router Network o DEFAULT_DECNET mailbox entry in the mailbox directory o DEFAULT_DECNET entry in the nodes list The mailbox entry for the User Agent is usually added to the mailbox directory during the User Agent's installation. Providing the User Agent has its own directory of users, or you are using the Directory Service, you do not need to make any further entries in the database for messages to be transferred. Since every node in the network knows how to send to every other node in the network, the message sender has to specify only the recipient, that recipient's User Agent mailbox name or Gateway name, and the destination node of the message. For example: To : COLLINS@A1@NODEA where: o COLLINS is the recipient o A1 is the User Agent mailbox, (in this case ALL-IN-1) o NODEA is the destination node; this is optional if the originator is on the same node as the recipient Providing the destination node is running a Message Router and the specified User Agent, the message is delivered to the User Agent mailbox on the destination node. The User Agent then delivers the message to the recipient. 2.6.2 Destination Routing Use this routing method if you want to specify which routes messages should take through the network. You might want to specify the routes that messages take so that they use fast links wherever possible. Another reason for specifying routes is for accounting purposes, so that you can monitor the resources certain users are using. This routing method is suitable for networks that are not always fully connected. For example, your network might include dialup links to remote nodes. If you are running Message Router with a DIGITAL User Agent, you can use this style of routing. However, it needs more management than default routing. 2-7 Planning a Message Router Network The advantages of destination routing are: o You can use fanout to lower the cost of sending the same message to many recipients along the same route. o You can control how messages are routed through your network and use specific paths, that differ from the normal DECnet traffic, to avoid congestion or to lower costs. o You know when a new node joins the network because you have to set up entries for it in the mailbox directories and the nodes lists The disadvantages of destination routing are: o Routing messages through the Transfer Service is more costly in terms of processor time and disk I/O than DECnet routing. o It involves more management than default routing. If your network is not stable, entries in the mailbox directories and nodes lists have to be updated to reflect the changes in topology. Adding a new node to the network is more complicated than for default routing. With destination routing, each mailbox directory specifies either a complete route or the next step in the route to reach every other node in the network. Since the Transfer Service systems can determine the complete route of a message using the information in their mailbox directories, the sender needs to specify the recipient, the recipient's User Agent or Gateway, and the destination node of the message. The sender need not specify the intervening nodes on the route. For example: To : COLLINS@A1@NODEA where: o COLLINS is the recipient o A1 is the User Agent mailbox, (in this case ALL-IN-1) o NODEA is the destination node; this does not need to be included if the recipient is on the same node as the originator 2-8 Planning a Message Router Network With this method of routing, you control only how messages are transferred between Transfer Services. The Transfer Service uses DECnet actually to transport the messages around the network and you cannot determine which paths DECnet uses to route messages. You can use default routing with this style of routing, because the message sender has to specify both the destination node and the recipient. However, if you mix default routing with destination routing in a network, you will not be able to control fully the routes that messages should take through the Transfer Service network. If you are running your network with mixed routing methods, the neighbor node entries in the mailbox directory, specified with destination routing, take precedence over the DEFAULT_DECNET entry, specified with default routing. See the Message Router Management Reference Manual for a definition of neighbor nodes. Also, if a node specified with destination routing is not reachable, default routing does not take over. The node can only be reached by the route specified by destination routing. Destination routing is ideal for a network that is stable and is not too large. As a rough guide, it is suitable for a network of up to about 30 nodes running the Transfer Service. It is easy for users to use but it can be difficult to maintain if the network configuration is unstable. The mailbox directory contains routing entries for each distant node in the network and has to be updated on each node to reflect any change in the network configuration. Providing the User Agent has its own directory of users, or you are using the Directory Service, you do not need to make any further entries in the database for messages to be transferred. Figure 2-1 shows an example of a network for which destination routing is suitable. Figure 2-1: An Example of Destination Routing NODEB NODEH | | | | NODEC----NODEA---------------------------NODEE----NODEF | | | | NODED NODEG 2-9 Planning a Message Router Network NOTE In this example, all the routing used is destination routing. You can use a combination of default and destination routing, if it suits your network. The mailbox directory on each node defines its local User Agents and Gateways and all the nodes in the network. Suppose user1 on NODEC wants to send a message to user2 on NODEF. The message address would be USER2@UAmbx@NODEF, where UAmbx is the name of the User Agent mailbox in the mailbox directory. The directory on NODEC holds the following entries: o The local User Agent mailbox o A local node entry for NODEC o NODEA is defined as a neighbor node entry o The other six nodes are defined as distant node entries, which means that messages for users on these nodes are routed through the neighbor nodes and any intervening distant nodes. The message for user2 on NODEF is routed through NODEA and NODEE where they are stored and forwarded. The entries in the directory for the distant nodes are: NODEB Route=@NODEA NODED Route=@NODEA NODEE Route=@NODEA NODEF Route=@NODEE@NODEA NODEG Route=@NODEE@NODEA NODEH Route=@NODEE@NODEA The routing entries for the remote nodes do not have to cover the whole route to reach the distant node. Instead, the routing entries could just indicate the step to the next node in the route. The node used to route messages through must be a neighbor node to the originator's node. In this example, the entries in the mailbox directory on NODEC would be as follows: NODEB Route=@NODEA NODED Route=@NODEA NODEE Route=@NODEA NODEF Route=@NODEA NODEG Route=@NODEA NODEH Route=@NODEA 2-10 Planning a Message Router Network The mailbox directory on NODEA would then indicate the next node in the route to reach the destination. NOTE In the DECnet database, each node must have the same name assigned to the DECnet node address for each node as every other node in the network. All addresses must be assigned the correct names on all nodes. Also, each node must have entries for all of its neighbor nodes in the DECnet database. 2.6.3 Area Routing In area routing, you specify area code mailbox directory entries that divide the network logically into a number of areas. Each area contains a group of nodes. If you are running Message Router with a DIGITAL User Agent, you can use this style of routing. However, it needs a lot more management than default routing. You can define the member nodes of an area on any basis, for example, geographical or functional. However, the network will run more efficiently if you group together nodes connected by fast links, for example, 56k baud or Ethernet. Within the area, nodes can send directly to each other using one of the other types of routing. In each area, one node, the hub node, handles all messages that pass to or from the area. That node is connected, possibly by a slow link, to the hub node in another area. On large networks, area routing has these advantages: o You can use fanout to reduce network traffic, especially along heavily-used links. For example, if a message is addressed to several users on nodes within another area, only one copy of the message passes between areas. o Providing the links between areas are reliable, area routing can reduce the number of transmission failures and, hence, messages do not need to be stored and forwarded as often as in other routing methods. 2-11 Planning a Message Router Network o It divides the system into units of manageable size, and nodes can be added to the network without affecting too many other nodes in the network. o It provides simple addressing for users. However, area routing can have disadvantages: o Processing at intervening hub nodes can cause a message to take longer to reach its destination than with more direct routing methods o If a hub node is unreliable, it can delay messages to and from nodes within the area, as well as messages that it routes between other areas o The quantity of traffic at a hub node can be enough to degrade performance, (a node with a high throughput of traffic needs more frequent maintenance) Mailbox directories at nodes within each area specify: o User Agent and Gateway mailbox entries, if they are installed in the network. o The route to reach the hub node of its area. Nodes can be connected to their hub node either directly or via another node in their area. o The route to each other area. Other areas can only be contacted through the hub nodes of the originating area and the destination area. o The route to reach each other node in their area, as in destination routing. However, nodes within an area can use default routing. During configuration, you must supply the area code for each area that uses area routing. These codes are used by User Agents and Gateways. The User Agents and Gateways append the area code to the address of the message originator. This ensures that replies to the message include the area code in the address. The example network in Figure 2-2 consists of two areas. Each area consists of a group of nodes connected by fast links. 2-12 Planning a Message Router Network Figure 2-2: An Example of Area Routing ------------------------------- ----------------------------- | | | | | NODEF | | | | | | | | | | | | NODEP | | NODEG---NODEB---NODEE | | | | | | | | NODEO | NODEQ | | NODEH | | | \ | / | | \ | | | \ | / | | \ | | | \ | / | | NODEI---NODEC---NODEA*************************NODEN----NODER | | / | | | / | \ | | / | | | / | \ | | NODEJ | | | / | \ | | | | | NODEU | NODES | | NODEK---NODED---NODEM | | | | | | | | NODET | | | | | | | NODEL | | | | | | | | AREA1 | | AREA2 | ------------------------------- ----------------------------- ------ denotes a fast link ****** denotes a slow link In Figure 2-2: o AREA1 contains nodes NODEA to NODEM, with NODEA as the hub node, and uses destination routing within the area o AREA2 contains nodes NODEN to NODEU, with NODEN as the hub node, and uses default routing within the area Only the hub nodes are connected to nodes outside their own area. In the example, the links between the hub nodes are slow. Each mailbox directory contains entries for any User Agents or Gateways that are in the network, as well as the local node entry. The list of users should be maintained by the User Agent or by the Directory Service. 2-13 Planning a Message Router Network In the example, the following mailbox directories contain the following entries: o NODEF - NODEF as a local node entry - User Agent or Gateway mailbox entries for any User Agents or Gateways used on NODEF - Routing entries for all other nodes in the area, routed through NODEB - NODEB as a neighbor node - AREA1 routed through NODEB - AREA2 routed through AREA1 o NODEB - NODEB as a local node entry - User Agent or Gateway mailbox entries for any User Agents or Gateways used on NODEB - NODEE, NODEF and NODEG as neighbor nodes - Routing entries for all other nodes in the area, routed through NODEA - NODEA as a neighbor node - AREA1 routed through NODEA - AREA2 routed through AREA1 o NODEA - the hub node for AREA1 - NODEA as a local node entry - User Agent or Gateway mailbox entries for any User Agents or Gateways used on NODEA - NODEB, NODEC, and NODED as neighbor nodes 2-14 Planning a Message Router Network - Routing entries for all other nodes in the area, routed through NODEB, NODEC, and NODED, as appropriate - NODEN as a neighbor node - AREA1 as a null entry - AREA2 routed through NODEN o NODEN - the hub node for AREA2 - NODEN as a local node entry - User Agent or Gateway mailbox entries for any User Agents or Gateways used on NODEN - DEFAULT_DECNET mailbox for default routing - AREA2 as a null entry With this method of routing, users must use the following addressing syntax: user@UAmbx@node@area where UAmbx is the name of the User Agent mailbox in the mailbox directory. If the recipient is in the same area as the originator, the message address does not have to include the name of the area. Also, if the recipient is on the same node as the originator, the message address does not have to include the name of the node. 2.7 Clusters The configuration procedure asks whether or not you want to accept a cluster-wide configuration. If you have installed the Transfer Service homogeneously, you can accept a cluster-wide configuration. In this case, you need only run the configuration procedure once on the cluster. If you have a heterogeneous cluster configuration, or do not want to use the cluster-wide configuration for your homogeneous cluster, the configuration procedure must be run for each Transfer Service 2-15 Planning a Message Router Network database, on each node that uses it. The full set of configuration questions is asked when you configure individual nodes on a heterogeneous cluster, even if you previously accept a cluster-wide configuration. There are other points that you need to consider when you configure either a homogeneous or heterogeneous cluster: o The default answers offered with the questions relating to nodes include the name of the cluster alias and not the name of the node. If the cluster alias is not defined, the default offered is the local node name. o The cluster configuration adds each cluster member into the exception reporting nodes list. This allows the network exception reports to be run interactively from nodes other than the network management node. For details of running the exception reports manually, refer to the Message Router Management Guide. o When you accept a cluster-wide configuration, the name of each node in the cluster and the cluster alias are added to the Transfer Service database on the cluster as null entries. If you want to change from a cluster configuration to a node-specific configuration, you must delete the null entries from the Transfer Service database manually using the MRMAN DELETE command. Refer to the Message Router Management Reference Manual for details of the MRMAN commands. If, for a heterogeneous cluster, you need to recover a component of MAILBUS, follow the same guidelines given for installing Message Router on a heterogeneous cluster. Recover the component on each node where Message Router is installed. 2.8 Network Time If your network spans more than one time zone, you must have a standard network time for Message Router. Using a single standard network time makes records consistent throughout the network, and therefore easier to compare. 2.9 Default or Customized Message Router Configuration Before you can configure your Message Router network, you must decide whether you want a default or customized system. This decision 2-16 Planning a Message Router Network determines how Gateways in your network are configured. For example, you can only customize the Message Router VMSmail Gateway if you have customized Message Router. The default configuration provided by Message Router has the following features: o The Transfer Service uses default routing o The Transfer Service maintenance command procedure performs housekeeping tasks automatically o One Transfer Service notify talker runs on every node in the network o The Transfer Service sends service messages interactively o The Transfer Service renames and keeps rejected messages o All Transfer Service message transactions are logged, but message transfer does not stop if logging fails o The exception reporting routines monitor the network for errors and exception conditions o The network management node monitors the exception reporting routines o The Directory Service maintenance command procedure performs housekeeping tasks automatically o The Directory Service cache refresh command procedure automatically refreshes entries in the cache database o The Directory Service deferred update command procedure automatically implements deferred updates to entries in the database If you want a default system, read Chapter 3, which describes how to plan a default configuration. Otherwise, read Chapter 4, which describes how to plan a customized configuration. 2.10 Network Planning Checklist Before you can configure your network, you need to know the following information: 2-17 Planning a Message Router Network o Which node in your network is going to be the world search node. You can have more than one world search node in your network. o Which node in your network is going to be the network management node. o Which node is your network is going to be the Directory Service master node. You must configure this node first. o The type of routing method you want to use. o How you are going to configure any clusters in your network. o The standard network time you want to use in your network if it spans more than one time zone. o The type of configuration you want for the network. You can either accept the default configuration or customize your system. 2-18 Chapter 3 Planning a Default Configuration There are some decisions that you have to make for every node, even if you decide to accept the default configuration. You must decide: o The time zone correction needed for the node. o Which devices you want to use for your Message Router system on the node. You can specify different devices for the Management Service, Directory Service, and Transfer Service. o The password that you want for the MBMANAGER account. 3.1 Time Zone Correction If your network spans more than one time zone you must specify the time zone correction you need for the node. The time zone correction is the time that you have to add to your local time to reach standard network time. You must specify the time zone correction in the format: -hh:mm where the minus sign (-) is only needed if local time is ahead of network time and hh:mm is the difference, expressed in hours and minutes. 3.2 Message Router Devices The configuration procedure gives you the option of moving the Directory Service, Transfer Service, and Management Service files from the device where Message Router was installed to other devices. 3-1 Planning a Default Configuration If you decide to move a component to a different device, make sure that the device has sufficient space: o The device for the Management Service must have at least 5000 blocks of free space available o The device for the Transfer Service must have at least 15000 blocks of free space available o The device for the Directory Service must have at least 30000 blocks of free space available (more for a world search node) You can use the same device for all these components, or for any combination of these components, providing there is sufficient space. 3.3 MBMANAGER Account Password Decide what password you are going to use for the MBMANAGER account. You must change this password frequently. The password that you set for the MBMANAGER account is also used by the following accounts: o MRNET o DDSNET o MBWATCH o MRMANAGER If you want to set separate passwords for the MRNET, DDSNET, and MBWATCH password, you must configure your system using a customized configuration. The MRMANAGER account always has the same password as the MBMANAGER account. 3.4 Enable Exception Reporting You must enable exception reporting during configuration if you want to run the exception reporting routines for any of the MAILBUS components. If you do not enable exception reporting, the exception reporting routines that monitor the Directory Service, Transfer Service, and any Gateways on your node, and the network exception reporting routines do not run. 3-2 Planning a Default Configuration 3.5 Alarm Levels of Free Blocks for Exception Reporting You can specify the minimum number of free blocks that can be available to the Transfer Service and Directory Service. If you are running the exception reporting routines, when the number of free blocks falls below these minimum values, an exception report is sent to the MBMANAGER account on the network management node. You can also specify a minimum value for the total number of free blocks available to Message Router on your node. 3.6 Configuration Checklist Before you configure Message Router accepting the default configuration on a node, you need to know the following information: o The name of the device for the Management Service o The name of the network management node o The time zone correction needed for the node you are configuring o The new password for the MBMANAGER account o The name of the device for the Directory Service o The name of the Directory Service master node (you must configure this node first) o The alarm level of free blocks for the Directory Service o The name of the device for the Transfer Service o The alarm level of free blocks for the Transfer Service o Whether you want to enable exception reporting on this node 3-3 Chapter 4 Planning a Customized Message Router System This chapter explains the configuration options in a non-default, or customized, Message Router system. If you customize your system, you can configure the following components of Message Router: o The Management Service o The Transfer Service o The Directory Service You can also configure exception reporting for Message Router. 4.1 Configuring the Management Service You can configure the following options in the Management Service: o The device used by the Management Service section of the MAILBUS directory structure o The account where the exception reporting routines send exception reports o The time zone correction, if your network spans more than one time zone o Passwords for the Message Router accounts 4.1.1 Device for the Management Service You can change the device used by the directories [MB$.MB] and 4-1 Planning a Customized Message Router System [MB$.TOOLS]. The new device does not have to be the same device as the device that the Message Router kit is installed on. If you choose to change the device used by the Management Service, the whole directory structure is copied on to the device you specify, but only the files in the Management Service subdirectory, [MB$.MB], and its subdirectories are moved to the new device. You must not delete the empty directory files. 4.1.2 Destination for Exception Reports You can specify the account to which the exception reporting routines send exception reports. The default account is the MBMANAGER account on the network management node. 4.1.3 The Time Zone Correction If your network spans more than one time zone, you must specify the difference between your own local system time and the standard network time. This enables all messages throughout the network to use a standard time and makes them easier to trace. Specify the time difference in delta-time format, that is, standard network time minus local system time. The delta-time format is as follows: -hh:mm where: o - (minus sign) is included only if the standard network time is behind your local system time o hh:mm represents the offset value, expressed in hours, minutes, and seconds. By default, the time zone correction is 00:00. If your local system time is the same as network time, accept the default value. 4.1.4 Account Passwords You can specify passwords for the MBMANAGER, MRNET, DDSNET, and MBWATCH accounts. The MRMANAGER account always uses the password that you specify for the MBMANAGER account. 4-2 Planning a Customized Message Router System 4.2 Configuring the Directory Service You can customize the following options in the Directory Service: o The device used by the Directory Service section of the MAILBUS directory structure o Whether you want to enable exception reporting for the Directory Service, and if so, the minimum number of free blocks that the Directory Service requires o The locations of the following Directory Service files: - The permanent database file - The permanent attribute index file - The cache database file - The cache attribute index file - The event log file - The input queue file - The output queue file - The network queue file - The network index file o The Directory Service events that you want to ignore, count, log, or broadcast to specified operators' consoles o Whether you want to defer update transactions on objects and, if so, which objects' updates you want to defer o Whether you want to notify an operator of Directory Service errors, and if so, which operator o The maximum number of entries in the cache o The maximum number of simultaneous network links to a Directory Service listener o Whether you want to run the Directory Service maintenance command procedure, DDS$TIDY, and if so, the schedule on which it runs 4-3 Planning a Customized Message Router System o Whether you want to run the Directory Service deferred update command procedure, DDS$DEFER, and if so, the schedule on which it runs o Whether you want to run the Directory Service cache refresh procedure, DDS$REFRESH, and if so, the schedule on which it runs 4.2.1 Directory Service Device You can change the device used by the Directory Service subdirectory, [MB$.DDS], of the MAILBUS directory structure. You do not have to use the device where the Message Router kit is installed. If you choose to change the device used by the Directory Service, the whole directory structure is copied on to the device you specify. Most of the files in the Directory Service subdirectory, [MB$.DDS], and its subdirectories, are moved to the new device. The files that are not copied to the new device are: o The permanent database file o The permanent database index file o The cache database file o The cache database index file o The event log file o The input queue file o The output queue file o The network queue file o The network queue index file See Section 4.2.3 for information about specifying the devices for these Directory Service files. The directory files in the other parts of the Message Router directory structure exist on the new device, but are empty. You must not delete these empty files. 4-4 Planning a Customized Message Router System The default device is the device where Message Router is installed. 4.2.2 Exception Reporting for the Directory Service The exception reporting routines monitor the Directory Service for errors and unusual occurrences. If you specify that you want exception reporting for the Directory Service, it is enabled when you use the MB$CONFIG ENABLE ER command, provided that you have enabled the Directory Service. If you want exception reporting for the Directory Service, you must specify the minimum number of free blocks on the device used by the Directory Service. The default number of free blocks is 20000. The exception reporting routines check that this number of free blocks are available on every node used by the Directory Service. By default, the exception reporting routines monitor the Directory Service. 4.2.3 The Directory Service File Locations The configuration procedure offers you the option of moving the following Directory Service files to other devices: o The permanent database file o The permanent database index file o The cache database file o The cache database index file o The event log file o The input queue file o The output queue file o The network queue file o The network queue index file See the Message Router Management Reference Manual for information about these files. 4-5 Planning a Customized Message Router System The default device is the device where Message Router is installed. 4.2.4 Directory Service Events You can specify the Directory Service events that you want to monitor, and those that you want to ignore. See the Message Router Management Reference Manual for details of Directory Service events. If you want to monitor an event, you can log each occurrence of that event, or count the number of times that the event occurs. You can also broadcast a message to a specified operator's console if that event occurs. If you specify that you want the operator to be informed of a particular event, that event is automatically logged and counted. If you specify that you want an event to be logged, it is automatically counted. The configuration procedure offers the following defaults: o Events broadcast: 0.0-0.7 o Events logged: 1.0-1.10, 3.0-3.4, 4.6-4.9, 7.0-7.15 o Events counted: 2.0, 2.1, 4.0-4.5, 4.10, 4.11, 5.0-5.31 o Events ignored: all other events If you do not specify at configuration how a particular event is to be treated, the Directory Service selects the default treatment for that event. You should not specify more than one treatment for an event. If you specify more than one treatment, the last treatment that you specify is the treatment that the event receives. You can use an asterisk (*) to specify groups of events. For example, 7.* means 7.0 to 7.15, and *.* means all events. 4.2.5 Deferring Updates You can defer updates to objects in the Directory Service database. That is, you can enter the commands that cause an update, but specify that the update does not take place immediately. Later, when the network is not busy, you can execute any deferred transactions. See Section 4.2.10 for information about configuring DDS$DEFER. See the 4-6 Planning a Customized Message Router System Message Router Management Guide for information about updating the database and deferred transactions. If you specify that you want to allow deferred updates, you must also specify the types of object whose updates you want to defer. By default, updates to the template object are deferred. 4.2.6 Informing the Operators of Directory Service Errors The Directory Service can broadcast messages to the operators' consoles indicating that selected events have occurred. The events that can cause messages to be broadcast to operators are described in the Message Router Management Reference Manual. The Directory Service can broadcast these messages on the consoles of the central operator, the network operator, or a user-defined operator. There are 16 user-defined operators, which correspond to the operator terminal types used by the VMS system service $SNDOPR (send-message-to-operator). For more information about $SNDOPR, see the VAX/VMS Systems Services Reference Manual. If you are running the exception reporting routines for the Directory Service, these same events cause exception report messages to be sent, so it is not necessary to broadcast the messages. If you are not running the exception reporting routines, you might still be able to use the information in the MAPs to recover from events that are broadcast to the operator. By default, the Directory Service broadcasts the messages to the network operator's console. 4.2.7 Controlling the Number of Entries in the Cache Database You can specify the maximum number of entries that the cache can hold simultaneously. For information about how the Directory Service uses its cache database, see the Introduction to Message Router. DIGITAL recommends that you accept the default number of entries, 200, when you first set up your system, except on nodes that you intend using as world search nodes, where the recommended number of entries is one. When the Directory Service has been in use for a short while on your system, you can assess whether the cache needs to be increased or decreased. If you have to perform world searches frequently for the 4-7 Planning a Customized Message Router System same object, the cache is too small. If you perform world searches only very rarely, the cache is too large. For information about changing the cache size, see the Message Router Management Guide. 4.2.8 Restricting the Number of Network Links You can specify the maximum number of network links that a Directory Service listener can have open simultaneously. In a VAXcluster, this limit applies to each node in a cluster, not to the total number of links in the whole cluster. When this maximum is reached, another listener process starts up to service the new link. When the Directory Service no longer needs more than one listener on a node, one of the listener processes is automatically deleted. You can specify any number of network links, up to a maximum of ten. The default is five simultaneous network links per Directory Service listener. 4.2.9 Running the Directory Service Maintenance Command Procedure The Directory Service maintenance command procedure, DDS$TIDY, performs regular housekeeping tasks for the Directory Service. For information about the tasks that DDS$TIDY performs, see the Message Router Management Guide. You can specify: o When the procedure is scheduled to run. The default is one o'clock in the morning. o The period within which the procedure can run. If the procedure starts after this period, it sends a mail message to the network management node saying that has started outside the time limit, and does not carry out any maintenance taasks. The default time is 300 minutes. o The days on which DDS$TIDY runs. The default is every day. o The batch queue where DDS$TIDY runs. The default is MB$BATCH. o The print queue that DDS$TIDY uses. The default is SYS$PRINT. 4-8 Planning a Customized Message Router System o How often DDS$TIDY carries out major housekeeping tasks. The default is once a week. o How often DDS$TIDY resets the Directory Service event counters. The default is once every 30 days. o How often DDS$TIDY purges the queues of old transactions. The default is once a week. o The time that a transaction can remain in the network queue before it is purged. The default is 60 days. o The time that a transaction can remain in the input queue before it is purged. The default is 60 days. o The time that the result of a transaction can remain in the output queue before it is purged. The default is 5 days. o The maximum size, in blocks, of the Directory Service log file, DDS$LOG.DAT. If you are running the exception reporting routines, when the file reaches this size, it is renamed to DDS$LOG_OLD.DAT and a new DDS$LOG.DAT file is automatically created. If you are running the exception reporting routines and DDS$TIDY, the exception reporting routines rename the file. If you are running DDS$TIDY but not the exception reporting routines, DDS$TIDY renames the files. 4.2.10 Running the Directory Service Deferred Update Command Procedure The Directory Service deferred update command procedure, DDS$DEFER, executes object updates that have been deferred. For more information about configuring the Directory Service to allow deferred updates, see Section 4.2.5. For more information about DDS$DEFER, see the Message Router Management Guide. You can specify: o When the procedure is scheduled to run. The default is one o'clock in the morning. o The period within which the procedure can run. If the procedure starts after this period, it sends a mail message to the network management node saying that has started outside the time limit, and does not execute any defered updates. The default time is 300 minutes. 4-9 Planning a Customized Message Router System o The days on which DDS$DEFER runs. The default is every day. o The batch queue where DDS$DEFER runs. The default is MB$BATCH. 4.2.11 Running the Directory Service Cache Refresh Command Procedure The Directory Service cache refresh command procedure refreshes the cache database. For more information about DDS$REFRESH, see the Message Router Management Guide. For more information about the cache database, see the Introduction to Message Router. You can specify: o When the procedure is scheduled to run. The default is one o'clock in the morning. o The period within which the procedure can run. If the procedure starts after this period, it sends a mail message to the network management node saying that has started outside the time limit, and does not refresh any cahce entries. The default time is 300 minutes. o The days on which DDS$REFRESH runs. The default is once a week. o The batch queue where DDS$REFRESH runs. The default is MB$BATCH. o The maximum number of entries refreshed each time DDS$REFRESH runs. The default is 0, which means there is no maximum, and all the entries that have expired are refreshed. Expiry times are set by the Directory Service. The expiry time for subscriber objects is 42 days. o The object types to be refreshed. The default is that all types of object are refreshed. 4.3 Configuring the Transfer Service You can configure the following options in the Transfer Service: 4-10 Planning a Customized Message Router System o The device used by the Transfer Service section of the MAILBUS directory structure o Whether you want to enable exception reporting on the Transfer Service, and if so, the alarm level of free blocks on the node o The maximum size for the Transfer Service error information file o Whether or not you use remote-commands messages to update Transfer Service databases remotely o Whether or not you want to run the Transfer Service maintenance command procedure, MR$TIDY, on your system and the characteristics of the procedure o The type of talker you want to use on your node, the number of talkers, and the talker characteristics o The number of message file areas used and the devices where they reside o The device where the mailbox directory resides o The device where the queue file resides o Which Transfer Service database to use on a cluster o The maximum number of Transfer Service images that can run at any one time on your node o The name of the queue for submitting Transfer Service batch jobs o The maximum hopcount for messages transferred by this node o Whether the Transfer Service renames and keeps rejected messages or deletes them o Whether service messages are sent interactively or are stored and sent in a batch when the mailboxes are purged o If you are using area routing, the area code o Whether or not the Transfer Service searches the system user authorization files for unrecognized recipient names 4-11 Planning a Customized Message Router System o Whether or not the Transfer Service journals messages originating or terminating at this node and, if so, the names of the journal mailboxes in the mailbox directory o Whether non-delivery notification messages are sent to the operator mailbox or the message sender and, if they are sent to the operator mailbox, the name of the operator mailbox in the mailbox directory o The class of broadcast to notify users of new mail o Whether or not selected error messages are broadcast to specified operators' consoles o Whether or not the Transfer Service logs, in the message transaction file, the status of each message it handles and whether such logging is essential for the Transfer Service to remain operating o The size of the message transaction file and how many message transaction files are kept after purging o The size of the message transaction file buffer and how many times the buffer size can be increased o The global values for active queue monitoring o If you are configuring a cluster, whether you are enabling cluster aliases o The time the DECnet NETSERVER process waits before it times out o The type of mailboxes that remote User Agents can access o Whether to enable the Transfer Service 4.3.1 Device for the Transfer Service You can change the device used by the Transfer Service subdirectory [MB$.MR] of the MAILBUS directory structure. It does not have to be the same device as the device that the Message Router kit is installed on. If you choose to change the device used by the Transfer Service, the whole directory structure is copied on to the device you specify. Most of the files in the Transfer Service subdirectory, [MB$.MR], and 4-12 Planning a Customized Message Router System its subdirectories, are moved to the new device. The files that are not moved are: o The mailbox directory o The queue file o The message file areas You must not delete the empty directory files created on the new device. 4.3.2 Exception Reporting for the Transfer Service The exception reporting routines monitor the Transfer Service for errors and unusual occurrences. If you specify that you want exception reporting for the Transfer Service, it is enabled when you use the MB$CONFIG ENABLE ER command. If you want exception reporting for the Transfer Service, you must specify the minimum number of free blocks on the device used by the Transfer Service. The exception reporting procedures check that this number of free blocks is available on all the devices used by the Transfer Service. The default number of free blocks is 10000. 4.3.3 Size of the Error Information File You can specify the maximum size of the Transfer Service error information file, MRERR.INF. When the error file reaches this size, a new version of the file is created. Previous versions of this file are purged by MR$TIDY. You should set the file size so that the file holds the error information for about seven days. If the file is too small, you lose information about recent errors; if the file is too large, it becomes difficult to examine. The default maximum size is 200. 4.3.4 Remote-commands Messages Remote-commands messages allow you to manage Transfer Services remotely. You can use these messages to make inquiries of other Transfer Service databases. If you know the relevant passwords, you can also update information in remote Transfer Service databases. Refer to the Message Router Management Reference Manual for details 4-13 Planning a Customized Message Router System about how to send remote-commands messages. When a Transfer Service receives a remote-commands message, a command procedure runs to obey the commands in the message and to return information to the inquiring Transfer Service. By default, MB$CONFIG allows you to use remote-commands messages and sets up the MRMAN mailbox in the mailbox directory. It also provides the default command procedure, MRMWRK.COM, which obeys the remote-commands messages received by the Transfer Service. Details of the MRMAN mailbox are given in the Message Router Management Reference Manual. If you do not want to run the default command procedure to process remote-commands messages, you can specify a different command procedure. 4.3.5 The Transfer Service Maintenance Command Procedure The Transfer Service maintenance command procedure, MR$TIDY, performs regular housekeeping tasks on the Transfer Service. For more information about the tasks performed by the MR$TIDY command procedure refer to the Message Router Management Guide. You can specify: o How often MR$TIDY performs its major housekeeping tasks. The default is once a week. o When the procedure is scheduled to run. The default is one o'clock in the morning. o The period within which the procedure can run. If the procedure starts after this period, it sends a mail message to the network management node saying that has started outside the time limit, and does not carry out any maintenance tasks. The default time is 300 minutes. o The days on which the procedure runs. The default is that MR$TIDY runs every day. o The batch queue used by the procedure. The default batch queue is MB$BATCH. o The print queue used by the procedure. The default print queue is SYS$PRINT. 4-14 Planning a Customized Message Router System 4.3.6 Talkers There are three different ways of running the talker: o You can submit it as a batch job submitted on a schedule. This type of talker is called a schedule talker. o You can run it as a detached process connected to a VMS mailbox. This type of talker is called a notify talker. o You can submit it as a batch job on demand. This type of talker is called a run talker. The Transfer Service offers a default of one notify talker per node and one notify talker for each node in a cluster. If you choose to run a notify talker, you must specify the following: o The name of the VMS mailbox. The default is MR$TALK_MBX. o The name of the Transfer Service nodes list to be used. The default is MR$:MR$NODES_DEF.DAT. o The maximum time that the talker waits to be notified. If the talker is not notified before this time expires, it polls the mailboxes to make sure there are no messages waiting to be processed. The default maximum wait is 30 minutes. o The maximum time that the talker can spend delivering messages to one node if there are messages waiting to be sent to other nodes. The default is 5 minutes. o The maximum number of messages that the talker can deliver to one node if there are messages waiting to be sent to other nodes. The default is 10. If you choose to run a schedule talker, the Transfer Service offers a default of one talker per node, or one talker for each node in a cluster. DIGITAL recommends that you use a notify talker instead of a schedule talker. You must specify the following: o The name of the Transfer Service nodes list served by the schedule talker. The default is MR$:MR$NODES_DEF.DAT. o How often the talker runs. The default is 30 minutes. o The maximum time that the talker can spend delivering messages to one node if there are messages waiting to be sent to other nodes. The default is 5 minutes. 4-15 Planning a Customized Message Router System o The maximum number of messages that the talker can deliver to one node if there are messages waiting to be sent to other nodes. The default is 10. o The batch queue for submitting the talker. The default is MB$BATCH. You can choose to run a talker as a batch job on demand, that is, a run talker. However, DIGITAL recommends that you use a notify talker instead of a run talker. If you choose to run a run talker, the Transfer Service offers a default of one talker per node, or one node for each node in a cluster. You must specify the following: o The name of the Transfer Service nodes list served by the run talker. The default is MR$:MR$NODES_DEF.DAT. o The resubmission interval for the talker batch job. If the run talker does not deliver all the messages that are waiting, it resubmits itself to the batch queue to run again. o The maximum time that the talker can spend delivering messages to one node if there are messages waiting to be sent to other nodes. The default is 5 minutes. o The maximum number of messages that the talker can deliver to one node if there are messages waiting to be sent to other nodes. The default is 10. o The batch queue for submitting the talker. The default is MB$BATCH. You can run more than one talker on a node. If you choose to run more than one talker per node in a cluster, you can specify a limit to the number of talkers running at any one time on the cluster. If you choose to run more than one talker on a node or cluster, all the talkers have the characteristics you specify at configuration. The configuration procedure sets all the talkers of the same type on a node or cluster to use the same Transfer Service nodes list. 4.3.7 Message File Areas The Transfer Service stores messages in message files. Message files are kept in message file areas that are defined by their directory specifications. You can specify the number of message file areas in 4-16 Planning a Customized Message Router System your Transfer Service and their devices. You can change the number of message file areas and their locations using the configuration procedure. Access to the message files is limited by the bandwidth of the disk, that is, the speed at which Read and Write operations can be carried out. Another limiting factor is that the VMS access time increases dramatically for directories of more than 1000 entries. Therefore, if you expect your system to hold a large number of messages at any time, as for a busy hub node in a network using area routing, choose more than two message file areas and place them on different disks. If you request n message file areas but do not specify the locations of the areas, the Transfer Service offers the device where Message Router is installed as the location for the message file areas. The names of the message file areas are: MSG1.DIR, MSG2.DIR through to MSGn.DIR. The default number of message file areas is 2. These message file areas are located, by default, on the device where you installed Message Router. The maximum number of message files areas you can have is ten. 4.3.8 The Mailbox Directory Location When you install Message Router, the mailbox directory, MRMDIRECT.DAT, is placed in its default location in the MAILBUS directory structure. You can use the configuration procedure to move the mailbox directory to another device. By default, the mailbox directory located on the device where you installed Message Router, in the [MB$.MR.DB] directory. 4.3.9 The Queue File Location When you install Message Router, the installation procedure places the queue file, MRMAILBOX.DAT, in its default location in the MAILBUS directory structure. You can use the configuration procedure to move the file to another device. By default, the queue file is on the device where you installed Message Router, in the [MB$.MR.DB] directory. 4-17 Planning a Customized Message Router System 4.3.10 Database Number If you are configuring a cluster, you can specify which Transfer Service database each node in the cluster uses. See Section 2.7 for more information about configuring clusters. 4.3.11 Transfer Service Images You can restrict the amount of message traffic that the Transfer Service handles by limiting the number of images that can run simultaneously on your system. The Transfer Service images are talkers, listeners, loggers, and the MRMAN utility. If you specify that you want to limit the number of Transfer Service images on your system, you can specify the limit. The default is that there is no limit to the number of Transfer Service images that can run simultaneously on the Message Router system. If you are configuring a node in a cluster, the limit you specify applies to the whole cluster, not to the particular node you are configuring. 4.3.12 Batch Queue The Transfer Service submits batch jobs to a batch queue when messages are delivered to mailbox entries that include the /RUN qualifier. For information about the /RUN qualifier on a mailbox entry, see the Message Router Management Reference Manual. These batch jobs are processes such as the run talker or the remote-commands process. You can specify the batch queue where the jobs are submitted. If you are configuring a cluster, there are some extra considerations that you must remember when you choose which batch queue Transfer Service batch jobs should use. See Section 4.3.28.3 for more information about specifying the batch queue to be used on a VAXcluster. The default queue is SYS$BATCH. 4.3.13 The Hopcount The hopcount allows the Transfer Service to detect addressing loops. 4-18 Planning a Customized Message Router System The hopcount on a message indicates the number of times that the message has been forwarded between Transfer Service nodes. It is increased by one every time the message is forwarded. You can specify the maximum hopcount for the messages handled by the Transfer Service on your node. If an incoming message has a hopcount that exceeds this maximum, and the recipient is not on your node, the Transfer Service rejects the message and generates a non-delivery notification message. The Transfer Service provides a default maximum hopcount of 5. Caution If the messages pass through a Gateway, the hopcount is lost, and therefore addressing loops through a Gateway are not detected. The performance of your mail system can be severely degraded if you specify different hopcounts on different nodes. Messages could appear to be lost, or non-delivery messages could themselves fail, if they are routed through a node with a low hopcount limit. 4.3.14 Handling Rejected Messages Corrupt messages cannot be forwarded by the Transfer Service and are rejected. The Transfer Service removes them from the top of the queues that they have blocked and forwards the next message in the queue. The rejected messages can be deleted after they have been removed from the blocked queues. However, you can specify that rejected messages are renamed and stored for examination. The rejected messages are renamed by appending _BAD to the file name (MRn.NBS_BAD). They are stored in the same directory as before they were renamed. By default, the Transfer Service renames rejected messages after they have been removed from the queues. 4.3.15 Returning Service Messages Service messages are usually returned to the message sender interactively. As soon as the success or failure of message delivery has been detected, the service message is created and returned to the 4-19 Planning a Customized Message Router System sender. If service messages are not returned interactively, you must run the MRMAN command PURGE */SERVICE regularly. If you run the Transfer Service maintenance procedure, MR$TIDY, service messages are returned automatically when the procedure runs. See Section 4.3.5 for information about running MR$TIDY. By default, service messages are returned interactively. 4.3.16 Area Code If you are using area routing in you network, you must specify the area code of the area where the node you are configuring resides. For more information about area routing and area codes, see Section 2.6.3. 4.3.17 Sending Messages to Unrecognized Recipients An unrecognized recipient is a term in an address that does not match an entry in the mailbox directory. When the Transfer Service receives a message, it checks its mailbox directory for a mailbox entry that matches the first term in the message address string. If there is more than one term in the message address, and the term is not matched, the unmatched address term is assumed to be a node. If default routing is enabled, the message is forwarded to the node. If default routing is not enabled, a non-delivery notification message is sent. If there is only one item in the address, that is, the message has reached its destination node, and the Transfer Service cannot find a matching mailbox entry, it generates a non-delivery notification message. However, you can instruct the Transfer Service to examine the system user authorization file, SYSUAF.DAT, for any unmatched message address terms at the destination node. The system user authorization file contains a list of all the VMS users on the system. If a match is found in this file, and there is an MRGATE mailbox on the node, the Transfer Service forwards the message to the Message Router VMSmail Gateway and the message is delivered by VMSmail to the relevant VMS account. The configuration procedure always offers you the option of sending mail to unrecognized recipients, even if you do not have a Message Router VMSmail Gateway on your node, because it cannot tell whether you have a Message Router VMSmail Gateway on another node in the network. 4-20 Planning a Customized Message Router System You must have a mailbox entry for the Gateway in the mailbox directory, so that the Transfer Service can send the message to the Message Router VMSmail Gateway. If the Gateway is on another node in your network, add a routing or replacement entry in the mailbox directory to route the message to the remote node, as described in the Message Router Management Reference Manual. When you install, or if you have already installed, the Gateway on your node, the Gateway configuration procedure automatically adds a local mailbox entry to the mailbox directory for the Gateway. The mailbox name is MRGATE. By default, the Transfer Service does not search the system user authorization file for unrecognized addresses. 4.3.18 Message Journaling The Transfer Service can journal messages on the node where they enter or leave Message Router. Messages journaled where they enter Message Router, that is, at their source, are stored in the source journal mailbox. Messages journaled where they leave Message Router, that is, at their destination, are stored in the destination journal mailbox. You need to write an Application to fetch the messages from the journal mailboxes, so this facility is useful only if you have the Message Router Programmer's Kit and write an Application to handle journaled messages. Refer to the Message Router Programming Guide for details on how to use the journal mailboxes. If you specify that the Transfer Service journals messages, you can also specify the names of the source and destination journal mailboxes. Alternatively, you can accept the default names of SRCJOURNAL and DESTJOURNAL for the source journal mailbox and destination journal mailbox, respectively. By default, the Transfer Service does not journal messages. 4.3.19 Destination of Non-delivery Notification Messages The Transfer Service generates a non-delivery notification message when it cannot forward a message, and normally sends it to the message sender. However, you can specify that the notification messages be sent to the operator mailbox for your node, so that when a message fails because of a typing error or the hopcount being exceeded, you can remedy the error in your area and the corrected message does not then have to re-trace its route. 4-21 Planning a Customized Message Router System If you specify that these messages should be sent to the operator, you must specify the name of the operator mailbox on your node. The operator mailbox entry can be a routing entry indicating a central point for all the nodes in your area or network, so that all non-delivery messages can be handled at one point. If you choose that messages should be sent to the operator mailbox, you must handle every non-delivery notification message that comes to the mailbox, correcting the error, or sending the message back to its sender. If, for some reason, the operator mailbox cannot be reached, the non-delivery message is sent to the sender of the message. If you specify that non-delivery messages are sent to the operator mailbox and do not specify a mailbox name, the Transfer Service supplies the default mailbox name of OPERATOR. By default, the Transfer Service sends non-delivery notification messages to the message sender. 4.3.20 Broadcasting Notification Messages to Users The Transfer Service can notify users that messages are waiting to be fetched. You specify whether or not users are notified of new mail by using the /BEEP qualifier in their mailbox entry in the mailbox directory (see the Message Router Management Reference Manual). You can also specify which broadcast class is used to notify the user. The broadcast classes recognized by the Transfer Service are: o GENERAL o MAIL o URGENT o USER1 to USER16 (Refer to the DCL SET BROADCAST command in the VAX/VMS DCL Dictionary for information about broadcast classes.) By default, the broadcast class is MAIL. 4-22 Planning a Customized Message Router System 4.3.21 Broadcasting Error Messages to Operators' Consoles The Transfer Service can broadcast selected error messages to the operators' consoles. These messages tell the operators that the Transfer Service on a remote node has rejected a message from the Transfer Service on a local node, or that the transaction file has stopped logging message traffic. The messages that can be broadcast to operators are described in the Message Router Management Reference Manual. The Transfer Service can broadcast these messages on the consoles of the central operator, the network operator, or a user-defined operator. There can be 16 user-defined operators, which correspond to the operator terminal types used by the VMS system service $SNDOPR (send-message-to-operator). For more information about $SNDOPR, see the VAX/VMS Systems Services Reference Manual. If you are running the exception reporting routines for the Transfer Service, the errors that cause these broadcast messages also cause exception report messages to be sent, so it is not necessary to broadcast the messages. If you are not running the exception reporting routines, you might still be able to use the information in the MAPs to recover from errors that are broadcast to the operator. By default, the Transfer Service broadcasts the error messages to the network operator's console. 4.3.22 Message Transaction File The message transaction file records the progress of each message through the Transfer Service (see the Message Router Management Reference Manual). You can specify whether or not messages are logged in the transaction file and whether or not such logging is essential. If logging is essential and for some reason fails, the Transfer Service stops handling messages. Alternatively, if logging is not essential and fails, the Transfer Service continues to handle messages but an error message is displayed on the operator's console and is recorded in the error information file. If you are running exception reporting, an exception report is generated. If you enable logging on a VAXcluster, each node in the cluster has its own transaction file. By default, transaction logging is enabled and is not essential. 4-23 Planning a Customized Message Router System NOTE If you have specified that logging is essential, the Transfer Service operates more efficiently if you set the maximum number of Transfer Service images to a specific value, that is, if you do not accept the default of an unrestricted number of images (see Section 4.3.11). 4.3.23 The Transaction File Size When a message transaction file reaches a certain size, the Transfer Service can create another one. This means that there can be several small files rather than one large one. A large number of these files, or one very large file, can cause maintenance problems. However, the Transfer Service can purge the message transaction files so that only a specified number of them are kept at any one time. You can specify the size, in blocks, that the file reaches before another is created, and you can specify how many of the files are kept after purging. By default, the Transfer Service limits the size of the message transaction file to 500 blocks and purges the files so that two are kept. 4.3.24 Message Transaction File Buffer When the Transfer Service performs an operation on a message, the transaction information is not immediately stored in the message transaction file. Instead, the information is initially stored in an internal buffer. The information is transferred to the file itself only when the message throughput is lower. This is so that the speed of transaction logging does not limit the speed of the Transfer Service. You can specify the maximum number of entries that can be stored in the internal buffer. A warning tells you when the number of entries in the buffer exceeds the specified number of entries. You can extend the size of the buffer so that it can hold a multiple of the specified maximum. For example, suppose you specified a maximum of 100 entries in the buffer and that the buffer can only be extended twice. The message traffic is so heavy that the 100 entries is exceeded. The Transfer 4-24 Planning a Customized Message Router System Service logger warns you that the number of entries has been exceeded but allows the buffer to be extended to hold 200 entries. Message traffic is still high and there are more than 200 entries. The Transfer Service logger again warns you that the buffer size has been exceeded but extends it by another 100 entries so that the maximum number of allowed entries is now 300. The chances of recovering from this situation are slim, but not impossible. Message traffic may have reduced sufficiently to allow information to be written to the transaction file. If so, the number of entries in the buffer decreases and the Transfer Service carries on. Alternatively, message traffic may still be high and therefore the new maximum of 300 entries is exceeded. The buffer cannot be extended further, because it has already been extended twice. If you have specified that logging message transactions is essential, and the buffer becomes full, the Transfer Service stops. Increase the maximum number of entries allowed in the buffer and restart the Transfer Service by using the MB$CONTROL procedure. Any data stored in the buffer is lost when the Transfer Service stops running. If you have not specified that logging message transactions is essential, logging stops but the Transfer Service continues to run. In this case, you can either stop the Transfer Service, using the MB$CONTROL procedure, in which case the information in the buffer is lost, or you can allow the Transfer Service to continue running. If you allow the Transfer Service to continue running, the information in the buffer will eventually be written into the transaction file. When this has happened, you can restart logging by restarting the Transfer Service. Heavy message traffic does not normally cause logging to be overloaded. Overloading is more likely to be caused by a problem with the logging process, or with the device where the transaction file resides. The specified maximum number of entries in the buffer cannot be less than 50. The default buffer size is 100 entries, with two extensions allowed. 4.3.25 Active Queue Monitoring When you add mailbox entries to the mailbox directory, you can specify how many messages can be in each queue (the queue limit) and how long they can stay there (the age limit). 4-25 Planning a Customized Message Router System If you are running MR$TIDY, when the number of messages in a queue reaches the queue limit, or a message is in the queue for longer than the age limit, MR$TIDY sends a VMSmail message warning you that there might be a problem with the queue. See Section 4.3.5 for more information about running MR$TIDY. If you are not running MR$TIDY, use the MRMAN CHECK_AQM command to monitor the queues. See the Message Router Management Reference Manual for more information about using the MRMAN CHECK_AQM command. The age limit and queue limit are not automatically enforced. Old messages are not deleted automatically and new messages on a full queue are not rejected. The configuration procedure allows you to set global values for every message queue. However, you can override these global restrictions by specifying values for individual mailboxes that handle different amounts of message traffic (use the /AGE_RESTRICTION and /QUEUE_RESTRICTION qualifiers on the mailbox entry). The individual restrictions take precedence over the global values. Specify the age value in the delta-time format, "dd hh:mm:ss", expressed in days, hours, minutes, and seconds. If you want an age limit and do not specify a value, the Transfer Service offers a value of two days. If you want to limit the number of messages in a message queue and do not specify a value, the Transfer Service offers a value of 20 messages. By default, the Transfer Service does not put a global restriction on the number of messages in a queue or on the length of time that the messages are in a queue. 4.3.26 NETSERVER Process Timeout The Transfer Service listeners are run either from DECnet or as shared images. Shared images are used by local User Agents and Gateways, while network listeners are used by remote User Agents or Transfer Service talkers. Any incoming network connection causes a DECnet NETSERVER process to start a Transfer Service listener. After the connection is broken, NETSERVER waits for a new connection and eventually times out. You can set this timeout period to reduce the CPU and elapsed time interval in making DECnet connections to the Transfer Service. 4-26 Planning a Customized Message Router System A suitable value for the NETSERVER process timeout is 15 minutes. A shorter timeout period means that few new connections can be made before the process dies. A longer timeout period means that, after a temporary period of high message traffic, a large number of processes are active on the system, which reduces the system performance. Also, you cannot read the last block of the listener log file, NETSERVER.LOG, while the NETSERVER process is still active. The timeout period must be specified in delta-time format, that is, "dd hh:mm:ss" expressed in days, hours, minutes, and seconds. By default, the Transfer Service offers a NETSERVER timeout of 15 minutes. 4.3.27 Mailboxes Accessed by Remote User Agents User Agents on the local node can connect to the Transfer Service and access privileged mailboxes, that is, mailboxes with the /SYSTEM qualifier (see the Message Router Management Reference Manual). You can specify whether or not User Agents on remote nodes can connect to the Transfer Service on your node and, if so, whether or not they can connect to privileged mailboxes. By default, remote User Agents can connect to the Transfer Service and access privileged mailboxes. If you want the network management node to monitor the exception reporting routines on the other nodes in your network, you must permit remote access to mailboxes. However, you do not need to allow remote access to privileged mailboxes for monitoring to take place. 4.3.28 Transfer Service Options on Clusters There are some extra options that you can configure on a cluster. 4.3.28.1 Cluster Aliasing A cluster alias is a single name that represents all the nodes in a VAXcluster or Local Area VAXcluster. If cluster aliasing is enabled, tell your users to use the name of the cluster rather than the node name to send mail. When receiving mail, connections from a node in a cluster are identified by the cluster name rather than the individual node name. 4-27 Planning a Customized Message Router System If you enable cluster aliasing during configuration, and you are using area or destination routing, you must add a neighbor node entry for the cluster and replace entries for the nodes in the Transfer Service mailbox directories that define the nodes as neighbor nodes. These entries ensure the Transfer Service recognizes both the nodename and the cluster name in the message address. The Message Router Reference Manual describes the entries that need to be made in the mailbox directory. If you have a homogeneous cluster that includes large and small machines, you can prevent any incoming connections to the cluster alias reaching the small machines. Do this by adding the following lines to the node-specific startup file, SYSTARTUP.COM, after the command that starts DECnet: $ RUN SYS$SYSTEM:NCP SET EXECUTOR ALIAS INCOMING DISABLED This affects all DECnet connections on the node, not only the Transfer Service connections. NOTE You must not enable cluster aliasing without the agreement of the other Message Router managers in your network. Cluster aliasing must be enabled on all nodes in the Transfer Service network, or none. You must not enable cluster aliasing if your network contains Message Router Version 2.0 or 2.1. The default is that cluster aliasing is not enabled. 4.3.28.2 The Transfer Service Database There can be more than one Transfer Service database on a VAXcluster. Nodes that have the same system user authorization file (SYSUAF.DAT) must share a common Transfer Service database. Nodes that have different system user authorization files can only share a Transfer Service database if these SYSUAF.DAT files are identical. A database that is shared must be accessible to all the nodes that use it. The default is that all nodes in a cluster use the same Transfer Service database. 4-28 Planning a Customized Message Router System 4.3.28.3 Batch Queues In a VAXcluster, there are extra factors that you must take into account when you choose the batch queue where a particular job runs. If you choose to run a job on a node-specific batch queue, you must make sure that running the job appropriate to the node. For example, you should not run MR$TIDY on a node that is not running the Transfer Service. If you choose to run a batch job on a cluster-wide (generic) batch queue, this queue must be accessible to all the nodes in the cluster. 4.4 Configuring Exception Reporting You can customize the following exception reporting options: o How often the exception reporting procedures run, and the maximum permitted interval between runs of the exception reporting procedures o Whether to monitor exception reporting throughout the network 4.4.1 VMSmail Address for Exception Reports The exception reports must be sent to a VMSmail address. The default destination is the MBMANAGER account on the network management node. Sending all the exception reports to this account has the following advantages: o All exception reports are sent to a single destination o The Message Router manager uses the MBMANAGER account to carry out many of the recovery procedures However, you might choose to send the exception reports to another destination for the following reasons: o Your network is managed in areas, and you want to send exception reports for each area to an area management node o Your network is large, and you want to send the exception reports to other accounts, where some of the recovery procedures can be carried out 4-29 Planning a Customized Message Router System NOTE When you configure the Management Service, MB$CONFIG asks you which account is to receive exception reports; this option is not part of the exception reporting configuration. 4.4.2 Frequency of Exception Reports You can specify how frequently the exception reporting routines run. The default is that they run every 30 minutes. You can also specify the maximum interval between runs of the exception reporting routines. If, for some reason, the exception reporting routines do not run on a remote node, the exception reporting routines on the network management node can detect this and send an exception report to the VMSmail address that you specified for exception reports (see Section 4.4.1). The default value for this interval is one hour and thirty minutes. 4.4.3 Monitoring Exception Reporting The network management node can monitor exception reporting on the other nodes in the network. 4.5 Configuration Checklist for the Management Service This section includes a checklist of all the decisions you must make before you configure the Management Service. Some of these decisions are network planning decisions, described in Chapter 2. Use this list to make sure that you have all the information that you need to configure the Management Service: o The device used by the Management Service o The name of the network management node o The VMS account where the exception reporting routines send exception reports 4-30 Planning a Customized Message Router System o The time zone correction needed if your network spans more than one time zone o Whether you want to change the passwords of any of the Message Router accounts, and if so, the new password 4.6 Configuration Checklist for the Transfer Service This section includes a checklist of all the decisions you must make before you configure the Transfer Service. Some of these decisions are network planning decisions, described in Chapter 2. Use this list to make sure that you have all the information that you need to configure the Transfer Service: o The device used by the Transfer Service o Whether you want to enable exception reporting for the Transfer Service o The alarm level of free blocks on the device used by the Transfer Service o The maximum size of the error information file o Whether you want to use remote-commands messages, and the name of the command procedure that runs when the node receives a remote-commands message o Whether you want to run the Transfer Service maintenance command procedure, and if so, how the procedure runs o How to use talkers on your node o The number of message file areas and the device on which they reside o The device you want to use for the mailbox directory o The device you want to use for the queue file o The maximum number of Transfer Service images o The name of the batch queue where /RUN batch jobs run 4-31 Planning a Customized Message Router System o The maximum hopcount to be allowed o How the Transfer handles rejected messages o How service messages are handled o The routing method used o If you are using area routing, the area code for the area in which the node resides o Whether the Transfer Service searches the system user authorization files for recipient names that it does not recognize o Whether the Transfer Service uses journal mailboxes, and the names of the journal mailboxes o How the Transfer Service handles non-delivery notification messages o The class of broadcast used to notify users of new mail o Whether to broadcast selected error messages to operators, and if so, to which operators o Whether the Transfer Service logs details of messages it handles o The size of the message transaction file, and how many messages are kept when the file is purged o The size of the internal logger buffer, and how many times the size can be increased o The global values for active queue monitoring o Whether to allow the Transfer Service to use cluster aliases o How long the DECnet NETSERVER process waits before it times out o The type of mailboxes that remote User Agents can access o Which nodes share the same Transfer Service database if you are running the Transfer Service on a VAXcluster 4-32 Planning a Customized Message Router System 4.7 Configuration Checklist for the Directory Service This section includes a checklist of all the decisions you must make before you configure the Directory Service. Some of these decisions are network planning decisions, described in Chapter 2. Use this list to make sure that you have all the information that you need to configure the Directory Service. o The device used by the Directory Service o If exception reporting will be enabled for the Directory Service o If you are running the exception reporting routines for the Directory Service, the alarm level of free blocks on the device used by the Directory Service o The name of the Directory Service master node o The location of the Directory Service files o The events that you want to count, log and broadcast to a specified operator console o Whether you want to defer update transactions, and if so, for which objects o Whether to broadcast selected error messages to operators, and if so, to which operators o The number of entries in the cache o The number of network links to a Directory Service listener o Whether you want to run the Directory Service maintenance procedure, and if so, how the procedure runs o The maximum size of the Directory Service event log file o Whether you want to run the Directory Service deferred update procedure, and if so, how the procedure runs o Whether you want to run the Directory Service cache refresh procedure, and if so, how the procedure runs 4-33 Planning a Customized Message Router System 4.8 Configuration Checklist for Exception Reporting This section includes a checklist of all the decisions you must make before you configure Exception Reporting. Some of these decisions are network planning decisions, described in Chapter 2. Use this list to make sure that you have all the information that you need to configure Exception Reporting. o How frequently the exception reporting routines run o The maximum time between runs of the exception reporting routines o If you want to monitor exception reporting throughout the network 4-34 Part II Default Configuration Chapter 5 Configuring a Default System 5.1 Configuring Your Network You must configure every node or VAXcluster in your network where Version 3.0 of Message Router is installed before you can use Message Router on that node or cluster. Use the MAILBUS configuration procedure, MB$CONFIG.COM, to configure your Message Router. If possible, use a hardcopy terminal to keep a record of the configuration. If you do not have a hardcopy terminal, you can make a file copy of the configuration using the command: $ SET HOST 0/LOG=filename where filename is the name of the file to contain the copy of the configuration. Make sure that DECnet is running before you start the configuration procedure. If you are not sure, ask your DECnet manager whether DECnet is running and, if it is not, to start it. If you are going to configure the Directory Service, and the node that you are configuring is not the Directory Service master node, make sure that the name of the node is in the Directory Service nodes list on the master node. Use the MBMAN SHOW DDS NODE command to see which nodes are in the Directory Service nodes list. See the Message Router Management Reference Manual for more information about this MBMAN command. If you are reconfiguring Message Router, make sure that Message Router is stopped. You must also stop any other MAILBUS components on your node. To stop MAILBUS, log in to the SYSTEM account and type: $ @SYS$MANAGER:MB$CONTROL STOP=(ER,DDS,TS,...) Include in this command the identifiers of any Gateways installed on 5-1 Configuring a Default System your node. 5.2 Starting the Configuration Procedure Log in to the SYSTEM account on the node that you want to configure. Run the configuration procedure: $ @SYS$MANAGER:MB$CONFIG If you are configuring the node for the first time, MB$CONFIG displays its prompt: MBC> If you have configured the node previously, MB$CONFIG announces itself, and displays the current date and time (dd-mmm-yyyy hh:mm:ss), a table of the MAILBUS components on the node and its prompt, for example: MAILBUS CONFIGURATION PROCEDURE Products currently defined in DEFAULT configuration database on dd-mmm-yyyy hh:mm:ss MR : MESSAGE ROUTER MS : MANAGEMENT SERVICE TS : TRANSFER SERVICE DDS : DIRECTORY SERVICE ER : EXCEPTION REPORTING A1 : ALL-IN-1 MBC> NOTE Message Router takes a few minutes to display the table of all the MAILBUS components on your system. The Message Router kit includes exception reporting routines for the ALL-IN-1 Electronic Messaging subsystem, so the A1 identifier is always displayed, even if ALL-IN-1 is not installed on your node. For details of how to configure exception reporting routines for the ALL-IN-1 Electronic Messaging subsystem, see the ALL-IN-1 Messaging Network Manager's Supplement. 5-2 Configuring a Default System If you are reconfiguring Message Router and you want to modify your existing database, instead of creating a new database, go to Section 5.3. Otherwise, use the CREATE command to create a configuration data file. If you are configuring Message Router only, type: MBC> CREATE MR If you are configuring Message Router and one or more Gateways, type: MBC> CREATE MB The procedure displays: %MB-I-MBC$CREATE, Creating new configuration data file * What type of configuration (default or customized) do you want [DEFAULT]? Press RETURN to accept the default answer. If you are configuring a VAXcluster, the procedure displays: * Is this configuration to apply to all nodes in the cluster [YES]? If you want this configuration to apply to every node in the cluster, press RETURN to accept the default answer. Otherwise, type NO and press RETURN. If you answer YES to this question, you do not need to configure the other nodes in the cluster, because they are configured automatically as you configure this node. If you answer NO, you must configure every node in the cluster separately. The procedure displays the following message, and the file specification of the configuration data file: %MB-I-MBC$CRECONFIG, Building configuration data file: 5.3 Configuring the Management Service Follow the instructions in this section if you want to configure the Management Service: 1 Type: MBC> SET MS 5-3 Configuring a Default System 2 MB$CONFIG displays: %MB-I-MBC$SET, Setting configuration parameters * What device do you want to use for the Management Service [instaldevice]? where instaldevice is the device where Message Router is installed. Type the name of the device and press RETURN, or press RETURN to accept the default device. If you change the device used by the Management Service, you must recover the Management Service before you recover any other MAILBUS components. 3 MB$CONFIG displays: * What is the name of the network management node [thisnode]? where thisnode is the name of the node where you are running the configuration procedure. Type the name of the network management node and press RETURN, or press RETURN to accept the default answer. 4 MB$CONFIG displays: * What is the difference between network time and local time [00:00]? If there is no difference between network time and local time, press RETURN. Otherwise, type in the time zone correction and press RETURN. If you change the time zone correction, you must recover the Management Service, and then recover the Directory Service and the Transfer Service. 5 MB$CONFIG displays: * Do you wish to modify the account passwords [N]? If you do not want to modify the account password, press RETURN. The configuration procedure continues at Section 5.4. Otherwise, type YES and press RETURN. 5-4 Configuring a Default System 6 MB$CONFIG displays: *What password do you want for the MBMANAGER account []? Type the password for the MBMANAGER account and press RETURN. 7 MB$CONFIG displays: Please confirm * What password do you want for the MBMANAGER account []? Type the password again, and press RETURN. If you chaneg the password of the MBMANAGER account, you must recover the Management Service, and then recover the Directory Service, Transfer Service, and Exception Reporting components of Message Router. 5.4 Configuring the Directory Service Follow the instructions in this section if you want to configure the Directory Service: 1 Type: MBC> SET DDS 2 MB$CONFIG displays: %MB-I-MBC$SET, Setting configuration parameters * What device do you want to use for the Directory Service [instaldevice]? where instaldevice is the name of the device where Message Router is installed. Type the name of the device that you want to use for the Directory Service and press RETURN, or press RETURN to accept the default. 3 MB$CONFIG displays: * What is the name of the DDS master node [thisnode]? 5-5 Configuring a Default System where thisnode is the name of the node you are configuring. If you are configuring the Directory Service master node, press RETURN. Otherwise, type the name of the master node and press RETURN. 5.5 Configuring the Transfer Service Follow the instructions in this section if you want to configure the Transfer Service: 1 Type: MBC> SET TS 2 MB$CONFIG displays: %MB-I-MBC$SET, Setting configuration parameters * What device do you want to use for the Transfer Service [instaldevice]? where instaldevice is the device where Message Router is installed. Type in the name of the device that you want to use for the Transfer Service and press RETURN, or press RETURN to accept the default. 5.6 Configuring Other MAILBUS Components You can configure other MAILBUS products, such as Gateways, at the same time as you configure Message Router. See the relevant Management Guide for information about configuring other products. 5.7 Completing the Configuration To complete the configuration, you must enable the components that you want to run, using the ENABLE command, and then build the working files and databases that these components use, using the RECOVER command. 5-6 Configuring a Default System The order in which you recover some MAILBUS components is important: o Always recover the Management Service before you recover any other Message Router components o If you are recovering both the Transfer Service and Exception Reporting components of Message Router, recover the Transfer Service before Exception Reporting If you are not sure in which order to recover the Management Service components you have configured, recover Management Service first, and Excepting Reporting last. The order of recovery of the other components does not matter. If you want to enable the Management Service, type: MBC> ENABLE MS MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE MS MB$CONFIG displays: %MB-I-MBC$DISABLE, Disabling messaging process NOTE If you do not enable, recover, and start the Management Service on a node, you cannot run any MAILBUS components on that node. If you want to enable the Directory Service, type: MBC> ENABLE DDS MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE DDS MB$CONFIG displays: 5-7 Configuring a Default System %MB-I-MBC$DISABLE, Disabling messaging process If you want to enable the Transfer Service, type: MBC> ENABLE TS MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE TS MB$CONFIG displays: %MB-I-MBC$DISABLE, Disabling messaging process If you want to enable the exception reporting routines for any components of MAILBUS, type: MBC> ENABLE ER MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE ER MB$CONFIG displays: %MB-I-MBC$DISABLE, Disabling messaging process If you configured any Gateways, enable the Gateways by typing: MBC> ENABLE gateway-id where gateway-id is the identifier of the Gateway, for example, MRG for the Message Router VMSmail Gateway. For each Gateway that you enable, MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process If you enabled the Management Service, type: MBC> RECOVER MS MB$CONFIG displays: 5-8 Configuring a Default System %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-MBC$REPLETE, Configuration database recovery complete If you enabled the Directory Service, type: MBC> RECOVER DDS MB$CONTROL displays: %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-CREDDSCNF, creating configuration file for DDS .. %MB-I-DDSDBUPD, updating DDS database .. %MB-I-DDSTMPL, loading DDS template .. %MB-I-UPDNCPOBJ, updating NCP object for DDS .. %MB-I-UPDXRPTENBF, updating DDS Exception Reporting enable flag %MB-I-MBC$REPLETE, Configuration database recovery complete NOTE You cannot recover the Directory Service if the master node is not reachable, or the Directory Service is not running on the master node. If you enabled the Transfer Service, type: MBC> RECOVER TS MB$CONFIG displays: %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-CREMRINI, creating initialization file for TS .. %MB-I-UPDMRDIRMBX, updating mbx directory database for TS .. %MB-I-UPDXRPTENBF, updating TS Exception Reporting enable flag %MB-I-MBC$REPLETE, Configuration database recovery complete If you enabled exception reporting, type: MBC> RECOVER ER MB$CONFIG displays: %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-UPDMRGMBX, Updating TS mbx directory database for Exception Reporting.. %MB-I-UPDXRPTZONE, updating network Exception Reporting zone flag %MB-I-UPDXRPTENBF, updating network Exception Reporting enable flag %MB-I-MBC$REPLETE, Configuration database recovery complete You must also recover any Gateways that you enabled. Type: 5-9 Configuring a Default System MBC> RECOVER gateway-id where gateway-id is the identifier of the Gateway you are recovering. MB$CONFIG displays messages as it recovers the Gateway. When you have finished configuring all the components on your node, exit from the configuration procedure: MBC> EXIT 5.8 Running the Configuration Verification Procedures The configuration verification procedure (CVP) provided for each component of Message Router verifies that the component is configured successfully. You are recommended to run the CVP for a component every time you configure or reconfigure that component. If possible, use a hardcopy terminal to keep a record of the CVP output. If you do not have a hardcopy terminal, you can make a file copy, as described in Section 5.1. 5.8.1 Running the Management Service Configuration Verification Procedure Log in to the SYSTEM account and type: $ @SYS$TEST:MB$MSCVP Section 5.8.1.1 contains a listing of a successful CVP. If the CVP runs successfully, the Management Service is ready to use. If it is not successful, reconfigure the Management Service. If the CVP is still unsuccessful, contact: o Your Customer Support Center, if you have a Basic or DECsupport contract o Your local DIGITAL office to arrange for a service contract, if you do not have a Basic or DECsupport contract 5-10 Configuring a Default System 5.8.1.1 Management Service CVP Output $ @SYS$TEST:MB$MSCVP ================================================================== MANAGEMENT SERVICE V3.0-042 CVP This is the configuration verification procedure (CVP) for Management Service. It tests whether or not the Management Service is successfully configured on your system. The procedure checks that the Management Services files exist and that they are the correct size. ------------------------------------------------------------------ Management Service V3.0-042 file check The total number of files is 71. All files exist and are the correct size. End of Management Service V3.0-042 file check. ------------------------------------------------------------------ The Management Service V3.0-042 CVP was successful END OF MS V3.0-042 CVP 5.8.2 Running the Directory Service Configuration Verification Procedure Log in to the SYSTEM account and type: $ @SYS$TEST:MB$DDSCVP Section 5.8.2.1 contains a listing of a successful CVP. If the CVP runs successfully, the Directory Service on the node is ready to use. If it is not successful, reconfigure the Directory Service. If the CVP is still unsuccessful, contact: o Your Customer Support Center, if you have a Basic or DECsupport contract o Your local DIGITAL office to arrange for a service contract, if you do not have a Basic or DECsupport contract 5-11 Configuring a Default System 5.8.2.1 Directory Service CVP Output $ @SYS$TEST:MB$DDSCVP ================================================================== DIRECTORY SERVICE V3.0-042 CVP This is the configuration verification procedure (CVP) for the Directory Service. It tests whether or not the Directory Service is successfully configured on your system. The procedure completes the following steps: 1. Checks that the Directory Service files exist and that they are the correct size 2. Retrieves preset entries from the database ------------------------------------------------------------------ Directory Service V3.0-042 file check The total number of files is 7. All files exist and are the correct size. End of Directory Service V3.0-042 file check. ------------------------------------------------------------------ Starting the MBMAN utility Starting the Directory Service The Directory Service V3.0-042 CVP was successful END OF DDS V3.0-042 CVP Shutting down Directory Service Shutting MRMAN and MBMAN 5.8.3 Running the Transfer Service Configuration Verification Procedure Log in to the SYSTEM account and type: $ @SYS$TEST:MB$TSCVP 5-12 Configuring a Default System Section 5.8.3.1 contains a listing of a successful CVP. If the CVP runs successfully, the Transfer Service on the node is ready to use. If it is not successful, reconfigure the Transfer Service. If the CVP is still unsuccessful, contact: o Your Customer Support Center, if you have a Basic or DECsupport contract o Your local DIGITAL office to arrange for a service contract, if you do not have a Basic or DECsupport contract 5.8.3.1 Transfer Service CVP Output $ @SYS$TEST:MB$TSCVP ------------------------------------------------------------------ TRANSFER SERVICE V3.0-042 CVP This is the configuration verification procedure (CVP) for the Transfer Service. It tests whether or not the Transfer Service is successfully configured on your system. The procedure starts by checking that all the files for the Transfer Service exist and are the correct size. It then starts DECnet and MRMAN if necessary. The verification procedure creates a test mailbox, using the MRMAN utility, and sends a test message to the mailbox. The verification procedure fetches the test message from the mailbox and displays it, and then shuts down DECnet and MRMAN. The CVP has not completed successfully until you have received this test message. ------------------------------------------------------------------ Transfer Service V3.0-042 file check The total number of files is 27. All files exist and are the correct size. End of Transfer Service V3.0-042 file check. ------------------------------------------------------------------ This is MRMAN BL7.18 Starting Transfer Service This is MRMAN BL7.18 %Added MB$TSCVP, 5-13 Configuring a Default System This is MRMAN BL7.18 %Using mailbox MB$TSCVP at node ORANGE % Message from: MB$TSCVP % Subject: TEST ************************************************** Output of this test message indicates that the Transfer Service V3.0-042 is configured successfully on your system. ************************************************** %Finished reading from mailbox MB$TSCVP %Directory entry MB$TSCVP deleted Shutting down the Transfer Service Shutting down Management Service The Transfer Service V3.0-042 CVP was successful END OF TS V3.0-042 CVP 5-14 Chapter 6 Post-configuration Tasks for a Default System 6.1 Tasks for the Directory Service Master Node Carry out the following tasks when you have configured the Directory Service master node: 1 Log in to the SYSTEM account and start the Directory Service by typing: $ @SYS$MANAGER:MB$CONTROL START=DDS 2 Add the names of all the nodes in the Directory Service network to the Directory Service nodes list, using the MBMAN utility. You cannot configure the Directory Service on a node, other than the master node, until the name of the node is in the Directory Service nodes list. Log in to the MBMANAGER account and run the MBMAN utility: a Type: $ RUN SYS$SYSTEM:MBMAN b If the Directory Service master node is to be a world search node, modify its entry in the nodes list: MBMAN> MODIFY DDS NODE masternode /WORLD where masternode is the name of the Directory Service master node. c Add the names of the world search nodes to the nodes list: 6-1 Post-configuration Tasks for a Default System MBMAN> ADD DDS NODE node /WORLD /NUMBER=number where node is the name of the world search node you are adding to the list, and number is the number of the node. See the Message Router Management Reference Manual for information about assigning node numbers to nodes. d Add the names of all the other nodes in your network to the nodes list: MBMAN> ADD DDS NODE node /NUMBER=number where node is the name of the node you are adding to the list, and number is the number of the node. See the Message Router Management Reference Manual for information about assigning node numbers to nodes. e When you have added the names of all the nodes, exit from MBMAN: MBMAN> EXIT 3 Carry out the tasks described in Section 6.3. 6.2 Tasks for the Network Management Node Carry out the following tasks on the network management node: 1 Use the MBMAN utility to set up the list of nodes to be monitored by the exception reporting routines. Log in to the MBMANAGER account and run the MBMAN utility: a Type: $ RUN SYS$SYSTEM:MBMAN b Add the names of the nodes to be monitored using the following command: MBMAN> ADD ER NODE node where node is the name of the node you are adding to the list. 6-2 Post-configuration Tasks for a Default System c When you have added all the nodes, exit from MBMAN: MBMAN> EXIT 2 Carry out the tasks described in Section 6.3. 6.3 Tasks for Every Node After you have configured Message Router on a node, you must carry out the following tasks: 1 Edit the site-specific start-up procedure, SYSTARTUP.COM, to start Message Router when the node is booted. Include the following line: $ @SYS$MANAGER:MB$CONTROL SYSTART=(MS,DDS,TS,...,ER) If the node is part of a cluster, you can either put this command in the cluster-wide start-up procedure, or in the node-specific start-up procedures on every node in the cluster. Make sure that Message Router is started on every node in the cluster where Message Router runs. NOTE You must not include the equivalent MB$CONTROL STOP command in the system shutdown file, SYS$SYSTEM:SHUTDOWN.COM. 2 When the entire network is configured, and the initial tasks on the network management node are completed, start Message Router using the MAILBUS control procedure, MB$CONTROL. Log in to the SYSTEM account and type: $ @SYS$MANAGER:MB$CONTROL START=(MS,DDS,TS,...,ER) If the system displays any warning messages as Message Router starts, make sure that you have set the system quotas to sufficiently high values, as described in the Message Router Installation Guide. 6-3 Part III Customized Configuration Chapter 7 Configuring a Customized System 7.1 Configuring Your Network You must configure a node or VAXcluster in your network where Version 3.0 of Message Router is installed before you can use Message Router on that node or cluster. Use the MAILBUS configuration procedure, MB$CONFIG.COM, to configure your Message Router. If possible, use a hardcopy terminal to keep a record of the configuration. If you do not have a hardcopy terminal, you can make a file copy of the configuration using the command: $ SET HOST 0/LOG=filename where filename is the name of the file to contain the copy of the configuration. Make sure that DECnet is running before you start the configuration procedure. If you are not sure, ask your DECnet manager whether DECnet is running and, if it is not, to start it. If you are going to configure the Directory Service, and the node that you are configuring is not the Directory Service master node, make sure that the name of the node is in the Directory Service nodes list on the master node. Use the MBMAN SHOW DDS NODE command to see which nodes are in the Directory Service nodes list. See the Message Router Management Reference Manual for more information about this MBMAN command. If you are reconfiguring Message Router, make sure that Message Router is stopped. You must also stop any other MAILBUS components on your node. To stop MAILBUS, log in to the SYSTEM account and type: $ @SYS$MANAGER:MB$CONTROL STOP=(ER,DDS,TS,...) Include in this command the identifiers of any Gateways installed on 7-1 Configuring a Customized System your node. 7.2 Starting the Configuration Procedure Log in to the SYSTEM account on the node that you want to configure. Run the configuration procedure: $ @SYS$MANAGER:MB$CONFIG If you are configuring the node for the first time, MB$CONFIG displays its prompt: MBC> If you have configured the node previously, MB$CONFIG announces itself, and displays the current date and time (dd-mmm-yyyy hh:mm:ss), a table of the MAILBUS components on the node and its prompt, for example: MAILBUS CONFIGURATION PROCEDURE Products currently defined in DEFAULT configuration database on dd-mmm-yyyy hh:mm:ss MR : MESSAGE ROUTER MS : MANAGEMENT SERVICE TS : TRANSFER SERVICE DDS : DIRECTORY SERVICE ER : EXCEPTION REPORTING A1 : ALL-IN-1 MBC> NOTE Message Router takes a few minutes to display the table of all the MAILBUS components on your system. The Message Router kit includes exception reporting routines for the ALL-IN-1 Electronic Messaging subsystem, so the A1 identifier is always displayed, even if ALL-IN-1 is not installed on your node. For details of how to configure exception reporting routines for the ALL-IN-1 Electronic Messaging subsystem, see the ALL-IN-1 Messaging Network Manager's Supplement. 7-2 Configuring a Customized System If you are reconfiguring Message Router and you want to modify your existing database, instead of creating a new database, go to Section 7.3. Otherwise, use the CREATE command to create a configuration data file. If you are configuring Message Router only, type: MBC> CREATE MR If you are configuring Message Router and one or more Gateways, type: MBC> CREATE MB The procedure displays: %MB-I-MBC$CREATE, Creating new configuration data file * What type of configuration (default or customized) do you want [DEFAULT]? Type CUSTOMIZED and press RETURN. If you are configuring a VAXcluster, the procedure displays: * Is this configuration to apply to all nodes in the cluster [YES]? If you want this configuration to apply to every node in the cluster, press RETURN to accept the default answer of YES. Otherwise, answer NO and press RETURN. If you answer YES to this question, you do not need to configure the other nodes in the cluster, because they are configured automatically as you configure this node. If you answer NO, you must configure every node in the cluster separately. 7.3 Configuring the Management Service Follow the instructions in this section if you want to configure the Management Service: MBC> SET MS MB$CONFIG displays: %MB-I-MBC$SET, Setting configuration parameters The procedure then asks you for the information it requires to configure the Management Service. For a list of the questions asked, see Section C.2. Answer these questions according to the decisions 7-3 Configuring a Customized System you made when reading Part I of this book. If you configure the Management Service to use a different disk, you must recover the Management Service before you recover any other MAILBUS components. If you change the time zone correction, you must recover the Management Service, and then recover the Directory Service and Transfer Service components of Message Router. If you change the passwords of any of the Message Router accounts, you must recover the Management Service, and then recover the Directory Service, Transfer Service, and exception reporting components of Message Router. 7.4 Configuring the Directory Service Follow the instructions in this section if you want to configure the Directory Service: MBC> SET DDS MB$CONFIG displays: %MB-I-MBC$SET, Setting configuration parameters The procedure then asks you for the information it requires to configure the Directory Service. For a list of the questions asked, see Section C.3. Answer these questions according to the decisions you made when reading Part I of this book. 7.5 Configuring the Transfer Service Follow the instructions in this section if you want to configure the Transfer Service: MBC> SET TS The procedure displays: %MB-I-MBC$SET, Setting configuration parameters The procedure then asks you for the information it requires to configure the Transfer Service. For a list of the questions asked, see Section C.4. Answer these questions according to the decisions you made when reading Part I of this book. 7-4 Configuring a Customized System 7.6 Configuring Exception Reporting Follow the instructions in this section if you want to configure the exception reporting routines: MBC> SET ER MB$CONFIG displays: %MB-I-MBC$SET, Setting configuration parameters The procedure then asks you for the information it requires to configure exception reporting. For a list of the questions asked, see Section C.5. Answer these questions according to the decisions you made when reading Part I of this book. 7.7 Configuring Other MAILBUS Components You can configure other MAILBUS products at the same time as you configure Message Router. See the relevant Management Guide for information about configuring these products. 7.8 Completing the Configuration To complete the configuration, you must enable the components that you want to run, using the ENABLE command, and then build the working files and databases that these components use, using the RECOVER command. The order in which you recover some MAILBUS components is important: o Always recover the Management Service before you recover any other Message Router components o If you are recovering both the Transfer Service and Exception Reporting components of Message Router, recover the Transfer Service before Exception Reporting If you are not sure in which order to recover the Management Service components you have configured, recover Management Service first, and Excepting Reporting last. The order of recovery of the other components does not matter. If you want to enable the Management Service, type: MBC> ENABLE MS 7-5 Configuring a Customized System MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE MS MB$CONFIG displays: %MB-I-MBC$DISABLE, Disabling messaging process NOTE If you do not enable, recover, and start the Management Service on a node, you cannot run any MAILBUS components on that node. If you want to enable the Directory Service, type: MBC> ENABLE DDS MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE DDS MB$CONFIG displays: %MB-I-MBC$DISABLE, Disabling messaging process If you want to enable the Transfer Service, type: MBC> ENABLE TS MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE TS MB$CONFIG displays: %MB-I-MBC$DISABLE, Disabling messaging process 7-6 Configuring a Customized System If you want to enable the exception reporting routines for any components of MAILBUS, type: MBC> ENABLE ER MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process Otherwise, type: MBC> DISABLE ER MB$CONFIG displays: %MB-I-MBC$DISABLE, Disabling messaging process If you configured any Gateways, enable the Gateways by typing: MBC> ENABLE gateway-id where gateway-id is the identifier of the Gateway, for example, MRG for the Message Router VMSmail Gateway. For each Gateway that you enable, MB$CONFIG displays: %MB-I-MBC$ENABLE, Enabling messaging process If you enabled the Management Service, type: MBC> RECOVER MS MB$CONFIG displays: %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-MBC$REPLETE, Configuration database recovery complete If you enabled the Directory Service, type: MBC> RECOVER DDS MB$CONTROL displays: %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-CREDDSCNF, creating configuration file for DDS .. %MB-I-DDSDBUPD, updating DDS database .. %MB-I-DDSTMPL, loading DDS template .. %MB-I-UPDNCPOBJ, updating NCP object for DDS .. %MB-I-UPDXRPTENBF, updating DDS Exception Reporting enable flag %MB-I-MBC$REPLETE, Configuration database recovery complete 7-7 Configuring a Customized System NOTE You cannot recover the Directory Service if the master node is not reachable, or the Directory Service is not running on the master node. If you enabled the Transfer Service, type: MBC> RECOVER TS MB$CONFIG displays: %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-CREMRINI, creating initialization file for TS .. %MB-I-UPDMRDIRMBX, updating mbx directory database for TS .. %MB-I-UPDXRPTENBF, updating TS Exception Reporting enable flag %MB-I-MBC$REPLETE, Configuration database recovery complete If you enabled exception reporting, type: MBC> RECOVER ER MB$CONFIG displays: %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-UPDMRGMBX, Updating TS mbx directory database for Exception Reporting.. %MB-I-UPDXRPTZONE, updating network Exception Reporting zone flag %MB-I-UPDXRPTENBF, updating network Exception Reporting enable flag %MB-I-MBC$REPLETE, Configuration database recovery complete You must also recover any Gateways that you enabled. Type: MBC> RECOVER gateway-id where gateway-id is the identifier of the Gateway you are recovering. MB$CONFIG displays messages as it recovers the Gateway. When you have finished configuring all the components on your node, exit from the configuration procedure: MBC> EXIT 7.9 Running the Configuration Verification Procedures The configuration verification procedure (CVP) provided for each component of Message Router verifies that the component is configured 7-8 Configuring a Customized System successfully. You are recommended to run the CVP for a component every time you configure or reconfigure that component. If possible, use a hardcopy terminal to keep a record of the CVP output. If you do not have a hardcopy terminal, you can make a file copy, as described in Section 7.1. 7.9.1 Running the Management Service Configuration Verification Procedure Log in to the SYSTEM account and type: $ @SYS$TEST:MB$MSCVP Section 7.9.1.1 contains a listing of a successful CVP. If the CVP runs successfully, the Management Service on the node is ready to use. If it is not successful, reconfigure the Management Service. If the CVP is still unsuccessful, contact: o Your Customer Support Center, if you have a Basic or DECsupport contract o Your local DIGITAL office to arrange for a service contract, if you do not have a Basic or DECsupport contract 7.9.1.1 Management Service CVP Output $ @SYS$TEST:MB$MSCVP ================================================================== MANAGEMENT SERVICE V3.0-042 CVP This is the configuration verification procedure (CVP) for Management Service. It tests whether or not the Management Service is successfully configured on your system. The procedure checks that the Management Services files exist and that they are the correct size. ------------------------------------------------------------------ Management Service V3.0-042 file check The total number of files is 71. All files exist and are the correct size. 7-9 Configuring a Customized System End of Management Service V3.0-042 file check. ------------------------------------------------------------------ The Management Service V3.0-042 CVP was successful END OF MS V3.0-042 CVP 7.9.2 Running the Directory Service Configuration Verification Procedure Log in to the SYSTEM account and type: $ @SYS$TEST:MB$DDSCVP Section 7.9.2.1 contains a listing of a successful CVP. If the CVP runs successfully, the Directory Service on the node is ready to use. If it is not successful, reconfigure the Directory Service. If the CVP is still unsuccessful, contact: o Your Customer Support Center, if you have a Basic or DECsupport contract o Your local DIGITAL office to arrange for a service contract, if you do not have a Basic or DECsupport contract 7.9.2.1 Directory Service CVP Output $ @SYS$TEST:MB$DDSCVP ================================================================== DIRECTORY SERVICE V3.0-042 CVP This is the configuration verification procedure (CVP) for the Directory Service. It tests whether or not the Directory Service is successfully configured on your system. The procedure completes the following steps: 1. Checks that the Directory Service files exist and that they are the correct size 2. Retrieves preset entries from the database ------------------------------------------------------------------ Directory Service V3.0-042 file check 7-10 Configuring a Customized System The total number of files is 7. All files exist and are the correct size. End of Directory Service V3.0-042 file check. ------------------------------------------------------------------ Starting the MBMAN utility Starting the Directory Service The Directory Service V3.0-042 CVP was successful END OF DDS V3.0-042 CVP Shutting down Directory Service Shutting MRMAN and MBMAN 7.9.3 Running the Transfer Service Configuration Verification Procedure Log in to the SYSTEM account and type: $ @SYS$TEST:MB$TSCVP Section 7.9.3.1 contains a listing of a successful CVP. If the CVP runs successfully, the Transfer Service on the node is ready to use. If it is not successful, reconfigure the Transfer Service. If the CVP is still unsuccessful, contact: o Your Customer Support Center, if you have a Basic or DECsupport contract o Your local DIGITAL office to arrange for a service contract, if you do not have a Basic or DECsupport contract 7.9.3.1 Transfer Service CVP Output $ @SYS$TEST:MB$TSCVP ------------------------------------------------------------------ 7-11 Configuring a Customized System TRANSFER SERVICE V3.0-042 CVP This is the configuration verification procedure (CVP) for the Transfer Service. It tests whether or not the Transfer Service is successfully configured on your system. The procedure starts by checking that all the files for the Transfer Service exist and are the correct size. It then starts DECnet and MRMAN if necessary. The verification procedure creates a test mailbox, using the MRMAN utility, and sends a test message to the mailbox. The verification procedure fetches the test message from the mailbox and displays it, and then shuts down DECnet and MRMAN. The CVP has not completed successfully until you have received this test message. ------------------------------------------------------------------ Transfer Service V3.0-042 file check The total number of files is 27. All files exist and are the correct size. End of Transfer Service V3.0-042 file check. ------------------------------------------------------------------ This is MRMAN BL7.18 Starting Transfer Service This is MRMAN BL7.18 %Added MB$TSCVP, This is MRMAN BL7.18 %Using mailbox MB$TSCVP at node ORANGE % Message from: MB$TSCVP % Subject: TEST ************************************************** Output of this test message indicates that the Transfer Service V3.0-042 is configured successfully on your system. ************************************************** %Finished reading from mailbox MB$TSCVP %Directory entry MB$TSCVP deleted Shutting down the Transfer Service Shutting down Management Service 7-12 Configuring a Customized System The Transfer Service V3.0-042 CVP was successful END OF TS V3.0-042 CVP 7-13 Chapter 8 Post-configuration Tasks for a Customized System 8.1 Tasks for the Directory Service Master Node Carry out the following tasks when you have configured the Directory Service master node: 1 Log in to the SYSTEM account on the master node and start the Directory Service by typing: $ @SYS$MANAGER:MB$CONTROL START=DDS 2 Add the names of all the nodes in the Directory Service network to the Directory Service nodes list, using the MBMAN utility. You cannot configure the Directory Service on a node, other than the master node, until the name of the node is in the Directory Service nodes list. Log in to the MBMANAGER account and run the MBMAN utility: a Type: $ RUN SYS$SYSTEM:MBMAN b If the Directory Service master node is to be a world search node, modify its entry in the nodes list: MBMAN> MODIFY DDS NODE masternode /WORLD where masternode is the name of the Directory Service master node. 8-1 Post-configuration Tasks for a Customized System c Add the names of the world search nodes to the nodes list: MBMAN> ADD DDS NODE node /WORLD /NUMBER=number where node is the name of the node you are adding to the list, and number is the number of the node. See the Message Router Management Reference Manual for information about assigning node numbers to nodes. d Add the names of all the other nodes in your network to the nodes list: MBMAN> ADD DDS NODE node /NUMBER=number where node is the name of the world search node you are adding to the list, and number is the number of the node. See the Message Router Management Reference Manual for information about assigning node numbers to nodes. e When you have added the names of all the nodes, exit from MBMAN: MBMAN> EXIT 3 Carry out the tasks described in Section 6.3. 8.2 Tasks for the Network Management Node Carry out the following tasks on the network management node: 1 Use the MBMAN utility to set up the list of nodes to be monitored by the exception reporting routines. Log in to the MBMANAGER account and run the MBMAN utility: a Type: $ RUN SYS$SYSTEM:MBMAN b Add the names of the nodes to be monitored using the following command: 8-2 Post-configuration Tasks for a Customized System MBMAN> ADD ER NODE node where node is the name of the node you are adding to the list. c When you have added all the nodes, exit from MBMAN: MBMAN> EXIT 2 Carry out the tasks described in Section 8.3 8.3 Tasks for Every Node After you have configured Message Router on a node, you must carry out the following tasks: 1 Edit the site-specific start-up procedure to start Message Router when the node is booted. Include the following line: $ @SYS$MANAGER:MB$CONTROL SYSTART=(MS,DDS,TS,...,ER) Make sure that this line is included after the DECnet start-up commands. If the node is part of a cluster, you can either put this command in the cluster-wide start-up procedure, or in the node-specific start-up procedures on every node in the cluster that runs Message Router. Make sure Message Router is started on every node in the cluster where Message Router runs. NOTE You must not include the equivalent MB$CONTROL STOP command in the system shutdown file, SYS$SYSTEM:SHUTDOWN.COM. 2 When the entire network is configured, and the initial tasks on the network management node are completed, start Message Router on the remaining nodes using the MAILBUS control procedure, MB$CONTROL. Log in to the SYSTEM account and type: $ @SYS$MANAGER:MB$CONTROL START=(MS,DDS,TS,...,ER) 8-3 Post-configuration Tasks for a Customized System If the system displays any warning messages as Message Router starts, make sure that you have set the system quotas to sufficiently high values, as described in the Message Router Installation Guide. If you have chosen either destination or area routing as the routing method on your system (see Section 2.6), you must add routing entries to the Transfer Service mailbox directory and make node entries in the Transfer Service nodes list. The Message Router Management Reference Manual describes how to add routing entries to the mailbox directory. The Transfer Service nodes list is located in the [MB$.MR.WRK] directory. To add nodes to the Transfer Service nodes list: 1 Create a new nodes list with a different name 2 Add the entries from MR$NODES_DEF.DAT to the new nodes list 3 Add the other node entries that you need 4 Configure the Transfer Service and specify the name of the new nodes list In this way, your new nodes list will not be overwritten when you next install the Transfer Service. 8-4 Appendix A Example Default Configuration This appendix contains an example of running the configuration procedure to set up a default configuration on a node: $ @sys$manager:mb$config MBC> create mr %MB-I-MBC$CREATE, Creating new configuration data file * What type of configuration (default or customized) do you want [DEFAULT] ? * Is this configuration to apply to all nodes on the cluster [Y] ? %MB-I-MBC$CRECONFIG, Building configuration data file: DUA0:[MB$.MB.MB$WORK]MB$CNFDB_CLUSTER.DAT MR : Message Router MS : Management Service TS : Transfer Service DDS : Directory Service ER : Exception Reporting A1 : ALL-IN-1 MBC> SET MS %MB-I-MBC$SET, Setting configuration parameters * What device do you want to use for the Management Service [DUA0:] ? * What is the name of the network management node [ORANGE] ? * What is the difference between network time and local time [00:00] ? * Do you wish to modify the account passwords [N] ? y * What password do you want for the MBMANAGER account [] ? Please confirm * What password do you want for the MBMANAGER account [] ? MBC> SET DDS %MB-I-MBC$SET, Setting configuration parameters * What device do you want to use for the Directory Service [DUA0:] ? A-1 Example Default Configuration * What is the alarm level of free blocks required for the Directory Service [20000] ? * What is the name of the DDS master node [ORANGE] ? MBC> SET TS %MB-I-MBC$SET, Setting configuration parameters * What device do you want to use for the Transfer Service [DUA0:] ? * What is the alarm level of free blocks required for the Transfer Service [10000] ? MBC> ENABLE MS %MB-I-MBC$ENABLE, Enabling messaging process MBC> ENABLE DDS %MB-I-MBC$ENABLE, Enabling messaging process MBC> ENABLE TS %MB-I-MBC$ENABLE, Enabling messaging process MBC> ENABLE ER %MB-I-MBC$ENABLE, Enabling messaging process MBC> RECOVER MS %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-MBC$RECPHASE, Beginning recovery phase for MS %MB-I-CHKMSREL, checking if MS relocated to different location ... %MB-I-UPDMSPSWD, updating MS passwords for MBMANAGER/MRMANAGER ... %MB-I-MBC$REPLETE, Configuration database recovery complete MBC> RECOVER DDS %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-MBC$RECPHASE, Beginning recovery phase for DDS %MB-I-CHKDDSREL, checking if DDS relocated to different location ... %MB-I-CREDDSCNF, creating configuration file for DDS ... %MB-I-DDSDBUPD, updating DDS database ... %MB-I-UPDNCPOBJ, updating NCP object for DDS ... %MB-I-UPDDDSPSWD, updating DDS password for DDSNET ... %MB-I-UPDXRPTENBF, updating DDS Exception Reporting enable flag ... %MB-I-MBC$REPLETE, Configuration database recovery complete MBC> RECOVER TS %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-MBC$RECPHASE, Beginning recovery phase for TS %MB-I-CHKTSREL, checking if TS relocated to different location ... %MB-I-CREINI, creating initialization file for TS ... %MB-I-UPDTSDIRMBX, updating mbx directory database for TS ... %MB-I-UPDNCPOBJ, updating NCP object for TS ... %MB-I-UPDTSPSWD, updating TS password for MRNET ... %MB-I-UPDXRPTENBF, updating TS Exception Reporting component enable flag(s) ... %MB-I-MBC$REPLETE, Configuration database recovery complete MBC> RECOVER ER %MB-I-MBC$RECOVER, Recovering configuration database %MB-I-MBC$RECPHASE, Beginning recovery phase for ER %MB-I-UPDTSMBX, Updating TS mbx directory database for Exception Reporting ... %MB-I-UPDERNODES, updating nodes database for ER ... %MB-I-UPDERPSWD, updating ER password for MBWATCH ... %MB-I-UPDXRPTZONE, updating network Exception Reporting zone time ... %MB-I-UPDXRPTENBF, updating network Exception Reporting enable flag ... A-2 Example Default Configuration %MB-I-MBC$REPLETE, Configuration database recovery complete MBC> EXIT A-3 Appendix B The Default Configuration B.1 Default Parameter Settings Table B-1 shows the settings of the configuration parameters in a default configuration. Table B-1: Default Configuration Values Option Setting Management Service Account to which exception reports are MBMANAGER account on sent network management node Time zone difference 00:00 (local time is the same as network time) Directory Service Run exception reporting for the yes Directory Service Minimum number of free blocks required 20000 by the Directory Service Maximum size of the Directory Service 200 blocks error file Directory Service events that are 0.0-0.7 broadcast Directory Service events that are logged 1.0-1.10, 3.0-3.4, 4.6-4.9, 7.0-7.15 B-1 The Default Configuration Option Setting Directory Service events that are 2.0-2.1, 4.0-4.5, counted 4.10-4.11, 5.0-5.30 Directory Service events that are 0.8-0.31, 1.11-1.31, ignored 2.2-2.31, 3.5-3.31, 4.12-4.31, 5.31, 6.0-6.31, 7.16-7.31 Defer updates on directory objects for TEMPLATE object only Maximum number of cache entries 200 Maximum number of simultaneous network 5 per listener links DDS$TIDY runs yes DDS$DEFER runs yes DDS$REFRESH runs yes Transfer Service Run exception reporting for the Transfer yes Service Minimum number of free blocks required 10000 blocks by the Transfer Service Maximum size of the Transfer Service 200 blocks error file Permit remote commands messages yes MR$TIDY runs yes Talkers 1 notify talkers per node Maximum time between scans of the nodes 30 minutes list by the notify talker Maximum time a notify talker spends 5 minutes sending to a particular node Maximum number of messages a notify 10 talker sends to each node each time it runs B-2 The Default Configuration Option Setting Number of message file areas 2 Maximum number of Transfer Service no restriction images that can run simultaneously Batch queue where jobs started by the SYS$BATCH /RUN qualifier run Maximum hopcount 5 Rejected messages renamed Return service messages interactively Default routing yes Searching the system user authorization no file for unrecognized recipients Journaling messages no Destination of non-delivery messages sender Broadcast class to notify users of MAIL messages Operator's console to which selected network status messages are sent Message transaction logging yes, not essential Maximum number of entries stored in the 100 message transaction buffer Number of buffer extensions 2 Maximum size of the message transaction 500 blocks file Number of versions of the message 2 transaction file kept Queue monitoring by age of message no Queue monitoring by size of queue no Mailboxes that can be accessed by remote any User Agents B-3 The Default Configuration Option Setting Exception Reporting Submission interval for exception 30 minutes reporting routines Maximum time between runs of the 90 minutes exception reporting routines Network management node monitors yes exception reporting B.2 Default Directory Structure Figure B-1 shows the default directory structure. Figure B-1: Default Directory Structure MB$ | | ___________________________|__________________________ | | | | MR DDS MB TOOLS ______|_______ | ________|________ | | | | | | | | WRK DB SCR MSGn | MB$WORK MB$COM MB$SCRATCH ______|______ | | | DB WRK SCR B.3 Message Router Files Table B-2 shows the files that are present when you after you configure your node accepting the default configuration but before you start Message Router. The files sizes shown are approximate. B-4 The Default Configuration Table B-2: Message Router Files Directory and File Size Protection(S,O,G,W) --------------------------------------------------------------------- [MB$] DDS.DIR 1 (RWE,RWE,R,R) MB.DIR 1 (RWE,RWE,R,R) MR.DIR 1 (RWE,RWE,R,R) TOOLS.DIR 1 (RWE,RWE,R,R) [MB$.DDS] DB.DIR 1 (RWE,RWE,R,R) SCR.DIR 1 (RWE,RWE,R,R) WRK.DIR 1 (RWE,RWE,R,R) [MB$.MB] MB$COM.DIR 1 (RWE,RWE,R,R) MB$SCRATCH.DIR 1 (RWE,RWE,R,R) MB$WORK.DIR 1 (RWE,RWE,R,R) [MB$.MB.MB$COM] MB$A1_ER.COM 17 (RWED,RWED,RE,E) MB$A1_ERRORS.DAT 2 (RWED,RWED,RE,E) MB$ADDREP.COM 14 (RWED,RWED,RE,E) MB$CHECKDEV.COM 11 (RWED,RWED,RE,E) MB$DDS_ER.COM 48 (RWED,RWED,RE,E) MB$ERRORS.DAT 15 (RWED,RWED,RE,E) MB$INIT.COM 28 (RWED,RWED,RE,RE) MB$MAILER.COM 8 (RWED,RWED,RE,E) MB$NET_ER.COM 53 (RWED,RWED,RE,E) MB$TS_ER.COM 47 (RWED,RWED,RE,E) [MB$.MB.MB$WORK] DDS$CACHE_AIF.FDL 3 (RWED,RWED,RE,RE) DDS$CACHE_DB.FDL 3 (RWED,RWED,RE,RE) DDS$INQUE.FDL 3 (RWED,RWED,RE,RE) DDS$NETQUE.FDL 2 (RWED,RWED,RE,RE) DDS$NIF.FDL 3 (RWED,RWED,RE,RE) DDS$OUTQUE.FDL 2 (RWED,RWED,RE,RE) DDS$PERM_AIF.FDL 3 (RWED,RWED,RE,RE) DDS$PERM_DB.FDL 2 (RWED,RWED,RE,RE) MB$A1$CONFIG$CUSTOMIZED.DAT 2 (RWED,RWED,RE,RE) MB$A1$CONFIG$DEFAULT.DAT 2 (RWED,RWED,RE,RE) B-5 The Default Configuration Directory and File Size Protection(S,O,G,W) --------------------------------------------------------------------- MB$CNFDB_node.DAT, 134 (RWED,RWED,RE,RE) MB$CNFDB_clustername.DAT, or MB$CNFDB_CLUSTER.DAT MB$CNFTXN_node.DAT, 134 (RWED,RWED,RE,RE) MB$CNFTXN_clustername.DAT, or MB$CNFTXN_CLUSTER.DAT MB$MR$CONFIG$CUSTOMIZED.DAT 50 (RWED,RWED,RE,RE) MB$MR$CONFIG$DEFAULT.DAT 53 (RWED,RWED,RE,RE) MB$STOP.DAT 0 (RWED,RWED,RE,RE) MB$VERSION.DAT 1 (RWED,RWED,RE,RE) [MB$.MR] DB.DIR 1 (RWE,RWE,R,R) MSG1.DIR 1 (RWE,RWE,R,R) MSG2.DIR 1 (RWE,RWE,R,R) SCR.DIR 1 (RWE,RWE,R,R) WRK.DIR 1 (RWE,RWE,R,R) [MB$.MR.SCR] [MB$.MR.WRK] MB$TALK_NOTIFY_TEMPLATE.COM 17 (RWED,RWED,RE,RE) MB$TALK_RUN_DEF.COM 18 (RWED,RWED,RE,RE) MB$TALK_RUN_TEMPLATE.COM 18 (RWED,RWED,RE,RE) MB$TALK_SCHEDULE_TEMPLATE.COM 20 (RWED,RWED,RE,RE) MR$NODES_DEF.DAT 1 (RWED,RWED,RE,E) MRINITDEF.DAT 33 (RWED,RWED,RE,E) MRINITHELP.COM 48 (RWED,RWED,RE,E) MRINITUTL.COM 99 (RWED,RWED,RE,E) MRMWRK.COM 4 (RWED,RWED,RE,E) [MB$.TOOLS] DDS$BACKUP.COM 14 (RWED,RWED,RE,E) DDS$COMPRESS.COM 14 (RWED,RWED,RE,E) DDS$CVP.DAT 1 (RWED,RE,RE,RE) MB$CVP.DAT 6 (RWED,RE,RE,RE) MB$DDSNET.COM 3 (RWED,RWED,RE,RE) MB$ER_UPGRADE.COM 8 (RWED,RWED,RE,RE) MB$LOCATION_TEMPLATE.COM 6 (RWED,RWED,RE,RE) MB$MBMANAGER.COM 4 (RWED,RWED,RE,RE) MB$MBWATCH.COM 3 (RWED,RWED,RE,RE) MB$MRMANAGER.COM 4 (RWED,RWED,RE,RE) MB$MRNET.COM 3 (RWED,RWED,RE,RE) MB$REPOST.COM 13 (RWED,RWED,RE,E) MR$COMPRESS.COM 12 (RWED,RWED,RE,E) B-6 The Default Configuration Directory and File Size Protection(S,O,G,W) --------------------------------------------------------------------- MR$CVP.DAT 2 (RWED,RE,RE,RE) MRNBSDMP.EXE 138 (RWED,RWED,RE,RE) B-7 Appendix C Configuration Questions C.1 Introduction This appendix contains lists of all the questions asked by the configuration procedure. If you choose the default configuration, the configuration procedure asks only a small number of these questions (see Chapter 5). If you choose a customized configuration, the configuration procedure asks most of these questions, depending on the answers you give. C.2 Management Service Questions What device do you want to use for the Management Service? What is the name of the network management node? Where do you want exception reports to be sent (VMSmail address)? What is the difference between network time and local time? Do you wish to modify the account passwords? What password do you want for the MBMANAGER account? What password do you want for the MRNET account? What password do you want for the DDSNET account? What password do you want for the MBWATCH account? C.3 Directory Service Questions What device do you want to use for the Directory Service? Do you want to enable Directory Service exception reporting? What is the alarm level of free blocks required for the Directory Service? What is the name of the DDS master node? What device do you want to use for the permanent database file? What device do you want to use for the permanent database index file? What device do you want to use for the cache database file? C-1 Configuration Questions What device do you want to use for the cache index database file? What device do you want to use for the event log file? What device do you want to use for the input queue file? What device do you want to use for the output queue file? What device do you want to use for the network queue file? What device do you want to use for the network index file? Which Directory Service events do you want to ignore? What events do you want to count? Which Directory Service events do you want to log? Which Directory Service events do you want to send to the operator's console? Do you want to defer updates for any objects? For which objects do you want deferred updates? Do you want to notify the operator of Directory Service errors? Do you want to notify a central operator of Directory Service errors? Do you want to notify the network operator of Directory Service errors? Do you want to notify user-defined operator(s)? Which user-defined operator do you want to notify? What is the maximum number of objects you want to store in the cache? What is the maximum number of network links you want to permit per listener? Do you want to run DDS$TIDY? On which days do you want to run DDS$TIDY (enter a list, for example, Mon,Wed)? At what time (in combination time format) do you want DDS$TIDY to start running? For how long (in minutes) do you want DDS$TIDY to try to start? How often (in days) do you want DDS$TIDY to carry out housekeeping tasks? How often (in days) do you want DDS$TIDY to purge the queues? How often (in days) do you want DDS$TIDY to reset the DDS event counters? How long (in days) can a transaction remain in the network queue before DDS$TIDY deletes it? How long (in days) can a transaction remain in the input queue before DDS$TIDY deletes it? How long (in days) can a transaction remain in the output queue before DDS$TIDY deletes it? What is the maximum size (in blocks) of the Directory Service event log file? On which batch queue do you want DDS$TIDY to run? Which print queue do you want DDS$TIDY to use? Do you want to run DDS$DEFER to carry out deferred updates? On which days do you want DDS$DEFER to run (enter a list, for example, Mon,Wed)? At what time (in combination time format) do you want DDS$DEFER to start running? For how long (in minutes) do you want DDS$DEFER to try to start? C-2 Configuration Questions On which batch queue do you want DDS$DEFER to run? Do you want to run DDS$REFRESH to refresh the cache? On which days do you want DDS$REFRESH to run (enter a list, for example, Mon,Wed)? At what time (in combination time format) do you want DDS$REFRESH to start running? For how long (in minutes) do you want DDS$REFRESH to try to start? On which batch queue do you want DDS$REFRESH to run? What is the maximum number of cache entries refreshed each time DDS$REFRESH runs? Which cache objects do you want to refresh? C.4 Transfer Service Questions What device do you want to use for the Transfer Service? Do you want to enable Transfer Service exception reporting? What is the alarm level of free blocks required for the Transfer Service? What is the maximum size (in blocks) for the Transfer Service error file? Do you want to use remote-commands messages? What is the command file that runs when a remote-commands message is received? Do you want to run MR$TIDY? How often (in days) do you want MR$TIDY to carry out housekeeping tasks? At what time do you want MR$TIDY to run? For how long (in minutes) do you want MR$TIDY to try to start? On which days do you want MR$TIDY to run (enter a list, for example, Mon,Wed)? On which batch queue do you want MR$TIDY to run? Which print queue do you want MR$TIDY to use? At what age (in days) do you want MR$TIDY to purge undelivered messages? What type of talker do you want? What is the maximum number of notify talkers you want on a node? What is the maximum number of notify talkers you want on the cluster? Do you want to notify the talker using a VMS mailbox? Which VMS mailbox does the notify talker use? What is the file specification of the nodes list served by the notify talker? What is the maximum time (in delta-time format) between scans of the nodes list by the notify talker? What is the maximum time (in delta-time format) the notify talker can spend sending to one node? What is the maximum number of messages the notify talker can send consecutively to one node? What is the maximum number of schedule talkers you want on a node? C-3 Configuration Questions What is the maximum number of schedule talkers you want on the cluster? What is the file specification of the nodes list served by the schedule talker? How often do you want the schedule talker to run? What is the maximum time (in delta-time format) the schedule talker can spend sending to one node? What is the maximum number of messages the schedule talker can send each time it runs? On which batch queue does the schedule talker run? What is the maximum number of run talkers you want on a node? What is the maximum number of run talkers you want on the cluster? What is the file specification of the nodes list served by the run talker? How often do you want the run talker to run? What is the maximum time (in delta-time format) the run talker can spend sending to one node? What is the maximum number of messages the run talker can send each time it runs? How many message file areas do you want? Enter the disk for message file area 1? Enter the disk for message file area 2? Enter the disk for message file area 3? Enter the disk for message file area 4? Enter the disk for message file area 5? Enter the disk for message file area 6? Enter the disk for message file area 7? Enter the disk for message file area 8? Enter the disk for message file area 9? Enter the disk for message file area 10? What device do you want to use for the Transfer Service mailbox directory? What device do you want to use for the Transfer Service queue file? What database number do you want to use? What is the maximum number of Transfer Service images that you want to run at any time? Which batch queue do you want to use to submit processes started by the /RUN qualifier? What is the maximum hopcount allowed on message transfer? Do you want to delete corrupt messages? Do you want to return service messages interactively? Does the Transfer Service use area routing? What is the area code for this area? Do you want to run the Transfer Service with default routing? Do you want to search the system user authorization file for unrecognized recipients? Do you want destination journaling? What is the name of the destination journal mailbox? Do you want source journaling? C-4 Configuration Questions What is the name of the source journal mailbox? Do you want to return non-delivery messages to the operator instead of the sender? What is the name of the mailbox to receive non-delivery messages? What VMS broadcast class do you want to use for new mail notifications? Do you want to notify the operator of Transfer Service errors? Do you want to notify a central operator of Transfer Service errors? Do you want to notify network operators of Transfer Service errors? Do you want to notify user-defined operator? Which user-defined operator do you want to notify? Do you want message transaction logging? Do you want to stop message transfer if transaction logging fails? How many message transaction entries do you want to store in the buffer? How many times do you want the message transaction file buffer to extend before failing? What is the maximum size (in blocks) of the message transaction file? How many versions of the message transaction file do you want to keep? Do you want active queue monitoring by age? What message age limit do you want to set? Do you want active queue monitoring by size? What queue size limit do you want to set? Do you want to allow cluster aliases? What timeout (in delta-time format) do you want on a DECnet listener? Do you want to permit connections from remote User Agents? Do you want to permit connections to SYSTEM mailboxes from remote User Agents? C.5 Exception Reporting Questions How often (in combination time format) do you want to run the exception reporting routines? What maximum time (in delta-time format) do you want between runs of exception reporting routines? Do you want the network management node to monitor exception reporting on the other nodes? C-5 INDEX INDEX account Transfer Service database, 4-28 destination for exception cluster aliases, 1-2, 4-27 reports, 4-29 disabling incoming connections, addressing loops 4-28 detecting, 4-18 enabling, 4-28 alias on a heterogeneous cluster, 1-3 cluster, 1-2, 4-27 on a homogeneous cluster, 1-3 area code, 2-12, 4-20 with a mixed cluster, 4-28 area management, 2-2 with area routing, 4-28 area routing with destination routing, 4-28 addressing, 2-15 with small machines, 4-28 advantages, 2-11 with the Directory Service, 1-3 area code, 2-12, 4-20 with the Transfer Service, 1-3 definition, 2-11 completing configuration, 5-6, disadvantages, 2-12 7-5 example, 2-13 configuration hub node, 2-11 completing, 5-6, 7-5 customized, 4-1 batch queue customized Directory Service, on a cluster, 4-29 4-3 used by DDS$DEFER, 4-10 customized Management Service, used by DDS$REFRESH, 4-10 4-1 used by DDS$TIDY, 4-8 customized Transfer Service, used by MR$TIDY, 4-14 4-10 used by the Transfer Service, default, 2-16 4-18 default parameters, B-1 broadcasting class Directory Service, 5-5, 7-4 GENERAL, 4-22 Directory Service questions, MAIL, 4-22 C-1 URGENT, 4-22 directory structure, B-4 used to notify users of new example log, A-1 mail, 4-22 exception reporting, 4-29, 7-5 USER1 to USER16, 4-22 exception reporting for Version 2.1, 1-3 cache database exception reporting questions, number of entries, 4-7 C-5 central operator, 4-23 heterogeneous, 2-16 cluster homogeneous cluster, 2-16 configuring heterogeneous, 2-15 introduction, 1-1 configuring homogeneous, 2-15 keeping a log, 5-1 configuring the batch queue, MAILBUS components, 5-6, 7-5 4-29 Management Service, 5-3, 7-3 name, 4-27 Management Service questions, names, 1-2 C-1 restrictions, 1-3 MB$CONFIG, 1-1 transaction logging, 4-23 Index-1 INDEX network planning checklist, renaming, 4-9 2-17 DDS$REFRESH, 4-10 network time, 2-16 batch queue, 4-10 planning, 1-1 configuration options, 4-10 planning a customized system, number of entries refreshed, 4-1 4-10 planning a default system, 3-1 objects refreshed, 4-10 preparation, 5-1, 7-1 schedule, 4-10 reconfiguring, 1-4 DDS$TIDY, 4-8 starting, 5-2, 7-2 batch queue, 4-8 Transfer Service, 4-10, 5-6, configuration options, 4-8 7-4 days when run, 4-8 Transfer Service questions, C-3 interval between housekeeping upgrading, 1-1 tasks, 4-9 verification procedure for the print queue, 4-8 Directory Service, 5-11, purging queues, 4-9 7-10 renaming DDS$LOG.DAT, 4-9 verification procedure for the resetting event counters, 4-9 Management Service, 5-10, scheduled time, 4-8 7-9 DDSNET account verification procedure for the password, 4-2 Transfer Service, 5-12, default configuration, 2-16 7-11 checklist, 3-3 verification procedures, 5-10, planning, 3-1 7-8 default routing configuration checklist advantages, 2-6 customized Directory Service, definition, 2-5 4-33 disadvantages, 2-6 customized exception reporting, sample address, 2-7 4-34 default routing option customized Management Service, accepting, 2-4 4-30 deferred updates, 4-6, 4-9 customized Transfer Service, defining world search nodes, 8-1 4-31 destination for exception reports, configuration verification 4-2 procedures, 5-10, 7-8 destination routing corrupt message advantages, 2-8 deleting, 4-19 definition, 2-7 renaming, 4-19 disadvantages, 2-8 CVP, 5-10, 7-8 example, 2-9 Directory Service, 5-11, 7-10 mailbox directory, 2-8 Management Service, 5-10, 7-9 when to use, 2-9 Transfer Service, 5-12, 7-11 device used by the Directory Service, DDS$DEFER, 4-9 3-1, 4-5 batch queue, 4-10 used by the Management Service, configuration options, 4-9 3-1, 4-1 schedule, 4-9 used by the Transfer Service, DDS$LOG.DAT 3-1, 4-12 maximum size, 4-9 DIGITAL User Agents Index-2 INDEX recommended routing method, 2-6 MRERR.INF Directory Service error messages broadcast errors, 4-7 broadcast to operator's console, changing devices, 4-4 4-23 configuration, 5-5, 7-4 events in the Directory Service, configuration questions, C-1 4-6 customized configuration example default configuration, checklist, 4-33 A-1 customized configuration exception report options, 4-3 destination account, 4-2, 4-29 CVP, 5-11, 7-10 exception reporting deferred updates, 4-6 broadcasting error messages, devices used, 4-5 4-23 events, 4-6 broadcasting errors, 4-7 housekeeping, 4-8 configuration, 7-5 network links, 4-8 configuration questions, C-5 nodes list, 8-1 configuring, 4-29 number of entries in cache, 4-7 customized configuration starting, 6-1, 8-1 checklist, 4-34 using cluster aliases, 1-3 enabling, 3-2 Directory Service cache refresh for the Directory Service, 4-5 command procedure for the Transfer Service, 4-13 DDS$REFRESH for Version 2.1, 1-3 Directory Service database free blocks needed by Directory Gateway requirements, 2-3 Service, 3-3 populating, 2-3 free blocks needed by Transfer unique entries, 2-4 Service, 3-3 updating, 2-4 monitoring, 4-27, 4-30 User Agent requirements, 2-3 network, 4-30 Directory Service deferred update nodes list, 8-2 command procedure schedule, 4-30 DDS$DEFER setting up the nodes list, 6-2, Directory Service events, 4-6 8-2 broadcasting, 4-6 counting, 4-6 GENERAL broadcasting class, 4-22 ignoring, 4-6 logging, 4-6 heterogeneous cluster Directory Service log file configuration, 2-15 DDS$LOG.DAT homogeneous cluster Directory Service maintenance configuration, 2-15 command procedure hopcount DDS$TIDY limit, 4-18 Directory Service master node, hub node 2-3 in area routing, 2-11 post-configuration tasks, 6-1 Directory Service nodes list setting up, 6-1, 8-1 journaling directory structure, B-4 a message, 4-21 at destination, 4-21 error information file at source, 4-21 Index-3 INDEX listener message transactions Directory Service, 4-8 logging, 4-23 shared image, 4-26 monitoring Transfer Service, 4-26 exception reporting, 4-27 mailbox queues, 4-25 MAIL broadcasting class, 4-22 moving Directory Service files, mailbox directory 3-1 moving, 4-17 moving Management Service files, operator mailbox entry, 4-21 3-1 unrecognized node entry, 2-4 moving Transfer Service files, unrecognized recipient, 4-20 3-1, 4-12 mailbox queues MR$TIDY monitoring, 4-25 batch queue, 4-14 MAILBUS configuring, 4-14 configuration, 5-6, 7-5 days to run, 4-14 MAILBUS configuration procedure interval between housekeeping MB$CONFIG tasks, 4-14 Management Service print queue, 4-14 configuration, 5-3, 7-3 scheduled time, 4-14 configuration questions, C-1 MRERR.INF customized configuration maximum size, 4-13 checklist, 4-30 MRGATE, 4-21 CVP, 5-10, 7-9 MRMANAGER account device used, 4-1 password, 4-2 master node, 2-3 MRMWRK.COM, 4-14 post-configuration tasks, 6-1 MRn.NBS_BAD, 4-19 MB$ER_UPGRADE, 1-3 MRNET account MBMANAGER account password, 4-2 password, 3-2, 4-2 multiple talkers, 4-16 MBWATCH account password, 4-2 NETSERVER process message setting the timeout period, journaling, 4-21 4-26 purging, 4-19 NETSERVER.LOG, 4-27 message file areas network exception reporting, 4-30 defining, 4-16 network links, 4-8 number of, 4-16 network management node, 2-2 Message Router areas, 2-2 files, B-4 characteristics, 2-2 starting, 6-3, 8-3 post-configuration tasks, 6-2, stopping, 5-1, 7-1 8-2 Message Router exception network operator, 4-23 reporting upgrade procedure network planning MB$ER_UPGRADE checklist, 2-17 message transaction file, 4-23 network routing methods buffer, 4-24 area, 2-5 buffer size, 4-24 default, 2-5 extending the buffer, 4-24 dependencies, 2-5 purging the, 4-24 destination, 2-5 size, 4-24 network time, 2-16 Index-4 INDEX new mail refreshing the cache, 4-10 broadcast class used to notify rejected messages users, 4-22 handling, 4-19 nodes list remote User Agents exception reporting, 8-2 connecting to privileged for exception reporting, 6-2 mailboxes, 4-27 non-delivery notification message remote-commands command procedure destination, 4-21 MRMWRK.COM notify talker, 4-15 remote-commands messages, 4-13 configuration options, 4-15 run talker, 4-15 configuration options, 4-16 OPERATOR, 4-21 operator schedule talker, 4-15 central, 4-23 configuration options, 4-15 mailbox, 4-21 service messages network, 4-23 sending as a batch, 4-19 user-defined, 4-23 sending interactively, 4-19 operator mailbox start-up file specifying, 4-21 commands to add, 4-28, 6-3 operator's console starting used to broadcast error Directory Service, 6-1, 8-1 messages, 4-6, 4-23 Message Router, 6-3, 8-3 stopping password Message Router, 5-1, 7-1 DDSNET account, 4-2 SYSTEM mailbox, 4-27 MBMANAGER, 3-2 MBMANAGER account, 4-2 MBWATCH account, 4-2 talker MRMANAGER account, 4-2 defaults, 4-15 MRNET account, 4-2 notify, 4-15 planning parameters, 4-15 configuration, 1-1 run, 4-15 customized configuration, 4-1 running more than one, 4-16 default configuration, 3-1 schedule, 4-15 populating the Directory Service template file, 4-16 database, 2-3 time zone correction, 3-1, 4-2 post-configuration tasks, 6-1, timeout period 8-1 for the NETSERVER process, 4-26 print queue transaction logging used by DDS$TIDY, 4-8 essential, 4-23 used by MR$TIDY, 4-14 non-essential, 4-23 privileged mailboxes number of images, 4-23 remote connection to, 4-27 on a cluster, 4-23 Transfer Service queue file batch queue, 4-18 moving, 4-17 batch queue on a cluster, 4-29 configuration, 4-10, 5-6, 7-4 reconfiguring, 1-4 configuration questions, C-3 changing your system, 1-4 customized configuration error recovery, 1-5 checklist, 4-31 Index-5 INDEX customized configuration cluster names, 1-2 options, 4-10 keeping messages, 1-2 CVP, 5-12, 7-11 minimizing interruption, 1-2 detecting addressing loops, upgrading from Message Router 4-18 V2.0 or 2.1, 1-1 device, 4-12 URGENT broadcasting class, 4-22 exception reporting, 4-13 user-defined operator, 4-23 hopcount limit, 4-18 USER1 to USER16 broadcasting image limit, 4-18 class, 4-22 listener, 4-26 using cluster aliases, 1-3 V2.0 or 2.1 configuration, 1-2 Transfer Service database, 4-28 VMSmail Gateway on a cluster, 4-18 using, 4-20 updating remotely, 4-13 VMSmail users Transfer Service device sending messages, 4-20 changing, 4-12 Transfer Service maintenance command procedure world search node, 2-1 MR$TIDY cache database, 2-1 characteristics, 2-2 unrecognized recipient, 4-20 defining, 6-1, 8-1 upgrading permanent database, 2-1 Index-6 VAX Message Router Configuration Guide KR-18A-TE Reader's Comments Please give us your comments and suggestions on this manual. They help us to improve the quality and usefulness of our publications. 1 How would you rate this manual for: good fair bad Completeness of information: Accuracy of information: Clarity: Organization: 2 Did you find errors in this manual? Please specify by page and paragraph, or mark corrections on pages and attach copies to this form. page paragraph Information that is missing: Information that is incorrect: Information that is hard to understand: Information that is hard to find: 3 What suggestions do you have for improving this manual? 4 Which parts of the manual are good at helping you understand the product? 5 Please mark the descriptions that apply to you. _ Technical _ Nontechnical _ Management _ Nonmanagement _ Other (explain) 6 How do you use this manual, e.g., as a reference, or to follow procedures? Name Title Company Street City State Zip Date