26
Mon, Feb
3 New Articles

Printing to an IP-connected Network Printer

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

In the wonderful days of yesteryear, there was a printer on every desktop. As networks have matured, the printers are

 

no longer directly attached to just one desktop. Network printers have become an integral part of the modern office. Presenting a low-cost, easy-to-maintain solution, they are sprouting up everywhere.

With the iSeries 400 now attached to the office network, the question of how to utilize these printers moves to the forefront. If the iSeries 400 and the network printer are on the same network, how can I get the two to talk to one another? The iSeries has the capability to talk to nearly anything. By the end of this article, you should have a powerful tool at your disposal to open up network printers for printing from the iSeries.

Output queues have been a regular part of the printing process "since the dawn of time," and you can use the Create Output Queue (CRTOUTQ) command to tap into the network printers. CRTOUTQ has been a trusty friend, and IBM expanded the capabilities of this command in OS/400 V3R7. The output queue and its associated writer become the bridge between the iSeries 400 output and the IP-connected network printers. With OS/400 built-in functions, solving the printing problem becomes quite simple. Figure 1 displays an example of the CRTOUTQ command with the appropriate values filled in.

 
CRTOUTQ  OUTQ(QUSRSYS/ACCT02Q)
RMTSYS(*INTNETADR)
RMTPRTQ('LPT1_PASSTHRU')
AUTOSTRWTR(1)
CNNTYPE(*IP)
DESTTYPE(*OTHER)
TRANSFORM(*YES)
MFRTYPMDL(*HP4)
INTNETADR('172.16.12.49')
SEPPAGE(*NO)
TEXT('Accounting HP Laserjet 4 via IP')

 

Figure 1: Use the CRTOUTQ command to establish a connection to an IP printer.

 

Network Terms 101

Before diving into the parameters of the CRTOUTQ command, some network terms need to be defined. This will aid in understanding the pieces and parts involved and will remove some of the mystery behind some of the parameters. The underlying protocols, utilities, and devices are often taken for granted when everything is working fine, but each has a role in making the simplest of print jobs successful. Most of the components have existed for years and are now being utilized for workgroup computing. The following is by no means a complete list of network-related components, but it will serve as a good starting point:

  • TCP/IP--This set of communication protocols defines how data is passed back and forth across a network.
  • IP address--This is a numbering system that the network uses to know where a device exists on the network. The IP address of a device can be either a static address (assigned once and never changed) or a dynamic address (the network itself assigns a new IP address to the device every time the device is turned off and then on again). The IP address is used by the routers on the network to deliver packets of commands and data to the destination device. The numbering system consists of a series of four numbers separated by periods, and each position has a significant meaning. So, a typical IP address would look something like the following: 172.16.12.49 or 192.25.1.32
  • Ethernet--This network topography supports the assigning and addressing of IP addresses. It defines a particular method of breaking data into packets and passing these packets to and from various devices.
  • PING--This command is used for testing whether a workstation or server on the network can communicate with the specific device represented by an IP address. A packet is sent to the specified address, and, if the device successfully receives the packet, it responds by sending the packet back. Think of PINGing an IP-addressed network device as similar to a submarine sending out a sonar wave to determine if an object is close by. The sonar waves go out; if they return, the submarine knows that something is close at hand. PINGing a device doesn't tell you what type of device it is, but it does confirm that a connection can, at the very least, be made. The PING command on the iSeries400 would look like this (using one of the example IP addresses):

PING ADDR('172.16.12.49')

  • Print Server --This device connects a printer to the network and acts as a communications liaison between the printer and the network. It may be an internally installed card or an external box. This is the device to which the IP address is assigned. The print server has several functions. It translates the packets coming from the network into something the printer understands; it maintains communications with the network; and it acts as a referee when more than one print job is thrown at the printer at the same time. Additional functions may be added by the print server's manufacturer.
  • Line Printer Requester/Line Printer Daemon--LPR/LPD are book-end utilities that allow print jobs to be sent by way of TCP/IP across a network. LPR sends the print file, and LPD receives the print file.

 

