Tips for cobol performance tuning



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Tips for cobol performance tuning

Postby hvats83 » Mon Dec 05, 2011 12:04 pm

Please provide some general techniques used to optimize a cobol code
hvats83
 
Posts: 18
Joined: Mon Dec 05, 2011 11:57 am
Has thanked: 1 time
Been thanked: 0 time

Re: Tips for cobol performance tuning

 

Re: Tips for cobol program performance tuning

Postby BillyBoyo » Mon Dec 05, 2011 1:07 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Tips for cobol program performance tuning

Postby Anuj Dhawan » Mon Dec 05, 2011 1:12 pm

Start from here: https://www-304.ibm.com/support/docview ... wg27001475" onclick="window.open(this.href);return false;

And here: COBOL Performance Tuning Tips
Anuj
Anuj Dhawan
 
Posts: 274
Joined: Mon Feb 25, 2008 3:53 am
Location: Mumbai, India
Has thanked: 6 times
Been thanked: 4 times

Re: Tips for cobol program performance tuning

Postby BillyBoyo » Mon Dec 05, 2011 2:44 pm

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.

These users thanked the author BillyBoyo for the post:
sergeyken (Mon Sep 09, 2019 10:38 pm)
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Tips for cobol program performance tuning

Postby Robert Sample » Mon Dec 05, 2011 5:43 pm

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.

These users thanked the author Robert Sample for the post:
sergeyken (Mon Sep 09, 2019 10:38 pm)
Robert Sample
Global moderator
 
Posts: 3620
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 266 times

Re: Tips for cobol program performance tuning

Postby Ed Goodman » Mon Dec 05, 2011 9:34 pm

#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.
Ed Goodman
 
Posts: 342
Joined: Thu Feb 24, 2011 12:05 am
Has thanked: 3 times
Been thanked: 17 times

Re: Tips for cobol program performance tuning

Postby dick scherrer » Mon Dec 05, 2011 11:25 pm

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).
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6269
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 93 times

Re: Tips for cobol performance tuning

Postby Elakkiya » Mon Sep 09, 2019 4:42 pm

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
Elakkiya
 
Posts: 2
Joined: Fri Aug 30, 2019 2:22 pm
Has thanked: 0 time
Been thanked: 1 time

Re: Tips for cobol performance tuning

Postby sergeyken » Mon Sep 09, 2019 10:50 pm

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.
sergeyken
 
Posts: 28
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 2 times
Been thanked: 5 times

Re: Tips for cobol performance tuning

Postby Terry Heinze » Tue Sep 10, 2019 6:14 pm

Is resurrecting an 8-year old topic a record? :o
.... Terry
Terry Heinze
 
Posts: 224
Joined: Wed Dec 04, 2013 11:08 pm
Location: Richfield, MN, USA
Has thanked: 11 times
Been thanked: 11 times

Next

Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post