Conference bulova::decw_jan-89_to_nov-90

    Greg, here's a shot in the dark...

    We ran into this exact behavior when we exhausted GBLPAGES --
    applications would run, but no DECterm or FileView.  The culprit was a
    system manager-type who installed a product without updating the
    appropriate SYSGEN parameters -- when the system rebooted, we ran out
    of "stuff" by the time DECwindows was started.  We discovered that the
    specific cause of the problem was that one of the X/DECw RTL's couldn't
    be INSTALL'ed. 

    If this is really the culprit, you should be able to do an INSTALL LIST
    /GLOBAL /SUMMARY -- if the number of free pages is low (say ~1500 or
    less), try bumping it up and see if that clears up the problem.

    Check on GBLSECTIONS too...


    Mike Endsley
    SWS @ STO

    That was it.  He did an autogen over nite, and in the process, it
    significantly increased both gblpages and sections.  Now, all works
    well.  Thanks for the hint!
    
    Greg...

Where is DECW$login.COM invoked?  I searched SYS$MANAGER:DECW*.COM, without
success?

tl

DECW$LOGIN.COM is run during startup of the session manager process.
I imagine that the mechanism is very similar to the one that gets
LOGIN.COM and SYLOGIN.COM executed under different circumstances -- i.e.,
it's set up by LOGINOUT and you therefore won't find any visible
references in ".COM" files.

Put DECW$LOGIN.COM in your SYS$LOGIN: directory, and the session manager will
find it and invoke it when you start a session.

--PSW

    Where is DECW$LOGIN.COM documented?  I've looked high and low through
    all of the Tables of Contents and Indices of the "Using DECwindows"
    manuals and can find no reference to this stuff.  This seems like the
    most likely place it should be documented.
    
    If it is documented in there, how do I suggest to the documentation 
    writers that the references should be much easier to find?  
    
    Thanks much.
    
    - Dave

	Hi,

	Here's another question on the fuzzy DECW$LOGIN.COM; when I
DEFINE/JOB a logical name in DECW$LOGIN.COM, and try to reuse that logical name
in the regular LOGIN.COM, it just doesn't exist anymore. On the other hand, any
logical DECW$DISPLAY defined in DECW$LOGIN seems to be available for later
references - what's going on exactly, there???

	Thanks for help,
	/Jean-Michel

    SYS$LOGIN:DECW$LOGIN.COM only gets run if you are logging in via
    DECWindows. If your LOGIN.COM expects the logical name to always be
    defined, it will be disapointed if you are logging in over the LAT.
    
    Could this be your problem?
    
    Andy

	Sorry, my reply wasn't that clear, I'm afraid.

	I know DECW$LOGIN.COM gets activated ONLY when you log in on a
DECwindows station. Trouble is, even then whatever is defined in that command
file isn't passed to LOGIN.COM...!

	What I wanna do, actually, is automatically have the environment be 
checked:, something like:
	if this_is_regular_lat_session
	  then
	    fool around with colors
	  else
	    keep clear from colors
	endif

	This is because when I log in through LAT on a VT, it happens to be on
an ALL-in_1 engine, where I want to modify the color setup (in LOGIN.COM); on
my workstation, I don't want LOGIN.COM to change anything, and skip that section
of the code instead.

	'Thought the easiest way was to define a logical name in DECW$LOGIN.COM,
(define/job WINDOW_MODE YES), and check for the existence of the logical in the
LOGIN.COM - doesn't work!

	But then, I can't understand how the logical DECW$DISPLAY manages to
get into the logical name tables...

	Does this make sense, or not?
	Regards,
	/JM
		

    Hmm. This always works for me. Are you sure DECW$LOGIN is being run? If
    so, do you do a DEASS/ALL or somesuch in your LOGIN?
    
    A

The Session Manager runs DECW$LOGIN.COM, but not LOGIN.COM

An interactive process running under a DECterm (etc.) runs LOGIN.COM but not
DECW$LOGIN.COM.  It runs in a DIFFERENT JOB from the Session Manager... it won't
share process or job logical names (it will share group and system names).  The
DECW$DISPLAY logical is explicitly COPIED between job name tables, behind your
back (if you change one, it won't affect the other: which is usually what you
want).

If you really need a non-group shared name table, create your own.  It's easy
and it's powerful (unfortunately, it also requires privs). Or else figure
out a different way to communicate between DECW$LOGIN.COM and LOGIN.COM (like
perhaps marker files in SYS$LOGIN?)

	/dave

	Thanks Dave; that's exactly what I wanted to know.

	In case someone else ever happens to browse thru this topic, I solved
my specific problem with a F$GETJPI("","TERMINAL"); sounds like the Columbus
egg, isn't is?

	/JM

re .1

>    We ran into this exact behavior when we exhausted GBLPAGES --
>    applications would run, but no DECterm or FileView.  The culprit was a
>    system manager-type who installed a product without updating the
>    appropriate SYSGEN parameters -- when the system rebooted, we ran out
>    of "stuff" by the time DECwindows was started.  We discovered that the
>    specific cause of the problem was that one of the X/DECw RTL's couldn't
>    be INSTALL'ed. 

& .2

>>  That was it.  He did an autogen over nite, and in the process, it
>>    significantly increased both gblpages and sections.  Now, all works
>>    well.  Thanks for the hint!

I had a similar problem when adding a new workstation to a cluster.

The automatic AUOTGEN did not create enough GBLPAGES or GBLPAGFIL's to run 
decwindows.  after logging in to the workstation, just the icon window would
come up.  all the other processes would die with the same mysterious 3AB8204
status.

again, bumping GBLPAGES and GBLPAGFIL solved the problem

						:-)
						Lou