Conference virke::mrmemo

151.0. "MEMO binary file type looping MRMEMO?" by MLN02::MALACRIDA () Thu Oct 15 1992 17:14

    I know that there is no support for binary sent from MEMO, and
    this is not a note asking for such a feature.
    I would only to bring to your attention what happen (to MY gateway ..)
    when a binary file is sent from MEMO.
    As you can see from the attached log file, after the gateway
    realize that the file's type is one that it can't handle, it goes in 
    a sort of loop with the remote application (see the several unbind
    received): looking at the SNA trace (I see it at the customer site
    but I can't provide it here), I saw an INIT-SELF from MRMEMO, a
    bind sent from the remote application immediately followed by an 
    unbind.
    
    Can anyone tell me what's happening?
    
    Thanks,
    
    giovanni
     
    
$ run/nodebug sys$system:mrmsrv
Time: 1992-10-13 16:45:45.55; message from server MRMEMO1
    %MRMEMO-I-NEWACCOUNT, opening new accounting file: 
    SYS$COMMON:[MRMEMO]MRMEMOACC1.DAT;16
Time: 1992-10-13 16:51:42.57; message from server MRMEMO1:
    %MRMEMO-W-UNSDOCTYP, unsupported MEMO document type
    -MRMEMO-I-GIU_GIDMTDP, document profile operand
    -MRMEMO-I-GIU_GIDMT, document unit
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, receiving from MEMO after data received from MEMO
-MRMEMO-I-RING, ring: '1A 1A 1A 1A 1A 1A 1A 1A 13 36.', substates: 00000070
%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 08938290:
%MRMEMO-W-UNSDOCTYP, unsupported MEMO document type
-MRMEMO-I-GIU_GIDMTDP, document profile operand
-MRMEMO-I-GIU_GIDMT, document unit
----- end of exception message
ALLUNP          ALL$UNP_DOCPROFIL                3557      000001F4  001F38EE
ALLUNP          ALL$UNP_DOCUMENT_UNIT            3652      00000050  001F39C0
ALLUNP          ALL$UNP_GIU_TO_MSGITMLST         3859      000000E6  001F3B93
SRVACT          SRV$ACT_R                        5172      000000A2  001EB591
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
                                                           0026537D  0026537D
ADA$ELAB_DDS    ADA$ELAB_DDS                               0000000E  001C0C0E
                                                           00239B89  00239B89

%SNA-I-UNBINDREC, UNBIND received from IBM application
Time: 1992-10-13 16:51:45.61; message from server MRMEMO1:
    %MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
    
%SNA-I-UNBINDREC, UNBIND received from IBM application
Time: 1992-10-13 16:51:54.90; message from server MRMEMO1:
    %MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
    
%SNA-I-UNBINDREC, UNBIND received from IBM application
Time: 1992-10-13 16:52:00.10; message from server MRMEMO1:
    %MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
    
    and so on .... every 6-10 seconds
    
    

    Ok, I have reproduced it (and consequently "disabled" my MEMO/Gateway
    port in the Valbonne IBM :-).

    The error message that MRMEMO creates as response to a binary document
    is apparently not received with any overwhelming enthusiasm.
    Some component on the IBM side (MEMO/MRGATE?) seems to get stuck in a
    state from which it isn't abel to recover by itself.

    Since recent versions of MEMO + MEMO/GWY have the ability to send out
    binary documents, it is of course rather inconvenient if this disables
    the connection.

    I'll try to determine if MRMEMO sends an incorrect error message to MEMO
    or if the problem is on the IBM side. Then we'll know if MRMEMO needs
    a fix or if it's a Verimation problem. The tests might take some time
    though since I need IBM operator assistance to unjam the port after each
    test.

    Anders

Thanks Anders for your interest in the problem.

As we can't be sure that the counterparts will not send a binary file,
this is a quite sensitive problem because the restart of the communication
between the two environments must be MANUALLY done (after an operator 
has pheraps noticed that something is stuck ...).

Looking forward for some fix/workaround,

giovanni
    

    After discussing this problem with a MEMO developer, I now understand
    what is happening. The error message MRMEMO is sending back to MEMO when
    a binary document is received, is only supposed to be used when an
    unrecoverable error has been discovered by MRMEMO and operator
    intervention is required. In this situation, MRGATE on the IBM side is
    supposed to hang - exactly as it does!
    
    To avoid this, MRMEMO must be changed to send back another (completely 
    different) kind of error message - actually a non-delivery. I might be 
    able to make a patch for this but it'll have to wait some time. I am
    currently on a customer assignment for some weeks (which means *real*, 
    external money).

    Anders

    Now there is patch for this problem available in 5.21.

    I can't make our MEMO system in Valbonne generate a real binary MEMO
    message (the MEMO version is too old). I have done tests by modifying
    a message from MEMO to a binary message with the debugger though, so
    I'm quite confident that it works.

    I'd appreciate if someone (Giovanni?) could apply the patch to a system
    where binary messages do fly around and post the results here.

    Anders

    I had the opportunity to install the patch at customer site a couple of
    weeks ago.
    Well, it works: now the sender of the binary file get back an error
    message and the link between MEMO and MRMEMO stays up and running.
    
    Thanks.
    
    giovanni