Conference bulova::decw_jan-89_to_nov-90

    Re:.0
    
>    Wouldn't it be better to run them as detached processes? Is there a
>    reason not to? Is there any trick (I bet there is!) to doing this?
    
    Absolutely.  Quota sharing is a problem not a benefit (unless you're
    being generous with job quotas).  The trick is communicating the
    desired display to the detached process.
    
    					monty

RE:.0

For the most part detaching them, submitting them (local or remote) or
using the TASK object (if available) is preferable.  This cuts down process
resource squabbling and can spread stuff out on several machines.  However,
some programs (ie: DECwindows banner) need a terminal for some features.
Therefore, it should be spawned instead of detached.

Dick

-<Don't submit them, cluster manager will get  p***ed about their batch queues>-

Detached processes are much more friendly than a "submitted" batch hog.
Unless your cluster manager is more friendly that the ones I know, detaching
the process is much preferable.

Task access is also a good mechanism, execept you have to be careful that 
you don't wind up creating new WSAn devices everytime you start an application.
And one other thing on task access. The only BAD task access is DEFAULT task
access. Proxy access to task is just as secure as proxy access to your own files
and SET HOST.

James

    What is the negative system impact of running DECwindows applications
    as batch jobs?
    
    fjp

The problem is that the processes occupy execution queue slots for extended
periods of time.  If your system manager has set things up such that this is
not a problem, that's fine.  Most systems are set up expecting that batch
queues will be doing real, compute-intensive batch work, not merely being
convenient ways to run remote DECwindows applicaitons.

--PSW

    I didn't think there was anything intrinsicly wrong with batch
    execution.
    
    We have a PRIORITY 4 DECW$BATCH queue with three slots.  It seems
    to work OK.  We don't have any node big enough to really test the
    concept though.  Hoping for a 3000 series boot node in the future
    and have been prototyping the concept to support DECwindows terminals
    (low memory VS 2000's) It seems like making DECW$BATCH a generic
    queue will be a good way to distribute task among a few machines.
    
    Running on a priority 3 queue is painful when ALL-IN-1's DDS fires
    up.
                                                                     
    We are looking at command procedures which just create detached
    jobs on the node they run on and direct the display to the node that
    submitted them.  Haven't tested much, and it seems harder to control
    the number executing on each machine.
    
    -fjp

    re .0
    
    Subprocesses automatically get cleaned up when their parent dies -
    so when you QUIT the session, all of those applications go away
    as well.  Last time I tried, a detached process stayed running
    after the session ended, which wasn't what I wanted at all.
    
    -
    
    The difference between DECW$SYLOGIN.COM and DECW$LOGIN.COM is the
    same as the difference between SYLOGIN.COM and LOGIN.COM -- namely,
    the former contains stuff which the system manager believes should
    be executed for all users, and the latter contains stuff that the
    user decides for himself to execute.  DECW$SYLOGIN.COM belongs to the
    system manager, DECW$LOGIN.COM belongs to the user.  Both of 'em
    are executed at session startup, in the expected order.

    --> .1
      > The trick is communicating the desired display to the 
      >	detached process.
    
    So how do you do that?
    
    --> .3
    > Task access is also a good mechanism 

    So how do you do that? And it this relevant when server and client are
    running onthe same node?



    --> .7
      > Subprocesses automatically get cleaned up when their parent dies -
      >	so when you QUIT the session, all of those applications go away
      >	as well.  Last time I tried, a detached process stayed running
      >	after the session ended, which wasn't what I wanted at all.
    
    Now this seems like a serious objection to what everyone seems to agree
    is a preferable mechanism. Any comments on how to cause detached
    processes to clean themselves up when the session is QUIT?
        
      >	... DECW$SYLOGIN.COM belongs to the
      >	system manager, DECW$LOGIN.COM belongs to the user.  Both of 'em
      >	are executed at session startup, in the expected order.
    
    Both of them are executed in the context of the session manager's 
    process? So if there is only one session menager process, there is no
    difference?
    
    Or is DECW$LOGIN executed by every DECterm process that is created?
    
    And when/how is it ever the case that more than one session manager
    process would be running?
    
    ... Thanks for your patience with this novice ...
    

re .8

>      > The trick is communicating the desired display to the 
>      > detached process.
>    
>    So how do you do that?

What my approaches usually do is create a .COM file on the remote node
to be executed.  Part of the .COM file is SET DISPLAY to the node from
which I am writing the .COM file.

$WRITE COM$OUT "SET DISPL/PERM/CREAT/TRANS=DECNET/NODE=''F$LOGICAL("SYS$NODE")'"

>    --> .3
>    > Task access is also a good mechanism 
>
>    So how do you do that? And it this relevant when server and client are
>    running onthe same node?

$OPEN/READ/WRITE TASK$PROC REMOTE::"TASK=filename"

>    --> .7
>      > Subprocesses automatically get cleaned up when their parent dies -
>      >	so when you QUIT the session, all of those applications go away
>      >	as well.  Last time I tried, a detached process stayed running
>      >	after the session ended, which wasn't what I wanted at all.
>    
>    Now this seems like a serious objection to what everyone seems to agree
>    is a preferable mechanism. Any comments on how to cause detached
>    processes to clean themselves up when the session is QUIT?

This is out of date.  The Session Manager in SDC 5.1 kills off all client
connections on session quit.

>    Both of them are executed in the context of the session manager's 
>    process? So if there is only one session menager process, there is no
>    difference?
 
Yes.  No.  DECW$SYLOGIN.COM contains the setups that are common to all
accounts which might run session manager clients on this host.  DECW$LOGIN.COM
is specific for each account.  DECW$SYLOGIN.COM contains stuff the system
manager thinks should be done for everyone.
   
>    Or is DECW$LOGIN executed by every DECterm process that is created?

DECW$LOGIN and DECW$SYLOGIN are not executed for DECterm processes.  The
LOGIN.COM and SYLOGIN.COM are executed for each of the DECterm processes.
The DECterm controller process does not execute any of these.
   
>    And when/how is it ever the case that more than one session manager
>    process would be running?

If you go through some gyrations, you can run a session manager on a compute
engine (client) displaying on some other workstation (server).  Potentially,
several different users could be running session managers on the compute
engine displaying on their respective workstations.  (I am not sure whether
this will really work today but it could in theory).
    
>    ... Thanks for your patience with this novice ...

No problem.  The only stupid question is the one left unasked.

Dick
    

	For those using other remote batch queues besides SYS$BATCH, how
are you getting your command procedures submitted to that queue?  SUBMIT/REMOTE
does not accept a /QUEUE qualifier.

Kevin

    ultrix> cat vue_node
    $SUBMIT/QUEUE=DECW$BATCH VUE$$ultrix
    $EXIT
    ultrix> dcp -S vue_node node/user//::
    
    <<<<< USER$DISK:[PRUSS]VUE$$ULTRIX.COM >>>>>
    
    $ SET DISPLAY/CREATE/NODE=ULTRIX
    $ @SYS$MANAGER:DECW$STARTVUE
    $ SET DISPLAY/NOPERM
    $ EXIT              
                           
    The names have been changed to protect the innocent.
    
    -fjp

    But note 19.14 is about the last word on the subject.
    
    -fjp

re 54.8

	>Both of them are executed in the context of the session
	>manager's process?  So if there is only one session manager
	>process, there is no difference?

	Not so, in general.  In most cases there will only be one
	session manager process, and there's only one user of the 
	workstation display at one time anyway, but it doesn't
	follow that it's always the same user who's using it.

	Stuff such as application startup (e.g. when I log in I 
	want to run calendar, notes, and the cardfiler) is probably
	the decision of each individual user, and therefore properly
	belongs in SYS$LOGIN:DECW$LOGIN.COM.