Simplifying IFs in COBOL

[pete dashwood]

I had occasion to talk to someone who is currently maintaining some
legacy COBOL. She is not a COBOL programmer, but she is a very competent
programmer and is doing her best with gaining enough knowledge of COBOL
to be able to maintain it.

(I was reminded of myself when young; fresh off the COBOL course (1967),
dying to get into writing some production code, and being given a report
program to change... My Boss was very old and wise and knew better than
to let me write something new and important... :-))

Anyway, the comment this lady made was: "I thought COBOL was supposed to
be readable... look at all these IFs..."

She produced a source that had a sprinkling of GO TOs in it and a number
of nested IFs, one of which covered nearly 4 pages of A4...

She asked if I had any tips that might help, so I gave her the
following... (I reproduce them here in case they could be useful to
anyone else in the same situation...) :

1. Recognize the difference between a COMPOUND conditional and a NESTED
conditional.

2. Use NESTED conditionals to describe condition TREEs (A condition tree
(for these purposes) being a structure that has a series of dependent
conditions) and DON'T nest further IFs into the FALSE branches of your
tree.

(Yes, you CAN do it, but it is really not helpful to people who may not
be as brilliant as you are...)

IF c1
IF c2 *> check c2 ONLY if c1 is true...
IF c3 *> check c3 ONLY if c1 AND c2 are true...
(It is tempting for newbies to write this as a COMPOUND condition: IF C1
AND C2 AND c3 ... resist this temptation UNLESS there is only ONE
possible action to be activated...)
... more nested IFs here...(if required)
ACTION to be done if c1, c2, and c3, are ALL true, goes here...
NO MORE nested IFs after the following ELSE (use PERFORM or CALL to
reference a separate block of code (if the actions are substantial), and
put your conditional test in THAT block...)
ELSE
ACTION if c1 and c2 are true BUT c3 is false...
ELSE
ACTION if c1 is true BUT c2 is false...
ELSE
ACTION if c1 is false...

3. Complex COMPOUND conditions can usually be simplified using Boolean
Algebra and Propositional Calculus. Sometimes the results of doing this
are quite amazing. You don't need to be a Maths whiz (I'm definitely
not...) to learn the simple rules of Association, Distribution, and
Commutation along with the use of additive and multiplicative identity,
(which apply to all algebras, including George Boole's) and De Morgan,
which is Boolean Algebra-specific. If you enjoy doing puzzles, you will
almost certainly enjoy unravelling twisted COBOL compound conditions,
converting them to symbolic form, simplifying the symbols and deriving a
new condition that covers all the cases that the previous one covered,
but in a fraction of the space. It's fun and extremely satisfying to
know that your final conditional test is mathematically pure and as
simple as it can possibly be.

Finally,

there is a spin-off from the above, in that the rules and tools outlined
will work in ANY language that supports IF, ELSE, AND, OR, and NOT...

Oh, and once she had the concepts above, the lady concerned started
drawing boxes around blocks of code that were governed by specific
IF/ELSE, and de-composing all the "noise" into manageable chunks.

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

[George McGinn]

Why not use the EVALUATE TRUE statement?

Or is the COBOL she is working with pre COBOL-II?

George.

[pete dashwood]

On 7/02/2017 11:44 p.m., George McGinn wrote:
> Why not use the EVALUATE TRUE statement?
>
> Or is the COBOL she is working with pre COBOL-II?
>
> George.
>
> On Monday, February 6, 2017 at 11:19:24 PM UTC-5, pete dashwood wrote:

<snipped>
>
EVALUATE is a good option and way better than its predecessor (GO TO...
DEPENDING ON...)

But it serves a different purpose from what is being discussed here.

EVALUATE was added to COBOL so that it would have an equivalent to the
SWITCH and CASE functionality in other languages.

If you use EVALUATE TRUE [ ALSO TRUE...] all you are really doing is
providing a framework for the IFs you still have to write (except that
now they are WHENs...). It may make things a bit more readable (in terms
of the layout) but it is adding more words, and that's something that is
best avoided... (IMO)

Personally, I seldom use EVALUATE TRUE. (I DO use EVALUATE <dataname>
when there are a number of specific actions for the discrete values of a
single variable.

The point of the post was about simplifying IFs, not replacing them with
something else... :-) (The significance of when and how to use nested
IFs was what I primarily wanted to address...)

Nevertheless, I agree with your point that sometimes we should use
EVALUATE rather than IF, in the first place.

[Charles Hottel]

"pete dashwood" <dash...@enternet.co.nz> wrote in message
news:eft06a...@mid.individual.net...

There are several different styles for coding nested IF statements. In "The
C programming Language" by Kernighan and Ritchie the following style is
recommended:

if (condition)
statement
else if (condition)
statement
else
statement

Of course the conditions and statements can be compound.. This is
essentally a multi-way decision. You can read the code from top until some
condition is staisfied and the corresponding statement is executed, and the
entire construction is finished. If none of the conditions is satified the
statement after the final else is executed if it is present. If the final
else and statement is omitted, no action takes place. Formatting in this
way ensures that long decisions do not march off the right side of the page.

[docd...@panix.com]

In article <efvcs4...@mid.individual.net>,
pete dashwood <dash...@enternet.co.nz> wrote:

[snip]

>The point of the post was about simplifying IFs, not replacing them with
>something else... :-)

If the code represents a set of decisions that are sloppy,
cobbled-together and have grown organically over centuries (eg, insurance
regulations) then expecting the code to be otherwise structured might lead
to disappointment.

Most often, in my experience, a statement about simplifying logical
structures in code is usually prefaced with 'Now, I'm Technical but it
seems like all ya gotta do is...' and accompanied by a lack of budget,
resources and testing.

DD

[Richard]

On Wednesday, February 8, 2017 at 3:08:07 PM UTC+13, pete dashwood wrote:

> EVALUATE is a good option and way better than its predecessor (GO TO...
> DEPENDING ON...)

GO TO DEPENDING ON is a completely different purpose than EVALUATE.

> But it serves a different purpose from what is being discussed here.
>
> EVALUATE was added to COBOL so that it would have an equivalent to the
> SWITCH and CASE functionality in other languages.

EVALUATE may be used as a switch..case but it has far more functionality.

> If you use EVALUATE TRUE [ ALSO TRUE...] all you are really doing is
> providing a framework for the IFs you still have to write (except that
> now they are WHENs...). It may make things a bit more readable (in terms
> of the layout) but it is adding more words, and that's something that is
> best avoided... (IMO)

'WHEN' is fewer words than 'ELSE IF'.

EVALUATE can be used as a decision table. In the early 70s I did use decision tables directly in source code and put the source through a pre-processor as part of the compile cycle. The program spec had the tables so putting these directly in the code meant any flaws could be blamed on the spec, not on my coding!!

With EVALUATE there is no need to pre-process.

>The point of the post was about simplifying IFs, not replacing them with
> something else... :-)

It seemed to me that the problem was exactly what decision tables are for.

[Bill Woodger]

Hi Pete,

Can you provide an example of the compound IF thing you are talking about? With realistic names (maybe ask the lady in (the) question to provide a lump of code).

I know we did this before, on LinkedIn, but I didn't really get it :-)

Is there much use in saying how to write pre-COBOL 85 nested IFs? Or does END-IF fall under your "too much typing, not good for you, even if it makes it clearer"?

In general I'm mightily surprised at the idea of someone doing maintenance fiddling with anything not directly within their spec for the change. I've never had a manager happy with "yes, make lots of changes, spend some time on it, extra testing (where "regression tests" are lacking) and then have it do exactly the same thing as it was doing before. I'm happy to sign-off on that".

Understand it, yes. Document it, yes. Change it? No.

EVALUATE data-name? Maintenance rats-nest. Analyst looking up from document: "Find me all the programs that use the literal one, and confirm whether any of them are related to ageing-method," reads further, "oh, and the letter A if it is related to warehouse stacking," and then "oh, and the letter A if it is related to transport origin".

