Conference virke::mrmemo

    This topic is reserved for patches and fixes to MRMEMO.

    There is a problem in the MRMEMO V2.0A server (and earlier) that can
    cause the server to abort something like this:

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000020,
		  PC=80000010, PSL=03C00000

  Improperly handled condition, image exit forced.

	Signal arguments	      Stack contents

	Number = 00000005		 801F606E
	Name   = 0000000C		 00000002
		 00000000		 7FDFBCE8
		 00000020		 7FDFBCD0
		 80000010		 00000004
		 03C00000		 7FDFBE18
					 00000000
					 00248200
					 000341CF
					 03000001

	Register dump

	R0 = 7FDFBE19  R1 = 00000020  R2 = 00000000  R3 = 7FE7CBF7
	R4 = 00000000  R5 = 00000000  R6 = 7FE7CBF7  R7 = 0001F3B5
	R8 = 000340BF  R9 = 7FDFBE78  R10= 7FFED7D4  R11= 00000029
	AP = 7FDFBC84  FP = 7FDFBC44  SP = 7FDFBCC0  PC = 80000010
	PSL= 03C00000

    And then there is another dump in the same fashion.

    This happens due to a string overflow check that does not work correctly.

    The patch below fixes this problem and causes long lines to be truncated
    to approximately 248 characters. This will make long text lines coming from
    MR to be truncated (including long from-addresses when /HEADER_IN_TEXT is
    enabled). This truncation occurs before the line is chopped up in MEMO
    line lengths.

        (If you wonder about the "approximately" above, it's because
	 expansion of tabs result in one to eight spaces depending on
	 the tab positions.)

---------------------------------------------------------------------------

MRMSRV.EXE
SET MODULE ALLPAC
!
! 16-Jan-1990 /AO
!
!  This patch for the MRMEMO V2.0A server image (MRMSRV.EXE) fixes the
!  following problem:
!
!  The server aborts with access violation followed by a stack dump when a
!  message line longer than 256 characters occurs in a message from MR to
!  MEMO. A long from-address string (e.g. long X.400 addresses) in combination
!  with /HEADER_IN_TEXT enabled can also cause this problem.
!
SET ECO 1
REPLACE /INSTRUCTION ALL$PAC_DOCUMENT_UNIT+2BE = 'MOVW #^X0100,B^^X18(SP)'
'MOVW #^X00F9,B^^X18(SP)'
EXIT
UPDATE

    There is a bug in the MRMEMO V2.0A server (and V2.0) that causes
    distribution lists displayed in MEMO messages to be incomplete
    sometimes.

    If the sender of the message requests read receipts (e.g. from
    ALL-IN-1) it works fine, but if there is no request for read receipts
    (as is always the case when using e.g. MRGATE), only the FIRST
    recipient in the distribution list will be displayed in the MEMO
    message.

    The patch below fixes this problem.
---------------------------------------------------------------------------

MRMSRV.EXE
SET MODULE ALLPAC
!
! 1990-04-26/AO
!
!  This patch for the MRMEMO V2.0A server image (MRMSRV.EXE) fixes the
!  following problem:
!
!  When presentation of distribution lists in the message text is enabled
!  (server option DEFINE/DISTRIBUTION_LIST=BEGINNING or END), the full
!  distribution list should be displayed in the message sent to MEMO.
!
!  If a read receipts has NOT been requested by the sender, only the FIRST
!  recipient in the distribution list will be displayed.
!
SET ECO 3
INSERT /INSTRUCTION ALL$PAC_TEXT_DISLIS+13F = 'MOVAB   B^04(R2)[R0],R2'
'CMPW    (R2),#34'
'BNEQ    .+9'
'MOVZWL  B^02(R2),R0'
'MOVAB   B^04(R2)[R0],R2'
EXIT
UPDATE

    In a MEMO system, receipt notications changes the status of the original
    message to indicate that the recipient(s) have read the message.

    This is not quite compatible with ALL-IN-1 that uses a somewhat different
    approach. When ALL-IN-1 issues a receipt notification (read receipt), it
    is in the form of a text mail that will be received by the MEMO user as
    a new message and not as a status change.

    There is currently no way in MRMEMO (V2.0A) to prevent MEMO's requests
    for receipt notifications from being passed on to Message Router. Neither
    is there a possibility for the MEMO user to inibit the request for
    receipt notifications.

    If these text mail read receipts are regarded as something annoying by
    the MEMO users, the patch below could be installed to stop MRMEMO from
    passing MEMO's receipt notification requests to Message Router.

---------------------------------------------------------------------------

MRMSRV.EXE
SET MODULE ALLUNP
!
! 1990-05-11/AO
!
!  This patch for the MRMEMO V2.0A server image (MRMSRV.EXE) disables
!  the passing of receipt notification requests from MEMO to Message Router.
!
!  NOTE   THIS IS A "FEATURE PATCH".  I.E. IT DOES NOT CORRECT A PROBLEM
!         BUT CHANGES THE FUNCTIONALITY.  INSTALL ONLY IF THE CHANGE IN
!         FUNCTIONALITY IS DESIRED.
!
!  A message sent from MEMO does normally contain a request for a receipt
!  notification (read receipt). MRMEMO always passes this request to the
!  Message Router.  When an ALL-IN-1 user reads such a message, a read
!  receipt is sent back to the MEMO user.  This read receipt is formatted
!  by ALL-IN-1 as a text mail that will appear in the MEMO user's mailbox.
!
!  If the text message read receipts from ALL-IN-1 are not desired, this
!  patch could be installed to prevent MRMEMO V2.0A from passing receipt
!  notification requests from MEMO to the Message Router.
!
SET ECO 4
REPLACE /INSTRUCTION ALL$UNP_COMSENDER+107 = 'EXTZV #5,#1,B^1(R3),B^8(SP)'
'MOVZWL   I^#1,W^8(SP)'
EXIT
UPDATE

    In MRMEMO V2.0, there is (was) a problem with freeform addressing format 
    from MEMO and character replacement for the space character. The space
    character is often replaced with double underscores ('__').

    In MRMEMO V2.0, when DDS MR recipient validation is not enabled, the
    space character replacement does not take place in freeform names,
    causing the userid element in the resulting message to look like
    'givenname__surname' instead of 'givenname surname'. 

    This problem was fixed in V2.0A so DON'T APPLY THIS PATCH TO ANY OTHER
    VERSION THAN V2.0. If you can, upgrading to V2.0A is a good thing to 
    do since there were many problems with V2.0 that were fixed in V2.0A.
