Migrating Printers from Twinax/Coax to Ethernet
Short Answer
Migrating printers from twinax or coax to Ethernet takes one of three routes: replace the printer with a network-capable model, add an Ethernet interface card to the printer you already own, or put a protocol converter or print server in front of it. The host work is rebuilding device descriptions and output queues, not rewriting applications.
Why twinax and coax are still in your plant
Legacy attachment survives because it works and because nobody has been given a reason to touch it. A twinax run from a workstation controller can address several devices in a daisy chain, the host auto-configures them, and the printers themselves are often line matrix units that have outlasted three generations of servers. Coax printers hang off a 3270 control unit in the same way. The cabling is already in the wall and the print jobs still come out.
The pressure to move rarely comes from the printers. It comes from the server refresh. Twinax workstation controller adapters are not something you can order for current hardware, so the moment a Power server or a data centre consolidation is scheduled, every twinax device in the building becomes a project. Doing that work under time pressure, during a server cutover weekend, is how shops end up printing to nothing on Monday morning.
What you gain by moving to Ethernet
- Independence from the controller. One failed workstation controller card or one bad cable segment can take down every printer on the chain. On Ethernet each printer stands alone.
- Remote management and monitoring. Network interfaces expose a web page and SNMP, so you can see status, consumables and error conditions, and push firmware without walking the floor.
- Distance and placement freedom. Printers can move to where the work is, limited by structured cabling rather than by twinax runs and terminators.
- Cheaper moves, adds and changes. Relocating a printer becomes a patch panel change instead of a cable pull and a device address renumbering.
- A supported path forward. Every current industrial printer ships with or offers Ethernet. Twinax attachment narrows your replacement options to whatever is left on the used market.
Three routes off twinax, and one for coax
Pick the route per printer, not per site. A mixed answer is normal: replace the printers that were already near end of life, convert the ones with plenty of life left, and gateway the one machine nobody is allowed to touch.
| Route | How it works | Best when | Watch out for |
|---|---|---|---|
| Replace the printer | New model with native Ethernet and the emulations you need | The printer is old, slow or hard to get parts for | Form alignment and print stream differences |
| Add an Ethernet interface | Vendor network interface card fitted into the existing printer | The printer is healthy and the mechanism has life left | Card availability and firmware level on older units |
| External print server | Small box converting Ethernet to the printer parallel or serial port | No internal card exists for that model | One more device to power, mount and monitor |
| Twinax protocol converter | Gateway presents the twinax printer to the host over IP | The printer must stay exactly as it is | Keeps a legacy dependency alive; support is thinning |
| Coax to TN3270E | Printer sessions delivered over TCP/IP instead of a control unit | Mainframe or 3270 output still required | Session definitions and LU mapping must be rebuilt |
| Retire the document | Output goes electronic or merges into another printer | Volume is low and the paper is habit, not requirement | Confirm nobody downstream depends on the copy |
Keeping the host side stable
On an IBM i, twinax printers appear as auto-configured device descriptions. An Ethernet printer needs a LAN device description or a remote output queue instead, plus a decision about how the data stream reaches it. If the printer speaks IPDS you point Print Services Facility at it; if it is an ASCII device you enable Host Print Transform and choose a manufacturer type and model. Our explainer on IPDS, SCS and Host Print Transform covers that choice in detail.
The trick that saves most of the application work is naming. Create the new device description and output queue with the same names the old twinax objects used, so every printer file, job description and user profile that references them keeps working. You are swapping what sits behind the name, not asking developers to find every hard-coded reference.
Network prerequisites people forget
- Addressing. Static addresses or DHCP reservations, never a plain lease. A printer that changes address at 2 a.m. is an outage.
- Ports. Raw socket printing, LPD and the IPDS port all have to be open between the host and the printer subnet. Firewall rules are the most common cause of a printer that pings but never prints.
- VLAN and switch ports. Confirm the port is live, on the right VLAN, and not waiting on port security or authentication.
- Naming and DNS. Give each printer a meaningful host name tied to its physical location so the help desk can find it.
A step-by-step migration plan
- Inventory every attached device and what it prints. Record the controller, port and device address, the device description name, the printer model and its data stream, and every form or report that lands on it.
- Choose a route for each printer. Replace, fit an Ethernet interface, add an external print server, gateway it, or retire the output. Confirm interface card availability for the older models before you assume conversion is possible.
- Prepare the network before any hardware moves. Assign addresses or DHCP reservations, create DNS names, open the printing ports, and verify each switch port and VLAN. Order cable drops where none exist.
- Build the new host configuration in parallel. Create LAN device descriptions or remote output queues, set the transform or PSF options, and leave the twinax objects in place and varied off rather than deleting them.
- Pilot one printer end to end. Run every form that printer produces, including the awkward ones at month end, and check alignment, pitch, page length and barcode grade against the old output.
- Cut over in waves by area. Move a department at a time, keep the twinax path available as a fallback for that wave, and confirm each queue is producing before starting the next.
- Decommission and turn on monitoring. Remove the controller cards and retired cable, delete the old device descriptions once a full close cycle has passed, and add the new printers to your monitoring and alerting.
What usually goes wrong
Three failures account for most of the pain. The first is discovering mid-project that no Ethernet interface card is available for a particular printer, which turns a conversion into an unplanned purchase. Ask that question in step two, not step five. The second is form geometry: the print stream changes subtly when it goes through a transform, and reports that fitted perfectly on twinax come out shifted, double spaced or split across pages. The third is deleting the old configuration too early, which removes the fallback exactly when you need it.
One more catches people: a twinax printer can be quietly serving a second application or a second system, and only the inventory step will surface it.
How PCI runs twinax and coax migrations
Printer Connection has been moving industrial fleets off legacy attachment since 2001, and we sell both sides of the decision, so we have no reason to push a replacement when an interface card will do. We inventory the devices, tell you honestly which legacy printers are worth converting, source the interface hardware, and handle host configuration and form testing as part of our printer integration services. Where replacement is the better answer, we match the emulation and forms handling of the outgoing unit, including drop-in paths for IBM 6400 and InfoPrint 6500 line matrix printers, and we can fold the new devices into fleet management so they are monitored from day one. Give us the device list and we will scope the cutover.
Planning a server refresh with twinax printers?
Send us your device list and we will tell you which printers can take an Ethernet card, which should be replaced, and what the cutover looks like week by week.
Frequently Asked Questions
Can we keep our existing twinax printers and just put them on the network?
Often yes. Many industrial line matrix and dot matrix printers accept a vendor Ethernet interface card, which is the cleanest conversion because the mechanism, emulations and forms handling stay identical. Where no card exists, an external print server on the parallel or serial port achieves the same result with one more box to manage. A twinax protocol converter is the last resort: it works, but it keeps a legacy dependency in the path and support for those gateways is getting thin.
Will migrating to Ethernet break our applications or printer file references?
Not if you plan the naming. Applications reference device descriptions and output queues by name, not by how the printer is attached. Create the replacement objects with the same names, point them at the network device, and the printer files, job descriptions and user profiles keep working untouched. What can change is output appearance, because an ASCII path through Host Print Transform formats differently from a native twinax stream. Test every form rather than assuming the application is safe.
What network ports does IBM i printing need open?
It depends on the delivery method you choose. Raw socket printing, LPR and LPD delivery to a remote output queue, and IPDS sessions driven by Print Services Facility each use their own port, and SNMP is needed if you want status and consumable monitoring. Get your network team to open those between the host subnet and the printer subnet before the cutover window. A printer that responds to ping but never prints is almost always a firewall rule, not a printer fault.
How many printers can share one twinax port, and why does it matter?
A twinax run supports a small number of devices in a daisy chain, each with its own station address, terminated at the end of the run. That matters during migration for two reasons. First, a fault anywhere in the chain, including a missing terminator, can affect every device behind it, so partial cutovers can destabilise the printers left behind. Second, station addresses are how the host identifies each device, so your inventory needs the controller, port and address for every unit.
Is coax migration different from twinax migration?
The hardware thinking is the same but the host side differs. Coax printers attach to a 3270 control unit and receive printer sessions, so the migration target is usually TN3270E printing over TCP/IP, or an IPDS session if the output is AFP. That means logical unit definitions and session mappings have to be rebuilt on the mainframe side rather than device descriptions on an IBM i. Involve the systems programmer who owns those definitions early; it is rarely a network-only project.
Should we replace the printers at the same time we migrate?
Only where the printer is already a liability. Combining a hardware change with an attachment change doubles the variables when something prints wrong, and it makes rollback harder. If a unit is out of production, hard to get parts for, or failing regularly, replace it during the migration and accept the extra testing. If it is healthy, convert it now and replace it later on its own schedule, when you can validate forms without a cutover deadline.