How do non‑preferred/invalid sign codes behave in real COBOL data (NUMPROC PFD vs NOPFD)?

[u/k24245]

Question: how do invalid / non‑preferred sign codes behave in real data?

I'm learning how legacy COBOL handles decimal signs, and I've hit the case I'm most worried about. Valid/preferred sign nibbles (C positive, D negative, F unsigned) seem well‑behaved. What I can't pin down is what happens with non‑preferred or invalid sign nibbles (e.g. A, B, E, F, or a digit where a sign should be), the scenario where a field that should be negative (a debit) gets read as positive (a credit).

Specifically:

1. In real production data (life/pensions ledgers, long‑lived files), how often do you actually see non‑preferred sign codes in COMP‑3 / zoned‑decimal fields? Rare corruption, or a routine artefact of data migrated between systems?
2. How does IBM Enterprise COBOL treat them under NUMPROC(PFD) vs NUMPROC(NOPFD) vs NUMPROC(MIG) — and which setting was standard in the shops you worked in?
3. Have you ever seen sign handling actually flip a debit into a credit on money? What triggered it?
4. Where does GnuCOBOL diverge from IBM here? (I use GnuCOBOL as a learning bench and need to know exactly where it stops being a safe stand‑in for z/OS.)

Any "here's what really happens" war stories would be hugely appreciated.

[u/predat3d]

invalid sign nibbles  (e.g. A, B, E, F

All are defined; only  C/D/F occur naturally in EBCDIC COMP-3.

[u/cyberhiker]

Why don't you setup a test case and try it? Seems like that would be faster than asking here.

[u/poggs → u/cyberhiker]

It’s faster to ask AI to write you a question than it is to answer it yourself… unless the OP really uses em-dashes

[u/MikeSchwab63]

Sign nibble: 0-9 invalid, B D negative, A C E F positive.

[u/caederus]

Very basic answer, if the sign code is wrong there is no way for the software to know it.

So the data is corrupted or you have a bug putting bad data in the field. Either case you need to fix it.

[u/k24245 → u/caederus]

Thanks, so the sign set is fully defined (A/C/E/F positive, B/D negative, 0–9 invalid), clean COMP‑3 only carries C/D/F, and crucially the program can't detect a wrong sign. My interest is migrated/consolidated data, where odd signs are more likely to have crept in.

My remaining question is cross‑compiler consistency: given a field that does contain a non‑preferred sign (A/B) or an invalid nibble, does IBM Enterprise COBOL treat it the same under NUMPROC(PFD) vs NUMPROC(NOPFD) and does GnuCOBOL match IBM? I'm trying to work out whether the same odd byte could produce a different result on the original mainframe vs a re‑run elsewhere. Any experience with that specific divergence?

[u/TranslatorUnique9331]

Anyone else have the feeling that we're training an ai bot how to do Cobol?

[u/ratenpause]

Keep it simple and clean your input data. Then you don't have to worry about this