Is it better to program COBOL using modules, or have everything you need in one code?

COBOL technical questions
1

So I have recently entered what I would consider an “intermediate” level in the language, and I am making my own codes. At the moment I am planning out a program for record I/O (Adding to a record, amending record fields, deleting records etc etc). So now I would like to know if it is acceptable practice to make modules for each individual utility and use CALL to run them all together (so for instance I have a separate module for record creation and another for deletion and CALL them in a skeleton program).

Using modules feels MUCH more intuitive to me personally and as far as I can tell it has some pros compared to doing it all in one code:

  • The modules can be used as templates for future programs and edited as needed.

  • The code is somewhat easier to edit, follow and amend, as every section exists in isolation. (This is debatable, but personally I find it to be that way)

  • Once you have made the module, its easier to understand how that segment works and if necessary you can adapt all modules into one big code

However it also arguably has some considerable drawbacks, for instance:

  • In some ways the code ends up being longer and less concise as with intelligent use of the PERFORM function many of the paragraphs end up being shared by multiple different sections of the code and therefore only need to be written once. But with modules they end up being written multiple times.

  • Using modules deprives you of the opportunity to use that PERFORM function intelligently, which is in my opinion one of the key skills for a COBOL programmer.

  • Using modules can also create challenges in the sense that now you also need to manage your COBOL files and keep track of them, on top of your data files. This makes it much harder to stay organized in the long run.

Sorry if any of my terminology is wrong, I am fresh into COBOL and I am still picking up the jargon. But anyway I would greatly appreciate any pointers on this dilemma, as I have heard conflicting responses to similar questions.

2

I have more than 20 years of COBOL experience.I would not use separate routines, as disadvantages outway advantages.

3

I’ve seen both kinds, and agree that for me the “all in one” approach is best. What I’ve done is clone these to do different jobs when there are different needs.

The modules would be OK if it were a simple need but there can be a lot of work keeping them generic enough to handle “any” kind of record, file, etc.

So, it’s your call, but I vote “all in one”.

1 Like
4

If you are programming in COBOL, you have to be careful!

You are working for a corporation.

The answer to your question about whether to use special-purpose programs that “do it all”, or whether to use callable modules that do individual things, is a question that the MANAGER has to answer.

Maybe, your manager will “draw a box around your work”, and allow you the “[work]-space” needed, to experiment with concepts such as “reusable code” in “callable” subroutines.

But, that’s only a “maybe”. You’ll probably have to earn that privilege by doing excellent work, quickly and well, and by servicing the human customers --whether they’re employees working in some other unit or (rarely) whether they’re actual clients that your company is servicing, and you’re allowed access to them-- in ways that demonstrate, to them, that you understand the nature of THEIR business, as well as understanding the nature of your own.

And, even if you ARE allowed to “experiment”, you’ll have to prove, to the manager who gave you that “space”/“leeway”, that the decision had been the right one, to make. And you’ll have to do THAT by keeping track of every module and what it does, and then SHOWING, to the manager, your “system” of how you are able to keep track of “which module does what”, etc., and by showing that manager HOW QUICKLY YOU CAN FIND WHAT YOU’RE LOOKING FOR, in that library of “callable modules”.

[And yes, that’ll mean “working nights and weekends”, actually INVENTING an interactive library that works, even as it grows larger.]

And it’ll be great, for awhile. And everybody’ll be happy. And the rest of the team, in your unit, will start using (and writing) “callable modules” (which will be a new skill, for some) and everyone’ll keep track of those modules, using your “system” (and its interface).

And you’ll be “the talk pf the town”. And somebody from Silicon Valley’s version of “Shark Tank” will offer you a million dollars; and you’ll be gone.

And the company you are working for, today, will have to be able to carry on, without you, without losing productivity AND WITHOUT LOSING TRACK OF ALL THE WORK THEY DID, during that “golden age” while you were there.

Are you willing to not only “become a star”, working for that Corporation, but to help that Corporation, “long-term”, by laying the foundation for performing even greater and better work, without you, as they ever accomplished, while you were there?

Are you willing to do all that extra effort, and devote all that time and mental energy TO THE CORPORATION AND TO ITS WELL-BEING, as kind of a “thank you” that you would give, not only to the manager who had given you the permission and “space” that you needed, to do that kind of “research-and-development” work, but as a “thank you”, also, to the corporation whose resources and assets (including company data and databases you’d be working with) THE MANAGER IS RESPONSIBLE FOR, as Steward and Guardian?

COBOL allows HUMANS who are NOT computer programmers, to actually SEE, WITH THEIR OWN EYES, EXACTLY WHAT IS BEING DONE, AND BY WHAT METHODS AND MEANS.

People who make a career, in COBOL, can be people who are working in order to “earn a paycheck”, moving from place to place, thinking of everything as an example of “interesting work” or “challenging problems”;…

…or, people who make a career, in COBOL, can be people who are working in order that they, themselves, through their own work and work-products, PROVIDE VALUE TO THE CORPORATION, keeping it alive and healthy, into a future that they will never see, so that its systems are able to be audited and verified, not only in terms of “the VISIBLE (seen) outputs”, but in terms of the invisible (UNSEEN) functionality that is, also, a CORPORATE process and a CORPORATE asset.

If a manager gives you the permission and “space” to “learn by working” (with “callable routines” being but ONE example), then, that manager is giving you the opportunity to choose what kind of COBOL career (if any) it might be, that you might want to pursue.

[NOTE: Yes, COBOL is “wordy” (aka: “verbose”); and it does take up some space, both “on disk” and “in memory”. But, what does it DO (for English-speakers) that cannot be done by ANY OTHER PROGRAMMING LANGUAGE?]

