Conference bulova::decw_jan-89_to_nov-90

The manuals are not really very clear on this.  There is some info. in
VMS Version 5.1 New Features.

On the remote node you must do:

$set display/create/perm/trans=decnet/node=<target>

in the process which will run the client before you run the client program.


There are several ways to start remote clients:
1) SET HOST in a DECterm and run the desired clients as detached or
   sub-processes of the interactive process.
2) Get 1 or more .COM files onto the remote machine which point back
   at the local machine and run the client.  Invoke these with SUBMIT/REMOTE
3) Get 1 or more .COM files onto the remote machine which point back
   at the local machine and run the client.  Invoke these with the DECNET
   TASK object.  (There are substantial security problems here so I would
   not recommend this approach for the naive).

My usual method is #2.  I have a .COM file on my workstation which
writes a new copy of a .COM file to invoke an application on the remote
host.  It then runs that new file with submit/remote.

Dick

===================================

$ if "''p1'" .eqs. ""
$ then
$	write sys$output "Remote what?"
$ endif
$ if "''p2'" .eqs. "" then p2 = "0"
$ if "''p3'" .eqs. "" then p3 = F$LOGICAL ("SYS$LOGIN") - "]"
$ open/read foo$bar 'p3'.remote]'p1'.com
$ count = 1
$read_loop:
$ read/end=end_loop foo$bar foo_line'count'
$ count = count + 1
$ goto read_loop
$end_loop:
$ close foo$bar
$ total = count
$ open/write foo$bar 'p2'::'p1'.com
$ node=f$logical("sys$node")-"_"-"_"-":"-":"
$ jname=f$extr(0,7,p1)
$ write foo$bar "$set proc/name=""''jname'=>''node'"""
$ write foo$bar "$set proc/priv=altpri"
$ write foo$bar "$set proc/prio=4"
$ write foo$bar "$set display/trans=decnet/create/perm/node=''node'"
$ count = 1
$write_loop:
$ write foo$bar foo_line'count'
$ count = count + 1
$ if count .ge. total then goto end_write_loop
$ goto write_loop
$end_write_loop:
$ write foo$bar "$pu 'f$environ(""procedure"")'"
$ write foo$bar "$pu 'f$parse("".log"",f$environ(""procedure""))'"
$ close foo$bar
$ submit/remote 'p2'::'p1'.com

Barry,

>	$ set display/create/node=client
>	$ run sys$system:vue$master
>
>   replacing "client" with the name of your client system.

Try replacing client with server in all of the above instances.  The client
node is the one where the application is running.  The server node is a
workstation where display and user interaction take place.  You have the
2 reversed.

You are right though to point out that on the server you must include
<client-node>::<your-account> amoung the permitted accesses or what I put
in won't work.

Dick

Re: 19.3 

>The client node is the one where the application is running.  The
>server node is a workstation where display and user interaction take
>place.  You have the 2 reversed. 

Dick,

Wow, that really turns things around! You're technically correct but I
find it much easier to think of the workstation as the client and the
"big" VAX as the compute server. That could be why the DECwindows
documentation seems to avoid the term "client/server." 

						Barry

Here's what we've been doing on the REORG cluster (an 8550 with 12
satellite VAXstations). Hope it helps.

First of all, read Chapter 8 of the DECwindows User's Guide (Running
Applications Across the Network).

1. On your workstation, choose the Security... menu item from the
   Session Manager's Customize menu and authorize bigvax::yourself.

2. On your big VAX system, SUBMIT/NOLOG the following command procedure:

	$ set display/create/node=workstation
	$ run sys$system:vue$master

   replacing "workstation" with the nodename of your workstation.

That starts up a FileView window that you can use to invoke all of the
other DECwindows applications in client/server mode. Although it is
running in the batch queue, the FileView process responds the same (at
least on our cluster) as if it were an interactive process. 

						Barry

    Since several COMmand files have been posted, thought I'd jump in with
    *my* version ;)  It basically accepts a nodename and a command string
    (and optionally a process name), and sets up a submit/remote command. 
    However, to free up the remote batch queue, it then does a run/det to
    begin running the *final* process.  The only bummer is that I can't
    tell the job controller that I DON'T want the log file printed to
    SYS$PRINT!  Ideas cheerfully accepted
    
    Regards,
    	 	== ken miller ==
    
