Need good advise on COBOL reference for rewriting programs

Hello all...
I need to know if someone out there has a good reference that outlines a method of converting some very old COBOL code to more structured code. I have the "fun" %-) task of converting code written circa 1968 and converting it to be more structured, keeping the same compiler using COBOL I. I'm sure someone out there is familiar with the term "spaghetti code". This indeed is and has many 'GO TO's as well as Sections mixed with individual Paragraphs. It's quite a mess but the implications of this restructuring project are staggering, as the programs are driver programs and literally millions of dollars are at stake.
I wanted to know if there were any good reference books written that could present ideas on how to turn 'GO TO' logic paths into PERFORMs that could be written into a modular and structured program. As a programmer in mid career I'm even toying with the idea of writing a book on this myself, as this project will present many of the relevant issues. BUT if there is reference material already available, this definitely will assist in reducing the project timeframe.

Anyone have any suggestions?
Thanks,
MHW

 

[Crox]

Hi,

There are people whom are building software to do this.
I work on this myself sometimes. It is not part of my current assignment but I would love to get such one

I know that Cornerstone in Holland is busy with this. I don't know how far they are yet.

The thing is not only to convert for example from GO TO rich to GO TO less source, the mainproblem is that after reorganizing things, people whom have to maintain the source have to understand what the new build structures mean.

It can help to determine record-level handling, group-level handling, etc. and create routines in the Jackson- or Volmac- way and build a picture of the design.

Also when there are recursive concepts (table handling with elements with status information, those kind of things), backtracking problems, interleaving clashes, boundary clashes, it can be less easy to understand the source after making those programs GO TO less.

It would be nice to share ideas.

Regards,

Crox

 

[MarcLodge]

Hi MHW,
I've done a small amount of this type of processing, when I had to write/maintain a REXX routine that read a language (Seers HPS) and output Cobol(!). The main components of this type of process are the lexer and the parser and there is a fair amount of literature freely available. I am told that the best language for this sort of thing is C++.

What you are after is more complicated as the language is not structured "correctly", but that is what you are hoping to create. This obviously causes problems, for instance a GO TO would sensibly have to be replaced by a PERFORM then GOBACK. If the para or section GONE TO had a GOBACK, then the code begins to look incomprehensible.

I've heard of and seen the website of a product which allegedly can do something along these lines. I must admit though to having taken it no further, as I no longer need to in the current job I'm doing. I'd have a look at

http://www.siber.org/sct/lib/intro.html

and see if a general inquiry can elicit any more information. Good luck and keep us posted.
Regards,
Marc

 

[mhw]

MarcLodge:
Thanks for the link - its looks interesting and I'll let everyone here know what I find. I do know that there are companies that have created (to various levels of success) COBOL converters to restructure the code. I worked on such a project in my earlier programming days but the problem was that we the programmers still had to go into the code and clean up various elements. The converter was a crude product and we had to add items such as EXIT paragraphs. Also, coding violations from some not so careful programmers (such as 'GO TO's out of an inline PERFORM loop) were not handled properly. Since this was back in 1994 and we were using COBOL II, I don't think the product was ready to handle the new COBOL version (via the END-PERFORM, END-READ, Etc constructs) . Unfortunately, I can't remember the name of it or who put it out either. Anyway, I'll keep looking. It would be nice to have a reliable conversion product that didn't cost hundreds of thousands of dollars to license and install on the mainframe. Again, if anyone else could share a link or reference material it would be appreciated. My own search on the web has been slow - there appears to be a myriad of outdated and out of print books for COBOL programming topics.
Thanks,
MHW

 

[StephenJSpiro]

I've done a lot of this kind of work -- turning spaghetti code into modular structured code. The trick is to work from the bottom up. Find all the places that GO TO the STOP RUN (GOBACK, EXIT PROGRAM) statement. If there are more than one, make a paragraph with the STOP RUN, and have all of them GO TO the one place. Then work back, taking everything to the next previous GO TO, and make it a single module. THEN, you can eliminate that GO TO, replacing it with PERFORM NEW-CONSOLIDATED-MODULE, STOP RUN or GO TO STOP-RUN-PARAGRAPH. Keep working back. Eventually, you will have only performed routines, with one or more GO TO STOP-RUN-PARAGRAPH, which you can then put inline in the control paragraph.

Stephen J Spiro
Member, ANSI COBOL Standards Committee
stephenjspiro@mail.com

 

[RussBartlett]

Check out Structured Cobol Methods from Paul Noll. It contains some very useful guidelines for writing good structured code.

 

[amosgreg]

I found the following yesterday and can't find the link quickly. It was from a dissertation about modernization of COBOL and I found it relevent but make your on mind up.
Greg

APPENDIX A - Rules for Modernization of Programs

RULE 1 - Use "/" in column 7 and blank or comment lines to control program formatting instead of "EJECT" and "SKIP" commands.


RULE 2 - When not as part of a comment block, use blank lines rather than blank comment lines.


RULE 3 - Omit the DATE-COMPILED paragraph from the program. Replace other IDENTIFICATION DIVISION paragraphs with appropriate comments.


