The Program-Generator Program

« Return to Article
  • Chronomium 2012-06-19 10:14
    Kind of like the inner-platform effect, except more parallel.

    So "Motorcycle-Sidecar-Effect".
  • snoofle 2012-06-19 10:17
    article:
    ...at least he had job security

    ...until the assignment would unexpectedly end.
  • Steven Seagal's ponytail 2012-06-19 10:42
    The real WTF is the attempt at a general solution to the problem (lexer, parser, SED script, C/C++ code - really?) when just keeping a diff between customer revisions and manually making the change would be simpler and less error-prone. Instead of simply making the change the customer wants, they have to fix their program and massage the input data to get it to come out as expected.

    I understand the inclination to come up with a general solution, but the added layer of indirection can be a huge pain in the ass if you don't do it right. I have a coworker who does this with our app configurations, and instead of me just adding a line in a YAML file like I used to be able to do, I have to go in and patch his stupid program to accommodate it, then update all of our other apps that use the program to get the latest version. And he thinks this is saving us time and effort (and wonders why I get grumpy about it)...
  • PiisAWheeL 2012-06-19 10:46
    Steven Seagal's ponytail:
    The real WTF is the attempt at a general solution to the problem (lexer, parser, SED script, C/C++ code - really?) when just keeping a diff between customer revisions and manually making the change would be simpler and less error-prone. Instead of simply making the change the customer wants, they have to fix their program and massage the input data to get it to come out as expected.

    I understand the inclination to come up with a general solution, but the added layer of indirection can be a huge pain in the ass if you don't do it right. I have a coworker who does this with our app configurations, and instead of me just adding a line in a YAML file like I used to be able to do, I have to go in and patch his stupid program to accommodate it, then update all of our other apps that use the program to get the latest version. And he thinks this is saving us time and effort (and wonders why I get grumpy about it)...


    At least you have job security.
  • Quango 2012-06-19 10:47
    "...started back in the 1960s – long before anyone had heard of 3rd Normal Form... "

    Defined by Codd in 1971, so no they probably would not have heard of it. :)
  • Nagesh 2012-06-19 10:57
    Is it really that hard to parse that? It looks like a simple field-length mapping.

    Sorry, I mean, I am not being seeing a problem here in Hyderabad.
  • Axeman 2012-06-19 10:57
    Ah, The good old days eh?
  • MumpsGeek 2012-06-19 11:00
    Shouldn't be too hard to handle with a simple Cache (MUMPS) routine.

    Simples!
  • Anketam 2012-06-19 11:12
    This would not have been half as bad if the customer had a standardized format for reporting the changes. However changing the format of import data that frequently is generally a bad idea.
  • realmerlyn 2012-06-19 11:13
    It could have just been a single Perl program.

    /me ducks
  • pjt33 2012-06-19 11:20
    Why was the client changing their COBOL code that frequently? And why did the records need importing into an Oracle database weekly? They would surely have been better off either sticking to COBOL or transitioning to a non-COBOL system rather than trying to keep the two systems running in parallel with a constantly changing interface.
  • Scrummy 2012-06-19 11:26
    "COBOL-format record and record descriptors don't respond to change very well..."

    Only because they were built using archaic development methodologies.
  • Zylon 2012-06-19 11:28
    Of course, we all know how that story ends, and five decades later, COBOL programmers are still paying for that arrogance today.

    I honestly can't tell if Alex is speaking for or against COBOL here. Clearly COBOL did enough things right that it's still clinging to existence fifty years later.
  • @Deprecated 2012-06-19 11:29
    pjt33:
    Why was the client changing their COBOL code that frequently? And why did the records need importing into an Oracle database weekly? They would surely have been better off either sticking to COBOL or transitioning to a non-COBOL system rather than trying to keep the two systems running in parallel with a constantly changing interface.

    That was my thought too.
    What kind of production system database changes that fast, and in so many unexpected ways?
  • C-Derb 2012-06-19 11:31
    I had a job while going to college that was very similar to this. We were receiving data files from 1000+ customers, usually in Excel or Lotus format. There were 4 of us who spent all day manipulating these files into a fixed width format to be imported into our database.

    One week I got really grumpy about it, vented to my coworkers, vented to my roommates, cursed our clients while driving to and from work.

    Then I got my paycheck and realized it was exactly the same no matter what my attitude was. Things got better after that.
  • David Emery 2012-06-19 11:36
    He should have dug around the Open Source community. There's a bunch of code in Ada as part of the GNAT (open source) Ada compiler that interprets COBOL PIC statements (that I helped write about 15 years ago.) With that code, he could have fed the PIC statements and generated the associated read/write routines, reusing the design even if he didn't want to link the Ada routines in to C or C++ (another feature of Ada...) The syntax for PIC clauses is quite static, you should capture the grammar/semantics of COBOL once.

    But someone show me a similar big fat ugly messy data structure definition in some other language. Do you think that struc definitions for this data in C would be less readable? He should be grateful for COBOL's ability to represent this structure, even if it was un-normalized....
  • steve 2012-06-19 11:37
    http://sourceforge.net/projects/cb2xml/

    there are many standard copybook translators
  • Sayer 2012-06-19 11:37
    C-Derb:
    I had a job while going to college that was very similar to this. We were receiving data files from 1000+ customers, usually in Excel or Lotus format. There were 4 of us who spent all day manipulating these files into a fixed width format to be imported into our database.

    One week I got really grumpy about it, vented to my coworkers, vented to my roommates, cursed our clients while driving to and from work.

    Then I got my paycheck and realized it was exactly the same no matter what my attitude was. Things got better after that.


    So the problem remained, but you just chose to not let it get you down.
  • AB 2012-06-19 11:44
    When did Pat become James?

    "When you've been in IT for as long as Pat McGee,..."

    ABCD123456MCGEE JAMES PACCTAR ABCD65432104250CLRK010195INTN010397

    Oh I see it now, Pat is his middle name and he's one of those weirdo's that uses their middle name rather than their given name.
  • Medinoc 2012-06-19 11:45
    Steven Seagal's ponytail:
    The real WTF is the attempt at a general solution to the problem (lexer, parser, SED script, C/C++ code - really?) when just keeping a diff between customer revisions and manually making the change would be simpler and less error-prone. Instead of simply making the change the customer wants, they have to fix their program and massage the input data to get it to come out as expected.

    I understand the inclination to come up with a general solution, but the added layer of indirection can be a huge pain in the ass if you don't do it right. I have a coworker who does this with our app configurations, and instead of me just adding a line in a YAML file like I used to be able to do, I have to go in and patch his stupid program to accommodate it, then update all of our other apps that use the program to get the latest version. And he thinks this is saving us time and effort (and wonders why I get grumpy about it)...

    Well, I guess in both cases, the programmer of the intermediary layer expected it to work for everything the input could throw at it. It proved false, but "on paper" it would have saved everybody's time... If it worked.
  • markfiend 2012-06-19 11:47
    My first proper coding job was a bit like this. Not quite COBOL but I was pulling data out of text files that had not-quite-fixed-width columns and numeric-fields-except-when-they-contain-a-letter and all sorts of similar exceptions.

    To complicate things further it was a two-dimensional set of rules (the client's customer's address will be in columns 60-80 on lines 5-10, that sort of thing) that had originally been designed to be printed by a dot-matrix printer onto pre-printed labels. I have no idea why whatever-it-was that produced those text files couldn't have been changed to send the data straight to the database but hey, it was a job.

    I did what I could to keep it maintainable, and to be fair I've never had my former employer ring me up asking for help. AFAIK my script is still working away on those horrible text files.

    Addendum (2012-06-19 11:55):
    customer's address will probably be in columns 60-80 on or around lines 5-10
  • ¯\(°_o)/¯ I DUNNO LOL 2012-06-19 11:47
    >At the heart of the system was a
    Mmm hmm...
    >10,000 line
    okaaay...
    >COBOL
    ummmm...
    >record descriptor
    (TURNS WHITE AS A SHEET)


    But TRWTF is an actual WTF on Tuesday, amirite?!
    (So the by Principle of Equivalent Exchange we're going to miss Wednesday or Thursday, of course.)
  • Steven Seagal's ponytail 2012-06-19 11:50
    Right. If it works, you're a hero. If it doesn't work - well now you have two problems.
  • Steven Seagal's ponytail 2012-06-19 11:51
    Medinoc:

    Well, I guess in both cases, the programmer of the intermediary layer expected it to work for everything the input could throw at it. It proved false, but "on paper" it would have saved everybody's time... If it worked.

    Right. If it works, you're a hero. If it doesn't work - well now you have two problems.
  • C-Octothorpe 2012-06-19 11:52
    Sayer:
    C-Derb:
    I had a job while going to college that was very similar to this. We were receiving data files from 1000+ customers, usually in Excel or Lotus format. There were 4 of us who spent all day manipulating these files into a fixed width format to be imported into our database.

    One week I got really grumpy about it, vented to my coworkers, vented to my roommates, cursed our clients while driving to and from work.

    Then I got my paycheck and realized it was exactly the same no matter what my attitude was. Things got better after that.


    So the problem remained, but you just chose to not let it get you down.
    No, he went to work the following day with his favourite automatic weapon...
  • C-Derb 2012-06-19 12:03
    C-Octothorpe:
    No, he went to work the following day with his favourite automatic weapon...

    I would never condone that, but if you must, please shoot yourself first to make sure the weapon is working, then shoot others.
  • MBV 2012-06-19 12:15
    So why didn't he write a COBOL program that fed the COBOL structures to Oracle? Seems like a lot easier to me, as Oracle has an interface for COBOL.
  • nB 2012-06-19 12:16
    realmerlyn:
    It could have just been a single Perl program.

    /me ducks
    Honestly, I think that's what I would have done. I did something similar when we had a particular program at my lab that needed a massive struct{} for register map that changed from project to project. It was always given in an xls file (8 megs or so) and used to be manually transcoded to c structs. I wrote a perl script to do it. My job role was allocated two weeks for that activity, my script did it in 40 seconds. I got a promotion out of that :/
  • Anderson Silva 2012-06-19 12:17
    Steven Seagal's ponytail:
    ...
    Less talky, more front-kicky.
  • ur 2012-06-19 12:19
    C-Derb:
    C-Octothorpe:
    No, he went to work the following day with his favourite automatic weapon...

    I would never condone that, but if you must, please shoot yourself first to make sure the weapon is working, then shoot others.

    Surely it's simpler just to carry a spare gun?
  • Nagesh 2012-06-19 12:20
    DATAPUMP ==> is feature of Oracle. It will allow you to pump data from any source.
  • Dave 2012-06-19 12:35
    Steven Seagal's ponytail:
    The real WTF...general solution to the problem...manually making the change would be simpler and less error-prone...they have to fix their program...inclination to come up with a general solution....added layer of indirection...huge pain in the ass...get grumpy about it...


    Loving all the "well that doesn't sound like a particularly good way to do things" comments today.

    It's The Daily WTF, guys. That's kind of the point.
  • myName 2012-06-19 12:39
    Two real WTFs - not using COBOL to write the translation program, and changing to Oracle.
  • PedanticCurmudgeon 2012-06-19 12:51
    Did Pat actually know COBOL, or did someone just show him how to read record descriptors?
  • Mason Wheeler 2012-06-19 12:57
    So what the article is basically saying is that his sufficiently complicated C++ program ended up containing an ad hoc, informally-specified, bug-ridden, slow implementation of half of COBOL? :P
  • Andrew 2012-06-19 13:07
    Steven Seagal's ponytail:
    Instead of simply making the change the customer wants, they have to fix their program and massage the input data to get it to come out as expected.
    Feke Nagesh detected!
  • MindChild 2012-06-19 13:09
    Nagesh:
    Is it really that hard to parse that? It looks like a simple field-length mapping.

    Sorry, I mean, I am not being seeing a problem here in Hyderabad.


    Yes, it is. You see, the currency field will have commas... sometimes. And the record is comma delimited. The middle name field will... sometimes... have a char(13) instead of a space. And so on
  • Slapout 2012-06-19 13:16
    nB:
    realmerlyn:
    It could have just been a single Perl program.

    /me ducks
    Honestly, I think that's what I would have done. I did something similar when we had a particular program at my lab that needed a massive struct{} for register map that changed from project to project. It was always given in an xls file (8 megs or so) and used to be manually transcoded to c structs. I wrote a perl script to do it. My job role was allocated two weeks for that activity, my script did it in 40 seconds. I got a promotion out of that :/


    How long did it take you to write the script?
  • Sayer 2012-06-19 13:17
    C-Derb:
    C-Octothorpe:
    No, he went to work the following day with his favourite automatic weapon...

    I would never condone that, but if you must, please shoot yourself first to make sure the weapon is working, then shoot others.


    I used to work at a fairly prominent Telecomm and we were so inundated with procedural (and managerial) stupidity that my coworkers would joke that if anyone ever showed up one day with a gun, all the other employees would be annoyed that they hadn't been notified and had left their guns at home.

    "Christ! It's gun day?! Why did no one tell me?! Do I have time to run home and get mine?"
  • d 2012-06-19 13:41
    Kill it! Kill it with fire!!!
  • Geoff 2012-06-19 13:48
    That was my first thought as well. Surely there had to be some simpler way to figure out what record type you are working with and use the correct copy book ahead of time, and just version the copy books.
  • Coyne 2012-06-19 13:58
    Quango:
    "...started back in the 1960s – long before anyone had heard of 3rd Normal Form... "

    Defined by Codd in 1971, so no they probably would not have heard of it. :)


    Like that matters. These people were like Mel: Even if they'd heard of it, they wouldn't have used it. It would have infringed on their freedom. "Besides, how would you optimize your data retrieval?"

    (I know: I were one.)
  • Jay 2012-06-19 14:03
    C-Octothorpe:
    No, he went to work the following day with his favourite automatic weapon...


    That wouldn't have worked at my last company. They had an Official Company Policy that any employee who brought a gun to work was "subject to disciplinary action, including suspension or termination". Someone might come to work and start shooting everyone in sight when the penalty is just life in prison or being killed by the SWAT team when they arrive to stop him. But the prospect of being suspended for two weeks without pay -- who would dare? I could stand 30 years in prison as long as I knew that I could get my old job back when I got out, but wow ...
  • Jay 2012-06-19 14:09
    steve:
    http://sourceforge.net/projects/cb2xml/

    there are many standard copybook translators


    In fairness, if the original poster's problem was that he couldn't get his translator to successfully translate a COBOL layout to a C struct, then one could fairly say that that isn't really that difficult a problem. Sure, maybe his first pass he forgot to handle OCCURS clauses or "V" in format specifiers or whatever, but you'd think with a few iterations he could get that worked out.

    But I presume he had to do some sort of processing. I mean, it's not enough to just have the C struct, you have to actually move the data across. That adds another level of complexity. Was it just a straight data move, copy "name" to "name", "account number" to "account number", etc? Or did he have to figure out record types, do data translations, etc.
  • RichP 2012-06-19 14:13
    realmerlyn:
    It could have just been a single line of Perl p̶r̶o̶g̶r̶a̶m̶.

    /me ducks


    FTFY

    /me ducks too.
  • Nagesh 2012-06-19 14:18
    Jay:
    C-Octothorpe:
    No, he went to work the following day with his favourite automatic weapon...


    That wouldn't have worked at my last company. They had an Official Company Policy that any employee who brought a gun to work was "subject to disciplinary action, including suspension or termination". Someone might come to work and start shooting everyone in sight when the penalty is just life in prison or being killed by the SWAT team when they arrive to stop him. But the prospect of being suspended for two weeks without pay -- who would dare? I could stand 30 years in prison as long as I knew that I could get my old job back when I got out, but wow ...

    Idiot. Ain't policy said about shooting: only about posession.
  • Nagesh 2012-06-19 14:30
    Sounds like someone tried to parse a programming language by extrapolating from a single example rather than actually consulting the language specification. (Yes, even Cobol has specifications.)

    Serves them well, I say.
  • trtrwtf 2012-06-19 14:41
    Jay:
    C-Octothorpe:
    No, he went to work the following day with his favourite automatic weapon...


    That wouldn't have worked at my last company. They had an Official Company Policy that any employee who brought a gun to work was "subject to disciplinary action, including suspension or termination". Someone might come to work and start shooting everyone in sight when the penalty is just life in prison or being killed by the SWAT team when they arrive to stop him. But the prospect of being suspended for two weeks without pay -- who would dare? I could stand 30 years in prison as long as I knew that I could get my old job back when I got out, but wow ...


    I know, right?
    'cause the only reason anyone would ever bring a gun to work would be to shoot the place up...
  • Sales Geek 2012-06-19 14:46
    Looks fine because it's a simple example. Wait until you see three pages of REDEFINE segments.
  • DCRoss 2012-06-19 14:52
    That sounds familiar.

    My first job was programming binary load lifters^H^H^H^H^H automated weather stations, each of which spit out a line of text which looked almost but not quite entirely unlike the report from any other weather station. I needed to identify all of the different variations of format and field placement, locate missing fields because some stations just didn't report everything all of the time, and somehow feed it all into a database so it could be used for weather simulations.

    It was something like getting reliable data from a GPS while someone kept unplugging it and connecting a different model every five seconds.

    Fortunately, I didn't have job security and stuck somebody else with the problem after only a few months.
  • Bill T 2012-06-19 14:56
    I use to support a mainframe billing system were the inputs came from each department. Each department created the inputs using what ever program generator / report write / spreadsheet they liked.

    The solutions was a Cobol program that used a 6 dimensional array to map the input file from each department into the output format.

    After I wrote that, all we had to do was edit the parameter file each week.

    10 years after I wrote that, a buddy who was still working at that bank told me. They forced each department to use the exact same output format. But they still ran it with my program to catch any bad data before it hit the main billing system. They just edit the parameter file for the new input format. They never had to change the cobol, as far as I know that program is still running.


    FYI,,,, back in the 80's I worked for Digital Equipment Corp. (DEC)

    One of my main jobs was to convert Cobol programs from what ever system they ran, to the DEC VAX systems.

    Also did system performance optimization, It was not uncommon to take a Cobol program that took 24 hours or longer, make a few changes and have it run in 8 hours or less.

    The key was understanding that the data format in the old program was based on old storage (drum, tape), and that some of the hardware instructions on the old machines were emulated in hardware on the new machines (packed decimal instructions etc.

    Bill T
  • Buffoon 2012-06-19 15:02
    Nagesh:
    Sounds like someone tried to parse a programming language by extrapolating from a single example rather than actually consulting the language specification. (Yes, even Cobol has specifications.)

    Serves them well, I say.


    Methinks you forgot to change your name back to whatever you use when not Nageshing with the rest of them.
  • PedanticCurmudgeon 2012-06-19 15:24
    Buffoon:
    Nagesh:
    Sounds like someone tried to parse a programming language by extrapolating from a single example rather than actually consulting the language specification. (Yes, even Cobol has specifications.)

    Serves them well, I say.


    Methinks you forgot to change your name back to whatever you use when not Nageshing with the rest of them.
    But he is Nageshing with the rest of them, in an effort to improve the general level of Nageshing. Just between us, I don't think it's working, but time will tell.
  • Tasty 2012-06-19 15:57
    pjt33:
    Why was the client changing their COBOL code that frequently? And why did the records need importing into an Oracle database weekly? They would surely have been better off either sticking to COBOL or transitioning to a non-COBOL system rather than trying to keep the two systems running in parallel with a constantly changing interface.


    ...or transition to a COBOL with Oracle solution. The Oracle Embedded SQL suite includes Pro*COBOL, and Pro*C to get it out later. The Pro*COBOL code can read DATA DIVISION code like the record here.
  • herby 2012-06-19 16:07
    So, let me get this straight...
    You write a program to parse Cobol data definitions.
    Isn't that what a Cobol compiler does?
    So, you are just writing a Cobol compiler (or a small, or not so small, subset of it)? Sounds like inventing a wheel here. Someone will say "been there, done that". If you ARE writing a Cobol data definition parser, you should really look at the language specifications. They have all sorts of clues as to how these things are written.

    As to WTF's, I don't know which is worse: Cobol, or something "modern" like XML. At least Cobol has been around for over 50 years, and has some history around it, warts and all. XML seems fleeting by comparison!
  • AnotherMumpsGeek 2012-06-19 16:08
    I agree. A simple Cache (MUMPS) routine would easily handle that.
  • Gunslinger 2012-06-19 16:08
    Frakking COBOL. But the Real WTF is customers.
  • Some Guy 2012-06-19 16:14
    Zylon:
    Of course, we all know how that story ends, and five decades later, COBOL programmers are still paying for that arrogance today.

    I honestly can't tell if Alex is speaking for or against COBOL here. Clearly COBOL did enough things [b]that cost too much to replace everything still{/b] that it's still clinging to existence fifty years later.


    FTFY
  • Spewin Coffee 2012-06-19 16:27
    Steven Seagal's ponytail:
    Medinoc:

    Well, I guess in both cases, the programmer of the intermediary layer expected it to work for everything the input could throw at it. It proved false, but "on paper" it would have saved everybody's time... If it worked.

    Right. If it works, you're a hero. If it doesn't work - well now you have two problems.


    This is what backups are for. You save the previous code in case it needs to be reverted.
  • C-Derb 2012-06-19 16:28
    Some Guy:
    Zylon:
    Of course, we all know how that story ends, and five decades later, COBOL programmers are still paying for that arrogance today.

    I honestly can't tell if Alex is speaking for or against COBOL here. Clearly COBOL did enough things that cost too much to replace everything still that it's still clinging to existence fifty years later.


    FTFY

    FTFY
  • fwip 2012-06-19 16:58
    The real WTF is writing sed in ALL-CAPS. But I guess after a while, the COBOL starts to get to you.
  • Matt Westwood 2012-06-19 17:07
    (*yawn*) yeah yeah bin there dun that. Except back in 1998 we converted a COBOL system to a FORTRAN one. Writing a parser for the general COBOL record descriptor was rather more worthwhile than creating a separate program for each COBOL file we were given. The difference between this story and that one is that after 3 weeks the program worked like a dream and didn't need to be touched for a decade, no matter how many times the source file changed.

    Oh, and we never converted the FORTRAN program to a more modern language. It was supposed to be upgraded to a C++ / Java / whatever-bollocks system but it worked so well the customer didn't see the benefit of changing it.
  • Ted 2012-06-19 17:47
    "virtual tapes"
    I think I just died a little.
  • Jerry 2012-06-19 17:58
    Jay:
    Someone might come to work and start shooting everyone in sight when the penalty is just life in prison or being killed by the SWAT team when they arrive to stop him. But the prospect of being suspended for two weeks without pay -- who would dare?
    Congratulations! You have plugged in to the mentality of gun-grabbers everywhere. "Yeah, there's already six laws against murdering someone, but if we add just one more that'll finally scare them off!"
  • Linus 2012-06-19 18:03
    fwip:
    The real WTF is writing sed in ALL-CAPS. But I guess after a while, the COBOL starts to get to you.
    SED is sed reimplemented in COBOL, for those who don't have a real OS.
  • Carl 2012-06-19 18:07
    You're not a real programmer until you've written something to parse data that usually has the date somewhere near column 60 of line 3 except when it wraps to line 4.

    You're not a real man until you've written your own program generator.

    And you don't get permission to use your balls until you've realized that the program-to-generate-a-program could be optimized by simply implementing some self-modifying code!
  • brazzy 2012-06-19 18:22
    Zylon:
    I honestly can't tell if Alex is speaking for or against COBOL here. Clearly COBOL did enough things right that it's still clinging to existence fifty years later.

    Yeah, but it completely failed to deliver on its original promise to be the language that would make professional programmers obsolete by allowing business users to write their own programs.
  • Meep 2012-06-19 19:22
    "long before anyone had heard of 3rd Normal Form"

    So, Boyce and Codd revised 3NF and devised BCNF, and in fact there is a fourth and fifth normal form that all databases can be normalized to. See Chris Date's Introduction to Database Systems if you're not familiar with these terms.

    The motivation is simple: Every redundancy that you can squeeze out of your schema is a whole host of stupid Heisenbugs you'll never have to deal with.
  • PRMan 2012-06-19 19:54
    realmerlyn:
    It could have just been a single line of Perl

    /me ducks


    FTFY
  • foxyshadis 2012-06-19 20:49
    This is a perfect capture of Zawinski's Law: When you have a problem and solve it with regular expressions, now you have two problems.

    (I am not spam!)
  • iiSel 2012-06-19 22:25
    I'm going to have to go with Chen - 1968 on that one.
  • Pat McGee (OP) 2012-06-19 22:35
    For those who suggested various solutions:

    1) This was done in around 1997. Much of what you suggested didn't exist back then.

    2) There's a lot of complexity here that I hinted at but didn't point out explicitly. Given a 10,000 line record format, how likely is it that this will fit into only one table? Or even just a few? Or that there's anywhere close to a 1-1 correspondence between the input records and the rows in various tables?

    Look back at the example of the record. See the pseudo-array, "02 PAST-JOB-CODES"? That's great for COBOL records, but anathema to relational tables. That data has to go into a separate table from the main record, and that table will get anywhere between 0 and 3 rows for each row in the EMPLOYEE-REC table.

    We ended up with around 200 tables, with lots of dependencies and cardinalities that varied between 1-1, 1-M, 0-M, and a few M-M.

    Those complexities were why most simple solutions simply wouldn't cut it.

    3) Not to mention the volume. We got around 1-10 million records a week, each record being somewhere between 10 and 1000 lines of data.


    4) Some of you expressed concerns about the requirements, saying that changing the requirements would have led to better solutions. Like changing the whole system to Oracle and dumping COBOL. I completely agree. The customer had actually tried that, spent several billion $ on it, and failed. I sure wasn't gonna try that again, not on the measly couple-million $ a year they paid us.
  • Decius 2012-06-20 01:43
    DCRoss:
    That sounds familiar.

    My first job was programming binary load lifters^H^H^H^H^H automated weather stations, each of which spit out a line of text which looked almost but not quite entirely unlike the report from any other weather station. I needed to identify all of the different variations of format and field placement, locate missing fields because some stations just didn't report everything all of the time, and somehow feed it all into a database so it could be used for weather simulations.

    It was something like getting reliable data from a GPS while someone kept unplugging it and connecting a different model every five seconds.

    Fortunately, I didn't have job security and stuck somebody else with the problem after only a few months.

    What's so hard about parsing [LOCATION ID] [type of observation: (METAR/SPECI)] [TIME]Z [WIND]KT [VISIBILITY]SM [OBSTRUCTION TO VISIBILITY/PRESENT WEATHER] [TEMPERATUTE]/[DEWPOINT] [ALTIMITER] [REMARKS]

    KBOS METAR 1652Z 05012G17KT 5SM BR 13/13 A3023

    You might have trouble parsing the remarks for the information that you consider interesting, but only if you don't have a clear idea of what you consider interesting.

  • Ru 2012-06-20 03:01
    You crazy kids and your "just write a perl script to do it!"

    For a little while I worked as a technical support monkey for a company which was making language examination software. All the critical data in one particular application was held together in an inadequately secured and poorly specified interbase database.

    There was a particular, and common, database corruption for which the support team had always previously asked the developers to sort out, and getting developer time for a support issue ate up the internal budget (a WTF in itself).

    As the new and least clueless member of the team, I compared the before and after databases for one of these corruption fixes, and worked out that the actual changes that needed to be done weren't that complex. A couple of dozen lines of perl would have sorted it out a treat. I suggested that I could do this and was soundly shut down.

    Neither the application developers nor internal IT wanted to risk a non-developer writing a tool that might become critical to the helpdesk monkeys, because what if that developer left and they had to maintain it in the future? No, they would continue to require that hours of customer and helpdesk time was wasted whilst we waited for a developer to fix things, and the helldesk budget dried up a little more each time.

    I'm very happy to say that I left there very shortly after that particular rejection.
  • holli 2012-06-20 03:08
    I'm surprised there's nothing for parsing COBOL data on CPAN.
  • WinDef 2012-06-20 04:18
    At my first client i had to export via script information from a database for printing.
    It was a pain cause the "standard comapny print layout" had to be followed no matter what.
    And after so much pain i finaly had my meeting to present the first print out.
    I never forget what followed next: my boss "why do you used a script?" - "cause you told me to? remeber like 2 weeks ago?" - "no - i dont want that anymore , i want to copy & paste the information into standard ms word document" ...

    ... so yes instead of using a script over 40 people now copy paste and doing it the old school day.
  • Anonymouse 2012-06-20 04:26
    They should have simply used a neural network; after an initial training periog for learning how to make the necessary changes it should be able to to them on its own...
  • Mike 2012-06-20 05:28
    In COBOL, MOVE CORRESPONDING says "Hi"
  • Dim 2012-06-20 05:33
    +1
    It's a lot easier to insert directly from cobol to database without external solution.
  • radarbob 2012-06-20 09:21
    brazzy:
    Zylon:
    I honestly can't tell if Alex is speaking for or against COBOL here. Clearly COBOL did enough things right that it's still clinging to existence fifty years later.

    Yeah, but it completely failed to deliver on its original promise to be the language that would make professional programmers obsolete by allowing business users to write their own programs.


    The original promise was not to "make professional programmers obsolete", but surely the hope was to take programming to the masses so to speak.

    In the context of the times, we're talking going from machine & assembler language with all their inherent challenges to something clearly more intuitive. The difference is far beyond today's "C++ vs C#" kind of arguments.

    As one wiser than I said "COBOL is the worst language for business applications, except for all the others."
  • Old Weather Comm Guy 2012-06-20 10:23
    Decius:

    What's so hard about parsing [LOCATION ID] [type of observation: (METAR/SPECI)] [TIME]Z [WIND]KT [VISIBILITY]SM [OBSTRUCTION TO VISIBILITY/PRESENT WEATHER] [TEMPERATUTE]/[DEWPOINT] [ALTIMITER] [REMARKS]

    KBOS METAR 1652Z 05012G17KT 5SM BR 13/13 A3023

    You might have trouble parsing the remarks for the information that you consider interesting, but only if you don't have a clear idea of what you consider interesting.


    Trust me. There are automated obs systems that can only fantasize about emitting METARs. I had a job similar to Decius once, and the variability among different vendors was startling, even to my jaded eyes.

    As far as I could tell, the vendors tended to offer "complies with international data format standard" as an extra-price option, and the customer did a faulty cost-versus-cost analysis and decided it would be cheaper to do a format conversion at the weather processing system rather than pay for a standard format at the observation system.

    There's an entire category of WTFs regarding data format standards that could be written from that.
  • Nagesh 2012-06-20 10:34
    Pat McGee (OP):
    Like changing the whole system to Oracle and dumping COBOL. I completely agree. The customer had actually tried that, spent several billion $ on it, and failed.

    Sounds like the customer had bigger problems than that then (as in, they would deserve to be in this site).
  • Bill T 2012-06-20 11:01
    What was your most outlandish Cobol application?

    Back in the 80's while working for DEC. I wrote a Cobol system for a small insurance company to print policies on the DEC laser printers.

    The policies were formatted using DEC Runoff, so they were binary files. Of course DEC Cobol did not officially support binary file formats.

    The way it worked was,
    1) Create an empty binary file format from the Cobol program using a system service call.
    2) extract the data from the database.
    3) add page positioning data and write it to the empty file
    4) use a system service call to spawn a "convert" command to append the policy pages and the file created by Cobol.
    5) Call a system service to send the created policy file to the printer.


  • Ryan 2012-06-20 11:41
    Bill T:
    Cobol application ... I wrote a Cobol system
    No you didn't. If you were around when COBOL was around you'd know (1) COBOL is upper case (2) they were called COBOL programs not "applications".

    A "program" is short for a "computer program" -- a series of instructions for a computer to follow.

    At first, most programs were "system programs" -- code written merely to try to get the system to work. Your own print driver, or hard disk badspot handler. Because the vendor didn't supply one.

    Once you got all your system programs working, you were free to apply this newfandangled technology to a business problem. That's what it was called -- an application of technology to a problem. You "apply" a thing to a thing. You don't just "apply" and end the sentence there.

    Soon this was shortened to "system programs" and "application programs". It was still an adjective, not a noun. (Apologies to the 95% of you who don't understand English sentence structure.)

    People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.
  • iToad 2012-06-20 11:48
    My most outlandish COBOL moment? Back in the 70s, I had a COBOL app which seemed to have stopped writing tape marks at the end of data blocks on 7-track magnetic tape. To prove this, I read the tape by hand.

    The bit density on the tapes back then was so low, that you could use a special reader to actually see the magnitized areas. It was a thin plastic strip about a foot long, filled with some sort of brown ferrite material behind a clear window. When you put it over the tape and tapped it, the magnitized bits in each frame turned black.

    I unwound some tape, put the reader on it, and started a voyage of discovery looking for the magic tapemark pattern. Indeed, they were missing, thanks to a mispunched card (we still used them) in the COBOL source deck.
  • trtrwtf 2012-06-20 11:54
    Ryan:

    People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.


    Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
    All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.
  • PiisAWheeL 2012-06-20 12:24
    PedanticCurmudgeon:
    Buffoon:
    Nagesh:
    Sounds like someone tried to parse a programming language by extrapolating from a single example rather than actually consulting the language specification. (Yes, even Cobol has specifications.)

    Serves them well, I say.


    Methinks you forgot to change your name back to whatever you use when not Nageshing with the rest of them.
    But he is Nageshing with the rest of them, in an effort to improve the general level of Nageshing. Just between us, I don't think it's working, but time will tell.

    Improving the general level of nageshing is like Serverside Javascript... You could but why bother?
  • pantsman 2012-06-20 12:45
    Ryan:
    People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.


    Application is already a noun!
  • Bananas 2012-06-20 13:02
    ¯\(°_o)/¯ I DUNNO LOL:
    >But TRWTF is an actual WTF on Tuesday, amirite?!
    (So the by Principle of Equivalent Exchange we're going to miss Wednesday or Thursday, of course.)

    You're prescient.
  • Matt Westwood 2012-06-20 13:06
    trtrwtf:
    Ryan:

    People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.


    Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
    All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.

    What! In what language does "apps" mean "food"?
  • Jay 2012-06-20 13:19
    trtrwtf:
    Ryan:

    People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.


    Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
    All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.


    ... Then one of us mentioned that we programmed in Perl. So she immediately called the bouncer and had us all thrown out. "This is a high-class place!" she yelled at us.

    There, finished the story for you.
  • PedanticCurmudgeon 2012-06-20 13:21
    Matt Westwood:
    trtrwtf:
    Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
    All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.

    What! In what language does "apps" mean "food"?
    It's probably short for appetizers.

    EDIT: To be fair, appetizers in most bars in America shouldn't really count as food.
  • Jay 2012-06-20 13:45
    herby:
    So, let me get this straight...
    You write a program to parse Cobol data definitions.
    Isn't that what a Cobol compiler does?
    So, you are just writing a Cobol compiler (or a small, or not so small, subset of it)? Sounds like inventing a wheel here.


    I presume you mean "re-inventing the wheel here". But anyway: Maybe so, but so what? What do you propose that he should have done instead? Found the source code for the COBOL compiler and extracted and repurposed the code that parsed data definitions? I rather suspect that that would have been far more work than starting from scratch.

    I think that "re-inventing the wheel" cliche is seriously flawed anyway. After all, in real life, companies "re-invent" literal, physical wheels every day. It's not like there's one wheel factory that makes one kind of wheel and that's what everybody in the world uses for every application. You do not use the same wheels on a child's tricylcle that you use on a 50-ton earth-moving machine. It is not at all unreasonable to suppose that the specific characteristics of a wheel for one vehicle might not be ideal for another. Indeed, when I recently got new tires for my pick-up I had a choice of many options, from a range of qualities to whether I wanted highway tires or off-road tires. Even for the same vehicle I might choose different wheels depending on how I intended to use the vehicle.

    Furthermore, manufacturing companies regularly consider whether to "make or buy", that is, whether it is more efficient and economical to buy something from an outside source or to make it themselves, based on a variety of factors.

    The same is true of software. Just because someone else has written, say, an accounting system, doesn't mean that it is stupid for anyone else to write his own accounting system. We might have different requirements and different priorities. Or we might just think that we can do it better.

    I often hear people say that it's dumb to write software yourself when you can download what you need from the Internet for free. But software downloaded from the internet may be available at no charge, but that does not make it free. Why would we download such "free" software rather than writing it ourselves? Surely the cost being considered is the time of our employees. But does it take zero time to download free software? No. Someone must take time to search the Internet to find candidate products. We must take time to read the descriptions to see if this sounds like it meets our needs. Then we must download them and install them on our local computer. We must learn how to properly configure the software. We must learn how to use it. Then we have to study the details of its features to see if it really does meet our needs. If not, we may be able to customize it, but that means getting the source code and decyphering that. If it doesn't meet our requirements and we can't customize it, then we have to start the process all over with another product.

    In some cases, of course, that is well worth the effort. In other cases it would be easier to just write what we need ourselves. I would need very unusual requirements before I would write my own database engine. But if I need a function that I know I can write and debug in a couple of hours, I'll just do it.
  • DCRoss 2012-06-20 14:00
    Decius:

    What's so hard about parsing [LOCATION ID] [type of observation: (METAR/SPECI)] [TIME]Z [WIND]KT [VISIBILITY]SM [OBSTRUCTION TO VISIBILITY/PRESENT WEATHER] [TEMPERATUTE]/[DEWPOINT] [ALTIMITER] [REMARKS]


    My question at the time was "What's so hard about reporting in that format?", since much of the data we received didn't follow it.

    But that became somebody else's problem decades ago.
  • C-Derb 2012-06-20 14:04
    trtrwtf:
    Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
    All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.

    It wasn't until I read the word "food" that I realized she was talking about appetizers. I was trying to remember if I'd heard of a new kind of bar that sells alcoholic drinks and smart phone applications. When's the IPO, amirite?
    PedanticCurmudgeon:

    EDIT: To be fair, appetizers in most bars in America shouldn't really count as food.

    +1
  • C-Derb 2012-06-20 14:13
    Jay:

    My understanding of that "re-inventing the wheel" cliche is seriously flawed....

    FTFY
  • JJ 2012-06-20 14:30
    Ryan:
    Soon this was shortened to "system programs" and "application programs". It was still an adjective, not a noun. (Apologies to the 95% of you who don't understand English sentence structure.)

    Count yourself in that 95%, then. "System" and "application" are both nouns which are part of a noun phrase. While they are describing another noun, they are not adjectives; rather they are simply considered "modifiers."
  • Bill T 2012-06-20 14:34
    iToad:

    The bit density on the tapes back then was so low, that you could use a special reader to actually see the magnitized areas. It was a thin plastic strip about a foot long, filled with some sort of brown ferrite material behind a clear window. When you put it over the tape and tapped it, the magnitized bits in each frame turned black.


    You had the fancy toys. We just dipped the tape in an oil with the ferrite material shaken up in. The ferrite would stick to the tape. We would then put scotch tape over it, pill off the scotch tape then look at the bit patterns.

    About two years ago I was cleaning the basement and I found my card reader. This was a metal frame that you would set the IBM punch cards are to assist in reading them by hand.

    I Pitched it along with my 132 column print layout ruler, and my mini guide to DEC COBOL Syntax.

    I did keep a copy of the DECUS (Digital Equipment Corp User Society) magazine that had a copy of a COBOL program I wrote to submit a file to the printer.

    I would say that is all that is left of my COBOL days

    Bill T
  • Sigivald 2012-06-20 16:30
    Right. If it works, you're a hero. If it doesn't work - well now you have two problems.


    As the Unix Hater's Handbook said:

    <I>Some people, when faced with a Unix problem, think "Aha! I know! I'll use sed!" ... now they have two problems.[/i]
  • Alvie 2012-06-20 18:15
    WTF ? This guy never heard of Perl ?
  • Sayer 2012-06-20 23:35
    Matt Westwood:
    trtrwtf:
    Ryan:

    People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.


    Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
    All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.

    What! In what language does "apps" mean "food"?


    Appetizers. Are you new?
  • Sayer 2012-06-20 23:37
    JJ:
    Ryan:
    Soon this was shortened to "system programs" and "application programs". It was still an adjective, not a noun. (Apologies to the 95% of you who don't understand English sentence structure.)

    Count yourself in that 95%, then. "System" and "application" are both nouns which are part of a noun phrase. While they are describing another noun, they are not adjectives; rather they are simply considered "modifiers."


    Even taking into account the environment, this entire train of argument is both pedantic and assinine.

    eros: I love you too.
  • David 2012-06-21 05:24
    Ryan:
    mwa mwa mwa - pompous and patronising lecture about what people used to call stuff in like 1955 - mwa mwa mwa


    I see what you are saying. People should continue to use terminology that is 50 years out of date, because that is what you fondly imagine is "correct".

    Smatta, damn kids on your lawn again?
  • Tha real frits 2012-06-21 08:39
    trtrwtf:
    Ryan:

    People got tired of saying "application programs" so they just used "applications" as a shortcut. I think that's called nouning an adjective. (barf) Then it got cut further to "app". But all that happened well after the true COBOL programmers learned their craft.


    Last night I walked into a bar with some friends, and the nice lady who greeted us asked us if we were just drinking, or if we wanted some apps too.
    All four of use are developers. All four of us were very confused for a few seconds, until we realized she was talking about food, not code.


    She didn't seem concerned about the bumps on your head?
  • M 2012-06-21 09:41
    David:
    Ryan:
    mwa mwa mwa - pompous and patronising lecture about what people used to call stuff in like 1955 - mwa mwa mwa


    I see what you are saying. People should continue to use terminology that is 50 years out of date, because that is what you fondly imagine is "correct".

    Smatta, damn kids on your lawn again?


    I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.

    Kibibytes sounds like pet food.
  • DCRoss 2012-06-21 14:38
    M:
    I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.


    I think the word you are looking for is "salespeople".

    The ones who want to sell 931 GB for the price of a "Terabyte".
  • M 2012-06-21 15:09
    DCRoss:
    M:
    I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.


    I think the word you are looking for is "salespeople".

    The ones who want to sell 931 GB for the price of a "Terabyte".


    That may be where it started, but there are some weirdos out there as well. I've argued with people who insisted that kilobytes were always 1000 bytes and people were just 'using it wrong'. I suspect these kinds of people never saw a computer before the 1990's.

    Just to clarify for future generations:
    Kilobyte = 1024 bytes
    Megabyte = 1048576 bytes
    Kibibyte = Pet food
    Mebibyte = What your dog might do if he doesn't get his Kibibytes
  • Kuba 2012-06-21 16:26
    Steven Seagal's ponytail:
    The real WTF is the attempt at a general solution to the problem (lexer, parser, SED script, C/C++ code - really?)
    The problem was really that the lexer and parser were not entirely up to spec on their COBOL. The "idiosyncracies" were accepted by the COBOL compiler, after all, weren't they?

    Yes, the attempt at a general solution was the right way to go about it, but it should have been done while having the documentation for the COBOL system handy. And, ideally, at least using previous revisions of the COBOL source code as test cases. You know, to make sure that all the "idiosyncracies" were all handled.

    Writing a lexer and a parser is quite often the right thing to do, instead of some manual or half-baked process that's usually the replacement. Admittedly, lex and yacc are horrible tools to work with, the various modern C++-using equivalents are much nicer to work with.

    Who the heck calls themselves a software engineer without having a multitude of tools in their toolbox -- lexer and parser generators being among those. Yeah, I know that the reality is such that people either never learn it, or they leave that knowledge among dusty college memories, best forgotten about. Lexing and parsing: it's not hard, just requires not having an irrational fear of it. This statement applies to most things in life, BTW.

    Addendum (2012-06-21 16:37):
    I also presume that some normalization and key selection was needed instead of just dumping the records straight into an SQL database. Both could be done entirely automatically, after the data got imported temporarily into a flat table that had 1:1 mapping to input from the COBOL system.

    I presume it'd be done in steps:

    1. Extract strucure from the COBOL source code.
    2. Dump data into tables that match COBOL records 1:1.
    3. Using structure from #1 and data from #2, run queries to determine keys and functional relationships between columns. This extracts normal forms out of the original mess.
    4. A set of fixed, use-oriented rules is added to denormalize the data for performance. This would be based on the use patterns of the data.
    5. Final tables are built from #2 and #3+#4.
  • Sayer 2012-06-21 16:29
    M:
    DCRoss:
    M:
    I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.


    I think the word you are looking for is "salespeople".

    The ones who want to sell 931 GB for the price of a "Terabyte".


    That may be where it started, but there are some weirdos out there as well. I've argued with people who insisted that kilobytes were always 1000 bytes and people were just 'using it wrong'. I suspect these kinds of people never saw a computer before the 1990's.

    Just to clarify for future generations:
    Kilobyte = 1024 bytes
    Megabyte = 1048576 bytes
    Kibibyte = Pet food
    Mebibyte = What your dog might do if he doesn't get his Kibibytes


    The interesting thing about this is that you're both right in such an argument. a "Kb" has always been 1024 bytes, but based on what "kilo" means, it was also being used wrong. You know, just so the water is good and muddy.
  • Kuba 2012-06-21 16:33
    Jay:
    herby:
    So, let me get this straight...
    You write a program to parse Cobol data definitions.
    Isn't that what a Cobol compiler does?
    So, you are just writing a Cobol compiler (or a small, or not so small, subset of it)? Sounds like inventing a wheel here.
    I presume you mean "re-inventing the wheel here". But anyway: Maybe so, but so what?
    Agreed. Every time someone starts turning something on a lathe, they "reinvent" the wheel :)
  • Cat 2012-06-21 22:27
    While COBOL is certainly not the worst platform to develop software on (MUMPS will most certainly hold that title through at least our grandchildren’s lifetimes)

    Actual MUMPS (as opposed to Strawman MUMPS, a language that exists only on this site) isn't bad at all. It's no more difficult to develop in than C, and in fact for the domains it normally handles (database and string operations) it's probably easier than C.
  • Greeno 2012-06-22 09:25
    It sounds like the problem is that the customer has not been forced into signing a contract that means it's more expensive for them if someone has spend lots of time doing manual fiddles.

    Customers are generally driven by money and if they can see that there's a way to save mutual time and money then they will always go for it.

    Otherwise you can't blame the customer for "getting away" with sending data of random format if they know that someone will sort it out for free.
  • M 2012-06-22 09:38
    Sayer:
    M:
    DCRoss:
    M:
    I mostly agree with you, except that to me a kilobyte will ALWAYS be 1024 bytes. Retroactively defining it to be 1000 just to keep the metriphiles(new word!) happy was idiotic and pointless.


    I think the word you are looking for is "salespeople".

    The ones who want to sell 931 GB for the price of a "Terabyte".


    That may be where it started, but there are some weirdos out there as well. I've argued with people who insisted that kilobytes were always 1000 bytes and people were just 'using it wrong'. I suspect these kinds of people never saw a computer before the 1990's.

    Just to clarify for future generations:
    Kilobyte = 1024 bytes
    Megabyte = 1048576 bytes
    Kibibyte = Pet food
    Mebibyte = What your dog might do if he doesn't get his Kibibytes


    The interesting thing about this is that you're both right in such an argument. a "Kb" has always been 1024 bytes, but based on what "kilo" means, it was also being used wrong. You know, just so the water is good and muddy.


    I strongly disagree.

    KB means kilobyte which means 1024 bytes. They are all the same thing.

    "Based on what 'kilo' means" - it means 1024 when used in the context of bytes. It always has. What it means in other contexts, historical or not, is irrelevant. It was deliberately chosen to represent 1024 in this context and has enjoyed popular usage ever since. That is the only true measure of correctness any language has, despite what grammar nazis might have you believe. So no, it has never been used wrong, unless you count the revisionist attempts to redefine it to mean 1000.
  • Eldon 2012-06-22 13:59
    To clear things up a bit.

    There is KB, kB, Kb and kb.

    They all have different meanings and are used by different peoples for different reasons

    KB = 1024 bytes (this is what ordinary people will use)
    Kb = 128 bytes
    kB = 1000 bytes (used by hard drive manufaturer to make you think the drive is bigger than it actually is)
    kb = 125 bytes (used by ISP to screw you on your download speed, that 30mbps connection only goes at about 3MB/s)

  • Luiz Felipe 2012-06-24 12:34
    Matt Westwood:
    (*yawn*) yeah yeah bin there dun that. Except back in 1998 we converted a COBOL system to a FORTRAN one. Writing a parser for the general COBOL record descriptor was rather more worthwhile than creating a separate program for each COBOL file we were given. The difference between this story and that one is that after 3 weeks the program worked like a dream and didn't need to be touched for a decade, no matter how many times the source file changed.

    Oh, and we never converted the FORTRAN program to a more modern language. It was supposed to be upgraded to a C++ / Java / whatever-bollocks system but it worked so well the customer didn't see the benefit of changing it.


    Basic are the most similar languague to fortran that exists now. There is no benefit in converting to java.
    First, upgrade to old basic, then no classic visual basic (6), then to new vb.net. Perhaps convert to csharp, csharp is almost 98% like vb.net, i dont see benefit in using csharp, only because some programmers think that comma terminated languages are better, this is bullshit.
  • Luiz Felipe 2012-06-24 12:44
    Anonymouse:
    They should have simply used a neural network; after an initial training periog for learning how to make the necessary changes it should be able to to them on its own...


    This is the reason they contracted you, that is what people does, if you dont like this stupid work, then you can quit.
  • Shark8 2012-06-30 13:20
    David Emery:
    He should have dug around the Open Source community. There's a bunch of code in Ada as part of the GNAT (open source) Ada compiler that interprets COBOL PIC statements (that I helped write about 15 years ago.) With that code, he could have fed the PIC statements and generated the associated read/write routines, reusing the design even if he didn't want to link the Ada routines in to C or C++ (another feature of Ada...) The syntax for PIC clauses is quite static, you should capture the grammar/semantics of COBOL once.

    But someone show me a similar big fat ugly messy data structure definition in some other language. Do you think that struc definitions for this data in C would be less readable? He should be grateful for COBOL's ability to represent this structure, even if it was un-normalized....


    Yeah, Ada's got some surprisingly good design behind it; it's shame that more people aren't looking into [using] it.
  • Shark8 2012-06-30 13:22
    Eldon:
    To clear things up a bit.

    There is KB, kB, Kb and kb.

    They all have different meanings and are used by different peoples for different reasons

    KB = 1024 bytes (this is what ordinary people will use)
    Kb = 128 bytes
    kB = 1000 bytes (used by hard drive manufaturer to make you think the drive is bigger than it actually is)
    kb = 125 bytes (used by ISP to screw you on your download speed, that 30mbps connection only goes at about 3MB/s)



    Always use KB, MB, GB etc. Ignore those pretenders.
  • Rockstone 2012-07-27 13:00
    One time, when working as an intern for a suburban city, I was given several days to work on organizing a database. I did it with a SQL command in 15 minutes. (and if I were better at SQL, it would have been faster)