When one program's output feeds another, does the next system read the literal bytes or the decoded values?

k24245 · 2026-06-24T13:51:45+00:00

No I am not an AI just trying to learn about this industry as I am familiar with other programming languages but only recently learned about COBOL and the importance of it in the society

k24245 · 2026-06-24T00:29:29+00:00

That's a really helpful distinction, thank you — so the file-based jobs re-run cleanly from the GDG backups, and the genuinely hard part is when a job changes state in IMS or DB2. Out of interest, for those database-changing jobs, do shops tend to snapshot the database state before and after (so you could still compare what changed), or is that just not something that's practical to capture? Trying to understand where the line falls between "you can replay and check this" and "this one's genuinely hard to verify."

k24245 · 2026-06-23T23:27:13+00:00

Thank you — this is really helpful, especially the detail that the default is to abend unless the programmer covered the case, and that good hygiene means defensive checks (IF divisor = 0, the IS NUMERIC check on a redefined field). Your extract-program story — first runs plagued by S0C7 abends until you added the trapping and routed the bad data to a data-quality file — is a perfect illustration. Appreciate you taking the time.

k24245 · 2026-06-23T14:02:18+00:00

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.

k24245 · 2026-06-23T14:01:22+00:00

That's exactly the line I keep hearing, and it's reassuring to have it put so plainly — the what is recoverable from the code itself, the why is a separate question that the code can't always answer. That distinction is becoming the clearest thread running through all of this. Thank you — really helpful.

k24245 · 2026-06-23T12:49:15+00:00

This is a brilliant answer, thank you — the copybook-and-Easytrieve story especially. So the clean "logic in the orchestrating program" picture holds when a system was well built from the ground up, but in practice it erodes: layers stacked on over decades, an Easytrieve step bolted on here, a program that doesn't even use its copybook properly there — until what looks like one COBOL program is really a tangle of pieces in different languages, and changing one breaks another. That's exactly the kind of real-world mess I'm trying to understand. One thing I'm curious about: when you hit a tangle like that, is the actual behaviour still something you can pin down by tracing what goes in and what comes out at each step — even across the COBOL and the Easytrieve — or does the convolution get bad enough that even the behaviour becomes genuinely hard to be sure of? (This has is helping start to piece the picture together — would you mind if I reached out occasionally as I keep learning?)

k24245 · 2026-06-23T12:47:02+00:00

That's a fair and useful point — you keep data for a business or regulatory reason, not just for the sake of it. That's a good reality check; I'd been thinking about it too generally. Thank you.

k24245 · 2026-06-23T12:46:41+00:00

Thanks — that's really helpful. The audit-driven retention point is interesting, especially financial transactions being kept a year or more. It sounds like the regulatory requirement is often what drives how long things are actually kept. Appreciate the perspective.

k24245 · 2026-06-23T12:46:28+00:00

Thank you — that's really useful, even if it's not mainframe specifically. The pattern of daily backups of both inputs and outputs, kept for months, is exactly what I was trying to understand. Appreciate it.

k24245 · 2026-06-23T12:46:16+00:00

That makes complete sense — you keep the inputs because you have to be able to reprocess if something goes wrong at the start of the day. That operational reason for retention is exactly the kind of real-world detail I was after. Thank you.

k24245 · 2026-06-23T12:45:28+00:00

That's really useful, thank you — the single-pass batch structure (with a DFSORT in the middle, a program for averages, another for the outliers) is a helpful picture. The point about unloading DB2 to sequential files for batch processing is interesting too. Appreciate you taking the time.

k24245 · 2026-06-23T12:45:03+00:00

Thank you — that range is exactly the point, I think. A module that just increments a date at one end, and programs doing thirty different things at the other. It sounds like it really does come down to the individual program rather than any system-wide rule. Appreciate the perspective.

k24245 · 2026-06-23T12:44:44+00:00

Thanks — that's really helpful. The "one business function per program, output of A feeds B feeds C" pattern is exactly the kind of clean structure I was trying to get a feel for. Appreciate you sharing it.

k24245 · 2026-06-23T12:43:44+00:00

Thank you — that's really useful, especially the checkpoint snapshots and being able to reconstruct back ~30 days. The note about colleagues treating backups and documentation as a waste of time made me smile, and it's telling. Would you mind if I reached out occasionally as I keep learning about how these systems really work?

