| Title: | VMS Mail Utility Suggestions and Discussions |
| Moderator: | EPS::VANDENHEUVEL |
| Created: | Thu Feb 13 1986 |
| Last Modified: | Tue Jun 03 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1943 |
| Total number of notes: | 8236 |
Dec C, OpenVMS for Alpha V7.1 A customer has reported a problem with MAIL$SEND_ADD_BODYPART after upgrading to OpenVMS V7.1. In particular, when you run the first example in the documention (Sending a file. Example 10-1 in the V6.0 doc set or Example 11-1 in the V7.1 doc set), you get an access violation. The access violation occurs on the line that reads resultspec[resultspeclen] = '\0'; which immediately follows a call to mail$send_add_bodypart. The problem is that the value returned in the variable RESULTSPECLEN is a very large number. Upon closer examination, one can see that the large number is due to the fact that only the low order word of this variable is being set by mail$send_add_bodypart. If there is some value other than 0 in the high order word, the resultant longword value is a huge number. Changing the declaration of the variable RESULTSPECLEN from a long to a short is one way to fix the problem. From the V6.0 documentation (OpenVMS Utility Routines Manual), section 10.6.2.1 Structure_of_an_Item_Descriptor_, in the table immediately following Figure 10-2, the Return Length address is defined as follows. . . . Return length address Depends on the type of item code specified as summarized below. ----------------------------------------------- item Code Use ------------------------------------------------ Input Not used; specify 0 Output Address of a LONGWORD that receives the length of the result. ------------------------------------------------ I don't have access to the 7.1 documentation, so I don't know if it reads the same or not. So, unless the 7.1 documentation has been changed to define the return length address as a word, plus the example has been modified accordingly, I think that there is a bug in this for V7.1. At the very least, it's a significant change from previous versions that will break a lot of existing code. I can qar/spr this if necessary. Please advise. Thanks, Jerry Henson U.S. CSC
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1931.1 | QAR it | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Feb 10 1997 16:26 | 0 |
| 1931.2 | done | CSC32::J_HENSON | Don't get even, get ahead! | Tue Feb 11 1997 09:11 | 12 |
>> <<< Note 1931.1 by XDELTA::HOFFMAN "Steve, OpenVMS Engineering" >>> >> -< QAR it >- I have qar'ed this as number 00760 in the evms-raven database. I don't know if this is the correct database to use or not, but there are so many, and we use so many confusing code words, I never know. I can qar to another database if needed. Just tell me which one to use. Jerry | |||||
| 1931.3 | Raven is the next (big) OpenVMS Release | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Feb 13 1997 16:56 | 17 |
The evms-raven database is the right spot for basic problem
reports -- Raven is the next large OpenVMS Alpha release, and
is presently under development.
--
Customer problems usually enter the system via IPMT, and the
IPMT gets transfered into the QAR system. (Critical customer
problems should use an IPMT, as it includes problem tracking
and escalation support.)
--
I've already tried getting the QAR database code-word morass
drained once, obviously without success...
| |||||
| 1931.4 | word returned by callable mail routines | STAR::CDONAT | Tue Feb 18 1997 16:13 | 33 | |
This is the reply the QAR is/will be closed with:
The issue of the description of a return length in the mail
documentation has been around for awhile, and to compound that,
mail has in many instances, been doing it wrong and/or inconsistently
- until now. The change, which now makes all of callable mail consistent,
brings callable mail into line with the definition of an item_list_3
type item list, which is what it uses. In the pre-v6.0 documentation,
the Introduction to Run-Time Library section of Volume 5A, starting
on page 2-14, is a good description of this type of item list. The
return length address is described on page 2-15, and is defined to be
the address of a word. On a VAX, the address (of anything) has always
been a stored in a longword; early ALPHA versions allowed this but are
slowly migrating to a more natural alignment. At any rate, I think this
is where the wording gets confusing. *Not* adhering to the definition
of an item_list_3 has generated QARs in the past; the user routine calls
were changed for V6.1, I believe, in response to a customer who had
passed to mail the address of a word. The User routines then were
returning longwords, and so overwriting data adjacent to the word-sized
field that was to hold the size returned by mail. Now all of the callable
mail routines return word-sized values, not just some of them.
I spoke to a writer today, and the documentation (and examples) will be
fixed for the next release.
Carey Donat
once and current MAIL maintainer
| |||||