PERFORM WITH IF 6

[claudeb]

Hi, what's wrong with my coding ?
the compiler is screaming: "The "IF" verb did not have a matching scope terminator."

PERFORM
VARYING K FROM 1 BY 1 UNTIL K > 6
IF A-AMT (J) < B-AMT (K)
PERFORM 1000-WRITE
THRU 1000-WRITE-X
END-PERFORM.
thanks

 

[jimlee]

hi,

PERFORM
VARYING K FROM 1 BY 1 UNTIL K > 6
IF A-AMT (J) < B-AMT (K) then
PERFORM 1000-WRITE
THRU 1000-WRITE-X
end-if
END-PERFORM.

???? jimlee

 

[Greenguy71]

That's it!!
s-)

 

[nontrad]

I would be VERY careful about using a perform thru statement. Even back in 1982, I was told that this is poor coding. For example, what would happen if you rearranged the paragraphs or inserted a new one?

You're better off to be mopre explicit. i.e.
perform 1000-write
perform 1001-writea
perform 1002-writeb.

That way , there is no possibility of error in what you actually want to perform.

 

[Greenguy71]

I would tend to disagree with you there nontrad....be very careful when not using the perform thru statements.

I have been on the other side of the coin with problems related to open ended performs and goto's alike.
s-)

 

[JanSweden]

does anyone use &quot;go to&quot; this days?

 

[RonaldB]

Greenguy,

WHAT is an open ended perform ?!! And indeed, who uses GO TO's ?!!
I don't have much with PERFORM THRU's either; there is a risk of performing unwanted paragraphs, and performing each paragraph explicitly makes the code far more legible (one of COBOL's strong points, remember ?)
I guess if one would perform a SECTION, one might get in trouble; that is why most structured programming techniques are in favour of not using SECTION's, but only paragraphs. I personally have never needed SECTION's to build well structured programs.

Regards,
Ronald.

 

[jimlee]

never heard of go to myself could someone enlighten me?
jimlee

 

[slade]

Jimlee,

Never heard of a goto? Wow, I'm getting old, I guess.
It's like a Model-T (I hope you've heard of that); it's what we used in the old days to go from one place to another.

e.g., GO TO 400-PGRAPH

Unlike a PERFORM, once you got there you had to find your own way back or continue on your merry way.

Never heard of a GO TO; I hope you were kidding.

Ronald,

I can understand the current reluctance to using GO TOs et al., but the zeal and intransigence of its adherents puzzle me. I think a GO TO to an exit pgraph makes a lot of sense.
I wouldn't recommend them in other situations, but consider the following:

We,ve all seen those nested IFs that meander across the page. Why can't we code the negative IFs with GO TOs to the exit? If I,m chasing a bug, I'd rather not enter that monster if I don't have to. The neg IF tells me that up front.

I guess it's a case of &quot;sauseach his own&quot;.

Chow.

 

[Greenguy71]

What! Doesn't anyone else have to look at old nasty code on occasion like I do!! What about generated code kicked out by some &quot;half baked&quot; translator to convert Assembler to COBOL.......I'm the only one! MAN!

Actually that may be a bit overstated, more often than not I see well constructed code, but there have been times.

Jimlee, if you do not encounter GO TO statements, then consider yourself lucky. They do serve their purpose when used appropriately however. We only use them to bypass code downward to the EXIT paragraph it is in. Obviously the same can be accomplished by using IF's and ELSE's over and over, but when you want to skip remaining code in a paragraph for a very particular reason, it works very well.

As far as PERFORM THRU goes, it works very effectively and is very readable when each COBOL paragraph is coded with a name and an exit. Those circumstances also allow for GO TO statements to be easily used and readable. For example:

    PERFORM 1000-PROCESS-RECORDS THRU 1000-EXIT.

1000-PROCESS-RECORDS.

    IF DONT-PROCESS-ME
        GO TO 1000-EXIT
    END-IF.

    |
    |
    |
    ---> REMAINING CODE FOR THIS PARAGRAPH
    |
    |
    |

1000-EXIT.
    EXIT.
