Cobol - evaluate false, again

Author

evaluate false, again

Frank Swarbrick

2007-08-14, 6:55 pm

So I wrote some code yesterday using my wonderful new discovery of "evaluate
false". Here's the logic.

05 MSC-ISS-COUNTRY PIC 9(03).
88 ISS-COUNTRY-IS-USA VALUE 840.
05 MSC-ACQ-STATE PIC X(02).
88 NON-US-SURCHG-ALLOWED VALUES 'CO' 'CA'.

IF ICR-COUNTRY-CODE IS NUMERIC
MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
MOVE STR-REGE-ST TO MSC-ACQ-STATE
EVALUATE ISS-COUNTRY-IS-USA
OR NON-US-SURCHG-ALLOWED
WHEN FALSE
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-EVALUATE
END-IF.

During peer code review the reviewer asserted that this would not work as
expected.
I then asked him if he believe that the following two sets of code were the
same as the first:

IF ICR-COUNTRY-CODE IS NUMERIC
MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
MOVE STR-REGE-ST TO MSC-ACQ-STATE
IF ISS-COUNTRY-IS-USA
OR NON-US-SURCHG-ALLOWED
CONTINUE
ELSE
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-IF
END-IF.

IF ICR-COUNTRY-CODE IS NUMERIC
MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
MOVE STR-REGE-ST TO MSC-ACQ-STATE
EVALUATE ISS-COUNTRY-IS-USA
OR NON-US-SURCHG-ALLOWED
WHEN TRUE
CONTINUE
WHEN FALSE
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-EVALUATE
END-IF.

He said he didn't believe so; that they were the same as each other but not
the same as the original. When asking why, it turns out he interpreted the
original kind of as the following:

IF ISS-COUNTRY-USA IS FALSE OR NON-US-SURCHG-ALLOWED IS FALSE
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-IF

(Assume the above was valid Cobol, which of course it is not.)

I set him straight on how it works (it evaluates the expression, getting a
single true/false result, and then , but now my concern is that the original
statement is not as 'obvious' as I had first hoped.

(Of course there is the slight possibility that I am incorrect, but I did
test what I believe to be all possible cases and got the results I was
expecting.)

Opinions?

Frank

Doug Miller

2007-08-14, 6:55 pm

In article <46C1779A.6F0F.0085.0@efirstbank.com>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>I set him straight on how it works (it evaluates the expression, getting a
>single true/false result, and then , but now my concern is that the original
>statement is not as 'obvious' as I had first hoped.

It's not. (IMO)
>
>(Of course there is the slight possibility that I am incorrect, but I did
>test what I believe to be all possible cases and got the results I was
>expecting.)

No, you're correct.
>
>Opinions?

I would have written the critical part as

IF NOT (ISS-COUNTRY-IS-USA OR NON-US-SURCHG-ALLOWED)
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-IF

or (perhaps better yet) the logically equivalent

IF NOT ISS-COUNTRY-IS-USA AND NOT NON-US-SURCHG-ALLOWED
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-IF

precisely because of the possibility for confusion created by EVALUATE FALSE
applied to a compound condition.

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Alistair

2007-08-14, 6:55 pm

On 14 Aug, 16:36, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
> So I wrote some code yesterday using my wonderful new discovery of "evaluate
> false". Here's the logic.
>
> 05 MSC-ISS-COUNTRY PIC 9(03).
> 88 ISS-COUNTRY-IS-USA VALUE 840.
> 05 MSC-ACQ-STATE PIC X(02).
> 88 NON-US-SURCHG-ALLOWED VALUES 'CO' 'CA'.
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
> END-IF.
>
> During peer code review the reviewer asserted that this would not work as
> expected.
> I then asked him if he believe that the following two sets of code were the
> same as the first:
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> IF ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> CONTINUE
> ELSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-IF
> END-IF.
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN TRUE
> CONTINUE
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
> END-IF.
>
> He said he didn't believe so; that they were the same as each other but not
> the same as the original. When asking why, it turns out he interpreted the
> original kind of as the following:
>
> IF ISS-COUNTRY-USA IS FALSE OR NON-US-SURCHG-ALLOWED IS FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-IF
>
> (Assume the above was valid Cobol, which of course it is not.)
>
> I set him straight on how it works (it evaluates the expression, getting a
> single true/false result, and then , but now my concern is that the original
> statement is not as 'obvious' as I had first hoped.
>
> (Of course there is the slight possibility that I am incorrect, but I did
> test what I believe to be all possible cases and got the results I was
> expecting.)
>
> Opinions?
>
> Frank

You have found one of the reasons that I rarely use evaluate - the
fact that I don't understand FALSE, etc. Better to simplify the
evaluate.

Pete Dashwood

2007-08-14, 6:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46C1779A.6F0F.0085.0@efirstbank.com...
> So I wrote some code yesterday using my wonderful new discovery of
> "evaluate
> false". Here's the logic.
>
> 05 MSC-ISS-COUNTRY PIC 9(03).
> 88 ISS-COUNTRY-IS-USA VALUE 840.
> 05 MSC-ACQ-STATE PIC X(02).
> 88 NON-US-SURCHG-ALLOWED VALUES 'CO' 'CA'.
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
> END-IF.
>
>
> During peer code review the reviewer asserted that this would not work as
> expected.
> I then asked him if he believe that the following two sets of code were
> the
> same as the first:
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> IF ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> CONTINUE
> ELSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-IF
> END-IF.
>
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN TRUE
> CONTINUE
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
> END-IF.
>
> He said he didn't believe so; that they were the same as each other but
> not
> the same as the original. When asking why, it turns out he interpreted
> the
> original kind of as the following:
>
> IF ISS-COUNTRY-USA IS FALSE OR NON-US-SURCHG-ALLOWED IS FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-IF
>
> (Assume the above was valid Cobol, which of course it is not.)
>
> I set him straight on how it works (it evaluates the expression, getting a
> single true/false result, and then , but now my concern is that the
> original
> statement is not as 'obvious' as I had first hoped.

No, it isn't.

This is a case of adding complexity so you can play with the new toys...
:-) (yeah, we've all done it...:-))

The problem here is that it disguises the De Morgan.

As soon as you use FALSE with a compound condition, you are into De Morgan
territory.

Most programmers know De Morgan's Laws (even if they may not recognise them
by that name):

(A.B)' = A' + B' [NOT (A AND B) = NOT A OR NOT B] De Morgan I
(A+B)' = A'.B' [NOT (A OR B) = NOT A AND NOT B] De Morgan II

You don't have to be an expert in Boolean Algebra to know that this has
tripped up so many programmers and made their programs crash and burn.

It is the reason behind the discussion on banning NOT that we saw here
recently.

(It made me shiver to think that people were seriously suggesting removing
NOT from the language, and letting the NOT implicit in an ELSE do the job
instead. That's like cutting your head off because you don't like the shape
of your mouth, and feeding yourself intravenously instead (assuming head
removal wasn't fatal :-))... Just because you consider NOT unsightly doesn't
mean that it is, or that it is of no use... )

So, the problem with EVALUATE FALSE and compound conditions is that the De
Morgan is implicit and not immediately obvious.

(With EVALUATE TRUE there is no De Morgan to worry about, and it is
encouraged on many sites; that's why many people are not even aware that you
CAN EVALUATE FALSE...)

Ban it? Well you could, I s'pose... but that's a bit drastic.

Why not make the standard be that people are encouraged to use the simplest
possible constructs, and run a few lunchtime courses on Boolean Algebra and
simplification? (I've done this in a few places and found these informal
sessions well attended and fun. Bring your lunch and lets unravel some
convoluted COBOL...)

The thing about standards is that people should be comfortable with them. If
they understand the risks in using various constructs, then they will use
them correctly or choose alternatives. If the aim is to keep things simple,
and everyone agrees with that aim, there should be no need to BAN anything.

Using a negated EVALUATE , as you have done, where a simple IF would serve
the purpose, arguably better, might then be viewed as pretentious, or
"antisocial" for that particular site... :-)

Doug's solution gets my vote...

IF NOT (ISS-COUNTRY-IS-USA OR NON-US-SURCHG-ALLOWED)
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-IF

This clearly shows the De Morgan.

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2007-08-14, 6:55 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1187121517.482881.128680@g4g2000hsf.googlegroups.com...
> On 14 Aug, 16:36, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
> wrote:
>
> You have found one of the reasons that I rarely use evaluate - the
> fact that I don't understand FALSE, etc. Better to simplify the
> evaluate.
>
....or maybe take up truck driving as a career?

Pete.
--
"I used to write COBOL...now I can do anything."

HeyBub

2007-08-14, 9:55 pm

Frank Swarbrick wrote:
>
>
> During peer code review the reviewer asserted that this would not
> work as expected.
>
> I set him straight on how it works (it evaluates the expression,
> getting a single true/false result, and then , but now my concern is
> that the original statement is not as 'obvious' as I had first hoped.
>
>
> Opinions?
>

A similar thing happened to me. I once wrote a FORTRAN subroutine where each
variable was a different number of dollar signs [i.e., $$$ = SQRT($$**2 +
$$$$) ].

A co-worker ("peer" in your example) expressed mild dissatisfaction with my
style.

I smashed the XXXXer in the mouth and moved on.

2007-08-14, 9:55 pm

In article <5iesc4F3oojb8U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:46C1779A.6F0F.0085.0@efirstbank.com...

This is what I would call A Strong Warning. If 'the reviewer' is a
slightly-above-average specimen of programmers on your site then your
code's intent is not readily grasped by a slightly-above-average specimen
of programmer at your site.

Whether this means the code needs to be changed or the programmers'
understanding needs to be changed I will leave for others; I will say,
simply, that for most situations putting code into Prod, the intent of
which is not readily grasped by a slightly-above-average specimen of
programmer at your site, is, as some programmers might put it:

NOT (A-GOOD-IDEA).

[snip]
[color=darkred]
>
>No, it isn't.

I appear to agree with Mr Dashwood... for reasons stated above.

>
>This is a case of adding complexity so you can play with the new toys...
>:-) (yeah, we've all done it...:-))

I disagree with Mr Dashwood... for reasons stated above. What I believe
Mr Dashwood is seeing is what I have called 'Look, Ma, I'm a Programmer!'
code, where a programmer learns a new construct and then finds a place to
put it.

>
>The problem here is that it disguises the De Morgan.

I disagree with Mr Dashwood again. 'The' problem - if there is, in this
instance, a 'the' problem - I see is that a slightly-above-average etc
etc.

>
>Why not make the standard be that people are encouraged to use the simplest
>possible constructs, and run a few lunchtime courses on Boolean Algebra and
>simplification?

Change the program or/and change the programmers, as mentioned above.

DD

LX-i

2007-08-14, 9:55 pm

Frank Swarbrick wrote:
> So I wrote some code yesterday using my wonderful new discovery of "evaluate
> false". Here's the logic.
>
> 05 MSC-ISS-COUNTRY PIC 9(03).
> 88 ISS-COUNTRY-IS-USA VALUE 840.
> 05 MSC-ACQ-STATE PIC X(02).
> 88 NON-US-SURCHG-ALLOWED VALUES 'CO' 'CA'.
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
> END-IF.

I think I would say

EVALUATE TRUE

WHEN ISS-COUNTRY-IS-USA
WHEN NON-US-SURCHG-ALLOWED
CONTINUE

WHEN OTHER
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG

END-EVALUATE

But, I think your code does what you intend. :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Richard

2007-08-15, 3:55 am

On Aug 15, 3:36 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
> So I wrote some code yesterday using my wonderful new discovery of "evaluate
> false". Here's the logic.
>
> 05 MSC-ISS-COUNTRY PIC 9(03).
> 88 ISS-COUNTRY-IS-USA VALUE 840.
> 05 MSC-ACQ-STATE PIC X(02).
> 88 NON-US-SURCHG-ALLOWED VALUES 'CO' 'CA'.

> Opinions?

I dislike 88 levels and don't use them.

I dislike building 'magic numbers' into program code and would have
these items in a configuration file or in a database. Your programs
may never need to be run outside of USA or even outside your site, but
what if the states that allow surcharge (?) change. You then need to
schedule maintenance, retesting, peer review, .. Oh well it ensures
that you will have some work to do in the future.

> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED

It seems to me that CO and CA are actually states of the USA. So from
a logical point of view you should be testing if the state is CO or CA
only when the country _is_ the USA. Your test is true for any state in
the USA or for the states of CA or CO in any country.

Therefore it is only FALSE if the country is not America AND the state
is not (CA or CO).

That doesn't make sense.

Richard

2007-08-15, 3:55 am

On Aug 15, 3:36 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
> So I wrote some code yesterday using my wonderful new discovery of "evaluate
> false". Here's the logic.
>
> 05 MSC-ISS-COUNTRY PIC 9(03).
> 88 ISS-COUNTRY-IS-USA VALUE 840.
> 05 MSC-ACQ-STATE PIC X(02).
> 88 NON-US-SURCHG-ALLOWED VALUES 'CO' 'CA'.
>
> IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
> END-IF.

> (Of course there is the slight possibility that I am incorrect, but I did
> test what I believe to be all possible cases and got the results I was
> expecting.)

My testing had your evaluate as above except I had a WHEN TRUE
displaying 'surcharge' and WHEN FALSE displaying 'no surcharge'

840CO SURCHARGE
840XX SURCHARGE
990CO SURCHARGE
990XX NO SURCHARGE

What does the spec say you should be doing ?

2007-08-15, 6:55 pm

In article < KJGdnQ0bYpIE_1_bnZ2dnUVZ_orinZ2d@comcast
.com>,
LX-i <lxi0007@netscape.net> wrote:

[snip]

>But, I think your code does what you intend. :)

And as it has been said many, many times before:

IF PROGRAM-RUNS
PERFORM NEXT-ASSIGNMENT
ELSE
PERFORM CODE-LIKE-HELL UNTIL DAMNED-THING-WORKS.

dd

Alistair

2007-08-15, 6:55 pm

On 15 Aug, 00:33, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Alistair" <alist...@ld50macca.demon.co.uk> wrote in message
>
> news:1187121517.482881.128680@g4g2000hsf.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ...or maybe take up truck driving as a career?
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."- Hide quoted text -
>
> - Show quoted text -

No can do - you need good vision in BOTH eyes to be a truck driver.

Howard Brazee

2007-08-15, 6:55 pm

On Tue, 14 Aug 2007 12:58:37 -0700, Alistair
<alistair@ld50macca.demon.co.uk> wrote:

>You have found one of the reasons that I rarely use evaluate - the
>fact that I don't understand FALSE, etc. Better to simplify the
>evaluate.

I once worked in a shop that used to be RPG only before it went to
CoBOL. There were programs that used all sorts of tricks to
accomplish what RPG was not well designed for. They were difficult
to maintain.

If EVALUATE FALSE isn't clear to a shop's maintenance programmers -
there is no need to eschew EVALUATE altogether.

Frank Swarbrick

2007-08-15, 6:55 pm

>>> On 8/14/2007 at 7:42 PM, in message <f9tlm4$8le$1@reader1.panix.com>,
<docdwarf@panix.com> wrote:
> In article <5iesc4F3oojb8U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
> as
>
> This is what I would call A Strong Warning. If 'the reviewer' is a
> slightly-above-average specimen of programmers on your site then your
> code's intent is not readily grasped by a slightly-above-average specimen

> of programmer at your site.

I'd say that he's above average in potential but not yet in experience. As
soon as I explained it he 'got' it. Which isn't to say it's a good idea,
still.

> Whether this means the code needs to be changed or the programmers'
> understanding needs to be changed I will leave for others; I will say,
> simply, that for most situations putting code into Prod, the intent of
> which is not readily grasped by a slightly-above-average specimen of
> programmer at your site, is, as some programmers might put it:
>
> NOT (A-GOOD-IDEA).
>
> [snip]
>
[color=darkred]
> a
>
> I appear to agree with Mr Dashwood... for reasons stated above.

Scary! :-)

[color=darkred]
>
>
> I disagree with Mr Dashwood... for reasons stated above. What I believe
>
> Mr Dashwood is seeing is what I have called 'Look, Ma, I'm a
> Programmer!'
> code, where a programmer learns a new construct and then finds a place
> to
> put it.

That is certainly an somewhat of an accurate assessment of why I did it. I
keep hearing how some programmers can be

by 'negative logic'. So I
tried to avoid it by, umm, using negative logic. :-)

Still, the only way to learn if a particular construct is useful is to use
it, yes? So while one should not shoehorn in usage of a construct just
because they just learned it, on the other hand one should not eschew new
constructs just because they (or others!) are not as familiar with them.
Imagine a COBOL program who won't use those 'new-fangled' scope terminators.
After all, you can get by without them!

EVALUATE ISS-COUNTRY-IS-USA
OR NON-US-SURCHG-ALLOWED
WHEN FALSE
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-EVALUATE

I'm curious if anyone thinks the following Ruby code is any more or less
confusing:

unless iss_country_is_usa
or non_us_surchg-allowed
str_surchg_amt = 0
str_surchg = false
end

I was trying to emulate that kind of construct using COBOL.

Anyway, I am not as 'sold' on it as I would like, but I've still not given
up on it. Perhaps its just a matter of getting people familiar with it.
And the only way to do that is to use it. Certainly if not for the fact
that there are two conditions rather than one it wouldn't be as prone to
misunderstanding.

Frank

Doug Miller

2007-08-15, 6:55 pm

In article <46C2C907.6F0F.0085.0@efirstbank.com>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:

>I'm curious if anyone thinks the following Ruby code is any more or less
>confusing:
>
>unless iss_country_is_usa
> or non_us_surchg-allowed
> str_surchg_amt = 0
> str_surchg = false
>end

I think that, as written, it's *much* worse, because it's not at all clear
whether the meaning of the conditional test is

(unless iss_country_is_usa) or (non_us_surchg_allowed)

-OR-

unless (iss_country_is_usa or non_us_surchg_allowed)

Appropriately placed parentheses would, of course, remove the ambiguity.

>
>I was trying to emulate that kind of construct using COBOL.
>
>Anyway, I am not as 'sold' on it as I would like, but I've still not given
>up on it. Perhaps its just a matter of getting people familiar with it.
>And the only way to do that is to use it. Certainly if not for the fact
>that there are two conditions rather than one it wouldn't be as prone to
>misunderstanding.

Regardless of whether there are two conditions, one, or five hundred, it's
still IMO unnecessarily confusing.

With only one condition, the simplest way of encoding the logic is just
IF NOT (condition)
<statement>
END-IF

With two conditions, simplest to write is
IF NOT (condition1 OR condition2)
<statement>
END-IF

Though in my opinion, the meaning is even more plain with the equivalent
IF NOT condition1 AND NOT condition2

And generally, with n conditions, it's still more straightforward to write
IF NOT condition1 AND NOT condition2 AND NOT... AND NOT condition_n)
<statement>
END-IF

