MCH3601: Pointer not set for location referenced

What it means

MCH messages come from the machine interface, the layer below the operating system that runs every program's instructions. MCH3601 is the one the machine sends when an instruction needs an address and the pointer it was given is empty. The program asked for data at a location, and there was no location.

Parameters are the usual way this happens. On IBM i, parameters are passed by reference, so each one is really a pointer to the caller's storage. If the caller passes two parameters and the called program declares three, the third has no pointer behind it. Nothing goes wrong until the program touches that third parameter. Then MCH3601 arrives, often several statements after the program started.

The message is an escape message sent to the program that ran the failing instruction. If that program doesn't handle it, the language takes over. An RPG program reports status 00222 (pointer or parameter error) and, with no handler, shows inquiry RNQ0222. A CL program gets an inquiry such as CPA0701. Other programs end with function check CPF9999.

Common causes

• A program was called with fewer parameters than it declares. Typical cases are a CALL typed on a command line without the PARM values, a menu option that passes nothing, or a caller that was never updated after a parameter was added.
• An optional parameter (RPG OPTIONS(*NOPASS) or *OMIT) was used without first checking that it was passed. Check %PARMS or test the address against *NULL first.
• A field based on a pointer (RPG BASED, COBOL SET ADDRESS OF, a C pointer) was used before the pointer was set, or after the storage it pointed to was freed.
• An ILE COBOL program referred to a record or field of a file that was closed, or that never opened because the OPEN failed and nobody checked the file status.
• An SQL stored procedure was started with the CL CALL command instead of SQL CALL. IBM notes this almost always ends in MCH3601. An unqualified SQL call that misses the procedure in the SQL path and finds a plain program of the same name can do the same.

How to find the problem

1. Run DSPJOBLOG, put the cursor on MCH3601 and press F1. Then press F9 for the message details. The to program, module, procedure and statement show where the empty pointer was used.
2. Look at that statement in the source. If it uses a parameter, compare the caller's parameter list with the called program's entry list (*ENTRY PLIST, the procedure interface, the CL PGM PARM(...) or the COBOL PROCEDURE DIVISION USING).
3. Check how the program was started. A job log that shows a CALL with no PARM keyword, or a menu that runs the program directly, points straight at a missing parameter.
4. If no parameter is involved, find the pointer the statement uses and trace where it is set. Debug with STRDBG and stop on the statement before it to see whether the pointer is null.

How to fix it

• Make the caller pass every parameter the program needs, with matching types and lengths. For RPG callers, a prototype checked at compile time stops the mismatch from coming back.
• Guard optional parameters. In RPG, test %PARMS before using a *NOPASS parameter and copy it to a local field with a default. In CL, use MONMSG MCH3601 on the first statement that touches an optional parameter.
• Set based pointers before use, and clear them after the storage is freed, so a later mistake fails on a check you wrote instead of on MCH3601.
• In COBOL, check the file status after every OPEN and stop before any read or write if it failed.
• Call SQL procedures through SQL, either with a qualified name or with the SQL path set so the right procedure is found.

What it looks like

Pointer not set for location referenced.

DSPMSGD MSGID(MCH3601) 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.