Conference bulova::decw_jan-89_to_nov-90

    Are you running securpak?  See problem description in 1943 and
    answer in 1943.9.

    
    I have taken out secupack on the nodes and still get the same results 
    as before. Does anyone have a more ideas. 
    I have looked at the logs (decw_server_0.log and found nothing that
    puts up a flag.....

    
    Look in sys$login:decw$sm.log.
    

    Do the satellites load a full node database?  Try a minimal node database.
    Also do AUTOGEN with feedback at the earliest opportunity.

    --Simon

Are you sure nothing else besides securepak asks a question during login?  How
about SET TERM/INQ?

Burns

    
    I tried all these things mentioned and still come with nothing. I took
    out decwindow's startup and still no results. It appears to be started 
    because I get the digital banner, but when I log in, I get to the icon 
    box at the top of the screen and then it sits there for hours.....
    
    
    
    
    

This just happened to me yesterday.  The system would boot fine, I would
login, the icon box would come up but nothing further would happen, and
the cursor stayed as a "watch" cursor.  The problem was that GBLPAGES
was too low.  I believe this would also happen if GBLSECTIONS was too low.

If you can set host to the workstation, run SYSGEN and check the following
parameters:

	GBLSECTIONS should be at least 400
	GBLPAGES should be at least 30000
	GBLPAGFIL should be at least 6024

I went a little further and bumped up my GBLPAGES to 45000, as I believe
lots of extra global pages never hurts, only helps.

If you can't set host to your workstation (I couldn't), then just boot
the system conversationally, and change the parameters with SYSBOOT.

    It seems like it would be a good idea to prove one way or another
    whether there is anything in the LOGIN files causing trouble.  A visual
    inspection is not always sufficient.  Try renaming your LOGIN.COM, your
    DECW$LOGIN.COM, and the system's SYLOGIN.COM and DECW$SYLOGIN.COM to
    something else for one login.  Also make sure that your authorize file
    entry doesn't specify something wierd for your LGICMD file.

               Dave

Re .8,

	Ayup, .6 sound conspiciously like a faulty (SY)LOGIN.COM.
	Just this morning I helped a collegea with much the same problem
	description. To make it easy I added that someone else _could_
	succesfully log in on the same workstation. After checking that
	his SYSUAF quota were adequate, more generous than that other
	user, I concluded it *had* to be his LOGIN.COM. 
	To verify this assumtion I told him to $CREATE LOGIN.COM with
	only the line $EXIT in there... Bingo: System becomes useable.
	Turned out that he had an INQUIRE in there and since DECwindows
	V2 was installed yesterday the problem had become visibile.
	
	With V2 just about every user process now goes through LOGIN.COM.
	Creating a DECterm seems create two processes that each go through it ?!
	In it self this is goodness, but it spoils my process naming convention!
	Any cute hacks beside sending (Autostart) application through a command
	file first? Kernel code to modify 'other' proces nams? If I just could
	find out what is planned to happen AFTER login.com finishes... Please?
	For now, I think I am going back to my trusted DECW$LOGIN.COM and
	explicitly setting process names for the spawned applications.
	
	Anyway, back to the subject on hand, I had him put in a chunk of
	conditional code, driven be F$GETJPI("","TT_PHYDEVNAM"). Fixed!
	As the base note seems to indicate it happened to all the users
	in the cluster, it is the (or a) systemtem wide (sy)login.com that
	needs the attentions.
	
	Btw, Are the any better or prefered symbols / logical names / items
	to find out whether this is going to be a terminal window at all
	and specifically what application this is going to be?

Best wishes for the New Year,
Hein.

> 	Turned out that he had an INQUIRE in there and since DECwindows
> 	V2 was installed yesterday the problem had become visibile.

   Why does an INQUIRE cause a problem?  I am about to go to VMS 5.3
   DECwindows 2.0, and I have a SET TERM/INQUIRE in my LOGIN.COM, and
   want to know if, when, how or why this will cause a problem.

.10>  Why does an INQUIRE cause a problem?  I am about to go to VMS 5.3
.10>   DECwindows 2.0, and I have a SET TERM/INQUIRE in my LOGIN.COM, and
.10>   want to know if, when, how or why this will cause a problem.

In simple speak: Because there is no terminal to talk to (yet).

Under VMS V5.2, DECwindows V1.0 you did not always come by your LOGIN.COM
but now you do (apparently... Dunno the details).

I have to leave more comprehensive explanations to more knowledgeable folks.

Hein.

    
    	I was able to get decwindows to work. What I did was, at the end of
    my Systartup_v5.com. I submitted decw$startup to batch, when I did that 
    and reboot the workstations came with full blown decwindows.
    
    	This is only a patch to fix the problem with decwindows, this is
    not the solution to the problem. My Gblpages and Gblsections are high
    enough for decwindows to run.
    
    
    	

    DECwindows requires DECnet to be running, and will only wait so long
    for it to come up.  Now that DECwindows is started automatically, you
    must make it through your SYSTARTUP_V5 file in a timely manner.  Are
    you perhaps doing something in your boot that causes DECnet to take a
    long time to come up, such as loading the full E-Net database in-line?
    The fact that submitting the DECW$STARTUP at the end of SYSTARTUP_V5
    makes it work sounds really suspicious.

    Try defining /SYSTEM/EXEC DECW$IGNORE_DECNET "TRUE" (I think that's it)
    in your SYLOGICALS and see what happens.

                     Dave

    This is a reasonably old note but...
    
    
    Do you, by any chance have a scanner installed on one of the nodes.
    (MDS300 or something like that?)  If so, do you have VAX Image Services
    V1.0 still?
    
    The problem is that VIS V1.0 installs IMG$SHRLIB /WRITE/PROT and
    DECwindows V2.0 tries to install it just /OPEN/HEAD/SHARE, which fails.
    If not all nodes run VIS$STARTUP before DECW$STARTUP (after
    systartup_v5) then you will see the sessions hang after the icon box
    pops up.
    
    The solution is to either:
    
    1) comment out VIS$STARTUP
    
    2) install the latest version of the Image Services software
    
    and do a complete cluster reboot.
    
    
    	It took me 3 days a couple of weeks ago to track this problem down.
    
    						--Doug