SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
.
} what's new
.
} contract access
.
} browse patch tree
.
} search patches
.
} join mailing list
.
} feedback
.
patches by topic
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
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.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

alpmail03_071.README
alpmail03_071.CHKSUM
alpmail03_071.CVRLET_TXT
alpmail03_071.a-dcx_axpexe

privacy and legal statement