77 A PIC 9(2) VALUE 89.
77 B PIC 9(2) VALUE 80.
77 C PIC 9(2).
ADD A TO B GIVING C.
DISPLAY 'A = ' A.
DISPLAY 'B = ' B.
DISPLAY 'C = ' C.
There is no way the above code can cause an 0C4. Try making it a real program, doesn't take much, and compile with "list" option, or whatever it is these days to get generated assembler for you code. The high-order truncation that is alleged to 0C4 is carried out entirely by code that is not even using these storage locations at the time the truncation occurs. Look at the generated code. To do the ADD, code is generated to convert both A and B to packed decimal (unsigned in this case, extra code generated to ensure (OK, these days it seems there may be extended options for that)) in the program's "work area". The calculation will be done, with the result in another chunk of work area. The result will be converted to a two-digit zoned decimal (unsigned) field. Can't remember if that is in the work area followed by an MVC, or if it is directly to the 77, but doesn't matter.
The point is, everything is within
your program. I can't see you getting any sort of addressing exception when everything is within the program. Don't see compiler or link-editor arrangements can come into it either, dynamic, non-dynamic, I don't care, it is all within the same program. If
the ADD were to cause an 0C4, then I would say it had nothing to do with C, because it would fail as soon as it referenced A (they are not very far apart, so I don't see how one would be addressable and the other not).
To get an 0C4 in this sort of situation (everything in working storage or the work area) then you have to have screwed-up in a program that you have called which has trashed your save area. Or, with several modules linked together, one of the others has to have gone a wild and trashed your code in the load module, which can give you unexpected sorts of abends.
If you have this type of code (not this basic, but without files to access after EOF, ie everything you access is within the module) and you get an 0C4, then the problem is not with the module that failed, but with another module that is linked together.
Even with all this modern COBOL that is around these days, I can't imagine they've made a compiler that would allow a progam not to be able to address itself.