---------------------------------------------------------------------------

MRMSRV.EXE
set modu ALLCNV
set modu SRVDDS
!
! 07-Sep-1990 /AO
!
! This patch for the MRMEMO V2.0 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When addressing a free form recipient from MEMO, the address is not removed
! of its blank string replacement (usually '__' for ' ') so the freeform
! address transmitted is "GIVENNAME__SURNAME" instead of "GIVENNAME SURNAME"
!
set eco 5
insert/instr SRVDDS\SRV$DDS_TO_ORNAME+32A = 'MOVL #0893C5D1,B^28(SP)'
'PUSHAB W^0FDE0(FP)'
'MOVZWL #0B2A,-(SP)'
'CALLS #2,ALL$CNV_SYNTAX'
exit
update

    MRMEMO V2.1 has problems handling certain message fields in messages
    from Message Router if the fields are "too" long.

    SUBJECT strings longer than 132 characters causes an internal string
    descriptor to be overwritten, which can result in the error
    "%STR-F-ILLSTRCLA, illegal string class". The server then loops, trying
    to read the same message over and over again. Removing the offending
    message with MRMAN from the MRMEMO mailbox is NOT enough since the
    corrupt decsriptor is still there. The server must be restarted. The
    problem occurs mainly when DDS validation is used for MR senders and/or
    MEMO recipients.

    Another problem is when a message arrives from Message Router with a
    UACONTID longer than 128 characters. This problem is related to the one
    above when VMSmail is used, since MRGATE uses the subject as uacontid.

    When a uacontid string longer than 128 characters is forwarded to MEMO,
    the message is rejected. This appears in the log file:

	%MRMEMO-W-FORMERROR, format error detected by MEMO Gateway
	-MRMEMO-I-FEEDBACK, feedback code 1: %x'02', 2: %x'0D'

    After the patch below is applied, a non-fatal error (%STR-W-TRU,
    truncation) will be logged each time a subject or uacontid longer than
    128 characters is found but the message will be forwarded to MEMO
    without problems.

    The complete subject string (even if longer than 128 characters) will be
    correctly displayed in the message text on the MEMO system if the
    MRMEMO server option /HEADER_IN_TEXT is enabled.

----------------------------------------------------------------------------

MRMSRV.EXE
set module SRVMRD
set module ALLGBL
!
! 25-Oct-1990 /AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) corrects the
! following problems:
!
! 1) When a message with a subject string longer than 132 characters is
!    received by MRMEMO (from Message Router), internal data areas in
!    MRMEMO are corrupted.
!
! 2) When a message with a uacontid string longer than 128 characters is
!    received by MRMEMO (from Message Router), MEMO will reject the message
!    with feedback codes 02, 0D.
!
set eco 6
insert/instruction SRV$MRD_GETSTR+0A5 = 'PUSHAB  B^10(SP)'
'CMPL R3,#ALLGBL\$GLOBAL$+1E730'
'BEQL L1'
'CMPL R3,#ALLGBL\$GLOBAL$+1E57C'
'BNEQ L2'
'L1: MOVZBW #80,(R3)'
'L2: NOP'
exit
update

    When the SHUT command is used from MRMMAN to stop the MRMEMO server and
    the message 

	%MRMEMO-I-SRVSTATUS, returned status from server n is:
	-MRMEMO-I-SHUTTING, server shutting down

    has been displayed, the server will usually shut down in a short time.
    Sometimes the server does however NOT shut down.

    This can happen if the SHUT command is used while the server is
    restarting due to some error (e.g. failure to connect to Message
    Router). The restart routine erroneously clears a flag in the server,
    making it forget about the SHUT request.

    The patch below can be applied to MRMEMO V2.1 to fix this problem.

---------------------------------------------------------------------------

MRMSRV.EXE
set module SRVMMO
set module SRVGBL
!
! 15-Nov-1990 /AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When giving the SHUT command from MRMMAN, the server will sometimes not
! shutdown despite the message
!
!     %MRMEMO-I-SRVSTATUS, returned status from server n is:
!     -MRMEMO-I-SHUTTING, server shutting down
!
! being displayed by MRMMAN.
!
set eco 7
insert/instr SRV$MMO_INIT+37D = -
			'MOVC5 #0,(SP),#20,#1E,L^SRVGBL\$GLOBAL$+21C'
'CLRL L^SRVGBL\$GLOBAL$+2374'
exit
replace/instr SRV$MMO_ONE_LIFE+99 = 'CLRL L^SRVGBL\$GLOBAL$+2374'
'EXTV #0,#1,L^SRVGBL\$GLOBAL$+2374,R0'
'CLRL L^SRVGBL\$GLOBAL$+2374'
'INSV R0,#0,#1,L^SRVGBL\$GLOBAL$+2374'
exit
update

    There is a problem in V2.1 when using the logical name MRMEMO$LOGMASK to
    obtain additional logging information (note that MRMEMO$LOGMASK is not
    supported or documented).

    MRMEMO$LOGMASK is interpreted as a (hexadecimal) sum of the different
    logging values. The values for MRMEMO V2.1 are listed below.

	    Value Logs info about

	     1    DECnet events
	     2    General events
	     4    Data to/from Memo (one line of info per byte)
	    10    State transitions
	    20    Formatted data sent to Memo
	    40    SNA API events

    When the value 4 is included, the whole data buffer sent to or received
    from Memo is logged with one byte of buffer info per line. E.g.

	offset     2260:   %d '126'   %x '7E'   %decmcs '~',   %ebcdic '='

    There is a bug in MRMEMO V2.1 that causes the log routine to display the
    contents of the whole message buffer (which is 500 Kbytes - the maximum
    possible message size), instead of just the part of the buffer where
    the message that is to be sent to Memo resides.

    Logging 500K lines of text is quite a lot, so don't use value 4 in
    MRMEMO$LOGMASK unless you have installed this patch.

