Bitnet Postmaster's Guide (V00539)
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,is granted by CREN to reproduce 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