| Title: | VAX MAILGATE for MEMO |
| Moderator: | STKHLM::OLSSON |
| Created: | Sat Feb 25 1989 |
| Last Modified: | Tue May 14 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 216 |
| Total number of notes: | 933 |
Hey ! I was today to one customer who reported few problems that they are currently having with their post-machine. I would appreciate if somebody could give a comment on these. 1. MRMEMO server replacement characters In the MRMEMO server you can use specific replacement characters to translate characters in the address field of messages going through the mrmemo server. Our customer is reporting, that when they try to insert a third replacement character after having two previously (it worked fine with two) the third does not work. Instead the server crashes when it encounters the specific character in the address. So our question is: Is there a limitation of only using max 2 replacement characters in the DEFINE/REPLACE definition or why IS IT NOT WORKING ? 2. WRONG POSITION ----------------- A customer has updated their X.400 software and after that they have had a new problem. I know that we should ofcourse try to first investigate what has been changed in the remote end software, but I would like to know if anybody can comment this error. Maybe something is obvious from the error message or the NBS file dump ? When our customer sends a X.400 message from their MEMO system through the MRMEMO server to a specific customer, they find the following problem: If they put read delivery notification on when sending from MEMO, then the MRMEMO server notifies of the following error when the read notification comes back: Message from X.400 to MEMO causes the following error message: %%%%%%%%%%% OPCOM 22-APR-1992 12:23:41.87 %%%%%%%%%%% Message from user MRMEMO on VTKES6 Time: 1992-04-22 12:23:41.87; message from server MRMEMO1: %MRIF-E-WRONGPOS, not positioned on specified element MRMEMO Server is not able to handle the message, Server takes the message from MR mailbox, it is disassembling and then it goes to state 'Starting, connecting to Message Router and Memo Gateway'. Then it takes the same message from MR mailbox and so on and so on. The Server does not handle any other messages as long as this one is not removed from mailbox queue. The NBS-file of the message from MR$NBS: dumped by MRNBSDMP is listed below: File DISK$USER1:[MB$.MR.MSG1]6105.POSITIONED_WRONG_ELEMENT_NBS;1 contains *** *** bytes. 000007 1 MSG[V2ENV] Len=0004C6 00000E 2 FIELD[PDATE] Len=000016 000014 3 DATE Len=000010 000016 4 ASCII Len=00000E "19920422110621 00002B 2 FIELD[MID] Len=000042 00002D 3 ASCII Len=000013 "FIICL 4:1743822:4:1 000046 3 SEQ Len=000027 00004D 4 ATTR[COUNTRY] Len=000004 00004F 5 ASCII Len=000002 "FI 000058 4 ATTR[ADMINDOMAIN] Len=000009 00005A 5 ASCII Len=000007 "MAILNET 000068 4 ATTR[PRIVATEDOM] Len=000005 00006A 5 ASCII Len=000003 "ICL 000074 2 FIELD[SENDER] Len=0000BF 00007B 3 ENT[NAME] Len=0000B8 000081 4 SEQ Len=00005E 000088 5 ATTR[COUNTRY] Len=000004 00008A 6 ASCII Len=000002 "FI 000093 5 ATTR[ADMINDOMAIN] Len=000009 000095 6 ASCII Len=000007 "MAILNET 0000A3 5 ATTR[PRIVATEDOM] Len=000005 0000A5 6 ASCII Len=000003 "ICL 0000AF 5 ATTR[ORGANTN] Len=00000C 0000B1 6 ASCII Len=00000A "Grafimedia 0000C2 5 ATTR[PNAME] Len=00001D 0000C9 6 ATTR[SURNAME] Len=000008 0000CB 7 ASCII Len=000006 "Ronkko 0000D8 6 ATTR[GIVENNAME] Len=000007 0000DA 7 ASCII Len=000005 "Hannu 0000E5 4 SEQ Len=00004E 0000EC 5 ATTR[ROUTE] Len=000032 0000F2 6 SEQ Len=00002C 0000F4 7 ASCII Len=000004 "X400 0000FA 7 ASCII Len=000004 "1=FI 000100 7 ASCII Len=000009 "2=MAILNET 00010B 7 ASCII Len=000005 "3=ICL 000112 7 ASCII Len=00000C "5=Grafimedia 000125 5 ATTR[USERID] Len=00000E 000127 6 ASCII Len=00000C "Hannu Ronkko 00013C 2 FIELD[CONTENTDIA] Len=000003 00013E 3 INT Len=000001 %02 000146 2 FIELD[PREC] Len=000003 000148 3 INT Len=000001 %01 000152 2 FIELD[PERMSGFLG] Len=000007 000155 3 BITS[%00] Len=000004 %40000000 000160 2 FIELD[TO] Len=0000B9 000166 3 SEQ Len=0000B3 00016D 4 ENT[NAME] Len=0000AC 000173 5 SEQ Len=00005F 00017A 6 ATTR[COUNTRY] Len=000004 00017C 7 ASCII Len=000002 "FI 000185 6 ATTR[ADMINDOMAIN] Len=000009 000187 7 ASCII Len=000007 "MAILNET 000195 6 ATTR[PRIVATEDOM] Len=00000A 000197 7 ASCII Len=000008 "TIETOTIE 0001A6 6 ATTR[ORGANTN] Len=000006 0001A8 7 ASCII Len=000004 "VTKK 0001B3 6 ATTR[PNAME] Len=00001F 0001BA 7 ATTR[SURNAME] Len=00000A 0001BC 8 ASCII Len=000008 "Kykkanen 0001CB 7 ATTR[GIVENNAME] Len=000007 0001CD 8 ASCII Len=000005 "Ritva 0001D8 5 SEQ Len=000026 0001DF 6 ATTR[ROUTE] Len=00000C 0001E5 7 SEQ Len=000006 0001E7 8 ASCII Len=000004 "ELVI 0001F2 6 ATTR[USERID] Len=00000C 0001F4 7 ASCII Len=00000A "VTKK.V1REK 000205 5 ATTR[PERRECFLG] Len=000007 000208 6 BITS[%00] Len=000004 %A0000000 000213 5 ATTR[EXTENTNID] Len=000006 000215 6 INT Len=000004 %00000001 000222 2 FIELD[MTRACE] Len=000135 000228 3 SEQ Len=00005E 00022E 4 SEQ Len=000027 000235 5 ATTR[COUNTRY] Len=000004 000237 6 ASCII Len=000002 "FI 000240 5 ATTR[ADMINDOMAIN] Len=000009 000242 6 ASCII Len=000007 "MAILNET 000250 5 ATTR[PRIVATEDOM] Len=000005 000252 6 ASCII Len=000003 "ICL 00025B 4 SET Len=00002B 000264 5 FIELD[ARVDATE] Len=000016 00026A 6 DATE Len=000010 00026C 7 ASCII Len=00000E "19920422110621 000283 5 FIELD[ACTION] Len=000003 000285 6 INT Len=000001 %00 00028C 3 SEQ Len=000052 000292 4 SEQ Len=00001B 000299 5 ATTR[COUNTRY] Len=000004 00029B 6 ASCII Len=000002 "FI 0002A4 5 ATTR[ADMINDOMAIN] Len=000009 0002A6 6 ASCII Len=000007 "MAILNET 0002B3 4 SET Len=00002B 0002BC 5 FIELD[ARVDATE] Len=000016 0002C2 6 DATE Len=000010 0002C4 7 ASCII Len=00000E "19920422111312 0002DB 5 FIELD[ACTION] Len=000003 0002DD 6 INT Len=000001 %00 0002E4 3 SEQ Len=000073 0002EA 4 SEQ Len=00002C 0002F1 5 ATTR[COUNTRY] Len=000004 0002F3 6 ASCII Len=000002 "FI 0002FC 5 ATTR[ADMINDOMAIN] Len=000009 0002FE 6 ASCII Len=000007 "MAILNET 00030C 5 ATTR[PRIVATEDOM] Len=00000A 00030E 6 ASCII Len=000008 "TIETOTIE 00031C 4 SET Len=00003B 000325 5 FIELD[ARVDATE] Len=000016 00032B 6 DATE Len=000010 00032D 7 ASCII Len=00000E "19920422121925 000344 5 FIELD[ACTION] Len=000003 000346 6 INT Len=000001 %00 000350 5 FIELD[CONTENTTYPE] Len=000007 000353 6 BITS[%00] Len=000004 %20000000 000360 2 FIELD[ITRACE] Len=000045 000366 3 SEQ Len=00003F 00036F 4 FIELD[MTA] Len=000008 000371 5 ASCII Len=000006 "VTKES6 000380 4 FIELD[ARVDATE] Len=000016 000386 5 DATE Len=000010 000388 6 ASCII Len=00000E "19920422141937 00039F 4 FIELD[ACTION] Len=000006 0003A1 5 INT Len=000004 %00000000 0003AE 2 FIELD[HOPCOUNT] Len=000006 0003B0 3 INT Len=000004 %00000001 0003BB 2 MSG[UAREPORT] Len=000112 0003C4 3 FIELD[REPORTED] Len=00001B 0003CD 4 FIELD[APPMID] Len=000012 0003CF 5 ASCII Len=000010 "iZMhlSpwX0eRwOAM 0003E8 3 FIELD[ACTUALREC] Len=0000C7 0003EF 4 ENT[NAME] Len=0000C0 0003F5 5 SEQ Len=00005E 0003FC 6 ATTR[COUNTRY] Len=000004 0003FE 7 ASCII Len=000002 "FI 000407 6 ATTR[ADMINDOMAIN] Len=000009 000409 7 ASCII Len=000007 "MAILNET 000417 6 ATTR[PRIVATEDOM] Len=000005 000419 7 ASCII Len=000003 "ICL 000423 6 ATTR[ORGANTN] Len=00000C 000425 7 ASCII Len=00000A "Grafimedia 000436 6 ATTR[PNAME] Len=00001D 00043D 7 ATTR[SURNAME] Len=000008 00043F 8 ASCII Len=000006 "Ronkko 00044C 7 ATTR[GIVENNAME] Len=000007 00044E 8 ASCII Len=000005 "Hannu 000459 5 SEQ Len=000056 000460 6 ATTR[ROUTE] Len=00003A 000466 7 SEQ Len=000034 000468 8 ASCII Len=000006 "VTKES6 000470 8 ASCII Len=000004 "X400 000476 8 ASCII Len=000004 "1=FI 00047C 8 ASCII Len=000009 "2=MAILNET 000487 8 ASCII Len=000005 "3=ICL 00048E 8 ASCII Len=00000C "5=Grafimedia 0004A1 6 ATTR[USERID] Len=00000E 0004A3 7 ASCII Len=00000C "Hannu Ronkko 0004B8 3 FIELD[UAREPORTTYPE] Len=000015 0004C1 4 FIELD[NONRECEIPT] Len=00000C 0004CA 5 FIELD[NONRECREASON] Len=000003 0004CC 6 INT Len=000001 %00 0004CD 0End of file Cheers from a Sunny Helsinki ! Jan-Erik
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 139.1 | Traceback info? | STKOFF::SPERSSON | Pas de probleme | Tue May 19 1992 10:15 | 11 |
Hi,
Before I start investigating this, could you provide the traceback part
of the log (ie the 10+ lines below the error message). This tells me
where in the code the error happens, and gives me a hint where to look
for errors in the .NBS file.
cheers,
Stefan
| |||||
| 139.2 | Your first problem is known and fixed | STKOFF::SPERSSON | Pas de probleme | Tue May 19 1992 10:37 | 4 |
ABout the number 1. problem:
See 5.9 for patch
| |||||
| 139.3 | Here is the error log | EEMELI::ALADIN | Wed May 20 1992 10:18 | 69 | |
Hey !
Here is the log following the error message.
I hope it will help you further, Stefan !
Greetings from a sunny Helsinki !
Jan-Erik
Time: 1992-05-17 13:28:14.60; message from server MRMEMO1:
%MRIF-E-WRONGPOS, not positioned on specified element
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, idle, connected to MR and MEMO after message indicated in
MR mailbox
-MRMEMO-I-RING, ring: ' 4A 4D 52 19.', substates: 00000470
%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 0935E8CA:
%MRIF-E-WRONGPOS, not positioned on specified element
----- end of exception message
SRVMRD SRV$MRD_PRSNT_NONRECEIPT 9392 00000035 001F0A0C
SRVMRD SRV$MRD_RNOTIF_CNT 10486 0000005B 001F185A
SRVMRD SRV$MRD_DISASS 11489 00000520 001F24B3
SRVACT SRV$ACT_M 4710 0000003D 001EB1A9
SRVDSP SRV$DSP_FSM 3310 00000115 001E3299
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
Time: 1992-05-17 13:28:41.93; message from server MRMEMO1:
%MRIF-E-WRONGPOS, not positioned on specified element
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, idle, connected to MR and MEMO after message indicated in
MR mailbox
-MRMEMO-I-RING, ring: ' 4A 4D 52 19 ][ 4A 52 19.', substates: 00000430
%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 0935E8CA:
%MRIF-E-WRONGPOS, not positioned on specified element
----- end of exception message
SRVMRD SRV$MRD_PRSNT_NONRECEIPT 9392 00000035 001F0A0C
SRVMRD SRV$MRD_RNOTIF_CNT 10486 0000005B 001F185A
SRVMRD SRV$MRD_DISASS 11489 00000520 001F24B3
SRVACT SRV$ACT_M 4710 0000003D 001EB1A9
SRVDSP SRV$DSP_FSM 3310 00000115 001E3299
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
| |||||
| 139.4 | NON-RECEIPTS are a new experience | STKOFF::SPERSSON | Pas de probleme | Thu May 21 1992 16:58 | 25 |
Hi,
Well it appears that the message has been rejected by the receiving
User Agent (hence the NON-RECEIPT). NONRECREASON = 00 means "User
agent discarded message".
Now the MRMEMO code should be able to handle this, and present the
NONRECEIPT as a text message to the original sender (it is not mapped
to a MEMO status message code) and I can't work out
from merely reading the code why it doesn't. Does the customer still have
the actual .NBS file, and is there any way that it could be sent to me
in binary form (either by X.400 ->
c=se,admd=tede,prmd=digital,surname=persson,given=stefan
or PSI-MAIL ->
24037121003::SPERSSON)
I would need this to be able and identify exactly what goes wrong, and
then possibly provide a patch. I'm really curious about this, it's the
first time I've seen live NON-RECEIPTS.
cheers,
Stefan
| |||||
| 139.5 | Bug found, still want .NBS file | STKOFF::SPERSSON | Pas de probleme | Fri May 22 1992 10:48 | 12 |
Errm,
The *smart* MRMEMO engineer (Anders Olsson) pointed out an obvious code
error in the handling of Non-Receipt messages.
We should be able to provide a patch. Please watch this space. We could
still use the binary .NBS file to test the patch though.
cheers,
Stefan
| |||||
| 139.6 | Watch out ... | KETJE::VANHOOSTE | Guide to Shadowland | Fri May 22 1992 11:13 | 5 |
Watch out for MR V3.2 . Non-receipt generation does not work there. If you want therefore to run MRMEMO on V3.2, you *REQUIRE* at least MR S3.2-1 . Marc VH. | |||||
| 139.7 | MRMEMO *will* run on MR V3.2 | STKOFF::SPERSSON | Pas de probleme | Fri May 22 1992 15:32 | 8 |
Re: .6
No-no, this is *incoming* Non-Receipt Notifications. MRMEMO does not
generate Non-Receipts
cheers,
Stefan
| |||||
| 139.8 | The NBS file is coming | EEMELI::ALADIN | Fri May 22 1992 16:07 | 11 | |
Hey, Stefan !
I just talked to our customer VTKK, Finland and they
are going to try to send the NBS file via PSI Mail
to you. The file should be coming.
If they wouldn't succeed I shall deliver it somehow
next week.
Cheers
Jan-Erik
| |||||
| 139.9 | NBS files can be copied from .... | EEMELI::ALADIN | Mon Jun 01 1992 16:16 | 15 | |
Hey !
The NBS files are now in following directory:
HSKSWA::DEV$NET:<TQPS.KIT>
MRMEMO1-CONTENTS.NBS;1
MRMEMO1-ENVELOPE.NBS;1
I hope these are the right files !
It seems, that the messages our customer is sending are
not coming to the message addressees.
Cheers
Jan-Erik
| |||||
| 139.10 | NBS files acknowledged | STKOFF::SPERSSON | Pas de probleme | Tue Jun 02 1992 10:09 | 30 |
Jan-Erik,
> The NBS files are now in following directory:
> HSKSWA::DEV$NET:<TQPS.KIT>
> MRMEMO1-CONTENTS.NBS;1
> MRMEMO1-ENVELOPE.NBS;1
We'll investigate the problem using the .NBS files, hopefully very
soon. As I've told you off-line already, Anders Olsson has built a
patch which seems to work inasmuch as the server won't crash, and the
messages will go away from the queue. The down side is that no useful
status info is transferred to MEMO. What is supposed to happen is that
MRMEMO sends a TEXT message to the original sender containing the
status information (much like the TEXT Delivery/Recipt messages of
ALL-IN-1) The tests Anders has performed so far however indicate that
MEMO just rejects the messages for some reason still unexamined.
> I hope these are the right files !
Yes, they are.
> It seems, that the messages our customer is sending are
> not coming to the message addressees.
Exactly. That's why the receiving User Agent is generating
Non-Receipts. Nothing we can do in the MRMEMO software will fix
this situation.
| |||||
| 139.11 | Patch seems to be working | EEMELI::ALADIN | Mon Sep 21 1992 11:04 | 10 | |
Hey !
The Patch has now been tested at the customer and it
seems to work. The reason for the problem originated from
that the remote end couldn't handle some re-routing information
and therefore it sent this return error acknowledge message
which caused MRMEMO server to 'hang-up'.
Jan-Erik
| |||||