[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

2863.0. "DECW$SERVER gone" by MUDDIN::CHINNASWAMY (saro ccg mr04) Mon Jun 04 1990 15:51

Hi,

This log is from a Dcwrite user, She is trying to get the PELE book out
by Tomorrow . When She is trying to do the update of the Decwrite report Decwindow
    s dissapeared. Her hardware is 3200 and it has 16mg memory. When I do a
    show system there are no jobs swaped out but Decw$server is gone. Any
    Idea why is this happening?. 

Thanks in advance,

Saro

 4-JUN-1990 11:26:36.1 Hello, this is the X server
Dixmain address=13074
Now attach all known txport images
%DECW-I-ATTACHED, transport DECNET attached to its network
%DECW-W-ATT_FAIL, failed to attach transport LAT
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image
in SetFontPath
Connection 99700 is accepted by Txport
out SetFontPath
GPX color/monochrome support loaded
gpx$InitOutput address=12a410
Connection Prefix: len == 42
 4-JUN-1990 11:30:11.2 Now I call scheduler/dispatcher
 4-JUN-1990 11:30:13.6 Connection 99738 is accepted by Txport
 4-JUN-1990 11:30:19.9 Connection 99700 is closed by Txport
 4-JUN-1990 11:30:43.5 Connection 99738 is closed by Txport
 4-JUN-1990 11:30:46.8 Connection 99700 is accepted by Txport
 4-JUN-1990 11:30:49.8 Connection 99770 is accepted by Txport
 4-JUN-1990 11:31:28.4 Connection 99738 is accepted by Txport
 4-JUN-1990 11:32:21.6 Connection 9adf8 is accepted by Txport
 4-JUN-1990 11:32:57.8 Connection 9adf8 is closed by Txport
 4-JUN-1990 11:33:17.1 Connection 1ef200 is accepted by Txport
 4-JUN-1990 11:38:45.9 Connection 22eb00 is accepted by Txport
 4-JUN-1990 11:39:46.2 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:39:46.7 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:39:47.0 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:39:58.5 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:39:58.9 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:39:59.3 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:42:20.2 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:42:21.0 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:42:21.5 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:42:22.0 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:45:25.3 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:45:25.9 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:47:16.3 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:47:16.7 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:47:17.2 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:47:21.1 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:47:21.5 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:47:21.9 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:49:31.4 Connection 4db448 is accepted by Txport
 4-JUN-1990 11:50:22.5 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:50:23.8 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:50:25.1 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:50:31.4 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:50:31.8 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:50:32.7 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:52:22.5 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:52:23.0 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:52:23.4 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:52:23.9 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:54:32.2 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:54:33.6 MEMMGR/XREALLOC - zero amount is requested
 4-JUN-1990 11:54:35.4 Connection 22eb00 is closed by Txport
 4-JUN-1990 11:55:57.7 Using extra todo packet pool...
 4-JUN-1990 12:07:37.3 Connection 4db448 is closed by Txport
 4-JUN-1990 12:35:27.2 %LIB-?-INSVIRMEM, insufficient virtual memory
%W
T.RTitleUserPersonal
Name
DateLines
2863.1MOre information still crashesPEARLY::GAETZTue Jun 05 1990 10:42118
Some followup information. We are running VMS V5.3-1 DECwindows V1.0
DECwrite V1.0. This is an LAVC with 3 6320 boot nodes and 2 system disk,
one for boot nodes and on e for the satellites. DECwrite is running 
on the local system.

We have VIRTUALPAGECNT ASET TO 100000, PAGE FILE QUOTA (PGFLQUO) set to 100000
a 200000 page file on a local disk. BALSETCNT 35 AND ENTRY SLOTS 39.

After the params were increased we autogened and rebooted. We still get the 
following crashes. I am having the same problem on another system, same
cluster working on the same doc. The params on that system have not been
increased and is getting the same messages in the log concerning USING EXTRA
TODO PACKET POOL and INSUFFUCUENT VIRTUAL MEMORY.

NOTE 2448 seems to have a simular problem. How can I tell?

Any suggestions???
Thanks!



 4-JUN-1990 15:31:38.2 Hello, this is the X server
Dixmain address=13074
Now attach all known txport images
%DECW-I-ATTACHED, transport DECNET attached to its network
%DECW-W-ATT_FAIL, failed to attach transport LAT
-SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image
in SetFontPath
Connection 99700 is accepted by Txport
out SetFontPath
GPX color/monochrome support loaded
gpx$InitOutput address=12a410
Connection Prefix: len == 42
 4-JUN-1990 15:35:26.4 Now I call scheduler/dispatcher
 4-JUN-1990 15:35:29.1 Connection 99738 is accepted by Txport
 4-JUN-1990 15:35:34.8 Connection 99700 is closed by Txport
 4-JUN-1990 15:41:53.9 Connection 99738 is closed by Txport
 4-JUN-1990 15:41:57.2 Connection 99700 is accepted by Txport
 4-JUN-1990 15:42:00.2 Connection 99770 is accepted by Txport
 4-JUN-1990 15:42:41.9 Connection 99738 is accepted by Txport
 4-JUN-1990 15:43:25.9 Connection 9adf8 is accepted by Txport
 4-JUN-1990 15:55:07.1 Using extra todo packet pool...
 4-JUN-1990 16:30:01.8 %LIB-?-INSVIRMEM, insufficient virtual memory
-COB-W
Request opcode 53 is ignored due to internal runtime error 158217 for client 4(#error = 1)
Exception Call stack dump follows: 
	8f8c5
	fad5
	df7c
	dc32
	12b3a1
	131807
	13184f
	20ae7
	d5ee
	1083d
	10355
	13343
	41a
	8015ced3
	8015ce84
********** marking the end of call stack dump **********
********************************************************
 4-JUN-1990 16:30:03.3 %LIB-?-INSVIRMEM, insufficient virtual memory
-COB-W
Client 4 has made too many runtime errors(2), its connection is marked for termination
Exception Call stack dump follows: 
	8f8c5
	fad5
	df7c
	dc32
	12b3a1
	131807
	13184f
	20ae7
	d5ee
	1083d
	10355
	13343
	41a
	8015ced3
	8015ce84
********** marking the end of call stack dump **********
********************************************************
 4-JUN-1990 16:30:03.9 ..ddx layer returns bad status(17)
 4-JUN-1990 16:30:04.3 ..Dispatcher close down connection 4
 4-JUN-1990 16:30:28.3 %LIB-?-INSVIRMEM, insufficient virtual memory
Request opcode 45 is ignored due to internal runtime error 158217 for client 2(#error = 1)
Exception Call stack dump follows: 
	8f8c5
	ea21
	df7c
	1e06b
	1e567
	190b4
	1ef9e
	1efd0
	2030c
	d5ee
	1083d
	10355
	13343
	41a
	8015ced3
********** marking the end of call stack dump **********
********************************************************
 4-JUN-1990 16:30:32.3 Connection 99738 is closed by Txport
 4-JUN-1990 16:31:45.9 Connection 241218 is accepted by Txport
 4-JUN-1990 16:32:40.8 Connection 245680 is accepted by Txport
 4-JUN-1990 17:10:32.0 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD14.DECW$FONT;1
 4-JUN-1990 17:10:37.6 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
 4-JUN-1990 17:10:38.6 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
 4-JUN-1990 17:10:39.0 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
 4-JUN-1990 17:10:39.5 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
 4-JUN-1990 17:10:39.9 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
 4-JUN-1990 17:10:40.4 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
 4-JUN-1990 17:10:40.8 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
 4-JUN-1990 17:10:41.2 Cannot open font file SYS$COMMON:[SYSFONT.DECW.75DPI]TIMES_BOLD12.DECW$FONT;1
2863.2Try the page file quoteDECWIN::FISHERPrune Juice: A Warrior's Drink!Tue Jun 05 1990 14:4424
If you run out of virtual memory anytime on VMS, there is usually one of two
problems:  the sysgen parameter VIRTUALPAGECNT (which specifies the maximum
size of ANY process) and the individual process's page file quota.  Since the
former seems quite large in this case, it is probably the latter.

Try

$ search sys$manager:decw$startserver.com page

If you see something like this:

$ decw$server_page_file = 25000
$ IF F$TRNLNM("decw$server_page_file") .NES. "" -
        THEN decw$server_page_file = F$TRNLM("decw$server_page_file")
        /PAGE_FILE=     'decw$server_page_file' -

then just define the logical name DECW$SERVER_PAGE_FILE to be some large number
(greater than 25000).  If you see something more like

/PAGE_FILE = 25000

then you will have to edit the file and replace 25000 with a larger number.

Burns
2863.3DECwindow/DECwrite problemMUDDIN::CHINNASWAMYsaro ccg mr04Mon Jul 23 1990 14:52100
  Decwindow Server crash
  ======================
  The users's are running the DECwrite locally (from fileview application
  menu) now and they are very pleased with the performance.

  One of our DECwindow user was complaining that her workstation 
  performance was very poor. Also the windows were disapearing once 
  in a while. Chris Methot from SECG suggested the following:

 	" It can be caused by too small a VIRTUALPAGECNT SYSGEN parameter.
          This limits  what any one process can have of the pagefile.
          So even if you have a large  contiguous pagefile, all processes
          are severely limited to how much of it they can use.

    	  It can be caused by the user's UAF PGFLQUOTA set too low.
          Same as above only on  a per user basis.  I recommend a 100,000
          block pagefile, VIRTUALPAGECNT and  PGFLGQUOTA (UAF).

    	  If it finds any it uses your number for the server (not the window
          manager we had trouble with at the top).  I suggest you start the
          server with the system logicals defined EARLIER in the systartup:

   	  decw$server_wsdef           =       768
    	  decw$server_wsquota         =       1536
          decw$server_wsextent        =       6143
          decw$server_page_file       =       40000

       I know the DECwindow workstations don't look like timeshare
       systems but the basic rule is we don't want anything
       pagefaulting."

    After receiving mail from Chris I changed the following parameters:

    Increased the SYSGEN parameter VIRTUALPAGECNT=100,000 (the current
    value the default was about 38000).
  
    Increased the UAF pgflquo to 100,000 (it was 35,000)

    After making the change the performance was a little better, but every
    time she was using CTRL/W to clear the window, the window will disappear
    and get the black screen with user prompt. We were able to start the
    DECW$SERVER.COM manually and bring the decwindows, but when she started
    to bring the larger size Decwrite files, the window's will disappear.
    I posted a NOTE in Notes file and got a suggestion to look at the error
    message. 
  
    (this error was found SYS$MANAGER:DECW$SERVER_0_ERROR.LOG)
    The system was crashing with the following error
    4-JUN-1990 11:54:35.4 Connection 22eb00 is closed by Txport
    4-JUN-1990 11:55:57.7 Using extra todo packet pool...
    4-JUN-1990 12:07:37.3 Connection 4db448 is closed by Txport
    4-JUN-1990 12:35:27.2 %LIB-?-INSVIRMEM, insufficient virtual memory
    %W

    I posted the error in DECwindow's Notes file again and received the 
    following reply from Burns Fisher:

        If you run out of virtual memory anytime on VMS, there is
        usually one of two problems:  the sysgen parameter VIRTUALPAGECNT
        (which specifies the maximum size of ANY process) and the individual
        process's page file quota.  Since the former seems quite large in
        this case, it is probably the latter.

        Try

	$ search sys$manager:decw$startserver.com page

	If you see something like this:

	$ decw$server_page_file = 25000
	$ IF F$TRNLNM("decw$server_page_file") .NES. "" -
        	THEN decw$server_page_file = F$TRNLM("decw$server_page_file")
        	/PAGE_FILE=     'decw$server_page_file' -

	then just define the logical name DECW$SERVER_PAGE_FILE to be some
        large number (greater than 25000).  If you see something more like

	/PAGE_FILE = 25000

	then you will have to edit the file and replace 25000 with a larger
        number.


   The final fix was changing the sys$common:[sysmgr]startserver.com
   file DECW$SERVER_PAGE_FILE=100,000.  The other parameter value's
   are higher and did not change.

================================================================================

   Also did the following changes for DECwrite Performance:

   (VPA was suggesting to increase the WSQUO and WSEXTENT and increase the 
   SYSGEN parameter PQL_DWSQUOTA)

   Increased the WSQUO and WSEXTENT.

   The user's are running the DECwrite locally (from fileview application
   menu) now and they are very pleased with the performance.