| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 54.1 | No problem here, I'm afraid | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Tue Oct 30 1990 14:44 | 25 |
| Hello Rainer
I have tried to reproduce this but without success. Starting and
stopping TS and/or DDS doesn't prevent MRMEMO here from reconnecting
properly to MR (and MEMO). Can you reproduce this or was it a one-time
event? If you can reproduce it, could you be more specific about the
order of events that causes this to happen.
Once, I have seen MRMEMO fail to reconnect to MR because it already was
connected (status MRIF$_CONNECTED). This should not happen so there is
probably a bug somewhere yet to be found.
You might be able to get a hint about what is happening if you define
the logical name MRMEMO$LOGMASK to "2" in a context where the MRMEMO
server can "see" it (i.e. /SYSTEM). This makes the server signal some
events in the logfile, in particular connect attempts to MR and the
resulting status.
The reluctance by the MRMEMO server to shut down when ordered to, is
something I have experienced several times. Unfortunately not in a
reproducable way, however.
I'll do some more testing...
Anders
|
| 54.2 | Reproducable at least sometimes | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Wed Oct 31 1990 09:47 | 14 |
| Hi Anders,
I could reproduce the error. Unfotunately I didn't define the LOGMASK
before. First I did send a message to MEMO such that the last state
says 'message sent to MEMO'. Then I did MB$CONTROL STOP=(TS,DDS) and
waited until the server tried to connect to MR. The connection to MEMO
was still established. But I was unable to shut the server down. After
STOP/ID=.. I couldn't reconnect to MEMO (I guess the session is still
active abd I've to contact the MEMO manager). Therefore currenntly
further testing is not possible for me.
Regards,
Rainer
|
| 54.3 | SHUT could be ignored | STKHLM::OLSSON | Anders Olsson, SIP Sweden | Fri Nov 02 1990 12:47 | 25 |
| I think I have found something now (by reading the code). I still haven't
been able to reproduce the problem but it seems to be somewhat timing
related.
One problem is that when the server has received the SHUT order, the
server won't shut down immediately if it has sent a message to MEMO that
has not yet been acknowledged by MEMO. It will wait until the ack. has
been received.
If MR goes away (e.g. due to MB$CONTROL STOP...), MRMEMO will enter
a restarting state where it repeatedly tries to connect to MR and MEMO.
One of the cleanup operations performed in this restart loop is to zero
some flags, of which one unfortunately is the 'pending shutdown' flag.
So, shutting down a server in a restarting state could be difficult.
By giving the SHUT command several times, you might be able to set the
shutdown flag in the right moment and have the server shut down. This
problem will of course be fixed in the next release of MRMEMO, but for
now, STOP/ID is necessary to reliably stop a server that is in the
restarting loop.
If we can find a simple solution to this problem, a patch will
eventually appear in Note 5.?.
Anders
|
| 54.4 | Again problem after STOP=DDS | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Thu Jan 24 1991 10:43 | 80 |
| Again I was unable to stop the MEMO server. The following occured:
1. I stopped DDS withou shutting the MEMO server down and the I got the
a stack dump (see below)
2. After restarting DDS I got an other stack dump (see below first dump)
My LOG file size did grow to more than 18000 blocks (within less
than 20 hours)
3. I was unable to MRMMAN> SHUT or NCP> DISC LINK id
I've installed the PATCH for the problem in the previous replies.
Regards,
Rainer
Time: 1991-01-23 15:50:56.43; message from server MRMEMO1:
%DDS-E-OPSYS, Operating system interface error
-SYSTEM-F-NOPRIV, no privilege for attempted operation
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, starting, connecting to MR and MEMO Gateway after clock tick
-MRMEMO-I-RING, ring: '1A 1A 1A 1A 1A 1A 1A 1A 1A 4A.', substates: 00000000
%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 0145808A:
%DDS-E-OPSYS, Operating system interface error
-SYSTEM-F-NOPRIV, no privilege for attempted operation
----- end of exception message
002FC147 002FC147
002F797F 002F797F
SRVMRC SRV$MRC_INIT 4649 00000134 001E7684
SRVACT SRV$ACT_C 4306 000001BF 001EADD9
SRVDSP SRV$DSP_FSM 3467 00000338 001E34BC
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: 1991-01-24 00:00:19.02; message from server MRMEMO1:
%MRMEMO-W-DDSINITTIME, DDS initialization timed out
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, starting, connecting to MR and MEMO Gateway after clock tick
-MRMEMO-I-RING, ring: '][ 4A ][ 4A ][ 4A ][ 4A ][ 4A.', substates: 00000000
%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 089380F0:
%MRMEMO-W-DDSINITTIME, DDS initialization timed out
----- end of exception message
SRVMRC SRV$DDS_INITIMEOUT 4570 0000000F 001E754F
801694F3 801694F3
SRVMRC SRV$MRC_INIT 4647 00000121 001E7671
SRVACT SRV$ACT_C 4306 000001BF 001EADD9
SRVDSP SRV$DSP_FSM 3467 00000338 001E34BC
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
|
| 54.5 | working... | STKOFF::SPERSSON | Pas de Probleme | Fri Jan 25 1991 16:41 | 24 |
|
Rainer,
I'm struggling with this one. We can indeed reproduce the error, so
that's not a problem. I thought I was onto something when I gave the
MRMEMO account all privileges (given that the log says "NOPRIV", and it
actually works on one of my systems, running MR V31B. MRMEMO logs "DDS
has shut down" (once) when I stop DDS, and then when I restart DDS, the
gateway starts working again.
On the other system, running MR T3.2 (BL9.04), when I give the MRMEMO
account all privileges, initially the server behaves as above, but when
I restart DDS, the MRMEMO server basically seems to hang. It does not
build up huge log files however, which does seem like some improvement.
I have not tested exactly which extra privilege is needed.
Now whether MR V3.1B is significant or whether I should check out
quotas (that's always fun) I really don't know. Which version of MR are
you running?
cheers,
Stefan
|
| 54.6 | FT MR V3.2 BL9.05 | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Mon Jan 28 1991 09:46 | 8 |
| Hi Stefan,
I forgot to describe our environment. We indeed are running the FT
version of MR V3.2 (T3.2 BL9.05).
Rainer
|
| 54.7 | MR V3.1B and all privs | STKOFF::SPERSSON | Pas de Probleme | Fri Feb 01 1991 17:30 | 22 |
|
OK, this is what I've found when I finally got time to look around ( I
only tested with shutting down and starting DDS):
1) MR V3.1B is definitely significant. T3.2 will not work whatever you
do about 2) and 3)
2) If you give the MMRMEMO account ALL *authorized* privileges it will
behave as exected (ie log DDS-SHUTDWN once plus DDS-TIMEOUT once and
then wait for DDS to come up without the runaway logging). I have tried
to find which extra privilege that is needed but so far have failed. I
tried READALL, BYPASS, EXQUOTA, SYSLCK all of which seemed relevant for
DDS.
3) At one time after raising privileges I encountered ACP-CREATE-FAILED
so I also upped the /FILE_LIMIT value in MRMEMO$DIR:MRMEMOLOGIN.COM
from 32 to 64.
I think I'll give up now. Will you accept the above as a workaround?
Stefan
|
| 54.8 | Configuration of MEMO on IBM question | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Mon Feb 04 1991 09:51 | 18 |
| Hi Stefan,
my gateway is installed in an test environment. Therefore this problem
isn't too critical.
A more critical problem is when we have to STOP/ID the memo server
and then are unable to restart the server due to the IBM state
'session already in use (or something like this)'. The IBM people in
Valbonne can release the session only in the evening. Hence demos could
be impossible if a problem appears at the same day before a demo will
be given. Isn't there a possibility to configure our MEMO system in
Valbonne such that sessions will be released automatically after
the server disappears. It seems that the MEMO manager in Valbonne
doesn't know a solution.
Regards,
Rainer
|
| 54.9 | Use Access Names, and don't specify Session No | STKOFF::SPERSSON | Pas de Probleme | Mon Feb 04 1991 10:24 | 29 |
|
Rainer,
> A more critical problem is when we have to STOP/ID the memo server
> and then are unable to restart the server due to the IBM state
> 'session already in use (or something like this)'. The IBM people in
> Valbonne can release the session only in the evening. Hence demos could
> be impossible if a problem appears at the same day before a demo will
> be given. Isn't there a possibility to configure our MEMO system in
> Valbonne such that sessions will be released automatically after
> the server disappears. It seems that the MEMO manager in Valbonne
> doesn't know a solution.
Are you sure you're describing the problem correctly? I was not aware
that an incorrectly stopped server does not release SNA related
resources. In fact I'm pretty sure they are released.
I always thought "session already in use" means exactly that, ie
someone else is running a server towards your session no. The session
no is not dedicated to your specific MRMEMO server.
However, there is a way to get around specifying dedicated session
no's, and that is: Use Access Names! That way you will be assigned a
free session by the SNA Gateway (I think). There is an access name
defined on the Valbonne equipment for MRMEMO, "MEMOGWY". Try this:
MRMMAN> DEFINE/ACCESS=MEMOGWY/SESSION=0
It works here.
|
| 54.10 | Some misunderstandings in my head ?!? | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Tue Feb 05 1991 09:46 | 18 |
| Hello Stefan,
I got a dedicated session address parameter from Valbonne. So I'm
always using the same address. Sure if you are only using an access
name then you will pick up a free session address. But I thought that
this is not allowed in our IBM environment in Valbonne.
May be that there is also a further misunderstanding. I thought that
the session address and the DGA name are in a one-to-one relation, i.e.
if I'm using a different session address then I'll pick up the wrong
mails. This means an access name can be used if and only if the access
name is dedicated to a single session address. But your reply says
that during establishing the connection to MEMO the correct MEMO queue
is selected.
Regards,
Rainer
|
| 54.11 | Application Name is unique | STKOFF::SPERSSON | Pas de Probleme | Tue Feb 05 1991 12:25 | 15 |
|
No, the Application Name has to be unique, not the session. Obviously
the MRMEMO documentation is a little ambiguous here, because from
reading it you get the impression that an Application name should not
be used in conjunction with Access Name. This is not true, you can
specify the Application Name as well as Access Name. However if you
specify both in the same MRMMAN command you'll get "illegal combination
of command elements"!
Not very clever I guess, and we probably should fix it. On the other
hand I daresay that most customer systems never have to worry about
several servers (most customers have one MRMEMO server/MEMO system, a
few have two, but I have never heard of anyone with more)
Stefan
|
| 54.12 | Again SHUT problems | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Wed Mar 20 1991 09:55 | 340 |
|
I've still problems to stop MRMEMO under some circumstances. I've the feeling
that a message sent from MR/TELEX to MEMO causes MEMO to lose the link to DDS.
Afterwards MEMO is unable to reconnect to DDS and I'm unable to SHUT MRMEMO
down. I've already installed the "SHUT PATCH". The problem is that I cannot
reproduce the problem by will, it only occures occasionally.
When the problem above occures then the command SHO SYS sometimes shows MUTEX
for the Memeo server process. I'm not able to disconnect the link to the
SNA gatway (NCP disc).
May be it's a problem with requested service messages. After disabling the
notification and receive requests the gateway seemed to be more stable.
Regards,
Rainer
Attachments :
NBSDUMPS
MROUTER_node.INF
my configuration
Log file
=============================================================================
File DISK$USER:[MRMEMO]MRMEMO1-ENVELOPE.NBS;1 contains ****** bytes.
000003 1 MSG[V2ENV] Len=******
000006 2 FIELD[MID] Len=00001D
000008 3 ASCII Len=00001B
"60627191301991/12413@VUSCLU
000026 2 FIELD[PDATE] Len=000012
000028 3 DATE Len=000010
00002A 4 ASCII Len=00000E
"19910319172606
00003B 2 FIELD[PREC] Len=000003
00003D 3 INT Len=000001
%01
000041 2 FIELD[SENDER] Len=000077
000048 3 ENT[NAME] Len=000070
00004E 4 SEQ Len=000035
000055 5 ATTR[X121ADDR] Len=000009
000057 6 ASCII Len=000007
"5218145
000065 5 ATTR[PNAME] Len=00001E
00006C 6 ATTR[SURNAME] Len=000009
00006E 7 ASCII Len=000007
"DIGITAL
00007C 6 ATTR[GIVENNAME] Len=000007
00007E 7 ASCII Len=000005
"TELEX
000089 4 SEQ Len=00002F
000090 5 ATTR[ROUTE] Len=000015
000096 6 SEQ Len=00000F
000098 7 ASCII Len=000006
"VUSCLU
0000A0 7 ASCII Len=000005
"TELEX
0000AC 5 ATTR[USERID] Len=00000C
0000AE 6 ASCII Len=00000A
"11=5218145
0000BC 2 FIELD[TO] Len=00007F
0000C2 3 SEQ Len=000079
0000C9 4 ENT[NAME] Len=000072
0000CF 5 SEQ Len=000031
0000D6 6 ATTR[PNAME] Len=00001D
0000DD 7 ATTR[SURNAME] Len=000009
0000DF 8 ASCII Len=000007
"Gyvusaa
0000ED 7 ATTR[GIVENNAME] Len=000006
0000EF 8 ASCII Len=000004
"Memo
0000FA 6 ATTR[ORGANTNUNIT] Len=000006
0000FC 7 ASCII Len=000004
"MEMO
000106 5 SEQ Len=000027
00010D 6 ATTR[ROUTE] Len=00000C
000113 7 SEQ Len=000006
000115 8 ASCII Len=000004
"MEMO
000120 6 ATTR[USERID] Len=00000D
000122 7 ASCII Len=00000B
"DGA.GYVUSAA
000134 5 ATTR[PERRECFLG] Len=000007
000137 6 BITS[%00] Len=000004
%A8000000
000140 2 FIELD[PERMSGFLG] Len=000007
000143 3 BITS[%00] Len=000004
%10000000
00014C 2 FIELD[CONTENTTYPE] Len=000007
00014F 3 BITS[%00] Len=000004
%00000040
000159 2 FIELD[ITRACE] Len=00008A
00015F 3 SEQ Len=00003F
000168 4 FIELD[MTA] Len=000008
00016A 5 ASCII Len=000006
"REFVUS
000179 4 FIELD[ARVDATE] Len=000016
00017F 5 DATE Len=000010
000181 6 ASCII Len=00000E
"19910319172233
000198 4 FIELD[ACTION] Len=000006
00019A 5 INT Len=000004
%00000000
0001A4 3 SEQ Len=00003F
0001AD 4 FIELD[MTA] Len=000008
0001AF 5 ASCII Len=000006
"BARVUS
0001BE 4 FIELD[ARVDATE] Len=000016
0001C4 5 DATE Len=000010
0001C6 6 ASCII Len=00000E
"19910319172606
0001DD 4 FIELD[ACTION] Len=000006
0001DF 5 INT Len=000004
%00000000
0001E8 2 FIELD[CONTENTDIA] Len=000006
0001EA 3 INT Len=000004
%00000002
0001F3 2 FIELD[HOPCOUNT] Len=000006
0001F5 3 INT Len=000004
%00000002
0001FA 0End of file
=============================================================================
File DISK$USER:[MRMEMO]MRMEMO1-CONTENTS.NBS;1 contains ****** bytes.
000003 1 MSG[V2CONT] Len=******
00000C 2 FIELD[APPMID] Len=00001E
00000E 3 ASCII Len=00001C
"TELEX$_TXA0_1991031917230700
000031 2 FIELD[FROM] Len=000077
000038 3 ENT[NAME] Len=000070
00003E 4 SEQ Len=000035
000045 5 ATTR[X121ADDR] Len=000009
000047 6 ASCII Len=000007
"5218145
000055 5 ATTR[PNAME] Len=00001E
00005C 6 ATTR[SURNAME] Len=000009
00005E 7 ASCII Len=000007
"DIGITAL
00006C 6 ATTR[GIVENNAME] Len=000007
00006E 7 ASCII Len=000005
"TELEX
000079 4 SEQ Len=00002F
000080 5 ATTR[ROUTE] Len=000015
000086 6 SEQ Len=00000F
000088 7 ASCII Len=000006
"VUSCLU
000090 7 ASCII Len=000005
"TELEX
00009C 5 ATTR[USERID] Len=00000C
00009E 6 ASCII Len=00000A
"11=5218145
0000AF 2 FIELD[TO] Len=000081
0000B5 3 SEQ Len=00007B
0000BC 4 ENT[NAME] Len=00003D
0000C2 5 SEQ Len=000000
0000C8 5 SEQ Len=000031
0000CF 6 ATTR[USERID] Len=00002A
0000D1 7 ASCII Len=000028
"( -TELEX/MARK LONGUET/524607/PZVUS D/L )
000100 4 ENT[NAME] Len=000030
000106 5 SEQ Len=000024
00010D 6 ATTR[PNAME] Len=00001D
000114 7 ATTR[SURNAME] Len=000009
000116 8 ASCII Len=000007
"GYVUSAA
000124 7 ATTR[GIVENNAME] Len=000006
000126 8 ASCII Len=000004
"MEMO
000130 5 SEQ Len=000000
000137 2 FIELD[SUBJ] Len=000021
000139 3 ASCII Len=00001F
"INCOMING TELEX FOR MEMO ACCOUNT
000161 2 FIELD[CRTDATE] Len=000012
000163 3 DATE Len=000010
000165 4 ASCII Len=00000E
"19910319172307
00017A 2 FIELD[PREC] Len=000003
00017C 3 INT Len=000001
%01
000186 2 FIELD[FORWDED] Len=000003
000188 3 INT Len=000001
%00
000190 2 FIELD[ATTACH] Len=0003F2
000197 3 MSG[TEXT] Len=0003EB
00019D 4 ASCII Len=0003E5
"
Text removed here ...............................
000583 0End of file
=============================================================================
1991031917223500,S1051,VUSCLU
1991031917223500,E1051,60627191301991/12413@VUSCLU,61
1991031917223500,D1051,MEMO, <-- see timestamp
and compare with
time in LOG
=============================================================================
VAX MAILGATE for MEMO Manager version V2.1
MRMEMO1 summary as of 1991-03-19 17:54:13
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
=============================================================================
%DDS-F-OPSYSFATAL, Fatal operating system interface error
-SYSTEM-F-IVLOCKID, invalid lock id
%ADA-I-TASTERUNH, Task with ID %TASK 32 of type results_handler has terminated due to unhandled exception
Time: 1991-03-19 17:22:52.93; message from server MRMEMO1:
%ADA-F-EXCCOPLOS, Exception was copied at a "raise;" or "accept", but some details were lost
-DDS-F-OPSYSFATAL, Fatal operating system interface error
-SYSTEM-F-IVLOCKID, invalid lock id
%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: '1A 1A 1A 1A 1A 1A 1A 1A 1A 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 0031B53C:
%ADA-F-EXCCOPLOS, Exception was copied at a "raise;" or "accept", but some details were lost
-DDS-F-OPSYSFATAL, Fatal operating system interface error
-SYSTEM-F-IVLOCKID, invalid lock id
----- end of exception message
00268CDB 00268CDB
DDS_UTIL LOOKUP 2975 0000366A 001DF9B7
SRVDDS SRV$DDS_LOOKUP 3361 00000358 001EC1F7
SRVMRD SRV$MRD_GETSND 9998 00000173 001F1343
SRVMRD SRV$MRD_DISASS 11358 0000030D 001F22A0
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: 1991-03-19 17:23:01.41; message from server MRMEMO1:
%DDS-F-OPSYSFATAL, Fatal operating system interface error
-SYSTEM-F-IVLOCKID, invalid lock id
%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: '1A 1A 1A 1A 1A 1A 1A 1A 1A 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 01458804:
%DDS-F-OPSYSFATAL, Fatal operating system interface error
-SYSTEM-F-IVLOCKID, invalid lock id
----- end of exception message
002FC147 002FC147
002F7B73 002F7B73
SRVMRC SRV$MRC_DISCONNECT 4868 00000030 001E792C
SRVMMO SRV$MMO_CLEANUP 4085 0000001F 001E00FB
SRVMMO SRV$MMO_MAIN 4210 00000022 001E01CE
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: 1991-03-19 17:23:09.69; message from server MRMEMO1:
%DDS-F-OPSYSFATAL, Fatal operating system interface error
-SYSTEM-F-IVLOCKID, invalid lock id
%MRMEMO-W-TRACE, traceback forced from the Server Handler
-MRMEMO-I-FSM, starting, connecting to MR and MEMO Gateway after clock tick
-MRMEMO-I-RING, ring: '1A 1A 1A 1A 1A 1A 1A 1A 19 4A.', substates: 00000000
%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 01458804:
%DDS-F-OPSYSFATAL, Fatal operating system interface error
-SYSTEM-F-IVLOCKID, invalid lock id
----- end of exception message
002FC147 002FC147
0030800A 0030800A
002F7AF9 002F7AF9
SRVMRC SRV$MRC_INIT 4649 00000134 001E7684
SRVACT SRV$ACT_C 4306 000001BF 001EADD9
SRVDSP SRV$DSP_FSM 3467 00000338 001E34BC
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
|
| 54.13 | Related to 55 | MUDIS3::RROSENBERGER | Rainer Rosenberger @MFR, PZ-SOGY | Wed Mar 20 1991 11:39 | 5 |
| I'm aware that my problem is related to the resource problems mentioned
in .55. But there is still the SHUT problem and this should be fixed
too.
Rainer
|