Conference virke::mrmemo

There are three types of error messages in the log file:

  1) %MRIF-E-NOMESSAGE, the mailbox contains no message
  2) %MRMEMO-W-INVFNSNTX, Invalid fullname addressing syntax
  3) %MRMEMO-F-STRANGE, non-expected event for current state

1) %MRIF-E-NOMESSAGE:

I haven't seen this one before. Apparently, MRMEMO has tried to fetch a
message from its mailbox but the mailbox was empty. This shouldn't happen
since MRMEMO calls MRIF$QUERY to check that there is a message to fetch 
before MRIF$FETCH is called. I could think of two reasons for this to 
happen:

  - Maybe Message Router is designed so that the mailbox message count is 
    updated *before* the message is actually available to fetch. I'll try
    to do some tests to see if I can provoke this behaviour. If this is
    the problem, it is probably more likely to happen on a slow machine.

  - Someone PURGEd or FREEd messages from the mailbox between MRMEMO's
    QUERY and FETCH operations (doesn't seem very plausible).

2) %MRMEMO-W-INVFNSNTX:

While 1) and 3) are temporary timing related errors, this error is caused
by the addressing information in a message. I can see from the traceback
that it's a service message from MEMO that fails in some way. Either an MR
sender has some strange address that MRMEMO fails to return a notification
to or an MR sender attempted to send to a strange MEMO address.

It could become difficult to find out what kind of addressing syntax that
triggers this. One thing you could try is to check the accounting file for
messages with timestamps close to the error messages in the log file and
see if the originator addresses in the accounting file looks strange in 
some way.

3) %MRMEMO-F-STRANGE:

The most frequent error is %MRMEMO-F-STRANGE [to other noters: this is not
seen in .0 but in the complete log file that I have access to offline]. 
I have seen this error twice before. It is probably caused by a race
condition that can occur when a slow MRMEMO server (e.g. overloaded
machine) is communicating through a fast SNA path.

In the first system where I saw this (an overloaded �VAX), the symptoms
disappeared after system performance was increased (larger working sets
and spreading I/O on disks).

In the second case (also an overloaded �VAX), I created a patch which was 
installed but then I didn't hear any more about it so the patch was never 
published. I'll mail the patch to you so you can test it if you like.

Anders

.1> - Maybe Message Router is designed so that the mailbox message count is 
.1>   updated *before* the message is actually available to fetch. I'll try
.1>   to do some tests to see if I can provoke this behaviour. If this is
.1>   the problem, it is probably more likely to happen on a slow machine.

    I have now reproduced this (not in MRMEMO but with a test program). There
    is indeed a timing window where MRIF$QUERY reports the presence of a
    message in the mailbox but MRIF$FETCH fails with MRIF-F-NOMESSAGE.

    It would be possible to change (or patch) MRMEMO to ignore this error
    without reporting it but I don't think we'll do that. I regard this as
    an error in Message Router.

    It doesn't look pretty in the MRMEMO log file when it happens, but it
    should be harmless since MRMEMO recovers and goes on.

    Anders

%MRMEMO-F-STRANGE
-----------------
I have sent the patch i got by mail from Anders to the customer. During the
last few days this error message has not been seen in the logfile.
However the customer says this system can be quite heavily loaded sometimes.

I'll try to give some feedback here later.


%MRMEMO-W-INVFNSNTX
-------------------
I had a look in the accounting file. I did found some quite peculiar addresses.

 1-JUN-1993 10:25 MEMO: VAX.SYSTEM@MRGATE@EDS
817       6         1         4D454D4F324D41494C20202020202020 20520110603991/176573@EDS
 1-JUN-1993 10:26 MEMO: VAX2.SYSTEM@MRGATE@EDS
1052      6         1         4D454D4F324D41494C20202020202020 63620110603991/176587@EDS
 1-JUN-1993 10:41 MEMO: VAX.SYSTEM@MRGATE@EDS
817       6         1         4D454D4F324D41494C20202020202020 52140110603991/176705@EDS
 1-JUN-1993 10:41 MEMO: VAX2.SYSTEM@MRGATE@EDS
48        0         1         4D454D4F324D41494C20202020202020 15140110603991/176711@EDS

This is some entries were the message is from MEMO to Message Router. But the
senders address is not a MEMO address, but a MR address. These entries does
not exactly match the INVFNSNTX errors in the logfile if I compare the time
stamps. However some entries in the log file have match in the accounting 
file.
Seems like MRMEMO mix up sender/receiver addresses.

%MRIF-E-NOMESSAGE:
------------------
Nice to hear that this can be reproduced. I assume this could be a bug in the
Message Routers Programmer's kit or Message Router.
Perhaps should this be reported to Message Router engineering.



Sven-Olof 

