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
 

 

COBOL code with GO TOs
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
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Thu Apr 14, 2011 7:42 pm    Post subject: COBOL code with GO TOs
Reply with quote

GO TO's

Rather than sticking something on the end of some random topic, why not discuss, rationally. Then have a hissy-fit later if you don't get your way :-)

Let's say I said that:

It is OK to have experienced guys use GO TO, but if you let the novices at it they will (ab)use it and cause a mess.

You don't get a structured program just by using more flags than a battleship.

Performs generate a lot of code, and I need performance (sic, sorry).
I want to write code that is easy to maintain.

There are reasons to avoid using GO TO, and reasons to use it. The trick is to know what the reasons are.

I maintain programs, and all I get to see is programs that are more difficult to understand beacause they use GOTO/Perform (delete as applicable) badly.

go to code-after-list

code-after-list.

So, anyone want to contribute a reasoned argument for/against one/the other or whatever.

If it is not reasoned, I get to throw the hissy-fit (my thread, my etiquette).

Regards,

Bill W.
Back to top
View user's profile Send private message

GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1278
Location: Belgium

PostPosted: Thu Apr 14, 2011 8:19 pm    Post subject:
Reply with quote

Argument 1:
Quote:
It is OK to have experienced guys use GO TO, but if you let the novices at it they will (ab)use it and cause a mess.

says it all.
In Cobol where a life cycle of a program can easily be 15 years : You don't write code for yourself. You write code for the person that has to maintain the program after you.
So you try to make up standards with the least possibility of "a mess".

Argument 2:
Based on my experience, in well-structured programs , both with and without GO TOs :
Coding errors with GO TOs give runtime errors
Coding errors with Performs give compile errors
I personally prefer compile errors.

"And that's all I have to say about that" Forrest Gump
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu Apr 14, 2011 8:34 pm    Post subject: Reply to: GO TOs
Reply with quote

Generating "Spaghetti Code" is real easy, if (for example), a given program issues a PERFORM to a routine (which has an exit) and once the routine gains control, a GO TO is issued to another part of the program, completely outside of the PERFORMed routine's scope. GO TO's within a routine, that branch to a paragraph label or the exit itself (IMHO) are perfectly OK.

Bill
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Thu Apr 14, 2011 8:35 pm    Post subject:
Reply with quote

There seems to be an unconscious assumption that everyone is programming in COBOL. I have not written any COBOL in over fifteen years; however I use PL/I regularly. Some of the "helpful" features of PL/I can only be evaded through the use of a GO TO (e.g., forcing an abnormal exit from an ON-unit).

Code without GO TOs is generally more readable, understandable, and maintainable than code with GO TOs. Generally. A few years back, the language support people in my shop installed a new version of the Enterprise PL/I compiler. One of our source modules ceased to be compilable; the default IF nesting level for that version of the compiler was 17...and this particular module had a nested IF levels deep!

To reiterate an oft-quoted witticism, it's impossible to make anything foolproof, because fools are so ingenious. That includes writing maintainable code.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Thu Apr 14, 2011 8:48 pm    Post subject:
Reply with quote

GuyC wrote:
Argument 1:
Quote:
It is OK to have experienced guys use GO TO, but if you let the novices at it they will (ab)use it and cause a mess.

says it all.
In Cobol where a life cycle of a program can easily be 15 years : You don't write code for yourself. You write code for the person that has to maintain the program after you.


Agreed. Although you also do it well because you take pride in doing a good job. Happily, the two things co-incide.

Problem remains in this scheme, in 15 years time, who is writing the same standard of code?

Quote:

So you try to make up standards with the least possibility of "a mess".

Guy, you get the prize as the first person to use the word "standards". (It is a worthless prize, so I've thrown it away on your behalf).

But, in my experience, just "standards" aren't enough. "I was following the standards" I have heard many-a-time for a rubbish program produced by someone left on their own with the local standards manual.

Standards can be bad as well as good. What about the "standard" that every line of code has to be commented (yes, I worked there - and this is the one "site standard" that I rigorously ignored). You "locate" a section name, and you are confronted by an "asterix box" saying, erroneously 95% of the time, which other sections perform that on, and which sections it performs (both of which, of course, you can get 100% accuartely from the compile listing). Two pieces of rexx/xedit solved the situation. First to delete every comment in the procedure division (for program analsysis) and secondly to duplicate each line in the procedure, starting each new line with an "*" (to "demonstrate" to the Team Leader that my comments were 100% accurate, which could not be said about one single other program in the system).

Quote:

Argument 2:
Based on my experience, in well-structured programs , both with and without GO TOs :
Coding errors with GO TOs give runtime errors
Coding errors with Performs give compile errors
I personally prefer compile errors.
"And that's all I have to say about that" Forrest Gump


So, that's one for no GO TOs, if I push you one way or another.[/quote]
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: Thu Apr 14, 2011 8:55 pm    Post subject:
Reply with quote

I would be quite happy if GO TO was dropped from the language. I don't use it, I don't need it.
Back to top
View user's profile Send private message
prino

Active Member


Joined: 07 Feb 2009
Posts: 982
Location: Oostende, Belgium

PostPosted: Thu Apr 14, 2011 9:29 pm    Post subject:
Reply with quote

Akatsukami wrote:
... Some of the "helpful" features of PL/I can only be evaded through the use of a GO TO (e.g., forcing an abnormal exit from an ON-unit). ...

In fact that is the only time you actually need GOTO in PL/I.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Thu Apr 14, 2011 9:58 pm    Post subject:
Reply with quote

prino wrote:
Akatsukami wrote:
... Some of the "helpful" features of PL/I can only be evaded through the use of a GO TO (e.g., forcing an abnormal exit from an ON-unit). ...

In fact that is the only time you actually need GOTO in PL/I.

True, that is the only time that it is absolutely needed. OTOH, executing the EXIT statement adds 1000 to the return code. Nesting DO groups to avoid it, combined with "prettyprinting" the code (as important for comprehensibility, IMHO, as actual structured programming), can lead to some rather short lines. Better (and more understandable, I think) to just GO TO the end of the program.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Thu Apr 14, 2011 10:40 pm    Post subject: Re: Reply to: GO TOs
Reply with quote

Bill O'Boyle wrote:
Generating "Spaghetti Code" is real easy, if (for example), a given program issues a PERFORM to a routine (which has an exit) and once the routine gains control, a GO TO is issued to another part of the program, completely outside of the PERFORMed routine's scope. GO TO's within a routine, that branch to a paragraph label or the exit itself (IMHO) are perfectly OK.

Bill


Yes. However, as has been alluded in the dog-end of the other topic, when someone copies the section with a GO TO as a model for another, but doesn't correctly change the previously valid GO TO, then you end up with situation "spaghetti".

So, one for GO TOs as appropriate.

But once the code is out of your hands...
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Thu Apr 14, 2011 10:46 pm    Post subject:
Reply with quote

don.leahy wrote:
I would be quite happy if GO TO was dropped from the language. I don't use it, I don't need it.


OK. There are, now, enough control constructs that this could be done. Also makes you think about how to arrange things so that you don't create the absurd with Perform.

However, we come back to the other side of the same problem. Some one who doesn't take the right level of care (either doesn't know to, or can't be bothered to learn how). Same sort of problem as the out-of-control GO TO - ie, program difficult to maintain/re-use.

Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Thu Apr 14, 2011 11:00 pm    Post subject:
Reply with quote

Akatsukami wrote:
There seems to be an unconscious assumption that everyone is programming in COBOL.

Well, sort of had no choice. No forum here for just "programming", or maybe should move to the funny stuff to be inclusive.

Quote:
I have not written any COBOL in over fifteen years; however I use PL/I regularly. Some of the "helpful" features of PL/I can only be evaded through the use of a GO TO (e.g., forcing an abnormal exit from an ON-unit).

Code without GO TOs is generally more readable, understandable, and maintainable than code with GO TOs. Generally. A few years back, the language support people in my shop installed a new version of the Enterprise PL/I compiler. One of our source modules ceased to be compilable; the default IF nesting level for that version of the compiler was 17...and this particular module had a nested IF levels deep!


So, one for appropriate use.

Quote:

To reiterate an oft-quoted witticism, it's impossible to make anything foolproof, because fools are so ingenious. That includes writing maintainable code.


I'm more optimistic. Although there is no magic bullet (although there's an idea for some...) I think in aiming to achieve maintainable code you can raise the overall standard of coding in a "shop".

Replace "fool" with "user" and it works really well as well. Except the code bit.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Apr 14, 2011 11:16 pm    Post subject:
Reply with quote

Quote:
Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?


only after I BUFNO'd the crap out of it.

Sorry Guys,

a GO TO over a PERFORM does not enhance performance.

some people can not program logically. Either with PERFORMs or GOTO's,
if the logic is crap, the program is crap.

PERFORM's sort of force you to sorta-generate a modular program,
but 90% of those out there causing machine code to be produced by compilers,
just do not understand the process that they are trying to automate.

I dislike GOTO's,
BUT I HATE LITERALS IN PROCEDURE DIVISION
and i am constantly battling with assholes who want to code in lower-case
and will not put lower-case valued data division entries in copybooks.
(means that I had to go thru all my edit macros and force UPPERCASE
anytime I was manipulating/searching for values) - but that is my problem.


Regardless of the rules, if you can not force compliance...
I spent a couple years (couple of decades ago) complaining about the
lack of professionalism, the inability to design even a module in an
effecient manner, and then I realized,
that if these jerks would/could code better,
I would be out of work.
So I have spent the last 20 or so years, compiling (pun intended) a list
of worst offenders,
and thanking every one of them.


