| Pete Dashwood 2007-07-31, 6:55 pm |
| 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
>
>
>
>
|