CPA0701: Unmonitored message received by CL program

What it means

When a command in a CL program fails, it sends an escape message to the program. If the program has a MONMSG for that message, the program handles it. If it doesn't, the system stops the program and sends CPA0701. The text reads like CPF9801 received by PAYCL at 1200. (C D I R). The first message ID is the real error. The program name and statement number tell you where it happened. The letters are the replies the message accepts.

The help text explains that the CL program detected an error at that statement and that the inquiry can be avoided by changing the program. It is a severity 99 inquiry, so the job waits. In an interactive job it appears on the user's screen. In a batch job it goes to the system operator's message queue, QSYSOPR, unless the job is set to answer inquiries on its own.

A similar message, CPA0702, names a procedure instead of a program and statement. The replies are the same.

Common causes

• A command in the CL program failed and the program has no MONMSG for its escape message. The message ID in the first part of the text is that error.
• An object the program uses is missing or not on the library list, giving CPF9801 or a similar message.
• An object is locked by another job, or the user isn't authorized to it.
• A called program ended in error and sent an escape message back to the CL program.
• A machine check such as MCH1211 or MCH3601 happened inside the CL program itself, for example a division by zero in CHGVAR or a parameter that wasn't passed.

How to find the problem

1. Press F1 on the CPA0701 message. The help names the CL program, its library and the statement number.
2. Run DSPJOBLOG (for a batch job, WRKJOB and option 10, or the job log spooled file) and look at the messages just above CPA0701. The original escape message and the diagnostics before it say what went wrong.
3. Find that statement number in the program's compile listing to see which command failed.
4. In a batch job, look in QSYSOPR with DSPMSG QSYSOPR to find the waiting inquiry.

How to fix it

• Pick the right reply. C cancels the CL program. D dumps the CL program's variables and then cancels it. I ignores the failing command and goes on with the next one. R runs the failing command again. C is the safe choice when you don't know the program, and D gives the developer more to work with.
• Use R only after fixing what made the command fail, such as releasing a lock or adding a missing library. Use I only if you know skipping that command is harmless.
• Fix the cause named in the original message, then rerun the job.
• Change the program. Add MONMSG for the messages that can happen at that command, or a global MONMSG CPF0000 right after the declarations with an error routine, so the program handles errors instead of stopping.
• Be careful with automatic replies. A batch job with INQMSGRPY(*DFT) gets the default reply, which forum users report as C. A system reply list entry for CPA0700 is generic and matches every message from CPA0701 to CPA0799, so a reply such as D there affects all of them.

What it looks like

CPF9801 received by PAYCL at 1200. (C D I R)

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