I have some questions about style. They might sound silly, but they are real questions for me.
Also keep in mind that the only COBOL I have seen is snippets posted online in tutorials, not actual procuction code.
Why this obsession with capitals? I read that originally it was the only option, but now that lowewrcase (at least in GnuCOBOL) is accepted, why are people still doing that? (Reason I ask: Plugin for now supports only lowercase)
Why prefixing with ws- and ls-? Proper names and syntax higlighting should be enough to differentiate them. (Reason I ask: I see them as spam, I plan to annotate them as redundant)
Why sections and paragraps inside a program? As far as I could tell, calling other programs is a much safer and reasonable way to execute other pieces of code: var scoping, sane control flow... Some examples even have one and only paragraph inside the procedure division, I guess as documentation, although a comment would do just fine, or even better the program id. What am I missing here? Why these things? (I plan to annotate paragraps and sections as "use subprogram instead.")
Sorry for the naivity, COBOL is indeed alien to me, but I do my best to understand it :)
Some progress update:
Autocompletion,
Highlighting of redundant keywords
Highlighting of undeclared variables
I have some questions about style. They might sound silly, but they
are real questions for me.
Also keep in mind that the only COBOL I have seen is snippets posted
online in tutorials, not actual procuction code.
If you look in the contrib areas also in sourceforge.net/p/ACAS
you will find a complete accounting system which includes Stock Control,
IRS (a GL tool for small businesses, book keepers and accountants),
Nominal, Sales, Purchase Ledgers also known to the North American area
as Inventory, IRS=GL = General Ledger, Accounts Receivables, Payables.
All written in Cobol with current updates and upgrades where the code
goes back to the 60's.
All code has been migrated over to GnuCobol using the FREE format source
in the main as lower case but where the first character is often upper
for all variables etc to highlight the variables.
If you prefer to see it all as upper case run all the 1,000+ modules
(and copy books) through cobxref using where the listings will all be in
upper case.
cobxref is in the contribs area.
Why this obsession with capitals? I read that originally it was
the only option, but now that lowewrcase (at least in GnuCOBOL) is
accepted, why are people still doing that? (Reason I ask: Plugin
for now supports only lowercase)
Older compilers used upper case as it was the standard (and only way to
enter code on Punched cards or paper tape) and is still used at some
mainframe sites around the world.
There are also many compilers such as M/F (mainframes) (IBM etc) that
will not accept FREE format code but some of this is because of issues
using variable length PDSE storage which is where source code is stored
for IBM kit.
For a play with such look for and download a product called Turnkey TK4
which is currently at release 8 and set up and run it where you will
find a ANSI) Cobol compiler, PLI, Assembler to name but a few different
languages and their compilers.
It will require a high learning curve but be useful if you wish to learn
to use modern IBM mainframes.
Why prefixing with ws- and ls-? Proper name and syntax higlighting
should be enough to differentiate them. (Reason I ask: I see them
as spam, I plan to annotate them with as redundant)
This is a standard used by many sites operating M/F's. As most of not
all professional Cobol programmers worked at such sites their standards
of writing programs in Cobol started and possibly continue.
Program code taken from such systems and migrated over to micro based
system using GnuCobol or similar stick to it if it means it is difficult
and time consuming to convert such to use lower or mixed case. I have
done it as I use a decent editor with good facilities.
Why sections and paragraps inside a program? As far as I could
tell, calling other programs is a much safer and reasonable way to
execute other pieces of code: var scoping, sane control flow...
Some examples even pave one and only paragraph inside the
procedure division, I guess as ducumentation, although a comment
would do just fine., or even better the program id. What am I
missing here? Why these things? (I plan to annotate paragraps and
sections as "use subprogram instead.")
I suggest you learn to program before coming out with these opinions.
Also look up standards and practices for maintaining code in production
systems including the costs and efficiencies of doing so.
Sorry for the naivity, COBOL is indeed alien to me, but I do my best
to understand it :)
Some progress update:
Autocompletion,
Highlighting of redundant keywords
Highlighting of undeclared variables
Look for a decent editor and for the last a good cross reference tool
for Cobol such as cobxref or to some point the internal gnucobol one -
not as good but - try both and compare the differences to a large
source program, say 5,000 to 50,000 lines of code.
Vincent
Using Cobol for a while.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-06-21
Both are traditions. The first came from history. The original source code was written then only Upper Case was available (punched cards). COBOL is mixed-case. Case is irrelevant except in literals.
The ws- and ls- prefixes remind the programmer/diagnostician where to go find the definition. ws-, for example, is the working-storage section.
I expect others will chime in with more detailed replies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use uppercase because it is easier to read. As I've gotten older my vision has deteriorated. Reading a screen several hours of a day makes the problem even worse.
I use prefixes to make it easier to determine where I might find the variable. Programs can get long in the production environment.
The fewer times that my program relies on external code the safer I feel. Calling external programs can cause problems if those programs change. Working with a program that makes external calls slows down debugging for me.
jimc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What am I missing here? Why these things? (I plan to annotate paragraps and sections as "use >subprogram instead.")
Instead, buy a COBOL programming book and read it.
Autocompletion
It is not as important as e.g. in Java or C ++. In Java or C ++ there are always a thousand attributes and methods, and you can no longer work without an IDE.
Why prefixing with ws- and ls-? ...
I see them as spam, I plan to annotate them as redundant.
That was the joke of the day. :)
Highlighting of undeclared variables.
First you have to check COPY.
László
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like upper case on the mainframe and lower case on Linux/Windows. If doing just maintaning code, I don't change it, and let it stay as is.
I am not fond of Free Format, and stick to the traditional 80 column.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@laszloerdos I do not know why not prefixing items with their, lets call it scope, is a joke. Maybe we use different tools, I am only a ctrl+B away from jumping to the item definition.
@vcoen Thank you very much for the long and informative answer. The only part that I did not gain as much information as I would like to, and as much as the rest of the answer was giving, was the part that said
I suggest you learn to program before coming out with these opinions.
I think I am a good programmer. Not at COBOL, but have some insticts about good writing and minimalism. Since other languages can thrive without the concept of paragraphs and sections, and since I can already see how they can be dangerous, but not see what they add that cannot be done with a subprogram, would you please illuminate me, as you did for the rest of my questions? The question was esentially "Why use them? What do they offer that a subprobram doesnt?"
Last edit: Nikos Papageorgiou 2020-07-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When COBOL was first created computer disk and memory was minimal and expensive. One of the requirements was that COBOL had to be easy to use than FORTRAN or ALGOL.
Calls were expensive and far from efficient compared to today's computers.
They came up with paragraph and section names as tags to make branching more maintainable and readable so it conformed to COBOL's English like syntax. This allowed code to execute much faster because it reduce disk i/o, memory management, You can separate your code with descriptive (paragraph) names.
Paragraphs make it easier to maintain code. In cases where you have to make many decisions (if/else or evaluate) you don't have to integrate the executable statements in between each if/else. By performing paragraphs the decision level are more compact and easier to weed through. Future changes then require changing only the paragraphs you need too all in a singe file. It will execute faster than if each decision executed a call to another program.
As to whether to use them or not is up to you (or the programming standards in place). For small systems it doesn't matter. For large systems paragraphs and sections can speed thing up even with today's hardware. For a handful of code lines why call it when you can perform it in a paragraph? The code will be right under your nose and won't have to open another file to access it. If you want to reuse it then make it a copybook and use the copy or copy/replacing in a paragraph. Another reason to use paragraphs is to reduce the code you have to write. If you have 15 lines of code why add 20 lines of redundant code to it just to make it a separate program? Those 20 lines add up to a lot of redundant code in many smaller programs. A lot of entry-exit points generated by the compiler.
The strongest argument for paragraphs is external dependencies. The more subprograms you have the more external dependencies and confusion you have due to parameters. External dependencies are the hardest to maintain especially in larger systems. Paragraphs have no external dependencies. In many cases 10 files are easier to maintain than 30 files. In my view dependancies are not a safe bet. The concept of global variables taught in programming classes as unsafe it totally made up. The proof of that is in the millions of lines of mission critical COBOL code used in banking transactions every day and maintained for decades. The code is fast and effcient and is built on the concept of paragraphs and sections far more than it is built on calls. If it all was built on calls, you might get your cash from an ATM the next day. An exageration for sure but it does make that much of a difference in the processing chain. Programs are thousands of lines long and they work like a charm.
Paragraphs and Sections just help organize your programs. As with anything else trade offs are involved. If you want to be a good COBOL programmer get the experince, try different things to see what works best. And that stuff you learned in school - forget it - you'll write less code that easier to maintain as you learn to balance your code usage.
If you have a program that has say 1000 lines it probably easier in the long run to divide it into paragraphs instead of 10 different files using functions or calls. A 1000 line program easy to maintain and reduces confusion. It's far easier to weed through 1 program instead of 10 to see what has to be changed.
Last edit: Joe Reichart 2020-07-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good points here. The only thing I'd add is that it still is good to have one program only doing one thing, and especially decouple any screen io from logic programs (possibly also file io, but that's harder to achieve).
These are the cases where additional programs make life easier than only using copybooks for these cases.
I would have to agree and add COBOL makes that task easier since records can be passed as parametes giving the apperance of looser coupling and ehhances maintenance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-07-17
Well said, Joe. Back in the day, there were other considerations. Working with cards and paper, thousands of lines of code were hard to manage. Programs were often block-structured, macro-structure descending into micro-structure. Sections sould be defined for the macro structure and filled in later by COPY using smaller decks/files. Paragraphs could then be defined and themselves filled in. The objective for some early IBM users was no block of code be longer than a page of listing. It makes for something of a bowl of needles that was "clarified" by complex naming conventions.
Few went to such a depth and relaxed the size of code blocks but at the time, like spaces versus tabs, it was a conversation at Users Group meetings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow... I remember all that! The stuff we would do to get a 1 second reponse time from a terminal when they first appeard - and not always possible. Wow!!!!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whether 1 file is easier to maintain than 10 depends on quite a few things, from experience to tools.
Any assertion about performance based on syntax is bound to be wrong. The compiler is free to implement whatever function-call implementation it likes. AFAIK the Cobol standard doesn't mandate any ABI. And there are many moving parts under the compiler.
Questions of style and readability are a matter of taste, also influenced by experience and tools. My favorite example is the 24-line function recommendation, born of the 24-line video terminals of the day because they could display the whole function on one screen, and still recommended today when we can set two 60-line functions side-by-side on one display.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not true. Assertions based on syntax must be true otherwise you would not get the expected result. How it is done is irrelavent so long as the compiled program works as advertised.
The programmer can control the program. All code is generated in line except for a call. A call will generate code for the linker. If you have too many calls and want to speed it up just compile the files together. It will then genrate one big binary program. An Assembler listing will show the results.
The syntax and pragmas are the rules of the game and all you have to guide you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Joe, the "assertions" I was referring to were yours, the statements you made above. I said [your] "assertions about performance based on syntax" do not hold. Syntax does not imply anything about performance. Two compilers may produce different object code for the same syntax. Heck, one compiler may do that. But surely you know that.
All code is generated in line except for a call.
That's up to the compiler.
A call will generate code for the linker.
The linker resolves calls between source code modules only.
If you have too many calls and want to speed it up just compile the files together.
I think what you're suggesting here is that dynamic linking is slower than static linking. How much time are we talking? A number, please.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well - Google seemed to think it important enough. All Go code is compiled inline. There are no dynamic calls in Go. Tell it to Google. And they're not the only one. So why do they not allow dynamic calls???
Read the GnuCOBOL manual - the compiler authors have some tips in there.
Why would they waste their time if it wasn't a something to consider?
Many compilers have perferred way do to things.
My assertions are correct. While you proably won't notice it in small systems, in large systems with millions of lines of code it becomes glaring.
Test the concept yourself. It will be a good learning experience.
Write a program and do about 20 calls to separate programs.
Time it out, Compile the statically and see the difference. Sure we are talking micoseconds for 200 lines of code. But what about 2,000,000, or 5,000,000? Do the math. Micro seconds turn into seconds and then into minutes.
It's not hard to write two programs to do the same task and have one run faster than another. It's how you write the code and knowing your compier - after all you only have the same syntx to work with. The compiler is static while the code written is dynamic as each program performs a different task. Two exact pograms will run the same. Any difference is not the compiler. It's the load/usage of the system at runtime.
And all you have is the syntax to work with. You can't change the syntax - it's fixed. Try to change it and the compiler won't accept it. So the conversation must be based on syntax.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seriously, Joe, you might want to stand down. Picking an argument like this with me is only likely to make you look silly. It's already happening.
You made a claim about every compiler. You're trying to support that claim by pointing to Go. You're suggesting that Go represents Google's considered language-implementation policy, and that Google's computing problems are representative of anyone else's. None of that is credible.
Your assertions aren't correct. Until you back them up, they're vacuous.
I'm not denying different code paths have different computational characteristics. I'm denying your assertion that it matters, or that the average Cobol programmer seeking advice on how to write Cobol should give dynamic linking one second's thought.
It's well known that programmers are terrible at guessing about performance. The first rule of improving performance is measurement, because the thing that is slow is hardly ever obvious -- even to experienced programmers -- from studing the source code. Virtually every "optimization" in the textbooks has been wrong since the PDP/11 went out of production.
To bring it back to GnuCOBOL, let's pick just one aspect of function calls. cobc, as you know, produces C. The C compiler has various optimization settings. At it's normal -O2 level, it may choose to inline functions that are not declared inline, or not to inline functions that are declared inline. That's the compiler's prerogative, and we're two levels away from Cobol paragraphs and procedures. You may not be aware that that is just one of dozens of optimization passes the GNU C compiler may make.
Finally, please don't suggest I go do some testing, especially because you have no clue about what testing I did long before you expressed your opinion. You made the claim. I denied it. It's for you to prove. That's why I asked for a number.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I thought...
If you don't like my claim... That's ok. I know your trying....
Level 2? Really? Forgetting something?
They call it optimization becasue it optimises. That does not mean change!
Big difference. Compilers do not change the intent of the code. Period.
Ask someone who writes compilers.
Now you are free to post - you can have the last word.
That's important - Right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To me style is of no concern.
Why ?
I have edited and compiled COBOL programs from literally 100's of individual zOS clients.
There is no standard style.
There is a standard animator - Xpeditor or MF (at the time of my involvement) enables visual execution of the code.
An animator is a must have (IMHO) if not familiar with an application(s)
The suggestion to compile mutiple modules together would not work in virtually every zOS account.
Probably none of my observations are germane to the Linux world.
But in the "trial by fire" mode of implementing proof of concept projects for zOS accounts, style was / is not an issue to be concerned with.
I have observed few professional COBOL programs without paragraphs.
I can't believe that is an issue to anyone :-)
2 cents :-)
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2020-07-17
What is the Sam Hill are you arguing about?
Who cares? You both seem like you have lost it.
This thread started with some nascent Cobol student asking bizarre questions.
Let's move on please.
The student needs some very basic education.
As someone else said, "get a COBOL manual"
Read it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to express my thoughts. Now to get back to Nikos’s original question number 3, concerning sections and paragraphs –vs- calling programs (subroutines/modules?).
Some statistics of the shop I work at today.
Our small group is responsible for only about 700 COBOL programs. These programs were ported down from the mainframe almost 20 years ago to microfocus cobol. The average line count is about 300 lines (includes every line, working storage, procedure and even blank lines) and not the copybook library, which is mostly 95% working storage. The largest programs, (minus 2 or 3 that are not applicable and are about 12k lines) is about 4000 lines. Most are executables and about 100 or so are subroutines, I guess….
And do not be fooled by the number of our programs. We create Binary hash files that are encrypted and used in data only products that are sold for the value that they are. The math and detail to bits and bytes are something that I have come to appreciate and admire.
I believe the issue is when to make something a subroutine or another paragraph.
If there is a function that has to be done several times then that is a candidate for a called subroutine program. An example, if we have data that needs to be converted to a specific character stream, and we need this character stream to inquire on data bases, then the process to build the character fields would be a subroutine. This way we know it is always built correctly and the same way.
Now if we need to read a file, and we have many different files and layouts that have the data, but we need to convert the data to the specific character stream to read the data base, we have many programs to read the file and reformat the data to match the specific data stream, so then, they can all call the subroutine to format the data for the call to the data base.
These read a file programs would have paragraphs to do the read of the Different specific files and Different outputs but would end up calling the subroutine. Of course this is not all we do.
I worked before the “structured” programming methodology was known to me. But now I see the value of structured programming in COBOL. This would explain the need of paragraphs. In structured programming we practice ‘go to less’ programing and ‘period less’ programming. We do NOT use goto’s, EVER. And periods mark the end of a paragraph in the procedure division or the end of the program.
Joe, I would like to recommend a book you may want to read. Although you can google “structured analysis” “structured design” and “structured programming”, please at least give a read to something like: Structured COBOL fundamentals and style, by Tyler Welburn and Wilson Price.
Last edit: Mickey White 2020-07-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given today's hardware speed - I can't disagree with Ralph's post. The beauty of COBOL is that no matter how you do it is still readable. Even with all the ugly gotos of the past in those old 5000 plus line of code programs.
Out of complexity and the lack of modern day COBOL verbs I started structured programming in the mid to late seventies. So I don't think the books would be much help at this point.
I have read tons of books on analysis, structure, languages and from my 38 years of experience It is my opinion that they really don't get into the nuts and bolts of the real world. They're good books and get you started but leave a lot of blanks down the read. And one must remember, they're an opinion - not the bible.
Back in the day I was a big copybook fan simply because I could break the program down with the path of least resistance and reuse the code all I wanted with replacing. Plus it was more efficient and less writing than a call. That was when memory swapping was big deal and took noticeable time.
Today I would go for the call but if I was searching for something across 20 servers I think the copybook wins that one.
Then there were the shops that didn't like the complexity of compound replacing statements. They made us cut and paste code - didn't care for that! Horrible.
When I had my way, I always looked to balance things by design (structured or not) between in line code,copybooks, and calls. If I cold do 4 thing in seven lines of code it's simpler to just do in line or a paragraph. Why make future programmers hunt through the source for one or two line paragraphs or files? Waste of time.
The only other thing I can say and you can only understand if you have been there - if you ever worked in a very high dynamic environment with millions of lines of code, no matter how good the design or the code is they're going to ask to add or change for something that does not fit well. On top of that they want it overnight.
It's about the money and that is just the way it is. But these environments are unique in they're on right.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have some questions about style. They might sound silly, but they are real questions for me.
Also keep in mind that the only COBOL I have seen is snippets posted online in tutorials, not actual procuction code.
Sorry for the naivity, COBOL is indeed alien to me, but I do my best to understand it :)
Some progress update:
Autocompletion,
Highlighting of redundant keywords
Highlighting of undeclared variables
Last edit: Nikos Papageorgiou 2020-06-21
Hi ;
On 21/06/2020 14:44, Nikos Papageorgiou wrote:
you will find a complete accounting system which includes Stock Control,
IRS (a GL tool for small businesses, book keepers and accountants),
Nominal, Sales, Purchase Ledgers also known to the North American area
as Inventory, IRS=GL = General Ledger, Accounts Receivables, Payables.
All written in Cobol with current updates and upgrades where the code
goes back to the 60's.
All code has been migrated over to GnuCobol using the FREE format source
in the main as lower case but where the first character is often upper
for all variables etc to highlight the variables.
If you prefer to see it all as upper case run all the 1,000+ modules
(and copy books) through cobxref using where the listings will all be in
upper case.
cobxref is in the contribs area.
There are also many compilers such as M/F (mainframes) (IBM etc) that
will not accept FREE format code but some of this is because of issues
using variable length PDSE storage which is where source code is stored
for IBM kit.
For a play with such look for and download a product called Turnkey TK4
which is currently at release 8 and set up and run it where you will
find a ANSI) Cobol compiler, PLI, Assembler to name but a few different
languages and their compilers.
It will require a high learning curve but be useful if you wish to learn
to use modern IBM mainframes.
Program code taken from such systems and migrated over to micro based
system using GnuCobol or similar stick to it if it means it is difficult
and time consuming to convert such to use lower or mixed case. I have
done it as I use a decent editor with good facilities.
Also look up standards and practices for maintaining code in production
systems including the costs and efficiencies of doing so.
Vincent
Using Cobol for a while.
Both are traditions. The first came from history. The original source code was written then only Upper Case was available (punched cards). COBOL is mixed-case. Case is irrelevant except in literals.
The
ws-andls-prefixes remind the programmer/diagnostician where to go find the definition.ws-, for example, is theworking-storage section.I expect others will chime in with more detailed replies.
I use uppercase because it is easier to read. As I've gotten older my vision has deteriorated. Reading a screen several hours of a day makes the problem even worse.
I use prefixes to make it easier to determine where I might find the variable. Programs can get long in the production environment.
The fewer times that my program relies on external code the safer I feel. Calling external programs can cause problems if those programs change. Working with a program that makes external calls slows down debugging for me.
jimc
Hi,
You can use the programs in Contributions for your plugin test. It is similar to production with different styles:
https://sourceforge.net/p/open-cobol/contrib/HEAD/tree/trunk/
Instead, buy a COBOL programming book and read it.
It is not as important as e.g. in Java or C ++. In Java or C ++ there are always a thousand attributes and methods, and you can no longer work without an IDE.
That was the joke of the day. :)
First you have to check COPY.
László
I like upper case on the mainframe and lower case on Linux/Windows. If doing just maintaning code, I don't change it, and let it stay as is.
I am not fond of Free Format, and stick to the traditional 80 column.
Thank you all for your replies.
@laszloerdos I do not know why not prefixing items with their, lets call it scope, is a joke. Maybe we use different tools, I am only a ctrl+B away from jumping to the item definition.
@vcoen Thank you very much for the long and informative answer. The only part that I did not gain as much information as I would like to, and as much as the rest of the answer was giving, was the part that said
I think I am a good programmer. Not at COBOL, but have some insticts about good writing and minimalism. Since other languages can thrive without the concept of paragraphs and sections, and since I can already see how they can be dangerous, but not see what they add that cannot be done with a subprogram, would you please illuminate me, as you did for the rest of my questions? The question was esentially "Why use them? What do they offer that a subprobram doesnt?"
Last edit: Nikos Papageorgiou 2020-07-14
When COBOL was first created computer disk and memory was minimal and expensive. One of the requirements was that COBOL had to be easy to use than FORTRAN or ALGOL.
Calls were expensive and far from efficient compared to today's computers.
They came up with paragraph and section names as tags to make branching more maintainable and readable so it conformed to COBOL's English like syntax. This allowed code to execute much faster because it reduce disk i/o, memory management, You can separate your code with descriptive (paragraph) names.
Paragraphs make it easier to maintain code. In cases where you have to make many decisions (if/else or evaluate) you don't have to integrate the executable statements in between each if/else. By performing paragraphs the decision level are more compact and easier to weed through. Future changes then require changing only the paragraphs you need too all in a singe file. It will execute faster than if each decision executed a call to another program.
As to whether to use them or not is up to you (or the programming standards in place). For small systems it doesn't matter. For large systems paragraphs and sections can speed thing up even with today's hardware. For a handful of code lines why call it when you can perform it in a paragraph? The code will be right under your nose and won't have to open another file to access it. If you want to reuse it then make it a copybook and use the copy or copy/replacing in a paragraph. Another reason to use paragraphs is to reduce the code you have to write. If you have 15 lines of code why add 20 lines of redundant code to it just to make it a separate program? Those 20 lines add up to a lot of redundant code in many smaller programs. A lot of entry-exit points generated by the compiler.
The strongest argument for paragraphs is external dependencies. The more subprograms you have the more external dependencies and confusion you have due to parameters. External dependencies are the hardest to maintain especially in larger systems. Paragraphs have no external dependencies. In many cases 10 files are easier to maintain than 30 files. In my view dependancies are not a safe bet. The concept of global variables taught in programming classes as unsafe it totally made up. The proof of that is in the millions of lines of mission critical COBOL code used in banking transactions every day and maintained for decades. The code is fast and effcient and is built on the concept of paragraphs and sections far more than it is built on calls. If it all was built on calls, you might get your cash from an ATM the next day. An exageration for sure but it does make that much of a difference in the processing chain. Programs are thousands of lines long and they work like a charm.
Paragraphs and Sections just help organize your programs. As with anything else trade offs are involved. If you want to be a good COBOL programmer get the experince, try different things to see what works best. And that stuff you learned in school - forget it - you'll write less code that easier to maintain as you learn to balance your code usage.
If you have a program that has say 1000 lines it probably easier in the long run to divide it into paragraphs instead of 10 different files using functions or calls. A 1000 line program easy to maintain and reduces confusion. It's far easier to weed through 1 program instead of 10 to see what has to be changed.
Last edit: Joe Reichart 2020-07-17
Good points here. The only thing I'd add is that it still is good to have one program only doing one thing, and especially decouple any screen io from logic programs (possibly also file io, but that's harder to achieve).
These are the cases where additional programs make life easier than only using copybooks for these cases.
I would have to agree and add COBOL makes that task easier since records can be passed as parametes giving the apperance of looser coupling and ehhances maintenance.
Well said, Joe. Back in the day, there were other considerations. Working with cards and paper, thousands of lines of code were hard to manage. Programs were often block-structured, macro-structure descending into micro-structure. Sections sould be defined for the macro structure and filled in later by COPY using smaller decks/files. Paragraphs could then be defined and themselves filled in. The objective for some early IBM users was no block of code be longer than a page of listing. It makes for something of a bowl of needles that was "clarified" by complex naming conventions.
Few went to such a depth and relaxed the size of code blocks but at the time, like spaces versus tabs, it was a conversation at Users Group meetings.
Wow... I remember all that! The stuff we would do to get a 1 second reponse time from a terminal when they first appeard - and not always possible. Wow!!!!!!
Whether 1 file is easier to maintain than 10 depends on quite a few things, from experience to tools.
Any assertion about performance based on syntax is bound to be wrong. The compiler is free to implement whatever function-call implementation it likes. AFAIK the Cobol standard doesn't mandate any ABI. And there are many moving parts under the compiler.
Questions of style and readability are a matter of taste, also influenced by experience and tools. My favorite example is the 24-line function recommendation, born of the 24-line video terminals of the day because they could display the whole function on one screen, and still recommended today when we can set two 60-line functions side-by-side on one display.
Not true. Assertions based on syntax must be true otherwise you would not get the expected result. How it is done is irrelavent so long as the compiled program works as advertised.
The programmer can control the program. All code is generated in line except for a call. A call will generate code for the linker. If you have too many calls and want to speed it up just compile the files together. It will then genrate one big binary program. An Assembler listing will show the results.
The syntax and pragmas are the rules of the game and all you have to guide you.
Joe, the "assertions" I was referring to were yours, the statements you made above. I said [your] "assertions about performance based on syntax" do not hold. Syntax does not imply anything about performance. Two compilers may produce different object code for the same syntax. Heck, one compiler may do that. But surely you know that.
That's up to the compiler.
The linker resolves calls between source code modules only.
I think what you're suggesting here is that dynamic linking is slower than static linking. How much time are we talking? A number, please.
Well - Google seemed to think it important enough. All Go code is compiled inline. There are no dynamic calls in Go. Tell it to Google. And they're not the only one. So why do they not allow dynamic calls???
Read the GnuCOBOL manual - the compiler authors have some tips in there.
Why would they waste their time if it wasn't a something to consider?
Many compilers have perferred way do to things.
My assertions are correct. While you proably won't notice it in small systems, in large systems with millions of lines of code it becomes glaring.
Test the concept yourself. It will be a good learning experience.
Write a program and do about 20 calls to separate programs.
Time it out, Compile the statically and see the difference. Sure we are talking micoseconds for 200 lines of code. But what about 2,000,000, or 5,000,000? Do the math. Micro seconds turn into seconds and then into minutes.
It's not hard to write two programs to do the same task and have one run faster than another. It's how you write the code and knowing your compier - after all you only have the same syntx to work with. The compiler is static while the code written is dynamic as each program performs a different task. Two exact pograms will run the same. Any difference is not the compiler. It's the load/usage of the system at runtime.
And all you have is the syntax to work with. You can't change the syntax - it's fixed. Try to change it and the compiler won't accept it. So the conversation must be based on syntax.
Seriously, Joe, you might want to stand down. Picking an argument like this with me is only likely to make you look silly. It's already happening.
You made a claim about every compiler. You're trying to support that claim by pointing to Go. You're suggesting that Go represents Google's considered language-implementation policy, and that Google's computing problems are representative of anyone else's. None of that is credible.
Your assertions aren't correct. Until you back them up, they're vacuous.
I'm not denying different code paths have different computational characteristics. I'm denying your assertion that it matters, or that the average Cobol programmer seeking advice on how to write Cobol should give dynamic linking one second's thought.
It's well known that programmers are terrible at guessing about performance. The first rule of improving performance is measurement, because the thing that is slow is hardly ever obvious -- even to experienced programmers -- from studing the source code. Virtually every "optimization" in the textbooks has been wrong since the PDP/11 went out of production.
To bring it back to GnuCOBOL, let's pick just one aspect of function calls. cobc, as you know, produces C. The C compiler has various optimization settings. At it's normal
-O2level, it may choose to inline functions that are not declared inline, or not to inline functions that are declared inline. That's the compiler's prerogative, and we're two levels away from Cobol paragraphs and procedures. You may not be aware that that is just one of dozens of optimization passes the GNU C compiler may make.Finally, please don't suggest I go do some testing, especially because you have no clue about what testing I did long before you expressed your opinion. You made the claim. I denied it. It's for you to prove. That's why I asked for a number.
As I thought...
If you don't like my claim... That's ok. I know your trying....
Level 2? Really? Forgetting something?
They call it optimization becasue it optimises. That does not mean change!
Big difference. Compilers do not change the intent of the code. Period.
Ask someone who writes compilers.
Now you are free to post - you can have the last word.
That's important - Right?
To me style is of no concern.
Why ?
I have edited and compiled COBOL programs from literally 100's of individual zOS clients.
There is no standard style.
There is a standard animator - Xpeditor or MF (at the time of my involvement) enables visual execution of the code.
An animator is a must have (IMHO) if not familiar with an application(s)
The suggestion to compile mutiple modules together would not work in virtually every zOS account.
Probably none of my observations are germane to the Linux world.
But in the "trial by fire" mode of implementing proof of concept projects for zOS accounts, style was / is not an issue to be concerned with.
I have observed few professional COBOL programs without paragraphs.
I can't believe that is an issue to anyone :-)
2 cents :-)
Ralph
What is the Sam Hill are you arguing about?
Who cares? You both seem like you have lost it.
This thread started with some nascent Cobol student asking bizarre questions.
Let's move on please.
The student needs some very basic education.
As someone else said, "get a COBOL manual"
Read it.
I would like to express my thoughts. Now to get back to Nikos’s original question number 3, concerning sections and paragraphs –vs- calling programs (subroutines/modules?).
Some statistics of the shop I work at today.
Our small group is responsible for only about 700 COBOL programs. These programs were ported down from the mainframe almost 20 years ago to microfocus cobol. The average line count is about 300 lines (includes every line, working storage, procedure and even blank lines) and not the copybook library, which is mostly 95% working storage. The largest programs, (minus 2 or 3 that are not applicable and are about 12k lines) is about 4000 lines. Most are executables and about 100 or so are subroutines, I guess….
And do not be fooled by the number of our programs. We create Binary hash files that are encrypted and used in data only products that are sold for the value that they are. The math and detail to bits and bytes are something that I have come to appreciate and admire.
I believe the issue is when to make something a subroutine or another paragraph.
If there is a function that has to be done several times then that is a candidate for a called subroutine program. An example, if we have data that needs to be converted to a specific character stream, and we need this character stream to inquire on data bases, then the process to build the character fields would be a subroutine. This way we know it is always built correctly and the same way.
Now if we need to read a file, and we have many different files and layouts that have the data, but we need to convert the data to the specific character stream to read the data base, we have many programs to read the file and reformat the data to match the specific data stream, so then, they can all call the subroutine to format the data for the call to the data base.
These read a file programs would have paragraphs to do the read of the Different specific files and Different outputs but would end up calling the subroutine. Of course this is not all we do.
I worked before the “structured” programming methodology was known to me. But now I see the value of structured programming in COBOL. This would explain the need of paragraphs. In structured programming we practice ‘go to less’ programing and ‘period less’ programming. We do NOT use goto’s, EVER. And periods mark the end of a paragraph in the procedure division or the end of the program.
Joe, I would like to recommend a book you may want to read. Although you can google “structured analysis” “structured design” and “structured programming”, please at least give a read to something like: Structured COBOL fundamentals and style, by Tyler Welburn and Wilson Price.
Last edit: Mickey White 2020-07-17
Well - there is nothing wrong with that.
Given today's hardware speed - I can't disagree with Ralph's post. The beauty of COBOL is that no matter how you do it is still readable. Even with all the ugly gotos of the past in those old 5000 plus line of code programs.
Out of complexity and the lack of modern day COBOL verbs I started structured programming in the mid to late seventies. So I don't think the books would be much help at this point.
I have read tons of books on analysis, structure, languages and from my 38 years of experience It is my opinion that they really don't get into the nuts and bolts of the real world. They're good books and get you started but leave a lot of blanks down the read. And one must remember, they're an opinion - not the bible.
Back in the day I was a big copybook fan simply because I could break the program down with the path of least resistance and reuse the code all I wanted with replacing. Plus it was more efficient and less writing than a call. That was when memory swapping was big deal and took noticeable time.
Today I would go for the call but if I was searching for something across 20 servers I think the copybook wins that one.
Then there were the shops that didn't like the complexity of compound replacing statements. They made us cut and paste code - didn't care for that! Horrible.
When I had my way, I always looked to balance things by design (structured or not) between in line code,copybooks, and calls. If I cold do 4 thing in seven lines of code it's simpler to just do in line or a paragraph. Why make future programmers hunt through the source for one or two line paragraphs or files? Waste of time.
The only other thing I can say and you can only understand if you have been there - if you ever worked in a very high dynamic environment with millions of lines of code, no matter how good the design or the code is they're going to ask to add or change for something that does not fit well. On top of that they want it overnight.
It's about the money and that is just the way it is. But these environments are unique in they're on right.