Printing to Microplex Print Servers

About This Document
Compatibility Issues
Architecture and Design
Configuration and Printing
Configuring the Print Server For Use
Adding an AIX Queue
Management
Common Troubleshooting Tips

About This Document

This document describes how to set up a Microplex print server from AIX and how to add AIX print queues to print to the attached printers.

This document applies to AIX 4.1 and above.

Compatibility Issues

Network Protocols

Microplex's current print server models support multiple environments simultaneously, including:

TCP/IP
- all Unix operating systems
- PCs, Macs, minis, and mainframes running a third party TCP stack
- PCs running Windows NT
NetBIOS over TCP/IP
- PCs running Windows 95 or Windows for Workgroups
IPX
- Novell NetWare 3.x
- Novell NetWare 4.x in bindery emulation mode with NDS support coming soon
EtherTalk
- Macintosh computers running EtherTalk

All printers containing a serial port or a standard Centronics interface will be supported by the Microplex print server line. This means 10-year old printers to the latest high-speed printers on the market today are supported as long as they have a serial or Centronics interface. This is the only compatibility requirement.

Job Types and Sizes

The type and size of a print job never matters to the Microplex print servers. The print server takes a few bytes at a time, passing them off to the attached printer, and never cares what type of data it is or how big the overall file is. However, the print server can be told to look at the type of data if something like ASCII to PostScript conversion or automatic emulation switching (for example, PCL to PostScript) is turned on.

Architecture and Design

Physical Design

The key parts of a Microplex print server's physical design are:

a network connector to attach itself and the printer(s) to the network,
a serial or parallel I/O port to attach the printer to,
flash PROM to store the firmware code,
EEPROM to store configurable settings,
RAM to help with print job and network communication processing.

Logical Design

Print path

When a print job comes through the print server, there's a certain logical print path it follows before it gets to the attached printer. It's not as simple as saying the job goes directly to the I/O port; it must first go through a sequence of logical steps in case there's any extra processing to be done to the data.

The overall print path for a print job going to a Microplex print server is:

Phase 1 - The host sends the job to a pre-defined destination/queue on the print server (for example, destination "d1prn1").
Phase 2 - The job passes through the associated model (for example, model "m1") on the print server for any extra processing, through the associated logpath (for example, logpath "l1") for any print job or printer logging, and then goes to the associated I/O port (for example, PRN1) with the printer attached.
Phase 3 - The data goes from the print server's I/O port (for example, PRN1) to the attached printer for output.