Sorry Bill, sorta-hijacked your thread.
Back to top
View user's profile Send private message
prino

Active Member


Joined: 07 Feb 2009
Posts: 982
Location: Oostende, Belgium

PostPosted: Thu Apr 14, 2011 11:47 pm    Post subject:
Reply with quote

Bill Woodger wrote:
... Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?

In PL/I, if the alternative is a very deeply nested IF statement, or a SELECT with a very large number of WHENs, and the test is on a numerical value, an array of labels with GOTO LABEL(I) might speed up things significantly. Never actually tried it.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Fri Apr 15, 2011 12:37 am    Post subject:
Reply with quote

prino wrote:
Bill Woodger wrote:
... Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?

In PL/I, if the alternative is a very deeply nested IF statement, or a SELECT with a very large number of WHENs, and the test is on a numerical value, an array of labels with GOTO LABEL(I) might speed up things significantly. Never actually tried it.


That's the sort of thing. IBM even suggest it. A "GO TO DEPENDING ON", of all things, over an EVALUATE sort of construct. If GO TO is bad, GO TO DEPENDING ON is much worse. But there might, at a rare time, be a use for it.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Fri Apr 15, 2011 1:04 am    Post subject:
Reply with quote

dbzTHEdinosauer wrote:
Quote:
Would you use GO TO for screwing the last bit of performance out of a critical application using a lot of data?


only after I BUFNO'd the crap out of it.

Sorry Guys,

a GO TO over a PERFORM does not enhance performance.


No problem with the hijack (mentioned later, but to get it out of the way before I forget). I welcome it.

I wasn't yet saying that. If you look at Prino's latest and my response, that was what I was thinking, not as to using GO TO over PERFORM.

While we're here though, would it be true (that a GO TO over a PERFORM...)? Kind of depends. A PERFORM generates a bus-load of instructions, not only for the PERFORM itself, but around the paragraph/section (my preference as you know) as well, because, paragraphs and sections can be PERFORMed, GO TOd, dropped-into, THRU'd and anything else I've forgotten at the moment.

Now, if you use an optimising compiler (or the now-built-in one) you end up with a satisfyingly small amount of code generated, becuase the compiler knows exactly how the paragraph/section is being used, and can ditch all the irrelevant stuff.

Quote:


some people can not program logically. Either with PERFORMs or GOTO's,
if the logic is crap, the program is crap.



The real point. I'd add to that people starting out, particularly if they're already happy with other languages. The worst people I found as trainees were those with degrees in computing. They had no idea how to work in a team, no idea about how to think about a program before writing it. You could see what bits they'd written first, and then instead of throwing it away cos it was such rubbish, how they'd tried to patch it up, and patch it up. All the time adhering to the site "standards" and "best programming practice" that they thought they knew, cos they had a degree.

Quote:

PERFORM's sort of force you to sorta-generate a modular program,
but 90% of those out there causing machine code to be produced by compilers,
just do not understand the process that they are trying to automate.

I dislike GOTO's,
BUT I HATE LITERALS IN PROCEDURE DIVISION
and i am constantly battling with assholes who want to code in lower-case
and will not put lower-case valued data division entries in copybooks.
(means that I had to go thru all my edit macros and force UPPERCASE
anytime I was manipulating/searching for values) - but that is my problem.



Yeah, you have a cross-reference listing, and the little... literals aren't there.

What about comments? I hate them. Or, rather, I hate the abundance of them. For code that isn't necessarily obvious, OK. Tell it in English (or whatever local language, obviously) what you are doing. Then the next person along gets a real chance to understand whether the code is correct or not. But all the rubbish saying "set this index to that value"? It never gets changed when the program is cloned, and you end up with comments that only misguide. So I don't read them. If I can, I delete them (but usually I can't, I do tend to add little sarcastic extras at times).

Never put my real name on a program either. 1) I don't have the ego. 2) I hate the idea of someone later butchering my program but having my name there (maybe I do have some ego).

Quote:

Regardless of the rules, if you can not force compliance...


Again, this is the thing. However, for me, you have to give a chance, I think, then many trainees and some with more experience will be able to recognise how to do things better (my experience). Then there are still those who are a total waste of space. Total. Total. Total. But I give everyone a chance or two, then know who not to bother with.

Quote:


I spent a couple years (couple of decades ago) complaining about the
lack of professionalism, the inability to design even a module in an
effecient manner, and then I realized,
that if these jerks would/could code better,
I would be out of work.
So I have spent the last 20 or so years, compiling (pun intended) a list
of worst offenders,
and thanking every one of them.


Sorry Bill, sorta-hijacked your thread.
Back to top
View user's profile Send private message
Ronald Burr

