Conference virke::mrmemo

67.0. "Corrupt message blocks MEMO queue" by MUDIS3::RROSENBERGER (Rainer Rosenberger @MFR, PZ-SOGY) Mon Jan 28 1991 14:44

I did produce a MEMO message (don't know how) which cannot be handled by the
MEMO gateway. Therefore the gateway crashes and doesn't send an acknowledge 
to MEMO. After a while the gateway restarts and the same occures again. 
So we have a loop and a message in the MEMO queue which blocks the
queue.  

I think the gateway should receive the message (even if it's corrupted)
and then send an acknowledgement. If there is something wrong with the 
message a nondelivery notification should be generated and/or the corrupt 
message should be requeued. 

Rainer

==============================================================================

Time: 1991-01-28 14:04:44.12; message from server MRMEMO1:
%MRIF-E-MISSUSERID, missing userid
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, receiving from MEMO after data received from MEMO
-MRMEMO-I-RING, ring: '36 13 36 ][ 4A 52 1A 1A 13 36.', substates: 00000030
%TRACE-W-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

SRVLOG          SRV$LOG_HANDLER                  3943      000001C9  001E379D
----- above condition handler called with exception 0935E83A:
%MRIF-E-MISSUSERID, missing userid
----- end of exception message
SRVMRC          SRV$MRC_POST                     4820      0000005E  001E7879
SRVACT          POST_MEMO                        4962      0000003B  001EB33B
SRVACT          SRV$ACT_R                        5290      00000210  001EB6FF
SRVDSP          SRV$DSP_FSM                      3423      000002A6  001E342A
SRVMMO          SRV$MMO_ONE_LIFE                 4376      000001EF  001E03BF
SRVMMO          SRV$MMO_MAIN                     4208      00000017  001E01C3
                                                           00239BAE  00239BAE
KOTERM          KOTERM                            804      00000039  002375A2
                                                           00239B89  00239B89
KODOC           KODOC                            1768      00000097  002347E4
                                                           00239B89  00239B89
                                                           00264DB2  00264DB2
ADA$ELAB_DDS    ADA$ELAB_DDS                               0000000E  001C0C0E
                                                           00239B89  00239B89

    I found the reason for the problem in .0:
    
    I did sent to a user with a DDS entry having all X.400 attributes
    defined as SA attributes and the MHSORADDRESS did point to the MRX
    mailbox (and node). So I added the subscriber in the recommended way,
    i.e. 
    
    BUILD DDS SUB/MHSo=(MHSMAIL=mrxmbx, ADDR=mrxnode)
    
    This caused the memo gateway to encode the TS address only in the route
    terms. There was no USERID field. After using an DDS entry like
    
    MOD DDS SUB/MHSo=(MHSU=mrxmbx, MHSMAIL=mrxnode)
    
    everything worked fine. Therefore the gateway should put the DDS
    attribute MHSMAILBOX into the NBS USERID field if the DDS attribute
    MHSUSERID is not specified.
    
    Regards,
    
    Rainer

    
    OK, point taken.
    
    We will put this on the "list to fix". Since this seems to be a problem
    with a reasonable workaround (build correct DDS records) we won't
    provide a patch unless you twist our arms :-)
    
    (I'm trying to find time to look into 54... it's difficult 'cause
    officially I'm 100% assigned to a customer project)
    
    cheers,
    
    	Stefan