Conference bulova::decw_jan-89_to_nov-90

Look at the sysgen parameter WINDOW_SYSTEM.  It must be 1 or no DECwindows.

Is that it?

Burns

    RE: .1
    
    The WINDOW_SYSTEM paremeter is set to "0" on the server and to "1"
    on the client.
    
    george

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

    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
    
    

    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
    

    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
     

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

	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

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

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

    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

    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)
    

    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.

    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

    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

    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

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