Improving Cobol Program Performance

There are various methods of improving the efficiency of your code from the way you code your program to the compiler options you choose. Some of these techniques will not make any major difference to speed unless you are processing high volumes of data and/or code is going to be executed millions of times for each run. The points presented below are guidelines only - there may be better ways of speeding things up - if you are worried about performance, it is always a good idea to discuss it with your local systems programmer.

1) Arithmetic. Some arithmetical calculations take longer than others. Multiplication and division take longer than adding or subtracting. So instead of, say multiplying a number by 2 , try adding the number to itself. If you want to make a number negative, you could subtract it from 0, instead of multiplying it by -1. Check all arithmetic to see if there is a more efficient way of doing it

2) Order of comparisons. The way you do comparisons on an IF or EVALUATE statement can affect performance. If you have multiple OR conditions on your IF statement try and make sure that the condition most likely to be true is first in the list. This means that the program will not have to check as many conditions before finding a 'true' one.

Here's an example to illustrate this. In the example, we are checking a VSAM status code. The most likely value is 00 (Executed without any errors).

We could code:

IF WS-STATUS = '97' OR '96' OR '95' OR '00'

DISPLAY WS-STATUS.

The program would first check is WS-STATUS = '97', then it would check is WS-STATUS = '96' then it would check is WS-STATUS = '95' and finally it would check is WS-STATUS = '00', which would be true so the DISPLAY would be executed. That would be four checks before the 'true' condition was found.

If we code:

IF WS-STATUS = '00' OR '97' OR '96' OR '97'

DISPLAY WS-STATUS.

then the program would check is WS-STATUS = '00'first, which is true so the DISPLAY would be executed, with just one check.

Conversely if you have multiple AND conditions on your IF statement try and make sure that the condition least likely to be true is first in the list. This means that the program will bomb out of checking conditions as early as possible.

3) Watch those compiler options. Some compiler options can result in longer running times. For example SSR, which checks for subscripts going out of range actually adds extra code to your program to check subscripts. SSR would be acceptable in a test environment, but may not be appropriate in the production environment.

4) Sorting. If at all possible avoid doing a sort within a COBOL program. COBOL sorts are very inefficient. If you must do a sort in a COBOL program, specifying the FASTSRT compiler option may speed up the sorting process.

5) Numbers.

a) How you define numeric fields can have an impact on performance. If you are using a field for arithmetic or as a subscript and the field has 8 or fewer digits it is quite often best to define it as a binary number (COMP-1) that is signed. This is because binary numbers can be manipulated much faster. If the field has between 8 and 15 digits then it is often best to define it as a Packed decimal number (COMP-3) with an odd number of digits and signed especially if the number is to be used with USAGE DISPLAY items. If the number has more than 18 digits then decimal arithmetic is always used by the compiler. For more information on this check out the appropriate COBOL Application Programming Guide. Use signed numbers wherever possible. COBOL does all arithmetic with signed numbers, so if you use unsigned numbers COBOL has to add code to remove signs.

b) Rounding numbers can often take longer than the calculation so try to avoid rounding numbers.

6) CALLs to other programs. When calling a subprogram with USING try to specify as few parameters as possible. Each parameter passed requires an individual BLL cell to be allocated in the called program and may require additional registers to be used.

7) PERFORMs. If you do a 'PERFORM paragraph' the compiler may convert this into up to six machine instructions. This is because the compiler must establish where it is to jump to and save the address of the instruction to jump back to at the end of the performed paragraph. PERFORMs with VARYING will require many more machine instructions. This will probably only be a problem if the code is executed millions of times. You should weigh up the pros and cons of maintainability with speed. It might be better to opt for writing the program in Assembler if the speed of execution is going to be a problem.