- 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
99999+2st
Admin
Ah, mon ami, you use the little grey cells!
Admin
no one understands cobol? let me explain then, 99999 is top for cobol pic9(5) datatype, and 100k overflows it
Admin
...or... it was just a bad developer in a very simple environment <grin>
Admin
Methinks you read to much into this. It is simply an issue of some idiot programmer using stringed numbers to track an order. Occam's Razor man!
Admin
Elementary, my dear Watson!
Admin
The inclusion of the cornify script in this story makes me wonder if there are other stories where I missed something similar.
Admin
Another clue: SMALLINT is a type in IBM DB2, 16 bit integer, range -32768 to 32767. Five digits, see? But not all of five digits. So I think the 99999 limit check is bogus.
Admin
SMALLINT is perfectly fine. It can hold values over 9000.
Admin
I can't understand how professional programmers can honestly declare that they don't understand COBOL. My view is that it's deliberate ignorance.
Admin
SMALLINT is perfectly fine. It can hold values over 9000.
Admin
Erm, SMALLINT isn't a DB2 datatype specifically, but a standard SQL one. Though the standard apparently doesn't prescribe its size, I haven't heard of any SQL implementation that defines the normal signed SMALLINT as anything but -32768 to 32767.
(And anyone who can't type those numbers by heart, or doesn't know why they are what they are, shouldn't be programming in any language.)
Admin
But do you know and can you type 2147483647 by heart?
Admin
I've managed stored procedure code where a dated changelog was part of the header, even though it was source controlled. Although redundant, because it's so much easier to deploy and mismatch stored procedures than executables (and many just end up getting passed around as loose scripts), it makes support way easier. If you're a software vendor, sometimes your client's problem could be diagnosed and fixed (and they're able to bill again) in an hour instead of a day or two.
I guess you can argue that fixes should never be deployed by changing a stored procedure manually, but when you know they're GOING to be whether you agree or not, having the DBA at least insist on being able to recognize it with a glance at the header sure helps.
This is especially important when (especially with legacy systems) you have a lot of logic in complex stored procedures instead of executables.
Admin
Yup. 0x7fffffff. Easy. :P
Admin
Why would you know the eighth Mersenne prime by heart?
Admin
"A conga-line of managers" - that line almost killed me. I visualize them, dancing to some Harry Belafonte :D
Admin
Get it virtualized first. Then you options: 1. Cloud data migration 2. Install it locally to the one guy in the office who needs it
Admin
"There's a hole in my program dear Liza, dear Liza ..."
Admin
Why WOULDN'T you know the 8th mersenne prime by heart?
Admin
It's a hobby. Nothing wrong with that. But get a real job, why don't you?
Admin
Today's WTF is about some piss poor comments, one variable modification, and a ton of assumptions?
Please give me something better, Remy. :( At least 90,000 lines of comments is disheartening and speaks to me on many sad and depressing levels... so that is certainly WTF material. But all in all, this small chunk does not satiate the appetite, no it does not...
Admin
More likely, the same developer that can't remember 32767 (and calls it "32000 something") also incorrectly assumed that the larger data type may have a decimal limit. It seems that this developer knows nothing more about data types and their storage formats beyond "use a bigger one when you run out of values". I highly doubt that there's actually any part of the system that imposes a restriction of 99999.
Admin
Huh. How about that? Didn't even know I knew the eighth Mersenne Prime.
Admin
You can plug it, Dear Henry, Dear Henry, with flour and water...
Admin
Or, you know, a database with a NUMBER(5) column. Because that's all you need to hold a SMALLINT, and when they changed the parameter datatype they didn't change the storage for it.
Admin
is this a hint that submitters should try to provide a bit more context?
Admin
Anything by Remy
Admin
I know all the Mersenne Primes, but it takes a long time to sort them by value and then count which one is the 8th smallest.
Admin
Yeah, from my experience, good chance it's a type that started out as a genuine 16-bit SMALLINT on one database, then got converted to a NUMBER(5) as part of an Oracle port due to Oracle not supporting traditional integer types.
Often, this results in mismatches – part of the code will still be treating the value as a 16-bit integer, the database will be treating it as a 5-digit decimal, and since a 5-digit decimal won't fit a 16-bit integer, newer code will end up treating it as a 32-bit integer. And since a 32-bit integer won't reliably fit a 5-digit decimal, you end up with a bunch of validation rules constraining the size of that integer to avoid breaking either the database or the old code.
Admin
My dear Hastings...
Admin
However in COBOL PIC 9(5) is not the maximum size one can declare, PIC 9(18) is.
Admin
Back in the good old days, before handheld calculators and interactive debuggers were a thing, knowing the powers of 2 by heart helped when you're debugging a crashed program using a printed hexadecimal dump at 2 o'clock in the morning.
Admin
The @PrevNumber paragraph needs to be read in Vizzini's voice. Follow up is:
PT: "You're really that smart are you? Remy: "Let's put it this way... have you ever heard of Niklaus Wirth? Dennis Ritchie? Donald Knuth?" PT: "yes..." Remy: "MORONS! where was I?" PT: "Business Integration..."
Admin
On the positive side, at least someone there understands YYYY-MM-DD format, except for the insistence on using slashes as separators.
Admin
Maybe because in everyday life a lot of people use '/' as a separator not '-'. Certainly in Western Europe the '/' is heavily used
Admin
Way to go Remy!!! This is exactly the kind of article that I come to TheDailyWTF to read -- not just "this happened" but a long, thoughful and thought-provoking analysis. I'm glad you took the time to tease out exactly what was happening here.
Admin
I've literally made this my mission in life, to convince people that YYYY-MM-DD is the only acceptable date format. I even made a spreadsheet to illustrate that it's the only format that even has a CHANCE of sorting correctly in things like filenames...
Most peoples' response is somewhere between "yeah yeah, ok" and "who let you in here?"
Admin
@As Scarlet_Manuka: "Or, you know, a database with a NUMBER(5) column. Because that's all you need to hold a SMALLINT, and when they changed the parameter datatype they didn't change the storage for it."
This looks to me like a rather ordinary effect of company growth on a database. Back when I was young (and everything ran on mainframes), both RAM and hard drive space were quite limited. So programmers would have to work out just how much space was needed for each field, and use no more than this. @PrevNumber originally was limited to less than 0 - 32,767, but might go over 9,999. The minimum necessary space was a 16 bit integer internally and unsigned 5-digit decimal for the database. Overflow was impossible in the smallint to 9(5) conversion, and no concern in the reverse conversion because the numbers just didn't get that big.
But eventually the domain grew until the limits of a signed integer-16 no longer were adequate. That's easy to change; they commented out the original definition and inserted a new definition. BUT the 5-digit database size is much more difficult to adjust; that would require inspecting, modifying, and recompiling every bit of software that accesses that database, and putting it all on-line at the same time along with copying the database to the new format. In the short term (that is, until they also bust through the 99,999 limit) , it's better to keep the database format unchanged and have the few pieces of code that enter or change this number check for fit in 5 digits.
Admin
"the one guy in the office who needs it" is probably the CEO, or somebody who kisses his a**. there's a lot of this kind of thing out there only because some bigwig insists that it be there.
Admin
nah, all U have to do is look it up on OEIS (oeis.org). U can find a lot of integer sequences there.
Admin
i, too, am older than digital dirt, and remember well being chastised for using a format statement in FORTRAN because it pulled in a 1K module that would otherwise be unneeded. however, i've always been a non-conformist, and even when strictly constrained to stupid limits by the powers-that-be, i often found ways to code in stubs and hooks to reduce the work necessary when future "expansion" became unavoidable. using "larger-than-necessary" datatypes in a database might have been a tad more noticeable, but i didn't usually do DB design, so it was usually somebody else's problem.
i didn't always get away with it, though. after i left one employer, the field engineer for the computer vendor came by my new place of employment to ask me about one of my programs; it had been butchered beyond recognition, so i was unable to help. at positions where i had been hanging around the job for a few years, however, it was usually an invaluable practice.