Re: SDSF RCF (was: MVS modify command capture)

[Paul Gilmartin]

On Thu, 27 Aug 2020 18:18:52 +, Rob Scott wrote:

>ISFCALLS is an external REXX function - all that is required is that the load 
>module (it is an alias to ISFYHOST in SISFLOAD) is available via the normal 
>search sequence.
> 
I have never had to be concerned with this when I call ISFCALLS under UNIX.
Perhaps it's in LPA or link list:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.bpxb600/bpx1rx22.htm

>ISFCALLS returns rc=0 by design when the host envirmnment already exists.
>
So there's no way the coder can restore the caller's status quo ante.
Perhaps it matters little.

-- gil

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

Re: SDSF RCF (was: MVS modify command capture)

[Rob Scott]

ISFCALLS is an external REXX function - all that is required is that the load 
module (it is an alias to ISFYHOST in SISFLOAD) is available via the normal 
search sequence.

ISFCALLS returns rc=0 by design when the host environment already exists.

There are no integrity issues introduced by omitting the ISFCALLS('OFF').

Rob Scott
Rocket Software


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, August 27, 2020 5:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL





On Thu, 27 Aug 2020 16:10:01 +, Rob Scott wrote:

>From what I can see, the original script was a REXX exec and from Chapter 5 in 
>the SDSF User Guide :
>
>"Adding the SDSF host command environment with ISFCALLS
>
>Using SDSF with REXX requires that you add a host command environment prior to 
>any other SDSF host environment commands.
>
But that in turn depends on ISFCALLS's availability in the function package 
with which Rexx is started.  That's true for TMP, UNIX, and IRXJCL.  It may be 
untrue for minor products, perhaps from ISVs.

What is the adverse consequence of omitting ISFCALLS( 'OFF' )?  Integrity?
I'm inclined to omit it, especially near the end of an EXEC. I suspect the case 
worst for performance is multiple ISFCALLS ON ... OFF pairs bracketing short 
sections of code.

ISFCALLS appears not to have a Result code defined for "ISFCALLS already 
active" to enable the coder of a Rexx subroutine to restore the status on entry.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
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

Re: SDSF RCF (was: MVS modify command capture)

[Seymour J Metz]

I replied too soon; I agree that the manual should mention in what contexts the 
external function ISFCALLS is available.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Rob 
Scott 
Sent: Thursday, August 27, 2020 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

>From what I can see, the original script was a REXX exec and from Chapter 5 in 
>the SDSF User Guide :

"Adding the SDSF host command environment with ISFCALLS

Using SDSF with REXX requires that you add a host command environment prior to 
any other SDSF host environment commands.

The host command environment is what allows you to use Address SDSF on the 
ISFEXEC and ISFACT commands.

You add the host command environment with the ISFCALLS() function.

You should delete the host command environment, again using ISFCALLS, prior to 
the termination of the exec.

The syntax of the ISFCALLS() function is: rc = ISFCALLS ( 'ON' 'OFF' 
,'SSTYPE=JES2' )

ON adds the SDSF host command environment
OFF deletes the SDSF host command environment
SSTYPE=JES2 requests that SDSF process JES2 rather than determining whether to 
process JES2 or JES3"


I think the above documentation is placed in the correct chapter (as long the 
"Invoking SDSF" section is updated to point to Chapter 5 for REXX).

SDSF is not implicitly activated in REXX, you have to explicitly activate it 
using the ISFCALLS() function (which the original REXX script does).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 27, 2020 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



> Any product can dynamically add itself

In the case under discussion, the script has not invoked SDSF. At a minimum, 
the SDSF documentation should mention that SDSF can be implicitly activated; 
ideally it should mention the relevant contexts.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Rob 
Scott mailto:rsc...@rocketsoftware.com>>
Sent: Thursday, August 27, 2020 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

Any product can dynamically add itself to the REXX host environment table to 
provide "ADDRESS foobar" style support, so I think that it is the requirement 
of the underlying product to document that fact (rather than TSO or z/OS Unix).

On re-reading the SDSF User Guide, the section on "Invoking SDSF" only mentions 
TSO and ISPF as I believe it is referring to the interactive interface and the 
things you can do on the panels (or screens).

I agree that this is misleading as there other ways of invoking SDSF to get 
data.

I will see if I can get the "Invoking SDSF" section in the user guide to be 
more explicit and point to the later chapters that describe REXX (and batch).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Paul 
Gilmartin
Sent: Thursday, August 27, 2020 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



On Wed, 26 Aug 2020 20:27:10 +, Seymour J Metz wrote:

>Well, here there's nothing to escalate; I've generally gotten good responses 
>from RCFs.
>
Submitted as below. Has anyone suggestions for additions?

Hello, MHVRCFs,

Neither z/OS Version 2 Release 4 TSO/E REXX Reference
IBM SA32-0972-40
nor z/OS Version 2 Release 4 Using REXX and z/OS UNIX System Services
IBM SA23-2283-40
mentions that the SDSF command environment ("ADDRESS SDSF")
is available under IRXJCL and Unix System Services. I have
used ADDRESS SDSF in both contexts. I suspect this function
is provided intentionally by IBM with intent to support it.
z/OS Version 2 Release 4 SDSF User's Guide IBM
SC27-9028-40
mentions only that it's available under TSO, not IRXJCL nor
UNIX System Services.

I find UNIX and IRXJCL mentioned somewhat obliquely in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247419.pdf>
... but a Redbook is not where most programmers would
seek such documentation.

The availability of "ADDRESS SDSF" under UNIX and IRXJCL
should be mentioned in a Reference manual.

More generally, should the availability of a command
environment be documented in a Rexx manual such as
SA32-0972-40 or SA23-2283-40, or in the manual describing
the commands such as SC27-9028-40? An incomplete list
such as in SA32-0972-40 or SC27-9028-40 is likely to
mislead programmers.

Thanks,
gil

Re: SDSF RCF (was: MVS modify command capture)

[Seymour J Metz]

Thanks; I missed that. Yes, pointing to Chapter 5 should be enough.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Rob 
Scott 
Sent: Thursday, August 27, 2020 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

>From what I can see, the original script was a REXX exec and from Chapter 5 in 
>the SDSF User Guide :

"Adding the SDSF host command environment with ISFCALLS

Using SDSF with REXX requires that you add a host command environment prior to 
any other SDSF host environment commands.

The host command environment is what allows you to use Address SDSF on the 
ISFEXEC and ISFACT commands.

You add the host command environment with the ISFCALLS() function.

You should delete the host command environment, again using ISFCALLS, prior to 
the termination of the exec.

The syntax of the ISFCALLS() function is: rc = ISFCALLS ( 'ON' 'OFF' 
,'SSTYPE=JES2' )

ON adds the SDSF host command environment
OFF deletes the SDSF host command environment
SSTYPE=JES2 requests that SDSF process JES2 rather than determining whether to 
process JES2 or JES3"


I think the above documentation is placed in the correct chapter (as long the 
"Invoking SDSF" section is updated to point to Chapter 5 for REXX).

SDSF is not implicitly activated in REXX, you have to explicitly activate it 
using the ISFCALLS() function (which the original REXX script does).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 27, 2020 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



> Any product can dynamically add itself

In the case under discussion, the script has not invoked SDSF. At a minimum, 
the SDSF documentation should mention that SDSF can be implicitly activated; 
ideally it should mention the relevant contexts.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Rob 
Scott mailto:rsc...@rocketsoftware.com>>
Sent: Thursday, August 27, 2020 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

Any product can dynamically add itself to the REXX host environment table to 
provide "ADDRESS foobar" style support, so I think that it is the requirement 
of the underlying product to document that fact (rather than TSO or z/OS Unix).

On re-reading the SDSF User Guide, the section on "Invoking SDSF" only mentions 
TSO and ISPF as I believe it is referring to the interactive interface and the 
things you can do on the panels (or screens).

I agree that this is misleading as there other ways of invoking SDSF to get 
data.

I will see if I can get the "Invoking SDSF" section in the user guide to be 
more explicit and point to the later chapters that describe REXX (and batch).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Paul 
Gilmartin
Sent: Thursday, August 27, 2020 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



On Wed, 26 Aug 2020 20:27:10 +, Seymour J Metz wrote:

>Well, here there's nothing to escalate; I've generally gotten good responses 
>from RCFs.
>
Submitted as below. Has anyone suggestions for additions?

Hello, MHVRCFs,

Neither z/OS Version 2 Release 4 TSO/E REXX Reference
IBM SA32-0972-40
nor z/OS Version 2 Release 4 Using REXX and z/OS UNIX System Services
IBM SA23-2283-40
mentions that the SDSF command environment ("ADDRESS SDSF")
is available under IRXJCL and Unix System Services. I have
used ADDRESS SDSF in both contexts. I suspect this function
is provided intentionally by IBM with intent to support it.
z/OS Version 2 Release 4 SDSF User's Guide IBM
SC27-9028-40
mentions only that it's available under TSO, not IRXJCL nor
UNIX System Services.

I find UNIX and IRXJCL mentioned somewhat obliquely in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247419.pdf>
... but a Redbook is not where most programmers would
seek such documentation.

The availability of "ADDRESS SDSF" under UNIX and IRXJCL
should be mentioned in a Reference manual.

More generally, should the availability of a command
environment be documented in a Rexx manual such as
SA32-0972-40 or SA23-2283-40, or in the manual describing
the commands such as SC27-9028-40? An incomplete list
such as in SA32-0972-40 or SC27-9028-40 is likely to
mislead programmers.

Thanks,
gil

--

Re: SDSF RCF (was: MVS modify command capture)

[Paul Gilmartin]

On Thu, 27 Aug 2020 16:10:01 +, Rob Scott wrote:

>From what I can see, the original script was a REXX exec and from Chapter 5 in 
>the SDSF User Guide :
>
>"Adding the SDSF host command environment with ISFCALLS
>
>Using SDSF with REXX requires that you add a host command environment prior to 
>any other SDSF host environment commands.
> 
But that in turn depends on ISFCALLS's availability in the function package
with which Rexx is started.  That's true for TMP, UNIX, and IRXJCL.  It may
be untrue for minor products, perhaps from ISVs.

What is the adverse consequence of omitting ISFCALLS( 'OFF' )?  Integrity?
I'm inclined to omit it, especially near the end of an EXEC. I suspect the
case worst for performance is multiple ISFCALLS ON ... OFF pairs 
bracketing short sections of code.

ISFCALLS appears not to have a Result code defined for "ISFCALLS already
active" to enable the coder of a Rexx subroutine to restore the status on
entry.

-- gil

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

Re: Physical Tape Ejection - RMM

[Jake Anderson]

Thank you for the information.

While requesting for a eject a tape in use will report us the same ? I mean
will it stall our request when a tape in use .

On Thu, 27 Aug, 2020, 7:00 pm Erika Dawson,  wrote:

> I checked with the RMM service team and they had indicated that clients
> will typically generate the eject commands after the DSTORE HSKP has run.
>
>
> Here's some additional information from one of the RMM manuals if the
> volumes are being system-managed in an IBM tape library ...
>
> DFSMSrmm does not automatically eject volumes from a system-managed tape
> library as part of inventory management processing. To request that a
> volume is ejected from a system-managed tape library, use the DFSMSrmm
> Change Volume Details panel to change the location for a volume residing in
> a system-managed library or use the RMM CHANGEVOLUME subcommand to change
> the location or issue an eject request. Figure 1 shows how to use the
> CHANGEVOLUME subcommand to change a volume's location to its shelf
> location. The change to the SHELF causes the volume to be ejected from a
> system-managed tape library.
> Figure 1. Ejecting a volume from a system-managed library
> RMM CHANGEVOLUME volser LOCATION(SHELF)
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.idarm00/manejt.htm
>
> They had also suggested that you can open a Q PMR (Case) and they can
> verify what you may have setup to eject the tape volumes and answer any
> additional questions that you have.
>
> Erika Dawson (IBM)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: SDSF RCF (was: MVS modify command capture)

[Rob Scott]

>From what I can see, the original script was a REXX exec and from Chapter 5 in 
>the SDSF User Guide :

"Adding the SDSF host command environment with ISFCALLS

Using SDSF with REXX requires that you add a host command environment prior to 
any other SDSF host environment commands.

The host command environment is what allows you to use Address SDSF on the 
ISFEXEC and ISFACT commands.

You add the host command environment with the ISFCALLS() function.

You should delete the host command environment, again using ISFCALLS, prior to 
the termination of the exec.

The syntax of the ISFCALLS() function is: rc = ISFCALLS ( 'ON' 'OFF' 
,'SSTYPE=JES2' )

ON adds the SDSF host command environment
OFF deletes the SDSF host command environment
SSTYPE=JES2 requests that SDSF process JES2 rather than determining whether to 
process JES2 or JES3"


I think the above documentation is placed in the correct chapter (as long the 
"Invoking SDSF" section is updated to point to Chapter 5 for REXX).

SDSF is not implicitly activated in REXX, you have to explicitly activate it 
using the ISFCALLS() function (which the original REXX script does).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, August 27, 2020 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



> Any product can dynamically add itself

In the case under discussion, the script has not invoked SDSF. At a minimum, 
the SDSF documentation should mention that SDSF can be implicitly activated; 
ideally it should mention the relevant contexts.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Rob 
Scott mailto:rsc...@rocketsoftware.com>>
Sent: Thursday, August 27, 2020 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

