Re: Perform forever


"Upon mine honour, I have done my best."

It is a difficult and tenuous concept to explain why I consider FOREVER
necessary.

The fact is that I do, and like you stated, I don't care to argue it
further. :-)

(And it isn't really important; it's only computer programming...)

Pete.

"jce" <defaultuser@xxxxxxxxxxx> wrote in message
news:5rOTe.28744$xl6.14803@xxxxxxxxxxxxxxxxxxxxxxxxxx
>
> "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
> news:3o8ig9F4oo2kU1@xxxxxxxxxxxxxxxxx
>> "jce" <defaultuser@xxxxxxxxxxx> wrote in message
>> news:NbBTe.7438$4i6.771@xxxxxxxxxxxxxxxxxxxxxxxxxx
>>>
>>>
>>> "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
>>> news:3o7s0mF48ukqU1@xxxxxxxxxxxxxxxxx
>>>>
>>>> "Joe Zitzelberger" <joe_zitzelberger@xxxxxxxxxx> wrote in message
>>>> news:joe_zitzelberger-A059E5.00063607092005@xxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>>
>>>>> Well, you really don't mean it should continue indefinitely. You
>>>>> clearly state that you want it to stop with (itsa-tag OR finished).
>>>>> That is a totally reasonable exit condition.
>>>> I see what you're saying, but actually I DO want the controlling
>>>> PERFORM to keep going indefinitely.
>>> Except when you EXIT it, no doubt.
>>
>> No, I explained that below. When I exit it I don't care whether it keeps
>> running or not...(The fact is that the nature of the hardware it is
>> running on, is such that it will stop running once it is exited, but
>> supposing it wasn't? From my point of view whatever happens to it after I
>> exit it is irrelevant...until the next time I need to use it...)
>
> In your example, after you EXIT, it's no longer the controlling PERFORM
> so it's not "running" or am I missing something? Sure you can enter the
> loop again....
>
>> I would agree that it is a fine and philosophical point, rather than a
>> computer programming practice.
>
> I don't pretend to understand it, but it doesn't bother me so much that I
> care to argue.
> I've made comments, asked questions and even made a quatement (that's a
> statement I'm not confident in) :-) I'm always interested in the way
> different people see different problems (well solutions I should say).
>
>>>> There are other exit conditions that the code does not currently cater
>>>> for; like output buffer overflow, for example. I'll add them once what
>>>> I have is working. I like to 'evolve' code, rather than just write
>>>> it...
>>>>
>>>> It just so happens that I will exit from on it on the stated
>>>> conditions. (The conditions could change, and there could be other
>>>> instances where I need an indefinite PERFORM that will work until some
>>>> event occurs, for example...)
>>>
>>> I *never* understood the need for a do forever, nothing is done forever.
>>> So it's like life?
>> Consider a 'default' process. You want it to proceed until some event
>> occurs, but that event may never occur.
>
> That statement there is still not a do forever... it's a do until event
> ....the event not occurring is happenstance unless the event is impossible
> (1=2) - which as we know is not true for sufficiently large quantities of
> 1.
>
>> Or other events which require varying responses may occur, and some of
>> these may require exiting the process and some of them may not.. This is
>> the major difference between interrupt driven programming and the normal
>> sequential processing we do with procedural code. (In the case in point,
>> it is a sequential procedural process and it really doesn't matter
>> whether the PERFORM keeps its control forever or until it is exited; but
>> there might be other occasions when it DOES matter, in other programs.)
>
> I was under the impression that "infinite loops" use "polling" and that
> part of the charm of "interrupts" is that they get rid of the wasted loop.
> I can understand in code like Entropy polling or Service rendering...but
> they nearly _always_ have a shutdown mechanism....even my USB hardware
> wants to be removed properly!
>
>>> I think I'm going to live forever until some other sudden event comes
>>> along and runs me over - but I'm not sure where that will happen.
>> And probably just as well... (Not that it will happen, but that you don't
>> know when...:-).
>>
>> It's not quite the same. Although we don't know when, we do know with
>> certainty that our lives must end. That is not necessarily the case with
>> the PERFORM.
>>
>> That is the nub of what I'm trying to convey. I don't know how long the
>> PERFORM needs to run, so I can't know when it should be terminated. (In
>> this instance it will depend on how many lines there are following the %8
>> tag, and that will vary as different tag sets are processed...) So, the
>> approach is to run it forever and quit when you've had enough.
>
> Well actually, by your definition it will end after a certain number of
> lines following the %8 tag...and you cannot run forever AND quit
> That's almost as daft as the ending of Highlander :-)
>
> JCE
>
>



.

Relevant Pages

  • Re: Report enhancements
    ... I don't agree that the functionality of GOBACK is directly and completely ... reflected within EXIT, even in '02 COBOL. ... Whatever syntax can be constructed for getting into and out of a "perform ... the use of "forever perform" syntax to the in-line subset. ...
    (comp.lang.cobol)
  • Re: Perform forever
    ... >>> I see what you're saying, but actually I DO want the controlling PERFORM ... When I exit it I don't care whether it keeps ... >>> need an indefinite PERFORM that will work until some event occurs, ... That statement there is still not a do forever... ...
    (comp.lang.cobol)
  • Re: Perform forever
    ... >>> That is a totally reasonable exit condition. ... >> need an indefinite PERFORM that will work until some event occurs, ... > I *never* understood the need for a do forever, ...
    (comp.lang.cobol)
  • Unable to close Outlook 2000
    ... When I Exit my Outlook 2000 either through <Exit and ... logoff. ... <Please, wait while outlook exits> ... stays forever unless I ...
    (microsoft.public.outlook)
  • Current TV scheds high-school football docuseries
    ... FOREVER" ON THURSDAY, ... Compelling Nine-Episode Series Chronicles the Football Team at Long ... game shows and recycled programming ... Peabody Award, The Livingston Award, the Alfred I. duPont-Columbia ...
    (rec.arts.tv)