Perform Thru/Go to vs. Perform - Compile Speed
LX-i
We've seen something strange at work and I thought I'd ask for
experienced opinions. We had a program that was a maze of Perform Thru
and Go to loops - we printed it out, put Ragu on it, and we all had lunch!
Anyway, one of our programmers untangle the mess, and ended up with a
very structured program that utilized Perform exclusively, except to "Go
to" the ending paragraph. The program compiled noticeably faster, with
an equivalent load on the machine both times.
Has anyone else experienced this? Have any of you object-code divers
noticed whether a Perform-structured program is any more "efficient"
than a Perform Thru/Go to structured program?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi...@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William M. Klein
I *know* that IBM's current compilers will be MUCH faster compiling (and
POSSIBLY running) a structured program with the OPT compiler option (but the
load module may be larger).
Micro Focus has a compiler option "trickle"(or something like that) which allows
a "structured" program to compile faster (and possible run faster).
My GUESS is that this is VERY compiler-specific.
--
Bill Klein
wmklein <at> ix.netcom.com
"LX-i" <lxi...@netscape.net> wrote in message
news:108r50e...@corp.supernews.com...
LX-i
> Can you tell us which compiler?
Sure - we're using the Unisys 2200 UCS COBOL compiler that came with
(and under) HMP IX 8.0. :)
> I *know* that IBM's current compilers will be MUCH faster compiling (and
> POSSIBLY running) a structured program with the OPT compiler option (but the
> load module may be larger).
>
> Micro Focus has a compiler option "trickle"(or something like that) which allows
> a "structured" program to compile faster (and possible run faster).
>
> My GUESS is that this is VERY compiler-specific.
What made it obvious is that we have several programs that appear to hit
a "wall", and take significantly longer to compile than most others.
This program was one of those - but, after restructuring, it compiles in
1-2 minutes (which isn't bad, considering the iron (or lack thereof) we
have) like the other well-behaving programs.
You're saying that some compilers have an "option" that would make this
happen? Maybe I need to dig into ours and see if we've got something
like that. :)
Arnold Trembley
docd...@panix.com
Arnold Trembley <arnold....@worldnet.att.net> wrote:
[snip]
>Way back in the old days there were "tricks" you could use with IBM
>COBOL (pre-OS/VS COBOL) to make the program compiler faster.
I believe that is why I was taught to never leave a blank line and instead
always use a comment line with an asterisk in column 7; the compiler will
check each position on the card... errrrr, line if it is blank but will
just skip to the next line when it encounters the asterisk, thereby saving
all the time/money spent checking the remaining 72 blank positions.
(Of course, since disk was so expensive some considered it profligate to
format the source with any kind of separators at all... some considered
that I was pushing the limit with my demands that a comment-card/blank
line be included for every five lines of code (or 'logical' break in
complex conditionals).)
DD
Howard Brazee
On 26-Apr-2004, LX-i <lxi...@netscape.net> wrote:
> Anyway, one of our programmers untangle the mess, and ended up with a
> very structured program that utilized Perform exclusively, except to "Go
> to" the ending paragraph. The program compiled noticeably faster, with
> an equivalent load on the machine both times.
Getting rid of all GO TO sometimes turns on optimizing options. But in this
case, I bet the efficiency was simply a result of the logic being better
organized. Good spaghetti code tends to be faster than good structured code.
But good code tends to be faster than bad code.
I suspect that while structuring the code, some inefficiencies were adjusted.
Russell Styles
"Howard Brazee" <how...@brazee.net> wrote in message
news:c6lo8r$hcr$1...@peabody.colorado.edu...
> What made it obvious is that we have several programs that appear to hit
> a "wall", and take significantly longer to compile than most others.
> This program was one of those - but, after restructuring, it compiles in
> 1-2 minutes (which isn't bad, considering the iron (or lack thereof) we
> have) like the other well-behaving programs.
It is possible that the size and complexity of the old version might
have
pushed some internal limit close to the edge, thereby turning on some sort
of behavior that allows the larger program to compile (thrashing?),
but slows things down.
I have seen this with Microfocus 16 bit with a 13,000 line program. If
I
use "XM", it compiles a good deal faster. Even now I can tell that it
compiles faster with XM than without (it is hard to time due to much faster
pc).
For those not familar with Microfocus, XM allows the use of extended
memory
instead of just 640K.
If you increased the memory available to your compiler (or some other
tuneable) would
the old program compile faster?
Jeff Lanam
>Good evening (or morning, afternoon, or night)...
>
>We've seen something strange at work and I thought I'd ask for
>experienced opinions. We had a program that was a maze of Perform Thru
>and Go to loops - we printed it out, put Ragu on it, and we all had lunch!
>
>Anyway, one of our programmers untangle the mess, and ended up with a
>very structured program that utilized Perform exclusively, except to "Go
>to" the ending paragraph. The program compiled noticeably faster, with
>an equivalent load on the machine both times.
My guess is that in the old code, the compiler was spending a lot of
time doing control flow analysis. Most code generators build a
directed acyclic graph of the basic blocks of the program and try to
figure out the flow of execution through the program, to do
optimizations. PERFORM THRUs, particular if they overlap, make for a
messy graph. Structured code is easier to optimize. Probably runs
faster, too.
Jeff Lanam HP NonStop COBOL Project INCITS/J4
NonStop Enterprise Division
Hewlett-Packard
LX-i
>
>
> LX-i wrote:
>
>> (snip) What made it obvious is that we have several programs that
>> appear to hit a "wall", and take significantly longer to compile than
>> most others. This program was one of those - but, after restructuring,
>> it compiles in 1-2 minutes (which isn't bad, considering the iron (or
>> lack thereof) we have) like the other well-behaving programs.
>
>
> Given that both programs produce the same output, I can't imagine why
> the structured program compiles significantly faster than the spaghetti
> version. You would have to know how the compiler works. I know I would
> much rather read the structured version.
Hear hear... :)
> Way back in the old days there were "tricks" you could use with IBM
> COBOL (pre-OS/VS COBOL) to make the program compiler faster. It sounds
> crazy, but I remember a Honeywell programmer saying he had to submit his
> COBOL compiles for overnight processing because a single compile could
> take hours. On the z900 my compiles seem to take less than 15 seconds
> normally.
That's the kicker. We've only got a 30 MIP machine, with a
less-than-usual memory configuration. If we have more than 3 compiles
going, we hit another "wall" where they take about 4 times as long. I
have a program with 6,500 lines, the majority of which is code which
plows through a database. It compiles, links, and is copied to
production in less than 2 minutes. These others can take 40 minutes.
> What about runtime performance? Do both versions of the compiled
> programs take as long to execute?
Haven't had a chance yet to evaluate that... However, I know that if it
performs wrong, it's a lot quicker to diagnose and fix the problem. :)
LX-i
> On 26-Apr-2004, LX-i <lxi...@netscape.net> wrote:
>
>
>>Anyway, one of our programmers untangle the mess, and ended up with a
>>very structured program that utilized Perform exclusively, except to "Go
>>to" the ending paragraph. The program compiled noticeably faster, with
>>an equivalent load on the machine both times.
>
>
> Getting rid of all GO TO sometimes turns on optimizing options.
Of course, we didn't get rid of -all- Go to's... :) But then, wouldn't
optimizing make the compile run longer?
> But in this
> case, I bet the efficiency was simply a result of the logic being better
> organized. Good spaghetti code tends to be faster than good structured code.
> But good code tends to be faster than bad code.
>
> I suspect that while structuring the code, some inefficiencies were adjusted.
That may be - there was some really weird stuff that it was doing. (It
probably wasn't weird when it was originally coded, but somehow missed
getting brought up to speed.)
Peter Lacey
> On 26-Apr-2004, LX-i <lxi...@netscape.net> wrote:
>
> > Anyway, one of our programmers untangle the mess, and ended up with a
> > very structured program that utilized Perform exclusively, except to "Go
> > to" the ending paragraph. The program compiled noticeably faster, with
> > an equivalent load on the machine both times.
>
> Getting rid of all GO TO sometimes turns on optimizing options. But in this
> case, I bet the efficiency was simply a result of the logic being better
> organized. Good spaghetti code tends to be faster than good structured code.
> But good code tends to be faster than bad code.
>
>
I don't see why simply changing the code to goto-less would make the program
compile faster. There would be roughly the same number of statements, I'd
guess. In fact, since goto-less = fewer labels, I'd have thought that the
compiler would have had to work harder just to determine its own labels (since
object code is loaded with explicit transfer instructions it has to have the
equivalent of labels). But since we'd be talking a few hundred milliseconds at
best it shouldn't make that much of a difference. If, however, the recoding
significantly revised the program as a whole then there might well be a noticeable
difference.
I would question the statement that "Getting rid of all GO TO sometimes turns on
optimizing options". Code can be significantly optimized with or without goto's.
If some vendor has written a compiler that does this ("Getting rid of ...")
without being intructed to optimize, I'd question that vendor's ethics. It smacks
to me of behaviour modification! Any compiler writer must support the standard
whether it likes it or not; goto's are not yet banished; punishing programmers
that write with goto's is not permitted!
PL
Joe Zitzelberger
Peter Lacey <la...@mb.sympatico.ca> wrote:
The known constructs -- for example a "Perform X times {statements}
End-Perform" are such that the compiler need only emit a mostly static
prolog, compile the contained statements, then emit a mostly static
epilog. Once emitted, the compiler need not maintain any state for the
perform statement.
The same construct, written using labels and goto causes the compiler to
track those labels for the entire life of the compile, as they remain
valid targets.
Enough labels and gotos to track and it might start bogging down. If the
compiler keeps a map to aid in optimization, the goto-less program
becomes a simple, heirarchial tree -- the goto-laden version becomes a
jumble of pasta.
The first rule of compiler optimization -- If you cannot guarentee
identical results, don't change it.
Following that rule would sometimes cause a compiler to look at a more
complicated map of the program and say -- 'nope, I'm not touching it'.
This is not to say that in all cases that would apply. Many compilers
have post-object code generation optimizers are unconcerned with what
the source looked like.
Lueko Willms
schrieb la...@mb.sympatico.ca (Peter Lacey)
auf /COMP/LANG/COBOL
in 4090222C...@mb.sympatico.ca
ueber Re: Perform Thru/Go to vs. Perform - Compile Speed
PL> goto's are not yet banished; punishing
PL> programmers that write with goto's is not permitted!
Those programmers punish themselves by using GOTOs. Unless they
complement its use with the corresponding COME FROM.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt." - Leo Trotzki (27. Januar 1932)
Peter Lacey
>
>
> PL> goto's are not yet banished; punishing
> PL> programmers that write with goto's is not permitted!
>
> Those programmers punish themselves by using GOTOs. Unless they
> complement its use with the corresponding COME FROM.
>
> Yours,
> Lüko Willms http://www.mlwerke.de
Knowing full well the firestorm that I'm going to incur: NONSENSE. Programs
with GOTO's - IF PROPERLY WRITTEN - are equal in quality, maintainability and
every other measure to GOTO-less programs.
I have written programs - and maintained programs written by others - in both
styles. Therefore I feel qualified to make the above statement. The key
postulate is "properly written".
PL
Howard Brazee
On 29-Apr-2004, Peter Lacey <la...@mb.sympatico.ca> wrote:
> Knowing full well the firestorm that I'm going to incur: NONSENSE. Programs
> with GOTO's - IF PROPERLY WRITTEN - are equal in quality, maintainability and
> every other measure to GOTO-less programs.
>
> I have written programs - and maintained programs written by others - in both
> styles. Therefore I feel qualified to make the above statement. The key
> postulate is "properly written".
Without arguing your premise (which I don't agree with)...
Your postulate is sufficient to make the whole statement useless. We can say
that about anything.
But we're talking about the real world here. Structured methodology makes it
much easier to write code that is much closer to the ideal of being PROPERLY
WRITTEN. Shops with structured methodology standards are much more likely to
have programs that are closer to being PROPERLY WRITTEN.
Michael Wojcik
In article <4090222C...@mb.sympatico.ca>, Peter Lacey <la...@mb.sympatico.ca> writes:
>
> I don't see why simply changing the code to goto-less would make the program
> compile faster. There would be roughly the same number of statements, I'd
> guess.
I suspect Jeff Lanam is correct - the structured program requires a
lot less graph processing in the compiler. Modern compilers on modern
hardware spend relatively little of their time in lexical analysis
(which is where number of source lines would be most relevant, in
terms of CPU cycles); most of it is in operating on the internal
program representation, which is usually a directed acyclic graph.
(Of course number of source lines will affect memory consumption and
file I/O, which may dominate in some cases.)
Conceptually, a typical compiler analyzes source to tokenize it and
remove stuff the compiler isn't interested in (like comments and
inconsequential whitespace). That's passed to a parser, which builds
an internal representation of the program. In concept that's a tree
(where for example you might have an "ADD" node with child nodes for
the operands), but typically it's actually a directed acyclic graph -
a tree where some branches are attached at more than one place, so
common code elements can be reused.
With spaghetti code, building and refining the DAG can get very
complicated, because there aren't so many neat separations between
areas of the graph. So the compiler has to spend more time wandering
around in the graph figuring out how to best fit things together -
particularly if it's doing any optimization.
Also, a complicated graph representing spaghetti code is likely to
have poor locality of reference: the compiler will jump around in it
rather than mostly working in one section, then in another, and so
on. That means more cache hits and potentially more paging to and
from virtual memory, which can be huge performance killers.
--
Michael Wojcik michael...@microfocus.com
Company Secretary Finance Manager
1) Half-grey haired executives.
2) Must be waist-deep in their field of activities.
3) Must be having the know-how and the do-how of the latest
developments in their respective fields.
-- from "Appointments Vacant" section of Business India
Richard
> Knowing full well the firestorm that I'm going to incur: NONSENSE. Prog
> rams
> with GOTO's - IF PROPERLY WRITTEN - are equal in quality, maintainability
> and
> every other measure to GOTO-less programs.
>
> I have written programs - and maintained programs written by others - in
> both
> styles. Therefore I feel qualified to make the above statement. The key
>
> postulate is "properly written".
I take issue with that. It is entirely possible, as you say, to have
one set of programs that uses GO TO and another set that does not
where the two sets are equal in maintainability and quality.
That statement does not exclude a third set which is more maintainable
and of better quality.
Having worked with all three styles I feel even better qualified
;-)
The reason that I moved (many many years ago) to eliminating GO TOs
entirely from my code is that there are programming faults that can
occur when using GO TOs that are impossible for the compiler to flag
and that may go undetected in testing. In some cases it may be
possible to develop an idiom in which an automatic checking program
can flag all such faults - Judson did this decades ago, but I
completely dislike the rather stilted style that must be followed.
Peter Lacey
> On 29-Apr-2004, Peter Lacey <la...@mb.sympatico.ca> wrote:
>
> > Knowing full well the firestorm that I'm going to incur: NONSENSE. Programs
> > with GOTO's - IF PROPERLY WRITTEN - are equal in quality, maintainability and
> > every other measure to GOTO-less programs.
>
>
>
> Your postulate is sufficient to make the whole statement useless. We can say
> that about anything.
I don't follow. I'm not calling on a Platonic ideal. All I'm saying is there's a
wrong way and a right way. Or are you implying that only programs that are
stipulated to be written the wrong way can be considered in this sort of
discussion?
>
>
> But we're talking about the real world here. Structured methodology makes it
> much easier to write code that is much closer to the ideal of being PROPERLY
> WRITTEN. Shops with structured methodology standards are much more likely to
> have programs that are closer to being PROPERLY WRITTEN.
You can say this with a straight face, can you, after seeing some of the coding
examples posted on this NG? (Remember the "ugly evaluate").
PL
Howard Brazee
On 29-Apr-2004, Peter Lacey <la...@mb.sympatico.ca> wrote:
> > Your postulate is sufficient to make the whole statement useless. We can
> > say that about anything.
>
> I don't follow. I'm not calling on a Platonic ideal. All I'm saying is
> there's a
> wrong way and a right way. Or are you implying that only programs that are
> stipulated to be written the wrong way can be considered in this sort of
> discussion?
You were saying that PROPERLY WRITTEN code is equally good whether structured or
spaghetti. My experience is that most unstructured code I have seen does not
meet your criteria. I suggest that you ARE calling on a Platonic ideal,
despite what you said above.
> > But we're talking about the real world here. Structured methodology makes
> > it
> > much easier to write code that is much closer to the ideal of being PROPERLY
> > WRITTEN. Shops with structured methodology standards are much more likely
> > to have programs that are closer to being PROPERLY WRITTEN.
>
> You can say this with a straight face, can you, after seeing some of the
> coding examples posted on this NG? (Remember the "ugly evaluate").
I've seen a LOT of coding in real shops since 1969 (with a gap while I was in
the USAF). Shops that encourage structured code are much, much more likely to
have PROPERLY WRITTEN code than shops that don't encourage such.
Robert Jones
Peter Lacey <la...@mb.sympatico.ca> wrote in message news:<4091195D...@mb.sympatico.ca>...
> Lueko Willms wrote:
>
> >
> >
> > PL> goto's are not yet banished; punishing
> > PL> programmers that write with goto's is not permitted!
> >
> > Those programmers punish themselves by using GOTOs. Unless they
> > complement its use with the corresponding COME FROM.
> >
> > Yours,
> > L ko Willms http://www.mlwerke.de
>
>
> Knowing full well the firestorm that I'm going to incur: NONSENSE. Prog
> rams
> with GOTO's - IF PROPERLY WRITTEN - are equal in quality, maintainability
> and
> every other measure to GOTO-less programs.
>
> I have written programs - and maintained programs written by others - in
> both
> styles. Therefore I feel qualified to make the above statement. The key
>
> postulate is "properly written".
>
> PL
I largely agree with Peter, though I would say that there are probably
several "right" ways to write programs and also several "wrong" ways
too. Also probably many ways that incorporate both "right" and
"wrong" aspects.
I think the GO TO statement is a very useful facility that has been
grossly abused by many programmers and pundits. Just because
something has been badly used does not necessarily mean that it should
never be used.
I currently try to use as few GO TO statements as I can get away with
without making the resultant code excessively convoluted, often I
don't need any at all.
A conditional construct is often much more legible/intelligible for
having a series of fairly simple IF statements that each terminate in
a GO TO section exit than a large nested IF or EVALUATE that rambles
over several screens or pages. Nevertheless, I still use nested IFs
and the EVALUATE statement as they also are very useful. It all
depends upon the circumstances.
Robert
LX-i
> I have written programs - and maintained programs written by others - in both
> styles. Therefore I feel qualified to make the above statement. The key
> postulate is "properly written".
I'll not even comment about the particular item in question - just a
side comment. What appears "properly written" to the original
programmer can seem decidedly "improperly written" to the maintenance
programmer - that's what makes our job more of an art than a science. :)
Peter Lacey
>
> You were saying that PROPERLY WRITTEN code is equally good whether structured or
> spaghetti. My experience is that most unstructured code I have seen does not
> meet your criteria. I suggest that you ARE calling on a Platonic ideal,
> despite what you said above.
>
I won't dispute your experience. It's yours, not mine, so your statement must be
accepted. But in MY experience, most code could stand a great deal of improvement,
regardless of the method. You implicitly admit that it's possible to write "proper"
unstructured code - you do say "most"!
Tell me: consider a program that has few and simple transfers of control. For the
purpose of discussion, it doesn't matter that it could be rewritten to make the
point less important.
A: IF A = B
(hundreds of lines of code)
END-IF
B. IF A NOT = B GOTO AFTER-B.
(same hundreds of lines of code)
AFTER-B.
Note that the "hundreds of lines of code" are identical in both cases.
Why is B less easy to understand and maintain than A? Why is it more error-prone?
Why are programmers punishing themselves doing it as in B? Isn't it true that it's
far easier in B to find out where the scope of the IF terminates (because the label
makes it explicit)?
Nobody has ever demonstrated points such as these to me.
PL
William M. Klein
Why is it <B> more error-prone?
Given:
B. IF A NOT = B GOTO AFTER-B.
(same hundreds of lines of code)
else *> new section
(some more hundreds of lines of code)
AFTER-B.
It is INCREDIBLY "easy" to add yet ANOTHER "IF" in the middle of the "same
hundreds of lines of code") with or without a "GO TO" causing erroneous logic
flow, while with
A: IF A = B
(hundreds of lines of code)
else *> new section
(some more hundreds of lines of code)
END-IF
any "new" IF in the middle of the "same hundreds of lines of code" can MUCH more
easily be "diagnosed" if it cause an erroneous logic flow change.
Of course, I am NOT saying that a "nested" section of logic with "hundreds of
lines of code" under one branch of an IF - much less under both branches is
"good" coding.
--
Bill Klein
wmklein <at> ix.netcom.com
"Peter Lacey" <la...@mb.sympatico.ca> wrote in message
news:4098011B...@mb.sympatico.ca...
JerryMouse
You're asking which is better, parsnips or beets. Fact is, they are both
hideous. Saying one is better is equivalent to putting lipstick on a pig.
How about:
IF A = B
PERFORM HUNDREDS-OF-LINES-OF-CODE
END-IF.
Richard
> A: IF A = B
> (hundreds of lines of code)
> END-IF
>
>
> B. IF A NOT = B GOTO AFTER-B.
> (same hundreds of lines of code)
> AFTER-B.
>
> Note that the "hundreds of lines of code" are identical in both cases.
>
> Why is B less easy to understand and maintain than A? Why is it more
> error-prone?
A can be performed by PERFORM A.
With B, having a GO TO requires that there be a label, in this case
'After-B'. This then requires that 'B' is part of a group of
paragraphs that must be performed together. Either there is a
'B-group SECTION' that must be performed and there must then be a
SECTION header following that group to indicate that the 'B-group' has
ended and the perform is thus of B-group, or the perform must be of 'B
THRU B-end' wherever that is.
Thus B is far more complex than A, thus more error prone and less
understandable.
> Why are programmers punishing themselves doing it as in B? Isn't it true that it's
> far easier in B to find out where the scope of the IF terminates (because the label
> makes it explicit)?
That is a very superficial viewpoint. There is nothing wrong with the
'GO TO' at all. As you say, from the point of view of the GO TO, it
is bleeding obvious what it is doing, that is not where the problem
lies.
The problem occurs at the point 'After-B'. As I have already
indicated this makes the execution of B far more complex and
error-prone than that of A. But real programs are not simple examples
with all parts viewable. Programs must be understood in small parts
at a time. When looking at code and a label is found, it is not
readily apparent the way that control flows around it.
The label After-B may be dropped into from above, be the target of a
GO TO, of a PERFORM, or it may terminate a PERFORM or be part of a
PERFORM THRU.
That is, the program may have any or all of:
PERFORM B-group (section)
PERFORM B
PERFORM B THRU After-B
PERFORM After-B
PERFORM B THRU B-end
GO TO After-B
The only way to determine what flows exist around the After-B label is
to examine the whole program, as you say there may be hundreds of
lines of separation.
In programs that I write I do not have GO TO, or THRU or SECTION.
This is easily provable with text searches. Thus the only structure
that is possible is PERFORM x, where x is a paragraph label. Thus
when examining a program and a label is found is it exactly clear what
logic flow exists. That label terminates the perform of the paragraph
above and is the start of where a perform of this paragraph begins.
My paragraphs may be of the form of A, above, but are more likely to
be of the form:
C. IF ( A = B )
PERFORM Some-part-of-hundreds
PERFORM Another-part-of-hundreds
...
END-IF
.
Where each part is a functional group that may be reused somewhere
else.
> Nobody has ever demonstrated points such as these to me.
While I accept that may be true, there is also the possibility that
they have, but you rejected this.
It may well be that in the case of A, above, you would also put A in
an A-group SECTION, have a SECTION after A, and PERFORM A-group, or
would add an unnecessary A-end and PERFORM A THRU A-end. If you were
to do this then you may claim that the difference between _your_
implementation of A and of B is insignificant.
Joe Zitzelberger
airplanes with only a few square meters of fabric.
I've also often seen people land safely on the ground in a craft
designed to safely transport people from place to place, via air,
without harm, and piloted by an experienced handler.
Both are cases of air transportation. And both, when done properly,
provide a significent possibility of a good landing.
Our examples are similar -- except I used people instead of software.
However, if you don't understand why 'hundreds of lines of code' in a
single IF statement is a problem then you have no hope of understanding
the goto problem.
In article <4098011B...@mb.sympatico.ca>,
Lueko Willms
schrieb rip...@Azonic.co.nz (Richard)
bei /COMP/LANG/COBOL
in 217e491a.04050...@posting.google.com
ueber Re: Perform Thru/Go to vs. Perform - Compile Speed
r> The problem occurs at the point 'After-B'. As I have already
r> indicated this makes the execution of B far more complex and
r> error-prone than that of A. But real programs are not simple examples
r> with all parts viewable. Programs must be understood in small parts
r> at a time. When looking at code and a label is found, it is not
r> readily apparent the way that control flows around it.
r>
r> The label After-B may be dropped into from above, be the target of a
r> GO TO, of a PERFORM, or it may terminate a PERFORM or be part of a
r> PERFORM THRU.
r>
r> That is, the program may have any or all of:
r>
r> PERFORM B-group (section)
r> PERFORM B
r> PERFORM B THRU After-B
r> PERFORM After-B
r> PERFORM B THRU B-end
r> GO TO After-B
That is why I said that GOTO should never be used without the
corresponding COME FROM.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela
Howard Brazee
On 4-May-2004, Peter Lacey <la...@mb.sympatico.ca> wrote:
> I won't dispute your experience. It's yours, not mine, so your statement must
> be accepted. But in MY experience, most code could stand a great deal of
> improvement,
> regardless of the method. You implicitly admit that it's possible to write
> "proper" unstructured code - you do say "most"!
>
> Tell me: consider a program that has few and simple transfers of control.
> For the purpose of discussion, it doesn't matter that it could be rewritten to
> make
> the point less important.
>
> A: IF A = B
> (hundreds of lines of code)
> END-IF
Is this your concept of "properly written structured code"?
> B. IF A NOT = B GOTO AFTER-B.
> (same hundreds of lines of code)
> AFTER-B.
Is this your concept of "properly written unstructured code"?
> Note that the "hundreds of lines of code" are identical in both cases.
>
> Why is B less easy to understand and maintain than A? Why is it more
> error-prone?
>
> Why are programmers punishing themselves doing it as in B? Isn't it true that
> it's
> far easier in B to find out where the scope of the IF terminates (because the
> label makes it explicit)?
>
> Nobody has ever demonstrated points such as these to me.
Doing your same code comparisons.
IF A=B
PERFORM B-ROUTINE
END-IF.
vs
IF A NOT = B GO TO NOT-B.
PERFORM B-ROUTINE
NOT-B.
This is more modular. It is more clear than in your two examples the scope of
what B-ROUTINE does. Now once I have removed the hundreds of lines of code we
have the above comparisons. Not a lot of difference, but do you still prefer
your GO TO code?
Howard Brazee
On 4-May-2004, Peter Lacey <la...@mb.sympatico.ca> wrote:
> Tell me: consider a program that has few and simple transfers of control.
> For the
> purpose of discussion, it doesn't matter that it could be rewritten to make
> the
> point less important.
>
> A: IF A = B
> (hundreds of lines of code)
> END-IF
>
>
> B. IF A NOT = B GOTO AFTER-B.
> (same hundreds of lines of code)
> AFTER-B.
What is more difficult is when you want to perform the above paragraph. In
your routine the maintenance programmer has to figure out where your logical
paragraph ends and do a PERFORM THRU.
Making each paragraph a logical module is easier, especially with a 3:00 A.M.
emergency fix by somebody who didn't write the program.
Peter Lacey
> >
> > Tell me: consider a program that has few and simple transfers of
> > control. For the purpose of discussion, it doesn't matter that it
> > could be rewritten to make the point less important.
>
> How about:
>
> IF A = B
> PERFORM HUNDREDS-OF-LINES-OF-CODE
> END-IF.
I did say that for the purposes of discussion it doesn't matter.
Peter Lacey
> Peter Lacey <la...@mb.sympatico.ca> wrote
>
> > A: IF A = B
> > (hundreds of lines of code)
> > END-IF
> >
> >
> > B. IF A NOT = B GOTO AFTER-B.
> > (same hundreds of lines of code)
> > AFTER-B.
> >
> > Note that the "hundreds of lines of code" are identical in both cases.
> >
> > Why is B less easy to understand and maintain than A? Why is it more
> > error-prone?
>
> A can be performed by PERFORM A.
>
> With B, having a GO TO requires that there be a label, in this case
> 'After-B'. This then requires that 'B' is part of a group of
> paragraphs that must be performed together. Either there is a
> 'B-group SECTION' that must be performed and there must then be a
> SECTION header following that group to indicate that the 'B-group' has
> ended and the perform is thus of B-group, or the perform must be of 'B
> THRU B-end' wherever that is.
>
I have to point out that if you must add assumptions to the example then you change the
question.
>
> Thus B is far more complex than A, thus more error prone and less
> understandable.
Actually, B with extra assumptions is more complex than A.
My prototype was a program I wrote some 3000 lines long with eight GOTO's. Six of them
were conditions exactly like the one I listed, one was to the top of the loop, and one
was to the end-of-job. Your assumptions about the program structure are not necessary.
> > Why are programmers punishing themselves doing it as in B? Isn't it true that it's
> > far easier in B to find out where the scope of the IF terminates (because the label
> > makes it explicit)?
>
> That is a very superficial viewpoint. There is nothing wrong with the
> 'GO TO' at all. As you say, from the point of view of the GO TO, it
> is bleeding obvious what it is doing, that is not where the problem
> lies.
Somebody else said they're punishing themesleves: I just quoted.
> The label After-B may be dropped into from above, be the target of a
> GO TO, of a PERFORM, or it may terminate a PERFORM or be part of a
> PERFORM THRU.
>
Again, the example as I gave it assumed none of these. I was trying to abstract
something for the purposes of discussion.
>
> > Nobody has ever demonstrated points such as these to me.
>
> While I accept that may be true, there is also the possibility that
> they have, but you rejected this.
>
I would deny that. I have nothing at all against goto-less programming. I've done
some. What I object to is people condemning out-of-hand the use of goto's, with
religious fervour. Many of the people who do so have never actually tried it out. Plus
I object to the atttitude often expressed that programs with goto's MUST be of lower
quality. I know that such is not the case. Normally I'm content to let it go but
sometimes my irritation gets the better of me, while all the time I know I'm preaching to
the converted.
PL
Peter Lacey
>
>
> Doing your same code comparisons.
>
> IF A=B
> PERFORM B-ROUTINE
> END-IF.
>
> vs
>
> IF A NOT = B GO TO NOT-B.
> PERFORM B-ROUTINE
> NOT-B.
>
> This is more modular. It is more clear than in your two examples the scope of
> what B-ROUTINE does. Now once I have removed the hundreds of lines of code we
> have the above comparisons. Not a lot of difference, but do you still prefer
> your GO TO code?
Did you actually notice that I said:
For the purpose of discussion, it doesn't matter that it could be rewritten to
> make
> the point less important.
>
You haven't answered my questions at all. You've changed the subject instead.
PL
Howard Brazee
You can say that if you want. And I can disagree.
Howard Brazee
On 5-May-2004, Peter Lacey <la...@mb.sympatico.ca> wrote:
> Did you actually notice that I said:
Yes I did. I disagreed with what you said though.
> > For the purpose of discussion, it doesn't matter that it could be rewritten
> > to
> > make the point less important.
> >
>
> You haven't answered my questions at all. You've changed the subject instead.
I disagree again. You were talking about "properly written code", and comparing
your example with ours. But you weren't using our example of "properly written
code". You also demand that we do not expand upon the idea beyond exactly what
you wrote, nor your assumptions about what we call "properly written code".
Richard
> Why are programmers punishing themselves doing it as in B?
That may be because they always write programs with what I call
'heavyweight' procedures. When they code a part that is to be
PERFORMed they do it with a lot of red tape. If they perform sections
then they must create a section header an initial paragraph label and
an end paragraph label, they alloacte a new prefix number to indicate
its place in the program hierarchy, almost guaranteeing that it won't
be reused from somewhere else, and they move the code to the physical
placement in the source given by its prefix.
This makes a lot of overhead for a simple separate block to perform,
so they take the 'easy' route and just bang in a GO TO and a label.
This make the performed procedures larger, less modular, and the
programmer only thinks of performs of large blocks of code.
Once the GO TOs are eliminated there is no need nor use for section,
or thru or exit labels. With modern tools (anything in the last
quarter century) text serches will find any name so prefixes are not
required as they were with lineflow listings and card packs. By
dumping the hierarchical numbering then performed paragraphs, without
all the red tape, can be adjacent to where they are performed. The
style of procedures is now 'lightweight', it is easier to split a
paragraph in two in situ and perform then it is to bang in a go to.
In your simplified examples you cannot see the merit of removing the
GO TO, that may be because you would still use 'heavyweight'
procedures with number prefixes and exit pargarphs and all the other
red tape. In fact all the things that were essential when source code
was in card trays.
But the real advantage of removing the GO TO, is that all the
'heavyweight' red tape can be removed, the sections, the thrus, the
exit pargraphs. Then the artificial structure of the prefixes can be
dumped and every pargaraph label will do one thing, and only ever one
thing: be the target of a perform of just that paragraph.
All the errors related to missing THRU, missing SECTION, wrong exit
labels, inserted paragraphs, unexpected drop-thru, all disappear.
And, more importantly, these things do not even need to be checked
for, they can't occur. There is no fear to breaking a procedure down
into simpler modules for performing and leaving them in place, no need
to sort the sorce code by 'layer', it can be arranged by logic. No
need to have 'hundreds of lines' they can be in many small paragraphs
grouped logically, and reusably.
The advantages of removing the GO TO is not about the GO TO at all.
William M. Klein
Notice that he did NOT reply to any of us who "directly" addressed his
question/issue about why it was error-prone (ignoring the "hundreds of lines"
issue)
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:c7bd4u$883$1...@peabody.colorado.edu...
Richard
> > A can be performed by PERFORM A.
> >
> > With B, having a GO TO requires that there be a label, in this case
> > 'After-B'. This then requires that 'B' is part of a group of
> > paragraphs that must be performed together. Either there is a
> > 'B-group SECTION' that must be performed and there must then be a
> > SECTION header following that group to indicate that the 'B-group' has
> > ended and the perform is thus of B-group, or the perform must be of 'B
> > THRU B-end' wherever that is.
> I have to point out that if you must add assumptions to the example then you
> change the question.
First of all they are not assumptions. For code 'B' to be of any use
it must have mechanisms surrounding it, such as I indicated. A
'PERFORM B' would be an error and this is just one of the reasons why
'B' is more error-prone and less maintainable. It is, as I have
pointed out elsewhere, not the GO TO that is directly the problem, it
is all the baggage that must go with it.
> > Thus B is far more complex than A, thus more error prone and less
> > understandable.
>
> Actually, B with extra assumptions is more complex than A.
No. The use of B is more complex.
I can quite see why you think that 'no one has explained this to you'
when you just go 'HHMMMMMM I can't hear you HHHMMMMM'.
> My prototype was a program I wrote some 3000 lines long with eight GOTO's. Six of them
> were conditions exactly like the one I listed, one was to the top of the loop, and one
> was to the end-of-job. Your assumptions about the program structure are not necessary.
You say 'structure', but it wasn't really was it.
A program with 6 decision points, even if it is 3000 lines, is
trivial. Trivial cases do not present issues with maintainability or
proneness to error. The 'structure' that you indicate does not scale
well. When a program has dozens or hundreds of decision points, as
real programs do, then your GO TO structure presents many problems.
It also makes it difficult and error-prone to reuse code, either
within the same program or externally.
> Again, the example as I gave it assumed none of these. I was trying to
> abstract something for the purposes of discussion.
And I was discussing it. It seems that you want to ignore all the
discussions that lead from your point to conclusions that you don't
want to hear.
> > While I accept that may be true, there is also the possibility that
> > they have, but you rejected this.
>
> I would deny that.
Yet you have rejected all the issues that I have raised, claiming that
they don't apply.
> I have nothing at all against goto-less programming. I've done
> some. What I object to is people condemning out-of-hand the use of goto's,
> with religious fervour. Many of the people who do so have never actually
> tried it out.
30 odd years ago, GO TOs were the standard mechanism for decisons. At
that time I noticed that this led to labels being used for multiple
purposes: to scope perform start and finish, as targets for branching
and as drop throughs. As I learnt other languages I saw that they
used labels for just one purpose: you couldn't goto a subroutine, or
call a branch label. This eliminated whole classes of errors.
Now in your 3000 line program you have eliminated all types of label
usage except for one: to be the target of a goto. Labels are not used
for performs, or to end the scope of a perform. As I have indicated
it is the multiple use of labels that leads to issues of error and
maintainability.
I recall deliberately using the skip-forward and cycle style in a
large program around 30 years ago. However, it simply does not scale
well into the more complex interactive programs that require extensive
reuse of code.
Achieving single-use labels throughout either means using GO TO
exclusively (no PERFORM) or using PERFORM exclusively (no GO TO). The
former is scalable and caters for code reuse.
> Plus I object to the atttitude often expressed that programs
> with goto's MUST be of lower quality. I know that such is not the case.
While it is true that there may be two sets of programs, one with GO
TOs, and one without, that are equal in terms of quality,
maintainability and proneness to error, this does not exclude there
being a third set (or more) which are of higher 'quality' in these
respects.
> Normally I'm content to let it go but sometimes my irritation gets the better > of me, while all the time I know I'm preaching to the converted.
What exactly are you preaching ?
Richard
> That is why I said that GOTO should never be used without the
> corresponding COME FROM.
Absolutely. Due to the 'COME FROM' not being implemented in current
Cobol compilers, we should defer the use of GO TO until this becomes
available.
;-)
LX-i
> I've seen a LOT of coding in real shops since 1969 (with a gap while I was in
> the USAF).
Man - I'm in the USAF, and I see a ton of coding! :) Even been
inclined to do a little myself. The "hidden switch" bug got me this
week, though - you know, that code that says
if SSgt-Summers-Out-of-Town
set Break-All-Heck-Loose to true
end-if
;) You won't find it in any program, but I swear it's there!
Russell Styles
"LX-i" <lxi...@netscape.net> wrote in message
news:109ojpu...@corp.supernews.com...
There used to be rumors that some people put code into some of the
programs that dealt with reassigning solders that checked to insure
that certain people where never assigned to some of the most remote
posts.
LX-i
> My prototype was a program I wrote some 3000 lines long with eight GOTO's. Six of them
> were conditions exactly like the one I listed, one was to the top of the loop, and one
> was to the end-of-job. Your assumptions about the program structure are not necessary.
Were there any Performs in this, other than in-line? I've found that
"Go to" is great, if there are no performs in the program. At that
point, everything is again "obvious" to the maintenance guy. As Richard
pointed out, though, mixing the two introduces a level of complexity
that can be avoided by sticking to one or the other. When I was taught
COBOL, I was taught to structure programs like
Driver.
Perform Initialization-Stuff
Perform [each independent step of the process, such as "edit user
input", "process input", "output results", etc.]
Perform Termination-Stuff
Stop Run. (Or, "Go to Common-Stop-Run-Paragraph.")
In my actual job, we have a copy procedure (copybook) that handles
transaction initialization and termination, but the concept is the same.
I'm not saying that I use the above structure in every one of my
programs - I've been known to write paragraphs hundreds of lines in
length. However, I do try to keep things sensibly modular, and "common"
code common, so if I need to change a "common" routine, I can do it in
one place and be done. :)
> I would deny that. I have nothing at all against goto-less programming. I've done
> some. What I object to is people condemning out-of-hand the use of goto's, with
> religious fervour. Many of the people who do so have never actually tried it out. Plus
> I object to the atttitude often expressed that programs with goto's MUST be of lower
> quality. I know that such is not the case. Normally I'm content to let it go but
> sometimes my irritation gets the better of me, while all the time I know I'm preaching to
> the converted.
My issue isn't with go-to, per se. As a maintenance programmer by trade
(although I'm finding myself in some new development here as of late),
what I normally see is 20-25-year-old code that was written with a mix
of Go to and Perform. It -is- difficult to desk-check code like that
(although it is sort of an acquired art), which leaves most programmers
in our shop reliant on program-wide traces and variable dumps to try to
figure out what the program is doing.
Perform can be abused to. I've seen something like
Perform These-Three-Lines.
These-Three-Lines.
Perform [stuff]
Perform The-Next-Four-Lines.
The-Next-Four-Lines.
Perform [stuff]
Perform Yet-Another-Three-Lines.
Yet-Another-Three-Lines.
...you get the idea. I believe what it really boils down to is that
Perform comes back (assuming it doesn't "Go to" out of scope), which
gives you a somewhat good idea of program flow. However, a poorly
placed Go to can really mess this up. (As an aside, I don't really care
for Perform Thru - did you know that "Perform A-Para Thru A-Para"
equates to "Go to A-Para"?) It's an easy mistake to introduce as a
maintenance programmer.
LX-i
> Achieving single-use labels throughout either means using GO TO
> exclusively (no PERFORM) or using PERFORM exclusively (no GO TO). The
> former is scalable and caters for code reuse.
Shouldn't that be "latter"? :)
LX-i
> There used to be rumors that some people put code into some of the
> programs that dealt with reassigning solders that checked to insure
> that certain people where never assigned to some of the most remote
> posts.
Heh - I wouldn't put it past 'em. There was actually an official deal
at one time for someone who could write a .dll to take heart rate
information from a telemetry (sp?) device. If they wrote it, their SSN
would be hard-code into the fitness software so they would pass for the
next 5 years.
(No, I didn't do it... :> )
Peter Lacey
> Peter Lacey wrote:
>
> > My prototype was a program I wrote some 3000 lines long with eight GOTO's. Six of them
> > were conditions exactly like the one I listed, one was to the top of the loop, and one
> > was to the end-of-job. Your assumptions about the program structure are not necessary.
>
> Were there any Performs in this, other than in-line? I've found that
> "Go to" is great, if there are no performs in the program.
No. It was a file-conversion program for a very complicated file. Lots of IF's for the
various fields and possibilities but no necessity to loop or jump out of line.
> At that
> point, everything is again "obvious" to the maintenance guy. As Richard
> pointed out, though, mixing the two introduces a level of complexity
> that can be avoided by sticking to one or the other. When I was taught
> COBOL, I was taught to structure programs like
>
> Driver.
> Perform Initialization-Stuff
> Perform [each independent step of the process, such as "edit user
> input", "process input", "output results", etc.]
> Perform Termination-Stuff
> Stop Run. (Or, "Go to Common-Stop-Run-Paragraph.")
>
Which I do myself. But in the protoype I refer to, the flow logic was so simple that to put
the detail logic out-of-line would have made the program structure more complicated.
I have never dared (after the first time I tried it, back in the days before we had in-line
PERFORM's) to use a label as the target of BOTH a GOTO and a PERFORM. By now that practice has
become an instinctive thing. Likewise, I ALWAYS use PERFORM A THRU A-X and never have trouble
with it. The people who never use THRU because disaster can happen if there's an extra label
there are quite correct in their practice. But it's only one way to avoid problems.
I appreciate your thoughtful comments.
PL
Richard
> > Achieving single-use labels throughout either means using GO TO
> > exclusively (no PERFORM) or using PERFORM exclusively (no GO TO). The
> > former is scalable and caters for code reuse.
>
> Shouldn't that be "latter"? :)
Yes.
Richard
> (As an aside, I don't really care
> for Perform Thru - did you know that "Perform A-Para Thru A-Para"
> equates to "Go to A-Para"?) It's an easy mistake to introduce as a
> maintenance programmer.
The _only_ reason that a PERFORM THRU or PERFORM section is required
is to cater for additional paragraph labels in the scope of the
PERFORM. The only reason that these would be required is to cater for
a GO TO between labels within the scope (or worse to branch back into
the scope after a goto out of it).
(Note use of word 'required').
LX-i
> LX-i wrote:
>
>
>>Peter Lacey wrote:
>>
>>
>>>My prototype was a program I wrote some 3000 lines long with eight GOTO's. Six of them
>>>were conditions exactly like the one I listed, one was to the top of the loop, and one
>>>was to the end-of-job. Your assumptions about the program structure are not necessary.
>>
>>Were there any Performs in this, other than in-line? I've found that
>>"Go to" is great, if there are no performs in the program.
>
>
> No. It was a file-conversion program for a very complicated file. Lots of IF's for the
> various fields and possibilities but no necessity to loop or jump out of line.
Makes sense to me. When I first learned BASIC, I was taught GOSUB, but
that "hardly anyone uses that", instead being taught to have loops that
are fallen into, and go back up to the top until they complete. (Of
course, I think I was 8 or 9 at the time too - but it would have been
nice to be grounded in structured programming.)
>>...you get the idea. I believe what it really boils down to is that
>>Perform comes back (assuming it doesn't "Go to" out of scope), which
>>gives you a somewhat good idea of program flow. However, a poorly
>>placed Go to can really mess this up. (As an aside, I don't really care
>>for Perform Thru - did you know that "Perform A-Para Thru A-Para"
>>equates to "Go to A-Para"?) It's an easy mistake to introduce as a
>>maintenance programmer.
>
> I have never dared (after the first time I tried it, back in the days before we had in-line
> PERFORM's) to use a label as the target of BOTH a GOTO and a PERFORM. By now that practice has
> become an instinctive thing. Likewise, I ALWAYS use PERFORM A THRU A-X and never have trouble
> with it. The people who never use THRU because disaster can happen if there's an extra label
> there are quite correct in their practice. But it's only one way to avoid problems.
True. Anything can be abused, and short-sighted programming is
regretted in the long term. We're trying to encourage our folks these
days to start thinking long-term when they code - what would someone
else say if they have to modify your code? :) (Of course, I've thought
nasty things about myself, seeing some of my early code... I guess it's
something that's not an exact science.)
> I appreciate your thoughtful comments.
Anytime. :)
LX-i
Can you "go to" back into a perform thru after you've left it and have
the "thru" still be in effect? I would have thought that once you're
gone, the "thru" has been satisfied. (I've never tried it - I know that
at least our compiler can't keep up when you perform a paragraph from
itself (and it doesn't support a program calling itself - but,
subprogram A can call subprogram B, then subprogram B can call
subprogram A, etc., and it can find its way back).
Richard
> Can you "go to" back into a perform thru after you've left it and have
> the "thru" still be in effect? I would have thought that once you're
> gone, the "thru" has been satisfied.
PERFORM A THRU A-exit
...
A. do some stuff
GO TO B.
A-exit.
B. do other stuff
GO TO A-exit.
Poor code but valid.
> (I've never tried it - I know that
> at least our compiler can't keep up when you perform a paragraph from
> itself (and it doesn't support a program calling itself - but,
That is recursion, quite a different thing.
> subprogram A can call subprogram B, then subprogram B can call
> subprogram A, etc., and it can find its way back).
That may, or may not, be allowed as it recursive.
Lueko Willms
schrieb rip...@Azonic.co.nz (Richard)
bei /COMP/LANG/COBOL
in 217e491a.04050...@posting.google.com
ueber Re: Perform Thru/Go to vs. Perform - Compile Speed
r> The _only_ reason that a PERFORM THRU or PERFORM section is required
r> is to cater for additional paragraph labels in the scope of the
r> PERFORM. The only reason that these would be required is to cater for
r> a GO TO between labels within the scope (or worse to branch back into
r> the scope after a goto out of it).
In my style of COBOL programming I did never write a PERFORM on
paragraphs; I had divided my programs into SECTIONs with one single
paragraph called "ANFANG" (beginning in German), and only in the main
section with a final paragraph called "ENDE" (end in German) with no
other statement than the EXIT PROGRAM statement.
So there could never be a question if a paragraph would be executed
by simple fall thru, by a GOTO, by a PERFORM and what have you. And
SECTIONs would only by subject to a PERFORM, nver a GOTO or a fall
thru. I think this eased the understanding of my programs a lot.
The main logic of the program was completely visible in the initial
main section on the first page of the PROCEDURE DIVISION.
With COBOL'74 which did not know about "inline PERFORMs" this had
its limits, but it worked.
Starting with any version of the COBOL standard since COBOL'85, GOTO
would really not be necessary any more.
But I have to admit that I met other programmers who did not look at
the program as a _structure,_ but could only understand it by stepping
thru the programm step by step like "then HE goes there, and from
there HE goes here", and so forth. For me this is like not seeing the
wood for the trees.
Same for describing a route to drive from here to there -- I prefer
to have a look at a map which gives me an overview instead of a
sequence of single instructions for each turn which does not help me
to understand the general direction.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)
Howard Brazee
The standard was to PERFORM MY-PARAGRAPH THRU MY-PARAGRAPH-EXIT. Every
paragraph was followed by an -EXIT paragraph that only contained EXIT.
This was a big improvement over PERFORM MY-SECTION.
At any rate, if we ever move to the next version of CoBOL, there won't be any
good reason for that standard. (which standard I dislike intensely)
Howard Brazee
On 8-May-2004, rip...@Azonic.co.nz (Richard) wrote:
> The _only_ reason that a PERFORM THRU or PERFORM section is required
> is to cater for additional paragraph labels in the scope of the
> PERFORM. The only reason that these would be required is to cater for
> a GO TO between labels within the scope (or worse to branch back into
> the scope after a goto out of it).
>
> (Note use of word 'required').
Now that sections are no longer used for memory management, you are pretty much
correct. I have seen shops use sections as a logical super-paragraph, sort of
like a call. I don't care for that style myself.
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
>I have seen shop standards that mandated combining GO TO and PERFORM.
>
>The standard was to PERFORM MY-PARAGRAPH THRU MY-PARAGRAPH-EXIT.
A silght quibble, then... you saw standards which mandated combining GO TO
and PERFORM THRU -EXIT, not PERFORM.
This combination - rigidly adhered-to PERFORM THRU -EX and GO TO only to
immediately preceding label, exit paragraph or ABEND routine - is, of
course, the sort of programming encouraged by all decent, sane,
right-thinking and well-bathed coders... and I know this because I was
told by so the King of England.
God save the Me!
DD
Howard Brazee
On 10-May-2004, docd...@panix.com wrote:
> A silght quibble, then... you saw standards which mandated combining GO TO
> and PERFORM THRU -EXIT, not PERFORM.
I have never been able to code a PERFORM THRU -EXIT without coding a PERFORM.
> This combination - rigidly adhered-to PERFORM THRU -EX and GO TO only to
> immediately preceding label, exit paragraph or ABEND routine - is, of
> course, the sort of programming encouraged by all decent, sane,
> right-thinking and well-bathed coders... and I know this because I was
> told by so the King of England.
I have debugged a program that had a cut-and paste -EXIT paragraph with the
wrong name/place.
If mainframe shops (and their vendors) ever see a cost-benefit value in
upgrading to the current ANSI version of CoBOL, the King of England may have
reason to change his mind about the value of -EXIT paragraphs.
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
>
>On 10-May-2004, docd...@panix.com wrote:
>
>> A silght quibble, then... you saw standards which mandated combining GO TO
>> and PERFORM THRU -EXIT, not PERFORM.
>
>I have never been able to code a PERFORM THRU -EXIT without coding a PERFORM.
This might be why what was addressed was *not* what you have done but the
standards which you cited.
>
>> This combination - rigidly adhered-to PERFORM THRU -EX and GO TO only to
>> immediately preceding label, exit paragraph or ABEND routine - is, of
>> course, the sort of programming encouraged by all decent, sane,
>> right-thinking and well-bathed coders... and I know this because I was
>> told by so the King of England.
>
>I have debugged a program that had a cut-and paste -EXIT paragraph with the
>wrong name/place.
The Anciente Wisdome is that 'something can be foolproof... but not
damned-fool-proof'.
>
>If mainframe shops (and their vendors) ever see a cost-benefit value in
>upgrading to the current ANSI version of CoBOL, the King of England may have
>reason to change his mind about the value of -EXIT paragraphs.
If the Queen has she might be King, as well.
DD
Richard
> r> The _only_ reason that a PERFORM THRU or PERFORM section is required
> r> is to cater for additional paragraph labels in the scope of the
> r> PERFORM. The only reason that these would be required is to cater for
> r> a GO TO between labels within the scope (or worse to branch back into
> r> the scope after a goto out of it).
>
> In my style of COBOL programming I did never write a PERFORM on
> paragraphs; I had divided my programs into SECTIONs with one single
> paragraph called "ANFANG" (beginning in German), and only in the main
> section with a final paragraph called "ENDE" (end in German) with no
Well exactly. If your compiler does not complain about sections with
no paragraph labels (it shouldn't) then you could could make those
ANFANG and ENDE into comments because they aren't required (I assume
you have no goto). Then it would make no difference if the remaining
labels were _all_ section labels (as you have them) or _all_ paragraph
labels.
With all sections there is a risk that a section keyword may have been
ommitted with obvious unwanted results, this must be manually checked
for, or a specific program written to check this. With all paragraph
labels a simple text search, or grep, for 'section'. will demonstrate
that there isn't a section keyword inadvertently left in the procedure
division.
> other statement than the EXIT PROGRAM statement.
I hope that you don't use 'EXIT PROGRAM' in each PERFORM scope. You
might use 'EXIT' without any qualifier, but this is a no-op, it does
not do anything except act as a place holder. The end of the PERFORM
scope is never actioned by an EXIT, only by the start of a new section
or paragraph as appropriate.
> So there could never be a question if a paragraph would be executed
> by simple fall thru, by a GOTO, by a PERFORM and what have you.
But they are - all the time you are falling thru the ANFANG and ENDE
labels.
> And
> SECTIONs would only by subject to a PERFORM, nver a GOTO or a fall
> thru. I think this eased the understanding of my programs a lot.
Certainly I have found the simplification of label usage to be the
greatest benefit to understanding and error removal.
Howard Brazee
On 10-May-2004, rip...@Azonic.co.nz (Richard) wrote:
> With all paragraph
> labels a simple text search, or grep, for 'section'. will demonstrate
> that there isn't a section keyword inadvertently left in the procedure
> division.
I stick in a GET-RID-OF-ERROR SECTION. at the start of my procedure division
because we have IDMS error routines in copy members that have sections. And
then make sure that the IDMS error routines are at the very end of my program.
It's a pain having a section in a copy member because it means that any
subsequent code should be in a section. I would lobby to have a dummy section
put in after the real section in the copy, but some people have already used
this "feature" to include their own code after the copy code.
Russell Styles
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.0405...@posting.google.com...
I think that it depends on which compiler, etc etc you are using.
Microfocus lets do choose one of three different options.
I wouldn't depend on the above being portable. It is also possible that
the above might cause a memory (stack) leak, that would not show up in
a simple demo, but would bite in a real program.
Robert Wagner
>In programs that I write I do not have GO TO, or THRU or SECTION.
>This is easily provable with text searches. Thus the only structure
>that is possible is PERFORM x, where x is a paragraph label. Thus
>when examining a program and a label is found is it exactly clear what
>logic flow exists. That label terminates the perform of the paragraph
>above and is the start of where a perform of this paragraph begins.
I used to program the same way, but I recently discovered a better style --
replacing paragraph names with ENTER statements and using CALL to invoke the
procedures.
The advantage of CALL over PERFORM is that one can pass parameters. This
facilitates replacing three lines like this:
move date-1 in input-file to work-date
perform edit-date
move edited-date to date-1 in report-file
edit-date.
move 'mm/dd/yyyy' to edited-date
move corr work-date to edited-date.
with one line:
call 'edit-date' using date-1 in input-file, date-1 in report-file
entry 'edit-date' using input-date, output-date.
move 'mm/dd/yyyy' to output-date
move corr input-date to output-date
goback.
The data division entries are simplified, too, by the use of TYPEDEF.
Rather than:
01 report-record.
...
05 date-1.
10 month pic z9.
10 pic x.
10 da pic 99.
10 pic x.
10 year pic 9999.
10 pic x.
One can write:
01 report-record.
...
05 date-1 edited-date.
And:
linkage section.
01 input-date normal-date.
01 output-date edited-date.
Another advantage CALL has over PERFORM is the absence of CALL THRU and CALL
SECTION, and the unlikelyhood that someone would dare to jump out with a GO TO.
Thus, it puts an end to this debate.
Yet another advantage is that ENTRY supports recursion. Some compilers let one
'get away' with recursive PERFORMs, but make the programmer maintain the data
stack himself. ENTRY supports a recursive data stack through the use of
LOCAL-STORAGE.
The only danger created by ENTRY is forgetting to GOBACK.
My timing tests, run mostly on Micro Focus, show CALL ... GOBACK runs as fast
as PERFORM.
Before discovering this use, I regarded ENTRY as providing multiple entry points
for outside callers .. its intended use. That's terrible style, so I avoided
ENTRY altogether.
Richard
> Now that sections are no longer used for memory management, you are pretty much
> correct. I have seen shops use sections as a logical super-paragraph, sort of
> like a call. I don't care for that style myself.
I dispute that a 'PERFORM section' is anything like a CALL in any way.
The main difference between performing a section containing paragraph
labels and perform the first paragraph thru the last paragraph is only
in the types of error that may result from inadequate manual checking
of details that are inside and outside the scope of the perform.
The advantage that _I_ find (others may not) of not using sections
_and_ not using thru, is that many things that required manual
checking and rechecking, things that the compiler could not check,
things that were prone to errors, simply no longer exist.
There is no THRU, I no longer have to check that I added the THRU and
used the correct end-point - neither the editor nor the compiler can
tell me if I have these wrong. With no THRU any text search will tell
me if I had inadvertantly added a THRU.
There are no section headers, a text search will prove that. I no
longer have to check that I am performing the section label and not
the first paragraph label, I no longer have to check that the end of
the scope is correctly terminated by the following label being a
section header.
Without labels in the scope of the performs a GO TO -Exit cannot be
used. I no longer have to check that each GO TO is to the correct
-Exit, and that the -Exit does have the correct name. The compiler
cannot check this for me, manual checking is time consuming and error
prone.
Without GO TOs I no longer have to check for these when I move a block
of code from one paragraph to another, or to a new paragraph. I can't
wind up with a GO TO to the wrong -Exit pargraph, there aren't any.
Obviously there is a trade off for this. I probably wind up with more
smaller paragraphs because I take code out from nested IFs into their
own paragraph. But I don't have to check where this new paragraph
might go, it can be put at the end of the current one. OTOH many small
paragraphs lead to reuse and less complex conditionals.
Instead of having a large complex condition to catch all possibilities
so that the action code need only be written once, I can use several
simpler conditionals that cover all required possibilities and each
has just a PERFORM of the action paragraph.
LX-i
> I have seen shop standards that mandated combining GO TO and PERFORM.
>
> The standard was to PERFORM MY-PARAGRAPH THRU MY-PARAGRAPH-EXIT. Every
> paragraph was followed by an -EXIT paragraph that only contained EXIT.
Just because you have an exit paragraph doesn't mean you have to "go to"
it... :)
In early versions of COBOL 74 on the platform I work on (which was then
known as "Sperry OS 1100 ASCII COBOL", if I remember my Unisys history
correctly), there were allocation problems if there was not an exit
paragraph. So, ALL of our older programs have thru's on every single
perform in them. The ones that have been retooled don't, but even then,
it depends on who's doing the retooling.
> This was a big improvement over PERFORM MY-SECTION.
I'm a little intrigued at Sections. I was never taught them, but they
seem interesting - sort of like subroutines, except without the private
data and such.
Richard
> It's a pain having a section in a copy member because it means that any
> subsequent code should be in a section. I would lobby to have a dummy section
> put in after the real section in the copy, but some people have already used
> this "feature" to include their own code after the copy code.
Ouch! Relying on the layout of a COPY book is a sure bugtrap.
docd...@panix.com
Robert Wagner <robert.d...@wagner.net> wrote:
[snip]
>The advantage of CALL over PERFORM is that one can pass parameters. This
>facilitates replacing three lines like this:
>
>move date-1 in input-file to work-date
>perform edit-date
>move edited-date to date-1 in report-file
>
>edit-date.
> move 'mm/dd/yyyy' to edited-date
> move corr work-date to edited-date.
>
>with one line:
>
>call 'edit-date' using date-1 in input-file, date-1 in report-file
>
>entry 'edit-date' using input-date, output-date.
> move 'mm/dd/yyyy' to output-date
> move corr input-date to output-date
> goback.
I do not understand what criteria are being used to generate a conclusion
that the above is superior to a one-statement solution such as:
STRING WS-INREC-MM, '/', WS-INREC-DD, '/', WS-INREC-CCYY
DELIMITED BY SIZE INTO WS-OUTREC-EDITED-DATE.
... keeping in mind, of course, that all reads are READ INTO, all writes
are WRITE FROM and file-buffers are not touched at all.
DD
Richard
> I used to program the same way, but I recently discovered a better style --
> replacing paragraph names with ENTER statements and using CALL to invoke the
> procedures.
I assume that ENTRY was meant rather than ENTER, which is quite a
different thing.
ENTRY is a non-standard extension in current compilers that support
its use and is thus non-portable. There is a perfectly good standard
mechanism in 'Nested Programs' to do this.
If, however, you do try this extension, you should not 'replace
paragraphs' with ENTRY, you should also have a paragraph label where
necessary as ENTRY statements are _not_ paragraph labels. An ENTRY
does not, for example, terminate the scope of a PERFORM even though it
is the start of a logical procedure.
> Another advantage CALL has over PERFORM is the absence of CALL THRU and CALL
> SECTION, and the unlikelyhood that someone would dare to jump out with a GO TO.
> Thus, it puts an end to this debate.
There is no mechanism in a CALL / ENTRY that prevents or even disuades
the use of GO TO. Indeed, while PERFORM must use a specific PERFORM
THRU or PERFORM section in order to cater for paragraph labels that
are required for a GO TO, there is no such distinction with
CALL/ENTRY. The scope of the CALL is terminated only by an EXIT
PROGRAM (or GOBACK) and there is no restriction on having as many
labels and GO TOs between the ENTRY and the EXIT PROGRAM as one
wishes.
In other words the absense of 'CALL THRU' or 'CALL SECTION' is
completely irrelevant, they aren't needed to enable the use of GO TO
if that is what the programmer wants to do (not that I would). The
mention of 'jump out' is also misleading, within a PERFORM a GO TO
does not 'jump out', it jumps to the end, exactly as one may do (if
one wishes) to the EXIT PROGRAM at the end.
I have no idea why RW thinks it 'unlikely' at all, it certainly is not
an 'advantage' of CALL, which is quite indifferent to the use of GO
TO. His conclusion is based on flawed logic.
> Yet another advantage is that ENTRY supports recursion. Some compilers let one
> 'get away' with recursive PERFORMs, but make the programmer maintain the data
> stack himself. ENTRY supports a recursive data stack through the use of
> LOCAL-STORAGE.
Recursion is implementation dependant. There are compilers that have
ENTRY but do not support recursion. RW extrapolates in error from too
small a sample.
> The only danger created by ENTRY is forgetting to GOBACK.
GOBACK, in current compilers, is a non-standard extension. EXIT
PROGRAM should be used in preferences (IMHO, YMMV).
But no. Forgetting 'GOBACK' is not the only danger. Thinking that
ENTRY will end the scope of a PERFORM is another. And then there is
the issue of which LINKAGE items are curently active. If the program
has been CALled or there are several levels of CALL - ENTRY then there
may be many LINKAGE items defined, only some of which are active. MF
has 'STICKY-LINKAGE' changes the behaviour somewhat, other compilers
may, or may not, work the same way.
> My timing tests, run mostly on Micro Focus, show CALL ... GOBACK runs as fast
> as PERFORM.
The timing of nested programs may give much the same results too.
CALLing nested program is certainly faster than CALLing external
programs.
Nested programs are standard, safer (they have their own linkage
section rather than sharing the main program's) and don't even have
the 'danger' of forgetting the EXIT PROGRAM, they will use an implicit
EXIT PROGRAM and the end of the program.
> Before discovering this use, I regarded ENTRY as providing multiple entry points
> for outside callers .. its intended use. That's terrible style, so I avoided
> ENTRY altogether.
I am not convinced that using ENTRY for multiple internal entry points
is stylistically any different from using it for multiple external
entry points.
BTW I have use ENTRY points over the last quarter century, but would
recommend that standard and portable mechanisms be used in preference
wherever possible.
William M. Klein
below) Standard "ENTER" statement, but I think that Robert really meant "ENTRY"
statement when he said,
> I used to program the same way, but I recently discovered a better style --
> replacing paragraph names with ENTER statements and using CALL to invoke the
> procedures.
The ENTRY "header" is a relatively but certainly NOT universal extension. The
biggest problem that I know about it is that when different ENTRY statements
have different parameters listed, some compilers keep addressability to
previously used Linkage Section items and others do not (and at least one as a
compiler option to determine this). Therefore, use of an ENTRY statement is not
(necessarily) very portable. Use of nested programs can (in almost ALL cases)
provide the same functionality for any '85 Standard compiler or later. Simply
use an EVALUATE as the first statement in your main program and call an
appropriate nested program.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert.d...@wagner.net> wrote in message
news:409ffd4b....@news.optonline.net...
Chuck Stevens
division and the date subfields (presumed here in yyyymmdd format) are used
only to produce edited-date:
STRING raw-date (5:2), '/', raw-date (7:2), '/', raw-date (1:4) DELIMITED BY
SIZE INTO edited-date.
-Chuck Stevens
<docd...@panix.com> wrote in message news:c7pb3u$pto$1...@panix5.panix.com...
Peter Lacey
> Peter Lacey <la...@mb.sympatico.ca> wrote
>
> > Why are programmers punishing themselves doing it as in B?
>
> That may be because they always write programs with what I call
> 'heavyweight' procedures. When they code a part that is to be
> PERFORMed they do it with a lot of red tape. If they perform sections
> then they must create a section header an initial paragraph label and
> an end paragraph label, they alloacte a new prefix number to indicate
> its place in the program hierarchy, almost guaranteeing that it won't
> be reused from somewhere else, and they move the code to the physical
> placement in the source given by its prefix.
I need to review this a bit before I reply. But I appreciate its
objective nature.
PL
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>... and, taking it a step further, if you don't want to clutter up your data
>division and the date subfields (presumed here in yyyymmdd format) are used
>only to produce edited-date:
>
>STRING raw-date (5:2), '/', raw-date (7:2), '/', raw-date (1:4) DELIMITED BY
>SIZE INTO edited-date.
Not to say that I've not done similar - and worse! - in code that's passed
a Production Review I'd argue that providing explicit subordinate
definitions for a date is not 'clutter(ing) up your data division'...
... and as for 'only to produce edited-date'... well... maybe that's all
it does *this* week. Next week someone will say 'Well, for the
quarterlies we'll want to break it down differently... but that's not a
problem, you already have the month on the input rec...'
DD
Chuck Stevens
exceeded the implementation limit on the number of user-defined names or
separately-addressed items one can have in a monolithic COBOL program (a
paltry 130K or so in MCP/AS COBOL74, quite a bit higher in MCP/AS COBOL85)
! And, of course, heaven forbid the use of comments to clarify anything
that might be deemed obtuse! ;-)
-Chuck Stevens
<docd...@panix.com> wrote in message news:c7r3gu$6iu$1...@panix5.panix.com...
Richard
> The ENTRY "header" is a relatively but certainly NOT universal extension. The
> biggest problem that I know about it is that when different ENTRY statements
> have different parameters listed, some compilers keep addressability to
> previously used Linkage Section items and others do not (and at least one as a
> compiler option to determine this). Therefore, use of an ENTRY statement is not
> (necessarily) very portable. Use of nested programs can (in almost ALL cases)
> provide the same functionality for any '85 Standard compiler or later. Simply
> use an EVALUATE as the first statement in your main program and call an
> appropriate nested program.
Yet another issue with ENTRY statements is that of name space
polution. The ENTRY names are external and thus global within the
whole run-unit. The effect of having a name duplicated because it is
used in two programs in the run-unit seems to be undefined.
While using ENTRY for its intended purpose of alternate entries into
programs from external programs is 'safe' in that these names can be
managed as part of the program naming mechanisms, the wholesale
replacement of paragraphs by ENTRY would lead to significant name
management issues and/or system instabilty.
Nested programs keep their names local and thus these do not lead to
name space polution.
Lueko Willms
schrieb la...@mb.sympatico.ca (Peter Lacey)
bei /COMP/LANG/COBOL
in 40A10991...@mb.sympatico.ca
ueber Re: Perform Thru/Go to vs. Perform - Compile Speed
PL> Richard wrote:
>> That may be because they always write programs with what I call
>> 'heavyweight' procedures. When they code a part that is to be
>> PERFORMed they do it with a lot of red tape. If they perform sections
>> then they must create a section header an initial paragraph label
That is necessary because the syntax says so
>> and an end paragraph label,
which is superflouus -- there is neither a practical need for it
nor a syntactical rule calling for it
>> they alloacte a new prefix number to indicate its place in the
>> program hierarchy, almost guaranteeing that it won't be reused from
>> somewhere else, and they move the code to the physical placement in
>> the source given by its prefix.
I have never used such prefix numbers, and I recommend not doing so.
The name of the SECTION should be clear enough to tell the reader
what purpose this section does have.
COBOL ain't assembler.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Die Arbeit in weißer Haut kann sich nicht dort emanzipieren, wo sie
in schwarzer Haut gebrandmarkt wird." - Karl Marx 12.11.1866
Robert Wagner
>ENTRY is a non-standard extension in current compilers that support
>its use and is thus non-portable. There is a perfectly good standard
>mechanism in 'Nested Programs' to do this.
I used Nested Programs in the Sorts demo. Programmers don't regard them as
paragraph replacements because three section headers and, usually a linkage
section, bloat the program. Replacing a paragraph name with an ENTRY causes no
increase in the line count. If the paragraph ended with EXIT, changing it to
GOBACK causes no increase either. At worst, the GOBACK adds one line.
>If, however, you do try this extension, you should not 'replace
>paragraphs' with ENTRY, you should also have a paragraph label where
>necessary as ENTRY statements are _not_ paragraph labels. An ENTRY
>does not, for example, terminate the scope of a PERFORM even though it
>is the start of a logical procedure.
Since you're not using PERFORM, there is no need for paragraph labels at all.
>> Another advantage CALL has over PERFORM is the absence of CALL THRU and CALL
>> SECTION, and the unlikelyhood that someone would dare to jump out with a GO
TO.
>> Thus, it puts an end to this debate.
>
>There is no mechanism in a CALL / ENTRY that prevents or even disuades
>the use of GO TO.
Lacking paragraph names, there is no target for a GO TO. One cannot GO TO an
entry point name.
> Indeed, while PERFORM must use a specific PERFORM
>THRU or PERFORM section in order to cater for paragraph labels that
>are required for a GO TO, there is no such distinction with
>CALL/ENTRY. The scope of the CALL is terminated only by an EXIT
>PROGRAM (or GOBACK) and there is no restriction on having as many
>labels and GO TOs between the ENTRY and the EXIT PROGRAM as one
>wishes.
True. But if one avoids THRU and GO TO as you and I do, replacing *all*
paragraph names with ENTRY is simple, mechanical, one-for-one. So is adding
GOBACK at the bottom of every (former) paragraph.
>In other words the absense of 'CALL THRU' or 'CALL SECTION' is
>completely irrelevant, they aren't needed to enable the use of GO TO
>if that is what the programmer wants to do (not that I would). The
>mention of 'jump out' is also misleading, within a PERFORM a GO TO
>does not 'jump out', it jumps to the end, exactly as one may do (if
>one wishes) to the EXIT PROGRAM at the end.
The paradigm shift may be enough to make legacy-style programmers stop thinking
in terms of THRU and GO TO.
>Recursion is implementation dependant. There are compilers that have
>ENTRY but do not support recursion. RW extrapolates in error from too
>small a sample.
Micro Focus *requires* ENTRY to do recursion. It doesn't allow Nested Programs
to call themselves.
>GOBACK, in current compilers, is a non-standard extension. EXIT
>PROGRAM should be used in preferences (IMHO, YMMV).
GOBACK has been legitimized in the 2002 Standard. Acknowledged may be a better
word; it has been available on most compilers for longer than 20 years.
>But no. Forgetting 'GOBACK' is not the only danger. Thinking that
>ENTRY will end the scope of a PERFORM is another. And then there is
>the issue of which LINKAGE items are curently active. If the program
>has been CALled or there are several levels of CALL - ENTRY then there
>may be many LINKAGE items defined, only some of which are active. MF
>has 'STICKY-LINKAGE' changes the behaviour somewhat, other compilers
>may, or may not, work the same way.
LINKAGE items are not a problem if each 'program' restricts itself to variables
listed in its ENTRY statement, and does not call subordinate 'programs' which
re-use them i.e. potentially change addressability.
>Nested programs are standard, safer (they have their own linkage
>section rather than sharing the main program's) and don't even have
>the 'danger' of forgetting the EXIT PROGRAM, they will use an implicit
>EXIT PROGRAM and the end of the program.
For longer than 20 years, we've been using paragraphs as 'lite-duty functions'
and external callable programs for 'heavy duty' processing, without significant
complaint about that dichotomy. My proposal merely changes the grammar of
PERFORM to be consistent with that of CALL by allowing one to pass parameters
and eliminating the troublesome THRU.
>> Before discovering this use, I regarded ENTRY as providing multiple entry
points
>> for outside callers .. its intended use. That's terrible style, so I avoided
>> ENTRY altogether.
>
>I am not convinced that using ENTRY for multiple internal entry points
>is stylistically any different from using it for multiple external
>entry points.
Perhaps you'll be convinced by my multi-threading demo, to be posted here soon.
>BTW I have use ENTRY points over the last quarter century, but would
>recommend that standard and portable mechanisms be used in preference
>wherever possible.
Generally, I share that sentiment. My primary reference is the Language
Standard, not compiler vendor manuals. When I cite the Standard, colleagues act
defuddled, making it clear they've never read the Standard. 'Yeahbut, how does
it work in XYZ Cobol.'
Non-technical employers are worse. They're forever asking whether an applicant
knows 'XYZ Cobol', as though every compiler created another dialect. It's as bad
with databases, which all use ANSI Standard SQL. Employers ask whether you know
Oracle or Informix or Sybase. When I try to explain they're all the same if you
stick to Standard SQL, they don't believe me, it's not what they want to hear.
Conclusion: decision-makers are tempermentally opposed to Standards. They *want*
workers to have specialized expertise, and they want to overpay for it. That's
fine with me and other contractors. I don't make the rules; I just play the
game.
Robert
William M. Klein
> rip...@Azonic.co.nz (Richard) wrote:
<snip>
>
> >GOBACK, in current compilers, is a non-standard extension. EXIT
> >PROGRAM should be used in preferences (IMHO, YMMV).
>
> GOBACK has been legitimized in the 2002 Standard. Acknowledged may be a better
> word; it has been available on most compilers for longer than 20 years.
>
When you say "most compilers" - on what basis do you claim this? I know that
most (all?) IBM compilers and those with "early" IBM-emulation mode provide it
(i.e. Micro Focus, Fujitsu, and CA-Realia). However, I don't know of ANY of the
non-IBM "emulation" compilers with it currently - much less for 20 years (e.g.
HP, DEC, Tandem, Unisys). It is certainly possible that some do (that I admit
to being unfamiliar with) - but I do question the "most compiler" statement
above.
It was (for those not familiar with the history) this type of generalization
based on limit data that caused previous problems with RW.
Robert Wagner
It has been available on most compilers I've worked on, which have generally
been the 'IBM emulation' ones -- IBM, Micro Focus, Realia (a long-time love
affair) and Fujitsu. I would have said 'mainstream compilers' except Chuck
Stevens would have objected to the slight against Unisys. He's very sensitive on
the subject.
Last year *you* championed GOBACK as a universal return mechanism. I agreed,
without comment. Now that I speak on the subject, you have a tergiversation -- a
reversal of opinion.
This is pure politics. It's not about the merits of GOBACK, it's about
discrediting me (RW).
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>Well, I'd say that depends on whether the program is approaching or has
>exceeded the implementation limit on the number of user-defined names or
>separately-addressed items one can have in a monolithic COBOL program (a
>paltry 130K or so in MCP/AS COBOL74, quite a bit higher in MCP/AS COBOL85)
>!
130K is 'paltry'? Pfah... my first programming instructor told the class
about the time the coders in the shop he worked in learned that an upgrade
from 8K to 16K was available for their mainframe; he said they stormed
into the manager's office, demanding 'Must have 16K!'.
The manager's response was '16K? No programmer worth his salary needs
16K; get outta here or you're all fired.'
But I digress... in the example you gave you used what appeared to be
reference modification ('STRING raw-date (5:2)'); is that in MCP/AS
COBOL74?
>And, of course, heaven forbid the use of comments to clarify anything
>that might be deemed obtuse! ;-)
Those who rely on job security due to idiosyncratic knowledge - and the
institutions which allow such folks to remain employed - deserve what they
get.
docd...@panix.com
Robert Wagner <robert.d...@wagner.net> wrote:
>"William M. Klein" <wmk...@nospam.netcom.com> wrote:
>
>>"Robert Wagner" <robert.d...@wagner.net> wrote in message
>>news:40a14cb9...@news.optonline.net...
>>> rip...@Azonic.co.nz (Richard) wrote:
>><snip>
>>>
>>> >GOBACK, in current compilers, is a non-standard extension. EXIT
>>> >PROGRAM should be used in preferences (IMHO, YMMV).
>>>
>>> GOBACK has been legitimized in the 2002 Standard. Acknowledged may be a better
>>> word; it has been available on most compilers for longer than 20 years.
>>>
>>
>>When you say "most compilers" - on what basis do you claim this?
[snip]
>It has been available on most compilers I've worked on, which have generally
>been the 'IBM emulation' ones -- IBM, Micro Focus, Realia (a long-time love
>affair) and Fujitsu.
Mr Wagner, it might be fruitful to consider the difference between 'most
compilers' (your original assertion) and 'most compilers I have worked on'
(what you state when asked for the basis of your original assertion).
[snip]
>Last year *you* championed GOBACK as a universal return mechanism. I agreed,
>without comment. Now that I speak on the subject, you have a tergiversation -- a
>reversal of opinion.
Mr Wagner, to 'champion' something is not the same, I believe, as
asserting that it is implemented in 'most compilers'. You made an
assertion about 'most compilers' and when asked for the basis of this you
cited 'most compilers I have worked on'.
>
>This is pure politics. It's not about the merits of GOBACK, it's about
>discrediting me (RW).
Mr Wagner, anyone who, when asked to supply a basis for a 'most' they
employed respond with a 'most that I have worked on' does not frequently
need, in my opinion, anyone else's efforts to discredit them.
DD
Richard
> Since you're not using PERFORM, there is no need for paragraph labels at all.
CALL does not replace PERFORM, PERFORM is the mechanism for
repitition, where is the CALL .. VARYING .. UNTIL ? What would you
use ? GO TO ?
> True. But if one avoids THRU and GO TO as you and I do, replacing *all*
> paragraph names with ENTRY is simple, mechanical, one-for-one. So is adding
> GOBACK at the bottom of every (former) paragraph.
It is also pointless, it introduces problems that you haven't thought
of (such as name space polution) and it fails to cater for repitition.
> Micro Focus *requires* ENTRY to do recursion. It doesn't allow Nested Programs
> to call themselves.
Your original claim was: "Yet another advantage is that ENTRY supports
recursion."
Microfocus Level II Cobol has ENTRY but no recursion. ENTRY does not
require recursion. Your claim was wrong, your support for it is an
inversion of your claim.
In fact MicroFocus does _NOT_ require ENTRY to do recursion:
"""A program can call itself via either its program-id or an entry
point."""
It is true that nested programs cannot recursively call themselves,
but external called programs can call themselves.
> LINKAGE items are not a problem if each 'program' restricts itself to variables
> listed in its ENTRY statement, and does not call subordinate 'programs' which
> re-use them i.e. potentially change addressability.
It was your suggestion that all paragraphs be replaced by ENTRY, now
all the data items need to be reworked into LINKAGE, _and_ the logic
must be restricted to a single level.
> My proposal merely changes the grammar of
> PERFORM to be consistent with that of CALL by allowing one to pass parameters
> and eliminating the troublesome THRU.
That is not what you proposed at all.
> My primary reference is the Language Standard, not compiler vendor manuals.
> When I cite the Standard, colleagues act defuddled, making it clear they've
> never read the Standard. 'Yeahbut, how does it work in XYZ Cobol.'
I recall that previously you were unconcerned about what the standard
said, it was quite clear that you had hardly read it even, your
criteria was 'whatever extensions the MF and Fujitsu compiler did'
_regardless_ even that the vendor's own manual did not support them.
For example:
""" -------------
>But it ain't Cobol. POINTER is an extension in Cobol'85 and the use
of
>them may be different, or not implemented at all, on current
compilers.
This is FUD (fear, uncertainty and doubt). In practice, it is
implemented
exactly the same on all mainstream compilers: Micro Focus, IBM and
Fujitsu. It
is real-world COBOL, even though you don't like it.
----------------
That's what Fujitsu documentation says. I believed it for awhile,
until I tried
the industry-standard way and found it worked. I documented this in
the paper:
"Fujitsu: A good compiler, whose weaknesses are ... incorrect
documentation of
pointer operations, ...". Look at the Demo. It was compiled under
Fujitsu v3 and
it works. It doesn't have any BASED-STORAGE nor FUNCTION ADDR().
------------------- """
Your 'proposal' decries your assertion that you are a 'born again'
standards follower. ENTRY will not be found in the standard.
Robert Wagner
>In article <40a16cfb...@news.optonline.net>,
>Robert Wagner <robert.d...@wagner.net> wrote:
>>"William M. Klein" <wmk...@nospam.netcom.com> wrote:
>>
>>>"Robert Wagner" <robert.d...@wagner.net> wrote in message
>>>news:40a14cb9...@news.optonline.net...
>>>> rip...@Azonic.co.nz (Richard) wrote:
>>><snip>
>>>>
>>>> >GOBACK, in current compilers, is a non-standard extension. EXIT
>>>> >PROGRAM should be used in preferences (IMHO, YMMV).
>>>>
>>>> GOBACK has been legitimized in the 2002 Standard. Acknowledged may be a
better
>>>> word; it has been available on most compilers for longer than 20 years.
>>>>
>>>
>>>When you say "most compilers" - on what basis do you claim this?
>
>[snip]
>
>>It has been available on most compilers I've worked on, which have generally
>>been the 'IBM emulation' ones -- IBM, Micro Focus, Realia (a long-time love
>>affair) and Fujitsu.
>
>Mr Wagner, it might be fruitful to consider the difference between 'most
>compilers' (your original assertion) and 'most compilers I have worked on'
>(what you state when asked for the basis of your original assertion).
I tried to clarify "most compilers" to mean 'the most commonly used.' Over 90%
of the production Cobol running today was compiled by IBM, Micro Focus or
Fujitsu. Do you dispute that?
>>This is pure politics. It's not about the merits of GOBACK, it's about
>>discrediting me (RW).
>
>Mr Wagner, anyone who, when asked to supply a basis for a 'most' they
>employed respond with a 'most that I have worked on' does not frequently
>need, in my opinion, anyone else's efforts to discredit them.
Logic is the raw material for building programs. Being logicians, CLC readers
know that most means majority. They also know the difference between factual
reportage and politically motivated quibbles. The former was written to benefit
the reader whereas the latter was penned to increase the writer's standing.
docd...@panix.com
Robert Wagner <robert.d...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>In article <40a16cfb...@news.optonline.net>,
>>Robert Wagner <robert.d...@wagner.net> wrote:
>>>"William M. Klein" <wmk...@nospam.netcom.com> wrote:
>>>
>>>>"Robert Wagner" <robert.d...@wagner.net> wrote in message
>>>>news:40a14cb9...@news.optonline.net...
>>>>> rip...@Azonic.co.nz (Richard) wrote:
>>>><snip>
>>>>>
>>>>> >GOBACK, in current compilers, is a non-standard extension. EXIT
>>>>> >PROGRAM should be used in preferences (IMHO, YMMV).
>>>>>
>>>>> GOBACK has been legitimized in the 2002 Standard. Acknowledged may be a better
>>>>> word; it has been available on most compilers for longer than 20 years.
>>>>>
>>>>
>>>>When you say "most compilers" - on what basis do you claim this?
>>
>>[snip]
>>
>>>It has been available on most compilers I've worked on, which have generally
>>>been the 'IBM emulation' ones -- IBM, Micro Focus, Realia (a long-time love
>>>affair) and Fujitsu.
>>
>>Mr Wagner, it might be fruitful to consider the difference between 'most
>>compilers' (your original assertion) and 'most compilers I have worked on'
>>(what you state when asked for the basis of your original assertion).
>
>I tried to clarify "most compilers" to mean 'the most commonly used.'
What you tried to do, Mr Wagner, is known best by you. What you did, as
might be concluded from the text above, is respond to the question of 'On
what basis do you say 'most compilers'?' with a statement about 'most
compilers I have worked on.'
>Over 90%
>of the production Cobol running today was compiled by IBM, Micro Focus or
>Fujitsu. Do you dispute that?
I disputed nothing, Mr Wagner; I tried to point out that when asked for
the basis of a statement you made regarding 'most compilers' you responded
with a statement about 'most compilers I have used'.
>
>>>This is pure politics. It's not about the merits of GOBACK, it's about
>>>discrediting me (RW).
>>
>>Mr Wagner, anyone who, when asked to supply a basis for a 'most' they
>>employed respond with a 'most that I have worked on' does not frequently
>>need, in my opinion, anyone else's efforts to discredit them.
>
>Logic is the raw material for building programs. Being logicians, CLC readers
>know that most means majority. They also know the difference between factual
>reportage and politically motivated quibbles. The former was written to benefit
>the reader whereas the latter was penned to increase the writer's standing.
Logic, as Wittgenstein stated, is a game played by a particular set of
rules. I am not aware of any formal logical systems which consistently
equate 'most' with 'most that I have used', as you appear to have done; if
you have documentation of such it might be rather... curious to peruse it.
DD
Lueko Willms
schrieb how...@brazee.net (Howard Brazee)
bei /COMP/LANG/COBOL
in c7o403$6he$1...@peabody.colorado.edu
ueber Re: Perform Thru/Go to vs. Perform - Compile Speed
HB> The standard was to PERFORM MY-PARAGRAPH THRU MY-PARAGRAPH-EXIT.
HB> Every paragraph was followed by an -EXIT paragraph that only
HB> contained EXIT.
HB>
HB> This was a big improvement over PERFORM MY-SECTION.
Hä? Strange statement .... how could that be an improvement?
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Das Volk, das ein anderes Volk unterjocht, schmiedet seine eigenen
Ketten." - Karl Marx (1. Januar 1870)
Howard Brazee
On 12-May-2004, robert.d...@wagner.net (Robert Wagner) wrote:
> I tried to clarify "most compilers" to mean 'the most commonly used.'
Sort of like saying "most operating systems have a start button that you press
when you want to shut down the computer".
> Over 90% of the production Cobol running today was compiled by IBM, Micro
> Focus or
> Fujitsu. Do you dispute that?
What relation does "Over 90% of production Cobol running today" have to do with
"most compilers"?
How many compilers run on IBM mainframes, vs how many compilers run on PC's,
mini computers, and other Mainframe computers?
Chuck Stevens
<docd...@panix.com> wrote in message news:c7rvbr$86s$1...@panix5.panix.com...
> But I digress... in the example you gave you used what appeared to be
> reference modification ('STRING raw-date (5:2)'); is that in MCP/AS
> COBOL74?
Noit is not; reference modification is a new feature associated with the '85
standard, and is in COBOL85. But the various limits in COBOL85 are
somewhat larger -- not vastly larger -- than those in COBOL74, and end users
not infrequently encounter such limits in both languages.
Both the Unisys MCP/AS COBOL compilers are regularly called upon to compile
monolithic programs in the range of half a million source lines and more,
and customers with such large programs must sometimes do what is necessary
to recompile them after seemingly minor changes if they are to remain
monolithic. In the case of COBOL85, one might need to use reference
modification instead of additional data-names to avoid a name-table
overflow; another technique that could be used in both compilers would be to
reduce the number of 88-level items. In the case of D2 stack space
overflow, one can use a directive to request that the PCW's associated with
labels be placed in a table instead of occupying a stack cell. Various
source-level techniques are appropriate for various limit breaches in the
various compilers.
Some of these very large programs are indeed hand-written; others are
generated. The compiler has no knowledge as to whether the program it is
compiling was generated by a program or written by a human, and for the
generated program, so long as the debugging is done at the level of the
input to a code generator, the clarity of the COBOL source code is
irrelevant. It's the compiler's job to compile it, not to pass judgment on
the elegance of the programmer's style.
> Those who rely on job security due to idiosyncratic knowledge - and the
> institutions which allow such folks to remain employed - deserve what they
> get.
I don't disagree; that's why I suggested the comments, although I don't mind
something like reference modification if its use is properly documented in
situ.
Speaking of "properly documented in situ": some years back I encountered a
problem in an unspecified compiler of an unspecified language. I tracked it
down to within a procedure some 1200 source lines long. The local variables
in this procedure were named things like "A" and "Q", and the source-level
indenting bore no relationship whatever to the logic of the routine. The
procedure was devoid of internal comments with one single exception,
somewhere beyond halfway into the procedure, and the comment read "Yes, this
is what you think it is ... ". Took me many, many hours to untangle this
code to figure out that what it was doing was optimizing a subtraction of an
item from itself into a setting of that item to zero. In this case I ripped
the optimization out on the dual grounds that the code was broken and that
anyone who was doing this almost certainly intended the code to do exactly
what he told it to do, not something else entirely.
Over the last two decades, all but three of the significant areas revised by
this particular author (who left Unisys' employ shortly before my move from
field support to the plant in '84) in this particular compiler have been
overwritten on the grounds not only that the logic was obscure but also that
it had been demonstrated to be unreliable, and not at all infrequently
incorrect on principle, however blindingly fast the generated code might
have been. In the remaining three cases, there are some edge conditions in
which the logic doesn't do what I think it ought to do, but we have chosen
to identify and document these cases as anomalies because correcting them
would cripple the performance of other cases that produce indisputably
correct answers. A total rewrite has been considered, but rejected on
cost/benefit/risk grounds.
For some years I seriously considered hanging an effigy doll over the
entrance to my cubicle anytime I was attempting to find and correct a bug
introduced by this person's logic, not an infrequent occurence.
-Chuck Stevens
Howard Brazee
On 12-May-2004, l.wi...@jpberlin.de (Lueko Willms) wrote:
> HB> The standard was to PERFORM MY-PARAGRAPH THRU MY-PARAGRAPH-EXIT.
> HB> Every paragraph was followed by an -EXIT paragraph that only
> HB> contained EXIT.
> HB>
> HB> This was a big improvement over PERFORM MY-SECTION.
>
> Hä? Strange statement .... how could that be an improvement?
Adding a performed paragraph at the end of a program containing sections is an
error that doesn't always get caught in time.
I have worked in shops that had the following standard back for shops that had
internal sorts when those sorts could not perform paragraphs:
SORT-OUT SECTION.
SORT-OUT-PARAGRAPH.
PERFORM THIS-AND-THAT.
REST-OF-THE-PROGRAM SECTION.
THIS-AND-THAT.
All of the rest of the program is in this dummy section that only serves as a
end-delimiter to the "real" section.
Chuck Stevens
> I tried to clarify "most compilers" to mean 'the most commonly used.' Over
90%
> of the production Cobol running today was compiled by IBM, Micro Focus or
> Fujitsu. Do you dispute that?
I would be surprised were that the case. What is the basis for this
figure? Is that 90% of COBOL source lines worldwide, 90% of production
COBOL programs in the United States, 90% of the COBOL shops in Armonk that
have been using GOBACK since the days of DOS COBOL, 90% of the logic touched
during transaction processing worldwide? I can think of several
*extremely* large COBOL environments right off the top of my head in which
compilation by IBM, Micro Focus or Fujitsu compilers would not be relevant,
including just as examples the national banks of several countries and the
interbank networks of several more.
And even if the 90% figure can be shown to be accurate, if your ability to
cash a check, access an ATM, purchase gasoline, register as a patient in the
hospital of your choice, have your insurance claims processed, or even
retrieve a voice-mail message is handled by that 10%, it's not clear to me
that the 10% is all that irrelevant!
-Chuck Stevens
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>
><docd...@panix.com> wrote in message news:c7rvbr$86s$1...@panix5.panix.com...
>
>> But I digress... in the example you gave you used what appeared to be
>> reference modification ('STRING raw-date (5:2)'); is that in MCP/AS
>> COBOL74?
>
>Noit is not; reference modification is a new feature associated with the '85
>standard, and is in COBOL85.
That's what I thought, aye.
[snip]
>Both the Unisys MCP/AS COBOL compilers are regularly called upon to compile
>monolithic programs in the range of half a million source lines and more,
>and customers with such large programs must sometimes do what is necessary
>to recompile them after seemingly minor changes if they are to remain
>monolithic.
'Our system was designed, decades ago, to use Phillip's-head screws. Over
the years these have been changed to hex-head screws... so every time we
open a toolbox and find a Phillip-shead screwdriver we get out a
blowtorch, a four-pound sledgehammer and a special form we made; we heat
the screwdriver-tip until it's red-hot and then use the sledgehammer to
pound it into the form until the tip is re-shaped into a hex-head.'
'Wouldn't it be better to buy a new hex-head driver?'
'We don't have the budget for development, only maintenance.'
(this is the first time I've formulated this metaphor... feel free to use
it.)
When it is time for system redesign it is time for system redesign... to
quote Jefferson, 'We might as well require a man to wear still the coat
which fitted him when a boy as civilized society to remain ever under the
regimen of their barbarous ancestors.'
[snip]
>> Those who rely on job security due to idiosyncratic knowledge - and the
>> institutions which allow such folks to remain employed - deserve what they
>> get.
>
>I don't disagree; that's why I suggested the comments, although I don't mind
>something like reference modification if its use is properly documented in
>situ.
All things in moderation... moderation included, of course.
[snip]
>Over the last two decades, all but three of the significant areas revised by
>this particular author (who left Unisys' employ shortly before my move from
>field support to the plant in '84) in this particular compiler have been
>overwritten on the grounds not only that the logic was obscure but also that
>it had been demonstrated to be unreliable, and not at all infrequently
>incorrect on principle, however blindingly fast the generated code might
>have been.
'The results can't be trusted, no... but we get them so quickly!'
>In the remaining three cases, there are some edge conditions in
>which the logic doesn't do what I think it ought to do, but we have chosen
>to identify and document these cases as anomalies because correcting them
>would cripple the performance of other cases that produce indisputably
>correct answers. A total rewrite has been considered, but rejected on
>cost/benefit/risk grounds.
... and besides... all ya gotta do is take out the blowtorch, heat the
screwdriver-tip until it glows read and then use the sledgehammer to pound
it into the form...
>
>For some years I seriously considered hanging an effigy doll over the
>entrance to my cubicle anytime I was attempting to find and correct a bug
>introduced by this person's logic, not an infrequent occurence.
'... not an infrequent occurence' seems to contradict 'rejected on
cost/benefit/risk grounds'... but my ability to see such appearances might
be why I don't get to make budget decisions.
DD
Howard Brazee
On 12-May-2004, "Chuck Stevens" <charles...@unisys.com> wrote:
> Both the Unisys MCP/AS COBOL compilers are regularly called upon to compile
> monolithic programs in the range of half a million source lines and more,
> and customers with such large programs must sometimes do what is necessary
> to recompile them after seemingly minor changes if they are to remain
> monolithic.
I remember using Univac Cobol with huge LINKAGE DIVISIONS full of database
record descriptions.
Howard Brazee
On 12-May-2004, docd...@panix.com wrote:
> 'Our system was designed, decades ago, to use Phillip's-head screws. Over
> the years these have been changed to hex-head screws... so every time we
> open a toolbox and find a Phillip-shead screwdriver we get out a
> blowtorch, a four-pound sledgehammer and a special form we made; we heat
> the screwdriver-tip until it's red-hot and then use the sledgehammer to
> pound it into the form until the tip is re-shaped into a hex-head.'
>
> 'Wouldn't it be better to buy a new hex-head driver?'
>
> 'We don't have the budget for development, only maintenance.'
>
> (this is the first time I've formulated this metaphor... feel free to use
> it.)
Thanks!
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
>
>On 12-May-2004, docd...@panix.com wrote:
>
[snip]
>> 'We don't have the budget for development, only maintenance.'
>>
>> (this is the first time I've formulated this metaphor... feel free to use
>> it.)
>
>Thanks!
Anytime.
DD
William M. Klein
> docd...@panix.com wrote:
<snip>
> I tried to clarify "most compilers" to mean 'the most commonly used.' Over 90%
> of the production Cobol running today was compiled by IBM, Micro Focus or
> Fujitsu. Do you dispute that?
>
Yes, I dispute that.
I think that RM, AcuCOBOL, HP (Including former DEC and TANDEM), and Unisys (not
to mention OpenCOBOL, KOBOL, etc) constitute a FAR greater per centage than 10
per cent. In fact, I think that Fujitsu and Micro Focus combined probably
constitute less than 20 per cent of all production code today. (As far as IBM
COBOL goes, I think that a medium-larger part is on OS/400 - which has VERY
different syntax support than what RW tends to assume that "all" IBM COBOL
supports)
HOWEVER, I also admit that all that I state above is "only a feeling" and that I
don't have hard evidence to back this up. On the other hand, the problem with
your (RW's) contention is that I don't think YOU have any evidence (other than
your own experience) to back up your statement either.
This is the problem I have always had with your "generalizations" - that you
make them based on your experience - but "phrase them" as if they were fact.
Donald Tees
>
> 'Our system was designed, decades ago, to use Phillip's-head screws. Over
> the years these have been changed to hex-head screws... so every time we
> open a toolbox and find a Phillip-shead screwdriver we get out a
> blowtorch, a four-pound sledgehammer and a special form we made; we heat
> the screwdriver-tip until it's red-hot and then use the sledgehammer to
> pound it into the form until the tip is re-shaped into a hex-head.'
>
> 'Wouldn't it be better to buy a new hex-head driver?'
>
> 'We don't have the budget for development, only maintenance.'
>
> (this is the first time I've formulated this metaphor... feel free to use
> it.)
>
You forgot the pair of vice-grips to hold (and turn) the screwdriver with.
Donald
docd...@panix.com
Donald Tees <donal...@sympatico.ca> wrote:
>docd...@panix.com wrote:
>>
[snip]
>> (this is the first time I've formulated this metaphor... feel free to use
>> it.)
>>
>
>You forgot the pair of vice-grips to hold (and turn) the screwdriver with.
No vise-grips... that's scheduled for the next release.
DD
Chuck Stevens
> >Both the Unisys MCP/AS COBOL compilers are regularly called upon to
compile
> >monolithic programs in the range of half a million source lines and more,
> >and customers with such large programs must sometimes do what is
necessary
> >to recompile them after seemingly minor changes if they are to remain
> >monolithic.
Docdwarf replied:
> 'Our system was designed, decades ago, to use Phillip's-head screws. Over
> the years these have been changed to hex-head screws... so every time we
> open a toolbox and find a Phillip-shead screwdriver we get out a
> blowtorch, a four-pound sledgehammer and a special form we made; we heat
> the screwdriver-tip until it's red-hot and then use the sledgehammer to
> pound it into the form until the tip is re-shaped into a hex-head.'
...
> When it is time for system redesign it is time for system redesign... to
> quote Jefferson, 'We might as well require a man to wear still the coat
> which fitted him when a boy as civilized society to remain ever under the
> regimen of their barbarous ancestors.'
As it happens, later versions of the application-development product that is
the most frequent offender in this area no longer generate such huge
programs, but for those users that are comfortable with the existing
product, they see need neither to regenerate their applications nor rewrite
the programs they generate. Your opinion of how much money they need to
spend Right Now to fix what you regard as a critical problem might well
differ from theirs, and it's their money!
> 'The results can't be trusted, no... but we get them so quickly!'
I don't disagree. If the customer has always gotten the right answer, it is
reasonable for him to complain if it suddenly takes twice (or three times or
ten times) the processor resources it once did to produce the same answer
after recompiling a program. The priorities you as an outside observer
might mandate for the compiler developers might not match the priorities
that actual customers of the product might request!
> ... and besides... all ya gotta do is take out the blowtorch, heat the
> screwdriver-tip until it glows read and then use the sledgehammer to pound
> it into the form...
I went back and checked, and that's not it -- in fact, the edge cases in
question are ones in which the programmer is already attempting to use a
screwdriver as a sledgehammer, and the documentation clearly suggests "Don't
DO that!". The constructs in question work just fine when they are used in
any manner that can be considered "reasonable". But I have learned from
painful experience that "nobody in his right mind would dream of coding such
a thing" is irrelevant when it comes to what a compiler encounters.
For example, I can't imagine using INSPECT ... REPLACING on a *signed
numeric* item as having any positive impact -- it looks to me like it's a
guarantee of data corruption, and at best is an example of an attempt to use
a welder's torch to dig a hole. However, the standard specifies the
behavior in this area, and we actually had a bug fix a while back to ensure
that the statement now corrupts the numeric item in exactly the way the
standard says it should!
> >For some years I seriously considered hanging an effigy doll over the
> >entrance to my cubicle anytime I was attempting to find and correct a bug
> >introduced by this person's logic, not an infrequent occurence.
>
> '... not an infrequent occurence' seems to contradict 'rejected on
> cost/benefit/risk grounds'... but my ability to see such appearances might
> be why I don't get to make budget decisions.
No, I think you misunderstood. Most of the areas touched by this particular
author were not only buggy but philosophically incorrect in context, and
have long since been rewritten to eliminate both the manifestation (the
incorrect behavior) and the cause (the wrong-headed approach to the
problem).
The three remaining areas were restructured to improve clarity (without
actually revising the logic flow) eleven years ago, and there have only been
three problems reported in these areas since that time, the last one over
three years ago, all corrected. Despite the code cleanup, when bugs do
surface in these areas they can still be time-consuming to correct, and the
corrections often involve disabling some sort of optimization.
There is no contradiction; the bugs being mentioned were "not an infrequent
occurrence" *until* the logic was redesigned and rewritten (many years ago)
to correct the underlying incorrect assumptions. The bugs are gone because
the code that contained them is gone. There may or may not be bugs in the
*new* code, but they can't be laid at the feet of the author of the *old*
code.
The "risk" in this equation is the risk to current users of the affected
code that rewriting it might entail, and the likelihood that we would spend
more time correcting problems in the new code than we would have spent had
we left it alone, with its current (and documented) restrictions. If
nobody is complaining about its current behavior -- including the documented
restictions -- it's difficult to support a rewrite just on accounta it looks
yucky. If it works, don't fix it.
-Chuck Stevens
Richard
> >> That may be because they always write programs with what I call
> >> 'heavyweight' procedures. When they code a part that is to be
> >> PERFORMed they do it with a lot of red tape. If they perform sections
> >> then they must create a section header an initial paragraph label
>
> That is necessary because the syntax says so
Yes, but if they perform paragraph labels then they don't need to
create a section header. Thus the section header is not 'necessary'.
> >> and an end paragraph label,
>
> which is superflouus -- there is neither a practical need for it
> nor a syntactical rule calling for it
My original message was in response to a question:
>>> Why are programmers punishing themselves doing it as in B?
The 'they' in my response are those that are 'punishing themselves'
writing in what I call 'heavyweight style'. I completely agree that
there is 'no practical need', except of course if they were to want to
use a GO TO, which is the whole point of using 'heavyweight style' in
the first place.
If there is no need for the exit paragraph, then there is also no need
for the section header as the only point of having a section is to
encompass all the paragraphs within it (as long as _all_ PERFORMs are
of paragraphs). This is then a move from a heavyweight:
43210-Process-Me SECTION.
43211-Process-Me-Start.
code.
43219-Process-Me-Exit.
EXIT.
to a lightweight:
Process-Me.
code
.
> >> they alloacte a new prefix number to indicate its place in the
> >> program hierarchy, almost guaranteeing that it won't be reused from
> >> somewhere else, and they move the code to the physical placement in
> >> the source given by its prefix.
>
> I have never used such prefix numbers, and I recommend not doing so.
Prefix numbers were extremely useful 30 years ago when my source code
was in a card box or two and I worked from lineflow listings. Some
haven't moved on since then ;-)
> The name of the SECTION should be clear enough to tell the reader
> what purpose this section does have.
I entirely agree with you, except the bit where you said 'SECTION'.
Howard Brazee
On 12-May-2004, rip...@Azonic.co.nz (Richard) wrote:
> > I have never used such prefix numbers, and I recommend not doing so.
>
> Prefix numbers were extremely useful 30 years ago when my source code
> was in a card box or two and I worked from lineflow listings. Some
> haven't moved on since then ;-)
And they survive because they don't cause harm.
Lueko Willms
in c7o92n$eoh$1...@peabody.colorado.edu
ueber Re: Perform Thru/Go to vs. Perform - Compile Speed
HB> If mainframe shops (and their vendors) ever see a cost-benefit value
HB> in upgrading to the current ANSI version of CoBOL, the King of
HB> England may have reason to change his mind about the value of -EXIT
HB> paragraphs.
As a republican democrat, opposed to monarchy, I have advised
against PERFORMing paragraphs and -EXIT-paragraphs decades ago.
The monarchy, as belonging to the past, is lagging vastly behind.
Robert Wagner
>robert.d...@wagner.net (Robert Wagner) wrote
>
>> Since you're not using PERFORM, there is no need for paragraph labels at all.
>
>CALL does not replace PERFORM, PERFORM is the mechanism for
>repitition, where is the CALL .. VARYING .. UNTIL ? What would you
>use ? GO TO ?
The demo programs I posted use inline PERFORM for loop control and CALL in place
of PERFORM paragraph-name.
>It is also pointless, it introduces problems that you haven't thought
>of (such as name space polution)
It's no worse than the possibility of using the same data name twice. Nobody
complains about that.
>> Micro Focus *requires* ENTRY to do recursion. It doesn't allow Nested
Programs
>> to call themselves.
>
>Your original claim was: "Yet another advantage is that ENTRY supports
>recursion."
>In fact MicroFocus does _NOT_ require ENTRY to do recursion:
>
> """A program can call itself via either its program-id or an entry
>point."""
>It is true that nested programs cannot recursively call themselves,
>but external called programs can call themselves.
Correct. Requiring separate compilation for the recursive portion of a program
is an ugly solution, especially in a demo. The *practical* way to demonstrate
recursion is through ENTRY.
>> LINKAGE items are not a problem if each 'program' restricts itself to
variables
>> listed in its ENTRY statement, and does not call subordinate 'programs' which
>> re-use them i.e. potentially change addressability.
>
>It was your suggestion that all paragraphs be replaced by ENTRY, now
>all the data items need to be reworked into LINKAGE, _and_ the logic
>must be restricted to a single level.
The trees demo I posted has four simple variables in LINKAGE and multi-level
CALLs.
If you want to construct straw men, you should insure they're not refuted by
recently posted code.
>> My proposal merely changes the grammar of
>> PERFORM to be consistent with that of CALL by allowing one to pass parameters
>> and eliminating the troublesome THRU.
>
>That is not what you proposed at all.
That's what my code does.
>I recall that previously you were unconcerned about what the standard
>said, it was quite clear that you had hardly read it even, your
>criteria was 'whatever extensions the MF and Fujitsu compiler did'
>_regardless_ even that the vendor's own manual did not support them.
>
>For example:
>
>""" -------------
>>But it ain't Cobol. POINTER is an extension in Cobol'85 and the use
>of
>>them may be different, or not implemented at all, on current
>compilers.
>
>This is FUD (fear, uncertainty and doubt). In practice, it is
>implemented
>exactly the same on all mainstream compilers: Micro Focus, IBM and
>Fujitsu. It
>is real-world COBOL, even though you don't like it.
My first preference is the J4 Standard. When it lets us down, as it did with
pointers, my second preference is de-facto standards. In the case of pointers,
the three compilers used by more than 90% of Cobol programmers support the EXACT
SAME syntax. That's a good example of a de-facto standard.
>Your 'proposal' decries your assertion that you are a 'born again'
>standards follower. ENTRY will not be found in the standard.
ENTRY is another de-facto standard, having the EXACT SAME syntax on IBM, Micro
Focus and Fujitsu. It didn't go away when Nested Programs were introduced in
'85, so I doubt it will be dropped.
Robert Wagner
>
>On 12-May-2004, robert.d...@wagner.net (Robert Wagner) wrote:
>
>> I tried to clarify "most compilers" to mean 'the most commonly used.'
>
>Sort of like saying "most operating systems have a start button that you press
>when you want to shut down the computer".
Haven't you seen the prompt "Press Enter to exit"?
>> Over 90% of the production Cobol running today was compiled by IBM, Micro
>> Focus or
>> Fujitsu. Do you dispute that?
>
>What relation does "Over 90% of production Cobol running today" have to do with
>"most compilers"?
Answered in my response to Chuck Stevens.
>How many compilers run on IBM mainframes, vs how many compilers run on PC's,
>mini computers, and other Mainframe computers?
If number of compilers available or installed was relevant, a free compiler
downloaded by 1,000,000 people (but used by few) would be 33 times more
significant than the estimated 30,000 IBM mainframe Cobol compilers worldwide.
Robert Wagner
>
>"Robert Wagner" <robert.d...@wagner.net> wrote in message
>news:40a1f7c7....@news.optonline.net...
>
>> I tried to clarify "most compilers" to mean 'the most commonly used.' Over
>90%
>> of the production Cobol running today was compiled by IBM, Micro Focus or
>> Fujitsu. Do you dispute that?
>
>I would be surprised were that the case. What is the basis for this
>figure? Is that 90% of COBOL source lines worldwide, 90% of production
>COBOL programs in the United States, 90% of the COBOL shops in Armonk that
>have been using GOBACK since the days of DOS COBOL, 90% of the logic touched
>during transaction processing worldwide?
I meant source lines and logic touched in the US and Canada. Assuming equal
productivity and turnover (human nature being fairly constant), we can determine
relative usage from job ads. I just went to DICE and entered search keys all
beginning with "cobol and (programmer or developer) and ..". To find IBM
mainframe, I used "(mainframe or cics) and not unisys and not unix". To find
Unisys, I used "unisys and not unix and not cics". The results were:
IBM mainframe 217
AS/400 35 67% IBM
Unix 46
PC (xp or nt) 36
client-server 19 27% MF & a little IBM
Tandem 12
Unisys 9
Accu Cobol 2
Fujitsu 0
Realia 0
Siemens 0
Total 376
This shows 94% of professional programmers are using IBM or MF.
Under-represented are programmers working solo, for very small companies and in
academic settings.
Richard
> > Prefix numbers were extremely useful 30 years ago when my source code
> > was in a card box or two and I worked from lineflow listings. Some
> > haven't moved on since then ;-)
>
> And they survive because they don't cause harm.
If someone were still rewriting the same programs that were being
written a quarter century ago (eg batch update, batch report), using
the same basic tools and reusing the same HIPO charts then I can see
how they may still find comfort in nicely numbered labels. ;-)
In my view they do cause harm, or would to me if I used them. The
implication of having numbered labels is there there is some strict
hierarchy in the code where 05... levels can only be performed from
04... levels, and also that the source code order is determined by
this numbering. All the 05... must be after all the 04... labels.
Typically, my code cannot be organised that way. Interactive systems
have their code executed in the order determined by the user input,
and does not follow some deterministic master plan (as batch programs
tend to). The numbering is also a (possibly small) overhead on
creating new procedures. If 'heavyweight' procedures are used then it
is another reason not to just create a new paragraph and perform it,
even if this could be performed from several places. It may be easier
to just add the code into and existing section and copy the code lines
to other sections that would use it. This is especially so if that
small new procedure just _had_ to be moved away where it would be
lost.
Using a 'lightweight' procedure style (ie dropping all the cruft,
especially numbering and shuffling code) means that the program is
many small, localised, reusable, paragraphs.
Label numbering was the first thing that I dropped a quarter century
ago when I got a decent screen based text editor that could just
search for what I wanted.
You may be lost without them, I find them extremely harmful.
Robert Wagner
>"Robert Wagner" <robert.d...@wagner.net> wrote in message
>news:40a1f7c7....@news.optonline.net...
>> docd...@panix.com wrote:
><snip>
>> I tried to clarify "most compilers" to mean 'the most commonly used.' Over
90%
>> of the production Cobol running today was compiled by IBM, Micro Focus or
>> Fujitsu. Do you dispute that?
>>
>
>Yes, I dispute that.
>
>I think that RM, AcuCOBOL, HP (Including former DEC and TANDEM), and Unisys
(not
>to mention OpenCOBOL, KOBOL, etc) constitute a FAR greater per centage than 10
>per cent.
I tried to provide evidence in reply to Chuck Stevens. A search for "cobol and
(rm or liant)" found zero. Accu Cobol and Unisys were previously reported.
"cobol and (dec or vax)" found three, one of which was a 'migration' away from
former DEC. "cobol and hitachi" (said to be a mainframe power outside the US)
returned one hit .. for a PC programmer.
HP does have their own compiler. The two HP (3000) shops I worked at recently
both used Micro Focus in preference to HP's.
OpenCOBOL, KOBOL and the like are toy compilers for hobbiests.
It is possible that job boards -- DICE and similar net-temps, monster, jobs,
etc. -- may be biased in that they look primarily for contractors as opposed to
employees. That means employers tend to be large (F-100) companies and
government agencies powered by politics and little concern for efficiency.
Can you make a case for 'right thinking' companies using other Cobol compilers?
> In fact, I think that Fujitsu and Micro Focus combined probably
>constitute less than 20 per cent of all production code today.
That's in the ballpark. I've heard, from several sources, that Fujitsu is 'very
popular' outside the US. I can't think of a way to quantify that.
> (As far as IBM
>COBOL goes, I think that a medium-larger part is on OS/400 - which has VERY
>different syntax support than what RW tends to assume that "all" IBM COBOL
>supports)
How odd it doesn't use the same 'front end' as other IBM compilers. On second
thought not so odd because AS/400 people like to think they have 'better ideas'
than everyone else. Kinda like Apple people, who don't have any Cobol and less
than 5% of market share.
I'm now on a project 'migrating' a major system from AS/400 to Unix. My
incidental exposure to AS/400 technology shows the debugger to be Grade C. Same
for the touted Integrated Database, which allows VSAM-oriented programmers to
conduct business-as-usual under the guise of being 'modern'. Database concepts
are out the window; it requires a program change every time a column is changed.
AS/400 had its genesis in a 1970 revamp of S/360 to something called NS (New
System). IBM management scrapped that plan and replaced it with S/370, a bigger
faster 360. NS resurfaced ca. 1980 as the AS/400. It has stagnated since then,
trying to use '80s technology to compete with Microsoft and Unix innovations.
>HOWEVER, I also admit that all that I state above is "only a feeling" and that
I
>don't have hard evidence to back this up. On the other hand, the problem with
>your (RW's) contention is that I don't think YOU have any evidence (other than
>your own experience) to back up your statement either.
>
>This is the problem I have always had with your "generalizations" - that you
>make them based on your experience - but "phrase them" as if they were fact.
It's not about experience, it's about reality. Reality is what keeps us honest.
It's the common ground we can't dispute, despite our emotional feelings favoring
other explanations.
Robert