CPF4165, QMAXSPLF and the Case of the Missing Output Queue

  • Home
  • /
  • Blog
  • /
  • CPF4165, QMAXSPLF and the Case of the Missing Output Queue

October 24, 2026

Yesterday, I had one of those wonderfully misleading IBM i problems, the kind where the error message sends you charging off in one direction, only for the real answer to be hiding somewhere completely different.

A client was printing truck loading labels when the batch routine crashed. The job log contained this little gem:

Error message CPF4165 appeared during OPEN for file MCSH003O3.

So far, so cryptic.

`MCSH003O3` was the printer file used to produce the labels. The program fell over while opening it, so I looked up CPF4165 and found information pointing towards the maximum number of spooled files allowed for a job.

Naturally, that sent me straight down the `QMAXSPLF` rabbit hole.

First Suspect: QMAXSPLF

[QMAXSPLF] is the IBM i system value that controls the maximum number of printer output, or spooled files, that can be created for a job. The IBM-supplied default is 9,999, and the value can be increased as high as 999,999.

You can check it with:

DSPSYSVAL SYSVAL(QMAXSPLF)

Or work with it using:

WRKSYSVAL SYSVAL(QMAXSPLF)

The message appeared to be telling me that the job had hit this limit. It sounded plausible, so I increased `QMAXSPLF` and ran the report again.

Same crash. Same message. No labels.

Excellent.

The good news was that I had eliminated one possible cause. The less-good news was that the system value change had solved precisely nothing.

Time to Stop Believing the Error Message

When an IBM i message points at an obvious cause, it is very tempting to take it literally, especially when the suggested fix appears to match the failure.

But the important part of this message was not only `CPF4165`. It was this:

during OPEN for file MCSH003O3

The failure occurred when the program tried to open the printer file. That meant it was time to inspect the PRTF itself and follow the entire printing route.

Where was the printer file trying to send its output?

Printer-file attributes can be inspected with `DSPFD`, for example:

DSPFD FILE(MYLIB/MCSH003O3) TYPE(*ATR)

It is also worth checking for printer-file overrides in the failing job. The output queue used at runtime might not be the one stored on the compiled printer file.

And there it was.

The PRTF was pointing at a specific output queue, so of course I looked at it.

wrkoutq when outq is not found CPF4165

To my surprise that output queue no longer existed. Best guess? Somebody had accidentally deleted it.

The Real Fix

I recreated the missing output queue , reran the batch report, and the truck loading labels printed cleanly.

No program change.

No RPG debugging marathon.

No need to keep fiddling with `QMAXSPLF`.

Just one missing IBM i object sitting at the end of the print chain.

The Troubleshooting Lesson

The interesting part of this problem was not simply that an output queue had been deleted. Objects get deleted, configurations drift, and mysterious things happen on busy systems. That is all part of the fun.

The interesting part was how convincingly the message pointed towards something else.

If you encounter CPF4165 while opening a printer file, do not stop after checking the spool-file limit. Follow the complete route used by the print operation:

1. Check `QMAXSPLF`, but do not assume it is the answer.

2. Identify the PRTF named in the job log.

3. Inspect the printer-file attributes.

4. Check for any `OVRPRTF` overrides active in the job.

5. Identify the effective output queue and library.

6. Confirm that the output queue actually exists and that the job has authority to use it.

7. Review the surrounding job-log messages for the underlying failure.

In my case, step six was the winner.

The Moral of the Story

IBM i error messages are often brilliantly specific. Occasionally, however, they hand you a shovel and invite you into a completely unnecessary rabbit hole.

I started with a suspected spooled-file limit, changed a system value, and ended up discovering a deleted output queue. Once the `OUTQ` was recreated, everything worked perfectly.

What an interesting little bug, and another reminder that when a printer file will not open, check where it is trying to print before blaming the program.

Happy debugging!

NickLitten


IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Shameless Trekkie, Belligerent Nerd, Englishman Abroad and Passionate Eater of Cheese and Biscuits.

Nick Litten Dot Com is a mixture of blog posts that can be sometimes serious, frequently playful and probably down-right pointless all in the space of a day.

Enjoy your stay, feel free to comment and remember: If at first you don't succeed then skydiving probably isn't a hobby you should look into.

Nick Litten

related posts:

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe NOW
7-day free trial

Take This Course with ALL ACCESS

Unlock your Learning Potential with instant access to every course and all new courses as they are released.
 [ For Serious Software Developers only ]

Online Learning for IBM i Software Technology Professionals

“The more that you read, the more things you will know. The more that you learn, the more places you’ll go.” – Dr. Seuss

>