Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Best Practices for Enterprise COBOL
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Susan Talbot

New User


Joined: 17 Dec 2010
Posts: 36
Location: KY

PostPosted: Tue Jul 19, 2011 9:45 pm    Post subject: Best Practices for Enterprise COBOL
Reply with quote

Is there any documents about best practices for Enterprise COBOL development?
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Tue Jul 19, 2011 9:59 pm    Post subject:
Reply with quote

Have you tried Google?

There are some tips in the manuals.

Colleagues? Local standards? Or are you looking for more than that?

For 10% of the value of the bet, post the question :-)
Back to top
View user's profile Send private message
Susan Talbot

New User


Joined: 17 Dec 2010
Posts: 36
Location: KY

PostPosted: Tue Jul 19, 2011 11:31 pm    Post subject:
Reply with quote

I have someone telling me how they think I should code and I don't always agree. For example they are saying never use variable files, use Perform Thru, etc. Not everything they suggest is bad, but I would rather heat it from IBM.
I tried Google, never found anything good. With Java, there are a lot of best practices.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Tue Jul 19, 2011 11:54 pm    Post subject:
Reply with quote

It is best to try to stick to local standards/practices.

Some things fall outside of this.

Not using variable files? To me, nuts. Try to nicely ask why not? They might have a good reason, but I'd more expect some nonsense.

The perform thing would come under how it is done at your site. Stick to that way, unless it is really a shocking mess, then you have to find an approach to address it. I'm no big fan of perform thru. I prefer to perform a section, and the section then perform the things which are logical for that element of work.

Section 1 of the 4.2 programmers guide has some stuff, not necessarily all good :-) Some of IBM's advice does not always strike me as the best.

I always explain why if I'm suggesting something particular to someone about coding. I try to be "always" anyway. If they can't explain why, by which I mean in a way you understand and make sense of, then it may well not be good advice.

Ask six of us here, you might get seven ideas about best practice as a whole. "Best practice" is usually do it the way the site does it, and try to fix the way they do the shoddy bits.

I don't know if this helps you at all.

If you post more examples of things you are unsure of, I suspect you'll find willingness to chew them over.
Back to top
View user's profile Send private message
ridgewalker58

New User


Joined: 26 Sep 2008
Posts: 51
Location: New York

PostPosted: Wed Jul 20, 2011 12:10 am    Post subject:
Reply with quote

Blanketly stating no variable files is saying that you should choose making things simpler to code for and IGNORE the DISK space you may be wasting. If you data comes on separate records with different record types (i.e. Employee demographic data, Employee financial data) then you could potentially be wasting lots of space and processing time to have each of these two different record types with the same size.
Especially if you are WALMART with its great numbers of employees.

First, program to your company's standards, then program to the type of data, the volume of data and the amount of processing that you will have to perform on the data.

I am and OLD consultant -- So I make my living from people who follow one "STANDARD PRACTICE" and cause inefficiencies that require more people to work on their systems (than are really necessary)
Back to top
View user's profile Send private message
Susan Talbot

New User


Joined: 17 Dec 2010
Posts: 36
Location: KY

PostPosted: Wed Jul 20, 2011 12:12 am    Post subject:
Reply with quote

He said he just 'preferred' them. I think he doesn't know how to code for them
Here are a couple I am questioning
• All performs of paragraphs must include a Thru ####-EXIT.
• Coding paragraphs must begin with a 4 digit number followed by a meaningful and descriptive name
• Paragraph numbers must be kept in numerical sequence for 0000- to 9999-

I know 4 digits numbers have been used in cobol since forever, but I hate them. I hate being halfway through coding and needing to add a paragraph and then having to try to renumber and fix all the compile errors where i forgot to change the number

it goes on to say what should be in the 8000s like I/O routines and 9000s for errors. seems quite restrictive
Back to top
View user's profile Send private message
ridgewalker58

New User


Joined: 26 Sep 2008
Posts: 51
Location: New York

PostPosted: Wed Jul 20, 2011 12:25 am    Post subject:
Reply with quote

personally, i like 4 digit numbers 1000- 1100- 1200- 2000- 3000- Try to SPREAD the originally-coded numbers as far apart (numerically) as possible. YES I also hate "renumbering" -- but I also hate people who get lazy and start different number -out-of-sequence- without making the effort to renumber paragraphs.

Sounds like the requirement for 8000- for I/O and 9000- for ERRORS is designed so that ANYONE who picks up your program for maintenance -- will know where to look

The following is how I CODE -- EXITs.
--BUT-- --BUT-- all of what you have put down for me is
---A MATTER OF STYLE--- and you are being told to
follow someone else's STYLE

I code PERFORM PARA-A THRU PARA-A-EXIT

PARA-A.
MOVE FIELD-A TO FIELD-B.
IF FIELD-C = 'Y'
GO TO PARA-A-EXIT
MOVE FIELD-C TO FIELD-D.
PARA-A-EXIT.
Back to top
View user's profile Send private message
valyk

Active User


Joined: 16 Apr 2008
Posts: 104
Location: South Carolina

PostPosted: Wed Jul 20, 2011 12:28 am    Post subject:
Reply with quote

Susan Talbot wrote:
He said he just 'preferred' them. I think he doesn't know how to code for them
Here are a couple I am questioning
• All performs of paragraphs must include a Thru ####-EXIT.
• Coding paragraphs must begin with a 4 digit number followed by a meaningful and descriptive name
• Paragraph numbers must be kept in numerical sequence for 0000- to 9999-

I know 4 digits numbers have been used in cobol since forever, but I hate them. I hate being halfway through coding and needing to add a paragraph and then having to try to renumber and fix all the compile errors where i forgot to change the number

it goes on to say what should be in the 8000s like I/O routines and 9000s for errors. seems quite restrictive


This sounds like the ridiculous coding standards that my shop put in place for Application Programmers. They implemented code 'checkers' in the change management product to look for things like this. They also have 'walkthroughs', but spend more time about how your code looks then how it actually functions. You could have the cleanest code in the world but cause a storage violation every other line and they could care less.
Back to top
View user's profile Send private message
ridgewalker58

New User


Joined: 26 Sep 2008
Posts: 51
Location: New York

PostPosted: Wed Jul 20, 2011 12:28 am    Post subject:
Reply with quote

The paragraph numbering system places everything in sequence and makes it easier for find PERFORMed paragrphs which are 3 or 4 pages away from where you are looking
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Wed Jul 20, 2011 1:05 am    Post subject: Reply to: Best Practices?
Reply with quote

If you dig into this topic, you can find some alternatives to the basic 4-digit numbers. http://www.ibmmainframes.com/viewtopic.php?t=54170

It is about being able to find things more easily, originally on physical listings. You can arrange them to highlight the structure of the code, as you'll see. To know not only where it is going, but where it came from (except for general purpose stuff).

I think some system helps over no system, but there are, to my thinking, better than the plain nnnn.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Wed Jul 20, 2011 1:15 am    Post subject:
Reply with quote

The term "Best Practice" implies a broad consensus of expert opinion. You will find that such a thing is rare in the Cobol world.

I have had discussions with people who passionately defended their non-structured spaghetti code on the (dubious) grounds that it was "efficient". I have also heard from defenders of the generally-hated ALTER statement, and those who think that PERFORM was invented by pointy-headed managers incapable of understanding complex logic.

To cite a less radical example, I normally concur with Bill Woodger's views on this forum, but I totally disagree with his preference for performing paragraphs within SECTIONS. (Sorry Bill).
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Wed Jul 20, 2011 1:28 am    Post subject: Reply to: Best Practices?
Reply with quote

No problem Don :-)

If the site uses perform thru, that is what I'd use. If sections, then sections. Personally, I prefer sections.

