Conference virke::mrmemo

Hello,

.0>	-should MR-MEMO be re-installed after the installation of the
.0>	SAN-API patch
.0>	-would a relink of some of the components also do the job, and if so
.0>	what should be relinked.

    No, I don't think that this is necessary since the SNA API consists of
    sharable images.

    To be able to try to reproduce this problem, I would like to know:

      - What version of MRMEMO?
      - What are the server parameters? (MRMMan> LIST/FULL server)
      - Are there any errors in the log file?
      - How fast does memory grow (check e.g. Virtual pages in SHOW PROC/CONT)
      - Approx. how many messages are processed per day? (So that I can
	calculate average amount of lost memory per message.)
      - What other user agents and gateways are present? ALL-IN-1, VMSmail,
	MRX...?
      - What kind of messages are sent? "Plain" text, WPS-PLUS, DDIF?
      - Other information that might be of interest, e.g. are there any other
	system problems? any "creative" configurations etc.

    If you can provide me with answers to (at least some of) these questions,
    I'll try to reproduce to problems and (if I can and if the problem is in
    our code), fix it.

    Anders Olsson

Hello Anders,

It took me sometime the get the requested info, but here it is:

- MRMEMO v2.1

- Server paramaters for server 1, there is a second server, but that one is not  c
  causing any problems. The IBM is always connected to that one.

Server Identification:
 Node name:			SYSA
 Mailbox name:			MEMO
 Message Router Password:	****
SNA Session Identification:
 Gateway node:			SNACT0
 Access name:			MEMO
 Circuit name:
 Session address:		0
 Application name:
 Logon mode entry:
Related files:
 Translation table		SYS$LIBRARY:SNATEDEF.TBL
 Log file:			MRMEMO$DIR:MRMEMO1.LOG
 Accounting file:		MRMEMO$DIR:MRMEMOACC1.DAT
Options:
 Accounting:			enabled
 Timestamp:			enabled
 Header in text:		enabled
 Request notification:		enabled
 Send notification:		enabled
 Cluster alias address:		disabled
 Address translation:		disabled
 MEMO address:			PR_ATTRIBUTES
 DDS Validation:
   MR to MEMO sender:		enabled
   MEMO to MR sender:		enabled
   MEMO to MR recipient		enabled
   MR to MEMO recipient		enabled
 Distribution list:		end
 Prefix:				FKRV
 Replace strings:		..=@
 Console logging:		Oper1
 Clock tick interval:		   0 00:00:30.00
 MEMO line length:		75
 Wrap/truncation string:
 Wrapping of long lines:	enabled
   Word wrap margin:		disabled
   Hyphenation string:		
 Hours to GMT:			1
Manager on server:		SYSA::SYSTEM
				SYSA::MBMANAGER
				SYSA::AP53287
				SYSA::OPR_OA

-There are no errors in the log file

-The system was started on Monday 25th of November 20:00 with 4500 virtual pages
 Currently there are 3200 pages left (its Wednesday 27 November 11:00).

-There are about 10 messages a day.

-ALL-IN-1 and MRgate are also in use.

-The messages are plain text, although now and then a Wordperfect document might 
 slip through when KEYpak is not working properly

-The virtual pages are lost when the IBM is not connected. The connection is 
 disabled a number of times a day on server 1.

Andy Komen

    Hello Andy,

    sorry about the delay.

.2> -There are no errors in the log file

.2> -The system was started on Monday 25th of November 20:00 with 4500 virtual
.2>  pages.
.2>  Currently there are 3200 pages left (its Wednesday 27 November 11:00).

.2> -The virtual pages are lost when the IBM is not connected. The connection
.2>  is disabled a number of times a day on server 1.

    I have done some tracing of calls to the memory allocation/deallocation
    routines (lib$get_vm and lib$free_vm) when the IBM is not connected. (I
    have simulated an unconnected IBM by defining 1) a non-existing
    SNA/Gateway node, 2) a non-existing access name.

    In both cases, each connection attempt (default interval 30 seconds)
    results in two more allocations than deallocations, causing 96 bytes
    to be lost. 96 bytes every 30s means approximately 20 (512 byte) pages
    of virtual memory lost every hour of IBM downtime.

    Disclaimer:
		These tests were made with V2.2 of SNASHR and SNALU0SHR.

    However, while connection has not been established to the IBM side,
    there are *no* memory allocation calls made directly from MRMEMO (i.e.
    the code written by us). All allocation (and deallocation) calls in this
    state come from within SNASHR and SNALU0SHR.

    If you could send me the SNA-API patch, I will set up a test with
    SNA-API V2.3 (patched and unpatched) and see what happens.

    I find it very likely that the SNA-API is the problem. Note that there
    are *two* deallocations missing for each connection attempt. Maybe
    the SNA-API patch fixes only one of them.

    Anders

                Hello Anders,