5

I know this is a year old and DanCOBOLFan has learned much in the past year.

It has been about 30 years since I have done much COBOL but before that I had more than 20 years of experience.

There is a difference between logical structuring and physical structuring. Programmers might describe logical structuring and some programmers might confuse it with physical structuring. I think that physical files is a matter of physical structuring.

Also, a concept that did not exist when I was doing COBOL is object-oriented programming (OOP). The concepts of OOP can be used even if a language does not have special features for it.

I do not understand that perfectly but if there is a way for common code to be put into a separate module that is shared then that would be good.

I think the logical structuring is most important.

6

A couple of comments, ignoring the snark, COBOL programs MAY be larger in source code form. They are likely to be about the same size (or smaller) than programs of equivalent function points in other languages. And, when external subroutines are AVOIDED generally have many fewer external dependencies lowering complexity of software management. Generally, I break down larger programs into smaller SECTION and PARAGRAPH uniits and once they are functionally correct, I put them in COPY files to include at compile time. … Nothing wrong with subroutines but linkage (CALL and RETURN)) just add overhead managing the stack.

7

I absolutely agree. Every independently-maintained, callable module would represent a specific “link” or “hand-off” within which a specific vulnerability might lurk.

Obviously, criticisms of COBOL, related to the memory-requirements of the executing program, as compared with the memory-requirements of an executing program that sports comparable functionality, that was written in some other language,…

…are “old news”, and based on the fact that older versions of COBOL did not make use of “pointers” (and, thus, could not “dynamically allocate” memory, but required the executable to allocate the LARGEST-FORESEEABLE MEMORY-REQUIREMENT, regardless of how much memory was ACTUALLY NEEDED, at run-time, in “normal” (rather than “worst-case”) scenarios.

I suspect, however, that the advent and popularity of other languages was made easier, because “decision-makers” in IT organizations stopped being people who personally KNEW (and cared about) every data-element and its usage and meaning, within that, specific organization [i.e., “the key to the company’s competitive advantage”],…

…and started being people who figured it would be easy, to go from a senior-management position, in a fast-food company’s corporate office, to the position of Chief-Executive of a company that builds fighter-jets for the military of a country whose “ties” to one’s own are “more decorative, than useful”.

They weren’t interested, any more, in KNOWING, PERSONALLY, EXACTLY what the computer was doing, with every data-element it touched. Maybe, because they figured "the age of buying a house; paying it off; owning it, free-and-clear; and dying, in it, surrounded by grieving family-members, was LONG GONE.

[I remember the story of some mathematician who was being called upon, to testify, in a court-case, years ago. He would not accept the results that “Lotus 1-2-3” produced, as a “regression analysis”, but insisted on performing the calculations manually, himself.]

FYI: I, personally, wrote a “Finite-State Automaton” program, using COBOL, before my organization had a COBOL compiler/linker that could “handle” “pointers”.

I knew, on the day on which the “test” of that program was successful, that COBOL had been unfairly maligned; and that there would never be a need for any COBOL programmer to "get logically ‘lost’ in a ‘nested-IF-ELSE-IF’ statement, no matter HOW many ‘levels’ ‘deep’ that statement might be.

IN ADDITION (if the program were written “modularly”, rather than “in ‘spaghetti-code’”) the MANAGER OF THE BUSINESS-UNIT [i.e., “the customer”] would be able to see EXACTLY WHAT WAS HAPPENING.

And yeah, it makes sense, that “maintaining version-control” on a single, giant, self-contained file, would be easier than trying to “maintain version-control” over 30 or 40 files that are stored separately, in multiple “owners’” domains.

8

We are in violent agreement. When I see articles saying COBOL programs are security risks that’s PROJECTION … blaming COBOL, since it is older, as if it has the problems introduced in “newer languages” I tend to post to Social Media correcting the misconception.

9

I’m content to leave the violence to the professionals.

Also, I’ve mostly given up on social media as an enabler of change.

Your reply to whatever post I made, on that “Open Mainframe” site, comes a LO-O-O-o-o-ong time after I made that post; as I can’t remember the last time I logged onto that site.

I might have posted a couple of times, within the last few years, seeking to be helpful. But, the truth is:

  1. I don’t think any decision-maker who has been tasked with deciding what the organization’s I.T. platform and “environment” will look like, is going to be speaking with anyone who has seen any of the posts I’ve made, on any, technology-related, “social-media” site; and

  2. I’m becoming more and more convinced, that the chances for long-term viability are increasingly slim, for any company that hires a contracting firm, to write programs and systems that touch that company’s:
    a) money;
    b) production;
    c) resource-management; and/or
    d) governance.

The security risk is in the lack of willingness, on the part of an I.T. manager, to admit that there were aspects of his/her/their computer’s architecture that the afore-mentioned I.T. Manager did not already know.

If a contractor --even a “cyber-forensics investigator”-- knows that there exists a period of time, between the computer’s performance of “the act of writing to a disk” and the computer’s subsequent performance of "the act of updating the activity-log, to show ‘who did what, when, where and how’,…

…BUT THE I.T. manager does NOT know that same information,…

…"It’s probably ‘just a matter of time’ before “risk” becomes “reality”.

[How far can a signal travel down a length of fiberoptic cable, in a nanosecond?

If two signals are sent from “Point A” to “Point B”, one right after the other,…

…how much EXTRA DISTANCE would “the first signal”, have to travel, in order to make that signal arrive at its destination AFTER the signal that had been sent-out, second, had arrived?

It’s the NOT KNOWING THAT IT CAN BE DONE, that is the security risk.

And that has NOTHING, AT ALL, to do with COBOL.

–Larry

10

The email, itself, is a security risk.