Active User


Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.

PostPosted: Fri Apr 15, 2011 1:39 am    Post subject:
Reply with quote

As a COBOL programmer AND an Assembler Programmer AND a REXX programmer, I have no problem with the inclusion of a well-reasoned GO TO in COBOL (note the accent on well-reasoned).
To me, the inclusion of such a GO TO is no worse than the inclusion of one of the many BRANCH instructions (e.g. B, BC, BR, BCR) in an Assembler program (and I don't think I've EVER seeing an Assembler program with zero Branch instructions). No worse than use of the SIGNAL instruction in REXX, either. As long as its use is CLEAR, and APPROPRIATE, and its inclusion AVOIDS more complicated code, it's OK with me.
The only difference (to me) is that, in COBOL, the generated assembler code for IF...ELSE or EVALUATE or NEXT SENTENCE or CONTINUE constructs contain implicit goto's (branches) rather than explicit GO TO's (also brances).
Unfortunately, I've seen both the USE and the NON-USE of GO TO's carried to the extreme.
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: Fri Apr 15, 2011 1:40 am    Post subject:
Reply with quote

Congratulations Bill. This is the first GO TO discussion thread in the history of the internet that didn't deteriorate into a holy war.

Well, not yet anyway. icon_evil.gif
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Fri Apr 15, 2011 2:02 am    Post subject:
Reply with quote

Ronald Burr wrote:
As a COBOL programmer AND an Assembler Programmer AND a REXX programmer, I have no problem with the inclusion of a well-reasoned GO TO in COBOL (note the accent on well-reasoned).
To me, the inclusion of such a GO TO is no worse than the inclusion of one of the many BRANCH instructions (e.g. B, BC, BR, BCR) in an Assembler program (and I don't think I've EVER seeing an Assembler program with zero Branch instructions). No worse than use of the SIGNAL instruction in REXX, either. As long as its use is CLEAR, and APPROPRIATE, and its inclusion AVOIDS more complicated code, it's OK with me.
The only difference (to me) is that, in COBOL, the generated assembler code for IF...ELSE or EVALUATE or NEXT SENTENCE or CONTINUE constructs contain implicit goto's (branches) rather than explicit GO TO's (also brances).
Unfortunately, I've seen both the USE and the NON-USE of GO TO's carried to the extreme.


Yes. Even a PERFORM is really a set of branches at either end. For fun, we could do it that way, but we'd make mistakes and the compiler doesn't.

I used to use SCRIPT/VS a lot. It has (had) a goto, but nothing for "perform". But, you could goto a value. So I could build performs. In a the spec for an online system I was doing it could show a dummy screen and then return back to the menu, and show another one.

The thing is, how to get programmers to accept "reasonable" use of either GO TO, modern control structures, or a mix as/if necessary.

I found show-and-tell could work with a surprising number. Others, I could spend hours with and not a single thing would sink in. Try again, same thing. Give up. Management problem then, not mine - except I was on support, of course.

I have to admit to doing some horribly wrong things as a trainee. I remember a loop, cancelled eventually (or canceled as IBM like to call it) but the output was not on hold. I was delivered 1000ft of fan-fold paper with nice headings and one line of data on the first page, and then the rest was just 2-asterisks-per-line ad infinitum. My boss sat me down, and spent some time with me (after he had stopped laughing). I got more from that than the six-week Cobol course I had just completed.
Back to top
View user's profile Send private message
prino

Active Member


Joined: 07 Feb 2009
Posts: 982
Location: Oostende, Belgium

PostPosted: Fri Apr 15, 2011 2:10 am    Post subject:
Reply with quote

Ronald Burr wrote:
... No worse than use of the SIGNAL instruction in REXX, either. As long as its use is CLEAR, and APPROPRIATE, and its inclusion AVOIDS more complicated code, it's OK with me. ...


The SIGNAL instruction in REXX has one advantage over the GOTO's in COBOL and PL/I, it gives you information as to from where it came, which allows you to very easily embed and extract data from inside your EXEC.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7225

PostPosted: Fri Apr 15, 2011 3:19 am    Post subject:
Reply with quote

don.leahy wrote:
Congratulations Bill. This is the first GO TO discussion thread in the history of the internet that didn't deteriorate into a holy war.

Well, not yet anyway. icon_evil.gif


Thanks... is the last a potential you are worried about, or a threat? :-)

No. 11 for your mainframe wars?
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
No new posts PL/I code tuning/Performance improvement Virendra Shambharkar PL/I & Assembler 3 Mon Dec 05, 2016 11:57 am
No new posts What is the code in CLIST to enable t... jackzhang75 CLIST & REXX 1 Fri Dec 02, 2016 3:02 am
No new posts IDEAL - Code Retrieval yugendran CA Products 0 Fri Nov 25, 2016 3:27 pm
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


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