Coding best practices.



Post anything related to mainframes (IBM & UNISYS) if not fit in any of the above categories

Coding best practices.

Postby swetha489 » Wed Mar 21, 2012 2:26 pm

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!
swetha489
 
Posts: 10
Joined: Wed Mar 14, 2012 4:16 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Coding best practices.

 

Re: Coding best practices.

Postby BillyBoyo » Wed Mar 21, 2012 3:30 pm

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

Re: Coding best practices.

Postby dick scherrer » Thu Mar 22, 2012 10:11 am

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

Re: Coding best practices.

Postby Ed Goodman » Thu Mar 22, 2012 7:09 pm

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

Line stuff up:
MOVE ZEROES TO WSS-SWITCHES.                   
MOVE WSP-GCU149J-PARM-RCPT  TO GA03INDQ-VALUE   
MOVE 'D'                    TO GA03PT2C-CMD1   
MOVE 'ADC'                  TO GA03PT2C-VALUE2 
                               GA03PT2C-VALUE4 
MOVE '*'                    TO GA03PT2C-RPAREN 
                               GA03PT2C-RPAREN3
MOVE '+'                    TO GA03PT2C-RPAREN2
MOVE '0'                    TO GA03PT2C-VALUE   
MOVE HIGH-VALUES            TO GA03PT2C-VALUE3.


Instead of
MOVE ZEROES TO WSS-SWITCHES.                   
MOVE WSP-GCU149J-PARM-RCPT  TO GA03INDQ-VALUE   
MOVE 'D'  TO GA03PT2C-CMD1   
MOVE 'ADC'  TO GA03PT2C-VALUE2 
                               GA03PT2C-VALUE4 
MOVE '*'   TO GA03PT2C-RPAREN 
                               GA03PT2C-RPAREN3
MOVE '+'   TO GA03PT2C-RPAREN2
MOVE '0'    TO GA03PT2C-VALUE   
MOVE HIGH-VALUES TO GA03PT2C-VALUE3.


and don't use "NOT" unless you have to, even if it means more lines of code:
IF WGPC05P0-STATUS-CODE = SPACE       
    CONTINUE                         
ELSE                                 
    SET WSS-ERROR-FOUND     TO TRUE   
    MOVE 006 TO WST-ES-NEW-NUM       
    MOVE 'BAD READ FOR GS05CSLD'     
      TO WST-ES-NEW-MSG               
    PERFORM 41500-STACK-ERRORS       
       THRU 41500-EXIT               
END-IF.                               


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

Re: Coding best practices.

Postby Robert Sample » Thu Mar 22, 2012 8:10 pm

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).
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 222 times

Re: Coding best practices.

Postby swetha489 » Fri Mar 23, 2012 3:22 pm

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!
swetha489
 
Posts: 10
Joined: Wed Mar 14, 2012 4:16 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Coding best practices.

Postby BillyBoyo » Fri Mar 23, 2012 3:37 pm

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

Re: Coding best practices.

Postby Ed Goodman » Fri Mar 23, 2012 7:57 pm

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

Re: Coding best practices.

Postby BillyBoyo » Fri Mar 23, 2012 8:27 pm

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

Re: Coding best practices.

Postby Robert Sample » Fri Mar 23, 2012 11:33 pm

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.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 222 times

Next

Return to All other Mainframe Topics

 


  • Related topics
    Replies
    Views
    Last post