Home > Archive > Cobol > August 2007 > Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
|
|
| Alistair 2007-08-03, 6:55 pm |
| On 3 Aug, 13:05, docdw...@panix.com () wrote:
> In article <5hflj7F3kpge...@mid.individual.net>,
>
> Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote:
>
>
>
> Here's one guess, Mr Dashwood... it was because the programmers, each and
> every one of them who worked on the system over the years, were shiftless,
> lazy, incompetent fools incapable of diagnosing and fixing errors which
> caused them to be, on a regular basis, disturbed from their nightly
> embracing of Morpheus, thereby insuring their own continued interrupted
> slumbers...
>
> ... and here's another: someone with sufficient authority saw it as being
> beneficial to keep things going Just The Way They Were. How do you think
> William of Ockham might have diced this?
>
> DD
I think Mr Dashwood's question is fair and proper. Also, his assertion
that I worked for bad managers may also have some truth in it. But it
may be in part due to the complexity of the systems exceeding the
abilities of the development staff to produce reliable and efficient
code (one programmer wrote code which validated every date by calling
external programs even when the date was the same as the previously
validated date. Code developed by a programmer whose brain was asleep
on the job and he was one of the better staff).
I think that the abilities of programmers declined with the generation
following on from me (apologies to Kellie et al but please indulge an
old fogey) whilst the management expectations rose (we all have seen
job ads for senior analyst/programmers with 18 months experience, and
ads for managers with 6 months experience). I also think that there is
too much pressure to complete a task quickly (what is it that you say
Doc: Time, Cost, Quality - which two do you want) with immovable
implementation dates agreed before anyone has a clear idea of the
requirements and that puts the squeeze on testing. Also, years of
experience allows us to pre-empt many possible problems and design/
code our way around them with intelligent and directed testing
discovering the remaining bugs.
I could go on but my medication has arrived..... ;-)
| |
| Doug Miller 2007-08-03, 9:55 pm |
| In article <1186191243.655094.162380@r34g2000hsd.googlegroups.com>, Alistair <alistair@ld50macca.demon.co.uk> wrote:
>There is a school of thought that would have NOT abolished. Perhaps
>your code would read better as:
>
>If Input-Date = Prev-Date
> blah blah blah
>else
> Perform Date-Ritual
>end-if.
Aaah, but what if "blah blah blah" is nothing at all? Eliminating NOT would
require replacing constructs such as
IF Input-Date NOT = Prev-Date
PERFORM Date-Ritual
END-IF
with
IF Input-Date = Prev-Date
CONTINUE
ELSE
PERFORM Date-Ritual
END-IF
which is IMO a *far* worse abomination than the use of NOT.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Pete Dashwood 2007-08-03, 9:55 pm |
|
--
"I used to write COBOL...now I can do anything."
"Howard Brazee" <howard@brazee.net> wrote in message
news:4vr6b3ltk0vg14dlik0khn8lec5n3802ne@
4ax.com...
> On Fri, 3 Aug 2007 17:29:49 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
> I believe one reason companies are moving towards Web environments is
> that the Web programmers can appear to be saying just that.
>
> But iterative analysis, review & testing aren't the same thing as no
> analysis, review & testing.
Exactly!
I don't disagree with Doc's emphasis on the lifecycle (and it is good to see
some positive suggestions coming out). The only area where I might differ is
in whether it should all be done up front, or whether it can be "started,
then revisited" (iterated)
I'm a big fan of RAD and iteration. Not because of text books, but because,
when it has been applied properly, I have seen startling results with it.
Iteration and interaction are the two key things that give the RAD approach
its power.
I'm currently developing a major (major, for me, and in the sense that there
is a great deal of code behind the visible pages...) web site for some
software I wrote. Building the pages and the code behind the pages (it is
all ASP.NET and C#) was pretty easy, but now I am into testing and linking
stuff together, and evolving the design as I go along. It is really
non-trivial.
Certainly, by the time I let it go live, this site will have had every bit
as much analysis, review and testing as a comparable desktop application.
Spreading these tasks over web pages does not eliminate them :-)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2007-08-03, 9:55 pm |
|
--
"I used to write COBOL...now I can do anything."
<docdwarf@panix.com> wrote in message news:f8vrpd$16a$1@reader2.panix.com...
> In article <4vr6b3ltk0vg14dlik0khn8lec5n3802ne@4ax.com>,
> Howard Brazee <howard@brazee.net> wrote:
>
> I don't know many Web programmers, true... but if I hear anyone tell me
> that they can get a programming-task accomplished 'without rigorous
> testing' my first response is 'How interesting... what does it mean to get
> a task done without determining if the results are accurate?'
>
The testing for web programming is every bit as rigourous as for any other
application development.
In fact, I'm finding that only by getting others to try various facilities
of the site can I find errors. There was a bug where a post code greater
than 3 digits was truncated. None of my own test plans encountered it. I got
another pair of eyes (in a different country - the web is amazing :-)) to
take a look and immediately, it came to light. (I should mention that this
was found after my engine had successfully processed over 100,000 addresses
and looked like it was bug free...) Anyone who tells you they develop web
sites without rigourous testing is either very foolish or very lucky.
Pete
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2007-08-04, 3:55 am |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1186191243.655094.162380@r34g2000hsd.googlegroups.com...
> On 3 Aug, 18:29, docdw...@panix.com () wrote:
>
<snip>
>
> There is a school of thought that would have NOT abolished.
I sincerely hope that any such school permanently closes its gates and goes
on holiday indefinitely... :-)
Presumably the same school would have AND and OR removed, also?
Makes my blood Boole...
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Doug Miller 2007-08-04, 6:55 pm |
| In article <1186227636.237724.32460@o61g2000hsh.googlegroups.com>, Alistair <alistair@ld50macca.demon.co.uk> wrote:
>I am happy with NOT being used to simplify constructs.
Same here.
>However, I have
>met programmers who would have difficulty understanding a moderate
>level of complex IF using NOT.
Yes, I have too -- and I've always thought that such folk were in the wrong
line of work.
>I am also happy with CONTINUE and the
>older NEXT SENTENCE.
I prefer to use constructs that make them unnecessary, e.g.
IF NOT <condition>
<statement>
END-IF
instead of
IF <condition>
CONTINUE
ELSE
<statement>
END-IF
which IMO unnecessarily impedes understanding the function of the program,
while contributing no compensating advantages whatever. But the one that
*really* drives me up the wall is
IF NOT <condition>
NEXT SENTENCE
ELSE
<statement> .
That, to me, is a complete inversion of the natural way of considering a
test-and-action sequence, and should always be written as the far simpler and
more understandable
IF <condition>
<statement> .
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Pete Dashwood 2007-08-04, 6:55 pm |
|
"Doug Miller" <spambait@milmac.com> wrote in message
news:J32ti.630$3x.597@newssvr25.news.prodigy.net...
> In article <1186227636.237724.32460@o61g2000hsh.googlegroups.com>,
> Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>
> Same here.
And me...
>
>
> Yes, I have too -- and I've always thought that such folk were in the
> wrong
> line of work.
Yep. Me too...
>
>
> I prefer to use constructs that make them unnecessary, e.g.
Hear hear... :-)
>
> IF NOT <condition>
> <statement>
> END-IF
>
> instead of
>
> IF <condition>
> CONTINUE
> ELSE
> <statement>
> END-IF
>
> which IMO unnecessarily impedes understanding the function of the program,
> while contributing no compensating advantages whatever. But the one that
> *really* drives me up the wall is
>
> IF NOT <condition>
> NEXT SENTENCE
> ELSE
> <statement> .
>
> That, to me, is a complete inversion of the natural way of considering a
> test-and-action sequence, and should always be written as the far simpler
> and
> more understandable
>
> IF <condition>
> <statement> .
>
Yes, absolutely.
And we can agree on all of these points just by applying common sense and
experience.
(I never even got a chance to get on my Boolean soapbox and extol the
virtues of George's Algebra and propositional calculus, or how you might
apply this to unravelling convoluted nested IFs in COBOL programs...)
Bugger!
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Doug Miller 2007-08-04, 9:56 pm |
| In article <1186273558.137520.199470@l70g2000hse.googlegroups.com>, Alistair <alistair@ld50macca.demon.co.uk> wrote:
>Whereas I agree with you about retaining and using NOT rather than
>using inelegant IF NOT...ELSE constructs I have found that inserting
>the CONTINUE/NEXT SENTENCE into the IF......ELSE construct can make
>the processing clearer and show that at least the other options were
>considered and discarded. And it balances up nested IFs. Which I have
>seen run over four pages long.
In the construct
IF <condition>
<statement>
ELSE
CONTINUE
END-IF
ELSE CONTINUE (or ELSE NEXT SENTENCE, as the case may be) is redundant, and
can easily be omitted with no loss of clarity.
Conversely, in the construct
IF <condition>
CONTINUE
ELSE
<statement>
END-IF
CONTINUE ELSE can (and IMO should) be omitted simply by inverting <condition>
to NOT <condition> -- with a considerable *gain* in clarity by so doing.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Rick Smith 2007-08-05, 3:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5hkgiaF3k84enU1@mid.individual.net...
>
>
> "Doug Miller" <spambait@milmac.com> wrote in message
> news:J32ti.630$3x.597@newssvr25.news.prodigy.net...
[snip][color=darkred]
>
> Yep. Me too...
Perhaps with such weaknesses as maintenance programmers,
their new line of work should be new program development.
In that position, they might keep the knots, ... er NOTs, out
of future code. <g>
Seriously, consider the problem of general exclusionary rules.
Such rules state, in effect, that a particular action is not to be
taken; but those rules, over time, may come to have exceptions.
From a program maintenance standpoint, having somewhere to
place those exceptions seems worthwhile.
if general-exclusionary-rule
continue
else
perform default-action
end-if
The 'continue' statement is the placeholder for the inevitable
exceptions to the general rule. When exceptions need to be
added to the code, the 'continue' is replaced with the necessary
tests.
perform tests-for-exception
if exception-to-general-rule
perform default-action
end-if
If the original code is written with a 'not',
if not general-exclusionary-rule
perform default-action
end-if
The tendency might be to begin stacking one exception after
another into the 'if' condition; thus leading to a maintenance
nightmare.
if (not general-exclusionary-rule)
or (1st-exception)
or (2d-exception)
or (...)
or (nth-exception)
perform default-action
end-if
In this case, one might say (and I will): When a general
exclusionary rule is present, use 'continue' instead of 'not'
as an exception to the general exclusionary rule, "Use 'not'
instead of 'continue'". <g>
| |
| tlmfru 2007-08-05, 6:55 pm |
|
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5hi9caF3jsol6U1@mid.individual.net...
>
>
> "Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
> news:1186191243.655094.162380@r34g2000hsd.googlegroups.com...
> <snip>
>
This is the "School of Over-reaction". I dare say many of us have been
caught at least once by the NOT .. AND requirement (i.e., IF A NOT = B OR C
should be IF A NOT = B AND C); the over-reaction is ban the NOT because its
use may be counter-intuitive. (I know there are alternate ways to code this
that make it clear. That's not the point).
There may in fact be a case to be made for employing only a subset of a
language - the subset necessary for the simplest expression of the problem -
and I don't care to get into specifying that because it's too personal - but
rules declared because of fear tend to stultify the programmer's development
and likely degrade the program as well.
PL
| |
| Pete Dashwood 2007-08-05, 6:55 pm |
|
"tlmfru" <lacey@mts.net> wrote in message
news:dnmti.24730$rH6.4634@newsfe22.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:5hi9caF3jsol6U1@mid.individual.net...
>
> This is the "School of Over-reaction". I dare say many of us have been
> caught at least once by the NOT .. AND requirement (i.e., IF A NOT = B OR
> C
> should be IF A NOT = B AND C); the over-reaction is ban the NOT because
> its
> use may be counter-intuitive. (I know there are alternate ways to code
> this
> that make it clear. That's not the point).
>
> There may in fact be a case to be made for employing only a subset of a
> language - the subset necessary for the simplest expression of the
> problem -
> and I don't care to get into specifying that because it's too personal -
> but
> rules declared because of fear tend to stultify the programmer's
> development
> and likely degrade the program as well.
>
> PL
>
Well said. I think De Morgans laws have tripped up many programmers at one
time or another, yet, they are beautiful in their simplicity and elegance if
one takes the trouble to understand them. I don't want NOT abolished because
it is part of a "set"; the set that defines a Boolean Algebra. To hear
people whio call themselves "programmers" advocating that NOT be abolished,
because they didn't understand De Morgan. or because it is
"counter-intuitive", is like hearing a coal miner suggest that picks should
not be allowed in the pit because his friend droopped one on his foot and
shovels are perfectly adequate anyway...
Pete.
--
"I used to write COBOL...now I can do anything."
>
| |
| Howard Brazee 2007-08-06, 6:55 pm |
| On Sat, 04 Aug 2007 01:51:10 GMT, spambait@milmac.com (Doug Miller)
wrote:
>IF Input-Date = Prev-Date
> CONTINUE
>ELSE
> PERFORM Date-Ritual
>END-IF
>
>which is IMO a *far* worse abomination than the use of NOT.
Why?
| |
| Howard Brazee 2007-08-06, 6:55 pm |
| On Sat, 04 Aug 2007 17:25:58 -0700, Alistair
<alistair@ld50macca.demon.co.uk> wrote:
>
>Whereas I agree with you about retaining and using NOT rather than
>using inelegant IF NOT...ELSE constructs I have found that inserting
>the CONTINUE/NEXT SENTENCE into the IF......ELSE construct can make
>the processing clearer and show that at least the other options were
>considered and discarded. And it balances up nested IFs. Which I have
>seen run over four pages long.
Also:
IF CONDITION
CONTINUE
ELSE
PERFORM MY-PARAGRAPH
END-IF
is easy to maintain.
| |
| Doug Miller 2007-08-06, 6:55 pm |
| In article <k8geb3djttctum50sjf8d1m55531hmlp4a@4ax.com>, Howard Brazee <howard@brazee.net> wrote:
>On Sat, 04 Aug 2007 01:51:10 GMT, spambait@milmac.com (Doug Miller)
>wrote:
>
>
>Why?
>
Because it inverts the natural way of thinking about a test-action sequence
from "if (something) then do (something)" to "if (something) then don't do
anything, otherwise do (something)". That's a bass-ackwards way of thinking.
IF Input-Date NOT EQUAL Prev-Date
PERFORM Date-Ritual
END-IF
is IMO vastly preferable to the construct above.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Doug Miller 2007-08-06, 6:55 pm |
| In article <odgeb3ltb7u7449peglr732tvj8kb430gb@4ax.com>, Howard Brazee <howard@brazee.net> wrote:
>On Sat, 04 Aug 2007 17:25:58 -0700, Alistair
><alistair@ld50macca.demon.co.uk> wrote:
>
>
>Also:
>
>IF CONDITION
> CONTINUE
>ELSE
> PERFORM MY-PARAGRAPH
>END-IF
>
>is easy to maintain.
IF NOT CONDITION
PERFORM MY-PARAGRAPH
END-IF
is equally easy to maintain, and has the additional advantage of being easier
to understand.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Howard Brazee 2007-08-06, 6:55 pm |
| On Mon, 06 Aug 2007 16:23:49 GMT, spambait@milmac.com (Doug Miller)
wrote:
>Because it inverts the natural way of thinking about a test-action sequence
>from "if (something) then do (something)" to "if (something) then don't do
>anything, otherwise do (something)". That's a bass-ackwards way of thinking.
>
>IF Input-Date NOT EQUAL Prev-Date
> PERFORM Date-Ritual
>END-IF
>
>is IMO vastly preferable to the construct above.
I don't see it.
It certainly is easier to notice a separate line CONTINUE than an
embedded NOT.
| |
| Doug Miller 2007-08-06, 6:55 pm |
| In article <6fjeb3537ni4hpmjvnn7816eqkr92m8qfe@4ax.com>, Howard Brazee <howard@brazee.net> wrote:
>On Mon, 06 Aug 2007 16:23:49 GMT, spambait@milmac.com (Doug Miller)
>wrote:
>
>
>I don't see it.
>
>It certainly is easier to notice a separate line CONTINUE than an
>embedded NOT.
To each his own...
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Howard Brazee 2007-08-06, 6:55 pm |
| On Mon, 6 Aug 2007 13:38:58 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>So I had the choice of doing either the IF statement with the parentheses or
>the EVALUATE. I chose EVALUATE.
Evaluate is easily the easiest to maintain - except for some
programmers who have never come across it (and this number is
amazingly large). While it's not as close to English as the
original idea for CoBOL is, it is straightforward. I agree with you.
| |
| Pete Dashwood 2007-08-07, 3:56 am |
|
"Doug Miller" <spambait@milmac.com> wrote in message
news:pWHti.47480$YL5.40162@newssvr29.news.prodigy.net...
> In article <k8geb3djttctum50sjf8d1m55531hmlp4a@4ax.com>, Howard Brazee
> <howard@brazee.net> wrote:
> Because it inverts the natural way of thinking about a test-action
> sequence
> from "if (something) then do (something)" to "if (something) then don't do
> anything, otherwise do (something)". That's a bass-ackwards way of
> thinking.
>
> IF Input-Date NOT EQUAL Prev-Date
> PERFORM Date-Ritual
> END-IF
>
> is IMO vastly preferable to the construct above.
>
You're right. And your explanation (justification?) is right on the button,
ignore the dissenters... :-)
(Is it really worth arguing about this?)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2007-08-07, 3:56 am |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1186428018.286416.272420@x35g2000prf.googlegroups.com...
> On Aug 7, 4:23 am, spamb...@milmac.com (Doug Miller) wrote:
>
> It inverts _your_ way of thinking about ...
>
> It may be the way that others _do_ think about ..
>
>
> Perhaps others think like an EVALUATE or case statement:
>
> condition1
> action1
> condition2
> ...
> otherwise
> ...
>
> It just happens that this has a condition1 with nothing to do (but may
> have later) and there isn't a condition2 (yet, that might come).
>
> IF Input-Date = Prev-Date
> CONTINUE
> ELSE
> IF Input-Date > Todays-Date
> PERFORM Too-Soon
> ELSE
> PERFORM Date-Ritual
> END-IF
> END-IF
>
>
> Others may prefer:
>
> IF NOT ( Input-Date = Prev-Date )
> PERFORM Date-Ritual
> END-IF
>
I think EVALUATE can have non active entries for the sake of the future, as
you describe, and I also have used the last example of NOT (and compound
variations of it) in the lines immediately above.
The only thing I see worth debating here is, not the particular way in which
we code a negated condition (in IF, EVALUATE, or PERFORM), but in whether
NOT should be allowed at all...:-)
(I can't believe someone suggesting that it shouldn't be... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
|
|
|
|
|