OpenVMS VAXMAIL03_071 MAIL Utility for OpenVMS VAX V7.1 ECO Summary
TITLE: OpenVMS VAXMAIL03_071 MAIL Utility for OpenVMS VAX V7.1 ECO Summary
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
The name of the compressed file will be kit_name-dcx_vaxexe
for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
Once the file is copied to your system, it can be expanded
by typing RUN compressed_file. The resultant file will
be the OpenVMS saveset or PCSI installation file which
can be used to install the ECO.
Copyright (c) Compaq Computer Corporation 1999. All rights reserved.
Modification Date: 18-Feb-99
Modification Type: Updated Kit: Supersedes VAXMAIL02_071
PRODUCT: OpenVMS VAX
COMPONENT: MAIL.EXE
MAIL_OLD.EXE
MAILSHR.EXE
MAILSHRP.EXE
MAIL_SERVER.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: VAXMAIL03_071
ECO Kits Superseded by This ECO Kit: VAXMAIL02_071
VAXMAIL01_071
ECO Kit Approximate Size: 882 Blocks
Kit Applies To: OpenVMS VAX V7.1
System/Cluster Reboot Necessary: No
Installation Rating: INSTALL_3
3 - To be installed on all systems running
the listed versions of OpenVMS which
are experiencing the problems described.
Kit Dependencies:
The following remedial kit(s) must be installed BEFORE
installation of this kit:
None
In order to receive all the corrections listed in this
kit, the following remedial kits should also be installed:
None
ECO KIT SUMMARY:
An ECO kit exists for MAIL on OpenVMS VAX V7.1.
Problems Addressed in VAXMAIL03_071:
o In OpenVMS V6.2, if the MAIL$INTERNET_TRANSPORT logical was
defined, the user could enter an address formatted according to
the syntax rules of the transport image pointed to by the
logical. Then an entry could be done without including the
transport name followed by a percent sign or without enclosing
the recipient address in double quotes. For example, the
address "user%xx@node.domain" could be entered and the message
would be successfully delivered.
In OpenVMS V7.0 and later, if the MAIL$INTERNET_TRANSPORT was
defined and the user entered a recipient address formatted as
above, the sender would eventually receive an error message
that the message was not delivered due to an unknown recipient.
o Use of external temporary edit files was restored to the mail
user interface.
In OpenVMS V7.1 MAIL, in some cases the User Interface (UI)
uses the same file for input and output during editing
functions. Via the MAIL$EDIT logical, users can have a variety
of procedures that modify the file specified in the input
argument parameter P1 and attempt to output it to the output
parameter argument P2. Using OpenVMS V6.2 MAIL, the write to
the output file (P2) succeeded. However, using OpenVMS V7.1,
the write to the output file fails with a file locked error.
The file name issue is easily reproducible using a command file
(eg. MAIL_TEST.COM) which contains:
$ SHO SYM p1
$ SHO SYM p2
$ EXIT
For a VAX running OpenVMS V6.2:
VMSSPT> DEFINE MAIL$EDIT work3:[user1.tests]mail_test.com
VMSSPT> MAIL
MAIL> REPLY/EXTRACT/NOSELF
To: NODE::USER1
CC:
Subj: RE: DCL quote parsing rules
P1 = "SYS$SCRATCH:MAIL_21E01ECA_EDIT.TMP" <<<<< infile name
P2 = "SYS$SCRATCH:MAIL_21E01ECA_SEND.TMP" <<<<< outfile name
%MAIL-E-SENDABORT, no message sent
MAIL>
For a VAX running OpenVMS V7.1:
VMSSPT> DEFINE MAIL$EDIT work300:[user1.tests]mail_test.com
VMSSPT> MAIL
MAIL> REPLY/EXTRACT/NOSELF
To: NODE::USER1
CC:
Subj: RE: test
P1 = "SYS$SCRATCH:MAIL_26204609_SEND.TMP" <<<<< infile name
P2 = "SYS$SCRATCH:MAIL_26204609_SEND.TMP" <<<<< outfile name again
%MAIL-E-SENDABORT, no message sent
MAIL>
For an Alpha running OpenVMS V7.1:
VMSSPT> DEFINE MAIL$EDIT mail_test.com
VMSSPT> MAIL
MAIL> REPLY/EXTRACT/NOSELF
To: EVMS::USER1
CC:
Subj: RE: ALPHA OpenVMS V7.1 image
P1 = "SYS$SCRATCH:MAIL_53E00262__SEND.TMP" <<<<< infile name
P2 = "SYS$SCRATCH:MAIL_53E00262_SEND.TMP" <<<<< infile name again
%MAIL-E-SENDABORT, no message sent
MAIL>
Further testing revealed that several other mail commands were
using incorrect input and output file names:
REPLY/EDIT/LAST
REPLY/EXTRACT
REPLY/EXTRACT/EDIT
ANSWER/EXTRACT
ANSWER/LAST/EDIT
SEND/EDIT/LAST
MAIL/EDIT/LAST
FORWARD/EDIT
o The OpenVMS V7.1 MAIL DIR command output needed to be directed.
Defining the logical SYS$OUTPUT to a file and then executing
the command DIR/NEW within the MAIL utility no longer returned
a listing of the new file messages as it did in OpenVMS V6.1.
o When an application attempts to extract mail from the user's
mail files by doing a $SET FILE to point to the target user's
mail files, which are 'foreign' documents, the extract fails.
The current user's MAIL directory is searched rather than the
mail directory of the target user where the the document files
(MAIL$nnnnnnnn.MAI) exist.
A sequence of MAIL commands to duplicate the problem are:
$ MAIL/FOR LOGIN.COM NODE::USER
- then on NODE logged in as say SYSTEM:
$ MAIL
SET FILE DIA0:[USER]
SET FOLDER NEWMAIL
READ 1
EXTRACT USER1.DAT
$
The above example fails to issue a message (sample expected
message below) and no file is created:
%MAIL-I-CREATED, SYS$SYSROOT:[SYSMGR]USER1.DAT;1 created
o Two problems concerned the use of the MAIL$INTERNET_TRANSPORT
logical:
1. Defining MAIL$INTERNET_TRANSPORT forced the use of the
alternate mail image, even when DECnet should be used.
2. If the user included a different transport on the "TO"
line, the mail code treated it as part of the address and
passed it on to the image defined by
MAIL$INTERNET_TRANSPORT, causing delivery errors.
Problems Addressed in VAXMAIL02_071:
o When replying to an address of the form node::node::"addressee",
the reply fails with "%MAIL-E-USERSPEC, invalid user specification".
This problem is most likely to occur with X.400 type addresses and
poor man's routing, but can happen with any quoted address using
PMR. However, replying to node::"address" is successful.
Note: (DECnet) "Poor Man's Routing" can be used between nodes
outside of the translation map as long as those nodes have
access to nodes that are in the map. For example, in the
diagram below, a user on node B could issue the following
OpenVMS DCL command:
$ DIR A::D::E::
When a PMR connection is made between 2 networks, only
the two adjacent nodes between the networks will have
any direct knowledge about the other network.
Application-level network access can then be specified
to route through the connection.
Poor Man's Routing sample configuration
Network 1 19.5 47.1 Network 2
------------------------------ ---------------------------
| | | | | | | |
| | | | | | | |
| | | --------------- | | |
19.1 19.2 19.3 /E1---->|<----E2\ 50.1 60.1 19.1
A:: B:: C:: | | D:: E:: F::
| Router |
`---------------'
19.5 --------> 50.1
19.1 <-------- 47.1
For the above configuration, in Network 1, the router is
configured at address 19.4 and is a level 1 router. In
Network 2, the router is configured at address 50.5 and
is an area router. At this point, no routing information
is exchanged between the 2 networks. Each network in the
router has a separate routing table.
Packets in Network 1 sent to virtual address 19.5 will be
routed to Network 2, and the destination address will be
translated to 50.1. Packets sent to virtual address 47.1
in Network 2 will be routed to Network 1 as 19.1.
o When REPLYing to or SENDing a message using the MAIL UI's
"line editor", if the user enters CTRL-C to abort the edit
(and the send), a problem can occur. That is, if the user
then issues a SEND/EDIT/LAST or REPLY/EDIT/LAST as the next
mail command, the text of that message cannot be re-edited
(and resent).
o After upgrading to OpenVMS V7.1, printing from mail produces
an unexpected file flag page in the output.
o Problems have occurred with OpenVMS MAIL users reading mail
sent by Quickmail users. The root of this problem was that
the Quickmail interface allows a user to compose a long
paragraph, without ever hitting the "Return" key. Quickmail
will then wrap the text and send the entire paragraph as one
long line.
OpenVMS MAIL (character cell version), will wrap the text when
displaying a long line, but will only display the first 512
characters of the line. OpenVMS users see only part of the
paragraph and are confused. The old version of MAIL ($MAIL/OLD)
was able to display a line of up to 2048 characters.
(A second related problem was that OpenVMS MAIL will sometimes
display only the first page of a message. It will say "Press
RETURN for more..." at the end of the page, but when you press
RETURN, no more is displayed. This problem happens to some
Quickmail messages which contain long lines. Again, MAIL/OLD
will display it properly.)
o A problem results when copying mail messages from a sequential
mail file into an indexed mail file.
From within MAIL, a sequential mail file is opened containing
small (less than 3 blocks) and large (greater than 3 blocks)
mail messages. These messages are selected and then copied
into a folder in an indexed mail file. After reading and
deleting a large message, the body of the sample small message
shown below is lost. (The header is there, but the body is
gone.)
The following steps can be used to reproduce the behavior:
$ MAIL
MAIL> set file seq_mail_file.mai ! Sequential mail file
MAIL> copy/all test test.mai ! Copy all messages from
! sequential mail file into
! folder 'test' in indexed
! mail file 'test.mai'. Note
! that 2 messages were copied
! - a large one and a small
! one. The file TEST.MAI was
! created by the copy command.
MAIL> set file test.mai ! Point to indexed mail file
MAIL> dir test ! See both mail messages
! Read both messages to ensure they exist
MAIL> delete 1 ! Delete the large mail message
MAIL> purge ! Ensure it gets deleted
MAIL> EXIT
$ MAIL
MAIL> set file test.mai
! Read the second message and the body will be gone
This problem with bodies of emails being lost occurs when the
following conditions are true:
1. At least 2 emails in the sequential mail file were created
within 1 minute.
2. Emails were copied to an indexed sequential access mode
(ISAM) mail file.
3. Order of emails in the sequential mail file were such
that the first email results in an external EMAIL file
being created (MAIL$*.MAI). The second email results
in the entire message being saved in the mail file
(MAIL.MAI).
4. Email that results in the external EMAIL file being
deleted.
5. The body of the remaining email is now lost.
o Interactively defining a key containing a quoted component
fails:
MAIL> define/key/if_state=gold kp9 "read/new"
%MAIL-E-PARSEFAIL, error parsing DEFINE/KEY/IF_STATE=GOLD KP9
READ/NEW
-CLI-W-IVQUAL, unrecognized qualifier - check validity,
spelling, and placement
If this same definition is in a MAIL$KEYDEF.INI file, the key
definition parsing is successful. In addition, enclosing the
command and qualifier inside a triple set of quotes will work,
but this form contradicts the OpenVMS MAIL UI documentation,
and is a departure from pre-V7.1 OpenVMS MAIL UI behavior.
o Sending a mail message to a large distribution list
(between 200 to 700 local users) intermittently signals a
non-fatal SSRVEXCEPTN bugcheck for the sending process.
o MAIL does not provide a correct exit status when invoked
as a Command Line Interface (CLI) command and an error
occurs. This feature worked in pre-V7.0 MAIL.
o A SSRVEXCEPT was caused by an access violation in MAILSHRP.
o Two problems are addressed by this checkin:
1. When MAIL.EXE is invoked as a CLI command and then an
error occurs on a remote node, the error status is
not returned to the user. This error causes problems
when MAIL CLI commands are themselves embedded in DCL
command files, where the success or failure of the
mail command is checked and acted upon.
2. If the symbol MAIL:=="MAIL/EDIT = (SEND,REPLY =
EXTRACT,FORWARD) is defined and the user specifies
/NOEDIT when replying, the editor is invoked so that
NOEDIT is ignored. In addition, when this same MAIL
symbol is defined, REPLY/NOEXTRACT does not invoke
the editor at all, where on OpenVMS V6.2 and before,
REPLY/NOEXTRACT would invoke the editor (without
inclusion of the original message).
o The second and subsequent pages of a mail message scroll
up the screen, which is a departure from previous behavior.
o The "ring-buffer" behavior of reading mail appears to be
broken. After reading and getting the "no more messages"
error, in previous versions of OpenVMS, the next read
would show the first record in the folder. Now it
continues to give the "no more message" error.
o SEND/LAST and SEND/LAST/EDIT do not use the text of the
last message sent.
o The address of the privileged context was zero, causing
any downstream access to any offset within it to access
violate. This problem occurred mostly, but not always,
when an error was being handled.
o On machines running DECnet Phase IV only, sending to a
local quoted addressee returned the user to the MAIL
prompt without any error message. If this address was in
a distribution list, the sender was not informed that the
message was not delivered to one (or more) recipients.
Problems addressed in VAXMAIL01_071:
o Two SSRVEXCEPTION crashes in MAILSHRP when running lbn disk I/O
or UETP, in the context of the image DTWM.
o The TO line in a received message can become so skewed that
passwords for remote distribution lists may be visible.
o In the event of an invalid or nonexistent SYSUAF.DAT, or an
error reading SYSUAF.DAT, the user is unaware of any error and
MAIL either continues, or exits. If an error is signaled at
all, the error message is often meaningless.
o Users of some POP servers, as well as a third-party MAIL UI
(PMDF) were seeing access violations in MAILSHRP. These
occurred primarily in the event of a locked SYSUAF record and
subsequent signaling of MAIL$_UAFGETERR. Sites typically
seeing this to date have been universities where 10,000 to
11,000 simultaneous mail users is the norm.
INSTALLATION NOTES:
The system does not need to be rebooted after this kit is installed.
However, if you have other nodes in your VMScluster, they should
be rebooted or you should install this kit on each system in order to
make use of the new images.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
vaxmail03_071.README
vaxmail03_071.CHKSUM
vaxmail03_071.CVRLET_TXT
vaxmail03_071.a-dcx_vaxexe
|
