sysmaster tables for onstat -u and onstat -g ath
Greetings.
In my quest to produce Perl scripts that consolidate the output of onstat
commands, it has been mostly straightforward to break up a line into into its
component pieces of data. For example, onstat -u, every line has exactly one
string in every column.
Not so for some others (like onstat -d), which I have worked around but never
liked the solution. And now, trying to break up a line in "onstat -g ath" my
workaround looks especially ugly. Here's a couple of lines from that. Sorry if
I can't make them align; our forums display in a non-fixed-width font and
compress repeated spaces.
tid tcb rstcb prty status vp-class name
2 1e89112a0 0 1 IO Idle 7lio* lio vp 0
13 1e8a87830 1e7de6870 1 sleeping secs: 1 1cpu flush_sub(0)
Notice that under the "status" heading, one row has 2 strings and the next has
3. In contrast, under the "name" heading, the first row has 3 strings while
the second row has only 1 string.
This kind of setup upsets the cart for me as a Perl programmer; I can't simply
program for $column[4] because that does not capture the whole value of what
we humans see as the column.
That's my motive for this question: Where in sysmaster can I find this
information? I have looked in systhreads, systcblst and sysrstcb (the latter
two officially undocumented and hence, not reliable after an upgrade). I find
some of this stuff but, to give one example: The status shows up as 0x20 and
that' supposed to mean "running", I think. But I would have to know that in my
scripting because the word does not appear in the table itself.
That's my question. For any Perl scholars I have more information but the
above sums it up.
My Perl workarounds, for Perl scholars:
1. I thought of splitting each line by a regular expression of a minimum of 2
spaces. Then I encountered statuses like "cond wait btc_sort", and "cond wait
netnorm" which have 2 consecutive spaces. Perhaps a 3-space minimum as a field
delimiter? I may experiment.
2. Using the offsets of the various human-visible fields, something like
sscanf(). (Who uses that in C even? Anyone remember that function?) The
problem is that in another release of the IDS product, those offset may
change. So I would have set up different sets of offsets for each new release
of IDS. (BTW, the Perl sscanf() function does not work; it stops for spaces no
matter the length I give it.)
Thanks much for even reading this far!
-- Jacob, the master of precision. NOT
Here is a sysmaster select that I like, it has the information you are
looking for and
I show the it for only userthreads. If you want system threads then
uncomment the
outer join.
select
username
,name thread=5Fname
,statedesc
,statedetail
,wait=5Freason
,num=5Fsched
,cpu=5Ftime
,dbinfo('UTC=5FTO=5FDATETIME',last=5Frun=5Ftime) AS last=5Frun=5Ftime
,format=5Funits( upf=5Flogspuse, "b") LOG=5FSPACE=5FUSED
,upf=5Fisread ROW=5Fprocessed
,upf=5Fiswrite rows=5Finserts
,upf=5Fisrwrite rows=5Fupdates
,upf=5Fisdelete rows=5Fdeleted
,upf=5Fiscommit commits
from systcblst T, {outer} sysrstcb R
where T.tid =3D R.tid
John F. Miller III
STSM, Lead Architect
miller3@us.ibm.com
503-747-1366
IBM Informix Dynamic Server (IDS)
ids-bounces@iiug.org wrote on 04/01/2016 08:03:47 AM:
> From: "JACOB SALOMON" <jakesalomon@yahoo.com>
> To: ids@iiug.org
> Date: 04/01/2016 08:04 AM
> Subject: sysmaster tables for onstat -u and onstat -g ath [36891]
> Sent by: ids-bounces@iiug.org
>
> Greetings.
>
> In my quest to produce Perl scripts that consolidate the output of onstat
> commands, it has been mostly straightforward to break up a line intointo
its
> component pieces of data. For example, onstat -u, every line has exactly
one
> string in every column.
>
> Not so for some others (like onstat -d), which I have worked around but
never
> liked the solution. And now, trying to break up a line in "onstat -g ath"
my
> workaround looks especially ugly. Here's a couple of lines from
> that. Sorry if
> I can't make them align; our forums display in a non-fixed-width font and
> compress repeated spaces.
>
> tid tcb rstcb prty status vp-class name
> 2 1e89112a0 0 1 IO Idle 7lio* lio vp 0
> 13 1e8a87830 1e7de6870 1 sleeping secs: 1 1cpu flush=5Fsub(0)
>
> Notice that under the "status" heading, one row has 2 strings and
> the next has
> 3. In contrast, under the "name" heading, the first row has 3 strings
while
> the second row has only 1 string.
>
> This kind of setup upsets the cart for me as a Perl programmer; I
> can't simply
> program for $column[4] because that does not capture the whole value of
what
> we humans see as the column.
>
> That's my motive for this question: Where in sysmaster can I find this
> information? I have looked in systhreads, systcblst and sysrstcb (the
latter
> two officially undocumented and hence, not reliable after an upgrade). I
find
> some of this stuff but, to give one example: The status shows up as 0x20
and
> that' supposed to mean "running", I think. But I would have to know
> that in my
> scripting because the word does not appear in the table itself.
>
> That's my question. For any Perl scholars I have more information but the
> above sums it up.
>
> My Perl workarounds, for Perl scholars:
> 1. I thought of splitting each line by a regular expression of a minimum
of 2
> spaces. Then I encountered statuses like "cond wait btc=5Fsort", and "cond
wait
> netnorm" which have 2 consecutive spaces. Perhaps a 3-space minimum
> as a field
> delimiter? I may experiment.
> 2. Using the offsets of the various human-visible fields, something like
> sscanf(). (Who uses that in C even? Anyone remember that function?) The
> problem is that in another release of the IDS product, those offset may
> change. So I would have set up different sets of offsets for each new
release
> of IDS. (BTW, the Perl sscanf() function does not work; it stops
forspaces no
> matter the length I give it.)
>
> Thanks much for even reading this far!
>
> -- Jacob, the master of precision. NOT
>
>
>
***************************************************************************=
****
> Forum Note: Use "Reply" to post a response in the discussion forum.
>