Conference bulova::decw_jan-89_to_nov-90

The following three command files allow you to start applications on a
remote node without having to ``set host'' to it.  All that is
required is that you have proxy on that node. 

What I do is this:

  1) Get proxy on the node you wish to access from your workstation. Lets
     pretend the remote node is node FOOBAR:: and your workstation is node
     WHOPIE::

  2) Define the following in your login.com on node WHOPIE::

	$ rstart :== @sys$login:decw$start_remote.com

  3) Put decw$start_remote in your workstation's sys$login directory on
     WHOPIE::

-=-=-=-= cut here -=-=-=-=-=-
$! DECW$START_REMOTE.COM -- Start up a remote node's apps.
$!   Requires the existance of DECW$RST.COM in the
$!   root directory of the target node
$!
$! P1 = node where DECW$RST lives
$!
$ set noon
$ if p1 .nes. ""
$  then
$    type 'p1'::"0=decw$rst"
$    exit %x10000001
$  else
$    write sys$output "Remote node not specified"
$    exit %x10000002
$ endif
-=-=-=-= cut here -=-=-=-=-=-

  4) Put DECW$RST in your sys$login on node FOOBAR::

-=-=-=-= cut here -=-=-=-=-=-
$! DECW$RST.COM -- Start up applications to display on a remote workstation.
$!
$! NOTE: This file must be in the login directory.
$!
$	open/write net_file sys$net
$	close net_file
$!
$! Execute users decw$remote_login.com if there is a valid display.
$!
$	if "''f$trnlnm(""DECW$DISPLAY"")'" .eqs. "" then exit
$	if f$search("decw$user_defaults:decw$remote_login.com") .nes. "" then -
	@decw$user_defaults:decw$remote_login.com
$	exit
-=-=-=-= cut here -=-=-=-=-=-

  5) Create a file decw$user_defaults:decw$remote_login.com on node
     FOOBAR::.  Here is an example:

-=-=-=-= cut here -=-=-=-=-=-
$! DECW$REMOTE_LOGIN.COM -- Start up the tasks I care about...
$!
$	define/user/nolog sys$error nl:
$!
$! Now, Start up a decterm for this node
$!
$	this_node = f$trnlnm("SYS$NODE")
$	child -
	  /detach -
	  /nopass -
	  /ititle='this_node -
	  /title='this_node -
	  /x=125 -
	  /y=90 -
	  /image=sys$system:loginout.exe
$!
$! Thats all
$!
$	exit
-=-=-=-= cut here -=-=-=-=-=-

  6) Now, Finally!  Log into your workstation on WHOPIE::  Type:

	$ rstart foobar

     and BINGO you should eventually get a terminal on your screen.

  7) Check your netserver.log on FOOBAR:: if you have problems.  Put
     ``set verify'' commands in the above command files to help debug.

  8) Of course, you must have child.  Also, you must have decw$display
     set up on FOOBAR:: by your login.com.  Check you .0 for that.

    re .0

    The loop in your command procedure can take a long time on a node with
    a lot of WS devices (I know from experience, having used a similar
    procedure in the past). I replaced the loop in mine with the following,
    which *assumes* that "USER" will not be simultaneously accessing more
    than one workstation. You could use this as a jumping off point for a
    more robust implementation. No guarantees, aside from the fact that it
    works in my environment, and is *much* faster than a loop if you have
    tens of WSA devices around. (You could use the "found" temp file, and
    loop through it looking for the node you want, if you are concerned
    that "USER" might have windows on several workstations at the same
    time.)

$	USER = F$USER()
$	SHOW DEVICE /FULL WSA /OUTPUT=SYS$SCRATCH:WSA-DEVICES.TMP
$	SEARCH /WINDOW=(3,0) SYS$SCRATCH:WSA-DEVICES.TMP ",''USER']" -
	       /OUTPUT=SYS$SCRATCH:WSA-DEVICES-FOUND.TMP
$	TEMP = $STATUS
$	DELETE SYS$SCRATCH:WSA-DEVICES.TMP;*
$	IF TEMP .NE. 1 THEN GOTO create
$	OPEN FILE SYS$SCRATCH:WSA-DEVICES-FOUND.TMP /READ
$	READ FILE RECORD
$	CLOSE FILE
$	DEVICE = F$ELEMENT(1," ",RECORD)
$	DEFINE DECW$DISPLAY 'DEVICE'
$	DELETE WSA-DEVICES-FOUND.TMP;*
    

    Your DECW$REMOTE_START procedure also requires that the TASK object
    be defined on the remote node - many nodes have removed it.  However,
    if the TASK object is disabled by means of defining it with an
    invalid userid, then the method in .1 will work.
    
    			Steve

re: .3

If TASK exists and is disabled by means of defining it with an invalid userid
then it must be defined PROXY INCOMING or PROXY BOTH.  Otherwise the TASK
object ignores your account PROXY.

Also, in many NI or mixed clusters (where this would be useful) no proxy is set
up between <cluster-alias>::<user> and <user>.  This will also make this sort
of thing fail.

