IBM Mainframe Forum

This might sound very vague, but I am trying to find the best coding practices in COBOL (for instance, speicifying the block size in the file definition (FD) using the BLOCK CONTAINS 0 statement), and SQL as well.

I have been doing some amount of reading regarding this, and am not able to gather much information.

I would like to know if anyone could help me by providing a few links with some best practices.

Any help would be appreciated!

This is a huge topic, don't expect any "pat" answers.

Do you have local standards for coding Cobol and SQL? You have to start there.

Hello,

One general way to consider "best coding practices" is that the code:

1. Works 100% of the time.
2. Uses only a reasonable amount of system resources.
3. Follows local standards.
4. Is easily maintainable.

For specifics about your system, suggest you talk with some senior who has a reputation for writing really good code.

Two that seem to be common where I've worked:

Line stuff up:


Instead of


and don't use "NOT" unless you have to, even if it means more lines of code:


A third rule is to not take anything personally. If you like doing something differently than the local standard, it doesn't mean you're wrong. Just do it like standards and get over it. I've seen more bad attitudes sprout from "Why don't they just..." thinking than from anything else.

Some of the coding rules I follow (created after developing as well as maintaining many programs over the last 37+ years of COBOL coding):

- Do not code block sizes in programs -- use BLOCK CONTAINS 0
- Veritcally align PIC and VALUE clauses
- Veritcally align code as Ed suggested
- Use scope terminators (END-IF, END-PERFORM, etc)
- Use file status codes for every file AND CHECK THEM IN YOUR PROGRAM
- Pick a scheme for paragraph names and stick with it
- Avoid tricky code (even if it is fun to write, a year later you'll have to rethink what the code was doing when maintenance is needed)
- Be consistent with variable names; if you abbreviate account as -ACCT then don't have -ACCT, -ACT, -ACCOUNT in your Data Division

Your goal should be code that works, first, and then is easily maintained, second. Some of the COBOL code at my site was last compiled in the 1980's (and at least one production program dates back to the 1970's).

Billy, I was looking for some statements that consume the resources heavily when used on large data ( Eg: a code accessing all the rows of a table that has about 10,000 rows). And yes, we do have some local standards for coding.

A few ways to avoid codes that are resource intensive are:
1- Avoiding the use of USAGE IS DISPLAY.
2- Avoiding sorts within the COBOL code, and if required providing the FASTSRT compiler option.

I am just trying to find more such ways to enhance code performace.

Dick, Ed and Robert, thanks for the help!

You have to be careful. Look at Dick's list. Whatever others think about 2, 3 and 4, we'd all agree on number 1.

I'd go 1, 3, 4, 2.

What I mean by that, is not doing anything "special" for performance (unless that is the specific task) but to do the sort of things you are talking about.

Unless it is your particular task, assigned to you, don't try anything "exotic" to "tune" your code. It's not necessary, unless it is necessary, when someone will give you that job.

As I say, it is a big area

If you use Binary or Indexes for subscripts and loop-control, packed-decimal for calculations, only define as numeric things that can be used in a calculation (and account-number can be PIC X, as you're never going to add it to anything). Then you will have a lot of "little things" going for your program which don't change the logic but do make it a little quicker.

Ooooohhhhh, you have a specific program in mind. That makes a bit of a difference.

First, please be certain that you are measuring the "gains" by measuring the entire new process. In other words, if you remove the COBOL sort, be sure to include the sort step when you step back and check to see how fast it's running now. I've seen a LOT of examples where the entire process got slower, but people still got awards for performance improvements.

Second, make sure you define your goal before you start. Are you reducing i/o, run time, cpu time...blah blah blah. That 10,000 row table lookup might be the best way to make the program run faster, but it could use more CPU time to accomplish it. However, if you change it to a VSAM file, you CPU could go down, but the program would run longer.

PS COBOL sorts aren't bad. I think if we run one here, it just calls DFSORT anyway.

Mmmm....

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.

Performance-wise, I'd be extremely surprised if taking a SORT out of a Cobol program slowed the overall processing down. I'd expect it to improve or, maybe, but unlikely, stay flat.

It also simplifies the program. Programmers don't tend to know what SORT does or how it works in the program. There is the possibility to get the program doing diverse things, do-some-stuff-with-unsorted, sort, do-some-stuff-with-sorted, which makes it more difficult to understand and maintain.

Used well, there is no "problem" with a SORT in a Cobol program. If used well, then the program would easily not miss it being removed and carried out externally.

You are not really looking for "best practices" in COBOL, you are looking for how to improve a program -- which is a totally different concept! If your site has a run-time analyzer such as Compuware's Strobe you first would run the tool on the program to determine if there are any problem statements. If there are no problem statements (say 10% or more of the run time is spent in a single statement or COBOL paragraph), then there's not much you're going to be able to do to improve the performance. If the program is I/O-bound (spending a lot of time doing reads and / or writes), look to moving the various files to different volumes using different channels for improvements -- this is an area where assistance from your site support group would be critical to making improvements.

If you don't have a run-time analyzer, then you're going to have to guess about improving performance, and my experience (over the last 20 years plus) has been that programmers are remarkably poor at guessing where their programs have performance issues.