Ask the Wizard Questions
World and Group privilege for DCL lexicals
The Question is:
What privilege does one need to see a process by the way
of f$context() and f$pid()? I can see it in the output of
"show system" as any user, but I can only see it by the
f$... way as the user who created the process.
Also, in 5.5-2h4 at least, I think there's a bug:
if f$pid(...) .eqs. "" then ...
doesn't work, but
var = f$pid(...)
if var .eqs. "" then ...
BTW, the process creator has almost all the privileges and
so I am not sure if the creator-ship mattered.
The Answer is:
From DCL HELP (below) you require GROUP or WORLD privilege to have F$PID
return a value for a process other than your own.
SHOW SYSTEM is able to display the information because the image is
installed with WORLD privilege.
>Also, in 5.5-2h4 at least, I think there's a bug:
> if f$pid(...) .eqs. "" then ...
> doesn't work, but
> var = f$pid(...)
> if var .eqs. "" then ...
Without an explanation of what you mean by "doesn't work" it's difficult
to comment. However, my experiments show that the command:
IF F$PID(context).EQS."" THEN
does work as it should, but it's not very useful. Since the context
variable is modified by the call, if the function were to return a
non-null string, the value would be lost (since it was a temporary
result used and discarded in evaluating the condition). Consider the
$ loop: p=F$PID(ctx1)
$ SHOW SYM p
$ IF F$PID(ctx).EQS."" THEN EXIT
$ GOTO loop
Here I'm following 2 parallel F$PID streams using 2 contexts. The
results will be the same for each stream. The output looks like:
P = "20200122"
P = "202000B9"
P = "202000BE"
P = "202000BF"
P = "20200140"
P = "202000C7"
P = ""
at which point the command procedure exitted, so the F$PID in the IF
command must have worked correctly. If I had written:
$ loop: IF F$PID(ctx).EQS."" THEN EXIT
$ SHOW PROCESS/PID='F$PID(ctx)'
$ GOTO loop
or similar, every second process in the list would be returned to the
SHOW PROCESS command. If the "blank" case happened to fall on an even probe
of F$PID, my SHOW PROCESS command would fail with a VALREQ error because
F$PID would have returned a blank.
So, this is not a bug. The commands are working as they should, it's
just that your particular usage doesn't make a lot of sense.
DCL HELP for F$PID
$ HELP LEX F$PID CONTEXT
Specifies a symbol that DCL uses to store a pointer into the
system's list of processes. The F$PID function uses this pointer
to return a PID.
Specify the context symbol by using a symbol. The first time you
use the F$PID function in a command procedure, you should use
a symbol that is either undefined or equated to the null string
(""), or a context symbol that has been created by the F$CONTEXT
If the context symbol is undefined or equated to a null string,
the F$PID function returns the first PID in the system's process
list that it has the privilege to access. That is, if you have
GROUP privilege and if the context symbol is null or undefined,
the F$PID function returns the PID of the first process in your
group. If you have WORLD privilege, the F$PID function returns the
PID of the first process in the list. If you have neither GROUP
nor WORLD privileges, the F$PID returns the first process that you
own. Subsequent calls to F$PID return the rest of the processes on
the system you are accessing.
If the context symbol has been created by the F$CONTEXT function,
the F$PID function returns the first process name in the system's
process list that fits the criteria specified in the F$CONTEXT
calls. Subsequent calls to F$PID return only the PIDs of those
processses that meet the selection criteria set up by the
F$CONTEXT function and that are accessible to your current