Conference virke::mrmemo

133.0. "Problem with MRMEMO at ALCATEL" by VNASWS::HELENE (See you at the New York Marathon 1992?) Wed Apr 01 1992 20:11

Hello,

my customer reports the following problem with MR-MEMO:

several times a day the connection to the IBM System breaks down and the 
MRMEMO-GAtewaydoes not recover as it should. 
If in this situation a message is waiting for transfer
on both sides (Memo and MRMemo), the MRMemo process hangs and cannot be shut.
Only a stop/id, purging the Memo-Mailbox  and a restart clears the situation.

I'll try to get more info on version numers etc.

Any clues?

Below is an excerpt of the Logfile, as the customer sent it to me:


$type SYSTEM_DATA:[MRMEMO]MRMEMO1.LOG

-SYSTEM-F-UNREACHABLE, remote node is not currently reachable
%SNALU0-E-NOSESN, failed to start session
-SNA-E-FAIESTLIN, failed to establish a DECnet link to the Gateway
-SYSTEM-F-UNREACHABLE, remote node is not currently reachable
%SNALU0-E-NOSESN, failed to start session
-SNA-E-FAIESTLIN, failed to establish a DECnet link to the Gateway
-SYSTEM-F-UNREACHABLE, remote node is not currently reachable
Time: 1992-03-31 10:30:32.86; message from server MRMEMO1:
%SNA-F-FATINTERR, internal error in Gateway access routines
-SNA-F-UNKMSGREC, unknown message code received from Gateway

%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, receiving from MEMO after BID request from MEMO
-MRMEMO-I-RING, ring: '1A 19 18 2A 27 1B 13 36 1A 33.', 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 0203827C:
%SNA-F-FATINTERR, internal error in Gateway access routines
-SNA-F-UNKMSGREC, unknown message code received from Gateway
----- end of exception message
                                                           002F06DE  002F06DE
                                                           002F5E45  002F5E45
                                                           002EC989  002EC989
                                                           002F40CA  002F40CA
KOSCRIPT        KOT$LEARN_CHAR                             8035D714  8059891B
SRVMMO          SRV$MMO_ONE_LIFE                 4300      000000DA  001E02AA
SRVMMO          SRV$MMO_MAIN                     4208      00000017  001E01C3
                                                           00239BAE  00239BAE
KOTERM          KOTERM                            804      00000039  002375A2
                                                           00239B89  00239B89
KODOC           KODOC                            1768      00000097  002347E4
                                                           00239B89  00239B89
                                                           0026517D  0026517D
ADA$ELAB_DDS    ADA$ELAB_DDS                               0000000E  001C0C0E
                                                           00239B89  00239B89
 **************************************************************************

  VAX MAILGATE for MEMO Manager version V2.1
MRMMan> show /deb

        MRMEMO1 status as of 1992-03-31 13:50:14

  Current state:               receiving from MEMO
  Last event:                  BID request from MEMO
  Current operation:           none
  Current substate:            00000020
  Current number of links:     1
  Last Application ID:         624AD4A57901FFB83E7C03
  Last Message Router ID:      60039013302991/1304@DVAX
  Direction:                   Message Router -> MEMO
  Timestamp:                   1992-03-31 10:30:30.76
  Status:                      Successful Delivery
  Start time:                  1992-03-27 12:58:34.07

I've seen this once, and it seems this is a bug in LU0 programming routines.

Perhaps you should ask the question to the SNA Gateway people ...

				Marc VH.

Hello, 

these are the version numbers as promised:

MRMEMO V2.1 link date/time: 24-jan-1991 20:43:46.73, no patches


SNAAPI:

SNALU0SHR 2.3   27
SNASHR    2.3   41


MARC, I think it is a good idea to test the SNA-connection first. 

Since the customer uses an Interlink Gateway he will test this week 
with an SNA-Gateway, a supported configuration

I'll post the result of the customer test here.

Helene

    This looks similar to note 81, where Interlink was also involved.
    So doing some testing with a real SNA/Gateway seems to be a good idea.

    Anders