than to write
EVALUATE FALSE
WHEN (condition1 OR condition2 OR ... OR condition_n)
<statement>
WHEN OTHER
CONTINUE
END-EVALUATE

--
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-15, 6:55 pm

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:13c4k3lcdsh0093@news.supernews.com...
> Frank Swarbrick wrote:
>
> A similar thing happened to me. I once wrote a FORTRAN subroutine where
> each variable was a different number of dollar signs [i.e., $$$ =
> SQRT($$**2 + $$$$) ].
>
> A co-worker ("peer" in your example) expressed mild dissatisfaction with
> my style.
>
> I smashed the XXXXer in the mouth and moved on.

Quite right too...:-)

They can express dissatisfaction with your code, but never with your
style...

(That was the best laugh I had all day... thanks :-))

Pete.
--
"I used to write COBOL...now I can do anything."
>

SkippyPB

2007-08-15, 6:55 pm

On Tue, 14 Aug 2007 09:36:26 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>So I wrote some code yesterday using my wonderful new discovery of "evaluate
>false". Here's the logic.
>
> 05 MSC-ISS-COUNTRY PIC 9(03).
> 88 ISS-COUNTRY-IS-USA VALUE 840.
> 05 MSC-ACQ-STATE PIC X(02).
> 88 NON-US-SURCHG-ALLOWED VALUES 'CO' 'CA'.
>
>IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
>END-IF.
>
>

