|
|
 |
OpenVMS ALPMAIL03_071 ALPHA V7.1 Mail ECO Summary
|
TITLE: OpenVMS ALPMAIL03_071 ALPHA V7.1 Mail ECO Summary
Modification Date: 18-FEB-99
Modification Type: Updated Kit Supersedes ALPMAIL02_071
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 1997, 1998. All rights reserved.
PRODUCT: DIGITAL OpenVMS Alpha
COMPONENT: MAIL.EXE
MAILSHR.EXE
MAILSHRP.EXE
MAIL_OLD.EXE
MAIL_SERVER.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPMAIL03_071
ECO Kits Superseded by This ECO Kit: ALPMAIL02_071
ECO Kit Approximate Size: 2070 Blocks
Kit Applies To: OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2
System/Cluster Reboot Necessary: No
Installation Rating: Not Available
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 Alpha V7.1 through V7.1-1H2. This
kit addresses the following problems:
PROBLEMS ADDRESSED IN ALPMAIL03_071 KIT
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: NODE::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 a 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 ALPMAIL02_071:
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 Enable EDIT/LAST on REPLY and SEND terminated with CTRL-C.
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
MAIL> 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 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 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 2
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 An SSRVEXCEPT is caused by an access violation in MAILSHRP.
o 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.
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 ALPMAIL01_071:
o The TO line in a received message can become so skewed that
passwords for remote distribution lists may be visible.
o Sending a mail message to a large distribution list (between
200 to 700 local users) intermittently signals a nonfatal
SSRVEXCEPTN bugcheck for the sending process.
o Users of a third party MAIL UI (PMDF mail) and a POP server
were seeing crashes due to access violations in MAILSHRP.
These ACCVIOs occurred consistently 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+ 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 OpenVMS VMScluster, they should
be rebooted or you should install this kit on each system in order to
make use of the new images.
|
Files on this server are as follows:
|
»alpmail03_071.README
»alpmail03_071.CHKSUM
»alpmail03_071.CVRLET_TXT
»alpmail03_071.a-dcx_axpexe
|
