A couple of issues ago, I wrote about setting up Client Access for printing under TCP/IP using a Line Printer Daemon (LPD). (See “AS/400 Printing to Windows Clients” in Client Access/400 Expert, November/December 1996.) The problem for Client Access/400 is that no native printer emulation is provided for clients connecting through TCP/IP. The solution is to use an LPD that handles the printer data stream as a separate server program on the PC.
Since the publication of that LPD article, IBM also published an article on the same process and posted it on the Web. In that document, IBM identifies the pros and cons of using an LPD. If your interest has been sparked, you’ll want to check out that article at http://www.as400.ibm.com/client/print.htm.
The response to my original article was quite positive, but some of you commented that you found it curious I didn’t mention how to set up remote output queues on the AS/400 to make the printing process easier. Essentially, you said, “It’s a drag to have to search for a user’s output and then use the Send TCP Spooled File (SNDTCPSPLF) command.” With that thought in mind, here is how you set up a remote output queue to facilitate automatic printing over TCP/IP.
What Is a Remote Output Queue?
A remote output queue is an enhanced AS/400 output queue that passes printer control information to a remote host. As the data is transferred from the AS/400, it’s removed from the output queue, just like any printer output queue. In the case of Client Access/400, this recipient host will be the LPD. Since the printer data stream normally sent by the AS/400 is in the Systems Network Architecture (SNA) character set with its own unique printer control commands, OS/400 also provides a mechanism within the remote
output queue to transform the output to an ASCII printer data stream, including some common ASCII control codes.
The advantage of using a remote output queue is obvious: Instead of searching for your spooled files and then manually transferring them to the LPD, you can merely set the job description to the new remote output queue. Everything will then be handled automatically—the user’s output will automatically be sent out through the queue to be printed on his local printer using a readily obtainable LPD.
As in the previous article, I’ll be using the Remote Print Manager (RPM) product, available from Brooks Internet Software at www.brooksnet.com, and the Windows 95 Client Access/400 client.
Simple OS/400 Steps
Begin by keying in CRTOUTQ and pressing F4 on the OS/400 command line, as shown in Figure 1. Key in an appropriate name for your output queue and the library where you want the queue to reside. In the area labeled Remote system, key in *INTNETADR. This will tell OS/400 that it will need to send along some Internet information. In the area labeled Remote printer queue, key in the actual name of the printer queue as it is known to your PC’s LPD. In the example shown, the queue managed by the RPM LPD is known as LPD_Q_ONPC. When OS/400 starts sending information to the TCP/IP LPD, it will rely upon RPM to direct the print job to this particular queue.
Scroll to the screen shown in Figure 2 and continue filling out the appropriate parameters. In the area labeled Writers to autostart, key in 1. This will ensure that an OS/400 writer will be created and automatically started with the remote output queue.
In the area labeled Queues for writer messages, I usually put the message queue of the person who actually controls the printer, so he can handle any errors. Remember, however, that the actual control of the physical printer is handled by the LPD software on the PC. Messages about the writer program that are created on the OS/400 side may be more appropriately handled by the local systems operator.
In this example, you’re sending a printer data stream across TCP/IP to an LPD, so you’ll use a connection type of *IP, and in the Destination type field, you’ll type in *OTHER. (In Joe Hertvik’s article on the cover of this issue, Joe uses *IPX and *NETWARE for these parameters because he is sending his printer data stream to his NetWare Print Server. This shows how flexible the CRTOUTQ function has become for OS/400.) Under the Host print transform parameter, specify *YES. This will tell OS/400 to translate the printer data stream from the SNA character set to an ASCII character set.
Press Enter and the parameter for Manufacturer type and model will appear. This is the area in which you will identify the kind of printer attached to the PC. In this example, you’ll see that I’m using the value of *EPLQ510, which represents an Epson Letter Quality 510 printer. By pressing F4, you can get an entire list of supported printers. You may have to research and experiment a bit to determine the supported printer that best matches the printer on your PC.
For the Internet address, specify the exact IP address of the PC that is running the LPD software. Aliases are not supported. Finally, if you don’t want printer separator pages sent with every printout, change the Print separator page parameter to *NO. Press Enter and your new remote output queue will be created.
Changing Your Job Description
To automatically route your print jobs to your remote output queue, you may want to change the user profiles of those individuals who will be using this printer, using the Change User Profile (CHGUSRPRF) command, or you may prefer to create a separate job description and then modify the user profile to make use of that description.
Figure 3 shows the Change Job Description (CHGJOBD) command. In this example, a JOBD called STOTOM has been modified to redirect print jobs to the output
queue called RMTTCPOUTQ, which was just created. Now, any job that uses this STOTOM job description will automatically send the print job across TCP/IP to the LPD named by the remote output queue.
The Line Printer Daemon
Figure 4 shows Brooks Internet Software’s RPM LPD receiving a print job from an AS/400. Multiple printer queues can be established using this software, each sending jobs to an associated printer. In the November/December 1996 issue of Client Access/400 Expert, I showed you how to set up this LPD, so I won’t take up space here. Essentially, each queue that you specify to RPM creates a separate subdirectory to receive the AS/400 data stream. The printer data stream arrives as a file and is then redirected to the Windows Print Manager.
A fully functional demonstration copy of the RPM LPD can be obtained from Brooks Internet Software at http://www.brooksnet.com. Versions for Windows 3.1, Windows for Workgroups 3.11, Windows 95, and Windows NT are available. Or you may want to search the Internet for other LPDs that have functions that more closely fit your needs. The process for configuring the remote output queue on the AS/400 should remain the same.
If you’ve got specific comments or questions on how or when to use an LPD, don’t hesitate to email us. It’s a neat feature that turns TCP/IP into a highly functional medium for Client Access.
Figure 1: Creating a Remote Output Queue using CRTOUTQ
Figure 2: TCP/IP Remote Output Queue Parameters Figure 3: Automatic Print Routing to the LPD using a Job Description
Figure 4: Receiving a Print Job using the RPM Line Printer Daemon
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online