---------------------------------------------------------------------------

MRMSRV.EXE
set module ALLPAC
!
! 20-Nov-1990 /AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When using the (unsupported!) logging feature in the MRMEMO Server by
! including the value 4 in the logical name MRMEMO$LOGMASK, the log can
! mistakenly dump the whole message buffer (500 Kbytes) instead of just the
! part containing the message.
!
set eco 8
replace/instr ALL$PAC_END_GIU+2E = 'PUSHL B^0C(R0)'
'PUSHL B^08(R0)'
exit
update

    There is a problem in V2.1 (and probably older versions too), when using
    the maximum allowed number (3) of replacement sequences (MRMMan command
    DEFINE /REPLACE).

    When 3 replacement sequences are used, the server doesn't find the end
    of the replacement string data and might crash or produce erroneous
    replacement results when it interprets other data as replacement strings.

    There is no problem if less than 3 sequences are used.

    The patch below will correct the problem for V2.1.
---------------------------------------------------------------------------

MRMSRV.EXE
set module ALLCNV
set module ALLGBL
!
! 14-Dec-1990/AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When using three replacement sequences (DEFINE /REPLACE), the server will
! probably crash.
!
set eco 9
repl/instr ALLCNV\ALL$CNV_SYNTAX+4B
'CMPL    B^04(AP),#00000B2A'
exit
'CMPL R6,#$GLOBAL$+1E264+24'
'BLSSU L1'
'JMP ALLCNV\ALL$CNV_SYNTAX+10F'
'L1: CMPL    B^04(AP),#00000B2A'
exit
update

    There is a problem in MRMEMO when a message does not contain a USERID.
    In some places, MRMEMO expects the USERID to be present and references
    a null pointer, resulting in an access violation.

    This problably mostly happens when X.400 is involved since USERID is more
    likely to be missing then.

    The patch below will probably correct the problem in most situations
    for V2.1. This is not a real solution, since what the patch does is to
    fake a dummy USERID ("?NO_USERID?") when it's missing.
---------------------------------------------------------------------------

MRMSRV.EXE
set modu SRVMRD
set modu SRVDDS
!
! 05-Jun-1991 /AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When a message arriving from Message Router is disassembled by MRMEMO and
! there is no USERID in some part of the message where MRMEMO expects this,
! MRMEMO crashes.
!
set eco 11
insert/instr SRVMRD\SRV$MRD_DISASS\SRV$MRD_GETORNAM+79 = 'MOVZBL #69,B^08(SP)'
'MOVL (R3),R4'
'TSTL B^4(R4)'
'BNEQ L1'
'PUSHAB SRVMRD\$PLIT$+11C'
'PUSHL #010E000B'
'PUSHAQ (SP)'
'CALLS #1,SRV$DDS_TO_BOUND'
'ADDL #8,SP'
'MOVL R0,B^4(R4)'
'L1: NOP'
exit
update

    
    The patch below filters out all Delete Notification messages so that
    they will not enter the Message Router. Please read instructions
    and Note 102.9 carefully before applying.
    
---------------------------------------------------------------------------

MRMSRV.EXE
set modu SRVACT
!
! 04-Dec-1991 /SP
!
! NOTE: This is a feature patch, not a bug correction. It works around 
! bugs in MEMO at the expense of MRMEMO functionality.
!
! Do  not apply it unless you are communicating with MEMO V3.1.3 or later
! and see problems with unexpected notification messages from MEMO. Read the
! below description carefully.
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) prevents MRMEMO
! from issuing Delete Notification messages. Delete Notification support
! is a MEMO specific functionality, ie it works between two MEMO systems only.
! MRMEMO supports this functionality between MEMO systems (
! MEMO <-> MRMEMO <->MEMO) through use of Domain Defined attributes
! in ordinary delivery Notification messages. Normally, these messages should
! never get sent to MR users, but it they do the receiving User Agents will not 
! be able to distinguish them from common delivery notifcations. There are
! bugs in MEMO 3.1.3 (and later?) that make MEMO send delete notification 
! messages although it shouldn't
! 
set eco 14
repl/instr SRVACT\SRV$ACT_R\TEST_REASON+37 = 'CMPB    B^05(SP),#08'
'brb SRVACT\SRV$ACT_R\TEST_REASON+3D'
exit
update

    
    The patch below filters out all Receipt Notification messages so that
    they will not enter the Message Router. Please read instructions
    and Note 102.9 carefully before applying.
    
---------------------------------------------------------------------------

MRMSRV.EXE
set modu SRVACT
!
! 06-Dec-1991 /SP
!
! NOTE: This is a feature patch, not a bug correction. It works around 
! bugs in MEMO at the expense of important MRMEMO functionality. Please make 
! sure you understand the consequences by applying this patch, and don't do
! it unless you feel you really have to. If in doubt, don't.
!
! Do  not apply it unless you are communicating with MEMO V3.1.3 or later
! and see problems with unexpected receipt 
! notification messages from MEMO. Read the below description carefully.
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) prevents MRMEMO
! from issuing Receipt Notification messages. Normally, these messages should
! get sent to MR users only when requested, but there are bugs in MEMO 3.1.3 
! (and later?) that under certain circumstances make MEMO send receipt
! notification messages although it shouldn't
!
set eco 15
repl/instr SRVACT\SRV$ACT_R\TEST_REASON+2B = 'CMPB    B^05(SP),#10'
'brb SRVACT\SRV$ACT_R\TEST_REASON+31'
exit
update

    
    MRMEMO V2.1 was modified from previous versions so that the original
    size limit of 50 Kb/message was changed to 500 Kb. This reflects
    signals from Verimation that MEMO 3.1 would support this message size.
    This means that messages smaller than 500 Kb would be transferred to
    MEMO, and it would then be MEMO's responsibility to reject the message
    if it were too large for MEMO. For messages larger than 500 Kb, MRMEMO
    would truncate the message at 500 Kb, and put a text line at the bottom
    of the message basically saying that the message has been truncated.
    
    However, there is a bug in MRMEMO V2.1 which makes the server
    crash at this stage with fatal error message MRMEMO-F-STRANGE
    "Internal error in MRMEMO Gateway".
              
    This bug is corrected by the patch below, however at
    the expense of supported message size. The messages will now
    instead be truncated at the size of roughly 50 Kb.  Note that
    this reflects the size of the message as received from the
    Message Router. The message sent to MEMO will be larger because
    it will contain padded blanks for each text line that is smaller
    than the maximum line length. It is still the responsibility of
    MEMO to decide whether the size of the message can be supported.