It is ironic that many "structured things" now in COBOL allow garbage that you'd not have got away with in the 80s, but now the defence is simple - "it's OK, I'm using a Structured Construct".

[pete dashwood]

Charlie,

the above in NO WAY represents the decision TREE structure that I would
use a truly NESTED IF for. In fact, I don't recognise the above as a
NESTED IF at all, (but that is probably because I ONLY use NESTED IFs
for decision trees...)

For COBOL, you could replace every ELSE in the above with a full stop
(period) and get exactly the same result.

You CAN'T do that with a TREE (truly NESTED IF), and that was my point.

I could clarify the whole thing if I could draw a picture, but this is a
text based forum. I'll make sure the new PRIMA 21 site describes it better.

Cheers,

[pete dashwood]

On 9/02/2017 2:22 p.m., Richard wrote:
> On Wednesday, February 8, 2017 at 3:08:07 PM UTC+13, pete dashwood wrote:
>
>> EVALUATE is a good option and way better than its predecessor (GO TO...
>> DEPENDING ON...)
>
> GO TO DEPENDING ON is a completely different purpose than EVALUATE.

Not COMPLETELY. EVALUATE <dataname> <WHEN list> serves pretty much the
same purpose as GO TO <List> DEPENDING ON <dataname>; namely, transfer
control to a list of locations, depending on the contents of a given
variable.

Before EVALUATE, the nearest thing (apart from IF itself) was GO TO...
DEPENDING ON.

>
>> But it serves a different purpose from what is being discussed here.
>>
>> EVALUATE was added to COBOL so that it would have an equivalent to the
>> SWITCH and CASE functionality in other languages.
>
> EVALUATE may be used as a switch..case but it has far more functionality.
>

Could you show an example of EVALUATE, that DOESN'T use TRUE, and is not
actually a SWITCH... CASE equivalent? I can't think of any, but that
may be because I limit the way I use EVALUATE.

>
>> If you use EVALUATE TRUE [ ALSO TRUE...] all you are really doing is
>> providing a framework for the IFs you still have to write (except that
>> now they are WHENs...). It may make things a bit more readable (in terms
>> of the layout) but it is adding more words, and that's something that is
>> best avoided... (IMO)
>
> 'WHEN' is fewer words than 'ELSE IF'.

I wouldn't write "ELSE IF" into an EVALUATE, so it isn't for me...

>
> EVALUATE can be used as a decision table. In the early 70s I did use decision tables directly in source code and put the source through a pre-processor as part of the compile cycle. The program spec had the tables so putting these directly in the code meant any flaws could be blamed on the spec, not on my coding!!
>
> With EVALUATE there is no need to pre-process.

Yes, I remember the popularity of decision tables and I agree they could
be very useful. I believe the late Jimmy Gavan who posted here for many
years was a big fan and posted some very good examples.

>
>> The point of the post was about simplifying IFs, not replacing them with
>> something else... :-)
>
> It seemed to me that the problem was exactly what decision tables are for.
>

It is certainly true that decision tables can simplify complex compound
IFs in much the way I mentioned using boolean Algebra.

[pete dashwood]

On 9/02/2017 11:30 p.m., Bill Woodger wrote:
> Hi Pete,
>
> Can you provide an example of the compound IF thing you are talking about? With realistic names (maybe ask the lady in (the) question to provide a lump of code).

For privacy reasons I wouldn't post any of the code concerned, but I
think I can come up with a realistic simplification of a real-world
commercial process.

Consider the case where it is required to translate numbers printed on a
cheque into words. Pretty easy you'd think... build a list of
numbers/words, parse each digit in the amount and construct your cheque
line...

so, e.g:

10.00 = TEN DOLLARS EXACTLY
21.45 = TWENTY-ONE DOLLARS AND FORTY-FIVE CENTS

Pretty straightforward. You have to juggle the words MILLION, THOUSAND,
HUNDRED, DOLLARS, AND, CENTS, and EXACTLY

7,654,321.99 = SEVEN MILLION SIX HUNDRED AND FIFY-FOUR THOUSAND THREE
HUNDRED AND TWENTY-ONE DOLLARS AND NINETY-NINE CENTS

If you actually sit down and write some code to do this (I haven't time
at the moment but if anybody else posts code here I'll make time...),
you will realise that the trickiest bit is setting the ANDs in the right
place... you start making rules, something like:

(This is a trivial example, but I don't have the time to create a much
more complex one and the rules below could be much more plentiful and
involve more variables if a less experienced programmer were formulating
them.)

1. If there is a positive number to the right of the point, there must
be an AND before that number, but only if there is a positive number to
the left of the point.
2. The word AND must follow the word HUNDRED, but only if there is a
positive number between the digit preceding HUNDRED, and the point.
3. The word AND must follow the word DOLLAR(S), but only if there is a
positive number to the right of the point.

We could code this from the rules above:

IF POINT-RIGHT IS POSITIVE AND POINT-LEFT IS POSITIVE
OR
CURRENT-WORD-HUNDRED AND POINT-LEFT IS POSITIVE
OR
CURRENT-WORD-DOLLAR OR CURRENT-WORD-DOLLARS AND POINT-RIGHT IS POSITIVE
<then string the word AND into the cheque line...>

But something tells us this is not as good as it could be, so convert it
to symbolic logic and mess with it using Boolean Algebra...

(Read ^ as AND and + as OR... I deliberately contrived to keep NOT out
of it for the sake of this simple example...)

1 = PR ^ PL
2 = WH ^ PL
3 = WD ^ PR

Applying simplification by Boolean Algebra:

(PL ^ (PR + WH)) + (PR ^ WD)

So the simplified expression is:


IF (POINT-LEFT IS POSITIVE AND
(POINT-RIGHT IS POSITIVE OR
CURRENT-WORD-HUNDRED) OR
(POINT-RIGHT IS POSITIVE AND
CURRENT-WORD-DOLLAR OR
CURRENT-WORD-DOLLARS))
<then string the word AND into the cheque line...>

I realize it is not a dramatic example but, hopefully, you'll catch my
drift...(The previous 7 tests have been reduced to 6; I had one example
many years ago where I was able to reduce 24 compound conditions down to
8. Results CAN be dramatic.)

>
> I know we did this before, on LinkedIn, but I didn't really get it :-)

I don't remember "doing it on LinkedIN" (although I don't doubt you
because it is something I have a strong interest in) and I'm too tired
at the moment to go and look... :-)

>
> Is there much use in saying how to write pre-COBOL 85 nested IFs?

Unfortunately, the point I was trying to make seems to have been
generally missed. "DON'T USE NESTED IFs UNLESS you are describing a TREE
structure, and then ONLY nest into the POSITIVE branches." It is as
valid and true in 2017 as it was in 1967. Using EVALUATE is NOT
addressing a TREE structure, unless you use EVALUATE TRUE... ALSO TRUE
(which I personally don't.)

Remember, I made the post because I was asked my opinion. I'm not
suggesting what I posted is the ONLY way; all I'm saying is that it
works for me... If other people get some use from it, great; if not
then, I may have wasted some time. At least my opinion is now
documented. :-) The person who asked me felt she got something of value
from the exchange.

Or does END-IF fall under your "too much typing, not good for you,
even if it makes it clearer"?

For me, END-IF is another scope delimiter and, as such, it is priceless.
I ALWAYS use scope delimiters so I ALWAYS use END-IF. One of the first
machines I ever wrote COBOL for was an ICL 1901 which had a barrel
printer and it was notoriously hard to distinguish commas, full stops,
and smudges on the paper. Scope delimiters were a much-needed blessing
and we embraced them.

>
> In general I'm mightily surprised at the idea of someone doing maintenance fiddling with anything not directly within their spec for the change. I've never had a manager happy with "yes, make lots of changes, spend some time on it, extra testing (where "regression tests" are lacking) and then have it do exactly the same thing as it was doing before. I'm happy to sign-off on that".
>
> Understand it, yes. Document it, yes. Change it? No.

