Re: Keep Your IBM i System from Crashing Like Mine Did

[Richard Schoen <richard@xxxxxxxxxxxxxxxxx>]

Interesting there was actually a method to the madness.  I had never understood what joblog *PND meant. And never took the time to learn more about the WHY if that 😊

Found this article by Dawn May that articulates it.
https://techchannel.com/i-can-blog/take-advantage-of-job-log-pending/

Either way in my case GO CLEANUP wasn't really an option as I had a system getting hammered with internet connections. And in the end for my scenario it was the 4/00/*MSG on QDFTSVR causing the issues.

That QLOGOUTPUT system value is a good one to know about.

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx

------------------------------

message: 2
date: Thu, 25 Dec 2025 21:17:43 -0500
from: Rob Berendt <robertowenberendt@xxxxxxxxx>
subject: Re: Keep Your IBM i System from Crashing Like Mine Did

Again, GO CLEANUP will clear out pending joblogs just as well as spooled joblogs.  We stopped using spooled joblogs many years ago and changed QLOGOUTPUT to *PND.  After all, when you query a data file, do you query it directly, or, do you CPYF TOFILE(*PRINT) and substring the snot out of that to mine your information?  Much easier to use JOBLOG_INFO.

On Tue, Dec 23, 2025 at 2:52?PM Richard Schoen <richard@xxxxxxxxxxxxxxxxx>
wrote:

> Nice.
>
> The delete spool file thing is good.
>
> However in my case it was the more nefarious one which is the joblogs 
> in limbo which haven't ended or created an actual spool file. That's 
> the *PENDING ones that get created by server jobs.
>
> That's why you can't/shouldn't have QDFTSVR and other jobs using 
> 4/00/*MSG or 4/00/*NOLIST.  It causes the pending joblog conundrum.
>
> Regards,
> Richard Schoen
> Web: http://www.richardschoen.net
> Email: richard@xxxxxxxxxxxxxxxxx
> ------------------------------
>
> message: 3
> date: Tue, 23 Dec 2025 19:32:38 +0000
> from: Michael Mayer via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>
> subject: Keep Your IBM i System from Crashing Like Mine Did
>
> When I started in my current role a few years back, first week on the 
> job, I get a phone call that ROBOT Alert detected close to full disk 
> storage. I run a DSPJOBTBL and of course, oops - almost full and 
> storage % very much high.
>
> First step, increase QMAXJOB value to 500000.
> Next was to run a CLLE pgm that ran an SQL in the advanced job 
> scheduler (Go JS) that looks like this:
>
> *************************************************************
> PGM
> RUNSQL ('CALL SYSTOOLS.DELETE_OLD_SPOOLED_FILES(DELETE_OLDER_THAN => 
> CURRENT DATE - 30 DAYS, + P_OUTPUT_QUEUE_LIBRARY_NAME => ''TESTLIB'', 
> + P_OUTPUT_QUEUE_NAME => ''TESTFILE'', + PREVIEW => ''NO'')') ENDPGM
> *************************************************************
>
> Note on the pgm:
> This CLLE program can be run standalone and/or be added to the job 
> scheduler or your startup program. It's up to you to set the parameters.
> Note the double quotes " " enclosing the library name, outq name and 
> preview value (NO = display what will be deleted, YES = the actual 
> deletion).