$ ! remsub.com
$ ! created to get around using DECnet 0 tasks for
$ ! corporate security reasons!
$ ! executed on your workstation
$ ! modified 1/12/89 to optionally accept process_name and general cleanup
$ !	 	== ken miller ==
$ !
$ def_node = 	"GLIVET"
$ def_command =	"MCR DECW$MAIL"
$ if p1 .eqs. "" then inquire p1 "Remote Node? [''def_node'] "
$ if p1 .eqs. "" then p1 = def_node
$ if p2 .eqs. "" then inquire p2 "Application Command Line? [""''def_command'""] "
$ if p2 .eqs. "" then p2 = def_command
$ WS_node = f$getsyi("nodename")
$ if WS_node .eqs. p1 
$ then local_flag = "true"
$ else local_flag = "false"
$ endif
$ write sys$output "remsub:  Sending command to ''p1'..."
$ if local_flag .nes. "true" 
$ then 	open/write temp1 'p1::remote1_'WS_node'.com
$ else 	open/write temp1 sys$login:remote1_'WS_node'.com
$ endif
$ write temp1 "$ set verify"
$ if local_flag .nes. "true" 
$ then 
	write temp1 "$ set display/create/node=''WS_node'"
$ else
	write temp1 "$ set display/create/transport=local
