I’m revisiting some old assignments and I’m seeing a distinction between implicit (.) and explicit (letting the code structure terminate the block of code itself. I’m wondering if there is any performance reason to code one way or the other, or is it all just for style points that will get built the same way by the assembler?
Hi Arnold: I’ve taught COBOL and Assembler since the 1980s. My principle is to always retain explicit control of the program flow, and clean up after yourself. That means that you always use explicit terminations, release memory that’s been requested when you’re done with it, and other similar rules. They have always avoided unexpected results, where the code could do something you didn’t anticipate. I’ve corrected many programs over the years who thought they had an implicit termination or change of flow, only to find that the code simply dropped through to the next instruction regardless. It’s always better to KNOW that the code will flow as you have programmed it, and the only way to be 100% sure is to code it explicitly. It’s also good style, but with a purpose.
Hope that helps!
Mark D’Gabriel
3 Likes
Thank you Mark that definitely helps. Appreciate the insight.
Explicit termination wasn’t introduced until Cobol '85, right? A lot of implicit termination may indicate the age of the code… Agree?
COBOL was designed before the concepts of structured programming were understood, and while it has caught up, implicit termination is a relic of this time. Perhaps because I came to COBOL after PL/I, I always use explicit termination, and this is the standard that I’ve built into MANASYS Jazz (https://jazzsoftware.co.nz/). Any reasonable COBOL compiler will generate the best code possible from either form (and IBM’s COBOL compiler is especially good), and even if there were a code penalty I’d advocate explicit termination because it creates programs that are more obviously correct. To a programmer like me trained first in a more regular language, COBOL’s syntax is quirky and leads to unexpected errors.
Robert Barnes
Correction - Any reasonable COBOL compiler
Implicit termination of code structures is a very common technique in many COBOL programs. “Structured” programming techniques usually rely on the implicit termination of “paragraphs” as a means of easy code control. “Non-structured” programs, which are often referred to as “spaghetti code”, are more reliant on terminators or branching verbs to control program flow.
Implicit or explicit use of terminators produces very little difference in the performance of the code. Most COBOL compilers are very good at creating efficient and fast execution code regardless of implicit versus explicit terminators. Most compilers have additional parameters that can be used to further optimize the generated code if required. Under general circumstances this is usually not necessary.
For structured programs I recommend the use of implicit terminators. This keeps the code cleaner and easier to understand. For programs that are not well formed it is sometimes necessary to use explicit terminators to accomplish the necessary code modification without major structure changes to the code.
If you are still reading…
Most COBOL systems use a technique where the code is “programmed” in a human readable format that utilizes “words” arranged in “sentences” and “paragraphs”. The sentences are terminated by “periods” just like a story written in english. This “story” is the COBOL “program”. The “program” is then processed by a “compiler” which reduces the human readable code into an efficient mass of bit and bytes known as “object code” or “intermediate byte code”. The output of this compilation step creates a file separate from the original programming code. It is this separate file that is used by the processing system to produce the end result the program was designed to accomplish.
In comparison many currently popular programming languages (like Javascript) use a “just in time” (JIT) method of interpreting the human readable code and changing it the machine executable instructions that the computer can utilize. This technique means there is not a visible compiler used in the process. The “compilation step” occurs at execution time. In terms of machine cycles this can be a time consuming step. Since COBOL has performed part of this step as part of the programming step the result is that COBOL code can run fast and efficient and not be subject to some of the issues faced by JIT code techniques. It is also part of what allows COBOL programs to continue to run for decades without changes to the code. It also allows some COBOL program to run in different environments such as mainframes and PC’s with little or no change to the actual program code.
I hope this helps.
Nothing wrong with both 
IF condition
do this
END-IF.
I liked the addition of explicit terminators, but I’ve been writing COBOL for so long that a statement just doesn’t look right to me without a period at the end.
2 Likes
You can use implicit and explicit termination. I would always prefer explicit termination as this supports the concept of (COBOL) sentences/statements very well. Always add a period at the end of a sentence/statement - as you would in your natural language. Always use END-… (END-IF, END-PERFORM, END-EVALUATE, …). Nobody would seriously recommend to write a text without correct punctuation.
2 Likes
I started programming in 1967 … COBOL in 1968 (along with many other languages through the years) until I retired in 2004. Most of the time I spent as a contractor in Massachusetts in a variety of industry types.
In all those years, I never heard the terms Implicit or Explicit termination … also, taught a number of COBOL courses … where my favorite response to a debugging question was “You forgot a period”.
At my current age of 85, it’s not practical for me to volunteer as a COBOL programmer (most would undoubtedly think that at my age I can’t think clearly anyway). However, I’ll keep my eye on this forum and if I can help in any way, I will.
2 Likes
The whole point of COBOL was to be English-like and readable. Use of periods and structuring your code appropriately - separating functions, etc, lends itself to that quite well.
I always endeavored to make my code clean, structured, efficient and stable. If it went down unexpectedly there were always sufficient breadcrumb trails consistently in the same places where one could find out where the program was and what data it was looking at. If I detected something wrong and had to abend the program there was always an explicit report in the run logs that told you exactly what happened on what input record or DB call, why it was bad and if possible what to do to fix it and finish the run. Those things are pretty easy to do if you set up the structure right the first time.
1 Like
Mark, also a former assembler guy here and I ran across that all the time where code would just fall through because they did not trap properly - they just assumed the data would always look a certain way.
Since you teach I have to relay a story. I was already an experienced COBOL guy when I took some college courses in assembler on Saturdays. My teacher was BRILLIANT, just a total whiz at it.
Then I started going up to his desk t get help on assignments and every time I did his breath reeked of marijuana. Not only was he brilliant, but quite stoned as well!
I don’t use them periods. Here is why. It forces you to you explicit scope terminators such as end-if and end-read. If you are modifying existing code, you should either use or not use periods depending on how the rest of the code is written, just so that it is is consistent. If the code is inconsistent do whatever is the clearest. AND ALWAYS USE END-IF
I have coded in COBOL since 1979 and always used Explicit (periods) termination. I cannot speak for it prior to 1979.
Hi Michael:
Thanks for your message… I love it! Just proves that programming has an artistic side as well as scientific.
I finished my undergrad degree at nights over many years, while I was working. The best course I ever took was on machine architecture… we started with Boolean algebra, built up the basis for digital processing components, then the 2nd term of the course was Assembler programming. The guy who taught us was frighteningly brilliant – he freelanced low-level code fixes to IBM operating systems and software like CICS, and he did it all IN HIS HEAD! One day he announced that he wouldn’t be there for the 2nd mid-term exam and another prof would be present that one week only. Turned out he was the president of the Toronto Blue Jays Fan Club, and he NEVER missed the opening day game of spring training!
If you’ve never read it, I very highly recommend a Pulitzer prize winning book called “The Soul of a New Machine” by Tracy Kidder. It’s one of my all-time favourites and I’ve read it at least 20 times over the years. If you’ve already read it, you’ll know why I say that!
Happy coding!
Mark D’Gabriel PMP
This email, including any attachments, is for the sole use of the intended recipient and may contain confidential information. If you are not the intended recipient, please immediately notify me by reply email or by telephone, delete this email and destroy any copies. Thank you.
1 Like
I’m retired now, but coded in COBOL, assembler, PL/1 and finally C#. Unfortunately, the end of my career involved moving a massive legacy system to a server based system. This was done using .Net and C#, SQL Server. etc. I actually became a fan of that environment, but not the migration.
My COBOL team ascribed to the philosophy that there was only ONE period in any paragraph on the EXIT statement. ALL block structures need to use the END termination, on its own line, with all lines in the block indented.
This eliminates all the old bugs from an extra period, or missing one.
Mark, I did read that, way back wen it first came out in 82 or 83! I was in school studying on a PDP-11. I remember the phrase ‘I’m not putting a bag on the Eclipse!’. Lots of drama over designing a new computer. I suspect it is that way to this day.
Sounds like the sanest behavior.
Requiring the explicit END compares to mandating [both] curly-braces in C-like languages, avoiding confusions like the one mentioned in this IBM reference article. Makes for easier reading and comprehension.
It’ll also be familiar to folx coming from other languages … ruby first comes to mind, but pretty much pick one. Except python, but then python requires indentation to indicate code level.
Yes, COBOL caught up with other languages in many ways, like MixedCase variable names, object oriented structures, etc.
Hi ,
You are an inspiration for many programmers like me. Age is not a barrier and we welcome your thought process, to contribute for this community.
Yes, COBOL is English like, period was the terminator initially, but later due to readability and the advent of other languages, explicit terminators become popular.
Regards
Lakshmisudha