Conference virke::mrmemo

141.0. "Can't start MRMEMO" by BACHUS::AUSSIE (Thank God for Fridays) Wed Jun 10 1992 09:52

Hi,

The customer is running MRMEMO V2.1.

The problem first occurred after testing DDS validation (DEFINE/DDS_VALIDATION).

Some DDS validation testing was done successfully before MRMEMO wouldn't start
anymore.

Resetting the DDS_VALIDATION or reinstalling the gateway hasn't helped.

When starting the gateway through MRMMAN it appears to start normally creating
the necessary process and giving a successful status message. However
about 10 seconds later if still in the MRMMAN utility you recieve the 
following error: NETWORK PARTNER ABORTED LOGICAL LINK

Listed below is the log file which contains a stack dump. The log is typed 
be hand so please excuse layout but content will be correct.

$			exit
$! M r m e m o . c o m
$!
$ set noon 
$ set verify
$ define tt nl:
$ run/nodebug sys$system:mrmsrv
Time: 1992-06-02 10:32:44.50; message from server MRMEM01:
%MRMEMO-I-NEWACCOUNT, opening new accounting file: CLIO$DKB300:[MRMEMO]MRMEMOACC
1.DAT;122

%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=2E492E49, PC
=80000010, PSL=03C00000

    Improperly handled condition, image exit forced.

         Signal arguments               Stack contents

         Number = 00000005                 8012806E
         Name   = 0000000C                 00000002 
                  00000001                 7FF22E70
                  2E492E49                 7FF22E58
                  80000010                 00000004
                  03C00000                 7FF2314C
                                           00000002
                                           054718BB
                                           7FF22F45
                                           05000001

         Register dump

         RC = 7FF2314D  R1 = 2E492E49  R2 = 000018BB  R3 = 7FF22F47
         R4 = 00000000  R5 = 000000C9  R6 = 00031814  R7 = 00000002
         R8 = 00000001  R9 = 7FFECC58  R10= 7FFED7D4  R11= 001C0698
         AP = 7FF22E0C  FP = 7FF22DCC  SP = 7FF22E48  PC = 80000010
	 PSL= 03C00000

%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=2E492E49, PC
=80000010, PSL=03C00000

    Improperly handled condition, image exit forced.

         Signal arguments               Stack contents

         Number = 00000005                 8012806E
         Name   = 0000000C                 00000002 
                  00000001                 7FF22E70
                  2E492E49                 7FF22E58
                  80000010                 00000004
                  03C00000                 7FF2314C
                                           00000002
                                           054718BB
                                           7FF22F45
                                           05000001

         Register dump

         RC = 7FF2314D  R1 = 2E492E49  R2 = 000018BB  R3 = 7FF22F47
         R4 = 00000000  R5 = 000000C9  R6 = 00031814  R7 = 00000002
         R8 = 00000001  R9 = 7FFECC58  R10= 7FFED7D4  R11= 001C0698
         AP = 7FF22E0C  FP = 7FF22DCC  SP = 7FF22E48  PC = 80000010
	 PSL= 03C00000

$ logout
  MRMEMO	job terminated at 2-jun-1992 10:33:06.26

  Accounting information:
  Buffered I/O count:	140	Peak working set size: 	2031
  Direct I/O count	 59	Peak page file size:	9663
  Page Faults:	       1555	Mounted Volumes:	   0
  Charged CUP time:   08.83	Elapsed time: 	0 00:00:33.99


We have also recieved several SNA traces from the customer which are 
apparently OK according to our SNA people.

I hopefully been reliably informed that the problem is on the VMS side.

The customer did upgrade NCP from 4.2 to 5.2 on the IBM but has sinced
backed out the upgrade with no change to our situation.

MRMEMO had previously been stable for approximately two months.

If anyone has any constructive ideas please let me know as we are fast
running out of ideas. If trace details are required please give me a 
call on DTN 856 8737 (Brussels). Thanks in advance

Sam.............

    
    Hi Sam,
    
    You seem to have a problem...
    
    I think we need to talk about this. I tried to phone you at 12:45. Will
    you call me at DTN 876-8168? I will be in the office all afternoon.
    
    cheers,
    
    	Stefan

    
    One thing that you could try is the patch in 5.10
    
    It will take care of messages in MR->MEMO direction with faulty ORNAMES
    (No Userid)
    
    I know you said when we talked on the phone that the problem occurs in
    the other direction, but until that can be verified, the above is worth
    a try.
    
    cheers,
    
    	stefan

    
    Right, after logging in remotely I seem to have got something going. I
    refuse to beleive that this gateway has ever worked properly. I set the
    MRMMAN/REPLACE switch to the recommended "..=@,__= " (see documentation
    for details) and it doesn't crash anymore.
    
    The offending message was a service message (MR->MEMO)
    
    The originating MEMO user had tried to send a message to recipient
    <vaxuser>__AM__<nodename>
    
    Now MRMEMO is somewhat flexible as far as addressing goes, so if this
    is the syntax the customer wants, it is perfectly possible to let him
    have it. If so, they must define the /REPLACE switch like this:
    
    MRMMAN> DEFINE/REPLACE="__=@"
    
    If however they want the default behaviour, they should leave it as
    I left it and use the syntax:
    
    <vaxuser>..AM..<nodename>
    
    More info on addressing in for instance the MRMEMO Operator's Manual,
    chapter 4
    
    	cheers,
    
    		Stefan