Re: SDSF CPU L/Z

2020-06-26 Thread Shaffer, Terri
I find is odd in my 34 years as a sysprog this has always been true or pretty 
close and now its not.  Not saying I don't believe that you are telling me just 
not what I am seeing..

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 11:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,

I think the SDSF doc could be a bit clearer in this area, but the numbers you 
quoted do not mean what you think they mean.

There is some extra help text in the "CPU and SIO fields" section of the help 
for the DA command (at the end of the help for the content of the fields).

Taking the  xx/yy numbers :

(o) xx - This is SRM's native view of CPU% busy of the local system without 
factoring in any LPAR weights from PR/SM.
For example, if over a period of 100 seconds, PR/SM gave this system a grand 
total of 10 CPU seconds (and 90 seconds to other LPARs) and this system was 
busy for 5 seconds then the CPU% would be 50%. Think of this as a SRM being 
blissfully unaware of other LPARs in the CEC and behaving like an old-school 
single MVS system.

(o) yy - This is the CPU% factoring in LPAR weighting.
Using the above trivial example, this would be 5.

SDSF does not perform any calculations in this area - we just report what we 
get back from RMF for these two numbers.

I will look to see if we can improve the help text.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 3:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Thanks Rob,
So NO to the first 2, as we run with hardly any usermods or customizations.

Number 3 is partially true. The 2 UBS2T* Jobs are running on ACW5, But that is 
reflected by the 45/29 number is my display. 45 is my total across the sysplex 
and 29 is the local lpar.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


1. You have an ISFUSER exit that alters the title line (possible - but not 
common) 2. You have a local replacement/modification for ERBSMFI or ERB2XDGS on 
your 2.2 system that is not installed on your 2.4 system (unlikely).
3. Your 2.2 system is getting the lion's share of CPU resources (maybe via LPAR 
definitions), or is naturally a much busier system so that it permanently shows 
a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:47 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a disc

Re: SDSF CPU L/Z

2020-06-26 Thread Martin Packer
Source RMF fields in the help text would be, ahem, helpful. :-) And if 
they derive from MVS control blocks those field names would be useful, 
too. And if MVS gets them from indeed Diagnose 204... :-)

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Rob Scott 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   26/06/2020 16:07
Subject:[EXTERNAL] Re: SDSF CPU L/Z
Sent by:IBM Mainframe Discussion List 



Terri,

I think the SDSF doc could be a bit clearer in this area, but the numbers 
you quoted do not mean what you think they mean.

There is some extra help text in the "CPU and SIO fields" section of the 
help for the DA command (at the end of the help for the content of the 
fields).

Taking the  xx/yy numbers :

(o) xx - This is SRM's native view of CPU% busy of the local system 
without factoring in any LPAR weights from PR/SM.
For example, if over a period of 100 seconds, PR/SM gave this system a 
grand total of 10 CPU seconds (and 90 seconds to other LPARs) and this 
system was busy for 5 seconds then the CPU% would be 50%. Think of this as 
a SRM being blissfully unaware of other LPARs in the CEC and behaving like 
an old-school single MVS system.

(o) yy - This is the CPU% factoring in LPAR weighting.
Using the above trivial example, this would be 5.

SDSF does not perform any calculations in this area - we just report what 
we get back from RMF for these two numbers.

I will look to see if we can improve the help text.

Rob

From: IBM Mainframe Discussion List  On Behalf 
Of Shaffer, Terri
Sent: Friday, June 26, 2020 3:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Thanks Rob,
So NO to the first 2, as we run with hardly any usermods or 
customizations.

Number 3 is partially true. The 2 UBS2T* Jobs are running on ACW5, But 
that is reflected by the 45/29 number is my display. 45 is my total across 
the sysplex and 29 is the local lpar.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system 
CPU usage.

A couple of possibilities exist that could explain what you are seeing :


1. You have an ISFUSER exit that alters the title line (possible - but not 
common)
2. You have a local replacement/modification for ERBSMFI or ERB2XDGS on 
your 2.2 system that is not installed on your 2.4 system (unlikely).
3. Your 2.2 system is getting the lion's share of CPU resources (maybe via 
LPAR definitions), or is naturally a much busier system so that it 
permanently shows a higher local CPU% which does not look out of place 
when SYSNAME=* is in effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe 
we can take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my 
point of sysname=* I think it should total all lpars, like I see in my 
z/OS 2.2 lpar and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what 
she stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you 
cant really tell the CPU column.


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<
mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com
>>

