Page 1 of 2

Tips for cobol performance tuning

PostPosted: Mon Dec 05, 2011 12:04 pm
by hvats83
Please provide some general techniques used to optimize a cobol code

Re: Tips for cobol program performance tuning

PostPosted: Mon Dec 05, 2011 1:07 pm
by BillyBoyo
This is such a general question, I don't believe there can be much of an answer to it. Either

  1. Don't bother because you'll probably not notice the difference
  2. Identify the part(s) of the program performing badly and fix the logic
  3. There are always three things

If you can give a fuller explanation of what you are looking for, there might be better answers.

Re: Tips for cobol program performance tuning

PostPosted: Mon Dec 05, 2011 1:12 pm
by Anuj Dhawan
Start from here: https://www-304.ibm.com/support/docview ... wg27001475" onclick="window.open(this.href);return false;

And here: COBOL Performance Tuning Tips

Re: Tips for cobol program performance tuning

PostPosted: Mon Dec 05, 2011 2:44 pm
by BillyBoyo
I'll restate my points:

  1. If your code is well-written with regard to implementing the requirement, then you will not notice much difference once the code is "tuned"
  2. If your code is badly-written (but still producing the correct output) write the code better to continue producing the correct output
  3. Hi Akatsukami!

If you there is something which requires real tuning, it is probably not a task for a beginner (except as an exercise, I suppose).

You have to judge the amount of time spent on the tuning/testing against the gain (which you have to fully understand the terms of). Most of the recommendations in the document for which Anuj has provided a link are for CPU-usage reduction. If you task is I/O-bound, it won't help much.

The biggest jump in reduction of CPU (after fixing any bad ways to do something, ie the "badly-written" above) will be to specify the compiler option OPTimise. The biggest jump in reduction of I/O (after fixing any bad ways to do something, ie the "badly-written" above) will likely be in the definition of the datasets/JCL.

Don't go off on your own and "tune" a program from the above document, unless it is an entirely learning-related task.

Re: Tips for cobol program performance tuning

PostPosted: Mon Dec 05, 2011 5:43 pm
by Robert Sample
First and foremost, unless there is some reason to think the code is not performing well, DO NOT OPTIMIZE IT!

Second, if you don't know the difference between I/O-bound and CPU-bound programs, there's no point in you attempting to optimize anything.

Third, with the level of optimization the compiler does these days, unless you change the algorithm in some way, there's little you can do that will materially affect the program's running. So unless you've got a mandate to pull the program apart and put it back together, optimization is not a solution.

Re: Tips for cobol program performance tuning

PostPosted: Mon Dec 05, 2011 9:34 pm
by Ed Goodman
#1: Get a definition of "tuning"
What are you trying to reduce? Is it CPU time, is it run time, is it EXCP counts?

#2: Find a way to measure the factors produced by answering #1

#3: Run a set of measurements over a long time, say several months, to see which programs are actually using a lot of (items from #1)

#4: Then, and only then, start figuring out how to improve the performance of those programs identified in #3.

Re: Tips for cobol program performance tuning

PostPosted: Mon Dec 05, 2011 11:25 pm
by dick scherrer
Hello,

I believe that what many want to call "tuning" is really based on extremely poor design and is beyond tuning. . .

The way to improve the performance of these "resource hogs" is to redesign the process (usually quite unattractive).

Re: Tips for cobol performance tuning

PostPosted: Mon Sep 09, 2019 4:42 pm
by Elakkiya
advertising deleted
Tip#1
If you are accessing ESDS VSAM file, then in COBOL do you know
that the SELECT clause has something different about it!!
For ESDS,
SELECT FILE ASSIGN TO AS-DDNAME
Yes, the names should be prefixed with AS-.
If you are not doing that then an S213 ABEND might occur when
attempting to open a data set.

TIP # 2
When writing a COBOL program that is to be used as a CICS application program, do not use the
compiler option DYNAM.
COBOL
MERGE statement can have an OUTPUT PROCEDURE but not an INPUT PROCEDURE !!

Tip# 3
Do you know how COBOL Compiler finds a dataset as a VSAM dataset?
When the ORGANIZATION clause is coded for a file, the COBOL compiler interprets it as a VSAM dataset. Hence, the ORGANIZATION clause should not be coded with a non-VSAM dataset.

TIP # 4
Do you know using an odd number of digits for PACKED DECIMAL (COMP-3) is 5% to 20% faster than using an even number of digits !!

TIP # 5
Performance considerations for indexes vs subscripts:
using COMP to address a table is 30% slower than using indexes!
using COMP-3 to address a table is 300% slower than using indexes !!
using DISPLAY data items to address a table is 450% slower than using indexes !!!
(source: Cobol performance tuning manual)

TIP # 6
Rule of the THUMB:
For a table with less than 50 entries ==> go for SEARCH ( Sequential Search)
greater than 50 entries ==> go for SEARCH ALL ( Binary Search)

TIP # 7
Using OPEN OUTPUT to load a VSAM file will significantly improve the performance of your
program. Using OPEN I-O or OPEN EXTEND will have a negative impact on your program’s
performance.

TIP # 8
Avoid repetitive uses of the INITIALIZE statement.
INITIALIZE once and move it to a second like-sized 01 level, then move the second 01 level to the first to initialize the fields.

TIP # 9
For KSDS or RRDS, when DELETE statement is used, the file must be
opened in I-O Mode.

TIP # 10
Performance Tuning
Taking constant expressions out of a loop speeds up a program with no ill effects.
Example
Move zero to the total.
Perform varying I from 1 by 1 until I > 100
Compute total = total + item (i) * discount
End-perform
Remove multiply from the loop
Move zero to total
Perform varying I from 1 by 1 until I > 100
Compute total = total + item (i)
End-perform
Compute total = total * discount

TIP # 11
Sometimes my initialization doesn’t work when I use INITIALIZE verb? Is there anything that I should take care of?
When we use INITIALIZE verb to initialize group verbs, group elements which are FILLERs will not be initialized!

TIP # 12
I am using an internal sort in my COBOL Program. Is there any way to test the return code of sort operation?
The return-code or completion code is stored in a SORT-RETURN special register.
If SORT-RETURN = 0 (successful completion of SORT/MERGE)
If SORT-RETURN = 16 (Unsuccessful completion of SORT/MERGE)


TIP # 13
In general, it is an advantage to use COMP for numeric data and COMP-3 for decimal data.

TIP # 14
Here is one better way of INITIALIZATION of a record or group item.
INITIALIZE WS-RECORD
REPLACING ALPHANUMERIC DATA BY SPACES
NUMERIC DATA BY ZEROES.
advertising deleted

Re: Tips for cobol performance tuning

PostPosted: Mon Sep 09, 2019 10:50 pm
by sergeyken
Elakkiya wrote:TIP # 4
Do you know using an odd number of digits for PACKED DECIMAL (COMP-3) is 5% to 20% faster than using an even number of digits !!

This tip seems more to be a bullshit.

Both odd-, and even-number of digits Packed decimals:
1) use the same space in memory,
2) use the same machine instructions for ANY calculation

The only difference is, even-number digits is stored in the same field in memory, but one extra decimal 0-digits is added in the unused half-byte.

There is absolutely no reason to make any performance difference.

Furthermore, performance difference related to CPU operations, if any, can affect 0.0000000001% to 0.1% of overall performance issues, caused mainly by senseless algorithmic approach, and/or by wrong organization or required I/O operations.

Re: Tips for cobol performance tuning

PostPosted: Tue Sep 10, 2019 6:14 pm
by Terry Heinze
Is resurrecting an 8-year old topic a record? :o