T.R | Title | User | Personal Name | Date | Lines |
---|
2448.1 | some insight ?? | GSRC::WEST | Variables don't, Constants aren't | Wed Mar 14 1990 21:38 | 15 |
|
The server aborted your connection. Why you ask, well I'm not real sure.
I've seen it happen to clients that don't process events fast enough so their
event queue overflows and the server tells you to have a nice day.
I have also seen this error from clients when I do something clever like
change the host list so that some client is no longer allowed access to the
server.
For all I know it could be quite a few different things. What I don't know
is how to find out what the exact cause is. It sure would be nice if there
was a way to expand on the error message...hint...hint... :^)
-=> Jim <=-
|
2448.2 | | DECWIN::FISHER | Prune Juice: A Warrior's Drink! | Thu Mar 15 1990 14:54 | 10 |
| If the server broke the connection, things are in sufficiently bad shape
that there is no way the server, who knows, could tell the client, who
displays the message (with the possible exception of the case when the
session manager shoots the applications at logout time).
If you look in the server log, though, you should see why the server shot
you. SYS$MANAGER:DECW$SERVER_0_OUTPUT.LOG and *ERROR.LOG. I never remember
which one it is.
Burns
|
2448.3 | It's DECW$SERVER_0_ERROR.LOG | ALLZS::MORRISON | The Network IS the System | Thu Mar 22 1990 15:07 | 27 |
| I've got the same problem as .0, and my log tells me:
22-MAR-1990 14:33:17.1 %LIB-?-INSVIRMEM, insufficient virtual memory
-FOR-W-NOMSG, Message number 8018C8E8
-FOR-W-NOMSG
Client 8 is disconnected due to unrecoverable runtime error 158217 detected
while processing opcode 47
Exception Call stack dump follows:
8eec5
fb4d
dff4
dcaa
185cb
1fc62
d60a
10f5b
10a91
12a7f
********** marking the end of call stack dump **********
********************************************************
22-MAR-1990 14:33:18.1 ..ddx layer returns bad status(17)
22-MAR-1990 14:33.18.4 ..Dispatcher close down connection 8
22-MAR-1990 14:43:50.3 Using extra todo packet pool...
The problem only happens when I try to start the Calendar program.
I'm running VMS V5.3 on a VS2000.
|
2448.4 | Parameter in here should be VIRTUALPAGECNT | DECWIN::FISHER | Prune Juice: A Warrior's Drink! | Fri Mar 23 1990 15:15 | 23 |
| Ok, well as the log says, your server ran out of virtual memory. This may
mean that the page file quota of the server is not high enough, or it could
mean that the sysgen MAXPAGCNT parameter is not high enough.
The server should be getting started with plenty, so my guess is MAXPAGCNT.
Here is how you find out:
Do SHOW SYS on the server. Get the process ID for the server. Then do
SHOW PROC/CONT/ID=<the id you just found>. In the upper right of the display
is the number of virtual pages the server is using. Mine is now about 8000+
on an SPX. Your mileage may vary, but it should never even approach, say ,
20000. 15k might even be high.
Anyway, now do SHOW PROC/QUOTA/ID=<server id>. See how page file quota is
doing. If it is getting near 0, something is funny. If this is the case,
please report both the pfquota and the total number of pages the server is
using.
Now say R SYS$SYSTEM:SYSGEN and then SHOW MAXPAGCNT. I'll bet that you are
close to that limit. If so, try AUTOGEN. If that does not help, modify
MODPARAMS.DAT to raise MAXPAGCNT manually and run AUTOGEN again.
Burns
|
2448.5 | VIRTUALPAGECNT is the right parametet name | DECWIN::FISHER | Prune Juice: A Warrior's Drink! | Fri Mar 23 1990 15:16 | 4 |
| Whoops. I never remember these stupid parameter names. It is VIRTUALPAGECNT,
not MAXPAGCNT.
Burns
|
2448.6 | Possible cause: corrupt system disk | ALLZS::MORRISON | The Network IS the System | Wed Apr 04 1990 13:30 | 5 |
| My problem was possibly related to a corrupted system disk. Since I
have rebuilt the disk (and re-AUTOGENed it), this has gone away. It was
a tough one to find, however, since the disk was showing no hard errors.
It wasn't until VMSINSTAL.COM became unusable (and unreadable) that I caught
on to what was happening.
|