From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
Subject: Re: DCL Help: Starting a remote DCL file & knowing when it's do
Date: Fri,  6 Nov 92 09:11:46 PDT
Organization: The Portal System (TM)

Dave DesRoches (a725911@bugs.mc.ti.com) writes:

>I have a central system (running VMS 5.5) which needs to start up a DCL file 
>on a remote system - and then "know" when that .com file has completed.  I'd
>like to do it all in DCL if possible - I'll be turning over responsibility 
>for this to a user-group, and an "English program" is preferable to them...
>though the "English" may look obscure with VMS system calls in it.

Depends what you mean by having the local system "know" when the remote job
has finished, which partly also depends on what the local system can, or 
wants to, be doing while the remote job is running.

I have one pair of DCL procedures -- a local "client" and remote "server" --
that use DECnet task-to-task communication to let me type DCL commands on
the local terminal, and have them executed on the remote host system.  In
that environment, my local procedure "knows when the remote (command) is
finished" by continuing to read responses from the remote process until
the remote process sends a special end-of-command-output tag.  The remote
process, of course, doesn't have to do anything special to know when to
send that tag: it issues the command I send it, and sends the tag as its
next act.  Any output generated by the command itself, naturally falls 
comes to me before the end-tag.   I hope this makes sense...

Another thing I've done on occasions when I don't want to tie up my terminal
waiting for the remote job to finish, is to have the remote job send me a 
MAIL message -- via DECnet if need be; the same technique applies equally
well from a batch job on my local system.  If I'm logged in when completion
occurs, and have broadcasts enabled etc., I am immediately notified that a
message has arrived, and can even have the remote process set up a personal_
name that appears on my screen at message-receipt time.  If I'm NOT logged
in, of course, the message is there waiting for me when I DO log in.

Those are the two DCL techniques I use to "know when a remote process com-
pletes."  If you actually "want something to happen" on the local system,
in a hands-off, no-human-intervention manner, when the remote job completes,
you have a couple of alternatives:

Launch the original remote job from a batch job on the local system that
hangs around waiting for completion in the task-to-task communication sense
of the first method described above.  The batch job can then do whatever
post-processing is required on the local side, when informed that the
remote process has completed.

Alternatively, have the remote job start up another DECnet task back on the
LOCAL host, to do whatever you want done locally, just BEFORE the remote
job exits.  To recap, that's a local job starting a remote DECnet task which
then starts a local task (which is "remote" from the perspective of the 
original remote task).  Got that?  :-)

There are other methods of internode communication, but these are the only
ones I can think of that can be done entirely in DCL.  Oh, you can of course
create and manipulate FILES across DECnet, if that floats your boat...

Chris Chiesa
  Chris_F_Chiesa@cup.portal.com