• (cs)

    A well-written, enjoyable story.

    I like this line:

    ...with about as much memory as a goldfish.
  • David (unregistered)

    Sometimes, every once in a while, the ingenuity and pragmatism of the average user makes me smile.

  • iceland (unregistered)

    Ok, so it was printing a failed job from 1984? So if they let it run its coarse once, the problem should go away?
    Or did the mainframe team stop at having the great idea of a printer backup (on another physical location?? TRWTF?). Leaving out the bit where the job would then be removed instead of printed over and over again?

  • phi (unregistered)

    I am not a native english speaker, so I can't figure if this was intended : Matt worked helLdesk at an assembly plant

    either way, i like this one.

  • Spudley (unregistered)

    It's been a long while since I worked on a system that printed cheques (or 'checks' for the Americans), but one thing I remember vividly from those days was that misprinting cheques was a sin capable of bringing down the wrath of the Internal Auditing team onto the poor unfortunate drone who had merely had a paper jam.

    An incident like this would have caused apoplexy among the higher management.

    I guess the management reaction in this case is hinted at by the phrase "This is causing some accounting issues", but the management in this story are clearly not in the same league as the people I used to work for, because the mainframe team would have been toasted over hot coals for allowing something like this to happen, and for not fixing it immediately.

  • QJo (unregistered)

    "... unplug the printer, wait five minutes, and then plug it back in."

    There's the real WFT. Five minutes? For a printer of that vintage? Why on earth so long? That's nearly half as long as it takes to boot up a contemporary laptop with Windows 7 installed! Even my TV cable box only needs at most half a minute.

  • Justsomedudette (unregistered) in reply to phi
    phi:
    I am not a native english speaker, so I can't figure if this was intended : Matt worked helLdesk at an assembly plant

    either way, i like this one.

    Yes it was intended, a second L often replaces the P, when referring to helpdesk.
  • Ben Jammin (unregistered)

    Redundant off-site backup working as intended. Close this WTF.

  • Andrew (unregistered)

    10-20 days later, corporate HQ calls, wondering why their print jobs keep failing.

  • Mike (unregistered)

    The link to the 1984 catalog was an "Emotion moment".

    Especially the various Tandy computers, or the AM radios, especially the smurf shaped one and the ones to put on the handlebar of the push bikes.

  • Robyrt (unregistered)

    The real problem is using the check printer as a backup printer for other random print jobs in the first place. What, did they think it would just switch over to A4 paper?

  • WC (unregistered) in reply to QJo
    QJo:
    "... unplug the printer, wait five minutes, and then plug it back in."

    There's the real WFT. Five minutes? For a printer of that vintage? Why on earth so long? That's nearly half as long as it takes to boot up a contemporary laptop with Windows 7 installed! Even my TV cable box only needs at most half a minute.

    Because it was a network print. It could take a couple minutes for the data to transfer. Better safe than sorry.

  • (cs) in reply to Spudley
    Spudley:
    It's been a long while since I worked on a system that printed cheques (or 'checks' for the Americans), but one thing I remember vividly from those days was that misprinting cheques was a sin capable of bringing down the wrath of the Internal Auditing team onto the poor unfortunate drone who had merely had a paper jam.

    An incident like this would have caused apoplexy among the higher management.

    Yeah, it really takes "higher" management to be stuck up at misprinting, and having to void, some silly preprinted security paper stock (a.k.a. checks, or cheques). I mean, what the fuck, when you issue checks you have a register where every numbered piece of stock is accounted, the misprints are labeled as voided and there you go. You can even, GASP, save the misprinted/mutilated stock for audit purposes if you so wish. Sometimes I wish I could get a bunch of managers in line and bash them on their heads until things settled in... :(

  • John (unregistered) in reply to QJo
    QJo:
    "... unplug the printer, wait five minutes, and then plug it back in."

    There's the real WFT. Five minutes? For a printer of that vintage? Why on earth so long?

    It probably has nothing to do with the age of the printer, but rather the age of the mainframe. It takes five minutes for the mainframe's job control to recognize that the job has failed. Back in the day (around 1980), before I escaped the mainframe ecosystem, I remember jobs where hitting Enter on one of their newfangled display terminals meant waiting two to five minutes for the reply to appear on the screen.

    And it wasn't because the machine (i.e., the hardware) was slow. It was quite fast, for the time. But increased hardware speed never could keep up with the growing complexity and slowness introduced by software "upgrades".

  • StMarc (unregistered) in reply to QJo

    I would guess that that's how long it takes the mainframe to decide that the printer's not there and take the job off queue again. Or something.

    CAPTCHA: nulla (n.) The time it takes a mainframe to decide not to print a job because the primary and secondary printers are unavailable.

  • (cs)

    As for it taking 10-20 days to the the mainframe code modification: Ha ha. Even though all of my mainframe experience was on a CP-67/CMS system on a 360, I just can't see it. It might take an hour to do code modifications and recompile/reassemble. Then you schedule a redeployment script (that you're supposed to have written long time ago!), and you're done. Whenever the batch processing for the day is finished, it will shut down the running code, and restart the one with the fixes. Easy. Even if it takes 10 minutes it should be OK to do in the middle of the night. A lot of the things that take more time today, or perhaps were complex and costly on desktop systems of the last decade, were fairly quick and easy on the mainframe.

  • bluesman (unregistered)

    Why not just fix the primary printer?

  • Spectere (unregistered) in reply to Kuba
    Kuba:
    As for it taking 10-20 days to the the mainframe code modification: Ha ha. Even though all of my mainframe experience was on a CP-67/CMS system on a 360, I just can't see it.
    You underestimate the power of laziness.
  • Just a guy (unregistered) in reply to Kuba
    Kuba:
    As for it taking 10-20 days to the the mainframe code modification: Ha ha

    Clearly you've never had to deal with Change Management. Here, non-emergency requests have a minimum 10 business-day lead time. It could be argued that something like this could be pushed through as an emergency, but the Change Managers I'm familiar in working with always prefer everything to be scheduled.

  • Jabrwock (unregistered) in reply to QJo

    "Why on earth so long?"

    Likely so that the mainframe times out and thinks it's unavailable. The end user probably figured it out through trial and error after merely resetting the printer didn't work.

  • Guest (unregistered)

    Why not just fix the primary printer?

    But we just did ! We assigned another IP to our printer so it would not print that silly inventory from 1984 anymore.

  • Simon K (unregistered) in reply to QJo

    It's not about the printer. Those 5 mins are for mainframe to timeout the printing job and come to conclusion that "secondary printer" is not operational.

  • camelotbob (unregistered)

    Wow this feels so 1980's or even early 1990's to me. I used to run into stupid stuff like this all the time. Nobody really wanted to fix the problem because that might take time or money. So this just do these screwy things like turning off the printer for 5 minutes. Nothing got fixed.

  • Mathias (unregistered)

    This story seems oddly less corny than the usual Remy standard.

  • Naosuke (unregistered) in reply to QJo

    Yeah, but that's user 5 minutes, which is usually between 45-90 seconds

  • (cs) in reply to Mathias

    Oh, look at that. We'll just say I was too busy recovering from New Years. Now all the other readers know who to thank for reminding me!

  • Josh (unregistered)

    Can't they just load the printer with crap paper, and let the job print to completion?

  • AP (unregistered)

    10-20 days to fix anything on a mainframe is pretty quick. The first company I worked for the answer was always "at least 6 months" which is why the team I was on (non-IT) switched to using SQL instead of the mainframe. We could do rate changes on the fly, not having it take a programmer 6 months to do it.... IT wasn't pleased when the CEO saw the reaction time we could have for him, and then placed it upon IT to manage the system.

  • fjf (unregistered) in reply to Robyrt
    Robyrt:
    The real problem is using the check printer as a backup printer for other random print jobs in the first place. What, did they think it would just switch over to A4 paper?
    Which country still uses checks these days and has A4 paper?
  • (cs) in reply to Josh
    Josh:
    Can't they just load the printer with crap paper, and let the job print to completion?

    Sure, but approving that "PC Load Letter" change request will take about... ten to twenty days.

  • Kevin Thorpe (unregistered)

    You forgot the part about putting the end of the unplugged printer lead in the bin to catch the loose letters.

  • Jack (unregistered) in reply to camelotbob
    camelotbob:
    I used to run into stupid stuff like this all the time. Nobody really wanted to fix the problem because that might take time or money. ... Nothing got fixed.
    Why are you speaking in past tense?
  • Harry (unregistered)

    Yeah, we had a six month lead time for all mainframe change requests. Not that it took six months, but every request had to be prioritized, and there was six months of "absolutely must have it right now or the judge is going to fine us for ignoring his mandate" work ahead of any stupid stuff like fiddling with print queues or IP addresses.

    Then someone bought a "desktop computer" and we all laughed about how his desk must be made out of reinforced steel to hold up that much weight.

    Then 100 more people bought desktop computers and they stopped nagging us about the six month lead time because they were rolling their own reports and such now.

    Then most of us got laid off. Damn, I hate progress. If only we had the foresight to unionize.

  • (cs) in reply to Justsomedudette
    Justsomedudette:
    phi:
    I am not a native english speaker, so I can't figure if this was intended : Matt worked helLdesk at an assembly plant

    either way, i like this one.

    Yes it was intended, a second L often replaces the P, when referring to helpdesk.
    Please close this ticket
  • trtrwtf (unregistered) in reply to Kevin Thorpe
    Kevin Thorpe:
    You forgot the part about putting the end of the unplugged printer lead in the bin to catch the loose letters.

    But first you have to put the satchel on the panel, or it won't work.

  • (cs)

    Wow, what a walk down memory lane. Forgot about all the goodies in the old Radio Shack catalogs. Forgot about the quirk of having the index in the middle of the book. The index was also the separator between the cool stuff like PA systems and the really cool stuff like ICs.

    I still have a few Radio Shack test leads and breadboard laying around.

    Great nerd porn.

  • Oh THAT Brian (unregistered)

    Five minutes - that's probably long enough for the mainframe to decide the alternate printer is offline and stop trying to print to the checks.

    Of course, the mainframe people will put in a ticket saying that their secondary printer is not working.

    Then, Matt replies - no, there's nothing wrong with our check printer. Maybe you should put in a change request to fix your problem! (cue evil laugh)

  • ZoomST (unregistered)

    That reminds me a similar problem we had. We had a printer connected to the network and some people was sending their jobs there by mistake... several times a week. And IT denied the change of its IP. My boss decided to unplug the printer from the network, plug it in to a computer using old parallel port, and configure a nice queue server for our area only. Not the ideal solution, but my boss was so proud of it that he decided to close this ticket.

    Captcha: jumentum. Take advantage of the moment to fix it.

  • Mock (unregistered) in reply to QJo

    I'm not sure if you're an admin, but there are some anomalies that occur when windows cannot connect to a mapped drive or printer. Essentially, windows will timeout for 300-600 seconds when it can't reach a device; otherwise it will keep trying to send the job until that time has been reached. This is also a heavy issue when on a domain and servers can't be reached. Even windows 7 will take up to 10 minutes to log in after credentials are entered, if policies aren't configured correctly.

  • Ralph (unregistered) in reply to Mock
    Mock:
    Even windows 7 will take up to 10 minutes to log in after credentials are entered, if policies aren't configured correctly.
    Policy = No Windows.

    Please close this ticket.

  • Rick (unregistered)

    The old Radio Shack catalog reminds me of one of my first web projects, back in the very early days. A highly successful order-by-mail retailer wanted to get online. So they launched a million dollar project.

    They scanned every page of their printed catalog as large multi-KB .jpgs. Never mind that .jpgs look like hammered crap for anything other than scenery. Never mind that a fast modem those days ran at 14.4 Kbps, so each image would take about 5 minutes to download. No, any mention of technical stuff like that and the project sponsors went into brainfreeze.

    We told them there should be one page per product, loaded from a database, with mostly text and only a small picture you could click to zoom. We told them there should be a search box so people could find what they wanted.

    Them: No, we want to force people to browse through the catalog. If we let them go directly to what they're looking for, we won't be able to "drive traffic" to our featured specials.

    Us: Ahem, you don't understand, on the web you're not in control. The user is.

    Them: Just do it already. You nerds can't understand marketing.

    So we did. Oh did I mention if while "browsing" this massive catalog you wanted to order something, you were to print out a .jpeg of the order page, fill it out (yes with a pen) and fax it to them?

    Strangely, a million dollars later, they never got any orders faxed in.

    Hmmm. What could possibly have gone wrong?

    Suddenly they were willing to listen to the nerds who "can't understand marketing".

  • Blah (unregistered) in reply to QJo

    The printer doesn't take 5 minutes to boot up. They leave it unplugged for 5 minutes in order for the print job to time out and then plug it back in once the job has timed out.

  • Blah (unregistered) in reply to QJo
    QJo:
    "... unplug the printer, wait five minutes, and then plug it back in."

    There's the real WFT. Five minutes? For a printer of that vintage? Why on earth so long? That's nearly half as long as it takes to boot up a contemporary laptop with Windows 7 installed! Even my TV cable box only needs at most half a minute.

    The printer doesn't take 5 minutes to boot up. They leave it unplugged for 5 minutes in order for the print job to time out and then plug it back in once the job has timed out.

  • Larry (unregistered)

    I think I'm starting to figure out why the printer had to be left off for 5 minutes! Should I post my theory? I'll go read the comments now to see if you want my brilant insight.

  • the beholder (unregistered) in reply to Larry
    Larry:
    I think I'm starting to figure out why the printer had to be left off for 5 minutes! Should I post my theory? I'll go read the comments now to see if you want my brilant insight.
    No, wait. I wanna go first. Because I just had this brillant insight and I'm pretty sure I'm the first one to think about a timeout and stuff. So don't post your theory before I do!
  • VR (unregistered)

    I think he could have just changed the permissions on the printer share so the mainframe doesn't have permission to print to it or even stop sharing it at all.

  • Some Damn Yank (unregistered)

    The one and only time I worked in the print room at a Fortune 500 company, the rules for printing checks were pretty strict. Only a handful of employees were allowed to do it (and their checks were printed by another team at another location), and at least two people had to be involved at all times. The pre-printed check number was also printed by the printer (for security reasons), so the first pre-printed check number had to be entered into the system first. Any un-used or damaged checks had to be logged and returned to the central accounting people. That latter requirement would save their butts in this example. The danger was running out of pre-printed checks, which is probably why they never let the 1984 job finish.

    Why didn't they just load the printer with blank paper, let it do it's 1984 nostalgia thing, and be done with it?

  • C-Derb (unregistered) in reply to Josh
    bluesman:
    Why not just fix the primary printer?
    +1
    Josh:
    Can't they just load the printer with crap paper, and let the job print to completion?
    +1
  • A developer (unregistered)

    I love the mainframe morons desperately trying to hang on to their boring jobs. Usually they're foreign born nationals with zero customer service skills.

  • Somebody (unregistered) in reply to QJo

    There's probably just a bit missing from that text... User is probably supposed to log on to the computer while the printer is unplugged. After that you have to wait for the print job to time out on the computer before plugging the printer in.

    So that's not WTF at all, but there are several deep WTF's in the story.

Leave a comment on “Check the Check Printer”

Log In or post as a guest

Replying to comment #398278:

« Return to Article