Re: EXIT PERFORM Help, please

From: Pete Dashwood (dashwood_at_enternet.co.nz)
Date: 11/18/04 

Date: Thu, 18 Nov 2004 15:56:48 +1300

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9L0WVN9eflB@jpberlin-l.willms.jpberlin.de...
> . On 17.11.04
> wrote dashwood@enternet.co.nz (Pete Dashwood)
> on /COMP/LANG/COBOL
> in 300ohcF2r3p5gU1@uni-berlin.de
> about EXIT PERFORM Help, please
>
>
> PD> I had a construct that said something along the lines of :
> PD>
> PD> *============Section of code that does something =================
> PD> start-of-section section.
> PD> sos000.
> PD> set not-finished to TRUE
> PD> perform until finished
> PD> (lots of good stuff)
> PD> end-perform
> PD> .
> PD> sos999.
> PD> exit.
> PD> *===============================
> PD> Now, within the good stuff, if I encounter certain conditions, I want
> PD> to finish the whole kaboodle. So I set finished to TRUE and EXIT
> PD> PERFORM. (My question relates to whether I need to set finished to
> PD> TRUE)
>
>
> Why don't you raise the other question: if your condition comes
> TRUE, what do you need the EXIT PERFORM for?

I dunno... I thought it was so I could stop the perform?
>
>
> PD> The program works fine with EXIT PERFORM, and I have used it in a
> PD> couple of places within the (fairly complex) code that is executed
> PD> under the PERFORM.
> PD>
> PD> MY question is this:
> PD>
> PD> Does EXIT PERFORM finish ALL cycles of the PERFORM, or does it just
> PD> finish the current cycle?
>
> The Fujitsu manual is not so clear about it, but since they also
> provide the option "EXIT TO TEST OF PERFORM", which passes control to
> the evaluation of the loop entry (or exit) condition, it should be
> clear that EXIT PERFORM without the TEST phrase acts like the 2002
> standard describes it: "The execution of an EXIT PERFORM without the
> CYCLE phrase" -- which corresponds to Fujitsu's TO TEST OF -- "causes
> control to be passed to an implicit CONTINUE statement immediately
> _following_ the END-PERFORM phrase that matches the most closely
> preceding, and as yet undeterminated, inline PEFORM statement".
>

(<tee hee> I made this post so I wouldn't have to read the manual... )
However, I have examined your extract above, and I believe I comprehend it.
Thanks.

>
> PD> If it finishes ALL cycles and transfers to the statement FOLLOWING
> PD> the END-PERFORM (rather than to the END-PERFORM itself), then there
> PD> is no need for me to run a finish flag whose only real purpose is to
> PD> tell the PERFORM when to stop.
>
> I would do it the other way round: set the flag, and drop the EXIT
> PERFORM.
>

Diversity is a wonderful thing.

> Specifying PERFORM UNTIL FINISHED you suggest to the reader that
> after that loop the condition FINISHED is true, but now you intend to
> leave that assertion undeterminated.

No, I set it before I take the EXIT PERFORM, for exactly the reasons you are
concerned about.

And we both realise that that is not really the most sensible solution.
Actually this code is a little bit "contrived"... but it serves the purpose.

Depending on how deep a reader
> will go into that program, he may assume that the condition is
> certainly true, and may introduce later a change which relies on that
> condition.
>
Yes, he may and it would be OK...

> Also, I understand from your description that FINISHED is just a
> flag for the purpose of controlling the loop. Isn't there some
> condition in the data being processed which end the loop? What object
> does exist repeatedly, so that a repetition statement is called for?
> Isn't it better to specify the limits to this repetitive _data_
> _object_ as a condition of this data object?
>

"Better" is too strong here, Lueko, because the code is contrived (It isn't
quite "real"). I neither agree nor disagree with your opinion here.
Sometimes it is better, but not always... I take each case on its merits and
consider all the factors, as I'm sure you do too...
>
<snip>

Thanks for the response.

Pete.

Relevant Pages

  • Re: Infinite Loops and Explicit Exits
    ... > CS> One of these proposals relaxes the current restriction that an EXIT ... > termination of the loop is not visible at that point. ... > terminating condition is visible in that context. ... > You now want to allow this remote procedure, ...
    (comp.lang.cobol)
  • Re: two questions about thread
    ... The best way to do this is by using a flag or event that the child-threads ... monitor each loop. ... flag is set, they exit themselves. ... > the lock is ever released. ...
    (comp.lang.python)
  • Re: Break a loop with a button
    ... I would have the button set a flag and the loop check for the flag. ... and then exit in a controlled means. ... Time hit to the loop will only be the if statement that checks the flag. ... No windows calls and all of the overhead for that. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Break a loop with a button
    ... I would have the button set a flag and the loop check for the flag. ... and then exit in a controlled means. ... Time hit to the loop will only be the if statement that checks the flag. ... No windows calls and all of the overhead for that. ...
    (alt.comp.lang.borland-delphi)
  • Re: R> DROP in GForth
    ... complex control flow structure. ... that causes you to exit the loop. ... It provides a single exit. ... that leave immediately if the flag is true, ...
    (comp.lang.forth)
Loading