• (cs)

    Why is this a WTF?

    Wrap it up in a stub, and you have your API as you would like it to look.

    PS: The frist part of any COBOL program is the identification division.

  • Drifter (unregistered)

    Well... at least now I don't feel so bad about the "services" I wrote using classic asp.

    Please, no bashing... I feel bad enough about that decision already

  • (cs)

    Really, 50 characters is more than enough for comm

  • coballer (unregistered)

    the wtf for me is that it took them so long. i was in school in 1999 (or was it 99?) and was witness to an instructor's demo..COBOL web servers.

  • (cs)

    Who needs Ruby on Rails when there is Cobol on Cogs... ;-)

  • huppenzuppen (unregistered) in reply to jnareb
    jnareb:
    Who needs Ruby on Rails when there is Cobol on Cogs... ;-)

    Or COBOL on Wheelchair

  • (cs)

    Been there, felt the pain of the C#-ie.

    Long ago I had to write a C++ library to interface with a legacy COBOL system that spat out fixed width data taken from various monitoring stations, munged into CSV format before we received it. In each COBOL record there was a field for an error status, one character wide. The client told us what errors "0" to "9", "A", "B" and "C" meant and off we went.

    Alarm bells should have gone off at the point where we were asked to provide end-users with meaningful descriptions of error codes "Y" and "Z". But no, the COBOLists carried merrily on using the next characters that came to mind - punctuation, which inevitably led to error codes "," and "(doublequote)". By that point any semblance of sanity in the CSV was well and truly gone...

  • Pete (unregistered)

    Well, when integrating systems you have to cater for the least common denominator - when connecting to the COBOL system, it won't be able to process a 31-character first name anyway (or one that contains a non-EBCDIC letter), so no matter how the API is specified, the limitations still won't go away.

  • faoileag (unregistered)

    Can't see a wtf here either. If you marry a legacy system with something new, data has to be converted. Who does the conversion can turn into endless discussions, but as a rule-by-thumb I would say it should be done by whoever is better equipped.

    If it costs X man hours to convert the legacy data delivered by the cobol system in th eweb service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.

    Argument for the dinosaurs to do it: once the legacy system dies, the now unnecessary conversion dies with it.

  • (cs) in reply to faoileag

    If only there were some piece of software you could put in the middle of this interaction, that only has the responsibility of handling the interaction. Some sort of software in the middle, some "middleware", so to speak.

    Man, that sounds useful. Somebody should implement that. I bet a business could make a lot of money selling middleware.

  • ORLY (unregistered)

    Umm, the WTF isn't the 2000 character field, or even EBCDIC interface.

    It's the fact that in 40 years, the COBOL system is still limited by these things. The fact that this Enterprise System still merrily truncates email addresses and this is considered acceptable is the WTF.

    The fact that names in the Enterprise System still can't handle accented characters (or I'm going to guess hyphenated last names) is the WTF.

    The COBOL folks are still stuck in the 1970s, regardless of the interface.

  • (cs) in reply to ORLY
    ORLY:
    Umm, the WTF isn't the 2000 character field, or even EBCDIC interface.

    It's the fact that in 40 years, the COBOL system is still limited by these things.

    Precisely. They've been trying to avoid investing in improving their "core" software by pushing the limitations onto the newer software, and it's biting them everywhere. This is not a architectural error or some programmer's foolishness, this is a management WTF.

  • Tim (unregistered) in reply to faoileag
    faoileag:
    If it costs X man hours to convert the legacy data delivered by the cobol system in the web service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.
    what if 0<x<1? </troll>
  • Tim^2 (unregistered) in reply to Tim

    Then you spend y hours arguing over whose responsibility it is, and resolve it by hiring consultants who charge z dollars, where x < y < z.

  • Geoff (unregistered) in reply to ORLY
    ORLY:
    Umm, the WTF isn't the 2000 character field, or even EBCDIC interface.

    It's the fact that in 40 years, the COBOL system is still limited by these things. The fact that this Enterprise System still merrily truncates email addresses and this is considered acceptable is the WTF.

    The fact that names in the Enterprise System still can't handle accented characters (or I'm going to guess hyphenated last names) is the WTF.

    The COBOL folks are still stuck in the 1970s, regardless of the interface.

    I am not advocating doing a bunch of new development in COBOL. But this sounds like more a people and budget problem then a technology one. COBOL does bulk records processing very very well and its very easy to write a stable bug free code in. On any modern COBOL system you certainly can do character conversion at least to/from ASCII easily and handle Unicode (with some minor challenges).

    The way I see it is one ore more of the following is true:

    The COBOL team is working on a really old platform, like COBOL 85 or older and nobody will pay for the upgrade.

    The COBOL team has lots of separate programs that work on the data, didn't use COPYBOOKS effectively and has built a very non-enterprisy mess of spaghetti that they can't maintain

    The COBOL team has lost all of its competent members over the years and just ain't up to the job.

  • John (unregistered)

    This is actually perfectly OK. You have a language conversion and you have a behavioural conversion. There's no need to do both of these at the same time with what might turn out to be a disastrous "complete rewrite" type project.

    Instead, it makes much more sense to:

    1. convert the COBOL directly into C#,
    2. provide a wrapper layer in C# to meet the new interfaces, then
    3. gradually build the new behaviour into the converted code until wrapper is no longer needed.

    1+2 gets you working, is quick, and low-risk. 3 is now just re-factoring and can be staged over time. Of course, most bosses see taking resource away from tasks like refactoring as an example of good priority management, and like brain damaged guinea pigs on Ecstasy, do it constantly, so that refactoring never happens - this is a recurring WTF almost everywhere.

  • faoileag (unregistered) in reply to Tim
    Tim:
    faoileag:
    If it costs X man hours to convert the legacy data delivered by the cobol system in the web service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.
    what if 0<x<1? </troll>
    Oh come on. If someone comes up to you and says: "Give me an estimate: how long does it take you to write a converter that takes a 2000 EBCDIC character large string as input and delivers an instance of the appropriate data object with its fields set accordingly?" do you answer "No prob, chief, give me 15mins"???
  • Charles F. (unregistered)

    TRWTF is all the people who don't see a problem here.

    A couple of years ago, I was working on one of those horrible "SOA without any planning" implementations. The service definitions changed hourly (no exaggeration). I joked that we could keep the interfaces stable by just making every web service exchange key-value pairs rather than detailed objects with typing.

    Fast forward a couple of years and I start a new job at a new place. The "architect" explains that the service definition never needs to be updated because in a flash of brilliance, he just made every server exchange key-value pairs.

    Face: meet desk.

    CAPTCHA: Oppeto A sysadmin who wants his Linux machine to turn into a real boy.

  • Charles F. (unregistered) in reply to John
    John:
    Instead, it makes much more sense to: 1. convert the COBOL directly into Java, which can run on the legacy AS/400s.
    FTFY.
  • John (unregistered) in reply to Julia
    Julia:
    Been there, felt the pain of the C#-ie.

    Long ago I had to write a C++ library to interface with a legacy COBOL system that spat out fixed width data taken from various monitoring stations, munged into CSV format before we received it. In each COBOL record there was a field for an error status, one character wide. The client told us what errors "0" to "9", "A", "B" and "C" meant and off we went.

    Alarm bells should have gone off at the point where we were asked to provide end-users with meaningful descriptions of error codes "Y" and "Z". But no, the COBOLists carried merrily on using the next characters that came to mind - punctuation, which inevitably led to error codes "," and "(doublequote)". By that point any semblance of sanity in the CSV was well and truly gone...

    See my earlier comment. Some drooling career manager tried to impress his higher-ups by saying "don't waste time fixing the error code representation, add this feature instead". Of course, now everyone who has to read those CSV files will take longer to figure out what the F*%^ is going on - a new recurring cost to the business. But that won't be the manager's fault will it. Oh no. He'll blame the troops, explain how hard it is to get good help, mutter something about herding cats, and carry on.

    It's only when the last serious engineer storms out and the only subordinates remaining are politicking morons that the tables turn. Eventually, that is what always happens. Rise by being a "player", expect to fall that way too.

  • John (unregistered) in reply to faoileag
    faoileag:
    Can't see a wtf here either. If you marry a legacy system with something new, data has to be converted. Who does the conversion can turn into endless discussions, but as a rule-by-thumb I would say it should be done by whoever is better equipped.

    If it costs X man hours to convert the legacy data delivered by the cobol system in th eweb service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.

    Argument for the dinosaurs to do it: once the legacy system dies, the now unnecessary conversion dies with it.

    I suggested that the new language be used for the conversion because it is likely (no guarantee) to be more expressive - i.e. the set of things that are straightforward is a superset.

    Also, old-school guys will be as stuck in their behavioural ways as their language ways. They should simply advise while the new language guys do all the wrappers etc. Then learn the new language properly from scratch, or retire.

  • John (unregistered) in reply to faoileag
    faoileag:
    Tim:
    faoileag:
    If it costs X man hours to convert the legacy data delivered by the cobol system in the web service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.
    what if 0<x<1? </troll>
    Oh come on. If someone comes up to you and says: "Give me an estimate: how long does it take you to write a converter that takes a 2000 EBCDIC character large string as input and delivers an instance of the appropriate data object with its fields set accordingly?" do you answer "No prob, chief, give me 15mins"???

    Comparatively speaking, yes.

    The work may be tedious and seem pointless, but the risk is much lower than a complete rewrite of the entire COBOL system as a monolithic project that may not be usable up to the previous level of functionality until 50%+ complete.

  • faoileag (unregistered) in reply to John
    John:
    faoileag:
    Tim:
    faoileag:
    If it costs X man hours to convert the legacy data delivered by the cobol system in the web service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.
    what if 0<x<1? </troll>
    Oh come on. If someone comes up to you and says: "Give me an estimate: how long does it take you to write a converter that takes a 2000 EBCDIC character large string as input and delivers an instance of the appropriate data object with its fields set accordingly?" do you answer "No prob, chief, give me 15mins"???
    Comparatively speaking, yes.
    Tim was just highlighting a flaw in my example - my assumption that X^2 is larger than X. Which isn't true if you allow for time units that are fractions of man hours ((1/2)^2 is 1/4).

    There's always a nitpicker around to highlight such things - I know, I am one myself :-)

  • RJ (unregistered) in reply to Drifter

    Been there, still supporting them.

    And doing new installs with them.

    Because it's risky to try to replace them with new equivalents, that's just more work and it might go wrong.

    ASP.NET web services with one string in and one out containing Xml. Check.

    Xml contains serialized ADO.NET datasets. Check.

    And now contract first SOAP is finally available in dotNET 4.5

    Can I just pretend everything before just didn't happen now?

  • EvilSnack (unregistered) in reply to Julia
    Julia:
    Alarm bells should have gone off at the point where we were asked to provide end-users with meaningful descriptions of error codes "Y" and "Z".
    The problem is hardly ever the technology, but in the decisions made by the people who use the technology. Designing a data record so that it can grow in the future is child's play, but many people consider themselves too "grown up" for that.
  • QJo (unregistered) in reply to Pete
    Pete:
    Well, when integrating systems you have to cater for the least common denominator - when connecting to the COBOL system, it won't be able to process a 31-character first name anyway (or one that contains a non-EBCDIC letter), so no matter how the API is specified, the limitations still won't go away.

    Only foreigners have names with non-EBCDIC letters in their names, so that's all right then. We design our applications for Americans.

  • ZoomST (unregistered)

    We all were wrongly commenting here. Comments don't have exactly 2000 characters, and they are not in EBCDIC. WRONG! We youngsters, with these fancy web services, C-sharpies, Javanese beans, and new COBOL versions beyond the glorious '85... despicable us.

  • faoileag (unregistered) in reply to John
    John:
    faoileag:
    Can't see a wtf here either. If you marry a legacy system with something new, data has to be converted. Who does the conversion can turn into endless discussions, but as a rule-by-thumb I would say it should be done by whoever is better equipped.

    If it costs X man hours to convert the legacy data delivered by the cobol system in th eweb service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.

    Argument for the dinosaurs to do it: once the legacy system dies, the now unnecessary conversion dies with it.

    I suggested that the new language be used for the conversion because it is likely (no guarantee) to be more expressive - i.e. the set of things that are straightforward is a superset.

    Definitely a good argument for letting the guys with the newer language handle the conversion - they should know what's available in the language regarding data types and their restrictions.

  • ZoomST (unregistered) in reply to QJo
    QJo:
    Pete:
    Well, when integrating systems you have to cater for the least common denominator - when connecting to the COBOL system, it won't be able to process a 31-character first name anyway (or one that contains a non-EBCDIC letter), so no matter how the API is specified, the limitations still won't go away.
    Only foreigners have names with non-EBCDIC letters in their names, so that's all right then. We design our applications for Americans.
    But there are Americans with these non-EBCDIC letters in their names. Some are living in Canada, and some others are inhabitants of the South part of America... And there are beers with umlauts scattered all over their names. Shouldn't we drink them?
  • Krunt (unregistered)

    I'm loving some of the terms in this article, especially C#-ie.

    "C#-ie - just smelling them gives you a headache."

    "Javan - even smaller than a Ja-shortbus."

  • John (unregistered) in reply to faoileag
    faoileag:
    John:
    faoileag:
    Tim:
    faoileag:
    If it costs X man hours to convert the legacy data delivered by the cobol system in the web service and X^2 man hours to convert the legacy data before it is delivered to the web service, than the sharpies have to do it.
    what if 0<x<1? </troll>
    Oh come on. If someone comes up to you and says: "Give me an estimate: how long does it take you to write a converter that takes a 2000 EBCDIC character large string as input and delivers an instance of the appropriate data object with its fields set accordingly?" do you answer "No prob, chief, give me 15mins"???
    Comparatively speaking, yes.
    Tim was just highlighting a flaw in my example - my assumption that X^2 is larger than X. Which isn't true if you allow for time units that are fractions of man hours ((1/2)^2 is 1/4).

    There's always a nitpicker around to highlight such things - I know, I am one myself :-)

    The square is always bigger and it's easy to prove. Construct a square of any side length X. This has area X^2, right? Now, take an identical copy of any of its sides. This has length X, yes? Now simply place it entirely inside the square. You might have to angle it a bit so it fits in there. X cannot be more than X^2 or it would not fit. Since by inspection you can see some unused space remaining in the square, X is in fact strictly smaller than X^2.

  • Anonymous Cow Herd (unregistered) in reply to faoileag
    faoileag:
    Tim was just highlighting a flaw in my example - my assumption that X^2 is larger than X. Which isn't true if you allow for time units that are fractions of man hours ((1/2)^2 is 1/4).

    There's always a nitpicker around to highlight such things - I know, I am one myself :-)

    30 minutes ^2 = 900 minutes 900 minutes = 1/4 man-hour

    Math checks out, guys. </middle-manager>

  • John (unregistered) in reply to ZoomST
    ZoomST:
    QJo:
    Pete:
    Well, when integrating systems you have to cater for the least common denominator - when connecting to the COBOL system, it won't be able to process a 31-character first name anyway (or one that contains a non-EBCDIC letter), so no matter how the API is specified, the limitations still won't go away.
    Only foreigners have names with non-EBCDIC letters in their names, so that's all right then. We design our applications for Americans.
    But there are Americans with these non-EBCDIC letters in their names. Some are living in Canada, and some others are inhabitants of the South part of America... And there are beers with umlauts scattered all over their names. Shouldn't we drink them?

    Use ROOOOOCKDIC. It has an additional bit for each character specifying whether there is an umlaut. You can even have ! umlaut, signalling a level of exclamation found only in aging rock stars.

    For example: "Bubbles?? Oh come on Sharon! I'm f**ing Ozzy Osbourne, the Prince of fing Darkness. Evil!<umlaut> Evil!<umlaut> What's fing evil about a buttload of f**ing bubbles!<umlaut>?<umlaut>"

  • faoileag (unregistered) in reply to Anonymous Cow Herd
    Anonymous Cow Herd:
    faoileag:
    Tim was just highlighting a flaw in my example - my assumption that X^2 is larger than X. Which isn't true if you allow for time units that are fractions of man hours ((1/2)^2 is 1/4).

    There's always a nitpicker around to highlight such things - I know, I am one myself :-)

    30 minutes ^2 = 900 minutes 900 minutes = 1/4 man-hour

    Math checks out, guys. </middle-manager>

    Reminds me of "The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. (Tom Cargill)" from http://www.cs.uni.edu/~mccormic/humor.html

    No, Akismet, this is not spam. Go away.

  • Yolken Bit (unregistered)

    Cobol is for dinosaurs still living in a Jurassic period time warp.

  • gnasher729 (unregistered) in reply to QJo
    QJo:
    Only foreigners have names with non-EBCDIC letters in their names, so that's all right then. We design our applications for Americans.
    Like some girl I know named Chloë.
  • DonaldK (unregistered) in reply to Severity One
    Severity One:
    Really, 50 characters is more than enough for comm

    Hahaha spot on. I counted. gedit was tasked with t

  • MK (unregistered) in reply to Anonymous Cow Herd
    Anonymous Cow Herd:
    faoileag:
    Tim was just highlighting a flaw in my example - my assumption that X^2 is larger than X. Which isn't true if you allow for time units that are fractions of man hours ((1/2)^2 is 1/4).

    There's always a nitpicker around to highlight such things - I know, I am one myself :-)

    30 minutes ^2 = 900 minutes 900 minutes = 1/4 man-hour

    Math checks out, guys. </middle-manager>

    30min ^ 2 = 900squaremin = 1/4squarehour

  • Zapp Brannigan (unregistered) in reply to Tim^2
    Tim^2:
    Then you spend y hours arguing over whose responsibility it is, and resolve it by hiring consultants who charge z dollars, where x < y < z.
    Comparing numbers with mixed units of measure, you must work for the government.
  • Anon (unregistered)

    Legacy systems should be burned to the ground, and their advocates with.

    Legacy systems are the reasons we can't have nice things, such as functioning healthcare.

  • (cs)

    Obligatory Comment: TRWTF is COBOL.

    Even at the time of its invention there were already better alternatives (Lisp) which could handle more than fixed-width data structures.

    Not only is COBOL crippled, it also cripples the mind. The inventors were dumb and it should be dumped!

  • faoileag (unregistered) in reply to Anon
    Anon:
    Legacy systems are the reasons we can't have nice things, such as functioning healthcare.
    "I can treat you, but you won't be able to reclaim the costs from your health insurance because the name of the disease is too long"?
  • faoileag (unregistered) in reply to Zapp Brannigan
    Zapp Brannigan:
    Tim^2:
    Then you spend y hours arguing over whose responsibility it is, and resolve it by hiring consultants who charge z dollars, where x < y < z.
    Comparing numbers with mixed units of measure, you must work for the government.
    That might explain why he thinks that by hiring consultants you can resolve a problem...
  • Hannes (unregistered)

    I really don't know why some people think it's "good practice" to truncate information they want to store. Oh, sure. You can abbreviate things, like "str." instead of "street" or "NY" instead of "New York". But truncating will make a mess out of your precious data sooner or later.

    After all, "123 Fake Blvd" is easier to figure out than "123 Fake Boul".

  • Egbert (unregistered) in reply to John
    John:
    This is actually perfectly OK. You have a language conversion and you have a behavioural conversion. There's no need to do both of these at the same time with what might turn out to be a disastrous "complete rewrite" type project.

    Instead, it makes much more sense to:

    1. convert the COBOL directly into C#,
    2. provide a wrapper layer in C# to meet the new interfaces, then
    3. gradually build the new behaviour into the converted code until wrapper is no longer needed.

    1+2 gets you working, is quick, and low-risk. 3 is now just re-factoring and can be staged over time. Of course, most bosses see taking resource away from tasks like refactoring as an example of good priority management, and like brain damaged guinea pigs on Ecstasy, do it constantly, so that refactoring never happens - this is a recurring WTF almost everywhere.

    Could you n00bs just stop introducing common sense and pragmatic thinking here? The idiots and trolls who frequent this place have made damn sure that this is not the place for it and they like it that way.

  • faoileag (unregistered) in reply to Hannes
    Hannes:
    I really don't know why some people think it's "good practice" to truncate information they want to store.
    I don't think they thought it to be a "good practice", at least the article doesn't say so. It's just one of these things you can't avoid if you have fixed-width datafields.

    What alternative would there be? Turning customers down because the name of the street they live in is too long? Not hiring the perfect match for a position because his surname happens to be longer than the max the payroll system can handle?

    And thinking back to the 70s it was not a question of "Ok, I'll use a payroll system of a different vendor", because there weren't that many.

  • faoileag (unregistered) in reply to Egbert
    Egbert:
    Could you n00bs just stop introducing common sense and pragmatic thinking here? The idiots and trolls who frequent this place have made damn sure that this is not the place for it and they like it that way.
    TDWTF comments? Oh come on, that's unjust. There's still a lot of on-the-subject debate here and people share insights (and the odd in-joke as well).

    I know tech news sites that are much worse. Much in the sense of: you don't open the comments, unless you want to learn about the latest conspiracy theories, company bashing ("it's earning money!! That's morally wrong!!!") and general whining ("A shortage in it experts? Impossible! I am unemployed and I can't find a job right now!").

    TDWTF comments are good reading.

  • CrankyOldFart (unregistered) in reply to ORLY
    The fact that names in the Enterprise System still can't handle accented characters (or I'm going to guess hyphenated last names) is the WTF.

    Actually, the real WTF would be to expect some clerk in accounting to know how to enter an accented character, or to care enough to bother doing.

  • Hannes (unregistered) in reply to faoileag
    faoileag:
    Hannes:
    I really don't know why some people think it's "good practice" to truncate information they want to store.
    I don't think they thought it to be a "good practice", at least the article doesn't say so.

    Yeah, that's why I put it in "", I just couldn't think of a better word. ;)

    It's just one of these things you can't avoid if you have fixed-width datafields.

    What alternative would there be? Turning customers down because the name of the street they live in is too long? Not hiring the perfect match for a position because his surname happens to be longer than the max the payroll system can handle?

    This may be true for the 70s, 80s and even the 90s, but there's no excuse for truncating data nowadays.

  • Daniel (unregistered)

    STRING and UNSTRING are in COBOL at least as far back as 74 (can't find a good COBOL 68 manual at this point). Insisting that fixed-width is the only thing COBOL will do is a statement from someone who hasn't taken the time to figure out how to make it work.

    (Yes, there are upper fixed-width limits for data items; in practice, though, it's not terribly hard to write variable-width XML, and parsing XML in is probably a medium-skill task.)

    EBCDIC, OTOH... They're just being lazy. There's no reason they can't support at least UTF-7.

Leave a comment on “Web Services...The COBOL Way”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article