Process information from GET$JPI seems inconsistent

[Nick Varley]

The code was just a snip, the items mentioned are properly initialised further up the program. I have re-posted the whole code should anyone be interested in seeing it all
.
I think the GET$JPIW route sounds the most hopeful, and I will talk to our developers to create version that uses that routine rather than GET$JPI.

Thanks again to all who have so far responded.

[Joseph Huber_1]

In addition to the synchronization issue, some of the data from the process may be missing/not updated due to the
JPI$M_NO_TARGET_INSWAP
flag (which itself of course is a good thing).
See the system services manual for details.

[Hein van den Heuvel · Accepted solution]

I'm sure that GETJPIW solved the coding problem, but just in case it does not...

$GETJPI works. Period. It has been working for 30 years and no 'rookie' OpenVMS user is going to find a glaring bug in it today.

So if someone writes "Process information from GET$JPI seems inconsistent" then I read that as: "we have created a broken program and woudl like help figuring out what we did wrong".

Using that as a starting point and focussing on "what could we possibly have done wrong" is more productive than speculating as to whether a core OpenVMS system call might have gone wrong on you.

If you still have a problem, then consider adding a LIB$SPAWN call to the program (outside the loop) to perform a SHOW SYSTEM into a file at the same time the program.

The output should be 95% the same as the test program output file. Any and all difference might help explain what is going wrong.

In fact "SHOW SYSTEM" and the proposed program are so close that I wonder why the program was even written?! The only significant difference is "IO" vs "DIRIO" and I wonder whether it is fully understood what the difference between those tow is (BUFIO) and which would be more appropriate.

Now IF you opt to waste development cycles on rolling your own SHOW SYSTEM, then consider adding USER/EXEC/KERNEL cputim, as that is a missing feature from SHOW SYSTEM and can help a lot when trying to understand system behaviour.

Cheers,
hein.

[Nick Varley]

Thank you Hein. Be assured, I am under no misconception that we have done this right and VMS is wrong - I'm a z/OS mainframe guy by breeding (some 30 years now), so I never assume that anything that appears to be wrong is the fault of the operating system.

Your idea is really good and will help us to cross-reference our results with the official version. We have our own deep dark reasons for doing it this way which I won't bore you with right now.

[H_Bachner]

Hello Hein,

> In fact "SHOW SYSTEM" and the proposed program are so close
> that I wonder why the program was even written?!

in his first posting, Nick mentioned that the goal was to collect performance data from various operating systems. This sounds like issuing DCL commands and looking at the result is not an option, rather than getting the information in machine readable format.

If my assumption is correct, I think going the $GETJPI(W) way is far superiour to scanning the output of a DCL command - which may change across versions, and with uncertain behaviour if some field overflows the allocated width or intended value range.

Remember SHOW SYSTEM showing delta times instead of used CPU time? Guy Peleg fixed this a couple of years ago for "SETI at Home" :-)

Cheers,
Hans.

[Richard Brodie_1]

"did you check, wheter a real process exists in the monitored system with a PID of 00153AB8 ? I bet this is some P0 space address in your program and not a real PID !"

On a quick look, I vote for Volker being correct, and you are using f$faol incorrectly; I suggest you check the unformatted values.