- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
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.
Admin
I'll cancel all the jobs to ensure the print queue has enough room for your theory...
Admin
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.
Admin
Admin
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.
Admin
It helps to picture any mainframe group as if everyone there were members of a union.
Admin
Let the job go to a virual (pdf) printer en get rid of it there?
Admin
Admin
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.
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.
Admin
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!
Admin
Because the mainframe might take a few minutes from triggering the job to actually sending the print job to the printer.
Admin
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...".
Admin
Thanks to the commenters for pointing out that this was about cheques. Now it makes a lot more sense :-)
Admin
{insert comment about print job timeouts here}
Admin
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.
Admin
The next week the third backup printer on the other side of the country started printing out the documents from 1984.
Admin
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?
Admin
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.
Admin
Admin
Cause you need 5 minutes to get coffee :)
Admin
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.
Admin
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.
Admin
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.
Admin
May be because it's out of service since 1985?
Admin
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?
Admin
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.
Admin
Standard procedure Need 30s - 1 min? Tell the user 5 min to be on the safe side.
Admin
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.
Admin
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.
Admin
[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.
Admin
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.
Admin
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?
Admin
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.
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
Restart the print spooler service and they'll be gone in a minute.
Anyway, this WTF sounds like "Failure by Design" to me.
Admin
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.
Admin
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.
Admin
Turn the printer on, print the checks, and then turn the printer off. Why leave it on all the time?
Admin
For the sake of all those who might have heard about checks in a rerun of some last-century movie, can someone summarize...
Admin
The 5 minutes is for the job to time out at the mainframe. Brilliant solution! I LOL'd.
Admin
The five minutes is to make sure the print job coming from the computer has timed-out.
Admin
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.
Admin
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.
Admin
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?)