In smaller companies the lines are more blurred. The person concerned
with this has a stake in the company. The "spec" is to make it work
slightly differently than it currently does and she has a vested
interest in making it so.

>
> EVALUATE data-name? Maintenance rats-nest. Analyst looking up from document: "Find me all the programs that use the literal one, and confirm whether any of them are related to ageing-method," reads further, "oh, and the letter A if it is related to warehouse stacking," and then "oh, and the letter A if it is related to transport origin".

Any good cross reference/search/editor should kill that, whether the
code is structured or not. I don't see how EVALUATE dataname makes it
any more difficult.

>
> It is ironic that many "structured things" now in COBOL allow garbage that you'd not have got away with in the 80s, but now the defence is simple - "it's OK, I'm using a Structured Construct".
>

Bad code, like the poor, is always with us. When approaching the problem
of skinning cats it is good to have many knives and many ways to do it.

Thanks for your post, Bill.

[docd...@panix.com]

In article <egb38v...@mid.individual.net>,

pete dashwood <dash...@enternet.co.nz> wrote:
>On 9/02/2017 2:22 p.m., Richard wrote:
>> On Wednesday, February 8, 2017 at 3:08:07 PM UTC+13, pete dashwood wrote:
>>
>>> EVALUATE is a good option and way better than its predecessor (GO TO...
>>> DEPENDING ON...)
>>
>> GO TO DEPENDING ON is a completely different purpose than EVALUATE.
>
>Not COMPLETELY. EVALUATE <dataname> <WHEN list> serves pretty much the
>same purpose as GO TO <List> DEPENDING ON <dataname>; namely, transfer
>control to a list of locations, depending on the contents of a given
>variable.

Your statement might be more true, Mr Dashwood, were the transfer of
control always irretrievable from the instruction invoking it and all
variables numeric.

Since the transfer of control invoked in a PERFORM is retrievable and all
variables aren't numeric... then your statement seems less true.

DD

[Richard]

On Monday, February 13, 2017 at 1:37:52 AM UTC+13, pete dashwood wrote:
> On 9/02/2017 2:22 p.m., Richard wrote:
> > On Wednesday, February 8, 2017 at 3:08:07 PM UTC+13, pete dashwood wrote:
> >
> >> EVALUATE is a good option and way better than its predecessor (GO TO...
> >> DEPENDING ON...)
> >
> > GO TO DEPENDING ON is a completely different purpose than EVALUATE.
>
> Not COMPLETELY. EVALUATE <dataname> <WHEN list> serves pretty much the
> same purpose as GO TO <List> DEPENDING ON <dataname>; namely, transfer
> control to a list of locations, depending on the contents of a given
> variable.

Yes, EVALUATE can be used to emulate a GO TO DEPENDING ON (GTDO):

GO TO A B C DEPENDING ON X

EVALUATE X
WHEN 1 GO A
WHEN 2 GO B
WHEN 3 GO C
END-EVALUATE

