I've had much success tuning DFSort (and SyncSort) with appropriate storage tuning parameters. There are many knobs to turn to provide whatever granularity is needed to resolve issues.
- Don Imbriale On Fri, Apr 18, 2014 at 1:31 PM, David Betten <bet...@us.ibm.com> wrote: > DFSORT does look at available resources before it "grabs whatever it can". > There are DFSORT installation defaults to control how much of the > available storage DFSORT will use but I agree the shipped defaults can > cause issues in some environments. We put a lot of guidance on these > installation defaults in our DFSORT Tuning Guide and in V2R1 we made some > changes to try and be a bit less agressive in how we allocate available > storage. > > > Have a nice day, > Dave Betten > DFSMS Performance Engineer > IBM Corporation > email: bet...@us.ibm.com > 1-301-240-3809 > DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ > > IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> wrote on > 04/18/2014 01:15:51 PM: > > > From: Elardus Engelbrecht <elardus.engelbre...@sita.co.za> > > To: IBM-MAIN@listserv.ua.edu, > > Date: 04/18/2014 01:16 PM > > Subject: Re: SORT ando MEMLIMIT best practice > > Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> > > > > Paul Gilmartin wrote: > > > > >R.S. wrote: > > >> If you specify absolutely nothing about MEMLIMIT anywhere, the > > system-provided default is 2G so obviously you can't go wrong with > > that in SMFPRMxx. > > > > >Right. IBM's provided defaults are always optimal. > > > > Agreed. But, as John Gilmore said, IBM's defaults are 'minimal > > troublesome' [ for 'most installations' <-- my own words ]. > > > > I usually find that these defaults are Ok and tailoring is reserved > > for those strange needs. Oh, my MEMLIMIT is NOLIMIT after several > > attempts to satisfy my DB2 needs and my z/OS Team handling of > > paging. I'm not using USI exit much these days. > > > > >o Hmmm... I'd think that any parameterization resulting in > > significant paging of I/O buffers is counterproductive. Is DFSORT > > aware of this in its design, and does it attempt to tailor its WSS > > to fit in real storage? > > > > Yes, I find that DFSORT looks what it can grab: memory, VIO, > > SORTWKxx and SORTIN parameters for storage usage. Then DFSORT looks > > at what size those SORT inputs are. At last, it tries to grab > > whatever it can get to start sorting at all. > > > > >o OTOH, paging I/O is reported to be very good. And 64-bit virtual > > is enough for most plausible data sets. How about eliminating > > SORTWKn data sets and performing the entire sort in virtual storage? > > But this approach must pay careful attention to LoR. > > > > Use SORTIN parameters to avoid SORTWKxx. Just don't code SORTWKnn in > > your JCL DD statements. But, I agree, be careful. > > > > For myself, I find using SORTWKnn, large REGION and large SORTIN > > parameters are 'better' for really big sort work. > > > > 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 > > > > ---------------------------------------------------------------------- > 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
