OpenVMS ALPMAIL03_062 MAIL Utility Alpha V6.2 ECO Summary
TITLE: OpenVMS ALPMAIL03_062 MAIL Utility Alpha V6.2 ECO Summary
Modification Date: 24-FEB-1999
Modification Type: Documentation: Reboot Information Added
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 1998. All rights reserved.
PRODUCT: DIGITAL OpenVMS Alpha
COMPONENT: MAIL
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: ALPMAIL03_062
ECO Kits Superseded by This ECO Kit: ALPMAIL02_062
ALPMAIL01_062
ECO Kit Approximate Size: 1462 Blocks
Saveset A: 1440 Blocks
Kit Applies To: OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3
System/Cluster Reboot Necessary: No
NOTE: The KITINSTAL.COM indicates that the system on which this
kit is installed needs to be rebooted. It *DOES NOT* have
to be rebooted. Engineering has been notified of this
issue.
Installation Rating: 1 : To be installed by all customers.
KIT DEPENDENCIES:
The following remedial kit(s) must be installed BEFORE
installation of this, or any required 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 V6.2. This kit addresses the
following problems:
Problems Addressed in ALPMAIL03_062:
o A SSRVEXCEPT error occurred due to an access violation occurred
in MAILSHR after a locked UAF record signal was processed by a
condition handler.
o More MAILSHRP SSRVEXCEPT crashes occurred. The address of the
privileged context was zero, causing any downstream access to
any offset within the context 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.
From within MAIL, a sequential mail file was 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 was 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 are created
within 1 minute.
2. Emails are copied to an indexed sequential access mode
(ISAM) mail file.
3. Order of emails in the sequential mail file are 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.
Problems Addressed in ALPMAIL02_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.
Problems Addressed in ALPMAIL01_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 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.
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.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
alpmail03_062.README
alpmail03_062.CHKSUM
alpmail03_062.CVRLET_TXT
alpmail03_062.a-dcx_axpexe
|
