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+
That is not a good thing. COBOL is hands down the worst language in common usage today. Its dominance is not continued by good programmers but by managers who consider it a 'safe' choice. Of course it hasn't been rewritten, the very ground that it is built on is considered antediluvian in concept.
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.
It seems unlikely to me that any 20-30 year-old piece of code would adequately represent good design principles, have good documentation, and be well-understood. Well no. 20-30 years ago, some companies took the time and had the resources to do it properly. I worked for one. It was a technology sector company with millions of customers, and highly profitable (gross margins of more than 90%). That company still exists, and critical systems still run in the original language, despite multiple projects subsequently to 'modernise' and replace the old applications. The kicker is the language wasn't COBOL, but VAX FORTRAN-77, using RMS and DECforms. Some serious business analysis was done up front. The subsequent attempts to replace with Oracle, first on VAX, then Oracle on IBM mainframes, then something (I don't know what) on Solaris on high-end Suns all failed badly. The application is 25 years old - almost certainly older than some of the programmers maintaining and extending it even now.
Just to twist knickers, there's Object-oriented COBOL running on the Java Virtual Machine.
Can we get a "-1 Wrong" moderation option?
I'm always fascinated by the programming language debates here at Slashdot. They don't make any sense to me.
English is a terrible, confusing mess of a spoken language (and not so great written). Some of the Asian languages are written language monstrosities. Modern Japanese has four alphabets (including romanji)! Esperanto allegedly fixes all that. So we'll all be speaking and writing Esperanto any day now, right? No.
COBOL thrives because it gets its job done, and it has an enormous (and growing -- 2 billion net new lines each year) installed value. That's not going to change any time soon although, just like English, COBOL will evolve.
Speaking of evolution, there's an awful lot of dated knowledge about COBOL in this long discussion. It's hard to know where to begin to address that. Looking just at the relatively recent IBM stuff, modern COBOL (called "Enterprise COBOL" in IBM parlance) is now object oriented (if you want or need), has language syntax to parse and generate XML, and has well specified cross-language calling conventions in every direction you can imagine (COBOL to Java, Java to COBOL, C to COBOL, COBOL to C, etc.) The environmentals and tooling keep getting more and more interesting, and that's probably a lot more important than the language itself. Something called WebSphere Developer for System z puts all COBOL development onto a graphical Eclipse framework. (Want to set a breakpoint? Drag a stop sign. Can't remember what verb comes next? Use Code Assist. Want to map copybooks to/from XML? Drag and drop.) No more TSO/ISPF/PF12 stuff (unless you want). The IBM Debug Tool U&AF has great code coverage measurements as you test. Application Performance Analyzer lets you peer into all your code to tweak it and optimize it extremely rigorously. Fault Analyzer zeros in on exactly where an abend occurred and helps you figure out what was going on in order to quickly fix the problem. The source code libraries/change management tools (SCLM, Endevor, Panvalet, ChangeMan, etc.) are first rate for team development and, at least in the case of SCLM and Endevor, plug into WebSphere Developer for z so you can do check-ins/check-outs from your PC. The testing tools (IBM's or Compuware's) are also first rate and keep getting better. You can even do many wild things most other languages can't, like instantiate COBOL as EJBs running inside WebSphere Application Server for z/OS alongside Java EJBs, interoperating transparently and as full peers. Re: Linux (including mainframe Linux), AccuCOBOL, a commercial compiler, seems to be getting reasonably popular. For code analysis and understanding IBM's WebSphere Studio Asset Analyzer, Asset Transformation Workbench, and CICS Interdependency Analyzer are all quite helpful, and I don't think I've seen that level of sophistication in comparable tools for other programming languages. It's probably also worth mentioning Language Environment, which puts COBOL on the same common runtime foundation as every other programming language for tracing, debugging, abend analysis, etc. LE started about 20 years ago, but it has evolved and matured quite nicely and keeps getting better.
I would like to see a 64-bit z/OS COBOL compiler. IBM hasn't pulled the trigger yet, out of an abundance of caution I think. (COBOL requirements tend to get driven by "we're going to need it in X years" rather than "wouldn't it be cool to have?" And I think we're only just getting into the time when direct support for 64-bit data structures looks like it might be moving into the "need soon" category.) C, C++, Assembler (obviously), and Java have all already made the leap on z/OS, so my suspicion is that COBOL is next. Note that 64-bit v. 31-bit -- yes, 31-bit -- isn't really the same issue as on other machines. You can mix 64-bit and 31-bit code freely on z/OS, including cross calling conventions. The only issue is whether a single address space running a COBOL program can itself contain a 64-bit data object of some kind. Right now that's 1.8 GB of data objects, or thereabouts.
... 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!