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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
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)
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
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.
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
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.
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
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.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
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).
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
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!
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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).
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
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.
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.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
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.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
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.
Bill W., I know this is picking-nits (and I do apologize for that) but:
---- I coded --------
000037 A0000-MAINLINE.
000038 *****==============================================*****
000039 PERFORM A.
000040 *****==============================================*****
000041 GOBACK.
000042
000043 A SECTION.
000044 DISPLAY 'THIS IS THE A-SECTION'.
000045 A-EXIT.
000046 EXIT.
000047
000048 B-PARAGRAPH.
000049 DISPLAY 'THIS IS THE B-PARAGRAPH'.
000050 C SECTION.
000051 DISPLAY 'THIS IS THE C-SECTION'.
***** these are the DISPLAYs that came out of the above code
THIS IS THE A-SECTION
THIS IS THE B-PARAGRAPH
And for this reason -- (admittedly as an old-timer) I prefer Paragraphs with PERFORM-THRUs. I don't have to worry about some programmer sticking a PARAGRAPH between two PERFORMed SECTIONs
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
ridgewalker58 wrote:
Bill W., I know this is picking-nits (and I do apologize for that) but:
---- I coded --------
000037 A0000-MAINLINE.
000038 *****==============================================*****
000039 PERFORM A.
000040 *****==============================================*****
000041 GOBACK.
000042
000043 A SECTION.
000044 DISPLAY 'THIS IS THE A-SECTION'.
000045 A-EXIT.
000046 EXIT.
000047
000048 B-PARAGRAPH.
000049 DISPLAY 'THIS IS THE B-PARAGRAPH'.
000050 C SECTION.
000051 DISPLAY 'THIS IS THE C-SECTION'.
***** these are the DISPLAYs that came out of the above code
THIS IS THE A-SECTION
THIS IS THE B-PARAGRAPH
And for this reason -- (admittedly as an old-timer) I prefer Paragraphs with PERFORM-THRUs. I don't have to worry about some programmer sticking a PARAGRAPH between two PERFORMed SECTIONs
No problem. I'm picky as well. :-)
I missed mentioning the mixing of paragraphs and sections when one "camp" doesn't know that the other "camp" works differently.
What most don't realise is that "EXIT" does nothing. It is just a marker for the compiler. In the condensed listing, you can see there is stuff associated with the exit, but it is just where the compiler sticks some of the code which allows all possibilities to work. Without the exit paragraph (exit must be on its own) then the last instruction in the para/section just looks very long.
As with sticking a para uknowingly "inside" a section, so with the other examples. If someone were to stick a section inside a perform thru program, I'd say it was even worse.
"We" are old enough to know how each works. We each have our own personal preferences. I'm not aware of a "defeat all" argument for one, or the other. I don't get bent up about it, but have to admit to preferring sections.
I do my sections the way I do my perform thru's (if local standard). I'm a great believer in KISS. The more you know, the easier it is to KISS. I keep my perform thru's simple. I keep my sections simple. I use lots of performs from the paras/sections I perform, rather than bunging everything together in one way or another. I love the way the optimiser chops away the extraneous rubbish and makes the performs not much slower than a go to anyway, and orders of magnitude easier to cope with.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
ridgewalker58 wrote:
And for this reason -- (admittedly as an old-timer) I prefer Paragraphs with PERFORM-THRUs. I don't have to worry about some programmer sticking a PARAGRAPH between two PERFORMed SECTIONs
You can also avoid this by not using SECTIONS at all. If you code in paragraphs and never use GOTO you will never see a fall-through.
