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
