![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Totally 404 man
Feb. 13th, 2004 04:09 pmMiscellaneous Friday ramblings.
(o) These have to be the worse butter tarts I've ever eaten. Bleah. No wonder they were so cheap.
(o) It's like every other Winnipeg driver took their "stupid and aggressive" pills this morning.
(o) Why do people feel the need to state the bleedingly obvious? I took my car key in and had a copy made because the original was cracking and could break at any time. The old fellow cut the key for me, and as he handed them both back to me he said, "are you aware that your old key is cracked?" Duh. Of course I'm aware - why do you think I'm getting a new one cut? And why do you think I handed it to you and said, "I need to get a new key cut before this one breaks completely."
(o) Some of our employees know just enough to be dangerous.
The operations senior called my co-worker last night, complaining that one of our servers was experiencing a recurring error. He had rebooted the server three times, and each time it had come back up reporting the same error. According to the senior, the server kept coming up with a "404 error", and he'd been on the Interweb long enough to know that a 404 is a Bad Thing ®.
At first my co-worker was puzzled because these servers do not have an internet connection.
"What exactly are you getting back as an error message?" he asked.
"In the status window it says '404 Error Report'," said the senior.
Now at this point I should mention that "404" is the report number for our EDI Bills of Lading. When these things come in, they bounce to a reject/rework menu if they have any syntactic or semantic exceptions. Every night at about 23:00 this server sifts through that menu and generates a statistical report of 404 exceptions based on line of business, exception type, etc. In other words it generates the "404 Error Report".
Each time this guy rebooted the machine it would check to see what it had been working on before it was rebooted, and seeing that it had not finished its report, it would restart the last job it had been running when it was rebooted. He could have rebooted it again and again and the same "error" would have come up each time. I don't think it was the server that had the "404 Error".
(o) These have to be the worse butter tarts I've ever eaten. Bleah. No wonder they were so cheap.
(o) It's like every other Winnipeg driver took their "stupid and aggressive" pills this morning.
(o) Why do people feel the need to state the bleedingly obvious? I took my car key in and had a copy made because the original was cracking and could break at any time. The old fellow cut the key for me, and as he handed them both back to me he said, "are you aware that your old key is cracked?" Duh. Of course I'm aware - why do you think I'm getting a new one cut? And why do you think I handed it to you and said, "I need to get a new key cut before this one breaks completely."
(o) Some of our employees know just enough to be dangerous.
The operations senior called my co-worker last night, complaining that one of our servers was experiencing a recurring error. He had rebooted the server three times, and each time it had come back up reporting the same error. According to the senior, the server kept coming up with a "404 error", and he'd been on the Interweb long enough to know that a 404 is a Bad Thing ®.
At first my co-worker was puzzled because these servers do not have an internet connection.
"What exactly are you getting back as an error message?" he asked.
"In the status window it says '404 Error Report'," said the senior.
Now at this point I should mention that "404" is the report number for our EDI Bills of Lading. When these things come in, they bounce to a reject/rework menu if they have any syntactic or semantic exceptions. Every night at about 23:00 this server sifts through that menu and generates a statistical report of 404 exceptions based on line of business, exception type, etc. In other words it generates the "404 Error Report".
Each time this guy rebooted the machine it would check to see what it had been working on before it was rebooted, and seeing that it had not finished its report, it would restart the last job it had been running when it was rebooted. He could have rebooted it again and again and the same "error" would have come up each time. I don't think it was the server that had the "404 Error".
