MVSFORUMS.com

[gupta]

Hi List,

I am facing SOC4 abend in my program.
I was able to determine the statement which caused the error with the help of offest as explained in one of the post. But not able to determine the actual cause (Compilation problem/Length problem/Data problem). Can any one guide me to rectify the abend.

The statement that cause the abend is

MOVE DATA-AREA TO WS-DATA-AREA

LINKAGE SECTION.
01 WS-DATA-AREA PIC X(24576).


The compilation option are
RMODE=ANY and AMODE=31 and DATA=31


Thanks

[dtf]

Well, there are probably several posibilities. However from the scant information that you have provided I guess the first thing that I would advise that you check is the length definition of WS-DATA-AREA. If you have a mismatch in this defintion between the caller and the called routine, that could cause a S0C4.

.
________
Fiesta RS Turbo

[gupta]

dtf,

I have a clarification regarding the length of DATA-AREA.
It's been declared as X(24576), but it varies i.e. somtime it will contain
24576 bytes of data or less than that. Whether this might cause the problem.




Thanks

[dtf]

What the area contains will not matter. What the defined length certainly could. When you call a program and pass a linkage area, you are passing an address.

Lets assume an extreame case.........

Caller defines

01 PASSED-FIELD PIC X.

Called defines:

01 WORK-FIELD PIC X(32000).
LINKAGE SECTION.
01 PASSED-FIELD PIC X(32000).
.
.
MOVE WORK-FIELD TO PASSED-FIELD



Back in the calling program, the area starting with address defined at PASSED-FIELD for 32000 bytes is going to get overlayed. Any number of things can happen at this point. If this area extends outside of storage owned by your task, you'd get a S0C4. If the area is still within your program, but the storage contains instructions that you later attempt to execute, you'd probably get a S0C1. In other cases, if you never reference this area, you might not abend at all, and/or you might get unpredictable results since you overlayed other storage and corrupted values.

Finally, in a very bizarre set of circumstances, I have seen something happen in a CICS environment which took me quite a while to debug.

What was occuring, was that a MOVE statment was actually failing intermitantly. This involved the MOVE of DFHCOMMAREA. I traced the failure to the fact that the lengths were defined differently between the LINK "from" and LINK "to" programs. Since this was a 32k move, the COBOL compiler generated an Assembler MVCL. Because of the way storage was being allocated, and the difference in the way the fields were defined, what resulted was that the two fields based upon their ADDRESS and LENGTH would have overlapped.

MVCL will not execute if the fields overlap. Since COBOL has no provision for checking this condition the move would either execute or fail depending on where storage was allocated by CICS. To make matters worse, the debugging tool that I was using at the time "INTERTEST" masked the problem all together.

Bottom line is that you need to be very careful about definitions of passed parameters.

DTF

Another thing I just thought of that you should check, is that your procedure division statement (or entry statement) contains a USING for the passed PARAMETER. I don't know if the compiler would give you an error or not, but if it doesn't and you tried to move something to a linkage field without having specified a USING, then you would have an adressability problem.
________
Tornado engine

[gupta]

Hi Dtf,

Thanks for your informations, but unfortunatly for me the length was
same.
I encounterd a strange thing, when we moved the code from ACT to
System testing region we are not encountering the error.
can you please share any information regarding this.


Thnaks