What it means
Programs, and the runtime libraries under them such as Language Environment, get working storage from z/OS while they run. S878 comes from the register forms of GETMAIN and from STORAGE OBTAIN, which most current code uses. When the request can't be met, the system issues message IEA705I and ends the task.
S878 shares its meaning with S80A and S804. Only the form of the request differs. The reason code is what tells you where to look, because it names the storage area that ran short.
| Reason | Storage that ran short | What it usually means | Who fixes it |
|---|---|---|---|
10 | Private area of your address space (the region) | The program needs more than REGION allows, or it keeps getting storage and never frees it | You, with a bigger REGION or a code fix |
0C | LSQA, the system's own storage inside your address space | Too many tasks or system control blocks for the space left | Your system programmer |
04 | SQA, shared by the whole system | A system-wide shortage. Other jobs are probably failing too | Operations and system programmers |
08 | CSA, shared by the whole system | A system-wide shortage, often from one address space using too much common storage | Operations and system programmers |
The private area is what REGION controls. It has two parts, below and above the 16 MB line. Below the line the space is small, well under 16 MB, and shared with system control blocks. Programs that need storage there run out first, however large a REGION you code.
Common causes
- Reason 10, REGION too small for the program, often after it grew or after the input grew.
- Reason 10, a storage leak. The program, or a routine it calls, gets storage again and again and never frees it.
- Reason 10, below-the-line storage used up. COBOL compiled with DATA(24), AMODE 24 code, or many files with large buffers can fill the area below 16 MB.
- Reason 04 or 08, a shortage of common storage across the whole system, often caused by a different address space.
- Your site's IEFUSI exit or SMFLIMxx parmlib member gave the step less storage than the REGION you coded.
How to find the problem
- Find
IEA705Iand read the code and reason, for example878-10, and the size of the request. A request far bigger than anything the program should need suggests a bad length value. - Read the step end message
IEF032I. VIRT and EXT show the most user storage used below and above the 16 MB line. Compare them with the REGION you coded to see which side ran out. - Check REGION on the EXEC and JOB statements. A REGION on the JOB statement overrides the EXEC value for every step.
- For a Language Environment program, rerun with the runtime option
RPTSTG(ON). The report shows heap and stack use and suggests better settings. - For reason 04 or 08, check whether other work failed at the same time, and tell operations.
How to fix it
- For reason 10, raise REGION on the EXEC statement, for example
REGION=128M, or useREGION=0Mif your site allows it. - Move storage above the line. Compile COBOL with DATA(31), link AMODE 31, and set the Language Environment options
ALL31(ON)and HEAP and STACK with ANYWHERE. - Fix any leak. Raising REGION for a leaking program only moves the failure later.
- For reasons 04, 08 and 0C, or when the storage you get is less than you coded, take the IEA705I message and the time to your system programmers.
What it looks like
IEA705I ERROR DURING GETMAIN SYS CODE = 878-10 CLMLOAD1 STEP020
IEF450I CLMLOAD1 STEP020 - ABEND=S878 U0000 REASON=00000010
IEF032I STEP/STEP020 /STOP 2026285.0233
CPU: 0 HR 00 MIN 12.40 SEC SRB: 0 HR 00 MIN 00.09 SEC
VIRT: 8996K SYS: 296K EXT: 32764K SYS: 11736K