Others have commented on your use of FALSE. I would have no problem
understanding this code and its intent but if folks in your shop are,
then you may want to consider rewritting it. Doug gave you a IF NOT
statement. I always find those harder to follow, espcially if there
is an AND or OR in them, than what you wrote. Another thing, I follow
is to use EVALUATE only when there are more than two fields or values
to check. Thus, if it were me, I'd change the EVALUATE to
IF ISS-COUNTRY-IS-USA OR NON--US-SURCHG-ALLOWED
CONTINUE
ELSE
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
END-IF
..
..
..

But that's just me.

>During peer code review the reviewer asserted that this would not work as
>expected.
>I then asked him if he believe that the following two sets of code were the
>same as the first:
>
>IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> IF ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> CONTINUE
> ELSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-IF
>END-IF.
>
>
>IF ICR-COUNTRY-CODE IS NUMERIC
> MOVE ICR-COUNTRY-CODE TO MSC-ISS-COUNTRY
> MOVE STR-REGE-ST TO MSC-ACQ-STATE
> EVALUATE ISS-COUNTRY-IS-USA
> OR NON-US-SURCHG-ALLOWED
> WHEN TRUE
> CONTINUE
> WHEN FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> END-EVALUATE
>END-IF.
>
>He said he didn't believe so; that they were the same as each other but not
>the same as the original. When asking why, it turns out he interpreted the
>original kind of as the following:
>
>IF ISS-COUNTRY-USA IS FALSE OR NON-US-SURCHG-ALLOWED IS FALSE
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
>END-IF
>
>(Assume the above was valid Cobol, which of course it is not.)
>
>I set him straight on how it works (it evaluates the expression, getting a
>single true/false result, and then , but now my concern is that the original
>statement is not as 'obvious' as I had first hoped.
>
>(Of course there is the slight possibility that I am incorrect, but I did
>test what I believe to be all possible cases and got the results I was
>expecting.)
>
>Opinions?
>
>Frank
>
>

Regards,
////
(o o)
-oOO--(_)--OOo-

"I've had bad luck with both my wives.
The first one left me, and the second one didn't."
Patrick Murray
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

2007-08-15, 6:55 pm

In article <46C2C907.6F0F.0085.0@efirstbank.com>,
Frank Swarbrick <Frank.Swarbrick@efirstbank.com> wrote:
><docdwarf@panix.com> wrote:

[snip]
[color=darkred]
>
>I'd say that he's above average in potential but not yet in experience. As
>soon as I explained it he 'got' it. Which isn't to say it's a good idea,
>still.

Just trying to get my point across, that's all... sounds like I was
moderately close, too.

[snip]

>
>That is certainly an somewhat of an accurate assessment of why I did it. I
>keep hearing how some programmers can be

by 'negative logic'. So I
>tried to avoid it by, umm, using negative logic. :-)

'We had to destroy the village in order to save it'... there's a career in
politics for you, old boy.

>
>Still, the only way to learn if a particular construct is useful is to use
>it, yes?

No. It might be valuable to see 'useful' as one of those 'reified
concepts' I mentioned a while back in a posting on humor; that being a
given the result would be that there is no 'useful', only 'useful for'.
It is a construct one employs in order to accomplish an end or set of
ends.

>So while one should not shoehorn in usage of a construct just
>because they just learned it, on the other hand one should not eschew new
>constructs just because they (or others!) are not as familiar with them.
>Imagine a COBOL program who won't use those 'new-fangled' scope terminators.
> After all, you can get by without them!

Hmmmmm... that sounds kind of familiar... let's see...
<http://groups.google.com/group/comp...c7?dmode=source>

--begin quoted text:

'What is *this* stuff? EVALUATE TRUE WHEN cond-1 imperative statement...
you call this COBOL?!?'

'Oh, please, Mr Standards-and-Practises Reviewmeister, it is exactly what
is allowed by the ANSI '85 Standard.'

'ANSI '85? Crap, I *knew* things were goin' ta hell in a handbasket when
we allowed them fancy ANSI '74 constructs in a couple a' years back...
look, 1985 is only 14 years ago, we oughta wait until the technology is
Really Proven before we implement it. Go back and rewrite this in *real*
COBOL, then try again.'

