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
 

 

The usage of GO TO statement

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
jctgf
Currently Banned

Active User


Joined: 04 Nov 2006
Posts: 109

PostPosted: Mon Jun 04, 2007 4:35 pm    Post subject: The usage of GO TO statement
Reply with quote

i have been reading some opinions about the usage of "go to" on many foruns and i think it's simply ridiculous.

there are cases in which the "go to" statement causes the opposite effect from what is usually expected: it makes the program more clear.

suppose u have a validation program. it reads a sequential file, validate every field and, in case any of the fields contains an error, it discards the record.

Code:

PERFORM READ-FILE.
PERFORM VALIDATION UNTIL READ-RECORD = HIGH-VALUE.

VALIDATION SECTION.
  IF A-FIELD NOT NUMERIC
      PERFORM WRITE-DISCARD-REC
      GO TO READING
  END-IF.
  IF B-FIELD NOT NUMERIC
      PERFORM WRITE-DISCARD-REC
      GO TO READING
  END-IF.
  IF C-FIELD NOT NUMERIC
      PERFORM WRITE-DISCARD-REC
      GO TO READING
  END-IF.
READING.
   PERFORM READ-FILE.
VALIDATION-EXIT.  EXIT.



is it a bad code? i don't think so...

JC
Back to top
View user's profile Send private message

swapnadeep.ganguly

Active User


Joined: 21 Mar 2007
Posts: 203
Location: India

PostPosted: Mon Jun 04, 2007 5:36 pm    Post subject: GO TO
Reply with quote

Various clients don't like the usage of GOTO satements. Instead of using a GOTO, you set an error flag.

For subsequent checks, just also check whether the negative error flag is true.

If the negative error flag (ie no error is found on the previous validation) is found, then only the control would check the next conditions.

Some times the GOTO statement acts erroneously due to the usage of GOTO.
Back to top
View user's profile Send private message
pingte

Active User


Joined: 03 Dec 2005
Posts: 120
Location: india

PostPosted: Mon Jun 04, 2007 5:38 pm    Post subject: Re: the usage of go to
Reply with quote

u can use Perform instead of GO TO...
using GO TO in not good practice in terms of structured programming!
Back to top
View user's profile Send private message
mahic

New User


Joined: 08 Jan 2007
Posts: 4
Location: Mumbai

PostPosted: Mon Jun 04, 2007 5:40 pm    Post subject: Re: the usage of go to
Reply with quote

Hi,
Actually using of GO TO verb soo many times, If use PERFORM READING para inside the PERFORM WRITE-PARA it will be better....becoz if u use GO TO the control will not be coming back from where u have called....

so use PERFORM...instead GO TO

If i am wrong plz correct me......

Mahi
Back to top
View user's profile Send private message
swapnadeep.ganguly

Active User


Joined: 21 Mar 2007
Posts: 203
Location: India

PostPosted: Mon Jun 04, 2007 5:52 pm    Post subject:
Reply with quote

Hi,

You can instead use the following codes instead of using GOTO:

Code:
PERFORM VALIDATION UNTIL READ-RECORD = HIGH-VALUE.                     
VALIDATION SECTION.                                                     
  IF A-FIELD NOT NUMERIC                                               
      PERFORM WRITE-DISCARD-REC                                         
      SET W410-ERROR-FLAG TO TRUE                                       
  END-IF.                                                               
                                                                       
  IF B-FIELD NOT NUMERIC AND W410-NO-ERROR-FLAG                         
      PERFORM WRITE-DISCARD-REC                                         
      SET W410-ERROR-FLAG TO TRUE                                       
  END-IF.                                                               
                                                                       
  IF C-FIELD NOT NUMERIC AND W410-NO-ERROR-FLAG                         
      PERFORM WRITE-DISCARD-REC                                         
      SET W410-ERROR-FLAG TO TRUE                                       
  END-IF.

READING.                                                               
   PERFORM READ-FILE.                                                   
VALIDATION-EXIT. 


More over if you are finding the above code a bit of difficult, then you can instead use EVALUATE clause.

The code can be shown as written under:

Code:
PERFORM VALIDATION UNTIL READ-RECORD = HIGH-VALUE.                     
VALIDATION SECTION. 

EVALUATE TRUE
                                                   
  WHEN A-FIELD NOT NUMERIC                                               
      PERFORM WRITE-DISCARD-REC-A                                         
                                                       
  WHEN B-FIELD NOT NUMERIC
      PERFORM WRITE-DISCARD-REC-B                                         
                                                                                 
  WHEN C-FIELD NOT NUMERIC
      PERFORM WRITE-DISCARD-REC-C                                         
     
  END-EVALUATE.                                                               
                                                                                                   
READING.                                                               
   PERFORM READ-FILE.                                                   
