We've got this zebra bar code printer that was originally connected to the server on serial, but we had some issues with hand shaking so we connected its parallel port to a HP printer server.
Someone/thing upset the wired connection (not in the OS) today and now it doesnt print.
I can access the HP print server config page via a browser and it says that a Zebra is attached - good.
Looking at lpstat reports that it is connected to tty08 - the serial port it hasnt used for two years.
Using the network printer config confirmation within SCO ADMIN found the Zebra on port 192.168.1.105 ok the first time, but failed on the 2nd.
I know this printer doesnt have a script like other text printers so it may be tricky, running RealWorld software means product support is next to nil from the vendor.
I have cancelled jobs for this printer, disabled/enabled the printer to no avail. Are there other processes to kill/cancel?
I am guessing that the professional Unix man who set the printer up on the HP server was ok with the lpstat report so I am loathe to remove/add the printer.
So, should I backup the script in /usr/spool/lp/admins/lp/scripts (cant remember exactly), remove all traces of any existence if it is connected serially and ethernet and re-add it via SCO Admin HP printer network thingo?
I did a SCO admin course in '94 so I am a little rusty on this O/S, let alone this version.
Thanks in advance,
JohnW
unconfigure it altogether, then use netcat!
I also have a Zebra label printer hooked to an SCO OpenServer 6 system, and can't get it to work I ALSO run Realworld. So, I am very curious as to how you fixed this problem, and look forward to reading on this forum. I know this is against the rules, 
but since you use Unix AND Realworld, you are a very scarce bird. Would appreciate a call so we can collaborate on the Realworld issues at 1-800-900-7224. Look forward to your call.
And to the Administrators...thanks for letting me get away with this on the Realworld issue...
Okey Dokey,
First up, I originally posted the question on my way out the door going home. Being in Australia, I thought the "brains trust" on the other side of the world could help me overnight.
Expecting the worst the next day with questions from the users about why the printer doesnt work - never came, the printer "fixed" itself overnight with no further problems since.
The Zebra is a strange beast, something that earns my respect.
I'm not sure whether this is a new install or a existing unit gone bad so this is what I'd do....
Install the printer on a "Windose" machine via Parallel and check that it actually works, these things do happen.
Then I'd check if it works via ethernet or serial. This clears any issues with conflicting IP address's. You will have to make a serial cable from scratch from the pc to the printer. The manual has examples of the wiring maps.
If you are going to connect the printer using a 8/16 port expansion board on the server, you are on your own. We had handshaking issues for years before we finally put the printer on a HP ethernet print server.
Last year, I asked the original vendor (who supplied the whole system 9 years ago) about installing a second Zebra - they refused with the reason that enhancements are not available.
It was then we heard that our "days are numbered" with Real World - apparently MS purchased the company and retired the product, thus forcing existing customers onto the MS server upgrade treadmill. Really annoys me - the system wasnt cheap to setup, its bullet proof on Unix and perfectly fits our needs.
Sorry I cant help anymore.
HP Print servers can be funny sometimes, usually because the printer went offline because of being out of paper (in this case labels) or jamming. The print server sends a message back to the Unix queue to stop the queue, but when the printer comes back on line, it never re-starts the unix queue.
Sometimes, if you wait long enough, the HP print server and the Unix queue will eventually sort them selves out and start printing again (which is what is sounds like happened). There are two other tricks I've found. Cancel the first job waiting to print, which means the second job query's the HP printserver and finds that it is on line and the queue starts printing again. Another thing to try is to shut down the lp print spooler on unix. /usr/spool/lpshut (stops the lp print spooler and all printing on the unix box is stopped, except for printers using rlp) and then /usr/spool/lpsched to restart the lp print spooler.
A Unix printer setup with rlp behaves a bit different, sometimes the queue never get's cleared, and the way to clear that queue is to kill the rlp print spooler on the Unix box, and restart it, or reboot the server.
Now, the guy who mentioned netcat, although not very helpfull for your problem is correct in a way. The Netcat program is very robust and stable. Getting it going to not hard, you can find very good instructions at the A.P. Lawrence website (aplawrence.com).