Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp


more options
 
hp.com home
End of Jump to page title
HP Services Software Patches
Jump to content


» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

patches by topic
» DOS
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

connection tools
» nameserver lookup
» traceroute
» ping


Find Support Information and Customer Communities for Presario.
Content starts here
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. 
Files on this server are as follows:
»vaxmail03_071.README
»vaxmail03_071.CHKSUM
»vaxmail03_071.CVRLET_TXT
»vaxmail03_071.a-dcx_vaxexe
privacy statement using this site means you accept its terms