Any product can dynamically add itself to the REXX host environment table to 
provide "ADDRESS foobar" style support, so I think that it is the requirement 
of the underlying product to document that fact (rather than TSO or z/OS Unix).

On re-reading the SDSF User Guide, the section on "Invoking SDSF" only mentions 
TSO and ISPF as I believe it is referring to the interactive interface and the 
things you can do on the panels (or screens).

I agree that this is misleading as there other ways of invoking SDSF to get 
data.

I will see if I can get the "Invoking SDSF" section in the user guide to be 
more explicit and point to the later chapters that describe REXX (and batch).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Paul 
Gilmartin
Sent: Thursday, August 27, 2020 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



On Wed, 26 Aug 2020 20:27:10 +, Seymour J Metz wrote:

>Well, here there's nothing to escalate; I've generally gotten good responses 
>from RCFs.
>
Submitted as below. Has anyone suggestions for additions?

Hello, MHVRCFs,

Neither z/OS Version 2 Release 4 TSO/E REXX Reference
IBM SA32-0972-40
nor z/OS Version 2 Release 4 Using REXX and z/OS UNIX System Services
IBM SA23-2283-40
mentions that the SDSF command environment ("ADDRESS SDSF")
is available under IRXJCL and Unix System Services. I have
used ADDRESS SDSF in both contexts. I suspect this function
is provided intentionally by IBM with intent to support it.
z/OS Version 2 Release 4 SDSF User's Guide IBM
SC27-9028-40
mentions only that it's available under TSO, not IRXJCL nor
UNIX System Services.

I find UNIX and IRXJCL mentioned somewhat obliquely in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247419.pdf>
... but a Redbook is not where most programmers would
seek such documentation.

The availability of "ADDRESS SDSF" under UNIX and IRXJCL
should be mentioned in a Reference manual.

More generally, should the availability of a command
environment be documented in a Rexx manual such as
SA32-0972-40 or SA23-2283-40, or in the manual describing
the commands such as SC27-9028-40? An incomplete list
such as in SA32-0972-40 or SC27-9028-40 is likely to
mislead programmers.

Thanks,
gil

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main 

Re: Physical Tape Ejection - RMM

[Erika Dawson]

I checked with the RMM service team and they had indicated that clients will 
typically generate the eject commands after the DSTORE HSKP has run.

Here's some additional information from one of the RMM manuals if the volumes 
are being system-managed in an IBM tape library ... 

DFSMSrmm does not automatically eject volumes from a system-managed tape 
library as part of inventory management processing. To request that a volume is 
ejected from a system-managed tape library, use the DFSMSrmm Change Volume 
Details panel to change the location for a volume residing in a system-managed 
library or use the RMM CHANGEVOLUME subcommand to change the location or issue 
an eject request. Figure 1 shows how to use the CHANGEVOLUME subcommand to 
change a volume's location to its shelf location. The change to the SHELF 
causes the volume to be ejected from a system-managed tape library.
Figure 1. Ejecting a volume from a system-managed library
RMM CHANGEVOLUME volser LOCATION(SHELF)

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.idarm00/manejt.htm

They had also suggested that you can open a Q PMR (Case) and they can verify 
what you may have setup to eject the tape volumes and answer any additional 
questions that you have.

Erika Dawson (IBM)

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

Re: ZCX task monitoring, anyone?

[Seymour J Metz]

I particularly hate the URL garbling that I'm currently stuck with. Take 
outlook - please!


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Sean Gleann 
Sent: Thursday, August 27, 2020 4:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZCX task monitoring, anyone?

*sigh*. Oh, how I wish that various e-mail clients would quit re-formatting
stuff. My previous response here was so nice & neat & tidy before I hit
'Send'. Reading that response back via IBMMain makes me look like a
complete illiterate...

Sean

On Thu, 27 Aug 2020 at 09:01, Sean Gleann  wrote:

> Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
> them.
>
> The start-up for Cadvisor that I'm using doesn't feature any pointer to a
> parameter list, and despite much googling I don't see any mention of such a
> thing. Everything keeps referring back to Prometheus and then on to Grafana
> My Cadvisor start-up (taken directly from the IBM Red Book and slightly
> modified to comply with local restrictions):
> docker network create monitoring
> docker run --name cadvisor -v /sys:/sys:ro -v
> /var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d --network
> monitoring ibmcom/cadvisor-s390x:0.33.0
>
> Perhaps I'm looking at things the wrong way, but my current understanding
> is:
> Cadvisor (and also Nodeexporter) collect various usage stats;
> Prometheus then gathers that data and does some sort of pre-processing of
> it (it doesn't tell Cadvisor to 'do something' - it just passively makes
> use of the data that Cadvisor collects)
> Grafana takes the data from Prometheus and uses it to generate various
> graphs/tables/reports.
>
> My situation is that when I run Cadvisor on it's own - no other containers
> at all - then it floods as many processors as I define in the zcx
> start.json file.
>
> Whilst Cadvisor is running, I can go to the relevant web-page and I can
> see that it is producing meters/charts, etc all on its own. Since that is
> the case, what is the point of Grafana?
>
> I have a Prometheus.yml file that features the term 'scrape_interval' (but
> not 'housekeeping'), but that file is for use by Prometheus, isn't it? How
> does it affect the amount of work that Cadvisor is doing, since I haven't
> even started that container yet?
>
> Regards
> Sean
>
> On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi  wrote:
>
>> Check your values for housekeeping interval and scrape_interval.
>> Recommended is 15s and 30s (which makes for a 60 second rate window).
>> Small value for housekeeping interval will cause cAdvisor cpu usage to be
>> high, while scrape_interval affects Prometheus cpu usage.  It is entirely
>> possible to cause data collection to use 100% of the z/OS cpu -- remember
>> that on Unix systems the rule of thumb is 40% overhead for uncaptured cpu
>> time while z/OS is far more efficient and runs well under 10%.  You will
>> see this behaviour in zCX containers, it isn't going to measure the same
>> as
>> z/OS workload.  The optimizations in Unix have the premise that cpu time
>> is
>> low cost (as is memory), while z/OS considers cpu to be high cost and path
>> length worth saving.  Same for the subsystems in z/OS and performance
>> monitors.
>>
>> On Wed, Aug 26, 2020 at 11:43 PM Sean Gleann 
>> wrote:
>>
>> > Allan - "...count the beans differently...' Yes, I'm beginning to get
>> used
>> > to that concept. For instance, with the CPU Utilisation data that I
>> *have*
>> > been able to retrieve, the metric given is not 'CPU%', but 'Number of
>> > cores'. I'm having to do some rapid re-orienting to my way of thinking.
>> > As for the memory size, I've got "mem-gb" : 2 defined in my start.json
>> > file, but I've not seen any indication of paging load at all in my
>> testing.
>> >
>> > Michael - 5 zIIPs?   I wish!  Nope - these are all general-purpose
>> > processors.
>> > The z/OS system I'm using is a z/VM guest on a system run by an external
>> > supplier, so I'm not sure if defining zIIPs would actually achieve
>> anything
>> > (Is it possible to dedicate a zIIP engine to a specific z/VM guest?
>> That's
>> > a road I've not yet gone down).
>> > With regard to the WLM definitions, I followed the advice in the red
>> book
>> > and I'm reasonably certain I've got it right. Having said that,
>> cross-refer
>> > to a thread that I started earlier this week, titled "WLM Query"
>> > The response to that led to me defining a resource group to cap the
>> > started task to 10MSU, which resulted in a CPU% Util value of roughly
>> 5% -
>> > something I could be happy with.
>> > Under that cap, the started task ran, yes, but it ran like a
>> three-legged
>> > dog (my apologies to limb-count-challenged canines).
>> > Start-up of the task, from the START command to the "server is
>> > listening..." message took over an hour, and
>> > STOP-command-to-task-termination took approx. 30 minutes.
>> > (SSH-ing to the 

Re: MVS modify command capture

[Ed Jaffe]

On 8/27/2020 3:29 AM, David Spiegel wrote:

Hi Ed,
Do EMCS messages not go to SYSLOG?
If yes, please provide an example.



Why does it matter to my EMCS console if some other message destination 
is experiencing a slow down? Hint: It doesn't.


Despite its irrelevancy, the answer to your question is of course that 
an EMCS console can *absolutely* receive solicited or unsolicited 
messages that do not go to the hardcopy log. The simplest example is one 
that occurs every second of every day in nearly every shop in the world 
where unsolicited WTP (route code 11) messages are rightly suppressed 
from the hardcopy log. It might be valuable to review the ROUTCODE 
parameter on your HARDCOPY statement in CONSOLxx to see how yours is 
configured.


In addition, our software takes advantage of WTO with MCSFLAG=NOCPY to 
return solicited response messages to EMCS requesters without the 
console request or server response appearing on hardcopy log no matter 
how things are configured.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: MVS modify command capture

[Seymour J Metz]

 1. I'd like to see Invoking SDSF refer to Chapter 5 
 2. I'd like to see Invoking SDSF mention the automatic invocation
of SDSF in, e.g., IRXJCL.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Rob 
Scott 
Sent: Thursday, August 27, 2020 4:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS modify command capture

Chapter 5 of the SDSF User's Guide is entitled : "Using SDSF with the REXX 
Programming Language"

What improvements do you wish to see in the manual?

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, August 26, 2020 7:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS modify command capture

EXTERNAL EMAIL



I guess that it's time for an RCF; invoking SDSF in 
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc279028/$file/isfa600_v2r4.pdf
 only mentions the first two.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Rob 
Scott mailto:rsc...@rocketsoftware.com>>
Sent: Wednesday, August 26, 2020 11:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS modify command capture

SDSF has distinct environments that it natively supports on z/OS :


1. ISPF
2. TSO CPPL
3. Batch (and AFD)
4. REXX

The SDSF REXX interface will run where there is a valid REXX environment.

Note that the batch SDSF interface has been stabilised and we now encourage 
users to convert to SDSF REXX.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Seymour J Metz
Sent: Wednesday, August 26, 2020 3:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS modify command capture

EXTERNAL EMAIL



That code has to run under SDSF, which is a TSO command. I don't know whether 
SDSF will run under a TSO subset environment.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3>



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>
 on behalf of Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu>>
Sent: Wednesday, August 26, 2020 9:40 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: MVS modify command capture

On Wed, 26 Aug 2020 07:40:47 -0500, Roger Lowe wrote:
>>
>>Is there a way to capture a MODIFY command ?
>>
>You could try this bit of REXX and then invoke it via IKJEFT01 batch jcl -
>
Does that require TSO or would IRXJCL (or even UNIX mutatis mutandis) sufffice?

> /*REXX*/
> blah = ISFCALLS('ON')
> ISFCONS = "MY@CONS"
> ISFDELAY = "1"
> PARSE ARG input
> cmd.0=1
> cmd.1=input
> ADDRESS SDSF ISFSLASH "(cmd.)"
> IF (ISFULOG.0 > 0) THEN
> DO i=1 TO ISFULOG.0
> SAY ISFULOG.i
> END
> EXIT 0
>
>and then the jcl to use -
>
> //S1 EXEC PGM=IKJEFT01
>//SYSEXEC DD DISP=SHR,DSN=my.rexx.lib
>//SYSTSPRT DD SYSOUT=* <= change this to point to a dataset
>//SYSTSIN DD *
> %SDSFCMD D T

-- gil

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 
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: 

Re: SDSF RCF (was: MVS modify command capture)

[Seymour J Metz]

> Any product can dynamically add itself

In the case under discussion, the script has not invoked SDSF.  At a minimum, 
the SDSF documentation should mention that SDSF can be implicitly activated; 
ideally it should mention the relevant contexts.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Rob 
Scott 
Sent: Thursday, August 27, 2020 6:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF RCF (was: MVS modify command capture)

Any product can dynamically add itself to the REXX host environment table to 
provide “ADDRESS foobar” style support, so I think that it is the requirement 
of the underlying product to document that fact (rather than TSO or z/OS Unix).

On re-reading the SDSF User Guide, the section on “Invoking SDSF” only mentions 
TSO and ISPF as I believe it is referring to the interactive interface and the 
things you can do on the panels (or screens).

I agree that this is misleading as there other ways of invoking SDSF to get 
data.

I will see if I can get the “Invoking SDSF” section in the user guide to be 
more explicit and point to the later chapters that describe REXX (and batch).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, August 27, 2020 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



On Wed, 26 Aug 2020 20:27:10 +, Seymour J Metz wrote:

>Well, here there's nothing to escalate; I've generally gotten good responses 
>from RCFs.
>
Submitted as below. Has anyone suggestions for additions?

Hello, MHVRCFs,

Neither z/OS Version 2 Release 4 TSO/E REXX Reference
IBM SA32-0972-40
nor z/OS Version 2 Release 4 Using REXX and z/OS UNIX System Services
IBM SA23-2283-40
mentions that the SDSF command environment ("ADDRESS SDSF")
is available under IRXJCL and Unix System Services. I have
used ADDRESS SDSF in both contexts. I suspect this function
is provided intentionally by IBM with intent to support it.
z/OS Version 2 Release 4 SDSF User's Guide IBM
SC27-9028-40
mentions only that it's available under TSO, not IRXJCL nor
UNIX System Services.

I find UNIX and IRXJCL mentioned somewhat obliquely in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247419.pdf
... but a Redbook is not where most programmers would
seek such documentation.

The availability of "ADDRESS SDSF" under UNIX and IRXJCL
should be mentioned in a Reference manual.

More generally, should the availability of a command
environment be documented in a Rexx manual such as
SA32-0972-40 or SA23-2283-40, or in the manual describing
the commands such as SC27-9028-40? An incomplete list
such as in SA32-0972-40 or SC27-9028-40 is likely to
mislead programmers.

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 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://secure-web.cisco.com/152_YT5WeUW8V-MUvUJRW1vu8UNhOvka-dOvVIaT6_06_0oWEqt0qAEwTTbxa_OXtDmGU9skNwm-L_ulvUJr4ErTfG1Yi4oXHHBZ06KNGvv2ulLx5zg_MWRThH45tgXJU9J3sbsPDmIQ7Qx6JH90HrxOjO1yGsIzhkrRfUDvZ5bKnuBiKCwKil1hz4zWViEau8v1puxyMRoGixoizzD0JkXIQRtAttG4tiblXXUFjVOTmyeH8e-VUmViZcQ1szNR16xyAPrJVPlAi1iXrRdR2G0yplJxb9e0n4nz_ohZcUQeUH-Za30Jzy23F5DPBNPrszNAkazt9hNjnstK-zcKHH-PE2u-fpJlXQtIGkyzImFFh5TpH8yi3KobJ6Z5SbgwXckSIp8kh2MBzMAPlNKW9OPBs14y8V32jzrZI3TsJiAKH68K8f4GoYm4PSI2EKLAz/https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://secure-web.cisco.com/1gzTzcKx0ODDaqFYEUzPOp83WJGyGEvIqa5uhsKuQLDpPN7QzqzkXpKjjMqsqc33WfB2Au4fRiUxsLB-59ul61kP9FVINZS6bOC45gMiCGsYnUbnNHJ7B_sLX4SLepXmzScy9XheIU3j20LUkrB-EpTAthkZpZhlYVkJnYw0Pgw_AWxzAYh_RSB2-2TWmKlmXoTWJSmV565S09hixE9l_2BPLPSd_VPRj0bRIQ-gh6VR0P4sh4k-1C8CwmsMfvOVLBGlbGVZHl1S1hnhkiJeJgi6f3A7fpDeeFfQoKU8abVF5lk-Q-CPxffGEODjCtthaJ4LF5uIgmuiLqBRRyZSO2msTKECzo_NTc65HXL8E9LL2bB44Y7icQnZfzEmn8f1pQMek8N-EI9EKaHsxvG30I8q434hs15Cj090mQNFyv1JfTU_5v3xAY5lmA-AImuHIPTXF7FAivV3GvCHTtOspLw/http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences
Privacy Policy - 

Re: MVS modify command capture

[Peter Relson]

Ed Jaffe's post was along the lines of what I was thinking as the right 
approach:

-- define a console
-- issue the command
-- capture messages sent to that console 
-- do what you want
-- undefine the console 

Some started tasks might send their output to the console that started 
them rather than to the console that issued the modify command.
The latter is probably what they should do.

There's also the possibility of using a WTO exit to capture "everything", 
figure out which are of interest and do what you want (as long as it is 
allowed within the exit).

Peter Relson
z/OS Core Technology Design


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

Re: ZCX task monitoring, anyone?

[Sean Gleann]

OK, so the scrape_interval part of your answer is something I can quickly
understand and deal with.
I'll put that to one side for now because my interest is with Cadvisor and
how to control it.

To take the parallel example for Prometheus from the IBM red book, I have
to:
 1. create a 'prometheus.yml' file
 2. create a Dockerfile, which features a COPY command referring to that
'prometheus.yml' file
 3. do a 'docker build' of the Prometheus image
 4. then I can 'run' the image.
With subsequent 'runs' of Prometheus I can skip steps 1-3 as they have
already been done.
For Cadvisor, there is no 'build' to be done, thus no copying of a yml file
The only command I know of for Cadvisor is the 'run' command I detailed
earlier in this thread.
(If the Cadvisor image does not exist, then it is automatically downloaded
before being started.)
In conceptual terms, am I right in thinking that I'm downloading a
'program' that has already been prepared for execution?
If that is true, then the value of any control parameters appears to be
hard-coded within the program.
Given this, I'm not sure I have any control over the container manifest for
Cadvisor.

Regards
Sean

On Thu, 27 Aug 2020 at 10:15, Attila Fogarasi  wrote:

> Housekeeping interval is part of the container manifest as it governs
> normal operation, not just performance metric collection.  As such it is
> specified wherever you have your container manifest defined (for example, a
> .yaml file or by HTTP endpoint or HTTP server).   You can also use the
> command line "kubelet" tool.
> Scrape_interval is the value for how often Prometheus asks cAdvisor for
> data from the collection cache, thus it affects cpu used by cAdvisor to
> prepare and send this data to Prometheus.
> As for how Docker monitoring works, you are right that there is overlap in
> the open-source tools, but the hierarchy is cAdvisor collects the metrics
> and also does some aggregation and processing.  You can use just cAdvisor.
> Prometheus is a layer on top, getting metrics from cAdvisor and then
> provides both better quality reporting and also alerting (which cAdvisor
> does not).  The next layer is Grafana which is a generalized metric
> analytics and visualization tool (not just for Docker).  For larger scale
> more complex container environments you need all 3.
> In a z/OS context these 3 tools became integrated circa 30 years ago, but
> for Unix they are not.   Splitting the processing like this has both good
> and bad points (for example Grafana can run in a separate Docker container)
> but definitely burns more cpu (a lot more).   If not careful the
> measurement tooling can cost more than the application being measured, even
> though it is "free".
>
> On Thu, Aug 27, 2020 at 6:02 PM Sean Gleann  wrote:
>
> > Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
> > them.
> >
> > The start-up for Cadvisor that I'm using doesn't feature any pointer to a
> > parameter list, and despite much googling I don't see any mention of
> such a
> > thing. Everything keeps referring back to Prometheus and then on to
> Grafana
> > My Cadvisor start-up (taken directly from the IBM Red Book and slightly
> > modified to comply with local restrictions):
> > docker network create monitoring
> > docker run --name cadvisor -v /sys:/sys:ro -v
> > /var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d
> --network
> > monitoring ibmcom/cadvisor-s390x:0.33.0
> >
> > Perhaps I'm looking at things the wrong way, but my current understanding
> > is:
> > Cadvisor (and also Nodeexporter) collect various usage stats;
> > Prometheus then gathers that data and does some sort of pre-processing of
> > it (it doesn't tell Cadvisor to 'do something' - it just passively makes
> > use of the data that Cadvisor collects)
> > Grafana takes the data from Prometheus and uses it to generate various
> > graphs/tables/reports.
> >
> > My situation is that when I run Cadvisor on it's own - no other
> containers
> > at all - then it floods as many processors as I define in the zcx
> > start.json file.
> >
> > Whilst Cadvisor is running, I can go to the relevant web-page and I can
> see
> > that it is producing meters/charts, etc all on its own. Since that is the
> > case, what is the point of Grafana?
> >
> > I have a Prometheus.yml file that features the term 'scrape_interval'
> (but
> > not 'housekeeping'), but that file is for use by Prometheus, isn't it?
> How
> > does it affect the amount of work that Cadvisor is doing, since I haven't
> > even started that container yet?
> >
> > Regards
> > Sean
> >
> > On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi 
> wrote:
> >
> > > Check your values for housekeeping interval and scrape_interval.
> > > Recommended is 15s and 30s (which makes for a 60 second rate window).
> > > Small value for housekeeping interval will cause cAdvisor cpu usage to
> be
> > > high, while scrape_interval affects Prometheus cpu usage.  It is
> entirely
> > > possible to cause data 

Re: MVS modify command capture

[David Spiegel]

Hi Ed,
Do EMCS messages not go to SYSLOG?
If yes, please provide an example.

Regards,
David

On 2020-08-26 23:55, Ed Jaffe wrote:

On 8/26/2020 5:03 PM, Steve Beaver wrote:

The only reason I can think of a case where the syslog is way behind.


Syslog is not relevant here. This is an EMCS console.




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

Re: SDSF RCF (was: MVS modify command capture)

[Rob Scott]

Any product can dynamically add itself to the REXX host environment table to 
provide “ADDRESS foobar” style support, so I think that it is the requirement 
of the underlying product to document that fact (rather than TSO or z/OS Unix).

On re-reading the SDSF User Guide, the section on “Invoking SDSF” only mentions 
TSO and ISPF as I believe it is referring to the interactive interface and the 
things you can do on the panels (or screens).

I agree that this is misleading as there other ways of invoking SDSF to get 
data.

I will see if I can get the “Invoking SDSF” section in the user guide to be 
more explicit and point to the later chapters that describe REXX (and batch).

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, August 27, 2020 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF RCF (was: MVS modify command capture)

EXTERNAL EMAIL



On Wed, 26 Aug 2020 20:27:10 +, Seymour J Metz wrote:

>Well, here there's nothing to escalate; I've generally gotten good responses 
>from RCFs.
>
Submitted as below. Has anyone suggestions for additions?

Hello, MHVRCFs,

Neither z/OS Version 2 Release 4 TSO/E REXX Reference
IBM SA32-0972-40
nor z/OS Version 2 Release 4 Using REXX and z/OS UNIX System Services
IBM SA23-2283-40
mentions that the SDSF command environment ("ADDRESS SDSF")
is available under IRXJCL and Unix System Services. I have
used ADDRESS SDSF in both contexts. I suspect this function
is provided intentionally by IBM with intent to support it.
z/OS Version 2 Release 4 SDSF User's Guide IBM
SC27-9028-40
mentions only that it's available under TSO, not IRXJCL nor
UNIX System Services.

I find UNIX and IRXJCL mentioned somewhat obliquely in
http://www.redbooks.ibm.com/redbooks/pdfs/sg247419.pdf
... but a Redbook is not where most programmers would
seek such documentation.

The availability of "ADDRESS SDSF" under UNIX and IRXJCL
should be mentioned in a Reference manual.

More generally, should the availability of a command
environment be documented in a Rexx manual such as
SA32-0972-40 or SA23-2283-40, or in the manual describing
the commands such as SC27-9028-40? An incomplete list
such as in SA32-0972-40 or SC27-9028-40 is likely to
mislead programmers.

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 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

Re: ZCX task monitoring, anyone?

[Attila Fogarasi]

Housekeeping interval is part of the container manifest as it governs
normal operation, not just performance metric collection.  As such it is
specified wherever you have your container manifest defined (for example, a
.yaml file or by HTTP endpoint or HTTP server).   You can also use the
command line "kubelet" tool.
Scrape_interval is the value for how often Prometheus asks cAdvisor for
data from the collection cache, thus it affects cpu used by cAdvisor to
prepare and send this data to Prometheus.
As for how Docker monitoring works, you are right that there is overlap in
the open-source tools, but the hierarchy is cAdvisor collects the metrics
and also does some aggregation and processing.  You can use just cAdvisor.
Prometheus is a layer on top, getting metrics from cAdvisor and then
provides both better quality reporting and also alerting (which cAdvisor
does not).  The next layer is Grafana which is a generalized metric
analytics and visualization tool (not just for Docker).  For larger scale
more complex container environments you need all 3.
In a z/OS context these 3 tools became integrated circa 30 years ago, but
for Unix they are not.   Splitting the processing like this has both good
and bad points (for example Grafana can run in a separate Docker container)
but definitely burns more cpu (a lot more).   If not careful the
measurement tooling can cost more than the application being measured, even
though it is "free".

On Thu, Aug 27, 2020 at 6:02 PM Sean Gleann  wrote:

> Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
> them.
>
> The start-up for Cadvisor that I'm using doesn't feature any pointer to a
> parameter list, and despite much googling I don't see any mention of such a
> thing. Everything keeps referring back to Prometheus and then on to Grafana
> My Cadvisor start-up (taken directly from the IBM Red Book and slightly
> modified to comply with local restrictions):
> docker network create monitoring
> docker run --name cadvisor -v /sys:/sys:ro -v
> /var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d --network
> monitoring ibmcom/cadvisor-s390x:0.33.0
>
> Perhaps I'm looking at things the wrong way, but my current understanding
> is:
> Cadvisor (and also Nodeexporter) collect various usage stats;
> Prometheus then gathers that data and does some sort of pre-processing of
> it (it doesn't tell Cadvisor to 'do something' - it just passively makes
> use of the data that Cadvisor collects)
> Grafana takes the data from Prometheus and uses it to generate various
> graphs/tables/reports.
>
> My situation is that when I run Cadvisor on it's own - no other containers
> at all - then it floods as many processors as I define in the zcx
> start.json file.
>
> Whilst Cadvisor is running, I can go to the relevant web-page and I can see
> that it is producing meters/charts, etc all on its own. Since that is the
> case, what is the point of Grafana?
>
> I have a Prometheus.yml file that features the term 'scrape_interval' (but
> not 'housekeeping'), but that file is for use by Prometheus, isn't it? How
> does it affect the amount of work that Cadvisor is doing, since I haven't
> even started that container yet?
>
> Regards
> Sean
>
> On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi  wrote:
>
> > Check your values for housekeeping interval and scrape_interval.
> > Recommended is 15s and 30s (which makes for a 60 second rate window).
> > Small value for housekeeping interval will cause cAdvisor cpu usage to be
> > high, while scrape_interval affects Prometheus cpu usage.  It is entirely
> > possible to cause data collection to use 100% of the z/OS cpu -- remember
> > that on Unix systems the rule of thumb is 40% overhead for uncaptured cpu
> > time while z/OS is far more efficient and runs well under 10%.  You will
> > see this behaviour in zCX containers, it isn't going to measure the same
> as
> > z/OS workload.  The optimizations in Unix have the premise that cpu time
> is
> > low cost (as is memory), while z/OS considers cpu to be high cost and
> path
> > length worth saving.  Same for the subsystems in z/OS and performance
> > monitors.
> >
> > On Wed, Aug 26, 2020 at 11:43 PM Sean Gleann 
> > wrote:
> >
> > > Allan - "...count the beans differently...' Yes, I'm beginning to get
> > used
> > > to that concept. For instance, with the CPU Utilisation data that I
> > *have*
> > > been able to retrieve, the metric given is not 'CPU%', but 'Number of
> > > cores'. I'm having to do some rapid re-orienting to my way of thinking.
> > > As for the memory size, I've got "mem-gb" : 2 defined in my start.json
> > > file, but I've not seen any indication of paging load at all in my
> > testing.
> > >
> > > Michael - 5 zIIPs?   I wish!  Nope - these are all general-purpose
> > > processors.
> > > The z/OS system I'm using is a z/VM guest on a system run by an
> external
> > > supplier, so I'm not sure if defining zIIPs would actually achieve
> > anything
> > > (Is it possible 

Re: MVS modify command capture

[Rob Scott]

Chapter 5 of the SDSF User's Guide is entitled : "Using SDSF with the REXX 
Programming Language"

What improvements do you wish to see in the manual?

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, August 26, 2020 7:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS modify command capture

EXTERNAL EMAIL



I guess that it's time for an RCF; invoking SDSF in 
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc279028/$file/isfa600_v2r4.pdf
 only mentions the first two.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Rob 
Scott mailto:rsc...@rocketsoftware.com>>
Sent: Wednesday, August 26, 2020 11:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS modify command capture

SDSF has distinct environments that it natively supports on z/OS :


1. ISPF
2. TSO CPPL
3. Batch (and AFD)
4. REXX

The SDSF REXX interface will run where there is a valid REXX environment.

Note that the batch SDSF interface has been stabilised and we now encourage 
users to convert to SDSF REXX.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Seymour J Metz
Sent: Wednesday, August 26, 2020 3:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MVS modify command capture

EXTERNAL EMAIL



That code has to run under SDSF, which is a TSO command. I don't know whether 
SDSF will run under a TSO subset environment.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3>



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>
 on behalf of Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu>>
Sent: Wednesday, August 26, 2020 9:40 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: MVS modify command capture

On Wed, 26 Aug 2020 07:40:47 -0500, Roger Lowe wrote:
>>
>>Is there a way to capture a MODIFY command ?
>>
>You could try this bit of REXX and then invoke it via IKJEFT01 batch jcl -
>
Does that require TSO or would IRXJCL (or even UNIX mutatis mutandis) sufffice?

> /*REXX*/
> blah = ISFCALLS('ON')
> ISFCONS = "MY@CONS"
> ISFDELAY = "1"
> PARSE ARG input
> cmd.0=1
> cmd.1=input
> ADDRESS SDSF ISFSLASH "(cmd.)"
> IF (ISFULOG.0 > 0) THEN
> DO i=1 TO ISFULOG.0
> SAY ISFULOG.i
> END
> EXIT 0
>
>and then the jcl to use -
>
> //S1 EXEC PGM=IKJEFT01
>//SYSEXEC DD DISP=SHR,DSN=my.rexx.lib
>//SYSTSPRT DD SYSOUT=* <= change this to point to a dataset
>//SYSTSIN DD *
> %SDSFCMD D T

-- gil

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 
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: 

Re: ZCX task monitoring, anyone?

[Sean Gleann]

*sigh*. Oh, how I wish that various e-mail clients would quit re-formatting
stuff. My previous response here was so nice & neat & tidy before I hit
'Send'. Reading that response back via IBMMain makes me look like a
complete illiterate...

Sean

On Thu, 27 Aug 2020 at 09:01, Sean Gleann  wrote:

> Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
> them.
>
> The start-up for Cadvisor that I'm using doesn't feature any pointer to a
> parameter list, and despite much googling I don't see any mention of such a
> thing. Everything keeps referring back to Prometheus and then on to Grafana
> My Cadvisor start-up (taken directly from the IBM Red Book and slightly
> modified to comply with local restrictions):
> docker network create monitoring
> docker run --name cadvisor -v /sys:/sys:ro -v
> /var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d --network
> monitoring ibmcom/cadvisor-s390x:0.33.0
>
> Perhaps I'm looking at things the wrong way, but my current understanding
> is:
> Cadvisor (and also Nodeexporter) collect various usage stats;
> Prometheus then gathers that data and does some sort of pre-processing of
> it (it doesn't tell Cadvisor to 'do something' - it just passively makes
> use of the data that Cadvisor collects)
> Grafana takes the data from Prometheus and uses it to generate various
> graphs/tables/reports.
>
> My situation is that when I run Cadvisor on it's own - no other containers
> at all - then it floods as many processors as I define in the zcx
> start.json file.
>
> Whilst Cadvisor is running, I can go to the relevant web-page and I can
> see that it is producing meters/charts, etc all on its own. Since that is
> the case, what is the point of Grafana?
>
> I have a Prometheus.yml file that features the term 'scrape_interval' (but
> not 'housekeeping'), but that file is for use by Prometheus, isn't it? How
> does it affect the amount of work that Cadvisor is doing, since I haven't
> even started that container yet?
>
> Regards
> Sean
>
> On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi  wrote:
>
>> Check your values for housekeeping interval and scrape_interval.
>> Recommended is 15s and 30s (which makes for a 60 second rate window).
>> Small value for housekeeping interval will cause cAdvisor cpu usage to be
>> high, while scrape_interval affects Prometheus cpu usage.  It is entirely
>> possible to cause data collection to use 100% of the z/OS cpu -- remember
>> that on Unix systems the rule of thumb is 40% overhead for uncaptured cpu
>> time while z/OS is far more efficient and runs well under 10%.  You will
>> see this behaviour in zCX containers, it isn't going to measure the same
>> as
>> z/OS workload.  The optimizations in Unix have the premise that cpu time
>> is
>> low cost (as is memory), while z/OS considers cpu to be high cost and path
>> length worth saving.  Same for the subsystems in z/OS and performance
>> monitors.
>>
>> On Wed, Aug 26, 2020 at 11:43 PM Sean Gleann 
>> wrote:
>>
>> > Allan - "...count the beans differently...' Yes, I'm beginning to get
>> used
>> > to that concept. For instance, with the CPU Utilisation data that I
>> *have*
>> > been able to retrieve, the metric given is not 'CPU%', but 'Number of
>> > cores'. I'm having to do some rapid re-orienting to my way of thinking.
>> > As for the memory size, I've got "mem-gb" : 2 defined in my start.json
>> > file, but I've not seen any indication of paging load at all in my
>> testing.
>> >
>> > Michael - 5 zIIPs?   I wish!  Nope - these are all general-purpose
>> > processors.
>> > The z/OS system I'm using is a z/VM guest on a system run by an external
>> > supplier, so I'm not sure if defining zIIPs would actually achieve
>> anything
>> > (Is it possible to dedicate a zIIP engine to a specific z/VM guest?
>> That's
>> > a road I've not yet gone down).
>> > With regard to the WLM definitions, I followed the advice in the red
>> book
>> > and I'm reasonably certain I've got it right. Having said that,
>> cross-refer
>> > to a thread that I started earlier this week, titled "WLM Query"
>> > The response to that led to me defining a resource group to cap the
>> > started task to 10MSU, which resulted in a CPU% Util value of roughly
>> 5% -
>> > something I could be happy with.
>> > Under that cap, the started task ran, yes, but it ran like a
>> three-legged
>> > dog (my apologies to limb-count-challenged canines).
>> > Start-up of the task, from the START command to the "server is
>> > listening..." message took over an hour, and
>> > STOP-command-to-task-termination took approx. 30 minutes.
>> > (SSH-ing to the task was a bit of a joke, too. Responses to simple
>> commands
>> > like 'docker ps -a' could be seen 'painting' across the screen,
>> > character-by-character...)
>> > As a result, I've moved away from trying to limit the task for the time
>> > being. I'm concentrating on attempting to get cadvisor to be a bit less
>> > greedy.
>> >
>> > Regards
>> > Sean
>> >
>> > On 

Re: ZCX task monitoring, anyone?

[Sean Gleann]

Hi Attila - thanks for the pointers, but I'm not sure of how to act upon
them.

The start-up for Cadvisor that I'm using doesn't feature any pointer to a
parameter list, and despite much googling I don't see any mention of such a
thing. Everything keeps referring back to Prometheus and then on to Grafana
My Cadvisor start-up (taken directly from the IBM Red Book and slightly
modified to comply with local restrictions):
docker network create monitoring
docker run --name cadvisor -v /sys:/sys:ro -v
/var/lib/docker/:/var/lib/docker:ro -v /dev/disk:/dev/disk:ro -d --network
monitoring ibmcom/cadvisor-s390x:0.33.0

Perhaps I'm looking at things the wrong way, but my current understanding
is:
Cadvisor (and also Nodeexporter) collect various usage stats;
Prometheus then gathers that data and does some sort of pre-processing of
it (it doesn't tell Cadvisor to 'do something' - it just passively makes
use of the data that Cadvisor collects)
Grafana takes the data from Prometheus and uses it to generate various
graphs/tables/reports.

My situation is that when I run Cadvisor on it's own - no other containers
at all - then it floods as many processors as I define in the zcx
start.json file.

Whilst Cadvisor is running, I can go to the relevant web-page and I can see
that it is producing meters/charts, etc all on its own. Since that is the
case, what is the point of Grafana?

I have a Prometheus.yml file that features the term 'scrape_interval' (but
not 'housekeeping'), but that file is for use by Prometheus, isn't it? How
does it affect the amount of work that Cadvisor is doing, since I haven't
even started that container yet?

Regards
Sean

On Wed, 26 Aug 2020 at 23:05, Attila Fogarasi  wrote:

> Check your values for housekeeping interval and scrape_interval.
> Recommended is 15s and 30s (which makes for a 60 second rate window).
> Small value for housekeeping interval will cause cAdvisor cpu usage to be
> high, while scrape_interval affects Prometheus cpu usage.  It is entirely
> possible to cause data collection to use 100% of the z/OS cpu -- remember
> that on Unix systems the rule of thumb is 40% overhead for uncaptured cpu
> time while z/OS is far more efficient and runs well under 10%.  You will
> see this behaviour in zCX containers, it isn't going to measure the same as
> z/OS workload.  The optimizations in Unix have the premise that cpu time is
> low cost (as is memory), while z/OS considers cpu to be high cost and path
> length worth saving.  Same for the subsystems in z/OS and performance
> monitors.
>
> On Wed, Aug 26, 2020 at 11:43 PM Sean Gleann 
> wrote:
>
> > Allan - "...count the beans differently...' Yes, I'm beginning to get
> used
> > to that concept. For instance, with the CPU Utilisation data that I
> *have*
> > been able to retrieve, the metric given is not 'CPU%', but 'Number of
> > cores'. I'm having to do some rapid re-orienting to my way of thinking.
> > As for the memory size, I've got "mem-gb" : 2 defined in my start.json
> > file, but I've not seen any indication of paging load at all in my
> testing.
> >
> > Michael - 5 zIIPs?   I wish!  Nope - these are all general-purpose
> > processors.
> > The z/OS system I'm using is a z/VM guest on a system run by an external
> > supplier, so I'm not sure if defining zIIPs would actually achieve
> anything
> > (Is it possible to dedicate a zIIP engine to a specific z/VM guest?
> That's
> > a road I've not yet gone down).
> > With regard to the WLM definitions, I followed the advice in the red book
> > and I'm reasonably certain I've got it right. Having said that,
> cross-refer
> > to a thread that I started earlier this week, titled "WLM Query"
> > The response to that led to me defining a resource group to cap the
> > started task to 10MSU, which resulted in a CPU% Util value of roughly 5%
> -
> > something I could be happy with.
> > Under that cap, the started task ran, yes, but it ran like a three-legged
> > dog (my apologies to limb-count-challenged canines).
> > Start-up of the task, from the START command to the "server is
> > listening..." message took over an hour, and
> > STOP-command-to-task-termination took approx. 30 minutes.
> > (SSH-ing to the task was a bit of a joke, too. Responses to simple
> commands
> > like 'docker ps -a' could be seen 'painting' across the screen,
> > character-by-character...)
> > As a result, I've moved away from trying to limit the task for the time
> > being. I'm concentrating on attempting to get cadvisor to be a bit less
> > greedy.
> >
> > Regards
> > Sean
> >
> > On Wed, 26 Aug 2020 at 13:49, Michael Babcock 
> > wrote:
> >
> > > I can’t check my zCX out right now since my internet is down.
> > >
> > > You are running these on zIIP engines correct? Must be nice to have 5
> > > zIIPs!  And have the WLM parts in place?   Although it probably
> wouldn’t
> > > make much difference during startup/shutdown.
> > >
> > > On Wed, Aug 26, 2020 at 3:40 AM Sean Gleann 
> > wrote:
> > >
> > > > Can anyone offer