Problem: User is saying that their sensitive printed output is remaining in the OUTPUT QUEUE after it is printed. This had never occurred before. Why it is "suddenly" happening?
Resolution: Another program that the User runs frequently generates a set of Reports from RPGIII and RPG IV applications and they requested that they be saved in their output queues even after printing. So in that job stream, the following CL command was added:
OVRPRTF FILE(*PRTF) SAVE(*YES) OVRSCOPE(*JOB)
It turns out that the end-users is calling this 2nd program throughout the day, and then ran their sensitive report (payroll checks). The previous OVRPRTF to *PRTF means "*ALL" and the override scope of *JOB means it doesn't go away until the user signs off. Therefore, their 2nd program, the one that includes the OVRPRTF needed to include a DLTOVR *PRTF LVL(*JOB) when it was finished producing reports. Problem solved!
So remember to include the following CL command when you override *ALL print files:
DLTOVR FILE(*PRTF) LVL(*JOB)
While the above DLTOVR command solves this problem, don't be a dick by inserting the following lazy DLTOVR command:
DLTOVR FILE(*ALL) LVL(*JOB)
If you see this type of CL statement, in most (not all, but most) cases the programmer was far too lazy to insert the specific delete override commands to the files in question. I've seen this in mid-job stream where I've gone in and inserted a new override; and in that same program a previous programmer inserted 3 or 4 overrides and then called an RPG program. After the call, they issued the DLTOVR *ALL command to get rid of them. Of course my new OVRxxx command was also deleted, even though I needed it later on in the job stream. Remember DLTOVR FILE(*ALL) LVL(*JOB) applies to every program you've run in your job at any point.
Never use DLTOVR *ALL unless you are ONLY using *CALLLVL overrides in your program.