• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Admin Alert: Avoiding Restoration Problems with Remote Output Queues

    November 5, 2008 Joe Hertvik

    i5/OS remote output queues are used to send spooled files to printers attached to remote systems. They are commonly created with two objects: the remote output queue itself; and a virtual printer device that allows the queue to function as a locally attached printer device. However, this configuration has some issues when it is restored from backup media, but those problems are easily fixed if you know the right tricks.

    Anatomy of a Remote Output Queue

    Remote output queues (remote OUTQ) are a special type of i5/OS writer that communicates with and sends spooled file output to a printer located on a remote system. A remote OUTQ is fairly easy to create, and I published setup instructions in an earlier Admin Alert column, see Remote OUTQs and Auto-Answer Messages.

    Unlike a printer device, a remote OUTQ is created without an associated writer. You start the remote writer by executing the Start Remote Writer command (STRRMTWTR), using the remote OUTQ name and library as the command’s parameters. A typical STRRMTWTR command would look like this.

    STRRMTWTR OUTQ(outq_lib/outq_name)
    

    The only thing that differentiates a remote OUTQ from a standard i5/OS writer is that by default, a remote OUTQ doesn’t have a printer device name. This causes problems whenever the system is using a program or command that does not support direct printing to an output queue. These functions–which include Query/400’s Work with Queries command (WRKQRY) and some third-party application–can only send spooled file output to a printer device. To allow these programs, commands, and applications to print to a remote OUTQ, you need to create a virtual printer device that redirects output toward a target remote OUTQ.

    A virtual printer device allows every program, command, and application on your system (including WRKQRY) to print directly to its corresponding remote OUTQ, making remote OUTQ writers the functional equivalent of a normal locally attached printer device. Note that some publications (including some IBM documentation) may refer to a virtual printer device as a “dummy device description”.

    For more information on how to create a virtual printer device that redirects spooled file output to a remote OUTQ, see my article Making a Remote Output Queue Look Like a Printer Device.

    Once you set up the remote output queue and its companion virtual printer device, the configuration will run fine, until you need to restore it.

    The Need To Restore Remote OUTQs/Virtual Printer Devices

    The problem with virtual printer devices and their associated remote output queues occurs when you try to restore them to the source system or when you try to restore them to another system. You may need to restore a virtual printer device/remote OUTQ pair in the following situations:

    • If the output queue is damaged on your source system, and you need to recreate it.
    • In a disaster recovery situation, where you are restoring your entire partition to another machine off site.
    • If you are migrating your current system partition to another system during a system box swap, such as when you’re upgrading a System 520 to a System 550.
    • If you are restoring your virtual printer device/remote OUTQ to a high availability Power i box residing on another partition or machine.

    In each of these instances, the virtual printer device/remote OUTQ must be set up exactly the same way that it was set up on the original source partition. The problem with duplicating this setup deals with the way that IBM uses the Restore Configuration (RSTCFG) command to restore printer device descriptions to the system.

    The Trouble With RSTCFG and Virtual Printer Devices

    I can best illustrate this problem through an example. Let’s say that I set up a remote OUTQ/virtual printer device pair where both of the objects are named JOETEST. These objects exist in the following places:

    • The virtual printer description (*DEVD object type) named TESTJOE exists in the QSYS library, with the rest of the partition’s device descriptions. Remember, this is a dummy device whose only mission is to allow i5/OS to send spooled file output to a remote output queue.
    • The TESTJOE remote output queue (*OUTQ object type) resides in the QUSRSYS library. This output queue is already configured with all the location information for sending spooled file output to a printer that is attached to a remote system. For this particular configuration to work, IBM specifies that the remote output queue must reside in the QUSRSYS library.

    The traditional way to move these pairs is to perform the following steps. Note: For restoring the TESTJOE objects back to their source system, I would first delete the TESTJOE device description and the TESTJOE remote output queue before I restore the objects.

    1. I would use the Save Configuration (SAVCFG) command to save my configuration data to media or a save file.

    SAVCFG saves all the configuration and resource management objects from my source system. These objects include all my line, controller and device descriptions (including the TESTJOE device), as well as all of my output queue configurations.

    SAVCFG DEV(device_name)
    

    2. Once the configuration is saved, I would transfer the backup media to my target system and run the following Restore Configuration (RSTCFG) command to restore TESTJOE to that system.

    RSTCFG OBJ(TESTJOE) DEV(device_name) OBJTYPE(*ALL)
    

    The second step is where the problem occurs. According to IBM, this RSTCFG command will restore the TESTJOE virtual printer device back to the QSYS library. However, because the system thinks the TESTJOE device is just a local printer device, it will create and restore a new normal output queue called TESTJOE in library QUSRSYS. RSTCFG does this because it is trying to configure the TESTJOE device the way that it thinks it should be configured. The net result is that because there will already be a normal output queue called TESTJOE on the system, RSTCFG will not restore the TESTJOE remote output queue to the system.

    And this problem will occur whether I am trying to restore one remote output queue/virtual printer device pair or 100 of them.

    Fortunately, there is an easy way to correctly restore these pairs without too much trouble. Here’s how you do it.

    The Right Way To Restore Remote Output Queues To a System

    The proper technique only adds three more steps to the procedure listed above, but those extra steps make all the difference. Here is the updated technique for restoring my TESTJOE remote output queue and virtual printer device.

    1. On the source system, all my remote output queues should reside in the QUSRSYS library. This technique will not work if the OUTQs are in another library, because the RSTCFG command will always create a corresponding output queue in QUSRSYS for my restored virtual printer device. If I needed to move the JOETEST remote output queue to QUSRSYS, I would use the Move Object (MOVOBJ) command, like this:

    MOVOBJ OBJ(lib_name/TESTJOE) OBJTYPE(*OUTQ) TOLIB(QUSRSYS)
    

    2. Backup the source system’s QUSRSYS library by using the following Save Library (SAVLIB) command:

    SAVLIB LIB(QUSRSYS) DEV(device_name) SAVACT(*SYNCLIB) 
    SAVACTMSGQ(QSYS/QSYSOPR)
    

    Notice that I am performing a save while active save on QUSRSYS, so that I backup all the objects in QUSRSYS, even if they are in use.

    3. Backup the source system’s configuration data to media or to a save file by using SAVCFG.

    SAVCFG DEV(device_name)
    

    4. On the target system, restore the remote output queue to the QUSRSYS library by using the backup media created in point 2 and the Restore Object (RSTOBJ) command.

    RSTOBJ OBJ(TESTJOE) SAVLIB(QUSRSYS) DEV(device_name) 
    

    This will put the TESTJOE remote output queue back in the QUSRSYS library on the target system.

    5. Again on the target system, restore the virtual printer device from the media configuration save file created in point 3.

    RSTCFG OBJ(TESTJOE) DEV(device_name)
    

    At this point, my remote output queue and its corresponding virtual printer device have been restored from my source system to my target system. Once started, the remote OUTQ will be able to send spooled files to its companion printer output queue on the remote system, and the virtual printer device that I restored to the target system will allow any command, program, or application to send spooled file output to its companion remote output queue.

    And that’s how to quickly and easily move or restore a remote output queue and its companion virtual printer device from one system to another.

    RELATED STORIES

    Making a Remote Output Queue Look Like a Printer Device

    Remote OUTQs and Auto-Answer Messages



                         Post this story to del.icio.us
                   Post this story to Digg
        Post this story to Slashdot

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    Rocket Software

    Meet digital age demands while maximizing your IT investment.

    Future-proof your mission-critical applications with Rocket® Solutions for IBM® i that keep your business ahead of the curve.

    Learn More

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Sponsored Links

    PowerTech:  Incorporating real-time security events from the System i into a security program
    Seagull Software:  Update your System i apps with LegaSuite GUI
    COMMON:  Join us at the 2009 annual meeting and expo, April 26-30, Reno, Nevada

    IT Jungle Store Top Book Picks

    Easy Steps to Internet Programming for AS/400, iSeries, and System i: List Price, $49.95
    Getting Started with PHP for i5/OS: List Price, $59.95
    The System i RPG & RPG IV Tutorial and Lab Exercises: List Price, $59.95
    The System i Pocket RPG & RPG IV Guide: List Price, $69.95
    The iSeries Pocket Database Guide: List Price, $59.00
    The iSeries Pocket Developers' Guide: List Price, $59.00
    The iSeries Pocket SQL Guide: List Price, $59.00
    The iSeries Pocket Query Guide: List Price, $49.00
    The iSeries Pocket WebFacing Primer: List Price, $39.00
    Migrating to WebSphere Express for iSeries: List Price, $49.00
    iSeries Express Web Implementer's Guide: List Price, $59.00
    Getting Started with WebSphere Development Studio for iSeries: List Price, $79.95
    Getting Started With WebSphere Development Studio Client for iSeries: List Price, $89.00
    Getting Started with WebSphere Express for iSeries: List Price, $49.00
    WebFacing Application Design and Development Guide: List Price, $55.00
    Can the AS/400 Survive IBM?: List Price, $49.00
    The All-Everything Machine: List Price, $29.95
    Chip Wars: List Price, $29.95

    Classic Software and System i Power World’s Largest Truck Stop A Few More Strands in the DNA of the Midrange

    Leave a Reply Cancel reply

Volume 8, Number 38 -- November 5, 2008
THIS ISSUE SPONSORED BY:

Help/Systems
WorksRight Software
Vision Solutions

Table of Contents

  • OPNQRYF Has No “If” But You Can Fake It
  • Embed PJL Statements in a Workstation Customizing Object
  • Admin Alert: Avoiding Restoration Problems with Remote Output Queues

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • POWERUp 2025 –Your Source For IBM i 7.6 Information
  • Maxava Consulting Services Does More Than HA/DR Project Management – A Lot More
  • Guru: Creating An SQL Stored Procedure That Returns A Result Set
  • As I See It: At Any Cost
  • IBM i PTF Guide, Volume 27, Number 19
  • IBM Unveils Manzan, A New Open Source Event Monitor For IBM i
  • Say Goodbye To Downtime: Update Your Database Without Taking Your Business Offline
  • i-Rays Brings Observability To IBM i Performance Problems
  • Another Non-TR “Technology Refresh” Happens With IBM i TR6
  • IBM i PTF Guide, Volume 27, Number 18

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle