• Björn Tantau (unregistered)

    Is it really that hard to whip up a proof-of-concept to at least show the COBOL guy how it should be done? And then offer a full rewrite? (or refer to a partner for the rewrite)

  • (nodebb) in reply to Björn Tantau

    Probably the (disc-shaped) company rested on a turtle resting on dinosaurs like Dawie. If so, no wonder even considering to suggest to say anything that might perhaps under circumstances hurt his feelings is a big NO-NO.

  • Quite (unregistered)

    Which company is this? I'm tempted to take this one on. After all, I'm an expert on COBOL, I read a book on it once when we did a millennium conversion back in the day.

  • (nodebb)

    Some customers are just not worth the headache of keeping.

  • Quite (unregistered)

    Incidentally, what sort of a name is "Dawie"? It calls to mind Bawwy Kwipke.

  • Vietcongster (unregistered)

    I was going to say "Why didn't he bill the hell out of them?", until I saw that they wouldn't spend any more money on this.

    Welp, let them greet the 22nd century with COBOL, so we may have a WTF 100 years from now.

  • Dawie (unregistered) in reply to Quite

    It's pronounced "Daa-vee". An Afrikaans name. In Afrikaans, a "w" is pronounced as "v". As the Afrikaners might say, "Praat Afrikaans of hou jou bek".

  • Quite (unregistered) in reply to Dawie

    As your reputation as a sociopolitical group would predict.

  • isthisunique (unregistered)

    60 tables, how bad can it be?

  • (nodebb) in reply to isthisunique

    60 tables, one row per table, easy.

    Why are they writing it all to a file? Surely the BLOB API is already delivering things in a form that supports the usual I/O handling?

  • Greg (unregistered)

    I don't quite get what the company George works for actually had to do with the problem? Sounds like the client decided to start (ab)using SQL Server without George's company being involved. The only explanation I can come up with is that George is some kind of consultant.

  • Bitter Like Quinine (unregistered)

    I once came up against a "Costs Database" that consisted of a a table of (product, calculator) and another table of (product, configuration, column, value).

    It turns out that the delicate costing calculations for each product had been worked out over generations (in staff turnover) of workers as super complicated formulae in various excel spreadsheets. When it came time to provide a modern automated feed to the rest of the company, there was nobody left who knew precisely how it all worked anymore. So some clever wag had put each spreadsheet into a blob, and all the input data for each supported config of each product in the other table as tag/value pairs.

    When the main app requested a particular costing, the product and config was read out of the request, the appropriate spreadsheet extracted, the relevant data entered into it, then the resulting (er) results were read back and returned.

  • Consultant (unregistered)

    As a consultant I see 3 WTF's here:

    1. Abuse of SQL
    • This is pretty common. We've all seen this countless times before: "I'm expert on language X so I'll write language Y like X"
    1. Response time to customer
    • "Felt confident in weeks before contact" It's hard to understand, for me, how you can stay in business if your customer has critical problem and he has to wait for weeks for help.
    1. Not telling the problem for the customer
    • Microsoft says to customer that they'll get their best technical expert. He comes in, after weeks of waiting, glances the system and says "No can do". And even before this there has been a group of experts who also said "No can do". So customer is left with the impression that a) Microsoft's products are crap b) Microsoft's personnel doesn't know how to use their products.

    For me the last WTF was biggest. As a consultant you're getting paid to tell customer where they have gone wrong and to help them fix things.

  • NoLand (unregistered)

    Now, the solution is as obvious as straight forward: A table with 81 columns, ID, and 80 small ints (COL1..COL80) for each of the columns of a punch card.

  • Anon (unregistered) in reply to NoLand

    You need 82 columns, you need a char column called RECORD_TYPE so the system knows what format to read the punch cards in. You can use the power of SQL to make the primary key the compound (RECORD_TYPE,ID)

    I'll take my cheque and be on my way.

  • NoLand (unregistered) in reply to Anon

    The even niftier solution would be to have a table with just 80 rows – and updating it for another column for each new record. (column-id = record number) :-)

  • Herby (unregistered)

    Today's lesson: Sometimes it is just best to walk away. Things are too screwed up to get any meaningful result. The unfortunate aspect of this is that sales droids rarely "walk away" form a potential sale, and end up promising things that people in the back office can't deliver in the time requested. In many cases WTF's are spawned (look at the archives!). That's how it goes.

  • Appalled (unregistered)

    Maniacally contrived. Could not possibly exist anywhere on this planet. Stop making things up.

    Back in the late 70's we were programming in COBOL and IMS, a hierarchical form of RDBMS, AS if that weren't enough, the batch side of things had countless instances of VSAM look up tables. Direct Access and Indexed Access methods of all flavors were floating around everywhere. No one in their right mind would EVER sweep a file UNLESS it was a Master file rather than a Lookup File. Even then one would often build a Secondary Index perhaps by Cycle Date to skip everything that wasn't to be updated.

    So you're not proposing a "COBOL" environment, you're proposing a Pre-HardDrive environment, where the only access is sequential, i.e. Cards and Tapes.

    COBOL was a masterpiece and I'm sick of you silly twits disparaging it, especially with make believe fantasy.

  • My name is Nobody (unregistered) in reply to Consultant

    Critical != urgent.

  • Adam Jorgensen (google) in reply to Appalled

    The story may well be contrived (Particularly because I live in South Africa and it's well know we have a top-notch banking system here, actually one of the best in the world and hence the odds of something this silly happening here are probably low) but I'm not sure I'd call COBOL a master-piece.

    I think the best thing you can say is that it's a language of its time. It's sure as hell not a language of the future or a trend-setter for modern development though...

  • Webskale (unregistered)

    He's just preparing for the NoSQL revolution.

  • mainframe web dev (unregistered) in reply to Appalled

    So you're not proposing a "COBOL" environment, you're proposing a Pre-HardDrive environment, where the only access is sequential, i.e. Cards and Tapes.

    Agreed. When you think Cobol, think CICS.. i.e, the predessor to the web server. You take a Cobol Program which uses a Copy Book to structure memory and a CICS Map to draw on the 3270 thin client. Then years later the kids will call it a Model-View-Controller pattern. It's totally new and different? LOLS -- COBOL is so OLD! And yet, Tomcat, Websphere, Cassandra, Spring Boot -- none of those can replay transactions via their log file. Think on that.

  • Georgeyboy (unregistered)

    I got suspicious at the first sentence. George, a highly prized technical troubleshooting consultant that even Microsoft calls in as a last resort is just checking the emails that piled up after a business trip? Really? You didn't have a smartphone with you? Something 'phishy' going on here..

  • (nodebb)

    Maybe I'll tell them to switch to some NoSQL implementations. NoSQL should be able to handle this kind of "single, all purpose table" scenario better than ordinary SQL servers and there's pretty good chance to gain small amount of performance improvement.

  • The Original Fritz (unregistered)

    The True WTF is, of course, not continuing to use a functioning system written in COBOL.

  • Norman Diamond (unregistered)

    Back in the late 70's we were programming in COBOL and IMS, a hierarchical form of RDBMS,

    No, IMS was hierarchical exactly as you say. It has no semblance of relational structure, not one bit RDBMS.

    AS if that weren't enough, the batch side of things had countless instances of VSAM look up tables.

    Yes, that is sure something that I miss in operating systems that came along later. I wonder if I'm the only one who designed a file system that provided insertions and deletions in the middle of a file without having to rewrite the entire file.

    So you're not proposing a "COBOL" environment, you're proposing a Pre-HardDrive environment, where the only access is sequential, i.e. Cards and Tapes.

    Well the article's photo SHOWS tapes. But there's still something odd about it, because IBM invented hard drives around 7 years before the 360 mainframe.

    By the way I finally discarded my tapes this year. I don't remember the last time I saw a machine that could read them though.

  • Norman Diamond (unregistered)

    So customer is left with the impression that a) Microsoft's products are crap b) Microsoft's personnel doesn't know how to use their products.

    Yes that sounds like the impression that Microsoft gives to Microsoft's customers in Microsoft's forums discussing Windows problems.

  • Kempeth (unregistered)

    Why walk away? (Provided you get paid) Especially if you've envisioned yourself as the comic book hero for weeks now.

    I don't know COBOL at all but to me it sounds like those datafiles are like a table with one record after another. It shouldn't be too hard to split them up into individual records, plant them into appropriate tables and then get rid of the whole file IO nonesense for CRUD operations. It's still ugly and hacky but performance should be loads better and from there you can turn one table after antother into real SQL. And with a bit of help from the COBOL guy you should be able to hack up a PoC in a day.

  • Meh (unregistered) in reply to Appalled

    Not really so contrived.

    I've had the opportinity to work with COBOL "experts" who were reading all of the files, all the times. And arguing that the main reason performance was bad was because everything was loaded from 5600rpm disks instead of 7200rpm ones. When confronted with having to do SQL work, the same folk would happily write every query as SELECT * FROM

    ; and then loop through the result set to find the records that met the search criteria.

    A shit programmer can do really horrible stuff in any programming language.

  • Appalled (unregistered) in reply to Norman Diamond

    "No, IMS was hierarchical exactly as you say. It has no semblance of relational structure, not one bit RDBMS."

    Parents and Children aren't Relational? Order Header/Order Detail where hdr.OrderNo = dtl.OrderNo? Adding a Secondary Index from anywhere in one structure to anywhere in another structure via a pre-defined key field (ForeignKey/ParentKey).

    Sure RDBMS is a phrase, meaning on-the-fly anything by anything. But on a case-by-case basis (as predefined by the DBA) you could set up any business need relationship you wanted. And we/they all did.

  • Mason Wheeler (unregistered) in reply to Appalled

    Parents and Children aren't Relational?

    No. "Relational" does not refer to the relationship between tables; it refers to the tables themselves being designed as relations, a mathematical concept of structuring the data to be accessed and manipulated according to the principles of relational algebra.

  • Norman Diamond (unregistered)

    I also once had a cow-orker who knew his design was a relational database system because it handled queries like field > value or field < value.

  • mainframe web dev (unregistered) in reply to Norman Diamond

    No, IMS was hierarchical exactly as you say. It has no semblance of relational structure, not one bit RDBMS.

    And it evolved into DB2

  • anonymous (unregistered) in reply to Herby

    Alternative lesson: Don't expect your paid-for microsoft consulting to come with an honest answer.

    Seriously, you don't have to diss anyone in the project, just discuss how their expertise in SQL is not a match for their COBOL expertise, so it might be indeed cheaper for the organization to stick with COBOL. It surely must be cheaper to look for an expensive COBOL consultant in case the current one leaves than to pay for Microsoft SQL consultants who apparently do nothing and just walk away after a week.

  • WTH? (unregistered)

    I have code right here that reads a COBOL copy book and creates then loads SQL tables....

  • GorGutz 'Ead 'Unta (unregistered)

    I would say the WTF is the dude taking one look at a system and just walking off without saying what's up, but then again, he IS a highly paid consultant.

Leave a comment on “The Mainframe Database”

Log In or post as a guest

Replying to comment #465481:

« Return to Article