IBM Mainframe Forum

hi, Rayster

Here is an example for SOC4 error
ex:

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.

//result will be 169 but C can store only 2 values, in this case SOC4 error will occur

i faced this error lot of time, and i corrected it successfully..


if i am incorrect,correct me

Thank You

Ravi Teja, which compiler were you using? Under Enterprise COBOL for z/OS, that behavior does not occur.
Code:produces results of

Hello,

//result will be 169 but C can store only 2 values, in this case SOC4 error will occur

Please test before posting. . .

Why do you believe this could cause an 0c4?

Whether something like this will create an S0C4 depends on how the compiler and run time library layout storage and exactly how that storage is allocated. There is quite a good chance the sample code will not create an S0C4 ABEND.

A personal library function I use quite a lot in my work has a similar issue, though the odds are it will get the S0C4 in an input field rather than an output field. The documentation for it warns it can get an S0C4, but while I was testing it I attempted to create the S0C4 it could theoretically get. Nothing. Then, months later, an S0C4 completely out of, I thought, nowhere. After more analysis I realized, "Oops!"

Hello,

There is quite a good chance the sample code will not create an S0C4 ABEND.

Quite the understatement, i believe

Having worked with every mainframe/mv-whatever COBOL compiler IBM ever released across more than 100 mainframe centers, i have not yet seen the code Robert posted cause an 0c4. I'd be interested to hear which exception within the 0c4 occurred.

If there is a way to predictably cause this abend with the posted code (using 77 level entries and an add), i'll surely add this to my "treasure trove".

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.

The replies above are correct. An OC7 does not turn into a OC4. There are multiple issues.
Easy answer; Search for the missing dataset. This could be a lib not concatenated properly, or underlying IMS DL1 Database missing from JCL or just missing(look for the VSAM, OSAM name), or something else you are trying to reference/use and it is not there. (like reading after it is closed)

Why are you replying to posts that are over 3 years old?, so far all seven of your posts have been to issues that have been solved or ignored