Power printing functions

IBM i functions that have been free all along

Over the past few years, customers have focused on moving their IBM i printing to a "paperless" process. However, there is still a need for old-fashioned hard copies. Discover capabilities for managing or enhancing spool files (reports) that have been built into the operating system for years, and learn how—without purchasing any external software or utilities—you can save money on paper and preprinted forms.

Eduardo Delgado (edify400@aol.com), Consultant, IBM

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.



19 March 2012

Also available in Chinese

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.

The trademarks of printing technology in IBM i

Although the IBM i platform is more than 20 years old, the foundation of its printing has not changed.

Early attributes and limitations

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
Image showing the window in which you change spool file attributes

Click to see larger image

Figure 1. Changing spool file attributes

Image showing the window in which you change 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
Image showing the window in which you change other spool file attributes

Click to see larger image

Figure 2. Changing spool file attributes: Other attributes

Image showing the window in which you change other spool file attributes

Enhancements over the years

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.


Spool file features standard in IBM i

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 CHGPRTF 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 OVRPRTF 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 OVRPRTF is an important technique.

Duplex printing

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 sides parameter shown in Figure 3 to *YES
    Figure 3. Changing the Print on both sides parameter to enable duplex printing
    Image showing how to change the Print on both sides parameter to enable duplex printing

    Click to see larger image

    Figure 3. Changing the Print on both sides parameter to enable duplex printing

    Image showing how to change 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
    Image showing how to change spool file attributes via IBM i Navigator

The nice thing about this attribute is that if it is set to *YES 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.

Multiple pages per side of paper

Another interesting although possibly misleading attribute is the Pages per side, or MULTIUP, 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 ways:

  • Specify the following command:
    OVRPRTF  FILE(print_file_name)  MULTIUP(2 or 4)
  • Change the Pages per side parameter to 2 or 4.
  • If using IBM i Navigator, navigate to Basic Operations/Printer Output, and change the properties of a specific report (see Figure 4).

Quick and dirty form overlays

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:

  1. Install the AFP print drivers from IBM i Access for Windows to your PC.
  2. Using any text processor, create a single-page document that depicts the form.
  3. Print a copy of the document using the AFP driver, and direct the output to a file with the extension .oly.
  4. Create a physical file on the IBM i machine that will be used as source for the ultimate form overlay.
  5. Transmit the .oly file to a physical file.
  6. Create an overlay object using the CRTOVL command.
  7. Create or override a printer file specifying a type of *AFPDS and 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 (BACKOVL) 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.

Setting expiration dates for reports

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 Go Cleanup 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 added were EXPDATE and DAYS. 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
Image showing how to set a file to expire on a given 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 DAYS parameter.

Figure 6. Specifying the number of days to keep a file before it expires
Image showing how to specify the number of days to keep a file before it expires

By specifying the number of days in an OVRPRTF command, 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
Image showing how to manipulate 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 (*SPLCTL) special 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.


Moving spool files to off-site storage or remote IBM i servers

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.

Saving contents of OUTQs to tape or save files

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 (SAVLIB) and Save Object (SAVOBJ) commands. The parameter is called SPLFDTA (Spool File Data), and it can be set to either *NONE or *ALL. Figure 8 provides an example.

Figure 8. The Save Spool File Data attribute as part of the SAVLIB command
Image showing the Save Spool File Data attribute as part of the SAVLIB command

If you're saving an OUTQ and the value of SPLFDTA is *NONE, no spool files within that OUTQ will be backed up. If SPLFDTA is set to *ALL, 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 *NONE.

Figure 9. Save option 21 settings
Image showing the settings for save option 21

Figure 10 shows the lower half of the screen.

Figure 10. Save option 21 settings (lower half of the screen)
Image showing the settings for save option 21

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 (RSTLIB) and Restore Object (RSTOBJ). These commands also contain a parameter called SPLFDTA, but in this case, the values can only be *NONE or *NEW (see Figure 11).

Figure 11. The Restoring Spool File Parameter in the RSTLIB command
Image showing 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 *NEW, however, 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.

Using remote OUTQs to send reports to another IBM i server

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 Save parameter to *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.


Conclusion

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!

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into IBM i on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=IBM i
ArticleID=804172
ArticleTitle=Power printing functions
publish-date=03192012