----------------------------------------------------------------------------

MRMSRV.EXE
set modu SRVMRD
!
! 15-Nov-1991 /SP
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When a message arriving from Message Router is disassembled by MRMEMO and
! the size is larger than 500K, the server crashes with MRMEMO-F-MESSED. This 
! patch truncates all message at approx 49K and send them over to MEMO.
!
set eco 12
replace/instr SRVMRD\SRV$MRD_DISASS+3B = 'MOVAB 0AF384,SRVMRD\$OWN$'
'MOVAB 040970,SRVMRD\$OWN$'
exit
update

    A significant memory leak has been found in MRMEMO, where approx. 128
    KBytes of memory are sometimes lost when a message from MR is not
    forwarded to MEMO.

    This is most likely to occur when DDS MR SENDER validation is used.
    When an unauthorized MR sender attempts to send to MEMO, the message
    is rejected (with MR diagnostic "The message originator is not
    authorized to use the Gateway") and memory is lost.

    The patch below should take care of this problem (i.e. prevent memory
    from being lost).

----------------------------------------------------------------------------

MRMSRV.EXE
set module SRVMRD
!
! 5-May-1992 /AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
! 
! When MRMEMO decides not to pass a message from MR to MEMO (e.g. due to
! DDS MR sender validation failure), some cleanup is not properly done.
! This can cause large amounts of virtual memory to be 'lost', eventually
! causing MRMEMO to crash in lack of memory.
!
set eco 17
verify/instruction SRV$MRD_SBJNOT-0B3 = 'PUSHAB B^34(SP)'
verify/byte SRV$MRD_SBJNOT-0B0 = 0FB, 01, 0FF
examine/long
define ENDIS = . + \ + 4
replace/instruction SRV$MRD_DISASS+3D9='MOVL #08938208,R0'
'PUSHAB B^34(SP)'
'CALLS  #1,@L^ENDIS'
'PUSHAB B^38(SP)'
'CALLS  #1,@L^ENDIS'
'MOVL   #08938208,R0'
exit
update

    
    This fix applies only to MRMEMO sites that have two or more servers
    running simultaneously and require document conversion from WPSPLUS or
    DX. The fix will work on all sites though, and it is recommended that it's
    installed.
    
    When MRMEMO performs conversion of WPSPLUS to ASCII it calls the Document
    Conversion Facility (DCF). This facility uses the temporary file
    DCF_WPS_ASCII_TMP.WPL in the default directory. Since the default
    directory is the same for all MRMEMO Servers this can and will lead
    to mix-ups if two servers call DCF at the same time. Thus, on rare
    occasions it will happen that the text of a message being handled on
    one server is included in another message being handled on another server!
    
    To fix this problem do the following: Create a subdirectory to
    MRMEMO$DIR, [.SRVn] for each of your servers.
    
    Then replace MRMEMO$DIR:MRMEMO.COM with the appended routine and
    restart all servers.
    
---------------------------------------------------------------------------

$! M r m e m o . C o m  - comments and copyright notice at the end
$!
$ set noon
$ set verify
$!
$! eco18 start of fix     
$!
$ prcnam = f$getjpi (0,"PRCNAM")
$ srvnum = f$extract (14,1,prcnam)
$ if f$search("SRV''srvnum'.dir") .eqs. "" then goto nosrvdir
$ defdir = "[.SRV''srvnum']"
$ set default 'defdir'
$ nosrvdir:
$!
$! eco18 end of fix     
$!
$ define tt nl:
$ run/nodebug sys$system:mrmsrv
$ logout

File:       mrmsrv:mrmemo.com
Ident:      V2.1-eco18
Facility:   MR/MEMO
Title:      MR/Memo Server Process Command Procedure

Edits: 	Ident	Date	     Sign & #	Description

	T1.0-1	1987-04-27	GM001	Creation
	V2.1	1992-08-27	SP001	Set default to server specific 
					directory (further explanation at end)

*= EON <File name> <Title> =*

                         Copyright (c) 1987 by
           Digital Equipment Corporation, Sundbyberg, Sweden

This software is furnished under a license and may be used and  copied
only  in  accordance  with  the  terms  of  such  license and with the
inclusion of the above copyright notice.  This software or  any  other
copies  thereof may not be provided or otherwise made available to any
other person.  No title to and ownership of  the  software  is  hereby
transferred.

The information in this software is subject to change  without  notice
and  should  not  be  construed  as  a commitment by Digital Equipment
Corporation.

Digital assumes no responsibility for the use or  reliability  of  its
software on equipment which is not supplied by Digital.

++ des

   This file is run within the server process, which is started with
   Loginout. The purpose of this way of starting the server is to
   add DCL to the server process, giving better control, logging
   possibilies etc. to the server.

   920827: 
	Determine server no out of process name and set default to server 
	specific subdirectory. If this subdirectory does not exist we'll
	just continue to run where we are

-- des

    
    There is a bug in MRMEMO that makes the server crash when it receives
    Non-Receipt Notification messages. This becomes increasingly more
    likely the more communication to external X.400 systems you have. The
    log file will show the entry 
    
    %MRIF-E-WRONGPOS, not positioned on specified element
    
    (see 139.0 for further problem statement)
    
    The patch below will correct this problem and generate a TEXT message
    indicating the Non-Receipt status of the message. This message will be
    sent to the MEMO originator.
    
---------------------------------------------------------------------------

!
! 22-Sep-1992
!
! This patch makes the MRMEMO server accept Non-Receipt Notification
! Messages from the Message Router and convert them to TEXT messages
! that indicate the status of the message to the MEMO originator.
!
MRMSRV.EXE                                                       
set module SRVMRD
set module SRVGBL
set module ALLPAC
!
!
!
set eco 19
verify/instruction SRV$MRD_PRSNT_RECEIPT+2C = 'PUSHAB L^SRVGBL\$GLOBAL$+1824CC'
verify/byte SRV$MRD_PRSNT_RECEIPT+32 = 0FB, 4, 0FF
examine/long
define FIND = . + \ + 4
replace/instruction SRV$MRD_PRSNT_NONRECEIPT+0D = 'ADDL3 #01,(R2),B^04(SP)'
'MOVZBL #69,B^4(SP)'
'PUSHAB B^4(SP)'
'PUSHL  R3'
'MOVZBL #0E7,B^8(SP)'
'PUSHAB B^8(SP)'
'PUSHAB L^SRVGBL\$GLOBAL$+1824CC'
'CALLS  #4,@L^FIND'
'BLBS   R0,L1'
'RET'
'L1: ADDL3 #01,(R2),B^04(SP)'
exit
!
!
!
define ITMLST1 = SRVGBL\$GLOBAL$+23DC
replace/instruction SRV$MRD_PRSNT_NONRECEIPT+0C4 = 'MOVL #089384A1,R0'
'PUSHL #1'
'PUSHAL (SP)'
'PUSHAB ITMLST1'
'CALLS #2,L^ALL$PAC_FIND_ITEM'
'TSTL (SP)+'
'TSTL R0'
'BEQL L2'
'MOVL #0CD0101,B^4(R0)'
'L2: MOVL #089384A1,R0'
exit
UPDATE
    

    There is a bug in the MRMEMO routine that converts dates/times from VMS
    to MVS format. The effect of this bug is that the MRMEMO server crashes
    if an attempt is made to convert a date/time representing the first day
    of the year (1-JAN-xxxx).

    Several User Agents sending messages from MR to MEMO do *not* produce any
    date message elements that are subject to conversion in MRMEMO.
    One major User Agent that *does* produce such date fields is, however,
    ALL-IN-1 IOS.

    The patch below will make MRMEMO properly convert all dates.

----------------------------------------------------------------------------

MRMSRV.EXE
set module ALLCNV
!
! 24-Sep-1992 /AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! MRMEMO crashes when trying to convert dates from VMS to MVS format if
! the date is the first day of a year (i.e. 1-JAN-xxxx).
!
set eco 20
verify/byte ALL$CNV_TO_BINTIM+16 = 0FB, 01, 0FF
examine/long
define SIGA = . + \ + 4
!
verify/instruction ALL$CNV_TIM_VMS_MVS+13B = 'CLRB @B^8(AP)'
replace/instruction ALL$CNV_TIM_VMS_MVS+0B8 = -
    'MOVC3 #7,L^ALLCNV\$PLIT$+0A0,B^14(SP)'
'MOVAL  SIGA,R0'
'ADDL3  (R0),#600,R0'
'CLRL	-(SP)'
'MOVL	#2,-(SP)'
'PUSHAQ B^34+8(SP)'
'PUSHAL B^8(SP)'
'PUSHAL B^8(SP)'
'CALLS  #3,(R0)'
'MOVW   B^4(SP),B^0+8(SP)'
'ADDL   #8,SP'
'BRW    ALL$CNV_TIM_VMS_MVS+13B'
exit
update

    When DDS validation is enabled in outgoing direction (MR senders or 
    MEMO recipients) MRMEMO will attempt to validate receipt notifications.

    If the validation fails, MRMEMO will crash with the error message:

%MRIF-E-INVALIDMSG, file does not contain specified message part

    This patch modifies MRMEMO's behaviour so that DDS validation is not
    attempted on outgoing receipt notification messages

---------------------------------------------------------------------------

MRMSRV.EXE
set module SRVMRD
!
! 05-Nov-1992/SP
!
! This patch for the MRMEMO V2.1 Server image (MRMSRV.EXE) fixes the following
! problem:
!
! When outgoing Receipt Notification messages arrive and DDS validation 
! is enabled and any of the lookups fail, the server will crash with the 
! error message 
!
! %MRIF-E-INVALIDMSG, file does not contain specified message part
!
set eco 22
insert/instr SRVMRD\SRV$MRD_DISASS+143 = 'MOVL #00CD0301,B^0C(SP)'
'MOVL #01,L^SRVMRD\$OWN$+19F0'
exit
update

    This patch replaces the old ECO 21 (former 5.18) We accidentally put in
    an erroneous test version. That version will run into a CPU loop if an
    address containing three consecutive quotes (or more?) arrives from
    MEMO. If you have installed that patch, please apply this one instead
    on the original MRMSRV.EXE. Sorry for any inconvenience caused .
    
    There is a problem in V2.1 when a message arrives with double qoutes in 
    the address. A message with the address VAX.""USER""..ROUTE will be
    transformed into a message router address with No Userid. This will
    cause the MRMEMO Server to crash with MRIF-F-MISSUSERID, and then it
    will go into a "looping restart"

    This patch will make sure that the message is instead returned to the 
    MEMO sender with Service Message diagnostic "Invalid Message Syntax"

---------------------------------------------------------------------------

MRMSRV.EXE
set module SRVMRA
!
! 02-Nov-1992/SP
! 25-Nov-1992/AO
!
! This patch for the MRMEMO V2.1 Server image (MRMSRV.EXE) fixes the following 
! problem:
!
! When incoming address parsing results in an empty Userid string the message
! is returned with diagnostic "Invalid syntax"
!
set eco 21
insert/instr SRV$MRA_RCP_TO_ORNAME+0F9 =  'CLRL (R7)'
'TSTW W^0FDF8(FP)'
'BNEQ L1'
'MOVL I^#08938190,R0'
'BRW SRVMRA\SRV$MRA_RCP_TO_ORNAME+28A'
'L1: NOP'
exit
update

    
    The old 5.18 has been replace by 5.20

    MEMO 3.1, included a new feature: "Transparent Transport". This gives
    a MEMO user the ability to forward binary messages (e.g. a word processor
    specific docuent from a PC).

    MRMEMO V2.1 (and earlier) does not support binary messages. When a binary
    message arrives from MEMO, MRMEMO responds with an error message that
    tells MEMO/GWY in the IBM that something is very wrong. This causes
    MEMO/GWY to disable the connection to the unhappy MRMEMO, waiting for
    an IBM operator to step forward and restart the connection.

    Since the MEMO/PC population is growing out there, more and more binary
    messages will probably arrive to MRMEMO at various sites, causing MEMO/GWY
    to stop.

    The patch below changes MRMEMO's behavior so that instead of sending the
    fatal message back, a standard non-delivery message is returned. Note
    that the (binary) document part will no longer be binary when returned
    to MEMO in the non-delivery message.

    The returned document part will be flagged as a normal memo text message
    (since that is the only format MRMEMO knows about).
    Furthermore, in the non-delivery process, the message has been translated
    from EBCDIC to ASCII and then back again, so the returned contents is
    most likely *not* identical to the original.

---------------------------------------------------------------------------

MRMSRV.EXE
set module ALLPAC
set module ALLUNP
set module SRVGBL
set module SRVMRA
!
! 18-Dec-1992/AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) corrects the
! following problem:
!
! When a binary message is sent from MEMO, MRMEMO responds with an error
! message that causes MEMO/GWY in the IBM system to disable the connection.
! This results in repeated UNBINDs arriving to MRMEMO and no connection can
! be established. IBM operator intervention is required to restart the
! connection.
!
! After applying this patch, binary message will be rejected by MRMEMO in
! a more polite way. The MEMO sender will get an error message back in the
! same way as for other non-devlivery reasons.
!
set eco 24
replace/instruction ALL$UNP_DOCPROFIL+1A5
'TSTB	B^02(R6)'
'BNEQ	ALL$UNP_DOCPROFIL+1CB'
'MOVL	#1,B^08(SP)'
exit
'MOVZBL	B^02(R6),R0'
'ADDL3	R0,#1,B^08(SP)'
exit
!
insert/instruction SRV$MRA_SND_ORNAME+59 = -
		 'CALLS #02,W^SRV$MRA_SND_TO_ORNAME'