You could also move the contents of A, B and C into the WHEN (which creates a different purpose compared to GTDO.

> Before EVALUATE, the nearest thing (apart from IF itself) was GO TO...
> DEPENDING ON.

Before EVALUATE the nearest thing _was_ IF itself (specifically IF .. ELSE IF .. ELSE IF ...). Your qualification removing the actual nearest thing merely shows how GTDO is completely _not_ "the nearest thing".

> >> But it serves a different purpose from what is being discussed here.
> >>
> >> EVALUATE was added to COBOL so that it would have an equivalent to the
> >> SWITCH and CASE functionality in other languages.
> >
> > EVALUATE may be used as a switch..case but it has far more functionality.
> >
>
> Could you show an example of EVALUATE, that DOESN'T use TRUE, and is not
> actually a SWITCH... CASE equivalent? I can't think of any, but that
> may be because I limit the way I use EVALUATE.

Again, you add a qualification to detract from the truth of the matter. A 'switch .. case' usually only allows a numeric selector, and only a single one. EVALUATE variable can be of _any_ type (including TRUE/FALSE), and can have several variables using ALSO. 'switch case' also drops through from one case to another unless there is a 'break', EVALUATE only does this by concatenation of WHENs. So, no, EVALUATE is not _equivalent_ to 'switch case', there are many differences in semantics even if there is a similar appearance and EVALUATE can be made to emulate the other.

EVALUATE was implemented to be able to directly code decision tables. Simplistic, subset usage of it may be used to emulate several different, simpler control structures, but that does not restrict it to those.

> >> If you use EVALUATE TRUE [ ALSO TRUE...] all you are really doing is
> >> providing a framework for the IFs you still have to write (except that
> >> now they are WHENs...). It may make things a bit more readable (in terms
> >> of the layout) but it is adding more words, and that's something that is
> >> best avoided... (IMO)
> >
> > 'WHEN' is fewer words than 'ELSE IF'.
>
> I wouldn't write "ELSE IF" into an EVALUATE, so it isn't for me...

Your point was that "more words .. is best avoided" in the context implying that an EVALUATE would have more words than an equivalent IF .. ELSE IF .. ELSE IF.

In fact the reverse may be true: EVALUATE TRUE WHEN .. WHEN .. END-EVALUATE may have fewer words than IF .. ELSE IF .. END-IF END-IF (5 vs 6).

> >
> > EVALUATE can be used as a decision table. In the early 70s I did use decision tables directly in source code and put the source through a pre-processor as part of the compile cycle. The program spec had the tables so putting these directly in the code meant any flaws could be blamed on the spec, not on my coding!!
> >
> > With EVALUATE there is no need to pre-process.
>
> Yes, I remember the popularity of decision tables and I agree they could
> be very useful. I believe the late Jimmy Gavan who posted here for many
> years was a big fan and posted some very good examples.

Decision table pre-processors were virtually made obsolete by EVALUATE, though the coding styles can be be somewhat different.

[Bill Woodger]

Thanks Pete. I see what you mean now. I've not come across a lot of code like that, but it certainly doesn't help get things across.

Privacy is easy. Just change the names to protect the innocent.

As has been said, switch/select/evaluate prior to the existence of EVALUATE is exactly the "other half" of the suggestion you make.

IF condition-1-on-field
do something-1
ELSE
IF condition-2-on-field
do something-2
ELSE
IF condition-3-on-field
do something-3
ELSE
IF condition-4-on-field
do something=4
ELSE
do something else.

This is a "vertical nested-IF", where conditions must be mutually exclusive (not cumulative).

Which doesn't detract from your point otherwise. If you make nested-IFs complicated, it can cause unnecessary trouble.

With END-IF, a third type of nested-IF arrives. Easily abstracted-out to the original, unless some... person... puts a GO TO in the embedded-IF. You can't put a GO TO in a "classic nested-IF" (at least not if you want it all to work).

When I started, it was explained to me that literals in the PROCEDURE DIVISION were not good: there's more meaning available in a condition-name; not all +1s are created equal (by which I mean, they may all mean one, but only in places where the intention is also one, rather than item-out-of-stock, should they actually appear to be equivalent).

EVALUATE data-name not only encourages literals in the PROCEDURE DIVISION, it forces the use of them.

Toss in the new "EXIT" formats, secret GO TOs, to arrive at points without obvious labels, data-names like I, J and K (and, if you remember, not what they may be expected to be for (from their FORTRAN roots), and hey-ho, we're back in the late 60s - except with "structure".

Now, don't jump and think I don't like scope-terminators. Although some are appalling misnomers when describing what they terminate.

[Bill Woodger]

Richard, do you have some reference for the intention of EVALUATE being to implement Decision Tables?

I've never seen them used for that, unless you count a rudimentary EVALUATE with an ALSO. For me, the strength of Decision Tables was their tabular representation of effect between condition/action. Can you do that with EVALUATE?

Their weakness was, writing sensible code was not inherent with the use of Decision Tables.

What perhaps I have to thank DTs for (as well as thank some people) is leading to minimal use of connected conditions and multiple use of "action-only" tables, which aided me with the COBOL-only programs I was also writing and maintaining at the times. By the time I was using Decision Tables to their best, I didn't need to use Decision Tables.

Does that mean DTs were a good "learning tool"? No, they could be as abused as ordinary COBOL by those who don't care.

case/select/evaluate/switch, the details differ, but there's not much interest in arguing over them from one language to another.

[Rick Smith]

On Sunday, February 12, 2017 at 3:50:21 PM UTC-5, Bill Woodger wrote:
> Richard, do you have some reference for the intention of EVALUATE being to implement Decision Tables?

< https://www.computer.org/csdl/proceedings/afips/1978/5086/00/50861099.pdf >
8 pages. This quote appears on PDF page 6, second column, near the top.

"The EVALUATE statement, which is much too complex
for the scope of this paper, represents CODASYL's answer
to the CASE construct in structured programming. The
EVALUATE statement can also be used to express a decision
table in a COBOL format."

[pete dashwood]

On 13/02/2017 7:58 a.m., Richard wrote:
> On Monday, February 13, 2017 at 1:37:52 AM UTC+13, pete dashwood wrote:
>> On 9/02/2017 2:22 p.m., Richard wrote:
>>> On Wednesday, February 8, 2017 at 3:08:07 PM UTC+13, pete dashwood wrote:
>>>
>>>> EVALUATE is a good option and way better than its predecessor (GO TO...
>>>> DEPENDING ON...)
>>>
>>> GO TO DEPENDING ON is a completely different purpose than EVALUATE.
>>
>> Not COMPLETELY. EVALUATE <dataname> <WHEN list> serves pretty much the
>> same purpose as GO TO <List> DEPENDING ON <dataname>; namely, transfer
>> control to a list of locations, depending on the contents of a given
>> variable.
>
> Yes, EVALUATE can be used to emulate a GO TO DEPENDING ON (GTDO):
>
> GO TO A B C DEPENDING ON X
>
> EVALUATE X
> WHEN 1 GO A
> WHEN 2 GO B
> WHEN 3 GO C
> END-EVALUATE
>
> You could also move the contents of A, B and C into the WHEN (which creates a different purpose compared to GTDO.
>
>> Before EVALUATE, the nearest thing (apart from IF itself) was GO TO...
>> DEPENDING ON.
>
> Before EVALUATE the nearest thing _was_ IF itself (specifically IF .. ELSE IF .. ELSE IF ...). Your qualification removing the actual nearest thing merely shows how GTDO is completely _not_ "the nearest thing".

OK :-)

>
>
>>>> But it serves a different purpose from what is being discussed here.
>>>>
>>>> EVALUATE was added to COBOL so that it would have an equivalent to the
>>>> SWITCH and CASE functionality in other languages.
>>>
>>> EVALUATE may be used as a switch..case but it has far more functionality.
>>>
>>
>> Could you show an example of EVALUATE, that DOESN'T use TRUE, and is not
>> actually a SWITCH... CASE equivalent? I can't think of any, but that
>> may be because I limit the way I use EVALUATE.
>
> Again, you add a qualification to detract from the truth of the matter.

No, that isn't why I qualified it. I simply wanted to see if I had
missed such a case, within the way I use EVALUATE.

I'll take it from your response that you are not able to find the
requested case so your answer is "No". This is no reflection on the
value of EVALUATE when used in ways other than the one I described.

A 'switch .. case' usually only allows a numeric selector, and only a
single one.

Not in C#. Yes a single variable, but no, it doesn't have to be numeric.
(I mention C# because it is the language I use most these days...)

EVALUATE variable can be of _any_ type (including TRUE/FALSE), and can
have several variables using ALSO. 'switch case' also drops through from
one case to another unless there is a 'break', EVALUATE only does this
by concatenation of WHENs. So, no, EVALUATE is not _equivalent_ to
'switch case', there are many differences in semantics even if there is
a similar appearance and EVALUATE can be made to emulate the other.

Hmmm... pretty weak argument. If you say they are not equivalent simply
because of some very minor differences in syntax, that is really not the
point I was arguing. I believe the FUNCTIONALITY of both of them (when
used as described) is similar enough to warrant claiming "equivalence".
I predicate my statement on the fact that when writing language
convertors (and I have had some experience at this) I would expect to
replace a COBOL EVALUATE with a "switch... case" before considering
decomposition and IF generation...

>
> EVALUATE was implemented to be able to directly code decision tables. Simplistic, subset usage of it may be used to emulate several different, simpler control structures, but that does not restrict it to those.
>
>
>>>> If you use EVALUATE TRUE [ ALSO TRUE...] all you are really doing is
>>>> providing a framework for the IFs you still have to write (except that
>>>> now they are WHENs...). It may make things a bit more readable (in terms
>>>> of the layout) but it is adding more words, and that's something that is
>>>> best avoided... (IMO)
>>>
>>> 'WHEN' is fewer words than 'ELSE IF'.
>>
>> I wouldn't write "ELSE IF" into an EVALUATE, so it isn't for me...
>
> Your point was that "more words .. is best avoided" in the context implying that an EVALUATE would have more words than an equivalent IF .. ELSE IF .. ELSE IF.

That was not the context I stated. I seldom, if ever, use IF...ELSE
IF... ELSE IF

I would scope the IFs instead.

>
> In fact the reverse may be true: EVALUATE TRUE WHEN .. WHEN .. END-EVALUATE may have fewer words than IF .. ELSE IF .. END-IF END-IF (5 vs 6).
>
>
>>>
>>> EVALUATE can be used as a decision table. In the early 70s I did use decision tables directly in source code and put the source through a pre-processor as part of the compile cycle. The program spec had the tables so putting these directly in the code meant any flaws could be blamed on the spec, not on my coding!!
>>>
>>> With EVALUATE there is no need to pre-process.
>>

That's a very good point...

>> Yes, I remember the popularity of decision tables and I agree they could
>> be very useful. I believe the late Jimmy Gavan who posted here for many
>> years was a big fan and posted some very good examples.
>
> Decision table pre-processors were virtually made obsolete by EVALUATE, though the coding styles can be be somewhat different.
>
>
>>>
>>>> The point of the post was about simplifying IFs, not replacing them with
>>>> something else... :-)
>>>
>>> It seemed to me that the problem was exactly what decision tables are for.
>>>
>>
>> It is certainly true that decision tables can simplify complex compound
>> IFs in much the way I mentioned using boolean Algebra.
>>>

Cheers,

[Greg Wallace]

I studied Gane and Sarson and Yourdon methodolgies for structured Cobol back in the late 70's or early 80's. I gave it 100% effort to avoid GOTO. In those days we submitted a compile to the operators overnight and the next day we had a fan-fold print-out. One day, I had all my ten fingers marking pages as I followed down and up the logic. I had an epiphany moment when I realized this is silly and just to avoid GOTO.

So I moved to back to If, Else and GOTO but with limitations. Perform until is OK. If you perform Sections, GOTOs can be within the section and never outside. If you perform paragraphs then do not use GOTO. There is only one exception with GOTO and it is a bad condition with GOTO Mainline-Exit which closes the program in an orderly way. If it is a called program, then it should pass back an error message with a return code.

I also had another epiphany moment when I realized I could cope with about six different tasks at a time. I also had 4 programmers under me and keeping track of their tasks, so it was potentially 6 x 4 = 24, two were clever and two were plodders. One of these could only cope with one task at a time. He would come to me each day and I had to say - do this - then move on with this. In those days, the late 1970's, a program change was a daily cycle, change today and get a compile report tomorrow. So you had to have multiple tasks to move best in this daily cycle.

End-If has been my best more recent friend because it avoids full stops and makes the code cleaner.

Getting back to the If/Else thread, I tend to oversimplify code and avoid long If/Else statements with the emphasis on making the code more easily readable. I could give examples.

Even with modern code editors these ideas still apply. My favorite editor today is TextPad from Helios Software. It does Cobol, PHP and other languages including HTML, CSS etc with plugins to check syntax. It has block move mode which I find invaluable.

The verbosity of COBOL is not an issue for me if you align code, copy and paste etc. Again I could say more.

I am still an advocate for Cobol and consider it as a chameleon language that adapts to the environment.

[pete dashwood]

On 13/02/2017 9:35 a.m., Bill Woodger wrote:
> Thanks Pete. I see what you mean now. I've not come across a lot of code like that, but it certainly doesn't help get things across.
>
> Privacy is easy. Just change the names to protect the innocent.

No it isn't that easy. There are principles involved and examples that
must be set for others who could be colleagues. Anyway, I'm not doing
it. :-)

>
> As has been said, switch/select/evaluate prior to the existence of EVALUATE is exactly the "other half" of the suggestion you make.
>
> IF condition-1-on-field
> do something-1
> ELSE
> IF condition-2-on-field
> do something-2
> ELSE
> IF condition-3-on-field
> do something-3
> ELSE
> IF condition-4-on-field
> do something=4
> ELSE
> do something else.
>
> This is a "vertical nested-IF", where conditions must be mutually exclusive (not cumulative).
>
> Which doesn't detract from your point otherwise. If you make nested-IFs complicated, it can cause unnecessary trouble.

This came across my desk today. You might find it interesting... :-)

https://techbeacon.com/revisiting-forgotten-code-constructs

>
> With END-IF, a third type of nested-IF arrives. Easily abstracted-out to the original, unless some... person... puts a GO TO in the embedded-IF. You can't put a GO TO in a "classic nested-IF" (at least not if you want it all to work).
>
> When I started, it was explained to me that literals in the PROCEDURE DIVISION were not good: there's more meaning available in a condition-name; not all +1s are created equal (by which I mean, they may all mean one, but only in places where the intention is also one, rather than item-out-of-stock, should they actually appear to be equivalent).

Without wishing to open up a whole 'nother can of worms here, I believe
88 levels are a good way to address that problem.

>
> EVALUATE data-name not only encourages literals in the PROCEDURE DIVISION, it forces the use of them.
>
> Toss in the new "EXIT" formats, secret GO TOs, to arrive at points without obvious labels, data-names like I, J and K (and, if you remember, not what they may be expected to be for (from their FORTRAN roots), and hey-ho, we're back in the late 60s - except with "structure".

Oops! I use J, K, L and sometimes some others, (although avoiding I
because it can be confused on some printouts) and have done so
throughout my career. They are ALWAYS subscripts, in programs I write.
(Indexes will have an X in them...) and they are ALWAYS "general
purpose" (don't expect any particular value...) :-))
Both indexes and subscripts get set before use.

Here's a typical example:

01 subscripts usage comp-5.

12 J pic s9(4).

12 K pic s9(4).

12 L pic s9(4).

12 M pic s9(4).

12 N pic s9(4).

12 P pic s9(4).


01 ExternalNames.

12 filler pic x(31) value "LINK_AUC9".

12 filler pic x(31) value "LINK_AUC22".

12 filler pic x(31) value "LINK_AUC170".

01 XNames REDEFINES ExternalNames.

12 XN OCCURS 003 TIMES

INDEXED by xXN.

15 filler pic x(31).


(The above code was generated by a tool I wrote, but you can see it
reflects my own style of coding... :-))

I inherited these conventions from people who were mentors, most of whom
are now working in the Big Computer Room in the Sky, so there may be
some emotional attachment... :-)

Nobody has every complained to me that they had difficulty or were
confused by them.

DISCLAIMER: The above code is not being presented as a paragon of COBOL
programming which people should emulate. It represents one man's
opinion, that's all.

>
> Now, don't jump and think I don't like scope-terminators. Although some are appalling misnomers when describing what they terminate.
>

I've often wondered in passing why INSPECT has no scope delimiter... I'm
sure there's a good reason. :-)

[pete dashwood]

On 13/02/2017 3:25 p.m., Greg Wallace wrote:
> On Tuesday, 7 February 2017 14:19:24 UTC+10, pete dashwood wrote:

<snipped>

>
> I studied Gane and Sarson and Yourdon methodolgies for structured Cobol back in the late 70's or early 80's. I gave it 100% effort to avoid GOTO. In those days we submitted a compile to the operators overnight and the next day we had a fan-fold print-out. One day, I had all my ten fingers marking pages as I followed down and up the logic. I had an epiphany moment when I realized this is silly and just to avoid GOTO.

I don't think it is the GO TO that is necessarily the problem (although
I generally don't use them any more). Rather it is HOW you use GO TO
that gets it a bad name.

>
> So I moved to back to If, Else and GOTO but with limitations.

> Perform until is OK.

It's OK until they have a production run in the middle of the night that
introduces some data that gets through the validation but has some knock
on effects that mean your UNTIL condition is never satisfied...

This is a real case I remember from back in the days when I was on call
during the night.

> If you perform Sections, GOTOs can be within the section and never outside. If you perform
> paragraphs then do not use GOTO. There is only one exception with GOTO and it is a bad condition with GOTO Mainline-Exit which closes the program in an orderly way. If it is a called program, then it should pass back an error message with a return code.
>
> I also had another epiphany moment when I realized I could cope with about six different tasks at a time. I also had 4 programmers under me and keeping track of their tasks, so it was potentially 6 x 4 = 24, two were clever and two were plodders. One of these could only cope with one task at a time. He would come to me each day and I had to say - do this - then move on with this. In those days, the late 1970's, a program change was a daily cycle, change today and get a compile report tomorrow. So you had to have multiple tasks to move best in this daily cycle.
>
> End-If has been my best more recent friend because it avoids full stops and makes the code cleaner.

Amen!

>
> Getting back to the If/Else thread, I tend to oversimplify code and avoid long If/Else statements with the emphasis on making the code more easily readable. I could give examples.

Sometimes people think in English when writing compound IFs and that can
really muddy the water. You need to think in symbolic logic (that's why
I like the Boolean approach described elsewhere.)

>
> Even with modern code editors these ideas still apply. My favorite editor today is TextPad from Helios Software. It does Cobol, PHP and other languages including HTML, CSS etc with plugins to check syntax. It has block move mode which I find invaluable.

Yes, I really like Jan Fiala's PSPad Editor and use it all the time.
(http://www.pspad.com/en/)

>
> The verbosity of COBOL is not an issue for me if you align code, copy and paste etc. Again I could say more.

The verbosity of COBOL is one of the factors in its demise. No matter
how you cut and arrange it, it still takes more typing. If you make the
names shorter you defeat the object of it, and the verbs are still the
same length. I think the perspective here is realizing what COBOL is
seeking to achieve by being "English-like". It DOESN'T make it easier to
maintain for a programmer (and you could achieve that with Notes in any
language). It was intended so that accountants could be persuaded that
they could "see what was going on" in the code being run by the
corporate computers. A marketing ploy, aimed at the people who made the
purchasing decisions, and never at the programmers.

Having said that, I agree with you that it will have different weight
with different people and if you find it OK, then it is good for you.

For myself, I find I can achieve what I need to in about one third the
LOC in C# that it would take in COBOL. That's important to me, so I use
C#, given that all the other things for a given exercise, are equal.

>
> I am still an advocate for Cobol and consider it as a chameleon language that adapts to the environment.
>

One of the major differences between Homo Sapiens and the other animals
is that the animals adapt to the environmnt; Man changes the environment
to suit himself. (Sometimes, he does this inadvertently and may then
have to make corrections.)

I'm an advocate for tools (including languages) that make my life easier
and help me develop stuff more quickly.

[Bill Woodger]

Thanks Rick. Pity it was beyond the scope of the paper to go into it a bit more.

The rest is not directed at you individually :-)

