"CONTINUE" as first line in Procedure Division ?? 1

[RICHINMINN]

This is a large IBM/DB2 shop, and I've just gotten a big bundle of programs to support. The programmer who wrote these programs started out the Procedure Division as follows:

PROCEDURE DIVISION.
CONTINUE.

FIRST-PARAGRAPH-NAME.
....

My question is: What good does it do to stick that "CONTINUE" in there as the first line of code in the PROCEDURE DIVISION?

I've been writing COBOL code for 20+ years, most of it spent on non-IBM platforms. What I've noticed is that IBM programmers do a lot of things in one particular way because that's the way that their professor in college did it, or their mentor at the first programming job they held. A lot of what IBM programmers do carry all the way back to the '50s when programmers were working on mainframe systems that make today's PCs look like supercomputers.

So what's up with this "CONTINUE"?

Rich (in Minn.)

 

[slade]

Yeah Glenn,

I've used it in situations like this:

2 I/P files. Sometimes you read one, sometimes the other, sometimes both.

In the code, I'll use this, for example:

     IF ...
        PERFORM 7000-READ-FILE-1
     ELSE
        PERFORM 7000-READ-BOTH-FILES
           THRU 7000-EXIT
     END-IF
.
.
7000-READ-BOTH-FILES.
7000-READ-FILE-1.
.
.
7000-READ-FILE-2.   
.
.
7000-EXIT. EXIT.

I know, the THRU bugaboo. I usually don't use it, but when it makes sense, I'll make an exception (the same w/GO TOs).

 

[StephenJSpiro]

PEREFORM
WHAT-LIGHT THRU YONDER-WINDOW-BREAKS.

PERFORM
TIPTOE THRU THE-TULIPS.

*Smile*
Stephen J Spiro

 

[BettyScherber]

Back in the mid 70's, I had a FORTRAN programmer working with my on a COBOL project. In FORTRAN, variable names at that time were limited to six characters and those that began with the letters I-N were integers unless you specifically defined them to be otherwise, so she had elected to name her index variables I, J, K, etc. When I explained to her that we had a thirty character limit in COBOL, so we could use descriptive names, she went back and modified the code, using the names, I-INDEX, J-INDEX, K-INDEX, etc. Seems that there have always been some things that have a hard time translating across the "language barrier". Betty Scherber
Brainbench MVP for COBOL II

http://www.brainbench.com

 

[dallasdino]

This is a bad programming move but they are trying to get rid of the compiler warning of no statements before the first paragraph.

Remove the first paragraph statement which is of no use unless they are doing a GO TO back to it which is also poor programming.

You likely write like this so would never do this but comment out the open and you get the same problem.

INITIALIZATION.

OPEN I-SYSUT1-FILE.

MAINLINE

PERFORM S0100-PROCESS UNTIL SYSUT1-EOF-YES.

FIALIZATION.

CLOSE I-SYSUT1-FILE.

 

[RICHINMINN]

I managed to track down the original programmer who had used this 'CONTINUE' statement as the first line in the PROCEDURE DIVISION, and I asked him why he did it that way.

He said that at some point in the past, at one company that he had worked at, some programmer had told him to ALWAYS put the CONTINUE statement as the first line of the PROCEDURE DIVISION. Normally, the DB/2 pre-compiler will put hundreds of lines of SQL code immediately after the PROCEDURE DIVISION statement, and then will put a CONTINUE statement in, before the first line of programmed code in the PROCEDURE DIVISION. This 'other programmer' had told him it's 'cheap insurance' to put the CONTINUE statement into the PROCEDURE DIVISION, just in case the SQL pre-compiler's CONTINUE statement goes awry. This is kinda like MarcLodge's tale of being forced to classify every COBOL program as a DB/2 program when putting it into ENDEVOR, just in case you accidentally left the DBRM card in when you compiled it. It's a solution for a problem that doesn't exist!!

And so this programmer standardized on putting CONTINUE as the first line in the PROCEDURE DIVISION of every program he wrote (DB/2 and non-DB/2), just in case it might be needed some time.

I just rolled my eyes and walked away...

Rich (in Minn.)