Job Log Pending

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.


Detach Spooled Files From a Job

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:

  • An unplanned outage due to hitting the maximum number of jobs
  • A large numbers of jobs that contribute to long IPLs for unplanned outages. 
  • Consumption of job table entries

Export Spooled Files to PDF Files in 7.1

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.


Reclaim Spooled Files

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.