'BLBC	R0,L2'
'PUSHL	#10'
'PUSHAL	(SP)'
'PUSHL	L^SRVGBL\$GLOBAL$+10'
'CALLS	#2,L^ALL$PAC_FIND_ITEM'
'ADDL	#4,SP'
'TSTL	R0'
'BEQL	L1'
'CMPL	B^04(R0),#1'
'BEQL	L1'
'MOVL	#08938190,R0'
'BRB	L2'
'L1: MOVL #1,R0'
'L2: NOP'
exit
update

    Binary bodyparts that arrive to MRMEMO from MR are subject to conversion.
    MRMEMO can convert CDA documents and WPS-PLUS documents to text. WPS-PLUS
    conversion is quite straight forward but CDA is more complicated since
    there are many different document formats.

    The task of selecting the correct converter is made by the CDA conversion 
    software (MRMEMO just calls CDA$CONVERT). Sometimes it can happen that
    CDA$CONVERT returns the status "%CDA-E-OCVNOTFND, output converter not 
    found", which causes MRMEMO to crash (and restart indefinitely).

    The patch below makes MRMEMO regard the %CDA-E-OCVNOTFND status (and any
    other unexpected status) as non-fatal, allowing the message to reach MEMO 
    - with the unconverted bodypart replaced by an informational message.

