The Line That Never Widened
Copyright© 2026 by Alexander Winston
Chapter 11: The Queue That Outlived Its Server
September 1997 through June 1998
Front Range had retired or reassigned nearly every server on its original consolidation plan. One NetWare machine still sat powered on in the corner of the operations room, its case dented from a move nobody remembered scheduling, a handwritten card taped across its drive bays: DO NOT POWER OFF — PRINT QUEUES.
Its file volumes had moved months earlier. Its directory replica hadn’t been required for longer than that. Nothing in the building depended on its processor for anything except the one job the card described. It stayed, because it owned the bank’s statement, loan, internal-report, and branch print queues, and replacing it without preserving those queues meant rebuilding rights, forms, operator assignments, client connections, and recovery procedures from scratch, by hand, across every branch in the network.
Curtis Boyd could point across the room to a UnixWare server capable of doing considerably more work than the machine wheezing in the corner. It already hosted eDirectory, NCP file services, and an NSS volume without complaint. The old NetWare box survived anyway, because the newer platform still couldn’t do this one unglamorous job in the way the bank actually expected it done, and nobody in the operations room was willing to find that out the hard way during a statement run.
The aging print server began reporting intermittent controller and disk warnings during preparation for the monthly statement run, which was the kind of ordinary bad news a Partner’s maintenance contract existed to absorb. Nothing had failed. The Partner already had a backup unit staged and a replacement plan on file. What the warning actually proved was smaller and, in its way, more useful: keeping a server alive purely because retiring it was inconvenient had quietly become a risk of its own.
“It’s not doing anything else,” Ellen Barrett said, looking at the warning log over Curtis’s shoulder. “We already moved everything that mattered onto the new system. Why can’t it just take the queues too?”
Curtis walked her over and sent a test page to a branch printer from the UnixWare server directly, using nothing but the tools that shipped with the operating system. The page printed cleanly, ordinary and unremarkable, exactly the kind of result that made the question sound like it should already be answered.
The Partner’s CNE, standing at the same terminal, didn’t dispute that the page had printed. She started listing, instead, everything a successful test page hadn’t touched: the existing directory objects describing every queue in the bank; the specific rights that let a teller print to one printer and a loan officer to another; an operator’s authority to hold a job, release it, redirect it to a different printer, or cancel it outright; the forms and printer configurations tied to particular queues; the accounting that recorded who had actually submitted a job; the workstation client behavior every branch already relied on without thinking about it; the notification a user expected when a job finished or failed; and a recoverable record of exactly what had been accepted by the server in the moments before it stopped. She could rebuild every piece of that by hand on another NetWare machine tomorrow, she said. That wouldn’t remove Front Range’s dependency on a fragile print server. It would only move it sideways.
“So we can rebuild it,” Ellen said, when the CNE finished. “On another machine exactly like the one that’s already worried about its own disk.”
“That’s the only option today,” the CNE agreed. “It’s not a solution. It’s the same dependency wearing a different asset tag.”
Ellen didn’t ask for a faster answer than that. She gave Sarah a plainer one instead: Front Range would not retire the machine until the same queues — the same names, the same rights, the same operators — could move to UnixWare without a single workstation or branch needing to be touched.
Sarah brought Front Range’s failure warning and its list of unmet requirements to Eric Langford and Priya Nandakumar, the engineer who’d spent the better part of two years keeping Novell’s print-service code aligned across NetWare’s various releases and who received the assignment with the particular satisfaction of someone finally being asked to fix a problem she’d been complaining about internally for months.
One of her own engineers opened the discussion by framing the work as translating NetWare’s queue operations into UnixWare’s existing print subsystem — a reasonable first instinct, and exactly the one Eric interrupted. “When the two disagree about what actually happened to a job,” he asked, “which one do we believe?”
Nobody had a ready answer, which was itself the point of asking. The team spent the rest of the meeting separating what customers casually called printing into four things that had been quietly bundled together for years: the directory objects that described queues, printers, operators, and rights; the proprietary Novell service that actually accepted and scheduled jobs; the local spool files and the job-state record underneath them; and the physical printer, along with whatever connection carried data to it.
eDirectory would remain the authority for identity, rights, and configuration, the same as it had for everything else the directory now governed — but it wouldn’t be asked to carry the full contents of a print job or track page-by-page state that changed a dozen times a second. Sarah asked, mostly out of habit at this point, whether anyone was tempted to let the directory hold that state anyway, just this once, since it was already sitting there governing everything else. Priya didn’t dignify it with a long answer. “The directory doesn’t need to know how many pages are left in a job any more than it needs to know how full a disk is. It needs to know who’s allowed to ask.” The print-service engine itself, running natively on UnixWare, would preserve every client operation Novell’s customers already used, over the same dual transport the network work had established the year before: TCP/IP preferred wherever a client supported it, IPX still fully honored for the older clients that didn’t. Spool storage could live on NSS where a site had it installed, or on a certified native UnixWare filesystem where it didn’t — printing would not be allowed to quietly become a function of one storage choice, any more than the directory had been. UnixWare’s own printing subsystem could supply documented device and transport interfaces underneath all of it, and nothing more; it didn’t get to define queue rights, job ownership, or how a CNE administered any of it.
Priya’s own engineer, still not entirely convinced the distinction was worth the extra work, asked what was actually wrong with letting UnixWare’s native spooler own the job once it left eDirectory’s hands. Eric’s answer was patient rather than dismissive, which was its own kind of signal that he’d expected the question. “Because the day it owns the job, it starts making decisions about rights and ownership that belong to us, whether anyone writes that down or not. We’re not borrowing a spooler. We’re building on top of one, without letting it forget which parts of the job aren’t its to decide.”
“It’s the same decision we’ve already made twice,” Eric said, without needing to spell out where. “UnixWare supplies what the host needs to supply. The licensed service supplies what the customer actually recognizes as ours.”
The first reliable build accepted jobs from existing clients, read its queue and rights straight from eDirectory, and printed correctly through days of ordinary testing, which was exactly when Priya’s team stopped trusting it and went looking for the failure that mattered.
They interrupted the connection deliberately, midway through a long multi-page statement job, and restarted the print service on a standby machine to see what came back. The service’s own journal was unambiguous: the job had been transmitted. What the printer itself could report back was considerably less unambiguous — a handful of status codes, none of which amounted to a confirmation that every page had actually landed in the output tray before the connection died.
Restarting the whole job automatically risked a duplicate statement landing on somebody’s desk, or worse, a duplicate check. Marking it complete and moving on risked the opposite — a customer’s statement missing its last page and nobody ever finding out. Neither one was an acceptable thing for the software to decide quietly on its own.
What the team built instead was a set of job states honest about exactly what the system did and didn’t know: accepted, safely spooled, released to a printer, transmission completed, printer completion confirmed where a device could actually report it, and — the state nobody had wanted to invent but every printer eventually forced them to — outcome unknown. A job that landed in that last category stopped and waited for a person, rather than being silently reprinted or silently written off. High-value queues, the ones carrying statements and checks, could require a separator page, a printed job total, a printer acknowledgment wherever the hardware supported one, and an operator’s explicit sign-off before an uncertain job was ever touched again. An ordinary office queue could run under a far looser policy — but which policy applied to which queue was something a person decided and wrote down, not something buried three layers deep in code where nobody would think to look for it.
One of the younger engineers on the team wanted to know whether a printer with a fuller status protocol could simply skip the unknown state altogether, since better hardware presumably meant better answers. Priya didn’t let the question go by unanswered. “A better printer gives you a better guess,” she said. “It doesn’t give you a printer that can see through a jam it never reported, or a connection that died between the fourth page and the fifth. We’re not building for the printer that behaves. We’re building for the one that doesn’t, on the one day it matters.”
“We’re not fixing the failure,” Priya said, watching the first job settle into outcome unknown exactly the way it was supposed to. “We’re just finally admitting when we have one.”
Compaq received the early build through the engineering relationship that had, by this point, stopped requiring any particular ceremony to hand something over. Avery’s team ran it on the same enterprise configuration already carrying eDirectory, NSS, and NCP file services in production, and put it through everything the bank’s own failure had suggested and a good deal it hadn’t: large statement and report queues under sustained load; dozens of smaller branch jobs arriving at once; the print-service process killed outright and restarted on a second certified machine; an NSS spool volume forcibly unmounted and remounted; a native UnixWare spool area torn down and restored through the documented procedure; a network printer disconnected partway through a job; and, after every one of those, a check that job ownership and operator rights had survived the recovery exactly as they’d been before it.
Compaq’s own management tools reported print-service health, queue backlog, storage consumption, and failover status through the same documented interfaces the storage work had established, without ever needing a look at Novell’s proprietary implementation to do it. Avery’s team was careful, in their own report, to draw a line Sarah appreciated seeing written down rather than assumed: redundant server hardware could preserve a queued job and everything the system knew about its state. It could not prove that a specific sheet of paper had actually passed through a printer that had stopped answering. Those were different guarantees, and nothing about better hardware collapsed the distance between them. “You can give me eight ways to keep the job alive,” Avery told Sarah on the call reporting the results, “and I still can’t give you a witness standing at the printer. That part doesn’t scale with the hardware budget.”
To read the complete story you need to be logged in:
Log In or
Register for a Free account
(Why register?)
* Allows you 3 stories to read in 24 hours.