AEIR: NOSPACE not handled

What it means

NOSPACE means CICS couldn't find room for data the program wanted to store. Several kinds of command raise it.

For file control, WRITE and REWRITE raise NOSPACE with an EIBRESP2 value that tells you which limit was hit. RESP2 100 means there is no space on disk to add the record to the data set. RESP2 102 means a user-maintained or coupling facility data table has reached its maximum number of records. RESP2 103 means CICS couldn't get storage in its own address space for a user-maintained table entry. RESP2 108 means the coupling facility data table pool is out of room. For the data table cases CICS also issues message DFHFC0432 to warn the system programmers.

For transient data, WRITEQ TD raises NOSPACE when an intrapartition or extrapartition queue has no space left, or when an intrapartition queue would grow past 2 GB. Temporary storage can also run out of space on WRITEQ TS. In that case CICS normally makes the task wait for space, and only raises NOSPACE when the command codes NOSUSPEND or a NOSPACE handler is active.

The default action is to abend the task with AEIR. A program that codes RESP(WS-RESP) gets control back and can test for DFHRESP(NOSPACE).

Common causes

• A VSAM data set has used all its extents or can't extend onto another volume. KSDS files that see many inserts fill up through CI and CA splits.
• An intrapartition TD queue keeps growing because nothing reads it. Its trigger transaction may be disabled, failing or never started.
• An extrapartition TD data set is full.
• A user-maintained or coupling facility data table hit its maximum record count, or the coupling facility pool is too small.
• Temporary storage queues are written and never deleted, so TS keeps growing until a WRITEQ TS with NOSUSPEND gets NOSPACE.

How to find the problem

1. The terminal message DFHAC2206 names the transaction. In the dump, EIBFN shows the command and EIBRSRCE the file or queue. For file control, EIBRESP2 tells you which limit was hit.
2. For a file, run CEMT INQUIRE FILE(name) to get the data set name, then run IDCAMS LISTCAT ALL on it. Compare the high-used RBA with the high-allocated RBA and check how many extents it has.
3. For a TD queue, run CEMT INQUIRE TDQUEUE(name) to see how many items it holds and whether it is enabled. Check that its trigger transaction is defined and working.
4. Look in the CICS job log for DFHFC0432 if a data table is involved, and for z/OS space messages about the data set.
5. CICS statistics for transient data and temporary storage show how full each is and how often requests had to wait.

How to fix it

• For a full VSAM data set, close the file in CICS, then reorganize it with a REPRO out and back in, or reallocate it with more space or more volumes.
• Drain a stuck TD queue. Fix the trigger transaction, or start a task that reads the queue until it returns QZERO.
• Raise the maximum record count for the data table, or enlarge the coupling facility list structure that holds the pool.
• Delete TS queues when the program has finished with them.
• Handle NOSPACE in the program so the user gets a 'try again later' message instead of an abend, and alert operations.

What it looks like

DFHDU0203I 10/18/2026 16:42:30 CICSPRD1 A transaction dump was taken for dumpcode: AEIR, Dumpid: 1/0063.
DFHAC2206 16:42:30 CICSPRD1 Transaction ORD4 failed with abend AEIR. Updates to local recoverable resources backed out.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s CICS documentation for your release.