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...
Why not use the EVALUATE TRUE statement?<snipped>
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:
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...
The point of the post was about simplifying IFs, not replacing them with >something else... :-)
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 may be used as a switch..case but it has far more functionality.
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'WHEN' is fewer words than 'ELSE IF'.
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)
The point of the post was about simplifying IFs, not replacing them withIt seemed to me that the problem was exactly what decision tables are for.
something else... :-)
"pete dashwood" <dashwood@enternet.co.nz> wrote in message news:eft06aFlc5uU1@mid.individual.net...
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...
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.
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 decisiontables 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.
Hi Pete,With realistic names (maybe ask the lady in (the) question to provide a lump of
Can you provide an example of the compound IF thing you are talking about?
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?
In general I'm mightily surprised at the idea of someone doing maintenancefiddling 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 thatyou'd not have got away with in the 80s, but now the defence is simple - "it's OK, I'm using a Structured Construct".
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.
On 9/02/2017 2:22 p.m., Richard wrote:Yes, EVALUATE can be used to emulate a GO TO DEPENDING ON (GTDO):
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.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 thatAgain, 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.
may be because I limit the way I use EVALUATE.
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 .. ELSEIf 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...
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,EVALUATE can be used as a decision table. In the early 70s I did use
Decision table pre-processors were virtually made obsolete by EVALUATE, though the coding styles can be be somewhat different.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.
--
I used to write COBOL; now I can do anything...
Richard, do you have some reference for the intention of EVALUATE being toimplement Decision Tables?
On Monday, February 13, 2017 at 1:37:52 AM UTC+13, pete dashwood wrote:different purpose compared to GTDO.
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
.. ELSE IF ...). Your qualification removing the actual nearest thing merely shows how GTDO is completely _not_ "the nearest thing".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
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.
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.
that an EVALUATE would have more words than an equivalent IF .. ELSE IF .. ELSE
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
In fact the reverse may be true: EVALUATE TRUE WHEN .. WHEN .. END-EVALUATEmay have fewer words than IF .. ELSE IF .. END-IF END-IF (5 vs 6).
not on my coding!!
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,
With EVALUATE there is no need to pre-process.
though the coding styles can be be somewhat different.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,
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.
I had occasion to talk to someone who is currently maintaining someI studied Gane and Sarson and Yourdon methodolgies for structured Cobol back in
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...
Thanks Pete. I see what you mean now. I've not come across a lot of code likethat, 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 EVALUATEis exactly the "other half" of the suggestion you make.
IF condition-1-on-field(not cumulative).
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
Which doesn't detract from your point otherwise. If you make nested-IFscomplicated, it can cause unnecessary trouble.
With END-IF, a third type of nested-IF arrives. Easily abstracted-out to theoriginal, 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 PROCEDUREDIVISION were not good: there's more meaning available in a condition-name; not
EVALUATE data-name not only encourages literals in the PROCEDURE DIVISION, itforces the use of them.
Toss in the new "EXIT" formats, secret GO TOs, to arrive at points withoutobvious labels, data-names like I, J and K (and, if you remember, not what they
Now, don't jump and think I don't like scope-terminators. Although some areappalling misnomers when describing what they terminate.
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 backin 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.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
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 itis 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 aboutsix 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
End-If has been my best more recent friend because it avoids full stops andmakes the code cleaner.
Getting back to the If/Else thread, I tend to oversimplify code and avoidlong 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 editortoday 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 andpaste etc. Again I could say more.
I am still an advocate for Cobol and consider it as a chameleon language thatadapts to the environment.
On 13/02/2017 9:35 a.m., Bill Woodger wrote:like that, but it certainly doesn't help get things across.
Thanks Pete. I see what you mean now. I've not come across a lot of code
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. :-)
On Monday, February 13, 2017 at 3:42:22 AM UTC+1, pete dashwood wrote:be so with an IF?
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
Why no END-INSPECT.is optional). Perhaps it would be too confusing to have END-SIZE-ERROR which could have been started by NOT ON SIZE ERROR?
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
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 usesomething tortuous, and find there is a conditional scope which needs terminating.
An example, with no names changed even: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.
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,
Clear so far?END-PERFORM. You can have an in-line PERFORM without a condition. You can't use
Then there is END-PERFORM. An in-line PERFORM must be terminated with
Then there is END-OF-PAGE. OK, that's history biting back. It's probably allhistory 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.
On 13/02/2017 7:58 a.m., Richard wrote:a different purpose compared to GTDO.
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
IF .. ELSE IF ...). Your qualification removing the actual nearest thing merelyBefore EVALUATE, the nearest thing (apart from IF itself) was GO TO...
DEPENDING ON.
Before EVALUATE the nearest thing _was_ IF itself (specifically IF .. ELSE
OK :-)
So, your argument is that you use EVALUATE in the limited way that is only a switch case, therefore EVALUATE is a switch case.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.At the time that EVALUATE was created there was no C#, nor Java.
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'Syntax' is not the same as 'semantics'.
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 theSimplistic, subset usage of it may be used to emulate several different, simpler control structures, but that does not restrict it to those.
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.
that an EVALUATE would have more words than an equivalent IF .. ELSE IF .. ELSEIf 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 was not the context I stated. I seldom, if ever, use IF...ELSEYes, 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.
IF... ELSE IF
I would scope the IFs instead.may have fewer words than IF .. ELSE IF .. END-IF END-IF (5 vs 6).
In fact the reverse may be true: EVALUATE TRUE WHEN .. WHEN .. END-EVALUATE
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,
EVALUATE can be used as a decision table. In the early 70s I did use
though the coding styles can be be somewhat different.
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,
for.
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
It is certainly true that decision tables can simplify complex compound
IFs in much the way I mentioned using boolean Algebra.
Cheers,
Pete.
--
I used to write COBOL; now I can do anything...
On Monday, February 13, 2017 at 3:42:22 AM UTC+1, pete dashwood wrote:like that, but it certainly doesn't help get things across.
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
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 thatbe so with an IF?
Why no END-INSPECT.is optional). Perhaps it would be too confusing to have END-SIZE-ERROR which could have been started by NOT ON SIZE ERROR?
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
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 usesomething tortuous, and find there is a conditional scope which needs terminating.
An example, with no names changed even: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.
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,
Clear so far?END-PERFORM. You can have an in-line PERFORM without a condition. You can't use
Then there is END-PERFORM. An in-line PERFORM must be terminated with
Then there is END-OF-PAGE. OK, that's history biting back. It's probably allhistory 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. 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.
Thanks Rick. Pity it was beyond the scope of the paper to go into it a bitmore.
The rest is not directed at you individually :-)Decision Tables was that multiple Actions could be used against different Conditions. Not so for EVALUATE, with the built-in "break" for each WHEN.
The intention explains the ALSO.. ALSO.. ALSO.. But. An advantage, for me, of
Perhaps I was just doing the wrong Decision Tables, although theWHEN-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, allowingmultiple 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 ofcomplication. 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.
I had occasion to talk to someone who is currently maintaining someI realized that anyone who is actually interested in learning to do
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.
On Tuesday, 7 February 2017 14:19:24 UTC+10, pete dashwood wrote:
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...
I studied Gane and Sarson and Yourdon methodolgies for structured Cobol backin 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 untilis 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
I also had another epiphany moment when I realized I could cope with aboutsix 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
End-If has been my best more recent friend because it avoids full stops andmakes the code cleaner.
Getting back to the If/Else thread, I tend to oversimplify code and avoidlong 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 editortoday 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 andpaste etc. Again I could say more.
I am still an advocate for Cobol and consider it as a chameleon language thatadapts to the environment.
END-OF-PAGE is not 'COBOL', it is a non-standard extension.
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
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 notthe Boss of DTs, but, still...
A simple decision-table of the pre-processor I used (the X/Y/N/blank are not"to scale"):
DT some-namefurther two spaces) and obviously the N/N column could be -/- for "irrelevant",
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
Pete's exactly-disliked nested-IF:repeat the PERFORMs, easy to grasp, and can give the process a good name), it is the "grasping" of the interaction between the conditions.
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,
Remember, that is a simple DT. Personally I'd not use more than threeconditions. Others would love to stick as much as possible in a single DT, then
Even with a complex DT, the "paths" were easily visualisable, a directrelationship between multiple conditions and multiple actions.
The same "visual" aspect is entirely missing from EVALUATE, so I don't thinkit 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 andnon-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
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
On Tuesday, 14 February 2017 02:14:30 UTC+1, Richard wrote:"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.
I wasn't trying to illustrate DTs, I was answering your 'the built-in
Apologies, I see you are quoting exactly what I said :-) . I had intended tolook up the exact phrase which is "selection object". Failed on that. Selection
Explicit breaks could have been included, and required on each selectionobject to get the current behaviour. But they weren't. Who says COBOL is overly
Usually, with COBOL, you get the fullest flexibility. An example beingSTRING. 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
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 >
On Tuesday, February 14, 2017 at 9:48:46 PM UTC+1, Rick Smith wrote:code a MOVE SPACES to the entire area for those cases where the STRING-ed value
[...]
Well, logically, it can't be for performance, since Joe Programmer has to
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.)
This came across my desk today. You might find it interesting... :-)
https://techbeacon.com/revisiting-forgotten-code-constructs
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 912 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 138:52:55 |
| Calls: | 12,133 |
| Calls today: | 1 |
| Files: | 186,513 |
| Messages: | 2,230,602 |