-Original Message-
From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU<
mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>> On 
Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<
mailt

Re: SDSF CPU L/Z

2020-06-26 Thread Rob Scott
Terri,

I think the SDSF doc could be a bit clearer in this area, but the numbers you 
quoted do not mean what you think they mean.

There is some extra help text in the "CPU and SIO fields" section of the help 
for the DA command (at the end of the help for the content of the fields).

Taking the  xx/yy numbers :

(o) xx - This is SRM's native view of CPU% busy of the local system without 
factoring in any LPAR weights from PR/SM.
For example, if over a period of 100 seconds, PR/SM gave this system a grand 
total of 10 CPU seconds (and 90 seconds to other LPARs) and this system was 
busy for 5 seconds then the CPU% would be 50%. Think of this as a SRM being 
blissfully unaware of other LPARs in the CEC and behaving like an old-school 
single MVS system.

(o) yy - This is the CPU% factoring in LPAR weighting.
Using the above trivial example, this would be 5.

SDSF does not perform any calculations in this area - we just report what we 
get back from RMF for these two numbers.

I will look to see if we can improve the help text.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 3:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Thanks Rob,
So NO to the first 2, as we run with hardly any usermods or customizations.

Number 3 is partially true. The 2 UBS2T* Jobs are running on ACW5, But that is 
reflected by the 45/29 number is my display. 45 is my total across the sysplex 
and 29 is the local lpar.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


1. You have an ISFUSER exit that alters the title line (possible - but not 
common)
2. You have a local replacement/modification for ERBSMFI or ERB2XDGS on your 
2.2 system that is not installed on your 2.4 system (unlikely).
3. Your 2.2 system is getting the lion's share of CPU resources (maybe via LPAR 
definitions), or is naturally a much busier system so that it permanently shows 
a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:47 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSE

Re: SDSF CPU L/Z

2020-06-26 Thread Shaffer, Terri
Thanks Rob,
 So NO to the first 2, as we run with hardly any usermods or customizations.

Number 3 is partially true.   The 2 UBS2T* Jobs are running on ACW5, But that 
is reflected by the 45/29 number is my display.  45 is my total across the 
sysplex and 29 is the local lpar.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


  1.  You have an ISFUSER exit that alters the title line (possible - but not 
common)
  2.  You have a local replacement/modification for ERBSMFI or ERB2XDGS on your 
2.2 system that is not installed on your 2.4 system (unlikely).
  3.  Your 2.2 system is getting the lion's share of CPU resources (maybe via 
LPAR definitions), or is naturally a much busier system so that it permanently 
shows a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR COMMAND 
INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=* NP ,JOBNAME ,DP,Real,Paging, 
SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time ,

TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83 , ZFS , FE 634T 0.00 1.75 
1.07 49 0031 22602696 5441.27 , NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 
29189.68 , QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80 , 
C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83 , UBS2EVTA, F0 55T 
0.00 269.00 2.60 264 0108 12993387 2005.01 , NFSC , FE 1M 0.00 0.00 2.93 39 
0027 71333 17037.59 ,T SPAXAA6, F4 54T 0.00 0.00 3.46214 00D6 58211 4888.83 , 
TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79 , TSOJXSA5, F4 37T 
0.00 0.00 6.86 350 015E 2123259 3352.63 , UBS2TDAL, E6 10T 0.00 15177 13.86 320 
0140 534324805 7649.91 , UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 
7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2 COMMAND INPUT ===>, 
,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=* NP ,JOBNAME 
,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt

TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735 , QZ77EVTL IN F2 572 0.00 
372.08 1.58 130 0082 4682243 , C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 
117123444
EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909 , UBS2EVTA IN F2 55T 0.00 335.48 
2.59 264 0108 12988064
TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211 , NFSC NS FE 1M 0.00 0.00 3.58 
39 0027 71333
TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259 , UBS2TDAL IN E6 10

Re: SDSF CPU L/Z

2020-06-26 Thread Rob Scott
Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


  1.  You have an ISFUSER exit that alters the title line (possible - but not 
common)
  2.  You have a local replacement/modification for ERBSMFI or ERB2XDGS on your 
2.2 system that is not installed on your 2.4 system (unlikely).
  3.  Your 2.2 system is getting the lion's share of CPU resources (maybe via 
