You are currently on IBM Systems Media’s archival website. Click here to view our new website.


Bookmark and Share
RSS

Recent Posts

i Can … Retrieve Spool Information

December 14, 2009

This week's blog post was written by Kevin Vette. Kevin is a developer on the print and spool team in the IBM i development lab. Thanks, Kevin!

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?

Increasingly, IBM i users are using spooled files for more than just their printed data. Spooled files are often used to store business reports and other information, so the number of spooled files on a system tends to get larger and larger. A simple improvement has been made that lets you determine how many spooled files exist on your system and where those spooled files are. This information can now be retrieved using the Retrieve Spool Information (QSPSPLI) API that has been released for 6.1 via PTF SI33959. The QSYSINC includes for this new API can be found in PTF SI34013.

The Retrieve Spool Information API can be used to get the total number of spooled files per auxiliary storage pool (ASP) group. These are also sometimes called disk pools. The main input for the API is the ASP group name, and one of the special values allowed is *SYSBAS, which gives you the number of spooled files in the system ASP and any user ASPs. Most systems have all of their spooled files in *SYSBAS. If you have spooled files on independent ASPs, you can either give it the name of the IASP group or use the special value of *CURASPGRP to have it give you the number of spooled files of the ASPs in that group.

The API also has another input, which is a user name. This lets you determine how many spooled files a particular user owns. This is handy especially when a user is no longer a valid user on the system.

So what can be done with this information? You could write a monitor job that would wake up at certain intervals, get the number of spooled files in the system ASP, and send a message or take some other action when a certain threshold is reached. This kind of proactive monitoring can be used to prevent unexpected storage consumption that could occur if a runaway job created too many spooled files. Note, too, that the system ASP has a limit of 2.6 million spooled files (IASPs can contain 10 million spooled files). While these numbers seem very large, some IBM i customers have hit these limits! Proactive monitoring of spooled file generation can prevent that.

If you’re interested in trying this, check out the IBM i 6.1 Information Center article for the Retrieve Spool Information API

 

 

Posted December 14, 2009| Permalink

-->