Conference iosg::all-in-1_v30

	Darryl,

	If there is a strict procedure that they always use, you might be able
to hack up the validation check on all of the EM forms (e.g., EMHEAD), so that
what it validates against is the mucked-up name.  This, of course, would require
that you know in advance that they've entered the *real* name -- not the hacked
up name.  For instance, in your example, if all they do is take the first 8 
characters, that would be an easy check:

	FORM AUTO SELECT FOR OA$MAIL_ADD_ADDR WITH .USER:8 = TO ...

	If it's more than that, you're on your own!

	F

    Darryl,
    
    The first thing that came to my mind was: use "Alternate Surname".
    
    Then I tried to remember if there where any problems
    with 2.4, DDS and Alternate Surnames....
    I think it only works when you use the Search Mail Directory (SMD)
    from the Message header menu (GOLD M in To:-field), 
    not in the To:-field itself
    
    With 3.0 and DDS Prime you can do the trick:
    specify the fullblown surname as "Alternate Surname".
    Set DDS prime to 1. Works fine.
    
    I was surprised that when DDS prime set to 2, the 
    Alternate Surname is not found when you
    specify PART of the name in the TO:-field. Looks like a bug.
    
    Regards,
    
    Jan

    Jan,
    
    Well I think "bug" is a bit strong a word for why alternate surnames
    don't appear to work (but then I would wouldn't I?). As you say they
    work fine from SMD (and SOM) because we could write the code from
    scratch and we knew what the key was ...
    
    ... but then we tried to implement it in Mail Addressing and we came
    across a 904 line BLISS routine that is recursive, isn't documented
    doesn't work completely for any addressing format, tries to support
    too many incompatible addressing formats and is never entirely sure what
    the key is from one line to the next ... and of course Vid left at that
    point !!
    
    Have you tried it when you specify your ALL-IN-1 username as one of the
    alternate surnames?
    
    There now I feel better I'll go back to the padded cell (:==:)
    
    Regards,
    
    Andrew.D.Wicks 
                                   

    
    	Another case for customised mail receipt? I have been pushing
    	for this in a PFR.
    
    Regards,
    Paul

    Andrew.                                   
    
>    across a 904 line BLISS routine that is recursive, isn't documented
    
    Is this going to run on Alpha ?
    
    When I went to customer-mode (I read the manual),
    I couldn't find any updates in the Mail Management Guide
    with regards to OA$DDS_PRIME and/or the new breakpoints.
    Even STARS let me down.
    
    In note 268.1 is stated that OA$DDS_PRIME has nothing to do with the
    breakpoints. I thought breakpoints where only used when OA$DDS_PRIME
    is set to 1 ?
    
    I think customers running "2.4, DDS prime" are better
    of with "3.0, DDS second".
    
    By the way. I didn't mention our football victories
    because we are waiting for the real competition.
    Perhaps France on friday.
    
    Regards,
    
    Jan
    
    
    
    
    
    
    So the message to 2.4 / DDS prime users should be: 
    set oa$dds_prime to 1 when 
    
    

    

    Jan,
    
    I was told that the "Mail Management Guide" was in retirement mode or
    something like that and it doesn't appear to have been fully updated
    to include all the changes that were made to the mail code in v3.0
    
    As for the question about ALPHA well of course we don't talk futures
    here!
    
    Regards,
    
    Andrew.D.Wicks

	Re: .1

    >	FORM AUTO SELECT FOR OA$MAIL_ADD_ADDR WITH .USER:8 = TO ...

    Shouldn't that be more like:

	FORM AUTO SELECT FOR OA$MAIL_ADD_ADDR WITH .USER = TO:8 ...

    to compare the first 8 characters of what the user entered with the
    user name in the profile?

    Ben