Is anybody running into IBM programmers who do not like . .

, ,
1

natural programs with an internal SORT? The IBM’ers are so used to SORTing a file in a JCL deck before inputting it into a program.

Doing a Natural program internal SORT is not that bad from what I can understand. Just a couple of extra lines of code within the program, change the END-READ to END-SORT, and you get the sorted results that you wanted. You can then remove the IBM SORT code in the JCL deck.

What about this?

2

Why would someone not like one of the nice features of a programming language? Perhaps no one ever explained to them how Natural’s SORT works.

steve

3

COBOL programmers, both IBM and non-IBM, have used embedded sorts for many years, so Natural supports them, too. They are not unique to Natural.

Both external sort (separate SORT utility step) and internal sort (SORT verb) have their pros and cons - too many to list in this thread.

My recommendation:

  • external sorts for all batch processes

  • internal sorts to process internal arrays within on-line applications

4

Personally, I replace external SORT steps with Natural SORTs whenever I can:

  • it simplifies the JCL JOB stream immensely. A typical scenario:
    • Natural extract step - write to work file
    • external sort
    • Natural report step - reads output of sort
      all of which can be done from one Natural program and thus one JCL step. If the sort can be done incore, all of the I/O between steps is eliminated, improving performance. If not, it’s performance is still at least as good as an external step
  • it is easier to understand and thus maintain:
    SORT …BY PERSONNEL-ID DESC
    is much easier to understand than
    SORT 1,10,CH,D
    …and that’s just for one field.

In batch, Natural can (and should) invoke the same sort routine as is used by the external sort step - check out the SORT settings. Performance for the Natural SORT will then equal (or even slightly better) an external sort step since it is using the same sorting function but with a bit less I/O involved.

When processing really large external files, I will use the external sort step for selecting small subsets or using esoteric features such as SUM and TALLY - again, only on really big files (and the definition of “really big files” gets bigger all the time!), and only if it is going to be used a lot. Otherwise, a Natural program is easier to read and maintain.

5

Old IBM analysts are RESISTANT to change, and this little subject is a typical example.

I have tried to sell them on a Natural SORT, but they pull out the old “this is not in line with shop standards. Do it our way, or get on the highway!”

6

The first question asked in this thread was:

Is anybody running into IBM programmers who do not like natural programs with an internal SORT?

The reason no one responded yes is clearly that all such “IBM programmers” are at your shop. javascript:emoticon(‘:D’)

steve

7

LOL! I am an ex-IBMer, and I would agree with “Pete”, that we are resistant to change. Coming from a Lotus/Domino development group (with no experience in PL/1 and JCL), I find learning Natural programming to be challenging, but not impossible.

I also agree with a comment in another post, that there isn’t as many online tutorials, examples or forums for Natural, as there are with other languages (JavaScript, Java, ASP.NET, etc…) As an IBMer, where funding for education was tight, I have relied mostly on the internet and book stores for my education. I have the blue, “Natural Developers Handbook” from WH&O, but that is a reference, not a developer’s guide. I will continue to read through the online documentation at Software AG and employ knowledge sharing techniques (on-line and co-workers).

8

Maybe bad performance. Some years ago we used an UNIX-Sort for sorting ~500,000 records.

Export into Workfile + unix-sort + Import of the sorted workfile was much faster than using Natural’s sort.