Conference virke::mrmemo

.0> Does the DEFINE/REPLACE command work as expected in V2.0 ?

    Yes, it should. There are no known problems with this.

.0> From MEMO, one of the users wants to send a mail to an ALL-IN-1 user
.0> named "DE JONGE". As we ( no, not we, MEMO ...) had problems handling
.0> the space character, we used the command described in documentation,
.0> paragraph 4.6.20 :
.0>     
.0>    MRMMAN> DEFINE/REPLACE="__= ,..=@"
.0>     
.0> We then sent the mail to OAS.DE__JONGE..A1, but it didn't succeed. The
.0> return message we received said that the user DE__JONGE does not exist.
.0> It looks like the double underscore has not been translated to the
.0> space during the transition via MRMEMO.

    I hope you restarted the server between the DEFINE command and sending
    the mail since the DEFINEd server parameters are transferred to the
    server only when it is started.

    If you *did* restart the server, there's only one other reason I can
    think of right now:

    The EBCDIC/ASCII translation table does not translate the EBCDIC '_' to
    an ASCII '_'. MRMEMO will then fail to recognize '__'. This could be
    tested by sending a message from MEMO to e.g. an ALL-IN-1 user, put
    some underscores in the MEMO text and check how the message recevied
    in ALL-IN-1 looks. If there are underscores in the received ALL-IN-1
    message, the translation table is not the problem.

    A way to check if the translation works is to create a dummy mailbox
    (e.g. DUMMYBOX) and send a message from MEMO to OAS.DE__JONGE..DUMMYBOX
    and then check the USERID field in the NBS file (MR$NBS:MRnnnn), using
    the NBS file dumper MB$TOOLS:MRNBSDMP.

    Anders

.1> I hope you restarted the server between the DEFINE command and sending
.1> the mail since the DEFINEd server parameters are transferred to the
.1> server only when it is started.
.1> 
.1> If you *did* restart the server, there's only one other reason I can
.1> think of right now:

    The server had been restarted.
    
.1> The EBCDIC/ASCII translation table does not translate the EBCDIC '_' to
.1> an ASCII '_'. MRMEMO will then fail to recognize '__'. This could be
.1> tested by sending a message from MEMO to e.g. an ALL-IN-1 user, put
.1> some underscores in the MEMO text and check how the message recevied
.1> in ALL-IN-1 looks. If there are underscores in the received ALL-IN-1
.1> message, the translation table is not the problem.

    Tested : OK ( there are underscores in the mail ).
    
.1> A way to check if the translation works is to create a dummy mailbox
.1> (e.g. DUMMYBOX) and send a message from MEMO to OAS.DE__JONGE..DUMMYBOX
.1> and then check the USERID field in the NBS file (MR$NBS:MRnnnn), using
.1> the NBS file dumper MB$TOOLS:MRNBSDMP.

    The [TO] field, ATTR [USERID] contains "DE__JONGE.
    It looks like the double underscore is not translated.
    ( note : I can provide a copy of the output of MRNBSDMP if this could
    help )
    
    Do you think you could have a try on your site so that we could be sure
    the problem is local on our configuration ? Or maybe do you have other
    ideas over this problem ?
    
    Sincerely appreciating your help.
    
    
    - Philippe -
    

    

.2> The [TO] field, ATTR [USERID] contains "DE__JONGE.
.2> It looks like the double underscore is not translated.
.2> ( note : I can provide a copy of the output of MRNBSDMP if this could
.2> help )
    
