Admin Alert: Configuring Output Queues to Print Multi-Copy Spooled Files on Remote Printers

February 23, 2005 Joe Hertvik

Like most business computers, OS/400 can send spooled file output to printers located on either a local or a remote system. Spooling to a remote printer is not without its hazards, however. One of the more common problems lies in configuring OS/400 to print multiple copies of a single spooled file on a remote printer. Here’s the rundown on how this problem works, the quick fix to make it go away, and a gotcha.

I recently ran into this problem on an IBM 6400 printer that we had networked through a NetGear print server, setting it up as a remote output queue for an OS/400 V5R3 box (for information on how to set a printer up as a remote output queue on your OS/400 box, see the Admin Alert column called ““Remote OUTQs and Auto-Answer Printer Messages” from a few years ago. The printer worked fine, but it would not print multiple copies of a spooled file when the copies parameter (COPIES) for the spooled file was set greater than one. Upon receiving a multi-copy spooled file, the IBM 6400 would print only the first copy, then the printer busy light would stay on and it would not print any additional copies of the report.

[Note: this problem isn’t unique to OS/400 spooled file jobs processed through remote output queues. It may also occur for OS/400 printer devices that are configured to print to a remote print server. For both types of printers, this solution should be exactly the same.]

I found that this problem can easily be solved by adding a specific destination option to my remote output queue. The Destination Options parameter (DESTOPT) can be specified on any output queue, and it tells OS/400 how spooled file output should be handled based on the characteristics of the remote printer where it will be processed. For IP-based printers, these destination-dependent options are added to the control file that OS/400 sends to the remote LPD server receiving the output.

The fix for this problem is to add an ‘XAIX’ string to the DESTOPT parameter on your problem output queue. On the green-screen, you can do this by entering the Change Output Queue command (CHGOUTQ) this way:

CHGOUTQ OUTQ(output_queue_name) DESTOPT(XAIX)

When the COPIES parameter on the spooled file is greater than one, the ‘XAIX’ value tells the OS/400 QSPL job (either a remote writer or a printer device) to send multiple copies of the spooled file to the remote printer. By sending multiple copies, the remote print server processes all the printouts it is sent, one at a time; it doesn’t worry about how many copies are supposed to be printed because OS/400 determines the number of copies to send down.

The downside of using ‘XAIX’ is that it may not work for all print servers. Some print servers will automatically close a connection after the first printed copy is received, even though there may be several more spool files to follow. When this happens, OS/400 considers it an unexpected connection failure and it attempts to resend the printer data from the beginning. This situation will cause remote output queue processing to loop because the printer will always print just one copy of the printout, no matter how many times you resend the data, and OS/400 will keep resending the spooled file data indefinitely. In these situations, IBM suggests that you do not use ‘XAIX’ in the destination options parameter, and it may be hit or miss as to whether the remote printer will be able to print multiple copies of a spooled file. There is no recorded fix for this situation, but if somebody has any ideas on how to handle this, I’ll print them in a future column.

For OS/400 versions V4R3 or below, there is a second option called ‘XAUTOQ’ that should also be added to your output queue destination options. To do that, modify your DESTOPT parameter like this:

CHGOUTQ OUTQ(output_queue_name) DESTOPT('XAUTOQ XAIX')

In pre-V4R4 OS/400 versions, XAUTOQ tells the remote writer to save the generated *USERASCII data stream in a spooled file whenever the remote print server times out. By doing this, the spooled file can be sent again without any transformation once a new connection is made with the timed out print server. The XAUTOQ function is only necessary in pre-V4R4 OS/400 functions; in OS/400 V4R4 and above, XAUTOQ processing is automatically incorporated into the operating system. The key here is that large OS/400 spooled files could continually time out and stay in sending status indefinitely if XAUTOQ doesn’t bypass the conversion process every time the file needs to be resent.

Click here to contact Joe Hertvik by e-mail.