IBM Mainframe Forum

HI,

Today One of our production job got abended with S0C1 + insufficient storage+S80A.
Initially i thought that job were failed due to bad problem policy but no dump was produced so
not able to find the bad policy in abend aid or dump master.For finding out the bad record Put display in abended program and got the policy but after bypassing those policy stilll we got same error.After that I bypassed chunk of policies via bypass control card but still problem were not resolved. So finally I changed the REGION pramaeter value from REGION=8M to REGION=400m
After that job ran successfully without any error.

In my test region i tried to find out the corrupted policy or the policy which require more virtual memory but for all the input policies job ran successfully without any error in our test region.

I don't know why we got abend during production cycle run.

With what little you have provided, it looks like you got an S0C1 in the production program, and then ran out of virtual storage when the dump-processing routines were being loaded to process the dump from the S0C1. If you look back through three or four production logs from that job, you'll probably find it has been running quite close to the maximum region allocated to it. If you do find this to be the case, then the region should be increased permanently for that job/step. Also something/someone should be monitoring the virtual memory usage, to avoid a production job going "bang" simply because of that.

Why you can't recreate the S0C1 in another environment is simple - to state. "Something", and that "something" actually led to the abend somehow, is different where you are running it now to where you were running it in production.

Simple to state, not so simple to find.

Talk to your technical support people and explain the problem you had, and that you can't recreate it. Ask them if there is anything they can do to help you recreate the problem.

Is there anything, even just a PSW, from the S0C1 abend?

It would seem there are two problems here, though they could be linked.

There are two possible reasons for an S0C1: Something happened that caused your program to take a wild branch into storage that does not have instructions, or the programmer deliberately inserted an invalid instruction that is "executed" in response to a situation the programmer did not think would occur. The advantage is an ABEND macro destroys register 1 and sometimes other registers, where an S0C1 preserves all the registers. Unfortunately, you have to figure out which situation is happening here.

An S80A often indicates an out of storage problem, but it may indicate other problems, and it may be from a FREEMAIN, not GETMAIN. As with the S0C1, it is up to the programmer to deduce the real problem.

Hello,

Suggest you concentrate on the first error first.

The second abend may be the victim rather than the cause of the problem.

If the first problem/abend cannot be recreated, it is possibly due to some not-completely-correct code combined with an unexpected data combination.

Thanks your help and suggetion.
Now i have successfully recreated the problem in my unit region
If I am taking region size 8M in job then it got failed with same error as production.After increased the region size to 400m job ran successfully without any error.
it seems that problem with the region size.In previous i thought that abend occured due to bad or corrupted policy but job ran successfully in production as well as in my region without bypassed any policy just increased the region size.
Please correct me if i am wrong.
Thanks !!!

Hello,

Suggest you detemine what really caused the problem (i.e. where is the "extra" memory needed?).

What happens when 400m is not enough? 800m?

To prevent this happening in the future, you could run the 8m execution and determine where things go wrong. Otherwise, this is just a time bomb waiting to happen again.

Also, your multi-post in another forum has been locked. Here, as there, you can lost posting privileges for multi-posting the same question.

You are saying the currently the job in production runs in 8M and now, to run to completion with that data, it needed 400M? An extra 392 megabytes? A 5000% increase in memory usage?

Something is not right and, as Dick says, you'll have to find it (or get help finding it).

Has the program/jcl been changed recently? Did you check back through the logs like I suggested? Did you get a PSW from the S0C1 abend?

How to get a S0C1 from a lack of virtual storage? What language are the modules in your load? Are any doing any "memory aquisition", GETMAIN, or heap storage? Especially anything which is trying to load code to execute (outside of normal call methods)?

If you can't get anywhere with the dump yourself, you should consult with your boss with the idea of handing it over to someone more senior or to the Systems' Programmers. Hopefully this is a new problem, not one which has been festering for a while. It, like any abend, needs to be solved as soon as possible, because it can happen again at any time, and it can be damaging data that you don't yet know about - the less that you allow it to damage, the less the pain of the data fix.