I don't wish to start a SORT war. :)
Syncsort has the GDSM STC which, as I understand it, keeps a history of
sort performance/requirments and helps Syncsort choose resource options. I
actually have no idea how effective it is for us or others,
Does DFSORT have a similar sort history function?
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of David Betten
> Sent: Friday, April 18, 2014 10:31 AM
> To: [email protected]
> Subject: Re: SORT ando MEMLIMIT best practice
>
> 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: [email protected]
> 1-301-240-3809
> DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/
>
> IBM Mainframe Discussion List <[email protected]> wrote on
> 04/18/2014 01:15:51 PM:
>
> > From: Elardus Engelbrecht <[email protected]>
> > To: [email protected],
> > Date: 04/18/2014 01:16 PM
> > Subject: Re: SORT ando MEMLIMIT best practice Sent by: IBM Mainframe
> > Discussion List <[email protected]>
> >
> > 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 [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
