Updated: 24-SEP-2003 (Use your browsers' Reload button to ensure you're viewing the most recent version)
VAXMAIL02_062 MAIL Utility for OpenVMS VAX V6.2 ECO Summary
Copyright (c) Digital Equipment Corporation 1997, 1998. All rights reserved.
PRODUCT: DIGITAL OpenVMS VAX
Modification Date: 08-JUL-98
Modification Type: Documentation: Technical Update:
Added information regarding a
fix for duplicate key on copied messages
COMPONENT: MAIL
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: VAXMAIL02_062
ECO Kits Superseded by This ECO Kit: VAXMAIL01_062
ECO Kit Approximate Size: 612 Blocks
Kit Applies To: OpenVMS VAX V6.2
System/Cluster Reboot Necessary: No
Installation Rating: 1 - To be installed on all systems running
the listed version(s) of OpenVMS.
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 V6.2. This kit addresses the
following problems:
Problems addressed in VAXMAIL02_062:
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 An SSRVEXCEPT was caused by an access violation in MAILSHRP.
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 A problem results when copying mail messages from a sequential mail
file into an indexed mail file. This problem occurs with the
following scenario:
From within MAIL, a sequential mail file that contains
small (less than 3 blocks) and large (greater than 3 blocks)
mail messages is opened. The messages are selected and then
copied into a folder in an indexed mail file. After reading
and deleting a large message, the body of a following small
message is lost. The header is there, but the body is gone.
This problem with bodies of emails being lost occurs when the
following conditions are true:
1. There are at least two emails in the sequential mail file
that were created in the same minute.
2. The emails are copied to an ISAM mailfile.
3. The order of the emails in the sequential mail file is
such that the first email results in an external EMAIL
file being created (MAIL$*.MAI) and the second email
results in the entire message being saving in the mail
file (MAIL.MAI).
4. The email that results in the external EMAIL file is deleted.
5. The body of the remaining email is now lost.
The following steps can be used to reproduce the behavior:
$ MAIL
MAIL> set file seq_mail_file.mai ! The sequential mail file
MAIL> copy/all test test.mai ! Copy all messages from
! seq. mail file into folder
! test in indexed test.mai.
! (Two messages were copied,
! one large and one small.)
! (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 ! Make sure it gets deleted.
MAIL> EXIT
$ MAIL
MAIL> set file test.mai
The body of the second mail mesage will now be gone.
Problems addressed in VAXMAIL01_062:
o In the event of an error opening or reading SYSUAF.DAT, and a
subsequent continuation or unwind request, the protected
image's condition handler must place the condition value in the
mechanism array. If this does not occur, SIGNAL returns an
undefined value, the error does not get passed back to the user
mode code, and MAIL attempts to continue.
o One of the privileged code condition handlers expects the
address of the privileged context block in the enable vector
when it is invoked. It then attempts to store the signal
arguments at an offset within that context block. However,
under certain circumstances, the address of the privileged
context is zero when a UAF record locked condition is being
handled. The ACCVIO occurs because the offset for the signal
arguments within the context block is invalid.
o When calling MAIL$MAILFILE_PURGE_WASTE from a detached process,
the image was aborting with a LIB$_NOCLI message.
o Programs using callable MAIL routines from AST level code will
often receive ACCVIOs when RMS errors are signaled.
o Strange <NULL> characters are displayed in DIR command when a
user has no mail messages and no folders.
o A program using callable mail routine MAIL$USER_GET_INFO will
receive an EXEC mode access violation and the process is
deleted. A non-fatal SSRVEXCEPTN bugcheck is generated.
o A program using callable mail routine MAIL$USER_GET_INFO will
receive an EXEC mode access violation and the process is
deleted when the MAIL$_USER_NEXT item code is used before
MAIL$_USER_FIRST or MAIL$_USER_USERNAME. A non-fatal
SSRVEXCEPTN bugcheck is generated.
o Two SSRVEXCEPTION crashes in MAILSHRP when running LBN disk I/O
or UETP, in the context of the image DTWM.
o When using callable mail to send messages, it will eventually
run out of virtual memory. There is a memory leak in both
MAIL$SEND_BEGIN and MAIL$SEND_END routines.
o Defining a Logical for Username in the following manner
produces Forward Loop in MAIL.
$DEFINE/TRANSLATION_ATTRIB=TERMINAL name node::name
eg.
$ define/tran=terminal system quebit::system
MAIL> send
To: system
%MAIL-E-FORWLOOP, infinite forwarding detected sending to user netaly
o The TO line in a received message can become so skewed that
passwords for remote distribution lists may be visible in a
received message.
o When sending mail to a REMOTE and LOCAL user of the same name,
and the send to the REMOTE recipient-name fails, the mail
message is NOT sent to the LOCAL recipient-name either.
However, other recipient names listed receive the mail.
o When a mail message is sent and the TO: field incorporates a
set of quotes, and the TO: field/addressee is incorrect, there
is no error message returned.
o A VAX C application that uses the MAIL$ callable API runs for
varied lengths of time, then crashes due to insufficient
virtual memory.
o When using MAIL$MESSAGE_COPY to copy messages from one mail
file to another version of the same file, the messages are not
copied to the target file, but rather are copied to the source
file.
o Depending on DECnet Plus namespace configuration, appearance of
MAIL> prompt can be very slow.
RELATED ARTICLES:
Detailed articles describing the problems listed above may exist in
the OPENVMS database. To view these articles, open the appropriate
product database and perform a query using either of the following
search strings: 'VAXMAIL02_062' or 'VAXMAIL'.
ECO KIT ORDERING INSTRUCTIONS:
If after an evaluation you wish to obtain this kit, request it
electronically using the appropriate Advanced Electronic Services
(AES) Service Tool. If you are not familiar with how to request
kits electronically, open the DIA, WIS or DSNLINK database and
review the article entitled:
[AES] How To Electronically Request ECO Kits Using Service Tools
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.
==========================================================================
| Table of Kit Image Information |
+----------------------------+----------+-----------------+--------------+
| | Overall | Image File | Image Link |
| Image Name | Checksum | Identification | Date/Time |
+----------------------------+----------+-----------------+--------------+
| MAIL.EXE |%X79B5B3FB| X-13 | 11-JUN-1998 |
| | | 09:05:44.77 |
+----------------------------+----------+-----------------+--------------+
| MAILSHR.EXE |%X3F6757BE| X-7 | 11-JUN-1998 |
| | | 09:03:43.77 |
+----------------------------+----------+-----------------+--------------+
| MAILSHRP.EXE |%X7016044E| X-7 | 11-JUN-1998 |
| | | 09:03:38.44 |
+----------------------------+----------+-----------------+--------------+
| MAIL_SERVER.EXE |%XADBD60A1| X-11 | 11-JUN-1998 |
| | | 09:05:49.66 |
+----------------------------+----------+-----------------+--------------+
|