--end quoted text

Granted that I wrote that in 1999... the trick, Mr Swarbrick, may be in
balancing what you want to do with what others are capable of handling.

DD

Frank Swarbrick

2007-08-15, 6:55 pm

>>> On 8/15/2007 at 12:30 AM, in message
<1187159411.738262.77160@e9g2000prf.googlegroups.com>,
Richard<riplin@Azonic.co.nz> wrote:
> On Aug 15, 3:36 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
> wrote:
> "evaluate
>
>
> I dislike 88 levels and don't use them.

That's certainly a point of view. :-)

The main reason I just 88 levels here is to make more clear what I am
testing for. (Though it's obvious by your misunderstanding below that
didn't quite work.

I could have, obviously, said

EVALUATE ICR-COUNTRY-CODE = 840
OR STR-REGE-ST = ('CA' OR 'CO')

But unless you happen to know that 840 is the country code for the U.S., you
may not *really* understand what that means.

Of course you could say....

77 MSC-USA-COUNTRY-CODE

EVALUATE ICR-COUNTRY-CODE = MSC-USA-COUNTRY-CODE
OR STR-REGE-ST = ('CA' OR 'CO')

With regard to the CA/CO 88 level, I like it because if we install an ATM in
another state that allows surcharging of non-U.S. cardholders then I can
simply add that state to the NON-US-SURCHG-ALLOWED 88 level, and I don't
have to change the code itself (or re-test!).

> I dislike building 'magic numbers' into program code and would have
> these items in a configuration file or in a database. Your programs
> may never need to be run outside of USA or even outside your site, but
> what if the states that allow surcharge (?) change. You then need to
> schedule maintenance, retesting, peer review, .. Oh well it ensures
> that you will have some work to do in the future.

Absolutely valid. In a perfect world I would have a table that contains all
of the 'exempt' states. If the card belongs to a non-U.S. cardholder and
the state is *not* in that table, then I would not surcharge.

However, said table does not exist, and I didn't feel the need to create it
for this project, which as is took be a minute to code and maybe 10 minutes
to test. If we were adding more and more states then yes, I would make it
more 'configuration driven'.

>
> It seems to me that CO and CA are actually states of the USA. So from
> a logical point of view you should be testing if the state is CO or CA
> only when the country _is_ the USA. Your test is true for any state in
> the USA or for the states of CA or CO in any country.
>
> Therefore it is only FALSE if the country is not America AND the state
> is not (CA or CO).
>
> That doesn't make sense.

Only you are misunderstanding the logic. The country refers to the country
where the card was issued. The state refers to the state where the
transaction was performed. Some examples:

Cardholder is a U.S. cardholder. We can charge a surcharge no matter what
state the ATM is located in.

Cardholder is not a U.S. cardholder. We can charge a surcharge only in a
state where there is a law saying that we can charge.

The default law is that we cannot charge a surcharge to a non-U.S.
cardholder. But a state can override that and say that we can. Colorado
and California are the two states in which we own ATMs where we can charge
non-U.S. cardholders. On the other hand, Arizona is a state in which we own
ATMs and we cannot charge non-U.S. customers. I could have made an 88-level
containing 'AZ' instead of 'CO' and 'CA', but since the default is that we
*can't* charge unless the state says we can I thought it would be safer to
err on not charging even when we could, rather than charging when we
shouldn't.

Now if we owned ATMs in other *countries* that would be a whole other kettle
of fish!

The old logic was simpler. All it said was if the cardholder country is
*not* 840, then do the logic to not surcharge. (The actual surcharge logic
is elsewhere, so this logic is used only to override the default, which is
to surcharge.)

I'm just grateful that there aren't additional rules, such as "you can only
surcharge on Mondays and Friday's and the fourth Sunday of the month. :-)

Frank

Frank Swarbrick

2007-08-15, 6:55 pm

>>> On 8/15/2007 at 1:10 AM, in message
<1187161805.201164.231550@x35g2000prf.googlegroups.com>,
Richard<riplin@Azonic.co.nz> wrote:
> On Aug 15, 3:36 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
> wrote:
> "evaluate
>
> did
>
> My testing had your evaluate as above except I had a WHEN TRUE
> displaying 'surcharge' and WHEN FALSE displaying 'no surcharge'
>
> 840CO SURCHARGE
> 840XX SURCHARGE
> 990CO SURCHARGE
> 990XX NO SURCHARGE
>
> What does the spec say you should be doing ?

That is correct. See my previous message for details on the actual 'spec'.

Frank

HeyBub

2007-08-15, 6:55 pm

Pete Dashwood wrote:
>
> Quite right too...:-)
>
> They can express dissatisfaction with your code, but never with your
> style...
>
> (That was the best laugh I had all day... thanks :-))
>

A programmers is much like a dentist: scientifically trained, but also
creative.

And, like an artist living in a garret in Greenwich Village (or the Left
Bank), a programmer is extremely defensive about his "creations." Programs
that don't work, never worked, and cannot be made to work, are often
protected against all depradations no matter how valid the complaint.

In fact, the most acceptance I've ever seen in this regard was:

"Well, I, uh, don't think it's quite fair to condemn a whole program because
of a single slip-up, sir."

Frank Swarbrick

2007-08-15, 9:56 pm

>>> On 8/15/2007 at 9:53 AM, in message
<jkFwi.58016$5j1.12539@newssvr21.news.prodigy.net>, Doug
Miller<spambait@milmac.com> wrote:
> In article <46C2C907.6F0F.0085.0@efirstbank.com>, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
>
>
> I think that, as written, it's *much* worse, because it's not at all
> clear
> whether the meaning of the conditional test is
>
> (unless iss_country_is_usa) or (non_us_surchg_allowed)
>
> -OR-
>
> unless (iss_country_is_usa or non_us_surchg_allowed)

I don't believe that the former would even work. That's like saying:
(IF NOT ISS-COUNTRY-IS-USA) OR (NON-US-SURCHG-ALLOWED)

....which doesn't even compile.
Or perhaps that's the point you were making?