RULE 4 - Do not code the CONFIGURATION SECTION if the compiler allows you to.


RULE 5 - Assign files to an external name only, without all the device dependent information.


RULE 6 - Specify only the minimum of information in the FD, namely LABEL RECORD when the compiler still requires it, and BLOCK CONTAINS 0 (used to designate that the JCL/file will contain the real block size instead of the program).


RULE 7 - Do not use the SYNCHRONIZED clause as it is no longer necessary.


RULE 8 - Use the group/numeric field construct rather than a REDEFINES for multiple field definitions needed in edit programs.


RULE 9 - Unless a field is used in computations a large number of times, or there are many numeric fields in a file, use the USAGE mode that is most comfortable to you.


RULE 10 - Initialize global fields, such as program counters, totals, and end-of-file switches with a VALUE clause, to avoid forgetting the initializing MOVE statement later.


RULE 11 - Use the Balanced Line algorithm for file "matching" instead of the key matching algorithm.


RULE 12 - Use the PERFORM UNTIL structure instead of the historical control break structure.


RULE 13 - Use the "triform" structure as the main control structure in your program.


RULE 14 - Do not indent when coding a "linear" nested IF to implement a CASE structure. Code the ELSE IF on the same line as if it were a single verb.


RULE 15 - When coding nested IF statements, always code both the true and false paths, using the NEXT SENTENCE or ELSE NEXT SENTENCE construct as necessary.


RULE 16 - Do not code an IF statement when the terminating condition of a PERFORM loop will also include the condition.


RULE 17 - Do not use the PERFORM ... THRU construct.


RULE 18 - Always use the READ ... INTO and WRITE ... FROM forms of these verbs and define all record definitions in the WORKING-STORAGE SECTION.


RULE 19 - Consider counting "records processed" instead of "records read". At least ask yourself, "why am I counting?" and "what am I counting?".


RULE 20 - Consider adding "PARM" overrides to allow for easy program testing, eliminated the need for "near-clones", etc.

Greg Amos
amosgreg@ix(dot)netcom(dot)com replace(dot)

 

[ceh4702]

The trick about most GO TO's is they are not used to do performs but used to skip executing code. So the Performs are what they skip! If you do not like my post feel free to point out your opinion or my errors.

 

[StephenJSpiro]

Rule 18 is garbage, and can create ENORMOUS overhead with a large file, or with large records. NEVER use READ INTO and WRITE FROM unless you absolutely can't do it any other way.

Some of these rules will be ENFORCED in the new standard (Identification Division entries are all dropped, for instance, except PROGRAM-ID.)

This is an OLD list. Do NOT use NEXT SENTENCE, as it is obsolete. Use CONTINUE, but be careful where your flow of logic goes. It is NOT the same as NEXT SENTENCE.

Stephen J Spiro
ANSI COBOL Standards Committee

 

[RussBartlett]

I think too many people get hung up on "GO TOless" programming and miss the big picture as each module written should be functionally subordinate. This way code is easily read from top to bottom.

Although I don't like to see "GO TO's" in programs there are situations when it doesn't matter really. For instance if the program encounters a fatal error. After all the program will not reach it's normal end anyway. So there are instances when a "GO TO" is OK to use. As long as they are used as the exception rather than the rule then it shouldn't be a problem.

 

[MarcLodge]

amosgreg, I don't know where you found those 'rules' but I reckon it must have been on a site designed to annoy professional coders! As I read thru them I found myself becoming more and more annoyed. Let's take rule 1. Why use / instead of EJECT? As far as I am aware, all compilers still accept EJECT, so why change it? Also, let's face it, how often do we print out listings any more? I can't remember the last time I did it, and in fact the site I'm currently working at, you'd have to download the job to the PC in order to print locally.

There are many other of these 'rules' that I object to (14 for instance is personal style) but 15 is quite patently incorrect. Never code NEXT SENTENCE, but code CONTINUE instead. We had a thread which covered this topic a month or two ago, and I'll quote an example I used there.....

back in the days when everybody coded periods, next sentence would have been the same as continue (if it existed!). Nowadays, they are VERY different. Consider:
IF A = B
CONTINUE
ELSE
DISPLAY 'Hello'
END-IF
DISPLAY 'GOT HERE'
DISPLAY 'AND HERE'
.
EXIT-PARA.
EXIT.
If A equals B then GOT HERE and AND HERE will be displayed.
Whereas:
IF A = B
NEXT SENTENCE
ELSE
DISPLAY 'Hello'
END-IF
DISPLAY 'GOT HERE'
DISPLAY 'AND HERE'
.
EXIT-PARA.
EXIT.
If A does equal B, it will drop thru to the next period ie GOT HERE AND HERE will not be displayed. In legacy coding. you can expect to find a period after the END-IF, and in this case the effect of the two statements would be the same.
Basically, BE VERY CAREFUL WITH NEXT SENTENCE !!!! It can miss huge chunks of code as it will begin processing at the statement following the next period. In programs with one period at the end of the section, then statement would drop thru to the end of the section!!!

I now need to go and have a drink in order to calm down.