/MartinPacker
From: Shane Ginnane ibm-m...@tpg.com.au
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 27/05/2015 04:30
Subject:Re: Slow storage creep in SYSTEM.SYSSTC
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote
] On Behalf
Of Gibney, David Allen,Jr
Sent: Tuesday, May 26, 2015 6:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Slow storage creep in SYSTEM.SYSSTC
We just had a zPCR study. There weren't any real surprises, but the Workload
CS Samples for my production Lpar shows a very slow creep
@LISTSERV.UA.EDU] On Behalf
Of Greg Shirey
Sent: 27 May, 2015 15:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC
Sure. The sysprogs wanted to try and be sure they could get into the system in
times of stress. We run a single LPAR on a machine with two processors, so
CICS
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC
Greg Shirey wrote:
We put the systems programmers' TSO sessions there, for instance.
TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm?
Just curious, if you don't mind please
-MAIN@LISTSERV.UA.EDU] On Behalf
Of Gibney, David Allen,Jr
Sent: 27 May, 2015 1:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Slow storage creep in SYSTEM.SYSSTC
We just had a zPCR study. There weren't any real surprises, but the Workload
CS Samples for my production Lpar shows a very slow creep
(er).
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gibney, David Allen,Jr
Sent: 27 May, 2015 1:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Slow storage creep in SYSTEM.SYSSTC
We just had a zPCR study. There weren't any real
On Wed, 27 May 2015 13:51:23 +, Vernooij, CP wrote:
It is very tempting for sysprogs to give themselves absolute performance, just
because they can, not because they need it.
True 'nuff.
As I don't live in any site, I try to placate the troops. When I need to get in
and fix things, I get
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Martin Packer
Sent: 27 May, 2015 15:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC
I wouldn't use a command but rather proper regular timestamped information
- to get the behaviour. That would be 72-3 for suitably-coded report
Greg Shirey wrote:
Sure. The sysprogs wanted to try and be sure they could get into the system
in times of stress. We run a single LPAR on a machine with two processors, so
CICS (our loved one) in a loop can monopolize one and leave the other
struggling to service the remaining workloads.
Greg Shirey wrote:
Just a note - perhaps you haven't at your shop, but you can add to the SYSSTC
service class.
Good suggestion.
We put the systems programmers' TSO sessions there, for instance.
TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm?
Just curious, if you don't mind
, May 26, 2015 8:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC
On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote:
... I neither have nor really can control what falls into SYSSTC. It's all
z/OS.
You can, and probably should at least look at some
On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote:
... I neither have nor really can control what falls into SYSSTC. It's all
z/OS.
You can, and probably should at least look at some of your heavy hitters.
Just tossing it out here for thought on identifying the guilty software?
Grab a
We just had a zPCR study. There weren't any real surprises, but the Workload
CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC
workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor
really can control what falls into SYSSTC. It's all z/OS.
I
13 matches
Mail list logo
