COBOL IDE, Compiler for Linux 26
Grizzly writes "Okay, go ahead and laugh. But there's a lot of COBOL out there, and that has kept a lot of businesses, especially outside the United States, from even looking at Linux. Linux and Main has a story on KOBOL and how it might make bringing those COBOL apps over to Linux possible."
Re:BTW, what "cob2c" compiler is this? (Score:2)
TinyCOBOL ? (Score:1, Informative)
The project is hosted on SF.net at http://tiny-cobol.sf.net/ [sf.net], check it out for more details.
Re:back to the future (Score:3, Insightful)
Those Cobol applications are things that my transportation agency count on to do buisness, like the payroll system, and the parts maintence system for all the busses.
We are looking at $450,000 to renew the lease on the mainframe in two years, or we can port the applications to our Unix environment that we already have and tell IBM what they can do with their mainframe.
Its much easier and more cost effective to bring the code over nearly as-is versus migrating to a new language entirely.
Re:back to the future (Score:2)
If it really is, then bravo. You've made the right decision. In my experience however, most people making this decision haven't taken into account the complete cost of these applications. More than the absurb hardware maintenance costs, there is an elevated cost for running batch-oriented applications. How many times a week does a human have to intervene overnight when a job fails? How much does that human cost you per hour in salary, benefits, office space, etc?
My point is that mainframes and the applications designed for them were built under the assumption that an hour of human time is orders of magnitude cheaper than an hour of computer time. Now, especially with high power to cost ratio systems like Linux/x86, that ratio has inverted. It's now much cheaper to let computers do the repetitive work and send the humans home. You might be able to save enough to justify spending nearly half a million dollars on some quality people to rewrite those applications for you.
Re:back to the future (Score:1)
For example, after our Cobol programs are ported to the unix system on Oracle we will be able to gradually replace parts of the application with another application that accesses the Oracle database (maintaining the buisness rules in the database) where both systems can operate in congunction untill we have perged all our Cobol code.
This takes time. Maybe by the time we are done doing it the language that the replacement code was written in will me legacy and need to be replaced.
But if we port directly to another platform with another language ourselfs, or if we are porting to another software package, we are looking at a longer term solution where both systems will have to be maintained durring the migration (and thus more mainframe leasing costs) than we would be looking at if we just move the Cobol applications over to the Unix environment and port them from there.
Re:back to the future (Score:2)
We have a front-end implemented mostly in C and Java running under Win2K and Solaris. The GUI is just Java and it sucks big time.
Way OT, but what the hell... (Score:1)
PerCobol LegacyJ (Score:3, Informative)
http://www.legacyj.com/lgcyj_perc1.html
My agency has had a developer trying to get Merants Cobol working on a Solaris system for some time now and hasn't had any luck getting it to connect to Oracle. All the instructions we could find refer to DB2, even those where incomplete. Merant was not willing to support us since we purchased the software directly from Sun.
I couldn't find any instructions on getting Kobol to connect to Orable either, but its still a pretty new product so I will be revisiting it later. But with PerCobol it took about 1 hour to figure it out. (this is including the 30 minutes it took to download the 100mb evaluation copy).
The cost of PerCobol is MUCH higher than Kobol's $39.95. Its more like 5000 dollars per developer (if you are deploying to a Solaris server which we are). But it still looks really good compared to what we have experianced with Merant and we can redeploy the mainframe applications to java applettes on our intranet with PerCobol with little trouble.
Well... (Score:3, Funny)
Re:Well... (Score:2)
Don't disrespect COBOL too much (Score:5, Insightful)
But there it is on the resume - you did C++ programming 25 years ago, and in the eyes of the young'ins, that makes you unemployable. I've worked with enough people with many decades of experience to know that these people can be the sharpest ones in an organization, even if their experience includes COBOL.
I know this is offtopic, but I can predict what some of the comments are going to say.
good for linux (Score:4, Insightful)
While it's true that cobol is often associated with legacy programs, cobol programs are a niche market, one that linux could exploit (recompile your cobol app for linux and save!). So far, linux growth has mostly been at the expense of other unix rather than cutting into the desktop (windos) market. I'm not suggesting that linux or x86 hardware can compete with mainframes, but a modern x86 box running linux could replace a mainframe for some cobol apps.
Additionally, scary as it sounds, ne wCobol development is still being done. A company I used to work for sold (and still sells) expensive bank software written in cobol and using Tandem SQL.
If it gets the job done, it gets the job done. That applies to linux and cobol.
What these compilers miss (Score:5, Insightful)
* VSAM -- IBM's keyed file format. It's simplistic in concept, but manages keyed files very well. A relational DB might be better, but you'd still have to convert the code.
* IMS -- IBM's hierarchical database. The syntax isn't declarative like SQL, but much more intent on moving a pointer throughout the database.
* Other OS calls.
Re:What these compilers miss (Score:1)
As for IMS, there is a command level preprocessor available for it. It is just rarely used. In fact, it is the same preprocessor that is used for command level CICS.
PowerCOBOL (Score:1, Informative)
It's not perfect however, there are some annoying bits about the IDE, at least in the demo that I tried (based on an older release). I had to close the editing window before I could compile. It becomes annoying opening and closing the same window during tests. Hopefully this issue is solved in newer releases.
I'm pleased that there will be KOBOL for Linux. I hope it measures up to PowerCOBOL eventually.
You're missing the most important thing (Score:4, Interesting)
I've been in computers 20+ years, and worked with all sorts of different platforms and languages. For some reason, there are more women who program in COBOL than in any other language.
You guys in the ultra-geeky C++ shops, look around. What's the ratio of males to females? In most COBOL shops, it's equitable. I've even worked in places where there were more women than men.
I've recently interviewed for a job elsewhere in my organization where I'd be swapping mostly COBOL and a little Java for full-time Java, SOAP, etc. Sounds like a much cooler job... but this group is off in another building, and there's only one woman. Don't get me wrong, I'm happily married... but I like having women around.
So what if all the women will look like Grace Hopper soon? I'll look like Hume Cronyn.
Programming needs women. Go COBOL!
Garg
Re:You're missing the most important thing (Score:1)
Therefore Cobol programmers represent the heterogeneous make up of the business world, while other computer disciplines represent the nearly all male world of University CS classes.
Listen you whippersnappers (Score:1)
Re:Listen you whippersnappers (Score:1)
Reinventing Micro Focus? (Score:1)
I have nothing against the Kompany, in fact I like them quite a bit, but this seems like a stupid move.