.2> Do you think you could have a try on your site so that we could be sure
.2> the problem is local on our configuration ? Or maybe do you have other
.2> ideas over this problem ?
    
    I have tried it here on MRMEMO V2.0 and everything works fine.

    Next thing to check is that the replacement sequence really is correctly
    defined in the permanent database. Could you provide me with a dump
    of the misbehaving server's data base record?

        $ DUMP MRMEMO$DIR:MRMEMOPAR.DAT/RECORD=(START=n,COUNT=1)
                                                      ^
                                                      |
                           Server SEQUENCE number -----

    By SEQUENCE number, I mean that if there are any servers that are not
    defined, they must not be counted. I.e. if servers 1,2,5 and 6 are
    defined, server 5 will have sequence number 3.
    This is an effect caused by the database being an RMS relative file and
    the DCL DUMP command ignoring "empty" records.
    In case you use server number one it is simple since it always will use
    record number one.

    You can post the DUMP here or send it to me by mail.

    Anders

.3> Next thing to check is that the replacement sequence really is correctly
.3> defined in the permanent database. Could you provide me with a dump
.3> of the misbehaving server's data base record?

.3>     $ DUMP MRMEMO$DIR:MRMEMOPAR.DAT/RECORD=(START=n,COUNT=1)
   
    This dump ( note : we only have one MRMEMO server ) 
    + an output of the MRMMAN "LIST" command 
    + the dump of the NBS file
    
    have been mailed to STKHLM::OLSSON.
    
    Not knowing if it has any relation with the here described problem, but
    the memo server V2.0 has been patched as described anywhere else in
    this note conference in order to get the whole distribution list in the 
    mail.
    
    Will this help you to help me ?
    
    
    - Philippe -

.4> This dump ( note : we only have one MRMEMO server ) 
.4> + an output of the MRMMAN "LIST" command 
.4> + the dump of the NBS file
    
.4> have been mailed to STKHLM::OLSSON.
    
    Thank you. I have looked at them and they look fine.


.4> Not knowing if it has any relation with the here described problem, but
.4> the memo server V2.0 has been patched as described anywhere else in
.4> this note conference in order to get the whole distribution list in the 
.4> mail.
    
    No - it is not related.

.4> Will this help you to help me ?
    
    Yes. Since all dumps looked as they should, we had to think a little and...

    SET/MODE=EMBARRASSED

        This indeed is a known problem with V2.0. It had slipped my mind.
        Furthermore - the test I performed with V2.0 wasn't done on V2.0
        as I thought, but on an early baselevel of V2.0A where this problem
        was fixed.

        Normally, the answer in this situation would be "Upgrade!" but since
        my mistakes have resulted in wasting your (and the customer's) time,
        I have a produced a patch to solve this problem (note 5.5).

    Sorry,
    Anders

.5> SET/MODE=EMBARRASSED

    Please, don't be.
    
    This note conference is really the one I get the quickest and the best
    answers to my questions.
    
    So : SET/MODE=NOEMBARRASSED/THANKED

.5>     Normally, the answer in this situation would be "Upgrade!" but since
.5>     my mistakes have resulted in wasting your (and the customer's) time,
.5>     I have a produced a patch to solve this problem (note 5.5).
    
    I would be pleased to install the 2.0A version on our systems.
    Am I allowed to do this, or is it still a Field Test version that may
    not go to customers ?
    If I am allowed, can you give me a pointer to the 2.0A distribution or
    tell me the required procedure to follow to get it ?
    
    In the mean time I will install the mentionned patch anyway.
                                                                          
    Thanks for your precious assistance.
    
    
    - Philippe -
    

.6> I would be pleased to install the 2.0A version on our systems.
.6> Am I allowed to do this, or is it still a Field Test version that may
.6> not go to customers ?
.6> If I am allowed, can you give me a pointer to the 2.0A distribution or
.6> tell me the required procedure to follow to get it ?
    
    2.0A is a "real" version. What's different with 2.0A is that it is
    only supposed to be delivered to customers that need it (something
    like the VMS "limited distribution" versions e.g. V5.3-2).

    In your case, where you have a customer with a V2.0 problem that is
    fixed in V2.0A you could of course do an upgrade.

    The proper procedure (outside Sweden and Germany) to get V2.0A is to
    contact the ASSETS Library in Turin, Italy. There is some information
    about this in other notes (e.g. 2.6 and 3.2).

    Anders