$ endif
$ write temp1 "$ ''p2'"
$ write temp1 "$ del remote2_''WS_node'.com;*"
$ write temp1 "$ del remote1_''WS_node'.com;*"
$ write temp1 "$ exit"
$ close temp1
$ write sys$output "remsub:  Sending batch command file..."
$ if local_flag .nes. "true" 
$ then 
$	open/write temp2 'p1::remote2_'WS_node'.com
$ else 
$	open/write temp2 sys$login:remote2_'WS_node'.com
$ endif
$ write temp2 "$ set verify"
$ write temp2 "$ Host_Node = f$getsyi(""nodename"")"
$ write temp2 "$ proc_name = ""''p3'"""
$ write temp2 "$ if proc_name .nes. """" then goto start_run"
$ write temp2 "$ pid = f$getjpi(0, ""PID"")"
$ write temp2 "$ proc_name = ""''WS_node'"" + f$extract(f$length(""''p2'"")-6,6,""''p2'"") -"
$ write temp2 " + f$extract(f$length(pid)-3,3,pid)"
$ write temp2 "$ start_run:"
$ write temp2 "$ msg = f$fao(""Starting '!AS' on Node !AS"", proc_name, Host_Node)"
$ write temp2 "$ write sys$output msg"
$ write temp2 "$ run/detached sys$system:loginout.exe -"
$ write temp2 "  /input=remote1_''WS_node'.com -"
$ write temp2 "  /error=remote1_''WS_node'.log -"
$ write temp2 "  /output=remote1_''WS_node'.log -"
$ write temp2 "  /proc='f$fao(""""""!AS"""""", proc_name) -"
$ write temp2 "  /buffer_limit=30000/enqueue_limit=800/extent=10000 -"
$ write temp2 "  /io_buffered=100/io_direct=100/maximum_working_set=2048 -"
$ write temp2 "  /page_file=30000/authorize/file_limit=64/working_set=512
$ write temp2 "$ exit"
$ close temp2
$ write sys$output "remsub:  Submitting batch request on ''p1'..."
$ if local_flag .nes. "true" 
$ then submit/remote/nonotify/noprint 'p1::remote2_'WS_node'.com
$ else submit/notify/noprint/log=sys$scratch:remote2_'WS_node'.log -
	sys$login:remote2_'WS_node'.com
$ endif
$ EXIT:
$ write sys$output "remsub:  Process Completed!"
$ exit

	re .6: Ken, try putting $DEFINE SYS$PRINT NL: in the .COM file
	you're SUBMITting/REMOTE to prevent the log from printing (it
	gets put into SYS$LOGIN instead, too bad it doesn't respect
	SYS$SCRATCH).

	Mike

Re .4: you're right, it sure is confusing, and what's more, the backwardness
of it all is what forces the use of all these kludges.

Re .1: on approach #3, you can avoid the TASK security issues by defining
separate object entries for the .COM files in question, along these lines:

	Object = 0
	Name = APPL1
	File = SYS$mumble:APPL1.COM
	<other parameters as desired>

Then again, the problem with TASK is not that it's hard to secure, but that
it acts on security weenies the way a red flag acts on a bull.

	paul

>re .6: Ken, try putting $DEFINE SYS$PRINT NL: in the .COM file
>you're SUBMITting/REMOTE to prevent the log from printing (it
>gets put into SYS$LOGIN instead, too bad it doesn't respect
>SYS$SCRATCH).

Mike,
The COMmand file that I'm SUBMITting/REMOTE is my workstation; yet
it's printing from SYS$PRINT of the remote system.  The problem is,
though, the Job Controller already has his own SYS$PRINT defined
before my Login.com is invoked and that's where it goes (I'm 
guessing).  Cause I thought I tried putting it in my LOGIN.COM and
it didn't work.

I think the only way I can suppress it is to define a System logical
for SYS$PRINT which points to NL:.  And you know how *that* would
go over with the system manglers! ;)

Try avoiding the naked word "server" and think of "Compute Server" and "Display
Server".  Getting this habit should help when we start talking about "Font Servers"
"file servers", "name servers", "time servers", etc etc etc.

Burns

Most all of the command procedures that I've seen for getting remote 
applications started have all used a variation of the "SUBMIT" command.

This is really great if you don't have many users on the system but it really
starts clogging up the batch queues if everyone uses this technique.

A better solution, one which creates DETACHED processes instead is to 
do 

$ RUN/UIC=[username] sys$system:loginout.exe -
     /INPUT=INPUTFILENAME.COM
     /OUTPUT=OUTPUTFILENAME.LOG
     /ERROR=ERRORFILENAME.ERR

In inputfilename.com you place the commands you want executed. 

Also, be kind to your system manager and make sure that you do a 

$ SET DISPLAY/NOPERM WSAn: 

after you finish using the workstation pseudo-device. This allows the 
system to free up the device control structures.

James

    	This system manager (who also happens to have a GPX and 'windows)
    simply created another batch queue on the 'bigvax' nodes so we could
    all happily suck computes across the net and not clog the 42 other
    batch queues we have defined for other things...  slurp!
    
    							--Doug

re: .11
>Most all of the command procedures that I've seen for getting remote 
>applications started have all used a variation of the "SUBMIT" command.
>This is really great if you don't have many users on the system but it really
>starts clogging up the batch queues if everyone uses this technique.
>A better solution, one which creates DETACHED processes instead is to 
>do 

Check out .6 again...I'm doing run/det via submit/remote (best of 
both worlds;)

Regards,

               == ken miller ==

Thanks to Mike Ryan for helping me see the error in my ways regarding
SYS$PRINT.  The following is a *new* version of REMSUB.COM previously
posted in .6 which does not print the log file with every batch 
submission:

Features:
1. Uses submit/remote to keep the net police happy.
2. Run's /detatched to free up the batch queue slot.
3. Takes node-name, command, and optional process-name as
   parameters.
4. Runs from the workstation.

Regards,

                     == ken miller ==

$ ! remsub.com
$ ! created to get around using DECnet 0 tasks for
$ ! corporate security reasons!
$ ! executed on your workstation
$ ! modified 1/12/89 to optionally accept process_name and general cleanup
$ !	 	== ken miller ==
$ !
$ def_node = 	"GLIVET"
$ def_command =	"MCR DECW$MAIL"
$ if p1 .eqs. "" then inquire p1 "Remote Node? [''def_node'] "
$ if p1 .eqs. "" then p1 = def_node
$ if p2 .eqs. "" then inquire p2 "Application Command Line? [""''def_command'""] "
$ if p2 .eqs. "" then p2 = def_command
$ WS_node = f$getsyi("nodename")
$ if WS_node .eqs. p1 
$ then local_flag = "true"
$ else local_flag = "false"
$ endif
$ write sys$output "remsub:  Sending command to ''p1'..."
$ if local_flag .nes. "true" 
$ then 	open/write temp1 'p1::remote1_'WS_node'.com
$ else 	open/write temp1 sys$login:remote1_'WS_node'.com
$ endif
$ write temp1 "$ set verify"
$ if local_flag .nes. "true" 
$ then 
	write temp1 "$ set display/create/node=''WS_node'"
$ else
	write temp1 "$ set display/create/transport=local
$ endif
$ write temp1 "$ ''p2'"
$ write temp1 "$ del remote2_''WS_node'.com;*"
$ write temp1 "$ del remote1_''WS_node'.com;*"
$ write temp1 "$ exit"
$ close temp1
$ write sys$output "remsub:  Sending batch command file..."
$ if local_flag .nes. "true" 
$ then 
$	open/write temp2 'p1::remote2_'WS_node'.com
$ else 
$	open/write temp2 sys$login:remote2_'WS_node'.com
$ endif
$ write temp2 "$ define sys$print nl:"
$ write temp2 "$ set verify"
$ write temp2 "$ Host_Node = f$getsyi(""nodename"")"
$ write temp2 "$ proc_name = ""''p3'"""
$ write temp2 "$ if proc_name .nes. """" then goto start_run"
$ write temp2 "$ pid = f$getjpi(0, ""PID"")"
$ write temp2 "$ proc_name = ""''WS_node'"" + f$extract(f$length(""''p2'"")-6,6,""''p2'"") -"
$ write temp2 " + f$extract(f$length(pid)-3,3,pid)"
$ write temp2 "$ start_run:"
$ write temp2 "$ msg = f$fao(""Starting '!AS' on Node !AS"", proc_name, Host_Node)"
$ write temp2 "$ write sys$output msg"
$ write temp2 "$ run/detached sys$system:loginout.exe -"
$ write temp2 "  /input=remote1_''WS_node'.com -"
$ write temp2 "  /error=remote1_''WS_node'.log -"
$ write temp2 "  /output=remote1_''WS_node'.log -"
$ write temp2 "  /proc='f$fao(""""""!AS"""""", proc_name) -"
$ write temp2 "  /buffer_limit=30000/enqueue_limit=800/extent=10000 -"
$ write temp2 "  /io_buffered=100/io_direct=100/maximum_working_set=2048 -"
$ write temp2 "  /page_file=30000/authorize/file_limit=64/working_set=512
$ write temp2 "$ exit"
$ close temp2
$ write sys$output "remsub:  Submitting batch request on ''p1'..."
$ if local_flag .nes. "true" 
$ then submit/remote/nonotify/noprint 'p1::remote2_'WS_node'.com
$ else submit/notify/noprint/log=sys$scratch:remote2_'WS_node'.log -
	sys$login:remote2_'WS_node'.com
$ endif
$ EXIT:
$ write sys$output "remsub:  Process Completed!"
$ exit

This is all very well and makes for great flexibility.  I can use .-1
within my MIVc, using the 8820 as client and my GPX as server.

Now, for the twist,  for good reasons, our MIVc must stay on VMS 5.0-2D1
(i.e. BL11 of DECwindows).  I have access to another VMS system which is
running SDC 5.1.  Can I use the technique described previously, keeping
my BL11 GPX satellite as the server and running say the DECwindows bookreader 
on the remote VMS 5.1 client?  This would be great because it would mean that 
I could keep my workstation in our standardised environment yet still use its
features to access all those new format books.  Presumably all the control 
and data flow is X-protocol and thus mixed DECwindows versions should work.

I've tried it and I get the following error on the client ;

$SET DISPLAY/CREATE/TRANS=DECNET/NODE=BOOTME
$MCR DECW$BOOKREADER
X Toolkit Error: Can't Open display
%DWT-F-DWTABORT, xtoolkit fatal error

Of course I've set up the security correctly on the server, by adding
client-node::LOVELL and even *::LOVELL, all to no avail.  What is my problem?

Thanks for any help,
Chris.

    
    Check the sysgen param GBLPAGES against the current usage as given by
    Install, it could be that an Autogen with feedback is in order. I was
    bitten by this after upgrading to 5.2. 
    
    Hope this helps...........Marcus

    
    Remote execution of DECwindows applications is a great and I have used
    it now for some time.  Is someone working on an "approved" way of
    running these applications remotely?  How should we tell customers to
    implement this?  Will our VAXserver systems be configured with software
    which implements the approved method?  Is this the Remote Procedure
    Call arena?
    
    Jim
     

This has nothing to do with remote procedure calls.  There isn't any "approved
method."  Use what works.

--PSW

    
    About the remsub.com file in .6 (and again in a later note).
    
    Does this mean you must give remote_node::DECNET security access?
    
    If not, then who needs it?
    
    		$$$$ ted $$$$

>    Does this mean you must give remote_node::DECNET security access?
>    
>    If not, then who needs it?

No.  It will use proxy from the account at the workstation.  If it doesn't
have proxy access, it will probably fail.  That is because DECNET account
usually can not run the batch job.  As to security access for displaying on
the WS, you should allow access from the account to which you are proxied
on the client.

Dick
Clear as mud?

RE: .-1 - Am an on a Cluster.  I am sending the file remsub to an 8370 from
my uVAXII.  This shouldn't require proxy should it?  However, the .com file does
fail.  It doesn't produce a .log file and the 2 remote*_node.com files remain
in DECNET.

any ideas?

		$$$$ ted $$$$

The DECNET account is usually setup so that the only thing it can do is
network access.  It can not run a batch job.  Without proxy (or explicit
username and password) the job will be submitted under the DECNET account
and will not be able to get through LOGINOUT.

    re: .16
    
    > Check the sysgen param GBLPAGES against the current usage as given by
    > Install, it could be that an Autogen with feedback is in order. I was
    > bitten by this after upgrading to 5.2. 
    
    I'm running vms 5.1-t2 and decwindows bl13.  Getting a client to 'draw'
    on my workstation *used* to work.  Now it doesn't
    
    I found, looking through netserver.log, that the remote client tries to
    access network object <<< X$X0 >>> .. I don't have one on my
    workstation.  Where did it go?
    
    Only changes (that I can remember) I've made was to lock out the Task
    Object 0 [virus fixes] by forcing NCP to use a dummy account/password.
    Why would that cause the DECwindows server not to declare itself an ACP
    with object name: X$X0 ?
    
    I checked my Global Pages (with Install) -- I have over 4000 pages
    free.
    
    Any ideas? Thanks
    Keith
    

    
    If the network shutdown after the server was started, the object will
    disappear and will not reappear when the network comes back up.  Try
    restarting.
    
    						m

    >> Try restarting [decwindows]
    
    I did that -- no luck ...
    
    ----------------------------------------
    
    Bottom Line:	DECnet Started
    			DECwindows Started
    
    			===>  No X$X0 Task
    
    There are 6 workstations on this LAVC, and none of them have the X$X0
    object.  BUT a standalone workstation, which installed the *exact* same
    vms and decwindows (sdc 5.1) kits has the X$X0 object.
    
    I also re-enabled the Task-object and rebooted the entire cluster...All I
    got was the task object (and other regulars) -- but still no X$X0!
    
    I thought one of the major features of DECwindows was the ability to
    run applications across the network...I can't use this feature.
    
    I see that I am not the only one with this problem.
    
    There must be a simple answer --- Doesn't anyone from DECwindows
    developement have a clue?
    
    Thanks,
    <getting-very-excited> Keith

	Check your system startup and see what is starting before DECwindows.
	I had started some of the layered products before DECwindows, and I
	had the same problem. Try commenting out everything but STARTNET and
	DECW$STARTUP ?

				-- Stan

                     A happy ending to a long story.
                                    
    
    In looking for the logical translation of DECW$SERVER_TRANSPORTS
    (which was "DECNET" & "LOCAL") .. I found that I had defined a logical
    of DECNET to point to SYS$COMMON:[DECNET].
    
    This made the translation of DECW$SERVER_TRANSPORTS to be
    SYS$COMMON:[DECNET] -- Not Correct.
    
    I deassigned the DECNET logical and restarted DECwindows...! Hooray !
    the X$X0 object is back!!
    
    
          !!! Many thanks to Monty Brandenberg for his help !!!
    
    
    Keith

    We found the same problem but with the LOCAL transport. Customer
    had a logical name LOCAL defined which caused the iterative
    translation of DECW$SERVER_TRANSPORTS in InitKnownXport (via 
    env$get_string_list) to return the "final" translation, passed
    to DECW$XPORT_ATTACH_TRANSPORT, which then constructs and invalid
    shareable image name.
    
    Our final fix was to make the definition of DECW$SERVER_TRANSPORTS
    in DECW$STARTSERVER.COM a /TRANSLATION=TERMINAL definition.  This
    prevents TRNLNM from "completing" the translation...customer can
    keep his logical, DECwindows works just fine.
    

Would someone please QAR this problem?  We have to do something about these
namespace problems.

Thanks,

Burns

    Feel free to QAR it if you like, but the solution posted in .27 
    seems like the right thing to do. I've included that fix into a
    future version of the startup files.

    I am trying to run fileview on a client node and I am having a problem.
    Here is the situation. I have  a VaxStation which is on a LAVc. I'd
    like to run fileview on the bootnode. I have tried to follow several of
    the examples in this note. I created a .COM file on the boot node:
    
    $SET DISPLAY/CREATE/NODE=server
    $RUN SYS$SYSTEM:VUE$MASTER
    
    and ran it. I got an error that said the Client is not authorized to
    access server. In .2 it said:
        	
    
> You are right though to point out that on the server you must include
> <client-node>::<your-account> amoung the permitted accesses or what I put
> in won't work.
    
    
    I thought I was doing this right, but maybe not. I created a file:
    
    SYS$SPECIFIC:[SYSMGR]DECW$SERVER_ACCESS_ALLOWED.DAT
    
    and in it I put
    
    * client *
    * client::wagner *
    * CLIENT *
    * CLIENT::WAGNER *
    
    
    
    Is this correct? I've tried running the .COM file interactively, and
    also running it as a detached job. In both cases I get the "not
    authorized" error. 3 questions I guess:
    
    	1) Is the name of the file and it's location correct?
    
    	2) Does case matter in the file, i.e., does the client name have to 	
    	   be in upper-case, lower-case, or doesn't it matter?
    
    	3) If everything looks OK, then can someone tell me where else to
    	   look?
    
    
    Thanks, 
    
    		James.
    

If you have a Session Mgr. running on/to your server, you must use his
node access list which is modified via the CUSTOMIZE\SECURITY
Pulldown (don't forget to APPLY).  You can also hack out the list with
Xdefaults:

sm.host_list:       your_favorite_node::usernames_with_*
sm.num_hosts:     total_num_hosts

Regards,

           == ken miller ==

P.S.  The filename:
SYS$SPECIFIC:[SYSMGR]DECW$SERVER_ACCESS_ALLOWED.DAT


is correct, and I'm pretty sure it's case insensitive.

    Thanks alot. I've got it working now. 
    
    		James.

    Hello World,

    Several questions from Not-a-DECWindows-expert-yet.


    1. I really do love FILEVIEW. Especially when you start it on
       another node.
       But, I only want to start up 1 program on the other node, not a
       fileview AND a DECTerm.
       Is it possible to start a DECTerm from a fileview.
       (I have considered CHILD, but I don't want to use that one.)
       (And I don't like the 'DCL Command' in the utilities menu.)

    2. I want to start fileview on another node with the command
       submit/remote.
       This is the way I do it:

       I start a command file and give a few parameters:

       $submit/remote 'p1'"catsburg ''p2'"::ik:[decw]'p3'_fileview

       p1 = Cluster to run on.
       p2 = Password
       p3 = This node

       On the other system there is a command file called
       <node_name>_fileview.com
       This is the contents of that one:

       $set display-
       	/create-
       	/tran=decnet-
       	/node='f$extract(0,6,f$parse(f$envi("procedure"),,,"name"))'
       $run sys$system:vue$master
        

       And this is the log created:

       $       set nover
       X Toolkit Error: Can't Open display
       %DWT-F-DWTABORT, xtoolkit fatal error
         CATSBURG     job terminated at 25-JUL-1989 11:58:23.28
        

       First the obvious solutions (after doing a lot of DIR on this notesfile):

       - I've got 13000 gblpages free on the client system.

       - Object X$X0 is a known object on the server system.

       - The security on the server system says that *::catsburg can access
         this system.

       - These are the installed images which might have something to do with
         this.
        
          DECW$DWTLIBSHR;1 Open Hdr Shar          Lnkbl
          DECW$LOGINOUT;1  Open     Shar Prv      Lnkbl
          DECW$TRANSPORT_COMMON;1
                           Open Hdr Shar     Prot Lnkbl
          DECW$TRANSPORT_DECNET;1
                           Open Hdr Shar          Lnkbl
          DECW$TRANSPORT_LOCAL;1
                           Open Hdr Shar          Lnkbl


       What I wanted to ask the experts is this:

       		HEEEEEEEEEEEEEEELP    !!!


       Bert Catsburg
       ESSC CRS Group
       Nijmegem  Holland

    re:.33
    
    First, do not use passwords but use proxys for the SUBMIT/REMOTE.
    Make sure you allow access to your workstation from server::USER.
    Do a SUBMIT/REMOTE server::start_remote.com.  Start_remote.com starts 
    a detached process running fileview.  The batch job exits and frees
    up the batch queue leaving behind a detached fileview process.  The 
    /authorize switch is important otherwise the default process quotas
    rather than your authorized ones will be used.
    
    	/s/	Roger
    
    
$! file - start_remote.com
$! start all the remote stuff from one process
$ RUN /DETACHED -
	/input=DISK$USER1:[coulson]remote.com -
	/output=DISK$USER1:[coulson]remote.log -
	/error=DISK$USER1:[coulson]remote_error.log -
	/authorize -
	/process="server_fileview" -
	sys$system:loginout.exe
$ exit
    
$! file - remote.com
$!
$ set display /create /node=workstation::
$ @sys$manager:decw$startvue
$! startup fileview on remote node

>>    1. I really do love FILEVIEW. Especially when you start it on
>>       another node.
>>       But, I only want to start up 1 program on the other node, not a
>>       fileview AND a DECTerm.
>>       Is it possible to start a DECTerm from a fileview.
>>       (I have considered CHILD, but I don't want to use that one.)
>>       (And I don't like the 'DCL Command' in the utilities menu.)

Thanks for the encouragement. ;)

DECwindows V2 FileView has a "DECterm" verb in the "Application" menu
by default.  The "DECterm" verb creates a new DECterm using the new
DCL command CREATE/TERMINAL that is supplied with V2 of DECterm.

-steve-

    Re: .34

>   First, do not use passwords but use proxys for the SUBMIT/REMOTE.

    Why not?  Looking at .33 it seems that the password is entered from the
    terminal rather than stored in a file.  Is the password less secure in a
    SUBMIT/REMOTE command than, say, in a COPY command?
    
    I also use the SUBMIT/REMOTE method to start applications in a client.  I
    have to use passwords because I don't have a proxy on the client.
    
  - Marvin

    re .34

       They have told me that somewhere in the policies in VTX (don't ask me
       where) is the statement that no proxies are allowed to priviledged
       users.

       re: 'Use run/detach instead of batch'

         I also read .5, but for now I like a batch job more.

       re: @sys$manager:decw$startvue

         If you read this command file, it's the same as using MC VUE$MASTER.
         Any reason for using this command file ?

    re .35

       Sorry for that, I should have checked the release notes on V2 first.
       But as a manufacturing site we're waiting for the SDC kits of VMS V5.2
       and DECWindows V2


    BUT,

       Guys, thanks for the replies, but the question was

       I do a set display, then a run vue$master and as a result I get a
       xtoolkit fatal error and I checked everything I knew to check.
       (The comlete story can be read in .33)


    Bert Catsburg
    ESSC CRS Group
    Nijmegen  Holland

    Hello world,

    A few replies back I wrote a list of things I checked to solve the
    Xtoolkit Fatal error.
    Just for completeness, Check if the client knows the server and if the
    server knows the client in NCP. Seems a stupid one, but can take up an
    awfull lot of time to find.

    Many thanks to all of you and especially John Connolly who helped me
    with this problem.

    Bert Catsburg.

    Is there a reasonable way to create a decterm on a client system,
    for display on my server node? (VMS 5.1-1, DW V1)
    I have been able to get specific applications working in client/server
    manner, which should eliminate the security/decnet issues.
    I attempted to use the methos in the VMS 5.1-1 release notes.
    (there is a C program and command file in the release notes which
    is supposed to do exactly this. However when I attempt to execute
    it, I get an error, exit code 154 (I think) which would correspond
    to "invalid logical name".
    
    Any suggestinos?
    
    Kevin

        It sounds as if you didn't start the DECterm controller
        on the client node.  The DECterm controller process
        defines the logical that the C program was looking for
        when it got the "invalid logical name" error.
        
        This is discussed in more detail in the DECterm
        conference at HANNAH::DECW$DISK:[PUBLIC]DECTERM (add
        to your notebook with KP7 or SELECT).
        
        Dan

    re: .-2
    
    The release notes listed a command file to start a remote DECterm.  The
    command file first checked if the controller was running, and if it
    wasn't, then the command file would start the controller.  You should
    use the command file in the release notes as well as the CREATE_DECTERM
    program.
    
    Note that CHILD will do a lot of this, and more ... I decided to use
    CHILD until DECwindows V2 (and the new CREATE command for DECterms).
    
    	-- Jeff

    Actually, I was using the COM file out of the release notes.
    Upon further reading in the DECTerm notesfile, I found that my
    problem was solved by recompiling CREATE_DECTERM with /NOOPT.
                                 
    It now works just fine.
    
    Thanks,
    Kevin