Conference bulova::decw_jan-89_to_nov-90

It'll work if you run LOGINOUT detached, with a procedure that first does a 
SET DISPLAY to your workstation, and then runs the DECwindows client.

Don't know why the SET DISPLAY is unnecessary when running locally.

-Lance-

        Anyone?

	Kevin

I think there is a trick involved: if you create a process with SYS$OUTPUT
set to a display name (e.g. WSAn:) then LOGINOUT will do a SET DISPLAY for you
in the created process; otherwise it won't.  This is how the CREATE/TERMINAL
command passes the display name to the DECterm controller, for example.

I'm not sure why locally created windows sometimes/always get this implicit
SET DISPLAY, though, because CREATE/TERMINAL sets their SYS$OUTPUT to
TWAn: (or FTAn: in the new version), not to WSAn:.  There must be some other
magic at work here.

				-- Bob

    Re: Bob,

    isn't it SYS$ERROR, not SYS$OUTPUT, that you set to the WSAn: device?

    Re: Kevin,

    try specifying /ERR=DECW$DISPLAY:
    I have a bliss program in which I specify the translation of DECW$DISPLAY
    as the SYS$ERROR parameter to a $CREPRC - and the created process always
    has DECW$DISPLAY defined.

    Paul.

Re: .4

>    isn't it SYS$ERROR, not SYS$OUTPUT, that you set to the WSAn: device?

No, I checked the code and it's setting SYS$OUTPUT to the display name (either
WSAn: or node::x.y) and SYS$ERROR to the name of the log file.  However, what
I've just noticed is that the newly created DECterm controller checks
DECW$DISPLAY and SYS$OUTPUT, and if DECW$DISPLAY is undefined it explicitly
sets it to the value of SYS$OUTPUT.  It does this so that the display name can
be passed in node::x.y form (although that ability is broken because of a
bug in a different part of the code).

In other words, DECterm isn't currently relying on LOGINOUT getting the
display name from SYS$OUTPUT, so you might be right that the display name
should be passed in SYS$ERROR.

				-- Bob

>>> setting SYS$OUTPUT to the display name
    
    Okay. This trick worked.

    $ RUN /OUT=DECW$DISPLAY: /PROC="Name" SYS$SYSTEM:DECW$PROGRAM 

    This creates the window program in a sub-process. (I could'a done 
    that with SPAWN/NOWAIT, right?

    However, if one adds /DETACH, it fails. Doesn't make sense to me.

    If I change /OUT=DECW$DISPLAY: to /OUT=WSAn:, or /OUT=WYRD::0.0, it
    does work with /DETACH. (Could it be the logical name decw$display
    is translated in the context of the created process?)

    Thanks for your help. I don't understand the problem, but there is a
    work-around, I guess.

    Kevin

Here's a problem I'm having that might fall into this note.  I have a DCL
command procedure which I'm trying to run in a create/term window.

$! FOO.COM
$LOOP:
$ inquire a "Enter something"
$ write sys$output a
$ goto LOOP

If I type the command interactively, CREATE/TERM @SYS$LOGIN:FOO.COM, it
works as expected by creating the terminal then asking for input in a loop.
If I define a new application command in the session manager using precisely
the same command string, then try to run it through the session manager, it
creates the terminal window, puts the prompt up and then immediately the
window vanishes.  What gives? How can I make this work through the session
manager?

-Mike

    RE: .6:
    Why adding /DETACH makes a difference is that RUN/PROCESS creates a
    subprocess; it shares your job logical name table, and DECW$DISPLAY is
    defined in the job table by LOGINOUT. A detached process does not share
    your job table. To create a detached job (which won't die when you log
    out..) use:
    $ RUN/INPUT=NL:/OUTPUT=NL:/ERROR=DECW$DISPLAY/PROCESS="Foo" decw$application
    Works for me.
    
    Re: .7:
    I've had success with defining the session manager menu to be
    "@command-file" with the file containing:
    $ create/terminal=decterm/resource=resource-file-
    	/window=(icon="App-name",title="App-name")-
    	/detach/input=another-command-file
    
    Where 'another-command-file' contains:
    $ define tt: sys$output
    $ define sys$command sys$output
    $ define sys$input sys$output
    $ application-command
    $ logout
    
    Much hacking until I got this to work; heaven only knows if all the
    logicals are needed. It works, so I stopped trying to understand it
    	-Rick

        RE .6

	If you don't use /WAIT or /DETACH, then when the process that executes
	the command terminates, the window is terminated with it.

	RE .7

	Yes it works. Thanks.

        

        ... except for the fact that it's an annoying subprocess. Annoying
	because I run out of subprocess quota if I start a couple of windows.

	Is there *any* way to RUN/DETACH a decwindows program??????

	Kevin

$ CRE RUN_whatever.COM
$ SET DISPLAY/CRE/NODE=yournode
$ RUN whatever.EXE
$ EXIT
^Z
$ RUN/DETACH/AUTH/INPUT=whatever.COM/OUT=whatever.LOG SYS$SYSTEM:LOGINOUT.EXE


					-mjg

        RE .11

	I was looking for a way to do it on the Run command. As in: why can't I 
	pass the window to a detached process as I can to a sub-process? After
	all, a window device is visible to the whole system.

        I mean, if I wanted to, I could start aDECTERM and enter
	RUN program for each program I want to start. But I was hoping for 
	something more succinct.

	Kevin

    re: .-1:
    Very odd; I just tried it and the following works:
    
    $ RUN /DETACH -
    	  /INPUT=NL:
    	  /OUTPUT='F$LOGICAL("DECW$DISPLAY") -
    	  /ERROR=NL: -
    	  /PROCESS="Clock" -
    	  SYS$SYSTEM:DECW$CLOCK
    
    I thought you passed the display device in SYS$ERROR; it appears that
    it belongs in SYS$OUTPUT..
    	-Rick

        Okay. Or /OUT=WYRD::0.0 works as well. (Better, because you can put it
	in a symbol.) 

	Sometimes this works, sometimes it doesn't. It works today. It worked
	last week, but I *swear* on other days it doesn't work.

	When I know why, I'll get back...

	Kevin

I use run/detach/authorize/output='lfile'/input='cfile'/proc="''pnam'"-
/err='f$logical("DECW$DISPLAY")' and that works too.  One thing you have
to be careful of is that the creating process stays around long enough
for the created process to start.  Otherwise you risk having the WSAn
device being gone.

Dick

Be careful if you're trying to run LOGINOUT.EXE. The /ERROR qualifier
is explicitly ignored.

Quoth HELP on the subject:


RUN

  Process

    /ERROR
     /ERROR=file-spec

     Defines an equivalence  name  string  for  the  logical  device  name
      SYS$ERROR.   The equivalence name can have from 1 to 63 alphanumeric
      characters.  The logical name and equivalence name are placed in the
      process logical name table for the created process.

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


RUN Process Subtopic?
 

I use it for LOGINOUT.EXE.  I suspect that the handling of /ERROR=WSAn: is
done as part of process creation.  Considering that LOGINOUT will ignore
the /ERROR, it makes it a great choice for passing display information.

Dick