JCL Sort versus Application Program(COBOL) Sort.

[Anand Sharma]

Hi all,

I have mostly used JCL Sort. But when do we use a Program (COBOL or some other language) Sort? Can some one let me know the pluses and minues of JCL Sort and Program Sort? When to use which one? Is there some consideration on that? Please help.

[Robert Sample]

If the program is being written anyway, and the data is needed to be sorted in a particular sequence, you might want to use a COBOL SORT. However, there's not really a whole lot of difference these days in how the sort is done. You can sort only the necessary data through defining the SD in COBOL, but you can achieve similar results via the BUILD in a JCL SORT.

[William Collins]

Most of the internal sorts I've seen (using the SORT verb) in COBOL programs have been "afterthoughts". Programmer realises in the middle of coding that it woiuld ne convenient if the data were in order, so bangs in a complex use of SORT.

The program is effectively three jammed together. Pre-sort. Sort. Post-sort. But all mixed together. Avoid this. A simple SORT as the first thing with compiler option FASTSRT will not compilcate a program, and the larger the file the more benefits you may get. Problem is if the program part crashes, the SORT (part of the program now) has to run again. This has to be balanced against reductions in IO with the SORT'n'GO approach.

[Anuj Dhawan]

"Which one is better" - this has long been a question, perhaps, because it relates to efficiency.

The answer, actually - I believe, depends on how much data needs to be sorted, as I think, you're already aware that the internal sort is simply an invocation of the same SORT utility that a JCL initiates (external sort).

When you run an external sort the entire address space is dedicated to the sort process. This means that outside the sort program itself all of the storage is used for buffers for the sort strings. If the COBOL program has FASTSRT in effect, as William has pointed out, for the input and output data sets, then SORT reads and writes the data sets directly and there should be no difference. If the COBOL program does not have FASTSRT in effect, then the COBOL program reads and writes the data sets rather than SORT, whereas with a direct invocation of SORT, it reads and writes the data sets. This can make a difference since SORT's I/O and buffering is more efficient than COBOL's. Apparently, that only matters if a direct invocation of SORT can be used to do the same thing the COBOL program does. As I've said earlier, with an internal sort less storage is available to the sort since the application program and any other elements (DB2 MQ etc.) take up some of that storage.

If the amount of data is small the difference in available storage is insignificant. The sort will run just as fast. In fact doing all the work in a program can be more efficient because the JCL allocation/deallocation steps are done once instead of once for the sort step and once for the program step.

Said all that, I personally do not prefer an internal sort. As the biggest disadvantage, I find, of using an COBOL sort is you need to recompile the program whenever the sort sequence changes. Maintenance is also an issue for programs with internal sorts. External sorts on the other hand are easy to understand and maintain.You can use all the utility aspects(INREC ,OUTREC, SUM...).we now have DFSORT's ICETOOL which offers a wide variety of options and utilities that makes the programmer's life easier.You don't have to worry about the LRECL,BLKSIZES.

I somewhere read this and thought it's worth sharing here -

"One day you'll get a job and your boss will tell you to sort something. Ask him if he wants an internal sort or an external sort. If he says 'internal' but doesn't give a reason, that means he doesn't know how to do external. If he says 'external' but doesn't give a reason, that means he doesn't know how to do internal. If he says one or the other and gives a reason (such as easier to code, will run faster etc.) then he understands both. If he says 'you're the programmer, do it however seems better to you' then you can bet your paycheck that he doesn't understand either of them.

[Anand Sharma]

Thank you so much for sucha detailed explnaion. I've some to carry with me now.

Once again thankyou!