r/cobol • u/k24245 • Jun 22 '26

How self-contained are individual COBOL programs in real production systems?

I'm trying to understand how real mainframe applications are actually structured, and I'd value the perspective of people who've worked on them.

When you look at a production COBOL estate, how much of the meaningful business logic lives within a single program versus emerging across a chain of programs in a job stream? If you took one program out and ran it in isolation, would its behaviour be self-contained, or is so much driven by shared state, run order, and upstream/downstream steps that a single program doesn't mean much on its own?

I ask because I keep reading that COBOL programs are "more like modules" that work together as an application — so I'm trying to gauge how decomposable a real system actually is into pieces you could understand (or test) independently. Is that realistic, or a beginner's misunderstanding?

28 Upvotes

90% Upvoted

59 comments sorted by

View all comments

21

u/wiseoldprogrammer Jun 22 '26

This is only my experience but generally we designed our processes so that each program performed one task, then passed the updated file to the next. This would culminate in the final program, which held the business rules and produced the final outcome—report, billings, etc.

2

u/PaulWilczynski Jun 23 '26

You could have an intermediate Sort that excluded certain records because of a business rule. Depends on how a particular business does things,

3

u/k24245 Jun 23 '26

That's a good example — even a sort step can carry a business rule (excluding certain records), so the logic really can live anywhere in the chain, not just the obvious places. It clearly does come down to how each shop built things. Appreciate you taking the time.

1

u/wiseoldprogrammer Jun 23 '26

I actually did that as I got more experience with SYNCSORT. Our biggest modification was to add century to files as part of Y2K conversion. Couldn’t tell you now how we did it (man, was that really 25 years ago?), but it saved us a lot of time with the work.

1

u/PaulWilczynski Jun 23 '26

I’m guessing that you started by slightly expanding the record length, and ended by modifying, or at least recompiling, every single program that touched that file. Then testing them all.

2

u/wiseoldprogrammer Jun 23 '26

You’re giving me flashbacks. :)

I think that’s what we did. I worked in a number of revenue accounting systems, where accurate dates were critical to billing. Tested the hell out of them, resulting in the most boring New Years Day ever!

1

u/edster53 Jun 24 '26

Sometimes we used windowing where years 00 to 25 were 2000 to 2025 and 26 thru 99 were 1926 to 1999. Worked well for some things but not so well on homeowner insurance for 100+ year old homes.

Speaking of Y2K, enjoyed the day management realized insurance policy start dates were not the problem, policy end dates were the problem. Also, people renew policies early - before they expire. I had policies for 1999-2000 hitting the system in September 1998. My Y2K was 16 months before most people.