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?
> 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? > 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. > Memory is (relatively) inexpensive, so use it to your advantage. Your SLA's > will appreciate it. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
