Admin Alert: More on Remote OUTQs and Printer Load Form Messages
by Timothy Prickett Morgan
One of the nice things about writing the Admin Alert column is the dedicated readers who fill in the gaps in my knowledge. Several readers e-mailed to correct my assertion last week that remote writers don't send reply messages to your iSeries or AS/400, demonstrating that the auto-answer technique for replying to printer load form messages, which I wrote about a few weeks ago, would indeed work with remote printer output queues.
For the record, I was wrong when I said that you could not auto-answer printer load form messages for remote writers, because OS/400 doesn't allow for these messages with remote output queues. OS/400 remote writers are capable of sending and receiving replies to printer load form messages from remote writers, and here's a sampling of the volumes of e-mail I received on the subject to prove it. I offer these tidbits to add to this column's collective knowledge.
The general reaction to my comments is best summed up in this e-mail from Doug Streifling:
Regarding your column's comment that "remote OUTQs don't care about forms," I beg to differ.
IBM does indeed support forms changes for remote output queues. All of our printers (about 50) are TCP/IP-attached devices. Six of these are used to print checks, and it is vital that the operator is warned if it is time to load check forms. I can assure you that our payroll and accounts-payable people receive a break message to load forms, just like we are used to from days of old. We have done no special programming; we just specify the form type on the print file.
The default for the Form Type options (FORMTYPE) parameter of Start Remote Writer (STRRMTWTR) is FORMTYPE(*ALL *NOMSG), which causes the printer to behave exactly as described in your article (that is, it leaves load form message handling to the remote system). However, if you specify FORMTYPE(*ALL *INQMSG), the remote writer will generate a "load forms" message when a spooled file is sent to the printer that has a form type that is different from the last form type sent. A really easy way to implement load form inquiry messages is to change the STRRMTWTR FORMTYPE parameter command default from *NOMSG to *INQMSG. This solves the problem instantly.
So this means I was half-wrong and that remote output queue writers will send load form type messages back to OS/400, provided that they are started correctly. I tested the above technique on a fresh remote printer output queue, started through Doug's FORMTYPE settings, and it worked. I did receive printer load messages prompting me to load the correct forms before printing started.
But notice that Doug mentioned that you can change the default settings for the STRRMTWTR FORMTYPE parameter to (*ALL *INQMSG) in order to specify that new remote writers will automatically send back inquiry messages. The exact command for doing so was provided by Peter Amstutz:
You can change the command so that you do get load forms messages by changing the FORMTYPE parameter default option to *INQMSG, with the following Change Command Default (CHGCMDDFT) command:
CHGCMDDFT CMD(STRRMTWTR) NEWDFT('FORMTYPE(*ALL *INQMSG)')
Unless specifically overwritten, any remote output queue created with STRRMTWTR will automatically send back printer messages. Your change to the reply list entry would work in this case for a remote writer.
So in two e-mails, I received one quick technique for configuring my remote output queues to receive form messages. But that wasn't the end of it. Another reader wrote in with an additional technique for receiving printer messages from remote writers:
If you use the CHGOUTQ command to put the following string in the Destination Option parameter of your remote output queue, then the reply list entry technique will work.
CHGOUTQ OUTQ(output_queue_name) DESTOPT('XAIX XAUTOQ')
For this technique, only the XAUTOQ string will have an effect on your printer messages, but it's worth putting in both strings to better handle your printouts.
According to IBM documentation, the auto-queue destination option (XAUTOQ) tells OS/400 to send the files directly to the remote system unless the remote printer times out during the operation. During a timeout, the spool files are sent back to your remote output queue using the AS/400's Line Printer Daemon (LPD) server, generating an inquiry message in the process. When the remote writer is running again, it will resend the spool file to the remote system.
I tested the ability of XAUTOQ to generate a form load message on a new remote printer output queue by sending it two consecutive spool files with different form types. Sorry to say, I didn't receive an error message to change the form type. Both files printed automatically without sending out a change form type message. It's possible that I configured my test wrong, so be careful if you decide to try this solution for load form type messages. One reader said it worked and another was unable to verify that claim (although it seems that XAUTOQ by itself might be a good solution for resending spool file output when the remote printer is out of paper or offline).
The XAIX string controls how you print multiple copy spool files to the remote system. Specifying XAIX tells OS/400 that when it's printing multiple copies of the same spool file to the remote system, it should send the printouts multiple times, once for each copy. The default is to send the data once, along with its control commands, with multiple print commands embedded in the control file. According to several sources, using XAIX to control multiple spool file printing is a much more reliable way to do this.
But this reader didn't stop there. He also reminded me that one of the challenges in using TCP/IP printing is to implement page range support, where users print a range of pages from the spool file to the remote writer, rather than printing the entire spool file. Midrange Guru recently published an excellent tip on how to perform page range printing for TCP/IP printers.
So there you have it. My mistake brought out a deeper understanding of how remote output queues work and of how you can apply them to your advantage. Keep those e-mails coming, folks, because we can all learn something from them.
Access lists must contain permit statements only. Access lists for policy NAT cannot contain deny statements.
