• Norman Diamond (unregistered) in reply to donger
    donger:
    How did Grandma come up with that system
    I have a feeling she didn't. I think IBM machines were already using BCD when Grandma Hopper invented Cobol, and IBM didn't switch to pure binary until later. This is just a guess though.
  • Norman Diamond (unregistered) in reply to JamesCurran
    JamesCurran:
    In addition to binary integers and floating point numbers, IBM 360s (and I assume other IBM computerd of that era -- 1960s), had a data type called "packed decimal" which is essentially what we now call "binary-code decimal" (BCD).
    Older IBM computers only used packed decimal. The 360 retained the capability for compatibility, but it was a lot slower than pure binary.
    JamesCurran:
    so packed decimal became the standard data type used, particularly in COBOL, but I believe also in Fortran.
    Older IBM computers used BCD for floating point as well as fixed point, but the 360 dropped BCD floating point, so it wasn't quite as compatible as I wrote above. Anyway, Fortran used BCD on older computers because the computers did, but Fortran used pure binary on the 360. No wait, Fortran used hex floats on the 360 because the 360 used hex floats, not pure binary and not pure BCD. Anyway, PL/I and Cobol could use BCD fixed point when the programmer specified it.
    JamesCurran:
    So, to enter a negative number, you would type the number, then backspace, and over-type the last digit with a dash (minus sign).
    Close. Card punches didn't have a backspace key so you had to hold down the multipunch key while typing the other two keys. Paper tape punches had a backspace key, which is why rubout is rubout (0x37, all seven bits 1's, rubbed out the typo, if you noticed your typo in time).
    JamesCurran:
    Technically, numbers without on overpunched final digit were considered "unsigned". To force a number of be positive, you were supposed to over-punch it with the character which was just a Y-hole, which was... Ampersand (go figure).
    On an IBM 24 keypunch and computers of that era, a single punch in the 12 row was a plus sign. I don't know why they changed that punched character to be ampersand on the IBM 26 keypunch and 360 computer.
  • Norman Diamond (unregistered) in reply to eViLegion
    eViLegion:
    "We want our customers to be able to compare their spending this year to last year, and they wont be able to compare like with like if we fix all the reports now... please introduce the same systematic errors into your new reports."

    (Which means... "We've been defrauding these guys for over 15 years (albeit unintentionally), so we probably shouldn't tell them about it now.")

    I refused, and said I'm happy to do any other work they require, but I will only deliver these web reports AS IS, and do not wish to be made to communicate with (e.g. lie to) these customers any more, because that would make me complicit in fraud.

    Having a sense of ethics, I must applaud your answer. But I can't help wondering: Did you ever get a job again after that?

  • Edsger Dijkstra (unregistered) in reply to EvilSnack
    EvilSnack:
    As others have stated, the converted final character is indeed a way to depict signed numbers, and it isn't really a big surprise that someone can work for long enough to become the go-to person without encountering this.
    Who is that go-to person? We must eliminate them.

    Captcha: delenit Someone get me one of those paper tape punches. We need a rubout.

  • Norman Diamond (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Paper tape punches had a backspace key, which is why rubout is rubout (0x37, all seven bits 1's, rubbed out the typo, if you noticed your typo in time).
    And if I'd noticed my typo in time, that would have said 0x7F. Sigh.
  • Marcel (unregistered) in reply to Norman Diamond
    Norman Diamond:
    eViLegion:
    (Which means... "We've been defrauding these guys for over 15 years (albeit unintentionally), so we probably shouldn't tell them about it now.")

    I refused, and said I'm happy to do any other work they require, but I will only deliver these web reports AS IS, and do not wish to be made to communicate with (e.g. lie to) these customers any more, because that would make me complicit in fraud.

    Having a sense of ethics, I must applaud your answer. But I can't help wondering: Did you ever get a job again after that?

    Actually, I am wondering if not reporting it doesn't mean that he's complicit in fraud anyway?

  • Meep (unregistered) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    TRWTF is writing code to handle the zoned overpunch. COBOL takes care of that for you if you define the variable correctly. (or is TRWTF that I know this?)

    You would kind of expect that a language could convert to and from its native datatypes.

    TRWTF is she's doing a project with COBOL and hasn't taken the time to learn how numbers work.

  • Sebastian Ramadan (unregistered)
  • nasch (unregistered)

    I can't really defend the writing (as someone pointed out, opposable thumbs aren't necessary for hitting a space bar), but as many commenters seem unaware of, most New World monkeys don't have opposable thumbs.

    https://en.wikipedia.org/wiki/New_World_monkey

  • lesle (unregistered) in reply to JamesCurran

    (EBCDIC was IBM's alternative to ASCII, because IBM had to be different).

    ASCII has 128 "characters"; EBCDIC has 256.

  • (cs) in reply to Meep
    Meep:
    TRWTF is she's doing a project with COBOL and hasn't taken the time to learn how numbers work.
    Where in the article is it stated that she's doing a project with COBOL?

    The code in the article is SQR, not COBOL!

  • Jeff Grigg (unregistered) in reply to Paddles
    Paddles:
    Surely if Alicia was that much of a hot shot, she would have seen signed overpunch numbers before. Not uncommon if you've had to wrangle data from a COBOL system.

    Yes, the bug in the code snippet is a WTF. But the fact that the conversion table wasn't part of her toolset already is a bigger WTF, given the context.

    And yes, COBOL itself is an even bigger WTF.

    Exactly. It's even a bigger WTF for "the company's best expert at data conversion." Hasn't she interfaced with a "mainframe" before? An AS-400? This is absolutely standard stuff for doing ASCII processing of numbers that were processed in an IBM-360-style EBCDIC packed-decimal format. It's baked into the hardware. (So no, it's not just COBOL.)

    I personally have done this at least half a dozen different times in different projects in my career. And I do not specialize in data conversion. (But I do specialize in being old and experienced. ;-)

  • Robert (unregistered)

    Signed decimal? Pfah! Real men (and real women) let the numbers roll over, odometer-style!

  • Anonymous (unregistered) in reply to Barf 4Eva
    Barf 4Eva:
    honestly, fail to see the WTF... looks like EBCDIC for a VAX or something. But yeah, always fun reading files like that one... :|

    That is WRONG BEYOND WRONG.

    The VAX was a machine from Digital Equipment Corporation, and while some of the very large machines did start to resemble mainframes, VMS and the UNIX variants that lived on VAX were all ASCII. EBCDIC was an IBM thing for the IBM world.

    Though I do believe the companies which cloned IBM machines also used EBCDIC because... they cloned IBM machines.

    CAPTHCA: vindico

  • BillClintonsWeiner (unregistered) in reply to Mainframer
    Mainframer:
    For the record, that's a type of zoned decimal format. It's used when your flat file dataset has fixed width columns and you want to be able to represent a negative number without losing a digit.

    It was somewhat clever for 1979, but it should be avoided at all costs now.

    Ceridian Tax Services, this means you!

  • J (unregistered) in reply to ANON
    ANON:
    What does 2t mean? I only know from C the prefixes 0 for octal 0x for hexadecimal and the suffixes l for long and f for float. But t? Never heard.

    In x86 assembly language, you can use the suffix 't'/'T' to specify decimal numbers (I always assumed it stood for 'ten'). 'd'/'D' is also valid. However, if you change the default radix (for numbers with no suffix) to 16, then 't'/'T' is required for decimal, since 'd'/'D' are valid hex digits. (I'm not sure why they didn't worry about this with binary, since 'b'/'B' doesn't play nice with a default radix of 16 either...)

  • (cs) in reply to J

    I assumed 2t would be 2 in the trinary system. Which is of course equal to 2 in the decimal system. So no harm done. No WTF, nothing to see here, move along.

    Although the real WTF of the story is the assumption that business and intelligence go together.

  • CRConrad (unregistered) in reply to faoileag
    faoileag:
    Then again: at the time that system had been devised, monitors usually used slashed zeroes (like Ø, only with a zero) to avoid exactly that ambiguity.
    Which is still so damn sensible I wish modern fonts -- that is, at least the monospaced ones we use in programming -- had their zeroes slashed too.
  • (cs) in reply to CRConrad
    CRConrad:
    faoileag:
    Then again: at the time that system had been devised, monitors usually used slashed zeroes (like Ø, only with a zero) to avoid exactly that ambiguity.
    Which is still so damn sensible I wish modern fonts -- that is, at least the monospaced ones we use in programming -- had their zeroes slashed too.
    THEY D0.

    Why, what font were you using...

  • Y. A. N. Troll (unregistered)

    TRWTF is monkeys without opposable thumbs trololololol

  • Catprog (unregistered) in reply to Sal Undy
    Sal Undy:
    faoileag:
    Sal Undy:
    Not to mention the fact that the odds of every negative number ending in 6 are pretty long.
    I think you must have misunderstood something. To denote a negative number, a trailing "6" is replaced by an "O". For a negative number ending in, say, 5, the letter would be "N".

    So the number "2196O" that's mentioned in the text is equal to "-21966" (note the second six) in a non-signed-overpunch world.

    Right, that's exactly the point. The whole story hinges on the negative numbers being all camouflaged because they end with "O" instead of "0". It falls apart unless somehow every negative number ends in 6.

    Or the negative numbers that end in something other then 6 go through fine and with the lack of them the only parts of the data that are looked at contain a single negative number

  • Halo (unregistered) in reply to Mainframer

    Zoned decimal formats were also not intended for display so the bytes aren't supposed to make sense when decoded into ASCII or EBCDIC. The high nibble for each digit byte could potentially contain a different control value which would render it unreadable. It would be like complaining that the four bytes of an encoded 32-bit integer are gobbledygook. Good thing they weren't dealing with packed decimals.

Leave a comment on “'O'-Convertible”

Log In or post as a guest

Replying to comment #:

« Return to Article