BITNET Postmaster's Guide for VAX/VMS Systems Written for CREN by Stephen L. Arnold, Ph.D., Arnold Consulting April 1992 This book describes mail routing and transport, and the respon- sibilities of the Postmaster, for a computer system on BITNET. This book also provides instructions, specific to the BITNET envi- ronment, on installing, configuring, and managing NJE and mailer software and data tables for Digital VAX computer systems running VMS, Jnet, and PMDF, to supplement the documentation provided with commercial software products. Revision/Update Information: This is a new book. Operating System and Version: VAX/VMS Version V5.0 or later Software Versions: Jnet Version 3.5 PMDF Version 4.0 or later Corporation for Research and Educational Networking Suite 600, 1112 Sixteenth Street NW, Washington, DC 20036 Permission,isRgrantedpbyaCREN torreproduce and distributelthis ma- terial in whole or in part, without imposition of fees or charges, so long as the source is acknowledged and CREN's copyright notice is included on the reproduced materials. The information in this document is subject to change without notice and should not be construed as a commitment by the author, Arnold Consulting, or the Corporation for Research and Educational Networking (CREN). The author, Arnold Consulting, and CREN assume no responsibility for any errors that may appear in this document. Some of the software described in this document is furnished under licenses and may be used, copied, or disclosed only in accordance with the terms of such licenses. The author would appreciate comments on this document so that future editions might be improved. By providing comments or cor- rections to CREN or the author, you give your permission for them to be used without restrictions. Please send your comments to the author at CRENDOC@BITNIC (BITNET), or call +1 (608) 238-7835. ALL-IN-1, DEC, DECnet, DECwindows, MicroVAX, ULTRIX, VAX, VAXcluster, VAXstation, VMS, and VMSmail are trademarks of Digital Equipment Corporation. BITNET and CREN are registered service marks of the Corporation for Research and Educational Networking. Application System/400, IBM, MVS, and VM are trademarks of International Business Machines Corporation. Joiner is a registered trademark of Joiner Associates Incorporated. Jnet is a registered trademark of Joiner Software, Inc. PMDF is a registered trademark of Innosoft International, Inc. Motif is a trademark of the Open Software Foundation, Inc. MultiNet is a trademark of SRI International and TGV, Incorporated. Tek is a registered trademark of Tektronix, Inc. UNIX is a registered trademark of UNIX System Laboratories, Inc. WIN and WIN/TCP are trademarks of The Wollongong Group, Inc. Ethernet is a trademark of Xerox Corporation. Contents PREFACE xi CHAPTER 1 MAILERS ON BITNET 1-1 1.1 DIRECT TRANSMISSION OF ELECTRONIC MAIL BY NETWORK JOB ENTRY 1-1 1.2 BITNET MAIL CONCEPTS 1-3 1.3 BITNET TECHNICAL REQUIREMENTS 1-6 1.4 BENEFITS OF INSTALLING A MAILER 1-9 1.4.1 Mailers Ease Addressing 1-10 1.4.2 Mailers Isolate Users From Network Changes 1-11 1.4.3 Mailers Provide New Functions 1-11 CHAPTER 2 OVERVIEW OF SETTING UP A BITNET NODE 2-1 2.1 ASSUMPTIONS 2-2 2.2 STEPS TO SET UP A BITNET NODE 2-3 CHAPTER 3 PLANNING SYSTEM AND USER NAMES 3-1 3.1 STARTING ASSUMPTIONS FOR NAME PLANNING 3-1 3.2 GENERAL CONSIDERATIONS FOR NETWORK NAMES 3-2 3.3 NAMES FOR BITNET HOSTS 3-4 3.4 SUGGESTED PROCEDURE FOR PLANNING SYSTEM NAMES 3-4 3.4.1 Summary of name planning procedure 3-5 3.4.2 Plan SCSNODE and DECnet-VAX names 3-5 3.4.3 Plan a VAXcluster alias name 3-7 3.4.4 Plan domain names 3-8 3.4.5 Register a domain name with the DDN NIC 3-10 3.4.6 Plan NJE names 3-12 iii Contents 3.4.7 Plan reserved and general user names 3-13 3.4.7.1 POSTMASTER and POSTMAST 3-13 3.4.7.2 MAILER and SMTPUSER 3-15 3.4.7.3 LISTSERV and NETSERV 3-15 3.4.7.4 JOB 3-16 3.4.7.5 SYSTEM, ROOT, and MAINT 3-16 3.4.7.6 PMDF and PMDF_USER 3-18 3.4.7.7 General user names 3-18 3.5 CAMPUS NETWORK EXAMPLE 3-19 CHAPTER 4 INSTALLING AND CONFIGURING NETWORKING SOFTWARE 4-1 4.1 VMSINSTAL AND AUTOANSWER FILES 4-1 4.2 CHANGING SCSNODE NAMES 4-2 4.3 CONFIGURING DECNET-VAX 4-4 4.4 CONFIGURING DECNET-VAX EXTENSIONS 4-4 4.5 CONFIGURING VMSMAIL 4-5 4.6 TCP/IP INSTALLATION AND CONFIGURATION 4-5 CHAPTER 5 INSTALLING AND CONFIGURING NJE SOFTWARE 5-1 5.1 PLAN BITNET TOPOLOGY 5-1 5.1.1 Selecting systems to participate in BITNET 5-1 5.1.2 Principal Nodes 5-4 5.1.3 Planning external connections 5-5 5.1.4 Planning intraorganization links 5-7 5.1.5 VAXcluster connections 5-8 5.1.6 Link protocols 5-9 5.2 INSTALL BITNET TRANSPORTS 5-10 5.3 INSTALL JNET AND LINK DRIVERS 5-12 5.4 CONFIGURE JNET 5-14 5.4.1 Run Jnet autoconfiguration procedure 5-15 iv Contents 5.4.2 Manual configuration tasks 5-17 5.4.2.1 Edit JAN_COMMON:[SYS]LOGIN.COM 5-18 5.4.2.2 Test SYS$MANAGER:SYLOGIN.COM 5-18 5.4.2.3 Use SYSMAN STARTUP instead of SYS$MANAGER:SYSTARTUP_V5.COM 5-18 5.4.2.4 Edit JAN_SYS:JANLINKS.JCP and JAN_SYS:JANSTART.JCP 5-18 5.4.2.5 Defer the creation of JAN_SYS:JANROUTES.JCP 5-20 5.4.2.6 Consolidate JAN_SYS:JANLOAD.COM 5-20 5.4.2.7 Edit JAN_COMMON:[SYS]JANSITECOMMON.COM 5-20 5.4.2.8 Skip instructions for LMD.COM 5-23 5.4.2.9 Edit and enable JAN_COMMON:[SYS]JANTIDY.COM 5-23 5.4.2.10 Edit link parameter files 5-23 5.4.2.11 Edit SYS$COMMON:[SYSMGR]LAT$SYSTARTUP.COM 5-24 5.5 BRING UP BITNET LINK 5-25 5.6 INSTALL BITNET TABLES 5-25 5.7 REGISTER BITNET NODES 5-27 5.7.1 About the UPDATE procedure 5-27 5.7.2 Where to send UPDATE jobs 5-28 5.7.3 Adding a Postmaster people tag 5-29 5.7.4 Registering a node 5-32 5.8 WAIT FOR ROUTING TABLES 5-37 5.8.1 The monthly update cycle 5-37 5.8.2 Monitoring table updates 5-38 5.8.3 Installing initial tables 5-39 CHAPTER 6 INSTALLING AND REGISTERING A BITNET MAILER 6-1 6.1 EXTERNAL VIEW OF A MAILER 6-1 6.2 INSTALL PMDF 6-2 6.2.1 Determine UICs for PMDF SYSUAF entries 6-2 6.2.2 Select a location for the PMDF files 6-2 6.2.3 Set up PMDF queues 6-3 6.2.4 Run VMSINSTAL 6-5 6.2.5 Configure PMDF for automatic startup 6-6 v Contents 6.2.6 Make PMDF online books available to Bookreader 6-8 6.3 CONFIGURE PMDF 6-10 6.3.1 Obtain mailer files 6-10 6.3.2 Run PMDF autoconfiguration 6-12 6.3.3 Edit PMDF configuration file 6-15 6.3.4 Run LONG_NAMES 6-20 6.3.5 Edit PMDF aliases file 6-20 6.3.6 Compile configuration 6-22 6.3.6.1 Compile maximum configuration 6-22 6.3.6.2 Install compiled configuration 6-23 6.3.7 Move LMD.COM 6-24 6.3.8 PMDF configuration steps to avoid 6-24 6.4 START UP PMDF ON ALL VAXCLUSTER NODES 6-27 6.5 UPDATE BITNET REGISTRATION 6-28 6.6 REGISTER DOMAIN GATEWAY WITH BITNIC 6-30 6.6.1 Tags in DOMAIN NAMES 6-32 6.6.2 Registering an Internet domain name with BITNIC 6-33 6.6.3 Registering a new domain name with BITNIC and the DDN NIC 6-35 6.7 SUBSCRIBE TO RELEVANT NETWORK DISCUSSIONS 6-38 6.7.1 Subscribing to LISTSERV lists 6-39 6.7.2 Subscribing to Internet discussions 6-41 CHAPTER 7 ON-GOING MANAGEMENT OF BITNET NODES 7-1 7.1 INITIALLY AND WHEN ADDING NEW USERS 7-1 7.1.1 Assigning user names 7-2 7.1.2 User training 7-2 7.2 CONSTANTLY 7-3 7.3 WEEKDAYS 7-4 7.3.1 Review JANTIDY output 7-4 7.3.2 Dispose of files sent to POSTMASTER 7-4 7.3.3 Read mail to POSTMASTER 7-5 vi Contents 7.3.4 Check PMDF channel queues 7-5 7.3.5 Check PMDF batch queues 7-6 7.3.6 Read relevant network discussions 7-6 7.4 MONTHLY 7-6 7.4.1 Install Jnet routing tables 7-6 7.4.2 Build mailer tables 7-7 7.5 WHEN CHANGING SYSTEM CLOCK 7-7 7.6 MANAGEMENT ACTIVITIES WITH NO REGULAR SCHEDULE 7-8 7.6.1 Update Jnet and PMDF configurations 7-8 7.6.2 Modify software when SCSNODE names change 7-8 7.6.3 Adjust queues when upgrading to VMS V5.5 7-8 7.6.4 Respond to mail from NETSERV 7-9 APPENDIX A ADDING AN INTERNET CONNECTION TO A BITNET NODE A-1 A.1 ASSUMPTIONS FOR THIS APPENDIX A-1 A.2 OBTAIN A NETWORK NUMBER FROM THE DDN NIC A-2 A.3 REVIEW ACCEPTABLE USE AND OTHER POLICIES A-2 A.4 JOIN A CONSORTIUM OR ARRANGE FOR COMMERCIAL IP SERVICE A-2 A.5 INSTALL A PHYSICAL CONNECTION A-3 A.6 INSTALL AND CONFIGURE TCP/IP SOFTWARE A-3 A.7 ARRANGE FOR NAME SERVICE A-3 A.8 RECONFIGURE YOUR MAILER A-4 A.9 UPDATE DOMAIN NAMES A-4 A.10 ADJUST BITNET TOPOLOGY A-5 A.11 TRAIN USERS ON NEW SERVICES A-5 A.12 SWITCH TO INTERNET NEWS FEED A-5 vii Contents APPENDIX B OPERATING BITNET MAIL GATEWAYS B-1 B.1 MAIL GATEWAYS TO DOMAINS WITH MAILERS B-2 B.2 PROVIDING NAME SERVICE FOR CONNECTED DOMAINS B-3 B.3 OPERATING AN INTERBIT MAIL GATEWAY B-3 B.4 MAIL GATEWAYS TO MAIL-11 DOMAINS B-4 APPENDIX C MIGRATION FROM GMAIL C-1 INDEX EXAMPLES 5-1 Member entry from BITEARN NODES 5-30 5-2 UPDATE job to create a node entry in BITEARN NODES for a standalone VAX system 5-33 5-3 UPDATE job to create node entries in BITEARN NODES for a two-node VAXcluster system 5-33 6-1 Command procedure to initialize PMDF batch queues on a two-member VAXcluster 6-4 6-2 Command procedure to start PMDF batch execution queues on a two-member VAXcluster 6-5 6-3 PMDF configuration file for a BITNET node 6-16 6-4 PMDF alias file for a BITNET node 6-21 6-5 UPDATE job to register a mailer and Internet address in BITEARN NODES for a standalone VAX system 6-28 6-6 UPDATE job to register a mailer and Internet address in BITEARN NODES for a two-node VAXcluster system 6-29 6-7 Mail to DOMAINS@BITNIC to register the Arnold.Com domain with BITNET 6-34 6-8 Mail to DOMAINS@BITNIC to register the BostonCol.Edu domain with BITNIC and the DDN NIC 6-35 viii Contents FIGURES 1-1 Architecture of the BITNET mail application. 1-4 1-2 Sending BITNET mail by direct use of NJE software. 1-5 2-1 Steps to set up an operational BITNET node. 2-5 5-1 BITNET topology example. Large filled circles represent Principal Nodes. Open circles represent pseudonodes bearing Jnet cluster names. 5-7 TABLES 1 Minimum and assumed software versions for Digital VAX systems running VMS xiv 3-1 Campus-wide network name space example: Bay College 3-20 5-1 TCP/IP Products supported by Jnet TCP NJE 5-19 ix _____________________________________________________________________ Preface This Preface explains the objectives, intended audience, and structure of this book, describes the software environment for which this book is relevant, and explains the topographical con- ventions used. ___________________________________________________________________ Objectives This book is designed to help get the routing and transport of BITNET mail up and running on a Digital VAX system running VMS as quickly and as easily as possible, while complying with BITNET standards for mailers. It does not deal with the mail user inter- face, except for aspects specific to BITNET. The general approach is to provide BITNET-specific instructions for all the tasks required at a new BITNET site in the order that they are encountered. For continuing BITNET sites, where Network Job Entry (NJE) software is already installed but with no mailer, the reader can easily review the NJE configuration and continue with mailer configuration and installation. ___________________________________________________________________ Intended audience This book is addressed to the person or persons responsible for installation and ongoing management of the electronic mail ap- plication on a BITNET computer system. This person is called the Postmaster throughout this book. (This book also discusses an electronic mailbox and user name for the Postmaster, called POSTMASTER, in upper case letters, throughout this book.) xi Preface For large systems, Postmaster responsibilities can be shared by a systems programmer, a network manager, a user services consultant, and those with other job titles. For a small system, a single in- dividual may have all of these responsibilities as well as other, unrelated roles. For VAX/VMS systems, the Postmaster is usually the system manager. The Postmaster is assumed to be familiar with VMS management procedures and the use of VMSmail. Many of the tasks described here require access to privileged system functions and technical competence to manage the system and attached networks. Other tasks, such as responding to rou- tine requests for information from network users and monitoring the system for trouble, can be delegated to staff with ordinary privileges and less technical expertise. You are urged to dele- gate Postmaster duties, as appropriate to your system environment, so that important tasks are performed in a timely manner without overloading staff. Both local and remote BITNET users depend on the Postmaster to complete the required tasks to provide reliable mail service. No prior experience with BITNET is assumed. For BITNET links over other networks and mail gateways to other networks, such as SNA, DECnet, and TCP/IP networks, the reader is assumed to be familiar with the concepts and software required to install and manage those networks. ___________________________________________________________________ Structure of this book This book includes seven chapters and three appendices. o Chapter 1, Mailers on BITNET, introduces required networking concepts and explains the requirements for and benefits of running a mailer on a BITNET node. o Chapter 2, Overview of Setting Up a BITNET Node, provides an overview of the installation and registration steps covered in this book. xii Preface o Chapter 3, Planning System and User Names, suggests guidelines for choosing names for computer systems and user accounts on BITNET. o Chapter 4, Installing and Configuring Networking Software, reminds you to install DECnet-VAX and TCP/IP software if your system will participate in DECnet or TCP/IP networks, and highlights aspects of DECnet and TCP/IP configurations that affect NJE and/or mailer software. o Chapter 5, Installing and Configuring NJE Software, supplements Jnet documentation with BITNET-specific instructions for in- stalling and configuring Jnet software and registering systems with the BITNET Network Information Center. o Chapter 6, Installing and Registering a BITNET Mailer, explains how to install and configure PMDF in the BITNET context and how to register a mailer and a domain name for a BITNET node. o Chapter 7, On-going Management of BITNET Nodes, lists BITNET Postmaster responsibilities and provides suggestions for the on-going management of BITNET nodes. o Appendix A, Adding an Internet Connection to a BITNET Node, suggests steps to take when adding an Internet connection to a system that previously was connected to BITNET only. o Appendix B, Operating BITNET Mail Gateways, explains how to configure a system to act as a BITNET-Internet or BITNET-DECnet mail gateway. o Appendix C, Migration from Gmail, provides supplementary infor- mation for sites where GMAIL is used to send mail to Internet addresses. xiii Preface ___________________________________________________________________ Software environment and associated documents This book assumes that you will use specific software products to implement BITNET and its mail application, that you have or will install the latest version of each program, and that you intend to upgrade your software as new versions become available. For this book to be helpful, you must install at least the minimum version of each recommended software product. When making references to vendor software product documentation, the references are to a specific version, called the assumed version, unless another version is specifically referenced by version number. You should have the complete documentation for the installed version of the recommended product at hand when working through this book, since not all information in vendor documentation is duplicated here. For Digital VAX systems running VMS, the minimum and assumed versions of relevant software products are listed in Table 1. Table 1: Minimum and assumed software versions for Digital VAX __________systems_running_VMS_____________________________________ Minimum Assumed Vendor_and_product_name_________version___version_________________ Digital VMS Operating System V5.0 V5.5 Digital DECnet-VAX V5.0 V5.5 Joiner Jnet standard features V3.5 V3.5 Joiner Jnet link driver op- V1.1 V1.1 tions Innosoft_PMDF___________________V3.2______V4.0____________________ xiv Preface Unless stated otherwise, the minimum and later versions of soft- ware products discussed here function in substantially the same way. The commercial mailer software recommended here is PMDF, from Innosoft International, Inc. (Innosoft). You will need the follow- ing Innosoft publications to install and configure PMDF: o PMDF Installation Guide & Release Notes, Version 4.0 o PMDF System Manager's Guide, Version 4.0 Additional important information on PMDF, including software corrections, is released regularly on the PMDF network forum: Info-PMDF. Instructions for subscribing to Info-PMDF are given in Section 6.7.2 of this book. If you are missing any PMDF documentation, or need additional copies, contact Innosoft: 250 West First Street, Suite 240 Claremont, California 91711 U.S.A. Telephone: +1 (714) 624-7907, facsimile: +1 (714) 621-5319 BITNET: III@YMIR Internet: Service@Innosoft.Com Most BITNET member sites make NJE connections among VAX systems over DECnet networks, and between VAX systems and other types of BITNET nodes over binary synchronous communications (BSC) lines or TCP/IP networks. You will need to refer to the following publications of Joiner Software, Inc. (Joiner), to install and configure Joiner's Jnet NJE software and the required options: o Jnet Installation Guide, Version 3.4 o Jnet Manager's Guide, Version 3.5 o Jnet User's Guide, Version 3.5 xv Preface o Jnet BSC/370 Manager's Guide, Version 1.0 o Jnet TCP NJE Manager's Guide, Version 1.0 Additional important information on Jnet and its options is found in cover letters, software product descriptions, and release notes. Release notes are shipped in machine-readable format on the distribution media, and can be printed using the instructions in the cover letters. The cover letters and software product descriptions are shipped with the product documentation. If you are missing any of the required Jnet documentation, or need additional copies, contact Joiner: 450 Science Drive Post Office Box 5630 Madison, Wisconsin 53705-0630 U.S.A. Telephone: +1 (608) 238-4454, facsimile: +1 (608) 238-8986 BITNET: CSC@JOINER Internet: CSC@Joiner.Com This book assumes you have access to the VMS Extended Documentation Set, published by Digital Equipment Corporation (Digital) on paper and Compact Disk-Read-Only Memory (CD-ROM). To obtain Digital doc- umentation, telephone Digital at 1-(800)-DIGITAL in the U.S.A., or contact the Digital subsidiary or distributor in your country. For recommendations on which VMS publications are most relevant to the installation and management of NJE and mailer software, refer to the Preface of the Jnet Manager's Guide. See also the publication lists in the recommended software vendor documentation listed here for additional references on prerequi- site products, protocols, historical background, and other topics. xvi Preface ___________________________________________________________________ Conventions The following conventions are used in this book. New term This typeface in the text represents the introduction of a new term. User input In examples, boldface type indicates text that the user enters. UPPERCASE Uppercase letters in a command or UPDATE job represent text that you have to enter as shown. lowercase italics Lowercase italic letters in a command or UPDATE job indicate variable information that you supply. The Return key is not shown in syntax statements or in examples; however, you must press the Return key after entering a command or responding to a prompt. This book distinguishes between the installation and configuration of Jnet and PMDF software. Installation is a standardized process requiring little input from the installer, and moves the soft- ware from the distribution media to its place in the file system. Configuration is a more complex task requiring careful, individu- alized planning for each site, and results in the creation of data tables that enable the software to do useful work. Distinctions are also made between installation and post- installation, and between configuration (or autoconfiguration) and post-configuration. Installation and autoconfiguration are accomplished by running command procedures that prompt for input; post-installation and post-configuration consist of manual tasks that are not easily automated, such as editing a system startup command procedure. xvii Chapter 1 Mailers on BITNET You may have been asked to install and operate a "mailer" on your computer system. This chapter describes the transmission of mail on BITNET without the use of a mailer (direct transmission, Section 1.1), defines mailer and related concepts (Section 1.2), lists CREN requirements for electronic mail (Section 1.3), and at- tempts to provide a rationale for running a mailer (Section 1.4). 1.1 Direct Transmission of Electronic Mail by Network Job Entry On a computer system (or node) on BITNET, the mail application is supported by a specialized software system, called a mailer, which transfers mail among local users and applications and mailers on remote nodes. Mail is transferred between mailers using files in Batch Simple Mail Transfer Protocol (BSMTP) format and BITNET's built-in Network Job Entry (NJE) file transfer facilities. Before mailers were developed, a copy of every BITNET mail message was sent directly from the sender to each recipient as a separate NJE file. This approach has many disadvantages. Some of the most important ones are: Mailers on BITNET 1-1 o Only users and applications with directly reachable NJE ad- dresses can receive mail. This precludes sending mail to ad- dresses on other networks connected to BITNET by mail gateways. o Sending separate copies of a message to every addressee is wasteful of network bandwidth, central processor cycles, and disk space. This problem is compounded by the fact that there is no standardized group communication application on BITNET except those based on mail. o The NJE envelope, or tag, does not include the information needed for adequate error handling. o When no mailer is present to insulate users from mail trans- ports, end users must explicitly address mail to different networks, for example, BITNET and the Internet. Mailers al- low mail to be sent on different networks, simultaneously and transparently, from a single user agent. o Using NJE software directly for electronic mail increases the difficulty of adapting to new mail transport and user interface technologies. This causes problems when switching from other transports to NJE and again when switching from NJE to other transports. To avoid the serious disadvantages of direct NJE transmission of mail, the CREN Board of Trustees and its Technical Advisory Committee have mandated the use of mailer software for BITNET nodes that send or receive mail through INTERBIT mail gateways. There are three reasons to switch to mailer-based BITNET mail: 1. Almost every BITNET user uses the INTERBIT mail gateways at least one time, so the CREN Terms and Conditions of Membership and Affiliation requires you to install a mailer. 2. There are many technical advantages and no significant disad- vantages. 1-2 Mailers on BITNET 3. CREN has worked hard to make installing a mailer easy. The sponsorship of the development and distribution of this book is one way CREN is supporting the installation of BITNET mailers. 1.2 BITNET Mail Concepts To register a BITNET node means to describe it in a standard format in the data file BITEARN NODES[1], maintained by the BITNET Network Information Center (BITNIC) and the European Academic and Research Network (EARN) Central Office. Various methods are used to generate NJE routing tables based on BITEARN NODES that are ultimately installed on every BITNET system, enabling each system to originate or forward NJE data to any node on BITNET and its cooperating networks. A mailer, as used in this document, is software that transmits BITNET mail in BSMTP format to NJE users (human users, applica- tions, and devices). Normally, mail is transmitted between nodes by NJE file transfer between mailers on those nodes. Mailers have NJE addresses (eight-character usernames and eight-character node names), and can also exchange mail with NJE users by direct NJE transmission, if necessary. On BITNET, a mail gateway, as used in this document, is software that sends or accepts BITNET mail in BSMTP format on behalf of addressees with fully-qualified domain-style names (FQDNs). Some confusion can result from the fact that mailers and mail gateways are usually implemented as different aspects of the configuration of the same software, for example, PMDF on VAX/VMS systems. _____________________ [1] Mailers were first developed under IBM's VM operating system, and BITNET data files are still maintained under VM. This book refers to BITEARN NODES and other such files using VM file nam- ing conventions. VM file identifications have space between the file name and the file type, while VAX/VMS file specifica- tions have a period (.) in that position. For example, when a copy of BITEARN NODES is stored on a VAX system, it is called BITEARN.NODES. Mailers on BITNET 1-3 A fully-qualified domain-style name is a name of the form mail- box_name@subdomain.subdomain.domain. My own Internet address, Arnold@Eisner.DECUS.Org, is an example. For a formal definition of a FQDN, refer to Section 6 of RFC 822: Standard for the format of ARPA Internet Text Messages, shipped with PMDF in the documenta- tion subdirectory. The concepts of mailers and mail gateways are illustrated in Figure 1-1. The figure shows the content of a mail message, "BITNET mail is...", created by a user at node CALTECH, with mail headers prepended by the VMSmail user agent (UA), wrapped in a BSMTP envelope by the PMDF mailer (Mailer), and transmitted over the NJE network by Jnet (NJE). Intermediate nodes NODE1 and NODE2 transmit the NJE file to its final destination, node RICEVM1. At RICEVM1, the NJE tag is removed by RSCS, the BSMTP envelope is interpreted and discarded by the VM Mailer, and the Rice Mail user agent delivers the content and mail headers to the addressee, using the address from the BSMTP envelope. Figure 1-1: Architecture of the BITNET mail application. _____________________________________________________________________ WIDE _____________________________________________________________________ RICEVM1 serves as a mail gateway between BITNET and the Internet (an INTERBIT gateway). Therefore, RICEVM1's mailer could follow instructions in the BSMTP envelope to send copies of the message to Internet addressees instead of or in addition to delivering it to local users. This is shown in Figure 1-1 by the connection between the mailer and TCP/IP software within RICEVM1. 1-4 Mailers on BITNET Contrast Figure 1-1 with Figure 1-2, which illustrates BITNET mail directly over NJE. Without the use of mailers, CALTECH users would have to send a separate copy of the message to every addressee at RICEVM1, and there would be no option to send mail to Internet users using the Internet connection at RICEVM1. Figure 1-2: Sending BITNET mail by direct use of NJE software. _____________________________________________________________________ WIDE _____________________________________________________________________ To register a BITNET mailer means to describe it in a standard format in BITEARN NODES. While mailers and mail gateways installed around BITNET and its cooperating networks could theoretically generate the routing tables they use, called mailer tables, from BITEARN NODES directly, in practice most sites generate mailer tables from a much smaller file, XMAILER NAMES. XMAILER NAMES is automatically derived from BITEARN NODES each month and made available for automatic file distribution (AFD). (AFD is described in Section 6.3.1.) Mailer tables enable mailers and mail gateways running on BITNET nodes to route mail files (in BSMTP format) to other mailers for delivery to addressees on specific NJE nodes. To register a mail gateway means to describe it in a standard format in the data file DOMAIN NAMES, maintained by BITNIC for BITNET, EARN, and their cooperating networks. DOMAIN NAMES is much smaller than BITEARN NODES or even XMAILER NAMES. Like XMAILER NAMES, it is updated each month and available for AFD. Data in DOMAIN NAMES is also incorporated in mailer tables, to enable mailers and mail gateways running on BITNET nodes to send mail files (again in BSMTP format) to mail gateways for delivery to Mailers on BITNET 1-5 addressees at specific domain-style addresses. Some of these addressees are on the same NJE node as the mail gateway, and mail is delivered to the addressee locally. Others are on systems on non-NJE networks, and the non-NJE network (for example, the Internet) is used to deliver the mail to its ultimate destination. This book explains how to register PMDF to simultaneously serve as a mailer to handle mail for a BITNET node by its NJE name and a mail gateway to handle mail for a BITNET node by any of its domain names. For VAXclusters, these instructions explain how to sent up PMDF to handle all the nodes of the cluster, both collectively and individually. Appendix B explains how to set up and register PMDF as a mail gateway between BITNET and an external network like the Internet. 1.3 BITNET Technical Requirements Every CREN member and affiliate is required to implement CREN technical standards, and to make every effort to implement CREN technical recommendations. These requirements are part of the CREN Terms and Conditions of Membership and Affiliation, published as the file CREN TERMS, available from LISTSERV@BITNIC[2]. _____________________ [2] To obtain a copy of a file from LISTSERV, send the LISTSERV command GET filename filetype to the NJE address of the server as an interactive command or in the body of an electronic mail message, where filename is the VM filename of the file, and filetype is the VM filetype of the file. For example, to get the file CREN TERMS from the LISTSERV server on node BITNIC by sending an interactive message, enter $ SEND LISTSERV@BITNIC GET CREN TERMS. Most public BITNET files are available from the LISTSERV server on node BITNIC, operated by the BITNET Network Information Center. You must send LISTSERV commands from nodes registered in BITEARN NODES, or the server will not be able to send files to you. To obtain a file before your node is registered, ask 1-6 Mailers on BITNET It is one of the objectives of this book to help you meet these BITNET technical requirements: 1. Every BITNET node must accept mail for the local addresses POSTMASTER and POSTMAST, in any combination of upper and lower case letters. All such mail must be promptly delivered to a trained person who can solve network problems and answer inquires. 2. Every BITNET node that exchanges mail with an INTERBIT mail gateway must have mailer software compliant with the BSMTP specification, as defined in the files BSMTP LISTING[3] and BSMTP ADDENDUM, available from LISTSERV@BITNIC. Currently, PMDF and MX are the only BSMTP-compliant mailers for the VAX/VMS environment known to me. (Additional information about MX, a public domain mailer by Matt Madison, of Rensselaer Polytechnic Institute, is in the file MX INFO, available from LISTSERV@BITNIC.) _____________________ for the assistance of the TECHREP or Postmaster of a registered node adjacent to yours. [3] This file is provided as a print-type file with FORTRAN car- riage control of forms skipping, underscoring, and bolding. For VMS to properly recognize these controls, RMS attribute must be correctly set. These settings can be changed with Joe Meadows' FILE utility, available as a VMS_SHAR file from any NETSERV server. Request the FILE utility by sending the command GET MODATT COM to a NETSERV server, such as NETSERV@BITNIC. Receive the command procedure MODATT.COM into an empty directory and run it to unpack the files. Follow the instructions pro- vided to install the FILE utility, then enter $ FILE filespec /ATTRIBUTES=(FORTRANCC,NOIMPLIEDCC) to to set the correct RMS attributes on filespec for typing or printing. Mailers on BITNET 1-7 3. Official INTERBIT mail gateways must reject mail from the Internet that is addressed to BITNET systems without registered BSMTP mailers, and reject mail from systems without a regis- tered mailer if the mail is addressed to Internet addresses. 4. Official INTERBIT mail gateways must rewrite addresses cor- rectly: a. FQDNs must not be modified when going through the mail gateway in either direction. b. NJE addresses of the form username@nodename must be converted to domain-style addresses of the form user- name%nodename.BITNET@gateway_fqdn (the "%-hack" convention) on the way from BITNET to the Internet, where gateway_fqdn is the fully-qualified domain name of the INTERBIT mail gateway itself. c. Domain-style addresses of the form username%nodename.BITNET@gateway_fqdn must be converted to NJE addresses of the form username@nodename on the way from the Internet to BITNET. d. Addresses with "!" in username must be rejected, because the precedence of "!" and "%" in abc!mno%xyz.BITNET@gateway_fqdn is undefined. INTERBIT mail gateways accept NJE files tagged for the NJE address SMTPUSER@INTERBIT and interpret the BSMTP commands in the files to forward mail to Internet addresses. The requirements for INTERBIT mail gateways are documented in the file GATEWAY STANDARD, avail- able from LISTSERV@BITNIC. Official INTERBIT sites are listed in the file BITNET GATES, available from LISTSERV@BITNIC. Unofficial mail gateways, which include almost every BITNET system with an Internet connection, should strive to comply with requirements 3 and 4. 1-8 Mailers on BITNET Strictly speaking, if users at a node do not require the use of INTERBIT gateways, CREN does not require that node to run a mailer. However, it is practically impossible for active BITNET users to avoid using INTERBIT services. To avoid using INTERBIT services: o Local users must never send mail to Internet addresses over their BITNET connection (for example, with the GMAIL com- mand procedure, by Ed Miller, of Stanford Linear Accelerator Center). o Remote users must never attempt to address your local users through an INTERBIT gateway. o Users must never reply to old messages that traversed any Internet/BITNET mail gateway. Installing a mailer and not registering it is just as bad as not installing a mailer at all. The INTERBIT gateways will not know you have a mailer, so they will bounce your users' mail. The performance and usability benefits of installing a mailer will not be realized, for the same reason: remote nodes will not know they they can take advantage of the mailer protocols. In conclusion, there is really no practical alternative to cor- rectly installing and registering a mailer to meet your orga- nization's obligations under the CREN Terms and Conditions of Membership and Affiliation. 1.4 Benefits of Installing a Mailer Fortunately, there are several substantial, immediate benefits of running a mailer that offset the extra expense and system management effort. Mailers on BITNET 1-9 1.4.1 Mailers Ease Addressing User names longer than the NJE maximum eight characters are cor- rectly handled by mailers, since addresses are not confined to the eight-byte fields in the NJE tag. Domain-style host names can also be longer, and thus more meaningful, than eight-character NJE node names. Mailers allow the user of a single address format, such as the IN% format used by PMDF, for BITNET NJE-style addresses, BITNET domain-style addresses, and Internet domain-style addresses. Every correspondent can be addressed using the most natural form of ad- dress, and the reply function can be used with all messages. Local users need never be concerned with what network a correspondent uses. Many BITNET-only nodes (that is, nodes with no direct Internet connection) now send all mail with a domain-style return address, and this practice is becoming more widespread. If your node does not have a mailer, you must use the VMSmail SEND or FORWARD/EDIT commands to send to a different address than the return address, since the VMSmail REPLY command won't work. The resulting mail must go over Internet to an INTERBIT mail gateway for retransmis- sion to the final addressee, delaying the mail and wasting network and system resources. As an alternative to responding to BITNET domain-style addresses as if they are Internet addresses, each user can keep a personal table of BITNET and Internet equivalent addresses (or you can make one available to all users of your system), and manually look up each domain-style address to determine if the system is on BITNET only and its NJE address. Mailers perform this function automatically. Installing a mailer allows Internet and other global network users to address your users by a domain-style name instead of the more awkward "%-hack", for example, Postmaster@host.domain.Edu instead of Postmaster%host.BITNET@CUNYVM.CUNY.Edu. 1-10 Mailers on BITNET Even if you could train all your users when to begin addresses with Jnet% and SMTP%, and even if you could get rid of all the old mail on the network with INTERBIT return addresses, it makes much more sense to install a mailer. Certainly your users will prefer to use the common mail addressing scheme that a mailer permits. 1.4.2 Mailers Isolate Users From Network Changes If you drop your BITNET connection completely, you need a mailer even more. A mailer will allow local users to continue to use the BITNET addresses stored on your system without change, in mailing lists and in the return addresses of old mail. When a mailer is installed, switching from a BITNET-only connection to BITNET and Internet connections or a an Internet-only connection is transparent to the mail application. 1.4.3 Mailers Provide New Functions PMDF adds many important new functions to your mail network. It supports forwarding to lists, a feature removed from VMSmail at VMS Version 5.0. Other additional functions include store-and- forward reliability for VMSmail-to-VMSmail links, mail directory service, a simple file server, and optionally, facsimile capabili- ties for any mail user. Mailers send all the copies of a message routed to one system or gateway in a single NJE file. This conserves network resources, and thereby improves the delivery speed of mail for all users. Mailers on BITNET 1-11 Chapter 2 Overview of Setting Up a BITNET Node You should be able to work straight through this book, whether you are a new BITNET site starting from scratch or a continuing site reviewing your configuration and adding a mailer, whether you are already on the Internet or not, and whether your have previously installed TCP/IP software or are doing it at this time. (If you add an Internet connection later, see Appendix A.) Depending on your situation, you will be skipping certain sec- tions. So that your work goes as quickly and easily as possible, skip ahead when asked to do so. There are many ways to accomplish some effects. I have favored methods that give the highest level of network service, are eas- iest to modify or extend as your network evolves, and, if all else is equal, that are somewhat standardized by tradition. I've consulted a panel of BITNET experts in coming to these recommenda- tions, but where there is no clear consensus, I've made the final decision based on my own experience. Overview of Setting Up a BITNET Node 2-1 2.1 Assumptions This book makes the following assumptions: o You will connect or have connected one or more systems to BITNET. If you do not have or plan a BITNET connection, do not use this book. o You will use as few names (mail addresses) for your system as possible, to simplify the use of network mail for your users and their correspondents. o You will use Jnet and PMDF software. o If you have a VAXcluster system, you will configure all the nodes of the VAXcluster for BITNET (and if applicable, Internet) mail by running PMDF on every node, even though not all of the nodes run BITNET (or TCP/IP) software. o You will install at least the minimum versions of the soft- ware in Table 1. This book explains major dependencies on the installed versions of Jnet, PMDF, and VMS. o You will establish a domain name for your systems, which will be used for addressing mail by all your users and any corre- spondents on BITNET and Internet. o VMSmail will be the mail user agent for BITNET mail. This book will not attempt to describe the use of ALL-IN-1, MM, Pony Express, or other user agents. The following variations are accommodated in this book: o Your system may already be on BITNET, or you may be adding your BITNET connection at this time. 2-2 Overview of Setting Up a BITNET Node o Your system may be a single, standalone VAX system, a homoge- neous VAXcluster system, or a heterogeneous VAXcluster system. (This book explains these terms.) o If you have a VAXcluster system, you can either configure all your VAXcluster nodes as BITNET nodes, or only a subset of them (a subcluster configuration). o Your system may already be on a DECnet network, or you can set up a DECnet connection at the same time as your BITNET connection, or you can have no DECnet connection and no plans to add one. o Your system may already be on Internet, or you can set up an Internet connection at the same time as your BITNET connection, or you can reserve the option of connecting to the Internet at some future time. Other combinations of software can be configured to meet CREN requirements, but such configurations are outside the scope of this book. 2.2 Steps to set up a BITNET node With these assumptions in mind, the planning and implementation of your network connections are divided into four steps here: 1. Plan system and user names Planning is required for the names of systems, users, and other network entities because the names are very hard to change once they become established. System and user names are the primary elements of your configuration that are visible to remote network users. This step is described in Chapter 3. 2. Plan and install DECnet and/or TCP/IP software Overview of Setting Up a BITNET Node 2-3 If you intend to install DECnet or TCP/IP software, instal- lation of your mailer will be considerably simplified if you install the DECnet-VAX and/or TCP/IP software first. If DECnet and/or TCP/IP software was previously installed on your system, you'll need to review how it is configured in order to install your mailer. The actual installation and configuration of DECnet-VAX and TCP/IP software is outside the scope of this book. This step is described in Chapter 4. 3. Bring up BITNET In this step you plan your BITNET connections and services, install and configure Jnet software, bring up your BITNET links with adjacent nodes, and register your nodes with BITNIC. If Jnet software was previously installed on your system, you'll need to review how it is configured in order to in- stall your mailer. You may also be able to use some of the suggestions in Chapter 5 to streamline your Jnet configuration and/or improve the level of network service your users enjoy. If your BITNET node is new, you may have to wait for several weeks for your node to become known to other systems on BITNET. You may be able to continue with the configuration of your mailer if you have an account on another BITNET node, if your system is already on the Internet, or if the Postmaster of another BITNET site is willing to help you obtain certain files. Install Jnet after TCP/IP and/or DECnet-VAX software, because Jnet is a network application that can be layered over TCP/IP or DECnet software. This step is described in Chapter 5. 4. Install and register a mailer and register a domain name 2-4 Overview of Setting Up a BITNET Node In this step you will install and configure PMDF using the information about your network connections you collected in the previous steps. You will also register your system's domain name through BITNIC (if it is not already registered) and update the BITNET node registration database to show your system's mailer and domain name. Install PMDF after NJE, TCP/IP, and/or DECnet-VAX software, because mail is a network application that is layered over over NJE, TCP/IP, or DECnet transports. This step is described in Chapter 6. Figure 2-1 shows the steps described in this book in graphical form. Figure 2-1: Steps to set up an operational BITNET node. _____________________________________________________________________ WIDE _____________________________________________________________________ Chapter 7 provides information on on-going management of your BITNET node. Overview of Setting Up a BITNET Node 2-5 Chapter 3 Planning System and User Names This chapter provides suggestions for naming, or reviewing the names of, your computer systems and users in the BITNET environ- ment. If the computer systems are on other networks as well, their names on those other networks must also be considered. This chapter does not deal with network topology. Network topology must be planned for each network in which your systems partici- pate. For suggestions on BITNET topology, see Section 5.1. 3.1 Starting assumptions for name planning This chapter assumes that your organization has joined BITNET by: o Completing a CREN Application for Membership or Affiliate Status o Receiving approval from membership or affiliation from the CREN Board of Trustees o Paying its CREN dues invoice Planning System and User Names 3-1 o Appointing institutional representatives: Member or Affiliate Representative, Technical Representative (TECHREP), and Information Representative (INFOREP) The remainder of this chapter is directed primarily to the TECHREP, whom I call "you" in this chapter. The TECHREP is re- sponsible for coordinating the BITNET names and topology for the organization. Before continuing, make sure you have received your TECHREP infor- mation packet from BITNIC. BITNIC mails this packet in hardcopy form upon receipt of the forms appointing you as TECHREP for your organization. 3.2 General considerations for network names Once a name comes into use for a system, user, or other network entity, the name spreads rapidly through the interconnected net- works of computers and people in the form of directory entries, return addresses, routes, and other network information. It is hard to change this information, in both computers and people, even using such devices as forwarding addresses and electronic "change of address" notices. Therefore, planning the use of net- work names saves time and effort because it reduces the future need to change names. Name planning should be done for all systems under your adminis- trative control at the same time, so as to have a coherent name system that will serve you for the foreseeable future. Authority for names should be clearly vested in an organization- wide authority appointed by the organization's chief executive officer, such as the chair of a campus or corporate network group. Names of systems sometimes have organizational connotations, and the name authority for your organization should have the clout, sensitivity, and expertise to deal with both political and technical issues. 3-2 Planning System and User Names The names you approve should meet as many of these guidelines as possible: o Name should serve only for identification, and not imply ad- dressing or routing. The organization operating the system is often a useful source for a name. Within an organization, it is often useful to give systems easy-to-remember names from a series that is not otherwise meaningful to the organization, such as planet or wildflower names. o Each system can have many types of names, each conforming to different rules. Try to make as many of these the same as possible to minimize the number of names with which network users and managers must cope. o Names should be short for ease of typing and remembering. o Names should be globally descriptive. Since you will be partic- ipating in interconnected networks that span five continents, avoid names like "VAX1" and "PHYSICS" that give no clue to the owner or location of a system. o Avoid names that could be embarrassing to the organization or individuals. Names intended to be "cute" may seem silly or be offensive to those that speak other languages or have different cultural backgrounds. o Names should not make reference to the system's manufacturer or operating system. Network names often outlive the hardware and software platforms for which they were first established, and become inappropriate when they are re-used for a new system. o The name of the organization itself, "Harvard", for example, should only be given to centrally managed systems, such as the primary timesharing system for an academic computer center. Planning System and User Names 3-3 o Hierarchical name spaces, such as the domain names used for Internet hosts, should be wide and shallow, not deep. A naming system based on campus and host would easier to set up and re- quire less changes over time than one based on campus, college, department, system-type, and host. 3.3 Names for BITNET hosts BITNET hosts, or nodes, have at least two names: NJE and domain. (The domain name was formerly optional. This book assumes you will establish and register a domain name and exchange mail with the Internet community. If this assumption is not true, do not use this book.) In addition, VAX systems running VMS may also have Jnet cluster names, SCSNODE names, DECnet Phase IV names, Distributed Name Service names, VAX P.S.I. addresses, VAXcluster DECnet aliases, UUCP names, and synonyms or aliases for some of these. Insofar as possible, names for a system should all be the same, and VAXcluster names should be related to the names of systems that make up the cluster in an obvious way. 3.4 Suggested procedure for planning system names When planning your system and user names, seek help from your or- ganization's network naming authority, or if your organization has little experience in this area, from BITNIC and other applicable network information centers. 3-4 Planning System and User Names 3.4.1 Summary of name planning procedure If you are experienced at planning network names in global net- works, use the following checklist to make sure you have consid- ered all the relevant issues in naming your systems. If you have not previously reviewed your system names using the criteria in this chapter, follow the step-by-step instructions beginning with Section 3.4.2, and use the following checklist after you have completed all the instructions in this chapter. < P>an SCSNODE and DECnet-VAX names < F>r VAXclusters, plan a VAXcluster alias name < P>an domain names < I> necessary, register your domain < P>an NJE names < P>an reserved and general user names 3.4.2 Plan SCSNODE and DECnet-VAX names Of all the names a VAX system can have, perhaps the most difficult to change is the name used by Systems Communications Services, a component of VMS. An SCSNODE name is required, even for stand- alone VAX systems, if the system uses: o VAXcluster Software, o DSNlink service software, o License Management Facility V1.1 or later, or Planning System and User Names 3-5 o VMS V5.5 or later. The DECnet-VAX name of your system must match the SCSNODE name, and other names are often based on the DECnet-VAX name. Display the SCSNODE name with the System Generation Utility (SYSGEN): $ sysgen :== $sysgen $ sysgen show scsnode Parameter Name Current Default Min. Max. Unit Dynamic -------------- ------- ------- ------- ------- ---- ------- SCSNODE "BAYACB " " " " " "ZZZZ" Ascii If no SCSNODE name is defined, or if one is defined that does not meet the criteria in Section 3.2, take this opportunity to plan a better name. Because DECnet names must match SCSNODE names, and because DECnet names are known throughout the DECnet net- work and must not conflict with other DECnet names, coordinate any changes in SCSNODE names with the network name authority of your organization and the name space coordinator for your DECnet network. SCSNODE names must be six or less alphanumeric characters, one of which must be alphabetic. If your system is part of a VAXcluster system, review the addi- tional information in Section 3.4.3 before changing the SCSNODE name. Make a note of the SCSNODE names you plan to use. You will use the same names for DECnet-VAX software. You will set or modify these names, if necessary, when you work through Chapter 4. If your system runs DECnet-VAX Extensions and Digital's Distributed Name Service (DEC DNS), and you have elected to store the DECnet nodes database in DEC DNS, you can establish a DNS name for your system as well as a six-character DECnet node name. DEC DNS names are not currently used by mailer software, however. If you estab- lish a DEC DNS name for your system or VAXcluster, consider the 3-6 Planning System and User Names criteria in Section 3.2, and if possible, use a systematic mapping between six-character DECnet node names and DEC DNS node names. If your system does not participate in a VAXcluster and you do no anticipate that it will in the future, skip ahead to Section 3.4.4. Otherwise, continue with Section 3.4.3. 3.4.3 Plan a VAXcluster alias name If your system currently participates in a VAXcluster, or you plan that it will in the near future, you can give it an addi- tional DECnet name, called a VAXcluster alias. This is to your advantage if two or more systems provide a similar computing envi- ronment to a group of users, an arrangement called a homogeneous VAXcluster. (Recent versions of the VMS documentation set use the terms common-environment and multiple-environment instead of homogeneous and heterogeneous.) Every characteristic of the computing environment need not be identical to use a VAXcluster alias. For purposes of electronic mail, a VAXcluster is homogeneous if the systems share a common System User Authorization File (SYSUAF), VMSmail profile, and batch queues. In addition, you must set up mailer software for a homogeneous VAXcluster, as described in Chapter 6. Likewise, all of the systems in a VAXcluster need not serve the same users for a VAXcluster alias to be useful. If not all the systems in a cluster are identical, you can use an alias for a proper subset of the VAXcluster, sometimes called a subcluster. Consider establishing a VAXcluster alias for each group of two or more nodes that shares a SYSUAF and VMSmail profile. However, the configuration of multiple homogeneous subclusters on a single VAXcluster is beyond the scope of this book. Use the VAXcluster instructions in this book to configure a VAXcluster alias for only one homogeneous cluster or subcluster. Planning System and User Names 3-7 If you intend to use a VAXcluster alias, consider deriving the names of the systems in the VAXcluster from the alias by adding a modifying letter or digit. For example, the U.S. Chapter DECUS Symposium timesharing VAXcluster nodes could be named DECUSA, DECUSB, and so on, and the VAXcluster aliases could be DECUS. Make a note of the VAXcluster alias name you plan to use. You will set or modify the VAXcluster alias name, if necessary, when you work through Chapter 4. 3.4.4 Plan domain names Domain names are used to identify computer systems (called hosts) on the Internet for many applications, including mail, file trans- fer, and remote login. Domain names have proven to be so useful that they are now widely used for mail among non-Internet systems. This book assumes that you will follow CREN recommendations to es- tablish a domain name for your system and to use that domain name to identify your system when sending mail to Internet addresses and other domain-style addresses. The primary reference for the use of domain names on BITNET is the file DOMAIN GUIDE[1], available from LISTSERV@BITNIC[2]. If you do not have a copy of DOMAIN GUIDE, obtain a copy at this time. If necessary, ask someone at BITNIC or at another BITNET node to print a paper copy and mail it to you. Only one second-level domain may be registered for each organi- zation. All systems in an organization must have the same top- and second-level domains (for example, Berkeley.Edu). The Defense Data Network (DDN) Network Information Center (NIC), which over- sees the registration of domain names world-wide, recommends that second-level domain names be limited to twelve characters. Having a single domain can be a significant issue for large or- ganizations having many computers, since it forces the chief executive officer of the organization, who may care little for these matters, to delegate the naming of networked systems to a 3-8 Planning System and User Names single authority. No matter how difficult it may be for your or- ganization, however, this issue must be resolved internal to your organization before proceeding with the planning process! Using the criteria in Section 3.2, choose: o a top-level domain and a second-level subdomain for your entire organization, o third-level subdomains for each VAXcluster alias and third- level host names each host without a VAXcluster alias, and o fourth-level host names for each clustered system that has a VAXcluster alias. The third-level subdomain for each VAXcluster or stand-alone system can be the same as the VAXcluster alias or DECnet node name for that system. A fourth-level subdomain can be the DECnet node name of a clustered system or a modifier to VAXcluster alias to construct the DECnet node name. For example, the DECUS Symposium VAXcluster mentioned as an example in Section 3.4.3 could use the domain-style name Sympos.DECUS.Org for the entire VAXcluster, and A.Sympos.DECUS.Org, B.Sympos.DECUS.Org, and so on as the domain- style names for individual nodes DECUSA, DECUSB, etc. If a VAXcluster or stand-alone system is a the main computing facility for an organization, it could use only the second- and top-level names as its domain-style name. For example, the main computing facility for Indiana University of Pennsylvania is a VAXcluster. The cluster bears the institution's top- and second- level domains as its domain-style name: IUP.Edu. Your organization's lower-level domain names must be coordinated by your own organization's network name authority. If you are not that authority, contact the authority to request that the names you have choosen be assigned to your system. Planning System and User Names 3-9 Make a note of the domain-style name you plan to use for this system, and if applicable, the domain-style name you plan to use for the VAXcluster alias. You will register the second-level do- main when you work through either Section 3.4.5 or Section 6.6.3, depending on the circumstances, and you will set or modify the domain name for your system and, if applicable, its VAXcluster alias, when you work through Chapter 4. 3.4.5 Register a domain name with the DDN NIC Your organization's second-level domain name (or more simply, your domain) must be registered with the DDN NIC. One of three situations applies to your case: 1. If your domain is already registered with the DDN NIC, no further action is necessary. Skip ahead to Section 3.4.6. 2. If you do not anticipate connecting your organization to the Internet, at least for the foreseeable future, the BITNIC will register your domain with the DDN NIC on your behalf. Detailed instructions are provided in DOMAIN GUIDE. Register your domain through BITNIC with the DDN NIC when directed to do so in Section 6.6.3. For now, skip ahead to Section 3.4.6. 3. If you are establishing an Internet connection, or intend to do so in the near future, you must register your domain directly with the DDN NIC at this time. References to instructions are provided in this section. To register your domain, you will need access to an electronic mail account that can communicate with the Internet (either on an Internet host or on a BITNET node running mailer software that conforms to CREN technical requirements for the use of INTERBIT mail gateways). A guest account on the system to which you will be making your BITNET link, as suggested in the TECHREP information packet, is ideal. It is also possible to register a domain with 3-10 Planning System and User Names only paper correspondence, but the process is slower and more awkward. Send an empty electronic mail message to Service@NIC.DDN.Mil with the subject line "NETINFO DOMAIN-TEMPLATE.TXT". The DDN NIC document server will send the domain application template to you by electronic mail. For example: MAIL> SEND NL:/NOEDIT To: IN%"SERVICE@NIC.DDN.MIL" Subj: NETINFO DOMAIN-TEMPLATE.TXT MAIL> You will also find a copy of DOMAIN-TEMPLATE.TXT in DOMAIN GUIDE. Review the template file. For additional background material, review DOMAIN GUIDE and the RFCs that it references. If you still have questions, telephone the DDN NIC at the toll-free number listed in the template. To operate a domain, you must also arrange for name service. A name server is an Internet host that converts FQDNs to Internet Protocol (IP) numeric addresses that can be used by TCP/IP soft- ware. You must arrange for both authoritative (primary) and backup (secondary) name servers for your own domain. Usually an organi- zation operates a primary name server on one of its own hosts and recruits one or more organizations to run secondary name servers in geographically and logically remote parts of the Internet. Additional information on name service can be found in the RFCs referenced in DOMAIN GUIDE. Collect all the information requested by the template, edit the on-line copy of the template, and send it by electronic mail to Hostmaster@NIC.DDN.Mil. You should receive return mail acknowl- edging the registration of your domain (or rarely, notifying you of a conflict with a pre-existing registration) within about ten business days. Planning System and User Names 3-11 After you have received acknowledgment of your registration, you can use the Internet WHOIS application to check that the registration is in the DDN NIC's on-line database. For example, if you are the Postmaster for the domain ASU.Edu, to check your domain registration data from an Internet host running VMS and TGV MultiNet, enter: $ whois asu.edu Arizona State University (ASU-DOM) Tempe, AZ Domain Name: ASU.EDU Administrative Contact: Cantrall, Arthur (AC85) icsadc%asuic.bitnet@CUNYVM.CUNY.EDU . . . 3.4.6 Plan NJE names While the NJE name of a system need not have any relation to its other names, it will be easier for users and their correspondents to remember mail addresses if the DECnet-VAX and NJE names and the host portion of the domain name of a system are all the same. Likewise, if a system is part of a VAXcluster, the DECnet alias name and the Jnet cluster name should be the same. NJE user and system names must be eight or less alphanumeric or IBM national characters, and the first character must be alpha- betic. However, avoid the use of the IBM national characters ($, @, and #), as they are not permitted in other kinds of network names, and cause problems with some user interfaces. For other suggestions on planning NJE names, refer to Section 6.1, NJE Node Naming, in the Jnet Manager's Guide. Make a note of the NJE name you plan to use for this system, and if applicable, the NJE name you plan to use for the Jnet cluster, on the worksheet in Chapter 6 of the Jnet Manager's Guide. You will set or modify the NJE name for your system and, if applicable, its Jnet cluster name alias, when you work through 3-12 Planning System and User Names Section 5.4, and you will register the NJE names with BITNET when you work through Section 5.7. 3.4.7 Plan reserved and general user names There are user names that are conventionally used for specific purposes on BITNET nodes and Internet hosts. If you are setting up a new system, or if these names are not yet in use for any pur- pose, you should take steps to prevent them from being assigned to general users or otherwise used in ways that conflict with their conventional purposes. If these user names have been assigned for conflicting use, you should make every effort to reclaim them for their conventional purposes. Using these names for their con- ventional purposes only will make it easier for other network users and managers to deal with your system in the global network environment. 3.4.7.1 POSTMASTER and POSTMAST The Internet has long required that the reserved mailbox "Postmaster" be supported on every host, and that mail to Postmaster be forwarded to the person with management respon- sibility for the mail application on that host or for the entire system (RFC 822, Sections 6.3 and 3.4.7; RFC 1123, Section 5.2.7). In 1991, CREN adopted a standard that all BITNET nodes must simi- larly support a Postmaster address, and its eight-character trun- cation, "Postmast", in any combination of upper and lower case letters. For the full text of this standard, see the file POSTMAST STANDARD, available from LISTSERV@BITNIC. In order to serve its intended purpose, the Postmaster user on VAX/VMS BITNET nodes, called POSTMASTER (in upper case) in this book, must: o Be able to receive VMSmail. Planning System and User Names 3-13 The login directory for POSTMASTER must exist on a mounted and accessible device. If disk quotas are enabled, POSTMASTER must have ample disk quota. The SYSUAF flag DISMAIL must not be set for the POSTMASTER entry. o Not forward its mail to another system. Mail for POSTMASTER may be forwarded to another user on the local system so that mail to POSTMASTER receives prompt at- tention, but forwarding to a remote system could subject Postmaster mail to delivery failures due to failure of the underlying network. If POSTMASTER's mail is forwarded to another local user, it should be forwarded consistently at both the VMSmail and PMDF levels. The user to which POSTMASTER's mail is forwarded must be able to receive VMSmail. (See the preceding item.) o Never send automatic replies to received mail. Many automatic programs on the global networks, including mail- ers and other servers, send error reports to the Postmaster mailbox. To prevent mail loops, they depend on the Postmaster to not send automatic replies. POSTMASTER, or, if POSTMASTER's mail is forwarded to another local user, the user receiving POSTMASTER's mail, must not be an automatic server or employ any automatic response or filtering programs, including "va- cation" programs and DELIVER scripts that return or delete mail. During the installation of Jnet, you will be asked if a POSTMASTER user should be created. The PMDF autoconfiguration procedure asks the mail address of the Postmaster. Recommendations for these options are given in Section 5.3 and Section 6.3. For now, plan to reserve the POSTMASTER user for this special purpose, and determine, if applicable, where POSTMASTER's mail is to be forwarded. 3-14 Planning System and User Names 3.4.7.2 MAILER and SMTPUSER When a mailer is configured on your system, BITNET mail files sent to the mailer address are handled by PMDF. (See Section 1.2 for an explanation of the mailer concept.) MAILER is the recommended user name for mailers, because the name clearly indicates the purpose of the address and because of long historical precedent. You will forward mail for MAILER to PMDF's BSMTP interpreter at the PMDF level when you install and configure PMDF. There is no need to create a user name of MAILER in the SYSUAF, but you should verify that no MAILER entry exists now, and modify your account creation procedures to prevent the name MAILER from ever being used for any other purpose. To quickly discover any mail incorrectly sent to MAILER, forward MAILER's VMSmail to POSTMASTER. If for some reason PMDF should become disabled (for example, by upgrading Jnet and forgetting to reinstall PMDF's replacement for the Jnet command procedure LMD.COM), BSMTP mail from other mailers will be sent to your POSTMASTER account where the problem will immediately become apparent. From an account with the VMS SYSNAM privilege, enter: MAIL> FORWARD /USER=MAILER POSTMASTER Some sites use SMTPUSER for the mailer address. Take the simple precaution to reserve the SMTPUSER name at your site and forward any mail to it to the Postmaster also. MAIL> FORWARD /USER=SMTPUSER POSTMASTER 3.4.7.3 LISTSERV and NETSERV LISTSERV and NETSERV are BITNET server programs widely installed on IBM VM systems on BITNET. Versions are not currently available for VAX/VMS systems. Planning System and User Names 3-15 NETSERV provides file server functions for various data and pro- gram files including BITEARN NODES. NETSERV generates and dis- tributes the new routing tables each month for those nodes that have requested that service from BITNIC. It also provides direc- tory services for general users. You should not assign the user names LISTSERV and NETSERV to ordinary users, and you should not run server software under these user names unless the software is compatible with the IBM VM versions and interoperates with the VM versions as true peers. (Such software is not likely to be available for years, if ever.) Choose other names for servers that are not completely compatible peers of IBM VM LISTSERV and NETSERV. Verify that no LISTSERV or NETSERV entry exists in your SYSUAF now, and modify your account creation procedures to prevent the names LISTSERV and NETSERV from being used for any purpose in the future. 3.4.7.4 JOB JOB is the conventional user name for the batch input stream on IBM mainframes running MVS and VAX/VMS systems running Jnet. When installing Jnet, you can elect to set up a batch server, and JOB is the recommended and default name. Verify that no JOB entry exists in your SYSUAF now, and modify your account creation procedures to prevent the name JOB from being used for any purpose, other than the Jnet batch server, in the future. 3.4.7.5 SYSTEM, ROOT, and MAINT SYSTEM is the system manager user name on VAX/VMS systems, which Digital recommends reserving for software installations and system backup operations. IBM and Joiner recommend that SYSTEM be used in a similar way on IBM Application System/400 systems, as the User ID for the system operator, QSYSOPR. 3-16 Planning System and User Names On IBM mainframes running VM or MVS, however, SYSTEM is reserved for addressing the system default printer and punch devices; mail sent to these addresses may be discarded. Nodal message records (NMRs, or simply "messages") to SYSTEM are treated as commands to the NJE software on the system (RSCS or JES). In the same way, Jnet treats to messages to SYSTEM as network commands to Jnet, and not as messages to the system operator. Because of these inconsistencies, take these precautions: o Do not send messages, files, or mail to SYSTEM on any BITNET node unless you know the operating system running on the node and the effect of your action. o Do not send messages, files, or mail from the SYSTEM account on your system to other BITNET nodes. Remote BITNET users may attempt to reach a knowledgeable user of your system to report a problem or ask a question by writing to the conventional system manager account for various operating systems: SYSTEM (for VAX/VMS), ROOT (for UNIX), or MAINT (for VM). Forward mail for these user names to the Postmaster for prompt and knowledgeable handling. From an account with the VMS SYSNAM privilege, enter: MAIL> FORWARD /USER=SYSTEM POSTMASTER MAIL> FORWARD /USER=ROOT POSTMASTER MAIL> FORWARD /USER=MAINT POSTMASTER Verify that no ROOT or MAINT entry exists in your SYSUAF now, and modify your account creation procedures to prevent the names ROOT and MAINT from being used for any purpose in the future. Planning System and User Names 3-17 3.4.7.6 PMDF and PMDF_USER During the installation of PMDF, you are asked if a PMDF or PMDF_USER entry should be created in the SYSUAF. PMDF is a non- privileged user that will own many PMDF files and under which certain PMDF jobs run. PMDF_USER is a privileged user required for the operation of the PMDF-FAX option. Do not confuse these users with the mailer user name, MAILER. You should not have these entries in the SYSUAF unless you have installed the related prod- ucts. Electronic mail should never be sent to these accounts. Verify that no PMDF or PMDF_USER entry exists in your SYSUAF un- less created by the PMDF or PMDF-FAX product installation proce- dures, and modify your account creation procedures to prevent the names beginning with "PMDF" from being used for non-PMDF purposes in the future. 3.4.7.7 General user names BITNET places limitations on user names. Although VAX/VMS supports user names of up to twelve characters, and while PMDF and other mailers can handle longer user names, only eight characters are supported for BITNET messages and file transfers. To minimize confusion among users of your system and their net- work correspondents, and to meet the requirements of the most restrictive user agent software used on BITNET, follow these rec- ommendations in assigning user names to general users of your system: o Limit user names to eight characters. If you are working with an existing system that already has users with longer user names, make sure no user name has the same first eight characters as any other user name. Reassign user names, if necessary, to meet this constraint. 3-18 Planning System and User Names o Construct user names of only letters and decimal digits, with the first character a letter. For example, do not include IBM national characters ($, @, and #), spaces, underscores, or hyphens. o Do not create a user name with same first eight characters as the name of an BITNET link (adjacent system) or NJE server running in your system. In the case of a conflict, the user must usually yield to a link, since the link takes its name from the adjacent system, and ordinarily you will have no control over the name assigned to other systems in the network. o If you run ALL-IN-1 Integrated Office System, assign each ALL- IN-1 user his or her own VMS account, and assign each user an ALL-IN-1 user name identical to his or her VMS user name. Blanks, used frequently in ALL-IN-1 user names, cannot be used in BITNET addresses with certain important BITNET software, including Jnet and LISTSERV. 3.5 Campus network example Bay College has a central timesharing VAXcluster of two timeshar- ing systems and ten workstations for academic computing, an IBM mainframe for administrative computing, two UNIX servers and a dozen UNIX workstations for computer science. The IBM system and the VAXcluster timesharing systems are on BITNET, the VAX systems are on a local DECnet network, and all systems are on Internet. The College President has designated the Vice President for Information and Communications Systems as the authority for cam- pus network names, who has delegated the development of a naming scheme and day-to-day assignment of names to the chair of the net- work council, a committee hosted by the academic computer center to coordinate campus networks. The council chair developed, and the council approved, the scheme for system names in Table 3-1. Planning System and User Names 3-19 Table_3-1:__Campus-wide_network_name_space_example:_Bay_College___ System___________BITNET___DECnet___Internet_______________________ IBM mainframe BAYADM Adm.Bay.Edu VAXcluster BAYACA BAYACA Aca.Bay.Edu VAX servers BAYACB BAYACB B.Aca.Bay.Edu BAYACC BAYACC C.Aca.Bay.Edu VAXstations ELVIS Elvis.Aca.Bay.Edu BOPPER Bopper.Aca.Bay.Edu EVERLY Everly.Aca.Bay.Edu ... ... UNIX servers Popcorn.CS.Bay.Edu Pretzel.CS.Bay.Edu UNIX worksta- Cracker.CS.Bay.Edu tions Cookie.CS.Bay.Edu ___________________________________...____________________________ Bay College allows system administrators to choose their own scheme for assigning user names, except: o names must consist of only uppercase letters and digits, and the first character must be a letter, 3-20 Planning System and User Names o no names on the same system may have the same first eight characters, and o ordinary user names may not be MAILER, JOB, ROOT, SYSTEM, or MAINT, or begin with POSTMAST. The POSTMASTER user name and its eight-character abbreviation POSTMAST is used on every system by an electronic mail coordi- nator, who, on the larger systems, checks mail many times a day. MAILER is reserved for the BITNET mail application, and ROOT, SYSTEM, and MAINT are (or are forwarded to) the mailbox of the system programmer for each system. JOB is the NJE name of the batch subsystem on the VMS systems and the IBM mainframe. Planning System and User Names 3-21 Chapter 4 Installing and Configuring Networking Software This chapter provides an overview of the installation of DECnet- VAX and TCP/IP software. You should install DECnet and TCP/IP software before installing Jnet and PMDF. Both Jnet and PMDF can use DECnet and TCP/IP network services, and the configuration of Jnet and PMDF is easier if the underlying networking software is already in place. 4.1 VMSINSTAL and autoanswer files VAX/VMS software from Digital, Joiner, and Innosoft, and VAX/VMS TCP/IP software from many vendors, is installed with the Digital- supplied installation procedure VMSINSTAL, in the directory SYS$UPDATE. When installing software, consider adopting the con- vention of documenting your installation by using the autoanswer option of VMSINSTAL and leaving the generated autoanswer file in the directory SYS$UPDATE. The autoanswer file contains all the questions asked during the installation and your answers, and the creation date of the file shows when the installation took place. Autoanswer files are also useful in reinstalling a specific version of a software product, should that ever become necessary. While a product's installation dialogue can be changed from one version to the next, having the dialogue from the installation of the previous version of the Installing and Configuring Networking Software 4-1 software can be helpful when upgrading. The installations shown in this book assume you are following this convention. 4.2 Changing SCSNODE names If necessary, change the SCSNODE name to the new value you planned in Section 3.4.2. To change the SCSNODE name and the corresponding numeric SCSSYSTEMID, edit the file SYS$SYSTEM:MODPARAMS.DAT, then run SYS$UPDATE:AUTOGEN.COM, as explained in Section 6.1 of the Guide to Setting Up a VMS System. It will be necessary to reboot your system to make the change effective. On a system in active use, changing the SCSNODE name is likely to cause problems in the operation of many software products. Try to make the change before the beginning of a business day, advertise widely that there will be a system change, and plan to spend the day reconfiguring software in response to problem reports. Here is a partial list of uses of SCSNODE: o SCSNODE and SCSSYSTEMID must be set in the file SYS$SYSROOT:[SYSEXE]MODPARAMS.DAT. There is a separate MODPARAMS file for each system in a VAXcluster. o SCSNODE is used by the License Management Facility to control which systems may load software licenses. Check the /INCLUDE and /EXCLUDE qualifiers in the license database for the changed SCSNODE. A license for VAX-VMS should always be affected. o The SYSMAN STARTUP database uses SCSNODE to enable or disable the running of startup command procedures. o Jnet uses SCSNODE as part of the name of the root directory tree (or trees, if you use a split Jnet device). If Jnet is already installed, change these names manually, or reinstall Jnet with VMSINSTAL, to use the new SCSNODE name. 4-2 Installing and Configuring Networking Software o The DECnet-VAX executor name (node name) of your system must match the SCSNODE name. If DECnet-VAX is already configured, change the DECnet-VAX executor name manually, or reconfig- ure DECnet-VAX with SYS$MANAGER:NETCONFIG.COM, to reset the executor name to match the SCSNODE name. o If you are running VAXcluster Software, the SCSNODE name is used to qualify the device names in your system configuration. For example, if the SCSNODE name is BIOLAB, disk devices will have the names of the form BIOLAB$Ddcu. Many software products create startup and other command procedures at installation time that contain these device names. Use the SEARCH command to search for the old SCSNODE name in command procedures in the directories in the search list SYS$STARTUP, and edit the procedures to change the device names. o DECnet node names, which should match SCSNODE names, are used in the startup procedures for DECwindows (see SYS$MANAGER:DECW$PRIVATE_ APPS_SETUP.COM) and DSNlink (see SYS$STARTUP:DSN$STARTUP.COM). Edit these files to change the names. o Batch queue names are often qualified by node names, and are often initialized to run or autostart on specific nodes with the /ON or /AUTOSTART_ON qualifiers. Examine all queues, create any necessary new queues, make any changes required to existing queues, and delete queues with obsolete names. When you have rebooted your system and run for a weekday without any reports of problems caused by changing the SCSNODE name, you can turn your attention to the configuration of DECnet-VAX software. Installing and Configuring Networking Software 4-3 4.3 Configuring DECnet-VAX DECnet-VAX is a VMS system integrated product, that is, it is shipped and installed with the VMS operating system. No installa- tion is required. You must, however, have a DECnet-VAX license to use the product. To enable the use of DECnet-VAX software, register the license by entering the information on the Product Authorization Key (PAK) into the license database, as explained in the VMS License management Utility Manual. For the most straight-forward DECnet-VAX configurations, you can configure your system automatically, as described in Section 3.3.2.2 of the Guide to DECnet-VAX Networking. If you will have a VAXcluster alias name for this system, manually define it us- ing the commands in Step 9 of that section. Use the node name and VAXcluster alias name you selected in Section 3.4.2 and Section 3.4.3 of this book. If you will install and configure DECnet-VAX software on this system, do it before installing and configuring Jnet, described in Chapter 5. The installation and configuration of DECnet-VAX software is outside the scope of this book. 4.4 Configuring DECnet-VAX Extensions DECnet-VAX Extensions is optional software that can be installed with DECnet-VAX V5.4 or later to provide certain Open Systems Interconnect (OSI) functions in the context of a DECnet net- work. As of this writing, the only reason to install DECnet-VAX Extensions to support BITNET or Internet networking is to support BITNET links over OSI sessions with Digital's OSI Application Kernel (OSAK) product. The configuration of BITNET or TCP/IP applications over OSI networks is outside the scope of this book. If you require DECnet-VAX Extensions for your configuration, you can install it now or at any time in the future to support emerging OSI applications. 4-4 Installing and Configuring Networking Software 4.5 Configuring VMSmail If this system is a member of a homogeneous VAXcluster, you should set three flags to control the delivery of VMSmail. Include the command $ DEFINE/SYSTEM/EXEC MAIL$SYSTEM_FLAGS 7 in the command procedure SYS$MANAGER:SYLOGICALS.COM. Defining this logical name bypasses DECnet for mail delivery within the VAXcluster, announces the arrival of mail on all VAXcluster nodes, and includes a time stamp in new mail announcements. If this system is not part of a homogeneous VAXcluster because it does not share a SYSUAF or VMSmail profile with any other system, or because the systems in the VAXcluster are not all running PMDF, you must set MAIL$SYSTEM_FLAGS to an even number (4 or 6 is recommended) or leave the logical name undefined. For further information on the settings of these flags, see Section 9 in the VMS Mail Utility Manual. 4.6 TCP/IP installation and configuration You may require TCP/IP software on your system to participate in the Internet or a TCP/IP network internal to your organization. For BITNET, your TCP/IP software may have two purposes: o You may want to make you BITNET link over an Internet connec- tion, using the BITNET II or TCP NJE protocol to save on the cost of a dedicated leased line for BITNET purposes. This con- figuration requires that you use TCP/IP software supported by Jnet TCP/NJE. o You may want to send electronic mail to Internet addressees di- rectly over an Internet connection, using the Internet standard Installing and Configuring Networking Software 4-5 Simple Mail Transfer Protocol (SMTP) protocol. This configura- tion requires that you use TCP/IP software supported by PMDF. By using software that is compatible with both Jnet TCP NJE and PMDF, you can use your TCP/IP software for both of these purposes simultaneously, a common and flexible arrangement. Jnet TCP NJE V1.1, the version current when this book was pub- lished, supports these TCP/IP software products: o Carnegie Mellon University CMU-TEK IP/TCP o Digital VMS/ULTRIX Connection (also known as UCX, and renamed TCP/IP Services for VMS beginning with V2.0) o Network Research FUSION for VAX/VMS o TGV MultiNet o The Wollongong Group WIN/TCP for VMS Consult Joiner for the most current information on TCP/IP prod- ucts compatible with Jnet TCP NJE, including applicable versions, support recommendations and limitations, and vendor contact ad- dresses. PMDF V4.0, the version current when this book was published, supports these TCP/IP software products: o Carnegie Mellon University CMU-TEK IP/TCP o Digital VMS/ULTRIX Connection o Network Research FUSION For VAX/VMS o Novell Excelan TCP/IP o Process Software TCPware 4-6 Installing and Configuring Networking Software o Tektronix TCP/IP o TGV MultiNet o The Wollongong Group WIN/TCP for VMS Consult Innosoft for the most current information on TCP/IP prod- ucts compatible with PMDF, including applicable versions, support recommendations and limitations, and vendor contact addresses. Since most TCP/IP networks are eventually connected to the Internet, you should install your TCP/IP software in a way that allows you to take advantage of an Internet connection in the future, even if you don't plan to connect to the Internet imme- diately. To prepare for eventual connection to the Internet, you should: o Apply for a network number and register a domain name with the DDN NIC. o Install TCP/IP software that conforms to all the applicable Internet standards, as documented in RFCs. o Use your assigned network number and registered domain name in the configuration of your hosts. o Use fully-qualified domain names (for example, Stat.Wisc.Edu) instead of short-form names (for example, Stat), and train your users to do the same. If your organization has more than one department that maintains its own computers (for example, a computer science department, an engineering school, administrative data processing, and an academic computer center) but no strong tradition of central network management, check with each such department to determine whether that department has already registered a domain name for your organization or been assigned a network number by the DDN NIC. See Section 3.4.4 for additional information on this step. Installing and Configuring Networking Software 4-7 Whether you have already installed TCP/IP software but must change the domain-style name you are using, or are installing TCP/IP software for the first time, set the host name of your system to the new value you planned in Section 3.4.4 and registered with the DDN NIC in Section 3.4.5. Follow the instructions for your TCP/IP software to set the host name of your system. If another name has been widely used on the Internet for your system, you may want to configure your software to advertise that name as a synonym, or host alias, but be certain that your software is using your registered, fully-qualified domain name as its official host name. Because the Internet rules require you to have a Postmaster mail- box, your TCP/IP software may require you to specify what VMS user is to receive mail addressed to the SMTP Postmaster mailbox. To facilitate the delegation of Postmaster duties, specify that such mail is to be sent as VMSmail to VMS user name POSTMASTER. If your system is a member of a homogeneous VAXcluster and your TCP/IP software permits it, configure the domain-style name of the VAXcluster as the official host name of your system, and configure a specific domain-style name as a host alias name for your system. If your system will be on both BITNET and the Internet, consider operating an INTERBIT mail gateway. Information on running an INTERBIT mail gateway is provided in Section B.3. If you will install and configure TCP/IP software on this sys- tem, do it before installing and configuring Jnet, described in Chapter 5. The installation and configuration of TCP/IP software is outside the scope of this book. 4-8 Installing and Configuring Networking Software Chapter 5 Installing and Configuring NJE Software This chapter provides suggestions for the BITNET transport layer of your network, which uses Network Job Entry (NJE) protocols. This book provides supplementary information on running Jnet in the BITNET environment, and is not intended to replace Jnet documentation. If you are unfamiliar with Jnet, read Chapter 1, Introduction to Network Job Entry (NJE), in the Jnet Manager's Guide. For additional background, see the references in the Preface of that book. 5.1 Plan BITNET topology In this section you will plan the topology of computer system participating in BITNET, called nodes, and the logical connections among them, called links. 5.1.1 Selecting systems to participate in BITNET The first decision in planning the BITNET topology for your or- ganization is to determine which systems will be BITNET nodes. Systems that run NJE software and are listed in the BITNET routing tables are BITNET nodes. Installing and Configuring NJE Software 5-1 There is no separate charge to CREN members for adding nodes to BITNET, and BITNET communications within an organization are often over existing DECnet or TCP/IP networks, so the main cost of adding additional systems to BITNET may be Jnet software licenses. In determining whether to put a specific system on BITNET, an organization must balance the costs with the expected benefits. The benefits of BITNET, or any other network, are network services received by users. Electronic mail is perhaps the most valuable service BITNET offers, but when mailers are used, mail can be carried over DECnet, TCP/IP, and NJE networks transparently to users, so adding direct BITNET connectivity does not normally increase electronic mail services to a system running PMDF and already on a DECnet network or the Internet. The added value of BITNET comes from non-mail services. In addition to electronic mail, BITNET services include: o Sender-initiated, password-free file transfer o Interactive commands and messages o Remote printing o Remote batch job execution o Applications built on the generic services above, such as group communication and automatic file distribution with LISTSERV Additional information about these services is available from CREN and Joiner, and some of these services are used in this book for the on-going management of Jnet and PMDF. Avoid putting single-user systems on BITNET. Users of workstations and personal computers can get direct access to BITNET services by using terminal emulation to log into a timesharing system or server with the DECnet SET HOST command, LAT Connect command, or TCP/IP TELNET application. By not putting single-user systems on BITNET, you will conserve BITNET's limited address space, save 5-2 Installing and Configuring NJE Software resources on every BITNET node by reducing the size of the BITNET routing tables, and free resources on the single-user system that would be consumed by running NJE software. There are several common exceptions to this guideline: o VAXstations used as network management consoles can benefit from running NJE software so as to more closely monitor BITNET traffic and link status. o VAXstations used as BITNET wide-area routers must run NJE soft- ware. This arrangement is used in the Texas Higher Education Network, THEnet. o VAXstations that are members of homogeneous VAXclusters can be configured to run Jnet with little management overhead, at little or no license cost (because of Joiner's ClusterWide license pricing), and without increasing the size of the BITNET routing tables. (Running Jnet on VAXcluster members without registering the NJE names of those systems in the BITNET tables is beyond the scope of this book, however.) In general, put only timesharing systems and servers on BITNET, and train users in BITNET applications to get a rapid return on investment in Jnet licenses. Another approach may appear, at first, to be more cost-effective: grant users needing BITNET services accounts on a single time- sharing system on BITNET, and require that they log into guest ac- counts on the BITNET node from their home system to access BITNET services. When the number of BITNET users grows to a critical mass on another timesharing system, those users can can be asked to raise the money for additional Jnet licenses. The disadvantage of this approach is that users may never see the benefits of non-mail BITNET services, and so the potential of BITNET in the organi- zation may never be realized. This is the reason that public and university libraries are not funded by user fees. Installing and Configuring NJE Software 5-3 Even if significant BITNET use builds, users of guest accounts on the initial BITNET node must notify all their correspondents, including server applications such as LISTSERV, that they have moved to a new address. As explained in Section 3.2, this is a long, manual process. If, for any reason, not all members of an otherwise homogeneous VAXcluster participate in BITNET, users must take care when they log in to use a BITNET node if they intend to access non-mail BITNET services. This configuration is not recommended, because the usual motivation for setting up a homogeneous VAXcluster is to provide high availability while relieving users from concern about which member they are using. This book assumes that you will run Jnet on all the nodes of a homogeneous VAXcluster. If this is not the case, install Jnet as for a standalone VAX system, install PMDF as for a VAXcluster, and train your users to only attempt to use non-mail BITNET services from the system(s) on BITNET. 5.1.2 Principal Nodes To connect your VAX or VAXcluster system to the BITNET, you have arranged to make a BITNET connection with another organization and have agreed on a transport protocol with technical representatives of that organization. If the system which you are connecting or have connected to BITNET has a connection to another BITNET member or affiliate, or is on the BITNET route between two of your organization's systems with such connections, the system is a Principal Node and must meet the requirements for Principal Nodes in the CREN Terms and Conditions of Membership and Affiliation. The first system on BITNET at a member or affiliate is always a Principal Node. See the file CREN TERMS[1], available from LISTSERV@BITNIC[2], for more information. 5-4 Installing and Configuring NJE Software Designate either a large, production system or a dedicated routing system as Principal Node for your organization. Your Principal Node must meet the requirements for availability, and your links to other CREN members and affiliates must meet the requirements for BITNET bandwidth, that are listed in CREN TERMS. Ideally, your Principal Node should be available for forwarding BITNET traffic all the time, and have around-the-clock supervision by operators who can diagnose and repair any problems with BITNET connections. If you can't meet this recommendation, and if the TECHREP or other CREN representative of the adjacent CREN member or affiliate is trusted and experienced, consider giving that individual a privileged guest account, enabled for dial-in access, on your Principal Node. That individual can be an additional resource in resolving any BITNET forwarding problems that appear when your organization is not open for business. 5.1.3 Planning external connections If you have not yet determined where you will connect your organi- zation to BITNET, the considerations in this section may help. Arrange to connect your Principal Node as close to the center of BITNET as possible. With the regionalization of BITNET over a TCP/IP backbone, the regional BITNET II core of hub sites are the "center" of BITNET. Each of these hub sites, two per region, are connected to every other hub by BITNET links over high-speed (1.5 Mbits/second or faster) lines operated by NSFnet and regional affiliated mid-level TCP/IP networks. A summary of the BITNET II project may be found in the file BITNET-2 INFO, available from LISTSERV@BITNIC. That file references additional on-line files that provide further information on protocols, core topology, and other topics. Personalized advice on where to connect to BITNET can be obtained by telephone BITNIC and asking to speak to a member of the technical staff. Installing and Configuring NJE Software 5-5 Minimizing the number of forwarding nodes between your Principal Node and the nearest BITNET II core site has two advantages. First, transit time for NJE traffic is proportional to the num- ber of links in the path to the destination, and minimizing the number of links to the core minimizes the average number of links traffic from your node must traverse, and so improves the speed of delivery of files to and from your node. Second, each link is a potential point of failure, and minimizing the number of links be- tween your systems and the core means improved BITNET reliability for your users and their correspondents. If possible, put all links to other BITNET members and affiliates on the Principal Node. Otherwise, any other node you use for external connections, and any nodes in your organization that carry traffic between them, must also meet all the requirements for Principal Nodes. Figure 5-1 illustrates these planning considerations for external links. State University has three external links, to a BITNET II core node and two local colleges. All three external links are to the State University's Principal Node, so the resources of other campus systems are not consumed in routing traffic between the colleges and the rest of BITNET. It would benefit the colleges to connect directly to the BITNET II core node themselves, but in this hypothetical example, they cannot make direct connections to the BITNET II core because of the cost of wide-area links. 5-6 Installing and Configuring NJE Software Figure 5-1: BITNET topology example. Large filled circles repre- sent Principal Nodes. Open circles represent pseudon- odes bearing Jnet cluster names. __________________________________________________________________ __________________________________________________________________ When planning NJE links over underlying networks, including TCP/IP, DECnet, SNA, and OSI networks, consider the structure of the underlying network when deciding on NJE topology. In gen- eral, make connections to other nodes that are logically close, where logical distance is measured by the number of routers and the speed and cost of bandwidth between routers. For example, when looking for a "nearby" BITNET II core node on the Internet, follow the topology of your fastest Internet links until you reach the BITNET II core. 5.1.4 Planning intraorganization links The principle of minimizing the number of forwarding links, or hops, between nodes also applies when planning NJE topology within your organization. In general, it is best to use a star topology, with your Principal node as the hub. There are two main exceptions to this rule of thumb: you should establish a second hub on the other side of a slow or unreliable link, and each Jnet cluster system should be configured as a single node externally and a full mesh internally. See Section 5.1.5 for suggestions on the NJE topology within VAXclusters. Figure 5-1 also illustrates the planning considerations for in- ternal links. State University has two VAXclusters, a stand-alone VAX system, and an IBM mainframe. For optimal performance, each should be connected to the Principle Node directly, but that would be too costly because the mainframe and one VAXcluster are at a second campus, connected to the main campus by a slow link. The Installing and Configuring NJE Software 5-7 IBM mainframe serves as a secondary hub for the suburban campus, and any future BITNET systems on that campus should be connected to that mainframe. As with external connections, consider the structure of any under- lying network when planning NJE topology within your organization. At State University, if the two VAXclusters were connected by a DECnet network, VAXcluster B would have probably been a better choice as the hub node for the Suburban Campus. But since there is no DECnet connection between the campuses, the IBM mainframe was choosen as the hub because it has greater synchronous port capacity. 5.1.5 VAXcluster connections In a VAXcluster system, you should license and run Jnet software on all timesharing nodes, establish links over DECnet between every pair of nodes (a full mesh topology), and register all NJE nodes and a Jnet cluster name in BITEARN nodes. You will register the Jnet cluster name in BITEARN NODES as a node that is connected to every other node in the Jnet cluster. The pseudonode bearing the Jnet cluster name is shown as an open circle in Figure 5-1. If there are more than four NJE nodes in a Jnet cluster, consider registering only nodes with external connections and the Jnet cluster name in BITEARN NODES, and defining a subset of a full mesh of links within the Jnet cluster. A star topology of internal links centered on a node with all external connections is another common configuration. These advanced configurations are outside the scope of this book, however. 5-8 Installing and Configuring NJE Software 5.1.6 Link protocols Jnet supports links to other systems using many link protocols, and the protocols used on different links are independent. Select a protocol for each link based on compatibility with NJE soft- ware on the node at the other end of the link (the peer node) and requirements for underlying networks, specialized hardware, communications lines, and Jnet licenses. Running NJE over DECnet or TCP/IP networks and local area net- work (LAN) hardware provide the highest available performance, and should be used whenever possible. Over wide area links, communica- tions line costs become an overriding factor, and sharing existing connections by running NJE over existing TCP/IP, DECnet, or less commonly SNA or OSI networks is recommended. For new, BITNET-only connections, links over BSC lines often have the lowest initial cost for equipment and software. In general, use links over DECnet (DNA NJE links) within Jnet clusters and in all other cases where an underlying DECnet network is available. Choose links over TCP/IP (TCP NJE links) when making connections between VAX/VMS and UNIX or IBM VM systems over a campus-wide network or when connecting to the rest of BITNET if an Internet connection is available. If your organization is currently connected to BITNET by a ded- icated BSC line and to the Internet by a separate connection, an attractive option is to switch your external connection from the BSC link to a TCP NJE link over the Internet and terminate the lease on the dedicated BSC line to save money. This change should be undertaken with caution, particularly if funding for your Internet connection comes from another entity. Technical problems can also crop up in the first few months of using a new connection that makes a BSC backup route desirable. When planning links, work with the Postmaster or other technical staff for the peer node to agree on the NJE names your systems will use, the link protocols, and any link protocol parameters. Examples: Installing and Configuring NJE Software 5-9 o If multistreaming is available on both systems, you should use it to improve total throughput and throughput of small files, but you must agree on how many streams will be used. o There are several BSC link protocols, and there must be agree- ment on which one will be used. o If you will use TCP NJE, you must exchange IP addresses or domain names and TCP port numbers with the manager of the peer system. Work through the appropriate chapters of the Jnet Manager's Guide to determine which parameters must be set for each link, and which must be coordinated with the peer system. 5.2 Install BITNET transports You should have already installed DECnet and/or TCP/IP software, as directed by Chapter 4 and the documentation for the relevant software. If you are installing a BSC link, you must arrange for the instal- lation of a communications line, modems, and a synchronous port on a VAX system before you can install and configure Jnet BSC/370 link driver software. BSC NJE software is designed to be used with V.29 analog modems and dedicated communications lines, either privately owned or leased from a telephone company. Order a "full-duplex, Bell type 3002" circuit if you are leasing a telephone company line. Specify that you will be sending data at 9600 baud over the line. Unconditioned lines are usually sufficient within metropolitan areas, but D1 conditioning may be required for wide area links. Full-duplex circuits have four wires, two for sending and two for receiving. 5-10 Installing and Configuring NJE Software V.29 modems are relatively expensive and use mature technology. A second alternative is a Dataphone Digital Service (DDS) con- nection. Instead of modems, DDS lines use less expensive devices called data service units and channel service units, most often combined into devices called DSU/CSUs . Whenever ordering leased lines, determine both initial and monthly costs of both analog and DDS services and equipment before making a decision, because either type can be more cost-effective, depending on the specific situation. For links within a local calling area, a third alternative is V.32 or V.32bis dial-up modems. Such modems use two-wire dial- up circuits and the switched telephone network. Dedicating a switched business telephone line to a BITNET link may be much less expensive than a leased line, and V.32 modems are sold in volume to personal computer users, so they are much less expensive than V.29 modems. While Jnet BSC/370 has no software support for dialing these modems, many modem models can be configured to automatically dial a stored number when Jnet signals the modem that it is ready to communicate. Modem configuration is usually accomplished by attaching a terminal to the modem port and sending configuration commands to the modem as asynchronous data. When purchasing any type of modem for BITNET use, be certain that a full complement of diagnostic features, including indicators and testing functions, are provided. Testing and diagnostic features are very useful in the BITNET environment, but they are often omitted from modems designed to be sold into price-sensitive markets, such as to personal computer users. There are many different synchronous interfaces available for the members of the VAX family of computers. Consult the Jnet System Support Addendum for a current list of supported interfaces, and the Digital VAX Systems/DECsystems Systems and Options Catalog for which interfaces are supported on your VAX systems. If required for the interface and VMS version you will use, obtain and install Digital's Wide Area Network Device Drivers software. Then refer to Installing and Configuring NJE Software 5-11 the Jnet BSC/370 Manager's Guide for information on configuring synchronous interfaces for use by Jnet BSC/370. 5.3 Install Jnet and link drivers Jnet installation is a straight-forward process of unpacking files from the distribution save sets into the Jnet directory tree. Your primary decision is where to put the Jnet files. To allow easy movement of Jnet files from one disk to an- other as your configuration changes, consider defining the logical names MY_JNET_PERM_DEVICE and MY_JNET_TMP_DEVICE in SYS$MANAGER:SYLOGICALS.COM, as in this example: ... $ ! Put Jnet permanent files on DUA0: and transitory $ ! files on DUA4:. $ DEFINE/SYSTEM/EXEC/TRANS=(TERMINAL,CONCEALED) - MY_JNET_PERM_DEVICE $1$DUA0: $ DEFINE/SYSTEM/EXEC/TRANS=(TERMINAL,CONCEALED) - MY_JNET_TMP_DEVICE $1$DUA4: ... Then create a Jnet startup procedure, called MY_JNET_STARTUP.COM, that uses the new logical names, as in this example: $ DEFINE/SYS/EXEC JAN_DEVICE - MY_JNET_PERM_DEVICE:[JNET_PERM.] $ DEFINE/SYS/EXEC JAN_TMPDEVICE MY_JNET_TMP_DEVICE:[JNET_TMP.] $ @JAN_DEVICE:[JANCOMMON.SYS]JANSTART 'P1 In the example above, a different top-level directory is used for the permanent and temporary files, allowing you to set up this flexible file arrangement even if all Jnet files will be on the same disk device initially. This directory arrangement is recommended for all new Jnet installations. 5-12 Installing and Configuring NJE Software NOTE In these logical and file names, MY_ (or another string of your preference) should be used to avoid conflicts with logical names used by the Jnet software itself, now or in the future. If you keep the Jnet startup procedure in the directory SYS$COMMON:[SYS$STARTUP], you can use the SYSMAN utility to start Jnet at each system re- boot. To direct SYSMAN to execute the Jnet startup procedure in batch mode in the main layered product phase of the VMS startup procedure, enter: $ SYSMAN :== $SYSMAN $ SYSMAN ADD FILE MY_JNET_STARTUP.COM /PHASE=LPMAIN - _$ /MODE=BATCH /PARAMETER=P1:COLD If, at some later time, you need to move one of the Jnet directory trees to a different disk device, merely shut down Jnet cold (as explained in Section 16.1.1.4 of the Jnet Manager's Guide, edit the logical name definitions in SYS$MANAGER:SYLOGICALS.COM, manually redefine the two device logical names, move the directory trees with the VMS BACKUP utility, and restart Jnet. Before beginning the installation, determine whether there is a POSTMASTER entry in the SYSUAF. You must tell the Jnet instal- lation procedure whether the user entry already exists so the procedure can create it if necessary. The POSTMASTER entry created by the Jnet installation has system privileges. Handling files for other or nonexistent users is a privileged function, so if you already have a POSTMASTER entry in the SYSUAF for another purpose, but it does not have system privileges, you will have to reconcile your use of the POSTMASTER entry with Jnet's. If you want the Jnet installation procedure to make a new POSTMASTER entry, delete the existing entry, any POSTMASTER entry in the system rights list database, and the login directory and any other files belonging to the old POSTMASTER user. Installing and Configuring NJE Software 5-13 When you have prepared the device logical names and determined whether you have a POSTMASTER entry in the SYSUAF, install Jnet with VMSINSTAL according the directions in the Jnet Installation Guide. If you will be configuring a Jnet cluster, perform the installation on any fast or lightly loaded VAX system that will be a member of the cluster. Normally, you should choose your Principal Node, or the system that will have the external links to systems outside the Jnet cluster. Unless you are running a VMS version before V5.0, answer that you do not want to install the install the whole kit. Then install all the kit parts except VMS "V4 compatibility". (There are certain situations, explained in the Jnet Installation Guide, in which you will skip installing other kit parts.) If you will be configuring a Jnet cluster, reinstall Jnet on every other system that will be a node in the cluster. On the second and subsequent nodes, do not install the whole kit again, but install only the "node-specific root". When you have installed Jnet's standard features, install any optional link drivers licensed and required for system. You can install these on any system that will be part of a Jnet cluster. When you have installed all the required Jnet components, continue with the configuration of Jnet, as described in Section 5.4. 5.4 Configure Jnet Jnet configuration is the process of creating or modifying Jnet startup files to automatically set up the proper NJE servers and links for your organization each time Jnet is started. Chapters 5-14 of the Jnet Manager's Guide provide instructions for config- uring Jnet that will not be repeated here. The following sections provide additional recommendations for Jnet configuration in the BITNET environment. 5-14 Installing and Configuring NJE Software 5.4.1 Run Jnet autoconfiguration procedure There are two steps to running the Jnet autoconfiguration command procedure, JAN_LIB:JANCONFIG.COM: 1. Work through the Jnet Manager's Guide, choosing the options you will need and recording your choices on the worksheet provided in Section 6.2 of that book. 2. Run the procedure and enter the information you have collected as you are prompted for it. If more than one VAX system will run Jnet, first record your configuration choices for all nodes, then run the procedure to enter your choices on each node. This section provides configuration recommendations for VAX sys- tems running Jnet on BITNET, in the order that the relevant ques- tions are asked by JANCONFIG. The material in the Jnet Manager's Guide also applies to BITNET nodes, and is not repeated here. See the Jnet Manager's Guide for additional important information. Specific recommendations follow: o Number of NJE network nodes: Specify that there are 4000 nodes in your NJE network. This answer will cause JANCONFIG to request space for 4050 nodes in the Jnet section, allowing about 14% free space. The ample free space will accommodate future variation in the number of NJE names defined in BITEARN NODES without the necessity of checking free space each month. The resulting Jnet section will require 463 global pages. o NJE names: If your system participates in a VAXcluster system, JANCONFIG will ask you if you want to define a Jnet cluster name. In any event, it will prompt you for the NJE name of your system. Enter the names you previously planned in Section 3.4.6. Installing and Configuring NJE Software 5-15 o Time zone: Use numeric offsets from Universal Time (UT, once called Greenwich Mean Time, or GMT) instead of customary United States timezone abbreviations, even though they are permitted by RFCs 822 and 1123. Your systems will participate in a global net- work where there is no standard for timezone abbreviations, and where even common timezone abbreviations are ambiguous. Numeric timezone designations can be subtracted directly from the adjacent local time displayed in mail headers to get UT for easy correlation of message times. They are understood globally, and avoid the appearance of "Internet provincialism", the view that the United States is the center of the global networks and the rest of the world is somehow less important. Be sensitive and use numeric timezone abbreviations! Many references to do not clearly state whether positive off- sets from UT are east or west of the prime meridian. Positive offsets are east, so, for example, most of western Europe observes +0100 when Summer Time is not in effect. Negative offsets are west of UT, so the United States Eastern Time Zone observes -0500 when on Eastern Standard Time and -0400 when on Eastern Daylight Time. Enter the offset used by your system clock. If you change your system clock to observe Daylight Savings Time or Summer Time twice a year, you will edit the Jnet startup file JAN_ SYS:JANLINKS.JCP to show the changed offset at the same time, as explained in Section 7.5. o Local servers: Your organization should establish a security policy on whether to configure batch server on BITNET, as VMS batch jobs sub- mitted through Jnet's JOB server must contain VMS passwords, and the confidentiality of BITNET files is not assured. Never 5-16 Installing and Configuring NJE Software sending batch jobs over BITNET to run in privileged accounts unless you o trust the confidentiality of the file on forwarding nodes and know that your job will not be queued on those nodes for more than a few moments, or o can access the system interactively to change the password immediately after the job runs. Configure batch and printer servers only on Jnet cluster nodes with external links, because batch and printer servers are normally used only by remote BITNET users, and not by local VMS users. The servers can queue jobs to batch queues and printers running on any VAXcluster node, even nodes not running Jnet, if the nodes share a batch/print subsystem. (All the nodes of a VAXcluster normally share a batch/print subsystem, and this arrangement is required beginning with VMS V5.5.) If you expect local users to send files to your BITNET batch and print servers, configure the servers homogeneously on all the nodes of a Jnet cluster so that users can send jobs to servers at the Jnet cluster name from any Jnet cluster node. 5.4.2 Manual configuration tasks Chapters 7-14 of the Jnet Manager's Guide deal with configuration tasks on a component-by-component basis. That organization is most useful when modifying a component in your Jnet configuration, but can be awkward for new Jnet site, because it requires a number of editing sessions on each of several command procedures. As an alternative, new sites should consider working through Section 7.2 of the Jnet Manager's Guide, making all the changes require in each file (for example, JAN_SYS:LOGIN.COM) before going onto the next file. You can use Table 7-1 of the Jnet Manager's Guide as a check list of possible customizations and cross-reference to instructions for each change. Installing and Configuring NJE Software 5-17 Specific recommendations for postconfiguration follow. These recommendations supplement, but do not replace, the instructions in the Jnet Manager's Guide. 5.4.2.1 Edit JAN_COMMON:[SYS]LOGIN.COM Change the word "network" to "BITNET" in the message. 5.4.2.2 Test SYS$MANAGER:SYLOGIN.COM After editing the Jnet login command procedure (Jnet Manager's Guide, Section 7.3.1) and this file (Section 7.3.2), test the files carefully from a non-privileged account. All users execute these command procedures at login time, and incorrect protections, editing errors, and so on can prevent logins by non-privileged users. Remember to test batch jobs, too. 5.4.2.3 Use SYSMAN STARTUP instead of SYS$MANAGER:SYSTARTUP_V5.COM If you followed the recommendation in Section 5.3 to create a site-specific Jnet startup file in SYS$COMMON:[SYS$STARTUP] and enter the file in the SYSMAN STARTUP database, you do not have to edit SYS$MANAGER:SYSTARTUP_V5.COM (Jnet Manager's Guide, Section 7.3.3). 5.4.2.4 Edit JAN_SYS:JANLINKS.JCP and JAN_SYS:JANSTART.JCP Normally, these files are created by the Jnet automatic configu- ration command procedure, JANCONFIG.COM. For most configurations, there will be one CREATE command and several DEFINE/LINK commands in JANLINKS.JCP, and a START command in JANSTART.JCP for every DEFINE/LINK command in JANLINKS.JCP. You can manually edit these files to change links without running JANCONFIG, however, and manual editing is required to use certain features that are not supported by JANCONFIG. 5-18 Installing and Configuring NJE Software The line name for a TCP NJE link determines which TCP/IP prod- uct Jnet will attempt to use to make the TCP NJE connection. If you change from one TCP/IP software product to another, edit JANLINKS.JCP to change the line name, or execute JANCONFIG.COM to create a new set of startup files. The line name is normally the only Jnet setup parameter that must be changed when switching TCP/IP software products. See Table 5-1 for the line name keyword associated with each TCP/IP software product supported by Jnet TCP NJE V1.1. Table_5-1:__TCP/IP_Products_supported_by_Jnet_TCP_NJE_____________ Line_name_______TCP/IP_Vendor_and_Product_________________________ CMU Carnegie Mellon University CMU-TEK IP/TCP UCX Digital VMS/ULTRIX Connection FUSION Network Research FUSION TCP/IP MNETV20 TGV MultiNet V2.0 MULTINET TGV MultiNet V2.1 and later WIN_____________TWG_WIN/TCP_for_VMS_______________________________ Busy BITNET links should use file queuing by size, explained in the Jnet Manager's Guide, Section 3.5. Set up file queuing by size when you define links by editing JANLINKS.JCP. BITNET links can benefit from using six size categories, the maximum number, distributed so approximately equal numbers of files are transmitted in each category. Initially, establish at least three categories. Categories for files up to 100 records, 100 to 1000 records, and larger than 1000 records are suggested. Later, you can tune category boundaries using the size data Jnet collects in log files. Installing and Configuring NJE Software 5-19 If you implement multistreaming , which is also recommended for busy links, you must also implement file queuing by size and use one of the size category boundaries as the size threshold for "large files". 5.4.2.5 Defer the creation of JAN_SYS:JANROUTES.JCP Defer the creation of the route file (Jnet Manager's Guide, Section 7.4.3). The creation of the route file is discussed in Section 5.6. 5.4.2.6 Consolidate JAN_SYS:JANLOAD.COM JANLOAD.COM is also created by JANCONFIG, and its contents depend on the types of links in your configuration. It is normally used for set up synchronous interfaces for use by BSC links. If your configuration results in a JANLOAD procedure containing only the definition of the SYSGEN symbol, you can replace it by a new, empty JANLOAD procedure. If more than one system in a Jnet cluster uses the same JANLOAD procedure, you can reduce the number of startup files by moving one copy to JAN_COMMON:[SYS] and deleting the remaining copies. Do not delete all the copies of the empty JANLOAD procedure, or JAN_COMMON:[SYS]JANSTART.COM, the main site-independent Jnet startup file, will produce an error message when it attempts to run JANLOAD.COM. 5.4.2.7 Edit JAN_COMMON:[SYS]JANSITECOMMON.COM For all BITNET nodes, edit JANSITECOMMON.COM to assign the value 34 to JAN_SYSTEM_FLAGS. This has two effects. Setting bit 5 (adding 32 to the value) causes Jnet to limit responses to net- work commands to 50 lines of output, in compliance with an EARN traffic requirement. If this bit is not set, Jnet can send thou- sands of high priority nodal message records in response to the command QUERY SYSTEM ROUTES, blocking file traffic on the af- fected links (Jnet Manager's Guide Section 7.5.9). Setting bit 1 (adding 2 to the value) causes Jnet to broadcast file arrival 5-20 Installing and Configuring NJE Software messages to all members of a VAXcluster (Jnet Manager's Guide Section 8.2.4). This setting does no harm on standalone systems (single-node VAXclusters). Beginning with VMS V5.5, the batch/print subsystem does not re- quire queues to be initialized each time the system is rebooted. For systems running Jnet on VMS V5.5 or later and defining NJE symbionts, including JNET_JOBLOG (for batch servers), initialize queues manually only once, using commands like those provided as comments in JANSITECOMMON.COM. Leave the commands you used to ini- tialize the queues as comments in JANSITECOMMON to document your queue setup. To avoid errors caused by running NJE symbionts when Jnet is not started, do not define queues for NJE symbionts as autostart queues with the /AUTOSTART_ON qualifier. Remove the comment character (!) from the SUBMIT command to submit the JANTIDY job to a batch queue each time Jnet is started. The remaining recommendations in this section apply only to Jnet clusters. If you are not setting up a Jnet cluster, skip ahead to Section 5.4.2.8. Jnet versions before V3.5 did not support messages to the Jnet cluster name, causing endless confusion about NJE node names, especially regarding the use of remote servers such as LISTSERV. It was so difficult for Jnet cluster users to maintain LISTSERV subscriptions that it is a frequent recommendation to never use interactive commands to communicate with LISTSERV, but instead send all commands by mail. Beginning with Jnet V3.5, this precaution is no longer necessary, because Jnet clusters can be set up to use the Jnet cluster name for all inbound and outbound messages, files, and electronic mail. For more information, see the Jnet Release Information, Version 3.5, Sections 1.10 and 1.11. If you are configuring a Jnet cluster, it is strongly recommended that you take advantage of cluster-wide messaging. Installing and Configuring NJE Software 5-21 If you have a Jnet cluster but are not yet running Jnet V3.5 or later, it is strongly recommended that you upgrade to the latest version of Jnet to take advantage of cluster-wide mes- saging. Implement it by following the instructions in the Jnet Manager's Guide, Section 8.2.2 (for new nodes) or the Jnet Release Information, Version 3.5, Section 2.16.1 (for upgrading nodes). The master node for should be the node with all (or at least most) of the external connections. If you are forming a Jnet cluster by adding a systems to a stand- alone Jnet node (for example, changing from the single node ACME to two nodes, ACME1 and ACME2, with Jnet cluster name ACME), no mail address or server subscriptions will be affected by the change. If you form a Jnet cluster from nodes previously operating on the BITNET with separate names (for example, forming the Jnet cluster ACME out of nodes ACME1 and ACME2), some care is required to change server subscriptions. To change a LISTSERV subscription from a specific node name to a Jnet cluster name, the user must sign off the list using the specific node name and resubscribe to the list using the Jnet cluster name. See the Jnet Release Information, Version 3.5, Section 1.11, for an example. It is possible for the TECHREP or node ADMIN contact to change LISTSERV subscriptions on behalf of other users, and it may be possible to use LISTSERV jobs to obtain lists of subscribers to all lists on a specific node and change them to the Jnet cluster name in bulk, but these techniques are beyond the scope of this book. See the online documentation available from LISTSERV for additional information on List Owner commands and LISTSERV jobs. Jnet's use of the specific node name or the Jnet cluster name as the origin of files, mail, and messages is controlled by logical names. Before V3.5, Jnet used a separate logical name for every image that called the Jnet shareable image. Beginning with V3.5, these logical names are no longer required. Follow the instruc- tions in the Jnet Release Information, Version 3.5, Section 2.17, or the Jnet Manager's Guide, Section 8.2.3, to configure Jnet to use the Jnet cluster name for all files, messages, and mail. 5-22 Installing and Configuring NJE Software 5.4.2.8 Skip instructions for LMD.COM Jnet versions after V3.3 use the logical name JAN_SPOOL for the directory to contain transient files, while earlier versions used JAN_SYS. Section 7.6.2 of the Jnet Manager's Guide asks you to define a search list for JAN_SYS in JAN_SYS:LMD.COM so that PMDF or other alternative mail handlers can find inbound mail files. This step is not necessary when using PMDF V4.0 or later versions, because the replacement files LMD.COM and LMD.V35, supplied with PMDF V4.0, already incorporate this change. You will replace Jnet's version of LMD.COM with one of these files as you work through Section 6.3.7. 5.4.2.9 Edit and enable JAN_COMMON:[SYS]JANTIDY.COM The use of JANTIDY.COM, Jnet's nightly cleanup and monitoring procedure, is recommended for all BITNET nodes. Edit JANTIDY to define the symbols JANSYSTEM, JANMANAGER, and BATCHQUEUE. Setting JANMANAGER to POSTMASTER is recommended, to funnel all BITNET management mail through a single account for ease of forwarding to the responsible individual. You may wish to develop a specialized version of JANTIDY (with a different name) to run frequently, as often as six times an hour, on busy BITNET nodes. Such a job can check that all links are up, queues are not too long, and so on, and send mail to POSTMASTER or a REQUEST to the system operator if it discovers any problems. This is a common practice on IBM mainframes on BITNET, where such a program is called a line monitor. 5.4.2.10 Edit link parameter files Create link parameter files in JAN_SYS: to specify characteristics of specific links. Recommendations for BITNET nodes follow: o If you will use batch or print servers over wide areas (rather than just between NJE hosts at your institution), configure each server to send messages as a user rather than a link, so that command replies from the server won't appear to be from an Installing and Configuring NJE Software 5-23 unknown BITNET node. Specify MSG=USER in the parameter file for the link. If servers are installed homogeneously across a Jnet cluster, you can store a single copy of the parameter file in the common directory JAN_COMMON:[SYS]. See Section 9.4 of the Jnet Manager's Guide for additional information. o Use DECnet object numbers rather than object names for DNA NJE links. Such a configuration eliminates login failure notices from DNA NJE daemons attempting to connect before Jnet has been started on their peer systems, and can improve security by allowing the removal of the DECnet TASK object. See Section 11.2.1 of the Jnet Manager's Guide for additional information. o Always enable multistreaming on busy BITNET links when both peers permit it. For the best utilization of available band- width, especially on TCP NJE links, configure seven streams. For the most responsive transmission of electronic mail files, specify transmission algorithm F with a file size threshold larger than most electronic mail files. Use an initial setting of 1000 lines unless you have determined the size distribu- tion of files transmitted on the link. See Section 11.5.1 of the Jnet Manager's Guide for additional information on multi- streaming on DNA NJE links, or the corresponding sections of the documentation for BSC NJE, OSI NJE, SNA NJE, and TCP NJE links. 5.4.2.11 Edit SYS$COMMON:[SYSMGR]LAT$SYSTARTUP.COM If you have a VAXcluster configuration in which not all VAXcluster members are Jnet cluster nodes, and users use Local Area Transport (LAT) to connect to the VAXcluster for timesharing services, consider establishing a LAT service called "BITNET", available only on BITNET nodes, to which BITNET users may connect. Setting up such a service, and training BITNET users to connect to it when they want BITNET services, will reduce the number of times BITNET users log into a VAXcluster member and try to use BITNET services, only to find that they must log out and 5-24 Installing and Configuring NJE Software connect to another cluster member. This situation often arises when a VAXcluster includes both timesharing systems on BITNET and workstations that do not run Jnet, as suggested in Section 5.1.1. 5.5 Bring up BITNET link If you have agreed on link protocols, parameters, and names with the Postmaster (or NJE network manager) of your peer node, your link should come up to the Connect state as soon as both sides are started. For your first attempt to bring up the link, it is useful to make telephone contact with the Postmaster of the other node and start both ends of the link while you monitor the state of the link with the JCP command MONITOR/CONTINUOUS. If both sides go to the Active state but do not connect, you and the other Postmaster can immediately review the configuration, test the underlying network layers, trace the BSC line, or ini- tiate other troubleshooting procedures. If either side does not reach the Active state, you should review the configuration of that side of the link, and if necessary, call Joiner or the vendor of the peer's NJE software for support. See Chapter 18 of the Jnet Manager's Guide for more information on troubleshooting BITNET links. If the link goes to the Connect state, test the link by sending interactive messages. If that works, request the other Postmaster to send you a copy of the routing tables for the peer node. You will use them in Section 5.6. 5.6 Install BITNET tables NJE routing requires every node to have a table of all the nodes in the network. For your node to fully participate in BITNET, you must obtain a list of all the nodes in the network, and your node must be added to the routing tables of every other node. This section provides suggestions for setting up initial routing tables for your node or Jnet cluster. After you have registered Installing and Configuring NJE Software 5-25 your nodes with the BITNIC, you will automatically receive updated tables monthly. Section 5.7 gives instructions on registering your nodes so that they can be included in the routing tables generated for nodes throughout the network. Section 5.8 discusses how tables on other nodes are updated. To create an initial routing table for your first or only node, you must edit a list of BITNET nodes into a file of Jnet Control Program DEFINE/ROUTE commands and store it as JAN_ SYS:JANROUTES.JCP. If your peer node is a VAX running Jnet, this is a simple matter. Use your favorite editor to make the name of your peer node the route for every node in the network. Each line of JANROUTES.JCP must be of the form: DEFINE linkname /ROUTE=peername ! optional comment Normally, adjacent nodes (links) are defined in a different file than non-adjacent nodes (routes), so you must add to your routing tables routes for all the nodes that are adjacent to your peer node but not adjacent to your own node. These nodes may be listed as comments in the routing table you get from your peer. If not, send the NJE command QUERY SYSTEM LINKS to your peer if it is a VAX or IBM VM system, or telephone the Postmaster of the peer node, to get a list of adjacent nodes. For additional information on setting up initial routing tables, see Section 7.4.3 of the Jnet Manager's Guide. Install your ini- tial tables manually, as described in that section, and watch for messages caused by duplicate entries, typing mistakes, and other errors. If you are configuring a Jnet cluster, install the initial tables for the node with your first (or only) external connection and store it in the directory JAN_SPECIFIC:[SYS]. Create a second ta- ble, routing every node outside of your cluster through the first node, and store it in the directory JAN_COMMON:[SYS]. This single routing table can serve every node in your Jnet cluster except nodes with external connections. (If you configure a full-mesh topology among the nodes of a Jnet cluster and request routing 5-26 Installing and Configuring NJE Software tables for each node, you will find that the tables for nodes without external links are identical.) 5.7 Register BITNET nodes You are ready to register a BITNET node if the following prereque- sites have been met: o All the assumptions in Section 3.1 are fulfilled. o Connection to adjacent site is operational. o Initial routing tables are installed. 5.7.1 About the UPDATE procedure All the data about the BITNET network and all NJE cooperating networks are maintained in BITEARN NODES. Each data value is associated with or assigned to a specific tag (not to be confused with the tag of an NJE file). Each tag begins with a colon (:) and ends with a period (.). The information after the period is the value associated with the tag. To register a BITNET node, the TECHREP sends a file of update commands and tags to the update server at BITNIC to add or change information in BITEARN NODES. You should have copies of "BITNET Node Information Update Procedures" and "Required Info". Printed copies were sent as part of the TECHREP packet. They are also available as the files UPDATE PROCEDUR and REQUIRED INFO, from LISTSERV@BITNIC. (Don't use the older, now-obsolete REQUIRED INFO1.) These documents describe the procedures required to prepare and submit an on-line request to add, delete, or modify node and certain member information, and the minimum information required in a node entry to register a new node. Installing and Configuring NJE Software 5-27 This book does not attempt to discuss the usage of all defined tags. The defining document for BITEARN NODES tags is NEWTAGS DESCRIPT[3], available from LISTSERV@BITNET. NEWTAGS DESCRIPT is a comprehensive document that is normally more useful to develop- ers of BITNET servers than to TECHREPs, who just need to update BITEARN NODES, for which UPDATE PROCEDUR and REQUIRED INFO are better references. The steps for a new member or affiliate are: 1. Receive notification that a BITNIC staff member has created the member entry 2. Send initial update job to CONNECT@BITNIC with steps to: o add Postmaster people tag to member entry o register Principal Node 3. Send update jobs to UPDATE@BITNIC to create remaining nodes These steps are explained in the following sections. 5.7.2 Where to send UPDATE jobs When registering the Principal Node for a new members and af- filiates, the Principal Node is not yet in the routing tables at intermediate nodes, so acknowledgments, error messages, and other mail automatically sent by the update processor cannot be sent to the TECHREP's address. Update jobs to create the Principal Node at a new member or affiliate must therefore be sent to a special address, CONNECT@BITNIC. A BITNIC staff member checks these jobs manually and offers any needed assistance to the staff of the new site, submits the update on behalf of the new site, and reports the results back, by telephone if necessary. 5-28 Installing and Configuring NJE Software After the TECHREP's node (usually the Principal Node) of a new member or affiliate is registered in BITEARN nodes, the TECHREP can send UPDATE jobs directly to UPDATE's BITNET address: UPDATE@BITNIC. The update server can also communicate directly with the TECHREP. If a group of UPDATE job steps are interdependent, they should be sent in a single job. Then, if any step fails, no step will be ap- plied to BITEARN NODES. Independent job steps can be sent as sepa- rate UPDATE jobs or combined into multi-step jobs. In the follow- ing sections, UPDATE job steps are shown. If the TECHREP's node is connected to the network but not yet registered, send the UPDATE job to CONNECT@BITNIC. If the TECHREP's node is both connected and registered in BITEARN NODES, send the job to UPDATE@BITNIC for automatic processing. You should make every effort to submit UPDATE jobs, particularly the job to add your initial node, by the cutoff date for the first possible monthly update cycle. Currently the cutoff date is the fifteenth day of each month, including holidays and weekends, for the following month's tables. You will be able to manage your BITNET nodes much more effectively after the TECHREP's node is registered in BITEARN NODES and the TECHREP can receive files and electronic mail over the network. 5.7.3 Adding a Postmaster people tag Each BITNET member organization has a single member entry in BITEARN NODES, which contains information about the member as a whole, or common to all the member's nodes. The TECHREP may modify member entries. Example 5-1 shows how the node entry MN_ DECUS might look if DECUS became a BITNET affiliate. Installing and Configuring NJE Software 5-29 Example 5-1: Member entry from BITEARN NODES __________________________________________________________________ :node.MN_DECUS * Member-specific address/location information :MEMBER.Digital Equipment Computer Users Society, U.S. Chapter :A_MEMBER.SHR1-4/D32; 333 South Street; Shrewsbury MA 01545-4195 :TYPE.MEMBER :MEMDATE.19920101 :COUNTRY.US * Contact people for this member :DIR.P_SARNOLD :INFOREP.P_SARNOLD :TECHREP.P_SARNOLD :ADMIN.P_SARNOLD :P_SARNOLD.Stephen L. Arnold;ARNOLD@DECUS;+1 608 238.7835 __________________________________________________________________ You will need to specify a Postmaster for every node you regis- ter. The easiest way to do this is to add a people tag for the Postmaster to your member entry where it can be referenced in ev- ery node entry. If this has not been done, include the following step in an UPDATE job: MODIFY MEMBER membername :P_POSTMAST.POSTMASTER;POSTMAST@principalnodename;+n nnn nnn.nnnn where: 5-30 Installing and Configuring NJE Software membername is the name assigned to your member tag by BITNIC staff or as subsequently renamed one of your autho- rized member representatives. (It is not the same as the name of your organization or any of your nodes.) principalnodenisethe NJE name of your Principal Node (or its Jnet cluster name, if your Principal Node is a member of a Jnet cluster). +n nnn is the telephone country code, city or area code, nnn.nnnn and number of the person who currently holds the postmaster role. The country code for the United States, Canada, and the Carribean is 1. Follow the punctuation example for this tag exactly; no hyphens may be used. To add a postmaster tag to the DECUS entry in Example 5-1, the TECHREP would submit this update job: MODIFY MEMBER MN_DECUS :P_POSTMAST.Postmaster;POSTMAST@DECUS;+1 608 238.7835 As your organization adds additional systems to BITNET, you may want different Postmasters for different kinds of systems, for example, one for IBM systems and one for VAX/VMS systems. You can then define additional people tags. See UPDATE PROCEDUR for more information on people tags. NOTE Even if you do not create a people tag for the POSTMASTER mailbox and even if you do not register the POSTMASTER mailbox as an privileged ADMIN user at the member or node level, there must still be a POSTMASTER (and POSTMAST) mailbox on every BITNET node, as explained in Section 3.4.7.1. Installing and Configuring NJE Software 5-31 5.7.4 Registering a node There must be a node entry in BITEARN NODES for each NJE name to be in the routing tables. You create node entries in BITEARN NODES by sending ADD NODE job steps to UPDATE. This section describes information required to create a node entry for a VAX system running VMS and Jnet. A node entry contains data about a specific node on the network. Only the TECHREP or ADMIN at the member level may add new nodes for a member. If more than one person is to have authority to create nodes and make other changes to your member entry, create people tags for each authorized user and reference each people tag in the :ADMIN tag. This is a better security practice than having a privileged account that is shared by more than one person. So entries like: :P_SARNOLD.Stephen L. Arnold;ARNOLD@DECUS;+1 608 238.7835 :P_MGRACEFF.Mark Graceffa;GRACEFFA@DECUS;+1 508 467.4526 :P_KMEANY;Kevin Meany;MEANY@DECUS;+1 508 467.4346 :ADMIN.P_SARNOLD P_MGRACEFF P_KMEANY are better than :P_TECHREP.DECUS BITNET managers;TECHREP@DECUS;+1 608 238.7835 :ADMIN.P_TECHREP where Arnold, Graceffa, and Meany have access to the TECHREP account. While POSTMAST should be registered as the contact for problems with mailer software on your system as described in Section 6.5, do not routinely use the POSTMASTER account for managing your BITNET system, because certain software, including LISTSERV, ignores commands in mail from POSTMASTER or POSTMAST to avoid mail loops. Instead, use specific, personal accounts listed in the :ADMIN tag for management tasks. Nevertheless, it is permitted and recommended to register POSTMASTER (or POSTMAST) as the contact point for questions and recipients of routing table updates. 5-32 Installing and Configuring NJE Software A sample update job step to create an entry for a stand-alone VAX/VMS system is shown in Example 5-2. The UPDATE job steps to create node entries for a two-node VAXcluster with a Jnet cluster name are shown in Example 5-3. Features of the job steps are explained in the following list. Example 5-2: UPDATE job to create a node entry in BITEARN NODES for a standalone VAX system __________________________________________________________________ ADD NODE ARNOLD1 TO MEMBER MN_ARNOLD :NODEDESC.Arnold Consulting :FFORMAT.VD ND PU PR DD2 :MSGS.YES3 * Topology configuration (connected to WISCMAC3 by Ethernet LAN) :LINKS1.WISCMAC3(V1,10M)4 :CONNECT.READY5 * System hardware/software configuration :MACHINE.Digital VAXstation 31006 :SYSTEM.VMS :NETSOFT.Jnet * Routing table generation/destination information :ROUTTAB.JNET (NETSERV,POSTMAST@ARNOLD)7 __________________________________________________________________ Example 5-3: UPDATE job to create node entries in BITEARN NODES for a two-node VAXcluster system __________________________________________________________________ __________________________________________________________________ Example 5-3 Cont'd on next page Installing and Configuring NJE Software 5-33 Example 5-3 (Cont.): UPDATE job to create node entries in BITEARN NODES for a two-node VAXcluster system __________________________________________________________________ ADD NODE DECUSA1 TO MEMBER MN_DECUS :NODEDESC.DECUS U.S. Chapter Spring Symposium :FFORMAT.VD ND PU PR DD2 * Topology configuration (connected to Georgia Tech by T1 link) :LINKS1.GITVMA(V1,1.5M)4 :CONNECT.199205015 * System hardware/software configuration :MACHINE.Digital VAX 9000-4206 :SYSTEM.VMS :NETSOFT.Jnet * Routing table generation/destination information :ROUTTAB.JNET (NETSERV,ARNOLD@DECUS)7 ADD NODE DECUSB1 TO MEMBER MN_DECUS :NODEDESC.DECUS U.S. Chapter Spring Symposium :FFORMAT.VD ND PU PR DD2 * Topology configuration (connected to DECUSA by Ethernet) :LINKS1.DECUSA(V0,10M)4 :CONNECT.199205015 * System hardware/software configuration :MACHINE.Digital VAX 6000-6606 :SYSTEM.VMS :NETSOFT.Jnet * Routing table generation/destination information :ROUTTAB.NONE7 __________________________________________________________________ Example 5-3 Cont'd on next page 5-34 Installing and Configuring NJE Software Example 5-3 (Cont.): UPDATE job to create node entries in BITEARN NODES for a two-node VAXcluster system __________________________________________________________________ ADD NODE DECUS1 TO MEMBER MN_DECUS :NODEDESC.DECUS U.S. Chapter Spring Symposium :FFORMAT.VD ND PU PR DD2 * Topology configuration (VAXcluster of DECUSA and DECUSB) :LINKS1.DECUSA(P,999M) DECUSB(P,999M)4 :CONNECT.199205015 * System hardware/software configuration :MACHINE.Digital VAXcluster6 :SYSTEM.VMS :NETSOFT.Jnet * Routing table generation/destination information :ROUTTAB.JNET (NETSERV,ARNOLD@DECUS)7 MODIFY NODE DECUSA :LINKS1.GITVMA(V1,1.5M) DECUSB(V0,10M)4 :LINKS2.DECUS(P,999M)4 MODIFY NODE DECUSB :LINKS2.DECUS(P,999M)4 __________________________________________________________________ 1 UPDATE uses the node name specified on the ADD NODE command to set the :NODE tag. Do not specify the :NODE tag in UPDATE jobs. 2 Users at this node, and all nodes running recent versions of Jnet, can receive files in VMSDUMP (VD), NETDATA (ND), PUNCH (PU), PRINT (PR), and DISK DUMP (DD) formats, in order of preference. 3 For Jnet V3.5 and later versions, specify :MSGS.YES, or omit the :MSGS tags from both node and Jnet cluster entries, ac- cepting the default of :MSGS.YES. (For Jnet V3.4 and earlier versions, it was necessary to specify :MSGS.NO for VAXcluster Installing and Configuring NJE Software 5-35 entries. All versions of Jnet support message to VAXcluster members and standalone VAX systems, so always specify :MSGS.YES in their entries.) 4 The :LINKSn tags (:LINKS1 through :LINKS99) specifies other BITNET nodes to which your node has a direct connection. If a link is not a 9600 baud leased line, code the link type and speed immediately after the name in parenthesis. For more information on link definition parameters refer to the :LINKS tag in NEWTAGS DESCRIPT. If a link is a virtual link between the Jnet cluster name and one of the cluster members, code the link type as (P,999M) (a dedicated, very fast link). If a node has many links, you may want to organize these by type. For example, you can put all links external to your organization on :LINKS1, all intracluster links on :LINKS2, all TCP NJE links to UNIX on your campus to :LINKS3, and a temporary link by itself on :LINKS4. 5 Specify the date, in yyyymmdd format, in the :CONNECT tag to show a future connection date, or specify READY to indicate a node is operational on the date the UPDATE job is submitted. 6 For the :MACHINE tag, specify either Digital and the sys- tem marketing model, as shown in the examples, or Digital VAXcluster, for Jnet cluster names. 7 The :ROUTTAB tag specifies the type of routing tables to be generated for this node, their source, and the BITNET address to which they should be sent. Specify JNET tables, that NETSERV is to generate the tables, and give the Postmaster's NJE ad- dress (not the name of a people tag) as the destination. Do not put a space after the comma. For VAXcluster nodes, specify :ROUTTAB.NONE for all entries except the Principal Node and the Jnet cluster name. You will only receive two routing tables each month. 5-36 Installing and Configuring NJE Software 5.8 Wait for routing tables When you register your nodes with BITNIC, as described in Section 5.7, information about your nodes will be distributed throughout the network in the next update cycle. An outline of the update cycle schedule is given in Section 5.8.1. Suggestions for monitoring the installation of tables with routes to your node, and for encouraging other Postmasters to install the new tables, are provided in Section 5.8.2. Instructions for the installation of your own initial monthly table updates are in Section 5.8.3. 5.8.1 The monthly update cycle After submitting UPDATE jobs to add your first node, and option- ally additional nodes, to BITEARN NODES, wait for routing tables including your nodes to be distributed throughout the network. Tables are normally sent the first full weekend of each month, and important hub nodes generally install them within a few days, so if you register your nodes just before the update cutoff (cur- rently the fifteenth of each month), tables with routes for your nodes will be shipped in as few as three weeks. If you just miss an update cutoff, however, it will take up to eight weeks for tables including your nodes to be shipped. Plan ahead! Since your first node will not be in the tables when they are shipped unless you have made special arrangements, the initial at- tempt to send you routing tables will probably fail. As a service to new nodes, however, an EARN participant, Hans-Ulrich Giese, U001212@HEARN or U001213@HNYKUN11.URC.KUN.NL, resends routing ta- bles for new nodes about two weeks after the initial tables are shipped. By this time, intermediate nodes have had a chance to install their tables, and successful delivery is much more likely. Until tables with routes for your nodes are generally available, you can improve initial network service by arranging for TECHREPs or Postmasters to manually define a route for your Principal Node at intermediate nodes between your node BITNIC, and between your node and your regional NETSERV. Contact the responsible people Installing and Configuring NJE Software 5-37 after your node is connected but before it is widely defined in NETSERV-generated tables. A telephone call to BITNIC can help determine if this would be practical and useful in your case. By the second update cycle after you register your nodes, your tables should arrive uneventfully each month. 5.8.2 Monitoring table updates You are dependent on Postmasters throughout the network to manually install their routing tables when they arrive. Many Postmasters can be depended upon to perform this important task promptly, but unfortunately, a few Postmasters do not take this responsibility seriously. This causes network connectivity prob- lems for new nodes. If there are still nodes between your node and your users' cor- respondents that have not installed tables defining a route for your node a month after such tables are generally available, you should feel justified in contacting the Postmaster of the node, by electronic mail or telephone, to insist that the new tables be installed, as required by the CREN Terms and Conditions of Membership and Affiliation. After you node has been published in the tables, trouble receiving mail and files is probably caused by out-of-date routing tables on other nodes. Remember how it feels, because years from now, Postmasters of new nodes will be depending on you to update your tables in a timely way, as demanded by the CREN terms. You can find out which nodes do not have you in their tables by sending a short file to or through them. The node adjacent to the last node to send you a file progress message is the cause of the trouble, if the system runs VM and RSCS or VMS and Jnet. (IBM systems running MVS and JES do not send messages when they forward files on behalf of a remote user.) 5-38 Installing and Configuring NJE Software If a node runs VM or Jnet and has your node in its tables, you can also send the NJE command QUERY VERSyymm to the node. If the node has a route for the pseudonode VERSyymm, it is using the mmth set of tables issued in the year 19yy. Unless there are special table updates (usually made to correct a problem), version yymm tables are those issued at the beginning of the mmth month. 5.8.3 Installing initial tables When you receive your own routing tables, they will come as file transfers to POSTMASTER (if you have followed the suggestions in Section 5.7) and be named nodename.NETINIT. Receive each routing table as the file JAN_SPECIFIC:[SYS]JANROUTES.JCP on the appropri- ate node, except tables for Jnet cluster names. Such tables should be received into JAN_COMMON:[SYS]JANROUTES.JCP on any node of the Jnet cluster, to be shared by all Jnet cluster nodes that do not have external links. If you followed the suggestions in Section 5.4.2.9, the new tables will be automatically installed by the next nightly JANTIDY run. When your receive the JANTIDY report the following morning, you can purge the old tables. For more information on installing subsequent monthy table updates, see Section 7.4.1. Consider using RMS version numbers to identify the versions of JANROUTES.JCP and other files that are updated monthly. These files have internal four-digit version numbers, consisting of the last two digits of the year and two digits for update in the current year, for example, 9202 for second set of tables in 1992. Unless there are special table updates (usually made to correct a problem), version yymm tables are those issued at the beginning of the mmth month. The file name, type, and version of your node's second set of tables routing tables in 1992 would thus be JANROUTES.JCP;9202. Installing and Configuring NJE Software 5-39 Chapter 6 Installing and Registering a BITNET Mailer This chapter provides suggestions for the mailer layer of your network. This book provides supplementary information on running PMDF in the BITNET environment, and is not intended to replace PMDF documentation. 6.1 External view of a mailer To other BITNET nodes, a mailer is an application with an NJE address that can send and receive BSMTP mail. To correctly set up a mailer, you must choose an NJE address for the mailer and insure that: o PMDF uses the selected address as the NJE envelope (tag) return address o Mail to the selected address is routed to PMDF's BSMTP proces- sor o The selected address is registered as the mailer for your node in BITEARN NODES[1], and in turn, in XMAILER NAMES o The selected address is registered as the mail gateway for your domain in DOMAIN NAMES Installing and Registering a BITNET Mailer 6-1 This book recommends that you select MAILER@nodename as the NJE address for your mailer, where nodename is the NJE name of your Jnet cluster, or if your system is not in a Jnet cluster, the NJE name of your VAX system. Using other addresses and setting up a remote mailer for your systems is beyond the scope of this book. The remainder of this chapter shows how to install and configure PMDF on a VAX or VAXcluster system to consistently meet these four requirements. 6.2 Install PMDF PMDF installation is a straight-forward process of unpacking files from the distribution save sets into the PMDF directory tree. Your primary decisions are the User Identification Codes (UICs) of any required PMDF accounts, the name of the batch queue(s) PMDF will use, and where to put the PMDF files. 6.2.1 Determine UICs for PMDF SYSUAF entries Before beginning the installation, determine whether you need PMDF server and user entries in the SYSUAF, their names, the UICs to be used for each entry, and whether the entries already exist in the UAF. This book recommends that you set up a server entry called PMDF in all cases, and a user account called PMDF_USER if you will be installing the PMDF-FAX optional product. See Sections 1.2.1 and 1.2.2 in the PMDF Installation Guide & Release Notes for further information. 6.2.2 Select a location for the PMDF files To allow easy movement of PMDF files from one disk to another as your configuration changes, consider defining the logical name MY_PMDF_DEVICE in SYS$MANAGER:SYLOGICALS.COM, as in this example: 6-2 Installing and Registering a BITNET Mailer ... $ ! Put PMDF files on DUA0:. $ DEFINE/SYSTEM/EXEC/TRANS=(TERMINAL,CONCEALED) - MY_PMDF_DEVICE $1$DUA0: ... If, at some later time, you need to move the PMDF directory tree to a different disk device, merely shut down PMDF (as explained in Section 1.4.1 of the PMDF Installation Guide & Release Notes, edit the logical name definition in SYS$MANAGER:SYLOGICALS.COM, manually redefine the device logical name, move the directory trees with the VMS BACKUP utility, and restart the PMDF queues. 6.2.3 Set up PMDF queues Section 1.2.3 of the PMDF Installation Guide & Release Notes provides instructions for selecting a batch queue in which to run PMDF jobs. Do not use the queue name MAIL$BATCH, as recommended by Innosoft. The name contains a dollar sign ($), and so is reserved for use by Digital. (The PMDF startup procedure will still use MAIL$BATCH as a logical name for your queue.) This book suggests that you create queues for exclusive by PMDF. Establish batch execution queues called PMDF_nodename, where nodename is the SCSNODE name (and DECnet node name) of each system that will run PMDF. If you are installing PMDF on a VAXcluster, also establish a generic batch queue called PMDF_aliasname, where aliasname is the DECnet alias name of your VAXcluster. To initialize PMDF batch queues, create the command procedure SYS$COMMON:[SYS$STARTUP]PMDF_INIT_QUEUES.COM. For VMS V5.0-V5.4, execute the procedure using the SYSMAN STARTUP facility (recom- mended) or SYS$STARTUP:SYSTARTUP_V5.COM. For VMS V5.5 and later versions, run PMDF_INIT_QUEUES.COM only once, then save it to document how you initialized your PMDF queues. The batch/print subsystem introduced with VMS V5.5 does not require queues to be initialized after each system boot. Installing and Registering a BITNET Mailer 6-3 Example 6-1 shows a sample PMDF queue initialization procedure for a VAXcluster with two members running PMDF. Do not start the node- specific queues from this procedure, and do not use the autostart feature, introduced in VMS V5.5, for PMDF queues. Example 6-1: Command procedure to initialize PMDF batch queues on a two-member VAXcluster __________________________________________________________________ $ ! PMDF_INIT_QUEUES.COM: initialize PMDF queues $ $ ! Run this procedure from SYSMAN STARTUP for VMS versions before V5.5. $ ! For VMS V5.5 and later versions, run this procedure manually and $ ! only once. $ $ ! Node-specific queues, to execute jobs that may run on any node as $ ! well as those that require special facilities of this node. $ ! Start these queues in SYS$STARTUP:PMDF_START_QUEUES.COM. $ initialize /queue PMDF_ARNOL1 /batch /on=ARNOL1:: /base=4 /job=2 $ initialize /queue PMDF_ARNOL2 /batch /on=ARNOL2:: /base=4 /job=2 $ $ ! Cluster-wide generic queue, to receive jobs that may run on any node. $ initialize /queue PMDF_ARNOLD /batch /start - /generic=(PMDF_ARNOL1,PMDF_ARNOL2) __________________________________________________________________ Start PMDF batch queues in a command procedure SYS$COMMON:[SYS$STARTUP]PMDF_ START_QUEUES.COM. Execute the procedure using the SYSMAN STARTUP facility (recommended) or SYS$STARTUP:SYSTARTUP_V5.COM. Example 6-2 shows a sample PMDF queue startup procedure for a VAXcluster with two members running PMDF. Note that the node- specific queues are started as the node on which they run comes up. 6-4 Installing and Registering a BITNET Mailer Example 6-2: Command procedure to start PMDF batch execution queues on a two-member VAXcluster __________________________________________________________________ $ ! PMDF_START_QUEUES.COM: start PMDF execution queues $ $ ! Run this procedure from SYSMAN STARTUP after all PMDF is started, $ ! PMDF queues are initialized, and all networks started. $ $ if 'f$edit(f$getsyi("SCSNODE"),"TRIM") .eqs. "ARNOL1" then - start /queue PMDF_ARNOL1 $ if 'f$edit(f$getsyi("SCSNODE"),"TRIM") .eqs. "ARNOL2" then - start /queue PMDF_ARNOL2 $ ! An alternative method, if all members have PMDF queues: $ ! start /queue PMDF_'f$edit(f$getsyi("SCSNODE"),"TRIM") __________________________________________________________________ 6.2.4 Run VMSINSTAL When you have prepared the device logical name, determined whether you have any PMDF entries in the SYSUAF, and set up the PMDF batch queues, install PMDF with VMSINSTAL according the directions in Section 1.5 of the PMDF Installation Guide & Release Notes, as supplemented by the suggestions in this section. If you will be installing PMDF on a VAXcluster, perform the in- stallation on any fast or lightly loaded VAX system in the cluster that is licensed to run PMDF. This section assumes that this installation is the first installation of PMDF on your VAX or VAXcluster system. The PMDF Installation Guide & Release Notes explains the differences between a new installation and an upgrade installation. Consider saving an autoanswer file in SYS$UPDATE as documentation of the installation choices you make, as suggested in Section 4.1. The PMDF installation procedure asks a number of questions. The procedure's prompts and Section 1.5 of the PMDF Installation Guide & Release Notes provide directions for answering the questions. Recommended answers for selected questions follow: Installing and Registering a BITNET Mailer 6-5 o If you followed the suggestion to create a logical name for the PMDF device in Section 6.2.2, enter MY_PMDF_DEVICE:[PMDF] for the device and directory for PMDF files. o If you have no PMDF server entry in the SYSUAF, allow VMSINSTAL to create one named PMDF. Accept the default name and UIC offered by the installation procedure. SECURITY CAUTION If you requested an autoanswer file, the password of the PMDF account will be written in the file. Edit the file after the installation is complete to delete the pass- word, and purge the original version of the autoanswer file. o Specify the same numeric offset from Universal Time as you did for the Jnet configuration procedure (Section 5.4). o The source files are useful only for applying patches, a pro- cess which requires a Pascal compiler. Normally you should request that the source files not be installed. When VMSINSTAL completes, if you added the PMDF command to the DCL tables and you are installing on a VAXcluster system, reinstall the DCL tables on all the nodes of the VAXcluster using SYSMAN. Then continue with the PMDF post-installation steps 1 and 2 in Section 1.6 of the PMDF Installation Guide & Release Notes. 6.2.5 Configure PMDF for automatic startup This section supplements the instructions for Post-installation step 1 in Section 1.6 of the PMDF Installation Guide & Release Notes. 6-6 Installing and Registering a BITNET Mailer PMDF components and other software must be started in a specific order to prevent mishandling of mail. You can use either the SYSMAN STARTUP facility (recommended) or SYSTARTUP_V5.COM to start PMDF and other networking and mail software. Software components must be started in this order: 1. Initialize PMDF queues (VMS V5.0-V5.4 only): PMDF_INIT_QUEUES.COM 2. Install PMDF images and define PMDF logical names: PMDF_STARTUP command procedure 3. Start DECnet-VAX: STARTNET.COM 4. Start other network software, for example: UCX$STARTUP.COM or MULTINET_STARTUP.COM 5. Start DECwindows 6. Start Jnet: JNET_STARTUP.COM 7. Start PMDF queues (only needed on nodes with PMDF queues): PMDF_START_QUEUES.COM 8. Submit periodic PMDF jobs: PMDF_SUBMIT_JOBS.COM Innosoft recommends that PMDF_STARTUP.COM be run before any net- works are started. Because DECnet-VAX must be started before DECwindows, STARTNET.COM must be run from SYSTARTUP_V5.COM. If you will run PMDF over DECnet (either MAIL-11 or SMTP over DECnet), you must run PMDF_STARTUP before STARTNET, and thus, from STARTUP_ V5 as well. Only if you will not be running PMDF over DECnet can you run PMDF_STARTUP with SYSMAN. Initialization of PMDF batch queues is only required on VMS ver- sions before V5.5. If you follow the recommendation to not use MAIL$BATCH and to initialize queues from a command procedure, you can run the procedure before or after PMDF_STARTUP, but you must Installing and Registering a BITNET Mailer 6-7 run it before any networks that PMDF uses are started and before users are allowed onto the system. If you are not using PMDF over DECnet, the SYSMAN utility is recommended for starting PMDF at each system reboot. To direct SYSMAN to execute the PMDF startup procedures in the correct order during the VMS startup procedure, enter, for all versions of VMS: $ SYSMAN :== $SYSMAN $ SYSMAN STARTUP ADD FILE PMDF_STARTUP.COM /PHASE=LPBEGIN $ SYSMAN STARTUP ADD FILE PMDF_SUBMIT_JOBS.COM /PHASE=END $ SYSMAN STARTUP ADD FILE PMDF_START_QUEUES.COM /PHASE=END and enter, for VMS V5.0 through V5.4: $ SYSMAN STARTUP ADD FILE PMDF_INIT_QUEUES.COM /PHASE=LPBEGIN 6.2.6 Make PMDF online books available to Bookreader Step 2 of Section 1.6 of the PMDF Installation Guide & Release Notes suggests that you run PMDF_ROOT:[EXE]PMDF_DEFINE_BOOK.COM each time you start up your system to add the PMDF online library to the list of libraries searched by the DECwindows Bookreader. Because this procedure must be run after DECwindows is started, it cannot be run from SYS$MANAGER:SYSTARTUP_V5.COM. Use one of these methods to make the PMDF online books available to Bookreader: o Copy the command procedure PMDF_DEFINE_BOOK.COM to the di- rectory SYS$COMMON:[SYS$STARTUP], and use the SYSMAN STARTUP facility to run it in phase LPMAIN. o Edit SYS$MANAGER:SYLOGICALS.COM to define DECW$BOOK in the system logical name table. Do not define it in the DECwindows logical name table, because the DECwindows startup procedures run after SYLOGICALS, and would overwrite your definition. 6-8 Installing and Registering a BITNET Mailer DECW$BOOK is a search list that has one value for each online library. The following lines show one way to define DECW$BOOK in SYLOGICALS.COM to make the online libraries for VMS, PMDF, and TGV MultiNet available to Bookreader: ... $ $! Online documentation for Bookreader $ DEFINE/SYSTEM/EXEC DECW$BOOK OLD_DEVICE:[DECW$BOOK],- PMDF_ROOT:[DOC],- MULTINET_ROOT:[MULTINET.DOCUMENTATION] ... The version of Bookreader shipped with DECwindows Motif (DECwindows Version 3) supports the expansion of libraries in outline form by double-clicking on the library name in the library window. Unless the bookshelf for a library has a TITLE line, the library is listed only as "Library n", where n is an integer. To cause Bookreader to display an informative name for the PMDF online library, enter: $ SET DEFAULT PMDF_ROOT:[DOC] $ COPY SYS$INPUT+PMDF.DECW$BOOKSHELF _To: LIBRARY.DECW$BOOKSHELF;/CONCATENATE TITLE\pmdf.decw$bookshelf\Innosoft PMDF for VMS This change also reduces by one the number of bookshelves a user must traverse to open the PMDF online books. Stop and restart Bookreader to make the change effective. To make the online version of this book available as part of the PMDF online library, copy the online book file VMS_ MAILER.DECW$BOOK to the directory PMDF_ROOT:[DOC] and set its protection to W:RE. To add the title of this book to the PMDF bookshelf file, enter: Installing and Registering a BITNET Mailer 6-9 $ APPEND SYS$INPUT PMDF_ROOT:[DOC]LIBRARY.DECW$BOOKSHELF BOOK\vms_mailer\BITNET Postmaster's Guide for VAX/VMS Systems When you have finished this post-installation step, complete steps 5-8 in Section 1.6 of the PMDF Installation Guide & Release Notes, if applicable to your system. Skip steps 3-4; you will cover this material in detail as you work through Section 6.3 of this book and Chapter 3 of the PMDF Installation Guide & Release Notes. 6.3 Configure PMDF This section provides instructions for: 1. Obtaining initial mailer tables (Section 6.3.1) 2. Running the PMDF autoconfiguration procedure (Section 6.3.2) 3. Manual steps to complete PMDF configuration (Section 6.3.3- Section 6.3.7) The section concludes with a list of PMDF instructions to avoid, either because they are handled by autoconfiguration or because they are not recommended for BITNET nodes (Section 6.3.8). 6.3.1 Obtain mailer files To generate PMDF tables, you must obtain up-to-date copies of the files DOMAIN NAMES and XMAILER NAMES initially and when the files are updated each month. (The use of current mailer tables is a CREN requirement.) Initial tables are shipped with PMDF, but unless your PMDF distribution includes the current tables, you should obtain the current tables immediately. 6-10 Installing and Registering a BITNET Mailer When your BITNET link is operational, you can obtain the current versions of these files by entering: $ SEND LISTSERV@BITNIC GET DOMAIN NAMES $ SEND LISTSERV@PUCC GET XMAILER NAMES You can also send the GET commands to the servers in the text portion of electronic mail messages. You can also obtain XMAILER NAMES from LISTSERV@BITNIC, but be- cause the mailer for IBM VM systems, VM Mailer V2, is maintained at Princeton University, and because PUCC is a BITNET II core node, LISTSERV@PUCC is a better source for XMAILER NAMES. If your node is not in the routing tables of all of the nodes between your node and PUCC, and between your node and BITNIC, ask the Postmaster of the node adjacent to yours to obtain current versions of these files and forward them to you. To have new versions of the mailer files sent to you each time they are updated, subscribe to LISTSERV's automatic file dis- tribution (AFD) service. Log into the account to which you would like the servers to send the files, for example, POSTMASTER. Then enter: $ SEND LISTSERV@BITNIC AFD ADD DOMAIN NAMES $ SEND LISTSERV@PUCC ADF ADD XMAILER NAMES You can also send the AFD ADD commands to the servers in the text portion of electronic mail messages. When the files arrive either initially or after a monthly update, use the Jnet RECEIVE utility to receive them into the directory PMDF_ROOT:[TABLE]. Consider using RMS version numbers to identify the versions of XMAILER NAMES, DOMAIN NAMES, and other files that are updated monthly. These files have internal four-digit version numbers, consisting of the last two digits of the year and two digits for the update number in the current year, for example, 9202 Installing and Registering a BITNET Mailer 6-11 for the second update in 1992. Unless there is an extra update, for example, to correct an error, the last two digits normally correspond to the month. The file name, type, and version of your copy of the February 1992 DOMAIN NAMES file would thus be DOMAIN.NAMES;9202. The use of XMAILER NAMES and DOMAIN NAMES is described in Section 6.3.2. 6.3.2 Run PMDF autoconfiguration Section 3.2 and Chapter 4 of the PMDF Installation Guide & Release Notes describe and illustrate the autoconfiguration of PMDF. This section provides additional suggestions for PMDF autoconfiguration of BITNET nodes. 1. If DECnet-VAX is available on your system, SET HOST/LOG to the system to be autoconfigured. The log provides a valuable record of the autoconfiguration session. If you are autoconfiguring a VAXcluster, set host to the fastest available system, as autoconfiguration is computationally intensive! 2. Log into a fully privileged account to autoconfigure PMDF. A personal account is preferred to the SYSTEM account for this purpose. Digital recommends that SYSTEM be used only for software installation and standalone backups, and the use of SYSTEM renders useless the configuration file comments identifying the user who ran the procedure. 3. Set your default device and directory to PMDF_ROOT:[TABLE]. 4. The autoconfiguration procedure checks the values of certain DCL symbols to set configuration options. Setting these symbols is recommended over editing the autoconfiguration procedure, because changes to the autoconfiguration procedure will be lost when you upgrade PMDF. You can either make a permanent note on what symbols you set, or if you set many symbols, 6-12 Installing and Registering a BITNET Mailer write a command procedure to set the symbols and then run the autoconfiguration procedure. Setting the following symbols is recommended: o For all BITNET nodes, set SKIP_XMAILER to "/nodename1/nodename2/.../", where the nodenames are a list of all the NJE names for your system or VAXcluster that appear in XMAILER NAMES. This op- tion avoids configuring these names twice, once as a BITNET node and once as the local node. For example, if your system is a standalone node with NJE name KNOX, then enter: $ SKIP_XMAILER == "/KNOX/" o For all BITNET nodes, set DO_CRDB to 1. This option causes your configuration to use an indexed file to store the large amount of configuration information required for BITNET. Enter: $ DO_CRDB == 1 o For VAXclusters, set BITNET_QUEUE to PMDF_scsnode, where PMDF_scsnode is the name of a PMDF batch queue that runs only on the VAXcluster member with the external BITNET links. This option causes all batch jobs that send mail on BITNET to run on the node with the external links, which avoids the NJE transfer of mail files between VAXcluster members. For example, if the external link to the DECUS Symposium VAXcluster is on node DECUSA, then enter: $ BITNET_QUEUE == "PMDF_DECUSA" 5. To run the autoconfiguration procedure, enter: $ @PMDF_ROOT:[EXE]CONFIGURE Installing and Registering a BITNET Mailer 6-13 6. If your system is on a TCP/IP network, you are asked your sys- tem's host name in Part One of the autoconfiguration dialogue. You should usually take the default. If your system is a homo- geneous VAXcluster, you will edit PMDF_ROOT:[TABLE]PMDF.CNF in Section 6.3.3 to add the TCP/IP host names of the other cluster members and the TCP/IP host alias for the VAXcluster system to your PMDF configuration, so that you can receive mail addressed to the TCP/IP host name of any cluster member. 7. You are asked your system's NJE node name in Part Two of the autoconfiguration dialogue. If your system is a homogeneous VAXcluster, enter the Jnet cluster name. This name will be the return address for all mail sent to BITNET destinations. You will edit PMDF_ROOT:[TABLE]PMDF.CNF in Section 6.3.3 to add the NJE node names of all cluster members running Jnet to your configuration, both with and without the .BITNET pseudodomain, so that you can receive mail addressed to the NJE node name of any cluster member. 8. You are asked if your system is a BITNET gateway in Part Two. Answer YES. Your system is a BITNET gateway for mail to its own domain-style name, even if it doesn't receive mail for routing to other systems. 9. Next you are asked for the domains for which your system serves as a gateway. At a minimum, enter your system's domain-style name, even if your system doesn't receive mail for routing to any other systems. For example, if you are configuring PMDF for BITNET node ARNOLD with domain name Arnold.Com, enter Arnold.Com in response to this question. 10.Next you are asked for the name of the mailbox the gateway uses. Accept the default, MAILER. The purpose of the mailbox is much more obvious from the name if you use MAILER than if you use SMTPUSER, and MAILER is the default name of the sending user for outbound BSMTP mail. 6-14 Installing and Registering a BITNET Mailer 11.You are asked for the official local host name in Part Four of the autoconfiguration dialogue. If your system is a homogeneous VAXcluster, enter the domain-style name of the VAXcluster, not that of the cluster member. This name will be the return address for all mail except that sent to BITNET destinations. 12.You are also asked for the account to which mail for Postmaster is to be sent. Enter POSTMASTER@ and the official host name of this homogeneous VAXcluster or system. You can later forward POSTMASTER's mail to another account, if necessary. 13.In Part Five of the autoconfiguration dialogue, you are asked to confirm or re-specify the file specifications of the files the procedure will use. The defaults are recom- mended, except for the files PMDF_ROOT:[TABLE]GATEWAY.RULES and PMDF_ROOT:[TABLE]BGATEWAY.RULES. Take the defaults for these files if there are VAX systems running PMDF, that are on the same DECnet or TCP/IP network and not on BITNET and not in the same VAXcluster as yours, and that will route mail to BITNET through your system. Otherwise enter NL: for these two files. When the autoconfiguration procedure finishes, review Chapter 5 in the PMDF System Manager's Guide. Much of the chapter explains how to manually set up the configuration you have just created automatically. Certain manual steps are still required, and are explained in the following sections. Section 6.3.8 provides more information on which steps you should not do. 6.3.3 Edit PMDF configuration file The autoconfiguration procedure writes the PMDF configuration file, PMDF_ROOT:[TABLE]PMDF.CNF, that recognizes mail for the TCP/IP host name or BITNET node name as local mail. On a homoge- neous VAXcluster system, each cluster member and the VAXcluster itself can be known by BITNET (NJE) node name, Installing and Registering a BITNET Mailer 6-15 domain (TCP/IP host) name, short-form aliases for the names above, DECnet node name, and domain literal name (IP address). The usual intention is to recognize mail to any of these names as local mail. Use an editor to add all the missing names to your own new PMDF configuration file. Insure that the TCP/IP host name, BITNET node name (with and without .BITNET), and DECnet node name of every system in your VAXcluster maps to the domain name of the VAXcluster itself. Example 6-3 shows the PMDF configuration file for a two-node VAXcluster system on both BITNET and the Internet. The file has been manually edited to include the full list of names recognized as local. Example 6-3: PMDF configuration file for a BITNET node __________________________________________________________________ __________________________________________________________________ Example 6-3 Cont'd on next page 6-16 Installing and Registering a BITNET Mailer Example 6-3 (Cont.): PMDF configuration file for a BITNET node __________________________________________________________________ ! PMDF.CNF - PMDF configuration file for the two-member ! VAXcluster system Arnold.Com. ! ! Rewrite rules for the local host/cluster ! Domain names Arnold.Com $U@Arnold.Com Arnold1.Arnold.Com $U@Arnold.Com Arnold2.Arnold.Com $U@Arnold.Com ! BITNET names ARNOLD.BITNET $U@Arnold.Com ARNOL1.BITNET $U@Arnold.Com ARNOL2.BITNET $U@Arnold.Com ! DECnet and short form names Arnold $U@Arnold.Com ARNOL1 $U@Arnold.Com Arnold1 $U@Arnold.Com ARNOL2 $U@Arnold.Com Arnold2 $U@Arnold.Com ! TCP/IP domain literals [192.135.80.1] $U@Arnold.Com [192.135.80.2] $U@Arnold.Com [192.135.80.3] $U@Arnold.Com ! All other domain literals [] $U%[$L]@MTCP-DAEMON ! ! BITNET rewrites included from external files ! LISTSERV preserves the case of my name; the case of the command doesn't matter. LISTSERV determines my NJE address from the com- mand itself, so it's not necessary to enter it. If any of the links on the BITNET path to the node hosting the LISTSERV are not connected, you will receive a message, for exam- ple: %SEND-E-NOTCONNECT, Link WISCMAC3 not connected If a link is down, you can still send mail to subscribe to a list. Your subscription request will be delivered when the communica- tions link comes back up. In the example above, I entered: $ MAIL MAIL> SEND/NOSELF/NOEDIT/NOCC/SUBJECT="" To: IN%"LISTSERV@BITNIC" Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: SUBSCRIBE LINKFAIL Stephen L. Arnold If the lists are on the same server, you enter multiple subscrip- tions by entering additional interactive commands or additional lines in a mail message. As a BITNET Postmaster, you should subscribe to these lists: o LINKFAIL@BITNIC, annoucements about network, host, and server service interruptions o JNET-L@BITNIC, a discussion on Joiner's Jnet software o BITNEWS@BITNIC, news about BITNET for general and management audiences 6-40 Installing and Registering a BITNET Mailer o TECHNEWS@BITNIC, technical news about BITNET o NODMGT-L@BITNIC, a discussion of routing and mailer tables, protocols, and other matters of concern to Postmasters Institutional representatives, TECHREPs, and INFOREPs are automat- ically subscribed to lists maintained by BITNIC for people serving in those roles. There are also many other LISTSERV lists on a myr- iad of subjects, which are beyond the scope of this book. See the TECHREP or INFOREP information packets to learn more about these. When you subscribe to a LISTSERV list, LISTSERV automatically sends you a welcome note that explains how to set certain list options and how to sign off the list. Consider saving these notes in a special mail folder to document what lists to which you've subscribed. To sign off a list, send the SIGNOFF command to the server as a message or mail. For example, to sign off the LINKFAIL list, I can enter: $ SEND LISTSERV@BITNIC SIGNOFF LINKFAIL 6.7.2 Subscribing to Internet discussions After your BITNET link is operational, your nodes have appeared in BITEARN NODES, and your domain has appeared in DOMAIN NAMES, or, if applicable, after your Internet connection is operational, you can join Internet discussion groups. This is normally a man- ual process, and is initiated by mailing a request to the list coordinator. By convention, the list coordinator of an Internet discussion can be reached on the same node as the list itself, at a mailbox named by adding "-Request" to the name of the list mailbox. For example, to join the discussion of TGV's MultiNet TCP/IP soft- ware, Info-MultiNet@TGV.Com, send your request to Info-MultiNet- Request@TGV.Com. Installing and Registering a BITNET Mailer 6-41 To sign off of an Internet discussion, send mail to the -Request mailbox for the list requesting that you be removed from the list. Do not send your request to the list itself. In general, BITNET-oriented discussions are hosted by LISTSERV servers, but there are two Internet discussions that you should join: for PMDF and for your TCP/IP software, if any. To join the PMDF discussion, Info-PMDF@Ymir.Claremont.Edu or IPMDF@YMIR (on BITNET), send your request to Info-PMDF-Request@Innosoft.Com or RPMDF@YMIR, respectively. Notice that the PMDF list does not fol- low the convention of having the discussion and request mailboxes on the same node. Also, do not attempt to send LISTSERV commands to RPMDF@YMIR. Not all lists on BITNET nodes are LISTSERV lists. Contact your TCP/IP software vendor to find out if there is a network discussion on the product. The address for TGV MultiNet is Info-MultiNet-Request@TGV.Com. Wollongong WIN/TCP is discussed on the LISTSERV list WINTCP-L@UBVM.CC.Buffalo.Edu. If you use Digital's TCP/IP software and have contracted for software support, Digital's DSNlink support network provides this function. If you do not have software support, you will find friendly, knowledgeable users of Digital's products on DECUServe, a computer conferencing service sponsored by the United States chapter of the Digital Equipment Computer Users Society (DECUS), Digital's user group. PMDF, Jnet, third-party TCP/IP software, ANU News, and many other products and programs of interest to BITNET Postmasters are also discussed on DECUServe. For information on DECUServe, dial 1 (800) 521-8950 with a VT terminal and modem, or Telnet to the Internet host Eisner.DECUS.Org, and log in with user name INFORMATION (no password). Both Info-PMDF and Info-Multinet are available as network news groups. If a news feed is justified for your site, you may wish to consider participating in the discussions via news rather than through mail. 6-42 Installing and Registering a BITNET Mailer Chapter 7 On-going Management of BITNET Nodes Congratulations! You have implemented BITNET for your organiza- tion, complete with a fully-functional, BSMTP-compliant mailer, as required by CREN for all members and affiliates. To keep your software running smoothly, provide the best BITNET services for your users, and remain a good network citizen, cer- tain maintenance tasks must be performed on a regular basis or when circumstances require. This chapter summarizes these tasks, and is organized by their required frequency: initially and when you add new users (Section 7.1), constantly (Section 7.2), daily on weekdays (Section 7.3), monthly (Section 7.4), when chang- ing system clock (Section 7.5), and irregularly, in response to certain changes (Section 7.6). 7.1 Initially and when adding new users When you first bring up a BITNET connection, and whenever you add users to your system in the future, you have two manage- ment responsibilities: to assign user names (Section 7.1.1) and to train or orient the new users in the user of the network (Section 7.1.2). On-going Management of BITNET Nodes 7-1 7.1.1 Assigning user names When adding new users, follow the user name policies you developed while working through Chapter 3. If you must assign VMS user names longer than eight characters, check for conflicts, add an eight-character alias to the PMDF ALIASES. file, and recompile and install the PMDF configuration (on all VAXcluster nodes if your system is a VAXcluster). 7.1.2 User training Your organization must have procedures for orienting new users to computers and networks, to help them learn of possible applica- tions and to comply with acceptable use agreements and applicable laws. The liason between CREN and the users at your organization for this purpose is the INFOREP. The INFOREP packet should contain starter information to help you. Instruct your users on computer and network security, and proper network behavior (netiquette). Any mail user can find an immediate audience of 50,000 or more readers of a single list, and can become a source of pride or embarrassment to your organization. Explain that the networks do not guarantee the confidentiality of mail or other data, and remind them to avoid compromising the security of their VMS password by sending it over BITNET in a VMS batch job. There are several guides to good electronic mail manners published in books on networking and circulated monthly in internet discus- sions, including Info-VAX, the VAX/VMS discussion. One or more of these will provide a good starting point for developing your new user training. The Electronic Mail Association (EMA), an industry group, pub- lishes several guides to privacy and security of electronic mail, such as Access to and Use and Disclosure of Electronic Mail on Company Computer Systems: A Tool Kit for Formulating Your Company's Policy. The EMA can be reached at 155 Wilson Boulevard, 7-2 On-going Management of BITNET Nodes Suite 300, Arlington VA 22209-2405, (703) 875-8620, fax (703) 552-0241, or send Internet mail to EMA@MCImail.MCI.Com. 7.2 Constantly Operating a BITNET node makes you responsible for prompt and reliable delivery of network data, not only to local users, but to their correspondents and to others whose network data must be transmitted through your system. The CREN Terms and Conditions of Membership and Affiliation require your organization to monitor the network and respond to problems constantly. You must strive to make your Principal Node and any other major nodes available around the clock. Specifically, your nodes and the links to adjacent sites should always be up. Consider developing a simple line monitor, a program which peri- odically checks for the correct configuration and state of your system and network links. If you do not have operators on duty at all times, you can program the line monitor to call a pager or a security desk when it determines that the network is down. For more on line monitors, see Section 5.4.2.9. Some of the things an operator or line monitor should periodically check include: o Are all links in the Connect state? o Do link queue counts go back to zero after a file is queued? o Are data link or device error counters increasing too quickly? o Is there enough disk space on important disk devices? o Are traffic counters increasing at the usual rate for the time of day? On-going Management of BITNET Nodes 7-3 In addition to NJE software, operators or monitor programs should check for failures in the underlying networking software (for example, TCP/IP or DECnet-VAX software) and if possible, monitor the condition of the system itself. 7.3 Weekdays The tasks in this section should be done each business day: re- view JANTIDY output (Section 7.3.1), dispose of files sent to POSTMASTER (Section 7.3.2), read mail to POSTMASTER (Section 7.3.3), check PMDF channel queues (Section 7.3.4), check PMDF batch queues (Section 7.3.5), and read relevant network discussions (Section 7.3.6). Consider automating as many of these tasks as possible and merging them into JANTIDY or another daily command procedure. 7.3.1 Review JANTIDY output If you run the JANTIDY management procedure, as suggested in Section 5.4.2.9, you will have mail each morning from the JANTIDY run on each of your VAX BITNET nodes. Review each of these mail messages for problem symptoms, then delete the mail. 7.3.2 Dispose of files sent to POSTMASTER JANTIDY warns you if there are any files for the POSTMASTER to receive. Most of these were sent to user names that do not exist on your system. Examine the file tag data with Jnet's RECEIVE utility, either by logging in as POSTMASTER or by using the /USER=POSTMASTER qualifier from a privileged account. You may be able to determine the user for whom the file was intended and send it along with RECEIVE's FORWARD/ORIGINAL/NOKEEP command. Do not, however, review the file contents. To do so would be to violate the sender's privacy. 7-4 On-going Management of BITNET Nodes 7.3.3 Read mail to POSTMASTER As Postmaster, you should read mail addressed to POSTMASTER or POSTMAST as it arrives. You can do this by logging in as POSTMASTER, but it is easier to delegate the Postmaster duties by forwarding POSTMASTER's mail to the personal account of the individual currently on Postmaster duty. PMDF and most other mail software return entire undelivered mail messages back to the sender or, if the sender cannot be reached, to the Postmaster. PMDF also sends, optionally and by default, a copy of bounced mail to the local Postmaster. This places a burden of confidentially on the Postmaster. Use your best effort to avoid reading any more of a mail message than necessary to diagnose any problems and send the message on to the proper destination. If you followed the recommendation in Section 6.3.3 to set the SENDHEAD channel keyword (in PMDF V4.0, renamed to POSTHEADONLY in PMDF V4.1) as a default for all channels, it is much easier to maintain the privacy of mail, because the text of at least some undeliverable messages is not sent to the Postmaster. Setting the HEADERBOTTOM channel keyword as the default makes privacy especially difficult to maintain, because the Postmaster must scroll through the entire text of returned messages to get to the headers needed to diagnose delivery failures. 7.3.4 Check PMDF channel queues Check PMDF channel queues daily with PMDF's Qman command proce- dure. Except on very busy systems, PMDF queues should usually be empty, or contain mail that has been held only a short time. If mail begins to build up or messages are remaining on queue for more than a half day, investigate the cause of the delivery delay. Used Qman to check for held messages. PMDF puts messages on hold if it finds more than forty Received lines, as a loop-prevention measure. Operators can also put messages on hold manually. On-going Management of BITNET Nodes 7-5 7.3.5 Check PMDF batch queues Each day, check that the PMDF batch queues are defined and started, that the message bouncer and delivery jobs are hold- ing until their next regularly scheduled run time, and that any other jobs are executing and soon leave the queue. 7.3.6 Read relevant network discussions Read the network discussion and LISTSERV lists pertaining to BITNET, including JNET-L, Info-PMDF, TECHREP, TECHNEWS, BITNEWS, LINKFAIL, and relevant TCP/IP lists. If you have network news feeds or VAX Notes conferences on BITNET-related topics, monitor those daily as well. Try to answer questions about your site for remote users and about the networks for local users, and try to run down any reported problems. 7.4 Monthly The tasks in this section should be done monthly: install Jnet routing tables (Section 7.4.1) and build mailer tables from DOMAIN NAMES[1] and XMAILER NAMES (Section 7.4.2). 7.4.1 Install Jnet routing tables Receive Jnet routing tables when they arrive at the beginning of each month. Compare each table to the previous month's tables to check for corruption, changes in format, or errors by the servers in generating your tables. Move the tables into JAN_SPECIFIC:[SYS] (or JAN_COMMON:[SYS] if Jnet cluster members share a copy) where JANTIDY will install them on its next morning run. You can also use JANTIDY to install new tables immediately by releasing the queued JANTIDY job with the DCL command SET ENTRY/RELEASE. 7-6 On-going Management of BITNET Nodes 7.4.2 Build mailer tables When both DOMAIN NAMES and XMAILER NAMES have arrived for a month, RECEIVE them into PMDF_ROOT:[TABLE], inspect them for correct format and damage in transit, and run the BITNET_DOMAINS_DRIVER and COMPILE_INSTALL procedures to generate and install new mailer tables, as described in Section 6.3.6.2. The recommended procedure automatically restarts the Jnet local mail delivery process so that the new mailer tables are available to route incoming mail. 7.5 When changing system clock If you change your system clock to a new time zone, because of the observation of daylight time, for example, you must inform any software that needs to know the time zone. These are usually products that use wide area networks, and include PMDF, Jnet, Message Router, TCP/IP software, ALL-IN-1 and other mail user agents, and Message Router. See the PMDF and Jnet documentation for details. If you observe daylight time in your locality and if your policy is to change the system clock to conform to local time, you will have to change all of these products twice a year. As alterna- tives, consider running your system clock on local standard time (or Universal Time) all year around and letting users make the necessary mental adjustment, or develop a daylight time command procedure that changes all your time-zone-sensitive products at once. You can also encourage your software vendors to modify their products to accept both the time and time zone from an external source, preferably the Internet Network Time Protocol (NTP) or Digital's Distributed Time Service. On-going Management of BITNET Nodes 7-7 7.6 Management activities with no regular schedule The tasks in this section must be done whenever circumstances warrant: update Jnet and PMDF configurations (Section 7.6.1), modify software dependent on the SCSNODE and DECnet node names when they change (Section 7.6.2), adjust queue configurations when first upgrading to VMS V5.5 (Section 7.6.3), and respond to mail from NETSERV servers (Section 7.6.4). 7.6.1 Update Jnet and PMDF configurations Update your PMDF and/or Jnet configuration to reflect any changes in your system or network configuration. If you use a compiled configuration, recompile your configuration after making any change to the PMDF configuration or alias files. 7.6.2 Modify software when SCSNODE names change If SCS/DECnet node names change, review Jnet directories, PMDF configuration files, PMDF queue names, queue initializations, and the definition of Jnet's JAN_MASTER_NODE logical name, as well as any other configuration parameter dependent on the DECnet-VAX or SCSNODE name of your system. Finding all the things that must be changed if you change your SCSNODE and DECnet node names is beyond the scope of the book. 7.6.3 Adjust queues when upgrading to VMS V5.5 When upgrading to VMS V5.5, edit JAN_SYS:JANSITECOMMON.COM to com- ment out the initialization of any queues for NJE symbionts. Under VMS V5.5 and later versions, queues do not need to be initialized each time the system is booted. Under VMS V5.5 and later, attempts to initialize queues when starting Jnet result in the message 7-8 On-going Management of BITNET Nodes %JBC-I-QUENOTMOD, modifications not made to running queue for each queue (after the first attempt). For more information, see Section 5.4.2.7. If you followed the recommendations in Section 6.2.3 to create the command procedure SYS$STARTUP:PMDF_INIT_QUEUES.COM to initialize PMDF queues at each boot, you must disable this command procedure as well. Either comment out the line in SYS$MANAGER:SYSTARTUP_ V5.COM that starts the procedure, or remove the procedure from the SYSMAN STARTUP database, depending on how you initially set up PMDF. 7.6.4 Respond to mail from NETSERV For a description of the NETSERV network server, see Section 3.4.7.3. For further information on NETSERV, obtain the file NETSERV INFO from LISTSERV@BITNIC, or the files NETSERV REFCARD and NETSERV HELPFILE from the nearest NETSERV or NETSERV@BITNIC. NETSERV uses passwords to control access to certain privileged server functions, such the fetching of restricted files. Although these functions are not normally used by node administrators (NADs) whose organizations are served by BITNIC, NADs should keep track of their NETSERV passwords in case they are needed. When a new node is created in BITEARN NODES, NETSERV automatically assigns the NAD a password and sends the password to the NAD by electronic mail. (NETSERV recognizes the person on the :USERADM tag as the node administrator (NAD). If that tag does not exist it uses the :ADMIN tag.) NADs can also nominate other privileged NETSERV users, who in turn get their passwords from NETSERV by mail. If you receive a NETSERV password by mail, save the message, with the password and the server address, with your important BITNET mail where you will be able to find it a year or more later. On-going Management of BITNET Nodes 7-9 NETSERV passwords expire after a certain number of months and must be changed. To change your NETSERV password you must know its current value. If you receive mail from NETSERV requesting that you change your password, get out the mail from NETSERV with your NETSERV password from safe keeping and use it to pick a new one according to the instructions that came in the mail requesting the password change. If you cannot remember your NETSERV password, you can request it from the controller (the human manager) of the NETSERV server that services your node. To find out the address of the NETSERV controller of any NETSERV, send a QUERY CONTROLLER command to that NETSERV. To find out which NETSERV serves your node, send a QUERY SERVICE command to NETSERV@BITNIC, and it will respond with various information about the NETSERV service area, including the node of the NETSERV that services your node. 7-10 On-going Management of BITNET Nodes Appendix A Adding an Internet Connection to a BITNET Node NOTE This appendix is a draft, and serves primarily to provide an outline for material for a future edition of this book. Your experiences and other contributions are welcome. To submit material or ideas for this appendix, follow the instructions on the copyright page for submitting comments. This appendix does not attempt to provide complete instructions for connecting to the Internet. Instead, it focuses on those tasks required of BITNET sites to maintain BITNET services while adding the complementary Internet services. A.1 Assumptions for this appendix This appendix assumes that your system is on BITNET and runs a mailer, as described in the first seven chapters of this document. In particular, I assume that you have registered a domain name for your system, either directly through the DDN NIC or indirectly through BITNIC. If you have not completed the tasks in the main part of this book, work through the book from the beginning, following the instructions for implementing an Internet connection as well as a BITNET connection. Do not use this appendix. Adding an Internet Connection to a BITNET Node A-1 A.2 Obtain a network number from the DDN NIC Complete the Internet number template, INTERNET-NUMBER-TEMPLATE.TXT, which can be obtained by sending mail to Service@NIC.DDN.MIL the same way you obtained DOMAIN-TEMPLATE.TXT. The template contains instructions. You will need an assigned Internet network number to install TCP/IP software and to connect to the Internet. Most commercial IP service providers and consortia will help you with this process, but it's easy enough to do yourself if you want to get started with local TCP/IP networking while you arrange for connection to the Internet. A.3 Review acceptable use and other policies Obtain and read the acceptable use policies of the NSFnet- affiliated regional or state network serving your area. (If you are in a border area, you may be eligible to join more than one such network. If so, request general information from each of them.) Policies on acceptable use vary among consortia, and you must carefully compare them to your expected use of the network. Also review the acceptable use policy of NSFnet itself. Colleges and universities should normally have no problems with the policies of any NSFnet-affiliated consortium. Libraries, hospitals, and other non-profit organizations may have to re- strict certain potential uses of the network to conform to the guidelines. For-profit companies are usually better served by com- mercial IP service providers, unless their business is strictly serving government and higher education. Also review prices and other policies. A.4 Join a consortium or arrange for commercial IP service Select the most applicable service or consortium and complete the administrative steps that are prerequisite to obtaining service. A-2 Adding an Internet Connection to a BITNET Node A.5 Install a physical connection Arrange for telecommunications lines and data communications equipment. Sometimes these arrangements are made by the consortium or service provider. Connect your local area network to the wide- area backbone. A.6 Install and configure TCP/IP software Obtain licenses and media for TCP/IP software. Available software ranges from robust and full-featured commercial products to in- expensive or free software provided by universities or by system vendor programs for education. Install and test the software. A.7 Arrange for name service When you connect your organization to the Internet, you must pro- vide primary name service for your domain and arrange for another Internet host to provide secondary name service. The host(s) pro- viding secondary name service should be geographically and logi- cally remote from your primary name server. Often secondary name service is provided by your consortium or service provider. If you advertise mail exchanger (MX) records to the Domain Name Service (DNS), they should be higher priority MX records than those advertised for your domain by Harvard and Berkeley, so that mail from other Internet sites starts coming to you directly immediately rather than coming via INTERBIT mail gateways and BITNET. Adding an Internet Connection to a BITNET Node A-3 A.8 Reconfigure your MAILER Rerun the PMDF autoconfiguration procedure to take advantage of your Internet link for mail. Compare the automatically generated configuration with the BITNET-only configuration you have been using, and make sure you understand the reason for all the differ- ences. Copy any needed customizations from the old configuration to the new one. Test the new configuration thoroughly. A.9 Update DOMAIN NAMES When your name service is operational, change the value of the :SERVED tag in DOMAIN NAMES from YES to NO. This will cause BITNIC to remove the mail exchanger (MX) records from the name servers at Harvard and Berkeley that point your mail to INTERBIT mail gateways. When you add an Internet connection to a BITNET node, if all the hosts in your domain are now directly connected to the Internet, or can receive Internet mail via MX records (other than MX records served by Harvard and Berkeley), you should change the value of the :INTERCONNECT tag in DOMAIN NAMES from NO to YES or MX, respectively. This will allow other dual-connected BITNET-Internet sites to route mail to your domain over Internet if they prefer. Mail addressed to your BITNET address will continue to come in via BITNET. Request all changes to DOMAIN NAMES by sending mail to DOMAINS@BITNIC. Explain the reason for the change and request the new values you need for any affected tags. A-4 Adding an Internet Connection to a BITNET Node A.10 Adjust BITNET topology When your Internet connection is stable, consider switching your BITNET link from BSC to TCP NJE. Retain your BSC line as a backup unless the funding of your Internet connection is totally under the control of your organization and the line itself proves reli- able for several months. You will benefit from higher throughput, redundancy, and fewer BITNET hops to most other sites. If you choose to drop your BSC connection, you will also realize telecommunications cost savings. A.11 Train users on new services Users need to be trained on the new services available, including FTP and TELNET. Continue to provide training on complementary services unique to BITNET, including interactive commands and messages, LISTSERV, SEND and RECEIVE for file transfer, and remote batch service. If your mailer was properly configured before adding the Internet connection, the only change end users should notice in electronic mail service is faster delivery and the lost of "file progress" messages for some addressees. Mail should no longer go through INTERBIT mail gateways. A.12 Switch to Internet News feed If you have been receiving a news feed over BITNET or UUCP, con- sider moving the feed to TCP/IP protocols to take advantage of higher speed lines and path redundancy. Adding an Internet Connection to a BITNET Node A-5 Appendix B Operating BITNET Mail Gateways NOTE This appendix is a draft, and serves primarily to provide an outline for material for a future edition of this book. Your experiences and other contributions are welcome. To submit material or ideas for this appendix, follow the instructions on the copyright page for submitting comments. The PMDF configuration described in Chapter 6 provides a "gateway" between BITNET mail and the domain name of your own system. This appendix is concerned with gateways on your system that route mail between BITNET and other systems. This appendix does not attempt to provide complete instructions for operating mail gateways for third parties. It attempts to pro- vide frequently needed information on providing such gateways for an organization's own use rather than for the global networking community at large. If you intend to provide such a service be- tween BITNET and the entire Internet, see Section B.3 in a future edition of this appendix. Operating BITNET Mail Gateways B-1 B.1 Mail gateways to domains with mailers This section covers two common situations. Your system or VAXcluster provides a mail gateway between BITNET and: 1. other VAX systems running PMDF, via a DECnet network, and/or 2. other hosts running SMTP, over a local TCP/IP network. In the second situation, I presume that the TCP/IP network is not connected to the Internet. If the TCP/IP systems are connected to the Internet, then use the instructions in the main part of this book. The gateway function requires a mailer on each system for which your system will accept mail. In the first case, the mailer func- tion is provided by PMDF; in the second case, SMTP software, such as the SMTP mailer provided with MultiNet or the sendmail compo- nent of the UNIX operating system, provides the mailer function. Assign a domain name in your organization's domain to each TCP/IP host or DECnet node to be served. Using the instructions provided in the PMDF documentation, config- ure a SMTP-over-DECnet or SMTP channel to connect to the non- BITNET systems. Add rewrite rules to your PMDF configuration file to route mail received by your system from BITNET to the appropriate channel. Do not attempt to set up NJE node names for the non-BITNET nodes. If you do, remote BITNET users will then expect the non-BITNET systems to support other BITNET applications, such as interactive messages and NJE file transfer. All mail to the non-BITNET nodes should go to their domain names. B-2 Operating BITNET Mail Gateways B.2 Providing name service for connected domains If your system will be a domain name server, consider providing name service for any BITNET-only (that is, non-Internet) nodes reachable through your organization. To provide name service for BITNET-only nodes, your system will advertise mail exchange (MX) records pointing to your organization's BITNET-Internet mail gateway to other servers in the Domain Name System. When your domain name server and your organization's BITNET-Internet mail gateway are operational, Internet users anywhere can send mail to domain addresses of the BITNET-only nodes that can be reached through the BITNET-Internet mail gateway at your organization. An example may serve to clarify this configuration. Suppose your organization is Bay College, the hypothetical institution de- scribed in Section 3.5, and that Acme Corporation has registered the domain Acme.Com for a VAXcluster on BITNET connected to your BITNET hub BAYACB. If you configure a BITNET-Internet mail gateway on your VAXcluster BAYACA (also called Aca.Bay.Edu) that accepts mail for the Acme.Com domain and provide name service for the Acme.Com domain, any Internet user can send mail to Acme mail boxes. For further information on providing domain name service for other domains, see the documentation for your domain name server software (usually part of your TCP/IP software). The configuration of domain names servers is outside the scope of this book. B.3 Operating an INTERBIT mail gateway The requirements for operation of an INTERBIT gateway on a VAX system running VMS have not yet been clarified, as all official INTERBIT hosts currently run the VM operating system. The CREN rules for INTERBIT gateways are in the file INTERBIT STANDARD, available from LISTSERV@BITNIC. Discussion of INTERBIT operational issues occurs on a LISTSERV list that closed to subscriptions from the BITNET community at large. Operating BITNET Mail Gateways B-3 An attempt will be made to compete this section in a future edi- tion. B.4 Mail gateways to Mail-11 domains When PMDF exchanges mail with VAX systems running only VMSmail, it must use the Mail-11 protocol (a DECnet application protocol). Mail-11 is a very old protocol, and has many problems that make it unsuitable for production mail, some of which are listed here. Therefore, only undertake to set up this configuration if you cannot get mailer software installed on the remote VAX systems. The principle reason to attempt this configuration is save the cost of PMDF licenses. Another reason is to exchange mail with non-VAX/VMS systems that have Mail-11 software, such as Digital PDP-11 minicomputers. Here are some reasons to avoid this approach, if at all possible. The remote system is the system running only Mail-11 software (for example, a VAX running VMS and VMSmail but without PMDF, MX, or TCP/IP sofware). o Users of the remote system cannot use IN% as their address prefix, as described in the documentation. They must use IN: instead. o Users of the remote system cannot use PMDF utilities, SEND/FOREIGN, and other PMDF features. In the future, this will prevent them from using the new Internet standard multi-media mail, which is not supported by Mail-11. o Mail-11 systems have six-character DECnet node names, and cannot support domain style names. The DECnet node names must be distinguished some how from BITNET node names and TCP/IP relative (also called "short form") host names. B-4 Operating BITNET Mail Gateways A Mail-11 mail gateway is often considered for a mixed intercon- nect VAXcluster with many satellites, to avoid running PMDF on each satellite. There are additional reasons that apply only to Mail-11 to BITNET mail gatewas serving a single VAXcluster. o The MAIL$SYSTEM_FLAGS logical name must be set to 0 to indicate the VAXcluster is hetergeneous; that forces all mail between cluser members to go through DECnet. (Normally, such mail should be written into the recipients MAIL.MAI file locally, just like mail within a single member.) o Mail replies only work if the sending node (say, a workstation) is on the network, even if the sending user is logged into another satellite. o All PMDF batch queues must run on boot node (which is already a single point of failure for cluster due to single system disk) instead of running on any idle node. o All messaging jobs must run on the boot node, and there will be many more such jobs, because every mail message sent or received on a satellite will require a DECnet job. One way to avoid the problems of Mail-11 transport within a VAXcluster is to prohibit mail on the satellites. All satellite users must use SET HOST or X-clients on boot node to send and receive their mail. If at all possible, avoid Mail-11 to BITNET mail gateways. If you must use this type of configuation, refer to the PMDF System Manager's Guide for additional information. Operating BITNET Mail Gateways B-5 Appendix C Migration from Gmail NOTE This appendix is a draft, and serves primarily to provide an outline for material for a future edition of this book. Your experiences and other contributions are welcome. To submit material or ideas for this appendix, follow the instructions on the copyright page for submitting comments. GMAIL should no longer be used. Its primary purpose is to send mail to INTERBIT and other mail gateways. The CREN Terms and Conditions of Membership and Affiliation require that all CREN members that use INTERBIT gateways must install a BSMTP-compliant mailer. GMAIL produces correct BSMTP-format messages, but cannot accept them. To remove GMAIL from your system, perform the following tasks: 1. Log into a privileged account. 2. Find the location of the GMAIL directory: $ SHOW SYMBOL GMAIL 3. Note the directory specification in the symbol value, and set your default directory there. Migration from Gmail C-1 4. Create a new GMAIL command procedure in the same directory that prints a message to users requesting that they use VMSmail and PMDF instead. Here is one way to enter such a message: $ CREATE GMAIL.COM $ TYPE SYS$INPUT GMAIL has been removed. Please send all mail using the VMSmail Utility (MAIL). To send to Internet and BITNET addresses, enter addresses of the form IN%"username@host.subdomain.domain" and IN%"USERNAME@nodename.BITNET" respectively. If you have any questions, please contact the System Manager. 5. You may also want to use your regular procedures to announce the change to all system users. 6. Now delete all the other files in the current directory. 7. Finally, send electronic mail to author of GMAIL, Ed Miller, GMAIL@SLACVX.BITNET, to ask him to remove your name from the GMAIL list because you will not be using the program in the future, and to give him a well-deserved "Thank you!" for making GMAIL available to the networking community through the years. C-2 Migration from Gmail Index __________________________________________________________ ___________________________ A ___________________________ ___________________________ B adding BITNET nodeso5-32 ___________________________ address rewriting, mail, by BACKUP utilityo5-13, 6-3 INTERBIT mail gatewayso batch, remoteo5-2 1-8 batch/print subsystem AFDo1-5, 5-2, 6-11 use of SCSNODE nameo4-3 aliases batch queueo3-7 duplicateo6-22 batch servero3-16 ALIASES.o6-20 Batch Simple Mail Transfer aliases fileo6-20 Protocolo1-1 ALL-IN-1o2-2 Bay College exampleo3-6, user nameso3-19 3-19 analog lineso5-10 binary synchronous ANU Newso6-39 communicationsoxv, 5-9 Application System/400o BITEARN NODESo1-3, 1-5, 3-16 3-16, 5-27, 6-1, 6-28, Arizona State University 6-30, 6-31, 6-32, 6-38, exampleo3-12 6-39, 6-41 Arnold, Stephen L.oii monthly update cycleo Arnold Consultingoii 5-37 Arnold Consulting exampleo update procedureo5-27 5-33, 6-4, 6-14, 6-16, BITNEToxi 6-20, 6-28, 6-33 access by terminal ASU.Eduo3-12 emulationo5-2 autoanswer option of adding nodeso5-32 VMSINSTALo4-1, 6-5, benefitso5-2 6-6 choosing BITNET systemso autoconfiguration fileso 5-1 6-15 continuing costso5-9 AUTOGEN command procedureo disconnectiono1-11 4-2 initial costso5-9 automatic file distribution initial link startupo o1-5, 5-2, 6-11 5-25 automatic replies mail conceptso1-3 to POSTMASTER's mailo nameso3-4 3-14 node registrationo5-27 autostart queueso6-4 performanceo5-9 availabilityo7-3 planning external linkso 5-5 planning internal linkso 5-7 Index-1 BITNET (cont'd) CONFIG.COM command planning link protocolso procedureo6-12 5-9 configurationoxvii planning VAXcluster links CONFIGURE command procedure o5-8 o6-13 Principal Nodeso5-4 configuring network routing tableso5-37 softwareo4-1 topology planningo5-1 :CONNECT tago5-36 transports conventionsoxvii installationo5-10 copyrightoii BITNET-2 INFOo5-5 Corporation for Research BITNET GATESo1-8 and Educational BITNET II Networkingoii coreo5-5 CRENoii BITNET II coreo6-11 Board of Trusteeso1-2 BITNET II protocolo4-5 dueso3-1 BITNET mail gatewayo6-14 membershipo3-1 BITNET node registrationo recommendationo3-8 6-28 representativeso3-2 BITNET_QUEUE symbolo6-13 requirementso1-6, 6-10 BITNICo1-3, 1-5, 1-6, 2-4, Technical Advisory 2-5, 3-4, 3-10, 3-16, Committeeo1-2 5-5 terms and conditionso1-6 blanks CREN TERMSo1-6, 5-4 in user nameso3-19 ___________________________ boldfaceoxvii D Bookreadero6-8 ___________________________ setupo6-9 daily management taskso7-4 Boston College exampleo Dataphone Digital Serviceo 6-35 5-11 BSCoxv, 5-9 daylight timeo7-7 BSMTPo1-1, 1-3, 1-5, 3-15 DCL tables envelopeo1-4 replacingo6-6 BSMTP ADDENDUMo1-7 DDN NICo3-8, 3-10, 3-12, ___________________________ 4-7 C document servero3-11 ___________________________ DECnet Carnegie Mellon University nameso3-4 see CMU-TEK IP/TCP networko2-3 channel networksoxv keywordo6-18 softwareo2-3 ClusterWide software DECnet alias licensingo5-3 nameso3-4 CMU-TEK IP/TCPo4-6, 5-19 DECnet objects commands, interactiveo5-2 for DNA NJE linkso5-24 commentsoii DECnet-VAXo4-1, 6-12 compiled configurationo configurationo4-4 6-22 nameso3-5 to 3-7 compiled configuration, softwareo2-4 PMDFo6-22 startupo6-7 concepts use of SCSNODE nameo4-3 BITNET mailo1-3 versionsoxiv conferencingo5-2 DECnet-VAX Extensionso3-7, 4-4 2-Index DECnet-VAX Extentsions domain nameso3-4 configurationo4-4 DOMAIN NAMESo1-5, 6-1, DECUSo6-42 6-10, 6-11, 6-23, 6-30, DECUServeo6-42 6-32, 6-41, 7-7 DECUS exampleo5-29 domain name systemo6-30 DECUS Symposium exampleo DO_CRDB symbolo6-13 3-8, 3-9, 5-33, 6-13, DSNlinko6-42 6-28 use of SCSNODE nameo4-3 DECW$BOOK logical nameo6-9 DSNlink softwareo3-6 DECW$PRIVATE_APPS_SETUP DSU/CSUo5-11 command procedureo4-3 ___________________________ DECwindows E startupo6-7 ___________________________ use of SCSNODE nameo4-3 EARNo1-3, 1-5 default channelo6-18 traffic requiremento5-20 Defense Data Networko3-8 Electronic Mail Association delegation o7-2 Postmasteroxii EMAo7-2 DELIVER facilityo6-19 Excelan TCP/IPo4-6 DELIVERY utilityo3-14 ___________________________ device names F use of SCSNODE nameo4-3 ___________________________ dial-up lineso5-11 facsimileo1-11 Digitaloxi faxo1-11 Digital Equipment :FFORMAT tago5-35 Corporationoxvi, 4-1 file formatso5-35 direct mail transmissiono file progress messageo5-38 1-1 file queuing by sizeo5-19 directory serviceso1-11, file servero1-11 3-16 file transfero5-2 direct transmission of FILE utilityo1-7 mailo1-1 FORTRAN carriage controlo disclaimeroii 1-7 DISK DUMP file formato5-35 forwarding mail disk quotaso3-14 for MAILERo3-15 DISMAIL flago3-14 for MAINTo3-17 Distributed Name Serviceo for POSTMASTERo3-14 3-7 for ROOTo3-17 nameso3-4 for SMTPUSERo3-15 DNA NJE linkso5-24 for SYSTEMo3-17 DNSo6-30 forwarding mail to listso documentationoxv to xvi 1-11 document conventionsoxvii FQDNo1-3, 1-4 documenting software full mesh topologyo5-7, installationso4-2 5-8 domain FUSION for VAX/VMSo4-6 nameso3-8 to 3-10 FUSION TCP/IP for VMSo5-19 registrationo6-30 ___________________________ domain application template G o3-11 ___________________________ DOMAIN GUIDEo3-8, 3-10, :GATEMAST tago6-32 3-11, 6-30, 6-31, 6-32 GATEWAY STANDARDo1-8 domain nameo2-2, 2-5 Giese, Hans-Ulricho5-37 registeredo4-7 GMAILo1-9, C-1 to C-2 registrationo6-33 Index-3 group communicationo5-2 Internet discussion groupso guest accounto3-10 6-38 guest accountso5-3 Internet discussionso6-41, ___________________________ 7-6 H Internet Protocolo3-11 ___________________________ :INTERNET tago6-32 %-hacko1-10 IP addresso3-11 HEADERBOTTOM channel italicoxvii keywordo6-19, 7-5 IUP.Eduo3-9 HEADEROMIT channel keywordo ___________________________ 6-19 J headers, mail ___________________________ excessiveo6-19 JANCONFIG command procedure held messageso7-5 o5-15 heterogeneous VAXclustero JANLINKS.JCPo5-16, 5-18 2-3 JANLOAD.COM homogeneous VAXclustero2-3 sharing in a VAXclustero definitiono3-7 5-20 hopso5-7 JANROUTES.JCPo5-20, 5-26 hosto3-8 JANSITECOMMON command host aliaso4-8 procedureo5-20 Hostmastero3-11 JANSTART.JCPo5-18 ___________________________ JANTIDY.COMo5-21 I JANTIDY command procedureo ___________________________ 5-23, 7-4 IBMo3-16 JAN_SYSTEM_FLAGS logical IBM national characterso nameo5-20 3-12 JESo3-17 Indiana University of Jnetoxv to xvi, 1-4, 2-2, Pennsylvania exampleo 3-16, 3-17, 3-19 3-9 autoconfigurationo5-15 Info-MultiNeto6-42 Jnet cluster nameo5-15 Info-PMDFoxv, 6-42 local serverso5-16 INFOREPo3-2 network sizeo5-15 initial NJE routing tableso time zoneo5-16 5-25 batch and print serverso Innosoft International, 5-17 Inc.oxv, 4-1, 4-7 configurationo5-1, 5-14 installationoxvii device connection command installing network software procedureo5-20 o4-1 documentationoxvi INSTALL_COMPILE command file locationo5-12 procedureo6-23 initial link startupo INTERBIT mail gatewayo1-4, 5-25 1-7, 4-8 installationo2-4, 5-1, INTERBIT mail gatewayso1-2 5-12 :INTERCONNECT tago6-32 on VAXclusterso5-14 interfaces optional link driverso synchronouso5-12 5-14 Interneto1-2, 1-4, 1-6, link definition procedure 3-10 o5-18 adding a connection to a link parameter fileso BITNET nodeoA-1 5-23 connectiono2-3 4-Index Jnet (cont'd) licenseoii link startup procedureo License Management Facility 5-18 o3-6 local mail delivery use of SCSNODE nameo4-2 procedureo5-23 line monitoro5-23, 7-3 login command procedureo link parameter fileso5-23 5-18 link protocolso5-9 nightly clean procedureo links, NJEo5-1 5-23 :LINKS tago5-36 postconfigurationo5-17 LISTSERVo1-6, 1-7, 1-8, RECEIVE utilityo7-4 3-8, 3-13, 3-15, 3-19, route definition 5-2, 5-4, 5-5, 5-22, procedureo5-20 5-27, 5-28, 6-32, 6-38 routing tables AFD ADD commando6-11 installationo7-6 GET commando1-6, 6-11 security listso7-6 batch servero5-17 subscriptionso6-39 site-specific common LMD.COMo3-15, 6-24 startup procedureo LMD.COM command procedureo 5-20 5-23 startupo6-7 Local Area Transporto5-24 startup procedureo5-12 LOGGING channel keywordo use of SCSNODE nameo4-2 6-18, 6-19 use of TCP/IP softwareo login directoryo3-14 4-5 LONG_NAMES command versionsoxiv procedureo6-20 Jnet BSC/370o5-10 ___________________________ Jnet cluster M nameo3-13 ___________________________ nameso3-4 :MACHINE tago5-36 Jnet clusters Madison, Matto1-7 messageso5-21 mailoxi Jnet section MAIL$BATCH batch queueo global page requirementso 6-3, 6-8 5-15 MAIL$SYSTEM_FLAGS logical Jnet TCP NJEo4-6, 5-19 nameo4-5 JNET_STARTUP command mail concepts, BITNETo1-3 procedureo6-7 maileroxi, 1-1 JOBo3-16, 3-21 benefitso1-9 Joiner Software, Inc.oxv, definitiono1-3 3-16, 4-1, 4-6 external viewo6-1 ___________________________ installationo2-5, 6-1 K registrationo6-1 ___________________________ tableso1-5 Knox exampleo6-13 MAILERo3-15, 3-18, 3-21, ___________________________ 6-14 L mailer fileso6-10 ___________________________ mailer tableso7-7 LATo5-24 :MAILER tago6-32 LAT$SYSTARTUP command mail gateway procedureo5-24 definitiono1-3 LAT startup procedureo5-24 mail gatewayso1-2 layered products operatingoB-1 use of SCSNODE nameo4-3 mail headers excessiveo6-19 Index-5 MAINTo3-16, 3-21 names (cont'd) managemento7-1 planningo3-1 master nodeo5-22 assumptionso3-1 maximum configurationo6-22 checklisto3-5 Meadows, Joeo1-7 suggested procedureo messages, interactiveo5-2 3-4 Miller, Edo1-9 SCSNODEo3-4, 3-5 to 3-7 MMo2-2 usero3-13, 3-18 MODATT COMo1-7 user, assigningo7-2 modem UUCPo3-4 autodialo5-11 VAXclustero3-4 diagnostic and test VAXcluster aliaso3-7 to featureso5-11 3-8 V.29o5-10 VAX P.S.I.o3-4 V.32o5-11 VMS usero3-18 MODPARAMS.DATo4-2 name servero3-11 monthly management taskso name serviceo6-30, A-3 7-6 national characterso3-12 Motifo6-9 NETCONFIG command procedure :MSGS tago5-36 o4-3 MultiNeto3-12, 4-6, 5-19 NETDATA file formato5-35 online documentationo6-9 netiquetteo7-2 MULTINET_STARTUP command NETSERVo3-15 procedureo6-7 GET commando1-7 multistreamingo5-10, 5-20, passwordo7-9 5-24 network discussionso6-38 MVS operating systemo3-16, Network Job Entryoxi, 1-1, 3-17 5-1 MXo1-7 network number MX INFOo1-7 assignedo4-7 ___________________________ Network Research N see FUSION TCP/IP for VMS ___________________________ newso6-38, 6-39, 7-6 Novell, see Excelan NEWTAGS DESCRIPTo5-28 NADo7-9 :NICK tago6-32 name NJEoxi, 1-1, 5-1 Jnet clustero3-13 linkso5-1 name authorityo3-2, 3-9, node nameo6-14 3-19, 4-7 nodeso5-1 name planningo2-3 tago1-2, 1-10 names NJE output limitationo5-20 ALL-IN-1 usero3-19 NJE software BITNETo3-4 configurationo5-1 planningo3-12 installationo5-1 DECneto3-4 nodal message recordo3-17, DECnet aliaso3-4 5-20 DECnet-VAXo3-5 to 3-7 nodeo1-1 difficulty in changingo node administratorso7-9 3-2 nodes, NJEo5-1 Distributed Name Serviceo :NODE tago5-35 3-4 NSFneto5-5 domaino3-4, 3-8 to 3-10 general considerationso 3-2 Jnet clustero3-4 6-Index ___________________________ PMDF (cont'd) O VAXcluster startupo6-27 ___________________________ versionsoxiv objectivesoxi PMDF.CNF official host nameo6-15 editingo6-15 Open Systems Interconnecto PMDF-FAXo6-2 4-4 PMDF_INIT_QUEUES command option file, PMDFo6-22 procedureo6-3, 6-7, 6-8 order of software PMDF_ROOT:[TABLE] installationo4-1 default for PMDF OSIo4-4 autoconfigurationo OSI Application Kernelo4-4 6-12 overviewo2-1 PMDF_START_QUEUES command ___________________________ procedureo6-4, 6-7, P ___________________________ 6-8, 6-27 Process Software, see PMDF_SUBMIT_JOBS command TCPware procedureo6-7 PAKo4-4 PMDF_USERo3-18, 6-2 Pascal compilero6-6 Pony Expresso2-2 peer nodeo5-9 POSTHEADONLY channel people tag keywordo6-18, 6-19, for Postmastero5-29 7-5 permission to reproduce and POSTMASTo1-7, 3-13, 3-21 distributeoii Postmasteroxi personal computerso5-2 delegationoxii planning nameso3-1 people tago5-29 checklisto3-5 responsibilitiesoxii suggested procedureo3-4 POSTMASTERoxi, 1-7, 3-13, PMDFoxv, 1-3, 1-6, 1-10, 3-21, 5-31, 6-11, 6-15, 2-2 6-20, 7-4, 7-5 aliases fileo6-20 conflicting useo5-13 alias fileo6-20 privilegeso5-13 autoconfigurationo6-12 POSTMAST STANDARDo3-13 batch queueso6-3, 6-7, prefaceoxi 7-4, 7-6 Princeton Universityo6-11 channel queueso7-4, 7-5 Principal Nodeo5-4 compiled configurationo Principal Nodeso5-4 6-22 PRINT file formato5-35 maximumo6-22 printing, remoteo5-2 configuration privacyo7-3, 7-4, 7-5 stepso6-10 privilegesoxii documentationoxv Product Authorization Key "don't"so6-24 DECnet-VAXo4-4 file locationo6-2 VAX-VMSo4-2 installationo6-2 pseudodomaino6-14 online documentationo6-8 pseudonodeo5-8 option fileo6-22 PUNCH file formato5-35 period batch jobso6-7 source fileso6-6 startupo6-6 UICs foro6-2 use of TCP/IP softwareo 4-6 user nameo3-18 Index-7 ___________________________ SMTPUSERo3-15, 6-14 Q STARTNET command procedureo ___________________________ 6-7 Qman command procedureo7-5 star topologyo5-8 QSYSOPRo3-16 startup procedure, systemo QUERY commando5-20, 5-26 5-18 ___________________________ State University exampleo R ___________________________ 5-6 registration subclustero2-3, 3-7 BITNET nodeo1-3, 2-4 SYLOGICALS command domain nameo3-10 to 3-12 procedureo4-5, 5-12, mailero1-5, 2-5 5-13, 6-2, 6-3, 6-8 mail gatewayo1-5, 2-5 synchronous interfaceso of BITNET nodeso5-27 5-12 reinstalling software SYS$SYLOGIN command productso4-2 procedureo5-18 rejection, mail, by SYS$UPDATE directoryo4-1 INTERBIT mail gatewayso SYSGENo3-6 1-8 SYSMANo6-6 Rensselaer Polytechnic STARTUP databaseo4-2 Instituteo1-7 SYSMAN STARTUP facilityo REQUIRED INFOo5-27 6-3, 6-4, 6-7, 6-8 REQUIRED INFO1o5-27 SYSNAM privilegeo3-15, requirements, CRENo1-6 3-17 Return keyoxvii SYSTARTUP_V5 command RFC 1123o3-13 procedureo5-18, 6-3, RFC 822o1-4, 3-13 6-4, 6-7, 6-8 Rice Mailo1-4 SYSTEMo3-16, 3-21, 6-12 ROOTo3-16, 3-21 system clocko7-7 routing tableso1-3 SYSUAFo3-7, 3-14, 3-15, installingo5-25 installing initialo5-39 3-16, 3-17, 3-18, 4-5, monitoring updateso5-38 5-13, 6-2 :ROUTTAB tago5-36 ___________________________ RSCSo1-4, 3-17 T ___________________________ ___________________________ S tago5-27 ___________________________ NJEo1-2 SCSNODEo4-2 tags nameso3-4, 3-5 to 3-7 DOMAIN NAMESo6-32 SCSNODE name TCP/IP changingo4-2 host nameo6-14 SCSSYSTEMIDo4-2 networksoxv securityo6-6, 7-2 softwareo1-4, 2-3 SENDHEAD channel keywordo TCP/IP Services for VMS 6-18, 6-19, 7-5 see VMS/ULTRIX Connection :SERVED tago6-32 TCP/IP softwareo4-1 short-form host nameso4-7 compatible with Jnet TCP Simple Mail Transfer NJEo4-6 Protocolo4-6 compatible with PMDFo4-6 :SITE tago6-32 configurationo4-5 SKIP_XMAILER symbolo6-13 for BITNET linkso4-5 slow BITNET linkso5-7 for Internet mailo4-6 SMTPo4-6 installationo4-5 8-Index TCP NJE links VAXclustero1-6, 2-2, 3-6, line nameo5-19 3-9, 3-12, 4-5, 5-24, TCP NJE protocolo4-5 6-6, 6-12, 6-14, 6-15 TCPwareo4-6 alias TECHREPo3-2 nameso3-7 to 3-8 information packeto3-2 common-environmento3-7 Tektronix TCP/IPo4-7 homogeneouso3-7, 5-4 terminology, newoxvii Jnet routing tables ono testingo5-25 5-27 TGV, Inc. multiple-environmento3-7 see MultiNet nameso3-4 time zoneo6-6, 7-7 use of SCSNODE nameo4-2 topology VAXcluster alias nameo4-4 NJEo5-8 VAXclusterso5-21 trademarksoii VAXcluster Softwareo3-6 trainingo7-2 VAX P.S.I. troubleshootingo5-25 nameso3-4 ___________________________ VAXstations U as BITNET nodeso5-3 ___________________________ versionsoi, 2-2 UCXo4-6 versions/BEGINoxiv UCX$STARTUP command versions/ENDoxv procedureo6-7 VM Mailero6-11 UICo6-2 VM operating systemo3-15, UICs 3-17 for PMDFo6-2 file naming conventionso unreliable BITNET linkso 1-3 5-7 VMS/ULTRIX Connectiono4-6, UPDATE jobs 5-19 address foro5-28 VMS batch/print subsystemo UPDATE PROCEDURo5-27 5-21 update procedureo5-27 VMSDUMP file formato5-35 update procedure for VMSINSTALo5-14, 6-5 BITEARN NODESo5-27 VMSINSTAL command procedure update servero5-27 o4-1 upgradeso7-8 VMSmailo1-10, 2-2, 3-13 uppercaseoxvii configurationo4-5 user agento1-2, 1-4, 2-2 profileo3-7 User Identification Codeo VMS operating systemoxi, 6-2 xiv, 1-3, 2-2, 3-6, 4-1 user interfaceoxi, 1-2 change in V5.5o5-21, user name planningo3-13 6-3, 6-4, 6-8, 7-8 user nameso3-18 documentationoxvi user names, assigningo7-2 system generation Utility UUCP o3-6 nameso3-4 system integrated ___________________________ V productso4-4 ___________________________ version 4 compatibilityo V.29 modemso5-10 5-14 V.32 modemso5-11 versionsoxiv vacation programo3-14 VAXoxi, xiv Index-9 ___________________________ W ___________________________ WHOISo3-12 WIN/TCP for VMSo4-6, 5-19 Wollongong Group, The see WIN/TCP for VMS workstationso5-2 ___________________________ X ___________________________ XMAILER NAMESo1-5, 6-1, 6-10, 6-11, 6-13, 6-23, 6-32, 7-7 10-Index