|
Admin Alert: Making a Remote Output Queue Look Like a Printer Device
by Joe Hertvik
There are two types of OS/400 and i5/OS printers: printer devices and remote output queues. In general, printer devices are used to define local printers that are either directly attached to or are controlled from an AS/400, iSeries, or i5 box (such as iSeries access printers and locally attached printers), while remote output queues are spooling writers that send OS/400 spool output to a printer located on a remote system. Each device type serves a different function, and both types are started by different OS/400 commands.
Although remote output queues are necessary constructs when dealing with off-system printers, a problem occurs when certain OS/400 commands or software packages need to treat a remote output queue as if it were a locally controlled printer device. OS/400's Work with Queries (WRKQRY) command, for example, can only direct spooled output to a printer device name; it doesn't know how to reference a remote output queue. Certain third-party software packages also require a printer device name. And to complicate matters, some print servers are difficult or impossible to configure as OS/400 printer devices, so they cannot be referenced in certain packages, either. In these situations, you need to create a virtual printer device that the system recognizes as a printer device, but which actually redirects spool file output to the remote system through a remote output queue. In other words, you need to make a remote output queue look like a printer device.
A virtual printer device is simply an OS/400 printer device that serves as a reference point for a remote output queue. It isn't used to start an OS/400 printer job and, ideally, shouldn't even be varied on at all. Virtual printer devices provide a device name for your remote output queues, and they are very helpful in allowing OS/400 utilities or programs to access those queues. Here are the steps to follow.
Step 1: Create and Start a Remote Writer Using a Remote Output Queue
This is fairly easy to do, and you can find instructions in an earlier "Admin Alert" column called "Remote OUTQs and Auto-Answer Printer Messages." The only significant point to remember is that you must create your remote output queue in the QUSRSYS library, because that's where OS/400 will look for it when creating the virtual printer device.
Step 2: Create the Virtual Printer Device That Will Direct Output to Your Remote Output Queue
This is done by using the Create Device Description (Printer) command (CRTDEVPRT) as follows:
CRTDEVPRT DEVD(remote_output_queue_name) DEVCLS(*VRT)
TYPE(3812) MODEL(1) ONLINE(*NO) FONT(011)
Although this is a relatively simple command to enter, it's important to enter it the same way that it is printed here. In particular, remember the following points:
- The remote output queue name in the Device Description parameter (DEVD) must be the same name as your remote output queue, or this technique will not work.
- The device class parameter (DEVCLS) must be *VRT, which indicates that this is a virtual device.
- Most of the available references specify that the printer type (TYPE), model (MODEL), and font (FONT) parameters should be set to 3812, 1, and 011, respectively. However, I haven't found any references that specify why these parameters must be set to these values. Using a 3812 device could just be an accepted convention for setting up a virtual printer device, or it could be a hard requirement. These settings work and should be used, but it shouldn't really matter what these parameters are set to, because this printer device will never be used to start a printer job on the system.
- The Online at IPL parameter (ONLINE) must be set to *NO--meaning that, after an IPL, OS/400 will not attempt to start a printer job by using this device. In fact, you should take special care never to start a virtual printer device printer at all, because the remote output queue is what actually controls where your printouts are sent to.
- The other thing to note is that once you enter the CRTDEVPRT command to create the virtual printer device, you may receive an OS/400 error telling you that the device's printer output queue already exists. This is normal, because you will have already created the remote output queue that this device points to in step 1, and OS/400 will not let you overwrite that queue. Don't worry about this message; OS/400 will still create the virtual device you need and designate the remote output queue as attached to this device.
Once you've created your remote output queue and the virtual printer device, you should be able to direct output to that queue through any program or utility that requires a device name. It's a simple configuration to create, but one that is sometimes necessary when dealing with OS/400 functions.
Click here to contact Joe Hertvik by e-mail.
|
|
Sponsored By
PATRICK TOWNSEND & ASSOCIATES
|
|
PGP Encryption
Native on the AS/400
First and most used worldwide
· No security exposure on external PC's and servers
· Completely automate encryption and decryption
· Get compliant - SOX, Privacy notification, GLBA, Etc.
· Free 30 day trial. Fully functional software - Not a demo.
Find out more at www.patownsend.com
Visit us for 30-day trial
Deploy. Run. Manage. Succeed.
PGP encryption for AS/400 and iSeries
PGP (Pretty Good Privacy) is the de facto standard for strong encryption and data security. The public/private key encryption technology that is a part of PGP is recognized worldwide as the strongest commercial data security software available.
The Alliance FTP Manager PGP Option provides a full implementation of PGP encryption, decryption, signing, and key management functions for the AS400 and iSeries platform. A native AS/400 application, there is no security exposure on a separate PC or UNIX server for encryption services. And Alliance FTP Manager provides a full set of automation capabilities including IFS directory scan, library scan, Application Program Interfaces (APIs), encrypt on the fly and other services.
The Alliance PGP Option gives you the ability to fully manage public and private keys on the AS/400. You can create your own keys, export your public key to distribute to your trading partners, import your partner's public keys for your encryption tasks, view lists of keys, and revoke keys as needed. The key support provides everything you need to work with your trading partners.
Alliance PGP has been certified with several financial and medical insurance organizations. These include Bank of America, Credit Suisse, First Boston, Fleet, Citibank, Citicorp, Zirmed, NBP, VSP Enterprise, and others. New interfaces are certified on a frequent basis. Please contact Patrick Townsend & Associates if you have questions about PGP compatibility with your trading partner.
The Alliance PGP Option is based on the Network Associates commercial release of PGP and is compatible with PGP and eBusiness Server on S/390, UNIX, Windows, Linux, and many other platforms.
Alliance PGP Option can help you satisfy government requirements for compliance and privacy. It is certified for HIPAA requirements for security and, when combined with Alliance EDI Workbench/400, can provide a complete solution for HIPAA.
Find out more at www.patownsend.com
Visit us for 30-day trial
Deploy. Run. Manage. Succeed.
|
|
|
Technical Editors: Howard Arner, Joe Hertvik, Ted Holt,
Shannon O'Donnell, Kevin Vandever
Managing Editor: Shannon Pastore
Contributing Technical Editors: Joel Cochran, Wayne O. Evans, Raymond Everhart,
Bruce Guetzkow, Marc Logemann, David Morris
Publisher and Advertising Director: Jenny Thomas
Advertising Sales Representative: Kim Reed
|
|
|
|
|