.3> %MRMEMO-W-INVFNSNTX
.3> -------------------
.3> I had a look in the accounting file. I did found some quite peculiar
.3> addresses.
.3>
.3>  1-JUN-1993 10:25 MEMO: VAX.SYSTEM@MRGATE@EDS
.3> 817       6         1         4D454D4F324D41494C20202020202020 20520110603991/176573@EDS
.3>  1-JUN-1993 10:26 MEMO: VAX2.SYSTEM@MRGATE@EDS
.3> 1052      6         1         4D454D4F324D41494C20202020202020 63620110603991/176587@EDS
.3>  1-JUN-1993 10:41 MEMO: VAX.SYSTEM@MRGATE@EDS
.3> 817       6         1         4D454D4F324D41494C20202020202020 52140110603991/176705@EDS
.3>  1-JUN-1993 10:41 MEMO: VAX2.SYSTEM@MRGATE@EDS
.3> 48        0         1         4D454D4F324D41494C20202020202020 15140110603991/176711@EDS
.3> 
.3> This is some entries were the message is from MEMO to Message Router. But the
.3> senders address is not a MEMO address, but a MR address. These entries does
.3> not exactly match the INVFNSNTX errors in the logfile if I compare the time
.3> stamps. However some entries in the log file have match in the accounting 
.3> file.
.3> Seems like MRMEMO mix up sender/receiver addresses.

    I think it looks fine. It might look like VAX.SYSTEM@MRGATE@EDS is not
    a MEMO address, but it is (sort of). The actual destination is not a MEMO
    mailbox but it still is a MEMO address. This happens when a message passes
    through MEMO. Since both the prefixes VAX and VAX2 occurs above, I guess
    the system looks something like this:

       (VAX.)  MRMEMO
        /            \ mbx MEMO
    MEMO              MR
        \            / mbx MEMO2
       (VAX2.) MRMEMO

    Suppose the VMSmail user SYSTEM at node EDS sends a message to an address
    like this:

       MRGATE::"MEMO::VAX2.user@mbx@node"

    This message is sent to MEMO by the MRMEMO server with prefix VAX.
    When the message arrives to MEMO, the address is VAX2.user@mbx@node so
    MEMO routes the message to the MRMEMO server with prefix VAX2.

    When the VAX2 MRMEMO server reports the message in the accounting file,
    the originator's address is VAX.SYSTEM@MRGATE@EDS. I.e. the originator
    is an MR user but the message came from (through) MEMO.

    You don't even have to have two MRMEMOs for this. You can "loop" messages
    through MEMO anyway. In the example above, just replace VAX2 by VAX in
    the VMSmail address and the message will return from MEMO through the
    same server it came through.

    I don't think there's any problem with these entries in the accounting
    file, so the problem (INVFNSNTX) most likely involves destination
    addresses (which are not seen in the accounting file).

    I don't have any suggestion right now about how to proceed to find
    the addresses that MRMEMO barfs on. I'll do some thinking...

    Anders

PS
    When the Address Translation functionality was added to MRMEMO (in 2.1),
    I heard about a creative (and not entirely serious) way to use the "loop":
    If a VMSmail user sends a message to another MR user through MEMO when
    Address Translation is enabled, MRMEMO will make a DDS lookup and
    hence give the VMSmail user access to DDS addressing!

%MRIF-E-NOMESSAGE:
------------------

.3> Nice to hear that this can be reproduced. I assume this could be a bug in 
.3> the Message Routers Programmer's kit or Message Router.
.3> Perhaps should this be reported to Message Router engineering.

    It is now confirmed that this is how Message Router works. It's regarded
    as a feature (not a bug). (See note 1704 in FORTY2::MAILBUS if you're
    interested.)

    Since MRMEMO does not expect this "feature", the %MRIF-E-NOMESSAGE will 
    sometimes occur. Now when we know that this property of Message Router is 
    here to stay, I guess MRMEMO needs to be taught not to be upset about it.
    However, since it doesn't cause any harm (except for the tracebacks in the 
    log file), I will not attend to it with high priority.

%MRMEMO-W-INVFNSNTX:
--------------------

    I have done some more digging and I now believe that the problem occurs
    when a status message is sent from MEMO to an MR user with a strange
    address. These strange sender addresses *should* be in the accounting file
    (if I'm right). The time of the %MRMEMO-W-INVFNSNTX logs and the time
    stamps in the accounting file need not be correlated if receipt
    notifications are involved (they could be days - or even weeks apart). For
    delivery notifications, however, the time stamps should mostly be rather
    close. 

    Delivery notifications from MEMO are only propagated to MR if the option
    "Send Notifications" is enabled in the server. Is it? 

    To get more information about the addresses causing %MRMEMO-W-INVFNSNTX, I 
    have made a patch that I'll mail you. The patch will make MRMEMO do some 
    additional tracebacks including the bad address string.

    Anders

The customer has now installed the patch (mentioened in 177.1) that should 
solve the problem were MRMEMO running on a VAX with poor system performance 
issued the error message %MRMEMO-F-STRANGE.
It seems that the patch indeed solves this problem. MRMEMO frequently
reported this message before the patch was installed. After the patch was 
installed %MRMEMO-F-STRANGE has not been reported.

The customer also installed the patch that makes  MRMEMO write additional
information to the errorlog when %MRMEMO-W-INVFNSNTX occurs. We have found
a MRMEMO address that seems quite strange. The customer will do some
further investigation.

.5> Delivery notifications from MEMO are only propagated to MR if the option
.5> "Send Notifications" is enabled in the server. Is it?

   "Send Notifications" is disabled in the MRMEMO server.


Sven-Olof