Job log pending has long been a possible state for a job log. When a job has a pending job log, the job has ended but the job log has not yet been written to an spooled file. In older releases of IBM i, this could occur when you powered down the system – the job logs would be saved in a pending state and the job logs would be written to spool files when the system was powered back up.
(more…)Many of the larger IBM i environments need more sophisticated methods to manage the number of jobs on the system. If the absolute maximum number of jobs–as defined by the Maximum Number of Jobs (QMAXJOB) system value–for the system is reached, there can be some negative results such as:
As I was learning about the details of our PDF support in the 7.1 release to write this blog, I discovered things were a bit more confusing than I realized. So this blog post is going to discuss the PDF support we’ve had in the past along with what’s new with 7.1. The information in this blog also pertains to the releases after 7.1.
(more…)Have you ever worked with spooled files, whether using WRKSPLF or WRKOUTQ, and noticed the output queue or spooled files listed have a status that doesn’t make sense? For example, the spooled file status is *WTR, but no spool writer is started to the output queue the spooled files are on? This should be a fairly rare event, but at times the abnormal ending of jobs may cause this situation. Introduced in the IBM i 6.1 release, a new command, Start Spool Reclaim (STRSPLRCL), can repair output queues and spooled files that are left in one of these unrecoverable states.
(more…)Have you ever wanted to know how many spooled files are on your system without having to do a WRKOUTQ *ALL and then adding up the spooled files within all the output queues?
(more…)