---------------------------------------------------------------------------

MRMSRV.EXE
set module SRVMRD
!
! 22-Apr-1993 /SP+AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! MRMEMO crashes when attempting to convert a document from MR and there
! is no suitable converter found. The error message in the log file is 
!
!     %CDA-E-OCVNOTFND, output converter not found
!
! The patch below hides the problem by converting all unexpected errors from
! CDA conversion to status cda$_unsupfmt. This causes a line of informational
! text to be included in the message sent to MEMO, informing the recipient
! about the fact that part of the original message was ignored.
!
set eco 26
examine/long SRV$MRD_DISASS_TEXT+41E
define TMP = . + \ + 4
replace/instr SRV$MRD_DISASS_TEXT+413
'MOVL    R1,R0'
'BLBS    R0,SRVMRD\SRV$MRD_DISASS\SRV$MRD_DISASS_TEXT+422'
'PUSHL   R0'
'CALLS   #01,@L^TMP'
exit
'MOVL    #01,(SP)'
'MOVL    #0893C869,R2'
'BRB     SRVMRD\SRV$MRD_DISASS\SRV$MRD_DISASS_TEXT+422'
exit
update

    There is a timing problem in MRMEMO that can be exposed when a slow
    MRMEMO server communicates with a fast MEMO system. E.g. when MRMEMO
    runs on a small overloaded �VAX and/or communicates with a fast
    channel SNA/Gateway.

    Under these conditions, an AST routine is sometimes triggered before
    MRMEMO expects it to happen. This causes MRMEMO to become confused
    about its internal state, output the following message and restart:

       %MRMEMO-F-STRANGE, non-expected event for current state

    This error is in general harmless since MRMEMO restarts automatically,
    but if it occurs often or is regarded as a nuisance, the patch below
    will probably help.

    In case anyone wonders why this over two years old patch hasn't been
    published until now, it's because the original target system for the
    patch was tuned/upgraded and stopped exhibiting the problem before the
    patch was evaluated. Now the problem has appeared again (see note 177),
    the patch was tested and seems to work.

---------------------------------------------------------------------------

