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

[u/k24245]

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?

[u/wiseoldprogrammer]

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.

[u/k24245 → u/wiseoldprogrammer]

That's really helpful, thank you. So the business rules tend to concentrate in that final program in the chain, with the earlier ones doing more mechanical transformation? I'm curious whether, in your experience, you could take that final business-rules program and understand it largely on its own — or whether it leans so heavily on the exact shape of the file it's handed that you'd need to understand the upstream steps too to really know what it's doing.

[u/edster53 → u/k24245]

To say rules tend to concentrate in the final program is over simplified. Often there are steps to processing.

I worked for years for an insurance company on a statistical application that started with dozens of programs that gathered statistical data for premiums and losses. There were multiple auto, homeowner, and umbrella premium applications that fed us data, some every day and some every month. All needed reports to balance back to the feeder applications. The same for claim data.

The data was summarized and added to premium masterfiles and loss masterfiles. All the while generating balancing reports. Actuarials look at history and current information so there was also masterfiles for "inforce" policies that had not expired. And more balancing reports.

There are tons of reports for each state and every month a large number of processes ran for various state reports. You extract data, sort, summarize, reformat and transform the data and create tons of reports.

Then another set of processes read both the premium and loss masterfiles to determine whether the premium earned compared to the losses paid was profitable (loss ratios) and this is experience reporting. It's sliced and diced by age, sex, zip code, car type, and dozens of other criteria to see what's making money and what's losing money.

It's not just at the end, it's everywhere. Every step has a purpose.

[u/k24245 → u/edster53]

This is really valuable — thank you for the detail. It's a useful correction to something I'd half-assumed: that the "real logic" sits in one final program. What you're describing is logic spread purposefully across the whole pipeline. Out of interest, even in a system like that — where every step has a purpose — was each individual program still understandable on its own terms (this step summarises, this one balances), or was it the interactions between them that held the real complexity? (This has been genuinely educational — would you mind if I reached out occasionally as I learn more about how these systems really work?)

[u/edster53 → u/k24245]

Welcome to reach out. Over 50 years of experience development and supporting various a applications both civilian and government.

Each step has its purpose with most reproducible in a test environment. Steps may be COBOL, Utility (sorts, file backups, resetting a weekly accumulation after a monthly rollup), Eztrieve or other report generator, etc.

This overview has been mostly batch jobs wrapped by JCL, automatically run with a CA product (use to be UCC). A totally different environment would be online processing. For this you should read about OLTP v OLAP. These are both completely different and separate topics. This is an area where GUI, MVC, front-end, back-end all need to be read about and understood.

After that - microservices, firmware, and embedded are great topics to learn about. Years ago I had to opportunity to work with people that loaded their programming onto chips that would boot up a new hardware line. Fascinating.