Apologies again if this has already been answered. I'm a few days behind. You can use a full stop (period) to terminate an IF statement. The "problem" is (and one of the any reasons I elide all periods that are not absolutely required) it terminates an entire COBOL "sentence" (not just a COBOL statement). Since you used a perform of a separate procedure you could end each IF with a period and its fine. The same would not be true for an "inline" perform, as I showed in my previous reply. If I had used a period instead of an END-IF the period would not only terminate the first IF, but also the PERFORM. Meaning the remainder of the IF statements would end up being "outside of the loop", while the END-PERFORM would have no PERFORM to match to, since the PERFORM was already terminated by the period. Bad news! But at least it wouldn't compile. If I had dropped the END-PERFORM it WOULD compile (with periods replacing END-IFs), but it wouldn't do what you want.
Here's, if you are interested, valid COBOL that also likely does not do what one would want it to do. IF SOMETHING NEXT SENTENCE ELSE PERFORM SOMETHING-ELSE END-IF PERFORM MORE PERFORM MORE-AND-MORE EXIT. The "NEXT SENTENCE" phrase of an IF statement is an implicit GO TO *beyond* the next period (i.e., "to the next sentence". In this case if SOMETHING is true not only would SOMETHING-ELSE be bypassed, but so would MORE and MORE-AND-MORE. Two possible fixes are: 1) add three periods (example below), or keep as-is except replace the NEXT SENTENCE phrase (clause?) with a CONTINUE statement. CONTINUE is a true no-op, rather then a GO TO in disguise. Option 1) IF SOMETHING NEXT SENTENCE ELSE PERFORM SOMETHING-ELSE END-IF. PERFORM MORE. PERFORM MORE-AND-MORE. EXIT. Option 2) IF SOMETHING CONTINUE ELSE PERFORM SOMETHING-ELSE END-IF PERFORM MORE PERFORM MORE-AND-MORE EXIT. All of this nonsense is, of course, a result of END- clauses not being part of COBOL before the 1985 standard. You HAD to use a period to terminate an IF. And of course all of that is a result of someone thinking that an "English like" programming language could be unambiguous, or at least a somewhat good idea in practice... A good idea in theory, but not so much in practice. ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Bob Bridges <robhbrid...@gmail.com> Sent: Saturday, June 6, 2020 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: COBOL Question Oh, you need an END-IF even for a single-statement IF? I forgot; I've been thinking in REXX too long. In that case you're close; I guess I really meant PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 1050-LOOP. IF X > 999 GOTO 1050-EXIT END-IF. IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. IF TYPE <> 195 GOTO 1050-EXIT END-IF. IF NOT SO-ON GOTO 1050-EXIT END-IF. IF NOT SO-FORTH GOTO 1050-EXIT END-IF. [do such and such] 1050-EXIT. I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ circumstances. In my old shop I argued for GOTOs in three very strictly limited circumstances, the other two being end-of-section and end-of-program. Some languages allow for this by including some flavor of "leave" statement; all I want to do with a GOTO is to simulate that part of structured programming. But at the particular shop I have in mind, none of that could be contemplated, because all GOTOs are evil. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Law #21 of combat operations: The important things are always simple; the simple things are always hard. */ -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Saturday, June 6, 2020 04:49 I think what you mean is this: PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 END-PERFORM 1050-LOOP. IF FIRST-NAME NOT = "ROBERT" GO TO 1059-EXIT END-IF IF TYPE NOT = 195 GO TO 1059-EXIT END-IF IF NOT SO-ON GO TO 1059-EXIT END-IF IF NOT SO-FORTH GO TO 1059-EXIT END-IF PERFORM 1050-SUCH-AND-SUCH END-PERFORM 1059-EXIT. EXIT. In structured programming, it is perfectly acceptable to use GO TO within a paragraph. It is NOT acceptable to use GO TO outside of a paragraph. --- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges <robhbrid...@gmail.com> wrote: > I realize this is a bit of a change in subject (and it's not as if we need > yet another one), but I avoid this construction. My phobia is based on an > extreme example: In their zeal never to use GOTOs, I've frequently seen > programmers write paragraphs like this: > > PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X < 1000 > IF FIRST-NAME NOT = "ROBERT" > IF TYPE = 195 > IF SO-ON > IF SO-FORTH > EXECUTE 1050-SUCH-AND-SUCH > END-IF > END-IF > END-IF > END-IF > END-IF > > Gives me a headache to try to evaluate that. Much better, in my opinion, > to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: > > PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1059-LOOP. > IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. > IF TYPE <> 195 GOTO 1059-LOOP. > IF NOT SO-ON GOTO 1059-LOOP. > IF NOT SO-FORTH GOTO 1059-LOOP. > EXECUTE 1050-SUCH-AND-SUCH > 1059-LOOP. > > Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the > syntax, I probably got part of it wrong nonetheless, and I'll bet there are > easier ways to do it nowadays. In REXX, for example, they have the ITERATE > statement: > > do jc=1 to 99 > if x>99 then iterate > if firstname='ROBERT' then iterate > if type<>195 then iterate > if \soon then iterate > if \soforth then iterate > call suchandsuch > end > > However you do it, I vastly prefer skip-to-next-item over nested Ifs. But > I confess that one single nested IF is not going to give me a headache; I > just react when I see one. Not your fault :). > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gibney, Dave > Sent: Friday, June 5, 2020 16:17 > > Using OP > IF TVOLL (IND1) NOT = HIGH-VALUE > AND SMOD (IND1) = 'B' OR 'R' > > I would do > IF TVOLL (IND1) NOT = HIGH-VALUE > IF SMOD (IND1) = 'B' OR 'R' > Do the stuff ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN