Paul Gilmartin wrote: You have made good points, thanks.
>> 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? Uhm, with same or different sort input and/or output for all these concurrent jobs? AFAIK, COBOL has its own internal SORT functions, but if I want to sort something big or complex, I would terminate my COBOL program, let sort it with DFSORT or SyncSort and do same or other COBOL program to process the sorted data. If it is not too big or complex to sort, I can let COBOL call DFSORT and wait for sorted data to come back. >I would hope (wish) that DFSORT would supply optimum defaults. AFAIK, those defaults are the best DFSORT can offer, but of course, only you know if those defaults are working or not. >Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect that in the era >of oscillating merge it relied on EXCP. AFAIK, DFSORT has its own OCO access method(s) just like RACF has its own OCO way to access the RACF database. Just my 3 cents, not 2, because of tax/inflation and a terrible mother-in-law... ;-) Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