MRMSRV.EXE
set module SRVDSP
set module SRVACT
set module ALLGBL
set module SRVGBL
!
! 12-Mar-1991 /AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) corrects the
! following problem:
!
! When the MRMEMO server is running on a slow machine and is communicating
! with a fast MEMO/Gateway, the server can sometimes output the message
!
!     %MRMEMO-F-STRANGE, non-expected event for current state
!
! followed by a traceback.
!
set eco 10
insert/instruction SRV$DSP_FSM+211 = 'MOVW #2,L^SRVGBL\$GLOBAL$+236E'
'	PUSHL	SP'
'	CLRL	-(SP)'
'	CALLS	#2,@#7FFEDFD0'
'	BBS	#2,(SP),L1'
'	RET'
'L1:	BLBC	L^ALLGBL\$GLOBAL$+44,L2'
'	RET'
'L2:	CALLS	#0,SRV$ACT_E'
'	MOVW	R0,L^SRVGBL\$GLOBAL$+236E'
exit
update

    There is a problem in MRMEMO that can cause SNA communication to stop and
    repeatedly display the message

        %SNA-E-SESIN_USE, session address is already in use

    in the log file.

    This happens when MRMEMO receives a negative response (on the SNA level)
    from MEMO/GWY. MRMEMO doesn't handle negative responses very well. The
    internal state is messed up and MRMEMO suddenly believes that it needs
    to connect to MEMO/GWY. But since there already is a connection (which
    MRMEMO has forgotten about), the connect attempt fails. 

    The patch below will make MRMEMO restart if a negative response is
    received. This will (among other cleanup actions) tear down the SNA
    connection and put the MRMEMO server in a known state again.

---------------------------------------------------------------------------

MRMSRV.EXE
set module SRVDSP
set module SRVACT
!
! 30-Apr-1993/AO
!
! This patch for the MRMEMO V2.1 Server image (MRMSRV.EXE) fixes the following
! problem:
!
! If MRMEMO receives a negative response (-RSP) on the SNA communication
! line, MRMEMO goes into a starting state. This causes message traffic to
! stop and the message
!
!     %SNA-E-SESSIN_USE, session address is already in use
!
! is repeated indefinitely in the MRMEMO log file.
!
! After applying this patch, the MRMEMO server will instead disconnect the
! SNA session and reconnect again if a negative response is received.
!
set eco 27
!
ex/long SRV$DSP_FSM+72
define LIBSIG = . + 4 + \
verify/instruction SRV$DSP_FSM+6F = 'CALLS #4,@L^LIBSIG'
define ERRCOD = 089387FA
!
replace/instruction SRV$DSP_FSM+150
'CALLS #0,L^SRV$ACT_N'
'MOVW #4,L^34502'
exit
'PUSHL #ERRCOD'
'CALLS #1,@L^LIBSIG'
exit
!
replace/instruction SRV$DSP_FSM+220
'CALLS #0,L^SRV$ACT_N'
'MOVW #4,L^34502'
exit
'PUSHL #ERRCOD'
'CALLS #1,@L^LIBSIG'
exit
!
replace/instruction SRV$DSP_FSM+2E9
'CALLS #0,L^SRV$ACT_N'
'MOVW #4,L^34502'
exit
'PUSHL #ERRCOD'
'CALLS #1,@L^LIBSIG'
exit
!
update

MRMSRV.EXE
set module srvmra
!
! 13-Sep-1993/SP
!
! This patch for the MRMEMO V2.1 Server image (MRMSRV.EXE) fixes the
! following problem.
!
! The recipient address of Delivery Notifications will not be correctly
! specified if the recipient is an X.400 user (via MRX). The recipient's 
! standard attributes will be present, but not the tagged Route elements
! (1=<country> etc). This may cause problems at some X.400 MTAs
!
! The patch will ensure the Route elements are there
!
set eco 30
!
replace/instruction SRVMRA\SRV$MRA_CHK_ONE_RCP+0A0 = 'BISL3 R9,@B^00(SP),B^1C(SP)'
'MOVL #01,B^1C(SP)'
exit
!
update
    

MRMSRV.EXE
!
! 24-Jan-1995/SP
!
! This patch for VAX Mailgate for MEMO V2.1 fixes the following problem:
! Version 3.1 of ALL-IN-1 has started to display the NBS Contents FROM element
! attribute "FREEFORM" to the ALL-IN-1 users instead of "SURNAME", that was
! used before V3.1. This patch will make sure that "FREEFORM" is part of
! the MRMEMO FROM element
!
set module str_utils
set eco 36
repl/inst STR_UTILS\STR_UTILS$ELAB+5D+1D4351-1D2D40 = 'XORB3 #01,R9,W^0FED3(FP)'
'MOVB    R9,R10'
'MOVB    #01,W^0FED3(FP)'
exit
set modul srvmra
replace/instr SRVMRA\SRV$MRA_SND_ORNAME+0CB = 'PUSHAB  B^10(SP)'
'PUSHAB  B^10(SP)'
'MOVL    #06,B^08(SP)'
'PUSHAB  B^08(SP)'
'PUSHAB  L^000321A4'
'CALLS   #03,W^SRVMRA\SRV$MRA_FNDSTR'
'BLBC    R0,LBL1'
'MOVL    (R3),R0'
'TSTL    B^54(R0)'
'BNEQ    LBL1'
'PUSHL   R3'
'MOVL    #0893C699,B^08(SP)'
'PUSHAB  B^08(SP)'
'PUSHAB  B^18(SP)'
'CALLS   #03,L^001ECBA9'
'BLBS    R0,LBL1'
'PUSHL   R0'
'CALLS   #01,@L^002575BC'
'LBL1:	 PUSHAB  B^10(SP)'
exit
update

MRMSRV.EXE
set module SRVMRD
!
! 15-Apr-1994/AO
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When MRMEMO tries to fetch an MR message with an unknown or unsupported
! format (e.g. a probe message or a non-p2 message), the server will crash.
!
! The following patch will make MRMEMO reject the message, which will end up
! as a .NBS_BAD file in the Message Router storage area MR$NBS.
!
set eco 32
replace/instr SRV$MRD_DISASS+111
'MOVL    #089383C3,R0'
exit
'MOVL    #089383C0,R0'
exit
replace/instr SRV$MRD_DISASS+156
'MOVL    #089383C3,R0'
exit
'MOVL    #089383C0,R0'
exit
replace/instr SRV$MRD_DISASS+160
'MOVL    #089383C3,R0'
exit
'MOVL    #089383C0,R0'
exit
replace/instr SRV$MRD_DISASS+16A
'MOVL    #089383C3,R0'
exit
'MOVL    #089383C0,R0'
exit
update

