Slashdot Mirror
Modernizing the Common Language - COBOL
Frumious Wombat writes "Over at the Register Developers section, they are quoting the head of research for Ovum Consulting on the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it. From the article: 'The first stage in the legacy modernization process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code - modern tools can automate much of this analysis for staff working at a higher level.'"
Comment removed based on user account deletion
I'm sure if someone made it easy to call web services from COBOL
j avcobol.html
I believe WebSphere does this. Supposedly you can pump COBOL data into EJB applications.
see:
http://www-306.ibm.com/software/data/ims/imsjava/
putting the 'B' in LGBTQ+
Honestly. You have some points, but one of the greatest in COBOL's favour is it's pervasivness.
A few years ago I was working at a job where we were doing everything in a 4th Generation Language. We got outsourced (thanks to a CIO who just popped in for a couple years to pad his resumee) to a company which had an integrated product written entirely in COBOL. (Of course they ran their code on an HP platform, which by now has been retired and HP support will soon, also end. COBOL survives because people still develop and keep old business apps written in it. Some work, by code, never changes.
The other major advantage of COBOL is it's library for handling business computation and I/O. That stuff exists in other languanges, but as an example with Microsoft's Visual Studio, it's all done differently (and somewhat stupidly re-defining formatting for the nth time.)
A feeling of having made the same mistake before: Deja Foobar
I had two COBOL classes, a 200 level and a 300 level, and this was in the past four years. The 200 level was mandatory, but the year after I took it was changed to VB. The 300 level was also changed to VB, and then changed back to COBOL, because some of the companies that come to our school suggested they keep a COBOL class. Surprisingly, I actually rather enjoyed COBOL, I guess because it was so easy to write.
The big advantage COBOL has is that the language is serious about data storage. The language knows about structured files, databases, indices, and formatted fields. COBOL was the first language to have data structures.
Look at what a mess it is to talk to a database from Perl, Python, Java, or C/C++. There's fussy glue code required, and the language doesn't help you make sure that field XYZ in the database comes out as field XYZ in the program. In COBOL, it's straightforward. The language knows about databases. There's even a good interface to MySQL.
It also has some formatting capabilities that HTML should have had. You can write CREDIT-CARD-NUMBER PICTURE 9999-9999-9999-9999. In some systems, that will eventually result in an input field on a green screen that will only accept four fields of all numbers with all digits filled in and will display a blank form field accordingly. HTML FORM fields should have worked that way.
There are some real advantages to a language where components outside the individual programs can see, check, and use the data declarations.
You can take a fresh wet behind the ears kid, give him the code, and he can figure out what's going on without any significant trouble
I disagree. I once was that kid. It is much harder than you imagine. Why?
1) Sphaghetti code. Lots and lots of sphaghetti code. COBOL, despite improvements, is still not much more structured than assembly. It was doing maint. programming in COBOL that I vowed in all future development to try to be kind to the maint. programmer.
2) The kid still has to learn the problem domain. I do not understand the mind set where a person says "I don't need to know the busness, just let me code it". With out the background knowledge you never know if what you are doing is right, reasonable, solves a domain problem or if it over laps another part of the problem domain so that code can be shared. In fact, learning the problem you are solving is the hardest part.
putting the 'B' in LGBTQ+
Sorry but I had to let that one out. "Code that matches my passion." is priceless.
When you start looking at a mortgage payment, car payment, grocery bill, doctor bill, etc. you'll realize that you work on something you can do well. Save your passion for your hobbies. Code on the bleeding edge at home.
Do you honestly expect business to conform to what you want to do instead of what works for them? Answer truly. And if you don't come up with "Heck no!" you need to rethink how it works.
Sure COBOL may not be for you. Good deal. Don't learn it. But if you're applying for a job and they need LegacySystem 5.7 and you tell them you don't know it, won't learn it, but would consider writing in BleedingEdgeSystem 0.54 you can pretty much figure out what the answer is going to be.
I've been coding since 1976. Yes, 1976. I've learned many languages. Some I've liked, some I haven't. But if the business needs it I learn it. Sometimes I learn it just because I want to. I missed out on COBOL (don't ask) but may just add it to my list of things I want to investigate.
I'm not being a troll or at least I'm not trying to be one. Some people will probably read that first exclamation and not go any farther. But sometimes you really do have to wake up and smell yesterday's coffee burning in the pot.
Ya I am cynical but this is just the way the tech market works.
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
<shameless plug>
In our research group e.g., we're evaluating aspect-orientation (AOP) as a means to both reverse-engineer (understand) and re-engineer (modify) legacy software written in Cobol or C. To this end, we've designed and implemented an aspect language called Cobble (http://faramir.ugent.be/~kdschutt/cobble/) and applied it on some typical legacy problems like Y2K, transition to Euro, encapsulation of web services,
</shameless plug>
Now, the biggest problems we encountered for Cobol (contrast this e.g. with the Java world) were:
Eventually, we had to implement our tools from scratch, tied to a subset of one particular Cobol dialect. This severely reduced the time for actual research. So, Cobol is not so simple as it may seem at first sight and this is aggravated by the limited (compared to Java, C#,
Huh? How does this comment apply to something abstract like a programming language? The COBOL language didn't degrade over time, yet somehow everyone's perception of it went from "this is the tool we need to use to do everything" to "please let it die."
Like every other widely-used language, COBOL has its place. You might not want to write a video game in it, but you also wouldn't want to write a billing system in C++.
The Big News Page
COBOL is such a deceiving language. When I was young, and this is a true story, I went to libraries as I was very interested in computers (early 70s). I pulled out this illustrated book on computers where they showed bits of code here and there. I saw this wonderful line:
MOVE INVENTORY-IN TO INVENTORY-OUT.
WOW! I say to myself... robotics! COBOL is able to control robots by moving inventory. I signed-up for three years of Data Processing only to find out that it in fact only moved data from one part of memory to another... I was very very disappointed.
I bet you that's why COBOL is so popular. By being so verbose, it attracted massed of kids on false promises of what appeared to be the ability to control robots. That would never happen in C or Java.
Views expressed do not necessarily reflect those of the author.
Just to twist knickers, there's Object-oriented COBOL running on the Java Virtual Machine.
Can we get a "-1 Wrong" moderation option?
... I can program in C/C++, Pascal/Delphi, Java, VB/Basic, Perl, a bit of Ruby, Python, and several shell scripting languages/applications like sed/awk. I find cobol to be the most obnoxious pain in the ass language I've ever used. I had to take two semesters of it in college and I hate it. I hate it just like I hate RPG. They're underpowered, obnoxious, and annoying to work with. Screw cobol, screw rpg. I'd sooner bag groceries than program in either language.
Shadus
Alternatively, you can begin teaching programming as a trade, much like plumbing, construction, etc.
Programming business processing is neither exciting, nor particularly fun, but it is however a pretty good way to make a living. You dont need the chops of someone who can write a TCP stack or a Kernel or a new Compression or Encryption algorithym to do so. What does it really take to say calculate the interest on someones savings account and post it to the acount transaction file, not much programming wise. There is no parsing involved, no tokenizing, nothing fancy at all.
I make a decent living writing custom applications and I rarely do anything very complicated. I write nice custom apps in Delphi, mostly against Oracle. Nothing earth shattering in the GUI, I stick to the basic control set and they just hum along either on windows or Linux ( Kylix ).
Business operations production coding can be tought to just about anyone with a logical mind that can understand the concepts of data flow, which as many have pointed out, things like VB, Delphi and the like support very well, even if they are pourly coded by people with no formal training.
Someone with business background ( mine came from banking and healthcare ), that can understand the concepts of programming in a logical progression to get from point A to point B can be trained in a given language like COBOL or TCL in a matter of a few months, possibly less, and can then function confidently in a business transaction production environment.
I went further and taught myself most of the very low levels of SE by reading many many books and experimenting. Programming anything is no magic, it is understanding the interaction of software with hardware. The first really difficult thing I ever wrote was an interupt driven serial I/O processor, back in uhmmm, around 1985, I wrote in a combination of 8086 assembler and Turbo Pascal 3.1.. Hmmm I think i am getting old.
I dont have a degree in anything except hard work and study.
Hey KID! Yeah you, get the fuck off my lawn!