Years ago I worked for a telecom as an IT shift supervisor. We had IT staff physically on the headquarters' premises 24/7. We provided support to remote telecom sites during the day, and on the night shift we took care of the maintenance and support that was easier to do when nobody was working.
Eventually one routine daily task got added to our job description: We ran batch jobs for many different applications for the business from 4 p.m. until midnight, optimizing the time when the repair staffs at the various remote sites were off-duty.
[ Also on InfoWorld: Read memorable Off the Record stories from 2009 in "Tall tales of tech -- that happen to be true." | Send your IT Off the Record story to firstname.lastname@example.org -- if we publish it, we'll send you a $50 American Express gift cheque. ]
One of these applications created work orders that resulted from customer calls to the service centers for phone repair, new installs, additional lines, configuration changes, and related work. These work orders would be compiled by the application jobs we ran and transmitted to printers at different sites throughout a five-state area late in the evening. They would then be printed out and ready when the repair staffs came to work in the morning, so they could sort through, make their assignments, and plan the day.
Since these printers were in offices that did not have any employees physically present while the print job ran, employees at the remote sites would make sure each day as they left to go home that the printers were turned on and had a good supply of paper forms. Surprisingly, we had very few problems, and it turned out to be an efficient system.
However, the occasional breakdown would occur. One site in particular became a thorn in our side for a few days.
We began getting complaints that service orders sent to the site's printer were not printing as scheduled. The orders wouldn't start printing until the staff arrived at work in the morning, and the repair staff were then having to wait until the printing was done. This was impacting their workday schedule, and if not remedied soon the telecom's bean counters would start asking serious questions about the site's productivity and bottom line.
The troubleshooting began. We checked our logs and confirmed that the printer hadn't drained for a couple of weeks. We verified on our end that the jobs were running as scheduled and the output was queued to their printer at the usual time. We ran tests against the printer to verify that the printer was working and had paper forms.
And yet the problem continued. We could see that everything was set up as it should be, but the paper wasn't actually coming out of the printer until the site's repair staff arrived in the morning. Before we resorted to spending the money to fly an IT staff member to the site, we came up with an alternative.
We worked with the site's repair staff supervisor to have someone from the repair staff agree to work a few hours' overtime and monitor the printer. As we sent the reports, the employee would be there to see what was going on.
The time came. We started the print jobs and got a call from the employee. He was laughing and jubilant: He'd discovered the problem.
It seems that each night when the custodial staff came by they would end their work by turning off the light switch and, you guessed it, the printer was plugged into an outlet controlled by the switch.
Sometimes IT solutions can be a little obtuse -- and so simple.
This story, "A tale of a troublesome printer and the low-tech solution," was originally published at InfoWorld.com.