APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Printers Down


I had a call from an old SCO Unix customer this week. There aren't many of those old systems left now - more than you'd probably think, more than there should be, but far less than there were just a few years back. I think you still have a good chance of finding a few SCO boxes in any city, but it's getting harder..

Anyway, this customer called because two printers were not working. I hadn't seen him in several years (that's the nice thing about these systems: they do run and run and run without attention) but I did remember that he had serial printers. I couldn't remember much else so after a small attempt at trying to help him out by phone, we decided I had better drive down to see the situation first hand.

When I walked in this morning, some memories flooded back. First of all I could see that a Digiboard C/Con handled the serial ports and the screen display on one of the Windows boxes reminded me that this was a custom point of sale app that I had never seen or even heard of before or since. I remembered that we'd had some trouble with that before but as this was just printers I didn't think that would be an issue today.

So, to the printers. Which ones didn't work? My customer pointed at an HP Laser. I logged in and did an "lpstat -v" and saw that printer was defined on /dev/ttya12 and that no other printers were defined at all. Oh, yeah: more memories: the app prints directly to device ports. So, what's wrong with ttya12?

Nothing, as it turns out. I could see the back end of the laser from where I stood and the only thing plugged into it was a parallel cable. Hmmm.. I walked closer and saw that a tangle of cables came down from the ceiling. My bet was that we'd find a serial adaptor at the end of one of them and sure enough, after fishing around under the desks, we found it, plugged it in and printing to the laser printer worked yet again. That was easy.

Next? An Oki 3410. I got my tone generator from the car and traced it back to ttya11. I tried "date > /dev/ttya11" and the printer spit out a line of garbage. Baud rate wrong? Nope, but when I did the config test page I noticed more was wrong: the printing started mid page. That's not a system problem, that's a printer hardware issue. "That's OK", said my customer, "I have another". And so he did. So I pulled the serial card from the old printer and put it in the new. Unfortunately the printer still spewed garbage.

Bad serial card? Nope, I moved it to ttya13 and that "date" printed fine. So it's the Digi acting up at ttya11. Now what? We can't change the app because no one knows how. I remembered having pawed through its menus before and never finding the magic printer configuration page.. looks like we're out of luck, have to buy a new Digi..

Don't be silly. This is Unix. I added the following to an rc.d startup file:

rm /dev/ttya11
ln /dev/ttya13 /dev/ttya11

That's all it takes. The app opens ttya11, but that's actually ttya13. This is a 16 port Digi supporting only three printers: it will have to lose a lot more ports before we need to replace it. Why waste money on a system that is unlikely to remain in use much longer?

As I packed up to leave, I reminded my customer that he is living on borrowed time. Someday he will have a crash or problem that I cannot fix so easily. It's way past time to move to some other POS application. He agreed and promised to look into it.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Fixing an Ancient Unix system with two dead printers


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Thu Sep 18 19:28:04 2008: 4566   BruceGarlock

Funny, I had to do the same thing when I was in a similar situation before. The app. printed directly to the port, and one of the digi ports went bad, so I made a symlink, so that the app. did not have to be re-coded. When I write code, I like to have things like ports be a variable that can be easily changed by anyone, but that's a whole other story :-)

I am in the process of putting all my "tricks" like this into documentation so that other people will be able to follow some of the "tricks" I have had to do over the years. In a case like this, Tony, what do you do to document what changes you make on a system? I have been in the habit of making a README in the / of any system, and have that point out the most important stuff about the server. What do you, or anyone else here, do for documentation? Sure some of it could easily be followed if you do enough detective work, but I like to document whenever I have to put something into any of the /usr/local dirs, or anything that has been changed from the base OS install.

What does everyone else around here do for documentation? Do you follow any specific templates for each server? The person I report to wanted to know if there was a standard for documentation, and of course there really isn't. I am trying to develop our own in-house "standard", so that each server will have the same look as far as the documents go.

-- Bruce Garlock

Thu Sep 18 19:31:53 2008: 4567   TonyLawrence

I have done README files, but it's probably pointless: the "Windows" guy who follows me in some day isn't even going to know how to log in, never mind read that file.

Fri Sep 19 10:54:44 2008: 4572   Simplicissimus

Was this an OpenServer box or UnixWare? OpenServer, if memory serves, rebuilds the /dev directory at reboot time. The serial card may be in charge of enumerating the ports. The kernel would then map the port indices to device major/minor numbers and recreate /dev/tty11 as it was before. You're safer to just reconfigure the printer to use /dev/tty13. I'm going back about 13 years, though. Might not be an issue at all.
OpenServer 5.x also generates a new /etc/inittab from a config file at boot time so you lose all of your edits. This I do know. With SCO machines, I always found it wise to boot the box and retest the fix if possible.

Fri Sep 19 12:34:54 2008: 4574   TonyLawrence

No, you are thinking of Unixware but it doesn't matter anyway: the rm and ln are done in the rc.d scripts long after any recreation of device files. It wouldn't matter if this were OSR5, Unixware, BSD or a modern Linux.

Fri Sep 19 12:39:51 2008: 4575   TonyLawrence

By the way, OSR5 does NOT generate a new inittab at boot. That happens at kernel rebuild, IF you answer Y to "Do you want the kernel environment rebuilt".

But you shouldn't edit inittab without editing the files in /etc/conf/init.d anyway.

Fri Sep 19 13:09:20 2008: 4576   anonymous

After reading this, I'm twitching a little bit.

I spent a year doing 24x7 level 3 for 2500+ distributed 5.0.5 and 5.0.7 boxes with multiple Digi's each.

Needless to say, that's what finally drove me in to management.

Fri Sep 19 13:39:18 2008: 4577   anonymous

I hate digiports! When we first moved off DG-UX to RH6 we needed a digport for our serial printers. I ended up chucking the digiport and using a cisco router w/16 serial async ports instead. Much easier than dealing w/digiport bs.

Fri Sep 19 14:15:02 2008: 4579   TonyLawrence

Digport bs??

Digi makes an excellent, reliable product.

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

I'm sure the universe is full of intelligent life. It's just been too intelligent to come here. (Arthur C. Clarke)

A crowded police docket is the surest of all signs that trade is brisk and money plenty. (Mark Twain)

This post tagged: