| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 157.1 | Use an SNA/Gateway access name | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Wed Dec 16 1992 09:00 | 56 |
| RE .0:
When MRMEMO is being started, it is quite possible for this to happen
if you have specified a particular circuit and session address for MRMEMO
to use and this session address is occupied in the SNA/Gateway.
To avoid this problem, you can use an SNA/Gateway access name. Is this
a customer problem or is it a connection to our (Digital's) IBM in
Valbonne? In the SNA/Gateway ALFRED, there is the access name MEMOGWY
(see below) that you can use to make the SNA/Gateway pick a free session
address (in the range 121-140) for you. If *all* the sessions 121-140 are
in use, you're out of luck of course but that is probably a rare condition.
SNANCP> sho access memogwy char
Access Name Characteristics as of 16-DEC-1992 08:05:34 from ALFRED
Access name = MEMOGWY
Note = memo gwys NOT FOR TE
PU = SNA-0
LU list = 121-140
Logon mode = MRGATE
Application = MEMOGATE
Here's an extract from my MRMEMO server parameters that uses this access
name:
SNA Session Identification:
Gateway node: ALFRED
Access name: MEMOGWY
Circuit name:
Session address: 0
Application name: XXXXXXX <--- Use your Application name here
Logon mode entry:
I assume that the problem only occurs when MRMEMO is being started. If
you mean that the MRMEMO server suddenly goes into the
"%SNA-E-SESIN_USE, session address is already in use"
mode when it has been up and running for some time, then it is an
unknown problem that I have never heard about. If contact is lost with
MEMO, there *should* be a message in the log file informing about the
reason for the disconnect before the reconnect attempts are started.
It is, however, possible that some unusual disconnect reason is missed,
and therefore not properly logged. Does it happen often?
Can you give some more information about the environment? Is it a new
installation? Is it a new problem or has this been going on for a long
time? Have any changes been made in the environment recently (new
SNA/Gateway, new MEMO version, new Message Router, new VAX...?).
Is the network ok? (Check LINE counters on VAX and SNA/Gateway.)
Anders
|
| 157.2 | environment | TOSSUC::RECCHIA | | Thu Dec 17 1992 17:22 | 120 |
| The System is:
Vms 5.4-2
Memo 2.1
Mr 3.1-b
Sna api 2.3
Sna gtw mgt 2.0
Sna gtw 1.5
Sna CT 2.1-1
Allin1 2.4
No recent changes to the software configuration.
Memo was installed one year ago but it was not used (and maintained).
I'm working on two month and the problem happens every four-five days,
but yesterday, sending a 'wrong' mail (memo -> allin1), the server gone in
starting state and in the log file appeared the 'Session in use'.
The Sna channel (130 in our configuration) was used by link to Memo
server but tracing it no traffic was showed.
The mail had a bad prefix in address field: vax..recchia..a1 (right is
Vax.recchia..a1).
Repeating the 'Error'(and trying other bad addresses) after a server restart
I've the 'Session in use' in the log file after a dump due the bad
prefix , sometimes only the dump (today only the dump after a lot of
'errors'!). In old log files the Session in use appears sometimes after
an UNBIND received but mostly without any message preceding it.
Ciao. Paolo.
The dump of server:
$ set nocontrol = Y
$!----------------------------------------------------------------------------
$ SET NOVER
$ define tt nl:
$ run/nodebug sys$system:mrmsrv
Time: 1992-12-17 15:39:52.00; message from server MRMEMO2:
%MRMEMO-I-NEWACCOUNT, opening new accounting file: MEMO$DISK:[MRMEMO]MRMEMOACC2.DAT;85
Time: 1992-12-17 17:00:52.71; message from server MRMEMO2:
%MRMEMO-W-BADPREFIX1, receiver VAX@RECCHIA@A1 is active, string doesn't begin with prefix
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, receiving from MEMO after data received from MEMO
-MRMEMO-I-RING, ring: '1A 1A 1A 1A 1A 1A 1A 1A 13 36.', substates: 00000070
%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 089380B8:
%MRMEMO-W-BADPREFIX1, receiver VAX@RECCHIA@A1 is active, string doesn't begin with prefix
----- end of exception message
SRVMRA SRV$MRA_CHK_ONE_RCP 5855 00000100 001E60CD
SRVMRA SRV$MRA_CHK_RCP_ORNAMES 6105 0000003E 001E6316
SRVMRA SRV$MRA_USRMSG 7071 00000236 001E6D6F
SRVMRA SRV$MRA_ASSMBL 7567 0000003C 001E7368
SRVACT POST_MEMO 4958 0000001F 001EB31F
SRVACT SRV$ACT_R 5290 00000210 001EB6FF
SRVDSP SRV$DSP_FSM 3423 000002A6 001E342A
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
0026513E 0026513E
ADA$ELAB_DDS ADA$ELAB_DDS 0000000E 001C0C0E
00239B89 00239B89
Time: 1992-12-17 17:03:33.44; message from server MRMEMO2:
%MRMEMO-I-SHUTTING, server shutting down
Time: 1992-12-17 17:03:34.93; message from server MRMEMO2:
%MRMEMO-I-CLOSEACC, closing accounting file: MEMO$DISK:[MRMEMO]MRMEMOACC2.DAT;85
Time: 1992-12-17 17:03:35.04; message from server MRMEMO2:
%MRMEMO-I-BYE, VAX MAILGATE for MEMO Server Exit
$ logout
MRMEMO job terminated at 17-DEC-1992 17:03:35.81
Accounting information:
Buffered I/O count: 1001 Peak working set size: 2560
Direct I/O count: 155 Peak page file size: 12166
Page faults: 2584 Mounted volumes: 0
Charged CPU time: 0 00:00:05.94 Elapsed time: 0 01:23:58.89
Here the definition of Memo server:
MRMEMO2 summary as of 1992-12-17 16:10:02
Server Identification:
Node name: DECTO1
Mailbox name: MEMO2
Message Router Password: ****
SNA Session Identification:
Gateway node: TODG98
Access name:
Circuit name: CHAN-0
Session address: 130
Application name: ITMEMOD
Logon mode entry:
Related files:
Translation table: SYS$LIBRARY:MRMEMOTRA.TBL
Log file: MRMEMO$DIR:MRMEMO2.LOG
Accounting file: MRMEMO$DIR:MRMEMOACC2.DAT
Options:
Accounting: Enabled
Timestamp: Disabled
Header in text: Disabled
Request Notifications: Disabled
Send Notifications: Disabled
Cluster alias address: Disabled
Address translation: Disabled
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: None
Clock tick interval: 0 00:00:30.00
MEMO line length: 121
Wrap/truncation string:
Wrapping of long lines: Enabled
Word wrap margin: Disabled
Hyphenation string:
Hours to GMT: 0
|
| 157.3 | Check memory and do SNA trace | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Fri Dec 18 1992 13:20 | 77 |
| How many messages per day go through your MRMEMO? I'm quite sure there
is some minor memory leak in MRMEMO so after a large number of messages
(something like > 10 000) you can start to run out of virtual memory.
If memory can't be allocated, e.g. by the SNA API routines, I guess
strange things can happen. Do you have heavy traffic (thousands of
messages per day)?
You say that:
.2> I'm working on two month and the problem happens every four-five days,
^^^^^^^^^^^^^^^^^^^^
Does "every four-five days" mean that after a restart, the server runs
ok for at least a couple of days. Does the problem never occur soon
after a restart?
Check the virtual memory size of the MRMEMO process to see if it is
growing from day to day. In particular check the memory size when
the "Session in use" occurs. Has it reached it's limit? Does the server
run longer if it is given some more page file quota?
If memory growth is a problem, take a look at the patch in note 5.14,
which might help.
If memory growth is *not* a problem, a closer look at what is happening
on the SNA link could be the next step:
Check the counters in the SNA/Gateway on the LU used (SNA-0.130?). Any
errors when MRMEMO works normally? Any errors when the "Session in use"
problem occurs?
What versions are in use on the IBM side (MEMO and MEMO/GWY)?
MEMO/GWY 1.0 is quite old and, according to a reliable source, a little
buggy - the current version is 1.2. BTW, I recently had another support
call where there was a problem with the SNA connection to MEMO/GWY and
it was fixed by a patch (they call it ZAP) by Verimation. The symptoms
were not exactly the same as you have but nevertheless - it could very
well be a problem on the IBM side.
To find out what happens when "Session in use" appears, an SNA trace of
the events *before* the error is necessary. Could you keep an SNA LU
trace running on the MRMEMO LU until the problem appears?
Another thing you could play with is the (undocumented) logical name
MRMEMO$LOGMASK that makes the MRMEMO server log additional information in
the server log file. See note 5.8 for a description of MRMEMO$LOGMASK.
The combination 1, 2 and 40 (i.e. 43) could be an appropriate value for
you to try. This will, however, make the log file grow faster so look out.
MRMEMO$LOGMASK is checked by the server every clock tick (default 30
seconds) so you don't have to restart the server after defining the
logical.
.2> The mail had a bad prefix in address field: vax..recchia..a1 (right is
.2> Vax.recchia..a1).
.2> Repeating the 'Error'(and trying other bad addresses) after a server restart
.2> I've the 'Session in use' in the log file after a dump due the bad
.2> prefix , sometimes only the dump (today only the dump after a lot of
.2> 'errors'!). In old log files the Session in use appears sometimes after
.2> an UNBIND received but mostly without any message preceding it.
I don't think that the bad message itself causes the "Session in use"
error but it might do it indirectly in some way. The error message might
change the timing in some way. What kind of VAX is MRMEMO running on?
A small VAX with no free memory? In that case, an unusual event (such as
an erroneous message) could cause otherwise idle code paths to be activated
and a burst of paging and swapper activities to be triggered. This could
affect the timing of messages in the SNA communication.
There should of course not be any communication problems just because the
machine is a little slow but this is an area where we haven't tested MRMEMO
very much ourselves. Internally we use the IBM in Valbonne but we run
MRMEMO in Sweden so there is long way to the SNA/Gateway, i.e. long
response times. If you run MRMEMO on a slow VAX and use a fast SNA/Gateway
on the same LAN, you have a completely different timing situation.
Hope you find something of the above useful.
Anders
|