Conference bulova::decw_jan-89_to_nov-90

    What do you mean, "startup"?
    System startup, or session startup?
    
    Once upon a time, DECW$DISPLAY was defined as a system-wide logical
    name.  Now it appears in the job table for a "DECwindows process".
    This means, for example, that FileView applications will get
    a suitable name definition, that subprocesses of the session manager
    will get one also, and that detached processes started by DECterm
    get a definition as well.  
    
    If you're running batch jobs or background processes which execute
    DECwindows applications, then you probably need to manually cause
    DECW$DISPLAY to be defined appropriately.

    Well, both I guess.  If I reboot and don't log in locally, but rather
    from a remote terminal, it's not defined.  After I log in locally
    and start DECterms, it is not there when examined from the DECterms
    either.  When attempting to run DECwrite from a DECterm window,
    using the command (as suggested in the docs) "RUN SYS$SYSTEM:WRITER",
    it won't start - fails with an "X toolkit error" or some such. 
    Defining DECW$DISPLAY from the DECterm solves the problem on the
    subsequent execution attempt.
        
    Gary

DECW$DISPLAY will never be automatically defined for login from a remote 
terminal,  because of the way it works (as described earlier).   You
need to manually define it.

I don't understand why it isn't turning up in the job tables for
for DECterm logins, though.  It's supposed to!

re: .2

When you say it is not there for decterms, do you mean:

Session manager -pulldown Create Terminal Window
Wait for login to complete
show log decw$display

or are you doing something like the following?

Session manager -pulldown Create Terminal Window
Wait for login to complete
set host to someplace else
show log decw$display

The former case will work the latter will not.  It will also not
show up automagically in a detached process (logical names are not
inherited from creator).  It should be defined in subprocesses of
the session manager, file view and terminal emulator logins.

Dick

	What the heck I'll ask here...

	I have the same problem when I create DECterms using CHILD. It appears
	that CHILD does not propigate (sic) the DECW$DISPLAY logical to the
	new process (or maybe I'm doing something wrong in the child command)

	BUT, it is similar to what the author of .0 is describing...

		Jan



	$ CHILD                                         -
            /detach/image=sys$system:loginout/nopass    -
            /pause=3    /insert     /page='p5'          -
            /ix='p1'    /iy='p2'    /x='p3'     /y='p4' -
            /process="''p6'"                            -
            /title="Term''p5'"      /ititle="Term''p5'" -
            /setup=sys$login:decw$terminal_default.dat

    Sorry, I've been away.
    
    Yes, I am using Child to create the DECterms at startup.
    
    I suppose that setting DECW$DISPLAY in SYLOGIN would be the easy
    answer.  Yes?  No?
    
    Thanks...Gary

    What I do is in my DECW$LOGIN.COM to define DECW$DISPLAY /GROUP.
    Works for me...
    
    				Steve

If somebody could tell me an easy way to convince CHILD to get
DECW$DISPLAY defined properly in the created detached processes, I
would be glad to do it.

    
    The way decw$display gets propogated to the DECterm processes by the
    session manager is as follows:
    	1. Session manager gets the current value of DECW$DISPLAY.  This
    should be a WSA workstation device which specifies a node, server,
    screen.
    	2. The session manager does a CREPRC with sys$error - WSA#
    	3. Loginout checks for sys$error device type a workstation and
    	   defines a job logical name decw$display = WSA#.
    
    So, try changing the call to create the DECterm process to have
    sys$error pointing to the current definition of decw$display.
    
    

Thank's.

(That's so obvious I should have been able to figure it out for myself.)

Ummmm.... How do I get my hardcopy error log for the created process then?

James

    
    
    Yes, that is a problem.  Unfortunately, there are a limited number of
    ways to get information to the new process through CREPRC.  Loginout
    will set sys$error = sys$output after it defined decw$display for the
    new process.
    

LOGINOUT.EXE never used SYS$ERROR for SYS$ERROR.  LIB$SPAWN hooks
SYS$ERROR to a mailbox that it uses to send symbols and logicals to
LOGINOUT.  LOGINOUT reads SYS$ERROR to get this information, presumably
if the device type is right.

Personally, I find this method to be a little questionable - although it
would be a lot less questionable if it were better documented.

(Oh, and yes, I was being sarcastic in .10.)

Well, I'll accept that there's no way to communicate between a detached job
and the creator, but why does DCL prevent you from using the mechanims that 
has been hacked to do this? Doing a 

$ run/uic='f$getjpi("","UIC") sys$system:loginout.exe -
	/input=<input_command_file>
	/output=<output_log_file>
	/error=_WSAn:

results in no effect since (from Help): 

     "Note that the  /ERROR  qualifier  is  ignored  if  you  are  running
      SYS$SYSTEM:LOGINOUT."

Would it be too much to ask for a supported mechanism? Oh well, I guess it's 
off to write a program...

James