Conference virke::mrmemo

.0> Is there any problem if the user (on the ALL-IN-1 or MEMO side)
.0> has in his/her surname (or ALL-IN-1 username) an spanish MCS 
.0> character?.
.0> Let say, "user A" is an ALL-IN-1 user and has a MCS character
.0> inside his ALL-IN-1 username. He sends a message to a MEMO user
.0> ("user B")through MRMEMO. Can "user B" get "user's A" return 
.0> address correctly or the MCS character was changed at any stage?.

    Since MEMO runs in an IBM world, it uses EBCDIC instead of ASCII/MCS.
    MRMEMO converts between the character sets through a translation table.
    The translation table is selected by the MRMMAN commande DEFINE
    /TRANSLATION_TABLE. Note that the translation table is actually a
    component of the SNA/Gateway software. See appendix "A. EBCDIC/DMCS 
    Translation Tables" in the manual "DECnet/SNA VMS Gateway Management" for 
    information about how to build your own translation table.

    For the text part of messages, users can usually live with an approximate
    character conversion (e.g. � is converted to n and � to i). When the
    characters being converted are part of the address, the situation becomes
    different. Then it is necessary to make sure that the original MCS address
    string is restored after conversion from MCS to EBCDIC and then back to
    MCS again. 

    So, you do have a potential problem with "exotic" MCS characters in 
    addresses since each character must be mapped to an EBCDIC character code
    before being sent to MEMO. The question back to the customer is: 

    "Can your MEMO terminals display all characters in your ALL-IN-1 user
    names?"

    If the answer to this question is yes, there is probably no problem.
    (There could still be a problem if there is some character that MEMO does
    not accept in address strings.) 

    If the answer is no, there could be a problem depending on how DDS is used 
    (I assume that you will use DDS since MAILbus Directory Synchronizer was 
    mentioned). By registering all MR (ALL-IN-1) users in DDS (or at least the 
    ones with "strange" characters in their addresses), you can avoid exposing 
    the MR addresses to MEMO. Define MEMO format names for the DDS records
    (using SNLOCATION + SNUSERNAME) and use MRMEMO address translation 
    (FORMAT=MEMO). This will make the MEMO user see the SNLOCATION +
    SNUSERNAME address when a message is received. 

    Anders

    PS
      If the customer is going to communicate with other systems too in 
      the future (e.g. X.400), it might be a good idea to stick to US
      ASCII to avoid headakes.

    	Thanks Anders,


>   If the answer is no, there could be a problem depending on how DDS is used 
>   (I assume that you will use DDS since MAILbus Directory Synchronizer was 
>   mentioned). By registering all MR (ALL-IN-1) users in DDS (or at least the 
>   ones with "strange" characters in their addresses), you can avoid exposing 
>   the MR addresses to MEMO. Define MEMO format names for the DDS records
>   (using SNLOCATION + SNUSERNAME) and use MRMEMO address translation 
>   (FORMAT=MEMO). This will make the MEMO user see the SNLOCATION +
>   SNUSERNAME address when a message is received. 

	Yes, DDS will be used and MAILbus Directory Synchronizer could be
the solution for new user register and automatic maintenance.
	The main point here is characters like "�" in addresses. And I'm
glad to hear that can be solved using DDS.


>    PS
>     If the customer is going to communicate with other systems too in 
>     the future (e.g. X.400), it might be a good idea to stick to US
>     ASCII to avoid headakes.

	Yes, it might be, but customers around here are a little bit 
sensitive about not using their own alphabet. 
(Including myself, I must confess).

	Regards,

	Miguel Casta�o

    
>>    PS
>>     If the customer is going to communicate with other systems too in 
>>     the future (e.g. X.400), it might be a good idea to stick to US
>>     ASCII to avoid headakes.
>
>	Yes, it might be, but customers around here are a little bit 
>sensitive about not using their own alphabet. 
>(Including myself, I must confess).

    Of course you are, and so you should be. We have the same situation
    here (Sweden)
    
    The problem is that the X.400 standard (1984) does not allow the use of
    non-ASCII characters in ORadresses, so you simply can't put national
    characters in the PRIMARY Surname and Givenname fields in your DDS
    records if you want to communicate via MRX.
    
    So for the Primary Surname/Givenname you must use the Fallback ASCII
    characters, ie N for � etc. However, you can use the SECONDARY name fields
    to store the real name. This way you can always do the LOOKUPS with
    real national characters. 
    
    It is quite common when implementing Directory Synchronization that you
    have to create a post-processing routine that walks through the DDS
    database and "moves" strings with national characters in them from the
    primary to secondary and converts the primary field to its fallback
    representation. I've got a C program that does this for swedish
    characters (���). It utilizes the CMC$DDS interface from the
    Messaging Practice group.  The program is available for a few boxes of
    Rioja :-)  
    
    
    For clarity, the above are general statements and have nothing to do
    with what's supported in MRMEMO.