Anne, Another item about paging is that if a task has pages sent to the page dataset, that page is not freed until the task ends.
So, if a batch job has storage pushed to the page datasets, these pages are freed when the job ends. However, if DB2 or CICS (typically large storage users) have some storage pushed to the page datasets, those pages are not freed until DB2 or CICS is recycled. This could be an IPL or just a bounce of the task. The pages may have been brought back into the system after your sort ended - but they stay allocated on the page datasets. This helps later on - when another large sort comes in. If a page hasn't changed, then it doesn't need to be rewritten to the page dataset and the 'page out' request is much faster. So, you may be able to ease the burden on the paging subsystem by bouncing some non-essential, large storage tasks. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Adams, Anne (DTI) Sent: Friday, March 01, 2013 7:24 AM To: [email protected] Subject: Re: DFSORT Weirdness The LPAR has 14GB of memory and the six page data sets have (yikes!) five different sizes (1000, 1000, 1500, 2000, 2500, and 3000 cylinders). Apparently the statement, we didn't change anything, really meant, we didn't change anything that should affect you. Anne R. Adams DTI, Systems Engineering State of Delaware -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Vernooij, CP - SPLXM Sent: Friday, March 01, 2013 2:17 AM To: [email protected] Subject: Re: DFSORT Weirdness Anne, Just for the picture: how much memory do you have in your LPAR and what is the total size of the page datasets.? Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Adams, Anne (DTI) Sent: Thursday, February 28, 2013 18:29 To: [email protected] Subject: Re: DFSORT Weirdness Ok - this is EXACTLY what we're seeing now. The one issue is that when the page data sets fill up, they never get emptied and we end up having to add new ones. What do people do? We can't IPL every week or go on adding page datasets indefinitely. Anne R. Adams DTI, Systems Engineering (302) 298 - 3196 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Vernooij, CP - SPLXM Sent: Thursday, February 28, 2013 10:59 AM To: [email protected] Subject: Re: DFSORT Weirdness I have seen DB2 utilities with large sorts (reorgs of partitioned table spaces, which does a lot in parallel), that consumed 6 - 8 GB memory of the 16GB in the LPAR. Nobody was really harmed by it, only you could see RMS paging out heavily old stuff to make room for the utilty. On these moments, you should have a page configuration ready for these page outs. There was no heavy page ins, so performance was not harmed. This is real memory management of modern, large machines, which should not be undervalued (correct English?) Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Elardus Engelbrecht Sent: Thursday, February 28, 2013 16:51 To: [email protected] Subject: Re: DFSORT Weirdness Kees Vernooij wrote: >Again: the fact that DFsort acts differently on the new device could be caused >by CFW. With CFW dfsort could decide to use SORTWKs, without CFW DFSORT could >decide that this is too slow and use memory. Very true! Will the DFSORT gurus answer on your statement this or next month? ;-D I'm watching this thread, because my own DFSORT + ICETOOL jobs are grabbing and eating everything - CPU, Inits, Memory and DASD space, name it, like there is no tomorrow... ;-D Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