I find the latter (w/ parentheses) as easy to read as the one without, but I
certainly can see where it might clarify things a bit.

While I do believe that parens can help to clarify, I also think they 'get
in the way' of adding additional conditions.

> Appropriately placed parentheses would, of course, remove the ambiguity.
>
> given
>
> Regardless of whether there are two conditions, one, or five hundred,
> it's
> still IMO unnecessarily confusing.
>
> With only one condition, the simplest way of encoding the logic is just
> IF NOT (condition)
> <statement>
> END-IF
>
> With two conditions, simplest to write is
> IF NOT (condition1 OR condition2)
> <statement>
> END-IF
>
> Though in my opinion, the meaning is even more plain with the equivalent
> IF NOT condition1 AND NOT condition2
>
> And generally, with n conditions, it's still more straightforward to
> write
> IF NOT condition1 AND NOT condition2 AND NOT... AND NOT condition_n)
> <statement>
> END-IF
>
> than to write
> EVALUATE FALSE
> WHEN (condition1 OR condition2 OR ... OR condition_n)
> <statement>
> WHEN OTHER
> CONTINUE
> END-EVALUATE

Well, I should point out that I did not endorse this last example, which I
don't think would work as desired anyway. Rather, I endorsed

EVALUATE (condition1 OR condition2 OR ... OR condition_n)
WHEN FALSE
<statement>
END-EVALUATE

In the end, if there was more than one NOT I still would lean toward
'positive logic'

IF condition_1
OR condition_2
OR condition_3
CONTINUE
ELSE
<statement>
END-IF

Or very likely
EVALUATE TRUE
WHEN condition_1
WHEN condition_2
WHEN condition_3
CONTINUE
ELSE
<statement>
END-IF

I'm still fairly certain I would never use EVALUATE FALSE under any
circumstance.

Frank

Doug Miller

2007-08-15, 9:56 pm

In article <46C317E7.6F0F.0085.0@efirstbank.com>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
><jkFwi.58016$5j1.12539@newssvr21.news.prodigy.net>, Doug
>Miller<spambait@milmac.com> wrote:
>
>I don't believe that the former would even work. That's like saying:
>(IF NOT ISS-COUNTRY-IS-USA) OR (NON-US-SURCHG-ALLOWED)

No, it's not. It's like saying
IF (NOT ISS-COUNTRY-IS-USA) OR (NON-US-SRCHG-ALLOWED)
>
>....which doesn't even compile.
>Or perhaps that's the point you were making?

No, the point is that (at least to a Cobol programmer) it's not clear whether
'unless' applies to the single condition immediately following it, or to the
compound condition created by the conjuction. Specifically, it's unclear
whether the construct
unless a or b
means
if (not a) or b
or
if not (a or b)
which are very, very different things. I'm pretty sure it must mean the
latter, because the former interpretation strikes me as silly -- but it's just
plausible enough to make the reader pause for a moment, and wonder what was
intended. Parentheses would remove the ambiguity, and with it my objections.
:-)

>I find the latter (w/ parentheses) as easy to read as the one without, but I
>certainly can see where it might clarify things a bit.
>
>While I do believe that parens can help to clarify, I also think they 'get
>in the way' of adding additional conditions.
>
>
>Well, I should point out that I did not endorse this last example, which I
>don't think would work as desired anyway. Rather, I endorsed
>
>EVALUATE (condition1 OR condition2 OR ... OR condition_n)
> WHEN FALSE
> <statement>
>END-EVALUATE
>
>In the end, if there was more than one NOT I still would lean toward
>'positive logic'
>
>IF condition_1
>OR condition_2
>OR condition_3
> CONTINUE
>ELSE
> <statement>
>END-IF
>
>Or very likely
>EVALUATE TRUE
>WHEN condition_1
>WHEN condition_2
>WHEN condition_3
> CONTINUE
>ELSE
> <statement>
>END-IF

I still think that

IF NOT condition-1
AND NOT condition-2
AND NOT condition-3
<statement>
END-IF

is the clearest way there is of expressing that idea.
>
>I'm still fairly certain I would never use EVALUATE FALSE under any
>circumstance.

Good idea. :-)

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

William M. Klein

2007-08-22, 6:55 pm

> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message[color=darkred]
> news:46C1779A.6F0F.0085.0@efirstbank.com...

I could be mistaken, but to me this would be clearer (if you WANT to use
EVALUATE) as:

Evaluate ISS-COUNTRY-IS-USA also NON-US-SURCHG-ALLOWED
When True Also True
Continue
When Other
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
End-Evaluate

***

Personally, I have always had to THINK HARD when I have negatives and OR or AND
(wehter EVALUATE FALSE or simple "not" relationals). I *can* do the Boolean
logic, but that doesn't mean that I "like" it.

--
Bill Klein
wmklein <at> ix.netcom.com

Frank Swarbrick

2007-08-22, 6:55 pm

>>> On 8/22/2007 at 2:51 PM, in message
<Pl1zi.268517$tb2.242808@fe02.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> "evaluate
>
> I could be mistaken, but to me this would be clearer (if you WANT to use
>
> EVALUATE) as:
>
> Evaluate ISS-COUNTRY-IS-USA also NON-US-SURCHG-ALLOWED
> When True Also True
> Continue
> When Other
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> End-Evaluate
>
> ***
>
> Personally, I have always had to THINK HARD when I have negatives and OR
> or AND
> (wehter EVALUATE FALSE or simple "not" relationals). I *can* do the
> Boolean
> logic, but that doesn't mean that I "like" it.

Well, if I were going to go that direction (not use negative logic) I'd
simply use EVALUATE TRUE and two WHEN clauses:

Evaluate True
When ISS-COUNTRY-IS-USA
When NON-US-SURCHG-ALLOWED
Continue
When Other
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
End-Evaluate

Which isn't to say that ALSO is not useful. Take the following real life
code:

