Check the Check Printer

« Return to Article
  • ParkinT 2013-01-02 06:37
    A well-written, enjoyable story.

    I like this line:
    ...with about as much memory as a goldfish.

  • David 2013-01-02 08:08
    Sometimes, every once in a while, the ingenuity and pragmatism of the average user makes me smile.
  • iceland 2013-01-02 08:11
    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 2013-01-02 08:26
    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 2013-01-02 08:31
    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 2013-01-02 08:38
    "... 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 2013-01-02 08:51
    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 2013-01-02 09:00
    Redundant off-site backup working as intended. Close this WTF.
  • Andrew 2013-01-02 09:07
    10-20 days later, corporate HQ calls, wondering why their print jobs keep failing.
  • Mike 2013-01-02 09:07
    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 2013-01-02 09:18
    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 2013-01-02 09:23
    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.
  • Kuba 2013-01-02 09:27
    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 2013-01-02 09:28
    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 2013-01-02 09:32
    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.
  • Kuba 2013-01-02 09:33
    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 2013-01-02 09:47
    Why not just fix the primary printer?
  • Spectere 2013-01-02 09:48
    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 2013-01-02 09:55
    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 2013-01-02 09:56
    "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 2013-01-02 09:56
    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 2013-01-02 10:02
    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 2013-01-02 10:16
    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 2013-01-02 10:23
    This story seems oddly less corny than the usual Remy standard.
  • Naosuke 2013-01-02 10:26
    Yeah, but that's user 5 minutes, which is usually between 45-90 seconds
  • Remy Porter 2013-01-02 10:29
    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 2013-01-02 10:36
    Can't they just load the printer with crap paper, and let the job print to completion?
  • AP 2013-01-02 10:54
    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 2013-01-02 10:56
    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?
  • DCRoss 2013-01-02 10:58
    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 2013-01-02 10:59
    You forgot the part about putting the end of the unplugged printer lead in the bin to catch the loose letters.
  • Jack 2013-01-02 11:00
    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 2013-01-02 11:08
    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.
  • Helix 2013-01-02 11:09
    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 2013-01-02 11:11
    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.
  • RichP 2013-01-02 11:15
    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 2013-01-02 11:39
    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 2013-01-02 11:47
    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 2013-01-02 11:50
    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 2013-01-02 12:07
    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 2013-01-02 12:16
    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 2013-01-02 12:17
    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 2013-01-02 12:18
    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 2013-01-02 12:20
    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 2013-01-02 12:26
    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 2013-01-02 12:35
    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 2013-01-02 12:41
    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 2013-01-02 12:44
    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 2013-01-02 12:56
    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 2013-01-02 13:00
    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.
  • confused 2013-01-02 13:00
    I don't understand at all. The printer is on the network so how does a login cause it to receive a remote print job.

    Then I worry about a cheque printer which is on an outside network.
  • lanmind 2013-01-02 13:03
    bluesman:
    Why not just fix the primary printer?


    It might have had some kind of MICR ribbon, or more likely, no one wanted to listen to the damn thing pounding out a massive and useless report.
  • Fermat's last print queue 2013-01-02 13:10
    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.


    I'll cancel all the jobs to ensure the print queue has enough room for your theory...
  • trtrwtf 2013-01-02 13:12
    A developer:
    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.


    Yes, precisely this is my story! For I am coming to America in 1987 to operate DEC machine, and have been continued in same position for twenty-five of years without interruption. It is well-known story, all sysadmins are having been Indian in this country since Hector was a pup, as it is being said.
  • foxyshadis 2013-01-02 13:33
    camelotbob:
    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.

    Believe me, that attitude hasn't changed one bit since then. People will even scream at you for fixing things and breaking their careful voodoo incantations, thus you'll still find VAX emulators and DOS programs with no source that have to be run in XP Mode or VirtualBox kicking around.
  • kbiel 2013-01-02 13:43
    TRWTF is Matt. Just close the ports for printing in the DMZ on the router. Or, and this is just paranoia talking I'm sure, only open the ports necessary to query the mainframe and receive a response.
  • eric76 2013-01-02 14:00
    Just a guy:
    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.


    It helps to picture any mainframe group as if everyone there were members of a union.
  • planB 2013-01-02 14:44
    Let the job go to a virual (pdf) printer en get rid of it there?
  • Anketam 2013-01-02 15:02
    Just a guy:
    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.
    Where I work if there is an issue affecting people's paychecks it by default gets the highest priority until a higher up can be convinced otherwise (which normally does not happen, since it can take 10-20 business days to get their decision). The justification for pay issues being so important is simple: How would you like to be told we can't pay you? Not to mention some people live paycheck to paycheck and you can really mess them up if there is any delay in that check.
  • Worf 2013-01-02 15:56
    confused:
    I don't understand at all. The printer is on the network so how does a login cause it to receive a remote print job.

    Then I worry about a cheque printer which is on an outside network.


    Because the guys at mainframe said so "Windows can't print without a user logged in". Obviously not true, but that's what they believed. Then again, perhaps they ran some custom printer daemon as a login task.

    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.


    Well, the printer is printing something out. You want to tell them that they need to unplug it for the exact time (1 minute 43 seconds? 2m37s? 3m23s?) or just say "5 minutes" and know it'll definitely be OK? In a rush you can probably cut it down, but for most users, 5 minutes is probably more than necessary and about the shortest interval a human can understand anyhow for a delay. Long enough to log in and do something else quickly without waiting there staring at the clock.

    Heck. bonus points if someone wrote a little program that popped up when you can plug the printer back in.
  • GettinSadda 2013-01-02 16:32
    Simple fix - send all mainframe staff paychecks on checks already printed over with partslist data from 1984. I suspect the problem will then be fixed before the end of the day.

    If you want it fixed before lunch, send upper management their paychecks on the spoilt media!
  • David Mårtensson 2013-01-02 16:45
    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 the mainframe might take a few minutes from triggering the job to actually sending the print job to the printer.
  • TeatimeOfSoul 2013-01-02 16:54
    The real WTF is Matt's inability to read between the lines. There is probably a policy against requesting a change request in the response to a ticket. So they point out that this retarded behaviour is precisely what has been demanded of them, but that it could be changed in 10-20 days (which for a mainframe is like 'three shakes of a lambs tail') if a proper change request were issued. Something along the lines of "...business case: this costs us resources every single day and has no possibility of ever being useful...".
  • eionrobb 2013-01-02 17:01
    Thanks to the commenters for pointing out that this was about cheques. Now it makes a lot more sense :-)
  • Beating a decomposed horse 2013-01-02 17:53
    {insert comment about print job timeouts here}
  • Trix 2013-01-02 18:27
    Uh, I would imagine the mainframe isn't printing to a Windows print queue at all. Pretty much every modern enterprise printer has LPT accessible over an internal ethernet-connected print server. All the mainframe needs is the IP address of the device.
  • David 2013-01-02 19:00
    The next week the third backup printer on the other side of the country started printing out the documents from 1984.
  • Crow T Robot 2013-01-02 19:28
    Ya know I have this theory that the mainframe would timeout if they unplugged the printer. I wonder how many minutes that would take? Any theories?
  • Jaime 2013-01-02 19:41
    AP:
    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.
    Your mistake was not fixing the right thing. In the "at least six months" company you worked for, the mainframe wasn't the problem, it was the process. Your SQL Server fix worked because it was outside the process. However, as soon as it became mission critical, it was destined to be folded back into the process.

    I run into something similar occasionally. Every once in a while someone will tell me "I like to put as much code as possible into stored procedures because you can deploy them in the middle of the day". I then ask "hmmm, I don't see a technical reason why stored procedures can be deployed quicker than web site and middle tier updates, why is it?". The usual response is "those changes have to go through change management, I can just run a script to update a stored procedure". So, at the end of the day, they are really just skirting the whole CM process. Depending on your point of view, the right answer is either to roll DB changes into CM or to get rid of CM.
  • Norman Diamond 2013-01-02 20:20
    A developer:
    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.
    It's not only foreign born nationals that have zero customer service skills, even though that stereotype is rooted in a kernel of truth. Although most native born citizens are trained by their employers to provide better customer service than gaijin usually do, there are some Japanese who never get the lesson.
  • Michael 2013-01-02 21:10
    Cause you need 5 minutes to get coffee :)
  • Wholesale groceries 2013-01-02 21:51
    fjf:
    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?


    Any country that has A4 paper. Cheques need to be mailed (3 business days) and cleared, (3 business days). Some people don't deposit their cheque for a month, some people just loose it.

    In todays zero-interest environment, zero interest is what you get paid for a deposit. Borrowing money still costs a few percent, and a free float like this is worth more than the printing, mailing, and fraud costs for people paying dividends and large trade incentives.
  • Fleepo 2013-01-02 23:23
    I work for a credit union - we use dot matrix tractor feed printers to print on preprinted cheques from Unix.

    The cheque printers used to be directly-connected serial printers; now we use Ethernet-to-USB, or Ethernet-to-parallel print servers.

    Quite often the print server locks up (resulting in mismatched cheque numbers) or it decides to print it's diagnostics to the cheque. And yes, accounting doesn't like it when this happens as preprinted cheques are expensive and need to be tracked/audited, and/or the cheque transaction needs to be reversed and done again.

    Generally the problem is with the crap quality of USB print servers; small text-only print jobs tend to be ignored by some print servers, and other print servers queue up multiple jobs and print them out of sequence. (cheque data is only about 50-100 bytes, tops.)

    Eg Netgear and D-Link print servers are useless for this kind of work, they overheat, lock up or just fail to print reliably. Makes for fun diagnostics!
    It mostly works now, but we still regularly have problems with cheque printing.
  • Simon 2013-01-02 23:25
    Just a guy:
    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.


    Yep, that's the trick. The actual change might only take a few minutes, but there's always a ton of management overhead involved in making changes, especially to mainframe systems. That's not 10-20 days of work, that's 10-20 days of meetings and writing documentation.
  • steffzt 2013-01-03 01:31
    May be because it's out of service since 1985?
  • KeroHazel 2013-01-03 02:30
    I was slightly disappointed to discover that the IP address in the story is just this site's IP. I was hoping it would lead on a merry chase ending with the final location of the treasure of the Knights Templar.

    ... or failing that, why not just spit out the requester's IP back at them?
  • Norman Diamond 2013-01-03 02:40
    Wholesale groceries:
    fjf:
    Which country still uses checks these days and has A4 paper?
    Any country that has A4 paper.
    Except, of course, for a bunch of countries that have A4 paper and don't use cheques.

    Japan used to have a weird kind of chequing system that didn't suit anyone other than organized crime, and abandoned it several decades ago. I didn't know that when I came here, so I brought a cheque payable in yen but couldn't cash it so I had to send it back to the Canadian bank that issued it. Two other payers sent me cheques payable in yen; in one case I could take it to the bank's Japanese representative office and cash it but that office later closed; and in the other case the bank's Japanese representative office refused to cash it so I had to send it back to Canada.
  • Ted 2013-01-03 03:14
    Standard procedure
    Need 30s - 1 min?
    Tell the user 5 min to be on the safe side.
  • Steve The Cynic 2013-01-03 03:27
    Anketam:
    Where I work if there is an issue affecting people's paychecks it by default gets the highest priority until a higher up can be convinced otherwise (which normally does not happen, since it can take 10-20 business days to get their decision). The justification for pay issues being so important is simple: How would you like to be told we can't pay you? Not to mention some people live paycheck to paycheck and you can really mess them up if there is any delay in that check.

    How quaint. Paychecks? Which level of the Stone Age do you live in?

    It's been over twenty years since someone paid me by giving me a check (and it was a check, not a cheque, because it was when I was living in the US). In the late 90s I worked briefly for a company that still paid by cheque (UK, this time), but they posted the cheques directly to the employee's bank because they had a pointlessly paranoid distrust of bank-to-bank transfer systems.

    Coupled with a policy of paying a few days after the end of the month, it did mean that we were sometimes paid a week and a half after the pay period, which was a significant annoyance. Other than that, every company I've worked for after graduating from Uni has paid me by direct bank transfer.
  • QJo 2013-01-03 04:01
    Jaime:
    AP:
    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.
    Your mistake was not fixing the right thing. In the "at least six months" company you worked for, the mainframe wasn't the problem, it was the process. Your SQL Server fix worked because it was outside the process. However, as soon as it became mission critical, it was destined to be folded back into the process.

    I run into something similar occasionally. Every once in a while someone will tell me "I like to put as much code as possible into stored procedures because you can deploy them in the middle of the day". I then ask "hmmm, I don't see a technical reason why stored procedures can be deployed quicker than web site and middle tier updates, why is it?". The usual response is "those changes have to go through change management, I can just run a script to update a stored procedure". So, at the end of the day, they are really just skirting the whole CM process. Depending on your point of view, the right answer is either to roll DB changes into CM or to get rid of CM.


    Argh, been there done that. CM is there for a reason.

    Had a boss once who insisted that this technique needed to be used. Consequently there were, get this, not even stored procedures, but complete web pages - business logic, html tags, the lot - stored as entries in ordinary database records. You'd pass in the parameters you need (customer ID, period and year, etc.) replace the bind variables and squirt the result into your browser. Nightmare.
  • Gibbon1 2013-01-03 04:36
    [quote user="Simon"][quote user="Just a guy"]Yep, that's the trick. The actual change might only take a few minutes, but there's always a ton of management overhead involved in making changes, especially to mainframe systems. That's not 10-20 days of work, that's 10-20 days of meetings and writing documentation. [/quote]

    None of you monkeys understand whats going on here. So the mainframe, stores parts lists from way way back. It'd probably cough up a parts lists from 1967 if you knew the right document number. But over the years the format of the parts list have changed. There are programs written over the years to handle all this. So when you ask for a parts list, a bunch of archaic processes run, which mao you request into either a database access, a flat file access, either the old format (pre-1978) new format (1978 to 1987), intermediate format etc etc.

    There is also a failure mechanism built in so that if the print job fails it gets restarted when 'the user' which is now 'all users' logs.

    So fast forward. Someone mistypes a part list request and oops dredges up this parts list from 1984. But something goes wrong and the process crashes while the thing is printing. Because say there isn't a carriage return on the last line of the flat file parts list. So yet another process reschedules the print job for 'next time'

    You can see where I'm going here. The mainframe guys really really do not want to open that can of worms.
  • comrad 2013-01-03 04:36
    Simply because if you tell your users that they just need to replug it in after a few seconds, most of them won't do that.

    I know these 5 minutes as rising your chances that the unplugging actually happens.
  • pencilcase 2013-01-03 05:32
    I still write cheques. I'm a contractor, so the client pays the agency, the agency pays my Limited Company, and my company pays me. This means that, once a week I write 2 cheques (Salary as employee, Dividend as director) to myself. This gives me great pleasure, and I take my time writing them up really nicely. Then I take my 2 cheques, and stroll down to the bank at the end of the road, normally mid-morning. I fill in the payslip, add up the numbers, double-check the totals, and hand them over at the desk, taking time to have a chat with the cashier about the weather, Christmas or whatever. Then I take my receipt, and stroll back to my desk to continue work.

    My girlfriend thinks I'm mad, and says I could do all of this online without leaving my desk, just by logging on at the bank's website and clicking a few boxes. Well of course I could, but which is more fun? No-one can give me a hard time for taking time out to get paid. Besides, what could be more satisfying than writing 2 nice cheques to yourself, with love?
  • VR 2013-01-03 08:12
    This part of the story:

    "“Why is this computer in the DMZ? Does it need a public IP?”

    ... the mainframe might be able to talk to the computer. ...Sure enough, every time someone logged in, a bunch of packets came from the mainframe, kicking off the print job.

    ...“The reason print-jobs are only arriving when a user logs in is probably related to some inability of Windows to receive print-jobs without a user present.”"

    Tells me the printer is not networked, it's shared by the workstation.

    So the solution should have been to just stop sharing it or rename the share or change the permissions etc.
  • Musaran 2013-01-03 08:27
    Every time a user logs on, it prints out an inventory of electrical parts dated from 1984. On our checks.
    The kind of random nonsense dreams are made of. :')
  • BrettM 2013-01-03 09:38
    What's with the "custom print-queue manager" that apparantly has no ability to actually, y'know, manage the queue? What is a print-queue manager for if not to give an operator the ability to cancel, hold, or re-direct print jobs at will? No wonder they needed a custom package, since anything off-the-shelf would undoubtedly have offered the basic functionality of a print-queue manager. The custom package then demonstrated its chops by switching the job to a backup printer when the primary failed, but was then unable to handle the failure of the backup. It will retry for eternity on the backup, though not on the primary, while offering no opportunity to manually correct the situation from the console? That looks like the biggest WTF to me.
  • geocities 2013-01-03 12:36
    VR:
    Tells me the printer is not networked, it's shared by the workstation.

    So the solution should have been to just stop sharing it or rename the share or change the permissions etc.


    Not if printing of the actual checks is also to be triggered by the mainframe.

    I.e., you log into the workstation, send some command to the mainframe and the mainframe sends back a print job for the checks.
  • jay 2013-01-03 14:26
    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. ...


    When I worked for the government, if someone had suggested making a software change in a mere 10-20 days we would have laughed. First you have to prepare a Request For Change (RFC). This must be routed through many layers of management for analysis and approval. That alone takes several weeks. If you do manage to get it approved, we then have to prepare the Software Design Document (SDD), the Functional Design Document (FDD), perhaps a Database Change Request (DBCR), a Software Test Plan (STP), etc. etc. At one time I was given a 20-page list of the forms and documents we had to complete to make a software change. Not a 20-page form, but a 20-page list of forms. Not all were required for every project, but I doubt any project required less than a dozen forms.
  • jay 2013-01-03 14:32
    pencilcase:
    I still write cheques. I'm a contractor, so the client pays the agency, the agency pays my Limited Company, and my company pays me. This means that, once a week I write 2 cheques (Salary as employee, Dividend as director) to myself. This gives me great pleasure, and I take my time writing them up really nicely. Then I take my 2 cheques, and stroll down to the bank at the end of the road, normally mid-morning. I fill in the payslip, add up the numbers, double-check the totals, and hand them over at the desk, taking time to have a chat with the cashier about the weather, Christmas or whatever. Then I take my receipt, and stroll back to my desk to continue work.

    My girlfriend thinks I'm mad, and says I could do all of this online without leaving my desk, just by logging on at the bank's website and clicking a few boxes. Well of course I could, but which is more fun? No-one can give me a hard time for taking time out to get paid. Besides, what could be more satisfying than writing 2 nice cheques to yourself, with love?


    Clearly you do not have the appropriate Corporate Mindset.

    Before you write these checks, you should be auditing the invoice that you give to yourself to be sure that it is accurate. How do you know that the person writing the invoice (you) is not inflating the hours worked or otherwise falsifying? When you pay yourself, you should have controls in place to insure that the person cashing the checks is, in fact, the person they were intended for. Etc.
  • AF 2013-01-03 16:51
    Probably because Windows takes forever to kill print jobs. Try pressing "cancel job" on Windows and it can take up to an hour before they are gone.
  • iMalc 2013-01-03 19:48
    Restart the print spooler service and they'll be gone in a minute.

    Anyway, this WTF sounds like "Failure by Design" to me.
  • ben_yo 2013-01-03 21:24
    The 5 min power down is not to reset the printer, it's to keep the printer offline while the user logon issue is sending packets and queuing the printer.
  • Chromatix 2013-01-03 22:36
    The five-minute wait is to make the mainframe time out of the 1984 job secondary-printer retry.

    Another workaround would be to make the *primary* printer work, so that the secondary retries stop happening.
  • Timmeh 2013-01-03 23:45

    Turn the printer on, print the checks, and then turn the printer off. Why leave it on all the time?

  • WtfIsACheck 2013-01-04 09:33
    For the sake of all those who might have heard about checks in a rerun of some last-century movie, can someone summarize...

    - what a check is
    - what the check printer is supposed to do
    - why it is a problem that some checks get unrelated gibberish printed on them
  • b0b 2013-01-04 11:44
    The 5 minutes is for the job to time out at the mainframe. Brilliant solution! I LOL'd.
  • smf 2013-01-05 07:29
    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 five minutes is to make sure the print job coming from the computer has timed-out.
  • hikari 2013-01-05 07:49
    fjf:
    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?


    The UK?

    OK, we have cheques rather than checks and they're quickly disappearing, but they're still in use. I got a printed one as a refund from the government for something not long ago.
  • aldo 2013-01-05 08:08
    Well, on January 1 one of our mainframe stopped working and filled tables with "am i really still running? "
    After brief inspection it turned out it was a piece of code dated 1993 with an IF on its activation. It was from a departed programmer we all knew.
    A January eastern egg from another world and time.
    This was understandable since that code 'is going to be dismissed by the end of the year with the whole mainframe '. In 1993.
  • AC 2013-01-06 00:49
    I'd redirect the local printer to nul and let the mainframe dump it's entire print queue. How long could 20 years of unnecessary printouts take to spool out? (somewhere between 25 seconds and 25 years?)
  • nothikari 2013-01-06 03:53
    fjf:

    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?


    Please turn on your sarcasm detector, You cheque-using countries seem to be completely unable to grasp that the cheque system is inherently inflexible, error-prone and expensive to maintain. We have overcome this decades ago by simply requesting people to directly transfer money between bank accounts. This now works (for some EU-countries even without any direct transaction costs) on a european scale.

    I am always amused by the inflexibility of thinking and not-knowing of how things work in other countries of US-centric minds.
  • Romojo 2013-01-06 18:47
    Must be change management - I support two mainframes here in <company name> and the Windows people are usually the ones who can't do what I do, or do it as fast as I can. They have a lot more cooks stirring that broth, as well....
  • Corporate_Monkey 2013-01-07 04:14
    Why not just put in the change request ticket with the mainframe guys and wait the 10-20 days?
  • Brian 2013-01-08 19:06
    The five minutes is likely so the problem print job times out and goes away until the next login.
  • Darth Age 2013-01-09 07:39
    Wait what!?!

    A mainframe doing TCP/IP networking back in 1984?

    That's pretty rare.

    And probably indicates a homegrown TCP/IP-stack; updated as regularly as they have updated the IP list of their printers.

    No wonder they don't use a VPN for connecting to the mainframe.

    Their network management really is arcane.
  • Mac 2013-01-10 17:31
    You never worked with "mainframe" folks... have you...
  • Andrew 2013-01-10 19:48
    The printer has nothing to do with it, that's the time for the mainframe to notice the user login, try to send the print job, notice that it's not going to work, and give up.
  • anon 2013-01-11 10:43
    I believe that waiting time is for the mainframe to determine that the printer is not responding, stop.

    The job isn't in the mainframe queue; rebooting the mainframe wouldn't have solved it--it was that the mainframe was sending this job fresh and new every time users logged in; why it wasn't going to the original printer if this was an alternative--they seemed to have decided the original printer and its IP is not an issue if no one complained about it, seeing this alternate was only supposed to be used in case the first one failed...

    Anyway the five minutes is to just let the mainframe printer pipes drain bits onto the floor. After that it is out of 1984 print jobs, and the printer can be turned on again and receive relevant data. That's my understanding of it...
  • -is 2013-02-27 11:41
    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 five minutes are not booting time or login time for anything - it is to be sure the mainframe has given up on sending the print job for this round.