The last time I saw a SCO 3.2v4.2 system was the summer of 2004, but another peeked out of the bushes this week.
This was at a hotel; apparently formerly a Bass Hotel but now owned by another firm. Their system printer stopped working, they brought someone in to look at it, he worked at it with a printer repair person from IBM, but no luck. They found me on the web and after an hour of getting nowhere (half an hour of which was spent finding someone who knew root’s password), I gave up trying to help by phone and decided it was easier to drive up to where it lived – fortunately only 50 miles away.
When I arrived, I was able to fairly quickly identify the first problem: “lpstat -v” showed me that the printer was using /dev/tty66 on the Digiboard serial multiport, but in fact was plugged into /dev/tty67. The consultant that was still there suggested that the IBM person might have done that, no doubt mistakenly thinking that a multiport box is a bus rather than individual serial devices.
On the other hand, the IBM Laser printer was not able to even print a test page, so it didn’t really matter where it was plugged in. The other consultant had already reached that conclusion without my help, and had scrounged an HP LaserJet with a serial interface. He had set it all up correctly as to baud and flow control, but we couldn’t get it to print. I hooked up my old Radio Shack RS232 tester (when was the last time I used THAT, I wonder) and showed him why: both the cable from the printer and the cable from the Digi were acting as DCE devices (see Serial Printers for more on that. That wasn’t going to work very well, but magically he popped up with a DTE wired RJ45-DB25 adaptor – good thing; I used to carry all that stuff in my car but those days are long gone. We swapped the adaptors and now my tester showed the right lights and indeed I could send print jobs. OK so far, right?
Ummm, not quite. The printer wouldn’t eject a page. We always had to press “Go” twice to get it to feed paper and print. It all looked right in the setup menus, but somehow it was convinced something was confused in the trays. We asked where this printer had come from.. the unsurprising answer was that it had never been used in anyone’s memory – it had just been sitting in a closet for years. Well, maybe its confusion about paper was why.
After a brief discussion with the manager, we decided to go out and buy a new printer. I didn’t think there was much chance of finding a serial port option board at the local Compusa or Staples, and of course that was true. So we brought back a LaserJet 1320 instead and I hooked it up to the parallel port. This would necessitate users traveling a few more feet to pick up their print jobs, but they felt this was fine, especially as the whole system would be replaced within six weeks. They could live with a new location until they got the new system.
So, I issued the lpadmin command to change the device to parallel: “/usr/lib/lpadmin -p lp_printer_1 -v /dev/lp0”. We ran a few test jobs and immediately realized another problem: the default font needed to be 16.7, it needed 8 lines per inch and 66 lines per page. Those had apparently been programmed into the front panel of the IBM, but the 1320 is too consumerish to have a front panel menu. So back to lpadmin: “/usr/lib/lpadmin -p lp_printer_1 -m HPLaserJet”. I then edited the /usr/spool/lp/admins/lp/interfaces/lp_printer_1 file to set the needed defaults.
We had the users print out several different reports and they reported satisfactory results. Total time: 2.5 hours plus travel, which is a ridiculously long time but considering the switched wiring, the wrong adaptor and the final need to buy a new printer, I guess it’s not too outrageous.
So will this be the very last SCO 3.2v4.2 system I see? Who knows..only time will tell.
*Originally published at APLawrence.com
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
