IBM Mainframe Forum Index
Log In
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register

Replacing GO TO Statements

IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message

New User

Joined: 16 Oct 2008
Posts: 74
Location: Boston

PostPosted: Tue Dec 02, 2014 5:28 pm
Reply with quote

My management as part of a COBOL standard that they introduced recently wants to replace all the GO TO statements. They have blindly said 'No GO TOs please for any of the new as well as the existing programs'.
There are more than 600+ Cobol programs having GO TOs in them which they want to be changed. This changing of GO TOs for the existing program does not make any sense to me as they work perfectly well now and they could have said they want it to be implemented for new programs.

Just wanted to know if there would be any way this can be done without me getting to analyse all the GO TO statements in each of the 600+ programs making sure that I dont tamper with the existing functionality.

Any suggestion in this regard would be highly appreciated.

Thank you!
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7311
Location: Inside the Matrix

PostPosted: Tue Dec 02, 2014 5:50 pm
Reply with quote

It will be very costly to analyse, change and test 600 programs to remove GO TOs and subsequently ensure that their behaviour is identical.

However, if that is what is ordered, then presumably the large cost (both in financial terms and in analysis/development/testing resources) has already been accepted.

There are no shortcuts. Unless you are lucky.

If, for instance, the only use of GO TO is to get to a fatal-error routine, then replacing the GO TO by a PERFORM will do (the fatal error generated will ensure there is no return from the PERFORM)..

However, it is much more likely that the GO TOs are in ordinary code, and that to post facto avoid their use will require sufficient restructuring as to require considerable amounts of testing.

He who pays the Piper calls the tune. But do they really know the cost? To achieve what, for that cost?

I've never heard of going back and removing GO TOs from all programs. For major changes to an existing program, it is reasonable to consider, since the testing can cover those changes as well. For small-to-medium changes to existing programs, it is not "worth" upsetting the existing program, in general.

If your company has money, resources and time to burn then OK (and get them to contact me, I don't mind making the changes in such situations of largesse).

For new programs, entirely reasonable. For existing programs not under major change, let's be polite and say it is a "questionable" idea at best.

PM me for contact and bank account details.
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator

Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA

PostPosted: Tue Dec 02, 2014 7:46 pm
Reply with quote

Bill brings up valid points, but I'd like to add another. The cost of replacing GO TOs should be weighed against the cost of maintaining those programs as is. Many of us have dealt with programs written decades ago and have been modified by numerous developers with numerous coding styles. The longer these programs exist the more difficult they become to understand because of those reasons. Advancement of COBOL functions have not always been taken advantage of. One option woud be to deal with these programs one at a time when other changes are required instead of biting the bullet with all 600 at one time.
Back to top
View user's profile Send private message


Joined: 07 Sep 2006
Posts: 1565
Location: Andromeda Galaxy

PostPosted: Tue Dec 02, 2014 8:26 pm
Reply with quote

Replacing GO TO could change the way the program was created.

Having said no GO TO in the new programs is a better idea.

But replacing all GO TO in existing programs is not a good idea.

I personally feel it is not worthy at all .. Assuming it will just take 2 hrs to do the analysis & change and 1 hr to do the promote and 1 hr for documentation and 1hr to retest .. 600 * 5 = 3000 hrs..

Assuming you work for 10 productive hrs a day = 300 days

Its just not worth it
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming


Similar Topics
Topic Forum Replies
No new posts JCL for replacing code in Cobol JCL & VSAM 7
No new posts special characters pipes "|"... COBOL Programming 1
No new posts filter COMMIT/ROLLBACK statements DFSORT/ICETOOL 13
No new posts Rexx to create VSAM define statements CLIST & REXX 10
No new posts Summing records conditional statements. SYNCSORT 13
Search our Forums:

Back to Top