DCL - Does a process with this PID exist?

[Jim Geier_1]

Thanks for the good discussion and very good answers -- PIPE is not a natural for me yet, so I seldom consider it first. And I always appreciate some Macro code.

I know how to do this and now I know some better methods. Obviously, others have encountered and considered this problem. And, as is characteristic of OpenVMS and DCL, there are many solutions to a problem. In spite of the many reasonable methods discussed here, I still believe the omission of f$getjpi(pid,"exists") is glaring, especially in the presence of f$getdvi(device,"exists"). Why one and not the other? It just doesn't make a lot of sense to me.

In the particular case that caused me to post the question, the flow is:
(1) A DCL script executes an application (in a Cache' environment) that we cannot modify.
(2) Cache' application does some setup and then starts a detached process to extract data into RMS files (variable number of files, unpredictable names, variable length of time).
(3) The Cache' application leaves the PID of the detached process in a global and exits.
(4) DCL continues and retrieves detached process PID and loads the PID into a DCL global symbol with a little M code I wrote.
(5) DCL waits for the detached process to finish, which is the only signal that the file creation is done.
(6) DCL converts and transfers files to another system.
(7) DCL sends a status e-mail to interested parties.

Before I got involved, none of this was automated. The users waited 4, 5, 6, or more hours and hoped that the detached process was done -- they did not even know how to check the Cache' environment for the detached process. I was asked to tighten the process as much as possible, because of changing requirements for data availability.

So, there is no choice of making the processes more synchronized using batch jobs, subprocesses, mailboxes to communicate between processes, or other mechanisms that OpenVMS may provides. So I thank you again for the many good ideas here.

[Jess Goodman]

So your real problem is that you want to synchronize on the completion of a detached process. I agree that there should be an easier way to do this, similar to how you can do it for a batch process with the DCL command SYNCHRONIZE.

Anyway, checking if the process exists with F$GETJPI in a DCL loop might work fine for you, but have you considered using a process termination mailbox?

If you can modify the RUN command that starts the process it is simple. Just create a mailbox at startup time and change the RUN command to use /MAILBOX=unit_number.
Then from another process you can post a read to the mailbox, either from a program or from DCL. When the read completes you get an accounting record and you know that the process has finished. No polling required.

You can also specify a termination mailbox when using the $CREPRC system service in a program.

And if you can't set the termination mailbox at process creation you could use kernel-mode code to modify the PCB$L_TMBU field of a target process. (I have code that could be modified to do this with a half-hour's work, so if you are interested let me know and I will send it to you.)

[Jim Geier_1]

We cannot modify the code that performs the run command - it is performed in a vendor-supplied M routine in a Cache' environment using the M (aka MUMPS) JOB command. The M code that performs the data extraction has run monthly for over 10 years without problems. Our current need will be well-served by using DCL and waiting until the PID goes away.

[Richard W Hunt]

I guess I'm too simple-minded, but is there a serious problem with this?

$ SHOW PROCESS /ID={suspected PID}/OUT=NLA0:

You either get back $STATUS as SYSTEM-S-NORMAL or SYSTEM-W-NONEXPR, which means that you could do an odd/even test on a substitution of $STATUS. The -W- isn't handled that badly by the DCL last-chance handler; only -E- or -F- get trapped in a way that potentially stops a process. You could as a precaution turn off messages with an appropriate SET MESSAGE command.

I might have approached this via:

$ SHOW PROC/IDE=xxxx /OUT=NLA0:
$ IF .NOT. '$STATUS THEN GOTO NOT_THERE

Note that the xxxx is not required to be 8 hex digits in this context. It just has to map to the same number format that would be shown after the command SHOW SYSTEM.

This DOES presume that you have adequate privileges to see the process information, but that usually isn't so tough a requirement.

This is in line with the KISS philosophy. Just one man's opinion.

[John Gillings]

Jim,

If you're happy with a polling approach, and the granularity of (say) a few minutes between polls so you don't overload your system with F$GETJPI calls then I guess you're all set. If you need to go to finer granularity, but can't get a termination mailbox, then you may need something more devious.

One possibility is to lob an AST at the process which requests an EX mode lock on some unique resource. Your watcher process can then request the same lock. When it's granted, you know the original process has gone. This is a non-polling, more-or-less instantaneous solution, but it requires fairly heavy privileges and potentially dangerous code. On the other hand, if your process has a known output file it has open exclusively, you may be able to find an existing lock that its holding to wait on. You'll still need privilege, but won't need to send an AST.

[Michael Moroney]

Then there is:

$ SET PROCESS /ID='pid

followed by a branch on the value of $STATUS (1 means process exists,
"%X1077808A" means it doesn't). This is a "null" SET PROCESS (doesn't change anything). This isn't any better than the original poster's solution other than not parsing the text of the message.

I actually had a similar problem in the past, determining whether a process with a certain process name existed. This is actually not as easy since surprisingly to me, there wasn't a one-line process_name-to-PID lexical or lexical that takes a process name as input. I wound up using:

$ SET PROCESS 'name

followed by a branch on $STATUS, which is where I came up with the other possibility.

[Jan van den Ende]

Re Michael:

>>>
$ SET PROCESS 'name

followed by a branch on $STATUS, which is where I came up with the other possibility.
<<<

Please be aware that 'name' only will be unique FOR THE SAME UIC ON THE SAME NODE.

Any existence of 'name' for any other UIC, or for the same UIC on another node in the cluster, will NOT prevent successfull execution.

So, IF the constraints on UIC and same-node are met, yes, this will work.
However, whenever I faced similar needs, it was always on a clusterwide basis, and more often than not, concerned all UICs.

I have a few lines in DCL in my SYS$LOGIN, pointed to by (LOGIN.COM defined LNM CTX), which is a complete sjablone for building a context and looping through a process lookup.

Include it; replace 2 or 3 values; (maybe delete one F$CONTEXT line), and live happily with it that way.

fwiw.

Proost.

Have one on me.

jpe

[Michael Moroney]

I know. For that particular application a certain process had to be running, and it always had a particular process name. The check was to be sure it was. It didn't matter if someone outside the group used that process name (unlikely).