> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Paul Gilmartin > Sent: Monday, October 02, 2017 12:24 PM > To: [email protected] > Subject: Re: Sort Question > > On 2017-10-02, at 09:29, Farley, Peter x23353 wrote: > > > With respect to the REGION size, remember that SORT (both IBM and its > > competitors) is most efficient the more memory you can let him have. I > > have found this especially true for COBOL-based SORT's. > > > But does this contend adversely with concurrent jobs?
IMHO it is the job of the Capacity and Performance team to tell the application programming teams when application jobs are contending for memory and causing paging, especially if it causes SLA's to be missed or near-missed. > > Consider using a region of at least 500M for large-volume sorts, and be > > sure to tell SORT he can use (most of) it via the SORT parameters. The > > more memory he has available the fewer SORTWK's and SORTWK I/O's he will > > need to use. > > > REGION=0K? Only if allowed by IEFUSI. Many large shops do not allow it except with special dispensation and approval, specifically because of the issue you raised above about memory contention. > > Also "buffer up" all of your high-volume input files with high BUFNO (QSAM) > > or AMP='BUFND=XXXX,BUFNI=YYYY,RMODE31=ALL' (VSAM) parameters (as > > appropriate). Consider using SUBSYS=BLSR or SMB parameters for high-volume > > VSAM inputs as well. > > > I would hope (wish) that DFSORT would supply optimum defaults. But can an > application discern in OPEN exit whether the options were supplied in JCL or > as OS defaults? > > Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in the > era of oscillating merge it relied on EXCP. Of course SORT uses his own EXCP (or OCO media manager interfaces) where possible, as it is far more efficient than QSAM. I was referring to the OP's original COBOL source for this SORT question. My reply concerned application-read input files, not directly-read-by-SORT files. For JCL sorts I always let SORT decide how to optimize his files, but COBOL SORT's act as E15 and/or E35 exits, so COBOL I/O can and often is being used for those I/O's, whether directly for the file to be sorted or a multiplicity of inputs used to construct the SORT input and output records. > > Memory is (relatively) inexpensive, so use it to your advantage. Your > > SLA's will appreciate it. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
