On 2014-04-18, at 03:48, R.S. wrote: > W dniu 2014-04-18 01:25, Ed Jaffe pisze: >> On 4/4/2014 12:47 PM, 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.
> Well, > My issue (problem?) is I have MEMLIMIT coded, but it's much more than default > 2G. And I noticed that some DFSORT jobs consume considerable amounts of > memory causing paging. > From the other hand I don't want to be stingy, so I'm looking for some > recommendations. > 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? 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. o What are the consequences of allocating SORTWKn to VIO? Many years ago (no longer), I knew the Cooley-Tukey fast Fourier transform algorithm well enough that I could code it from memory. At one point it makes a pass that toucnes the first location in each page in sequence; then the second location in each page; then the third; ... . This is brutal if WSS doesn't fit in real storage. Has anyone optimized FFT to optimize LoR, perhaps rearranging the data on each pass, perhaps even employing PS data sets rather than virual storage? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
