Newsletters   Subscriptions  Forums  Store   Career  Media Kit  About Us  Contact  Search   Home 
fhg
Volume 5, Number 42 -- November 9, 2005

Admin Alert: Use Remote Output Queues to Share Printers Between Partitions


by Joe Hertvik


With many shops running multi-partition i5 or iSeries boxes, writers and remote printers can become an issue between partitions. It's not practical to create and manage two or more writers that point to the same physical printer on different partitions, because duplicate printers on different partitions can interfere with each other. Fortunately, i5/OS has a handy solution for sending spooled files from different partitions to the same printer: two remote output queues working in tandem.

Using two remote output queues, you can easily set up one output queue on the first partition to send i5/OS spooled files to an ASCII printer on your network, while a second remote output queue on a second partition sends spooled files to the first partition's remote output queue, where it is automatically redirected to your network printer. By doing this, you can create a path for sending i5/OS spooled files from either of two partitions to the same network printer, where both partitions cooperatively share the same i5/OS-to-network printer connection.

Creating a cross-partition printing setup like this is easy to do. To prove it, let's walk through all the steps needed to make this configuration happen. Before we start, please note that, although I refer to this technique as working on i5 machines running i5/OS V5RX, you can use all of these commands to set up the same configuration on iSeries and AS/400 computers running earlier versions of OS/400. The commands are similar, if not identical, in both environments.

In our sample, let's assume that we have two i5 partitions, PartitionA and PartitionB. PartitionA has a TCP/IP address of 10.1.0.5 and PartitionB has a TCP/IP address of 10.1.0.10. We want application programs on each partition to be able to print to a Hewlett-Packard 3880 printer that is available on our internal network at a local TCP/IP address of 10.1.0.25. Here are the steps that I would take to share this printer between partitions so that jobs from either partition can easily direct spooled output to it.

First. On PartitionA, I would first create a remote output queue that redirects spooled file output to the networked HP 3880 printer that I want to print to. This PartitionA output queue will function as the master printer that directly communicates and sends spooled files from both partitions to the remote HP printer. As such, I will use it to start and stop my i5/OS printer, answer printer messages, and manage printouts. It does not matter if I set this printer up as an OS/400 printer device or as a remote output queue, as long as it points to my networked TCP/IP printer. While there are a number of ways to set up this printer, I have already provided some examples for setting up a remote output queue that prints to a networked TCP/IP printer. You can find these examples by reading my earlier article, Admin Alert: Three Ways to Direct OS/400 Output Queues to TCP/IP Printers. For our purposes, I'll use the information in that article to create my i5/OS-to-HP 3880 remote output queue on PartitionA, and I'll name that output queue HP3880A.

Second. I would make sure that PartitionB can reach PartitionA through TCP/IP. Generally, there are three ways that I can enable TCP/IP communications between my two partitions.

  1. By telling PartitionB to talk to PartitionA using its direct TCP/IP address of 10.1.0.5. This requires no additional TCP/IP configuration in i5/OS. All of the configuration will occur in the next step when we create a remote output queue on PartitionB that allows PartitionB to send spooled file output to PartitionA.


  2. By referencing a host table entry on PartitionB that points to the TCP/IP address of PartitionA. I can create an i5/OS Host Table entry on PartitionB that associates a host name with the TCP/IP address of PartitionA (10.1.0.5). If I want to create a host name called PARTA that points to PartitionA's TCP/IP address, I can easily do this by running the following Add TCP/IP Host Table Entry command (ADDTCPHTE):
    ADDTCPHTE INTNETADR('10.1.0.5') HOSTNAME((PARTA)) 
    TEXT('Host name for PartitionA')
    
    By doing this, each time that I reference PARTA in a TCP/IP parameter or command, OS/400 will automatically find this entry in its internal Host Table and send that request to an IP address of 10.1.0.5. It's important to note that Host Table entries are internal to the partition they are created on, and they cannot be used by any other i5 or iSeries partitions or by any other machine on your network.

    After adding the new Host Table entry, I can view and update it or any other Host Table entry on my partition by using option 10, Work with TCP/IP host table entries, from the green-screen Configure TCP/IP menu (the Configure TCP/IP menu can be reached by typing in GO CFGTCP from a green-screen command line).


  3. By adding a Domain Name Server (DNS) entry that links the host name PARTA with PartitionA's TCP/IP address of 10.1.0.5. This is similar to the process of adding a local host table name that I described in the last step, except that the entry is added to the DNS server that i5/OS uses when it tries to resolve a host name to an IP address. To find the list of DNS servers that your partition uses when resolving host names, enter the Change TCP/IP Domain command (CHGTCPDMN) on a green-screen command line and press F4 to prompt for your system's domain values. You'll find the server's external DNS servers listed under the Domain name server: Internet address parameter list parameter (INTNETADR). If not already present, I can add a new DNS entry for PartitionA to this server.

