Coding best practices.

Post anything related to mainframes (IBM & UNISYS) if not fit in any of the above categories

Re: Coding best practices.

Postby dick scherrer » Sun Mar 25, 2012 1:44 am


It is true that the Cobol SORT just uses the installed sort product (DFSORT, SYNCSORT, Whatever's-left-SORT). However, generally, the SORT is going to run faster outside the Cobol program, and won't run slower.

Except with Compiler option FASTSRT (which I know works with DFSORT) and when it can be used, Cobol is doing the I/O. One thing, among many, that SORT is extremely good at is I/O.

Gotta beg to differ a bit. . .

Some time ago "we" (several different clients) did a bunch of "performance testing" comparing the internal sort (COBOL SORT statement) versus the external sort (invoked via jcl). Keep in mind that the external sort typically takes 3 steps (one to prepare the data to be sorted, the sort, and the process to use the sorted data) and step initiation/termination is rather expensive. For "small" to "medium" volumes, the internal sort performed as well as or better than the external sort. For "massive" amounts of data the external sort performed better - both in elapsed time and resourcfes used.

Unless something has been changed in the interface between COBOL and the sort product, the sort product handled all of the sorting i/o. The COBOL code had to read the input but once the data to be sorted was RELEASED to the sort, the sort took over. In my opinion the internal sort should Never use both the USING and GIVING options. This just wastes resources and is largely where the internal sort got a bad name years ago. USING and GIVING in the same program most often says that the developer is really lazy or is unwilling to learn better.
Hope this helps,
User avatar
dick scherrer
Global moderator
Posts: 6268
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 93 times

Re: Coding best practices.

Postby steve-myers » Sun Mar 25, 2012 6:29 am

Just to add to Mr. Scherrer's comments. When the system sort id called from an Assembler program there are 4 I/O options -
  • Sort performs the SORTIN/SORTOUT I/O
  • An E15 "exit" performs an equivalent to SORTIN I/O, and sort performs the SORTOUT I/O.
  • Sort performs the SORTIN I/O, and an E35 "exit" performs the equivalent of the SORTOUT I/O.
  • An E15 "exit" performs the SORTIN I/O, and an E35 "exit" performs the equivalent of the SORTOUT I/O.
Arguably there are more options, though they are variations on the other options: SORT is called using the JCL interface, but E15 or E35 "exits" are used for SORTIN or SORTOUT I/O.

"Efficiency" is a matter of debate. As Mr. Scherrer correctly points out, much of the apparent "efficiency" of sort's I/O can be lost when there is a program in front of the sort to prepare the SORTIN data, or there is a program after the sort to process the SORTOUT data.

By definition, sort will operate less "efficiently" when it is called from a program: sort will have less storage to work with, and this can affect its performance.
Global moderator
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times


Return to All other Mainframe Topics


  • Related topics
    Last post