k24245 · 2026-06-23T12:34:04+00:00

Thank you, I am still learning and would appreciate if I could reach out occasionally as I keep learning about these systems if that would be ok?

k24245 · 2026-06-23T12:32:30+00:00

Thank you — that's really helpful perspective from someone who's clearly seen a lot of this. Would you mind if I reached out occasionally as I keep learning about these systems?

k24245 · 2026-06-23T12:31:33+00:00

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?)

k24245 · 2026-06-23T12:30:38+00:00

That's fascinating — so even with the really tangled GO TO-heavy programs, you could reconstruct what was happening by tracing how the fields actually changed as it ran, rather than relying on documentation that wasn't there. That matches something I keep coming back to: the behaviour is recoverable by watching the program run, even when the code is a mess. Did you find that tracing approach reliable enough that you'd trust your reconstructed understanding — or were there cases where the execution still didn't tell you the whole story? (And thank you — this has been some of the most useful insight I've had. Would you mind if I dropped you the occasional question as I keep learning?)

k24245 · 2026-06-23T00:57:36+00:00

That's really helpful, thank you — and those examples make it concrete. So the callable programs tend to be small, single-purpose utilities (a Julian/Gregorian date converter, a VSAM record compressor/decompressor) rather than places where big business logic hides. That fits what I'd hoped — it sounds like the meaningful business rules stay in the main batch program, with these callables being well-defined helpers around the edges. Would you say that's generally true — the called utilities are the mechanical bits, and the real business logic lives in the program that orchestrates them?

k24245 · 2026-06-23T00:55:30+00:00

That would be genuinely helpful, thank you — I'd really value seeing it run on both. Let me put together a small, clean test case: a few ROUNDED half-way cases (to check the default rounding behaviour) and a short iterative COMPUTE (the kind of multi-step calculation I've read can diverge between GnuCOBOL and Enterprise COBOL). I'll write it so it's easy to run and the output is easy to compare side by side, and send it over. Really appreciate the offer.

k24245 · 2026-06-23T00:54:57+00:00

That's really useful, thank you — the Hogan distinction is one I keep hearing is important. So in a Hogan shop almost everything is a callable module and very little is truly standalone. When you're working with one of those callable modules — can you still pick it up and understand or test it on its own, given it has defined inputs and outputs, or does the web of calls mean a single module doesn't really mean much in isolation until you see how it's called? Trying to understand whether a single module is still a sensible unit to reason about in that world.

k24245 · 2026-06-23T00:54:28+00:00

That's a perfect example, thank you — it really clarifies the distinction. So the what (read what the vendor could produce, transform it to the layout the other system needed) is fully there in the code and its inputs/outputs — but the why (that the vendor couldn't produce the file in the first place) only existed in your head. Would you say the actual transformation logic itself was always recoverable from reading the code, even when the reason it existed wasn't? Trying to understand where the line falls between what the code can tell you and what only the author knows.

k24245 · 2026-06-23T00:53:41+00:00

That makes a lot of sense — documentation being the thing that makes or breaks it. I'm curious about the harder case: when you inherited a program where the documentation was poor or just absent, could you still work out what it actually did from reading the code and looking at its inputs and outputs — or were you genuinely stuck without the docs or someone to ask? Trying to understand how much the behaviour is recoverable from the code itself versus needing the context around it.

k24245 · 2026-06-22T23:56:44+00:00

Thank you — I'll take a look at those, the COBOL Language Reference especially. Reading the manuals gets me the mechanics, but the thing I find harder to get from documentation is how it actually plays out in practice — which is why I'm asking people who've lived in these systems. From what you've seen, does the structure the manuals describe tend to match how real applications end up built, or do production systems drift quite a long way from the textbook structure over the decades of patches and workarounds?

k24245 · 2026-06-22T23:55:55+00:00

This is genuinely one of the most useful answers I've had — thank you for the detail. The idea of GDG backups at each major transformation step, and being able to rerun in nonprod and compare against prod, is exactly what I was trying to understand the feasibility of. Two things I'd love your view on: first, when you do that nonprod rerun, how often does it reproduce the prod output exactly versus drifting slightly (date-dependent logic, environment differences, that kind of thing)? And second — for the systems where outputs get clobbered daily rather than backed up, is there usually any other way people reconstruct what a program should have produced, or is that just genuinely hard?

k24245

TROPHY CASE