When I call $zgetjpi("","cputim"), I just get back the same number despite repeated calls. Is this expected?

Thanks
Kevin T


yottadb>

yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zver
GT.M V6.3-008 Linux x86_64
yottadb>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'll add that I was initially looking at GT.M manual, here: http://tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/ch07s36.html

I also see a YottaDB entry here: https://docs.yottadb.com/ProgrammersGuide/functions.html#zgetjpi
It mentions that there may be a linux-level privileges issues for some information. Could this be the problem?

Kevin




On Sunday, August 7, 2022 at 8:33:40 PM UTC-4, kdtop wrote:

When I call $zgetjpi("","cputim"), I just get back the same number despite repeated calls. Is this expected?

Thanks
Kevin T

yottadb>

yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zver
GT.M V6.3-008 Linux x86_64
yottadb>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

More info:

yottadb>w $ZYRELEASE
YottaDB r1.30 Linux x86_64
yottadb>

Kevin

On Sunday, August 7, 2022 at 8:37:04 PM UTC-4, kdtop wrote:

I'll add that I was initially looking at GT.M manual, here: http://tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/ch07s36.html

I also see a YottaDB entry here: https://docs.yottadb.com/ProgrammersGuide/functions.html#zgetjpi
It mentions that there may be a linux-level privileges issues for some information. Could this be the problem?

Kevin
On Sunday, August 7, 2022 at 8:33:40 PM UTC-4, kdtop wrote:

When I call $zgetjpi("","cputim"), I just get back the same number despite repeated calls. Is this expected?

Thanks
Kevin T

yottadb>

yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zver
GT.M V6.3-008 Linux x86_64
yottadb>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, August 7, 2022 at 8:41:06 PM UTC-4, kdtop wrote:

More info:

yottadb>w $ZYRELEASE
YottaDB r1.30 Linux x86_64
yottadb>

Kevin
On Sunday, August 7, 2022 at 8:37:04 PM UTC-4, kdtop wrote:

I'll add that I was initially looking at GT.M manual, here: http://tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/ch07s36.html

I also see a YottaDB entry here: https://docs.yottadb.com/ProgrammersGuide/functions.html#zgetjpi
It mentions that there may be a linux-level privileges issues for some information. Could this be the problem?

Kevin
On Sunday, August 7, 2022 at 8:33:40 PM UTC-4, kdtop wrote:

When I call $zgetjpi("","cputim"), I just get back the same number despite repeated calls. Is this expected?

Thanks
Kevin T

yottadb>

yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zver
GT.M V6.3-008 Linux x86_64
yottadb>

Kevin,