MRMSRV.EXE
set module SRVMRA
!
! 22-Aug-1994/SP
!
! This patch for the MRMEMO V2.1 server image (MRMSRV.EXE) fixes the following
! problem:
!
! When MRMEMO receives an MR message where the sender address contains '@' chrs
! (eg. from Internet) the sender address will be quoted. If replied to the
! quotes will be removedin the recipient address. However with the recent
! addition of "set forward"  functionality in MEMO the sender address will
! contain quotes if the message is forwarded back into MR. This causes all
! sorts of problems
!
! The following patch will make MRMEMO "unquote" MEMO sender addresses
!
set eco 33
insert/instruction SRVMRA\SRV$MRA_NONDEL+56 = 'MOVL R0,B^04(R2)'
'MOVL    #01,B^04(SP)'
'PUSHAB  B^04(SP)'
'ADDL3   #04,B^0C(SP),-(SP)'
'CALLS   #02,W^SRVMRA\SRV$MRA_UNQUOTE_STR'
exit
replace/instr SRVMRA\SRV$MRA_SND_ORNAME+44
'BLBS    R0,SRVMRA\SRV$MRA_SND_ORNAME+54'
'PUSHL   #0893803C'
'CALLS   #01,@L^002575BC'
exit
'BLBS    R0,L101'
'PUSHL   #0893803C'
'CALLS   #01,@L^002575BC'
'L101: MOVL    #01,B^04(SP)'
'PUSHAB  B^04(SP)'
'PUSHAB  B^14(SP)'
'CALLS   #02,W^SRVMRA\SRV$MRA_UNQUOTE_STR'
exit
insert/instr SRVMRA\SRV$MRA_UNQUOTE_STR+2 = 'MOVL B^04(AP),R3'
'SUBL2   #1C,SP'
'MOVL    B^04(AP),R3'
'MOVAB   B^04(R3),R2'
'CMPB    (AP),#01'
'BLEQU   L1'
'TSTL    B^08(AP)'
'BEQL    L1'
'MOVL    @B^08(AP),R5'
'BRB     L2'
'L1: CLRL    R5'
'L2: CLRL    (SP)'
'L4: MOVAB   (SP),R0'
'CMPZV   #00,#10,(R3),R0'
'BLEQ    L3'
'ADDL3   (SP),(R2),R1'
'CMPB    (R1),#20'
'BNEQ    L3'
'INCL    (SP)'
'BRB     L4'
'L3: CMPB    (AP),#01'
'BLEQU   L5'
'TSTL    B^08(AP)'
'BEQL    L5'
'BLBC    R5,L5'
'MOVL    #010E0000,B^14(SP)'
'MOVAB   B^04(SP),B^18(SP)'
'MOVL    #010E0000,B^0C(SP)'
'MOVAB   B^08(SP),B^10(SP)'
'MOVB    #22,B^04(SP)'
'MOVB    #27,B^08(SP)'
'MOVW    #01,B^14(SP)'
'MOVW    #01,B^0C(SP)'
'PUSHAB  B^14(SP)'
'PUSHL   R3'
'CALLS   #02,@L^002575A0'
'MOVL    R0,(SP)'
'BEQL    L6'
'CLRL    R4'
'DECL    (SP)'
'BRB     L7'
'L6: PUSHAB  B^0C(SP)'
'PUSHL   R3'
'CALLS   #02,@L^002575A0'
'MOVL    R0,(SP)'
'BEQL    L8'
'MOVL    #01,R4'
'DECL    (SP)'
'BRB     L7'
'L8: MOVL    #089384A1,R0'
'BRW     L9'
'L5: ADDL3   (SP),(R2),R1'
'CMPB    (R1),#22'
'BNEQ    L10'
'CLRL    R4'
'BRB     L7'
'L10: ADDL3   (SP),(R2),R1'
'CMPB    (R1),#27'
'BNEQ    L11'
'MOVL    #01,R4'
'BRB     L7'
'L11: MOVL    #089384A1,R0'
'BRW     L9'
'L7: BLBC    R5,L22'
'MOVL    (SP),R0'
'BRB     L12'
'L22: CLRL    R0'
'L12: INCL    (SP)'
'L17: CMPZV   #00,#10,(R3),(SP)'
'BLEQ    L13'
'BLBC    R4,L14'
'ADDL3   (SP),(R2),R1'
'CMPB    (R1),#27'
'BNEQ    L15'
'BLBC    R5,L16'
'INCL    (SP)'
'BRB     L17'
'L16: MOVW    R0,(R3)'
'MOVL    #089384A1,R0'
'BRB     L9'
'L15: ADDL3   (SP),(R2),R1'
'MOVB    (R1),@B^00(R2)[R0]'
'INCL    R0'
'INCL    (SP)'
'BRB     L17'
'L14: ADDL3   (SP),(R2),R1'
'CMPB    (R1),#22'
'BNEQ    L18'
'ADDL3   (SP),(R2),R1'
'CMPB    B^01(R1),#22'
'BNEQ    L19'
'ADDL3   (SP),(R2),R1'
'MOVB    (R1),@B^00(R2)[R0]'
'INCL    R0'
'ADDL2   #02,(SP)'
'BRB     L17'
'L19: BLBC    R5,L21'
'INCL    (SP)'
'BRB     L17'
'L21: MOVW    R0,(R3)'
'MOVL    #089384A1,R0'
'BRB     L9'
'L18: ADDL3   (SP),(R2),R1'
'MOVB    (R1),@B^00(R2)[R0]'
'INCL    R0'
'INCL    (SP)'
'BRB     L17'
'L13: BLBC    R5,L20'
'MOVW    R0,(R3)'
'L20: MOVL    #089384A1,R0'
'L9: RET'
exit
update