DCL - Does a process with this PID exist?

[Jim Geier_1]

I encounter many situations in DCL in which the logic knows a PID, and needs to know if the process exists. If it were a device, I'd use f$getdvi with the "exists" argument. It seems to me that a glaring omission from f$getjpi is lack of an "exists" argument. I typically use something like the following, but it is hardly elegant:

$ on warning then continue
$ info = f$getjpi(pid,"master_pid")
$ if f$message($status,"ident") .eqs. "%NONEXPR"
$ then
$ write sys$output "Process does NOT exist"
$ else
$ write sys$output "Process exists"
$ endif

Not particularly pretty... What is your favorite and most elegant means for determining whether a process exists?

[labadie_1]

May be you could loop with f$context to see if you pid is here ?

Changing a little bit the example below should be enough
http://h71000.www7.hp.com/doc/73final/6489/6489pro_046.html

[Richard Brodie_1]

$ if f$getjpi(pid,"pid") .eqs. pid then ...

[Duncan Morris]

Richard,

that relies on the incoming PID being 8 chars long, which may not be the case in standalone systems if the value is passed in from another source.

You also get a DCL wobbly when running with a non-existant PID

$ set ver
$ if f$getjpi(p1,"pid") .eqs. p1
%SYSTEM-W-NONEXPR, nonexistent process
\1\
$ then
%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data inconsistency
DEVT02>

Duncan

[Duncan Morris]

Jim,

a snippet from one of our procedures:

$! Get process ID of job
$ jobPID = f$trnlnm("xyz_pid")
$ usenam = f$getjpi(jobPID,"USERNAME")
$ if $severity .eqs. 1 .and. jobPID .nes. ""
$ then
$ ! Process exists
$ write sys$output "PID exists"
$ else
$ ! Process does not exist
$ write sys$output "PID missing"
$ endif
$

Duncan

[Robert Gezelter]

Jim,

It is certainly awkward. One can scan the process list, or one can use SPAWN/OUTPUT=NL: to do a SHOW PROCESS/ID=xxx command (and then check $STATUS).

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Elegance and DCL are not often used in the same sentence.

Why change? (Seriously.) I'm usually in favor of increased elegance, but I'm usually rather more in favor of stable and functional and tested. What you have might be ugly, but it has the very significant advantage of "it works."

Another approach here is to better synchronize the operations and to manage the processes more directly, as cases where you can encounter stale PIDs can have other implications. What happens when you have a valid PID and your f$getjpi returns the MASTER_PID, but the process then immediately exits.

And just for fun (and entirely orthagonal to any elegance), here's one "one-line" DCL approach:

$ pipe define foo/job/nolog "0" | ( x = f$getjpi("''pid'","MASTER_PID") 2> nla0: > nla0: && define foo/job/nolog &x )

[John Gillings · Accepted solution]

Jim,

Well, it depends a bit on how bullet proof you want this test to be, and how much time you want to spend testing it.

Dealing with a non-numeric or non-existant symbol "pid" is fairly easy:

$ tpid=F$FAO("!8XL",F$INTEGER("%X''pid'"))

tpid is now an 8 digit hex string, either the same as the original or 0. If it's zero F$GETJPI will return information about the current process, so:

$ IF F$$GETJPI(tpid,"PID").EQS.tpid THEN process exists and is not myself

However, that won't deal with the case where "pid" is a valid hex string with no corresponding process. Using brute force, pure DCL, the quickest way might be a SEARCH of SHOW SYSTEM/CLUSTER:

$ PIPE SHOW SYSTEM/CLUSTER | SEARCH SYS$PIPE "''tpid' " >nl: 2>nl:
$ IF $SEVERITY.EQS."1" THEN process exists

Note, this may give a false positive because it will match a PID string anywhere in the output (like a process name). The trailing space will help, but is not foolproof.

An F$CONTEXT loop across the cluster is safer, and may be quicker than the PIPE, but is more code.

If you're prepared to go with a program, here's a simple MACRO32 program that accepts a PID string (as a foreign command argument) and returns status %X10000001 if the process exists, %X100008E8 (%SYSTEM-W-NONEXPR, nonexistent process) if it doesn't exist and %X10000000 if the PID string is invalid.

.title checkpid
.psect data,rd,wrt,noexe
pid: .LONG 0
pidnew: .LONG 0
pidret: .LONG 0
pidstr: .ASCID /00000000/
$JPIDEF
item: .LONG JPI$_PID
.psect code,rd,nowrt,exe
.entry start,^M<>
; get argument
PUSHAB pidstr
CALLS #1,G^LIB$GET_FOREIGN

; convert to longword integer
PUSHAL pid
PUSHAB pidstr
CALLS #2,G^OTS$CVT_TZ_L

; get PID from $GETJPI
MOVL pid,pidnew
PUSHAL pidret
PUSHL #0
PUSHAL pidnew
PUSHAL item
CALLS #4,G^LIB$GETJPI

CMPL pid,pidnew ; check same
BEQL fin
MOVL #0,R0
fin: ADDL2 #^X10000000,R0
RET
.end start

[Jess Goodman]

Using PIPE to turn off error messages in a one-liner is a good idea, but since F$GETJPI already returns status value %SYSTEM-W-NONEXPR, as your example shows, why not just:

$ PIPE PID = F$GETJPI(PID,"PID") 2>NL: >NL:
$ IF F$MESSAGE($STATUS,"IDENT").EQS."NONEXPR"
$ THEN ...

The symbol PID will not be updated on any F$GETJPI error, and if F$GETJPI succeeds it will get the normalized (8 upper-case hex digits) string version of what PID was before.

If you just want to check the symbol PID after the PIPE command you could use:
$ PIPE PID = F$GETJPI(PID,"PID") 2>NL: >NL: || PID=-1

which will set PID to -1 when the process does not exist (but -1 also on any other F$GETJPI error such as %SYSTEM-F-NOPRIV).

As to using F$CONTEXT, if you know that your process is on the current node and is not a subprocess then this would work:

$ DUMMY=F$CONTEXT("PROCESS",CTX,"MASTER_PID",PID,"EQL")
$ IF F$PID(CTX).EQS."" THEN !No such process
$ DELETE/SYMBOL CTX

If the process can be on other nodes then add
$ DUMMY=F$CONTEXT("PROCESS",CTX,"NODE_CSID",0,"NEQ")

Hoff's point about the race-condition that exists if you are first checking if a process exists, and then doing something to/for it if it *does*, is quite valid. So I'm guessing that you want to do something when the process does *not* exist.

[John Gillings]

Ah, I like Jess's idea...

I'd forgotten that a single stage PIPE command is executed in the context of the current process. That makes it cheap, and it can return symbol values.

So, combining my trick for "cleaning" the PID string, and Jess's for testing it, we get:

$ PIPE newpid=F$GETJPI(F$FAO("!8XL",F$INTEGER("%X''pid'")),"PID") >NL: 2>NL:
$ ProcessExists=$STATUS.AND.-
F$INTEGER("%X''newpid'").EQ.F$INTEGER("%X''pid'")

This will work correctly for any value of PID, including null and undefined. Adding the F$INTEGERs to compare newpid and pid allows leading zeros in the PID string to be omitted.

[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).