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
