You're invited to critique my new Cobol page I started
Robert M. Pritchett - RMP Consulting Partners LLC
but I think it's off to a good start.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Steve Thompson
of GO TO. However, if it is your wish to practice religion, then
sacrifice yourself upon the ALTER.
I don't know where you want to go with your COBOL page, but, if
you haven't already, check out alt.cobol (too) and you may get
some more ideas of what to do on your page/site.
"Robert M. Pritchett - RMP Consulting Partners LLC" wrote:
>
> It's at http://rmpcp.com/cobol.html - I'm not finished with it obviously
> but I think it's off to a good start.
>
<snip>
--
Steve Thompson
OSP LLC
330/335-9907 office
330/334-2097 fax
Remove "_" in email address to contact me -- anti-spam measures
in use
Howard Brazee
"Robert M. Pritchett - RMP Consulting Partners LLC" wrote:
>
> It's at http://rmpcp.com/cobol.html - I'm not finished with it obviously
> but I think it's off to a good start.
The only web pages I do is documentation for programs. One thing which
I have been trying to find out (I use Netscape Composer) is how to make
a URL open a new version of Navigator instead of using the old one.
Then I saw your newsgroup message did that - How is this determined?
Cheesle
wrote in message
news:4Z9k4.3741$%87.1...@newsread1.prod.itd.earthlink.net...
> It's at http://rmpcp.com/cobol.html - I'm not finished with it obviously
> but I think it's off to a good start.
My compliments. A structured and informative page. A pleasure to read your
main article which I found to be very informative. A real value for
programmers that are non Cobol and want to know what it is all about. I
believe non-programmers won't get much, but they are probably not the target
either?
Cheesle
Robert M. Pritchett - RMP Consulting Partners LLC
implemented a nice set of structured programming macros like I did for MIX
in college, you pretty much have to put your own structures together with
the various kinds of branches. Of course, Cobol is supposed to be a higher
level language with the control structures already included, so to me
GoTo's are not only unnecessary, they're unnecessarily dangerous. And of
course I have noticed over the years that various opinions about these
issues exist and sometimes even become fanatic. So I may as well come out
of the closet on this one (not that I was ever in it anyway) - yes, I am a
structured programming fanatic and proud of it. The GoTo stops here. :)
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Steve Thompson wrote in message <3891A410...@neo.rr.com>...
Warren Simmons
Isn't it rewarding to have a reserved word list that grows like the
dictionary?
Bad at one time was considered unexceptable, now to some it means good. <G>
Warren Simmons
"Robert M. Pritchett - RMP Consulting Partners LLC" <EL.Bu...@rmpcp.com>
wrote in message
news:pUpk4.3121$Sa2.1...@newsread2.prod.itd.earthlink.net...
Jeff Baynard
years, so many of them are of very poor quality <snip>.
-- this is simply not true. What do you define as quality? Readability?
No, quality is software that works and I've seen no discernible difference
in quality between our old stuff and our new stuff.
As a result, there is no longer any excuse for new Cobol programs to be
written with GoTo's, Alter's, Perform Thru's, fall thru's, Next Sentence,
Sections, simple Exit statements, or periods on executable statements
themselves.
--- I've had no problems using (most) of these constructs and I've been
programming COBOL only for a year.
An example of poor design in Cobol itself is the ability of a paragraph or
section in the Procedure Division to be used in several ways, by fallthru,
GoTo, Perform, Perform Thru, etc. even several ways at once in the same
program from different points.
--- This is a good point. I guess that's the purpose of a shop standard.
We use Perform Thru and many programs use GOTO. But fallthru is generally
dangerours especially for the maintenance programmer.
Some languages support some overlap between subroutines and functions but
those are still modularly invoked, while GoTo's may never come back and you
never know where without following the spaghetti.
--- This 'modularity' you describe is the result of quality code and
testing, not the language it's written in.
At least when you look at a piece of code you can tell how it's executed
without having to look everywhere else.
--- Again, I don't feel that COBOL has anything to do with this. Quality
code is good code. I have seen plenty of total crap code in all
languages... most of it never makes production or does anything useful. The
purpose of good code is to make the computer do what you want. I kind of
think the page has a general negative attitude toward the language that many
of us make a good living off of. Sometimes when we're greedy and selfish we
don't realize it, but being a programmer is a hell of a good job nomatter
what language. But good page... I like the attack toward style. Please
include some sort of style section!
Jeff
Warren Simmons
material presented.
Presentation should be directed to attracting someone to the service
offered. Since it seems to be
to do it in COBOL, stressing the positives of the modern version of the
language will interest more
potential customers, and a stiring of the pot of the evolution.
Warren Simmons
"Jeff Baynard" <uni...@macconnect.com> wrote in message
news:86tj0...@enews3.newsguy.com...
DennisHarley
I have seen people use PERFORM ABEND-ROUTINE, but they are only spelling "GO
TO" incorrectly.
Even C has a GOTO.
If the coding is easier to understand with the use of a GO TO, why not use
it?
Robert M. Pritchett - RMP Consulting Partners LLC
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Jeff Baynard wrote in message <86tj0...@enews3.newsguy.com>...
>CoBOL (COmmon Business Oriented Language) programs have been around for
>years, so many of them are of very poor quality <snip>.
>
>-- this is simply not true. What do you define as quality? Readability?
>No, quality is software that works and I've seen no discernible difference
>in quality between our old stuff and our new stuff.
===> I'm not saying that all old programs are of poor quality, just that
there's a high correlation. There are lots of poorly written programs out
there. And a quality program is not only correct in execution but also easy
to read and understand so that it's easy to maintain.
>
>As a result, there is no longer any excuse for new Cobol programs to be
>written with GoTo's, Alter's, Perform Thru's, fall thru's, Next Sentence,
>Sections, simple Exit statements, or periods on executable statements
>themselves.
>
>--- I've had no problems using (most) of these constructs and I've been
>programming COBOL only for a year.
>
===> As you get more experience you'll appreciate this.
>
>An example of poor design in Cobol itself is the ability of a paragraph or
>section in the Procedure Division to be used in several ways, by fallthru,
>GoTo, Perform, Perform Thru, etc. even several ways at once in the same
>program from different points.
>
>--- This is a good point. I guess that's the purpose of a shop standard.
>We use Perform Thru and many programs use GOTO. But fallthru is generally
>dangerours especially for the maintenance programmer.
>
===> You partly miss the point but you're right about fallthru's.
>
> Some languages support some overlap between subroutines and functions but
>those are still modularly invoked, while GoTo's may never come back and
you
>never know where without following the spaghetti.
>
>--- This 'modularity' you describe is the result of quality code and
>testing, not the language it's written in.
>
===> Good code is not the result of the language but a poor language or
coding habit makes writing good code an uphill battle, while good languages
more easily support good coding practices which make it easier to write
good code.
>
>
> At least when you look at a piece of code you can tell how it's executed
>without having to look everywhere else.
>
>--- Again, I don't feel that COBOL has anything to do with this.
===> You miss the point entirely; as it was a technical point relating
specifically to the Cobol language, I should probably illustrate later when
I have time. I think only assembler code has Cobol's lack of control in
that when you see a paragraph or section you don't know whether it's
performed, goto'd, or both without looking elsewhere. Every other high
level language makes it obvious and the same piece of code can't be both
called and goto'd, it's one or the other and it's obvious which.
Quality
>code is good code. I have seen plenty of total crap code in all
>languages... most of it never makes production or does anything useful.
The
>purpose of good code is to make the computer do what you want.
===> True - but there's still lots of crap in production and not just in
Cobol. Even dead code, tautologies and impossibilities due to
misunderstanding of DeMorgan's rules, etc. as well as just misleading code
that does something other than what it looks like at first and is a booby
trap for maintenance.
I kind of
>think the page has a general negative attitude toward the language that
many
>of us make a good living off of.
===> Good point, not intended as negative toward the language but to bad
coding practices. Maybe I should brighten it up and clarify it a bit.
Sometimes when we're greedy and selfish we
>don't realize it, but being a programmer is a hell of a good job nomatter
>what language.
===> Yes, I love it.
But good page... I like the attack toward style. Please
>include some sort of style section!
===> Definitely planned as time permits. Thanks.
>
>Jeff
>
Robert M. Pritchett - RMP Consulting Partners LLC
is cleanup of bad code.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Warren Simmons wrote in message <86tt3e$aku$1...@bgtnsc03.worldnet.att.net>...
Robert M. Pritchett - RMP Consulting Partners LLC
as cleanly structured as it should be, and/or it's those programmers who
never quite fully understood structured programming who would find it
"easier to understand". Which again supports my contention that old coding
standards in many shops, which are afraid to challenge the intelligence of
their staff, effectively reduce software quality to the lowest common
denominator.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
DennisHarley wrote in message <#wgNZYia$GA.307@cpmsnbbsa02>...
DennisHarley
GO TO ABEND-ROUTINE.
PERFORM ABEND-ROUTINE
or what?
Robert M. Pritchett - RMP Consulting Partners LLC <EL.Bu...@rmpcp.com>
wrote in message
news:2dGk4.4560$Sa2.1...@newsread2.prod.itd.earthlink.net...
> If the code is "easier to understand" with a GoTo, that's because it's not
> as cleanly structured as it should be, and/or it's those programmers who
> never quite fully understood structured programming who would find it
> "easier to understand".
Understanding Structured Programming is not the issue.
The problem is that you want support of the rules you feel are valid.
Anyone who disagrees with you doesn't understand.
You disapprove of limited use of explicit GO TO statements.
Isn't CONTINUE an implicit GO TO?
Don't we interpret IF, THEN, ELSE constructions with an implied GO TO?
Ken Foskey
> CoBOL (COmmon Business Oriented Language) programs have been around
> for years, so many of them are of very poor quality <snip>.
To which Steve Thompson wrote:
> This is simply not true. What do you define as quality?
> Readability? No, quality is software that works and I've seen no
> discernible difference in quality between our old stuff and our new
> stuff.
And Robert responded :
> ===> I'm not saying that all old programs are of poor quality, just
> that there's a high correlation. There are lots of poorly written
> programs out there. And a quality program is not only correct in
> execution but also easy to read and understand so that it's easy to
> maintain.
If a program works and needs no changes then there really is no
quality problem. Even if the code is truly awful, the design was good
enough to survive the test of time.
The issue arises when you are asked to make a change to a currently
running system. You then need to carefully graft your extra features
into an existing framework. If the original code is good then it is
relatively trivial to graft additional features and reuse some
sections of the code. If it is poor then it requires great skill to
rework the existing process into a reliable changed program.
I have so many times seen modifications that work but are not the best
change that could be applied because the programmer did a minimal
change even if this approach was not the clearest. This is entropy at
it best after about ten of these modifications you can't make a change
without breaking something and you have to totally rework the code
from scratch again. Once again the choice to rework the program is
rarely done and programmers complain bitterly and suffer long testing
cycles with the 'monster program from hell'
Refactoring: The process of changing the program code without changing
the functionality.
Change: Refactor the program first to make your change easy, then
implement the new functionality.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
Ken Foskey
>
> Even C has a GOTO.
>
I have only once seen a goto used in a C program. It was a low level
internal routine of Linux. Goto's ate not required in C programming.
There are absolutely minimal reasons that they should appear in CObol.
I personally never code them.
Michael Mattias
>Give me your solution:
>
>GO TO ABEND-ROUTINE.
>PERFORM ABEND-ROUTINE
>or what?
MOVE Big-number to return-code.
CLOSE (all open files)
GOBACK.
MCM
Dan Harpold
the same function? I have used GOTOs to back up a few lines and retry a save
operation, for example...
...
try_to_save_data
if_error
if_contention_error
retry_save_up_to_five_times
...
alternate method
...
try_to_save_up_to_five_times
if_succeeded_then_continue
else_if_not_contention_error_then_handle_it
else_next_save
...
I find the first method, although it does use the dreaded GOTO, is cleaner
and easier to read...
"Ken Foskey" <war...@zip.com.au> wrote in message
news:38942B5D...@zip.com.au...
William M. Klein
(mainframe primarily) extensions. Some other COBOL compilers also support
one or both of these extensions. The next Standard will add "goback" (but
not return-code) as "standard COBOL". The next Standard also introduces a
new way of "communicating" a value during a STOP RUN (or GOBACK) - but
doesn't use the "return-code" methodology.
--
Bill Klein
wmklein <at> ix dot netcom dot com
Michael Mattias <michael...@gte.net> wrote in message
news:TX_k4.2783$aZ4....@dfiatx1-snr1.gtei.net...
Judson McClendon
>If the code is "easier to understand" with a GoTo, that's because it's not
>as cleanly structured as it should be, and/or it's those programmers who
>never quite fully understood structured programming who would find it
>"easier to understand
I have seen lots of code that is easier to understand with GO TO.
Unless you have seen all the kinds of code and algorithms that must
be written, you are hardly in a position to make such sweeping and
blanket statements. Any time someone says "this is never" or "this
is always" is showing a restricted viewpoint. I would agree with
you that GO TO is generally not justified, and should be avoided the
majority of the time. But how many structured languages can you
name that do not have statements to exit from the middle of a code
block? Error conditions can sometimes demand it. There is currently
no command in COBOL to do this. We have had a number of long threads
on this issue, but there are certain kinds of code that can only be
made more complex and obfuscated by eliminating GO TO as an exit from
the middle of a paragraph. Not because it is poorly structured, but
because of the functions the code is doing. Curare is a deadly poison
that is fatal in very small doses. In general, it is a good idea not
to inject curare into your bloodstream. However, millions of people
go to hospitals all over the world and curare derivatives are injected
into their bloodstream in extremely small quantities to keep them from
going into shock on the operating table. If the people who developed
this treatment had taken your exact viewpoint, a lot of people who are
walking around would be dead. Just because something can be harmful
when misused, and even if it is generally to be avoided, does not mean
that it must always be avoided in every possible situation. One of
the marks of real genius is looking at a situation where 'everybody
knows' that such and such is true or false, but they see anther view
where it isn't, that everybody else missing by being to fixed and
narrow in their viewpoint. Always be very, very careful how you
select your dogmas. :-)
--
Judson McClendon ju...@bellsouth.net
Sun Valley Systems http://www.sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Jerry Peters
goto's are used extensively to exit various constructs for error
conditions and to improve the common code paths for performance.
Linus has explicitely stated that _he_ uses goto's when
he thinks it's necessary. He also has rejected patches which remove
goto's, especially when he's used them for performance reasons.
I've had to fix some idiots goto'less code in Cobol. Have you ever tried
to figure out an if statement that spans several pages and nests 8 or more
levels deep? Especially when a few goto's would have greatly simplified
the code? You can design a well structured program using goto's; you can
also design a monstrosity by _not_ using goto's. It has much less to do
with goto's than with coding ability and logical thinking.
Jerry
Bjorn Alvik
I also think that we should tell them that SECTIONing of programs is not at
all bad.
Bjorn
Judson McClendon <ju...@bellsouth.net> skrev i
meldingsnyheter:CV3l4.1986$rC3....@news3.mia...
donald tees
>narrow in their viewpoint. Always be very, very careful how you
>select your dogmas. :-)
Yes Judson.
<G>
;<)
Ken Foskey
> I have used GOTOs to back up a few lines and retry a save
> operation, for example...
>
> ...
> try_to_save_data
> if_error
> if_contention_error
> retry_save_up_to_five_times
Why not code:
perform until saved or some-arbitrary-limit-exceeded.
try-and-save
if OK
set saved to true
end-if
end-perform
Ken Foskey
>
> You have not looked at much of the Linux kernel have you?
Yes that right. I code applications not rocket science.
> goto's are used extensively to exit various constructs for error
> conditions and to improve the common code paths for performance.
> Linus has explicitely stated that _he_ uses goto's when
> he thinks it's necessary. He also has rejected patches which remove
> goto's, especially when he's used them for performance reasons.
Performance is rarely an issue with application code. Write it well
first time and then attempt to refactor for performance. Well written
code outshines badly written code every time.
If you follow up with C++ you would use exception to escape a
sequential process that errors. This closely follows the use case
that you would build for the system. That is another argument though.
> I've had to fix some idiots goto'less code in Cobol. Have you ever
> tried to figure out an if statement that spans several pages and
> nests 8 or more levels deep?
Yes. I then break it up into functional groups with a named paragraph
that is called to describe what is occurring. That is I leave
footprints of my path to the next poor sucker (err programmer).
> Especially when a few goto's would have greatly simplified the code?
> You can design a well structured program using goto's; you can
> also design a monstrosity by _not_ using goto's. It has much less to
> do with goto's than with coding ability and logical thinking.
Could not agree more.
Setting good style guidelines for new players adds to your chance of
getting a comprehensible mess rather than an incomprehensible.
donald tees
>
>I've had to fix some idiots goto'less code in Cobol. Have you ever tried
>to figure out an if statement that spans several pages and nests 8 or more
>the code? You can design a well structured program using goto's; you can
>also design a monstrosity by _not_ using goto's. It has much less to do
>with goto's than with coding ability and logical thinking.
>
While I agree that rules for the sake of rules are silly, and while I agree
that there is, indeed, a place for the odd (very odd) goto, laying the blame
for the above sort of code on the head of "structure" is ridiculous.
An eight page IF statement is the result of poor programming and is not
predicated by topdown structure. In fact, I would not consider it topdown at
all. Topdown refers to the practice of sub-dividing a complex method into
multiple simple methods. To equate it to simply avoiding the "GO TO"
statement reveals a profound misunderstanding of the entire methodology.
Readable code is created by trying, real hard, to write code that is easy to
read, then reading it back and changing it until it is easy to read. With
practice, a programmer can even do it the first time. If it were possible to
just make a rule, then have the code magically become readable, then we
would not need programmers.
I could write readable code without "PERFORMS"; using *only* "GOTO's" for
flow control. I have written thousands of lines of code in assembler that
way, simply because that is the most readable way of writing it. I could
even write readable code using nothing but the ALTER statement if I had to.
Rules like "avoid GOTO" are training wheels for beginner programmers.
Structure is just that: the way program parts are put together. You can do
it logically and neatly so that it can be followed, or you can just jam it
all into a source code module and leave a mess. Applying a label to the
various methods does not change their basic nature, nor does it affect
readability.
DennisHarley
The purpose of an ABEND-ROUTINE is to get the attention of Computer
Operations.
A non-zero RETURN-CODE does not get the same attention as an ABEND.
We force ABENDs because of serious errors at run time.
This is normally done with a User ABEND-ROUTINE which calls ILBOABN0, or
CEEABEND.
The User ABEND is also used to invoke the ABEND options for dataset
disposition in the MVS OS/390 world.
The ABEND routine will, among other things:
Call DSNTIAR to format DB2 Error messages (if this is a DB2 error).
Display Error Messages.
Display Control Counts.
CALL the user abend program of your choice.
When running DB2 programs under IJKEFT01, ABENDS are trapped, and a return
code of 12 is issued.
I have seen this cause problems with dataset disposition.
The solution is to run under IJKEFT1B, which does not trap ABENDs.
Even with your solution you need a routine.
The situations which cause the need for a User ABEND are scattered
trroughout a program.
Are you going to going to CLOSE you files all over the place? Will you have
multiple GOBACKs?
Leif Svalgaard
donald tees <don...@willmack.com> wrote
> Jerry Peters wrote in message
> Structure is just that: the way program parts are put together. You can
do
> it logically and neatly so that it can be followed, or you can just jam it
> all into a source code module and leave a mess. Applying a label to the
> various methods does not change their basic nature, nor does it affect
> readability.
It is amazing that 32 years after Dijkstra's GOTO-paper this discussion
still goes on. (just for the record, Dijkstra has also stated that the
teaching and use of COBOL ought to be a criminal offense).
As readable assembler code clearly shows, the GOTO is not the
problem. The programmer is the problem.
For COBOL there is a special problem that once you use a GOTO
you have lost the 'way back'. That is: if you perform A, that performs
B, that go to C, you can't get back to where you performed A. This
means that perform and goto cannot be mixed while retaining a
reasonable structure (except with the artifice of using sections).
This alone relegates GOTOs to error exits and abends where
a GOTO might save the day. Personally, I have never used a
GO TO in COBOL, for the simple reason that I have never
*needed* to, but different applications (and people) may have
different perceived needs.
Michael Mattias
a lot in the IBM mainframe environment, where the Second Coming would not
get the attention of the operators unless it's also accompanied by an abend.
However, most mainframe sites I've worked at have a program which does
nothing but abend, allowing you to set that up as a separate job step,
trigger it based on condition code, and terminate the current (offending)
program in an "orderly" fashion.
--
Michael Mattias
Racine WI USA
DennisHarley wrote in message <#$FsM4#a$GA.315@cpmsnbbsa03>...
>I work in the OS/390 environment:
>
>The purpose of an ABEND-ROUTINE is to get the attention of Computer
>Operations.
>....
David Olson
Judson McClendon <ju...@bellsouth.net> wrote in message
news:CV3l4.1986$rC3....@news3.mia...
> I have seen lots of code that is easier to understand with GO TO.
> Unless you have seen all the kinds of code and algorithms that must
> be written, you are hardly in a position to make such sweeping and
> blanket statements. Any time someone says "this is never" or "this
> is always" is showing a restricted viewpoint. I would agree with
> you that GO TO is generally not justified, and should be avoided the
> majority of the time. But how many structured languages can you
> name that do not have statements to exit from the middle of a code
> block? Error conditions can sometimes demand it. There is currently
> no command in COBOL to do this. We have had a number of long threads
> on this issue, but there are certain kinds of code that can only be
> made more complex and obfuscated by eliminating GO TO as an exit from
> the middle of a paragraph. Not because it is poorly structured, but
> because of the functions the code is doing.
-snipped lots of good stuff _
I agree that there is *nothing* inherently wrong with a forward GO TO. In
fact, using one can make code that it a whole lot more readable,
understandable, and maintainable. It can make a lot of sense to always
PERFORM a subroutine from the mainline, and then exit from the subroutine
with a GO TO the exit if it turns out you really don't want to be there!
As an example, I once found a piece of code in a program we inherited that
used a stupidly long and complex nested IF statement just to avoid a GO TO.
I posted that piece of code for my group with the comment..."If anyone in my
group does this...I'll make you eat the entire listing I find it in" <G>.
David
Howard Brazee
DennisHarley wrote:
>
> Give me your solution:
>
> GO TO ABEND-ROUTINE.
> PERFORM ABEND-ROUTINE
> or what?
I like GO TO ABEND-ROUTINE in the name of honesty, but I am aware that
some compilers do a pre-search for GO TO, and if they find it put out
less efficient code.
Howard Brazee
>
> The issue arises when you are asked to make a change to a currently
> running system. You then need to carefully graft your extra features
> into an existing framework. If the original code is good then it is
> relatively trivial to graft additional features and reuse some
> sections of the code. If it is poor then it requires great skill to
> rework the existing process into a reliable changed program.
Of course if your business doesn't change at all, then they won't need
maintenance programmers. Or anybody else for that matter, as more
adaptable competitors take over.
Howard Brazee
>
> I have seen lots of code that is easier to understand with GO TO.
> Unless you have seen all the kinds of code and algorithms that must
> be written, you are hardly in a position to make such sweeping and
> blanket statements. Any time someone says "this is never" or "this
> is always" is showing a restricted viewpoint. I would agree with
> you that GO TO is generally not justified, and should be avoided the
> majority of the time. But how many structured languages can you
> name that do not have statements to exit from the middle of a code
> block? Error conditions can sometimes demand it.
When I write a new program, the only exits needed from the middle of a
paragraph are those going to an ABORT routine. It is not hard to design
a program so that it doesn't use switches and it doesn't need GO TO
EXIT. Once this technique is learned, it becomes first nature.
There are lots of ways to structure a program. Some structures have GO
TO XXXX-EXIT statements in them. Others do not need these.
Howard Brazee
>
> I've had to fix some idiots goto'less code in Cobol. Have you ever tried
> to figure out an if statement that spans several pages and nests 8 or more
> levels deep? Especially when a few goto's would have greatly simplified
> the code? You can design a well structured program using goto's; you can
> also design a monstrosity by _not_ using goto's. It has much less to do
> with goto's than with coding ability and logical thinking.
>
It isn't hard for someone who doesn't understand how to structure simple
GOTO-less, switch-less to mess up a program entirely by attempting to
remove GOTOs. But someone who knew what he was doing could have done
that same program much more clear and maintainable - WITHOUT resorting
to GOTO statements.
Don't create a rule or standard for a shop without teaching the
programmers how to properly code using that rule or standard.
Bjorn Alvik
Like
nn-XXXXXX SECTION
*+---------------------------------------------
*!
*+----------------------------------------------
00.
......
GO TO 99.
.....
99.
EXIT.
Howard Brazee <bra...@NOSPAMwebaccess.net> skrev i
meldingsnyheter:3895BF99...@NOSPAMwebaccess.net...
Howard Brazee
though that I don't have the ability to persuade people who like GOTO
EXIT to give that up unless I have the ability to force them to. It's
just as well, as I also need the authority to allocate time to teach
them to do it right. Replacing all GOTOs with switches is a cure worse
than the disease.
F. George McDuffee
>> I have seen lots of code that is easier to understand with GO TO.
>> Unless you have seen all the kinds of code and algorithms that must
>> be written, you are hardly in a position to make such sweeping and
>> blanket statements. Any time someone says "this is never" or "this
>> is always" is showing a restricted viewpoint. I would agree with
>> you that GO TO is generally not justified, and should be avoided the
>> majority of the time. But how many structured languages can you
>> name that do not have statements to exit from the middle of a code
>> no command in COBOL to do this. We have had a number of long threads
>> on this issue, but there are certain kinds of code that can only be
>> the middle of a paragraph.
Its been a while since I programmed in COBOL, but the GOTO
question is not just a COBOL problem. In many ways it is like a
pair of Vise-Grips. In most cases a mechanic or technicial will
never use a pair of Vise-Grips as they have the correct tool
available which can be used with much less risk to both the
fastener and mechanic/technician, there are however cases where
the only practible solution is a good pair of Vise-Grips and the
skilled mechanic/technician will recognize this.
So to for the skilled programmer. In normal conditions
constructs other than GOTO are much the better choice,
never-the-less a GOTO is sometimes the correct choice. However
just as the skillful mechanic avoids the use of Vise-Grips the
skillful programmer avoids the use of GOTO.
George
If Education is the answer, what was the question?
Richard Plinston
: It is amazing that 32 years after Dijkstra's GOTO-paper this discussion
: still goes on. (just for the record, Dijkstra has also stated that the
: teaching and use of COBOL ought to be a criminal offense).
: As readable assembler code clearly shows, the GOTO is not the
: problem. The programmer is the problem.
It is mmy view that, in Cobol, the problem with GO TO is not the
GO TO at all. When reading or writing code the GO TO is always
clear and explicit as to what will happen at that point (it may
be wrong but it is always clear).
This gives the impression that a GO TO may be a clearer way of
expressing the program.
The problem with GO TO is that it must have a label. Generally
this means that the program must have more labels (paragraph and
section names). The usual way of increasing the number of labels
to cater for GO TO is to have sections and to add paragraph labels
within this. In Cobol a label can be used in several different
ways: Performed, GOne TO, dropped into, and are of two types
(section and paragraph) which can be made to overlap in
complex ways.
Other languages use different label types for different purposes:
a label that may be used as a target for a goto cannot be used
for any other purpose; a procedure name cannot be used to goto.
When examining a part of the code in a Cobol program where a
mixture of PERFORM and GO TO is used it is necessary to determine
all the paths through the code by examination of the whole
program. That is, if the part of the program being examined
contains a label, for example:
calculate, say, price of item.
calc-paragraph-label.
calculate tax on item.
If it is necessary to change the code such that the price and
tax calculations are revised then the presence of the label
_may_ indicated that it is:
target for a goto
terminates a perform of the paragraph above
target for a perfrom
drops through
So the code above and below the label may be executed separately
or together in arbitrary ways.
The only solution is to examine the whole source code to determine
every possible path involving this label and the labels above.
If, in examining some code, a GO TO is found, this is trivial to
trace and is an entirely different issue.
One way of reducing the complexity of determining program flow is
to lay down standards which can be guaranteed. This may be, for
example, that the only GO TOs are to the end of a performed section
with a guaranteed name. It is thus only necessary to confirm
the guarantee. In the above case the label must be spurious and
should be commented out (because it is not the end of a section
and is not a section).
Another way of reducing complexity is to guarantee that all labels
only have one type of use. As PERFORM is the most useful statement
then this should eliminate all other ways that a label could be
used. Thus GO TO is banned, as are drop throughs and thus
THRU.
Thus when examining the example code above one can be guaranteed
that the pricing and tax are always done separately by specific
performs of the paragraphj above and the label shown and this
can be searched for without needing to understand the whole
program.
One of the skills of programming is to reduce the complexity.
There are several ways of doing this, each can work. I prefer
the way that has no sections and the only reference allowed to
a label is a perform (without thru).
Those that have used other mechanisms (such as perform section
and goto exit) usually raise objections based on applying
their styles to this different mechanism and don't see that a
completely different style is required which, once, adopted
actually produces much less complexity.
--
William M. Klein
PARAGRAPH/EXIT SECTION" is added to the Standard (as they are already
supported as extensions in some existing compilers).
--
Bill Klein
wmklein <at> ix dot netcom dot com
Howard Brazee <bra...@NOSPAMwebaccess.net> wrote in message
news:3895DDE2...@NOSPAMwebaccess.net...
Judson McClendon
>
>This is time for my "usual plug" for the next revision where "EXIT
>PARAGRAPH/EXIT SECTION" is added to the Standard (as they are already
>supported as extensions in some existing compilers).
Yes!
Steve Thompson
<Soapbox>
If you are going to program in CICS, then you will need to use
GOTO if you want to make your programs run as quickly as
possible. Perform... perform... perform etc. leads to a lot of
code that has to be backed out of in order to get into and out of
CICS for the next I/O with the USER's terminal (assuming you are
doing Pseudo conversational code). Now, all of this is based on
my not having done any CICS COBOL coding since CICS 1.7. And,
given the EXEC command expansion, as I recall, there is no way
around it doing GOTO. Performing routines would mean having to
write restrictions into how one could use the EXEC commands for
dealing with AID processing (just to name one).
Next, in the area of ABENDs. Orderly cleanup of files is done by
OS/390 (or good ol' MVS) during ABEND processing. The only way
this does NOT get done is if you were somehow able to FREEMAIN
the DEB associated with that file (or somehow over-write that
storage). This is where DECLARATIVES come into play within COBOL
- to deal with unusual or ERROR (ABEND) situations/conditions.
And, since I don't have the latest IBM COBOL-II/COBOL-LE IMS-DB/2
manuals in front of me, I can't tell you for sure what
features/functions exist within the DECLARATIVE sections for
cleaning up a database. BUT, to get to DEB storage, you have to
somehow get into SUPERVISOR state and/or KEY0/5. If you were
able to do this, you have managed to find a security hole, or,
buggy system level software. If you happen to clobber your
DCB/ACB, the system will still get the file closed (in the case
of VSAM, you may have a corrupted Index, but, you'd have done
that one to yourself anyway).
If one is doing XMEM calls for database I/O or other services
(via CALLs to external routines), then one must have an RTM exit
in place to make sure of proper cleanup (even if you exit your
program nicely, the service provider may HAVE to know you went
away in order to free storage up in (E)CSA/(E)SQA reserved for
your Address space, or, "non-releasable" storage in the (E)LSQA.
Given this, one could call an ALC program to issue whatever ABEND
you'd like (including the one's that IBM says are NO NOs -
although some x22's do get special treatment that you may not
want, come to think of it). The point is, the I/O and XMEM
control blocks would get properly cleaned up (the XMEM part, if
and only if the storage was GETMAINed correctly).
Ok, back to the original religious argument. GOTO (within COBOL)
is one of those things which can be used to make the code more
readable. PERFORM is one of those things that can be used to
make code less readable. Again, as I said in a much earlier post
on a.c.c., this is one topic that starts religious wars. And if
you really want a Jihad, let's talk about ALTER (which as I
recall was written out of the language - THANK YOU! -- Even in
ALC I really try to avoid self-altering/modifying code - makes
reading a dump at 0400 much easier, and with 2GB of memory these
days, as opposed to 8KB of memory on the whole machine, why drive
yourself nuts?).
The idea of structured code was to make it readable and
maintainable. To flatly say, NO GO TO may be used is to build a
house and say that you can't use a philips screw-driver (I
specifically avoided the hammer routine :-) ). You can drive a
philips screw with a hammer, or, you can use a small straight
blade screwdriver -- but it sometimes takes alot of strength to
keep from stripping the head of the screw. The similarity in
COBOL is this: A GO TO used for clarity makes convoluted PERFORM
logic easier to read.
NOW, all that said, the availability of "END-xxx" (e.g., END-IF)
has obviated one of the reasons that I would use a GO TO. But,
still, if that GO TO would make the code clearer, I'd use it in a
heartbeat.
<\Soapbox>
Michael Mattias wrote:
>
> I hope you realize my proposed solution is somewhat idealistic. I, too, work
> a lot in the IBM mainframe environment, where the Second Coming would not
> get the attention of the operators unless it's also accompanied by an abend.
>
> However, most mainframe sites I've worked at have a program which does
> nothing but abend, allowing you to set that up as a separate job step,
> trigger it based on condition code, and terminate the current (offending)
> program in an "orderly" fashion.
<snip>
--
Steve Thompson
OSP LLC
330/335-9907 office
330/334-2097 fax
Remove "_" in email address to contact me -- anti-spam measures
in use
Jerry Peters
> Jerry Peters wrote in message
>>
>>to figure out an if statement that spans several pages and nests 8 or more
>>levels deep? Especially when a few goto's would have greatly simplified
>>the code? You can design a well structured program using goto's; you can
>>also design a monstrosity by _not_ using goto's. It has much less to do
>>with goto's than with coding ability and logical thinking.
>>
> While I agree that rules for the sake of rules are silly, and while I agree
> that there is, indeed, a place for the odd (very odd) goto, laying the blame
> for the above sort of code on the head of "structure" is ridiculous.
I _would_ agree, except to many people, structured means no goto's.
> An eight page IF statement is the result of poor programming and is not
> predicated by topdown structure. In fact, I would not consider it topdown at
> all. Topdown refers to the practice of sub-dividing a complex method into
> multiple simple methods. To equate it to simply avoiding the "GO TO"
> statement reveals a profound misunderstanding of the entire methodology.
That's what I tend to do in assembler, which is my main language. I create a
stack of register save areas, then create relatively simple subroutines to do
all of the work. The problem with doing that in COBOL is that there is no
argument passing, which makes using subroutines a pain.
> Readable code is created by trying, real hard, to write code that is easy to
> read, then reading it back and changing it until it is easy to read. With
> practice, a programmer can even do it the first time. If it were possible to
> just make a rule, then have the code magically become readable, then we
> would not need programmers.
Of course, but COBOL was designed under tha assumption that bean counters could
do the coding, if only the language were simple enough (English like, I assume).
> I could write readable code without "PERFORMS"; using *only* "GOTO's" for
> flow control. I have written thousands of lines of code in assembler that
> way, simply because that is the most readable way of writing it. I could
> even write readable code using nothing but the ALTER statement if I had to.
I once maintained a system that used alter-goto's instead of performs, because
using even one perform caused the program to become much larger (this was under
360 DOS). The alter-goto's were only used to emulate performs, not as part of
the logic. It worked and was not hard to maintain.
> Rules like "avoid GOTO" are training wheels for beginner programmers.
> Structure is just that: the way program parts are put together. You can do
> it logically and neatly so that it can be followed, or you can just jam it
> all into a source code module and leave a mess. Applying a label to the
> various methods does not change their basic nature, nor does it affect
> readability.
The problem is that nobody seems to emphasize that the code should be readable,
certainly not in college. One of the first things I learned was to make my code
readable; in 6 months or a year even I'll need all the help I can get to understand
what the code is doing, let alone some other poor maintenance programmer who get
stuck fixing or modifying the code. Yet I'm amazed to see others who don't do that.
Especially in assembler where they code offsets from some base register rather than
using dsects. You may as well be reading a hex dump of the object code.
Jerry
DennisHarley
Jerry Peters <gape...@worldnet.att.net> wrote in message
news:Eapl4.185$Vu3....@bgtnsc04-news.ops.worldnet.att.net...
>
> > An eight page IF statement is the result of poor programming and is not
> > predicated by topdown structure. In fact, I would not consider it
topdown at
> > all. Topdown refers to the practice of sub-dividing a complex method
into
> > multiple simple methods. To equate it to simply avoiding the "GO TO"
> > statement reveals a profound misunderstanding of the entire methodology.
>
> That's what I tend to do in assembler, which is my main language. I create
a
> stack of register save areas, then create relatively simple subroutines to
do
> all of the work. The problem with doing that in COBOL is that there is no
> argument passing, which makes using subroutines a pain.
I think using nested programs may address the argument passing.
The other benefit is localization of work areas.
>
> I once maintained a system that used alter-goto's instead of performs,
because
> using even one perform caused the program to become much larger (this was
under
> 360 DOS). The alter-goto's were only used to emulate performs, not as part
of
> the logic. It worked and was not hard to maintain.
Oh my God!!! You maintained my first COBOL Program.
When I wrote my first COBOL program, I was forced to use ALTERS, when I
tried using PERFORMs the program was too large to run in the 40K partition.
Leif Svalgaard
Richard Plinston <rip...@kcbbs.gen.nz> wrote in message
news:874pe4$56q$1...@aklobs.kc.net.nz...
Michael Mattias
topic of writing efficient code, but if you are GO[ing] TO an ABEND-ROUTINE,
why does efficiency matter?
MCM
Howard Brazee wrote in message <3895AE78...@NOSPAMwebaccess.net>...
Michael Mattias
--
Michael Mattias
Racine WI USA
Judson McClendon wrote in message ...
Steve Thompson
Jerry Peters wrote:
<snip>
> The problem is that nobody seems to emphasize that the code should be readable,
> certainly not in college. One of the first things I learned was to make my code
> readable; in 6 months or a year even I'll need all the help I can get to understand
> what the code is doing, let alone some other poor maintenance programmer who get
> stuck fixing or modifying the code. Yet I'm amazed to see others who don't do that.
> Especially in assembler where they code offsets from some base register rather than
> using dsects. You may as well be reading a hex dump of the object code.
>
> Jerry
I taught a COBOL class many years ago. One of the things I told
the students on their third program was, make sure you write this
program so that it is readable, because you will be graded on
that for program number four.
They all got the point when they had to pass their programs on to
another person in the class who had to modify program #3 written
by someone else, to do what program #4 required. And, they were
not allowed to go and ask questions of the author.
My very obvious point was, yes, you can make your paragraph names
single characters, just like you can your data names. But, when
you have to fix it later, how much sense will it make?
I told them all to remember this little exercise, because they
never knew which program I'd do it with next (just like the
golfer with the two gotcha's -- you don't use the second one, all
you needed was the first).
donald tees
>
>The problem is that nobody seems to emphasize that the code should be
readable,
>certainly not in college. One of the first things I learned was to make my
code
>readable; in 6 months or a year even I'll need all the help I can get to
understand
>what the code is doing, let alone some other poor maintenance programmer
who get
>stuck fixing or modifying the code. Yet I'm amazed to see others who don't
do that.
>Especially in assembler where they code offsets from some base register
rather than
>using dsects. You may as well be reading a hex dump of the object code.
>
changing the previous classes code. I have written thousands of pages of
assembler for at least twenty CPU's, and can write assembler as clear as
COBOL. It is simply a matter of developing the right habits.
I have an entire general ledger system here that still works, written in
1981 for a PC with a 360k single sided floppy. The run module is 4k.
Including the online (syntax sensitive) help, it resides in 45k.
How times change.
donald tees
students work (IE:- the person who's code they had to revise)<G>
Steve Thompson wrote in message <3896340B...@neo.rr.com>...
>
>Jerry Peters wrote:
><snip>
>> The problem is that nobody seems to emphasize that the code should be
readable,
>> certainly not in college. One of the first things I learned was to make
my code
>> readable; in 6 months or a year even I'll need all the help I can get to
understand
>> what the code is doing, let alone some other poor maintenance programmer
who get
>> stuck fixing or modifying the code. Yet I'm amazed to see others who
don't do that.
>> Especially in assembler where they code offsets from some base register
rather than
>> using dsects. You may as well be reading a hex dump of the object code.
>>
Ken Foskey
>
> Ok, back to the original religious argument. GOTO (within COBOL)
> is one of those things which can be used to make the code more
> readable. PERFORM is one of those things that can be used to
> make code less readable. Again, as I said in a much earlier post
> on a.c.c., this is one topic that starts religious wars. And if
> you really want a Jihad, let's talk about ALTER (which as I
> recall was written out of the language - THANK YOU! -- Even in
> ALC I really try to avoid self-altering/modifying code - makes
> reading a dump at 0400 much easier, and with 2GB of memory these
> days, as opposed to 8KB of memory on the whole machine, why drive
> yourself nuts?).
This religious war is what this group is really about :-}
Firstly I don't strongly disagree with what you have said. In some
instances a well placed goto makes life easier. The problem is
deciding when this is the time. I prefer to ban them, if you come up
with a compelling argument I will accept it.
Is your argument compelling? No.
When I was doing CICS (and listening to Frank Zappa). My screens were
validated all fields and the errors marked in read for the operator to
clean up. One pass of the data, no escaping half done.
The issue with multiple performs is just no really an issue. As
pointed out the compiler can optimize them away and as I have said
before efficiency at such a low level is rarely an issue. Unless it is
run about once per second or maybe once per minute do not bother with
micro optimization.
Do the performs create a rats nest of a program. Yes in some
instances they do but, just like your argument for goto, if you do it
well then this is not an issue. For a CICS screen (validation) my
program would look like (using real names not field 1):
validate-screen-1.
perform validate-feild-1
perform validate-field-2
perform validate-field-3
if field-1-ok and field-3-ok
perform cross-validate-field-1-and-field3
end-if
....
This gives a clear flow of the program and the procedures
automatically document the code. No comments required because the
performs tell you what is going on.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
PS: Question. A logical cupacino to the person who answers
correctly.
Why do I not imbed the cross-validate into validate field-3?
Ken Foskey
>
> Give me your solution:
>
> GO TO ABEND-ROUTINE.
> PERFORM ABEND-ROUTINE
> or what?
>
Call abend-routine.
It places the call to the abend function in one module. When you
migrate to windows you can log the error and send a kill program
message to yourself.
Howard Brazee
then they use one optimizing technique for the whole program, otherwise they use
a different optimizing technique for the whole program. It isn't the particular
GO TO which is optimized, it is the program. I don't recall which compiler(s)
have this feature.
Michael Mattias wrote:
> OK, I'll be the sucker who bites. I am as anal-retentive as anyone on the
> topic of writing efficient code, but if you are GO[ing] TO an ABEND-ROUTINE,
> why does efficiency matter?
>
> MCM
>
> Howard Brazee wrote in message <3895AE78...@NOSPAMwebaccess.net>...
> >
> >
> >DennisHarley wrote:
> >>
> >> Give me your solution:
> >>
> >> GO TO ABEND-ROUTINE.
> >> PERFORM ABEND-ROUTINE
> >> or what?
> >
DennisHarley
Ken Foskey <war...@zip.com.au> wrote in message
news:3896D10F...@zip.com.au...
> DennisHarley wrote:
> >
> > Give me your solution:
> >
> > GO TO ABEND-ROUTINE.
> > PERFORM ABEND-ROUTINE
> > or what?
> >
>
>
> It places the call to the abend function in one module.
Nice solution.
However, the systems I work on do not normally have a canned callable
module.
I could devote time to writing and implementing one, but experience tells me
that no one else will use it, and it would delay the delivery of the project
I am currenly working on.
The problem is not just ABENDing, but also displaying additional
information: KEY fields, File Status, record counts etc., which would aid in
the problem resolution process. While a common module with the necessary
flexibility could be written, there would also be the need for a message
formatting routine.
The solution would be:
PERFORM FORMAT-ABEND-MESSAGE
CALL ABEND-ROUTINE USING ABEND-MESSAGE-AREA.
> When you
> migrate to windows you can log the error and send a kill program
> message to yourself.
To be honest there isn't even a slight chance that the systems I work on
will be migrated to Windows.
Some of the places I have worked have multiple mainframes running the same
application to support the volume. GUI front ends using TCP/IP connections
to CICS are being developed, but the bulk of the processing is done in
batch.
Richard Plinston
:>
:> Ok, back to the original religious argument. GOTO (within COBOL)
:> is one of those things which can be used to make the code more
:> readable. PERFORM is one of those things that can be used to
:> make code less readable. Aga
Whether GO TO or PERFORM is 'more readable' is purely a function
of the reader. If the programmer is looking at and writing GO TOs
in programs then he will see this as the 'more readable' form and
PERFORMs will confuse him. and vice versa.
--
Jerry Peters
That's about it. The bank had a "large" 256K mdoel 40 (or maybe that was the
360-50, it's been a long time). The machine I'm writing this on has 64M,
current 967x's ship with a minimum of 1G, I think.
Jerry
Michael Mattias
MCM
Howard Brazee wrote in message <3896EF71...@NOSPAMwebaccess.net>...
>I have heard that some compilers look to see if there is a GO TO. If there
is,
>then they use one optimizing technique for the whole program, otherwise
they use
>a different optimizing technique for the whole program. It isn't the
particular
>GO TO which is optimized, it is the program.
>
>Michael Mattias wrote:
>
>> OK, I'll be the sucker who bites. I am as anal-retentive as anyone on the
>> topic of writing efficient code, but if you are GO[ing] TO an
ABEND-ROUTINE,
>> why does efficiency matter?
>>
>> MCM
>>
>> Howard Brazee wrote in message <3895AE78...@NOSPAMwebaccess.net>...
>> >
>> >
>> >DennisHarley wrote:
>> >>
>> >> Give me your solution:
>> >>
>> >> GO TO ABEND-ROUTINE.
>> >> PERFORM ABEND-ROUTINE
>> >> or what?
>> >
Robert M. Pritchett - RMP Consulting Partners LLC
was detected, THEN call your abend routine.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
DennisHarley wrote in message <#$FsM4#a$GA.315@cpmsnbbsa03>...
>I work in the OS/390 environment:
>
>The purpose of an ABEND-ROUTINE is to get the attention of Computer
>Operations.
Robert M. Pritchett - RMP Consulting Partners LLC
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Ken Foskey wrote in message <389431B2...@zip.com.au>...
>Robert Pritchett wrote:
>> CoBOL (COmmon Business Oriented Language) programs have been around
>> for years, so many of them are of very poor quality <snip>.
>
>To which Steve Thompson wrote:
===> By the way, I'm not sure he's the one who wrote that.
>> This is simply not true. What do you define as quality?
>> Readability? No, quality is software that works and I've seen no
>> discernible difference in quality between our old stuff and our new
>> stuff.
>
>And Robert responded :
>> ===> I'm not saying that all old programs are of poor quality, just
>> that there's a high correlation. There are lots of poorly written
>> programs out there. And a quality program is not only correct in
>> execution but also easy to read and understand so that it's easy to
>> maintain.
>
>If a program works and needs no changes then there really is no
>quality problem. Even if the code is truly awful, the design was good
>enough to survive the test of time.
===> If the code is awful it will be harder to maintain, which you agree
below is important. That in itself is an important part of program quality.
If 2 programs both work right and meet other criteria then whichever one is
easier to maintain is probably higher quality.
>
>The issue arises when you are asked to make a change to a currently
>running system. You then need to carefully graft your extra features
>into an existing framework. If the original code is good then it is
>relatively trivial to graft additional features and reuse some
>sections of the code. If it is poor then it requires great skill to
>rework the existing process into a reliable changed program.
>
>I have so many times seen modifications that work but are not the best
>change that could be applied because the programmer did a minimal
>change even if this approach was not the clearest. This is entropy at
>it best after about ten of these modifications you can't make a change
>without breaking something and you have to totally rework the code
>from scratch again. Once again the choice to rework the program is
>rarely done and programmers complain bitterly and suffer long testing
>cycles with the 'monster program from hell'
>
>Refactoring: The process of changing the program code without changing
>the functionality.
>
>Change: Refactor the program first to make your change easy, then
>implement the new functionality.
===> I've had to do that a number of times and always recommend it whenever
appropriate. Too many people, especially clients, are reluctant to consider
that option.
Robert M. Pritchett - RMP Consulting Partners LLC
these questions. See further below.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
DennisHarley wrote in message ...
>Give me your solution:
>
>GO TO ABEND-ROUTINE.
>PERFORM ABEND-ROUTINE
>or what?
===> Neither. Set a flag if you have to and test it wherever appropriate in
the proper constructs and the proper levels. Then everything almost takes
care of itself (since you have to include error handling code either way),
and if you need to change how one error is handled without making the same
change to related errors (or with making the same change to related errors
but not others), it's much easier this way.
>
>Robert M. Pritchett - RMP Consulting Partners LLC <EL.Bu...@rmpcp.com>
>wrote in message
>news:2dGk4.4560$Sa2.1...@newsread2.prod.itd.earthlink.net...
>> If the code is "easier to understand" with a GoTo, that's because it's
not
>> as cleanly structured as it should be, and/or it's those programmers who
>> never quite fully understood structured programming who would find it
>> "easier to understand".
>
>Understanding Structured Programming is not the issue.
>The problem is that you want support of the rules you feel are valid.
>Anyone who disagrees with you doesn't understand.
>
>You disapprove of limited use of explicit GO TO statements.
>Isn't CONTINUE an implicit GO TO?
>Don't we interpret IF, THEN, ELSE constructions with an implied GO TO?
===> This really proves you don't get it, structured programming is about
the source level, not the object level.
>
>>
>>
Robert M. Pritchett - RMP Consulting Partners LLC
higher level cross dependency to the appropriate higher code level.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Ken Foskey wrote in message <3896D22B...@zip.com.au>...
> validate-screen-1.
> perform validate-feild-1
> perform validate-field-2
> perform validate-field-3
> if field-1-ok and field-3-ok
> perform cross-validate-field-1-and-field3
> end-if
> ....
>
>Why do I not imbed the cross-validate into validate field-3?
>
Robert M. Pritchett - RMP Consulting Partners LLC
agreement, see below:
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Steve Thompson wrote in message <38961CF0...@neo.rr.com>...
>I could stay out of this no longer.
>
><Soapbox>
>If you are going to program in CICS, then you will need to use
>GOTO if you want to make your programs run as quickly as
>possible. Perform... perform... perform etc. leads to a lot of
>code that has to be backed out of in order to get into and out of
>CICS for the next I/O with the USER's terminal (assuming you are
>doing Pseudo conversational code). Now, all of this is based on
>my not having done any CICS COBOL coding since CICS 1.7.
===> And for some time now CICS has had parallel improvements to support
Cobol II etc. so that you no longer have to use Handle (which forces
GoTo's) for everything, just test the EIB return code, and the preprocessor
even provides nice symbolic constants for the possible codes. In fact C for
the IBM mainframe REQUIRES this technique, I've read somewhere, maybe it
doesn't even have GoTo's. I haven't tried mainframe C but it'd be
interesting to check it out.
>Ok, back to the original religious argument. GOTO (within COBOL)
>is one of those things which can be used to make the code more
>readable. PERFORM is one of those things that can be used to
>make code less readable...
===> Yes, if it's abused.
A GO TO used for clarity makes convoluted PERFORM
>logic easier to read.
===> Making your Perform logic less convoluted and avoiding GoTo's entirely
is even much easier to read.
>
>NOW, all that said, the availability of "END-xxx" (e.g., END-IF)
>has obviated one of the reasons that I would use a GO TO. But,
>still, if that GO TO would make the code clearer, I'd use it in a
>heartbeat.
>
===> I've yet to see an example where this would be the case, given the
opportunity to write a clean structured program from scratch. In
maintenance situations where you aren't allowed time to clean up anything
more than the minimum amount needed to facilitate making your change, this
could conceivable be the case, however - but I'd still view it as a
temporary, transitional state (which, unfortunately, most production
programs are probably still in).
Robert M. Pritchett - RMP Consulting Partners LLC
practices and this will influence what they understand easily, but in
structured programming there's also an inherent improvement in readability,
maintainability, and even developing it correctly in the first place, which
is the point. I think a programmer who fully understands both structured
(with and without GoTo's) and non-structured styles would find well
structured, GoTo-less programs easier to write and maintain.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Richard Plinston wrote in message <877e0u$u50$2...@aklobs.kc.net.nz>...
Robert M. Pritchett - RMP Consulting Partners LLC
Sure, Cobol only provides this kind of construct for such specific cases
e.g. at end and not at end clauses, invalid key and not invalid key, etc.
but you can still use the existing structures to implement the technique.
This is far preferable to using a GoTo which has so much potential to be
changed (by poor maintenance) to go anywhere and then you're out of
control. Even if you have to repeat a test by having an If inside which
duplicates some of the tests in the outer Perform, this is still preferable
to a GoTo.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Judson McClendon wrote in message ...
But how many structured languages can you
>name that do not have statements to exit from the middle of a code
>block? Error conditions can sometimes demand it. There is currently
>no command in COBOL to do this
Robert M. Pritchett - RMP Consulting Partners LLC
add multiple paragraphs in a section and then you have fallthrus and
inviting targets for goto's. Where sections are useful is as a transitional
tool for cleanups, in getting rid of perform thru's.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Bjorn Alvik wrote in message <3S9l4.18045$in5.3...@news1.online.no>...
>Thank you for this, Judson.
>I also think that we should tell them that SECTIONing of programs is not
at
>all bad.
Robert M. Pritchett - RMP Consulting Partners LLC
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
David Olson wrote in message ...
>I agree that there is *nothing* inherently wrong with a forward GO TO. In
>fact, using one can make code that it a whole lot more readable,
>understandable, and maintainable. It can make a lot of sense to always
>PERFORM a subroutine from the mainline, and then exit from the subroutine
>with a GO TO the exit if it turns out you really don't want to be there!
===> That's what IF/End-If is for.
>
>As an example, I once found a piece of code in a program we inherited that
>used a stupidly long and complex nested IF statement just to avoid a GO
TO.
===> In that case, simply adding another Perform level would've probably
made it much clearer.
Robert M. Pritchett - RMP Consulting Partners LLC
waiting to happen. Someone will eventually take advantage of the convenient
label or standard to add more goto's and/or labels.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Howard Brazee wrote in message <3895BF99...@NOSPAMwebaccess.net>...
>When I write a new program, the only exits needed from the middle of a
>paragraph are those going to an ABORT routine. It is not hard to design
>a program so that it doesn't use switches and it doesn't need GO TO
>EXIT. Once this technique is learned, it becomes first nature.
>
>There are lots of ways to structure a program. Some structures have GO
>TO XXXX-EXIT statements in them. Others do not need these.
>
Robert M. Pritchett - RMP Consulting Partners LLC
Perform would probably be cleaner.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
William M. Klein wrote in message
<874rcq$eak$1...@nntp5.atl.mindspring.net>...
Robert M. Pritchett - RMP Consulting Partners LLC
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Jerry Peters wrote in message <872mka$3mm$1...@bgtnsc02.worldnet.att.net>...
>I've had to fix some idiots goto'less code in Cobol. Have you ever tried
>to figure out an if statement that spans several pages and nests 8 or more
>levels deep?
===> Obviously that's where Performs should've been added to break up the
levels. I don't like to see any routine exceed a page. I could make an
exception for purely straight line code like a long series of moves or
similar unconditional things processing lots of fields. Even then, if
there's any logical way to group these, then I'd prefer to insert another
perform level.
Especially when a few goto's would have greatly simplified
>the code?
===> Not necessarily.
You can design a well structured program using goto's; you can
>also design a monstrosity by _not_ using goto's. It has much less to do
>with goto's than with coding ability and logical thinking.
===> On that I agree. But I'd also suggest that good coding ability and
logical thinking tend to correlate with at least structured programming and
probably also goto-less programming.
Robert M. Pritchett - RMP Consulting Partners LLC
uniquely) having the multi-use label problem (perform/goto/etc.) much
better than I did. Thanks.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Richard Plinston wrote in message <874pe4$56q$1...@aklobs.kc.net.nz>...
Robert M. Pritchett - RMP Consulting Partners LLC
like Pascal etc. so you have effectively a "Perform Using". And of course
you can still call an externally compiled subroutine as you always could.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Jerry Peters wrote in message ...
Ken Foskey
>
> >If a program works and needs no changes then there really is no
> >quality problem. Even if the code is truly awful, the design was
> >good enough to survive the test of time.
>
> ===> If the code is awful it will be harder to maintain, which you
> agree below is important. That in itself is an important part of
> program quality.
This is a derivation of if a branch falls in the forest and no one
notices, did the branch fall at all.
When was the last time you looked at a system that did not require any
changes?
I strongly agree with what you are saying though apart from that.
DennisHarley
> If you understood structured programming well enough you wouldn't have
> these questions. See further below.
>
>
> Robert M. Pritchett, President - RMP Consulting Partners LLC
> http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
> "Quality means doing it right the first time!"
> Contractors: tired of hearing "W-2 only"? Join us and let us help you get
> that same contract on a 1099 as a self-employed independent contractor!
>
>
> >Give me your solution:
> >
> >GO TO ABEND-ROUTINE.
> >PERFORM ABEND-ROUTINE
> >or what?
>
> ===> Neither. Set a flag if you have to and test it wherever appropriate
in
> the proper constructs and the proper levels. Then everything almost takes
> care of itself (since you have to include error handling code either way),
> and if you need to change how one error is handled without making the same
> change to related errors (or with making the same change to related errors
> but not others), it's much easier this way.
I've seen this done, and it creates a mess.
Instead of:
PERFORM ROUTINE-A
PERFORM ROUTINE-B
PERFORM ROUTINE-C
you get:
IF NOT FATAL-ERROR
PERFORM ROUTINE-A
IF NOT FATAL-ERROR
PERFORM ROUTINE-B
IF NOT FATAL-ERROR
PERFORM ROUTINE-C
END-IF
END-IF
END-IF.
Every major routine winds up testing the FATAL-ERROR condition. And
unfortunately, if the FATAL-ERROR condition is not tested when it should be,
you may trigger a system Abend which masks the true nature of the problem.
The bottom line is that when you dectect a fatal error, Abend immediately.
> >
> >Robert M. Pritchett - RMP Consulting Partners LLC <EL.Bu...@rmpcp.com>
> >wrote in message
> >news:2dGk4.4560$Sa2.1...@newsread2.prod.itd.earthlink.net...
> >> If the code is "easier to understand" with a GoTo, that's because it's
> not
> >> as cleanly structured as it should be, and/or it's those programmers
who
> >> never quite fully understood structured programming who would find it
> >> "easier to understand".
> >
> >Understanding Structured Programming is not the issue.
> >The problem is that you want support of the rules you feel are valid.
> >Anyone who disagrees with you doesn't understand.
> >
> >You disapprove of limited use of explicit GO TO statements.
> >Isn't CONTINUE an implicit GO TO?
> >Don't we interpret IF, THEN, ELSE constructions with an implied GO TO?
>
> ===> This really proves you don't get it, structured programming is about
> the source level, not the object level.
> >
When we read programs we process the code in our head. We interpret what we
read. We follow the flow of the program.
When I see a CONTINUE, I have to establish the scope it is contained in, and
find the corresponding Scope Terminator. Processing continues after the
scope terminator.
I interpret the CONTINUE as a "GO TO END-EVALUATE", "GO TO END-SEARCH", "GO
TO END-IF", etc.
Even though there is no explicit GO TO involved, it is interpreted as a GO
TO.
The generic nature of the CONTINUE sometimes leads to confusion. It may have
been beneficial to have an unambiguous form which specified the terminator.
When in-line comments are supported, don't be surprised to see:
CONTINUE *> GO TO END-EVALUATE
or CONTINUE *> END-EVALUATE
BTW: I use the GO TO for ABEND routines only, everthing else is GO TO-less.
I break a program down into small provable paragraphs, and let the OPTIMIZER
do its job.
My latest crusade is to get more people to use nested programs.
> >>
> >>
>
>
William M. Klein
> Right, and the go to exit technique is a trap, a maintenance nightmare
> waiting to happen. Someone will eventually take advantage of the convenient
> label or standard to add more goto's and/or labels.
>
Which is why the new (next revision) "EXIT PARAGRAPH/SECTION" syntax is so
much bettiner (IMHO). There is no "label" involved and, thus, no way for the
next programmer to use an exit paragraph name in any statement.
NOTE WELL:
If your current "vendor of choice" doesn't already support this syntax
(from the draft revision), I really DO suggest that you go thru their
"enhancement request" procedures to get this added BEFORE they provide a full
20xx conforming standard.
--
Bill Klein
wmklein <at> ix dot netcom dot com
Richard Plinston
: When I see a CONTINUE, I have to establish the scope it is contained in, and
: find the corresponding Scope Terminator. Processing continues after the
: scope terminator.
: I interpret the CONTINUE as a "GO TO END-EVALUATE", "GO TO END-SEARCH", "GO
: TO END-IF", etc.
: Even though there is no explicit GO TO involved, it is interpreted as a GO
: TO.
Each and every WHEN in an EVALUATE execues the following code and
then _Processing_continues_after_the_scope_terminator_. The
CONTINUE is not a special case (except there is nothing to
actually do). The CONTINUE is _NOT_ a 'GO TO END-EVALUATE' any
more than there is an implicit goto at the end of each and every
block under a WHEN.
If you 'interpret' it this way then, it seems, you are still
trying to handle the code as a mental 'flowchart' and don't
'get it' yet.
: The generic nature of the CONTINUE sometimes leads to confusion. It may have
: been beneficial to have an unambiguous form which specified the terminator.
If you are confused by CONTINUE then you could always try abusing
the NEXT SENTENCE with a movable full stop.
: When in-line comments are supported, don't be surprised to see:
: CONTINUE *> GO TO END-EVALUATE
: or CONTINUE *> END-EVALUATE
I am seldom surprised by comments anymore, they are often either
useless (as above) of simply wrong.
--
Robert M. Pritchett - RMP Consulting Partners LLC
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
DennisHarley wrote in message ...
>I've seen this done, and it creates a mess.
>Instead of:
> PERFORM ROUTINE-A
> PERFORM ROUTINE-B
> PERFORM ROUTINE-C
>you get:
>IF NOT FATAL-ERROR
> PERFORM ROUTINE-A
> IF NOT FATAL-ERROR
> PERFORM ROUTINE-B
> IF NOT FATAL-ERROR
> PERFORM ROUTINE-C
> END-IF
> END-IF
>END-IF.
>
>Every major routine winds up testing the FATAL-ERROR condition. And
>unfortunately, if the FATAL-ERROR condition is not tested when it should
be,
>you may trigger a system Abend which masks the true nature of the problem.
>
>The bottom line is that when you dectect a fatal error, Abend immediately.
===> Your example above is only one possibility, often other ways are more
appropriate depending on the situation and the exact error. And you're
forgetting the possible levels of abstraction included in what the
program's trying to do that make appropriate opportunities for
corresponding Perform levels. e.g.
Proc. Div.
Perform set-up-and-initial-error-check
If OK-so-far
Perform main-processing
End-If
.
Main-Processing.
Perform this-part
If OK-so-far
Perform that-part
End-if
If OK-so-far
Perform next-part
End-If
.
...
The above also shows a possible way to avoid adding If nesting levels. The
extra If tests executed should have negligable effect on performance. The
main point is that having the extra levels of Performs can more clearly
show the structure without requiring deep nesting of If's, and can also
more clearly distinguish between parts of the program concerned with one
overall issue (and relevant possible errors) and the subsequent parts which
are deeper into the processing and are concerned with entirely different
issues and errors.
>When I see a CONTINUE, I have to establish the scope it is contained in,
and
>find the corresponding Scope Terminator. Processing continues after the
>scope terminator.
===> You're confusing Continue with Next Sentence. Continue is a NOP and is
almost never required.
>BTW: I use the GO TO for ABEND routines only, everthing else is GO
TO-less.
===> That's good, and is certainly a workable compromise especially in
maintenance situations.
>I break a program down into small provable paragraphs, and let the
OPTIMIZER
>do its job.
===> Right.
>My latest crusade is to get more people to use nested programs.
===> Right, that's also good.
Judson McClendon
>Right, and the go to exit technique is a trap, a maintenance nightmare
>waiting to happen. Someone will eventually take advantage of the convenient
>label or standard to add more goto's and/or labels.
It is not a 'trap' if you impose two policies.
1. Always use a code scanner that flags PERFORM THRU wrong exit,
GO TO outside of the paragraph and unmatched paragraph/exit.
2. Make it a firing offense if anybody uses a GO TO outside a
paragraph on purpose, or places a program into production
without running the code scanner on it first.
Believe me, that works. Hopefully, EXIT PARAGRAPH will be in the
next standard, and we can eliminate this issue altogether.
--
Judson McClendon ju...@bellsouth.net
Sun Valley Systems http://www.sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Judson McClendon
>Hey, Judson
>Agree with you.
>By the way, do you have that kind of a scanner.
>Or do you know where to get it?
Yes, I wrote my own a long time ago. However, my particular scanner
is so tailored to my own coding style (it checks other things too,
such as missing and extra periods), that it would be of little value
to anyone with different coding standards. They're actually not very
difficult to write. :-)
Bjorn Alvik
Agree with you.
By the way, do you have that kind of a scanner.
Or do you know where to get it?
Judson McClendon <ju...@bellsouth.net> skrev i
meldingsnyheter:5sfm4.3484$pk.3...@news3.mia...
> Robert M. Pritchett - RMP Consulting Partners LLC wrote:
> >Right, and the go to exit technique is a trap, a maintenance nightmare
> >waiting to happen. Someone will eventually take advantage of the
convenient
> >label or standard to add more goto's and/or labels.
>
> It is not a 'trap' if you impose two policies.
>
> 1. Always use a code scanner that flags PERFORM THRU wrong exit,
> GO TO outside of the paragraph and unmatched paragraph/exit.
>
> 2. Make it a firing offense if anybody uses a GO TO outside a
> paragraph on purpose, or places a program into production
> without running the code scanner on it first.
>
> Believe me, that works. Hopefully, EXIT PARAGRAPH will be in the
> next standard, and we can eliminate this issue altogether.
Judson McClendon
>Sure, Cobol only provides this kind of construct for such specific cases
>e.g. at end and not at end clauses, invalid key and not invalid key, etc.
>but you can still use the existing structures to implement the technique.
>This is far preferable to using a GoTo which has so much potential to be
>changed (by poor maintenance) to go anywhere and then you're out of
>control. Even if you have to repeat a test by having an If inside which
>duplicates some of the tests in the outer Perform, this is still preferable
>to a GoTo.
You snipped the example in my message that doesn't match what you say.
Consider a program that contains many paragraphs like this, with
perhaps 30 to 60 sets of field validation tests, or other similar
operations, on a series of fields. There is no logical point to
split the tests into groups. The fields are each autonomous and
unique, they are of different sizes and types, so you can't subscript
them. Please show us a way to code this without the GO TO that does
not require substantially more coding and is much less readable.
This example is not contrived, I can show you hundreds of programs at
my clients that must do these kind of tests. Bear in mind that we had
a long thread on this a while back, and though there were some very
clever suggestions, not one of them was clearer or simpler than the
GO TO exit. The only logical difference here between using GO TO EXIT
and EXIT PARAGRAPH is the GO TO EXIT presents the opportunity to
PERFORM THRU the wrong exit, and you can do a GO TO outside the
paragraph. You address this with a simple code checker that flags
those errors. With the code checker, the GO TO EXIT is just as safe as
the EXIT PARAGRAPH, and simpler and clearer than trying to do it with
hugely embedded IF/ELSE, or setting flags which are tested every time,
etc. When coded, those look like abominations, and are hardly clearer
than GO TO EXIT. :-)
PARAGRAPH.
<validate field>
IF <error>
GO TO PARAGRAPH-EXIT.
<validate field>
IF <error>
GO TO PARAGRAPH-EXIT.
<validate field>
IF <error>
GO TO PARAGRAPH-EXIT.
<validate field>
IF <error>
GO TO PARAGRAPH-EXIT.
<validate field>
IF <error>
GO TO PARAGRAPH-EXIT.
<validate field>
IF <error>
GO TO PARAGRAPH-EXIT.
...
PARAGRAPH-EXIT.
EXIT.
Bjorn Alvik
I supposed it was that way.
The reason I asked, is my searching for tools to scan Wang Cobol for certain
syntax, in order to be able to do some kind of refactoring, conversion etc.
I do think that I need to have a big COBOL parser to perform my tasks, at
least not by the current moment. And I really cannot afford much time on
writing my own.
Got an idea? After all, the topic should be of general interest, I think.meldingsnyheter:XRfm4.3530$pk.3...@news3.mia...
> Bjorn Alvik wrote:
> >Hey, Judson
> >Agree with you.
> >By the way, do you have that kind of a scanner.
> >Or do you know where to get it?
>
> is so tailored to my own coding style (it checks other things too,
> such as missing and extra periods), that it would be of little value
> to anyone with different coding standards. They're actually not very
> difficult to write. :-)
Oscar T. Grouch
it to the PC for analysis.
If all you want to do is find certain text strings then there are a zillion
utilities for looking for doing text searches including the 'FIND' utility
that ships with DOS, Windows, OS/2, etc. I tend to use GNU utilities since
they support regular expression. (http://www.gnu.org)
-- Karl Wagner
It's been too long since I've been on a Wang but there ought to be a USERAID
utility to do this.
"Bjorn Alvik" <bjorn...@asp.no> wrote in message
news:R5gm4.21174$in5.3...@news1.online.no...
shi...@my-deja.com
"go to"'s and no switches (if you don't count ws-error-sw, er, I mean
msg):
PARAGRAPH.
move spaces to ws-error-msg
<validate field 1>
IF <error>
if ws-error-msg not = spaces
move 'error message 1' to ws-error-msg
end-if
end-if
<validate field 2>
IF <error>
if ws-error-msg not = spaces
move 'error message 2' to ws-error-msg
end-if
end-if
<validate field 3>
IF <error>
if ws-error-msg not = spaces
move 'error message 3' to ws-error-msg
end-if
end-if
<validate field 4>
IF <error>
if ws-error-msg not = spaces
move 'error message 4' to ws-error-msg
end-if
end-if
<validate field 5>
IF <error>
if ws-error-msg not = spaces
move 'error message 5' to ws-error-msg
end-if
end-if
<validate field 6>
IF <error>
if ws-error-msg not = spaces
move 'error message 6' to ws-error-msg
end-if
end-if.
Personally, I like your way better. And I used to argure with a guy
about "go to"s. One of my arguments was that COBOL hasn't got a the
necessary implied goto's that C++ has, such as "continue" or "break" and
as such was a crippled language that occaisionally required using
goto's. He told me that he wrote C++ and he didn't use *those*
constructs. Maybe some adhere to the rules tightly so they won't fail
and others understand the rules and can
break them when needed. UMMV.
In article <FOfm4.3524$pk.3...@news3.mia>,
> --
> Judson McClendon ju...@bellsouth.net
> Sun Valley Systems http://www.sunvaley.com
> "For God so loved the world that He gave His only begotten Son, that
> whoever believes in Him should not perish but have everlasting life."
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Rick Price
news:Dngm4.336$45....@news2.rdc1.on.home.com...
> Micro Focus Revolve is supposed to handle Wang COBOL, assuming you can get
> it to the PC for analysis.
>
> If all you want to do is find certain text strings then there are a
zillion
> utilities for looking for doing text searches including the 'FIND' utility
> that ships with DOS, Windows, OS/2, etc. I tend to use GNU utilities since
> they support regular expression. (http://www.gnu.org)
>
> -- Karl Wagner
>
>
> It's been too long since I've been on a Wang but there ought to be a
USERAID
> utility to do this.
We used SCANSRC for searching for strings in source on WANG. You could have
multiple strings and multiple source libraries. The only problems are that
this is case dependent as I remember and when one of the strings was found
in a source, then that source was ended and the next source was searched.
This was a batch process that produce a report at the end.
Alternatively there was FINDTEXT which would look for a single string in a
source library. This could be case independent.
Rick
Howard Brazee
done, respond accordingly, or you will want to quit when you find your first
error.
Also, typically a screen will have a pattern:
PERFORM CHECK-HEADER-FIELDS
IF MY-STATUS-OK
PERFORM CHECK-ACCOUNTS
END-IF
IF MY-STATUS-OK
PERFORM CHECK-AMOUNTS
END-IF
This will allow breaking up your testing into manageable hunks.
shi...@my-deja.com wrote:
> > --
> > Judson McClendon ju...@bellsouth.net
> > Sun Valley Systems http://www.sunvaley.com
> > "For God so loved the world that He gave His only begotten Son, that
> > whoever believes in Him should not perish but have everlasting life."
> >
> >
>
Terry Heinze
<shi...@my-deja.com> wrote in message news:87csi0$uol$1...@nnrp1.deja.com...
Your code, as written, uses ws-error-msg as a switch and if more than one
field is in error, your code will only put out the error message for the
last one detected. The error message for each field found in error will
overlay the previous error message. I probably would have coded:
VALIDATE-FIELDS.
VALIDATE FIELD-1
IF IN-ERR
SET FIELD-1-IN-ERR TO TRUE
END-IF
VALIDATE FIELD-2
IF IN-ERR
SET FIELD-2-IN-ERR TO TRUE
END-IF
VALIDATE FIELD-3
IF IN-ERR
SET FIELD-3-IN-ERR TO TRUE
END-IF
VALIDATE FIELD-4
IF IN-ERR
SET FIELD-4-IN-ERR TO TRUE
END-IF
VALIDATE FIELD-5
IF IN-ERR
SET FIELD-5-IN-ERR TO TRUE
END-IF
VALIDATE FIELD-6
IF IN-ERR
SET FIELD-6-IN-ERR TO TRUE
END-IF
.
DISPLAY-ERRS.
IF FIELD-1-IN-ERR
DISPLAY ERR-1
END-IF
IF FIELD-2-IN-ERR
DISPLAY ERR-2
END-IF
IF FIELD-3-IN-ERR
DISPLAY ERR-3
END-IF
IF FIELD-4-IN-ERR
DISPLAY ERR-4
END-IF
IF FIELD-5-IN-ERR
DISPLAY ERR-5
END-IF
IF FIELD-6-IN-ERR
DISPLAY ERR-6
END-IF
.
Of course for more than a half dozen fields, I would've used subscripts or
indexes to set the error switches and to display the corresponding error
messages.
Leif Svalgaard
problem I have is that your validation plods along
one field at a time. The way I do things is to check
as many fields as possible in one go, to minimize
1) the transaction load on the machine and the communications line
2) the end-user aggravation ("why can't it check all fields at a time")
If you try to do this, the GO TO exit is not the thing to do.
You should normally check the fields from the bottom
up, highlight the ones that are in error, and put the cursor
on the topmost error, with an error message pertaining
to that only. Your coding style does not really support
this, so your users become victims of your convenience.
An argument against my point of view is that users
normally only make one error at a time, so it doesn't
matter.
Judson McClendon <ju...@bellsouth.net> wrote in message
news:FOfm4.3524$pk.3...@news3.mia...
> Robert M. Pritchett - RMP Consulting Partners LLC wrote:
> >An exit in the middle of a loop is like the classic read until EOF
problem.
> You snipped the example in my message that doesn't match what you say.
> Consider a program that contains many paragraphs like this, with
> perhaps 30 to 60 sets of field validation tests,
>
Robert M. Pritchett - RMP Consulting Partners LLC
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
William M. Klein wrote in message <87aili$br0
>Robert, I think that it is you that is confused. "NEXT SENTENCE" always
>jumps to (dare I say "goes to") the next period. Continue (which you are
>correct is "basically" a no-op) does transfer control to the next
"logical"
>statement - which may well be the statement following the next
>scope-terminator. However, you are correct that it isn't required very
>often.
===> Perhaps I rushed to answer and wasn't clear, but Continue does NOT
transfer control anywhere. The statements AFTER the continue, or the
structure the continue is in, does the transfer.
>
>Just to show an example of where "continue" would go to just after the
next
>scope terminator, consider
>
>If A = B
> continue
>Else
> Display "in else"
>end-if
>Display "continue goes here"
> .
>
>and for an example of where it does NOT go to after the next scope
terminator
>(and please do NOT ask me why anyone would ever code this)
>
>If A = B
> continue
> Display "this is after the continue"
>else
> Display "in else"
>end-if
>Display "This will be the 2nd, not the 1st display"
> .
===> As I said above, the 2 are identical, the Continue itself does NOT
transfer control, the ELSE does that.
>
>P.S. The first example (which is a reasonable - or at least
>semi-reasonable - use of "continue") is "useful" when
>
> A) you "like" coding postive rather than negative conditional statements
> B) the "true" situation is significantly more "common" than the "else"
and
>your performance is enhanced by coding the most "commonly executed" code
>first.
===> B is usually a trivial consideration not worth cluttering up the
control flow by adhering to counterproductive standards like A - it's MUCH
clearer to say:
If not error-condition
Perform next-part
End-if
rather than to pander to the anti-Not group by adding additional complexity
via:
If error-condition
Continue because I really didn't want to do anything here anyway
Else
Perform next-part
End-If
People that are so afraid of a straightforward negative that they'll add
unnecessary paths to the logic and make the logic more confusing are not
thinking straight, in my opinion, and this kind of confused thing
correlates highly with those who do not fully understand structured
programming and also with the PHB clueless client type of mentality.
In another example I actually had to go to bat over, a routine that accepts
a variable number of parameters had to have logic like
If parm1 not = 'END'
perform process-parm1
If parm2 not = 'END'
perform process-parm2
etc....
End-If
End-If
Since it was parameter passing, no looping or table was possible; the logic
had to work this way. The client's own programmer that was involved with
standards (and this is when Mobil was still using old Cobol, I was
pioneering the use of Cobol II there with this project) wanted to come up
with something using else's but the client manager (one of very few
excellent non-PHB clients I've had) realized that the above was much
clearer and stated exactly what was needed to be done.
Robert M. Pritchett - RMP Consulting Partners LLC
Robert M. Pritchett - RMP Consulting Partners LLC
can be useful to check for traps, but no NEW code should be written like
this, including code added during maintenance. With proper use of
structured programming, no more goto's should need to be added.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Judson McClendon wrote in message <5sfm4.3484$pk.3...@news3.mia>...
>Robert M. Pritchett - RMP Consulting Partners LLC wrote:
>>Right, and the go to exit technique is a trap, a maintenance nightmare
>>waiting to happen. Someone will eventually take advantage of the
convenient
>>label or standard to add more goto's and/or labels.
>
>It is not a 'trap' if you impose two policies.
>
> 1. Always use a code scanner that flags PERFORM THRU wrong exit,
> GO TO outside of the paragraph and unmatched paragraph/exit.
>
> 2. Make it a firing offense if anybody uses a GO TO outside a
> paragraph on purpose, or places a program into production
> without running the code scanner on it first.
>
>Believe me, that works. Hopefully, EXIT PARAGRAPH will be in the
>next standard, and we can eliminate this issue altogether.
Robert M. Pritchett - RMP Consulting Partners LLC
flag that that field was bad (as well as setting a flag that at least one
field was bad), completely avoiding the need for your the If's inside your
entire first half of the code. But yes, I like your approach better.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Terry Heinze wrote in message
<87d0h6$62om$1...@newssvr03-int.news.prodigy.com>...
>VALIDATE-FIELDS.
> VALIDATE FIELD-1
> IF IN-ERR
> SET FIELD-1-IN-ERR TO TRUE
> END-IF
...
> VALIDATE FIELD-6
> IF IN-ERR
> SET FIELD-6-IN-ERR TO TRUE
> END-IF
> .
>DISPLAY-ERRS.
> IF FIELD-1-IN-ERR
> DISPLAY ERR-1
> END-IF
...
Robert M. Pritchett - RMP Consulting Partners LLC
like to have room for a few error lines at the bottom of the screen, then I
can do something similar (pseudocode):
(#errs and err msg table set as global in cobol program)
#errs = 0
if fld1 bad
call append-err-msg using 1
endif
if fld2 bad
call append-err-msg using 2
endif
...
if #errs > 0
perform show-err-msgs
else
perform this-screen-ok-now-process-data
endif
...
(nested program) append-err-msg using msg#
#errs = #errs + 1
if #errs <= max # errs there are lines for
msg-lines (#errs) = error-msg-text (msg#)
endif
goback
You can see the general idea - there are lots of ways to do this. The final
perform of the this screen ok routine moves on to the next phase of the
processing without getting into deeper nested if's. Or it could be where
the cross checks and more complicated validations are done.
--
Robert M. Pritchett, President - RMP Consulting Partners LLC
http://rmpcp.com - r...@rmpcp.com - Dallas, TX - Member ICCA
"Quality means doing it right the first time!"
Contractors: tired of hearing "W-2 only"? Join us and let us help you get
that same contract on a 1099 as a self-employed independent contractor!
Leif Svalgaard wrote in message <389a2...@news3.prserv.net>...
shi...@my-deja.com
alot of setting of switches which I see as a problem. Years ago, for
batch updates, I coded the error message in a table with a switch and
would print the transaction and all errors listed afterwards. But online
(CICS) where you have one error message line on the screen, I just print
the most important error first by editing the most lethal conditions
first. Our users are very sharp and meke few errors anyway, I don't see
the value in "over coding" for events that are not likely (or
infrequently) to happen.
In article <87d0h6$62om$1...@newssvr03-int.news.prodigy.com>,
> VALIDATE-FIELDS.
> VALIDATE FIELD-1
> IF IN-ERR
> SET FIELD-1-IN-ERR TO TRUE
> END-IF
> VALIDATE FIELD-2
> IF IN-ERR
> SET FIELD-2-IN-ERR TO TRUE
> END-IF
> VALIDATE FIELD-3
> IF IN-ERR
> SET FIELD-3-IN-ERR TO TRUE
> END-IF
> VALIDATE FIELD-4
> IF IN-ERR
> SET FIELD-4-IN-ERR TO TRUE
> END-IF
> VALIDATE FIELD-5
> IF IN-ERR
> SET FIELD-5-IN-ERR TO TRUE
> END-IF
> VALIDATE FIELD-6
> IF IN-ERR
> SET FIELD-6-IN-ERR TO TRUE
> END-IF
> .
> DISPLAY-ERRS.
> IF FIELD-1-IN-ERR
> DISPLAY ERR-1
> END-IF
> IF FIELD-2-IN-ERR
> DISPLAY ERR-2
> END-IF
> IF FIELD-3-IN-ERR
> DISPLAY ERR-3
> END-IF
> IF FIELD-4-IN-ERR
> DISPLAY ERR-4
> END-IF
> IF FIELD-5-IN-ERR
> DISPLAY ERR-5
> END-IF
> IF FIELD-6-IN-ERR
> DISPLAY ERR-6
> END-IF
> .
>
> Of course for more than a half dozen fields, I would've used
subscripts or
> indexes to set the error switches and to display the corresponding
error
> messages.
>
>
donald tees
>
>normally only make one error at a time, so it doesn't
>matter.
>
;<)
Robert W. McAdams
> Isn't CONTINUE an implicit GO TO?
> Don't we interpret IF, THEN, ELSE constructions with an implied GO TO?
Yes. What's your point?
The problem with explicit GO TOs is that they require paragraph names to "go
to". And every time you add a paragraph name, it forces a programmer who is
reading the program to spend time evaluating where and how the paragraph is
referenced. Implicit GO TOs do not have this problem.
Bob
Howard Brazee
values before they used that field as a key to look up something on the
database. With faster machines, I would rather have simpler code and
just not find the record. And if they ever change to allow alpha
characters it will still work.
Judson McClendon
>Your comments are generally true. The only
>problem I have is that your validation plods along
>one field at a time. The way I do things is to check
>as many fields as possible in one go, to minimize
>1) the transaction load on the machine and the communications line
>2) the end-user aggravation ("why can't it check all fields at a time")
>
>You should normally check the fields from the bottom
>up, highlight the ones that are in error, and put the cursor
>on the topmost error, with an error message pertaining
>to that only. Your coding style does not really support
>this, so your users become victims of your convenience.
>
>normally only make one error at a time, so it doesn't
>matter.
There's two more arguments that are paramount in these programs.
They generally have very complex validations involving multiple
fields. This is necessary to meet design requirements. Once an
error is detected in a field, it is indefinite what other fields
may or may not be in error. Also, the way the error messages
are returned (a special line at the bottom of the screen that
the terminal or emulator supports for this purpose) only has
space for one error message. :-) At one time I devised a system
where the bottom two lines of the screen were divided into four
error messages. But this eventually had to be dropped, because
the user's data screens have so many data fields that it is not
possible to do it. Many of their later systems require multiple
screens to do one transaction, just to fit all the data on the
screens. In the Unisys A Series COMS environment, this presents
special problems and makes processing the transactions much more
complicated for the programmer and the user. I have two large
clients, both of whom have similar situations. True interactive
systems wouldn't have these particular problems, of course. :-)
Judson McClendon
>I supposed it was that way.
>The reason I asked, is my searching for tools to scan Wang Cobol for certain
>syntax, in order to be able to do some kind of refactoring, conversion etc.
>I do think that I need to have a big COBOL parser to perform my tasks, at
>least not by the current moment. And I really cannot afford much time on
>writing my own.
>Got an idea? After all, the topic should be of general interest, I think.
I don't know your requirements, but for a simple PERFORM THRU/GO TO
checker, you don't need to completely parse the entire program. In
my own personal coding standard I use paragraph numbers, which makes
this task much simpler, because a paragraph and its exit will always
have the same number. You only need to check that each PERFORM has
a THRU with the same paragraph number, with '-EXIT' on the end of
the paragraph name. Within a paragraph, remember the paragraph's
number, then check all GO TOs within to make sure they have the same
number. Test the exit paragraph as well. Also verify that all the
paragraph numbers are ascending with no duplicates. With paragraph
numbers, this is all you need for simple PERFORM THRU/GO TO tests,
because the compiler will syntax any other problems, if you test for
these.
Without paragraph numbers, I would highly recommend using the form
PERFORM THIS-PARAGRAPH
THRU THIS-PARAGRAPH-EXIT.
This will permit you to test GO TOs within the paragraph without
having to build paragraph name tables in order to match them
with their exits and GO TOs within them. If you do this, the logic
is pretty much the same, because if you have duplicate paragraph
names, the compiler will flag them.
I always assume the code is syntax free, which simplifies parsing
a bit, and you only need to look at the Procedure Division. If
you eliminate comments and literals from the line before parsing
the line, you can depend on a space delimited "PERFORM" being an
actual command, and the next word following the paragraph name
must be "THRU" or "THROUGH", followed by the same paragraph name,
with "-EXIT" appended. My code checker looks for improperly
indented code and missing/extra periods, etc. Essentially, it
checks the indenting of the code against period placement, to
make sure they are in agreement. This program has caught many
thousands of errors, hundreds of them in programs that had been
running for years, until the scanner was run against them. It
is also useful to enforce certain coding style standards.
DennisHarley
Robert W. McAdams <famb...@sigmais.com> wrote in message
news:389B13CD...@sigmais.com...
I have written edit macros which make finding paragraph names and data names
easier.
It takes about 5-10 seconds to determine where something is referenced.
>
>
> Bob
>
Howard Brazee
> I don't know your requirements, but for a simple PERFORM THRU/GO TO
> checker, you don't need to completely parse the entire program.
I highly recommend that if someone chooses to write programs with drop through
logic to write utilities to catch mistakes caused by this style, and to enforce
the standard that these utilities have to be used.
Or alternatively switch to a coding style where these checks are not necessary,
and enforce that style.
Rick Price
> Judson McClendon ju...@bellsouth.net
> Sun Valley Systems http://www.sunvaley.com
> "For God so loved the world that He gave His only begotten Son, that
> whoever believes in Him should not perish but have everlasting life."
>
I didn't really want to get into this but I'm really fed up with this
thread. BTW I kind of support both of you on validation.
As Bill Klein said earlier (more than somewhat) in this thread; in the UK we
tend to use sections all the time. This seems to be anathema to some
people, but tough.
So as far as validation goes, I would have a section which dealt with the
validation of a whole screen, which could perform subsidiary sections for
complex validation of individual fields. I would certainly validate the
screen as a whole, and highlight all invalid fields even if I only had room
to describe the error on the first field. Users can normally recognise what
is wrong with a field if it is highlighted. They don't need to have a 'Must
be numeric' message to tell them. If they don't understand the error, they
fix what they can and press enter to get the next message. So that's Lief's
point of view.
But I agree with Judson that there's no point in doing cross validation if
any fields are in error. However we validate for content first and only
validate for context if all content is OK.
BTW I would tend to do full screen validation even on Windows or using
curses on Unix although I might allow the users to configure whether they
wanted to have their typing interrupted on each error. In my experience,
they don't take that option.
What I don't agree with is this fundamentalist view, that has driven this
thread, that there is only one correct way to program. Total tosh. I've
been programming for 35 years. I've programmed in 4-5 different assemblers,
COBOL, PL/I, various BASICS, C and languages whose initials I can't
remember. I know that I write code that is generally easy to maintain. I
also know that I have frequently had to write code that is going to be hard
to understand, even by me, a little way down the line. Its no good saying
it shouldn't be so. It is so. In these cases I try to comment what I'm
doing so that it explains why I did what I did. But even that's not always
possible.
I agree that structured programming is nice. In fact I think I was using it
before it had a name. But its not the meaning of life. Its just a tool and
you always have to use the right tool for the job. In my time there have
been many philosophies/languages that were going to transform programming
and solve all problems. Most of them disappeared, while some of them just
became another tool. But all of them had worshippers who thought they were
the only way to do things.
Some times you just have to use GO TO. Sometimes code has GO TO in it
because of its age. We have modules working on our WANG that were last
compiled in 1980. Similarly we have modules on the AS400 that were last
compiled in 1990. Unfortunately there doesn't seem to be this sort of
stability/upward compatibility in UNIX but certainly we are still compiling
old COBOL source. They all still work. If I had to change them I would
just do the change. I wouldn't rewrite them no matter how many GO TOs they
had. If anybody in our organisation rewrote something because they don't
like the structure they would have to find another job.
I have never found major problems maintaining other peoples code because it
has GO TOs in it. Maybe using sections in COBOL make GO TOs easier to
control and follow. But that would just show that GO TOs are not inherently
wrong. They just cause problems in some styles of programs.
One thing that worries me is, if these programs are so difficult to
maintain, how can they be understood well enough to allow them to be
rewritten and totally revalidated.
Have a nice weekend everyone. :-)
Rick
William M. Klein
this particular thread incredibly "unproductive". I haven't heard anyone
convincing anyone else of anything !!! (much less presenting some fact that
the other readers didn't already know)
Being of "good German Jewish stock," I won't mention that specific nasty
Austrian, but I think that allowing this thread to die a well deserved death
might be "in order".
--
Bill Klein
wmklein <at> ix dot netcom dot com