Admin Alert: Using Remote OUTQs to Cover for Broken Printers
November 1, 2006 Joe Hertvik
|
Physical printer breakdowns always cause problems in delivering critical output to i5 or iSeries shops. This problem is usually solved by transferring spooled file output to another functioning printer queue or by changing the non-functioning queue’s IP address to point to another printer. There is a third option, however, as you can also quickly redirect printer output between queues on the same i5 partition by using a remote output queue. I discovered this trick when a critical IP-based printer broke down on me and I had to quickly redirect important spooled files to another i5/OS writer on the same partition. In this situation, I knew I pretty much had two choices:
The problem with the manual technique is that it wastes time, since someone needs to monitor the non-functioning output queue and transfer newly created spooled files to the new target output queue. The second technique is better, but it can create a conflict situation if both writers (the original writer and the redirected one) try to control the same printer by starting it, stopping it, or changing form types at the same time. To solve this problem, I discovered that I can take a familiar AS/400, iSeries, and i5 printer concept (remote output queues) and apply it not only across i5/OS partitions or to Windows servers, but that I could also use it inside the same partition to quickly redirect printouts from one writer to another. The technique is basically the same as I would use if I were sending printer output to another output queue on a different i5/OS or OS/400 partition. The good news is that it’s easy to put this technique into practice, and if you set it up correctly, it’s also easy to put the original printer writer back in place when your broken physical printer comes back on line. The Basic Setup If you’re not familiar with how to use a remote output queue to share one i5, iSeries, or AS/400 printer between two partitions, read this article to bone up on the concept. The primary benefit of using a remote output queue for sending printouts to the same printer from two different partitions is that it decreases conflicts by avoiding a situation where each partition writer may try to control the physical printer at the same time. One writer is put in charge of the printer’s start, stop, and form change functions while the other writer merely sends spooled files to the first writer for printing on the shared printer. It’s a fairly simple concept that keeps the reports printing from two different sources. Changing the Rules Just a Little The interesting thing that I found out about remote output queues is that I can also use them to redirect printouts to a different output queue on the same i5 partition. So in this case, where a critical printer is put out of commission and needs to be redirected to another system printer on the same partition, I can use a remote output queue to get the job done. Here’s my simple procedure for using a remote output queue to redirect printouts from one i5 writer to another writer on the same partition. Let’s say that I have two i5/OS writers on the same partition. Each writer sends printouts to different printer queues that service the same type of Hewlett Packard printer, and the output queues are named HPPRINT1 and HPPRINT2. The physical printer that HPPRINT1 sends spooled files to gives up the ghost one day and I need to quickly redirect reports to HPPRINT2 while I’m waiting for a replacement printer or for the printer maintenance people to show up. I can easily accomplish this task by performing three simple steps. 1. I rename the i5 writer or remote output queue for HPPRINT1 to another name for safekeeping. Because this is a temporary redirection, I want to save HPPRINT1’s original configuration so that I can use it again when the writer’s broken printer comes back on line. If HPPRINT1 is a printer device, I can use the following Rename Object command (RNMOBJ) to change the printer’s name so that I can preserve its original description: RNMOBJ OBJ(HPPRINT1) OBJTYPE(*DEVD) NEWOBJ(HPPRINT1SV) When I rename a printer device like this, it also changes the name of its associated output queue to the same New Object name parameter (NEWOBJ) as its parent device. So for this example, both the HPPRINT1 writer and HPPRINT1 output queue on my system are renamed to HPPRINT1SV. If my HPPRINT1 writer is a remote output queue that sends printouts directly to an HP printer without using a printer writer device, I would rename the output queue this way. RNMOBJ OBJ(Library_name/HPPRINT1) OBJTYPE(*OUTQ) NEWOBJ(HPPRINT1SV) 2. Once I have saved my original writer or remote output queue configuration, I can then create a new remote output queue that sends printouts to a writer or another remote output queue sitting on the same partition. To do this for our example, I would run the following Create Output Queue command (CRTOUTQ).
CRTOUTQ OUTQ(library_name/HPPRINT1) RMTSYS(Host_table_name or In this case, the Remote System parameter (RMTSYS) tells i5/OS to resolve the IP location of my partition by using either its host table name or its domain name in one of the partition’s DNS servers. If I want, I can also designate without a doubt that I am sending printouts to my home partition by designating that the printouts should be sent to the partition’s loopback address of 127.0.0.1. I would do that by changing my CRTOUTQ statement to look like this.
CRTOUTQ OUTQ(library_name/HPPRINT1) RMTSYS(*INTNETADR) The difference between these two statements is that in the second statement, I am telling the operating system to send spooled files directly to another output queue on the same system by using the loopback Internet address of ‘127.0.0.1’ (in the first statement, the remote output queue has to look up the system IP address through the host table or retrieve it form a DNS server, which adds some overhead). In the second CRTOUTQ command, I send printouts back to my partition by designating *INTNETADR in the Remote System parameter and by putting the actual loopback address in the Internet address parameter (INTNETADR). Using the loopback address, printouts are guaranteed never to leave the machine, and they will automatically be written to the output queue designated in the Remote printer queue parameter (RMTPRTQ). The rest of the parameters are the same regardless of whether you send printouts to your home partition by using a host name or an IP address. The Connection Type parameter (CNNTYPE) of *IP tells i5/OS that printouts sent to the remote output queue will be sent by using the TCP/IP protocol. The Destination Type parameter (DESTTYPE) of *OS400 tells the queue that the designated system is another AS/400, iSeries, or i5 box, and the Writers to Autostart (AUTOSTRWTR) and Host print transform (TRANSFORM) parameters tell i5/OS to a) automatically start this remote output queue whenever the QSPL spooled file subsystem is started; and b) to avoid transforming spooled files to another format before sending them to the designated output queue. By using either of these commands to recreate my output queue as a remote output queue, I can easily use TCP/IP to send spooled file output from one output queue (HPPRINT1) on my system to another (HPPRINT2). This is a handy trick to keep production reports churning when you are waiting for a sick printer to be repaired or replaced. 3. When my original printer is fixed and I want to reconfigure my system to once again send printouts to the newly repaired printer, I can restore my original printer device or remote output queue by running the following commands. First, I delete the temporary remote output queue that I created for this function. For my example, I can easily do this by running this Delete Output Queue command (DLTOUTQ). DLTOUTQ OUTQ(Library_name/HPPRINT1) Note that the printer must first be ended to delete the output queue. Since this is a remote output queue (where anything I put into it should immediately be sent to another output queue), I should not have to worry about clearing it out before deleting it. Next, I would rename the HPPRINT1SV printer device and output queue (or just the remote output queue) that I saved in step one. I can easily do that by running one of these two Rename Object commands. If the original configuration is a printer device, I would use this command to rename it and its associated output queue back to their original names: RNMOBJ OBJ(HPPRINT1SV) OBJTYPE(*DEVD) NEWOBJ(HPPRINT1) If I had saved a remote output queue in step one, I would use this RNMOBJ command to rename just the output queue back to its original name. RNMOBJ OBJ(Library_name/HPPRINT1SV) OBJTYPE(*OUTQ) NEWOBJ(HPPRINT1) Then once I restarted my writer, spooled file outputs will start printing to their original physical printer again. As you can see, there are a lot of benefits in knowing some of i5/OS’ basic building blocks, as well as some additional tricks for making them work in new and different ways. All it takes is a little imagination and a basic knowledge of how the system works. About Our Testing Environment All configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Most of the referenced commands are also available in earlier versions of the i5/OS and OS/400 operating systems, so the configurations should be usable in prior releases. However, you may notice minor variations in pre-V5R3 copies of these commands. These differences may be due to incremental command improvements that have occurred from release to release. RELATED STORY Use Remote Output Queues to Share Printers Between Partitions |