It's helpful to mention that all three of these options use the same TCP/IP connection techniques that I used in step one for creating my PartitionA remote output queue, HP3880A. So the good news is that the mechanics for communicating via TCP/IP are the same whether you are sending from an i5 or iSeries box to an HP printer or whether you are transmitting data via TCP/IP between two i5/OS boxes.


Third. I would then create a remote output queue called HP3880B on PartitionB. This output queue will automatically send spooled files to the HP3880A output queue on PartitionA. The end result is that, once a program or user places a spooled file in the HP3880B output queue on PartitionB, that spooled file is automatically transferred to the HP3880A output queue on PartitionA. The HP3880A remote output queue on PartitionA, in turn, automatically sends the newly received spooled file to the networked HP 3880 printer. By setting up the HP3880A and HP3880B output queues on my two partitions, I will have created a mechanism for automatically transferring spooled files from either of the partitions over to my networked HP printer.

The new HP3880B queue for PartitionB is created by using the Create Output queue command (CRTOUTQ) in one of two configurations. These configurations relate to the three different ways I mentioned in step two that PartitionB can resolve the IP address of PartitionA. Here are the two ways that I can create a remote output queue that automatically transfers i5/OS spooled files from PartitionB to the HP3880A remote output queue on PartitionA.

If I want to set up my HP3880B output queue so that it explicitly sends spooled file output from PartitionB to PartitionA by using PartitionA's IP address, I would enter my CRTOUTQ command like this:

CRTOUTQ OUTQ(library_name/HP3880B) RMTSYS(*INTNETADR)
RMTPRTQ('library_name/HP3880A') AUTOSTRWTR(1) CNNTYPE(*IP)
DESTTYPE(*OS400) TRANSFORM(*NO) INTNETADR('10.1.0.5') 

The Output queue parameter (OUTQ) specifies the name and library where I want to create my new remote output queue. The Connection Type parameter (CNNTYPE) of *IP specifies this output queue communicates via TCP/IP, while the Remote System parameter (RMTSYS) value of *INTNETADR tells i5/OS that spool files will reach the target system by using the 10.1.0.5 IP address listed in the Internet Address parameter (INTNETADR). The Destination Type parameter (DESTTYPE) value of *OS400 specifies that the remote system that this output queue will send spooled files to is an i5, iSeries, or AS/400. The Remote Printer Queue parameter (RMTPRTQ) tells my output queue the library and output queue name of the remote output queue on PartitionA that it should send the spooled files to. Finally, setting the Writers to Autostart parameter to '1' tells i5/OS that this remote output should be started whenever the QSPL printer subsystem is started and the Host print transform parameter (TRANSFORM) value of *NONE tells i5/OS not to translate my spooled files to ASCII format when they are transmitted to PartitionA.

This command is complete and it will create my remote output queue for sending spool files to PartitionA's HP3880A remote output queue by using a hard-coded TCP/IP address. If I wanted to change this CRTOUTQ command to specify PartitionA's TCP/IP address through a host table entry or a DNS entry, I could change the command to the following:

CRTOUTQ OUTQ(library_name/HP3880B) RMTSYS(Host_table_name or
DNS_entry_name) RMTPRTQ('library_name/HP3880A') AUTOSTRWTR(1) 
DESTTYPE(*OS400) CNNTYPE(*IP) TRANSFORM(*NO) 

The only difference between this command and the previous CRTOUTQ command is that there is no explicit IP address specified in the INTNETADR parameter. Whenever a spool file is placed in this output queue, i5/OS will resolve the IP address of my target PartitionA system by using either the partition's Host Table or one of its designated DNS servers, and then transmit the spooled file to that TCP/IP address. It's usually better to designate a TCP/IP address through a host table entry or a DNS server than it is to hard-code it into your commands. This is true because if the target i5 box changes its IP address, then you can automatically ripple that IP address down to your object by changing a single entry, rather than having to change your output queue's IP address. Using an entry is also easier because the entry can be assigned to any i5/OS object that needs to communicate with the PartitionA partition. So you would only have to enter PartitionA's IP address once for any cross-partition communication.

So that's it. Three relatively simple steps to enabling two i5, iSeries, or AS/400 partitions to print to the same networked printer. You should also note that this technique is not restricted to TCP/IP printers; it will work with any other type of OS/400 printers where you want to send spooled files to the same printer from two or more partitions.


RELATED STORIES

Three Ways to Direct Output Queues to TCP/IP Printers

Admin Alert: Remote OUTQs and Auto-Answer Printer Messages

Admin Alert: More on Remote OUTQs and Printer Load Form Messages

Sponsored By
PATRICK TOWNSEND & ASSOCIATES

Deploy. Run. Manage. Succeed.

Alliance AES/400
Database Field Encryption

· Encrypt credit card, social security, pin numbers and other sensitive data.
· Easy to use with RPG or COBOL - sample code included.
· Get compliant - SOX, Privacy notification, GLBA, Etc.
· Free 30-day trial. Fully functional software - Not a demo.

DB2 field encryption with Alliance AES: Encrypt and decrypt individual fields in AS/400 DB2 database files. Alliance APIs can be used in RPG and Cobol applications including older OPM applications. Alliance AES encryption for DB2 fields integrates with Alliance key management for the secure storage of AES keys.

DB2 file encryption with Alliance AES: Encrypt any DB2 database file with Alliance AES/400. You can specify that the data be converted to ASCII or retained in the original EBCDIC character set. You can also specify that the pass phrase should be converted to ASCII for decryption on an ASCII system such as Microsoft Windows. Alliance DB2 file encryption integrates with Alliance AES key management.

IFS file encryption with Alliance AES: You can encrypt and decrypt IFS (Integrated File System) files with Alliance AES encryption commands. Once encrypted files can be decrypted on an AS/400 or Windows PC or Server platform. You can also use the free Alliance Windows AES encryption application to encrypt files on a Windows platform for decryption on the AS/400. IFS file encryption integrates with Alliance AES key management for secure key storage.

AES self-decrypting archives: Alliance AES/400 can encrypt files into a self-decrypting archive. A self-decrypting archive is a Windows executable program. You can run the self-decrypting archive, enter a pass phrase, and decrypt and extract the file. If run from a command line you can pass the program parameters for the decryption. This is helpful if you are automating the decryption process. If you run the self-decrypting archive program without parameters it presents a Windows GUI dialog for pass phrase and other decryption information.

Report distribution with AES encryption: When Alliance AES encryption is used with the Alliance FTP Manager application you can automatically distribute reports in encrypted or self-decrypting archive format. Reports can be sent from one or more output queues, and reports can be selectively routed from the output queue.

AES key management: Alliance AES/400 provides a complete key management facility to help you securely store keys and pass phrases. All application program interfaces and commands allow the use of a named AES key. The Alliance AES key manager automatically backs up the key store when keys are added or changed.

Windows encryption application: Alliance AES encryption includes a Windows application that you can freely distribute to provide encryption and decryption services. Files encrypted on a Windows platform with the Alliance application can be decrypted on the AS/400. Files encrypted on the AS/400 can be decrypted on the Windows platform.

Sample code: The Alliance AES/400 product includes sample RPG and ILE-RPG source code that demonstrate how to use the encryption APIs. There are also sample CL programs that show how to use the Alliance commands to encrypt and decrypt files, and create self-decrypting archives.

More information:
Patrick Townsend & Associates, Inc.
7700 Earling Street NE
Olympia, WA 98506
Voice: (360) 357-8971
Fax: (360) 357-9047
Email: Info@patownsend.com
Web: www.patownsend.com

Click here for 30 day trial


Technical Editors: Howard Arner, Joe Hertvik, Ted Holt,
Shannon O'Donnell, Kevin Vandever
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
Contact the Editors: To contact anyone on the IT Jungle Team
Go to our contacts page and send us a message.


THIS ISSUE
SPONSORED BY:

ProData Computer Svcs
iTera
Patrick Townsend & Associates


Four Hundred Guru

BACK ISSUES

TABLE OF
CONTENTS
A Handy RPG FUNction

Edit Spooled Files with SEU

Admin Alert: Use Remote Output Queues to Share Printers Between Partitions


The Four Hundred
Domino on the iSeries Versus the Competition

Two New iSeries ISVs Target Large Accounts

PA Semi Divulges Its Power Processor Aspirations

As I See It: Management by Intercourse

Four Hundred Stuff
Infor's Owners Gobble Up Geac for $1 Billion

RODIN Simplifies Maintenance of Data Warehouses

Kisco Boosts Security in WebReport/400

Wyse Takes Software-Oriented Thin Client Strategy to the Market

Four Hundred Monitor


Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.
Guild Companies, Inc. (formerly Midrange Server), 50 Park Terrace East, Suite 8F, New York, NY 10034
Privacy Statement