From: CAFFEEC@leia.polaroid.com ("Cameron Caffee : W300F-2 : 222-6278")
Newsgroups: comp.os.vms
Subject: Re: Q: DECTerm Startup
Date: 9 Oct 92 19:36:00 GMT
Distribution: world
Organization: The Internet

John McCarthy writes :

>In order to make life simpler, I would like to minimize the nnumber of manual 
>interventions (read keystrokes) required to bring up the various applications 
>that I use all the time.

>Briefly, I end up having to have 3-4 DECTerms up, with each one then running the 
>real application (e.g. DECDesign, TELNET, etc.). Bringing up the DECTerms is no 
>problem, but I would like to then have each one execute a command (optimally a 
>.COM file), that would issue the DCL commands that are needed.

>Does anyone have a way to do this that he/she would be willing to share, or 
>should I just become a better typist ? :-)


I see a couple of considerations that need to be defined :

(1) are the applications you wish to run on your local node or on a remote
    node ?

(2) do you wish to auto-start the applications at DECwindows login time or
    as needed but without the keystrokes required to start the application
    ?


Here are a few techniques that you should be able to mix and match to get
the desired result :

Basic DECterm on local node with application :

$ set display/create/user_mode/screen=n		! for two head station 0/1
$!							else omit
$ create/terminal -
	/window_attributes=(icon_name="whatever",-
			     title="whatever") -
	set host/lat whatever			! any DCL command

The basic code above can be made a Fileview or Session manager pull-down
entry to avoid all keystrokes save that of a mouse click.


Running applications remotely requires a few more pieces of the puzzle to
be in place but is none the less possible :

- on the local node, Session Manager security must be set-up to accept a
broadcast window from the node/user of your choice.

- on the remote node, the task object must be available in order to run the
procedure described below in a task-to-task fashion :

$ spawn/notify/nowait/out=nl: type remote_node::"0=remote_dcl"

- on the remote node in the default directory of the user account to run
the application (this account is proxy'd to the user's remote
node::account) a DCL procedure to create the remote display and run the
application :

$!
$!	Create remote application
$!
$ remote_node = f$trnlnm("SYS$REM_NODE","LNM$JOB")	! remote node
$ nodename    = f$getsyi("nodename")                    ! local node
$ msg := write sys$output
$ if remote_node .eqs. "" then goto local_init
$ goto do_term
$local_init:
$ if p1 .eqs. ""
$ then
$	msg "Remote node name (p1) missing ..."
$	goto theend
$ endif
$ remote_node = p1 + "::"
$do_term:
$ set display/create/user_mode/node='remote_node'/screen=0	! 0/1 
$!
$!	The DCL that follows runs ANY DECwindows application
$!
$!+
$!+ 	This creates a DECterm broadcast into to originating node
$!+
$ create/terminal -
	/detach -
	/window_attributes=(icon_name="''nodename'",-
			    title="''nodename'")
$theend:
$ exit

{or}

$!+
$!+ 	This creates a DECterm running a std application
$!+
$ create/terminal -
	/window_attributes=(icon_name="''nodename'",-
			    title="''nodename'") -
	monitor process/topcpu
$theend:
$ exit


{or}

$!+
$!+ 	This runs a DECwindows application
$!+
$ run sys$system:decw$bookreader.exe
$theend:
$ exit


The net effect of the remote appraoch is to have the remote node doing the
work of the application (DECterm, Bookreader, etc.) and your workstation
providing only the necessary window server functions.


For applications to be run locally, you have two choices :

	(1) add them to the Session Manager autostart list once they are
		defined as menu verbs.
	(2) initiate them during DECwindows login processing.


Initiating applications during DECwindows login processing for things that
aren't available as Session manager/Fileview verbs is possible but one must
work a bit harder if one is to run them as detached processes like DEC
recommends. Here's an example I use to get an editor running "the way I
want it" (yes, I am familiar with the TPU$SECTION logical - this is how I
like it !) :

in SYS$LOGIN:DECW$LOGIN.COM :

$ user  = f$getjpi("","username")
$ u_prv = f$setprv("all,nobypass")
$ run	/detached -
	/process_name="eve$''user'" -
	/privileges=(TMPMBX,NETMBX) -
	/error=nl: -				! some app's need a real
	/output=nl: -                           !   file here
	/input=eve_dw.com -
	sys$system:loginout.exe
$ n_prv = f$setprv(u_prv)

SYS$LOGIN:EVE_DW.COM :

$ user = f$edit(f$getjpi("","username"),"trim")
$ set display/create/user_mode
$ define sys$scratch 	sys$disk:['user']
$ define sys$login 	sys$disk:['user']
$ edit/tpu/display=decwindows/command=sys$login:eveini.tpu 


This technique can be used to create a detached process with most any DCL
procedure to invoke the application at login as long as you remember that 
detached processes don't do some of the things an interactive process will
do at creation (define logical sys$login, run sys$login:login.com, etc.)
and provide appropirate code to handle this fact. A much simpler approach
would be to spawn the desired procedure but then one loses the advantages 
of the detached process.


Enjoy !

Cameron

+-------------------------------------------------------------------------+
| Cameron Caffee, System Manager                     Polaroid Corporation |
+---------------------------------------------------------+---------------+
| Internet : caffeec@mr.polaroid.com                      | Snail Mail :  |
| MCI Mail : EMS:Internet                                 +---------------+
|            MBX:caffeec@mr.polaroid.com                  | 300 Fifth Ave |
| FAX      : (617) 684-3057                               | Waltham, MA   |
| Voice    : (617) 684-6278                               |        02254  |
+---------------------------------------------------------+-------------- +