I have connected many a RS232 serial printer under XENIX and Unix - more than I want to remember. Flavors of UNIX that I have done this under are Microsoft XENIX, ATT Unix, and SCO Unix. Based on my personal experience with serial printing under all flavors of Unix, I only endorse printing with hardware flow control. Printing to a serial printer with software (Xon/Xoff) flow control is at best problematic. Sooner or later Unix and the printer will lose sync with each other and one side will be waiting for the other side to issue the okay to print software flow control command. If you use hardware flow control that type of deadlock will never happen. Also, with hardware flow control, the printer must be powered on and be online before any printing can occur. Never again will that important print job (packing lists) disappear, never to be seen again.

With hardware flow control, a UNIX system can print to a printer anywhere where a serial line can go. You can extend a serial line with auto-dialing modems and print to a remote location such as a warehouse or field office. With Precidia Ether 232 serial port extenders, you can put that serial printer anywhere where the internet or your WAN goes. Serial printing, once configured properly, will provide you years of excellent reliable service and you will never lose a print job because of the cabling and/or handshaking failure. If your cable breaks or the printer goes offline or gets powered off, the print job is stuck in the print queue. Most serial printers today can buffer five to ten pages, so you could lose the "printed" pages if the printer runs out of paper and is power cycled but that is a human problem and not a computer problem.

Under XENIX and SCO Unix, serial printing should be straight forward, but what should be and is are two different stories. The first problem to solve is the wiring of the RS232 serial printer to the serial port on your server. Most serial printers support DTR handshaking. The DTR line (Pin 20 on a DB25 connector) is wired to the CD, DSR, and RTS lines on the serial port of the Unix box. The DTR line on the Unix box should be wired to the CD, DSR, and RTS lines on the printer. Some printers will not print unless those signal lines are asserted. Basically we are describing the equivalent of a null modem adaptor. If you are going to use a null modem adaptor be sure your null modem adaptor adheres to the wiring as stated. We can make you RJ45 to DB9 and RJ45 to DB25 adaptors that allow you use standard 10BT cat3/cat5/cat5e cable and will allow you to connect most serial printers to Unix systems running on standard PC hardware. We can also provide adaptors that allow you to connect certain Digi-ports products to serial printers. Contact our office to inquire on pricing and availability.

On some older serial printers, the hardware flow control signal is on pin 11 and not pin 20 of the DB25 connecter. DB9 did not exist when serial printers were popular but today the Unix box you using may have a 9 pin serial port or you may have a RJ45 connector if you are using a serial ports board like a digi-ports board. Again, be sure to get your pin outs right. If you are using a serial ports board, I strongly suggest purchasing the manufactures RJ45 to DB9 DCE (or DB25 DCE) cable as a sample. Once you ring out the sample, you'll know how to make the RJ45 to DBx adaptors.

Now that you have the cable made, you need to get the printer and UNIX to speak to each other at the same baud rate, data bits, parity, and stop bits. Experience again provides guidance here. If the cable run exceeds 50 feet, keep the baud rate to 9600 baud, 8 data bits, no parity, 1 stop bit. Most serial printers are slow dot matrix printers and 9600 baud (960 CPS) far exceeds the printers print speed. Getting the serial printer configured to these parameters should be an easy read of the printer manual. Getting Unix to match gets interesting.

Earlier versions (and maybe even the latest versions) of XENIX and SCO UNIX have serious problems with serial printing. If you do not have UNIX set up correctly, your printing experience will vary. Small jobs may print perfectly. With larger jobs, you may get truncated reports (missing one or more ending characters). You could have print flow issues where the printer locks up do to a frame overrun. You may experience dropped characters or missing lines in the middle of your reports. You may loose print jobs where they just vanish. All these are fixable as long as you are using hardware flow control on your printer, the right cable, and hardware flow control on UNIX.

At first glance, when you set up a serial printer using scoadmin or sysadminsh you can provide serial settings that could and should but don't work as expected. The first thing one needs to do is to lock the printing port into the desired speed, data bits, parity, stop bits, and flow control mode. You do this by adding to or creating a system startup script that sets the serial printing port(s) operating conditions.

Under XENIX and SCO UNIX, any files in the /etc/rc.d/8 folder that are executable are run in alphanumerical order. "/etc/rc.d/8/userdef" is a preexisting file just waiting to hold your favorite startup script and is an excellent place to put the commands to lock the printing port into the desired operating mode. You can edit/create the file "/etc/rc.d/8/userdef" and add the following command:

(stty 9600 -ixon -ixoff -clocal ctsflow ;while : ;do sleep 3600; done) </dev/tty1A &

If you are creating a new script file be sure to set the execute permission with the chmod command (chmod 777 fname).

if /etc/rc.d/8/userdef does not contain any other commands, then run script /etc/rc.d/8/userdef

if /etc/rc.d/8/userdef contains other commands, then shutdown and restart the server once you notified all the users of the upcoming reboot.

The printer interface script also needs to have the proper stty setting.

My label printer has these lines as the first executable lines near the top of the printer interface script:

#! Serial or parallel printer requiring <nl> mapped to <cr><lf>
#
stty onlcr opost 9600 ixon ixany -clocal rtsflow ctsflow 0<&1

My laser printer, at one time a serial laser print on a Digi-ports product, later parallel has these lines as the first executable lines near the top of the printer interface script:

# Serial or parallel printer requiring <nl> mapped to <cr><lf>
# set tty for cts flow control (dtr from printer to cts on UNIX serial port)
#ditty fastbaud 50 onlcr opost -ixon -ixoff -clocal rtsflow ctsflow 0<&1
stty 9600 onlcr opost -ixon -ixoff -clocal rtsflow ctsflow 0<&1

My invoice printer with forms overlay required two type of stty commands: Raw and Cooked. Cooked converted <nl> to <cr><lf> whereas Raw sent to the printer the exact bytes in a data stream exactly what a forms overlay asks for. Here is the stty commands for that printer interface:

# Serial or parallel printer requiring <nl> mapped to <cr><lf>
# set tty for cts flow control (dtr from printer to cts on UNIX serial port)
cooked="stty onlcr opost -ixon -ixoff -clocal rtsflow ctsflow"
raw="stty -opost -ixon -ixoff -clocal rtsflow ctsflow"

To recap, in order for serial printing to work correctly the following must all be in place:

1. Printer configured for serial mode

2. Printer baud rate, data bits, parity, stop bits, and flow control properly configured

3. Serial cable made correctly.

4. Unix start up script nailing up serial port baud rate

5. Unix printer interface script reaffirming flow control and possible onlcr option: new line (NL) to carriage return - line feed translations.

If you skip any of these steps, your serial printing experience may not be as memorable as you would like it to be. If you have followed the above steps and are in need of additional assistance, my technical services are available for hire. Please contact my office at the contact number listed above for assistance.

Notes:

1. if the serial printer is not on tty1A then switch tty1A in the above to port you are using.

2. There is a difference between tty1a and tty1A. The capital letter device supports hardware flow control.

3. Adjust the baud rate to the desired baud rate.

4. If the serial printer is not connected and/or not powered up during system restart, the serial port servicing the serial printer may not get the baud rate nailed up at the desired speed. Be sure that all serial printers are powered up and ready to print before rebooting the server.

5. If you are using a serial ports product like Digi-ports, the stty command become ditty command.