Re: Slow storage creep in SYSTEM.SYSSTC
Thanks for all the suggestions. I'll look for time to try some of them :) Wish I could just send a ticket Shane, is is fairly nice out there right now. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Shane Ginnane > Sent: Tuesday, 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 of your heavy hitters. > > >Just tossing it out here for thought on identifying the guilty software? > > Grab a couple of (system) dumps a couple of weeks apart. Under IPCS run the > VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of > what you'll get. You may be able to see from a quick eyeball where it's going. > You can run a getmain/freemain trace, but you really don't want to go there. > Running GTF for weeks, then trying to process the output just ain't funny. > > All else fails, flick me a return business class air ticket, and I'll come > have a > look. Washington can't be too bad this time of year ;-) > > Shane ... > (all the above presumes you have the DIAGxx member set up already) > > -- > 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: Slow storage creep in SYSTEM.SYSSTC
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 my userid reset. If the ops can't get in and reset me, there are bigger problems. Seen that too of course Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
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. We didn't even bother with >experimenting with a TSOHOT service class - we felt like we had enough service >classes defined already. Thanks. Those loved CICS can get your system with two CPUs for dinner leaving you only with little crumbs to sit with... Your setup seemed realistic to me, thanks for telling. Much appreciated. Sorry, that I can't really contribute to this creeepy thread... ;-) I'll creep out of this thread for now... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Partly true, we have the same setup, but only for the 'standby userid'. It is very tempting for sysprogs to give themselves absolute performance, just because they can, not because they need it. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@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 (our loved one) in a loop can monopolize one and leave the other struggling to service the remaining workloads. We didn't even bother with experimenting with a TSOHOT service class - we felt like we had enough service classes defined already. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, May 27, 2015 8:07 AM 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Still you are looking for the one task that has the creep and therefor you must go down to the details of each individual task. By displaying which tasks run in SYSSTC, you can limit the number of tasks to monitor. Kees. -Original Message- From: IBM Mainframe Discussion List [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 classes. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: "Vernooij, CP (ITOPT1) - KLM" To: IBM-MAIN@LISTSERV.UA.EDU Date: 27/05/2015 14:15 Subject: Re: Slow storage creep in SYSTEM.SYSSTC Sent by:IBM Mainframe Discussion List There are some sidepaths take from this thread. Yes, you can add workload to SYSSTC, and you should have done so in the past according to recommendations. But this is not the point. Some task in SYSSTC has the creep. You can display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC in the display. Then you know which tasks to monitor. In CMF I can start a VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM report weekly and you must be able to find the 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 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 recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Lu
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 (our loved one) in a loop can monopolize one and leave the other struggling to service the remaining workloads. We didn't even bother with experimenting with a TSOHOT service class - we felt like we had enough service classes defined already. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, May 27, 2015 8:07 AM 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 classes. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: "Vernooij, CP (ITOPT1) - KLM" To: IBM-MAIN@LISTSERV.UA.EDU Date: 27/05/2015 14:15 Subject: Re: Slow storage creep in SYSTEM.SYSSTC Sent by:IBM Mainframe Discussion List There are some sidepaths take from this thread. Yes, you can add workload to SYSSTC, and you should have done so in the past according to recommendations. But this is not the point. Some task in SYSSTC has the creep. You can display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC in the display. Then you know which tasks to monitor. In CMF I can start a VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM report weekly and you must be able to find the 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 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 recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
There are some sidepaths take from this thread. Yes, you can add workload to SYSSTC, and you should have done so in the past according to recommendations. But this is not the point. Some task in SYSSTC has the creep. You can display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC in the display. Then you know which tasks to monitor. In CMF I can start a VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM report weekly and you must be able to find the 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 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 recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
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 please. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
Just a note - perhaps you haven't at your shop, but you can add to the SYSSTC service class. We put the systems programmers' TSO sessions there, for instance. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 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 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 recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow storage creep in SYSTEM.SYSSTC
In SYSTEM Service Class (for several customers) I think I'm seeing Master Scheduler being said to acquire more storage service over time. Not sure if this is what the OP meant by SYSSTC or not. (Probably not). In my case I suspect this is an anchor point for something Common or Shared above the Bar. Instrumentation I'm using is SMF 30 Interval (2,3) records. And I agree you can control what goes into SYSSTC and can define Report Classes to "narrow the doubt" if you don't have SMF 30(2,3) to work with. Actually for NON-SWAPPABLE address spaces a Report Class would be much more accurate for REAL storage usage. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Shane Ginnane 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 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 couple of (system) dumps a couple of weeks apart. Under IPCS run the VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of what you'll get. You may be able to see from a quick eyeball where it's going. You can run a getmain/freemain trace, but you really don't want to go there. Running GTF for weeks, then trying to process the output just ain't funny. All else fails, flick me a return business class air ticket, and I'll come have a look. Washington can't be too bad this time of year ;-) Shane ... (all the above presumes you have the DIAGxx member set up already) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 of your heavy hitters. >Just tossing it out here for thought on identifying the guilty software? Grab a couple of (system) dumps a couple of weeks apart. Under IPCS run the VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of what you'll get. You may be able to see from a quick eyeball where it's going. You can run a getmain/freemain trace, but you really don't want to go there. Running GTF for weeks, then trying to process the output just ain't funny. All else fails, flick me a return business class air ticket, and I'll come have a look. Washington can't be too bad this time of year ;-) Shane ... (all the above presumes you have the DIAGxx member set up already) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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 recently stopped the practice of monthly IPLs and am a little concerned. The growth rate is slow and I have ample head room. Just tossing it out here for thought on identifying the guilty software? Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