LPAR definitions), or is naturally a much busier system so that it permanently 
shows a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR
COMMAND INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time ,

TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83 ,
ZFS , FE 634T 0.00 1.75 1.07 49 0031 22602696 5441.27 ,
NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 29189.68 ,
QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80 ,
C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83 ,
UBS2EVTA, F0 55T 0.00 269.00 2.60 264 0108 12993387 2005.01 ,
NFSC , FE 1M 0.00 0.00 2.93 39 0027 71333 17037.59 ,T
SPAXAA6, F4 54T 0.00 0.00 3.46214 00D6 58211 4888.83 ,
TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79 ,
TSOJXSA5, F4 37T 0.00 0.00 6.86 350 015E 2123259 3352.63 ,
UBS2TDAL, E6 10T 0.00 15177 13.86 320 0140 534324805 7649.91 ,
UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2
COMMAND INPUT ===>, ,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt

TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735 ,
QZ77EVTL IN F2 572 0.00 372.08 1.58 130 0082 4682243 ,
C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 117123444
EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909 ,
UBS2EVTA IN F2 55T 0.00 335.48 2.59 264 0108 12988064
TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211 ,
NFSC NS FE 1M 0.00 0.00 3.58 39 0027 71333
TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259 ,
UBS2TDAL IN E6 10T 0.00 15428 12.91 259 0103 537122733 ,
UBS2TDAL IN E6 10T 0.00 16673 14.37 320 0140 534062332

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:01 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<

Re: SDSF CPU L/Z

2020-06-26 Thread Shaffer, Terri
Rob,
 My question,  was does anyone else see this behavior?  And yes that was my 
point of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 
lpar and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR
COMMAND INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time ,

TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83 ,
ZFS , FE 634T 0.00 1.75 1.07 49 0031 22602696 5441.27 ,
NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 29189.68 ,
QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80 ,
C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83 ,
UBS2EVTA, F0 55T 0.00 269.00 2.60 264 0108 12993387 2005.01 ,
NFSC , FE 1M 0.00 0.00 2.93 39 0027 71333 17037.59 ,T
SPAXAA6, F4 54T 0.00 0.00 3.46214 00D6 58211 4888.83 ,
TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79 ,
TSOJXSA5, F4 37T 0.00 0.00 6.86 350 015E 2123259 3352.63 ,
UBS2TDAL, E6 10T 0.00 15177 13.86 320 0140 534324805 7649.91 ,
UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2
COMMAND INPUT ===>, ,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt

TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735 ,
QZ77EVTL IN F2 572 0.00 372.08 1.58 130 0082 4682243 ,
C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 117123444
EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909 ,
UBS2EVTA IN F2 55T 0.00 335.48 2.59 264 0108 12988064
TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211 ,
NFSC NS FE 1M 0.00 0.00 3.58 39 0027 71333
TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259 ,
UBS2TDAL IN E6 10T 0.00 15428 12.91 259 0103 537122733 ,
UBS2TDAL IN E6 10T 0.00 16673 14.37 320 0140 534062332

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbe

Re: SDSF CPU L/Z

2020-06-26 Thread Rob Scott
Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR
COMMAND INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time
,TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83
,ZFS , FE 634T 0.00 1.75 1.07 49 0031 22602696 5441.27
,NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 29189.68
,QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80
,C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83
,UBS2EVTA, F0 55T 0.00 269.00 2.60 264 0108 12993387 2005.01
,NFSC , FE 1M 0.00 0.00 2.93 39 0027 71333 17037.59
,TSPAXAA6, F4 54T 0.00 0.00 3.46 214 00D6 58211 4888.83
,TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79
,TSOJXSA5, F4 37T 0.00 0.00 6.86 350 015E 2123259 3352.63
,UBS2TDAL, E6 10T 0.00 15177 13.86 320 0140 534324805 7649.91
,UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2
COMMAND INPUT ===>, ,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt
,JES2 NS FE 9940 0.00 6.10 1.12 36 0024 594743
,TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
,BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735
,QZ77EVTL IN F2 572 0.00 372.08 1.58 130 0082 4682243
,C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 117123444
,EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909
,UBS2EVTA IN F2 55T 0.00 335.48 2.59 264 0108 12988064
,TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211
,NFSC NS FE 1M 0.00 0.00 3.58 39 0027 71333
,TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
,TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259
,UBS2TDAL IN E6 10T 0.00 15428 12.91 259 0103 537122733
,UBS2TDAL IN E6 10T 0.00 16673 14.37 320 0140 534062332

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>