Dick

    Is there any way to get this stuff to work if the server (wstn)
    is in a hidden area node and the client is in a non-adjacent area?
    
    I may have misunderstood these notes so assume that you have to
    explain from the top.
    
    malcolm

Re: .2

Thanks. I imagine that the search utility WOULD be faster when you have
lots of WS devices.  On the other hand, if everyone uses this type
of procedures there would only be 1 WS device per workstation.  In the
case of our cluster that amounts to about 8 WS devices, and on the
average it searches through about 4.  I doesn't seem to take too long
under those conditons.  I may change to use SEARCH in the future.

RE: .3 and .4:  

All very true.  It so happens that our situation has things set up that
way.  All of these restrictions give more weight to my claim that the
set display command should know how to do this itself.

re: Note 1041.5 -< hidden areas ? >-

>     Is there any way to get this stuff to work if the server (wstn)
>     is in a hidden area node and the client is in a non-adjacent area?

Well.  My workstation is in a hidden area but the cluster I access is
ajacent.  I don't really know the answer... Anyone else?

>    .  On the other hand, if everyone uses this type
>    of procedures there would only be 1 WS device per workstation.  

    Yup, if you could enforce it. I just checked, and there are about 133
    WS devices on the node I'm currently logged into. The SEARCH is a
    requirement here.

    You've left out people (like me!) who use VWSLAT for outgoing LAT
    access to systems.  They want the display set up to go back to where
    they originated the connection just like is done for SET HOST.
    
    I find the following works:
    
    	decw_node = f$getdvi ("sys$command", "tt_accpornam")
    	decw_node = f$extract (0, f$locate ("::", decw_node), decw_node)
    	decw_node = f$extract (0, f$locate ("/",  decw_node), decw_node)
    
    At the end "decw_node" is either null or the originating node.

I have modified decw$set_display with the intention of using it to help
kick off decw$winmgr.exe plus some other application on a particular
workstation. I want the client and server processes both running on the 
workstation. To paraphrase, I would like to get things going on my 
workstation from a remote node (using the task object) without having to 
have someone log in locally at the workstation. I have not had much success!

Here is the command file I run on the workstation:-

$ set veri
$ set noon
$!
$ @decw$set_display
$ r/det/error=kickoff.error/proc=winmgr/priv=all sys$system:decw$winmgr
$ wait 00:00:10
$ r sys$system:decw$clock
$ exit

kickoff.error ends up containing:-

%NONAME-F-NOMSG, Message number 02DB821C

Can any one help me here? 

Cheers,
       Mike Collins

The modified DECW$SET_DISPLAY.COM follows....

$! DECW$SET_DISPLAY.COM -- This command file will set up the appropriate 
$! DECWindows environment for using a remote DECWindows server.  It first
$! makes sure that you have an appropriate remote node.  Then it makes sure
$! that the remote node is actually a DECWindows workstation.  Then it
$! attempts to use an existing WS device or will create new one for you. 
$!
$! Author: Robert Withrow, VINO::WITHROW
$!
$! First make sure we have an appropriate remote node...
$!
$! Modified to only work on local node...
$!
$	if f$trnlnm("DECW$DISPLAY") .nes. "" then exit
$	my_ws_node = f$trnlnm("sys$node")
$	if my_ws_node .eqs. "" then exit
$	if my_ws_node .eqs. f$trnlnm("sys$node") then my_ws_node = "0::"
$!
$! Now, make sure that 'my_ws_node' is a workstation, and that it will
$! allow us to talk to it...
$!
$	open/read/error=no_server my_server 'my_ws_node'"0=X$X0"
$	close my_server
$	goto setup_ws_device
$!
$ no_server:
$	exit
$!
$! Since there is no way to get a device list we must just parse
$! the output of $ show device.
$!
$ setup_ws_device:
$	my_uic = f$getjpi("","UIC")
$	show device/brief/out=sys$scratch:decw_device_list.tmp ws:
$	open/read device_list sys$scratch:decw_device_list.tmp
$	read device_list list_line
$	read device_list list_line
$	read device_list list_line
$ scan:
$	read/end=done_scan device_list list_line
$	a_ws_device = f$element(0,":",list_line) + ":"
$	if f$getdvi("''a_ws_device'","OWNUIC") .nes. my_uic then goto scan
$!
$! Now we need to check that it is on the proper node.
$!
$	define/user sys$output sys$scratch:decw_disp_list.tmp
$	show display 'a_ws_device'
$	open/read display_list sys$scratch:decw_disp_list.tmp
$	read display_list list_line
$	read display_list list_line
$	read display_list list_line
$	close display_list
$	delete/nolog sys$scratch:decw_disp_list.tmp;*
$	this_ws_node = f$edit(f$element(1,":",list_line) + "::","COLLAPSE")
$	if this_ws_node .nes. my_ws_node then goto scan
$	my_ws = a_ws_device
$ done_scan:
$	close device_list
$	delete/nolog sys$scratch:decw_device_list.tmp;*
$!
$! Now, if there is already a ws for us, we will use it.  Otherwise
$! we will create a new one!
$!
$	if my_ws_node .eqs. "0::" then protocol = "/transport=local"
$	if "''my_ws'" .eqs. "" Then goto create_ws
$!
$! /sys/exec so that the logical is seen by the detached winmgr process
$!
$	define/system/exec/nolog decw$display _'my_ws'
$	goto done
$ create_ws:
$	set display/create'protocol'/node='my_ws_node'
$	define/system/exec/nolog decw$display 'f$trnlnm("DECW$DISPLAY")
$	deassign/proc decw$display
$ done:
$	exit

> To paraphrase, I would like to get things going on my 
> workstation from a remote node (using the task object) without having to 
> have someone log in locally at the workstation. I have not had much success!

What you are trying to do is run things without running the session manager.
The server and WM and session mgr have some private communications that arent
being done the way you are running things, thus the message you are getting.
Do a dir/all/tit= and look for things about the session mgr, and also perhaps
a dir/all/tit=allowed to see how one may bypass the session mgr.

P.S. I dont think you need decw$set_display for this usage, since you know the
node and display already, you can do your own set/display and set/display/noperm
without all the worry that decw$set_display goes through.  Also, the changes
you made require privileges that most users don't have on the systems where
this command file is usefull.

    am I missing something??
    
    I set up decw$set_display.com as per .0
    
    I found I had to define sys$rem_node
    
    I want to try it local first so I added
        define sys$rem_node bonzod::
    	@sys$login:decw$set_display.com
    to my sys$login:login.com

        confirm :
    BONZOD> sho log sys$node
       "SYS$NODE" = "BONZOD::" (LNM$SYSTEM_TABLE)
    BONZOD> sho log sys$rem_node
       "SYS$REM_NODE" = "BONZOD::" (LNM$PROCESS_TABLE)
    BONZOD>
    
    I then do log out of decwindows and log back in
    and I don't get any terminals at decwindowns terminals
    
    If I call a decterm from the sesion manager and invoke @decw$set_display.
    nothing happens I assume thats because decterm gets decw$display defined.
    
    so I set host 0
    and get 
            This is node BONZOD, VMS V5.1
    
        Last interactive login on Wednesday, 12-JUL-1989 16:03
     DELETE USER4$:[JOHN]DECW_DISP_LIST.TMP;1 ? [N]: UL-1989 16:00
    DELETE USER4$:[JOHN]DECW_DEVICE_LIST.TMP;3 ? [N]:
    DELETE USER4$:[JOHN]DECW_DEVICE_LIST.TMP;2 ? [N]:
    DELETE USER4$:[JOHN]DECW_DEVICE_LIST.TMP;1 ? [N]:
    BONZOD>
    
    but no new window.  
    
    I am looking for a terminal window at login is this correct

Re: .11

I'm not sure if this is relevant, but there is a problem in DECterm V2:
decw$display has to be defined in WSAn: form, not node::x.y form.  Hopefully
this will be fixed in a later baselevel.

				-- Bob

Do you have

	$ DELETE :== DELETE/CONFIRM

in your LOGIN.COM?

..Dan

SYS$REM_NODE only gets defined if you have set host or started a network
job.  Simply put the @decw$set_display.com in your login and then
set host 0.  But I don't understand why you want this to run on your
workstation anyway??!?  The whole point of this procedure is to have
decw$display set correctly when you are running programs on something
other than your workstation, but displaying the windows on your workstation,
I.E. when you run programs on the ``big vax'' and want to display on your
``little vaxstation''.  This procedure goes to some effort to be sure that
it isn't doing something stupid in attempting to define decw$display.

P.S.: I should probably protect decw$set_display from people who redefine
commands such as delete...

P.P.S:
>     I am looking for a terminal window at login is this correct

Incorrect.  All the procedure does is correctly set decw$display.  If you want
a window you must run child or some other application!

Child is not set up on my system(s).  Where does it come from?

Thanks,
Eric

    Try dir/tit=child.

  Note 111.* is the primary discussion for CHILD.


					-=> Jim <=-

Thanks!  Should've known to look in this conference for it.

Now the problem is:  I don't think my proxy is set up right.  I'm trying the 
files listed in 1041.1, and I get

----------------
Error opening (remote node name)::"0=decw$rst" as input
ACP file access failed
Login information invalid at remote node
----------------

I do have proxy access to my directories and files there (in other words I can
read and write even protected files in 
(remote node name)::(my$disk):[westbrook...]*.*), but do I need more?

Thanks a million for any tips!

Eric

> Now the problem is:  I don't think my proxy is set up right.  I'm trying the 
> files listed in 1041.1, and I get

If, from your workstation, you can do:

$ type (remote node)::decw$rst.com

and see the contents of the file, then I think your proxys should be set
up OK.  Note that I have no disk id in there.  DECW$RST.COM must be in
the sys$login directory of the account who's proxys apply.