Printing to Microplex Print Servers

Question & Answer

Question

Answer

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 Versions 4x and 5L.

Compatibility issues
Architecture and design
Configuration and printing
Configuring the print server for use
Adding an AIX queue
Management
Common troubleshooting tips

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.2
54 
```
- 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           <b>BSD </b>

     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                                                           

</pre>

</small>

<li>Press the enter key to add the print queue.

<p>

<li>Change the timeout value for the remote connection.<br>

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 <b>/usr/lib/lpd/pio/etc/piorlfb</b> and change the line:

<pre>

typeset         piorlfb_rbflags=""              # rembak flags

to

typeset         piorlfb_rbflags="-T50"              # rembak flags

</pre>

</ol>

<p>

<p>

<A NAME=remn></A>

<h4>

Setting up an AIX remote queue with no formatting</h4>

<p>

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

<p>

<ol>

<li>Start smitty with the mkpq fast path.

<pre>

  smitty mkpq

</pre>

<li>For attachment type choose <b>remote</b>.

<small>

<pre>

   ----------------------------------------------------------------

                         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

        <b>remote               Printer Attached to Remote Host</b>

        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

   ----------------------------------------------------------------

</pre>

</small>

<li>Select <b>Standard processing</b>

<p>

<li>Fill in the form with the following information<br>

<p>

The <b>HOSTNAME of remote server</b> is the host name or ip address that

you added to /etc/hosts.

<p>

The <b>Name of QUEUE on remote server</b> is

<pre>

  d1prn1       Parallel port 1

  d2prn2       Parallel port 2

  d3com1       Serial port 1

  d4com2       Serial port 2  

</pre>

The  product manual lists all default destinations possible.

<p>

The <b>TYPE of print spooler on remote server</b> is <b>BSD</b>

<p>

In AIX 4.3, set the Backend TIME OUT period to 50.

<p>

<small>

<pre>

                        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              <b>BSD </b>

  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            []

</pre>

</small>

<p>

<li>Lengthen the timeout for the remote queue.

<p>

This is most easily done by adding a -T50 flag to rembak in

the queue device stanza for the queue in /etc/qconfig

<pre>

  backend = /usr/lib/lpd/rembak -T50

</pre>

</ol>

<p>

<hr>

<p>

</P>

<H2><A NAME="7">Management</A></H2> 

<P>Microplex print servers offer the following management tools: 

</P>

<UL>

<LI><B>Telnet Session</B><P>

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.</P></LI> 

<LI><B>SNMP Support</B><P>

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. 

</P></LI> 

<LI><b>Logpaths</b> 

<ul>

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:

<p>

<ul>

<li>printer errors like out of paper, 

<li>number of pages printed in a job, 

<li>user and job IDs, 

<LI>file checksums for troubleshooting.</LI>

</UL> 

<P>

This information can then be sent to:</P> 

<UL>

<LI>a designated email address,</LI>

<LI>the SYSLOG daemon on a central Unix host,</LI>

<LI>another I/O port on the print server which has an output device  

attached,</LI>

<LI>a TCP port number where an application can gather and manipulate the  

data.</LI>

</UL></LI>

</UL>     

</UL>     

<hr>

<H2><A NAME="8">Common troubleshooting tips</A>

</H2> 

<P>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. 

</P>

<H3><A NAME="TCPIP">For TCP/IP</A></H3> 

<H3>AIX queues keep going down</H3>

This usually happens with multiple protocols.  Some of the things to

try are:

<ul>

<li>Increase the timeout for rembak

<li>Try sending the control file first

<li>Set up a JetDirect queue using the direct port on the Microplex server

</ul>

<p>

<H3>Print server won't talk on Network</H3>

<P>

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:</P>    

<UL>

<p>

<LI>Is the network cable going to the print server working? Try different 

network cables and locations to help narrow down the problem.</LI>

<p>

<LI>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.</LI>

<p>

<LI>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.</LI>

<p>

<LI>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.</LI>

<p>

<LI>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.</LI>

<p>

<LI>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.</LI> 

<p>

<LI>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?</LI> 

<p>

<LI>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.</LI>  

</UL> 

<H3>Nothing prints</H3>

<P>

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. </P> 

<P>

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:

</P> 

<UL>

<p>

<LI>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.</LI> 

<p>

<LI>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.</LI> 

<p>

<LI>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 <I>portname</I>" (for example, "start fox  prn1") followed by "stop

<I>portname</I>" (for example, "stop prn1").</LI>  

<p>

<LI>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. </LI> 

<p>

<LI>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.  </LI> 

<p>

<LI>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?</LI>

</UL> 

<H3>Stair-stepped output</H3> 

<P>

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. 

</P>

<P>

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.</P>

<P>

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".

</P> 

<p>

<B>AIX:</B> The easiest way to solve this problem in AIX is to add a

remote queue with local formatting.

<P><B>Note:</B><BR>Be careful not to double up on this carriage return 

insertion or else the output will be double-spaced.  

</P>

<H3>No formfeed or extra page comes out</H3>

<P>

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.</P>

<P>

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 

<I>modelname</I> 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.

</P> 

<p>

<B>AIX:</b> If you are getting an extra formfeed when using local formatting,

set the _Z attribute in the virtual printer to "!".

<P><B>Note:</B><BR>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. 

</P>

<H3>Garbled output</H3>

<P>

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:

</P> 

<UL><LI>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.</LI>

<p>

<B>AIX</b>: The equivalent to the FOX test in AIX is to send a test string

with

<pre>

  lptest 10 10 | qprt -P <i>queue_name</i>

This gives a test pattern line:

<FONT STYLE=FIXED>

!"#$%&'()*

"#$%&'()*+

#$%&'()*+,

$%&'()*+,-

%&'()*+,-.

&'()*+,-./

'()*+,-./0

()*+,-./01

)*+,-./012

*+,-./0123

</FONT>

</pre>

<LI>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. </LI>

</UL>

<P><B>NOTE:</B><BR>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.</P> 

<UL><LI>Are you sending a job format (for example, PCL) supported by the 

attached 

printer?</LI>  

<LI>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.</LI> 

<LI>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.</LI>

</UL>    

<!-- References -->

<p>

<!-- a 

HREF=http://www.microplex.com/microplex/support/training/print.html#UNIX>Micropl

ex Printing in Depth --> 

<!-- A 

HREF=http://www.microplex.com/microplex/support/bulletins/PRT-960607-06.html>Mic

roplex LPD Setup -->

<!-- A 

HREF=http://www.microplex.com/microplex/support/bulletins/CFG-960607-01.html -->

<!-- Print Server Configuration Methods for IP Environments-->

<!--End content -->]

[{"Product":{"code":"SWG10","label":"AIX"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Attached devices","Platform":[{"code":"PF002","label":"AIX"}],"Version":"5.3;5.2;5.1;4.3","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}},{"Product":{"code":"SWG10","label":"AIX"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Network communications","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]

Historical Number

isg1pTechnote0416

Was this topic helpful?

Document Information

Modified date:
17 June 2018

UID

isg3T1000271

Tips

Printing to Microplex Print Servers

Question & Answer

Question

Answer

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.

Historical Number

Was this topic helpful?

Document Information

UID

Share your feedback

Need support?