Since the inception of the IBM® AS/400® platform in 1988, IBM has slowly but surely been introducing enhancements into the operating system's printing features. Many of these enhancements have been slow in coming (for example, only with version 7.1 did IBM provide a no-cost means of converting spool files to PDFs), so many software vendors have plugged the gap with products that allow users to convert reports to PDF files or spreadsheets and use special forms. A lot of standard IBM i5/OS® functions have gotten lost in the shuffle. This article discusses a few of the features that can save money and help manage reports on an IBM i system without spending an extra dime on other products.
Although the IBM i platform is more than 20 years old, the foundation of its printing has not changed.
In the 1980s, the most common types of printers connected to the AS/400 system were directly attached by twin-axial (twinax) cable or were PC printers driven by an emulator program such as Client Access Express. The coolest thing about this type of connectivity was that once a connection was made, the operating system could automatically configure the printer description and create the corresponding output queue (OUTQ). Many workhorse, "greenbar" printers were connected this way. If a user wanted anything graphical to appear on paper, such as a form, logo, or signature, he or she could license IBM's Advanced Function Print Utility and send the output to a printer that had Intelligent Printer Data Stream (IPDS) features installed.
Reports intended for printing are designated as spool files, and these files were kept in OUTQs to await final printing. If the OUTQ were not linked to a print writer, the spool files would stay there indefinitely. Up until version 5 release 4 (V5R4), there was no easy way to back up the contents of an OUTQ without having to buy an outside utility or write an elaborate program.
Each spool file is chock full of characteristics that determine how the text will
appear on the page. These attributes are specified when the printer file is
created, and each spool file is based on a print file. Figure 1
and Figure 2 show results from the
CHGSPLFA command, which allows you to change the
attributes in spool files that have already been created.
Figure 1. Changing spool file attributes
The most common attributes were OUTQ name (to route the report to a different printer), page ranges, form types, and the ability to save a copy of the report in the OUTQ after the report has been printed. However, many other useful attributes are also available.
Figure 2. Changing spool file attributes: Other attributes
Over the years, advances in laser technology and network printing offered a powerful alternative for AS/400 output. IBM, HP, and other manufacturers rolled out cut-sheet printers that were fast, had excellent quality, and supported graphics. Most of these printers were developed with PC output in mind but could receive data streams from AS/400 systems, as well. The key is that spool file attributes could take advantage of the functions in the printer hardware itself.
Although there isn't an option for auto-configuration, IBM provides ample information on how to connect to a host of printers from different vendors. See Resources for links to IBM documentation on how you can define these network printers as LAN-attached devices or by way of a remote OUTQ.
This section discusses interesting print features that have been part of the spool file
attributes for years and may have been overlooked by IBM iSeries® customers.
You can change these attributes interactively by using the Change Spool File Attributes
CHGSPLFA) command (easily selected from a list of spool
files) or by choosing Properties from a highlighted spool file using
the graphical IBM i Navigator.
Typically, you specify attributes before the spool file is created by using the
Override with Printer File (
OVRPRTF) command or by
making a permanent change to the print file using the Change Printer File
CHGPRTF) command. The
command can be dangerous if used on IBM-supplied print files and, even at version 6
release 1, is a most user-unfriendly command. Using
allows you to change the attributes temporarily for the life of the IBM i job. Many
attributes for a spool file cannot be changed once the report has been created, which
is another reason why making the change with
is an important technique.
Although going paperless is fashionable, there are still times when you can't avoid hard copy. If the printer you're using has the ability to print on both sides of the sheet, IBM i can use it, thus potentially reducing paper usage by half. You activate this feature in one of the following ways:
- Using the following command:
OVRPRTF FILE(print_file_name) DUPLEX(*YES)
- Change the
Print on both sidesparameter shown in Figure 3 to
Figure 3. Changing the Print on both sides parameter to enable duplex printing
- If using IBM i Navigator, navigate to Basic Operations/Printer Output and
change the properties of a specific report. The Layout
tab has the options, as shown in Figure 4.
Figure 4. Changing spool file attributes via IBM i Navigator
The nice thing about this attribute is that if it is set to
but the printer does not have the duplex ability, the setting will be ignored, and
the pages will print on separate sheets as normal. You don't have to worry about
getting a report with only odd-numbered pages.
Another interesting although possibly misleading attribute is the
Pages per side, or
parameter, which seems to allow page reduction so that two or even four pages
can fit on one side of the sheet. This is a feature can only work on a printer on
which an IPDS feature is installed. Even if this type of printer is available, it is
good practice to try it out before going live with it. Some reports simply do not
look good when they are condensed. You activate this feature in one of the following
- Specify the following command:
OVRPRTF FILE(print_file_name) MULTIUP(2 or 4)
- Change the
Pages per sideparameter to
- If using IBM i Navigator, navigate to Basic Operations/Printer Output, and change the properties of a specific report (see Figure 4).
Several third-party software vendors offer software that allows IBM i users to create electronic forms that will be embedded on each page of a report. This is a popular way to reduce the cost of purchasing preprinted forms to use for invoices, letterhead, and other static images. These products can be elegant but are rarely free. If cost savings is the goal, it's worth looking at a way to create a static form, or overlay, using nothing more than System i Access for Windows® and IBM i (see Resources for a link to more information).
In a nutshell, the process is as follows:
- Install the AFP print drivers from IBM i Access for Windows to your PC.
- Using any text processor, create a single-page document that depicts the form.
- Print a copy of the document using the AFP driver, and direct the output to a file with the extension .oly.
- Create a physical file on the IBM i machine that will be used as source for the ultimate form overlay.
- Transmit the .oly file to a physical file.
- Create an overlay object using the
- Create or override a printer file specifying a type of
*AFPDSand a front overlay (
FRONTOVL) value matching the name you created. Depending on the layout of the text, you may also need to override the default page size and font characteristics.
Although this technique allows you to create an overlay without using any other software, there are some drawbacks. You can preview the spool file with the combined text and overlay using IBM i Navigator, but the proof in the pudding is when the actual document is printed. Overlay documents look terrific on IPDS printers or printers like HP LaserJet printers that incorporate the Printer Job Language and can be configured with Host Print Transform. Other printers may not be so cooperative. Because the overlay is static, it will likely be necessary to reposition the report's text to fit within the lines or boxes of the overlay. In short, be prepared for a good amount of trial and error here.
Because using overlays with this technique requires the spool file to have the
*AFPDS data type, you can't change the overlay after
the spool file is created. There is a similar parameter (
if a separate overlay for even-numbered pages is required. So, using overlays
can save on preprinted forms, but they are only meaningful if you create spool
files where the overlay is needed on each page.
Since the early days, the IBM i cleanup utility has made it easy to designate
a number of days to keep job log reports on the system. (If you haven't seen
this information, enter the command
to check it out.) Starting with V5R4, it became possible to specify an expiration
date for other spool files, as well. The key attribute parameters that were
These attributes determine the date when a spool file is considered expired and,
based on the installations policies, can be safely deleted. Spool files that have
passed their expiration date will be removed the next time the CL command
DLTEXPSPLF is executed.
Figure 5 shows how you can set a spool file to expire on a specific date (in this example, 31 December 2011). Note that the date must be no earlier than the current date—no going back in time allowed.
Figure 5. Setting file expiration by date
As a more flexible alternative, you can specify the number of days that the spool
file can be kept before it expires. In the example shown in Figure 6,
you must set the
EXPDATE value to
*DAYS and enter the number of days in the
Figure 6. Specifying the number of days to keep a file before it expires
By specifying the number of days in an
you will have told the system how many days to keep the report from the time it
was created. If you enter the value by changing an existing spool file, you are
specifying the number of days to keep the report from that moment on.
To change these parameters in IBM i Navigator (after the report was created), display the properties of a spool file, and then click the Origin/Expiration tab, as shown in Figure 7.
Figure 7. Manipulating expiration settings in IBM i Navigator
Regardless of how you set the expiration date, no reports will be deleted until the
you run the
DLTEXPSPLF command. You can run this
command manually or as part of a batch program. The user profile that runs the
command must have spool control (
authority to have the rights to delete files that other users create. The
DLTEXPSPLF command deletes all spool files that have
gone over their expiration date in one or all auxiliary storage pools. The only way
for a file to be exempt is to have
EXPDATE set to
*NONE (the default). When the
DLTEXPSPLF command runs, it generates a message
indicating the total number of spool files that were deleted.
DLTEXPSPLF is a useful tool for cleaning up spool files
proactively. However, if you are looking to clean up thousands of existing spool
files that have no expiration date, it helps to have a CL programmer set up a
routine that will collect all the spool file identification attributes and change the
EXPDATE using the saved information.
This section offers techniques for moving spool files out of the local IBM i server. These features work regardless of the attributes of the spool files themselves.
The AS/400 and iSeries communities gave a collective cheer when IBM announced that V5R4 would include the means to save and restore the contents of OUTQs to tape. This addition was long overdue and brought relief to organizations that maintained critical historical reports online that could not be easily recreated if they were accidentally lost. It became a common headache in disaster recovery planning to have to include provisions for potentially losing all the spool files in all the output queues if the system had a catastrophic disk loss. To solve the problem, many organizations had to buy utilities or write routines that copied the text in a report to a data file.
The good news is that the implementation of this feature is remarkably straightforward.
A new parameter was embedded in the Save Library (
and Save Object (
SAVOBJ) commands. The parameter
SPLFDTA (Spool File Data), and it can be set
Figure 8 provides an example.
Figure 8. The Save Spool File Data attribute as part of the SAVLIB command
If you're saving an OUTQ and the value of
*NONE, no spool files within that OUTQ will be
backed up. If
SPLFDTA is set to
however, every spool file encountered in that OUTQ will be saved.
Be aware that if you are performing a full system save or using options 20 through 23
in the GO SAVE menu, you will need to scroll through the settings
to specify that the spool files should be saved. Figure 9 provides
an example of how this process looks for a full system save (option 21). Note that
the default is always
Figure 9. Save option 21 settings
Figure 10 shows the lower half of the screen.
Figure 10. Save option 21 settings (lower half of the screen)
When a spool file is saved to tape or a save file, IBM i keeps track of its unique
identifiers to ensure that a duplicate copy of a report can be restored on a system.
You see this functionality in the commands Restore Library (
and Restore Object (
RSTOBJ). These commands also
contain a parameter called
SPLFDTA, but in this case,
the values can only be
(see Figure 11).
Figure 11. The Restoring Spool File Parameter in the RSTLIB command
If the value is set to
*NONE, no spool files will be
restored to an OUTQ. If the value is
the system compares the identifiers of the reports on the save media to the spool
files on the system, and only spool files that are not present on the server are
restored. Needless to say, if you are restoring a library containing OUTQs to a
different server, all of the spool files will be restored.
This process is a useful way to archive old reports that still have value or legal relevance. If the spool files are saved to virtual tape or to a save file, they can be sent to a Windows Server® machine using FTP as another archival method.
In the previous section, you saw a technique for offloading reports to external media. Sometimes, however, you may need to transmit a report to another IBM i system so that it can be printed there. This may come into play if a remote system has specialized printers for labels, checks, or still supports twinax devices.
If an IBM i server is in a network containing other IBM i servers, it is easy to send spool files from the originating system to any of the others. The key is to set up a remote OUTQ on your system that points to the address and a valid OUTQ of a remote server. IBM describes this technique in detail: See Resources for a link.
Once the remote OUTQ is active, any spool file placed there will be shipped to the
remote site. The only way to keep a copy is to set the
*YES. Doing so keeps a copy in the OUTQ
of the local system. The remote server will see the report arrive, but the report
will no longer have the original creation date and time stamp. A useful operator
message (TCP3602) will be sent to alert the target server that an inbound spool
file had been sent.
The features described in this article have been part of the IBM i operating system for a long time and can be exploited to save cost on paper, forms, and disk space. Although some may be more difficult to implement than others, they all share two things in common: (1) they were included with each IBM i server at no extra cost, and (2) because all these features are built into the IBM i operating system (with an assist from IBM i Access), organizations with active IBM software support are eligible for Supportline help to make them work. Try them out!
Check out IBM Redbook SG24-6250,
IBM eServer iSeries Printing VI.
Check out IBM Redbook SG24-2160-01,
IBM AS/400 Printing V.
Learn more about printing on
i 6.1 and IBM
i 7.1 from the IBM i Information Center.
For instructions on creating detailed overlays, see the IBM document
AFP Resources Using the IBM AFP Printer Drivers.
For instructions on migrating spool files from one IBM i server to another, see the IBM
a RMTOUTQ to Send SPLFs from one IBM IBM i to Another using LPR/LPD.
Learn more about save files for IBM
i 6.1 and IBM i 7.1
from the IBM i Information Center.
IBM i developerWorks
zone: The IBM i zone provides a wealth of information relating to
all aspects of IBM i systems administration.
New to IBM i?
Visit the New to IBM i page to learn more.
bookstore: Browse the technology bookstore for books on this and other
Follow developerWorks on Twitter.
developerWorks blogs: Check out
our blogs and get involved in the developerWorks
Participate in the IBM i forums:
Eduardo Delgado worked as an IBM systems engineer for 14 years, serving as an AS/400 and iSeries specialist for the Santa Monica, California, office. He supported IBM customers and provided technical support for IBM marketing representatives. Since 1994, he has been a self-employed consultant supporting clients who rely on the AS/400 and iSeries platforms or their businesses. He complements IT staff members with systems operations and management assistance while providing planning and installation support for hardware and software upgrades.