u/k24245

A question about how these systems behave when the data goes wrong, rather than the happy path. 

When a batch program hits something like a divide-by-zero, a numeric field overflowing its size, or an invalid value where a number should be — in practice, does the typical production program abend (and the job stops), or does it carry on, maybe with ON SIZE ERROR handling, maybe with a leftover or default value in the field? 

I ask because I imagine the ‘normal’ answer varies a lot — some shops code defensively with ON SIZE ERROR everywhere, others let it abend so nothing bad slips through silently. What's been your experience of how these edge cases are actually handled, and have you seen cases where a program quietly continued with a wrong value rather than failing loudly? Any war stories there would be really helpful. 

I'm trying to understand what ‘the same output’ really means when one COBOL program's output file feeds into another system. 

My assumption is that it depends on what the downstream system actually consumes. If it reads the literal characters/bytes of the file — including how a number is formatted, how a sign is represented (trailing sign, overpunch, CR/DB), how fields are padded — then two files that represent the same values but format them differently would NOT be interchangeable. But if the downstream just decodes the values, the formatting wouldn't matter. 

In your experience, which is it usually — is the exact byte-level layout and sign/format representation of an output file load-bearing for whatever reads it next, or do downstream systems mostly re-parse into values so formatting differences wash out? Trying to understand whether ‘identical output’ has to mean byte-for-byte or just value-for-value. 

For those who've worked in production mainframe environments (banking, insurance, building societies especially): in practice, do shops retain their overnight batch input and output files long enough, and in a usable enough form, that you could take a historical run and replay the same inputs to check you get the same outputs? Or is that data typically gone, archived beyond practical reach, or just not kept that way?

Trying to understand whether "compare against what the system actually produced in production" is realistic, or whether you're usually forced to reconstruct expected results some other way.

Two things I'm trying to pin down about how the maths actually behaves:

1. When ROUNDED is written with no MODE phrase on Enterprise COBOL for z/OS, my understanding is the default is nearest-away-from-zero (round half up), not banker's rounding — can anyone confirm that's right for current versions?
2. I've read that GnuCOBOL with -farithmetic-osvs only emulates the older OS/VS intermediate-precision behaviour, not modern Enterprise COBOL — and seen a forum case where iterative COMPUTEs diverged significantly between the two. For ordinary financial maths (interest, premiums), is that divergence something that actually bites in practice, or mostly a corner-case curiosity?

Trying to understand where a calculation done off-mainframe would silently disagree with the real thing.

Two things I'm trying to pin down about how the maths actually behaves:

1. When ROUNDED is written with no MODE phrase on Enterprise COBOL for z/OS, my understanding is the default is nearest-away-from-zero (round half up), not banker's rounding — can anyone confirm that's right for current versions?
2. I've read that GnuCOBOL with -farithmetic-osvs only emulates the older OS/VS intermediate-precision behaviour, not modern Enterprise COBOL — and seen a forum case where iterative COMPUTEs diverged significantly between the two. For ordinary financial maths (interest, premiums), is that divergence something that actually bites in practice, or mostly a corner-case curiosity?

Trying to understand where a calculation done off-mainframe would silently disagree with the real thing.

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?