Re: interesting use of NEXT SENTENCE vs. CONTINUE


"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
news:d859v3$2a99$1@xxxxxxxxxxxxxxxxxxxxxxx
> Sorry about that; messed up in the editing. Here's a second try:
>
> "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
> news:3gmlfjFd8f0qU1@xxxxxxxxxxxxxxxxx
> >
> > "Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
> > news:d84fb0$1qbd$1@xxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
> > > news:3gk48iFcotqsU1@xxxxxxxxxxxxxxxxx
> > > > It isn't. And it has been dropped from the 02 standard (not that I
> > really
> > > > care about that...)
> > >
> > > Well... not exactly. Its use is *disparaged by* the '02 standard, but
> > > support for it in compliant compilers is still required by that same
> > > standard.
> >
> > An important but subtle distinction. Thanks for clarifying that Chuck. I
> > understood it had been dropped form a previous post in this thread.
> >
>
> To clarify further: the 2002 standard puts NEXT SENTENCE in the "archaic"
> list. The proposed 2008 COBOL standard makes no change in that status.
It
> can stay "archaic" through any number of revision cycles to the standard.
>
> However, for it to disappear altogether, it has to move from "archaic" to
> "obsolete" for one full revision d cycle, and only then can it be dropped
> from the standard.
>
> Presuming that the process of developing and approving a COBOL standard
> seems to take around six years with no "hitches", and presuming that
process
> doesn't get streamlined further, the *earliest* it could move from
"archaic"
> to "obsolete" would be late 2014, and from "obsolete" into the sunset
> sometime after 2020.
>

Wow! I guess I must have been writing 2020 COBOL for the past 30 years...
<g>

> > To digress for a moment, in Odene Dayse I worked on sites where ALTER
was
> > used as a matter of course. It was extremely efficient and, in machines
> > with limited memory, was MUCH better than using IF for a first time
> switch,
> > for example. With IF, the first time condition is tested for every
> iteration
> > of the code; with ALTER, once only...(and IF required other machine code
> > overheads, which ALTER didn't.)
>
> I've heard that it was very effective on certain architectures, though I
> would not necessarily agree that limited memory was a significant
criterion
> in all architectures. On certain limited-memory machines ALTER is much
> slower than a first-time switch.
>

Now THAT I find VERY interesting. I cannot conceive of an unconditional
branch being slower than a compare on ANY architecture; can you elaborate
what architecture and how/why a branch was slower than comparing two
operands?

It is like switching the points on a railway line.

Takes some effort to move the lever but you don't have to do it very often.

Actually the 'effort to move the lever' is simply loading another address
into the operand of the branch instruction, and that would normally be
faster than comparing two operands which are in memory, even if optimized
direct or indirect addressing is used.

I have worked on 6 of the 7 major mainframe architectures (IBM and the
UNCH - Burroughs, Univac, NCR, CDC, and Honeywell, and ICL) and all the
ones I've worked on show an unconditional branch as the fastest executing
non register-to-register instruction in their set.
Even the Intel architecture has a branch (Jump) as faster than anything else
I can find.

I don't want to labour this because it really isn't that important, but I
would dearly LOVE to know what architecture has a compare as faster, and the
reason for it.

> One of the worst programs I've ever had the misfortune to attempt to debug
> was a cross-reference utility for COBOL, written in COBOL by a Fortran
> programmer who had just discovered the ALTER statement.
>
> > We had conventions for using it and it wasn't just sprinkled willy nilly
> > through our code. When it fell into disfavour, and, eventually, disuse,
> none
> > of us could figure why... We had never had a problem with understanding,
> > using, or debugging it.
>
> The use of ALTER implies the use of GO TO, and those who disparage GO TO
> like ALTER even less for that reason alone. It's a bit tough to tell,
> particularly in poorly-written COBOL code, exactly where "GO TO."
actually
> ended up GOing TO.

Yes, I think I covered this with loonies and matches...:-) Any powerful tool
has the capacity to hurt. That's why we don't let kids play with them. But,
once they are mature and responsible enough to understand the dangers, the
same kids who were using the Black and Decker to make holes in the furniture
a few years ago, are now making letter boxes and bookcases and so on...
Let's exclude 'improper use' and 'poorly-written' from this discussion. We
can definitely agree about those...

We've all moved away from GO TO , and with good reason.
With ALTER, it didn't have to 'go' anywhere... :-) the address could be left
null until you wanted to use it.

>
> Put more succinctly, in two words: Blame Dijkstra!
>

Or thank him, depending on how you look at it.

> > Installation standards should encourage a common style that all agree
with
> > for axiomatic reasons. When standards are used in this way they actually
> > help programmers, rather than stifling their thought and creativity.
>
> I wholeheartedly agree. One issue, though is what is "axiomatic" as a
Good
> Idea in one operating environment may be a performance catastrophe in
> another. One implication of "axiomatic" is "taken for granted", and it
> would be appropriate if the *reasons* for the rule in that particular
> environment were explicitly available alongside the rule itself;
"everybody
> knows" is not really an appropriate justification!

I agree. I use "axiomatic" to mean "self-evidently true". If it has to be
explained, it is NOT self evidently true. Once people come to understand
something (such as the performance implications you speak of), THEN it is
axiomatic and no longer requires explanation. I am all in favour of people
being trained and mentored and given understanding of the environment and
how it works. As understanding grows, good standards can be agreed upon as a
natural spin-off.

I see standards as being a helpful guide to new people joining the team. The
existing team already know why they do things the way they do.

What I was trying to get away from is (just one example, there are, sadly,
many more...) the case where: "You will not use NOT in a condition" is a
standard. Instead, run a session on basic logic and Boolean Algebra so that
people are not baffled by negated conditions when they encounter them, and
also so they can realise that for all it's English-like qualities, COBOL is
still a computer programming language, and cannot tolerate the slack use of
logical operators that standard English can... ("You can't think in
colloquial English and write good COBOL.")

Pete.



.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... the 2002 standard puts NEXT SENTENCE in the "archaic" ... The proposed 2008 COBOL standard makes no change in that status. ... > To digress for a moment, in Odene Dayse I worked on sites where ALTER was ... > for axiomatic reasons. ...
    (comp.lang.cobol)
  • Re: Method to force keeping of source
    ... It appears to me that your wish is that the COBOL standard should prevent ... environment for the compiler or in the execution environment. ... > implementor defined is one of the problems as I look at the situation as ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... Here's the problem with OO COBOL - it is still very incomplete.. ... realized that OO was incomplete without support ... It's about two years ago a former, retired M/F Manager, (not Bill Klein ... Micro Focus above - but he was referring to the fact that Standard ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... There are users of OO COBOL; they are just far fewer than either the vendors ... whether from the same vendor or not. ... disagreed with you that XML should be supported *first* by the OO features ... > being spent by J4 to provide these facilities through a standard that will ...
    (comp.lang.cobol)
  • Re: Program templates as Object Classes
    ... some aspects of OO COBOL have grown and evolved since then. ... Classes from ANY vendor on ANY platform can be "wrapped" (provided the ... 2002 standard implemented. ... I really don't care what J4 or WG4 or SG-1 ...
    (comp.lang.cobol)