Conference virke::mrmemo

    Hello Torkild,

.0> $ run/nodebug sys$system:mrmsrv
.0> Time: 1992-02-25 10:26:29.08; message from server MRMEMO1:
.0> %MRMEMO-I-NEWACCOUNT, opening new accounting file: MAILBUS$DISK:[MRMEMO]MRMEMOACC1.DAT;18
.0> %SNA-I-UNBINDREC, UNBIND received from IBM application
.0> Time: 1992-02-25 10:27:38.97; message from server MRMEMO1:
.0> %MRMEMO-F-UNBIND, UNBIND request received from MEMO Gateway
.0> Time: 1992-02-25 10:27:39.68; message from server MRMEMO1:
.0> %DDS-E-OPSYS, Operating system interface error
.0> -SYSTEM-F-NOPRIV, no privilege for attempted operation
    .
    .
 
    Is this part of the log file extract unedited? I.e. did the problems start
    almost immediately after the server was started?

    I don't think DDS is to blame for this.
    There is an UNBIND less than a second before the DDS message. I think that
    something happened during processing of the UNBIND that made DDS upset/
    confused. I have seen this happen before and I think the reason might be a
    design problem in MRMEMO concerning the way condition signaling is used.
    Unfortunately, this is nothing that can be fixed by a simple patch. This
    will be looked over next time a new MRMEMO version is planned.

    Anders

    Hi Anders,
    
    
    The log file is un-edited (I've cut out a big part in the end, of
    course - it's a total of 25000 blocks).
    
    Do you say that this is something that occasionally may happen? Can I
    add some DCL hack that checks for such a failure and restarts the
    gateway?
    
    Thanks,
    Torkild

    
    Torkild,
    
>    Do you say that this is something that occasionally may happen? Can I
>    add some DCL hack that checks for such a failure and restarts the gateway?
    
    I think that is what Anders says. Your suggested workaround is
    reasonable and I know of a few customers who do something similar.
    Don't forget:
    
    1) Use the $ STOP command to shut the server. MRMMAN SHUT is sort of
    unreliable in this kind of situation, and besides you would then have
    to allow for a delay factor.
    
    2) Post the routine here when you're finished :-)
    
    cheers,
    
    	Stefan

The problems seem to start when the DDS maintenance (DDS$TIDY) job runs.
Has anyone else seen this? 

    
>    The problems seem to start when the DDS maintenance (DDS$TIDY) job
>    runs. Has anyone else seen this?
    
    Yes, sort of. See 92.*

    I've seen alot of (especially ALL-IN-1/IOS) problems related to DDS
    maintenance, and I guess stopping most MAILbus software when DDS$TIDY
    runs *may* be a (not soo good, but acceptable) solution.
    
    I still have problems as described in previous reply:
    
    %%%%%%%%%%%  OPCOM   9-MAR-1992 15:56:01.49  %%%%%%%%%%%
    Message from user MRMEMO on DECWAY
    Time: 1992-03-09 15:56:01.48; message from server MRMEMO1:
    %ADA-F-EXCCOP, Exception was copied at a raise or accept statement
    -ADA-F-CONSTRAINT_ERRO, CONSTRAINT_ERROR
    -ADA-I-EXCRAIPRI, Exception raised prior to PC = 001DBBA5
    
    
    %%%%%%%%%%%  OPCOM   9-MAR-1992 15:57:20.98  %%%%%%%%%%%
    Message from user MRMEMO on DECWAY
    Time: 1992-03-09 15:57:20.97; message from server MRMEMO1:
    %ADA-F-EXCCOP, Exception was copied at a raise or accept statement
    -ADA-F-CONSTRAINT_ERRO, CONSTRAINT_ERROR
    -ADA-I-EXCRAIPRI, Exception raised prior to PC = 001DBBA5
    
    %%%%%%%%%%%  OPCOM   9-MAR-1992 16:05:10.48  %%%%%%%%%%%
    Message from user MRMEMO on DECWAY
    Time: 1992-03-09 16:05:10.47; message from server MRMEMO1:
    %ADA-F-EXCCOP, Exception was copied at a raise or accept statement
    -ADA-F-TASKING_ERROR, TASKING_ERROR
    -LIB-F-INSVIRMEM, insufficient virtual memory
    -ADA-I-TASTYPEIS, The task's type is results_handler
    -ADA-I-TASIDIS, The task's id is %TASK 16
    
    
    %%%%%%%%%%%  OPCOM   9-MAR-1992 16:06:25.34  %%%%%%%%%%%
    Message from user MRMEMO on DECWAY
    Time: 1992-03-09 16:06:25.34; message from server MRMEMO1:
    %LIB-F-INSVIRMEM, insufficient virtual memory
                                                  
    Anyone got some ideas?!?!
    
    
    Torkild

    I just rebooted to be sure everything was fresh after the API
    reinstallations, but the ADA exception still occurs, and message
    traffic direction MEMO ---> MAILbus is blocked....
    
    I'm in need for some help!
    
    
    Torkild

Some gateway info:

	MRMEMO1 summary as of 1992-03-09 18:43:32
Server Identification:
  Node name:               DECWAY
  Mailbox name:            MEMO
  Message Router Password: ****
SNA Session Identification:
  Gateway node:            DECRT1
  Access name:             
  Circuit name:            SDLC-1
  Session address:         2
  Application name:        TCITMMRG
  Logon mode entry:        MEMOMRG
Related files:
  Translation table:       SYS$LIBRARY:MRMEMOTRA.TBL
  Log file:                MRMEMO$DIR:MRMEMO1.LOG
  Accounting file:         MRMEMO$DIR:MRMEMOACC1.DAT
Options:
  Accounting:              Enabled
  Timestamp:               Enabled
  Header in text:          Enabled
  Request Notifications:   Enabled
  Send Notifications:      Enabled
  Cluster alias address:   Disabled
  Address translation:     Enabled
    Format:                MEMO
    Ensure uniqueness:     Disabled
    Multiaddress action:   PRIMARY
  MEMO address:            SN_ATTRIBUTES
  DDS validation:
    MR to MEMO sender:     Disabled
    MEMO to MR sender:     Disabled
    MEMO to MR recipient:  Disabled
    MR to MEMO recipient:  Disabled
  Distribution list:       End
  Prefix:                  VAX
  Replace Strings:         ..=@
  Console logging:         Network
  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:            0

    
    Hi Torkild,
    
    I've just sent you a mail suggesting that you call me so we can agree
    on a proper support action. I'm fully prepared to log into the system.
    
    It's not quite clear whether you ever managed to get any
    messages through the gateway using DDS (ie address translation), or
    indeed whether you've managed to get messages through at all. I assume
    you have tested successfully without Adress translation so we can
    disregard communication problems for the time being.
    
    I think the problem here is realated to either:
    
    1) Quotas, or hardware resources
    
    2) there's something basically wrong with the config of the DDS
       system on the node you're running MRMEMO.
    
    A longshot: Is your MRMEMO system *not* a DDS WS node? I think it
    should be, primarily for performance reasons, but something I read a
    few days ago in the MAILBUS notes conference indicates that MRMEMO
    may not work so well otherwise...