EVALUATE WS-EDIT-BUS-FUNC ALSO TRUE
WHEN 'BTR' ALSO VALID-BTR-TYPE-CODE
WHEN 'CTR' ALSO VALID-CTR-TYPE-CODE
WHEN 'DRB' ALSO VALID-DRB-TYPE-CODE
WHEN 'DRC' ALSO VALID-DRC-TYPE-CODE
WHEN 'DRW' ALSO VALID-DRW-TYPE-CODE
WHEN 'SVC' ALSO VALID-SVC-TYPE-CODE
WHEN 'FGN' ALSO ANY
CONTINUE
WHEN OTHER
MOVE 'TYPE CD/BUS FUNC MISMATCH'
TO WIRM-MESSAGE-LINEO
MOVE -1 TO WIRM-BUS-FUNCL
GO TO 0100-SEND-MAPWIRM
END-EVALUATE.

Certainly there are other ways of doing it, but I think this is the
cleanest.

Frank

William M. Klein

2007-08-22, 6:55 pm

Frank,
That would be DIFFERENT logic.

"two whens" = OR (test if either is true)
"also" = AND (both must be true)

P.S. the "multiple WHEN" construct is - to me - the MOST confusing
(non-obvious) construct of EVALUATE

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46CC6896.6F0F.0085.0@efirstbank.com...
> <Pl1zi.268517$tb2.242808@fe02.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:
>
> Well, if I were going to go that direction (not use negative logic) I'd
> simply use EVALUATE TRUE and two WHEN clauses:
>
> Evaluate True
> When ISS-COUNTRY-IS-USA
> When NON-US-SURCHG-ALLOWED
> Continue
> When Other
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> End-Evaluate
>
> Which isn't to say that ALSO is not useful. Take the following real life
> code:
>
> EVALUATE WS-EDIT-BUS-FUNC ALSO TRUE
> WHEN 'BTR' ALSO VALID-BTR-TYPE-CODE
> WHEN 'CTR' ALSO VALID-CTR-TYPE-CODE
> WHEN 'DRB' ALSO VALID-DRB-TYPE-CODE
> WHEN 'DRC' ALSO VALID-DRC-TYPE-CODE
> WHEN 'DRW' ALSO VALID-DRW-TYPE-CODE
> WHEN 'SVC' ALSO VALID-SVC-TYPE-CODE
> WHEN 'FGN' ALSO ANY
> CONTINUE
> WHEN OTHER
> MOVE 'TYPE CD/BUS FUNC MISMATCH'
> TO WIRM-MESSAGE-LINEO
> MOVE -1 TO WIRM-BUS-FUNCL
> GO TO 0100-SEND-MAPWIRM
> END-EVALUATE.
>
> Certainly there are other ways of doing it, but I think this is the
> cleanest.
>
> Frank
>

Pete Dashwood

2007-08-23, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Pl1zi.268517$tb2.242808@fe02.news.easynews.com...
>
> I could be mistaken, but to me this would be clearer (if you WANT to use
> EVALUATE) as:
>
> Evaluate ISS-COUNTRY-IS-USA also NON-US-SURCHG-ALLOWED
> When True Also True
> Continue
> When Other
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> End-Evaluate
>
> ***
>
> Personally, I have always had to THINK HARD when I have negatives and OR
> or AND (wehter EVALUATE FALSE or simple "not" relationals). I *can* do
> the Boolean logic, but that doesn't mean that I "like" it.
>

Hopefully, some of the fun we've been having in the "regarding Evaluate
TRUE" thread might persuade you to change your mind :-)

Boole is

. :-)

It really is very enjoyable, Bill. And satisfying when you see the
result... :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2007-08-23, 3:55 am

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46CC6896.6F0F.0085.0@efirstbank.com...
> <Pl1zi.268517$tb2.242808@fe02.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:
>
> Well, if I were going to go that direction (not use negative logic) I'd
> simply use EVALUATE TRUE and two WHEN clauses:
>
> Evaluate True
> When ISS-COUNTRY-IS-USA
> When NON-US-SURCHG-ALLOWED
> Continue
> When Other
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> End-Evaluate
>
> Which isn't to say that ALSO is not useful. Take the following real life
> code:
>
> EVALUATE WS-EDIT-BUS-FUNC ALSO TRUE
> WHEN 'BTR' ALSO VALID-BTR-TYPE-CODE
> WHEN 'CTR' ALSO VALID-CTR-TYPE-CODE
> WHEN 'DRB' ALSO VALID-DRB-TYPE-CODE
> WHEN 'DRC' ALSO VALID-DRC-TYPE-CODE
> WHEN 'DRW' ALSO VALID-DRW-TYPE-CODE
> WHEN 'SVC' ALSO VALID-SVC-TYPE-CODE
> WHEN 'FGN' ALSO ANY
> CONTINUE
> WHEN OTHER
> MOVE 'TYPE CD/BUS FUNC MISMATCH'
> TO WIRM-MESSAGE-LINEO
> MOVE -1 TO WIRM-BUS-FUNCL
> GO TO 0100-SEND-MAPWIRM
> END-EVALUATE.
>
> Certainly there are other ways of doing it, but I think this is the
> cleanest.
>

Hmmm...when first looked at this this, I didn't like it, but it has grown
on me... :-)

I can't warm to use of CONTINUE and WHEN OTHER but I see why you are using
them.

IF NOT ((WS-EDIT-BUS-FUNC = "BTR" AND VALID-BTR-TYPE-CODE) OR
(WS-EDIT-BUS-FUNC = "CTR" AND VALID-CTR-TYPE-CODE) OR
(WS-EDIT-BUS-FUNC = "DRB" AND VALID-DTR-TYPE-CODE) OR
(WS-EDIT-BUS-FUNC = "DRC" AND VALID-DRC-TYPE-CODE) OR
(WS-EDIT-BUS-FUNC = "DRW" AND VALID-DRW-TYPE-CODE) OR
(WS-EDIT-BUS-FUNC = "SVC" AND VALID-SVC-TYPE-CODE) OR
(WS-EDIT-BUS-FUNC = "FGN" ))
MOVE 'TYPE CD/BUS FUNC MISMATCH'
TO WIRM-MESSAGE-LINEO
MOVE -1 TO WIRM-BUS-FUNCL
GO TO 0100-SEND-MAPWIRM
END-IF

....seems just as "clean" to me, requires no knowledge of EVALUATE's obscure
ALSO function, and it is fewer lines of code :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Michael Mattias

2007-08-23, 9:55 pm

> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message[color=darkred]
> news:Pl1zi.268517$tb2.242808@fe02.news.easynews.com...

That's something I have learned, too. Even when you don't have NOT in the
condition, a test for TRUE is a heck of lot easier to convert into a
compound condition when - as is inevitable - the business rules change.

MCM

Frank Swarbrick

2007-08-23, 9:55 pm

>>> On 8/22/2007 at 4:59 PM, in message
<Ed3zi.122589$sR4.26226@fe08.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> Frank,
> That would be DIFFERENT logic.
>
> "two whens" = OR (test if either is true)
> "also" = AND (both must be true)
>
> P.S. the "multiple WHEN" construct is - to me - the MOST confusing
> (non-obvious) construct of EVALUATE

Hmm, you're right. Except that I think your original logic would *not* do
what I want it to do. The logic to turn off the surcharge should be
performed only if the card issuing country is non-U.S. and the transaction
acquiring state is does not allow surcharging of non-U.S. cardholders. The
way you have it, if it's a US cardholder and charging of non-US cardholders
is not allowed then that customer would not be charged. Which is not
correct.

To be honest, I think the following makes it even more clear:

evaluate true
when US-cardholder
when not US-cardholder and non-US-cardholder-surcharge-is-allowed
continue
when other
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
end-evaluate

Or, of course

if US-cardholder
or (not US-cardholder and non-US-cardholder-surcharge-is-allowed)
continue
else
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
end-if

The only reason I didn't use one of those is for the silly reason that I try
to check a field for a certain value only once, and this one can check the
US-cardholder 88-level twice.

These two actually seem to me to be most clear from a 'business rules' point
of view.

Of course there's always this.

if not US-cardholder
if not non-US-cardholder-surcharge-is-allowed
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
end-if
end-if

But then we're back to the most common suggestion
if not US-cardholder and not non-US-cardholder-surcharge-is-allowed
MOVE ZERO TO STR-SURCHG-AMT
MOVE 'N' TO STR-SURCHG-FLAG
end-if

Ironic! :-)

Frank

Frank Swarbrick

2007-08-23, 9:55 pm

>>> On 8/22/2007 at 7:04 PM, in message
<5j44o8F3s52sjU1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:

> "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
> news:46CC6896.6F0F.0085.0@efirstbank.com...
use[color=darkred]
OR[color=darkred]
> life
>
> Hmmm...when first looked at this this, I didn't like it, but it has
> grown
> on me... :-)

Cool! :-)

> I can't warm to use of CONTINUE and WHEN OTHER but I see why you are
> using
> them.
>
> IF NOT ((WS-EDIT-BUS-FUNC = "BTR" AND VALID-BTR-TYPE-CODE) OR
> (WS-EDIT-BUS-FUNC = "CTR" AND VALID-CTR-TYPE-CODE) OR
> (WS-EDIT-BUS-FUNC = "DRB" AND VALID-DTR-TYPE-CODE) OR
> (WS-EDIT-BUS-FUNC = "DRC" AND VALID-DRC-TYPE-CODE) OR
> (WS-EDIT-BUS-FUNC = "DRW" AND VALID-DRW-TYPE-CODE) OR
> (WS-EDIT-BUS-FUNC = "SVC" AND VALID-SVC-TYPE-CODE) OR
> (WS-EDIT-BUS-FUNC = "FGN" ))
> MOVE 'TYPE CD/BUS FUNC MISMATCH'
> TO WIRM-MESSAGE-LINEO
> MOVE -1 TO WIRM-BUS-FUNCL
> GO TO 0100-SEND-MAPWIRM
> END-IF
>
> ...seems just as "clean" to me, requires no knowledge of EVALUATE's
> obscure
> ALSO function, and it is fewer lines of code :-)

I still like my way better. :-)

Frank

Pete Dashwood

2007-08-23, 9:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46CD54E8.6F0F.0085.0@efirstbank.com...
> <5j44o8F3s52sjU1@mid.individual.net>,
> Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
>
> use
> OR
>
> Cool! :-)
>
>
> I still like my way better. :-)

Then that is reason enough to do it your way.

However, don't justify it with claims of cleanliness. Doing that opens your
method to debate. I claim the approach I posted above is "cleaner" for the
reasons stated, but that doesn't mean it is "better". We all use what we
are comfortable with.

Just say: "I like it this way." No dubious justification required. :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Richard

2007-08-23, 9:55 pm

On Aug 24, 3:29 am, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
wrote:
>
> <Ed3zi.122589$sR4.26...@fe08.news.easynews.com>, William M.
>
> Klein<wmkl...@nospam.netcom.com> wrote:
>
>
>
> Hmm, you're right. Except that I think your original logic would *not* do
> what I want it to do. The logic to turn off the surcharge should be
> performed only if the card issuing country is non-U.S. and the transaction
> acquiring state is does not allow surcharging of non-U.S. cardholders. The
> way you have it, if it's a US cardholder and charging of non-US cardholders
> is not allowed then that customer would not be charged. Which is not
> correct.

Of course if you had put in the actual specification at the start then
there would have been no 'misunderstanding' about the non-relationship
between country and state.

>
> To be honest, I think the following makes it even more clear:
>
> evaluate true
> when US-cardholder
> when not US-cardholder and non-US-cardholder-surcharge-is-allowed
> continue
> when other
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> end-evaluate

I can never remember if that means "not ( a and b )" or "(not a) and
b" so I always use parentheses and then I no longer care which it is
or whether I can remember or not.

> Or, of course
>
> if US-cardholder
> or (not US-cardholder and non-US-cardholder-surcharge-is-allowed)
> continue
> else
> MOVE ZERO TO STR-SURCHG-AMT
> MOVE 'N' TO STR-SURCHG-FLAG
> end-if

Howard Brazee

2007-08-24, 6:55 pm

On Thu, 23 Aug 2007 19:08:45 -0700, Richard <riplin@Azonic.co.nz>
wrote:

>I can never remember if that means "not ( a and b )" or "(not a) and
>b" so I always use parentheses and then I no longer care which it is
>or whether I can remember or not.

And you make sure that anybody maintaining your code knew that what
you coded was what you meant.

Sponsored Links