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.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Anthony Lawrence © 2012-07-14 Anthony Lawrence