• Bas (unregistered)


  • Conradus (unregistered)

    Ah, mon ami, you use the little grey cells!

  • bvs23bkv33 (unregistered)

    no one understands cobol? let me explain then, 99999 is top for cobol pic9(5) datatype, and 100k overflows it

  • (nodebb)

    ...or... it was just a bad developer in a very simple environment <grin>

  • (nodebb)

    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!

  • Pista (unregistered)

    Elementary, my dear Watson!

  • Kaine (unregistered)

    The inclusion of the cornify script in this story makes me wonder if there are other stories where I missed something similar.

  • (nodebb)

    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.

  • What? I'm not giving you my name. (unregistered)

    SMALLINT is perfectly fine. It can hold values over 9000.

  • Quite (unregistered)

    I can't understand how professional programmers can honestly declare that they don't understand COBOL. My view is that it's deliberate ignorance.

  • What? I'm not giving you my name. (unregistered)

    SMALLINT is perfectly fine. It can hold values over 9000.

  • RLB (unregistered) in reply to CoyneTheDup

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

  • (nodebb) in reply to RLB

    But do you know and can you type 2147483647 by heart?

  • Brian Parker (google)

    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.

  • kb (unregistered) in reply to CoyneTheDup

    Yup. 0x7fffffff. Easy. :P

  • Colin (unregistered) in reply to CoyneTheDup

    Why would you know the eighth Mersenne prime by heart?

  • Leonardo Herrera (unregistered)

    "A conga-line of managers" - that line almost killed me. I visualize them, dancing to some Harry Belafonte :D

  • fragile (unregistered)

    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

  • Quite (unregistered) in reply to Leonardo Herrera

    "There's a hole in my program dear Liza, dear Liza ..."

  • Uhm (unregistered) in reply to Colin

    Why WOULDN'T you know the 8th mersenne prime by heart?

  • Sole Purpose of Visit (unregistered) in reply to Colin

    It's a hobby. Nothing wrong with that. But get a real job, why don't you?

  • Barf4Eva (unregistered)

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

  • anonymous (unregistered)

    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.

  • (nodebb) in reply to Colin

    Huh. How about that? Didn't even know I knew the eighth Mersenne Prime.

  • (nodebb) in reply to Quite

    You can plug it, Dear Henry, Dear Henry, with flour and water...

  • (nodebb)

    more than 5 characters to represent it is a problem. This obviously means that the target system is a mainframe with a flat-file storage model.

    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.

  • (nodebb)

    is this a hint that submitters should try to provide a bit more context?

  • Cornify (unregistered) in reply to Kaine

    Anything by Remy

  • Decius (unregistered) in reply to Uhm

    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.

  • Simon (unregistered) in reply to Scarlet_Manuka

    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.

  • 🤷 (unregistered) in reply to Conradus

    My dear Hastings...

  • DCL (unregistered) in reply to bvs23bkv33

    However in COBOL PIC 9(5) is not the maximum size one can declare, PIC 9(18) is.

  • DCL (unregistered) in reply to Colin

    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.

  • RichP (unregistered)

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

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    On the positive side, at least someone there understands YYYY-MM-DD format, except for the insistence on using slashes as separators.

  • SCL (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    Maybe because in everyday life a lot of people use '/' as a separator not '-'. Certainly in Western Europe the '/' is heavily used

  • DrPepper (unregistered)

    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.

  • oxfouzer (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

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

  • markm (unregistered)

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

  • b.a. freeman (unregistered) in reply to fragile

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

  • b.a. freeman (unregistered) in reply to Decius

    nah, all U have to do is look it up on OEIS (oeis.org). U can find a lot of integer sequences there.

  • b.a. freeman (unregistered) in reply to markm

    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.

Leave a comment on “The Mystery of the SmallInt”

Log In or post as a guest

Replying to comment #:

« Return to Article