Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,--- Synchronet 3.20a-Linux NewsLink 1.114
Mayer
Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
If there were other uses of Sections I am drawing a blank on that...Apart from overlays, sections were used to enable the use of GO TO within a PERFORMed procedure. The PERFORM of a section lasted until the end of the section was reached, which was just before the next section header or end of program. There could be paragraph labels within the section so that GO TO could be used to jump around in any way the programmer thought of. You could also do PERFORM section THRU section if you really wanted to complexify your code.
On Friday, September 28, 2018 at 1:27:57 AM UTC+12, Kerry Liles wrote:
--- Synchronet 3.20a-Linux NewsLink 1.114If there were other uses of Sections I am drawing a blank on that...
Apart from overlays, sections were used to enable the use of GO TO within a PERFORMed procedure. The PERFORM of a section lasted until the end of the section was reached, which was just before the next section header or end of program. There could be paragraph labels within the section so that GO TO could be used to jump around in any way the programmer thought of. You could also do PERFORM section THRU section if you really wanted to complexify your code.
By eliminating sections and THRU the use of GO TO is easily avoided.
Hello:
Can any cobol guru provide some insights into sections in the procedure >division: I don't see them used much in any of the cobol textbooks I own
or any of the cobol code I see, and I'd like to understand why.
They do
have some interesting properties, and I can think of several reasons why
I might want to use them. On the other hand, I can't imagine why people
would avoid them. Can anyone suggest some reasons?
Thanks to all who replied! This was very helpful to me!
The relationship between GO TO and sections in the procedure division is
one of the reasons I thought of using sections.
Another reason has to do
with grouping related pieces of code (paragraphs), and in fact, stating
that the internal paragraphs should not be accessed directly, and rather
the entire section should be taken as a "black box".
Short reason: there's no need for them (except when Site StandardsAre they marked off as deprecated?
require their use, in which case my hourly rate just went up).
Longer reason: since code should be written so that it isNot many programmers are being trained to use cobol, so by that reasoning... Anyway, I'm trying to understand the language feature: Why it was introduced, how it was used, etc. I have old cobol books and already in the 1974 standard they're not used; They just appear in the syntax tables at the end of the book. So I was curious.
maintainable and fewer maintenance programmers are being trained in
the use of Sections then the use of Sections should be avoided.
'Interesting' is the very last reason to write a piece of code in aI'm trying to learn. Thank you for your help.
given manner. Bulletproof code is boring. Write boring code.
Hello:--- Synchronet 3.20a-Linux NewsLink 1.114
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
I don't get this "brave" stuff, sorry: I'm here to learn, I'm not playing ego games, I asked a simple question in a relevant forum: What is the rationale for having a specific language feature (sections in the procedure division). The answer ought to be the rationale. Admonitions do not address the question.Another reason has to do with grouping related pieces of codeThis is exactly a reason not to use SECTIONs. Code is written to be maintained and anything that requires 'black boxing' - for example,
(paragraphs), and in fact, stating that the internal paragraphs
should not be accessed directly, and rather the entire section
should be taken as a "black box".
the calculation of compound interest - should be neither a paragraph
nor a SECTION.
(whoever dares to ask 'if it's neither a paragraph nor a SECTION then how does the code get executed?' is brave)
Hello:--- Synchronet 3.20a-Linux NewsLink 1.114
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
Any decent, sane, well-educated and properly-experienced COBOL programmer will have learned that GO TO is permitted under three, and only three, conditions:
Another reason has to do with grouping related pieces of code
(paragraphs), and in fact, stating that the internal paragraphs
should not be accessed directly, and rather the entire section
should be taken as a "black box".
This is exactly a reason not to use SECTIONs. Code is written to be
maintained and anything that requires 'black boxing' - for example,
the calculation of compound interest - should be neither a paragraph
nor a SECTION.
(whoever dares to ask 'if it's neither a paragraph nor a SECTION then how
does the code get executed?' is brave)
I don't get this "brave" stuff, sorry: I'm here to learn, I'm not playing ego games, I asked a simple question in a relevant forum: What is the rationale for having a specific language feature (sections in the procedure division). The answer ought to be the rationale. Admonitions do not address the question.
Black boxing is never required for the code to function. It's a way of organizing code so that some parts are available for use but not for change. My question centers around the rationale behind the language feature, and I was trying to guess at and imagine what it could be useful for. I've seen many cobol books, but few of them give any kind of rationale as to why the standard is defined the way it is, so it would seem to me that falling back on the collective memory of experienced programmers would be the way to proceed.
The calculation of compound interest involves a simple formula. I don't know whether there is a function for raising numbers to a power, but if there isn't, then logarithms and the exponential function would be the way to go. A-priori, this seems to me like something I'd like to perform in a single COMPUTE statement, but you may have other ideas.
Mayer
On Thursday, September 27, 2018 at 6:29:14 AM UTC+3, Mayer Goldberg wrote:
Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
Hello:They were particularly useful before the adoption of the COBOL 85 standard with its scope delimiters such as END-IF and END-PERFORM to avoid the perform para thru para construct. They are used to compartment related groups of paragraphs and statements into higher level logical elements with meaningful names for those logical groups for easier comprehension. It is not advisable to use them in a program already written with perform thru statements, where subsequent amendments may be made by programmers that do not remember that sections only end when another section is specified.
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
On Friday, September 28, 2018 at 1:34:12 PM UTC+12, docd...@panix.com wrote:
Any decent, sane, well-educated and properly-experienced COBOL programmer will have learned that GO TO is permitted under three, and only three, conditions:
That is 3 more than I would permit!
COBOL supports the ** operator (exponentiation), so for example,Right! I forgot this, but re-learned it last night.
square root becomes A ** 0.5 and etc.
On 9/27/2018 9:55 PM, Mayer Goldberg wrote:
Another reason has to do with grouping related pieces of code
(paragraphs), and in fact, stating that the internal paragraphs
should not be accessed directly, and rather the entire section
should be taken as a "black box".
This is exactly a reason not to use SECTIONs. Code is written to be
maintained and anything that requires 'black boxing' - for example,
the calculation of compound interest - should be neither a paragraph
nor a SECTION.
(whoever dares to ask 'if it's neither a paragraph nor a SECTION then how >> does the code get executed?' is brave)
I don't get this "brave" stuff, sorry: I'm here to learn, I'm not playing ego games, I asked a simple question in a relevant forum: What is the rationale for having a specific language feature (sections in the procedure division). The answer ought to be the rationale. Admonitions do not address the question.
Don't worry... DOC is just being DOC - he often plays the part of a
crusty curmudgeon but he has some very strong beliefs... hehe (and often
he is in fact correct).
Black boxing is never required for the code to function. It's a way of organizing code so that some parts are available for use but not for change. My question centers around the rationale behind the language feature, and I was trying to guess at and imagine what it could be useful for. I've seen many cobol books, but few of them give any kind of rationale as to why the standard is defined the way it is, so it would seem to me that falling back on the collective memory of experienced programmers would be the way to proceed.
The calculation of compound interest involves a simple formula. I don't know whether there is a function for raising numbers to a power, but if there isn't, then logarithms and the exponential function would be the way to go. A-priori, this seems to me like something I'd like to perform in a single COMPUTE statement, but you may have other ideas.
Mayer
COBOL supports the ** operator (exponentiation), so for example,
square root becomes A ** 0.5 and etc.
On Thursday, September 27, 2018 at 6:29:14 AM UTC+3, Mayer Goldberg wrote:
Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
On Thursday, 27 September 2018 04:29:14 UTC+1, Mayer Goldberg wrote:--- Synchronet 3.20a-Linux NewsLink 1.114
Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
They were particularly useful before the adoption of the COBOL 85 standard with its scope delimiters such as END-IF and END-PERFORM to avoid the perform para thru para construct. They are used to compartment related groups of paragraphs and statements into higher level logical elements with meaningful names for those logical groups for easier comprehension. It is not advisable to use them in a program already written with perform thru statements, where subsequent amendments may be made by programmers that do not remember that sections only end when another section is specified.
On Friday, September 28, 2018 at 8:47:38 AM UTC+3, Richard wrote:
On Friday, September 28, 2018 at 1:34:12 PM UTC+12, docd...@panix.com wrote:
Any decent, sane, well-educated and properly-experienced COBOL programmer
will have learned that GO TO is permitted under three, and only three, conditions:
That is 3 more than I would permit!
A go to to the top of the current paragraph (which doc permits :-) ) is useful for optimizing tail-recursive calls, which isn't something normally done in cobol, but which is useful, e.g., if you were to solve e.g., the towers of hanoi problem in cobol.
To optimize tail-calls in general, and not necessarily tail-recursive calls, would require a go to to other paragraphs (which doc does not permit), so I guess I'll just skip that optimization... Anyway, it's not very important in business programming.
On Friday, 28 September 2018 15:24:17 UTC+1, Mayer Goldberg wrote:Right. This makes perfect sense.
On Friday, September 28, 2018 at 8:47:38 AM UTC+3, Richard wrote:
On Friday, September 28, 2018 at 1:34:12 PM UTC+12, docd...@panix.com wrote:
Any decent, sane, well-educated and properly-experienced COBOL programmer
will have learned that GO TO is permitted under three, and only three, conditions:
That is 3 more than I would permit!
A go to to the top of the current paragraph (which doc permits :-) ) is useful for optimizing tail-recursive calls, which isn't something normally done in cobol, but which is useful, e.g., if you were to solve e.g., the towers of hanoi problem in cobol.
To optimize tail-calls in general, and not necessarily tail-recursive calls, would require a go to to other paragraphs (which doc does not permit), so I guess I'll just skip that optimization... Anyway, it's not very important in business programming.
I should add that if GO TO is used within a section, it is highly inadvisable for it to be used to transfer control outside that section.
I should add that if GO TO is used within a section, it is highly inadvisable <strike>for it to be used to transfer control outside that section</strike>.
I was SURE sections in the procedure division were used for grouping code! But then doc wrote that this wasn't a good enough reason to use them, which may be the case. I really have no idea. As weird as this seems to sound to some people here, I really do take a liking to this language and really do try to understand it, knowing full well that hardly anyone is ever going to use and modify the code I write in it.
Mayer
On 9/28/2018 9:34 AM, Mayer Goldberg wrote:IIRC, 52K; the other 8K was taken up by OS/360. :->
I was SURE sections in the procedure division were used for grouping
code! But then doc wrote that this wasn't a good enough reason to use
them, which may be the case. I really have no idea. As weird as this
seems to sound to some people here, I really do take a liking to this
language and really do try to understand it, knowing full well that
hardly anyone is ever going to use and modify the code I write in it.
Mayer
The reason few people use sections for code overlays is that modern
hardware has far more memory available, so there is no need to page in
or page out sections of your procedure division in order to fit into 64K bytes of memory.
The whole point of COBOL is that it is a business accounting language.
Code is expected to be modified. Tax laws change every year. Business
rules change every year. Therefore, having code that (in theory) is
easy to read and understand would make it easier for a different author
to modify the code.
One problem for anyone learning COBOL is that it's difficult to find
good, free samples of COBOL code to read. Businesses generally consider their COBOL code to be proprietary, and don't like to just share it.
Here are some resources for example programs in COBOL:
https://open-cobol.sourceforge.io/faq/index.html
https://open-cobol.sourceforge.io/faq/gcfaq.html#rosetta-code
http://rosettacode.org/wiki/Category:COBOL
http://speleotrove.com/decimal/telco.html
Kind Regards,
Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
=========SUBROUTINES ACTIVATED FROM THE ABOVE MAINLINE CODEOPEN-FILES SECTION.
The rules are (all 2 of them...):
1. Avoid using GO TO and if you do so, the ONLY permissible target is
the exit from the SECTION YOU ARE IN.
2. You must only PERFORM a SECTION (or use a scope delimited inline PERFORM.)
Pretty simple.
I have coded COBOL like this for well over 30 years now and nobody ever complained about maintaining my code... :-)
However, for me, the best spinoff from this is that when you move to OO COBOL, what used to be a SECTION, now becomes a Method and it gets
INVOKED instead of PERFORMED. The whole paradigm shift is made easier if
the original COBOL was already separated by function and, for me at
least, using SECTIONS facilitates that.
Obviously, the way in which you code is a choice for each individual programmer and there will always be pros and cons of any approach. Use
what you feel comfortable with but be aware that others will have other styles and that doesn't mean they are "wrong"... a "good" programmer can understand and accommodate any style that complies with the language
syntax being used.
One problem for anyone learning COBOL is that it's difficult to find
good, free samples of COBOL code to read. Businesses generally consider their COBOL code to be proprietary, and don't like to just share it.
On 9/28/2018 9:34 AM, Mayer Goldberg wrote:
I was SURE sections in the procedure division were used for grouping code! But then doc wrote that this wasn't a good enough reason to use them, which may be the case. I really have no idea. As weird as this seems to sound to some people here, I really do take a liking to this language and really do try to understand it, knowing full well that hardly anyone is ever going to use and modify the code I write in it.
Mayer
The reason few people use sections for code overlays is that modern
hardware has far more memory available, so there is no need to page in
or page out sections of your procedure division in order to fit into 64K bytes of memory.
The whole point of COBOL is that it is a business accounting language.
Code is expected to be modified. Tax laws change every year. Business rules change every year. Therefore, having code that (in theory) is
easy to read and understand would make it easier for a different author
to modify the code.
One problem for anyone learning COBOL is that it's difficult to find
good, free samples of COBOL code to read. Businesses generally consider their COBOL code to be proprietary, and don't like to just share it.
Here are some resources for example programs in COBOL:
https://open-cobol.sourceforge.io/faq/index.html
https://open-cobol.sourceforge.io/faq/gcfaq.html#rosetta-code
http://rosettacode.org/wiki/Category:COBOL
https://open-cobol.sourceforge.io/faq/gcfaq.html#what-about-gnucobol-and-benchmarks
http://speleotrove.com/decimal/telco.html
Kind Regards,
----- Synchronet 3.20a-Linux NewsLink 1.114
https://www.arnoldtrembley.com/
---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 27/09/2018 3:29 PM, Mayer Goldberg wrote:--- Synchronet 3.20a-Linux NewsLink 1.114
Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
I thought this might be a troll because the use of SECTIONs in COBOL
is an old chestnut that has provoked passionate protest and support in
the past, but as I glanced through the thread I see that some
respectable posters here have stated their opinions.
There are a number of good arguments for NOT using SECTIONS and you have seen them here.
When I first learned COBOL (1967) we always wrote PERFORM... THRU so
that the scope of the PERFORM was specifically stated. Very much the way that Doc suggested and using the rules he laid down.
However, as time went on and I was exposed to many different
implementations of COBOL around the World, I came to realize that there
is actually nothing wrong with using SECTIONS to group paragraphs and functions together logically, PROVIDED you observe some simple rules to
keep it consistent.
If you ONLY PERFORM a SECTION and never use THRU, then it can work
pretty well.
(Of course, it would be fatal to mix this approach with someone else's
code where they DON'T do that...).
It's kind of "nice" to structure your code into SECTIONS so you get
things like...
PROCEDURE DIVISION.
MAIN SECTION.
start-main.
perform initialize-it
perform do-the-biz
perform close-down.
end-main.
exit program.
INITIALIZE-IT SECTION.
start-init.
perform open-files
perform set-working-storage
...
end-init.
exit. *> if you REALLY need to GO TO this for some reason... DO-THE-BIZ SECTION.
start-processing.
...
end-processing.
exit. *> if you REALLY need to GO TO this for some reason... CLOSE-DOWN SECTION.
start-close.
perform close=files
perform clean-up
.
end-close.
exit. *> if you REALLY need to GO TO this for some reason...
=========SUBROUTINES ACTIVATED FROM THE ABOVE MAINLINE CODEOPEN-FILES SECTION.
start-open.
open... etc.
...
end-open.
exit. *> if you REALLY need to GO TO this for some reason... SET-WORKING-STORAGE SECTION.
... and so on.
It's a simple, clear, structure with each function easily locatable in
its own SECTION.
The rules are (all 2 of them...):
1. Avoid using GO TO and if you do so, the ONLY permissible target is
the exit from the SECTION YOU ARE IN.
2. You must only PERFORM a SECTION (or use a scope delimited inline PERFORM.)
Pretty simple.
I have coded COBOL like this for well over 30 years now and nobody ever complained about maintaining my code... :-)
However, for me, the best spinoff from this is that when you move to OO COBOL, what used to be a SECTION, now becomes a Method and it gets
INVOKED instead of PERFORMED. The whole paradigm shift is made easier if
the original COBOL was already separated by function and, for me at
least, using SECTIONS facilitates that.
Obviously, the way in which you code is a choice for each individual programmer and there will always be pros and cons of any approach. Use
what you feel comfortable with but be aware that others will have other styles and that doesn't mean they are "wrong"... a "good" programmer can understand and accommodate any style that complies with the language
syntax being used.
Pete.
--
I used to write COBOL; now I can do anything...
Re go to... As you can imagine, I am familiar with Dijksta's paper on the goto statement being considered harmful... :-) I don't think it's one of his better papers, and there are many ways to make spaghetti, goto being just one of them. If you follow his advice, you'll avoid the goto, invest in structured programming, and create your spaghetti code in other ways... This is one discussion I'm not going to get into. :-)
But since you brought up PERFORM ... THRU, I'll say that I can't imagine I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it is not in the middle of a PERFORM ... THRU sequence. To me, this seems like courting dissaster. Nothing in cobol scares me more than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
On Sunday, September 30, 2018 at 1:40:44 AM UTC+12, Mayer Goldberg wrote:
But since you brought up PERFORM ... THRU, I'll say that I can't imagine I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it is not in the middle of a PERFORM ... THRU sequence. To me, this seems like courting dissaster. Nothing in cobol scares me more than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
Hello:--- Synchronet 3.20a-Linux NewsLink 1.114
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
But since you brought up PERFORM ... THRU, I'll say that I can't imagine I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it is not in the middle of a PERFORM ... THRU sequence. To me, this seems like courting dissaster. Nothing in cobol scares me more than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
Re trolling, that would have to be one hell of a troll to learn enough toWhen I worked in IT Support at the local university, which at the time was still using IBM Mainframe technology, there was one professor in the College
ask a specific question like that. :-)
I have a thought that perhaps you're not the only person who thinks I'm a troll, so let me give you, and by extension, everyone else, an
introduction and an explanation:
When I was a student, cobol was literally a dirty word: The one instructor who used to teach cobol was ignored or made fun of to his face, until
finally the dept stopped teaching cobol as a service course, and he packed his bags and left elsewhere. I knew of him, but cobol was an introductory course offered to non-majors, and I was an MSc and PhD student, so I had
no real reason to interact with him. When I did get to know him, it was something like 2-3 months before he left: He was one of the nicer guys at
the dept. Very friendly, and very happy to answer questions. People
actually snickered when they saw me visit his office.
Now there's something contrarian about my personality, and when I got fedMy last job was with the State of Missouri, working on a COBOL-based
up with cobol jokes at the dept (told by people who didn't know any
cobol), I started looking at the language. I didn't have access to any
real cobol, so I went to this instructor for advice. He gave me an old
copy of RM Cobol for DOS that used to be handed out to students. In fact,
he gave me like 10 copies :-) It was not a nice system compared to the programming environments I was familiar with, but pretty soon I discovered the student edition of MF Cobol for DOS, which was inexpensive, and came
with some nice documentation. So I picked up a bit of cobol back in the 1980's. And then, as I moved to the Mac, and later to linux, I simply
didn't have a cobol to play with, and didn't want to use DOS under
emulation (DOS Box), so I forgot my cobol. I forgot the syntax, but remembered some of the ideas.
Now I do know that cobol is a business language, and that people here are
all serious about the business programming culture, etc. Well, I'm an outsider: I'm not looking for work in business programming, and whatever I write in cobol will probably never be seen by anyone other than myself.
But I study the ideas behind programming languages, and here is where I
find cobol interesting. I know what people in the academia think about
cobol (I myself am an academician), but I'm not interested in opinions
from people who don't know the language and have little or no insights
into it.
In some sense, cobol is actually a difficult language to learn: There's aWhen I worked as a contractor for the Bonneville Power Administration
lot of syntax, the semantics is generally simple until it becomes really tricky, and a lot of the pragmatics of the language (how best to use it)
does not appear in any book, but is passed on in the culture of cobol programming. That's why I'm here. I have no interest in trolling, and hope
to learn from people who spent the better part of their programming
careers writing in cobol.
Re go to... As you can imagine, I am familiar with Dijksta's paper on the goto statement being considered harmful... :-) I don't think it's one ofPERFORM THROUGH is, like SECTION, an obsolescent artifact which has been superceded by the PERFORM ... END-PERFORM construct.
his better papers, and there are many ways to make spaghetti, goto being
just one of them. If you follow his advice, you'll avoid the goto, invest
in structured programming, and create your spaghetti code in other ways... This is one discussion I'm not going to get into. :-)
But since you brought up PERFORM ... THRU, I'll say that I can't imagine
I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere
in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it
is not in the middle of a PERFORM ... THRU sequence. To me, this seems
like courting dissaster. Nothing in cobol scares me more than a PERFORM
... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
On Saturday, September 29, 2018 at 8:36:13 AM UTC+3, pete dashwood wrote:
On 27/09/2018 3:29 PM, Mayer Goldberg wrote:
Hello:I thought this might be a troll because the use of SECTIONs in COBOL
Can any cobol guru provide some insights into sections in the procedure
division: I don't see them used much in any of the cobol textbooks I
own or any of the cobol code I see, and I'd like to understand why.
They do have some interesting properties, and I can think of several
reasons why I might want to use them. On the other hand, I can't
imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
is an old chestnut that has provoked passionate protest and support in
the past, but as I glanced through the thread I see that some
respectable posters here have stated their opinions.
There are a number of good arguments for NOT using SECTIONS and you have
seen them here.
When I first learned COBOL (1967) we always wrote PERFORM... THRU so
that the scope of the PERFORM was specifically stated. Very much the way
that Doc suggested and using the rules he laid down.
However, as time went on and I was exposed to many different
implementations of COBOL around the World, I came to realize that there
is actually nothing wrong with using SECTIONS to group paragraphs and
functions together logically, PROVIDED you observe some simple rules to
keep it consistent.
If you ONLY PERFORM a SECTION and never use THRU, then it can work
pretty well.
(Of course, it would be fatal to mix this approach with someone else's
code where they DON'T do that...).
It's kind of "nice" to structure your code into SECTIONS so you get
things like...
PROCEDURE DIVISION.
MAIN SECTION.
start-main.
perform initialize-it
perform do-the-biz
perform close-down.
end-main.
exit program.
INITIALIZE-IT SECTION.
start-init.
perform open-files
perform set-working-storage
...
end-init.
exit. *> if you REALLY need to GO TO this for some reason...
DO-THE-BIZ SECTION.
start-processing.
...
end-processing.
exit. *> if you REALLY need to GO TO this for some reason...
CLOSE-DOWN SECTION.
start-close.
perform close=files
perform clean-up
.
end-close.
exit. *> if you REALLY need to GO TO this for some reason...
=========SUBROUTINES ACTIVATED FROM THE ABOVE MAINLINE CODEOPEN-FILES SECTION.
start-open.
open... etc.
...
end-open.
exit. *> if you REALLY need to GO TO this for some reason...
SET-WORKING-STORAGE SECTION.
... and so on.
It's a simple, clear, structure with each function easily locatable in
its own SECTION.
The rules are (all 2 of them...):
1. Avoid using GO TO and if you do so, the ONLY permissible target is
the exit from the SECTION YOU ARE IN.
2. You must only PERFORM a SECTION (or use a scope delimited inline
PERFORM.)
Pretty simple.
I have coded COBOL like this for well over 30 years now and nobody ever
complained about maintaining my code... :-)
However, for me, the best spinoff from this is that when you move to OO
COBOL, what used to be a SECTION, now becomes a Method and it gets
INVOKED instead of PERFORMED. The whole paradigm shift is made easier if
the original COBOL was already separated by function and, for me at
least, using SECTIONS facilitates that.
Obviously, the way in which you code is a choice for each individual
programmer and there will always be pros and cons of any approach. Use
what you feel comfortable with but be aware that others will have other
styles and that doesn't mean they are "wrong"... a "good" programmer can
understand and accommodate any style that complies with the language
syntax being used.
Pete.
--
I used to write COBOL; now I can do anything...
On Sunday, September 30, 2018 at 1:40:44 AM UTC+12, Mayer Goldberg wrote:Quite so; just like FORTRAN's famous COMEFROM statement. https://www.fortran.com/come_from.html
Re go to... As you can imagine, I am familiar with Dijksta's paper on the
goto statement being considered harmful... :-) I don't think it's one of
his better papers, and there are many ways to make spaghetti, goto being
just one of them. If you follow his advice, you'll avoid the goto, invest
in structured programming, and create your spaghetti code in other
ways... This is one discussion I'm not going to get into. :-)
But since you brought up PERFORM ... THRU, I'll say that I can't imagine
I'd ever use this statement. The idea that a specific sub-sequence of
contiguous paragraphs will be executed in sequence, just because
somewhere in the code there is a PERFORM ... THRU that ranges over them
is a scary thought: You can add paragraphs wherever you like EXCEPT in
the middle of such a sequence of paragraphs... This means that when you
need to add a paragraph, you must first make sure that wherever you plan
on sticking it is not in the middle of a PERFORM ... THRU sequence. To
me, this seems like courting dissaster. Nothing in cobol scares me more
than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ...
CORRESPONDING. Nothing.
In fact there is nothing wrong with GO TO. When a GO TO is encountered
when examining code it is very clear what happens, the logic is obvious.
The problem with using GO TO in programs is that there must be a label
that is the target. This means that every label is potentially the target
of a GO TO. When examining code (written by someone else) then, when a
label is encountered, the whole program must be scanned to see if the
logic flow can arrive at that label from elsewhere.
By eliminating GO TO in all its forms and the structures that enable it: PERFORM section and PERFORM THRU; only allowing PERFORM paragraph, then
all procedure logic is local. Every label terminates the perform of the paragraph above and is only accessible by a PERFORM which, in turn, is terminated by the next label. New procedures can be added anywhere before
an existing label knowing that this will never break existing logic. This allows simplification of code by breaking deep logic into performed procedures that are close by without the overhead of searching for a
location where they won't break existing code, setting up a section or
thru, giving it a level number. Just cut and copy code to the end of the paragraph, give it a new label, and perform it.
Getting rid of the overhead and clutter encourages simpler procedures, smaller paragraphs that are easier to understand and maintain.
Other languages enforce this by having different types of labels:
subroutine and method labels cannot be the target of a goto; this enforced localization of logic. COBOL introduced mechanisms that also enforced
logic localization: nested procedures and OO with methods; but these have been generally ignored.
As Pete says: OO was a revelation; but it was so (IMHO) in relation to his PERFORM THRU structure because methods enforced the localization that was achievable by elimination of THRU, sections and GO TO in COBOL-85.
Richard wrote:
On Sunday, September 30, 2018 at 1:40:44 AM UTC+12, Mayer Goldberg wrote:
Re go to... As you can imagine, I am familiar with Dijksta's paper on the >> goto statement being considered harmful... :-) I don't think it's one of >> his better papers, and there are many ways to make spaghetti, goto being >> just one of them. If you follow his advice, you'll avoid the goto, invest >> in structured programming, and create your spaghetti code in other
ways... This is one discussion I'm not going to get into. :-)
But since you brought up PERFORM ... THRU, I'll say that I can't imagine >> I'd ever use this statement. The idea that a specific sub-sequence of
contiguous paragraphs will be executed in sequence, just because
somewhere in the code there is a PERFORM ... THRU that ranges over them
is a scary thought: You can add paragraphs wherever you like EXCEPT in
the middle of such a sequence of paragraphs... This means that when you
need to add a paragraph, you must first make sure that wherever you plan >> on sticking it is not in the middle of a PERFORM ... THRU sequence. To
me, this seems like courting dissaster. Nothing in cobol scares me more
than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ...
CORRESPONDING. Nothing.
In fact there is nothing wrong with GO TO. When a GO TO is encounteredQuite so; just like FORTRAN's famous COMEFROM statement. https://www.fortran.com/come_from.html
when examining code it is very clear what happens, the logic is obvious.
:-D
Leslie
The problem with using GO TO in programs is that there must be a label
that is the target. This means that every label is potentially the target of a GO TO. When examining code (written by someone else) then, when a label is encountered, the whole program must be scanned to see if the
logic flow can arrive at that label from elsewhere.
By eliminating GO TO in all its forms and the structures that enable it: PERFORM section and PERFORM THRU; only allowing PERFORM paragraph, then
all procedure logic is local. Every label terminates the perform of the paragraph above and is only accessible by a PERFORM which, in turn, is terminated by the next label. New procedures can be added anywhere before an existing label knowing that this will never break existing logic. This allows simplification of code by breaking deep logic into performed procedures that are close by without the overhead of searching for a location where they won't break existing code, setting up a section or thru, giving it a level number. Just cut and copy code to the end of the paragraph, give it a new label, and perform it.
Getting rid of the overhead and clutter encourages simpler procedures, smaller paragraphs that are easier to understand and maintain.
Other languages enforce this by having different types of labels: subroutine and method labels cannot be the target of a goto; this enforced localization of logic. COBOL introduced mechanisms that also enforced
logic localization: nested procedures and OO with methods; but these have been generally ignored.
As Pete says: OO was a revelation; but it was so (IMHO) in relation to his PERFORM THRU structure because methods enforced the localization that was achievable by elimination of THRU, sections and GO TO in COBOL-85.
--
JLT
Hello:If anything, cobol makes it very easy to process data efficiently, because it encourages a highly-structured, tabular form, as opposed to the free-form output that most other programming languages allow programmers to generate. Cobol programs can of course generate any format, but then processing such format would be computationally intensive and require parsing.
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
Hello:There's something here I don't get. First off, you have a rigid numbering convention, so you're performing from 200-something to 299-something... This is already one hint to the programmer, not to insert paragraphs in the numbered paragraphs unless they plan them to be a part of this sequence. So if you program like this, you're right, it's less confusing. On the other thand, what do you do with a joker that has perform 200-something thru 299-something, and then perform 241-something thru 276-something, and then perform 239-something thru 299-something, etc. Now you have multiple entry points and multiple exit points, and the code is as hard to figure out as anything else you could write. So obviously, you must have some additional conventions that would preclude this kind of programming.
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
On Thursday, September 27, 2018 at 6:29:14 AM UTC+3, Mayer Goldberg wrote:There are two key words in there: "Rigid" and "joker."
Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
There's something here I don't get. First off, you have a rigid numbering convention, so you're performing from 200-something to 299-something... This is already one hint to the programmer, not to insert paragraphs in the numbered paragraphs unless they plan them to be a part of this sequence. So if you program like this, you're right, it's less confusing. On the other thand, what do you do with a joker that has perform 200-something thru 299-something, and then perform 241-something thru 276-something, and then perform 239-something thru 299-something, etc. Now you have multiple entry points and multiple exit points, and the code is as hard to figure out as anything else you could write. So obviously, you must have some additional conventions that would preclude this kind of programming.
On Sat, 29 Sep 2018 14:46:16 -0700 (PDT), Mayer Goldberg <mayer.goldberg@gmail.com> wrote:Ok. Very good: Now please tell me what textbook on cobol will teach me coding conventions. I know they'll change from one shop to the next, but please recommend a document that will have naming and numbering conventions, as well as other conventions --- the kind of stuff without which it's impossible to write large systems, and with these it's actually doable. :-)
On Thursday, September 27, 2018 at 6:29:14 AM UTC+3, Mayer Goldberg wrote: >> Hello:
Can any cobol guru provide some insights into sections in the procedure division: I don't see them used much in any of the cobol textbooks I own or any of the cobol code I see, and I'd like to understand why. They do have some interesting properties, and I can think of several reasons why I might want to use them. On the other hand, I can't imagine why people would avoid them. Can anyone suggest some reasons?
Thanks,
Mayer
There's something here I don't get. First off, you have a rigid numbering convention, so you're performing from 200-something to 299-something... This is already one hint to the programmer, not to insert paragraphs in the numbered paragraphs unless they plan them to be a part of this sequence. So if you program like this, you're right, it's less confusing. On the other thand, what do you do with a joker that has perform 200-something thru 299-something, and then perform 241-something thru 276-something, and then perform 239-something thru 299-something, etc. Now you have multiple entry points and multiple exit points, and the code is as hard to figure out as anything else you could write. So obviously, you must have some additional conventions that would preclude this kind of programming.
There are two key words in there: "Rigid" and "joker."
In a COBOL shop, the paragraph numbering convention is rigid, the
entire coding standard is often rigid, and sometimes even the dress
code is rigid. Jokers and people with wide ties are generally not made
to feel welcome.
C++ shops, on the other hand, are consensus-driven places where people
and ideas are always judged on their merit. Yes, I'm joking.
Louis
On Sat, 29 Sep 2018 06:40:42 -0700 (PDT), Mayer Goldberg <mayer.goldberg@gmail.com> wrote:
<snip>
But since you brought up PERFORM ... THRU, I'll say that I can't imagine I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it is not in the middle of a PERFORM ... THRU sequence. To me, this seems like courting dissaster. Nothing in cobol scares me more than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
Like anything else, PERFORM THRU is OK as long as it's used carefullyThere _are_ several problems that I find with your style.
and consistently, as in:
...
perform 0200-do-something thru 0299-do-something-end.
...
stop run.
0200-do-something.
...
...
if error then
...
go to 0299-do-something-end.
...
...
0299-do-something-end.
exit.
If I recall correctly, there were versions of COBOL that didn't have
EXIT PARAGRAPH, and PERFORM THRU with a branch to an "end" paragraph
was one way of allowing a quick return to the caller.
If paragraph sequences are kept short and simple, there shouldn't be
much temptation to add paragraphs in the middle. And the inline
PERFORM makes it easier to code loops without adding new paragraphs.
Please post your reply below the dashes; it keeps us old folks happy,
or at least happier...
Louis
----------------------------------------------------------------------------------------------------------------------
Ok. Very good: Now please tell me what textbook on cobol will teach me coding conventions. I know they'll change from one shop to the next, but please recommend a document that will have naming and numbering conventions, as well as other conventions --- the kind of stuff without which it's impossible to write large systems, and with these it's actually doable. :-)I have never used any 'numbering convention' because I have never used numbering. It would have been useful in the days of punch cards and lineflow in the 60s (which is where I started - 50 years this month!) and where programs ran to thousands of lines of code. My large systems were based on CALL CANCEL to modularize them and didn't need the bureaucracy (or tyranny) of performed sections, perform thru and the need to lay these out by perform level.
BTW: I studied at Aarhus University, where Stroustrup got his BSc, and the good folks over there don't have many positive things to say about C++, and neither do I. :-)
On Sunday, September 30, 2018 at 11:23:24 AM UTC+13, Mayer Goldberg wrote:Perhaps I don't understand: Is call for external subroutines that are linked with the executable, or for external programs that need to invoked as with the fork/pipe/dup/exec mechanism in C/linux?
Ok. Very good: Now please tell me what textbook on cobol will teach me coding conventions. I know they'll change from one shop to the next, but please recommend a document that will have naming and numbering conventions, as well as other conventions --- the kind of stuff without which it's impossible to write large systems, and with these it's actually doable. :-)
BTW: I studied at Aarhus University, where Stroustrup got his BSc, and the good folks over there don't have many positive things to say about C++, and neither do I. :-)
I have never used any 'numbering convention' because I have never used numbering. It would have been useful in the days of punch cards and lineflow in the 60s (which is where I started - 50 years this month!) and where programs ran to thousands of lines of code. My large systems were based on CALL CANCEL to modularize them and didn't need the bureaucracy (or tyranny) of performed sections, perform thru and the need to lay these out by perform level.
In a COBOL shop, the paragraph numbering convention is rigid, theI was contracted to do work in P&O in London a couple of decades ago where they did have a dress code. I haven't owned a suit for 35 years and haven't worn business shirts and tie either. I was approached and informed that there was a dress code. I just answered: "It's OK, I'm from New Zealand" and he wandered off and nothing more was said.
entire coding standard is often rigid, and sometimes even the dress
code is rigid. Jokers and people with wide ties are generally not made
to feel welcome.
On Sunday, September 30, 2018 at 11:17:41 AM UTC+13, Louis Krupp wrote:Ahh, a Kiwi! :-) Katherine Mansfield is my favourite poet! :-)
In a COBOL shop, the paragraph numbering convention is rigid, the
entire coding standard is often rigid, and sometimes even the dress
code is rigid. Jokers and people with wide ties are generally not made
to feel welcome.
I was contracted to do work in P&O in London a couple of decades ago where they did have a dress code. I haven't owned a suit for 35 years and haven't worn business shirts and tie either. I was approached and informed that there was a dress code. I just answered: "It's OK, I'm from New Zealand" and he wandered off and nothing more was said.
Fortunately, my contract was with someone fairly high up in the organization and it was my code that was being implemented for them.
On 09/29/2018 01:36 AM, pete dashwood wrote:
The rules are (all 2 of them...):
1. Avoid using GO TO and if you do so, the ONLY permissible target is
the exit from the SECTION YOU ARE IN.
2. You must only PERFORM a SECTION (or use a scope delimited inline
PERFORM.)
Pretty simple.
I have coded COBOL like this for well over 30 years now and nobody
ever complained about maintaining my code... :-)
This is, by far, the most important comment.
I can say the same
thing. I remember stopping by the shop at West Point for a visit
where I did a lot of COBOL programming more than 20 years after
I had left. When one of the few people remaining from my days
there introduced me to one of the newer programmers he looked
up from the listing he was pondering and asked, "Is he the
William Gunshannon who wrote this program?" What better
compliment can there be then to see your work still in use
after more than two decades. It also strongly attacks the myth
of code written unintelligibly for job security.
However, for me, the best spinoff from this is that when you move to
OO COBOL, what used to be a SECTION, now becomes a Method and it gets
INVOKED instead of PERFORMED. The whole paradigm shift is made easier
if the original COBOL was already separated by function and, for me at
least, using SECTIONS facilitates that.
And if the code was already working just fine for some unspecified
length of time, what, exactly, does one gain by rewriting it in OO?
Obviously, the way in which you code is a choice for each individual
programmer and there will always be pros and cons of any approach. Use
what you feel comfortable with but be aware that others will have
other styles and that doesn't mean they are "wrong"... a "good"
programmer can understand and accommodate any style that complies with
the language syntax being used.
And a bad paradigm can obfuscate even the best of code.
Thanks for the code samples! This will be very helpful.
Mayer
Re trolling, that would have to be one hell of a troll to learn enough to ask a specific question like that. :-)
I have a thought that perhaps you're not the only person who thinks I'm a troll, so let me give you, and by extension, everyone else, an introduction and an explanation:
When I was a student, cobol was literally a dirty word: The one instructor who used to teach cobol was ignored or made fun of to his face, until finally the dept stopped teaching cobol as a service course, and he packed his bags and left elsewhere. I knew of him, but cobol was an introductory course offered to non-majors, and I was an MSc and PhD student, so I had no real reason to interact with him. When I did get to know him, it was something like 2-3 months before he left: He was one of the nicer guys at the dept. Very friendly, and very happy to answer questions. People actually snickered when they saw me visit his office.
Now there's something contrarian about my personality, and when I got fed up with cobol jokes at the dept (told by people who didn't know any cobol), I started looking at the language. I didn't have access to any real cobol, so I went to this instructor for advice. He gave me an old copy of RM Cobol for DOS that used to be handed out to students. In fact, he gave me like 10 copies :-) It was not a nice system compared to the programming environments I was familiar with, but pretty soon I discovered the student edition of MF Cobol for DOS, which was inexpensive, and came with some nice documentation. So I picked up a bit of cobol back in the 1980's. And then, as I moved to the Mac, and later to linux, I simply didn't have a cobol to play with, and didn't want to use DOS under emulation (DOS Box), so I forgot my cobol. I forgot the syntax, but remembered some of the ideas.
Now I do know that cobol is a business language, and that people here are all serious about the business programming culture, etc. Well, I'm an outsider: I'm not looking for work in business programming, and whatever I write in cobol will probably never be seen by anyone other than myself. But I study the ideas behind programming languages, and here is where I find cobol interesting. I know what people in the academia think about cobol (I myself am an academician), but I'm not interested in opinions from people who don't know the language and have little or no insights into it.
In some sense, cobol is actually a difficult language to learn: There's a lot of syntax, the semantics is generally simple until it becomes really tricky, and a lot of the pragmatics of the language (how best to use it) does not appear in any book, but is passed on in the culture of cobol programming. That's why I'm here. I have no interest in trolling, and hope to learn from people who spent the better part of their programming careers writing in cobol.
Re go to... As you can imagine, I am familiar with Dijksta's paper on the goto statement being considered harmful... :-) I don't think it's one of his better papers, and there are many ways to make spaghetti, goto being just one of them. If you follow his advice, you'll avoid the goto, invest in structured programming, and create your spaghetti code in other ways... This is one discussion I'm not going to get into. :-)
But since you brought up PERFORM ... THRU, I'll say that I can't imagine I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it is not in the middle of a PERFORM ... THRU sequence. To me, this seems like courting dissaster. Nothing in cobol scares me more than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
On Sunday, September 30, 2018 at 11:23:24 AM UTC+13, Mayer Goldberg wrote:
Ok. Very good: Now please tell me what textbook on cobol will teach me coding conventions. I know they'll change from one shop to the next, but please recommend a document that will have naming and numbering conventions, as well as other conventions --- the kind of stuff without which it's impossible to write large systems, and with these it's actually doable. :-)
BTW: I studied at Aarhus University, where Stroustrup got his BSc, and the good folks over there don't have many positive things to say about C++, and neither do I. :-)
I have never used any 'numbering convention' because I have never used numbering. It would have been useful in the days of punch cards and lineflow in the 60s (which is where I started - 50 years this month!) and where programs ran to thousands of lines of code. My large systems were based on CALL CANCEL to modularize them and didn't need the bureaucracy (or tyranny) of performed sections, perform thru and the need to lay these out by perform level.
On Sunday, September 30, 2018 at 11:17:41 AM UTC+13, Louis Krupp wrote:
In a COBOL shop, the paragraph numbering convention is rigid, the
entire coding standard is often rigid, and sometimes even the dress
code is rigid. Jokers and people with wide ties are generally not made
to feel welcome.
I was contracted to do work in P&O in London a couple of decades ago where they did have a dress code. I haven't owned a suit for 35 years and haven't worn business shirts and tie either. I was approached and informed that there was a dress code. I just answered: "It's OK, I'm from New Zealand" and he wandered off and nothing more was said.
Fortunately, my contract was with someone fairly high up in the organization and it was my code that was being implemented for them.
Amen to that!Yes, if only that were the common response; but more often than not
(I am probably the ONLY person here who has ever defended the use of
ALTER but I believe it is like everything else: if you find a construct
in a language that is potentially disastrous, don't ban it in the local standards, teach people to understand it and use it responsibly.
It's kind of sad (IMO) that the vendors bowed to pressure from the User Groups and dropped it from the language. I remember using it in a system
in the late 1960s where it was a lot like switching points in a Railway marshalling yard... and it was MUCH more efficient on the platform where
it was running (Burroughs B500) than a COBOL IF...)
<snipped>
Pete.
Fortran doesn't really have COME FROM! :-) The article said it would demonstrate COME FROM using fortran syntax. In fact, COME FROM is Intercal (https://en.wikipedia.org/wiki/INTERCAL) and there actually was a compiler for it at some point.Sure, but the article itself is funny, which proves that FORTRAN
Fortran is too serious a language to will have added tongue-in-cheek constructs just to get laughs... :-)
On Sunday, September 30, 2018 at 1:54:02 AM UTC+3, Richard wrote:
On Sunday, September 30, 2018 at 11:17:41 AM UTC+13, Louis Krupp wrote:
In a COBOL shop, the paragraph numbering convention is rigid, the
entire coding standard is often rigid, and sometimes even the dress
code is rigid. Jokers and people with wide ties are generally not made
to feel welcome.
I was contracted to do work in P&O in London a couple of decades ago where they did have a dress code. I haven't owned a suit for 35 years and haven't worn business shirts and tie either. I was approached and informed that there was a dress code. I just answered: "It's OK, I'm from New Zealand" and he wandered off and nothing more was said.
Fortunately, my contract was with someone fairly high up in the organization and it was my code that was being implemented for them.
Ahh, a Kiwi! :-) Katherine Mansfield is my favourite poet! :-)
Short reason: there's no need for them (except when Site Standards
require their use, in which case my hourly rate just went up).
Are they marked off as deprecated?
Longer reason: since code should be written so that it is
maintainable and fewer maintenance programmers are being trained in
the use of Sections then the use of Sections should be avoided.
Not many programmers are being trained to use cobol, so by that reasoning...
'Interesting' is the very last reason to write a piece of code in a
given manner. Bulletproof code is boring. Write boring code.
I'm trying to learn.
Thank you for your help.
Another reason has to do with grouping related pieces of code >>>(paragraphs), and in fact, stating that the internal paragraphs
should not be accessed directly, and rather the entire section
should be taken as a "black box".
This is exactly a reason not to use SECTIONs. Code is written to be
maintained and anything that requires 'black boxing' - for example,
the calculation of compound interest - should be neither a paragraph
nor a SECTION.
(whoever dares to ask 'if it's neither a paragraph nor a SECTION then how
does the code get executed?' is brave)
I don't get this "brave" stuff, sorry: I'm here to learn, I'm not
playing ego games, I asked a simple question in a relevant forum: What
is the rationale for having a specific language feature (sections in the >procedure division). The answer ought to be the rationale. Admonitions
do not address the question.
Black boxing is never required for the code to function. It's a way of >organizing code so that some parts are available for use but not for
change.
My question centers around the rationale behind the language
feature, and I was trying to guess at and imagine what it could be
useful for.
I've seen many cobol books, but few of them give any kind of
rationale as to why the standard is defined the way it is, so it would
seem to me that falling back on the collective memory of experienced >programmers would be the way to proceed.
The calculation of compound interest involves a simple formula. I don't
know whether there is a function for raising numbers to a power, but if
there isn't, then logarithms and the exponential function would be the
way to go. A-priori, this seems to me like something I'd like to perform
in a single COMPUTE statement, but you may have other ideas.
I was SURE sections in the procedure division were used for grouping
code!
On Sunday, September 30, 2018 at 9:58:25 AM UTC+13, Louis Krupp wrote:
On Sat, 29 Sep 2018 06:40:42 -0700 (PDT), Mayer Goldberg
<mayer.goldberg@gmail.com> wrote:
<snip>
But since you brought up PERFORM ... THRU, I'll say that I can't imagine I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it is not in the middle of a PERFORM ... THRU sequence. To me, this seems like courting dissaster. Nothing in cobol scares me more than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
Like anything else, PERFORM THRU is OK as long as it's used carefully
and consistently, as in:
...
perform 0200-do-something thru 0299-do-something-end.
...
stop run.
0200-do-something.
...
...
if error then
...
go to 0299-do-something-end.
...
...
0299-do-something-end.
exit.
If I recall correctly, there were versions of COBOL that didn't have
EXIT PARAGRAPH, and PERFORM THRU with a branch to an "end" paragraph
was one way of allowing a quick return to the caller.
If paragraph sequences are kept short and simple, there shouldn't be
much temptation to add paragraphs in the middle. And the inline
PERFORM makes it easier to code loops without adding new paragraphs.
Please post your reply below the dashes; it keeps us old folks happy,
or at least happier...
Louis
----------------------------------------------------------------------------------------------------------------------
There _are_ several problems that I find with your style.
Have you not heard of 'ELSE' ?
The first is that a PERFORM added without the THRU would likely work and could pass all the tests _until_ an error occurred and then there would be complete garbage that would be difficult to diagnose.
Then there is the problem - which I have seen - where the wrong exit was used in the GO TO. Again it is difficult to diagnose.
I is difficult to verify that code has the correct THRU and the correct GO TO labels without a specific program that goes through the text to check these. Whereas if section, THRU and GO TO are disallowed a simple text search will validate this.
The other issue that I disagree with is the use of numbering. This would have been really useful when programming was done using card packs and lineflow listings, but that disappeared, for me, in the mid 70s. All that the numbering does now is increase the overhead when it should be easy to split a paragraph into two or more for code sharing or reducing indent levels. With numbering and THRU, and especially if the numbering insists that the levels of perform are required to be echoed in where procedures are located in the code, there is an incentive to _not_ break the code into simpler pieces. This can result in ramblingly long paragraphs.
On another note, I never* put a full stop at the end of a line, it is too easy to overlook it. Use END-IF and only have a full stop at the end of a paragraph and it simplifies cut and pasting a block of code to a new paragraph (immediately after current one) and replacing it with a PERFORM so that it can be shared or simply to make the code more readable.
* I haven't actually written any serious COBOL code for many years.I haven't written any COBOL code of any kind for many years.
In article <97d64a9a-b76d-4aef-b148-2966ac96b091@googlegroups.com>,Here is my reasoning:
Mayer Goldberg <mayer.goldberg@gmail.com> wrote:
I was SURE sections in the procedure division were used for grouping
code!
Your certainty might have been based on faulty reasoning. How did you come to the conclusion?
DD
On 30/09/2018 1:40 AM, Mayer Goldberg wrote:
Re trolling, that would have to be one hell of a troll to learn enough to ask a specific question like that. :-)
I have a thought that perhaps you're not the only person who thinks I'm a troll, so let me give you, and by extension, everyone else, an introduction and an explanation:
Let me assure you that, had I decided you were a troll, I would not have responded. On inspection I saw that your interest was genuine.
When I was a student, cobol was literally a dirty word: The one instructor who used to teach cobol was ignored or made fun of to his face, until finally the dept stopped teaching cobol as a service course, and he packed his bags and left elsewhere. I knew of him, but cobol was an introductory course offered to non-majors, and I was an MSc and PhD student, so I had no real reason to interact with him. When I did get to know him, it was something like 2-3 months before he left: He was one of the nicer guys at the dept. Very friendly, and very happy to answer questions. People actually snickered when they saw me visit his office.
Yes, I have encountered similar prejudices in industry during the late
1990s and the first decade of this century, where the COBOL guys were
"only" maintaining the "legacy" as the hot-shot Java people implemented
the Brave New World... :-)
One way I found to overcome this was to take an interest in the Java
stuff and talk/listen to the programmers (I taught myself Java at this time).
Then produce some COBOL code that did what they were doing and elicited responses like: "I didn't know you could do that in COBOL...", "Wow!
that's really cool... and in COBOL too..."
Once the "Class culture" between first and second class programmers was resolved and some mutual respect for both the languages and people was established, things generally progressed much more easily.
(It was around this time that I wrote the article on Cretaceous COBOL
and Jurassic Java, which was primarily aimed at Java programmers and Managers who get their information from in-flight magazines... https://dzone.com/articles/cretaceous-cobol-can-spawn
More than 16000 people have read this article and nobody "like"d it...
:-) (Given that the audience are mainly Java guys, I count that as a success... :-))
Some years ago, I actually wrote an exam question for a compilers course, that asked about how ALTER can be implemented, i.e., translated into assembly language, and what are the advantages and disadvantages of either approach, both for older architectures and modern ones... Even though my students didn't know cobol, this was a great question, IMO.Now there's something contrarian about my personality, and when I got fed up with cobol jokes at the dept (told by people who didn't know any cobol), I started looking at the language. I didn't have access to any real cobol, so I went to this instructor for advice. He gave me an old copy of RM Cobol for DOS that used to be handed out to students. In fact, he gave me like 10 copies :-) It was not a nice system compared to the programming environments I was familiar with, but pretty soon I discovered the student edition of MF Cobol for DOS, which was inexpensive, and came with some nice documentation. So I picked up a bit of cobol back in the 1980's. And then, as I moved to the Mac, and later to linux, I simply didn't have a cobol to play with, and didn't want to use DOS under emulation (DOS Box), so I forgot my cobol. I forgot the syntax, but remembered some of the ideas.
Now I do know that cobol is a business language, and that people here are all serious about the business programming culture, etc. Well, I'm an outsider: I'm not looking for work in business programming, and whatever I write in cobol will probably never be seen by anyone other than myself. But I study the ideas behind programming languages, and here is where I find cobol interesting. I know what people in the academia think about cobol (I myself am an academician), but I'm not interested in opinions from people who don't know the language and have little or no insights into it.
This is a "proper" attitude and makes you welcome here, Mayer.
In some sense, cobol is actually a difficult language to learn: There's a lot of syntax, the semantics is generally simple until it becomes really tricky, and a lot of the pragmatics of the language (how best to use it) does not appear in any book, but is passed on in the culture of cobol programming. That's why I'm here. I have no interest in trolling, and hope to learn from people who spent the better part of their programming careers writing in cobol.
Re go to... As you can imagine, I am familiar with Dijksta's paper on the goto statement being considered harmful... :-) I don't think it's one of his better papers, and there are many ways to make spaghetti, goto being just one of them. If you follow his advice, you'll avoid the goto, invest in structured programming, and create your spaghetti code in other ways... This is one discussion I'm not going to get into. :-)
But since you brought up PERFORM ... THRU, I'll say that I can't imagine I'd ever use this statement. The idea that a specific sub-sequence of contiguous paragraphs will be executed in sequence, just because somewhere in the code there is a PERFORM ... THRU that ranges over them is a scary thought: You can add paragraphs wherever you like EXCEPT in the middle of such a sequence of paragraphs... This means that when you need to add a paragraph, you must first make sure that wherever you plan on sticking it is not in the middle of a PERFORM ... THRU sequence. To me, this seems like courting dissaster. Nothing in cobol scares me more than a PERFORM ... THRU: Not GO TO, not ALTER, not MOVE ... CORRESPONDING. Nothing.
Amen to that!
(I am probably the ONLY person here who has ever defended the use of
ALTER but I believe it is like everything else: if you find a construct
in a language that is potentially disastrous, don't ban it in the local standards, teach people to understand it and use it responsibly.
It's kind of sad (IMO) that the vendors bowed to pressure from the User Groups and dropped it from the language. I remember using it in a system
in the late 1960s where it was a lot like switching points in a Railway marshalling yard... and it was MUCH more efficient on the platform where
it was running (Burroughs B500) than a COBOL IF...)
<snipped>
Pete.
--
I used to write COBOL; now I can do anything...
On 30/09/2018 1:09 AM, Mayer Goldberg wrote:Most of my time is spent on actual programming. But when I study a language I like to compare it to languages I already know and think hard about the differences. So I'll explain why I seem obsessive about sections in the procedure division --- this is something I've been thinking about, on and off, since I first noticed this in the 1980's, when I took my first cursory look at cobol: People criticise cobol for being in the spaghetti business for supposedly misusing GO TO with reckless abandon. :-) I don't need to tell you, in a forum of other cobol programmers, that this hasn't been true for years, and that cobol programming practices, more than in other languages, are rigidly controlled/policed on the grounds that the code must be understood by others, be easy to debug, etc. So in fact, cobol programs written for the 1985 standard or later, tend to be relatively free of unrestricted GO TOs. But what I realized was that GO TO to sections actually RETURNED at the end of the section. This means that GO TO to sections were not really unconditional jumps in the Dijkstra sense, but rather curious control operators that are more similar to PERFORM ... THRU for paragraphs. Now I don't use PERFORM ... THRU, so I won't be using GO TO to sections. But the similarity was curious. The books I read just laid out the standard, censored a bit for "bad practices", and gave no reasoning as to the design issues. Most cobol programmers I knew at the time had no idea that go to to a section returned at the end of the section... In fact, they had never heard of sections in the procedure division, or have heard but have never used them. So I knew there's an issue here, that there's some rationale I'm not getting.
Thanks for the code samples! This will be very helpful.
Mayer
It has been my experience across many different programming languages
and platforms that examining examples and reading conceptual background
can only take you so far...
The best way to come to grips with a new language or programming
paradigm is to change some code written in it or to start writing your
own simple programs.
(Programming success, like many things in life, requires intangibles
like confidence as well as practical skills... Confidence comes from
action rather than thought...)
Part of my job across the years has been to effect "skills transfer".
(What this really means is that people who are paying serious money for
my time, actually want to extract something tangible that remains after
I've gone... :-)) In my early years I trained as a teacher so you'd
think I wouldn't have any trouble passing knowledge on to others.
But, everybody is different and people learn differently. Some people respond really well to pictures and charts, others struggle with it
until you show them a code snippet and then the light goes on.
If you found the code helpful then the time to write it was well spent.
I wish you well with your COBOL programming.
<unreferenced remainder snipped>
Pete.
--
I used to write COBOL; now I can do anything...
But what I realized was that GO TO to sections actually RETURNED at the end of the section.<snip>
This means that GO TO to sections were not really unconditional jumps in the Dijkstra sense, but rather curious control operators that are more similar to PERFORM ... THRU for paragraphs. Now I don't use PERFORM ... >THRU, so I won't be using GO TO to sections.
The thing that caught my eyes back in the 1980's, when I first took a look at cobol, was that a GO TO to a section RETURNED at the end of the section. This means that go to to sections, rather than paragraphs, are NOT THE SAME as the goto statements referred to in e.g., Dijkstra's [in]famous admonotion, and that GO TO to a section really behaves like a PERFORM ... THRU.
On Sunday, September 30, 2018 at 11:54:23 PM UTC+13, Mayer Goldberg wrote:
The thing that caught my eyes back in the 1980's, when I first took a look at cobol, was that a GO TO to a section RETURNED at the end of the section. This means that go to to sections, rather than paragraphs, are NOT THE SAME as the goto statements referred to in e.g., Dijkstra's [in]famous admonotion, and that GO TO to a section really behaves like a PERFORM ... THRU.
THAT IS NOT TRUE AT ALL.I just checked this in gnu cobol, which is the only cobol I have at the moment, and you seem to be correct. I don't remember how and on what system I checked this on back then... :-( Thanks for your correction (same goes to Louis), which prompted me to re-test.
A GO TO _TO_ A SECTION WILL _NOT_ RETURN.
On Sunday, September 30, 2018 at 11:54:23 PM UTC+13, Mayer Goldberg wrote:
The thing that caught my eyes back in the 1980's, when I first took a look at cobol, was that a GO TO to a section RETURNED at the end of the section. This means that go to to sections, rather than paragraphs, are NOT THE SAME as the goto statements referred to in e.g., Dijkstra's [in]famous admonotion, and that GO TO to a section really behaves like a PERFORM ... THRU.
THAT IS NOT TRUE AT ALL.Also a go to out of a section does not terminate a performed section, problems would occur should the section be invoked while it still thinks it is being invoked. A section only terminates when it is exited properly, i.e. when there are no more statements in it to be executed. The end of a section is when a following section name defining a section is encountered or the end of the program is reached.
A GO TO _TO_ A SECTION WILL _NOT_ RETURN.
On Sunday, September 30, 2018 at 1:46:21 AM UTC+3, Richard wrote:CALL is to a COBOL subroutine which can be nested in the program, can be external but statically linked, or can be dynamically linked and loaded at run time in which case a CANCEL will unload the routine and free the memory that it used.
On Sunday, September 30, 2018 at 11:23:24 AM UTC+13, Mayer Goldberg wrote:
Ok. Very good: Now please tell me what textbook on cobol will teach me coding conventions. I know they'll change from one shop to the next, but please recommend a document that will have naming and numbering conventions, as well as other conventions --- the kind of stuff without which it's impossible to write large systems, and with these it's actually doable. :-)
BTW: I studied at Aarhus University, where Stroustrup got his BSc, and the good folks over there don't have many positive things to say about C++, and neither do I. :-)
I have never used any 'numbering convention' because I have never used numbering. It would have been useful in the days of punch cards and lineflow in the 60s (which is where I started - 50 years this month!) and where programs ran to thousands of lines of code. My large systems were based on CALL CANCEL to modularize them and didn't need the bureaucracy (or tyranny) of performed sections, perform thru and the need to lay these out by perform level.
Perhaps I don't understand: Is call for external subroutines that are linked with the executable, or for external programs that need to invoked as with the fork/pipe/dup/exec mechanism in C/linux?
There are NO COBOL numbering conventions that are laid down by theWhich was really useful when the source code moved from trays of punched cards to source libraries on mag tape. Then you could get the source renumbered to, say, hundreds, and then working from a lineflow listing you could write new or replaced lines using the numbers and have the computer merge these cards into the main source without needed to laboriously merge them into the card tray yourself.
language (except the one about columns 1 - 6 being reserved for line numbers...).
On Sunday, September 30, 2018 at 11:54:23 PM UTC+13, Mayer Goldberg wrote:
The thing that caught my eyes back in the 1980's, when I first took a look at cobol, was that a GO TO to a section RETURNED at the end of the section. This means that go to to sections, rather than paragraphs, are NOT THE SAME as the goto statements referred to in e.g., Dijkstra's [in]famous admonotion, and that GO TO to a section really behaves like a PERFORM ... THRU.
THAT IS NOT TRUE AT ALL.
A GO TO _TO_ A SECTION WILL _NOT_ RETURN.
In article <bc1f4340-9a9e-40c4-be22-8f6e7449b987@googlegroups.com>,
Mayer Goldberg <mayer.goldberg@gmail.com> wrote:
Another reason has to do with grouping related pieces of code
(paragraphs), and in fact, stating that the internal paragraphs
should not be accessed directly, and rather the entire section
should be taken as a "black box".
This is exactly a reason not to use SECTIONs. Code is written to be
maintained and anything that requires 'black boxing' - for example,
the calculation of compound interest - should be neither a paragraph
nor a SECTION.
(whoever dares to ask 'if it's neither a paragraph nor a SECTION then how >>> does the code get executed?' is brave)
I don't get this "brave" stuff, sorry: I'm here to learn, I'm not
playing ego games, I asked a simple question in a relevant forum: What
is the rationale for having a specific language feature (sections in the
procedure division). The answer ought to be the rationale. Admonitions
do not address the question.
The question was addressed, clearly and unambiguously, with 'there's no
need for them'. This might not have been the answer you expected... but that's what Real Learning's about, not re-learning something you already know.
Black boxing is never required for the code to function. It's a way of
organizing code so that some parts are available for use but not for
change.
Code is written in response to a need. Needs change, code must change.
My question centers around the rationale behind the language
feature, and I was trying to guess at and imagine what it could be
useful for.
They aren't useful. Stay away from them. Stay away from shops that have a standard that demand you use them.
You've just been given valuable, applicable, professional advice. It isn't what you expected. Such is Life.
I've seen many cobol books, but few of them give any kind of
rationale as to why the standard is defined the way it is, so it would
seem to me that falling back on the collective memory of experienced
programmers would be the way to proceed.
The way to proceed is: Don't Use Sections.
The calculation of compound interest involves a simple formula. I don't
know whether there is a function for raising numbers to a power, but if
there isn't, then logarithms and the exponential function would be the
way to go. A-priori, this seems to me like something I'd like to perform
in a single COMPUTE statement, but you may have other ideas.
I have a few ideas born of experiences and those experiences include
working in shops where compound interest is calculated. It's different
from other calculations.
DD
On 30/09/2018 6:47 PM, docdwarf@panix.com wrote:
In article <bc1f4340-9a9e-40c4-be22-8f6e7449b987@googlegroups.com>,Sorry Doc,
Mayer Goldberg <mayer.goldberg@gmail.com> wrote:
Another reason has to do with grouping related pieces of code
(paragraphs), and in fact, stating that the internal paragraphs
should not be accessed directly, and rather the entire section
should be taken as a "black box".
This is exactly a reason not to use SECTIONs. Code is written to be
maintained and anything that requires 'black boxing' - for example,
the calculation of compound interest - should be neither a paragraph
nor a SECTION.
(whoever dares to ask 'if it's neither a paragraph nor a SECTION then how >>>> does the code get executed?' is brave)
I don't get this "brave" stuff, sorry: I'm here to learn, I'm not
playing ego games, I asked a simple question in a relevant forum: What
is the rationale for having a specific language feature (sections in the >>> procedure division). The answer ought to be the rationale. Admonitions
do not address the question.
The question was addressed, clearly and unambiguously, with 'there's no
need for them'. This might not have been the answer you expected... but
that's what Real Learning's about, not re-learning something you already
know.
Black boxing is never required for the code to function. It's a way of
organizing code so that some parts are available for use but not for
change.
Code is written in response to a need. Needs change, code must change.
My question centers around the rationale behind the language
feature, and I was trying to guess at and imagine what it could be
useful for.
They aren't useful. Stay away from them. Stay away from shops that have a
standard that demand you use them.
You've just been given valuable, applicable, professional advice. It isn't >> what you expected. Such is Life.
I've seen many cobol books, but few of them give any kind of
rationale as to why the standard is defined the way it is, so it would
seem to me that falling back on the collective memory of experienced
programmers would be the way to proceed.
The way to proceed is: Don't Use Sections.
The calculation of compound interest involves a simple formula. I don't
know whether there is a function for raising numbers to a power, but if
there isn't, then logarithms and the exponential function would be the
way to go. A-priori, this seems to me like something I'd like to perform >>> in a single COMPUTE statement, but you may have other ideas.
I have a few ideas born of experiences and those experiences include
working in shops where compound interest is calculated. It's different
from other calculations.
DD
Nothwithstanding the high regard I have for you personally and the
respect for your experience, I strongly disagree.
SECTIONs are fine and serve several useful purposes.
So now the OP has two conflicting opinions from two people well
qualified to have an opinion...
Makes it hard, doesn't it?
Perhaps some independent thought and considering on the part of the OP
will be called for... :-)
On Sunday, September 30, 2018 at 8:50:18 AM UTC+3, docd...@panix.com wrote:
In article <97d64a9a-b76d-4aef-b148-2966ac96b091@googlegroups.com>,
Mayer Goldberg <mayer.goldberg@gmail.com> wrote:
I was SURE sections in the procedure division were used for grouping
code!
Your certainty might have been based on faulty reasoning. How did you come >> to the conclusion?
DD
Here is my reasoning:
(1) Not knowing of overlays in cobol, they seem like a grouping mechanism because of the unique way GO TO works within section.
(2) Having learned about overlays, I discovered that only sections marked with priority number >= 50 are used for overlays. Others are not. This means there needs to be some purpose to having them.
(3) Today I found out that the Codasyl committee actually spelled out its reasoning:
<quote>
"Although it is not mandatory, the Procedure Division for a source program is usually written as a consecutive group of sections, each of which is composed of a series of closely related operations that are designed to collectively perform a particular function.
</quote>
[The source is the Codasyl Journal, p 331, section 8.1.2.1 "Program Segments"]
(4) I actually have Sammet's book on the history of programming languages, but I seem to have missed or not understood at the time the following comment by her:
<quote>
The storage allocation is handled automatically by the compiler. The prime unit for allocating executable code is a group of sections called a segment. The programmer combines sections be specifying a priority number with each section's name. ... The compiler is required to see that the proper control transfers are provided so that control among segments which are not stored simultaneously can take place.
</quote>
So there you have it --- Sections were intended as a mechanism for grouping related paragraphs. Such groups were intended to be loaded into memory as a group, so as to ensure efficient execution (in case of overlays).
The thing that caught my eyes back in the 1980's, when I first took a look at cobol, was that a GO TO to a section RETURNED at the end of the section.
The question as to whether I'll use these is not interesting to me at this point, even though you insist it's good for me to receive instruction on this. The question that does interest me is what is the meaning and intended purpose of sections in the procedure division. By now, with the help of the members here, and some digging around, I think I was able to obtains a sufficiently clear answer that explains the intention behind the standard. So a hearty Thank You goes to all who have responded, and now we can happily move on to programming and learning additional things.
Mayer
SECTIONs are fine and serve several useful purposes.
In article <g1df7rFbs5iU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
On 30/09/2018 6:47 PM, docdwarf@panix.com wrote:
In article <bc1f4340-9a9e-40c4-be22-8f6e7449b987@googlegroups.com>,Sorry Doc,
Mayer Goldberg <mayer.goldberg@gmail.com> wrote:
Another reason has to do with grouping related pieces of code
(paragraphs), and in fact, stating that the internal paragraphs
should not be accessed directly, and rather the entire section
should be taken as a "black box".
This is exactly a reason not to use SECTIONs. Code is written to be
maintained and anything that requires 'black boxing' - for example,
the calculation of compound interest - should be neither a paragraph >>>>> nor a SECTION.
(whoever dares to ask 'if it's neither a paragraph nor a SECTION then how >>>>> does the code get executed?' is brave)
I don't get this "brave" stuff, sorry: I'm here to learn, I'm not
playing ego games, I asked a simple question in a relevant forum: What >>>> is the rationale for having a specific language feature (sections in the >>>> procedure division). The answer ought to be the rationale. Admonitions >>>> do not address the question.
The question was addressed, clearly and unambiguously, with 'there's no
need for them'. This might not have been the answer you expected... but
that's what Real Learning's about, not re-learning something you already >>> know.
Black boxing is never required for the code to function. It's a way of >>>> organizing code so that some parts are available for use but not for
change.
Code is written in response to a need. Needs change, code must change.
My question centers around the rationale behind the language
feature, and I was trying to guess at and imagine what it could be
useful for.
They aren't useful. Stay away from them. Stay away from shops that have a >>> standard that demand you use them.
You've just been given valuable, applicable, professional advice. It isn't >>> what you expected. Such is Life.
I've seen many cobol books, but few of them give any kind of
rationale as to why the standard is defined the way it is, so it would >>>> seem to me that falling back on the collective memory of experienced
programmers would be the way to proceed.
The way to proceed is: Don't Use Sections.
The calculation of compound interest involves a simple formula. I don't >>>> know whether there is a function for raising numbers to a power, but if >>>> there isn't, then logarithms and the exponential function would be the >>>> way to go. A-priori, this seems to me like something I'd like to perform >>>> in a single COMPUTE statement, but you may have other ideas.
I have a few ideas born of experiences and those experiences include
working in shops where compound interest is calculated. It's different
from other calculations.
DD
Nothwithstanding the high regard I have for you personally and the
respect for your experience, I strongly disagree.
Two professionals with over a half-century experience between them don't
come to the same conclusions? Who could have heard of such a thing... certainly not the King of England.
SECTIONs are fine and serve several useful purposes.
Outside of the various SORT manipulations... is there any kind of
processing of which you are aware that can be performed by use of SECTIONs and nothing else?
So now the OP has two conflicting opinions from two people well
qualified to have an opinion...
Makes it hard, doesn't it?
Perhaps some independent thought and considering on the part of the OP
will be called for... :-)
What comes next... asking folks to do their own homework?
In article <g1df7rFbs5iU1@mid.individual.net>,
pete dashwood <dash...@enternet.co.nz> wrote:
SECTIONs are fine and serve several useful purposes.
Outside of the various SORT manipulations... is there any kind of
processing of which you are aware that can be performed by use of SECTIONs and nothing else?
What comes next... asking folks to do their own homework?
On 1/10/2018 3:38 PM, docdwarf@panix.com wrote:
In article <g1df7rFbs5iU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
SECTIONs are fine and serve several useful purposes.
Outside of the various SORT manipulations... is there any kind of
processing of which you are aware that can be performed by use of SECTIONs >> and nothing else?
No.
(leaving segmentation out of the argument as being obsolete...)
Is there any kind of computer processing YOU are aware of that can be >performed by use of COBOL and nothing else?
On Sunday, September 30, 2018 at 10:38:10 PM UTC-4, docd...@panix.com wrote: >> In article <g1df7rFbs5iU1@mid.individual.net>,
pete dashwood <dash...@enternet.co.nz> wrote:
[snip]
SECTIONs are fine and serve several useful purposes.
Outside of the various SORT manipulations... is there any kind of
processing of which you are aware that can be performed by use of SECTIONs >> and nothing else?
DECLARATIVES require sections, can't work without them.
The requirement for SORT input and output procedures to be in sections
was removed in COBOL 85.
Segmentation was removed in COBOL 2002.
Declaratives are all that remain.
On 09/30/2018 10:38 PM, docdwarf@panix.com wrote:
What comes next... asking folks to do their own homework?
One thing is certain. Given the nearsightedness of academia
no one asking a question about COBOL here is looking for help
with their homework.
In article <g1dhbbFc7phU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
On 1/10/2018 3:38 PM, docdwarf@panix.com wrote:
In article <g1df7rFbs5iU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
SECTIONs are fine and serve several useful purposes.
Outside of the various SORT manipulations... is there any kind of
processing of which you are aware that can be performed by use of SECTIONs >>> and nothing else?
No.
Most gracious of you to contradict yourself so readily, Mr Dashwood.
(leaving segmentation out of the argument as being obsolete...)
Is there any kind of computer processing YOU are aware of that can be
performed by use of COBOL and nothing else?
When someone posts that 'COBOL is fine and serves several useful purposes' this might be addressed.
In article <g1eek2Fi4rdU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 09/30/2018 10:38 PM, docdwarf@panix.com wrote:
What comes next... asking folks to do their own homework?
One thing is certain. Given the nearsightedness of academia
no one asking a question about COBOL here is looking for help
with their homework.
I use 'homework' in the sense of https://www.dictionary.com/browse/homework?s=t , 3: Thorough preparatory study of a subject.
much snipped
(I am probably the ONLY person here who has ever defended the use of
ALTER but I believe it is like everything else: if you find a construct
in a language that is potentially disastrous, don't ban it in the local >standards, teach people to understand it and use it responsibly.
It's kind of sad (IMO) that the vendors bowed to pressure from the User >Groups and dropped it from the language. I remember using it in a system
in the late 1960s where it was a lot like switching points in a Railway >marshalling yard... and it was MUCH more efficient on the platform where
it was running (Burroughs B500) than a COBOL IF...)
<snipped>--- Synchronet 3.20a-Linux NewsLink 1.114
Pete.
In article <g1dhbbFc7phU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
On 1/10/2018 3:38 PM, docdwarf@panix.com wrote:
In article <g1df7rFbs5iU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
SECTIONs are fine and serve several useful purposes.
Outside of the various SORT manipulations... is there any kind of
processing of which you are aware that can be performed by use of SECTIONs >>> and nothing else?
No.
Most gracious of you to contradict yourself so readily, Mr Dashwood.
On 2/10/2018 2:26 AM, docdwarf@panix.com wrote:
In article <g1dhbbFc7phU1@mid.individual.net>,Most foolish of you to see a contradiction where none exists.
pete dashwood <dashwood@enternet.co.nz> wrote:
On 1/10/2018 3:38 PM, docdwarf@panix.com wrote:
In article <g1df7rFbs5iU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
SECTIONs are fine and serve several useful purposes.
Outside of the various SORT manipulations... is there any kind of
processing of which you are aware that can be performed by use of SECTIONs >>>> and nothing else?
No.
Most gracious of you to contradict yourself so readily, Mr Dashwood.
The fact that SECTIONS are not the ONLY way does not gainsay the
assertion that "SECTIONS are fine and serve several useful purposes".
Rick pointed out that DECLARATIVES (which are far from obsolete) require >SECTIONs (I had forgotten about that...) but both of you have only >considered the use of SECTION as an instrument in COBOL code.
If the desired results are obtained either way, then the program is
serving its purpose.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 143:10:34 |
| Calls: | 12,962 |
| Files: | 186,574 |
| Messages: | 3,266,439 |