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 |
This is a quite long note. There is a problem with MRMEMO$LOGMASK = FF and the file name of the translation table. I was able to send a message with an unsupported bodypart without defining the logical. After defining the logical the translation table was not found and it seems that the server process is looping. I was not able to SHUT the server down. Again I had to STOP/ID and now I can't reconnect to MEMO (receiving UNBIND). I got mails from the MEMO manager in Valbonne saying that there is a 'corrupt or invalid' message in the queue. I didn't test the situation with the patch mentioned in 5.7. I guess that this patch will fix at least the SHUT problem. Below you'll find the NBSDMP of the content, the definition of my files and the memo log file. Regards, Rainer ======================================================================= VAX MAILGATE for MEMO Manager version V2.1 Net mailbox message T Type: 49 Unit: 2092 Name: NET Info: rMMan . MRMEMO1 status as of 1990-11-16 10:44:26 Current state: idle, connected to MR and MEMO Last event: message indicated in MR mailbox Current operation: packing MEMO DIA message Current number of links: 1 Last Application ID: 30313430303239313638363433303235 Last Message Router ID: 0140029168643025@VUSCLU Direction: Message Router -> MEMO Timestamp: 1990-11-16 09:38:07.17 Status: Successful Delivery Start time: 1990-11-15 10:58:25.95 ======================================================================= MRMMAN > LIST/FILES Related files: Translation table: SYS$LIBRARY:MRMEMOTRA.TBL <------- Log file: MRMEMO$DIR:MRMEMO1.LOG Accounting file: MRMEMO$DIR:MRMEMOACC1.DAT ======================================================================= File DISK$USER:[MRMEMO]MRMEMO1-CONTENTS.NBS;1 contains ****** bytes. 000003 1 MSG[V2CONT] Len=****** 00000C 2 FIELD[APPMID] Len=000012 00000E 3 ASCII Len=000010 "0140029168643025 000025 2 FIELD[FROM] Len=0000FE 00002C 3 ENT[NAME] Len=0000F7 000032 4 SEQ Len=00006D 000039 5 ATTR[COUNTRY] Len=000004 00003B 6 ASCII Len=000002 "DE 000044 5 ATTR[ADMINDOMAIN] Len=000007 000046 6 ASCII Len=000005 "EMSA1 000052 5 ATTR[ORGANTN] Len=000009 000054 6 ASCII Len=000007 "Digital 000062 5 ATTR[PNAME] Len=00002D 000069 6 ATTR[SURNAME] Len=00000D 00006B 7 ASCII Len=00000B "Rosenberger 00007D 6 ATTR[GIVENNAME] Len=000008 00007F 7 ASCII Len=000006 "Rainer 00008C 6 ATTR[INITIALS] Len=000003 00008E 7 ASCII Len=000001 "R 000096 5 ATTR[ORGANTNUNIT] Len=000009 000098 6 ASCII Len=000007 "PZ-SOGY 0000A5 4 SEQ Len=000063 0000AC 5 ATTR[ROUTE] Len=000041 0000B2 6 SEQ Len=00003B 0000B4 7 ASCII Len=000006 "REFVUS 0000BC 7 ASCII Len=000007 "MTA_CLU 0000C5 7 ASCII Len=000004 "1=DE 0000CB 7 ASCII Len=000007 "2=EMSA1 0000D4 7 ASCII Len=000009 "5=Digital 0000DF 7 ASCII Len=000009 "4=PZ-SOGY 0000EA 7 ASCII Len=000003 "8=R 0000F4 5 ATTR[USERID] Len=000014 0000F6 6 ASCII Len=000012 "Rainer Rosenberger 00010F 4 ATTR[FREEFORM] Len=000014 000111 5 ASCII Len=000012 "Rainer Rosenberger 00012A 2 FIELD[TO] Len=000694 000130 3 SEQ Len=00068E 000137 4 ENT[NAME] Len=0000AD 00013D 5 SEQ Len=000053 000144 6 ATTR[COUNTRY] Len=000004 000146 7 ASCII Len=000002 "DE 00014F 6 ATTR[ADMINDOMAIN] Len=000007 000151 7 ASCII Len=000005 "EMSA1 00015D 6 ATTR[PRIVATEDOM] Len=000008 00015F 7 ASCII Len=000006 "RAINER 00016C 6 ATTR[PNAME] Len=000024 000173 7 ATTR[SURNAME] Len=00000D 000175 8 ASCII Len=00000B "Rosenberger 000187 7 ATTR[GIVENNAME] Len=000009 000189 8 ASCII Len=000007 "vmsmail 000196 5 SEQ Len=000032 00019D 6 ATTR[ROUTE] Len=000016 0001A3 7 SEQ Len=000010 0001A5 8 ASCII Len=000006 "REFVUS 0001AD 8 ASCII Len=000006 "MRGATE 0001BA 6 ATTR[USERID] Len=00000E 0001BC 7 ASCII Len=00000C "RROSENBERGER 0001CF 5 ATTR[FREEFORM] Len=000015 0001D1 6 ASCII Len=000013 "vmsmail Rosenberger 0001EB 4 ENT[NAME] Len=0000A7 0001F1 5 SEQ Len=000052 0001F8 6 ATTR[COUNTRY] Len=000004 0001FA 7 ASCII Len=000002 "DE 000203 6 ATTR[ADMINDOMAIN] Len=000007 000205 7 ASCII Len=000005 "EMSA1 000211 6 ATTR[PRIVATEDOM] Len=000008 000213 7 ASCII Len=000006 "RAINER 000220 6 ATTR[PNAME] Len=000023 000227 7 ATTR[SURNAME] Len=00000D 000229 8 ASCII Len=00000B "rosenberger 00023B 7 ATTR[GIVENNAME] Len=000008 00023D 8 ASCII Len=000006 "Allin1 000249 5 SEQ Len=00002E 000250 6 ATTR[ROUTE] Len=000012 000256 7 SEQ Len=00000C 000258 8 ASCII Len=000006 "REFVUS 000260 8 ASCII Len=000002 "A1 000269 6 ATTR[USERID] Len=00000E 00026B 7 ASCII Len=00000C "RROSENBERGER 00027E 5 ATTR[FREEFORM] Len=000014 000280 6 ASCII Len=000012 "Allin1 rosenberger 000299 4 ENT[NAME] Len=0000AE 00029F 5 SEQ Len=000052 0002A6 6 ATTR[COUNTRY] Len=000004 0002A8 7 ASCII Len=000002 "DE 0002B1 6 ATTR[ADMINDOMAIN] Len=000007 0002B3 7 ASCII Len=000005 "EMSA1 0002BF 6 ATTR[PRIVATEDOM] Len=000008 0002C1 7 ASCII Len=000006 "RAINER 0002CE 6 ATTR[PNAME] Len=000023 0002D5 7 ATTR[SURNAME] Len=00000D 0002D7 8 ASCII Len=00000B "Rosenberger 0002E9 7 ATTR[GIVENNAME] Len=000008 0002EB 8 ASCII Len=000006 "A1mail 0002F7 5 SEQ Len=000035 0002FE 6 ATTR[ROUTE] Len=000019 000304 7 SEQ Len=000013 000306 8 ASCII Len=000006 "REFVUS 00030E 8 ASCII Len=000009 "REFVUS_AM 00031E 6 ATTR[USERID] Len=00000E 000320 7 ASCII Len=00000C "RROSENBERGER 000333 5 ATTR[FREEFORM] Len=000014 000335 6 ASCII Len=000012 "A1mail Rosenberger 00034E 4 ENT[NAME] Len=0000AF 000354 5 SEQ Len=000053 00035B 6 ATTR[COUNTRY] Len=000004 00035D 7 ASCII Len=000002 "DE 000366 6 ATTR[ADMINDOMAIN] Len=000007 000368 7 ASCII Len=000005 "EMSA1 000374 6 ATTR[PRIVATEDOM] Len=000008 000376 7 ASCII Len=000006 "RAINER 000383 6 ATTR[PNAME] Len=000024 00038A 7 ATTR[SURNAME] Len=00000D 00038C 8 ASCII Len=00000B "Rosenberger 00039E 7 ATTR[GIVENNAME] Len=000009 0003A0 8 ASCII Len=000007 "Mailbox 0003AD 5 SEQ Len=000034 0003B4 6 ATTR[ROUTE] Len=00001B 0003BA 7 SEQ Len=000015 0003BC 8 ASCII Len=000006 "REFVUS 0003C4 8 ASCII Len=00000B "TEST_RAINER 0003D6 6 ATTR[USERID] Len=00000B 0003D8 7 ASCII Len=000009 "001400300 0003E8 5 ATTR[FREEFORM] Len=000015 0003EA 6 ASCII Len=000013 "Mailbox Rosenberger 000404 4 ENT[NAME] Len=0000AA 00040A 5 SEQ Len=00004D 000411 6 ATTR[COUNTRY] Len=000004 000413 7 ASCII Len=000002 "DE 00041C 6 ATTR[ADMINDOMAIN] Len=000007 00041E 7 ASCII Len=000005 "EMSA1 00042A 6 ATTR[PRIVATEDOM] Len=000008 00042C 7 ASCII Len=000006 "RAINER 000439 6 ATTR[PNAME] Len=00001E 000440 7 ATTR[SURNAME] Len=000009 000442 8 ASCII Len=000007 "Gyvusaa 000450 7 ATTR[GIVENNAME] Len=000007 000452 8 ASCII Len=000005 "Profs 00045D 5 SEQ Len=00003B 000464 6 ATTR[ROUTE] Len=00001F 00046A 7 SEQ Len=000019 00046C 8 ASCII Len=000006 "REFVUS 000474 8 ASCII Len=000003 "MRP 000479 8 ASCII Len=00000A "PR_L=VMVBO 00048A 6 ATTR[USERID] Len=00000E 00048C 7 ASCII Len=00000C "PR_U=GYVUSAA 00049F 5 ATTR[FREEFORM] Len=00000F 0004A1 6 ASCII Len=00000D "Profs Gyvusaa 0004B5 4 ENT[NAME] Len=0000AF 0004BB 5 SEQ Len=00004E 0004C2 6 ATTR[COUNTRY] Len=000004 0004C4 7 ASCII Len=000002 "DE 0004CD 6 ATTR[ADMINDOMAIN] Len=000007 0004CF 7 ASCII Len=000005 "EMSA1 0004DB 6 ATTR[PRIVATEDOM] Len=000008 0004DD 7 ASCII Len=000006 "RAINER 0004EA 6 ATTR[PNAME] Len=00001F 0004F1 7 ATTR[SURNAME] Len=000009 0004F3 8 ASCII Len=000007 "Gyvusaa 000501 7 ATTR[GIVENNAME] Len=000008 000503 8 ASCII Len=000006 "Disoss 00050F 5 SEQ Len=00003E 000516 6 ATTR[ROUTE] Len=000022 00051C 7 SEQ Len=00001C 00051E 8 ASCII Len=000006 "REFVUS 000526 8 ASCII Len=000003 "MRS 00052B 8 ASCII Len=00000D "SN_L=VBODISOS 00053F 6 ATTR[USERID] Len=00000E 000541 7 ASCII Len=00000C "SN_U=GYVUSAA 000554 5 ATTR[FREEFORM] Len=000010 000556 6 ASCII Len=00000E "Disoss Gyvusaa 00056B 4 ENT[NAME] Len=00009C 000571 5 SEQ Len=00004C 000578 6 ATTR[COUNTRY] Len=000004 00057A 7 ASCII Len=000002 "DE 000583 6 ATTR[ADMINDOMAIN] Len=000007 000585 7 ASCII Len=000005 "EMSA1 000591 6 ATTR[PRIVATEDOM] Len=000008 000593 7 ASCII Len=000006 "RAINER 0005A0 6 ATTR[PNAME] Len=00001D 0005A7 7 ATTR[SURNAME] Len=000009 0005A9 8 ASCII Len=000007 "Gyvusaa 0005B7 7 ATTR[GIVENNAME] Len=000006 0005B9 8 ASCII Len=000004 "Memo 0005C3 5 SEQ Len=00002F 0005CA 6 ATTR[ROUTE] Len=000014 0005D0 7 SEQ Len=00000E 0005D2 8 ASCII Len=000006 "REFVUS 0005DA 8 ASCII Len=000004 "MEMO 0005E5 6 ATTR[USERID] Len=00000D 0005E7 7 ASCII Len=00000B "DGA.GYVUSAA 0005F9 5 ATTR[FREEFORM] Len=00000E 0005FB 6 ASCII Len=00000C "Memo Gyvusaa 00060E 4 ENT[NAME] Len=0000B2 000614 5 SEQ Len=00004F 00061B 6 ATTR[COUNTRY] Len=000004 00061D 7 ASCII Len=000002 "DE 000626 6 ATTR[ADMINDOMAIN] Len=000007 000628 7 ASCII Len=000005 "EMSA1 000634 6 ATTR[PRIVATEDOM] Len=000008 000636 7 ASCII Len=000006 "RAINER 000643 6 ATTR[PNAME] Len=000020 00064A 7 ATTR[SURNAME] Len=00000A 00064C 8 ASCII Len=000008 "Gyvuspsa 00065B 7 ATTR[GIVENNAME] Len=000008 00065D 8 ASCII Len=000006 "Disoss 000669 5 SEQ Len=00003F 000670 6 ATTR[ROUTE] Len=000022 000676 7 SEQ Len=00001C 000678 8 ASCII Len=000006 "REFVUS 000680 8 ASCII Len=000003 "MRS 000685 8 ASCII Len=00000D "SN_L=VBODISOS 000699 6 ATTR[USERID] Len=00000F 00069B 7 ASCII Len=00000D "SN_U=GYVUSPSA 0006AF 5 ATTR[FREEFORM] Len=000011 0006B1 6 ASCII Len=00000F "Disoss Gyvuspsa 0006C7 4 ENT[NAME] Len=0000F7 0006CD 5 SEQ Len=00006D 0006D4 6 ATTR[COUNTRY] Len=000004 0006D6 7 ASCII Len=000002 "DE 0006DF 6 ATTR[ADMINDOMAIN] Len=000007 0006E1 7 ASCII Len=000005 "EMSA1 0006ED 6 ATTR[ORGANTN] Len=000009 0006EF 7 ASCII Len=000007 "Digital 0006FD 6 ATTR[PNAME] Len=00002D 000704 7 ATTR[SURNAME] Len=00000D 000706 8 ASCII Len=00000B "Rosenberger 000718 7 ATTR[GIVENNAME] Len=000008 00071A 8 ASCII Len=000006 "Rainer 000727 7 ATTR[INITIALS] Len=000003 000729 8 ASCII Len=000001 "R 000731 6 ATTR[ORGANTNUNIT] Len=000009 000733 7 ASCII Len=000007 "PZ-SOGY 000740 5 SEQ Len=000063 000747 6 ATTR[ROUTE] Len=000041 00074D 7 SEQ Len=00003B 00074F 8 ASCII Len=000006 "REFVUS 000757 8 ASCII Len=000007 "MTA_CLU 000760 8 ASCII Len=000004 "1=DE 000766 8 ASCII Len=000007 "2=EMSA1 00076F 8 ASCII Len=000009 "5=Digital 00077A 8 ASCII Len=000009 "4=PZ-SOGY 000785 8 ASCII Len=000003 "8=R 00078F 6 ATTR[USERID] Len=000014 000791 7 ASCII Len=000012 "Rainer Rosenberger 0007AA 5 ATTR[FREEFORM] Len=000014 0007AC 6 ASCII Len=000012 "Rainer Rosenberger 0007C5 2 VEND[TYPE] Len=000011 0007C7 3 ASCII Len=00000F "MAIL 0007DD 2 VEND[FORMAT] Len=000011 0007DF 3 ASCII Len=00000F " 0007F5 2 FIELD[SUBJ] Len=000026 0007F7 3 ASCII Len=000024 "test Distribution list as attachment 000822 2 FIELD[ATTACH] Len=000029 000829 3 MSG[TEXT] Len=000022 00082B 4 ASCII Len=000020 "Text first line " "end of text 000852 2 FIELD[ATTACH] Len=0002E2 00085B 3 MSG[DECBODY_13] Len=0002D9 000864 4 FIELD[NBSBODYCOUNTRY] Len=000004 000866 5 INT Len=000002 %0136 000871 4 FIELD[NBSBODYNUMBER] Len=000003 000873 5 INT Len=000001 %0A 00087D 4 FIELD[X409DATA] Len=0002B7 000881 5 ASCII Len=0002B3 " "Data have been edited , Rainer ******* " 000B3B 2 FIELD[ATTACH] Len=0001CA 000B42 3 MSG[V2CONT] Len=0001C3 000B4B 4 FIELD[APPMID] Len=000012 000B4D 5 ASCII Len=000010 "0140029168631739 000B64 4 FIELD[FROM] Len=0000B1 000B6B 5 ENT[NAME] Len=0000AA 000B71 6 SEQ Len=000039 000B78 7 ATTR[COUNTRY] Len=000004 000B7A 8 ASCII Len=000002 "DE 000B83 7 ATTR[ADMINDOMAIN] Len=000007 000B85 8 ASCII Len=000005 "EMSA1 000B91 7 ATTR[ORGANTN] Len=000009 000B93 8 ASCII Len=000007 "Digital 000BA1 7 ATTR[ORGANTNUNIT] Len=000009 000BA3 8 ASCII Len=000007 "PZ-SOGY 000BB0 6 SEQ Len=00004A 000BB7 7 ATTR[ROUTE] Len=000036 000BBD 8 SEQ Len=000030 000BBF 9 ASCII Len=000006 "REFVUS 000BC7 9 ASCII Len=000007 "MTA_CLU 000BD0 9 ASCII Len=000007 "2=EMSA1 000BD9 9 ASCII Len=000009 "5=Digital 000BE4 9 ASCII Len=000009 "4=PZ-SOGY 000BF4 7 ATTR[USERID] Len=000006 000BF6 8 ASCII Len=000004 "1=DE 000C01 6 ATTR[FREEFORM] Len=000014 000C03 7 ASCII Len=000012 "Rainer Rosenberger 000C1C 4 FIELD[TO] Len=0000B4 000C22 5 SEQ Len=0000AE 000C29 6 ENT[NAME] Len=0000A7 000C2F 7 SEQ Len=000052 000C36 8 ATTR[COUNTRY] Len=000004 000C38 9 ASCII Len=000002 "DE 000C41 8 ATTR[ADMINDOMAIN] Len=000007 000C43 9 ASCII Len=000005 "EMSA1 000C4F 8 ATTR[PRIVATEDOM] Len=000008 000C51 9 ASCII Len=000006 "RAINER 000C5E 8 ATTR[PNAME] Len=000023 000C65 9 ATTR[SURNAME] Len=00000D 000C67 10 ASCII Len=00000B "rosenberger 000C79 9 ATTR[GIVENNAME] Len=000008 000C7B 10 ASCII Len=000006 "allin1 000C87 7 SEQ Len=00002E 000C8E 8 ATTR[ROUTE] Len=000012 000C94 9 SEQ Len=00000C 000C96 10 ASCII Len=000006 "REFVUS 000C9E 10 ASCII Len=000002 "A1 000CA7 8 ATTR[USERID] Len=00000E 000CA9 9 ASCII Len=00000C "RROSENBERGER 000CBC 7 ATTR[FREEFORM] Len=000014 000CBE 8 ASCII Len=000012 "allin1 rosenberger 000CD7 4 FIELD[SUBJ] Len=000010 000CD9 5 ASCII Len=00000E "test an allin1 000CEE 4 FIELD[ATTACH] Len=000017 000CF5 5 MSG[TEXT] Len=000010 000CF7 6 ASCII Len=00000E "test " "ende 000D06 0End of file ======================================================================= $ run/nodebug sys$system:mrmsrv Time: 1990-11-16 11:03:48.82; message from server MRMEMO1: %MRMEMO-I-FSM, starting, connecting to MR and MEMO Gateway after clock tick Time: 1990-11-16 11:03:55.69; message from server MRMEMO1: %MRMEMO-I-DECNETMSG, DECnet notification, message number is: 50 Time: 1990-11-16 11:03:55.73; message from server MRMEMO1: %MRMEMO-I-FSM, starting, connecting to MR and MEMO Gateway after start request from MRMMAN Time: 1990-11-16 11:03:56.05; message from server MRMEMO1: %MRMEMO-I-NEWACCOUNT, opening new accounting file: DISK$USER:[MRMEMO]MRMEMOACC1.DAT;26 Time: 1990-11-16 11:04:03.53; message from server MRMEMO1: %MRMEMO-I-CONNECTION, connection established to Message Router: -SYSTEM-S-SUCCESS, Successful completion 16-NOV-1990 11:04:06.69: SNA event CONNECT, substate: 0050, info: 00 16-NOV-1990 11:04:06.90: SNA event BINDOK, substate: 0050, info: 00 Time: 1990-11-16 11:04:06.91; message from server MRMEMO1: %MRMEMO-I-CONNECTION, connection established to MEMO: -SNALU0-S-NORMAL, normal successful completion 16-NOV-1990 11:04:06.93: SNA event RCVMSG, substate: 0070, info: 00 16-NOV-1990 11:04:07.57: SNA event BIDTST, substate: 0070, info: A0 Time: 1990-11-16 11:04:07.63; message from server MRMEMO1: %MRMEMO-I-FSM, synchronising MEMO Gateway link after SDT request from MEMO 16-NOV-1990 11:04:07.73: SNA event POSRSP, substate: 0070, info: A0 16-NOV-1990 11:04:07.76: SNA event RCVMSG, substate: 0470, info: 00 Time: 1990-11-16 11:04:07.77; message from server MRMEMO1: %MRMEMO-I-FSM, idle, connected to MR and MEMO after message indicated in MR mailbox -------- Packing message to MEMO -------- L L C0 01 00 00 05 (end) L L CD 01 01 . L L C3 01 41 . . 06 01 00 00 00 0F . . 12 02 30 36 38 31 34 30 31 31 36 31 31 31 30 39 4D 4D . 00 1D (end) . L L C3 02 01 . . L L C2 01 41 . . . 04 01 00 08 . . 00 09 (end) . . L L C2 02 41 . . . 1C 01 'GYVUS.RROSENBERGER..MRGATE' . . . 04 02 00 01 . . . 04 03 00 00 . . 00 29 (end) . . L L C2 02 41 . . . 18 01 'GYVUS.RROSENBERGER..A1' . . . 04 02 00 02 . . . 04 03 00 00 . . 00 25 (end) . . L L C2 02 41 . . . 1F 01 'GYVUS.RROSENBERGER..REFVUS_AM' . . . 04 02 00 03 . . . 04 03 00 00 . . 00 2C (end) . . L L C2 02 41 . . . 1E 01 'GYVUS.001400300..TEST_RAINER' . . . 04 02 00 04 . . . 04 03 00 00 . . 00 2B (end) . . L L C2 02 41 . . . 25 01 'GYVUS.PR_U=GYVUSAA..PR_L=VMVBO..MRP' . . . 04 02 00 05 . . . 04 03 00 00 . . 00 32 (end) . . L L C2 02 41 . . . 28 01 'GYVUS.SN_U=GYVUSAA..SN_L=VBODISOS..MRS' . . . 04 02 00 06 . . . 04 03 00 00 . . 00 35 (end) . . L L C2 02 41 . . . 0D 01 'DGA.GYVUSAA' . . . 04 02 00 07 . . . 04 03 80 00 . . 00 1A (end) . . L L C2 02 41 . . . 29 01 'GYVUS.SN_U=GYVUSPSA..SN_L=VBODISOS..MRS' . . . 04 02 00 08 . . . 04 03 00 00 . . 00 36 (end) . 01 6A (end) . L L C3 03 41 . . 10 01 'GYVUS.TCLURROS' . . 0D 02 'Rosenberger' . . 09 03 'PZ-SOGY' . . 08 07 C0 00 B4 00 00 00 . . 03 08 'A' . 00 36 (end) . L L C5 05 41 . . 03 01 01 . 00 08 (end) 01 CA (end) L L C9 03 01 . L L CA 03 41 Time: 1990-11-16 11:04:18.98; message from server MRMEMO1: %MRMEMO-I-TRUNC, field SUBJCT truncated: 36 > 14 (max) . . 10 01 'test Distribut' . . 12 02 30 31 34 30 30 32 39 31 36 38 36 34 33 30 32 35 . . 04 05 00 4B . . 04 06 00 37 . . 03 07 00 . 00 32 (end) . L L CB 01 01 . 00 05 (end) 10 59 (end) L L CF 01 00 00 05 (end) Time: 1990-11-16 11:04:19.11; message from server MRMEMO1: %MRMEMO-W-NOTABLE, error opening character translation table SYS$COMMON:[SYSLIB]MRMEMO$TRATBL.TBL; -RMS-E-FNF, file not found %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 08938238: %MRMEMO-W-NOTABLE, error opening character translation table SYS$COMMON:[SYSLIB]MRMEMO$TRATBL.TBL; -RMS-E-FNF, file not found ----- end of exception message ALLDBG ALL$DBG_HAE 3059 0000006B 001E27F2 ALLPAC ALL$PAC_END_GIU 2397 0000003E 001E91E5 ALLPAC ALL$PAC_MSGITMLST_TO_GIUBUF 4404 000000CC 001EA701 SRVACT SRV$ACT_M 4773 000000B4 001EB220 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 00264BB2 00264BB2 ADA$ELAB_DDS ADA$ELAB_DDS 0000000E 001C0C0E 00239B89 00239B89 offset 0: %d ' 0' %x '00' %decmcs '.', %ebcdic '.' offset 1: %d ' 5' %x '05' %decmcs '.', %ebcdic '.' ***************************** and so on forever ******************************
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
56.1 | MRMEMO$TRATBL is a "feature" | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Fri Nov 16 1990 15:16 | 70 |
Hello Rainer! The "missing" translation table that MRMEMO complains about %MRMEMO-W-NOTABLE, error opening character translation table SYS$COMMON:[SYSLIB]MRMEMO$TRATBL.TBL; -RMS-E-FNF, file not found is caused by a "feature" in the logging routines. An alternate translation table can be specified with the logical name MRMEMO$TRATBL. This logical is used when the value 4 is present in MRMEMO$LOGMASK. The best thing to do is to define MRMEMO$TRATBL to the translation table file name (e.g. SYS$LIBRARY:MRMEMOTRA.TBL). Another option is to not include 4 in the MRMEMO$LOGMASK value. For the following discussion, I'll start by listing the current (V2.1) meaning of the MRMEMO$LOGMASK bits (undocumented, unsupported, no commitment, subject to change etc...): 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 .0> offset 0: %d ' 0' %x '00' %decmcs '.', %ebcdic '.' .0> offset 1: %d ' 5' %x '05' %decmcs '.', %ebcdic '.' .0> .0> ***************************** and so on forever ****************************** Do you mean *literally* forever (stuck in a loop) or just for a long time? This is the logging info that is enabled by the value 4 in MRMEMO$LOGMASK. For messages sent to Memo, the formatted logging (MRMEMO$LOGMASK value 20) is much more convenient. The formatted logging is the part that looks like: -------- Packing message to MEMO -------- L L C0 01 00 00 05 (end) L L CD 01 01 . L L C3 01 41 . . 06 01 00 00 00 0F . . 12 02 30 36 38 31 34 30 31 31 36 31 31 31 30 39 4D 4D . 00 1D (end) There is however no corresponding formatted logging of messages *from* Memo. The full one-byte-per-line logging is the only way to get a detailed log of data from Memo (well - SNATRACE is of course an alternative). Unfortunately this logging produces vast amounts of logged data. If we get the time to implement formatted logging of data from Memo, the one-byte-per-line logging could be removed. About the UNBINDs: I doubt that it is something in your message that upsets Memo in Valbonne. When something goes wrong on the Memo side, it usually takes time before it gets cleared up and works properly again. I have also had problems to communicate with Memo in Valbonne the last couple of weeks. Once (a couple of days ago) I managed to send one message before the UNBINDs started to arrive again. I guess that is what happened to you too. It's probably not something wrong with the message. It's "just" that when Memo tries to respond, something goes wrong. Anders | |||||
56.2 | Further studies will follow | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Fri Nov 16 1990 18:04 | 14 |
Hi Anders, The *** forever *** means that there must have been a loop. I didn't really check it because it took ages to go to the bottom of the logfile. My logfile size was about 70000 blocks. But there must be a problem with the logical. Last week I hadn't defined the logical and was able to send a similar message to MEMO. In the successfull case I got a MEMO text message like 'bodypart lost during conversion'. I'll try it again next week (without logical) and post the result here. Regards, Rainer | |||||
56.3 | Still problems with corrupt messages | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Mon Nov 19 1990 17:45 | 32 |
Hi, today again I tried to send a message to MEMO and the same problem occured again. I had to ask Jean-Pierre Julaude to purge the MEMO queue in Valbonne. My message had the same structure as the dump in .0, i.e. Bodypart_1: Text Bodypart_2: 'unsupported' Bodypart_3: Forwarded message Last week I was able to send a message with only the first two bodyparts to MEMO and this did work. Now with SHO/CONT I could see that the message was translated and sent to MEMO. But then the MEMO system stops and sends an UNBIND (so the message remains in the MEMO TS Mailbox). Again I have to ask the MEMO manager to purge the queue. (I've similar problems with MR/P FT_1 V1.2, here the last bodypart is lost.) As soon as I'll have the passwords I'll produce an SNA Trace with the UNBIND commands. But I've not too much time to do much more testings on this situation. You can copy the NBS message from REFVUS::MR259.NBS (49.530) and use the MRM> REPOST command to corrupt your own queue. I think I'll run into problems with the MEMO manager in Valbonne. I'll stop to send unsupported bodyparts. Only a hint how to create them. Send an DECbody_7 from MRX_1 to MRX_2 and configure the two MRXs such that they'll use different numbers to send NBS bodys transparently (MRX parameter DEC_PRIVATE_BODYPART=nn in MRX$:MRX$INIT.DAT. Default value is nn=0). Rainer | |||||
56.4 | Here is the trace | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Tue Nov 20 1990 13:02 | 107 |
AN: Jean-Pierre Julaude @vbo ( JULAUDE@A1NSTC@HERON@VBO ) Betr.: Antwort auf: RE: Antwort auf: RE: Again problems with MEMO Hello Jean-Pierre, I've traced a session and tried to comment the data (I've an example trace from the gateway documentation). Please could you purge the queue again, please. I'm also interested in the exact meaning of the trace. This could also help our engineers to fix the problem. Thanks, Rainer SNATRACE V2.1 PU Trace 20-NOV-1990 12:11:32.63 Gateway node ALFRED Physical Unit SNA-0 (Protocol version = 2.0.0, Buffering level = 10, Data size = 256) T 13:09:22.12 TH=2C00008C06E3 RH=0B8000 RU=25. bytes (005,00000000) FID2,OS,DAF=00,OAF=8C,SNF=06E3 RQ,FMD,FI,BCI,ECI,DR1I 0106 8100 D4D9 C7C1 E3C5 4040 F308 D4C5 : .\a.MRGATE 3\ME D4C7 E8E5 E4E2 0000 00 : MGYVUS... Send initiate request R 13:09:22.15 TH=2C008C0006E3 RH=8B8000 RU=3. bytes (005,00000001) FID2,OS,DAF=8C,OAF=00,SNF=06E3 +RSP,FMD,FI,BCI,ECI,DR1I 0106 81 : .\a VTAM positive Response R 13:09:22.96 TH=2D008C01231F RH=6B8000 RU=37. bytes (005,00000001) FID2,OS,EFI,DAF=8C,OAF=01,SNF=231F RQ,SC,FI,BCI,ECI,DR1I 3101 0303 A1A1 3060 0101 8585 8101 0000 : \...~~\-..eea... 0000 0000 0000 0000 0000 0008 D4C5 D4C7 : ...........\MEMG E8E5 E4E2 00 : YVUS. Send Bind request T 13:09:23.31 TH=2D00018C231F RH=EB8000 RU=1. byte (005,00000000) FID2,OS,EFI,DAF=01,OAF=8C,SNF=231F +RSP,SC,FI,BCI,ECI,DR1I 31 : \ Positive Response R 13:09:23.75 TH=2D008C012320 RH=6B8000 RU=2. bytes (005,00000001) FID2,OS,EFI,DAF=8C,OAF=01,SNF=2320 RQ,SC,FI,BCI,ECI,DR1I 3201 : .. ???????????????????? may be data traced from an other session ???????? T 13:09:24.70 TH=2D00018C2320 RH=EB8000 RU=1. byte (005,00000000) FID2,OS,EFI,DAF=01,OAF=8C,SNF=2320 +RSP,SC,FI,BCI,ECI,DR1I 32 : . Normally: Send Start Data Trafic SDT (A0) Instead: Send '32' ???? So it might be a problem of my gateway ?? R 13:09:24.77 TH=2C008C0006D6 RH=038000 RU=1346. bytes * (005,00000001) FID2,OS,DAF=8C,OAF=00,SNF=06D6 RQ,FMD,BCI,ECI,DR1I 4040 4040 4040 4040 4040 4040 4040 4040 : 4040 4040 4040 4040 4040 4040 4040 4040 : 4040 4040 4040 4040 4040 C440 C940 C740 : D I G C940 E340 C140 D340 4040 C540 D840 E440 : I T A L E Q U C940 D740 D440 C540 D540 E315 4040 40C5 : I P M E N T\ E C5C5 C5C5 C5C5 C5C5 C5C5 C515 4040 40C5 : EEEEEEEEEEE\ E C5C5 C5C5 C5C5 C5C5 C5C5 C540 4040 4040 : EEEEEEEEEEE 4040 4040 4040 6161 6140 4040 4040 4040 : /// 4040 4040 4040 4040 4040 4040 4040 4040 : 4040 4040 4040 4040 E540 C140 D340 C240 : V A L B D640 D540 D540 C515 4040 40C5 C5C5 4040 : O N N E\ EEE 4040 4040 4040 4040 4040 4040 4040 4040 : 4061 6161 1540 4040 C5C5 C540 4040 4040 : ///\ EEE 4040 4040 4040 4040 4040 4040 4061 6161 : /// 4040 40C1 4040 4040 4040 4040 4040 4040 : A 4040 4040 4040 4040 4040 4040 4040 4040 : Logon Mask ???? Expected is an Accept of SDT T 13:09:24.79 TH=2C00008C06D6 RH=879000 RU=7. bytes (005,00000000) FID2,OS,DAF=00,OAF=8C,SNF=06D6 -RSP,FMD,SDI,BCI,ECI,DR1I 0826 0000 4040 40 : \... Transmit negative Response Now the same again ..... T 13:09:27.67 TH=2C00008C06E4 RH=0B8000 RU=25. bytes (005,00000000) FID2,OS,DAF=00,OAF=8C,SNF=06E4 RQ,FMD,FI,BCI,ECI,DR1I 0106 8100 D4D9 C7C1 E3C5 4040 F308 D4C5 : .\a.MRGATE 3\ME D4C7 E8E5 E4E2 0000 00 : MGYVUS... | |||||
56.5 | No problem here! | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Tue Nov 20 1990 13:42 | 34 |
Hello, The logging problem ------------------- The logging that goes on *forever* was a bug. Thank you for finding it. There is now a patch for that in Note 5.8. Actually, the logging didn't go on literally forever. It "just" logged 500K lines of text so your 70000 blocks of logfile makes sense: 512*1024 lines * (66 bytes + 1 word record length) / (disk_block_size=512) = 69632 blocks. Problems with unsupported body part ----------------------------------- I have used your NBS file (REFVUS::MR259.NBS), reposted it and sent it to Memo. I used the debugger to change the destination address to send it to my own Memo account but otherwise I didn't change it. The message was successfully sent to Memo. There was no problem at all. There shouldn't be any problem due to the unsupported body part. Nothing strange is sent to Memo when an unsupported body part is detected, just a text line informing about the body part that wasn't processed. If you try sending this kind of message again, could you install the patch from Note 5.8 and define MRMEMO$LOGMASK to 24 during the test? Also define MRMEMO$TRATBL to the translation table filename. [Oops, I now see that while I am writing this you have already done a test and posted it in 56.4] Could you post your server characteristics (MRMMAN LIST n), so I can make my configuration exactly like yours? Anders | |||||
56.6 | Here the parameters | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Tue Nov 20 1990 14:48 | 52 |
Here it is. But what do you think about my SNATRACE. May be that it's important to mention that I'm running FT_1 of MR 3.2. VAX MAILGATE for MEMO Manager version V2.1 MRMEMO1 summary as of 1990-11-20 14:45:35 Server Identification: Node name: REFVUS Mailbox name: MEMO Message Router Password: **** SNA Session Identification: Gateway node: ALFRED Access name: MEMOGWY Circuit name: SNA-0 Session address: 140 Application name: MEMGYVUS Logon mode entry: MRGATE 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: PR_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: GYVUS. Replace Strings: ..=@ Console logging: None 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 | |||||
56.7 | Trace comments | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Tue Nov 20 1990 16:04 | 136 |
RE: .4 Here are my comments to the trace: > SNATRACE V2.1 PU Trace 20-NOV-1990 12:11:32.63 > Gateway node ALFRED Physical Unit SNA-0 > (Protocol version = 2.0.0, Buffering level = 10, Data size = 256) This is a PU trace that will trace ALL sessions on the PU (SNA-0). If there are several active sessions, the trace could be difficult to read. You can use TRACE ... SNA-0.140/SESSION to trace just your own session. You seems to have been lucky this time - there is only session involved below. > T 13:09:22.12 TH=2C00008C06E3 RH=0B8000 RU=25. bytes (005,00000000) > FID2,OS,DAF=00,OAF=8C,SNF=06E3 > RQ,FMD,FI,BCI,ECI,DR1I > 0106 8100 D4D9 C7C1 E3C5 4040 F308 D4C5 : .\a.MRGATE 3\ME > D4C7 E8E5 E4E2 0000 00 : MGYVUS... > > Send initiate request > > > R 13:09:22.15 TH=2C008C0006E3 RH=8B8000 RU=3. bytes (005,00000001) > FID2,OS,DAF=8C,OAF=00,SNF=06E3 > +RSP,FMD,FI,BCI,ECI,DR1I > 0106 81 : .\a > > VTAM positive Response Ok so far. MRMEMO has sent an INIT-SELF and received a positive response. > R 13:09:22.96 TH=2D008C01231F RH=6B8000 RU=37. bytes (005,00000001) > FID2,OS,EFI,DAF=8C,OAF=01,SNF=231F > RQ,SC,FI,BCI,ECI,DR1I > 3101 0303 A1A1 3060 0101 8585 8101 0000 : \...~~\-..eea... > 0000 0000 0000 0000 0000 0008 D4C5 D4C7 : ...........\MEMG > E8E5 E4E2 00 : YVUS. > > Send Bind request Just a nit - I would say "RECEIVE Bind request". Above, you used "Send initiate request" about info going out from MRMEMO so when info comes in (as here), it is "received". > T 13:09:23.31 TH=2D00018C231F RH=EB8000 RU=1. byte (005,00000000) > FID2,OS,EFI,DAF=01,OAF=8C,SNF=231F > +RSP,SC,FI,BCI,ECI,DR1I > 31 : \ > > Positive Response MRMEMO has responded positively to the Bind from Memo Gateway. The session is now established. > R 13:09:23.75 TH=2D008C012320 RH=6B8000 RU=2. bytes (005,00000001) > FID2,OS,EFI,DAF=8C,OAF=01,SNF=2320 > RQ,SC,FI,BCI,ECI,DR1I > 3201 : .. > > ???????????????????? may be data traced from an other session ???????? No, it's not another session - DAF(Destination Address Field)=8C (140 decimal). Memo Gateway has sent an UNBIND (for some yet unknown reason). > T 13:09:24.70 TH=2D00018C2320 RH=EB8000 RU=1. byte (005,00000000) > FID2,OS,EFI,DAF=01,OAF=8C,SNF=2320 > +RSP,SC,FI,BCI,ECI,DR1I > 32 : . > > Normally: Send Start Data Trafic SDT (A0) > Instead: Send '32' ???? So it might be a problem of my gateway ?? MRMEMO politely sends a positive response to Memo Gateway's UNBIND (exactly as it should). The session is now ended. > R 13:09:24.77 TH=2C008C0006D6 RH=038000 RU=1346. bytes * (005,00000001) > FID2,OS,DAF=8C,OAF=00,SNF=06D6 > RQ,FMD,BCI,ECI,DR1I > 4040 4040 4040 4040 4040 4040 4040 4040 : > 4040 4040 4040 4040 4040 4040 4040 4040 : > 4040 4040 4040 4040 4040 C440 C940 C740 : D I G > C940 E340 C140 D340 4040 C540 D840 E440 : I T A L E Q U > C940 D740 D440 C540 D540 E315 4040 40C5 : I P M E N T\ E > C5C5 C5C5 C5C5 C5C5 C5C5 C515 4040 40C5 : EEEEEEEEEEE\ E > C5C5 C5C5 C5C5 C5C5 C5C5 C540 4040 4040 : EEEEEEEEEEE > 4040 4040 4040 6161 6140 4040 4040 4040 : /// > 4040 4040 4040 4040 4040 4040 4040 4040 : > 4040 4040 4040 4040 E540 C140 D340 C240 : V A L B > D640 D540 D540 C515 4040 40C5 C5C5 4040 : O N N E\ EEE > 4040 4040 4040 4040 4040 4040 4040 4040 : > 4061 6161 1540 4040 C5C5 C540 4040 4040 : ///\ EEE > 4040 4040 4040 4040 4040 4040 4061 6161 : /// > 4040 40C1 4040 4040 4040 4040 4040 4040 : A > 4040 4040 4040 4040 4040 4040 4040 4040 : > > Logon Mask ???? > Expected is an Accept of SDT I think this is what is called the USS screen (Unsupported System Services). This is sent out by VTAM when the session ends. I guess it has some use when there isn't a gateway but a real IBM terminal connected to a fixed line. > T 13:09:24.79 TH=2C00008C06D6 RH=879000 RU=7. bytes (005,00000000) > FID2,OS,DAF=00,OAF=8C,SNF=06D6 > -RSP,FMD,SDI,BCI,ECI,DR1I > 0826 0000 4040 40 : \... > > Transmit negative Response This, I believe, is sent out by the SNA Gateway. Since there is no session, the data can't be sent anywhere so this function can not be used through an SNA Gateway. (0826 = 'FM function not supported'.) > Now the same again ..... > > T 13:09:27.67 TH=2C00008C06E4 RH=0B8000 RU=25. bytes (005,00000000) > FID2,OS,DAF=00,OAF=8C,SNF=06E4 > RQ,FMD,FI,BCI,ECI,DR1I > 0106 8100 D4D9 C7C1 E3C5 4040 F308 D4C5 : .\a.MRGATE 3\ME > D4C7 E8E5 E4E2 0000 00 : MGYVUS... Unfortunately there is not much we can conlude from the trace. It's on the "other side" (in Memo Gateway) that something strange happens. It sends an UNBIND completely unprovoked immediately when the session has been activated. RE .6: I'll see if I can try MR 3.2 too and reproduce your problem. Thank you for your patience, Anders | |||||
56.8 | Now we have to wait | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Tue Nov 20 1990 16:45 | 13 |
Hi Anders, your responses receive nearly faster than my questions raise. Thanks for explanation. So we'll have to find why MEMO sends the UNBIND request. Don't expect any further responses before next Thursday (29-Nov) because I'm on customer site. If you need urgent answers then you should contact Jean-Pierre Julaude @VBO. Very kind regards, Rainer |