[https://www.aciworldwide.com/-/media/aci-footer<https://www.aciworldwide.com/-/media/a

Re: SDSF CPU L/Z

2020-06-26 Thread Shaffer, Terri
Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL)PAG  0  CPU/L 4/  1  LINE 815-826 (826)z/OS 
2.4 LPAR
COMMAND INPUT ===>,  ,SCROLL ===>,C
PREFIX=*  DEST=(ALL)  OWNER=*  SORT=CPU%/A  SYSNAME=*
NP  ,JOBNAME  ,DP,Real,Paging,   SIO,  CPU%,ASID,ASIDX, EXCP-Cnt,  CPU-Time
,TCPIP   , FE  14T   0.00   0.001.01   78 004E  129189250.83
,ZFS , FE 634T   0.00   1.75  1.07   49 0031   22602696
5441.27
,NFSC, FE  72T   0.00   0.00 1.13  66 0042 289157   
29189.68
,QZ77EVTL, F2  572   0.00 342.50 1.30  130 00824688161 454.80
,C8QBMSTR, FE  29T   0.00 863.00   1.40   41 0029  1171383406337.83
,UBS2EVTA, F0  55T   0.00 269.00   2.60  264 0108   129933872005.01
,NFSC, FE   1M   0.00   0.00   2.93   39 0027  71333   
17037.59
,TSPAXAA6, F4  54T   0.00   0.00  3.46  214 00D6  582114888.83
,TSPQEBA6, F0  39T   0.00 4113.5   4.65  157 009D  2486803996875.79
,TSOJXSA5, F4  37T   0.00   0.00   6.86  350 015E21232593352.63
,UBS2TDAL, E6  10T   0.00  15177  13.86  320 0140  5343248057649.91
,UBS2TDAL, E6  10T   0.00  16494  14.73  259 0103  5373887497603.17


SDSF DA ACW5 (ALL)PAG  0  CPU/L45/ 29  LINE 813-825Z/OS 2.2
COMMAND INPUT ===>,  ,SCROLL
PREFIX=*  DEST=(ALL)  OWNER=*  SORT=CPU%/A  SYSNAME=*
NP  ,JOBNAME  ,Pos,DP,Real,Paging,   SIO,  CPU%,ASID,ASIDX, EXCP-Cnt
,JES2  NS  FE 9940   0.00   6.10   1.12   36 0024 594743
,TCPIP NS  FE  14T   0.00   0.00   1.27   78 004E  12918
,BBOS010   NS  F0  75T   0.00 338.53   1.52  141 008D7705735
,QZ77EVTL  IN  F2  572   0.00 372.08   1.58  130 00824682243
,C8QBMSTR  NS  FE  29T   0.00 937.32  1.70   41 0029  117123444
,EYUCAS31  NS  EE 2106   0.00   0.00   2.06   87 0057909
,UBS2EVTA  IN  F2  55T   0.00 335.48   2.59  264 0108   12988064
,TSPAXAA6  IN  F2  54T   0.00   0.00   3.16  214 00D6  58211
,NFSC  NS  FE   1M   0.00   0.00   3.58   39 0027  71333
,TSPQEBA6  IN  F0  39T   0.00 4469.0   5.59  157 009D  248609323
,TSOJXSA5  IN  F2  37T   0.00   0.00   6.46  350 015E2123259
,UBS2TDAL  IN  E6  10T   0.00  15428  12.91  259 0103  537122733
,UBS2TDAL  IN  E6  10T   0.00  16673  14.37  320 0140  534062332

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>


[https://www.aciworldwide.com/-/media/aci-footer<https://www.aciworldwide.com/-/media/aci-footer>]
 <http://www.aciworldwide.com<http://www.aciworldwide.com>>
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designate

Re: SDSF CPU L/Z

2020-06-26 Thread Rob Scott
Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>


[https://www.aciworldwide.com/-/media/aci-footer<https://www.aciworldwide.com/-/media/aci-footer>]
 <http://www.aciworldwide.com<http://www.aciworldwide.com>>
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


SDSF CPU L/Z

2020-06-26 Thread Shaffer, Terri
Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com


 [https://www.aciworldwide.com/-/media/aci-footer] 
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN