• confused (unregistered)

    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.

  • (cs) in reply to bluesman
    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 (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.

    I'll cancel all the jobs to ensure the print queue has enough room for your theory...

  • trtrwtf (unregistered) in reply to A developer
    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 (unregistered) in reply to camelotbob
    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 (unregistered)

    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 (unregistered) in reply to Just a guy
    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 (unregistered)

    Let the job go to a virual (pdf) printer en get rid of it there?

  • (cs) in reply to Just a guy
    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 (unregistered) in reply to confused
    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.

  • (cs)

    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 (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 the mainframe might take a few minutes from triggering the job to actually sending the print job to the printer.

  • TeatimeOfSoul (unregistered) in reply to QJo

    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...".

  • (cs)

    Thanks to the commenters for pointing out that this was about cheques. Now it makes a lot more sense :-)

  • Beating a decomposed horse (unregistered)

    {insert comment about print job timeouts here}

  • Trix (unregistered) in reply to VR

    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 (unregistered) in reply to Simon K

    The next week the third backup printer on the other side of the country started printing out the documents from 1984.

  • Crow T Robot (unregistered)

    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?

  • (cs) in reply to AP
    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 (unregistered) in reply to A developer
    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 (unregistered) in reply to QJo

    Cause you need 5 minutes to get coffee :)

  • Wholesale groceries (unregistered) in reply to fjf
    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 (unregistered)

    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 (unregistered) in reply to Just a guy
    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 (unregistered) in reply to bluesman

    May be because it's out of service since 1985?

  • KeroHazel (unregistered)

    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 (unregistered) in reply to Wholesale groceries
    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 (unregistered) in reply to QJo

    Standard procedure Need 30s - 1 min? Tell the user 5 min to be on the safe side.

  • (cs) in reply to Anketam
    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 (unregistered) in reply to Jaime
    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 (unregistered) in reply to Simon

    [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 (unregistered) in reply to QJo

    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 (unregistered)

    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 (unregistered)

    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.

  • (cs)
    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 (unregistered)

    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.

  • (cs) in reply to VR
    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 (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. ...

    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 (unregistered) in reply to pencilcase
    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 (unregistered) in reply to QJo

    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 (unregistered) in reply to AF

    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 (unregistered) in reply to QJo

    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 (unregistered) in reply to QJo

    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 (unregistered)

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

  • WtfIsACheck (unregistered)

    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 (unregistered) in reply to QJo

    The 5 minutes is for the job to time out at the mainframe. Brilliant solution! I LOL'd.

  • smf (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 five minutes is to make sure the print job coming from the computer has timed-out.

  • (cs) in reply to fjf
    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 (unregistered)

    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 (unregistered)

    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?)

Leave a comment on “Check the Check Printer”

Log In or post as a guest

Replying to comment #:

« Return to Article