One of my program failed with S0c4. I figured that the program is stepping on storage and increased the Region parameter (Region=0M). Now after all the records are processed, The program is failing with S30A.
Code:
CEE3250C The system or user abend S30A R=00000024 was issued.
From compile unit RFSAIAS2 at entry point RFSAIAS2 at compile unit offset +00008ADA at entry offset +00008ADA
at address 000105D2.
Code:
IEF450I COGYSAS2 AIAANAL2 STEP1 - ABEND=S30A U0000 REASON=00000024 858
TIME=11.20.56
IEF234E K 5534,397066,PVT,COGYSAS2,AIAANAL2
TMS014 IEF234E K 5534,397066,PVT,COGYSAS2,AIAANAL2
TMS014 IEF234E K 5534,397066,PVT,COGYSAS2,AIAANAL2
IEF234E D 55E9,930689,PUB,COGYSAS2,AIAANAL2
TMS014 IEF234E D 55E9,930689,PUB,COGYSAS2,AIAANAL2
-STEP1 AIAANAL2 *S30A 96979 96603 10.32 .01 23.9 18628K BATCH
IEF234E K 55AA,930647,PVT,COGYSAS2
TMS014 IEF234E K 55AA,930647,PVT,COGYSAS2
IEF404I COGYSAS2 - ENDED - TIME=11.21.03
Storage dump near condition, beginning at location: 001DA7D4
Quote:
System manual says:
Explanation: An error occurred when the system tried to run an R form of
the FREEMAIN macro. A reason code in the SDWACRC field of the system
diagnostic work area (SDWA) explains the error:
24 One of the following:
o In the private area, the area specified on a FREEMAIN is
larger than the area specified on the original GETMAIN.
o The FREEMAIN start address is not valid.
I believe the program is still using the system area and hence when it tries to free the memory after the execution it is failing.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
1. Increasing memory to REGION=0M is NOT a fix for a S0C4 abend.
2. The S30A is almost certainly due to the unhandled S0C4 abend.
3. Unless and until you perform actual debugging and find out what caused the S0C4 abend in the first place, and fix that error, we cannot provide you with any assistance on the S30A abend since it is directly caused by the problem you did not attempt to resolve.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
The S30A could be caused because the program overlaid memory that contains the value used by the FREEMAIN, hence fixing the S0C4 would also fix the S30A abend.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
i believe,
that a problem correctable with an increase of region size
is delineated by an error code indicating
not enough ...
and either the program will not load,
or if during execution, it is due to some service requesting more memory,
and the memory request (getmain) will fail with a code indicating
that there is not enough storage available to fulfill the request.
a s0c4 (this is not a belief)
is simply your program trying to access storage,
that is not assigned to you program.
very common causes:
1. improper use of COBOL internal tables
i.e. going beyond the the allocated size of the table
which has been the problem of several of your topics
apparently the code in your shop was developed by less that competent coders -
they failed to code overflow logic.
most of the time this is due to additional business needs
added to the table,
and the analysis of the table size
was not properly done prior to the code change.
2. insisting on accessing the record area in the buffer
(that is the FD definition of a record)
when the file is not open.
3. change in linkage defintions
which are not properly propagated throughout the system,
resulting in a sub-module steps-all-over the working storage of a CALLing module.
there are others, but I would insure the 3 above are properly analyzed.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I've never tried to "fix" a S0C4 by increasing the region.
If that is literally all that you did for the S0C4, I suppose if something is allocating an erroneously huge amount of storage which was previously ending "outside" your region and is now "inside" that might account for it, but I've never heard of that - because I don't know anyone else who just tried increasing the region either.
Go back to the region size where you had the S0C4. Recreate the problem. Solve the problem creating the S0C4. I also suspect that the S30A will then go away.
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
Quote:
I figured that the program is stepping on storage
Those are hard to debug. Many times, the storage overlay occurs first, then a subsequent user of the storage finds garbage, for example, a bad pointer, and abends. That is, there are two segments of code: 1) the perpetrator and 2) the victim.
With a dump, you can figure out who the victim is (location 001DA7D4). It is not so easy to determine who the perpetrator is.
You may be able to determine what storage is corrupted and then step through your program while monitoring the storage.
-----
It might help if all of your control blocks had a eyecatcher text at the beginning. In your dump, you may be able to see which control block has overlaid / been overlaid.
-----
(I am not a COBOL guy) If you have a set of programs, and you change a control block, be sure to compile all of the parts that reference that control block. Otherwise, the result is that you some parts that think the length is A while other parts think the length is B, for example.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
If your code uses internal tables and the code abends with an s0c4, you could compile specifying SSRANGE which will "catch" when the code attempts to use an address that is outside the table.
