MCH0601: Space offset outside current limit

What it means

Program storage on IBM i lives in spaces, and every space has a current size. When an instruction tries to read or write at an offset past that size, or sets a space pointer outside it, the machine stops the instruction and sends MCH0601. The message names the object that owns the space and the offset that was out of bounds.

IBM's support note says this is nearly always a programming error, usually in a user program. Something believed a piece of storage was bigger than it is. A record buffer, a parameter or a based structure was declared longer than the storage really behind it.

MCH0601 is an escape message sent to the program that ran the instruction. If nothing handles it, the job ends in an inquiry or a function check. A related message, MCH0602, covers pointer alignment, where the storage is the right size but doesn't start on the 16-byte boundary a pointer needs.

Common causes

• A program-described file is read or written with a record length longer than the file's real record length.
• A file was opened with a buffer that doesn't match what the program expects, for example after the file changed and the program wasn't recompiled.
• A caller passed a parameter shorter than the called program declares. The called program then writes past the end of the caller's field. In ILE COBOL, a MOVE to a Linkage Section item that extends past the storage passed in is a classic case.
• A based structure or array was mapped over storage smaller than the structure, such as a user space or an allocated buffer that was never extended.
• With embedded SQL, IBM notes cases in COBOL where the host arrays used to receive rows didn't fit the results returned.

How to find the problem

1. Run DSPJOBLOG, put the cursor on MCH0601 and press F1, then F9. IBM points to the from and to programs in the message details as the main suspects, together with the statement number.
2. Note the object named in the message. If it is a program's own storage, the bad reference is in that program. If it is a user space or a buffer, look at who created it and how big it is.
3. Compare the lengths. Check the file's record length with DSPFD, the parameter lengths on both sides of the call, and the size of any based structure against the storage under it.
4. If the programs named are IBM system programs and your code passed correct lengths, search IBM support for the module name, since it may be a known defect.

How to fix it

• Make the program's record description match the file, and recompile programs after a file change.
• Make caller and called program agree on every parameter's length. In RPG, use prototypes so the compiler checks it. Pass a copy in a field of the declared length if the caller's field is shorter.
• Allocate or extend storage to at least the size of the structure you map over it, and check sizes returned by APIs before reading past them.
• Size SQL host arrays and fetch counts so the returned rows always fit.
• If the failing code is IBM's, apply the PTFs IBM names for it.

DSPMSGD MSGID(MCH0601) MSGF(QSYS/QCPFMSG)

Technical reviewer: Albert Joseph, WND Software.

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