Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)

Sorry, the post above this was made in error. Please ignore it. It may or
may not be updated and posted later.

Thanks,

Pete.
--
"I used to write COBOL...now I can do anything."

TOP POST nothing new below...

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5h97ekF3hv8npU1@mid.individual.net...
>
>
> "LX-i" <lxi0007@netscape.net> wrote in message
>  news:4MWdnUDRHLIlPTPbnZ2dnUVZ_h2pnZ2d@co
mcast.com... 
>
> Now, see, that's a really good question. So much more interesting than
> simply arguing about the relative merits of ALTER.:-)
>
> I'll attempt to give you an answer that excludes the things already
> covered,
> like first time thru switches, although these are worth looking at for a
> moment, in passing...
>
> If you put an IF statement at the start of  a piece of code (maybe even a
> SECTION... :-)) that says:
>
> IF FIRST-TIME-THRU
>     SET NOT-FIRST-TIME-THRU TO TRUE
>     PERFORM TAKE-THE-LID-OFF
> END-IF
> PERFORM POUR-A-MEASURE
> ...
>
> And this section gets executed  (by PERFORM or GO TO) 10 million times,
> you
> are doing a compare that can never be true 9,999,999 times. Nowadays, that
> isn't such a big deal, but there was a time when it was...
>
> If, instead, you were to formulate it as:
>
> FIRST-TIME.
>      GO TO REMOVE-LID.
> REMOVE-LID.
>       ALTER FIRST-TIME TO PROCEED TO OTHER-TIMES
>       PERFORM TAKE-THE-LID-OFF.
> OTHER-TIMES.
>       PERFORM POUR-A-MEASURE
> ...
>
> You have removed 9,999,999 instructions from the execution. Now it just
> does
> a branch instead of a compare. On most platforms this is the quickest
> instruction in the set. (Almost invariably, a single machine instruction).
> Compares on some machines can be horrific, generating up to a dozen
> machine
> instructions (especially if data conversion is required before the compare
> can take place.)
>
> Can you honestly say that the second example above is much more complex
> than
> the first? Or so "horrendous" it couldn't be maintained by a trained COBOL
> Programmer? :-)
>
> It doesn't even take much more writing, yet it saves 9,999,999 compare
> instructions, and is maybe 12 times more efficient than your IF switch....
>
> Some people would call that "good" :-)
>
> YOUR QUESTION:
> 
>
> It isn't really about designing ALTER, it is about approaching things in a
> different way.
>
> I'll rephrtase your question thus:
>
> "So, what kind of mindset do you need to deal with COBOL that
> modifies itself as it runs?"
>
> MY ANSWER:
>
> Something close to the old Assembler mindset where instructions in memory
> were frequently modified (not just the Branch instructions) to save time
> and
> space.
>
> You need a non-linear mindset that is imaginative and intelligent. What
> DeBono calls "Lateral" thinking,  but not only must you think "outside the
> box" you must do it "on the hop".   Some people really enjoy this way of
> working and are very good at it, most do not and are not... It is
> definitely
> not for the faint-hearted...(That's what I meant when I said "the wimps
> won
> the day") :-)
>
> Now let's look at a few cases where the ALTER solution is probably the
> most
> elegant one available...
>
> Consider a dynamic process where a series of  "stages" are executed in a
> variable sequence, but only as the execution proceeds, can the subsequent
> stage requirements be decided. Normally, we would write a program that
> controlled the flow, tracked each item through each stage,  and could
> cater
> for every possible "path". That would be linear.
>
> But what about when the "path" is actually a network and the possibilities
> are approaching infinity? We have little choice but to cause the stages to
> be switched as we proceed through them. "Fast switching"...rings a bell...
> sure there used to be something in COBOL that could do that...Oops! Not
> any
> more.
>
> What about a state transition processor?  You have a bunch of, say, 700
> odd
> keywords for COBOL and you need to parse a COBOL source program. You COULD
> lookup every word the parser encountered against the Reserved word list.
> That would be linear. (It would also be pretty slow).
>
> Suppose instead you had a series of transition diagrams
>
>
>
>
>
>
>
>
>
> be decided. . There are dependencies and there are exceptions. If we call
> the "stages" (they could be machines on a shop floor, software functions
> or
> objects,  people proceeding through immigration, whatever your
> imaginative,
> intelligent mind can come up with...:-))  arrive that conflict with each
> other. It is a dynamic process with different areas of the organisation
> all
> independently submitting and correcting requirements. Let's say we have a
> machine that cuts corrugated cardboard or carpet, or linoleum from huge
> rolls, according to the sizes that people order. An order arrives, start
> cutting... Well, you COULD do that, but it it would be pretty wasteful.
>
>
>
>
>
>
>
> Ghastly, or
> 
>
>
>