Conference virke::mrmemo

    Hello Heinz,

    I'm not sure I understand the configuration here. Is it like this?

      +-- MRMEMO <-- MEMO <-- IBM Screen Mail
      |
      V
      MR (generates non-delivery)
      |
      +--> MRMEMO --> MEMO --> IBM Screen Mail
         ^^^^^^^^^^^^^^^^^^^^^^^^^
         The non-delivery disappears somewhere here.
    
.0> I can't see any problem areas in the following
.0> NBS dump (espec. the TO routing info seems ok and
.0> is validated by other mails). But maybe someone
.0> in the LEG group sees more.

    The NBS dump in .0 is repeated four times. Do you have any other dumps
    (e.g. the non-delivery message)?

    To enable formatted logging of all messages going from MRMEMO to MEMO,
    you can use "$ define/system MRMEMO$LOGMASK 20". The formatted log
    appears in the MRMEMOn.LOG file. There is no need to restart the server
    to enable/disable the formatted message logging. If you could get such a
    formatted trace of the non-delivery message, it would be a help.

    What kind of connection is there between IBM Screen Mail and MEMO? It
    might be possible that there is some vital information in the message
    from IBM Screen Mail to MEMO that is not propagated to MRMEMO. If this
    is the case, we have no chance to return a proper non-delivery.

    But let's not get to pessimistic yet. If you get a formatted message log,
    we could (hopefully) at least show the MEMO people that the non-delivery
    that we send to MEMO seems to be correct. Then they should be able to go
    on and find out why the message doesn't show up at the destination.

    BTW, the LEG group in Sweden is no more (since several years). I (and
    Stefan) are still here though but we spend >100% in customer projects
    nowadays. That's why it took some time before I answered this.

    Anders

    
    Anders,
    
    the message flow you have drawn in your reply is quite right.
    In the mean time we tried to involve our MR backup to analyze the
    NBS files. In the end we got the following information from 
    Mark Boyes:
From:	FORTY2::BOYES        "Marky Mark"  2-NOV-1994 16:08:20.37
To:	HAN::FISCHER_HE
CC:	
Subj:	RE: IPMT VW

There must be a backlog on the IPMT front: I include an informal copy of my
formal response written on 31st October...

                      FURTHER INFORMATION REQUEST
                      ---------------------------

Heinz Fischer            
                                                                            
QUERY-ID : Case MGO100936 (MR-V32-1098)                                        
QUERY : NDN OF MAIL FROM MR MEMO

To help us in the investigation of this Problem, could you send, or provide
the location of, the following information :


I have examined NBS and RMS dumps of the file MR1008502.NBS and have seen
that this file is not a complete NBS message: it is the first two records of a
file that should be three records long. Please confirm that this is the state
MR1008502.NBS was in when it was copied i.e. that the file was corrupt in this
way before it was extracted from Message Router for examination.

If MRMEMO consistently produces corrupt NBS, tracing in MRMEMO should be enabled
to detect where this is happening: as the missing record would contain, as well
as some of the recipient information, the body text of the message, it may be
that the DCF converters are failing but MRMEMO is attempting to create an NBS
message with the two records it successfully produced before this point.

This case should be left open until the problem is confirmed to be in MRMEMO:
the error is occurring at such a low level that the source of the problem may be
a flaw in the MRIF API used by MRMEMO, which is supported by the MAILbus Support
Group. 


    **********************
    
    We tried to set up another test mail from VOLVO and enabled
    the tracing in the MRMEMO server. The output (where
    the SM.VOLVD.* messages represent the test mails) we
    put on the default decnet directory of the HAN::  as
    MRMEMO_TRACE_VW.LOG.
    
    I hope you can find any further another part in the puzzle.
    May be it might be useful to give you the access to the
    VW system to have a look at the NBS file too?
    
    Thanks
    Heinz

    Heinz,

    as far as I can see, the trace in MRMEMO_TRACE_VW.LOG shows a
    perfectly valid non-delivery message being sent to MEMO.
    [I got a mail from Heinz with a pointer to the message log I asked for
    in .1]
    The original destination being reported is "Z1.MANAGER<A1<VD001".
    I assume that '<' is used as a replacement character for '@', correct?

    Can you tell me if the recipient Z1.MANAGER is valid? I.e. is the primary
    problem that the message doesn't arrive to Z1.MANAGER? Or is this an
    invalid destination, which is just being used to provoke a non-delivery?
    Can any IBM Screen Mail (ISM) user successfully send a message through
    MRMREMO to any destination? If yes, can any ISM user get a notification
    back? Is DDS involved, translating Z1.MANAGER to something strange?
    Can a message be sent from Z1.MANAGER to SM.VOLVD.ROGERM?

    In any case, the non-delivery doesn't work, so let's start with that.
    As I said above, the message sent from MRMEMO to MEMO looks fine. So,
    why doesn't it arrive to the sender (SM.VOLVD.ROGERM). The only reason
    I can think of is that the ISM system does correlation on recipient names
    only. The original destination in the message from ISM was destined to
    "Z1.MANAGER". In the non-delivery, however the recipient is identified as
    "Z1.MANAGER<A1<VD001" (this "expansion" is normal in MRMEMO). Maybe this
    makes ISM fail to recognize the address.

    With MEMO, this is not a problem since there is another message element
    (receiver list position) that identifies each recipient within a message.
    If this element is present, MEMO uses it and ignores the textual name.
    ISM might not have this ability. [BTW, in some MEMO version - don't
    remember which one - the receiver list position lost its priority over
    the textual name, but this was fixed in a follow-up release.]
    
    We also had problems with notification messages some years ago when there
    was more than one MEMO system involved. I.e. a message from an originating
    MEMO system passed another MEMO system before reaching MRMEMO. This was
    some MEMO-MEMO inter-version problem. Maybe MEMO-ISM could have the same
    type of problem.

    About the reportedly corrupt NBS file, this sounds strange. Since MRMEMO
    doesn't crash or log any problem, it seems unlikely that it should be able
    to create a crippled NBS file. But it could of course be a bug in MRIF
    or MRMEMO. To find this could be difficult. The best way might be to try
    to catch the MRMEMOn-ENVELOPE.NBS and MRMEMOn-CONTENTS.NBS files.
    At least there shouldn't be any CDA converter involved since this is only
    invoked when a message from another MR sender arrives in non-text format.
    In this case, the message is created by MRMEMO and therefore only contains
    plain text.
    
    So, about the disappearing non-delivery the question is what IBM Screen
    Mail does when the reported recipient id doesn't match the original one.
    A question to Verimation?

    About the corrupt NBS file I don't have any ideas except catching the
    MRMEMOn-xxxxxxxx.NBS files to be able to have a look at them.

    If you have any answers to my questions in the first paragraphs of this
    note, I think this would help me to get a clearer picture.

    Anders

    
>    With MEMO, this is not a problem since there is another message element
>    (receiver list position) that identifies each recipient within a message.
>    If this element is present, MEMO uses it and ignores the textual name.
>    ISM might not have this ability. [BTW, in some MEMO version - don't
>    remember which one - the receiver list position lost its priority over
>    the textual name, but this was fixed in a follow-up release.]
    
    Might be a red herring, but this is discussed in 130.*
    
    cheers,
    
    	/Stefan

    
    
    Anders,
    
    '<' is the replacement character we selected.
    Z1.MANAGER3 is valid and unique (in SN fields, not in
    all surnames items).
    All other SM systems can exchange mail.
    Also the VOLVO SM mail system can be reached from
    A1 accounts on VD001 but we get no message from them through
    to the VD001 (forwarding mails from the MEMO system at VW which
    came from SM VOLVO will reach the VD001 accounts !?).
    Sound like an routing (inter-version) problem SM VOLVO - MEMO VW ?
    We did some testing today but we didn't get the MRMEMO*.NBS files
    through PSI. Tomorrow we will trie to give you a pointer to
    dumps on it.
    And I will ask for the MEMO version to control the problems
    Stefan mentioned with recipient correlation .
    
    Thanks
    Heinz

    
    After chasing numerous shadows, this problem has now been corrected. It
    was only a matter of "Hop-count exceeded"
    
    /Stefan