[\code] 
s-)

 

[jimlee]

slade,
yes, i've heard of a model-t!! and no I wasn't joking, i've honestly never heard of GOTO before. Having said that, i've only been learning COBOL for 5 months or so, and have seen no code apart from my cobol manual and that on this forum so don't worry too much about feeling old!
slade + greenguy,
thanks for the examples GOTO looks like it could be quite useful if used right.
cheers, jimlee

 

[slade]

Hi Jimlee,

Hope you weren't offended by my teasing. Just a word of warning; some get very emotional about the GO TO. Since you haven't heard of it during your 5 months of learning, your prof may be an anti-GO TO zealot, so BEWARE!!!

Regards, Jack.

 

[jimlee]

hi jack, don't worry, I have no prof as i am learning from home,Just one manual and a personal tutor,but haven't been in touch with him/her yet!
I've found this forum excellent, everyone takes a lot of time to be really helpful which is nice,
here's to ya all! jimlee

 

[nontrad]

First of the 10 Commandments at the Computer Systems Development Officer Course (aka Grace Hopper School of Programming) at Keesler AFB in the 80's -

Thou shalt not GOTO

=;-)

 

[RonaldB]

Jack,

the thing about GO TO's indeed is a matter of taste. I don't want to discard it all together, but it bares a risk if improperly used (as anything). Jumping unconditionally out of a chain of actions can make it very hard to follow what is happening (spaghetti code). Actually, i feel that the only acceptable use is jumping to an exit paragraph, and that is only necessary when using SECTIONs.

Bottom line is: i think it can easely be avoided. But, that's just another opinion ...

Good luck,
Ronald.

 

[clegg]

I find using sections most useful - but again you don't need to use a GOTO in this context - you could just use EXIT SECTION.

 

[slade]

Hi Ronald,

I'm an avid proponent of readable code. I'll even sacrifice a certain amount of efficiency to make the code understand- able. While I agree that unrestricted use of go tos can result in spago like code, I object to those who outlaw its use altogether.

I think its the result of managerial laziness. I think all code should be checked for style and structure. Eliminating go tos won't eliminate spaghetti code; but constructive review will.

I'm not a believer in the dictum: &quot;As long as it works&quot;. A program is a unique tool; it's the only tool I know of that serves as its own user's manual. And for that reason the clarity of the code is crucial.

Descending the soapbox, I quote Dennis Miller &quot; I may be wrong, but that's what I think&quot;.

Regards, Jack

 

[BettyScherber]

True story: I once analyzed a series of programs from a vendor and made a casual remark about the frequencies of GO TO's in the code (I am a non-fan of GO TO, by the way). The vendor explained their rule, which I found to be amusing.

You put in a line of *'s from column 7 all the way to 72.

You write some code.

You put in another line of *'s from column 7 all the way to 72.

In the code, it is considered to be a &quot;well-structured&quot; program, as long as you don't GO TO outside the lines of *'s.


WOW! What a revelation! I was able to go back to my office and make all of that old spaghetti code structured, simply by adding a line of *'s at the beginning of the PROCEDURE DIVISION and at the end of the program!
Betty Scherber
Brainbench MVP for COBOL II

http://www.brainbench.com

 

[RonaldB]

Jack,

afterall, we're on the same frequency anyway ! I'm allso very picky about well structured programs, since any (debatable ?) loss of efficiency is way outweighted by readability and ease of maintenance gained by a sound structure. That's why it pleases me greatly that you seize every opportunity to educate anyone with appearent troubles on that subject.
In the end, it doesn't really matter what technique one uses to produce a sound structure, as long as it is done ! I can only say that my education on this matter chose not to use GO TO's, but to implement structure strictly by performing paragraphs, which works fine.

Regards,
Ronald.

 

[JanSweden]

Hi All

I don't like GO TO as it's so easy to 'jump just for now - fix later' - But more important - naming conventions for variables and sections/paragraphs. To get the so easy to read structure - I belive this is the most important issue - and keeping those conventions in more than one program;-)

Are there any interesting ideas in this area?

Jan