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.