|
I N T E R O F F I C E M E M O R A N D U M
Subject: No addressee problem, answer to your questions
I apologize for taking so long to get this back to you. The
weather, among other things, didn't help!
Attached are the questions which you send to me, which was from
when you entered our problem into the engineering database.
Let me know if you need any clarification!
Thanks.
DATE: Mon Mar 7, 1994 7:47 pm
SUBJECT:No addressee answers for Ramana
<<< IOSG::USER3:[NOTES$LIBRARY]ALL-IN-1.NOTE;3 >>>
-< ALL-IN-1 (tm) Support Conference >-
================================================================================
Note 3920.1 " NO ADDRESS PROBLEM & MH : HELP " 1 of 1
IOSG::MARSHALL "When you've got a widget, you don't" 21 lines 24-FEB-1994 19:32
-< Not a lot to go on >-
--------------------------------------------------------------------------------
Which version of ALL-IN-1? V3.0
Which patches? S030_016, S030_001, V030_001
Which version of VMS? V5.5-2
Which modules does the ELF customisation affect? EMEDHD, EMFWHD, EMHEAD
What does this customisation do? Bypasses ALL-IN-1 lookup in PROFILE.DAT &
NETWORK.DAT, and accesses internally developed Employee Locator file.
After creating the message, but before sending it, if they Read it (or SH), are
the addressees visible? NO
After they try and send it and get the error, if they then Read it (or SH) are
the addressees visible? NO
What is the message's STATUS after they try and send it? Has it been moved to
the shared areas (filename beginning OA$SHAR...) or is it still in their message
directory (filename beginning [.MSG]...) Still in [.MSG] directory.
This is not a new problem, therefore not caused by the V3.0 upgrade, as we have
had it since V2.3. The problem does not occur consistantly.
An additional note, the ALL-IN-1 system manager at the TCC site, stopped a
user's subprocess, who had reported this problem. The user was then able to
do a MH and add the address. Usually we have the user exit ALL-IN-1, then
get back in.
|
| Hi,
It sounds like this problem has nothing to do with sending the message; the
addressees were never there in the first place, the attempt to send is merely
reporting that fact.
So why should their application sometimes add addressees and sometimes not?
Without knowing what's in their application it's hard to say. They'll probably
have to pay $$$ to get a Digital consultant to go and debug their code!
But a few thoughts in the meantime...
Is it always the same addressees that fail, or is it random? If it's always the
same addressees, in what ways are those addresses different from ones that work?
If it's different addresses, is there any pattern at all to the addresses not
being added to the message?
After they enter an address and hit CR or TAB to invoke their customisation
(which I presume replaces the OA$MAIL_ADD_ADDR stuff on the forms?), does the
address appear to have been processed correctly (ie get recast into the
"parenthesis at position 37" format)? If so, it suggests their application is
doing its thing OK, but that it is returning the address to ALL-IN-1 in a format
that ALL-IN-1 can't subsequently understand, eg are there extra parentheses,
quotation marks, etc in the address?
If the address doesn't appear correctly on EMHEAD after they hit CR, it suggests
their application is failing to process it correctly. Only they can investigate
that end of things!
This is really something that can only be sorted out by someone with access to
and knowledge of their system and customisation. The first thing to do is work
out at exactly what point things are going wrong. A flow diagram of what
happens in an uncustomised system might help them:
User enters address in TO or CC field
|
v
/RSE_RECOG=OA$MAIL_ADD_ADDR ... invokes all the recognition and validation
| code for mail addresses (including DDS)
v
/SCROLL=,,,MAIL$SCL_FUNCTION causes the entered addresses to be stored
| in memory until the user leaves the form
v
If user exits form, the in-memory list is thrown away
If user closes form with CR, etc, the in-memory list is used to update the
addressee-list in the message's DAF record
Note the code also tries to be clever about addresses that are longer than the
75 character field - it keeps the full address in memory even though it can't
display it all.
If they can isolate the point in the above chain where the addresses are getting
lost, it will help in pin-pointing the problem.
Scott
|