| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 974.1 | | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Mon Jun 19 1989 12:55 | 6 |
| Look at the sysgen parameter WINDOW_SYSTEM. It must be 1 or no DECwindows.
Is that it?
Burns
|
| 974.2 | should be ok??? | OLDTMR::COOLIDGE | | Mon Jun 19 1989 14:03 | 7 |
| RE: .1
The WINDOW_SYSTEM paremeter is set to "0" on the server and to "1"
on the client.
george
|
| 974.3 | Confused.... | EZWIND::LEVY | Bound to cover just a little more ground | Mon Jun 19 1989 15:23 | 13 |
| I'm confused.
.0 said "I have a system". .1 says that the server and client are different
machines.
Perhaps a little more information regarding the configuration would be in order.
Also, how can you run DECwindows on the server that has WINDOW_SYSTEM set
set to "0"? As far as I know, you have to have WINDOW_SYSTEM set to "1" on
both.
- Dave
|
| 974.4 | | 24810::SYSTEM | | Mon Jun 19 1989 15:46 | 21 |
| RE: .3
My apologies. There are times when the fingers don't always convey what
the mind is thinking.
VMS 5.2 was installed on a MV3600 with one system disk. It was
configured as a LAVC boot server and currently has eight satellites,
each being configured as a diskless client. DECwindows was installed
on the server node but as it does not have a graphics device the sysgen
parameter, WINDOW_SYSTEM, is set to "0". Each satellite was configured
to run DECwindows and its window parameter is set to (1).
As the system boots (either the server or one of the clients) there
aren't any of the informative messages that used to appear on VMS V5.1.
As this is my first experience with DECwindows and V5.2 I don't know
if that is the norm or not.
george
|
| 974.5 | Server is the workstation...it is providing graphics services | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Mon Jun 19 1989 20:26 | 20 |
| Let's start with terminology. The client is an application. The
server is a graphics server, that is a workstation. This is distinct
from the concept of a "compute server", i.e. a VAXserver or something.
As to the WINDOW_SYSTEM paramter, it certainly must be 1 on the
workstation. If you are not running DECwindows applications on the boot
node and trying to display them on a workstation, then I imagine that
having WINDOW_SYSTEM as 0 will not hurt anything. However, you might
as well set it to 1. The main reason for the existance of 0 is as a
default which will load neither the VWS or the DECwindows drivers and
give the system manager a chance to choose later.
Of course, this does not tell you why your system is not working. Did
you give it a chance to run autogen? Are the graphics devices there on
the workstation? (I.e. SHOW DEV G should list GA, GB, or GC; SHOW DEV
I should list IN, IM, IK)
Burns
|
| 974.6 | No graphics devices found | OLDTMR::COOLIDGE | | Tue Jun 20 1989 09:17 | 12 |
| RE: .5
Autogen has been run using feedback. No graphics devices (I or G) exist
on either the server or the client. At your suggestion I changed the
WINDOW_SYSTEM parameter to "1" on the boot node. It did not make any
difference.
Thanks for your quick response...
george
|
| 974.7 | How about a startup log file | EZWIND::LEVY | Bound to cover just a little more ground | Tue Jun 20 1989 11:45 | 6 |
| Perhaps if you got your startup to generate a log file, something in that would
be obvious. If not, you could post a pointer to the log file and maybe someone
here would see something.
- Dave
|
| 974.8 | DECWindows startup log file | OLDTMR::COOLIDGE | | Tue Jun 20 1989 15:14 | 64 |
| RE: .7
The folowing is the log file created when the satellite system
booted into the cluster and DECwindows was started.
george
===========================================================================
$SET VER
$ !
$ ! DECW$STARTUP.COM - Initialize the DECwindows environment
$ !
$ !****************************************************************************
$ !* *
$ !* COPYRIGHT (c) 1987,1989 BY *
$ !* DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS. *
$ !* ALL RIGHTS RESERVED. *
$ !* *
$ !* THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED *
$ !* ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE *
$ !* INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER *
$ !* COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY *
$ !* OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY *
$ !* TRANSFERRED. *
$ !* *
$ !* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE *
$ !* AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT *
$ !* CORPORATION. *
$ !* *
$ !* DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS *
$ !* SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. *
$ !* *
$ !* *
$ !****************************************************************************
$ !
$ ! This command procedure sets up the DECwindows environment. It should
$ ! be run at system startup time. It is not advisable to edit this procedure
$ ! as it may be replaced in future software updates. Instead, you should
$ ! perform site-specific commands in your SYSTARTUP file.
$ !
$ !
$ ! Check to see if we've been told to do nothing. If so, then deassign
$ ! the logical name (this is a one shot deal) and exit.
$ !
$ IF F$TRNLNM("DECW$IGNORE_DECWINDOWS")
$ THEN
$
$ !
$ ! Check the user privs. Exit if we can't get the right ones.
$ !
$ req_privs = "BYPASS,PRMGBL,SYSNAM,DETACH,PSWAPM,ALTPRI,NETMBX,TMPMBX,PRMMBX,SYSPRV,CMKRNL,PFNMAP,S
$ prev_privs = F$SETPRV(req_privs)
$ IF F$PRIVILEGE(req_privs) THEN GOTO privs_ok
$privs_ok:
$
$ !
$ ! Run the startup procedure as a subprocess.
$ !
$ IF F$TRNLNM("DECW$IGNORE_SUBPROCESS") .NES. "" THEN GOTO subprocess_ok
$ IF F$GETJPI(0,"MASTER_PID") .NES. F$GETJPI(0,"PID") THEN GOTO subprocess_ok
$ IF F$GETJPI(0,"PRCNAM") .NES. "STARTUP" THEN GOTO subprocess_ok
$ SPAWN/NOWAIT/NOLOG/INPUT=nl:/PROCESS=DECW$STARTUP/TABLES=DCLTABLES @sys$manager:decw$startup
$ prev_privs = F$SETPRV(prev_privs)
$ EXIT
|
| 974.9 | | EZWIND::LEVY | Bound to cover just a little more ground | Wed Jun 21 1989 09:35 | 36 |
| Well that log file didn't tell me much, but re-reading your previous reply
makes me wonder...
You said that "no graphics devices exist...on the server". This is clearly a
problem. DECwindows can't hope to do anything if it can't find the devices
to display upon.
At some point in your startup, there should be an AUTOCONFIGURE ALL in SYSGEN.
Has this been eliminated for some reason?
Here's what I get when I do SHOW DEV G and SHOW DEV I from a diskless
VAXstation 2000 server on our cluster:
Semour� sh dev g
Device Device Error
Name Status Count
GCA0: Online 0
Semour� sh dev i
Device Device Error
Name Status Count
IKA0: Offline 0
IMA0: Offline 0
INA0: Offline 0
Semour�
Yours should look similar. Until it does, I wouldn't expect DECwindows to
do much.
Perhaps someone with a little more experience than I has some better ideas?
Groping_in_the_dark,
- Dave
|
| 974.10 | information update... | OLDTMR::COOLIDGE | | Wed Jun 21 1989 10:48 | 32 |
| It appears that during the installation the application files were not
installed for some reason, so I ran DECW$TAILOR and added everything
with the exception of the programming support files. The system (boot
node) autogened and rebooted. I then rebooted one of the satellites
and the windows came up, almost. The cursor arrow did its change and
the screen changed to its usual off grey color. That is as far as it
gets. It appears to be stuck in some sort of loop, the screen blanks
and reappears every 10 seconds or so. Each loop appears to create a
process which runs LOGINOUT until it recycles and a new process starts.
A SHOW SYS looks like the following:
VAX/VMS V5.2-42N on node LES128 21-JUN-1989 10:31:53.74 Uptime 0 00:24:56
Pid Process Name State Pri I/O CPU Page flts Ph.Mem
23400041 SWAPPER HIB 16 0 0 00:00:01.29 0 0
23400047 ERRFMT HIB 7 54 0 00:00:00.32 89 104
23400048 CACHE_SERVER HIB 16 6 0 00:00:00.06 62 93
23400049 CLUSTER_SERVER HIB 10 24 0 00:00:00.41 158 204
2340004A OPCOM HIB 8 113 0 00:00:00.98 231 79
2340004B AUDIT_SERVER HIB 10 28 0 00:00:00.74 1300 165
2340004C JOB_CONTROL HIB 10 489 0 00:00:02.26 144 279
2340004D CONFIGURE HIB 8 11 0 00:00:00.19 112 153
2340004E SMISERVER HIB 9 65 0 00:00:00.90 299 417
2340004F NETACP HIB 10 26 0 00:00:01.73 281 384
23400050 REMACP HIB 9 12 0 00:00:00.10 76 46
23400052 DECW$SERVER_0 HIB 8 2593 0 00:00:53.72 61394 500
234000DC SYSTEM CUR 4 161 0 00:00:03.68 2596 318
234000DF HIB 4 32 0 00:00:00.87 557 500
Soooo, that is where I stand...
george
|
| 974.11 | Wait a couple of hours and then let AUTOGEN do it's thing... | EZWIND::LEVY | Bound to cover just a little more ground | Wed Jun 21 1989 11:15 | 8 |
| I'd recommend waiting a few hours...patience, patience...and then doing another
AUTOGEN. You'll probably have to force it through using FEEDBACK, 'cause the
system won't like to use FEEDBACK if it's been up for less than a day.
This AUTOGEN *should* fix whatever resource you're exhausting.
- Dave
|
| 974.12 | try this | NEURON::NICHOLSON | A belly as big as an oil spill | Wed Jun 21 1989 13:40 | 16 |
| Add the line
$decw$define decw$login_log name-of-log-file.log
to the file sys$manager:decw$private_server_setup.com (you might
have to create the file if it doesn't exist - there is a .template
version in sys$manager to get you going).
This will create a log from loginout and you should see error messages
about why loginout is failing and cycling.
Do you have any sys$manager:decw$server_access_*.dat files on the
boot node? If so, what's in them?
Mark
|
| 974.13 | Fails before logging | OLDTMR::BENNETT | | Wed Jun 21 1989 16:11 | 14 |
| We just tried this. We now have a 0-block log file for every time that
loginout cycled, and all created ~15 seconds apart.
Some other observations: a "show device wsa1 /full" shows an
ever-increasing number of operations. it increments by 4 every time
loginout cycles. Also, a process named _WSA1: appears, then
disappears, then reappears with a process ID incremented by one. I
guess this is consistent with loginout running...(?)
Thanks for the help so far,
-Steve
(working with the author of .0)
|
| 974.14 | | STAR::ORGOVAN | Vince Orgovan | Thu Jun 22 1989 19:00 | 3 |
| You might try enabling image accounting (i.e. $ set acc/enab=image)
and then looking to see what the exit status of the loginout image is.
|
| 974.15 | Maybe global pages exhausted? | UFP::MURPHY | Rick - WA1SPT/4 | Fri Jun 23 1989 21:28 | 6 |
| One WAG: double GBLPAGES and GBLSECTIONS on a satellite and reboot it.
I've seen this behaviour when the local transport couldn't create the
global section it needs. After a few days, AUTOGEN FEEDBACK will work
right.
-Rick
|
| 974.16 | thanks... | OLDTMR::COOLIDGE | | Wed Jun 28 1989 20:59 | 6 |
| I did a reinstall of V5.2-42N and DECwindows and the DECW process
has started. I'm not sure exactly what was wrong but would like to
thank all for their help.
george
|
| 974.17 | Same problem with 43Z | REVEAL::LEE | Wook... Like 'Book' with a 'W' | Thu Jul 06 1989 16:30 | 12 |
| I'm having the same kind of trouble after upgrading my cluster to 43Z.
In my case, the loginout process cycles, but I don't get the screen
flashing. I get a window manager started up, but when I try to start
any applications I get an error saying I can't open the display.
I've already autogened once, but it looks like I have to do it again.
I'll let folks know it helps.
Wook
|
| 974.18 | Autogen works so much better the second time around | REVEAL::LEE | Wook... Like 'Book' with a 'W' | Thu Jul 06 1989 20:17 | 9 |
| The second autogen fixed my problem. I'm up to 42000 Global Pages.
BTW, even though I did the second autogen after only five hours, the feedback
still helped a lot. I'll do another autogen in a few days to really tune things
up nicely. The LAVC server has been running fine.
Moral of the story: If at first you don't succeed, autogen again.
Wook
|