| » contact hp |
search: |  | more options |
| Supportall of hp US

|  | HP Services Software Patches |

» | 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
HP Services Software Patches - vaxmail06_061
    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.

    *OpenVMS] VAXMAIL06_061 VAX V5.5-V6.1 Mail/Process Audit ECO Summary

    Copyright (c) Digital Equipment Corporation 1995.  All rights reserved.

    PRODUCT:    OpenVMS VAX

    COMPONENT:  VAXmail Utility
                Process Auditing

    SOURCE:     Digital Equipment Corporation

    ECO INFORMATION:

         ECO Kit Name:  VAXMAIL06_061
         ECO Kits Superseded by This ECO Kit:  VAXMAIL05_061
                                               VAXMAIL04_061
                                               VAXMAIL03_061
                                               VAXMAIL02_061   (CSCPAT_1171 V1.0)
                                               VAXAUDI01_061
                                               VAXMAIL01_061
                                               VAXMAIL02_060   (CSCPAT_1170 V1.0)
                                               VAXAUDI01_060
                                               VAXMAIL01_060
                                               VAXMAIL06_U2055 (CSCPAT_1123 V1.2)
                                               VAXMAIL05_U2055
                                               VAXMAIL03_U2055
                                               MAIL$03_U1055
                                               MAIL$01_U1055

         ECO Kit Approximate Size:  1990 Blocks
                        Saveset A -  126 Blocks
                        Saveset B -  450 Blocks
                        Saveset C -  666 Blocks
                        Saveset D -  684 Blocks
                     Cover Letter -   64 Blocks

         Kit Applies To:  OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF,
                                      V6.0, V6.1
         System/Cluster Reboot Necessary:  No

         Installation Rating:  3 - To be installed on all systems running
                                   the listed versions of OpenVMS which
                                   are experiencing the problems described.

         NOTE:  In order to receive the full fixes listed in this kit,
                the following remedial kits also need to be installed:

                     None.

    ECO KIT SUMMARY:

    An ECO kit exists for the VAXmail Utility on OpenVMS VAX V5.5-2
    through V6.1 and for Process Auditing on OpenVMS VAX V6.0 through
    V6.1.  This kit addresses the problems described below.  The
    descriptions are broken down for the different versions of OpenVMS
    VAX.  Therefore, if a problem is fixed in both OpenVMS VAX V5.5-2 and
    OpenVMS VAX V6.1, it will be listed twice in the problem descriptions
    below.

    Problems Addressed in the VAXMAIL06_061 Kit for OpenVMS VAX V5.5,
    V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, and V6.1:

      o  This kit is being issued to update the SECURESHRP.EXE image to
         avoid installation conflicts with the VAXLOAD01_070 kit which
         also contains the SECURESHRP.EXE image.  There are no new
         fixes in this kit.  If you have installed the VAXMAIL05_061
         kit you do not need to install this kit.

    Problems Addressed in the VAXMAIL05_061 Kit for OpenVMS VAX V5.5,
    V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1:

      o  In the MAIL user interface, if a user asks for a directory of a
         nonexistent folder, the signaled message is:

              %MAIL-E-NOTEXIST, folder !AS does not exist

         The actual message should contain the name of the nonexistent
         folder rather than !AS.

         This problem is corrected in OpenVMS VAX V6.2.

    Problems Addressed in the VAXMAIL05_061 Kit for OpenVMS VAX V6.1:

      o  The SECURESHRP.EXE image is common to the VAXMAIL04_061 and
         VAXLOAD01_061 kit.  In order to eliminate a possible image
         regression problem, this kit updates the SECURESHRP.EXE image to
         the same level as the image in the VAXLOAD01_061 kit.

    Problems Addressed in the VAXMAIL04_061 Kit for OpenVMS VAX V5.5, V5.5-1,
    V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1:

      o  System status code rather than mail status code is reported.

      o  Applications that use the MAIL$ callable mail API can exhaust
         virtual memory.  This may cause system crashes due to insufficient
         virtual memory.

      o  The $GETUAI and $SETUAI services may return RMS record locked
         errors during attempts to access the SYSUAF.  These errors
         occur if the caller uses these services with a context block
         supplied (which keeps the SYSUAF open), and encounters a
         locked record for other than the initial call.  This happens
         because the RMS structures are not correctly re-initialized
         after the initial call.

    Problems Addressed in the VAXMAIL03_061 Kit for OpenVMS VAX V5.5,
    V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF, V6.0, V6.1:

      o  If one process is writing messages to a mail folder and another
         process is updating message headers in the same mail folder
         (as in a mail delete operation), the process that is updating
         message headers may access violate.  This may occur while using
         either callable MAIL or 'MAIL' commands in a DCL command procedure.

      o  The following error message may occur while reading mail:

         %MAIL-E-OPENIN,
         error opening DEV:[USER.MAIL]MAIL$1234567800050098.MAI; as input
         -RMS-E-FNF, file not found

         The mail message does exist but has a filename that is one
         digit different than the filename in the error message.

    Problems Addressed in the VAXMAIL03_061 Kit for OpenVMS VAX V6.1:

      o  If a mail TO: address that is a local recipient's address
         is called and it references an alternate transport image
         that is not installed, MAIL appears to hang.

         In order for this hang to occur the UNWIND has to be
         initiated once the call to LIB$FIND_IMAGE_SYMBOL fails.
         This can be done in any of the following ways:

              1)  MAIL$_NOSIGNAL must be included in the input
                  item list for the call to MAIL$SEND_ADD_ADDRESS.
                  This causes MAIL$HANDLER to call $UNWIND.

              2)  LIB$SIG_TO_RET (which calls $UNWIND) is either enabled
                  as a condition handler in the calling program or is
                  called by the calling program's condition handler.

              3)  The caller calls the $UNWIND service on its own.

      o  If mail is sent from one user to another user on the same CPU or
         on the same cluster, both the broadcasted new mail notification
         message and the FROM: line contain only the username.  The
         message does not include the user's node name.

    Problems Addressed in the VAXMAIL02_061 Kit for OpenVMS VAX V6.1:

      o  VAXAUDI01_061 and VAXMAIL01_061 contain different versions
         of MAILSHRP.EXE.  If a user installs VAXAUDI01_061 and then
         installs  VAXMAIL01_061 kit, image regression will occur.
         This kit (VAXMAIL02_061) combines VAXMAIL01_061 and
         VAXAUDI01_061 with the latest version of MAILSHRP.EXE to
         prevent this regression.

    Problems Addressed in the VAXAUDI01_061 Kit for OpenVMS VAX V6.1:

      o  This kit corrects a security problem involving process auditing.

    Problems Addressed in the VAXMAIL01_061 Kit for OpenVMS VAX V6.1:

      o  The FROM field, and the mail notification message broadcast to a
         user's terminal, uses the DECnet phase 5 full name in the node
         specification instead of the cluster alias or simple name.

      o  If a file containing a message is sent repeatedly to a recipient
         with a logical name in the disk portion of the mail file
         directory specification (the SYSTEM account, for example, using
         SYS$SYSROOT:[SYSMGR]MAIL.MAI), the sends will eventually fail
         with the following error when the MAIL image is not restarted:

              %MAIL-E-SENDERR, error sending to user SYSTEM
              -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI;
                               as output
              -SYSTEM-F-IVDEVNAM, invalid device name

      o  OpenVMS VAX V6.1 MAIL does not preserve the pre-OpenVMS VAX V6.1
         avoidance of DECnet connections when sending inter-cluster MAIL.

      o  If a user enters an address in the form of IN%"FRED@BC (foreign
         protocol, mismatched quoted address), LIB-F-SYNTAXERR is signaled
         and the user is returned to DCL.  Other kinds of errors generated
         by an address in the TO: line will either return the user to the
         MAIL> prompt, or ask the user if the mail should be sent anyway.

      o  Sending mail to a user from more than 1 source within a 10
         millisecond interval returns the following errors:

              %MAIL-E-SENDERR, error sending to username USERNAME
              -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1
              -RMS-F-DUP, duplicate key detected (DUP not set)

      o  An access violation (ACCVIO) occurs within MAIL$MESSAGE_SELECT
         when a mail message is selected from a mail folder and two
         processes are simultaneously accessing that same mail folder.

    Problems Addressed in the VAXMAIL02_060 Kit for OpenVMS VAX V6.0:

      o  VAXAUDI01_060 and VAXMAIL01_060 contain different versions of
         MAILSHRP.EXE.  If a user installs VAXAUDI01_060 and then
         installs VAXMAIL01_060, image regression will occur.  This kit
         combines VAXMAIL01_060 and VAXAUDI01_060 with the latest version
         of MAILSHRP.EXE to prevent this regression.

    Problems Addressed in the VAXAUDI01_060 Kit for OpenVMS VAX V6.0:

      o  This kit corrects a security problem involving process auditing.

    Problems Addressed in the VAXMAIL01_060 Kit for OpenVMS VAX V6.0:

      o  MAIL.EXE will honor a process enabled EXQUOTA privilege for
         the 'SEND/NOEDIT' command only if it is issued after a
         'SEND/EDIT' command.

      o  When a mail file is COMPRESSed and the COMPRESS fails, the
         MAIL_xxx_COMPRESS.TMP file will be left in the MAIL directory.
         This prevents that process from being able to successfully
         re-attempt the COMPRESS until the MAIL_xxx_COMPRESS.TMP file is
         manually unprotected and deleted.

      o  If a message is moved or filed from one MAIL folder to another
         and the user does not SELECT the new folder and READ the
         message, an attempt to EXTRACT that message will fail.  However,
         the user is not notified of this failure.

      o  After a SET MAIL_DIRECTORY [.NEW_DIR] is issued by the user, some
         MAIL commands may fail.  The failure depends on the order in which
         the MAIL commands are issued.  For example,

         - DIR/FOLDER fails on a file open error attempting to open
           MAIL.MAI in the old directory

         - READ fails on a file open error attempting to open a message
           file in the old directory

         - SHOW FILE (or SHOW ALL) reports the location of the MAIL
           file and the name of the MAIL directory incorrectly

         - COMPRESS fails trying to open a MAIL file in the old
           directory

      o  If a user does not provide either a mail file name or a default
         mail file name in the call to MAIL$MESSAGE_COPY, MAILSHR
         creates SYS$LOGIN:MAIL.MAI and copies the message there.

      o  If an error occurs during processing of a call to
         MAIL$SEND_MESSAGE, the calling program may hang.  One
         example of an error would be if an attempt is made to
         send to an address containing an invalid device name.

      o  If requested, the routines MAIL$USER_BEGIN and MAIL$USER_GET_INFO
         will return the length of an output item list entry to a
         user-supplied address.  The two routines MAIL$$USER_RET_INFO_OLD
         and MAIL$$USER_RET_INFO_NEW actually return the field length
         which may cause information in fields adjacent to the user-supplied
         address to be lost.

      o  If a file containing a message is sent repeatedly to a recipient
         with a logical name in the disk portion of the mail file
         directory specification (the SYSTEM account, for example, using
         SYS$SYSROOT:[SYSMGR]MAIL.MAI), the sends will eventually fail
         with the following error when the MAIL image is not restarted:

              %MAIL-E-SENDERR, error sending to user SYSTEM
              -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI;
                               as output
              -SYSTEM-F-IVDEVNAM, invalid device name

      o  If a user enters an address in the form of IN%"FRED@BC (foreign
         protocol, mismatched quoted address), LIB-F-SYNTAXERR is signaled
         and the user is returned to DCL.  Other kinds of errors generated
         by an address in the TO: line will either return the user to the
         MAIL> prompt, or ask the user if the mail should be sent anyway.

      o  Sending mail to a user from more than one source within a 10
         millisecond interval returns the following errors:

            %MAIL-E-SENDERR, error sending to username USERNAME
            -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1
            -RMS-F-DUP, duplicate key detected (DUP not set)

      o  If the node name portion of an address is a logical name,  MAIL
         displays the logical translation in the TO: and CC: lines (if
         present).

      o  An access violation (ACCVIO) occurs within MAIL$MESSAGE_SELECT
         when a mail message is selected from a mail folder and two processes
         are simultaneously accessing that same mail folder.

      o  DDIF files are not consistently characterized by MAIL.EXE.

         For example, when DECW$EXAMPLES:CLOCK.DDIF is sent, with or
         without the /FOREIGN switch, the receiver does not see any
         message indicating that the file must be treated differently from
         other MAIL messages when extracted.  When foreign files are
         "read", the following message should be displayed:

            %MAIL-E-FORMSG, you cannot read this foreign format message
            Use the EXTRACT command to copy the message to an external file

         While MAIL does send CLOCK.DDIF correctly, the absence of this
         message may lead the user to believe it is an empty file, a
         message consisting of nothing but the message header, and it
         could be mistakenly deleted.

         If the MAIL command DIR/FULL is issued, the message containing
         CLOCK.DDIF has "Foreign" listed as a message attribute.

         However, some other .DDIF files, as well as other files sent with
         the /FOREIGN switch, do cause the %MAIL-E-FORMSG message to be
         displayed.

    Problems Addressed in the VAXMAIL06_U2055 Kit for OpenVMS VAX V5.5,
    V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF:

      o  Sending mail to a user from more than 1 source within a 10
         millisecond interval returns the following errors:

              %MAIL-E-SENDERR, error sending to username USERNAME
              -MAIL-W-WRITERR, error writing DISK:[USER_DIRECTORY]MAIL.MAI;1
              -RMS-F-DUP, duplicate key detected (DUP not set)

      o  An Access Violation may occur within MAIL$MESSAGE_SELECT
         when two processes are accessing the same mail folder if
         a user attempts to select a message from the folder.

      o  When a local user's disk quota has been exceeded, the DEC TCP/IP
         SMTP symbiont ceases delivery of mail.

    Problems Addressed in the VAXMAIL05_U2055 Kit for OpenVMS VAX V5.5,
    V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF:

      o  MAIL hangs when attempting to send mail to two users on a remote
         node when one has his mail forwarded to the other.

      o  The current message number in MAIL is getting set incorrectly, or
         to nonexistent message numbers as a result of BACKUP or NEXT
         commands which result in a "No more messages" error.

      o  Access Violations may occur when attempts are made to mail
         binary files.  This may also occur when files with very large
         record sizes are sent.

      o  Copying large mail messages to a drawer/directory accessible by
         an ACL will cause a protection failure when the attempt is made
         to create the external message body file.

      o  RMS$_DUP errors occur when local messages from STREAM files
         with an odd length of 3 blocks plus 465 to 511 bytes are sent.

      o  Attempts to MAIL a DDIF or DTIF compound document result in
         a send of the base file if the unsupported /FOREIGN qualifier
         is used.  However, none of the file's inclusions are sent.

      o  Disk volume used by the MAIL_SERVER process contains a large
         number of lost (not pointed to by any directory) MAIL.TXT files.

      o  User-written applications need SYSPRV to connect to a remote
         node.

      o  A program which invokes callable mail works without extraordinary
         privileges, but that same program, when invoked with SYSPRV set
         in the process privilege mask, will fail with an insufficient
         privilege message.

      o  When TPU is the selected editor (either explicitly or by default)
         and the user attempts any MAIL command which invokes the editor
         on a terminal which is not an ANSI-compliant CRT (such as a
         hard-copy terminal), TPU exits with TPU$_NONANSICRT.  However,
         the message is discarded.  The user sees the next MAIL> prompt
         without any indication that a problem exists.

      o  When a user enters the DCL command '$ MAIL FILENAME' without
         specifying an addressee,  MAIL prompts for the addressee with
         "To:".  If the user merely hits RETURN without supplying an
         addressee, MAIL exits without comment and with success status.

      o  The description of how the logical name MAIL$EDIT is used in
         MAIL is incorrect in MAILEDIT.COM, which is the example file
         of a command procedure suitable for assigning to MAIL$EDIT.

      o  MAIL cannot handle ACL protected MAIL.MAI files.  Attempting to
         COMPRESS a MAIL file, where access to that file and parent
         directory are granted via an identifier ACE on a RESOURCE owned
         by the user, fails due to privilege violation while attempting to
         rename the new file to MAIL.MAI.

      o  If a received mail message contains lines longer than the
         terminal's width (either as part of the message header, or as
         part of the message text), the message display will scroll the
         top few lines off the screen before prompting "Press return for
         more".

      o  A user program will try to disable all error signaling by turning
         on the "NOSIGNAL" option in the call to MAILSHR after discovering
         that error messages cannot be trapped with an error handler.  If
         the user then attempts to compress a MAIL file, the compress
         operation aborts just after the .TMP file is created.

      o  User A does a SET FORWARD PSI%mumble::UserC.  User B sends mail
         to PSI%mumble::UserA.  The mail happens to be a STREAM_LF file or
         a file that is not a "normal" text file.  During the forwarding
         process, the STREAM_LF format is lost and the mail message
         becomes unreadable by User C.

      o  Selecting a folder after a SEARCH command causes the search
         string to be lost.

      o  A user-written program that calls MAILSHR's callable interface
         to compress a MAIL file cannot reliably detect whether the
         compress fails.  While MAILSHR displays error strings to the
         user's terminal, it does not signal anything of consequence to
         the user's program.  Furthermore, the routine status returned
         by MAILSHR is incorrect.

      o  User says "DELETE n-m", where the highest selected message number
         is less than "n".  This causes the deletion of all the messages
         in the currently selected folder, even though all the messages
         are outside the selected deletion range.

      o  While attempting to send mail, the sender sees a "Signal with
         no arguments" error.  This occurs when mail is sent to a "broken"
         mail file.

      o  In some instances, a system crash may occur because 'NEXT_ITEM'
         is not initialized in the appropriate code.

      o  Mail occasionally neglects to display the first line of a mail
         message; however, the line is there, and will be displayed on
         subsequent attempts to display the message.

      o  Even though explicit access is ignored by Mail, when an addressee
         specification has explicit access  (e.g., To: REMOTE"USER
         CORRECTPASSWORD"::USER2), the specified password is visible at
         all destinations.

      o  When DECW$EXAMPLES:CLOCK.DDIF is sent, with or without the
         /FOREIGN switch, the receiver does not see any message indicating
         that the file must be treated differently from other MAIL
         messages when extracted.  When foreign files are "read", the
         following message is displayed:

              %MAIL-E-FORMSG, you cannot read this foreign format message
              Use the EXTRACT command to copy the message to an external file

         While MAIL does send CLOCK.DDIF correctly, the absence of this
         "flag" may lead the user to believe it is an empty file, a
         message consisting of nothing but the message header, and it
         could be mistakenly deleted.  If the MAIL command DIR/FULL is
         issued, the message containing CLOCK.DDIF has "Foreign" listed as
         a message attribute.  Some other .DDIF files, as well as other
         files sent with the /FOREIGN  switch, do cause the %MAIL-E-FORMSG
         message to be displayed.

      o  If the node name portion of an address is a logical name,  MAIL
         displays the logical translation in the TO: and CC: lines (if
         present).

      o  Some MAIL commands fail after SET MAIL_DIRECTORY [.NEW_DIR] is
         issued by the user.  Depending on the order of MAIL commands
         issued, the following may occur:

           -  DIR/FOLDER fails on a file open error attempting to open
              MAIL.MAI in the old directory

           -  READ fails on a file open error attempting to open a
              message file in the old directory

           -  SHOW FILE (or SHOW ALL) reports the location of the MAIL
              file, and the name of the MAIL directory incorrectly

           -  COMPRESS fails trying to open a MAIL file in the old
              directory

      o  MAIL.EXE will honor a process's enabled EXQUOTA privilege for
         SEND/NOEDIT, only if the SEND/NOEDIT command is issued after a
         SEND/EDIT command.

      o  A user attempts to COMPRESS his MAIL file and the COMPRESS fails.
         The failure may occur due to valid or invalid problem.  This
         leaves a MAIL_xxx_COMPRESS.TMP file in the user's MAIL directory,
         which prevents that process from being able to successfully
         re-attempt the COMPRESS until the user manually re-sets the file
         protection and deletes the .TMP file.

      o  If a message is moved or filed from one MAIL folder to another,
         and the user attempts to EXTRACT that message without first
         SELECTing the new folder then READing the message, the file
         create fails but MAIL does not notify the user.

      o  If a user does not provide either a mail file name or a default
         mail file name in the call to MAIL$MESSAGE_COPY, MAILSHR creates
         SYS$LOGIN:MAIL.MAI, and copies the message there.

      o  Two user routines, MAIL$USER_BEGIN and MAIL$USER_GET_INFO, will
         return the length of an output item list entry to a user-supplied
         address if requested.  The two routines MAIL$$USER_RET_INFO_OLD
         and MAIL$$USER_RET_INFO_NEW actually return the length.  The MAIL
         documentation states that the return length address item in the
         output item list is "a longword containing the user-supplied
         address of a word in which the routine writes the actual length
         in bytes of the information it returned."  MAIL$$USER_RET_INFO_OLD
         and MAIL$$USER_RET_INFO_NEW are writing a longword into the
         user-supplied address of a word, overwriting any adjacent field(s).

      o  A user program hangs on a call to MAIL$SEND_MESSAGE when
         attempting to send to an address containing an invalid device.
         Hangs might also occur due to other errors signaled by the
         receiving system.

      o  If a file containing a message is sent repeatedly to a recipient
         with a logical name in the disk portion of the mail file
         directory specification (the SYSTEM  account, for example, using
         SYS$SYSROOT:[SYSMGR] MAIL.MAI), the sends will eventually fail
         with the following message when the MAIL image is not restarted:

              %MAIL-E-SENDERR, error sending to user SYSTEM
               -MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL.MAI;
                                as output
               -SYSTEM-F-IVDEVNAM, invalid device name

    Problems Addressed in the VAXMAIL03_U2055 Kit for OpenVMS VAX V5.5,
    V5.5-1, V5.5-2, V5.5-2H4, V5.5-2HF:

      o  A user application using callable mail establishes a condition
         handler which unwinds the stack when Mail signals an unreachable
         node (and presumably, other errors as well).  This results in the
         associated mailboxes not being deassigned, and the application
         uses all the BYTLM quota.

    Problems Addressed in the MAIL$03_U1055 Kit for OpenVMS VAX V5.5,
    V5.5-1:

      o  Disk volume used by the MAIL_SERVER process contains a large
         number of lost (not pointed to by any directory) MAIL.TXT files.

    Problems Addressed in the MAIL$01_U1055 Kit for OpenVMS VAX V5.5,
    V5.5-1:

      o  EXTRACT/FOREIGN or EXTRACTing a foreign message results in a
         file allowing all access with its protections set to W:RWED.

    INSTALLATION NOTES:

    The system/cluster does not need to be rebooted after this kit is
    installed.  However, MAIL should be shutdown and restarted in order
    for all kit changes to take effect.
Files on this server are as follows:
    »vaxmail06_061.README
    »vaxmail06_061.CHKSUM
    »vaxmail06_061.CVRLET_TXT
    »vaxmail06_061.a-dcx_vaxexe
    »vaxmail06_061.b-dcx_vaxexe
    »vaxmail06_061.c-dcx_vaxexe
    »vaxmail06_061.d-dcx_vaxexe

privacy statement | using this site means you accept its terms |
© 1994-2002 Hewlett-Packard Company