Release Notes V3.0
DSNlink Version 3.0 for OpenVMS
Release Notes
November 4, 2000
These release notes describe new features, fixed problems, and known
bugs in DSNlink Version 3.0.
Revision/Update Information:
This is a revised manual, which
supersedes all previous versions.
Operating System and Version: OpenVMS Versions 5.5-2 (on VAX
systems only), 6.2, 7.1, and 7.2
Software Version:
DSNlink Version 3.0 for OpenVMS
© 1989, 2000 Compaq Computer Corporation.
Compaq, DECnet, VAX, and the Compaq logo Registered in U.S. Patent and Trademark Office.
Alpha, OpenVMS and Tru64 are trademarks of Compaq Information Technologies Group, L.P.
Motif and UNIX are trademarks of The Open Group.
All other product names mentioned herein may be trademarks or registered trademarks of their
respective companies.
The MD5 software contained in this product is derived from the RSA Data Security, Inc. MD5
Message-Digest Algorithm.
Confidential computer software. Valid license from Compaq required for possession, use or copying.
Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government
under vendor’s standard commercial license.
Compaq shall not be liable for technical or editorial errors or omissions contained herein. The
information in this document is provided "as is" without warranty of any kind and is subject
to change without notice. The warranties for Compaq products are set forth in the express
limited warranty statement accompanying such products. Nothing herein should be construed as
constituting an additional warranty.
This services tool software is the property of, and contains confidential technology of, Compaq.
Possession and use of this software is authorized only pursuant to the Proprietary Service Tool
Software License contained in the software or documentation accompanying this software.
Exports of this product are subject to U.S. Export Administration Regulations pertaining to
encryption items and may require that the exporter obtain individual export authorization from the
U.S. Department of Commerce.
This document was prepared using VAX DOCUMENT Version 2.1.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
1 What’s New in DSNlink Version 3.0?
1.1
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.2
1.3
1.4
1.5
1.6
1.6.1
1.6.2
1.6.3
1.6.4
1.7
1.7.1
1.7.2
1.7.3
1.7.4
1.7.5
1.7.6
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
There Are Encrypted and Nonencrypted Versions . . . . . . . . . . . . . . . . . . .
About the Kit with Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
About the Kit Without Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Improved Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
New Authentication Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Login Is Enhanced When Using RC4 Encryption . . . . . . . . . .
Restrictions on Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interoperability Between DSNlink Version 3.0 and Previous Versions . . . .
The DSNlink Getting Started Has Been Removed . . . . . . . . . . . . . . . . . . .
Netscape Replaces the Mosaic Browser . . . . . . . . . . . . . . . . . . . . . . . . . . .
A PostScript Version of the User’s Guide is Included . . . . . . . . . . . . . . . . .
Changes in TCP/IP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP Connections Use Single-Port Mode on A Nodes . . . . . . . . . . . .
Lynx No Longer Requires Digital TCP/IP Services for OpenVMS
(UCX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Installation No Longer Requires Digital TCP/IP Services for
OpenVMS (UCX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enhancements Permit MultiNet and TCPware Use . . . . . . . . . . . . . . .
Enhanced OpenVMS Cluster Support . . . . . . . . . . . . . . . . . . . . . . . . . . . .
You Can Install Once on Mixed OpenVMS Clusters if They Have a
Common Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The OpenVMS Cluster Alias Name Is Not Used for DSN$DATA
Subdirectory Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requirements for A and B Nodes Have Changed . . . . . . . . . . . . . . . . .
Node Name Definitions in the Configuration File Have Changed . . . .
You Must Be Logged into the SYSTEM Account for Installation . . . . .
The Executing Node’s Name Appears in Log Files . . . . . . . . . . . . . . . .
Startup and Shutdown Files Are in DSN$COMMAND . . . . . . . . . . . . . . .
Installed Images Are Removed by DSN$SHUTDOWN.COM . . . . . . . . . . .
Motif Resource Files Are in DSN$ROOT:[DAT] . . . . . . . . . . . . . . . . . . . . .
DSNlink Does Not Require the SYS$BATCH Queue . . . . . . . . . . . . . . . . .
Obsolete Files Are Deleted After a Successful Installation . . . . . . . . . . . .
VT Menu Includes Remote Login Authorization . . . . . . . . . . . . . . . . . . . .
Startup Files and Logical Names for the SRQ Utility Are Included in the
DSNlink Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The SPAWN Command Works from the ITS Command Line . . . . . . . . . . .
The Service Request Application Allows Hours and Minutes in the
Beginning and Ending Date Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DECwindows Motif Is No Longer Required for the Command Line
Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1–1
1–1
1–2
1–2
1–2
1–3
1–3
1–3
1–3
1–3
1–4
1–4
1–4
1–5
1–5
1–5
1–6
1–6
1–6
1–6
1–7
1–7
1–7
1–7
1–7
1–7
1–8
1–8
1–8
1–8
1–9
1–9
1–9
iii
1.18
1.19
1.20
1.21
The Logical Name DSN$MAIL_CC_RECIPIENT Has an Equivalent In
DSNlink Version 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recipients for Communique Mail Are Defined by Configuration File
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Your A Node is Set to be the Receiver Node . . . . . . . . . . . . . . . . . . . . . .
REPKO Modem Scripts Have Been Added to the Kit . . . . . . . . . . . . . . .
..
1–9
..
..
..
1–10
1–11
1–11
Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incoming Applications Using X.25 Produced DSN_K2 Log Files . . . . .
An Incoming DECnet Connection Was Misinterpreted as a TCP/IP
Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Some File Copies Did Not Create a Work Unit . . . . . . . . . . . . . . . . . .
TYPE-F-WRITEERR Message Appeared After a File Copy
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mail Notification After a File Copy Was Inconsistent . . . . . . . . . . . . .
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation on a VAX in a Mixed OpenVMS Cluster Resulted in
Missing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Route Map Entry for X.25 Corrected . . . . . . . . . . . . . . . . . . . . . . . . . .
The Startup File Was Provided on the Installing Platform Only . . . . .
SYS$COMMON Was Not Translated to Device and Directory
Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using an ITS Initialization File Resulted in an ACCVIO . . . . . . . . . . .
ACCVIO After Mistyping the Show Database/Open Command . . . . . .
ITS Extracted Articles Could Have All the Characters in the First
Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interactive Command Procedures Produced the Timed Read Error . . .
Modem Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Customers Could Make Only One ITS Connection with the Modem
Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modems Did Not Hang Up After a DSNlink Session . . . . . . . . . . . . . .
DTE Speed in MDDF Was Not Set on the DTE Device . . . . . . . . . . . .
Multiple Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Startup Was Sent to the Wrong Batch Queue on an OpenVMS
Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
All DSN Commands Invoked the DSN Modem Daemon . . . . . . . . . . . .
DECthreads Bugcheck Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The DSN SHOW VERSION Command Response Is Improved . . . . . . .
Network Exerciser Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining DSNGATEWAY_TRACE Resulted in a Transport Error . . . . .
The Network Exerciser Had Obsolete Authentication and Encryption
Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Verbose Qualifier Had No Effect . . . . . . . . . . . . . . . . . . . . . . . . . .
The Initial Network Exerciser Test Failed Using X.25 . . . . . . . . . . . . .
Network Exerciser Stopped Responding After a Midtest Error . . . . . .
IVP Failed Because of Authentication Key File Format . . . . . . . . . . . .
Route Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DSNMAPQ Did Not Add Entries to the Route Map . . . . . . . . . . . . . . .
Route Map Access Time Reduced . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communications from a B Node Did Not Go Through the A Node . . . .
2–1
2–1
2 Fixed Bugs
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.2.3
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.5
2.5.1
2.5.2
2.5.3
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.7
2.7.1
2.7.2
2.7.3
2.7.4
2.7.5
2.7.6
2.8
2.8.1
2.8.2
2.8.3
iv
2–1
2–1
2–2
2–2
2–2
2–2
2–2
2–3
2–3
2–3
2–4
2–4
2–4
2–4
2–5
2–5
2–5
2–5
2–5
2–6
2–6
2–6
2–6
2–7
2–8
2–8
2–9
2–9
2–9
2–9
2–9
2–10
2–10
2–11
2–11
Route Map Single-Port Mode Was Not Retained . . . . . . . . . . . . . . . .
Service Request Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Some Routing Codes Mistakenly Sent Acknowledgement Mail . . . . .
SICL Requests Via a Modem Might Fail During Batch Processing . .
Service Request Submitter’s Name Was Lost . . . . . . . . . . . . . . . . . . .
DSN%"SRQ$NULL Was Returned for Routing Codes That Generate
an Automatic Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.9.5
The Create Service Request Tutorial Did Not Appear . . . . . . . . . . . .
2.10
SRQ Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10.1
The SRQ Utility’s Hardware Database Could Not Be Accessed . . . . .
.
.
.
.
.
2–11
2–11
2–11
2–11
2–12
.
.
.
.
2–12
2–13
2–13
2–13
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
X.25 Is Not Supported for Intra-Cluster A and B Node
Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2
Do Not Use Rooted Logical Names for the Installation Device . . . . . . .
3.1.3
OpenVMS Installations Require That You Log In To the SYSTEM
Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4
You Cannot Reply to Mail from Compaq . . . . . . . . . . . . . . . . . . . . . . .
3.1.5
The Year Part of Dates Must Have Four Digits . . . . . . . . . . . . . . . . . .
3.1.6
The Modem Daemon Must Be Started from a Privileged Account . . . .
3.1.7
Defining EDIT Prevents TPU from Displaying Files . . . . . . . . . . . . . .
3.2
File Copy Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1
File Copy Is Unable to Copy Beyond the EOF Marker . . . . . . . . . . . . .
3.2.2
History Log Does Not Have Outgoing File Copy Records . . . . . . . . . . .
3.3
Interactive Text Search (ITS) Problems . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1
DECthreads Bugcheck Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2
OPCOM Messages May Appear After Receiving an ECO . . . . . . . . . . .
3.3.3
An ITS Timeout Causes TPU to Exit with an Access Violation . . . . . .
3.4
Installation and Startup Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1
Netscape Reduces the Colors Available to DSNlink . . . . . . . . . . . . . . .
3.5
Mail Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1
Mail to DSN% Addresses Fails with a Timeout Error . . . . . . . . . . . . .
3.5.2
A Mail File Cannot Be Restored from the Pulldown Menu . . . . . . . . .
3.6
Maintenance or Multiple Application Problems . . . . . . . . . . . . . . . . . . . . .
3.6.1
History Log File Does Not Show Some Rejected Applications . . . . . . .
3.7
Modem Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1
The DSN TEST HDLC Command Does Not Complete . . . . . . . . . . . . .
3.7.2
Modem Reset Phase Is Lengthened During Simultaneous Connections
.......................................................
3.7.3
Modem Daemon Ignores Sick and Dead Limits on Alpha Systems . . .
3.8
Network Exerciser Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.1
The Network Exerciser Does Not Support the LZW_DYN Compression
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.2
Error Messages Overwrite Statistics Report . . . . . . . . . . . . . . . . . . . .
3.8.3
The Network Exerciser Has Not Implemented Mirror Options or
Language Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9
Route Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1
Identical Learned Entries in the Route Map . . . . . . . . . . . . . . . . . . . .
3.10
Service Request Application Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.1
Some Routing Code Descriptions Are Displayed Twice . . . . . . . . . . . .
3.10.2
Problem Description Lines Over 255 Characters Are Truncated . . . . .
3–1
2.8.4
2.9
2.9.1
2.9.2
2.9.3
2.9.4
3 Known Problems and Restrictions
3.1
3.1.1
3–1
3–1
3–1
3–1
3–1
3–2
3–2
3–2
3–2
3–3
3–3
3–3
3–4
3–4
3–4
3–4
3–5
3–5
3–5
3–5
3–6
3–6
3–6
3–6
3–6
3–7
3–7
3–7
3–7
3–7
3–7
3–8
3–8
3–8
v
4 Starting DSNlink and Getting Help
4.1
4.2
Starting DSNlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4–1
4–1
Manual Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
Index
Tables
1
vi
Preface
This document explains:
•
New features in DSNlink Version 3.0
•
Restrictions and known bugs
•
How to start DSNlink
Overview
The DSNlink software is a service tool that provides electronic communication
capabilities between customers’ systems and a Compaq Customer Support Center.
Using DSNlink, customers can send electronic service requests and receive help
from Compaq specialists. Customers can also use DSNlink to search Compaq’s
technical support databases for information about products for which they have
service contracts.
Intended Audience
The audience for this document is anyone who uses DSNlink.
A Guide to the Documentation
DSNlink has no hardcopy documentation. The documentation consists of
PostScript and text files you can print and embedded online documentation that
is displayed by the Mosaic or Lynx browsers.
The files you can print are:
•
DSNlink Version 3.0 for OpenVMS Release Notes - this document
•
DSNlink Version 3.0 for OpenVMS Installation Guide
•
DSNlink Version 3.0 for OpenVMS Quick Reference Cards
•
DSNlink Version 3.0 for OpenVMS Service Tool Description
•
DSNlink Version 3.0 User’s Guide for the DECwindows Motif Interface
For the location of the files, see the Preface in the DSNlink Version 3.0 for
OpenVMS Installation Guide.
vii
Conventions Used in This Document
This document uses the conventions listed in Table 1, as needed:
Table 1 Manual Conventions
Convention
Description
UPPERCASE
Indicates file names and commands. You do not have to type them in
uppercase. DSNlink is case insensitive.
DSNlink
The abbreviated service tool name is used for convenience to refer to
the DSNlink Version 3.0 for OpenVMS software.
boldface text
Boldface text is used in examples to show what the user types to
contrast that with the results of the command.
monospace
type
Monospace type designates commands and examples.
.
.
.
viii
A vertical ellipsis indicates the example continues, but the additional
text is not displayed.
1
What’s New in DSNlink Version 3.0?
DSNlink Version 3.0 is a full kit, as opposed to an engineering change order
(ECO) kit. It includes the earlier DSNlink Version 2.2C, 2.2D, and 2.2E ECO
software. Installing DSNlink Version 3.0 gives you all the new features and
bug fixes since DSNlink Version 2.2 in addition to the new features in DSNlink
Version 3.0.
1.1 There Are Encrypted and Nonencrypted Versions
There are two DSNlink Version 3.0 kits:
•
DSNlink Version 3.0 for OpenVMS™
This version contains encryption ciphers that automatically encrypt messages.
It also contains new authentication methods.
•
DSNlink NE Version 3.0 for OpenVMS
This version has no encryption capability. It does have the new authentication
methods that replace MD5.
1.1.1 About the Kit with Encryption
The major enhancement in DSNlink Version 3.0 is the addition of encryption.
DSNlink Version 3.0 encrypts communications to and from your DSNlink systems
and Compaq. Authentication has also been enhanced with the addition of new
authentication methods and longer authentication keys.
These ciphers are in DSNlink Version 3.0:
Triple DES 168-bit block cipher (TDES)
DES 56-bit block cipher (DES)
RC4 128-bit stream cipher (RC4_128)
RC5 128-bit block cipher (RC5_128)
DSNlink encrypts all communications between your system and the Compaq host:
•
Service request submissions, augmentations, and responses
•
Requests for lists of routing codes, open and closed service requests, and
supported products
•
ITS sessions
•
DSNlink mail messages
•
Network Exerciser tests
•
SICL (System-Initiated Call Logging) service requests
Your system may not have SICL, which is not included in DSNlink. SICL
is part of the Compaq Analyze software, which uses DSNlink to send SICL
service requests to the Compaq host.
What’s New in DSNlink Version 3.0? 1–1
What’s New in DSNlink Version 3.0?
1.1 There Are Encrypted and Nonencrypted Versions
•
Remote login sessions
If you use the DECwindows Motif interface, there is no indication that the
communication was encrypted except for messages in the window where you
started DSNlink. If you use the command line interface, screen messages include
the encryption ciphers. Similar messages also appear in the server log files.
1.1.2 About the Kit Without Encryption
Not all customers and Compaq hosts can install DSNlink Version 3.0 because of
U.S. or local restrictions on the export or import of encryption software. Those
sites can install DSNlink NE Version 3.0, which contains no encryption code.
1.1.3 Improved Authentication
When either your system or the Compaq host initiates a connection, the systems
first perform authentication. The goal of the process is for the customer
and host systems to verify their identities to each other before establishing
a communication connection. The systems must successfully authenticate
themselves before either encrypted or nonencrypted messages are exchanged.
Authentication has also been enhanced with the addition of new, stronger, hashbased message authentication code (HMAC) functions. During the authentication
process, DSNlink Version 3.0 combines a message with your authentication key,
processes the result with industry-standard secure hash functions to generate a
hash-based message authentication code (HMAC) for the digital signature. The
HMAC algorithm follows RFC 2104 guidelines.
DSNlink Version 3.0 offers the following HMAC authentication methods:
•
MD5_V3 uses the MD5 cryptographic hash function to produce a 128-bit
signature.
•
RMD160 uses the cryptographic hash function RIPEMD–160 to produce a
160-bit signature.
•
SHA1 uses the cryptographic hash function SHA–1 to produce a 160-bit
signature.
•
SR160 uses both of the RIPEMD–160 and and SHA–1 cryptographic hash
functions to produce a 160-bit signature. The advantage of this method is
that an adversary would have to break both the SHA–1 and RIPEMD–160
functions to break the signature. This is the default authentication method.
The older MD5 authentication method, which produces a 128-bit signature, was
used in earlier versions of DSNlink. Your DSNlink Version 3.0 system will use
this method if the host system is running an earlier version of DSNlink. This
method does not follow RFC 2104 guidelines and is not as secure as the HMAC
methods mentioned above.
1.1.4 New Authentication Keys
Previously, DSNlink used only MD5 to authenticate all connections. Both your
system and the Compaq host had identical MD5 keys.
In DSNlink Version 3.0, if your system has existing MD5 authentication keys the
installation procedure renames them to replace the MD5 part of the file name
with HMAC. The contents remain unchanged. The key has this file name format:
DSN$KEYS:HMAC-DIGITAL-access_number
1–2 What’s New in DSNlink Version 3.0?
What’s New in DSNlink Version 3.0?
1.1 There Are Encrypted and Nonencrypted Versions
Customers are encouraged to request longer HMAC keys, which have 16 more
characters than the old MD5 keys. The longer keys are more difficult to break.
1.1.5 Remote Login Is Enhanced When Using RC4 Encryption
DSNlink Remote Login performance has been improved for slow network
connections, especially using the DSNlink modem protocol. However, this
improvement is only noticeable when using 128-bit RC4 encryption (RC4_128).
Specialists use 128-bit RC4 encryption when using the Remote Login application.
For all other communications, the default encryption cipher is Triple DES. If you
prefer 168-bit Triple-DES encryption for remote login sessions, modify the Remote
Login server’s cipher suite in the configuration file by defining the parameter
Login.CipherSuite as follows:
Login.CipherSuite:
TDES
This definition forces the specialist to use Triple DES encryption when logging in.
Triple DES adds as much as 6 bytes additional overhead per message. Depending
on the transport, a performance slowdown may be noticed by the specialist.
This information also appears in the chapter on the Remote Login Application in
the DSNlink User’s Guide.
1.1.6 Restrictions on Distribution
Exports of this product are subject to U.S. Export Administration Regulations
pertaining to encryption items and may require that the exporter obtain
individual export authorization from the U.S. Department of Commerce.
1.2 Interoperability Between DSNlink Version 3.0 and Previous
Versions
DSNlink Version 3.0 is compatible with previous versions of DSNlink. You do
not have to install DSNlink Version 3.0 on all the DSNlink systems at your site.
However, only messages between the system with DSNlink Version 3.0 and the
DSNlink Version 3.0 host are encrypted.
1.3 The DSNlink Getting Started Has Been Removed
The DSNlink Getting Started has been removed from the DSNlink Version 3.0
kit. Its information now appears in the DSNlink User’s Guide.
In the DSNlink main window, where the Getting Started previously appeared on
the Help menu, there is now the Index menu item. If you select it, the index to
the DSNlink User’s Guide appears.
When you enter the DSN HELP command for help on the command line interface,
the list of documents that appears now has a link to the DSNlink User’s Guide
index instead of the DSNlink Getting Started).
1.4 Netscape Replaces the Mosaic Browser
Previously, the Mosaic browser displayed the online help for the DECwindows
Motif user interface. In DSNlink Version 3.0, Mosaic has been replaced with
Netscape. The DSNlink Version 3.0 for OpenVMS Installation Guide provides
information on where to download the Netscape browser for OpenVMS systems.
What’s New in DSNlink Version 3.0? 1–3
What’s New in DSNlink Version 3.0?
1.4 Netscape Replaces the Mosaic Browser
Netscape’s product description states that Digital TCP/IP Services for OpenVMS
(UCX) is required by Netscape. That is true if you want Netscape to access the
Internet. However, UCX is not required to display the DSNlink online help using
Netscape.
1.5 A PostScript Version of the User’s Guide is Included
The DSNlink User’s Guide for the DECwindows Motif Interface has been added to
the kit to support OpenVMS Version 5.5-2 customers, who cannot run Netscape
on their systems to display the online version of the User’s Guide. Although
some wording and formatting changes were necessary, the versions are identical
technically.
1.6 Changes in TCP/IP Usage
The following sections explain changes relating to using TCP/IP with DSNlink.
1.6.1 TCP/IP Connections Use Single-Port Mode on A Nodes
In DSNlink Version 2.2 for OpenVMS, DSNlink used separate TCP/IP ports for
each DSNlink application. You could modify the route map, DSN$DATA:DSN_
ROUTE_MAP.DAT, to force all applications to use a single port, number 2370.
In DSNlink Version 3.0, when you install DSNlink on A nodes (the nodes that
communicate directly with Compaq), the installation procedure generates the
route map in single-port mode. If the node had a multiple-port route map, the
conversion process to single-port mode removes all the route map entries for each
of the ports for individual applications and routes them through port 2370. For
example, the File Copy application uses port 2371 in multiple-port mode and ITS
uses port 2373. Both route map entries are removed and changed to use port
2370 in single-port mode. Installations on B nodes (which connect to an A node)
do not convert a multiple-port route map to single port.
A new parameter, which you can enter in the configuration file,
Setup.Routemap.IP.Ports.Single determines whether future route map
regeneration operations produce single or multiple-port mode entries in the
route map. If set to True (the default), the route map is generated for a single
TCP/IP port. If set to False, the route map has a port for each application.
Previously, the Configuration utility, which you start with the command
@DSN$COMMAND:DSN$CONFIG, had two options on the Route Map operations
menu. The second menu item generated the route map in single-port mode. This
menu item has been removed.
The goal of the change is to make firewall setup simpler. If your firewall is
set up for multiple ports, and the A node uses a single port or multiple ports,
communications function without problems. However, if your firewall is set up for
a single port, and the A node uses multiple ports, connections fail at the firewall.
The DSNlink applications use the single port through the firewall. Once the
connection passes through the firewall onto your network, the Name Services
Directory (dsn_nsd) application forwards the connection to the individual port for
the application.
If your firewall was previously set up for multiple ports, and you plan to keep
the default single-port mode, you may want to have your firewall administrator
remove the DSNlink ports that are no longer necessary.
To switch to multiple-port mode, see the postinstallation instructions in the
DSNlink Version 3.0 for OpenVMS Installation Guide.
1–4 What’s New in DSNlink Version 3.0?
What’s New in DSNlink Version 3.0?
1.6 Changes in TCP/IP Usage
1.6.2 Lynx No Longer Requires Digital TCP/IP Services for OpenVMS (UCX)
The Lynx browser, which is included in the kit to display the online help for
the command line interface, previously required Digital TCP/IP Services for
OpenVMS (UCX). Lynx no longer has that requirement.
1.6.3 The Installation No Longer Requires Digital TCP/IP Services for
OpenVMS (UCX)
The installation procedure no longer fails if Digital TCP/IP Services for OpenVMS
(UCX) is missing. TCP/IP software is still required. DSNlink has been enhanced
to allow MultiNet or TCPware use. Digital TCP/IP Services for OpenVMS Version
3.3 or higher is supported. If UCX is present, the installation procedure verifies
that it meets the minimum version requirement.
1.6.4 Enhancements Permit MultiNet and TCPware Use
DSNlink has been enhanced to allow MultiNet and TCPware to be used for
TPC/IP services. If Digital Services for TCP/IP is not found on the system, the
installation procedure checks for MultiNet or TCPware. If MultiNet is found,
the installation verifies that it is MultiNet Version 4.2 or higher. If TCPware is
found, the installation makes sure that it is TCPWare Version 5.4 or higher. If
the minimum version is not present, a message appears.
For MultiNet, the installation does the following:
•
Defines the outgoing (host-to-customer) services, if they do not already exist,
in MULTINET_ROOT:[MULTINET]HOSTS.LOCAL as follows:
SERVICE
SERVICE
SERVICE
SERVICE
SERVICE
SERVICE
SERVICE
•
:
:
:
:
:
:
:
TCP
TCP
TCP
TCP
TCP
TCP
TCP
:
:
:
:
:
:
:
2370
2372
2374
2375
2377
2379
2381
:
:
:
:
:
:
:
DSN_NSD :
DSN_MAIL :
DSN_LOGIN :
DSN_NETEX :
DSN_K2 :
DSN_FILE :
DSN_TUNNEL :
Compiles the updated hosts.local file using the command:
$ MULTINET HOST_TABLE COMPILE
•
Installs the updated hosts.local file using the command:
$ MULTINET:INSTALL_DATABASES
•
Adds the incoming service definitions, if they do not already exist, using these
commands:
$ DEFINE/USER SYS$INPUT DSN$ROOT:[DAT]DSN$MULTINET_
INCOMING_SERVERS.DAT
$ MULTINET CONFIGURE/SERVERS
For TCPware, the installation does the following:
•
Adds these lines to the TCPWARE:SERVICES.; file:
dsn_nsd
dsn_mail
dsn_login
dsn_netex
dsn_k2
dsn_file
dsn_tunnel
•
2370/tcp
2372/tcp
2374/tcp
2375/tcp
2377/tcp
2379/tcp
2381/tcp
Adds service definitions using NETCU ADD SERVICE
What’s New in DSNlink Version 3.0? 1–5
What’s New in DSNlink Version 3.0?
1.6 Changes in TCP/IP Usage
You do not need to perform any additional tasks to make MultiNet or TCPware
work with DSNlink.
1.7 Enhanced OpenVMS Cluster Support
This section explain the enhancements to support OpenVMS Cluster systems in
DSNlink Version 3.0.
1.7.1 You Can Install Once on Mixed OpenVMS Clusters if They Have a
Common Disk
Previously, you could not perform a single DSNlink installation on an OpenVMS
Cluster of VAX™ and Alpha™ systems. In DSNlink Version 3.0, you can install
once on the cluster common disk. The directories for VAX and Alpha systems on
the common disk are as follows:
[DSN]
[.COM] - shared between VAX and Alpha
[.DAT] - shared between VAX and Alpha
[.EXE]
[.VAX]
[.ALPHA]
[.HELP] - shared between VAX and Alpha
[.INCOMING_FILES] - shared between VAX and Alpha
[.KEYS] - shared between VAX and Alpha
[.LIB]
[.VAX]
[.ALPHA]
[.LOGS] - shared between VAX and Alpha
[.OUTGOING_FILES] - shared between VAX and Alpha
[.TOOLS] - shared between VAX and Alpha
[.UTILITIES]
[.VAX]
[.ALPHA]
In OpenVMS Clusters of both Alpha and VAX systems without one common disk,
you must install DSNlink on a common disk shared by the VAX systems and on a
common disk shared by the Alpha systems.
1.7.2 The OpenVMS Cluster Alias Name Is Not Used for DSN$DATA
Subdirectory Names
Previously, if you installed DSNlink on an OpenVMS Cluster with an alias
name, DSNlink created subdirectories under DSN$DATA with the alias name,
for example, DSN$ROOT:[DAT.ZALIAS]. In DSNlink Version 3.0, subdirectories
with the nodes’ DECnet™ node name are created. For example, if a node in the
cluster is named ALBERT, there is a directory [DSN$ROOT:[DAT.ALBERT] on
node ALBERT.
1.7.3 Requirements for A and B Nodes Have Changed
Previously, all nodes in an OpenVMS Cluster had to be either all A nodes or
all B nodes. (An A node communicates directly with the Compaq host. B nodes
communicate through the A node.)
Currently, the node where the installation is performed is set up as an A node
and any other nodes in the OpenVMS Cluster are set up as B nodes by default.
An installation prompt allows you to change the default node type. This change
supports the requirement that only one node in an OpenVMS Cluster can be an
A node if you use the modem transport. However, if you need to perform multiple
installations on the nodes in a cluster, for example, because there is no cluster
1–6 What’s New in DSNlink Version 3.0?
What’s New in DSNlink Version 3.0?
1.7 Enhanced OpenVMS Cluster Support
common disk, DSNlink treats each installation as separate OpenVMS Cluster
systems.
1.7.4 Node Name Definitions in the Configuration File Have Changed
How connection parameters are defined in the configuration file,
DSN$DATA:DSN_CONFIG.DAT, has changed. The changes are as follows:
•
Local.Node is the DSNlink node name, which is normally the DECnet node
name. It is never an alias name.
•
Transport.LocalName.DECnet is the DECnet node name and, if it exists, the
DECnet cluster alias name, for example, "ZNODE,ZALIAS".
•
Transport.LocalName.TCP is the fully-qualified TCP/IP host name,
and if it exists, the TCP/IP cluster alias name, for example,
"ZNODE.SITE.COM,ZALIAS.SITE.COM".
1.7.5 You Must Be Logged into the SYSTEM Account for Installation
Previously, the person installing DSNlink could perform the installation from a
user account that had system manager’s privileges.
In DSNlink Version 3.0, the installer must be logged into the SYSTEM account.
1.7.6 The Executing Node’s Name Appears in Log Files
Previously, log files did not provide the name of the node executing DSNlink
commands. It made troubleshooting more difficult when there were multiple
nodes in the OpenVMS Cluster. The node’s name has now been added to log
files.
1.8 Startup and Shutdown Files Are in DSN$COMMAND
Previously, the DSNlink startup and shutdown files were in SYS$STARTUP.
DSN$STARTUP.COM and DSN$SHUTDOWN.COM are now provided
to DSN$COMMAND (DSN$ROOT:[COM]) to support the OpenVMS
Cluster changes. The DSNlink Version 3.0 installation renames
any existing files to SYS$STARTUP:DSN$STARTUP.OLD and
SYS$STARTUP:DSN$SHUTDOWN.OLD.
Log files for the startup procedure are in DSN$LOGS instead of
SYS$COMMON:[SYS$STARTUP].
1.9 Installed Images Are Removed by DSN$SHUTDOWN.COM
All images installed by the DSNlink startup file, DSN$STARTUP.COM, are now
deinstalled by the DSNlink shutdown file, DSN$SHUTDOWN.COM. This allows
dismounting the disk that DSNlink is on during a shutdown.
1.10 Motif Resource Files Are in DSN$ROOT:[DAT]
The installation provides the Motif resource and .UID files to DSN$ROOT:[DAT].
The postinstallation part of the installation deletes the obsolete Motif files from
SYS$COMMON:[DECW$DEFAULTS.SYSTEM].
What’s New in DSNlink Version 3.0? 1–7
What’s New in DSNlink Version 3.0?
1.11 DSNlink Does Not Require the SYS$BATCH Queue
1.11 DSNlink Does Not Require the SYS$BATCH Queue
Previously, the installation procedure submitted the DSNlink startup command
procedure, DSN$STARTUP.COM to the SYS$BATCH queue. In DSNlink Version
3.0, the installation creates the DSN$BATCH_nodename batch queue to process
DSN$STARTUP.COM. Nodename is the system’s name.
The logical name DSN$BATCH points to the node-specific batch queue. DSNlink
also uses that queue when you submit service requests, update service requests,
and copy files to Compaq using batch processing.
1.12 Obsolete Files Are Deleted After a Successful Installation
If you install DSNlink Version 3.0 on a disk where DSNlink Version 2.2 was
previously installed, the installation deletes obsolete files after a successful
installation. Deleted images reside in DSN$SYSTEM, DSN$LIBRARY, and
DSN$UTILITIES. Obsolete .CLI files are removed from DSN$SYSTEM. The
files DSN_ITS_SERVER.COM and DSN_SRA_SERVER.COM are removed from
DSN$COMMAND.
However, DSNlink Version 2.2 files are not removed if you install DSNlink
Version 3.0 on a different disk on the system. For information on removing
obsolete files, see the DSNlink Version 3.0 for OpenVMS Installation Guide.
1.13 VT Menu Includes Remote Login Authorization
The DSNlink VT Menu has been improved by the addition of a menu item
that allows you to authorize a remote login by Compaq. DSNlink records the
authorization in the remote authorizations file, DSN$DATA:DSN_REMOTE_
AUTH.DAT, which requires system manager’s privileges. To run the VT Menu,
enter this command:
$ @DSN$ROOT:[COM]DSN_VT_MENU.COM
The DSNlink VT menu appears. Choose the Control menu item to authorize a
remote log in to your system.
1.14 Startup Files and Logical Names for the SRQ Utility Are
Included in the DSNlink Startup
Previously: Before you could use the SRQ (service request) utility to send
hardware service requests to Compaq, you had to edit the DSNlink startup to
add the file DSN$ROOT:[UTILITIES.HARDWARE_DB]DSN$SRQ_UTILITY_
STARTUP.TXT. This file defined the logical names necessary to run the utility.
Currently: The file DSN$SRQ_UTILITY_STARTUP.TXT is now part of the
DSNlink startup file, DSN$COMMAND:DSN$STARTUP.COM. DSN$SRQ_
UTILITY_STARTUP.TXT is no longer in the DSNlink kit.
Before you can use the utility, you must create the database of hardware systems
or service contracts. You may also want to define a foreign command for running
the utility. For more information, see the section Setting Up the Database in the
chapter Managing DSNlink in the DSNlink User’s Guide.
It is a postinstallation task to define a foreign command to run the utility, such
as:
$ DSN_SRQ := = $DSN$UTILITIES:DSN$SRQ_UTILITY
1–8 What’s New in DSNlink Version 3.0?
What’s New in DSNlink Version 3.0?
1.15 The SPAWN Command Works from the ITS Command Line
1.15 The SPAWN Command Works from the ITS Command Line
The SPAWN command can be used in the command line interface at the its>
prompt. SPAWN allows you to temporarily exit an ITS session it and then return
without ending the ITS session.
To use the command, enter SPAWN at the ITS prompt. The system prompt
appears. When you are ready to return to ITS, enter the LOG command. For
example:
its> SPAWN
$ DCL commands
.
.
.
$ LOGOUT
its>
1.16 The Service Request Application Allows Hours and Minutes in
the Beginning and Ending Date Fields
You can now add hours and minutes specifications to the Beginning and Ending
dates when you request a list of closed or open service requests. For example, in
the Fetch List window, you can click on Open Service Requests, and then enter
this date in the Beginning Date field:
31 December 1999 12:59
You can also enter hours and minutes in the command line interface. For
example:
$ DSN FETCH OPEN/BEGINNING="31 December 1999 12:59"
DSNlink returns a list that begins with the specified date and time. The time is
the Compaq call handling system’s time when it received the service request, not
the time on your system. Therefore, if your system and the Compaq call handling
system are in different time zones, you may need to be aware of the difference if
you specify hours with dates.
The Beginning and Ending date fields accept 32 characters.
1.17 DECwindows Motif Is No Longer Required for the Command
Line Interface
DECwindows Motif was previously required, even for the command line interface.
That requirement has been removed. You no longer need DECwindows Motif to
use the DSNlink command line interface. The installation procedure provides
several DECwindows images that are necessary for the command line interface.
1.18 The Logical Name DSN$MAIL_CC_RECIPIENT Has an
Equivalent In DSNlink Version 3.0
The DSN$MAIL_CC_RECIPIENT logical name, which allows you to specify a list
of people to receive copies of the responses from the Customer Support Center,
was implemented in DSNlink Version 1.2 but not in Version 2.2. Consequently,
there was no way to copy several people on the mail from Compaq in DSNlink
Version 2.2 for OpenVMS.
What’s New in DSNlink Version 3.0? 1–9
What’s New in DSNlink Version 3.0?
1.18 The Logical Name DSN$MAIL_CC_RECIPIENT Has an Equivalent In DSNlink Version 3.0
In DSNlink Version 3.0, the configuration file has a new parameter named
Mail.Incoming.CC that you can define with a list of people to copy on mail
from the Customer Support Center. You must edit the configuration file,
DSN$DATA:DSN_CONFIG.DAT, on all systems that receive mail to specify the
mail addresses of the people to receive copies of the incoming mail. The types
of mail are service request response mail, file copies and engineering change
orders (ECOs) arrival notifications, communique mail, and System-Initiated Call
Logging (SICL) responses (if you have SICL installed). The default definition of
the parameter Mail.Incoming.CC is none, and it is preceded by the comment flag
(#), which prevents its use by applications.
For more information on defining the parameter, see the postinstallation tasks
chapter of the DSNlink Version 3.0 for OpenVMS Installation Guide.
1.19 Recipients for Communique Mail Are Defined by Configuration
File Parameters
Previously, the way you defined who was to receive communique mail from
Compaq was to enter the recipients’ mail addresses as the values for logical
names in the DSNlink startup file. That method has been changed. You now
define the recipients in configuration file parameters. These parameters have
been added to the configuration file, DSN$DATA:DSN_CONFIG.DAT:
•
Mail.Flash
This parameter defines a list of people to get copies of flash communique
mail. Flash mail contains urgent product information including software
engineering change orders (ECOs).
•
Mail.Informative
This parameter defines a list of people to get copies of general product
information.
•
Mail.Marketing
This parameter defines a list of people to get copies of mail explaining new
products and services. This mail also provides information about updates to
existing products and services.
•
Mail.Surveys
This parameter defines a list of people to get copies of surveys that ask for
your opinions on Compaq services and product quality.
The DSNlink Version 3.0 installation checks your system for previous definitions
of these logical names:
•
DSN$MAIL_FLASH_RECIPIENT
•
DSN$MAIL_SURVEY_RECIPIENT
•
DSN$MAIL_INFORMATION_RECIPIENT
•
DSN$MAIL_MARKETING_RECIPIENT
If the logical names are defined, the installation procedure transfers the
definitions to the corresponding parameters in the configuration file. If the logical
names do not exist, the parameters have the value %NONE%.
The default definition for all parameters is %NONE%. Therefore, unless you
change that definition, no one will receive communique mail.
1–10 What’s New in DSNlink Version 3.0?
What’s New in DSNlink Version 3.0?
1.19 Recipients for Communique Mail Are Defined by Configuration File Parameters
Changing the definitions of the parameters is a postinstallation task in the
DSNlink Version 3.0 for OpenVMS Installation Guide.
1.20 Your A Node is Set to be the Receiver Node
Previously, if you wanted to designate a node to receive ECOs and file copies from
Compaq, you added a name (which comes before all other node names at your
site in ASCII sort order), to the Local.Node parameter in the configuration file,
DSN$DATA:DSN_CONFIG.DAT. This causes the DSNlink host to send ECOs
and file copies to that node rather than to another node at your site whose name
happens to be first in ASCII order in the host route map.
Currently, the DSNlink installation adds the name 4DSN to the A node name in
the configuration file for the parameter Local.Node. For example:
Local.Node:
zanode,4DSN
If you install DSNlink on multiple A nodes, DSNlink adds 4DSN to each node’s
name. When multiple nodes have 4DSN, the first node in ASCII sort order on the
host’s route map receives the ECO or file copy. For example, if the nodes START
and ZIPPY appear in the host route map as follows, START is the receiver node:
12345/4DSN
12345/4DSN
t/zippy.mycorp.com/2370
t/start.mycorp.com/2370
255
255
r
r
Changing the receiver node is an optional postinstallation task in the DSNlink
Version 3.0 for OpenVMS Installation Guide.
1.21 REPKO Modem Scripts Have Been Added to the Kit
Modem scripts for REPKO modems have been added to the kit. The scripts are
in DSN$DATA and have these names:
•
REPKO_EU.DDSF_SRC —for European REPKO modems with XON/XOFF
flow control
•
REPKOHW_EU.DDSF_SRC—for the European REPKO modems with RTS
/CTS flow control
What’s New in DSNlink Version 3.0? 1–11
2
Fixed Bugs
This chapter lists software or documentation errors that have been fixed since the
DSNlink Version 2.2E kit.
2.1 Communications
The following problems with creating and maintaining communications have been
fixed.
2.1.1 Incoming Applications Using X.25 Produced DSN_K2 Log Files
Previously: In DSNlink Version 2.2E, all incoming applications using the X.25
transport produced DSN_K2 (the Cryptographic Services application) log files in
DSN$LOGS.
Currently: This has been fixed. DSN_K2 log files no longer appear in
DSN$LOGS for each incoming application that uses the X.25 transport.
2.1.2 An Incoming DECnet Connection Was Misinterpreted as a TCP/IP
Connection
Previously: An incoming connection via DECnet Phase IV to a node named
BG001 was interpreted as a TCP/IP connection. The node name was mistaken for
a BG device. This is an example of the error:
BG001> dsn its
DSNlink V2.2E for OpenVMS Alpha Modem Daemon
Copyright (c) 1989, 1999 by Digital Equipment Corporation
.
.
.
Establishing ITS connection to domain digital at node cscuvo.
--- DsnSession::GATEWAYERR, DsnGateway error
- DsnGateway::TRANSPORTERR, Transport error: caller = d/BG001/FIELD,
callee = d/bg002/dsn_nsd
- DsnTransport::END, End of data; connection was abruptly terminated
*** Failed to establish DsnIts session!
The DSN$LOGS:NETSERVER.LOG shows the transport was set to TCP/IP
instead of DECnet.
Currently: The test for DECnet has been fixed to not mistake a node name that
begins with BG for a BG device.
2.2 File Copy
The following problems in the File Copy application have been fixed.
Fixed Bugs 2–1
Fixed Bugs
2.2 File Copy
2.2.1 Some File Copies Did Not Create a Work Unit
Previously: When you copied a file to the Compaq host, a record of the file copy
should, but did not, appear in the work units you saw when you reviewed the
service request. File copies from the host to your system did appear in the work
units.
Currently: The work units associated with a service request include the names
of files you copy to the host.
2.2.2 TYPE-F-WRITEERR Message Appeared After a File Copy Operation
Previously: After a successful file copy from the host, the following message
appeared in the File Copy transfer log, DSN$FILE_TRANSFER.LOG:
.
.
--- Beginning transfer of all files in job
--- Opening file _DSA2:[DSN.OUTGOING_FILES]A1_FIX033033.A;4
--- Beginning transfer of file _DSA2:[DSN.OUTGOING_FILES]A1_FIX033033.A;4
to 0:A1_FIX033033.A
--- Creating file 0:A1_FIX033033.A
%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded
The following transfer update message was overwritten on the screen:
Transferred %x of %y bytes for file z ...
The overwritten message occurred only when you typed the log file. The message
"Transferred %x of %y bytes for file z ..." was missing a form feed character at the
end of the line, which caused the message to be overwritten on the screen. The
result was that the File Copy application wrote a large record to the batch log
file, which produced the process quota exceeded errors.
Currently: The message now has a carriage return and line feed included in
batch mode, which fixes the process quota exceeded error. You can view the
contents of the File Copy transfer log by typing it or using an editor.
2.2.3 Mail Notification After a File Copy Was Inconsistent
Previously: After a Compaq specialist copies a file from the host to your system,
you should receive notification mail about the file copy. However, under some
circumstances, no notification mail was sent, and the specialist performing the
file copy did not know about the notification mail failure.
Currently: This problem has been fixed. DSNlink notifies the person associated
with the service request when mail is copied to their system. Rarely, although it
can happen, Compaq copies a file to you with no associated service request. In
this case, the specialist must have the email address of the person to notify to
send notification mail.
2.3 Installation
2.3.1 Installation on a VAX in a Mixed OpenVMS Cluster Resulted in Missing
Files
Previously: A mixed OpenVMS Cluster installation on an Alpha system
included having the installation provide the VAX images. Everything was fine on
the Alpha system, but not on the VAX. The DECnet objects and TCP/IP services
were missing on the on the VAX system.
2–2 Fixed Bugs
Fixed Bugs
2.3 Installation
Currently: This problem has been fixed by using SYSMAN to create the objects,
destinations and TCP/IP services during the postinstallation. Also, the installer
has to be logged into the SYSTEM account for SYSMAN to work clusterwide.
2.3.2 Route Map Entry for X.25 Corrected
Previously: DSNlink entered DATANET1 for the X.25 line even if the installer
entered another line name in the installation. For example:
* Enter the X.25 network name for this system: PIE1
* Enter the X.25 DTE address for this system: 1234567
At the end of the installation the IVP failed with:
Connecting to target cscuto.digital.dsn. Please wait...
--- DsnGateway::TRANSPORTERR, Transport error: caller = (none),
callee = x/datanet1.130045250/dsn_nsd
- DsnTransport::CONNECTERR, Unable to connect to x/datanet1.130045250/dsn_nsd
- psi$c_err_nosuchnet, The specified network is not known
Currently: This problem has been fixed.
2.3.3 The Startup File Was Provided on the Installing Platform Only
Previously: If DSNlink was installed on a mixed-architecture OpenVMS Cluster,
the startup file DSN$STARTUP.COM was only provided to SYS$STARTUP on the
platform where the installation was performed.
If you installed on a VAX, the startup was not copied to or run on the Alpha
systems.
If you install on an Alpha, the startup was not copied to or run on the VAX
systems.
The installer had to copy the startup file from the system where DSNlink was
installed to to the common disk or disks that are shared by any other nodes that
will run DSNlink. Then the installer had to run the startup on each DSNlink
node in the OpenVMS Cluster.
Currently: All cluster nodes execute the same DSNlink startup file,
DSN$ROOT:[COM]DSN$STARTUP.COM, when the installation is on a clusterwide common disk. When there is no single cluster-wide common disk, you must
install DSNlink on a common disk or disks shared by the VAX systems and again
on a common disk or disks shared by the Alpha systems. The installation for the
VAX systems runs the startup from the VAXes’ common disk for each node, and
the Alpha systems run the startup from the Alphas’ common disk for each node.
Note that the DSNlink Startup file, DSN$STARTUP, was previously provided to
SYS$STARTUP. The installation procedure now provides it to DSN$COMMAND
(DSN$ROOT:[COM]). For more information, see Section 1.8.
2.3.4 SYS$COMMON Was Not Translated to Device and Directory Names
Previously: During the DSNlink Version 2.2 for OpenVMS installation, when
SYS$COMMON: was entered for the device for the DSNlink directory tree, the
logical name was not translated down to the device and directory names. That is,
the logical names such as DSN$ROOT and DSN$KEYS were not defined.
Currently: Do not use a rooted logical name, such as SYS$COMMON, for
the device for the DSNlink directory tree. Instead, enter SYS$SYSDEVICE: or
DISK$USER1: when asked for the device and directory for the DSNlink directory
tree in the DSNlink Version 3.0 installation.
Fixed Bugs 2–3
Fixed Bugs
2.3 Installation
You can tell if the logical name is rooted because there is a dot after the directory
name before the closing square bracket. For example:
$ SHOW LOG SYS$COMMON
"SYS$COMMON" = "DSA100:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)
2.4 ITS
The following are fixed problems in the Interactive Text Search (ITS) application.
2.4.1 Using an ITS Initialization File Resulted in an ACCVIO
Previously: An ACCVIO error resulted after using the following ITS
initialization file, DSN_ITS_INIT.INI:
open eco-summary
open aes
search shadow
dir
mail/dir/subj="DSN dir_listing since 01-jun-2000"
exit
The ITS session failed during the DIR command.
Currently: This has been fixed. The ACCVIO no longer occurs. Furthermore,
the DSNlink User’s Guide has an improved example of an ITS initialization file
for use with the command line interface.
2.4.2 ACCVIO After Mistyping the Show Database/Open Command
Previously: When using ITS in the command line interface, if you mistyped the
ITS show database/open command so that the slash was missing from the /open
qualifier, an ACCVIO resulted.
Currently: This has been fixed so that if the command is mistyped, a message
appears with the ITS command syntax.
2.4.3 ITS Extracted Articles Could Have All the Characters in the First Column
Previously: If you extracted an ITS article to a file on your system, the text
might all appear in the first column in your file. For example:
*
O
p
e
n
V
M
S
]
V
A
X
S
Y
S
L
0
.
.
.
2–4 Fixed Bugs
Fixed Bugs
2.4 ITS
Currently: The cause of the error was never pinpointed because it occurred
rarely. However, the DSNlink code has been modified with the expectation that it
will alleviate the problem.
2.4.4 Interactive Command Procedures Produced the Timed Read Error
Previously: If you created ITS command procedures and ran the file in batch
mode, the commands were executed without errors. However, the same command
procedure run interactively had this error:
DSNITS Unexpected timed read error. Exiting...
This is an example of an ITS command procedure:
$ dsn its
open openvms
open dsn
open network
open service-offers
open spd
open wis
open cib
dir/all/beginning=yesterday
extract/dir DISK$USER1:[MYTEA.TMP]its_latest.txt
set page off
show data
$ exit
Currently: ITS command procedures now run in interactive mode without the
timed read error.
2.5 Modem Transport
2.5.1 Customers Could Make Only One ITS Connection with the Modem
Transport
Previously: Customers could make only one ITS session with the Version 2.x
modem transport. The second session got as far as ’Remote server responding’
then eventually died with ’modem heartbeat stopped’ and ’object referenced
already in use’ errors. The original connection kept working.
Currently: This problem has been fixed so that you can start multiple ITS
sessions from a DSNlink node.
2.5.2 Modems Did Not Hang Up After a DSNlink Session
Previously: Some modems, for example, USRobotics Sportster Flash or
Sportster Voice modems, otherwise operated as expected but did not hang up
after a DSNlink session. The same problem occurred on a VAX 6000 with a
DMB32 serial port.
Currently: This problem has been fixed. Modems hang up after the DSNlink
session ends.
2.5.3 DTE Speed in MDDF Was Not Set on the DTE Device
Previously: When using the modem transport, the DTE speed from the modem
devices definition file (MDDF) did not modify the direct port to use the specified
speed.
Fixed Bugs 2–5
Fixed Bugs
2.5 Modem Transport
Currently: The terminal server port for an LTA device must have remote
modification enabled for the speed from the MDDF to be used. If remote
modification is disabled, the change request is ignored. However, you should
leave remote modification disabled because the port speed on the terminal server
is used regardless.
2.6 Multiple Applications
The following fixes apply to several DSNlink applications.
2.6.1 The Startup Was Sent to the Wrong Batch Queue on an OpenVMS
Cluster
Description: DSNlink Version 2.2D did not queue the DSNlink startup batch
job correctly on a large OpenVMS Cluster. This error appeared:
RMS-W-RTB error, xxxx byte record too large
from DSN$STARTUP.COM
$ batchque_nodename ==
Currently: This problem has been fixed. DSNlink Version 3.0 creates
one execution queue, DSN$BATCH_nodename. The system logical
name,DSN$BATCH, points to the node-specific batch queue.
2.6.2 All DSN Commands Invoked the DSN Modem Daemon
Previously: All DSN commands invoked the modem daemon to identify the
DSNlink version number. For example:
$ DSN ITS
DSNlink V2.2E for OpenVMS Alpha Modem Daemon
Copyright (c) 1989, 1999 by Digital Equipment Corporation
Compaq Computer Corporation Proprietary Service Tool
All Rights Reserved
Currently: Rather than invoking the modem daemon, each application invokes
its own DSNlink identifier. For example:
$ DSN ITS
DSNlink V3.0 for OpenVMS Alpha Interactive Text Search Application
Copyright 1989, 2000 Compaq Computer Corporation
Compaq Registered in U.S. Patent and Trademark Office.
Proprietary service tool software. Valid license required.
2.6.3 DECthreads Bugcheck Error
Previously: Some DSNlink Version 2.2E customers experienced intermittent
DECthreads bugcheck errors. The problem was also likely on DSNlink Versions
2.2C and 2.2D.
2–6 Fixed Bugs
Fixed Bugs
2.6 Multiple Applications
$ TYPE PTHREAD_DUMP.LOG
%DECthreads bugcheck (version V3.13-553), terminating execution.
% Running on OpenVMS VAX [OpenVMS V7.1; MicroVAX 3100-30/40, 1 cpu, 24Mb]
% Reason: krnSpinLock: deadlock at
_$22$DIA11:[PTHREAD.SRC]THD_MUTEX.C;1:1361
%
%
The DECthreads library has detected an inconsistency in its internal
% state and cannot continue execution. The inconsistency may be due to a bug
% within the DECthreads library, the application program, or in any library
% active in the address space. Common causes are unchecked stack overflows,
% writes through uninitialized pointers, and synchronization races that
% result in use of invalid data by some thread.
%
Application and library developers are requested to please check for
% such problems before reporting a DECthreads library problem.
%
The information in this file may aid application program, library, or
% DECthreads developers in determining the state of the process at the time
% of this bugcheck. When the problem is reported, this information should be
% included, along with a detailed procedure for reproducing the problem, if
% that is possible. The ’detailed procedure’ most likely to be of use to
% developers is a complete program.
%
% The bugcheck occurred at 02-DEC-1999 13:34:02.51, running image
% DISK03$DKA300:[DSN.][EXE]DSNMODEMDAEMON.EXE in process 00000DB2 (named
% "line-000"), under username "SYSTEM". AST delivery is enabled for all modes;
% ASTs are active in user sequence 23, at 0x00491868
% Current thread traceback:
%
0: PC 0x00122C9B, FP 0x00548B68, AP 0x00548B94
%
1: PC 0x00124F43, FP 0x00548C04, AP 0x00548C40
%
2: PC 0x0011CB7D, FP 0x00548C4C, AP 0x00548C64
%
3: PC 0x0025C6EC, FP 0x00548C70, AP 0x00548C88
%
4: PC 0x001E60A5, FP 0x00548CC8, AP 0x00548CDC
%
5: PC 0x8152F647, FP 0x00548CF4, AP 0x00548D08
%
6: PC 0x0013A0FE, FP 0x00548D24, AP 0x00548D50
%
7: PC 0x0013B2BE, FP 0x00548D64, AP 0x00548D7C
%
8: PC 0x0013EC6C, FP 0x00548DCC, AP 0x00548DFC
%
9: PC 0x8152F647, FP 0x00548E14, AP 0x00548E50
%
10: PC 0x000674DD, FP 0x00549014, AP 0x00549050
%
11: PC 0x00074A35, FP 0x00549078, AP 0x0054909C
%
12: PC 0x002E9A30, FP 0x0054919C, AP 0x005491C4
%
13: PC 0x002CD120, FP 0x005493E8, AP 0x00549424
%
14: PC 0x00397488, FP 0x00549988, AP 0x005499BC
%
15: PC 0x00322FF1, FP 0x0054AA5C, AP 0x0054AA98
%
16: PC 0x0032291C, FP 0x0054AAAC, AP 0x0054AAC0
%
17: PC 0x00268BB2, FP 0x0054AAD4, AP 0x0054AAFC
%
18: PC 0x0012E08C, FP 0x0054ADAC, AP 0x0054ADDC
%
19: PC 0x0012379F, FP 0x0054ADE4, AP 0x0054ADF8
% DECthreads scheduling database is locked.
Currently: This problem has been fixed.
2.6.4 The DSN SHOW VERSION Command Response Is Improved
Previously: The DSN SHOW VERSION command displayed information for the
Modem Manager utility. For example:
$ DSN SHOW VERSION
DSNlink V2.2E for OpenVMS Alpha Modem Manager Utility
Copyright (c) 1989, 1999 by Digital Equipment Corporation
Compaq Computer Corporation Proprietary Service Tool
All Rights Reserved
Fixed Bugs 2–7
Fixed Bugs
2.6 Multiple Applications
Currently: The response to the command does not reference the Modem
Manager Utility, as shown in the following example:
$ DSN SHOW VERSION
DSNlink V3.0 for OpenVMS VAX
Copyright 1989, 2000 Compaq Computer Corporation
Compaq Registered in U.S. Patent and Trademark Office.
Proprietary service tool software. Valid license required.
2.7 Network Exerciser Fixes
The following problems with the Network Exerciser application have been fixed.
2.7.1 Defining DSNGATEWAY_TRACE Resulted in a Transport Error
Previously: If you defined the logical name DSNGATEWAY_TRACE to CT to
trace connection errors and then ran the Network Exerciser, DSNlink generated
transport errors. For example:
$ define dsngateway_trace ct
$ dsn netex
DSNlink T2.2D-EFT2 for OpenVMS Alpha Network Exerciser Utility
Copyright (c) 1989, 1999 by Digital Equipment Corporation
Compaq Computer Corporation Proprietary Service Tool
All Rights Reserved
Connecting to target host.digital.dsn. Please wait...
DsnGateway::Connect HIT:
Date:
Mon, 30 Aug 1999 14:15:20 -0600
Hop Count:
1
Redirect Count: 0
State:
CONNREPLY
Status:
--- DsnGateway::OK, Operation successful
System ID:
digital/host
Platform ID:
VMS ZHOST V6.2 0 VAX T2.2D-EFT2
Version:
2.37 Exp
Network Address: (None)
Path: 112125/RAINY|VMS RAINY V6.2 0 Alpha T2.2D-EFT2||T/RAINY/1078&
T/host1.compaq.com/DSN_NETEX
digital/host|VMS HOST1 V6.2 0 VAX
T2.2D-EFT2|T/rainy.splat.com/1078&T/zhost/DSN_NETEX|
Connection established.
Stats: M100/100/100/0 B49070/49070/49070/0 e981400
Testing complete.
Messages Sent:
100
Messages Read:
100
Messages Good:
100
Messages Bad:
0
Bytes Sent:
49070
Bytes Read:
49070
Bytes Good:
49070
Bytes Bad:
0
e-baud:
981400
--- DsnGateway::TRANSPORTERR, Transport error: caller = T/RAINY/1078,
callee =T/host1.compaq.com/DSN_NETEX
- DsnTransport::END, End of data; connection was abruptly terminated
Currently: This problem has been fixed.
2–8 Fixed Bugs
Fixed Bugs
2.7 Network Exerciser Fixes
2.7.2 The Network Exerciser Had Obsolete Authentication and Encryption
Options
Previously: The Network Exerciser window had obsolete fields for the
authentication and encryption options to use during Network Exerciser tests.
The Authentication field allowed only the MD5 key to be chosen. The Encryption
field’s default was None.
Currently: The fields have been removed from the window. They are obsolete.
2.7.3 The Verbose Qualifier Had No Effect
Previously: The /VERBOSE qualifier to the DSN NETEX command, was
ignored. No connection information was displayed if you enter DSN NETEX
/VERBOSE on the command line. Only message statistics appeared.
Currently: This has been fixed. The /VERBOSE qualifier causes connection
routing information to be displayed. Note that you cannot use the DECwindows
Motif interface to display connection information.
2.7.4 The Initial Network Exerciser Test Failed Using X.25
Previously: Using the X.25 transport, after a new installation, the initial
Network Exerciser connection to Compaq failed as follows:
$ DEFINE DSNGATEWAY_TRACE CT
$ DSN NETEX
Connecting to target cscabc.digital.dsn. Please wait...
--- DsnGateway::TRANSPORTERR, Transport error: caller =
X/datanet.12345678/*, callee = X/datanet.130045678/dsn_nsd
- DsnTransport::END, End of data; connection was abruptly terminated
--- DsnNetEx::FAILURE, Operation failed
- DsnSession::GATEWAYERR, DsnGateway error
- DsnGateway::TRANSPORTERR, Transport error: caller = X/datanet.12345678/*,
callee = X/datanet.130045250/dsn_nsd
- DsnTransport::END, End of data; connection was abruptly terminated
The problem was that REDIRECT messages were deleted before they could be
sent.
Currently: This problem has been fixed.
2.7.5 Network Exerciser Stopped Responding After a Midtest Error
Previously: During a Network Exerciser test on the modem transport, if an
error occurred during the data looping phase, a message said the testing was
complete, provided statistics about the test and then the Network Exerciser
stopped and did not respond. This error was not reported for other transports but
may have occurred on them too.
Currently: This problem is fixed. If errors occur during a Network Exerciser
test, messages explain the errors, and then the Network Exerciser terminates
properly.
2.7.6 IVP Failed Because of Authentication Key File Format
Previously: DSNlink authentication failed intermittently during the installation
verification procedure (IVP), which is a Network Exerciser test, when the
authentication key file was created with file attributes of sequential VFC (variable
with fixed control). For example:
Fixed Bugs 2–9
Fixed Bugs
2.7 Network Exerciser Fixes
Size:
1/9
Owner:
[CONTRL,AES_DSNLINK]
.
.
.
File organization: Sequential
Shelved state:
Online
File attributes:
Allocation: 9, Extend: 0, Global buffer count: 0
No version limit
Record format:
VFC, 2 byte header, maximum 0 bytes, longest 34
bytes
Record attributes: Print file carriage control
.
.
.
Currently: The record format has been corrected. DSNlink creates the
authentication key file as sequential variable. For example:
.
.
.
File organization: Sequential
Shelved state:
Online
File attributes:
Allocation: 9, Extend: 0, Global buffer count: 0
No version limit
Record format:
Variable length, maximum 0 bytes, longest 33 bytes
Record attributes: Carriage return carriage control
.
.
.
2.8 Route Map
The following are changes to the route map.
2.8.1 DSNMAPQ Did Not Add Entries to the Route Map
Previously: The DSNMAPQ utility, which allows you to query the route map
for entries that match a specified string, did not add entries to the route map.
When you attempted to add an entry to the route map, the command was not
recognized. For example:
$ @dsn$utilities:dsnmapq_setup
$ dsnmapq -A "test/dsncxo/dsn_nsd"
Usage: zhost$dka200:[dsn.][utilities]dsnmapq.exe;194 [flags]
domain/node/application (selects based on destination)
zhost$dka200:[dsn.][utilities]dsnmapq.exe;194 -d [flags]
(dumps contents of route map in sorted order)
flags: -a "entry" = add "entry" to route map file
-f file
= specify route map filename
-i rflags = ignore entries which have rflags set
-n
= number output lines from query
-s rflags = select only entries which have rflags set
-t [dmtx] = display only entries which match listed
transports:
d = DECnet
m = Modem
t = TCP/IP
x = X.25
Currently: The command has been fixed. The -A option now adds an entry to
the route map, DSN$DATA:DSN_ROUTE_MAP.DAT.
2–10 Fixed Bugs
Fixed Bugs
2.8 Route Map
2.8.2 Route Map Access Time Reduced
Previously: Route map access can be slow when supporting a large number of
DSNlink connections to the host.
Currently: Access time has been improved by sorting the route map. A sorted
route map has this file name:
DSN$DATA:DSN_ROUTE_MAP.DAT-SORTED
DSNlink creates the sorted route map as necessary, and it requires no upkeep or
monitoring.
2.8.3 Communications from a B Node Did Not Go Through the A Node
Previously: When a B node used an A node to connect to the host, it was
redirected to the host and bypassed the A node. This occurred because the cost of
the A node’s entry was higher than the cost of the host’s entry.
Currently: DSNlink no longer writes the host’s entries to the route map on the
B node. This prevents the B node from bypassing the A node.
2.8.4 Route Map Single-Port Mode Was Not Retained
Previously: When generating a route map, you can choose to use single-port
mode. However, the setting was not retained anywhere. Therefore, if you
regenerated the route map and did not specify the mode, the route map generator
used multi-port mode.
Currently: The single-port mode for communications is now stored in the
configuration file parameter Setup.Routemap.IP.Ports.Single.
This value is set to true by default.
For more information on using multiple ports, see Section 1.6.1.
2.9 Service Request Application
The following are fixes to the Service Request Application.
2.9.1 Some Routing Codes Mistakenly Sent Acknowledgement Mail
Previously: If you sent a non-service request to the host, such as a suggestion,
you received a service request acknowledgement instead of a thank you note for
the suggestion.
Currently: The code has been modified so that the confirmation mail is not sent
if no service request number is returned by the host. You receive the appropriate
reply.
2.9.2 SICL Requests Via a Modem Might Fail During Batch Processing
Previously: Service requests submitted by the System-Initiated Call Logging
(SICL) software occasionally failed to be delivered from a DSNlink Version 2.2E
system using the modem transport. The requests were not submitted to the
DSN$BATCH queue, which sends them to the Compaq host.
Currently: This problem has been fixed so that the SICL submission is
submitted to the DSN$BATCH queue. If, during attempts to send the SICL
message, errors occur, the message is requeued until the maximum number of
retries is reached.
Fixed Bugs 2–11
Fixed Bugs
2.9 Service Request Application
2.9.3 Service Request Submitter’s Name Was Lost
Previously: Beginning in DSNlink Version 2.2D, OpenVMS mail was changed to
use batch processing. If mail was sent from a non-DSNlink node to a DSNlink A
node (gateway), DSNlink lost the original submitter’s node name and username.
For example, prior to DSNlink Version 2.2D, information in the header of a
System-Initiated Call Logging (SICL) service request had this information:
From:
To:
Subj:
(280280) source-node::[email protected]
DSN%SICL
DECevent Service Request - SICL End To End Test:[S011F]
Beginning with DSNlink Version 2.2D, the information in the From field was
from the MAIL$SERVER account as in this example:
From:
To:
Subj:
(280280) [email protected]
DSN%SICL
DECevent Service Request - SICL End To End Test:[S011F]
Consequently, the Customer Support Center’s reply mail about SICL events was
sent to the MAIL$SERVER account rather than to the system that sent the mail.
This error also occurred for any system that submitted a service request in batch
mode from a B node. The response went to the MAIL$SERVER account on the A
node instead of to the original submitter.
Currently: This problem has been fixed. Replies to service requests are sent to
the node where the request originates.
Note that even with this change, some replies may not be seen by the submitter.
For example, DECevent automatically forwards mail sent to DIA$MANAGER to
the SYSTEM account, which can be verified with this command:
MAIL> SHOW FORWARD/USER=DIA$MANAGER
DIA$MANAGER has mail forwarded to SYSTEM
In this case, the service request acknowledgement appears in the NEWMAIL
folder of the SYSTEM account. The submitter does not get the reply.
2.9.4 DSN%"SRQ$NULL Was Returned for Routing Codes That Generate an
Automatic Response
Previously: When submitting a service request to a routing code that
automatically responds to the service request, you received the service request
acknowledgment with the NULL routing code in the From field instead of the
correct routing code. This is an example of a service request acknowledgement:
From:
To:
CC:
Subj:
DSN%"SRQ$NULL"
Gotfield
DSNlink Acknowledgment for Service Request
(via Dsn_Mail T3.0-IFT5; sender [email protected])
Support Center: cscabc.digital.dsn
Access Number:
282828
Routing Code:
MARKM-TEST
Subject:
Test
Your service request has been successfully created.
2–12 Fixed Bugs
Fixed Bugs
2.9 Service Request Application
Currently: The routing code you use appears in the From field instead of NULL
in the service request acknowledgement mail. For example:
From:
To:
CC:
Subj:
DSN%"MAIL-TEST"
Gotfield
DSNlink Acknowledgment for Service Request
(via Dsn_Mail T3.0-EFT1; sender [email protected])
Support Center: cscabc.digital.dsn
Access Number:
282828
Routing Code:
MAIL-TEST
Subject:
Test
Your service request has been successfully created.
2.9.5 The Create Service Request Tutorial Did Not Appear
Previously: When you displayed the Create Service Request window and chose
Tutorial from the Help menu, the following error message appeared:
Requested document (URL file://localhost/dsn$help/) could not be
accessed.
The information server either is not accessible or is refusing to
serve the document to you.
Currently: This has been fixed. The tutorial information for the Create Service
Request window now appears.
2.10 SRQ Utility
The following are fixes to the SRQ utility. For a description of the utility, see the
"Managing DSNlink" chapter in the DSNlink User’s Guide.
2.10.1 The SRQ Utility’s Hardware Database Could Not Be Accessed
Previously: When you used the VT Menu (which provides a way to use the
DSNlink command line interface without having to enter commands), if you chose
Service Request => DSNlink Create Service Request, the SRQ utility did not
appear. Instead a prompt for the routing code appeared.
Currently: DSNlink now displays the SRQ utility if you choose the Service
Request menu item from the DSNlink VT Menu.
If you prefer to not display the SRQ utility when you choose Service Request
DSNlink Create Service Request, enter this command before invoking the VT
Menu:
$ RENAME DSN$DATA:DSN$HARDWARE_DB.DAT
DSN$DATA:DSN$HARDWARE_DB.OLD
The prompt for a routing code appears.
Fixed Bugs 2–13
3
Known Problems and Restrictions
This chapter lists the known problems and restrictions in DSNlink Version 3.0.
3.1 Restrictions
3.1.1 X.25 Is Not Supported for Intra-Cluster A and B Node Communications
Restriction: The X.25 transport is not supported for communications between A
and B nodes within an OpenVMS Cluster. X.25 is supported for communications
between A nodes within an OpenVMS Cluster, between standalone A and B nodes
that are not within an OpenVMS Cluster, and between A nodes and the DSNlink
host. You can use DECnet or TCP/IP for communications between A and B nodes
in an OpenVMS Cluster.
3.1.2 Do Not Use Rooted Logical Names for the Installation Device
Restriction: Do not use a rooted logical name, such as SYS$COMMON, for
the device for the DSNlink directory tree. Instead, enter SYS$SYSDEVICE: or
DISK$USER1: when asked for the device and directory for the DSNlink directory
tree in the DSNlink Version 3.0 installation.
3.1.3 OpenVMS Installations Require That You Log In To the SYSTEM Account
You must log in to the SYSTEM account to install DSNlink on OpenVMS. For
more information, see Section 1.7.5.
3.1.4 You Cannot Reply to Mail from Compaq
Restriction: When you receive mail from Compaq, such as Flash mail, surveys,
marketing information, and responses to your service requests, if you reply to the
mail, DSNlink appears to send the reply, but it is not delivered.
Workaround: Contact your Customer Support Center by telephone or with a
new service request to respond to mail. To respond to replies to service requests,
use the Augment Service Request function of the Service Request application.
3.1.5 The Year Part of Dates Must Have Four Digits
Restriction: To ensure that DSNlink does not misinterpret dates beginning in
the year 2000, you must enter all years with four digits. Previously, you could
enter either two or four digits for the year. Without this requirement, DSNlink
might interpret the date Jan 01, 01 as January 01, 1901 when the intended date
was January 01, 2001.
You enter dates in the following places:
•
ITS, when you search for articles based on their last technical review date
•
Service requests, when you fetch lists of open or closed service requests based
on their dates
Known Problems and Restrictions 3–1
Known Problems and Restrictions
3.1 Restrictions
•
The local and remote authorizations files when you allow or disallow access to
DSNlink applications and include the year in the date
•
Configuration file parameters that specify a date, such as Its.BeginDate
Some date formats without the year imply the current year. The date formats
dd month (01 January), dd-month (01-Jan), and month dd (Jan 01) force the
application to use the current year.
If you do not enter a four-digit year, DSNlink displays an error message.
3.1.6 The Modem Daemon Must Be Started from a Privileged Account
Restriction: You must start the modem daemon from a privileged account.
The account you use must have at least these privileges: DETACH, LOG_
IO, NETMBX, OPER, SYSPRV, TMPMBX, and WORLD. Without sufficient
privileges, when you attempt to start the modem daemon, the modem daemon
does not start and messages list the necessary privileges.
DSNlink developers recommend starting the modem daemon from the SYSTEM
account.
3.1.7 Defining EDIT Prevents TPU from Displaying Files
Restriction: In the DECwindows Motif interface, if you define the EDIT
command, it prevents the TPU editor from displaying these files on the Utilities
menu: Local Authorizations, Remote Authorizations, History Records, and the
Systemwide and User Configuration files. This message appears in the window
where you start DSNlink:
%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
\INTERFACE\
If you see the above error message, look for definitions such as the following,
which may appear in your LOGIN.COM file:
$ EDIT
:== EDIT/EDT/COMMAND=EDTINI.EDT
Workaround: Deassign the symbol for the DSNlink session. For example:
$ DELETE/SYMBOL/LOCAL EDIT
Note: The EDIT definition does not interfere with the ITS view command, which
invokes TPU.
3.2 File Copy Problems
The following are problems in the File Copy application.
3.2.1 File Copy Is Unable to Copy Beyond the EOF Marker
Description: The File Copy application does not copy any part of a file beyond
the end-of-file (EOF) marker. Usually, the part of the file beyond the EOF marker
contains unused bytes that do not need to be copied. However, if the EOF is
misset due to a file corruption problem, the entire file might need to be copied to
Compaq for repair, which includes the bytes beyond the EOF marker.
Workaround: If you need to copy a file to Compaq and include the data beyond
the EOF marker:
1. Enter this command, which sets the EOF to the end of the file:
$ SET FILE/END_OF_FILE filename
3–2 Known Problems and Restrictions
Known Problems and Restrictions
3.2 File Copy Problems
where filename is the name of the file to copy.
2. Use the File Copy application to send the file to Compaq.
3.2.2 History Log Does Not Have Outgoing File Copy Records
Description: The history log file, DSN$LOGS:DSN_HISTORY.LOG, does not
have records for files you copy to the host with the File Copy application. The
history log file does record host-initiated file copies.
Workaround: None.
3.3 Interactive Text Search (ITS) Problems
The following are problems in the Interactive Text Search (ITS) application.
3.3.1 DECthreads Bugcheck Error
Description: Running ITS in command line mode, it did not exit cleanly. After
using Ctrl/Y to end the session, this DECthreads error appeared:
Selected a non-ready thread -2 (0x...bd9b40)
state blocked".
This PTHREAD_DUMP.LOG;1 was left in DSN$ROOT:[DAT.ZNODE]:
%DECthreads bugcheck (version V3.15-262), terminating execution.
%Reason: selected a non-ready thread -2 (0x0000000000BD9B40) state
blocked
%Running on OpenVMS V7.2-1 on AlphaStation 250 4/266, 384Mb; 1 CPUs
% The bugcheck occurred at 29-AUG-2000 09:41:15.18, running image
% DSA2:[DSN.][EXE.ALPHA]DSNMAIN.EXE in process 210000E9 (named
"ABIGAIL_DCL"),
% under username "ABIGAIL". AST delivery is enabled for all modes; no
ASTs
% active. Upcalls are disabled. Multiple kernel threads are disabled.
% The current thread sequence number is -2, at 0x00BD9B40
% Current thread traceback:
%
0: PC 0x7BBADAC8, FP 0x00BD7570, DESC 0x7BB8FBD8
%
1: PC 0x7BBABEB4, FP 0x00BD7640, DESC 0x7BB8F698
%
2: PC 0x7BBA9C9C, FP 0x00BD76B0, DESC 0x7BB8F778
%
3: PC 0x7BBBCCB4, FP 0x00BD7770, DESC 0x7BB922D0
%
4: PC 0x7BBBD528, FP 0x00BD7830, DESC 0x7BB92310
%
5: PC 0x001C6664, FP 0x00BD7860, DESC 0x00196110
%
6: PC 0x0035DF08, FP 0x00BD78B0, DESC 0x00275750
%
7: PC 0x000A3CB4, FP 0x00BD7920, DESC 0x0002E5D0
%
8: PC 0x8095D16C, FP 0x00BD7990, DESC 0x7BE362E0
%
9: PC 0x80068E14, FP 0x00BD7A00, DESC 0x84AD39B8
%
10: PC 0x800CC7D0, FP 0x00BD7A50, DESC 0x82C3A3B0
%
11: PC 0x800DD5B0, FP 0x00BD7AC0, DESC 0x82C3C140
%
12: PC 0x7B034354, FP 0x00BD7C90, DESC 0x82C3AF40
%
13: PC 0x7BBD9478, FP 0x00BD7CB0, DESC 0x7BB950F0
%
14: PC 0x7BBCD408, FP 0x00BD7CD0, DESC 0x7BB93BA0
%
15: PC 0x7BBCC580, FP 0x00BD7D00, DESC 0x7BB93BD8
%
16: PC 0x7BBBF15C, FP 0x00BD7DA0, DESC 0x7BB92098
%
17: PC 0x7BBAF494, FP 0x00BD7FE0, DESC 0x7BB90470
%
18: PC 0x00000000, FP 0x7AF05B10, DESC 0x7BB8E4B0
%
19: PC 0x7B03352C, FP 0x7AF09BB0, DESC 0x7B00A330
Workaround: None.
Known Problems and Restrictions 3–3
Known Problems and Restrictions
3.3 Interactive Text Search (ITS) Problems
3.3.2 OPCOM Messages May Appear After Receiving an ECO
Description: After you successfully receive an engineering change order (ECO)
and its accompanying confirmation mail messages, OPCOM messages may appear
if OPCOM is enabled on the system. For example:
1. This message is related to using MultiNet instead of DIGITAL Services for
TCP/IP (UCX) and is not a problem that DSNlink can address:
%%%%%%%%%%% OPCOM 5-JAN-1998 00:06:00.67 %%%%%%%%%%%
Message from user SYSTEM on WINTER
MultiNet Server: DSN_NSD (accepted) from [111.222.33.444,5555]
(dsnlink.support.compaq.com)
2. This message is also a normal notification message:
%%%%%%%%%%% OPCOM 30-JUL-1997 09:17:30.99 %%%%%%%%%%%
Message from user INTERnet on SPRING
INTERnet ACP DSN_NSD Accept Request from Host: 111.2.33.44
Port: 1179
3. Messages about sockets indicate a DSNlink application’s completion:
%%%%%%%%%%%
%%%%%%%%%%%
Message from
INTERnet ACP
OPCOM 13-JAN-1998 10:54:22.95 %%%%%%%%%%%
OPCOM 13-JAN-1998 10:54:22.95 %%%%%%%%%%%
user INTERnet on FALL
detected DSN_FILE exiting before ’socket’
Workaround: Consult your TCP/IP implementation documentation to disable
the messages.
3.3.3 An ITS Timeout Causes TPU to Exit with an Access Violation
Description: In the ITS command line interface, if you are reading an article in
the editor when the session time limit expires, TPU exits with an access violation
message.
Workaround: None. This problem does not affect future ITS sessions.
3.4 Installation and Startup Problems
3.4.1 Netscape Reduces the Colors Available to DSNlink
Description: After installing DSNlink, the DSN/WINDOWS command may
result in this message:
$ dsn/win
X Toolkit Warning: Urm__CW_ConvertValue: Could not convert color/pixel
’Maroon’
- MrmNOT_FOUND
X Toolkit Warning: Urm__RealizeColorTable: Could not load color ’Dark
Orchid’ MrmSUCCESS
The DECwindows interface appears with fewer colors than it should have.
This error occurs when Netscape is running when you start DSNlink. It is a
color display problem that cannot be fixed in DSNlink code. problem. Netscape
allocates 216 color map entries for its color table. Most older color graphics
adapters have only 256 colors. When Netscape takes 216 colors, not many are left
for other applications, such as DSNlink.
Workaround:
1. Exit DSNlink and Netscape.
3–4 Known Problems and Restrictions
Known Problems and Restrictions
3.4 Installation and Startup Problems
2. Start Netscape with the -install option to make it use a private color map.
For example:
$ netscape -install
The Netscape color map errors may appear anyway, and any other existing
pleasant colors on your screen are replaced with color combinations that were
rejected by Netscape for obvious reasons. However, amid the color muck,
Netscape looks fine.
3. Start DSNlink.
DSNlink starts without messages about missing colors.
Or, you can restrict the number of colors Netscape is allowed to allocate with
either of these methods:
•
Use the following resource setting, which, in this example, sets the maximum
colors to 80:
Netscape*maxImageColors: 80
•
Use the -ncols option to specify the maximum number of colors. For example,
this command specifies 128 colors:
$ MCR NETSCAPE -ncols 128
3.5 Mail Problems
The errors in this section pertain to DSNlink mail.
3.5.1 Mail to DSN% Addresses Fails with a Timeout Error
Description: Mail to DSN% addresses can fail due to a time-out error.
Workaround: Use the DSN CREATE command. See the ITS article "[DSNlink
/OpenVMS] V2.2 Maximum Amount of Time to Deliver Error from Mail" for
details on how to obtain the image that corrects this problem.
3.5.2 A Mail File Cannot Be Restored from the Pulldown Menu
Description: If you include a file name when you invoke the DSNlink Mail
window, the specified file properly appears in the Message Body window. For
example, this command displays the DSNlink Mail window and enters the file
TEXT.TXT in the window:
% DSN MAIL/WINDOWS TEST.TXT
However, if you erase the file from the window and then try to restore it by
choosing its name from the pop-up menu (where the file name is listed), only the
file name appears in the Message Body area.
Workaround: Instead of including the file name in the DSN MAIL/WINDOWS
command, in the DSNlink Mail window, use the Include File... menu item to
choose the file to include.
3.6 Maintenance or Multiple Application Problems
The following are problems that apply to DSNlink maintenance or to multiple
applications.
Known Problems and Restrictions 3–5
Known Problems and Restrictions
3.6 Maintenance or Multiple Application Problems
3.6.1 History Log File Does Not Show Some Rejected Applications
Description: The history log file, DSN$DATA:DSN_HISTORY.LOG, does not
have failure records when the host rejects the Network Exerciser, fetches of lists
by the Service Request application, and File Copy jobs. Rejection occurs when the
host system disallows access by applications, usually because the service contract
has expired.
When you run the application, such as the Network Exerciser, a message appears
that the application is rejected. However, the history log file has this information:
•
Network Exerciser–the record’s status is CANCEL followed by the test results
•
File copy–no record
•
Create service request–a failure record
•
ITS–a failure record
•
Fetch service requests–two records, one for failure, one for success
•
Review service requests–a failure record
•
Service request augmentations–a failure record
A failure record should appear for the application.
Workaround: Contact your Customer Support Center if the application is
rejected even if the history record does not show a failure.
3.7 Modem Problems
The following sections describe known modem problems.
3.7.1 The DSN TEST HDLC Command Does Not Complete
Description: The HDLC protocol, introduced in DSNlink Version 2.2D, prevents
DSN TEST HDLC tests from completing.
Workaround: None. Do not use the DSN TEST HDLC command.
3.7.2 Modem Reset Phase Is Lengthened During Simultaneous Connections
Description: When customer and host systems make simultaneous connections
to each other, for example the host begins a Network Exerciser test at the same
time your system initiates a Network Exerciser test, it takes the modem about 12
seconds to reset. It should take one or two seconds.
This problem was discovered in DSNlink Version 2.2D.
Workaround: None.
3.7.3 Modem Daemon Ignores Sick and Dead Limits on Alpha Systems
Description: The modem daemon has error thresholds that place it in the sick
or dead state. For example, it is in a sick state if it cannot detect a heartbeat
message in three consecutive attempts or when there are too many attach errors.
The daemon is considered dead if there is no heartbeat message after 20 attempts
to detect it, or if the daemon exceeds an error threshold. On Alpha systems, the
sick and dead limits for detecting errors are ignored. Consequently, the modem
daemon cannot properly process the errors.
Workaround: None.
3–6 Known Problems and Restrictions
Known Problems and Restrictions
3.8 Network Exerciser Problems
3.8 Network Exerciser Problems
The following are bugs in the Network Exerciser application.
3.8.1 The Network Exerciser Does Not Support the LZW_DYN Compression
Option
Description: When you specify the LZW_DYN (dynamic Lempel-Ziv-Welsh)
compression algorithm when using the Network Exerciser, a message tells you
the operation failed and the LZW_DYN compression option is unsupported.
Workaround: Use the Network Exerciser compression option None to test
the effects of compression. If you then click on LZW, DSNlink compresses the
Network Exerciser messages the same way it compresses all transferred data.
3.8.2 Error Messages Overwrite Statistics Report
Description: If an error occurs when using the Network Exerciser in the
command line interface with the modem transport, the error message overwrites
the statistics line. For example,
--- DsnTransport::MODEMERR, Modem error982/39982/0 C726
- DsnModem::LINK_ABORT, Data link aborted by session entity
Workaround: If possible, perform the test in the DECwindows Motif interface.
If modem errors appear there or when you use other applications, contact your
Customer Support Center.
3.8.3 The Network Exerciser Has Not Implemented Mirror Options or
Language Recognition
Description: The mirror clarity items for the Network Exerciser utility are not
implemented, except for Pure, which returns bytes without any manipulations.
The unimplemented mirror options are: Invert, Reject Always, Reverse, Rotate,
and Scratched. Tests with those items selected run as Pure tests. There are no
error messages that the items are not implemented.
The Language field is also ignored.
Workaround: None.
3.9 Route Map
The following are known bugs related to the route map.
3.9.1 Identical Learned Entries in the Route Map
Problem: When DSNlink connections are forwarded between applications on
the same system, and the applications write their learned connection path in the
route map, it is possible for duplicate learned entries to be entered into the route
map. This problem has little effect on connection routing, but it can clutter the
route map.
The following is an example of duplicate entries from backwards learning:
280142/zanode/*
280142/zanode/*
t/zanode.cxo.dec.com/dsn_nsd
t/zanode.cxo.dec.com/dsn_nsd
255
255
Workaround: Regenerate the route map using the Configuration utility,
DSN$COMMAND:DSN$CONFIG.COM. This sorts the entries and removes
duplicates.
Known Problems and Restrictions 3–7
Known Problems and Restrictions
3.10 Service Request Application Problems
3.10 Service Request Application Problems
The following are known problems in the Service Request application.
3.10.1 Some Routing Code Descriptions Are Displayed Twice
Description: When you fetch a list of your routing codes, some of the routing
code descriptions appear twice. For example:
$ DSN FETCH ROUTING_CODES
.
.
.
DIA
DIA (DIGITAL Dial-In Access) Support
DIA (DIGITAL Dial-In Access) Support
DSNLINK
DSNlink for OpenVMS, DSNlink for ULTRIX and
DSNlink for DIGITAL UNIX[R]: Questions with the
installation and use of the DSNlink service tool;
Modem and phone line connections; Security
issues; DSNlink configuration and application
management issues.
DSNlink for OpenVMS, DSNlink for ULTRIX and
DSNlink for DIGITAL UNIX[R]: Questions with the
installation and use of the DSNlink service tool;
Modem and phone line connections; Security
issues; DSNlink configuration and application
management issues.
.
.
.
Workaround: None.
3.10.2 Problem Description Lines Over 255 Characters Are Truncated
Description: If you create a service request in the DECwindows Motif interface
and enter the problem description without pressing the Return or Enter keys,
even if the text wraps in the window, DSNlink converts the text into a single line.
If you view a copy of the service request, the problem description, now a single
line, is truncated after 255 characters.
Workaround: When entering a problem description in the Create Service
Request Application window, press the Return or Enter key after each line of text.
Make sure that lines do not exceed 256 characters.
3–8 Known Problems and Restrictions
4
Starting DSNlink and Getting Help
4.1 Starting DSNlink
To display the DSNlink main window, use this command:
$ DSN/WINDOWS
To use DSNlink in the command line interface, see the online help. To display
the online documentation, enter this command:
$ DSN HELP
4.2 Getting Help
In the DECwindows interface, use the Help menus or Help buttons to access the
online help. It is displayed by the Netscape browser, which is not included in
your kit. For information about downloading Netscape, see the DSNlink Version
3.0 for OpenVMS Installation Guide.
In the command line interface, the DSN HELP command displays a list of
documents you can access. The information is displayed in the Lynx browser,
which is included in the kit.
For VMS Version 5.5-2 customers, who do not have Netscape to disply the
DSNlink User’s Guide, you can print the DSNlink Version 3.0 User’s Guide for the
DECwindows Motif Interface, which is included in the DSNLINK030.S save set.
Starting DSNlink and Getting Help 4–1
Index
A
A nodes
requirements, 1–6
skipped in communications, 2–11
Authentication, 1–2
B
Batch queues, 1–8
B nodes
requirements, 1–6
C
Clusters
See OpenVMS Clusters
Colors
Netscape interference, 3–4
Command line interface
DECwindows Motif requirement, 1–9
Communications
B nodes skip A node, 2–11
receiver node, 1–11
Communique mail
cannot reply, 3–1
change in defining recipients, 1–10
Configuration file
parameter definitions for clusters, 1–7
Conventions
used in this manual, viii
D
Dates
four-digit requirement, 3–1
DECevent
customer replies went to MAIL$SERVER, 2–12
DECnet
BG node names mistaken for BG devices, 2–1
DECthreads bugcheck error, 2–6
DECwindows Motif
requirement dropped, 1–9
resource files in DSN$ROOT:[DAT], 1–7
Default receiver node
See Receiver node
DES, 1–1
Digital TCP/IP Services for OpenVMS
requirement, 1–5
Documentation guide, vii
4DSN
receiver node name, 1–11
DSN commands
modem daemon identifier is gone, 2–6
DSNlink
cannot reply to mail, 3–1
documentation, vii
overview, vii
restrictions, 3–1
starting, 4–1
startup and shutdown files relocated, 1–7
V3.0 purpose of kit, 1–1
V3.0 restrictions, 1–1
DSNMAPQ
add feature now works, 2–10
E
EDIT definition
interferes with TPU, 3–2
Encryption, 1–1
version, 1–1
F
File Copy application
EOF marker, 3–2
fixed problems, 2–1
history log missing outgoing records, 3–3
known problems, 3–2
mail notification, 2–2
TYPE-F-WRITEERR message, 2–2
work units for file copies, 2–2
Files
deleting obsolete, 1–8
Motif resource files, 1–7
H
Hash-based message authentication code
See HMAC
Index–1
History log file
missing some rejected applications, 3–6
outgoing file copy records, 3–3
HMAC
authentication keys, 1–2
functions, 1–2
I
Installation
problems, 3–4
SYSTEM account requirement, 1–7
ITS application
command procedures produced timed read
errors, 2–5
DECthreads bugcheck error, 3–3
extracted articles had characters only in the
first column, 2–4
fixed problems, 2–4
initialization file, 2–4
known problems, 3–3
mistyped Show Database command resulted in
ACCVIO, 2–4
modems made one ITS connection, 2–5
OPCOM messages, 3–4
SPAWN command, 1–9
timeout when reading an article in TPU, 3–4
L
Log files
host name appears, 1–7
Lynx
TCP/IP Services for OpenVMS, 1–5
M
Mail
cannot restore file, 3–5
communique mail recipients, 1–10
DSN% addresses time out, 3–5
known problems, 3–5
Maintenance
known problems, 3–5
MD5, 1–2
Modem transport
DSN commands invoked the modem daemon
identifier, 2–6
DTE speed in MDDF, 2–5
fixed problems, 2–5
ignores sick and dead limits, 3–6
known problems, 3–6
no hangup after a DSNlink session, 2–5
one ITS connection, 2–5
privileged account required, 3–2
REPKO modem scripts, 1–11
reset phase, 3–6
Index–2
Mosaic browser, 1–3
MultiNet, 1–5
Multiple applications
known problems, 3–5
Multiple-port mode for TCP/IP, 1–4
N
Netscape
color adjustment, 3–4
replaces Mosaic, 1–3
Network Exerciser
Authentication and Encryption fields, 2–9
errors after defining DSNGATEWAY_TRACE,
2–8
fixed problems, 2–8
initial test failed, 2–9
IVP failure due to authentication key file
format, 2–9
known problems, 3–7
messages overwrite statistics, 3–7
midtest errors, 2–9
mirror options and language recognition, 3–7
no LZW_DYN option, 3–7
verbose qualifier, 2–9
Node types
A and B node designations, 1–6
A node is the receiver node, 1–11
O
Online documentation
accessing, 4–1
displayed by Netscape in DECwindows, 1–3
OpenVMS Clusters
configuration file parameters, 1–7
directories for mixed architectures, 1–6
missing files after installation, 2–2
names for subdirectories, 1–6
RMS-W-RTB errors during DSNlink startup,
2–6
startup run on cluster members, 2–3
SYSTEM account requirement, 3–1
X.25 support, 3–1
R
RC4 and RC5, 1–1
Receiver node, 1–11
Remote Login application
performance, 1–3
Remote logins
authorized via the VT Menu, 1–8
REPKO modem scripts, 1–11
RMD160, 1–2
RMS-W-RTB error, 2–6
Rooted logical names
restriction on use, 3–1
Route map
access time reduced with sorted map, 2–11
DSNMAPQ does not add entries, 2–10
identical learned entries, 3–7
single-port mode was not retained, 2–11
TCP/IP uses single-port mode on A nodes, 1–4
X.25 entry corrected, 2–3
Routing codes
null code no longer returned, 2–12
S
Service Request application
acknowledgement mail incorrectly sent, 2–11
fixed problems, 2–11
hours can be added to beginning and ending
dates, 1–9
known problems, 3–8
submitter information lost, 2–12
SHA1, 1–2
Shutdown
DSN$STARTUP.COM removes images, 1–7
file in new location, 1–7
SICL
modem requests fail, 2–11
submitter information lost, 2–12
Single-port mode for TCP/IP, 1–4
SPAWN command, 1–9
SR160, 1–2
SRQ utility
invoking from the VT Menu, 2–13
startup is part of DSNlink startup, 1–8
Startup
file in new location, 1–7
not queued correctly on a large OpenVMS
Cluster, 2–6
Startup file
run on OpenVMS Cluster members, 2–3
SYSMAN
creates objects, 2–2
SYSTEM account
required for cluster installations, 3–1
T
TCP/IP
MultiNet and TCPware can be used, 1–5
single port mode, 1–4
UCX not required, 1–5
TCPware, 1–5
TDES, 1–1
Timed read error, 2–5
Triple DES, 1–2
TYPE-F-WRITEERR message, 2–2
V
VT Menu
hardware database fix, 2–13
remote logins authorized, 1–8
W
Work units
file copies, 2–2
X
X.25
communication within clusters, 3–1
incomplete X.25 setting, 2–1
initial Network Exerciser test failed, 2–9
route map entry corrected, 2–3
Y
Year entries
four-digit requirement, 3–1
Index–3
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement