topic Re: background process in Operating System - OpenVMS

background process

gurram — Mon, 10 Dec 2007 21:52:35 GMT

the script should not exit until all the background process are complete

could you please provide the solution

Re: background process

Hoff — Mon, 10 Dec 2007 22:14:48 GMT

Which operating system and which version? The OpenVMS operating system (the subject of this HP ITRC forum) offers subprocesses and detached processes, and batch processes, mechanisms which are analogous to Unix-style detached processes -- but are not called that.

OpenVMS also offers DCL command procedures, which are analogous to what Unix calls scripts -- but are not called that.

Assuming there are just some differences in the terminology here and that this question is about OpenVMS...

The two ways are to poll for the processes using f$getjpi and DCL loops and such, and commands such as SYNCHRONIZE, or to implement a mechanism using the distributed lock manager (DLM) to coordinate the various processes. Or batch.

It's also quite common to see scheduling packages used to control these sorts of activities. There are several of these packages around, both free and commercial.

And batch jobs and batch queues can also be used to control execution. Commands here include f$getqui and such.

Assuming this is OpenVMS, which OpenVMS platform and which OpenVMS version is in use here, and do you have access to make modifications to the background processes and the procedure. Some background on your particular situation would be helpful, in other words.

If this is a Unix shell of some sort, see if whichever shell here you're working with has the jobs command. (This tends to be tied in with the fg and bg commands and related.) And FWIW, the book _UNIX for the Impatient_ is a good resource for these sorts of shell situations. (I have the first edition, but there's a second edition available now.) There is a Unix forum (HP-UX) around here, too.

Stephen Hoffman
HoffmanLabs LLC

Re: background process

Wim Van den Wyngaert — Tue, 11 Dec 2007 12:37:28 GMT

You mean something like this ?
>ty wim.txt
$ spa/nowait wait 00:00:05
$ spa/nowait wait 00:00:08
$redo:
$ pc=f$getjpi(0,"prccnt")
$ if pc .gt. 0
$ then
$ write sys$output "Waiting for ''pc' processes to complete
$ wait 00:00:01
$ goto redo
$ endif

>@wim.txt
%DCL-S-SPAWNED, process SYSMGR_WVW_2 spawned
%DCL-S-SPAWNED, process SYSMGR_WVW_3 spawned
Waiting for 2 processes to complete
Waiting for 2 processes to complete
Waiting for 2 processes to complete
Waiting for 2 processes to complete
Waiting for 2 processes to complete
Waiting for 1 processes to complete
Waiting for 1 processes to complete
Waiting for 1 processes to complete

Wim

Re: background process

Richard W Hunt — Tue, 11 Dec 2007 16:26:05 GMT

Another approach that even works for clusters - but requires some considerable privileges - is to pre-define some name for a cluster-wide logical that changes from "RUNNING" to "DONE" and then have the waiting process check those logical names every so often.

Another approach that works for clusters if you have services set up right is to capture the PID of the process on which you are waiting and perform F$GETJPI calls on it to get a status. Trap errors when you do. Like, ON ERROR THEN CONTINUE. Then look for it to return something. As long as F$GETJPI can see that process, you can look up something (anything) about the process. When it is no longer running, you will get back an empty string for the process in question. I might use "STATE" as the JPI attribute I query if I were doing it. Again, just write a little loop to test the F$GETJPI probe and exit the loop when your process - or processes - are done.

Re: background process

Jan van den Ende — Tue, 11 Dec 2007 17:25:52 GMT

gurram,

some good suggestions so far,

Another way that works quite well:

$ SUBMIT
$ SYNCHRONISE '$entry

If you want to do something else in the meantime:

$ SUBMIT
$ somename = $entry

... now do whatever.

$ SYNCHRONISE 'somename

hth

Proost.

Have one on me.

jpe

Re: background process

John Gillings — Tue, 11 Dec 2007 21:31:32 GMT

>Another way that works quite well:
>
>$ SUBMIT
>$ SYNCHRONISE '$entry

Syntax error:

$ submit/hold login.com
Job LOGIN (queue SYS$BATCH, entry 621) holding
$ synchronize '$entry'
%JBC-E-NOSUCHJOB, no such job

The parameter for SYNCHRONIZE is the job NAME. To use the entry number (much better, since the job name is not guaranteed unique), use /ENTRY

$ SYNCHRONIZE/ENTRY='$ENTRY'

SYNCHRONIZE is a very useful command, and frequently overlooked.

A few other useful things to know, the $STATUS after a $ SYNC command is the completion status of the job (except, of course for the errors like JBC-E-NOSUCHENT)

You can $SYNC against a RETAINED job. The $SYNC will return immediately, with $STATUS of that job.

So, if you're not going to $SYNC immediately it's safer to do it like this:

$ SUBMIT/RETAIN=ALWAYS
$ myentry=$STATUS

...

$ SYNCHRONIZE/ENTRY='myentry'
$ mystat=$STATUS
$ DELETE/ENTRY='myentry'

Re: background process

Jan van den Ende — Wed, 12 Dec 2007 15:33:50 GMT

@John:

>>>
>Another way that works quite well:
>
>$ SUBMIT
>$ SYNCHRONISE '$entry

Syntax error:
<<<

Well, mostly you are right.
If SYNCHRONISing on the entry number, I should have used the /ENTRY=.. qualifier.
(that's what comes from answering from bio memory).

But, it is _NOT_ a syntax error.

And I _COULD_ even make it work, by SUBMIT/HOLD xxx
$ SET ENTRY '$entry' /NAME='$entry'
$ SET ENTRY '$entry'/RELEASE

Admittedly, crafted to make it work, but, _NOT_ a syntax error.

fwiw

Proost.

Have one on me.

jpe

Re: background process

Jan van den Ende — Wed, 12 Dec 2007 15:35:39 GMT

Addendum:

Probably that should have been quoted:
... /NAME"''$entry'"

Proost.

Have one on me.

jpe