The intention explains the ALSO.. ALSO.. ALSO.. But. An advantage, for me, of Decision Tables was that multiple Actions could be used against different Conditions. Not so for EVALUATE, with the built-in "break" for each WHEN.

Perhaps I was just doing the wrong Decision Tables, although the WHEN-with-break would require repetition of code, such that it more represents the code generated for a Decision Table than the code which generates.

Plus, of course, the visual. The DTs I used were highly formatted, allowing multiple conditions to be connected to multiple actions by consulting a column (which would contain Y, N and - (irrelevant) for Conditions and X and - (don't do this) for Actions).

Without the graphical aid, EVALUATE with ALSO seems to be a potential tool of complication. After all (at least with IBM's Enterprise COBOL) you can have 64 "subjects" and 256 WHENs. I'd really love to have to attempt to comprehend a full-sized one of those.

[Bill Woodger]

On Monday, February 13, 2017 at 3:42:22 AM UTC+1, pete dashwood wrote:
> On 13/02/2017 9:35 a.m., Bill Woodger wrote:
> > Thanks Pete. I see what you mean now. I've not come across a lot of code like that, but it certainly doesn't help get things across.
> >
> > Privacy is easy. Just change the names to protect the innocent.
>
> No it isn't that easy. There are principles involved and examples that
> must be set for others who could be colleagues. Anyway, I'm not doing
> it. :-)
> >

If the code were representing something proprietary, sure, but how would that be so with an IF?

Why no END-INSPECT.

Here are a selection of scope-terminators.

END-ADD
END-CALL
END-COMPUTE
END-DELETE
END-DIVIDE
END-MULTIPLY
END-READ
END-RETURN
END-REWRITE
END-SEARCH
END-START
END-STRING
END-SUBTRACT
END-UNSTRING
END-WRITE

List of those which actually terminate what they name:

END-EVALUATE
END-IF

The rest terminate an optional conditional part.

The maths ones terminate "SIZE ERROR" or "ON" (can't really be ON, because it is optional). Perhaps it would be too confusing to have END-SIZE-ERROR which could have been started by NOT ON SIZE ERROR?

COMPUTE is not terminated by END-COMPUTE. COMPUTE ends fine, all on its own. What needs an END is the SIZE ERROR.

Similar with the IO statements. All end themselves fine. All can use something tortuous, and find there is a conditional scope which needs terminating.

An example, with no names changed even:

Perform 100-Initialize-Paragraph
* The following statement is an inline PERFORM:
Perform Until Transaction-EOF
Read Update-Transaction-File Into WS-Transaction-Record
At End
Set Transaction-EOF To True
Not At End
Perform 200-Edit-Update-Transaction
If No-Errors
Perform 300-Update-Commuter-Record
Perform 400-Print-Transaction-Errors
* End-If is a required scope terminator
End-If
Perform 410-Re-Initialize-Fields
* End-Read is a required scope terminator
End-Read
End-Perform

Are we *really* still in the READ?

And:

READ FILE1
AT END
MOVE A TO B
READ FILE2
END-READ

The latter example introduces an element of schizophrenia. The END-READ, which is not required to terminate a READ, but is required to terminate AT END (or/and NOT AT END) terminates the READ without a condition, instead of the READ with a condition.

Clear so far?

Then there is END-PERFORM. An in-line PERFORM must be terminated with END-PERFORM. You can have an in-line PERFORM without a condition. You can't use a full-stop/period as a scope-terminator for an in-line PERFORM, unlike all the other END- constructs.

Then there is END-OF-PAGE. OK, that's history biting back. It's probably all history biting back. After the failure of COBOL-80 (which would require code changes on grand scales just to stand still) I guess things got compromised.

INSPECT has no conditional/imperative element, so no END-INSPECT.

[pete dashwood]

Thanks for that, Bill. :-)

[Richard]

So, your argument is that you use EVALUATE in the limited way that is only a switch case, therefore EVALUATE is a switch case.

In fact EVALUATE has ALSO and I don't know of any switch that has that. It does not need to use EVALUATE TRUE to use ALSO. There is a corresponding ANY where one of the variables in a set of ALSOs can take any value.

EVALUATE File-Status-1 ALSO File-Status-2
WHEN "0" ALSO "2"
PERFORM Status-Valid-Duplicate
WHEN "0" ALSO ANY
PERFORM Status-OK
WHEN "2" ALSO "2"
PERFORM Duplicate-Record
...

> A 'switch .. case' usually only allows a numeric selector, and only a
> single one.
>
> Not in C#. Yes a single variable, but no, it doesn't have to be numeric.
> (I mention C# because it is the language I use most these days...)

At the time that EVALUATE was created there was no C#, nor Java.

I use Python mostly these days, it has no switch case at all. Python prides itself on only giving one way to do things and if .. elif .. else does it all.

> EVALUATE variable can be of _any_ type (including TRUE/FALSE), and can
> have several variables using ALSO. 'switch case' also drops through from
> one case to another unless there is a 'break', EVALUATE only does this
> by concatenation of WHENs. So, no, EVALUATE is not _equivalent_ to
> 'switch case', there are many differences in semantics even if there is
> a similar appearance and EVALUATE can be made to emulate the other.
>
> Hmmm... pretty weak argument. If you say they are not equivalent simply
> because of some very minor differences in syntax,

'Syntax' is not the same as 'semantics'.

> that is really not the
> point I was arguing. I believe the FUNCTIONALITY of both of them (when
> used as described) is similar enough to warrant claiming "equivalence".
> I predicate my statement on the fact that when writing language
> convertors (and I have had some experience at this) I would expect to
> replace a COBOL EVALUATE with a "switch... case" before considering
> decomposition and IF generation...
> >
> > EVALUATE was implemented to be able to directly code decision tables. Simplistic, subset usage of it may be used to emulate several different, simpler control structures, but that does not restrict it to those.
> >
> >
> >>>> If you use EVALUATE TRUE [ ALSO TRUE...] all you are really doing is
> >>>> providing a framework for the IFs you still have to write (except that
> >>>> now they are WHENs...). It may make things a bit more readable (in terms
> >>>> of the layout) but it is adding more words, and that's something that is
> >>>> best avoided... (IMO)
> >>>
> >>> 'WHEN' is fewer words than 'ELSE IF'.
> >>
> >> I wouldn't write "ELSE IF" into an EVALUATE, so it isn't for me...
> >
> > Your point was that "more words .. is best avoided" in the context implying that an EVALUATE would have more words than an equivalent IF .. ELSE IF .. ELSE IF.
>
> That was not the context I stated. I seldom, if ever, use IF...ELSE
> IF... ELSE IF

Yes, it is the context you stated. You stated that EVALUATE TRUE is just a framework for the IFs except they are now WHENs, but it uses more words. My point is that the EVALUATE demonstratively uses _less_ words.

[Richard]

END-OF-PAGE is not 'COBOL', it is a non-standard extension.

> INSPECT has no conditional/imperative element, so no END-INSPECT.

Statements are either imperative or conditional. Conditional statements have a scope and thus require a scope delimiter. Imperative statements have no scope and thus a scope terminator is invalid.

Some statements are always imperative (eg CONTINUE), some are always conditional (eg IF, EVALUATE), some are conditional only when particular optional phrases are present.

An inline PERFORM creates a scope and thus is classed as a conditional statement. An out of line PERFORM does not create a scope within the procedure it is in (the scope is elsewhere) and thus is classed as imperative. This is regardless of whether they have a limiting phrase (UNTIL) or not.

[Richard]

On Monday, February 13, 2017 at 8:09:56 PM UTC+13, Bill Woodger wrote:
> Thanks Rick. Pity it was beyond the scope of the paper to go into it a bit more.
>
> The rest is not directed at you individually :-)
>
> The intention explains the ALSO.. ALSO.. ALSO.. But. An advantage, for me, of Decision Tables was that multiple Actions could be used against different Conditions. Not so for EVALUATE, with the built-in "break" for each WHEN.

You can concatenate WHENs

EVALUATE somthing
WHEN "A"
WHEN "D"
WHEN "F" THRU "H"
PERFORM Found-A-D-FGH
WHEN "B"
CONTINUE
WHEN OTHER
PERFORM Not-ABDFGH
END-EVALUATE

[pete dashwood]

I realized that anyone who is actually interested in learning to do
these simplifications would have to go all over the place to find a
succinct explanation of the above mentioned laws.

I'll add a page on Boolean simplification to the new release of the
COBOL 21 web site which I'm hoping to have ready by June/July this year
(to coincide with the launch of the commercial version of our new
PowerCOBOL to .Net migration tool, PCOB2NET.
(see http://primacomputing.co.nz)

In the meantime here is a very succinct statement of the laws I use when
simplifying compound conditions:

(A "variable" in this context is a conditional statement.)

Variables used can have only two values. Binary 1 for TRUE and Binary 0
for FALSE.

NEGATION of a variable is represented by an overbar (-) or an
apostrophe. Thus if B = 0 then NOT B (B') = 1 and, if B = 1 then NOT B
= 0.

ORing of the variables is represented by a plus (+) sign between them.
For example, ORing of A, B, C is represented as A + B + C. (Read as:"A
or B or c".)

ANDing of the variables is represented by writing a dot between them
such as A.B.C. Sometimes the dot may be omitted, so ABC or A.B.C.

Boolean Laws:

COMMUTATIVE law:
The Commutative law states that changing the sequence of the variables
does not have any effect on the output of a logic circuit (if you are
using Boolean Algebra to simplify circuit design), or the truth value of
the result.

A + B = B + A
A.B = B.A

ASSOCIATIVE law:
The ASSOCIATIVE law states that the order in which the logic operations
are performed is irrelevant, as their effect is the same.
A.(B.C) = (A.B).C
A+(B + C) = (A + B).C

DISTRIBUTIVE LAW:
The Distributive law states the following condition.

A.(B + C) = A.B + B.C

The actual values of 0 and 1 (FALSE and TRUE, respectively) are called
'Multiplicative and Additive identity' because they don't change things
multiplied (ANDed) or added (ORed) with them, as follows:

AND law:
A.0 = 0 A.1 = A
(Note also...)
A.A' = 0 A.A = A

OR law:
A + 0 = A A + 1 = 1
(Note also...)
A + A' = 1 A + A = A

INVERSION law
The inversion law states that double negation of a variable results in
the original variable itself.
(A')' = A

And finally (the famous trap for newbie COBOL guys who are thinking in
English...):

De Morgan's Laws:

1. (A.B)' = A' + B' (read: A and B negated = not A OR not B)
2. (A + B)' = A'.B' (read: A or B negated = not A AND not B)

Using just the above simple postulates you can get some truly amazing
results. There are examples all over the Internet, but I really liked
this one... :-):

http://math.stackexchange.com/questions/1935029/need-help-with-boolean-algebra-simplification?rq=1

And there are worked examples using the rules above at:

http://sandbox.mc.edu/~bennet/cs110/boolalg/simple.html

HTH,

[Richard]

The problem not the GO TO at all. When a GO TO is seen then it is perfectly clear what will happen.

The problem is that each GO TO requires a label (or several if ALTERed or DEPENDING ON). When code is examined and a label is encountered then, in the general case, it is only possible to know the logic flow around that label by examining the whole program. The label may be reached by dropping into, by being used by a GO TO or a PERFORM or it may terminate the scope of a PERFORM or THRU.

By restricting the control flow to only be PERFORM paragraph (no section, no thru) and disallowing GO TO (except possibly to abandon) then one can be assured what control flow at a label is.

[Rick Smith]

On Monday, February 13, 2017 at 5:51:37 PM UTC-5, Richard wrote:

[...]

> END-OF-PAGE is not 'COBOL', it is a non-standard extension.

END-OF-PAGE was added in COBOL 85. prior to that it was a
non-standard extension.

[Bill Woodger]

A simple decision-table of the pre-processor I used (the X/Y/N/blank are not "to scale"):

DT some-name
CONDITIONS
01 A EQUAL TO B Y Y N N
02 A EQUAL TO C Y N Y N
ACTIONS
01 ADD 1 TO X - X - X
02 ADD 1 TO Y X X - -
03 ADD 1 TO Z - - - X
04 ADD 1 TO Q - - X X

(there was an "initial actions" available (indent the condition Y/N/- by a further two spaces) and obviously the N/N column could be -/- for "irrelevant", being a "WHEN OTHER" or the final ELSE of a nested-IF.

Pete's exactly-disliked nested-IF:

IF A EQUAL TO B
IF A EQUAL TO C
ADD 1 TO Y
ELSE
ADD 1 TO X
ADD 1 TO Y
ELSE
IF A EQUAL TO C
ADD 1 TO Q
ELSE
ADD 1 TO X
ADD 1 TO Z
ADD 1 TO Q.

The EVALUATE:

EVALUATE A EQUAL TO B
ALSO A EQUAL TO C
WHEN TRUE ALSO TRUE
ADD 1 TO Y
WHEN TRUE ALSO FALSE
ADD 1 TO X
ADD 1 TO Y
WHEN FALSE ALSO TRUE
ADD 1 TO Q
WHEN FALSE ALSO FALSE
ADD 1 TO X
ADD 1 TO Z
ADD 1 TO Q
END-EVALUATE

It is not the repetition of the ADDs that is a concern (make them PERFORMs, repeat the PERFORMs, easy to grasp, and can give the process a good name), it is the "grasping" of the interaction between the conditions.

Remember, that is a simple DT. Personally I'd not use more than three conditions. Others would love to stick as much as possible in a single DT, then leave it to the next person who had to make a change to split a table to add a further simple condition.

Even with a complex DT, the "paths" were easily visualisable, a direct relationship between multiple conditions and multiple actions.

The same "visual" aspect is entirely missing from EVALUATE, so I don't think it a "good" representation of a DT. You can code a DT in it, but it isn't useful as a DT (for me).

I do have to say the code generated was replete with conditional and non-conditional GO TOs, to far-from-meaningful names. But, since it was generated, you only needed to look at the actual COBOL when there was a program failure (then hear the 10-conditions-to-a-table guys squeal).

[Bill Woodger]

When I was typing, it was proportional :-)

Best viewed when pasted into something really dumb, or paste it into something clever with a proportional font.

[Bill Woodger]

On Monday, February 13, 2017 at 11:59:15 PM UTC+1, Richard wrote:
> You can concatenate WHENs
>
> EVALUATE somthing
> WHEN "A"
> WHEN "D"
> WHEN "F" THRU "H"
> PERFORM Found-A-D-FGH
> WHEN "B"
> CONTINUE
> WHEN OTHER
> PERFORM Not-ABDFGH
> END-EVALUATE
>

Sure, but you don't get anything like a Decision Table I know. OK, so I'm not the Boss of DTs, but, still...

[Richard]

I wasn't trying to illustrate DTs, I was answering your 'the built-in "break" for each WHEN' by illustrating how WHENs can be concatenated, you need to have an imperative statement (eg CONTINUE) if you want an automatic break.

[Bill Woodger]

OK but no-one would expect the break to be on the WHEN, that wouldn't work well :-)

[pete dashwood]

This is a very lucid description of the points under discussion. I found
it interesting and informative. Thanks, Bill.

[Bill Woodger]

On Tuesday, 14 February 2017 02:14:30 UTC+1, Richard wrote:
> I wasn't trying to illustrate DTs, I was answering your 'the built-in "break" for each WHEN' by illustrating how WHENs can be concatenated, you need to have an imperative statement (eg CONTINUE) if you want an automatic break.

Apologies, I see you are quoting exactly what I said :-) . I had intended to look up the exact phrase which is "selection object". Failed on that. Selection objects have the built-in break.

Usually, with COBOL, you get the fullest flexibility. An example being STRING. Unless the data is the same size each time for the STRING, you need to clear the output first. That's for the 0.0001% of the time anyone actually uses STRING *wanting* other data in the target field to be undisturbed.

Explicit breaks could have been included, and required on each selection object to get the current behaviour. But they weren't. Who says COBOL is overly verbose?

[Rick Smith]

On Tuesday, February 14, 2017 at 10:20:51 AM UTC-5, Bill Woodger wrote:
> On Tuesday, 14 February 2017 02:14:30 UTC+1, Richard wrote:
> > I wasn't trying to illustrate DTs, I was answering your 'the built-in "break" for each WHEN' by illustrating how WHENs can be concatenated, you need to have an imperative statement (eg CONTINUE) if you want an automatic break.
>
> Apologies, I see you are quoting exactly what I said :-) . I had intended to look up the exact phrase which is "selection object". Failed on that. Selection objects have the built-in break.

[...]

> Explicit breaks could have been included, and required on each selection object to get the current behaviour. But they weren't. Who says COBOL is overly verbose?

I have published a document that explains where the "break" occurs
in the EVALUATE statement.

< https://docs.google.com/document/d/1-rvdHkMhMm00cxfIsgAw2fzy1yIyAF9rsLsbpQqq9D8/pub >

And, quoting the COBOL 2002 standard:
-----
14.8.12.1 General format
EVALUATE selection-subject [ ALSO selection-subject ] ...
{ { WHEN selection-object [ ALSO selection-object ] ... }
... imperative-statement-1 } ...
[ WHEN OTHER imperative-statement-2 ]
[ END-EVALUATE ]

14.8.12.3 General rules
5) The execution of the EVALUATE statement then proceeds as follows:
a) If a WHEN phrase is selected, execution continues with the first
imperative-statement-1 following the selected WHEN phrase.

c) The execution of the EVALUATE statement is terminated when execution
reaches the end of imperative-statement-1 of the selected WHEN
phrase or the end of imperative-statement-2, or when no WHEN phrase
is selected and no WHEN OTHER phrase is specified.
-----

The general format shows that the WHEN phrase does not terminate until
after imperative-statement-1 and any continuations have terminated.

General rule 5)c) describes the "built-in 'break'" for the EVALUATE
statement.