I tried it on v 1.28 of YottaDB. The reported value is in hundredths of a second, which is actually a lot of CPU time for a modern processor. I was able to get it to increment by doing some actual work, although after several loop squaring the value of
x until it reached a really big number then resetting it to 2, then a 1000 iteration loop taking a string of all Alpha characters, uppercasing it is an odd iteration, and lowercasing it if it is an even iteration, I only got the value of $zgetjpi("","
cputim") up to 2.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

So are you saying that this is a measurement of actual CPU working time? I.e. if the mumps environment hasn't had to really do anything, but was just sitting there for 1 minute, that the CPU time wouldn't increase significantly?

OK, then I guess it must be working.

Thanks
Kevin

I tried it on v 1.28 of YottaDB. The reported value is in hundredths of a second, which is actually a lot of CPU time for a modern processor. I was able to get it to increment by doing some actual work, although after several loop squaring the

value of x until it reached a really big number then resetting it to 2, then a 1000 iteration loop taking a string of all Alpha characters, uppercasing it is an odd iteration, and lowercasing it if it is an even iteration, I only got the value of $
zgetjpi("","cputim") up to 2.

Mark

Did you try doing a lot of 'work' and then rechecking $zgetjpi? It takes a lot of command line 'work' before it will increment. I ran several 1000 iteration loops doing exponentiation and string manipulation, and only got it up to 2 (which is .02

seconds of cpu time).

Linux is hard to do this with because so much 'stuff' creates a new process.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

So we have one system not working and other system that does work.

Anyone have ideas of how I can test this?

Thanks
Kevin

On Monday, August 8, 2022 at 11:47:45 AM UTC-4, OldMster wrote:

On Sunday, August 7, 2022 at 8:41:06 PM UTC-4, kdtop wrote:

More info:

yottadb>w $ZYRELEASE
YottaDB r1.30 Linux x86_64
yottadb>

Kevin
On Sunday, August 7, 2022 at 8:37:04 PM UTC-4, kdtop wrote:

I'll add that I was initially looking at GT.M manual, here: http://tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/ch07s36.html

I also see a YottaDB entry here: https://docs.yottadb.com/ProgrammersGuide/functions.html#zgetjpi
It mentions that there may be a linux-level privileges issues for some information. Could this be the problem?

Kevin
On Sunday, August 7, 2022 at 8:33:40 PM UTC-4, kdtop wrote:

When I call $zgetjpi("","cputim"), I just get back the same number despite repeated calls. Is this expected?

Thanks
Kevin T

yottadb>

yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zver
GT.M V6.3-008 Linux x86_64
yottadb>

Kevin,

I tried it on v 1.28 of YottaDB. The reported value is in hundredths of a second, which is actually a lot of CPU time for a modern processor. I was able to get it to increment by doing some actual work, although after several loop squaring the value of

x until it reached a really big number then resetting it to 2, then a 1000 iteration loop taking a string of all Alpha characters, uppercasing it is an odd iteration, and lowercasing it if it is an even iteration, I only got the value of $zgetjpi("","
cputim") up to 2.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, August 8, 2022 at 5:37:52 PM UTC-4, kdtop wrote:

So we have one system not working and other system that does work.

Anyone have ideas of how I can test this?

Thanks
Kevin
On Monday, August 8, 2022 at 11:47:45 AM UTC-4, OldMster wrote:

On Sunday, August 7, 2022 at 8:41:06 PM UTC-4, kdtop wrote:

More info:

yottadb>w $ZYRELEASE
YottaDB r1.30 Linux x86_64
yottadb>

Kevin
On Sunday, August 7, 2022 at 8:37:04 PM UTC-4, kdtop wrote:

I'll add that I was initially looking at GT.M manual, here: http://tinco.pair.com/bhaskar/gtm/doc/books/pg/UNIX_manual/ch07s36.html

I also see a YottaDB entry here: https://docs.yottadb.com/ProgrammersGuide/functions.html#zgetjpi
It mentions that there may be a linux-level privileges issues for some information. Could this be the problem?

Kevin
On Sunday, August 7, 2022 at 8:33:40 PM UTC-4, kdtop wrote:

When I call $zgetjpi("","cputim"), I just get back the same number despite repeated calls. Is this expected?

Thanks
Kevin T

yottadb>

yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zgetjpi("","cputim")
77
yottadb>w $zver
GT.M V6.3-008 Linux x86_64
yottadb>

Kevin,

I tried it on v 1.28 of YottaDB. The reported value is in hundredths of a second, which is actually a lot of CPU time for a modern processor. I was able to get it to increment by doing some actual work, although after several loop squaring the value

of x until it reached a really big number then resetting it to 2, then a 1000 iteration loop taking a string of all Alpha characters, uppercasing it is an odd iteration, and lowercasing it if it is an even iteration, I only got the value of $zgetjpi("","
cputim") up to 2.

Mark

Did you try doing a lot of 'work' and then rechecking $zgetjpi? It takes a lot of command line 'work' before it will increment. I ran several 1000 iteration loops doing exponentiation and string manipulation, and only got it up to 2 (which is .02
seconds of cpu time).
Linux is hard to do this with because so much 'stuff' creates a new process.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, August 8, 2022 at 6:11:48 PM UTC-4, kdtop wrote:

So are you saying that this is a measurement of actual CPU working time? I.e. if the mumps environment hasn't had to really do anything, but was just sitting there for 1 minute, that the CPU time wouldn't increase significantly?

OK, then I guess it must be working.

Thanks
Kevin

I tried it on v 1.28 of YottaDB. The reported value is in hundredths of a second, which is actually a lot of CPU time for a modern processor. I was able to get it to increment by doing some actual work, although after several loop squaring the

value of x until it reached a really big number then resetting it to 2, then a 1000 iteration loop taking a string of all Alpha characters, uppercasing it is an odd iteration, and lowercasing it if it is an even iteration, I only got the value of $
zgetjpi("","cputim") up to 2.

Mark

Did you try doing a lot of 'work' and then rechecking $zgetjpi? It takes a lot of command line 'work' before it will increment. I ran several 1000 iteration loops doing exponentiation and string manipulation, and only got it up to 2 (which is .02

seconds of cpu time).

Linux is hard to do this with because so much 'stuff' creates a new process.

Mark

Correct. It is a measurement of CPU Time for the process # passed in the first parameter. If the first parameter is blank, then it is for the current process. It is not a measurement of the entire machine CPU time, from the M programmers guide:

"Returns job or process information of the specified process. The format for the $ZGETJPI function is:"

The privilege issue discussed is if you are trying to retrieve information about process other than the current process - you might not have privileges to get that information for another process.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, August 9, 2022 at 11:47:47 AM UTC-4, OldMster wrote:

On Monday, August 8, 2022 at 6:11:48 PM UTC-4, kdtop wrote:

So are you saying that this is a measurement of actual CPU working time? I.e. if the mumps environment hasn't had to really do anything, but was just sitting there for 1 minute, that the CPU time wouldn't increase significantly?

OK, then I guess it must be working.

Thanks
Kevin

I tried it on v 1.28 of YottaDB. The reported value is in hundredths of a second, which is actually a lot of CPU time for a modern processor. I was able to get it to increment by doing some actual work, although after several loop squaring the

value of x until it reached a really big number then resetting it to 2, then a 1000 iteration loop taking a string of all Alpha characters, uppercasing it is an odd iteration, and lowercasing it if it is an even iteration, I only got the value of $
zgetjpi("","cputim") up to 2.

Mark

Did you try doing a lot of 'work' and then rechecking $zgetjpi? It takes a lot of command line 'work' before it will increment. I ran several 1000 iteration loops doing exponentiation and string manipulation, and only got it up to 2 (which is .02

seconds of cpu time).

Linux is hard to do this with because so much 'stuff' creates a new process.

Mark

Correct. It is a measurement of CPU Time for the process # passed in the first parameter. If the first parameter is blank, then it is for the current process. It is not a measurement of the entire machine CPU time, from the M programmers guide:

"Returns job or process information of the specified process. The format for the $ZGETJPI function is:"

The privilege issue discussed is if you are trying to retrieve information about process other than the current process - you might not have privileges to get that information for another process.

Mark

Kevin,

I've done some more playing with this, and it appears $zgetjpi always returns the cpu time for the current process, regardless of what the first parameter is. I'm going to submit an issue for it on GitLab.

Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, August 9, 2022 at 4:52:53 PM UTC-4, OldMster wrote:

On Tuesday, August 9, 2022 at 11:47:47 AM UTC-4, OldMster wrote:

On Monday, August 8, 2022 at 6:11:48 PM UTC-4, kdtop wrote:

So are you saying that this is a measurement of actual CPU working time? I.e. if the mumps environment hasn't had to really do anything, but was just sitting there for 1 minute, that the CPU time wouldn't increase significantly?

OK, then I guess it must be working.

Thanks
Kevin

I tried it on v 1.28 of YottaDB. The reported value is in hundredths of a second, which is actually a lot of CPU time for a modern processor. I was able to get it to increment by doing some actual work, although after several loop squaring

the value of x until it reached a really big number then resetting it to 2, then a 1000 iteration loop taking a string of all Alpha characters, uppercasing it is an odd iteration, and lowercasing it if it is an even iteration, I only got the value of $
zgetjpi("","cputim") up to 2.

Mark

Did you try doing a lot of 'work' and then rechecking $zgetjpi? It takes a lot of command line 'work' before it will increment. I ran several 1000 iteration loops doing exponentiation and string manipulation, and only got it up to 2 (which is .02

seconds of cpu time).

Linux is hard to do this with because so much 'stuff' creates a new process.

Mark

Correct. It is a measurement of CPU Time for the process # passed in the first parameter. If the first parameter is blank, then it is for the current process. It is not a measurement of the entire machine CPU time, from the M programmers guide:

"Returns job or process information of the specified process. The format for the $ZGETJPI function is:"

The privilege issue discussed is if you are trying to retrieve information about process other than the current process - you might not have privileges to get that information for another process.

Mark

Kevin,

I've done some more playing with this, and it appears $zgetjpi always returns the cpu time for the current process, regardless of what the first parameter is. I'm going to submit an issue for it on GitLab.

Mark

From https://docs.yottadb.com/ProgrammersGuide/functions.html#zgetjpi

Note that the $ZGETJPI() retrieves process time measurements (CPUTIM, CSTIME, CUTIME, STIME, and UTIME) only of the current process ($JOB). The “child” process time includes ZSYSTEM and PIPE device sub-processes (only after the PIPE CLOSEs), but
excludes processes created by JOB commands.

https://gitlab.com/YottaDB/DB/YDB/-/issues/908 has been created suggesting adding the functionality as an improvement to YottaDB.

Regards
– Bhaskar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)