Note:
Most print methods direct print jobs to the destination/queue in the initial print setup, but in some cases, the print job can be sent directly to the I/O port. However, every single job that comes to the print server (no matter whether it's directed to a destination/queue or an I/O port) will still find its way through the associated models and logpaths.

Destinations/Queues

For every I/O port on the print server, there is at least one pre-defined logical print queue or destination to accept print jobs destined for it. This is where print jobs get sent to with most print methods offered. For example, if there was a printer attached to the COM1 port, the print jobs might be sent to a pre-defined destination called "d3com1" in the print setup rather than to the I/O port, COM1, directly. These logical queues or destinations are pre-defined by Microplex but the names can be changed.

Models

For every pre-defined destination/queue on the print server, there is a pre-defined associated model which defines how the print job will be processed as it passes through to the printer. Models are like a set of mini filters that add something to the data to change or help the printer output. In most cases, the print server will not touch the data, but there are special circumstances when extra processing may be desired. For example, maybe the printer needs to output the data in two-sided landscape form or maybe the ASCII data coming through needs to be converted to PostScript for the attached PostScript printer. It is within the models that these options get set. Once again, the models are pre-defined by Microplex but can be changed.

Logpaths

With every destination comes a pre-defined logpath as well which determines what type of print job and printer logging will be done by the print server for a given I/O port. These too are pre-defined by Microplex but can be changed.

Built-in Command Shell (npsh)

Within each Microplex print server, a command shell is built in to the firmware. It's called "npsh" and allows manipulation of objects like destinations, models, and logpaths. It also provides some viewing capabilities for monitoring print queues and I/O ports.

These methods can be used to access "npsh":

Telnet session (for example, "telnet printserverIPaddress" - "telnet 192.1.1.1"),
serial port login (that is, terminal or laptop off COM port),
npsh.exe Novell executable (for example, "npsh printservername" - "npsh M_001C1A"),
NPWin Windows software.

When commands are referred to within this document or within the product manual, these are commands executed once logged into "npsh". The four main command prefixes within "npsh" are:

store - change settings stored in EEPROM only
set - change current/working settings only
list - view current/working settings only
debug - view certain debugging information

Note:
If the "store" command is used, the print server must be repowered to make the changes take effect. If the "set" command is used, a "save" command must be done so the settings are retained after power cycles. However, a reset is not necessary since the changes take effect immediately.

Print Job Spooling and Queueing

Microplex print servers can support up to four printers simultaneously while supporting multiple hosts and network protocols. They are smart enough to queue up jobs for every I/O port based on a first come, first serve algorithm and they have the ability to manage all of this queueing for every I/O port.

At any given time, the print servers will only hold approximately 3000 to 4000 bytes per I/O port. This means the majority of the print job's data will reside on the host, and through standard flow control methods, the data will quickly pass over to the print server's buffers on to the printer's. Though the print server only holds a few kilobytes per I/O port, it is not the bottleneck in the print path. The printer is always the bottleneck and comes down to its I/O port speed and its buffer size.

Configuration and Printing

Configuration Tools

The following tools are available for Microplex print server configuration:

NPWin - software for Windows stations running IP
EZSETUP - Non-AIX Unix shell script that configures print server and host's print setup
npsh.exe - Novell executable that provides way to access built-in command shell on device

Configuration Steps

To use a Microplex print server, the basic configuration steps are:

Attach the print server to the network, attach printers, and power up the devices.
Configure the print server with its network settings if needed.
Configure AIX remote queue to print to the print server.

Attaching to the Network

These steps are necessary to attach Microplex print servers to the network:

Plug in the network connection.
Attach peripherals to the appropriate I/O ports and power them up.
Plug in the print server's power supply and watch the power-on self test cycle through. When this test is complete, the POWER LED should be on and STAT should be flashing.

Configuring the Print Server For Use

TCP/IP - AIX Setup

Environment Description - AIX at any level will work. AIX 4.1 and above provide local data formatting.

Requirements for Use - IP address and subnet mask configured on the print server at the minimum and a print setup on Unix host saying where to print to on the print server

Configuration Methods - Manual "arp -s" command, RARP, and BOOTP

Print Method Options - LPD, RSHD (that is, remote shell command for System V printing), FTP, and direct socket printing through a proprietary Microplex binary like NPD or NPWRITE or through a custom application The AIX JetDirect support backend should also work for the socket printing, but has not been tested at this time.

The steps to do this are:

Add the Microplex unit's host name and IP address to the DNS or /etc/hosts.
Find the Ethernet address for the Microplex print server on the bottom of the device. It must be entered as part of this process.

Adding the Microplex unit and IP address
- Use the "arp" command to add an entry for this print server into the PC's ARP table.
```
arp -s printserverIPaddress printserverEthernetaddress
ping printserverIPaddress
```
  Example:
```
arp -s 192.1.1.12 00:80:72:00:1c:1a temp
ping 192.1.1.12
```
- Add the microplex unit to the /etc/bootptab file. This should all be placed on one line:
```
  west4247:ht=tr:ha=000231C80061:ip=192.36.253.96:sm=255.255.255.0:gw=192.36.353.254 
```
- If bootpd is running refresh -s inted.
- If bootpd has not been enabled, remove the # from the bootp line in /etc/inetd.conf and refresh -s inetd.
telnet to the print server's IP address
```
telnet printserverIPaddress
```
Log in to the print server as root.

At the password prompt, press ENTER since there is no password set by default.

At the prompt that displays (that is, "ipaddress:root"), store the IP address and subnet mask into EEPROM on the print server so that it can remember its IP settings after power cycles. The possible commands are:
```
store net ifnum addr IPaddress
store net ifnum mask subnetmask
```
or:
```
store net ip IPaddress
store net mask subnetmask
```
Note: ifnum is the index to a network interface on the print server. With all print server models except the M204, this will always be the number "1". On the M204, however, this number will depend on which slot is used for the PCMCIA card. The slot numbers are labeled on the print server for easy identification.
Verify the IP address and subnet mask stored in EEPROM on the print server.
```
list stored net
```
Exit the Telnet session with "quit" and repower the print server by unplugging and plugging in the power supply.

Wait 30 seconds and then try to telnet back to the print server's IP address from this PC.
```
telnet printserverIPaddress
```
At this point, the print server can be seen on the network. Now a print setup must be configured on this PC to print to a printer off of the print server.

Adding an AIX Queue

You will add a remote queue with local formatting when you do not want to change the settings on the printer, or when the data has already been formatted such as when AIX is acting as a print server for a PC. These instructions assume AIX 4, but similar queues can be setup at AIX 3. Set up the remote queue as follow:

When asked for a "remote queue", choose one of the pre-defined destinations/queues on the print server. For example, some default M202/M212 destinations include "d1prn1", "d2prn2", "d3com1", and "d4com2". The product manual lists all default destinations possible.

Setting up an AIX remote queue with local formatting.

A remote queue with local formatting can be used when you want control of the printer trays, pitch size, page orientation, and other factors determined by an AIX virtual printer and the qprt print command including header pages.

To add a remote queue with local formatting follow these steps:

Start smitty with the mkpq fast path.
```
  smitty mkpq
```

For attachment type choose remote.

   ----------------------------------------------------------------
                         Add a Print Queue
  Move cursor to desired item and press Enter.  Use arrow keys to scroll.
     #  ATTACHMENT TYPE      DESCRIPTION
        local                Printer Attached to Local Host
        remote               Printer Attached to Remote Host
        ascii                Printer Attached to ASCII Terminal
        hpJetDirect          Network Printer (HP JetDirect)
        file                 File (in /dev directory)
        ibmNetPrinter        IBM Network Printer\
        other                User Defined Backend
  F1=Help                 F2=Refresh              F3=Cancel
  8=Image                F10=Exit                Enter=Do
  /=Find                  n=Find Next
   ----------------------------------------------------------------

For type of remote printing choose local formatting.

                           Type of Remote Printing
   Move cursor to desired item and press Enter.
     Standard processing
     Standard with NFS access to server print queue attributes
     Local filtering before sending to print server

Choose the manufacturer and printer type

Fill in the new print queue name and remote server characteristics.

The HOSTNAME of remote server is the host name or ip address that you added to /etc/hosts.

The Name of QUEUE on remote server is

  d1prn1       Parallel port 1
  d2prn2       Parallel port 2
  d3com1       Serial port 1
  d4com2       Serial port 2

The product manual lists all default destinations possible.

The TYPE of print spooler on remote server is BSD

In AIX 4.3 set the Backend TIME OUT period to 50

For example:

                  Add a Remote Print Queue with Local Filtering
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
                                                        [Entry Fields]
  Description                                         Lexmark Optra E laser p>
* Name of new PRINT QUEUE to add                     [laser4+B]
  Remote server characteristics
*    HOSTNAME of remote server                       [netport1]
*    Name of QUEUE on remote server                  [c1prn1]
     TYPE of print spooler on remote server           BSD 
     Send PASS-THROUGH FLAG to queue                  yes                      +
        on remote server?
  Backend TIME OUT period (minutes)                  [50]                        #
  Send control file first?                            no                      +
  To turn on debugging, specify output               []                       
      file pathname

Press the enter key to add the print queue.
Change the timeout value for the remote connection.
This is necessary because the AIX connection will time out if some other server is printing to the NetportExpress while AIX attempts to print. This will cause the queue to go down. To set this value for a remote queue with local formatting, edit the file /usr/lib/lpd/pio/etc/piorlfb and change the line:
typeset piorlfb_rbflags="" # rembak flags to typeset piorlfb_rbflags="-T50" # rembak flags

Setting up an AIX remote queue with no formatting

To add a remote queue with no formatting follow these steps:

Start smitty with the mkpq fast path.
smitty mkpq

For attachment type choose remote.
---------------------------------------------------------------- Add a Print Queue Move cursor to desired item and press Enter. Use arrow keys to scroll. # ATTACHMENT TYPE DESCRIPTION local Printer Attached to Local Host remote Printer Attached to Remote Host ascii Printer Attached to ASCII Terminal hpJetDirect Network Printer (HP JetDirect) file File (in /dev directory) ibmNetPrinter IBM Network Printer\ other User Defined Backend F1=Help F2=Refresh F3=Cancel 8=Image F10=Exit Enter=Do /=Find n=Find Next ----------------------------------------------------------------

Select Standard processing

Fill in the form with the following information

The HOSTNAME of remote server is the host name or ip address that you added to /etc/hosts.
The Name of QUEUE on remote server is
d1prn1 Parallel port 1 d2prn2 Parallel port 2 d3com1 Serial port 1 d4com2 Serial port 2
The product manual lists all default destinations possible.
The TYPE of print spooler on remote server is BSD
In AIX 4.3, set the Backend TIME OUT period to 50.

Add a Standard Remote Print Queue Type or select values in entry fields. Press Enter AFTER making all desired changes. [Entry Fields] * Name of QUEUE to add [laser5] * HOSTNAME of remote server [netprt2] * Name of QUEUE on remote server [d1prn2] TYPE of print spooler on remote server BSD Backend TIME OUT period (minutes) [50] in AIX 4.3 Send control file first? no + To turn on debugging, specify output [] file pathname DESCRIPTION of printer on remote server []

Lengthen the timeout for the remote queue.
This is most easily done by adding a -T50 flag to rembak in the queue device stanza for the queue in /etc/qconfig
backend = /usr/lib/lpd/rembak -T50

Management

Microplex print servers offer the following management tools:

Telnet Session
Within TCP/IP environments, all Microplex print servers support Telnet sessions from anywhere on the network. By telnetting into the print server and logging in as a root or guest user, you can monitor job status and printer status. For example, the command "lpstat" shows activity on the I/O ports at a given time and displays the status of the printer at that moment. Back to back "lpstat" commands will show a print job as it passes through the print server to the printer.

SNMP Support
Microplex print servers are all MIB II compliant but they also have their own custom MIB support. This custom MIB includes all possible configuration settings on the print server (for example, destinations, ports, models) and supports traps. For example, when the printer status changes on a specified I/O port, a trap can be sent back to the SNMP Manager or when the print server is reset for some reason, a trap can be sent.

Logpaths
With every pre-defined destination on the Microplex print servers comes an associated logpath. This explains what type of printer logging is to be done and where the log information is to be sent. Some possible types of information that can be logged are:

printer errors like out of paper,
number of pages printed in a job,
user and job IDs,
file checksums for troubleshooting.

This information can then be sent to:

a designated email address,

the SYSLOG daemon on a central Unix host,

another I/O port on the print server which has an output device attached,

a TCP port number where an application can gather and manipulate the data.

Common Troubleshooting Tips

These are some of the most common problems reported with Microplex print servers. For each problem, a description is given along with steps to solve the problem.

For TCP/IP

AIX queues keep going down
This usually happens with multiple protocols. Some of the things to try are:

Increase the timeout for rembak
Try sending the control file first
Set up a JetDirect queue using the direct port on the Microplex server

Print Server Won't Talk on Network

Sometimes the print server won't communicate over the network from the beginning or it will suddenly stop communicating after working for a while. In these cases, customers most often think something has gone wrong with the device, meaning an RMA is needed, but 75% of the time the problem is related to configuration or network problems. Therefore, the things to check when this happens are:

Is the network cable going to the print server working? Try different network cables and locations to help narrow down the problem.

Has another network connector on the print server been tried to help narrow down the problem to a particular print server network port? A transceiver would be needed to try this other port.

Has there been a change to the network recently that might affect this print server's communications? For example, on a TCP/IP network, a new device added to the network could be accidentally using the same IP address as the print server.

Has there been a change to the device itself? For example, maybe the device has been moved to a new location or maybe somebody has changed a key network setting.

If this is a brand new installation, is it confirmed that the network station trying to talk to the print server resides on the same subnet? At first, the print server can only be seen on its own subnet until it can later be told about a default router/gateway.

Is there a RARP or BOOTP server running on the network? If so, the print server will send out a RARP and BOOTP request by default upon bootup, so even if the network settings have been stored in EEPROM, the device may gain a new IP address from one of these servers. RARP and BOOTP can be turned off within the print server though using the "store net" command prefix. Simply type this in once you are logged in to the print server's command shell, npsh, and, looking at the output that displays, use the command referring to RARP and BOOTP.

Has a special event taken place such as a lightning storm or power surge? If so, did other equipment on the network get affected as well? Is there anything different about the LED pattern on the front of the device (for example, ERR LED comes on) after waiting 30 seconds after bootup?

Has the print server been put back to a factory default mode by using the appropriate jumper on the device's board? Sometimes setting things back to square one and then redoing the network setting configuration helps kick things into gear.

Nothing Prints

Most often when nothing prints, the problem is with the configuration, whether it be the host configuration or the print server configuration. Rarely is it a problem with the hardware (for example, I/O port interface) unless it's the printer cable or printer itself having troubles.

What's important to find out with this problem is where exactly the print job is faltering. Therefore, start with the basics (that is, take the network right out of the picture) and work backwards towards the host end. The steps to consider when this happens are:

Is it still possible to communicate with the print server over the network? If not, printing will obviously be affected so look for reasons why communications have stopped.

Is there a working printer attached to the print server I/O port that is ready to go and not in an error state? Use the "lpstat" command within the print server's command shell, npsh, to see whether or not the print server's I/O port recognizes that attached printer.

Are the printer and printer cable okay? To test this hardware, use the FOX test built in to the print server's command shell, npsh. This sends an ASCII line over and over again to the attached printer, ruling out the network side of things completely. The most common command syntax for this FOX test is "start fox portname" (for example, "start fox prn1") followed by "stop portname" (for example, "stop prn1").

Is the job leaving the host and getting to the print server? Once again, use "lpstat" on the print server to see if the job registers on the appropriate I/O port or simply check the host queue to see if the job gets stuck there. If it is stuck on the host, the problem is the spooler configuration most likely unless the print server can't be communicated with over the network.

Is the job format or type (for example, text, PostScript) being sent supported by the attached printer? For example, sending a text job to a PostScript printer will not produce any output. The printer will choke on this since it is not PostScript code.

Is it only certain jobs that are failing? For example, maybe a particular application's jobs aren't printing but other jobs are. If that's the case, then look at this application's print output to make sure it matches the printer's emulation (for example, PostScript) and also look closer at its print configuration. Is the job able to get from the application to the right print setup on the host where it can then be sent to the print server?

Stair-Stepped Output

This refers to any Unix output that starts on the top left of the page but, in every line thereafter, starts a little more over to the right rather than coming back properly to the left margin. It also refers to Unix jobs that print one line at the top of the page but then follow that with blank pages rather than the rest of the job.

The reason for this odd output is the lack of carriage returns in the job. The printer may be told to do a linefeed, but this may not be followed by a carriage return to start the next line at the left margin. Therefore, the printer does a linefeed but then starts the next line where the previous line left off.

This should only happen with Unix text jobs and to avoid this, some type of carriage return insertion must be added in the print path. The easiest and most common location is on the print server itself within the appropriate model. The feature is called "onlcr", and to see the correct command on the device to set this on or off, enter "set model" once logged in. Then pick the command referring to "onlcr".

AIX: The easiest way to solve this problem in AIX is to add a remote queue with local formatting.
Note:
Be careful not to double up on this carriage return insertion or else the output will be double-spaced.

No Formfeed or Extra Page Comes Out

Unix text jobs may also have problems kicking the last page of the print job out of the printer, especially if the LPD print method is used. This means the formfeed button has to be pressed right on the printer to get this last page out.

To make this process automatic, tell the print server to handle the manual formfeed by setting this feature on in the appropriate model. The command structure on the print server is "set model modelname trailer $FF" (for example, "set model m1 trailer $FF"). The "$FF" is a pre-defined variable on the print server which equals the proper hexadecimal code for a formfeed.

AIX: If you are getting an extra formfeed when using local formatting, set the _Z attribute in the virtual printer to "!".
Note:
Be careful not to double up on the formfeed or else the job will eject properly but with an extra blank page at the very end.

Garbled Output

Garbled data means any output that does not look as it should. This can range from missing or overlapping characters to odd spacing. Most often it is caused by some extra unwanted processing done to the job as it passes through its print path or else it may be related to the hardware involved. No matter what, 99% of the time it is fixable without having to bring a print server back for repair. Therefore, the things to consider if this happens are:

Has a basic test like the FOX test been tried to confirm that basic communications between the print server and the printer are okay? Narrowing down the problem is the most important step in trying to determine where the garbling is happening, and the FOX test concentrates solely on the print server's I/O port, the cable, the printer, and the communications between the print server and the printer. The network and host are not brought into the picture at all. This way if the data garbles here, the problem is definitely hardware related.

AIX: The equivalent to the FOX test in AIX is to send a test string with
lptest 10 10 | qprt -P queue_name This gives a test pattern line: !"#$%&'()* "#$%&'()*+ #$%&'()*+, $%&'()*+,- %&'()*+,-. &'()*+,-./ '()*+,-./0 ()*+,-./01 )*+,-./012 *+,-./0123

Has the printer output ever been proper with this setup? If not, there's a configuration error or the data is getting processed on its way to the print server for printing. If it did work at one point and then started garbling, something might be failing like the printer cable or the flow control between the print server's I/O port and the printer. The FOX test will help with this. In addition, maybe somebody turned on some extra processing somewhere (for example, onlcr) along the print path which these print jobs don't like. This would most likely be turned on at the print server in a destination's model.

Note:
The most common extra processing that causes garbling is onlcr which provides carriage return insertion for Unix text jobs. This tends to garble any jobs coming from non-Unix hosts so be sure to have this off with any non-Unix printing. If printing from both PCs and Unix hosts is needed, two separate setups are recommended: one with onlcr on and one with it off.

Are you sending a job format (for example, PCL) supported by the attached printer?

Is the data leaving the host in a proper format or is it getting garbled before leaving the host? Sometimes capturing the job to a file first and then viewing this file can help tell where the garbling is occurring.

Is there an old firmware version inside the print server? There are some versions that have I/O port bugs which garble output, so it's recommended that the latest firmware version be used. Please contact Microplex Technical Support for further help with this or feel free to check out the "Support Shack" at Microplex's Web site for the latest firmware code and instructions.

[ Doc Ref: 92031909613832 Publish Date: Mar. 29, 2001]

Printing to Microplex Print Servers

Contents

About This Document

Compatibility Issues

Network Protocols

Printers

Job Types and Sizes

Architecture and Design

Physical Design

Logical Design

Print path

Destinations/Queues

Models

Logpaths

Built-in Command Shell (npsh)

Print Job Spooling and Queueing

Configuration and Printing

Configuration Tools

Configuration Steps

Attaching to the Network

Configuring the Print Server For Use

TCP/IP - AIX Setup

Adding an AIX Queue

Setting up an AIX remote queue with local formatting.

Setting up an AIX remote queue with no formatting

Management

Common Troubleshooting Tips

For TCP/IP

AIX queues keep going down

Print Server Won't Talk on Network

Nothing Prints

Stair-Stepped Output

No Formfeed or Extra Page Comes Out

Garbled Output