What it means
Programs get working storage from z/OS while they run. S80A comes from one particular way of asking, the R form of GETMAIN, which older programs and some system routines still use. When the system can't find enough free storage for the request, it issues message IEA705I and ends the task.
S80A, S804 and S878 are close relatives. They differ only in the form of the storage request. What matters is the reason code, 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 |
Reason 10 is the one most jobs hit, and it's usually yours to fix. Reasons 04 and 08 mean storage shared by every address space ran out, and your job may just have asked at the wrong moment. Other, rarer reason codes cover internal shortages and go to your system programmer.
Common causes
- Reason 10, REGION too small, or a program that keeps getting storage and never frees it.
- Reason 10, below-the-line shortage. An AMODE 24 program, or data that must be below the 16 MB line, fills that small area even though there is room above.
- Reason 04 or 08, a system-wide shortage of common storage. Often one address space has used far too much of it, and unrelated jobs fail as a result.
- Reason 0C, too little room left for the system's own control blocks in your address space, for example in a step that starts many tasks.
How to find the problem
- Find
IEA705Iand read the code and reason, for example80A-10. Note the size of the request as well. - For reason 10, check REGION on the EXEC and JOB statements, then read the step end message
IEF032I. VIRT and EXT show the most user storage the step used below and above the 16 MB line. - For reason 04 or 08, check whether other jobs failed with storage abends at the same time. If they did, tell operations right away, because the whole system is short.
- For a Language Environment program, rerun with
RPTSTG(ON)to get a report of heap and stack use.
How to fix it
- For reason 10, raise REGION on the EXEC statement, for example
REGION=64M, or useREGION=0Mif your site allows it. - Move the program's storage above the line where you can, by linking it AMODE 31 and using the Language Environment options
ALL31(ON)and HEAP and STACK with ANYWHERE. - Fix any storage leak in the program.
- For reasons 04, 08 and 0C, leave your JCL alone. Pass the IEA705I message and the time to your system programmers, and rerun once they've found what used up the storage.
What it looks like
IEA705I ERROR DURING GETMAIN SYS CODE = 80A-10 ACCTSUM1 STEP030
IEF450I ACCTSUM1 STEP030 - ABEND=S80A U0000 REASON=00000010
IEF032I STEP/STEP030 /STOP 2026285.1907
CPU: 0 HR 00 MIN 04.55 SEC SRB: 0 HR 00 MIN 00.06 SEC
VIRT: 9208K SYS: 344K EXT: 102380K SYS: 11204K