Privilege required to access other process information

[RAVIKANTH_3]

I am checking whether process is running or not using sys$getjpiw as shown below

* Check whether process runs in the cluster

vg_l_jpi.vg_pid.vh_itmcod = JPI$_PID
vg_l_jpi.vg_pid.vh_buflen = 4
vg_l_jpi.vg_pid.vf_bufadr = %LOC (vh_l_pid)
vg_l_jpi.vg_pid.vf_retadr = %LOC (vh_l_pidlen)

vg_l_jpi.vg_eol.vf_end_of_list = 0

* Get process Information

vf_l_status = SYS$GETJPIW (,vh_l_pid_db,,vg_l_jpi,,,)

This is working fine for processes running in local node.
But when for processes in other nodes in the cluster, it is giving as process is running in the cluster even if the process is not running.

I have added WORLD privilege but its still not able to access process information in other nodes. GROUP privilege also exists.

How can i make it workable to access other process information in other nodes in the cluster?
It would be grateful if someone responds quickly, i really got stuck.

Many thanks
Ravi

[Kris Clippeleyr]

Ravi,


But when for processes in other nodes in the cluster, it is giving as process is running in the cluster even if the process is not running.


How do you tell the difference?
What's the value of "vf_l_status" before & after the call to $GETJPIW?
And why do you not specify an IOSB in the call to $GETJPIW?

Regards,
Kris (aka Qkcl)

[RAVIKANTH_3]

Hi chris,

Can you please provide information how can i access other process information from the same system call. Will providing WORLD privilege solves the problem?

Many thanks
Ravi

[Kris Clippeleyr]

Ravi,

Quoting from
http://h71000.www7.hp.com/doc/83final/4527/4527pro_056.html#jun_290

"The calling process must have GROUP privilege to obtain information about other processes with the same group UIC number as the calling process. The calling process must have WORLD privilege to obtain information about other processes on the system that are not in the same group as the calling process."

I've checked it myself and with TMPMBX,NETMBX and WORLD enabled, I was able to retrieve info from processes running on all nodes of our development cluster.

Regards,
Kris (aka Qkcl)

[RAVIKANTH_3]

Hi Kris,

Thanks for the repsonse.

vh_l_pid_db is the process id in database. When ever user logs in i am storing pid in the database. Upon succesful exit, i am making pid as NULL. If the logout is not succesful, then pid remains same.

So user is logging to window in node1 and he has not logged out succesfully. Now user is trying to login with another window with node2. So the code is taking the process id from database and checkign it runs in the cluster or not by using system call sys$getjpiw. But sys$getjpiw is working fine for processes in the same node.

Do you have any idea what is the problem?

Many thanks,
Ravi

[Kris Clippeleyr]

Ravi,
As I asked earlier...
What is the value of "vf_l_status" after a successful call, and after a call that fails?

Regards,
Kris (aka Qkcl)

[RAVIKANTH_3]

Hi Kris,

Thank you
We identified the problem
Using IOSB solved the problem

Ravi

[Ian Miller.]

IOSB is never optional

[Steven Schweda]

> IOSB is never optional

Well, if you don't care about the answer, you
may be able to ignore the IOSB.

In some cases, it's not even sufficient. For
example, I recently discovered the benefits
of considering fib$l_acl_status when using
sys$qiow( [...] (IO$_ACCESS| IO$M_ACCESS)
[...]) to gather ACL data on a file.
(Finding someone else's old bugs is always
more fun than finding one's own.)

[Hoff]

PIDs are volatile and not something that would typically be stored in a database. I'll presume there is some sort of a mechanism here to clear all this non-volatile storage of volatile data should the system fail or the should application crash at an untoward moment.

The sys$getjpiw call here contains two errors. It omits both the event flag and the IOSB. Best practices has both of these as required. If you don't care about the event flag and you're on OpenVMS V7.1 or later, then use EFN$C_ENF from EFNDEF. Otherwise use lib$get_ef call, and get yourself a unique event flag. Get off Event Flag Zero. I'll presume you are checking both vf_l_status and the IOSB after the call, too; both should contain an odd value after a successful completion.

Also read the following topic over at HP, and review your code for the various and sundry coding bugs and instabilities that are listed there:

http://h71000.www7.hp.com/wizard/wiz_1661.html