VALIDATION-EXIT.
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: Mon Jun 04, 2007 7:59 pm    Post subject:
Reply with quote

Hello,

The GO TO is neither good nor bad by itself - usage is everything. Some of the very worst code i have ever seen was "structured" and "GOTOless". You don't need the GO TO to write simply horrible code. Some of the very best code i've seen (worked all the time, was easy to maintain, and performed well) included some GO TO statements.

If you have strong feelings on using or not using GO TO, i'd suggest making sure that a company or project has the same feeling you do - preferable before joining.

Because i'm mostly an outsider providing support, i support whatever the rules are at that location.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3158
Location: Tucson AZ

PostPosted: Mon Jun 04, 2007 9:02 pm    Post subject:
Reply with quote

Well said Dick, I've been biting my lip to avoid saying something un-nice to these young professionals.... icon_confused.gif
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 149
Location: Ottawa Canada

PostPosted: Mon Jun 04, 2007 11:53 pm    Post subject:
Reply with quote

Well here's another view.

In the old days programmers used GO TO in all sorts of inappropriate ways. I recall having to maintain unstructured logic that was full of GO TO's. Nightmare. When structured programming concepts took over, it was necessary to establish strict rules preventing the use of GO TO in order to break old habits.

However, the old days are long gone and the pendulum has swung back. Today it is safe to recognise that there are valid uses for GO TO. The sample code that jctgf shows us is considered to be OK where I work. The only difference is that our shop has this rule: the GO TO paragraph name must use the suffix -EXIT and contain 1 statement: EXIT.

Note: I never use this EXIT approach myself. However, I see it all the time and it doesn't bother me. I just find it is very easy to avoid using it.

Where do I use GO TO?

I use it in error handling logic where there is NO chance that control will be returning. Under this scenario I find that GO TO is better than PERFORM because it makes clear the fact that control will not be coming back. PERFORM is actually misleading in this case but many programmers continue to use PERFORM because they believe it is bad to use GO TO.

The use of GO TO in error handling actually makes your program look better because it avoids cluttering the logic with switches.

Side Note: I locate all my error reporting logic at the bottom of my source file. The reason I do this is to separate the mundane but plentiful error reporting logic from the main logic. Makes the program easier to read.
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: Tue Jun 05, 2007 12:13 am    Post subject:
Reply with quote

Hello,

Agreeing with TG's post, i'd like to add one other bit to the 2 GO TO rules he mentioned (going to the end-of-routine exit and going to the error/abend code). The other situation several places use (and i rather like) is that it is permissable to GO TO the top of a routine as well as the bottom/exit. Sometimes this is more clear (understandable/maintainable) and uses less resources than running inside of performs.

In no case should a GO TO be used to transfer control to "somewhere else" where processing would continue. This would be where the infamous "spaghetti code" lives. . . . icon_smile.gif especially when that code issues a GO TO back to somewhere already "in flight".
Back to top
View user's profile Send private message
prasadvrk

Active User


Joined: 31 May 2006
Posts: 200
Location: Netherlands

PostPosted: Tue Jun 05, 2007 11:22 am    Post subject:
Reply with quote

If you have a strict handle on the GOTO you can always use one, after all it serves its purpose. More often than not people use GOTO without knowing the flow of the control. Forward GOTO will never have any problem as there is no confusion about the flow
Back to top
View user's profile Send private message
jasorn

Active User


Joined: 12 Jul 2006
Posts: 153
Location: USA

PostPosted: Tue Jun 05, 2007 4:34 pm    Post subject:
Reply with quote

dick scherrer wrote:
Hello,

Agreeing with TG's post, i'd like to add one other bit to the 2 GO TO rules he mentioned (going to the end-of-routine exit and going to the error/abend code). The other situation several places use (and i rather like) is that it is permissable to GO TO the top of a routine as well as the bottom/exit. Sometimes this is more clear (understandable/maintainable) and uses less resources than running inside of performs.

In no case should a GO TO be used to transfer control to "somewhere else" where processing would continue. This would be where the infamous "spaghetti code" lives. . . . icon_smile.gif especially when that code issues a GO TO back to somewhere already "in flight".

yep.
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
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Need inputs on Space requirement and... ashek15 IMS DB/DC 0 Sat Apr 01, 2017 8:26 am
No new posts ROUNDED Problem with COMPUTE statement shalem COBOL Programming 11 Thu Feb 09, 2017 8:16 pm
No new posts VALIDATE NULL VALUE IN DB2 CASE STATE... useit DB2 5 Thu Feb 09, 2017 4:34 pm
No new posts -913/-911 Deadlock during UPDATE stat... NoSleep319 DB2 5 Fri Nov 18, 2016 12:37 am
No new posts COBOL DB2 - CALL statement - high CPU... TS70363 DB2 15 Sun Sep 11, 2016 6:07 am


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