today when tracking another problem I saw that when the IBM was goen also
errors in the messagerouter inf file appeared.

The exact message was :

MROUTER-I-FAILOG_LSTN_F, 19920702115700  The application MRMEMO on node
SYSA, identified to mailbox MEMO, is fetching a message.

%MROUTER-F-PROTOVIOLATION, MRMEMO on node SYSA violated the Transfer 
Service protocol with "D"

This goes on untill.... you gues is right,

        does this help ?

regards Rob.

Hello Rob,

.0> MROUTER-I-FAILOG_LSTN_F, 19920702115700  The application MRMEMO on node
.0> SYSA, identified to mailbox MEMO, is fetching a message.
.0> 
.0> %MROUTER-F-PROTOVIOLATION, MRMEMO on node SYSA violated the Transfer 
.0> Service protocol with "D"

This indicates that MRMEMO *might* be doing something illegal in its
communication with Message Router. The "D" doesn't tell me anything but
%MROUTER-F-PROTOVIOLATION could mean e.g. that an application has attempted
to confirm a message (by calling mrif$confirm) without first fetching a
message (by calling mrif$fetch).

We might be on to something here. The memory loss you experience when the
IBM is down could very well be a problem with the MR connection, indirectly
caused by the failed attempts to connect to the IBM.

When MRMEMO does an internal restart due some error (e.g. a lost SNA 
connection), it starts over from scratch by first disconnecting from MR
and SNA and then it starts the connection sequence again. There might be
some state where the sudden MR disconnect is frowned upon by MR. (Maybe the
"D" means disconnect...)

.0> does this help ?

Yes, I think so. I might be able to reproduce the problem now when I think I
know in what area to look. It would, however, be easier if you could get
the contents of the MRMEMO log file from this time, where the IBM connection
failure should be logged.

Anders

    
    Hey !
    
    I think I've got the above problem at one of my customers.
    
    The customer has upgraded their message router products including
    mrx and also they installed the software to a newer machine.
    
    I found the insufficient virtual memory error text in the memo
    log files. I checked the snalu0api version. It is 2.3-27, which
    should be OK.
    After that I also found the same error logs in the .inf files:
    MROUTER-I-FAILOG_LSTN_F, 19920702115700  The application MRMEMO on node
    .0> SYSA, identified to mailbox MEMO, is fetching a message.
    .0>
    .0> %MROUTER-F-PROTOVIOLATION, MRMEMO on node SYSA violated the Transfer
    .0> Service protocol with "D"
     
    I wonder, what the solution to this problem has been, since there are
    no entries after 107.5 ??
    
    Jan-Erik
    

     
.6> I wonder, what the solution to this problem has been, since there are
.6> no entries after 107.5 ??

    There hasn't been any solution (yet).

    I do remember that I did some research on this problem once. I think the
    problem occurs if MRMEMO makes a crash-and-restart between fetching a
    message from MR and sending the message to MEMO. MRMEMO then disconnects
    from MR while the fetched message is not yet confirmed, which Message
    Router seems to regard as a protocol violation. Probably some    
    (substantial) amount of memory is lost in the process. 

    I assume that there is some connection problem (e.g. to the IBM) logged in 
    the MRMEMO log file. Otherwise this should not happen.

    Since this problem has now been reopened I guess I'll have to look at this
    again. I don't think it's impossible to make patch for it. It could take
    some time though. Is the customer having severe problems? 

    Anders    

    
    Hey, Anders !
    Actually this problem has ow disappeared from our customers
    environment. It seems that the above problem occurred due to another
    problem we had. And now when we have corrected the problem that caused
    everything, the resulting problem has disappeared.
    
    So altogether, maybe it's not worth putting too much time into this
    one. I shall come back if the problem comes up again !
    
    Jan-Erik