[Rick Smith]

On Tuesday, February 14, 2017 at 10:20:51 AM UTC-5, Bill Woodger wrote:

[...]

> Usually, with COBOL, you get the fullest flexibility. An example being STRING. Unless the data is the same size each time for the STRING, you need to clear the output first. That's for the 0.0001% of the time anyone actually uses STRING *wanting* other data in the target field to be undisturbed.

The STRING (and UNSTRING) statements appeared as non-standard extensions
to IBM COBOL for their COBOL 68 standard. It was subsequently added to
COBOL 74 by the CODASYL COBOL Committee (At least, that is what appears
to me to be the case.)

While the STRING statement was able to string together multiple fields
with one statement, the POINTER phrase allowed extending the text
with separate STRING statements. It seems to me, that if the remaining
characters were space filled after each separate STRING statement,
performance would suffer.

If the receiving field was defined as ODO, its length could set by
subtracting 1 from the ending value of the pointer variable. Whatever is
present in memory beyond that length would not participate in subsequent
operations on that field. Hence space-filling would not be necessary.

I don't know why space-filling was not done but there are reasons
for not doing so.

[Bill Woodger]

On Tuesday, February 14, 2017 at 9:04:36 PM UTC+1, Rick Smith wrote:
> On Tuesday, February 14, 2017 at 10:20:51 AM UTC-5, Bill Woodger wrote:
> I have published a document that explains where the "break" occurs
> in the EVALUATE statement.
>
> < https://docs.google.com/document/d/1-rvdHkMhMm00cxfIsgAw2fzy1yIyAF9rsLsbpQqq9D8/pub >
>

