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