Either method can be used badly, as with all (I originally wrote "most", but I've seen some stuff) things. I think the "best practice" here is to not abuse either of them, whichever is in use. No go to's into sections or the middle of thru's, no performing paragraphs from sections or in the middle of thru's, that sort of stuff.

dbz has a nice workaround for the "go to exit" in a section which is then copied without the go to being changed.
Back to top
View user's profile Send private message
mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Wed Jul 20, 2011 4:29 am    Post subject:
Reply with quote

Dumb question: so by 'variable file' you all mean variable length file ie VB?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Wed Jul 20, 2011 5:00 am    Post subject:
Reply with quote

mtaylor wrote:
Dumb question: so by 'variable file' you all mean variable length file ie VB?


Maybe a good question. It is what I've been assuming, but...

Perhaps with Occurs Depending On?

Or is it for a file which has fixed-length records, yet has been defined in program and JCL as variable? To me that would be "bad practice", although from a number of topics it may well be becoming common.

Otherwise, I have no clue as to why not use it.

Sometimes stuff is "handed down" without the people who are the latest to pass it on knowing "why". Always worth checking on, as the "ancestor" may have known what they were talking about.

Some things get dated, though. Occurs Depending On is much easier now, since they've changed the compiler.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7909
Location: Bellevue, IA

PostPosted: Wed Jul 20, 2011 5:21 am    Post subject:
Reply with quote

I think the "best practices" are changing as the machines get faster, too. It used to be totally taboo to use a PERFORM in a CICS program, and back these many years ago that made sense. Nowadays, with the machine speed increases, a PERFORM in a CICS program doesn't have nearly the impact. My recommendation is develop some practices that make sense to you, alter them for the individual site when necessary, but as long as you're consistent in coding that's probably more important than any externally defined rules. Several years from now, when you have to go back to that program to change it, having some standard practices makes it easier to pick up the logic thread again. And don't think about performance issues when picking your standards until you actually have some indication that you have a performance issue!
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Wed Jul 20, 2011 5:49 am    Post subject:
Reply with quote

don.leahy wrote:
[...] ...but I totally disagree with [Bill Woodger's] preference for performing paragraphs within SECTIONS.[...].


I just re-read your post Don.

If I ever wrote that, it was a typo or poorly explained by me. I'll have to hunt back and correct myself.

Code:

perform a thru a-exit

a.
some stuff
.
a-exit.
    exit
    .


Code:
perform a

a section.
some stuff
.
a-exit.
    exit
    .


These are the same.

What I avoid with perform thru, is this

Code:
perform a thru e-exit.

or "worse"

perform a thru e

a.
some stuff
.
d.
some more stuff
.
e.
a last bit of stuff
e-exit.
    exit
    .


With paragraphs being performed, if go to is used (I avoid) you need "thru".

With sections, you don't.

With the second example, it is too easy for someone to stick an extra paragraph in the middle, without "realising" that there is a perform thru. The flipside being that you have to check before inserting a new para in a particular place.

With sections, it is not impossible to screw them up in the such a manner, but it is much more difficult (you can only really code a new section without realising you haven't reached the end of the current section yet).

I don't perform section thru section. I don't perform a para which is within a section. I don't go to a section. I don't go to a para within a section from outside the section.

I don't perform para thru. I don't perform a para that is part of an existing perform thru (if I need to use it, I make the existing perform a new para, and my code perform the same para). I don't go to a para that is in a perform thru from outside the perform thru. If there are "genuine" paras in the perform thru, I would only "go to" paras that are with the range of the para/exit containing the go to.

So, for my "style", sections are better. dbz's point is to make use of the "implicit" qualification you get with a section. You can have non-unique paras as long as they are in different sections. So, the "exit para" can be named identically in all sections. Such that, when someone copies the section for another purpose and changes everything but the "to go exit", the code will still work, and the correct exit will be chosen by the compiler. It would screw-up my desire for the cross-reference to be in order, but does deal with a problem cleanly.

It is an interesting option for dealing with slackers.

The problem at the root of all this is that the compiler allows you to do every rubbishy thing that someone can think of when it comes to paras (and sections, for that matter). You can perform them, go to then, "fall through" into them, perform inside whilst outer perform is active, go to out of them, exit the program from within (this was useful to me once) and much, much, more.

The ability to do all this stuff (even if not used) means that there is tons of code generated by the compiler in and around paras and sections to deal with all circumstances. If you optimise it, you get a sudden shrinkage of that code, as the optimiser knows that you are using the stuff cleanly.

Hence my idea for the NOSH1T compiler option (search the Cobol forum if interested).
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Wed Jul 20, 2011 6:27 am    Post subject:
Reply with quote

Robert Sample wrote:
I think the "best practices" are changing as the machines get faster, too. It used to be totally taboo to use a PERFORM in a CICS program, and back these many years ago that made sense. Nowadays, with the machine speed increases, a PERFORM in a CICS program doesn't have nearly the impact. My recommendation is develop some practices that make sense to you, alter them for the individual site when necessary, but as long as you're consistent in coding that's probably more important than any externally defined rules. Several years from now, when you have to go back to that program to change it, having some standard practices makes it easier to pick up the logic thread again. [...]


Spot on. I'll dig up who coined it on this forum later, but when you are writing a program you are writing it for someone else. Later on, someone is going to have to pick it up for maintenance/support. That someone might even be you. Help them out all you can.

Quote:
[...] And don't think about performance issues when picking your standards until you actually have some indication that you have a performance issue!


I knew we'd have to discuss your sig sometime, Robert :-)

There are lots of little things I do, just as a matter of course. Maybe they used to make things faster, and maybe today they don't, but I'd still regard them as good practice.

Only define as numeric something which is going to be used for calculation, along the way - exception can be dates, which can reasonably be packed for reduced mass storage (not so necessary these days). Just because it has "number" in it's name, doesn't mean it should be defined as PIC 9. PIC X uses less code than PIC 9.

COMP-3 as an odd-number of digits in total. Avoids extra code generated to ensure the left-most half-byte is zero if not used.

COMP as 4 or 8 digits. The compiler will use the same amout of space for 1, 2, 3 and 5, 6, 7 digits respectively and avoids any generated code to insist on the length. 9 digit binary is a pig for calculations, as the compiler will convert it to a double-word and use double-word instructions, then convert it back. It is more efficient to use 10 digits - can't say I've ever had to, though, but the "maximum" digits I use in a binary word is 8, for this reason.

Subscripts, loop-control counts, binary, as the compiler prefers them that way.

For calculations, comp-3.

Comp-3, comp always signed. Display signed unless illogical.

Etc. Little things like this.

Actual "optimisation" is then a different thing. It is changing the code, almost certainly so that it becomes less obvious, to do things in an "abnormal" way, with two benefits. Getting the right answer. Getting it faster. The downsides being reduced maintainability and increased initial coding time.

There is also "tuning", which is taking (someone else's) rubbish code (files, JCL, databases, whatever) and doing it properly. This is when things are originally done in a way which is just plain dumb. Usually much bigger run-time benefits than actual optimisation, plus get the right answer, plus reduced maintenance.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Wed Jul 20, 2011 7:25 am    Post subject:
Reply with quote

This could be a long thread.

Personally, I never need EXIT paragraphs because I never ever use GOTO. I code all of my stuff in paragraphs, to me SECTIONs are unnecessary.

However, I do code in the real world, so I will use SECTIONs and (much more rarely) GOTOs when working on a program already infected with them. icon_wink.gif

One other "Best Practice" that seems to have gained some widespread acceptance is the use of "minimum period" coding style in the Procedure Division. That's a trend that I fully support.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Jul 20, 2011 9:36 am    Post subject:
Reply with quote

Hello,

Yup, things are now "acceptable" that only a few years ago would not have been. Largely due to the speed/size of the new cpu's and dasd. Slop that would not have once run now does with relative ease. And largely because very few new people have anything even approachng proper training. . .

When coding and having to renumber this indicates very little planning when determining the structure of the code. On some of the older systems where i've helped fight fires, the performed paragraph might be 50 or 100 pages away - these monsters were/are in the 13 - 17k lines of code and few comment blocks, so basically all of the lines are "real code". At several sites, i worked with their people to implement code to properly number all of the paragraphs - just to give new support people a chance to actually work on code they had not seen before. . . If a program has only 100 lines, 4-digit paragraph prefixes are less important - but should still be used if this is the standard. One simple way to enforce this standard is to make part of the promotion process verify the sequence of the paragraph names and that they have a proper prefix.

As has been mentioned, one needs to follow the local standards. When one changes organizations, different standards are quite likely to be used and these must be followed at the new organization. Not following the standards is often a valid reason for termination.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7228

PostPosted: Wed Jul 20, 2011 1:34 pm    Post subject: Reply to: Best Practices?
Reply with quote

Quote:
[...] I hate being halfway through coding and needing to add a paragraph and then having to try to renumber [...]


As Dick has pointed out, this is a planning problem. It is maybe good that it irks you, as you should do your planning better so that this does not arise.

I have to say, with the editor, it really is "no biggie" renumbering things.

Quote:
[...] it goes on to say what should be in the 8000s like I/O routines and 9000s for errors. seems quite restrictive [...]


The idea here is that when anyone reads the four digits, they know that 8xxx is i/o, 9xxx is error, without having to flip over the listing to locate and check. At a different site, it might well be a different convention. Adhere, it helps others.

If you are thinking "how should I number this one" you are also thinking "where is the best place to do this". If you are thinking "where is the best place to do this" the "numbering" comes naturally.

Quote:
[...] meaningful and descriptive name [...]


If anyone only wants to do one thing only to make their programs better, I think this is what I'd suggest. OK, I haven't thought about it so deeply, but it is such a bugbear of mine that it comes easily to the surface. In real code (not examples to make points like in these fora :-) ) things like SUBA, PARA-ONE, LOOPING-PARA, get me going in all the wrong ways.

Where you have such stuff, you have to look, and dig, to understand what is going on. OK, the more experience you have, the easier this is. But I'm always thinking of the maintenance guy, with less experience then I, trying to deal with code produced in such a way - at 3am, or with two days to change 20 modules, whatever.

You have 30 characters in Cobol (if you use more, no biggie, as long as the 30 are unique). I describe the data. Describe the paras/sections. The better you make your names, the fewer times you'll find, after three hours, that SUBC should have been SUBD, when, if genuinely named, it would not have even been sensible to write the incorrect line in the first place.

This can be applied whatever the local standard (I suppose I stand waiting to be told otherwise).

Alongside this is my other pet hate. Comments. Comments? Comments.

The better you make your names, the less need you'll have of comments. Your program tends towards being "self-documented". Then you only comment when genuinely needed - something to explain. Then, don't just repeat what the code says, but put the business/technical reason, in English. Someone picking up the code later then knows what you were trying to do, as well as what you actually did. The first can be checked to specs/business docs, the second to whether it works or not.

Just "having" comments is a waste of time. No-one ever updates the comments (OK Don, some do). If there are lots of comments in the program, I don't read any (OK, within reason) because they are so unlikely to genuinely add something to the understanding. Even been sent up the wrong track by a comment? What's the point?

Quote:
With Java, there are a lot of best practices.


And I bet most of them are different. Or just copied from somewhere else, without actual knowledge. Java is a bit newer than Cobol, and emerges in an environment where instantaneous international communication is not even noticed, it is so usual.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts COBOL Version 6.1 Virendra Shambharkar COBOL Programming 5 Tue Nov 01, 2016 11:24 am
No new posts Cobol list of programs being called biswajit.dattagupta COBOL Programming 5 Tue Nov 01, 2016 2:10 am
No new posts Can sending 5 MB data between cobol p... Kevin Vaz CICS 12 Tue Oct 18, 2016 4:50 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us