That looks good. Of course, no type of syntax-diagram is expected to cater for what can actually happen if someone jams in a GO TO (or an EXIT with PARAGRAPH, SECTION, PERFORM or PERFORM CYCLE) :-)

[Bill Woodger]

On Tuesday, February 14, 2017 at 9:48:46 PM UTC+1, Rick Smith wrote:
[...]

Well, logically, it can't be for performance, since Joe Programmer has to code a MOVE SPACES to the entire area for those cases where the STRING-ed value can be of different lengths (and, if the same length, why use STRING so much?).

STRING with POINTER allows the insertion of data into the target at a variable starting point and for a variable length, leaving any prior or subsequent data unchanged.

That is very useful when you *need* it, but it is not needed (or even more so not used) often. UNSTRING has great flexibility. SEARCH has great flexibility. The programmer has to code to use them for the particular requirement. INSPECT as well, including the "growing" of its flexibility after initial appearance.

EVALUATE could have had more flexibility, and doesn't. Just a curiosity now, since it is all history.

[Rick Smith]

On Tuesday, February 14, 2017 at 9:08:59 PM UTC-5, Bill Woodger wrote:
> On Tuesday, February 14, 2017 at 9:48:46 PM UTC+1, Rick Smith wrote:
> [...]
>
> Well, logically, it can't be for performance, since Joe Programmer has to code a MOVE SPACES to the entire area for those cases where the STRING-ed value can be of different lengths (and, if the same length, why use STRING so much?).

One need not MOVE SPACES before using STRING!

-----
program-id. str-ex.
data division.
1 space-30 pic x(30) value space.
1 output-field pic x(30).
1 field-1 pic x(10) value "The quick ".
1 field-2 pic x(9) value "brown fox".
procedure division.
move all "abcd" to output-field
display "Before: " quote output-field quote
string field-1 field-2 space-30
delimited size into output-field
display "After : " quote output-field quote
stop run
.

Before: "abcdabcdabcdabcdabcdabcdabcdab"
After : "The quick brown fox "
-----

Using MOVE SPACES before STRING may be a common practice, but
doing so instead of the above would result in moving 49 characters.
This example moves only 30 characters. Logically, gross performance
is better, with this example, though net performance would vary
with platform and implementation.

[Bill Woodger]

But, you can no longer deal with overflow, because you always have overflow.

Whether faster than a MOVE of space prior to the STRING will depend on how the implementation of STRING deals with the bytes for that example, and for others, as you suggest.

Certainly not slower than the STRING for the example you give would be three simple MOVEs and three "subordinate" data-items. Fixed position, fixed length, no STRING needed. But it was only an example for illustration.

The guaranteed overflow could be avoided (so tested for if it really happens) and minimum bytes moved by using POINTER with an initial value of one, and then (am I really going to say this) a reference-modified MOVE of space to the position of the POINTER for a length of (with calculation) the remainder of the field, and only done when the pointer-value does not exceed the length of the receiving field.

[docd...@panix.com]

In article <649a4e7c-b3a7-4b20...@googlegroups.com>,
Rick Smith <rs84...@gmail.com> wrote:

[snip]

>The STRING (and UNSTRING) statements appeared as non-standard extensions
>to IBM COBOL for their COBOL 68 standard. It was subsequently added to
>COBOL 74 by the CODASYL COBOL Committee (At least, that is what appears
>to me to be the case.)

Only forty-some years ago? Best not to be hasty.

DD

[anti...@math.uni.wroc.pl]

pete dashwood <dash...@enternet.co.nz> wrote:
>
> This came across my desk today. You might find it interesting... :-)
>
> https://techbeacon.com/revisiting-forgotten-code-constructs

It is interesing that in some places recursion is considered
forgotten. For me it is one of fundamental programming
techniques and I see it used almost everywhere.

--
Waldek Hebisch