Some Work Has Already Been Done

The scope of this article doesn't cover the configuration of the underlying subsystems and communication protocols that are needed to connect devices on the network. Setting these up and maintaining them are the jobs of the iSeries and network administrators. Assume that a few things are already in place and working fine. First, the network devices that connect the iSeries, the PCs, and the printers support the TCP/IP protocol (a common type is Ethernet). Second, the iSeries already has TCP/IP configured and running. Third, the network printer has a static IP address. This is very important, as the IP address of the network printer cannot change after the output queue has been created. It is the IP address that the iSeries will use to route the output file to the network printer. The network administrator should provide the printer's IP address. Finally, when PINGing the printer using the IP address, the packet is successfully returned, meaning that the iSeries can, in fact, communicate with the device. These assumptions simply mean that our environment is primed to allow the iSeries to print to the IP-connected network printers.

 

Welcome Back, Old Friend

The CRTOUTQ command allows us to create an output queue that contains print files. As boring as that description might seem, the actual wonder is revealed in the way the command is constructed. By specifying the right values on the right parameters, the plain-vanilla output queue is transformed into a staging area for printing to the IP-connected network printers. The associated writer becomes a powerful companion that takes the files from the queue, translates them for the destination printer, and sends them through the network to the printer itself. In the process of creating the output queue, you will also implicitly create an associated writer, accomplishing two tasks with one command. There will be an interesting twist, though. Because the printer is not directly attached to the iSeries, the type of writer created is called a remote writer.

One notable limitation exists using this method: the output file must have a printer device type of *SCS, which means that basic report formatting is available, but some of the features available with printer files generated for *IPDS device types are not available. Several *SCS printer device file parameters do influence the way that the output file is printed, and the vast majority of reports fall into this category.

 

Doing Your Homework

Before you can create the output queue that will allow output files to be sent to the IP-connected network printer, you must answer four questions.

  • What is the type and manufacturer of the network printer?
  • What is the statically assigned IP address?
  • What is the type and manufacturer of the print server?
  • What will be the name of the new output queue?


The answers become the values to some of the parameters of the CRTOUTQ command.
As you build a sample CRTOUTQ command, use the following as an example: an HP LaserJet 4 printer has been assigned a static IP address of 172.16.12.49; the print server that connects the printer to the network is an Intel Netport Pro print server; and the output queue name is ACCT02Q because it resides in the Accounting department. Also assume that users are currently printing to the printer from their PCs and that you've successfully PINGed the printer from the iSeries.

 

The Mystery Revealed

Several parameters of the CRTOUTQ command are necessary to accomplish the stated goal. Sometimes the value for one parameter will drive the value for a following parameter, as some of the parameters are interrelated. Each is discussed in turn as the command is built.

  • OUTQ--Output queue specifies the library where the output queue is located and the name of the output queue itself. Using the example above, this is what the parameter would look like:

OUTQ(QUSRSYS/ACCT02Q)

  • RMTSYS--Remote system specifies the remote system that the iSeries should send files to when it's time to print. Because the printer is located on the network and is linked to the iSeries by an IP address, the value for this parameter will be *INTNETADR. This parameter's value will drive the value of the parameter CNNTYPE. By specifying *INTNETADR as the RMTSYS, the CNNTYPE must be set to *IP. It will also cause the type of writer associated with this output queue to be a remote writer:

RMTSYS(*INTNETADR)

  • RMTPRTQ--Remote printer queue is the name of the printer queue on the remote system that the output files are sent to. When printing to an IP-connected network printer, this parameter is directly related to the type and manufacturer of the print server. IBM has published a partial list of these values in an online technical support document at www.ibm.com/support. Search for "Recommended RMTPRTQ Values." Although the document is not a complete list, it does list several of the more common print servers. Figure 2 lists two examples for this parameter. Because the example print server is an Intel Netport Pro print server, the value for this parameter is LPT1_PASSTHRU:

RMTPRTQ('LPT1_PASSTHRU')

Print Server
RMTPRTQ Entry
HP JetDirect Card (Internal)
'raw' (formatted)
'text' (unformatted)
Intel Netport Pro
'LPTx_PASSTHRU' (formatted)
'LPTx_TEXT' (unformatted)
where x = port

Figure 2: Remote Printer Queue entries are based on print server manufacturer.

 

  • AUTOSTRWTR--This parameter specifies the number of remote writers that will be started automatically by the system when the output queue is created or the system IPLs. This parameter takes the place of the Start Remote Writer (STRRMTWTR) command so that the STRRMTWTR command doesn't have to be manually executed after creating the output queue:

AUTOSTRWTR(1)

  • CNNTYPE--This parameter specifies the connection type that the iSeries will make with the remote system. Because *INTNETADR was specified on the RMTSYS parameter, the value for CNNTYPE must be *IP. This means that the spooled files will be sent from the iSeries 400 to the network printer using TCP/IP:

CNNTYPE(*IP)

  • DESTTYPE--Destination type specifies the type of the remote system. This parameter, along with the type of data contained in the spooled file, is used by the remote writer to determine the format used to send the spooled file. Because *INTNETADR was specified on the RMTSYS parameter, the value for this parameter is *OTHER:

DESTTYPE(*OTHER)

  • TRANSFORM--This parameter is Transform SCS data to ASCII; it determines whether the writer should make use of the host print transform function to transform a spooled file of device type *SCS into ASCII data when the file is sent to a remote printer. The value should be set to *YES:

TRANSFORM(*YES)

  • MFRTYPMDL--This parameter specifies the manufacturer, type, and model for a printer using the host print transform function or user data transform program. *IP must by specified on the CNNTYPE parameter and *YES must be specified on the TRANSFORM parameter in order to use this parameter. F4 (prompt) will be very helpful in viewing the vast IBM-supplied list of manufacturer printer types and models. The example printer is an HP LaserJet 4 printer, so the value will be *HP4:

MFRTYPMDL(*HP4)

  • INTNETADR--This is the IP address of the network printer that output files in this output queue will be sent to. Because *INTNETADR was specified on the RMTSYS parameter and *IP was specified on the CNNTYPE parameter, the IP address must be entered. The IP address assigned to the example printer is 172.16.12.49, making the INTNETADR parameter look as follows:

INTNETADR('172.16.12.49')

  • SEPPAGE--This parameter determines whether or not to request a separator page when printing on a network printer. This is individual preference; no separator page will be required for the example:

SEPPAGE(*NO)

  • TEXT--Text description is a brief description of the output queue. Make sure that the description indicates that this output queue is for an IP-connected network printer:

TEXT('Accounting HP LaserJet 4 via IP')

 

Life Just Got Good

You now have a very powerful tool to access resources that have been begging to be utilized. Looking back at Figure 1, you can now see how it all fits together. There are many combinations of printers and print servers in the marketplace, but a couple of minutes spent in research will pay huge dividends in the long run. Even though the list of printer manufacturers is quite extensive, some printers may not be supported or may need to be set up in an emulation mode. Your mind is probably already turning to which printer you want to tackle first. Run, don't walk, to your nearest workstation and start experimenting. The steps to setting up and printing to the IP-connected network printer are simple and straightforward. I'll list these steps again for quick reference:

1. Answer the four questions.
2. PING the device.
3. Create the new output queue.
4. Test the new output queue.
5. Change user profiles to the new output queue.

One final thing: If you're setting up an HP LaserJet printer and would like to take advantage of the many fonts available to you, refer back to my article "Changing Fonts on IP-connected HP LaserJet Printers" for some insight.


Herbert H. Rea is a systems consultant for Mason Associates, Inc., based in Brunswick, Maine, and has been working with the AS/400 since 1989. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..


BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$0.00 Raised:
$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: