S878 and S80A — not enough virtual storage in the region

A program asked for more virtual storage than its region allows. Reason 10 with IEA705I is the common case: raise the region, or find out why the program needs so much.

What happened

A job step ended with ABEND=S878 (or S80A). Just before the abend, the job log and JESYSMSG show IEA705I with the system code and reason.

Job log (illustrative)Illustrative example

IEA705I ERROR DURING GETMAIN SYS CODE = 878-10 TARIFRUN RUN
IEF450I TARIFRUN RUN - ABEND=S878 U0000 REASON=00000010

What it means

A program gets working storage with a GETMAIN (or STORAGE) request. With reason 10, there was not enough virtual private storage left in the step's region to satisfy the request. 878 and 80A mean the same kind of failure from different storage requests.

The region comes from REGION on the EXEC statement; REGION on the JOB statement overrides every step's. REGION=0M asks for all the storage the installation allows, which many sites limit.

Typical causes

The data a program keeps in memory grew (a bigger table, more entries), but the region stayed the same.
A program change made its tables or buffers larger.
A program keeps getting storage and never frees it (a storage leak), so it fails however big the region is.

Where to look

IEA705I: the system code, the reason and the step.
The REGION on the EXEC and JOB statements, and what the step had before.
What changed: data volumes, a new release of the program, a new input.

How to fix it

If the program now needs more storage for good reasons, raise REGION on the step to a real value with headroom (for example from 32M to 64M).
Avoid REGION=0M as a fix: it hides how much the program really needs.
If the storage keeps growing during the run while the data does not, give the problem to the developers: a bigger region only delays the next abend.

Interview question

A job that has run for years abends S878-10 the day after a product launch. Nobody changed the program. What do you check?