Slashdot Mirror
COBOL Will Outlive Us All
jfruh writes "Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works. The truth behind that is the reason that so much decades-old COBOL code is out there still driving crucial applications at banks and other huge companies. Many attempts to replace COBOL applications flopped in the 1980s and '90s, and we're stuck with them for the foreseeable future — but the Baby Boomers who wrote all that code are now retiring en masse."
Well... that and the fact that COBOL is actually very good at what it was made to do; batch file processing.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I code in Java but I'm also not above coding in an old language. My C skills are one of the main reasons I'm valued where I work. I did learn some COBOL at one stage and remember thinking it was tedious...but I'd happily pick it up and apply my knowledge to it.
Writing COBOL is not just easy, it's fun! It takes about a fortnight to work through the manual and become fluent. It uses very English like syntax. It's much easier than FORTRAN or C as it's so small! Lets face it in this world of UNIX massively parallel cloud social web computing, this is hardly a complex problem to solve – it's already been done by the folks that wrote COBOL. A simple database! So get that manual out, and have a try!
The purpose of existence is to make money.
Yup. I was hired into one of those mainframe companies that worked with COBOL and JCL. The work was the most menial of works I had ever done(after they trained me for 6 months in it).
The financial sector, the lumbering dinosaur that accepts change only when they have no other option, and the ones maintaining decades-old mainframes really have no incentive to change technologies at the moment. It's easier to just outsource the maintenance and servicing of the mainframes. There are enough of coders (like in the company I joined) in developing countries across the world who would gladly take it up.
From my experience, there is little development happening any more. I think the day when they run out of people who want to this crappy menial job (which is never) is the day COBOL will go extinct.
All of this has happened before and will happen again...
I use to make a living rewriting these solutions to suit modern platforms. In my experience, it wasn't the language that made these solutions great pieces of engineering, I think it was either better programmers or a better culture regarding quality, maybe they were better motivated? I for one would love to see what some of these guys could have done if they just had a bit of syntactic sugar to sweeten their code to get around some of the clever but ugly hacks we've all seen.
why bother paying tons of money developing new software, going through the painful growth and ironing out all the bugs of the new software, educating people on the new software, importing your current clients into new software, getting modern hardware to run the new software, installing modern networking equpment for the new hardware to run the new software, etc.. theres just no real reason to upgrade the software. There won't be many new exploits for COBOL based software as well, since its not used by the average person.
http://interserver.net/
http://en.wikipedia.org/wiki/COBOL
Why is Snark Required?
While it is true that many companies run mission critical COBOL applications, they are very well aware of the issues that this poses. Many IT shops approach them proposing to replace existing applications which doesn't make any economic sense whatsoever... the risk associated with such a project makes it a no-starter.
What smart IT shops are doing is proposing to "modernize" existing infrastructure. The way it's done is with analyzing key "services" that existing apps provide and then "wrapping" them with modern technologies such as web-services. This way it's easy to build modern UIs on top (HTML5, Mobile apps etc) as well as build another backend for new functionality under the same new UI. From the business's perspective it looks like an entirely new application with a modern UI and the ability to add features while at the same time not assuming the tremendous risk of retiring existing apps.
The premise of the article is that there will always be COBOL jobs but the reality is that the approach I describe doesn't really require any COBOL knowledge (or hardly any).
One of the things that I seriously loved about COBOL was the basic English structure of it. Properly written, you (the programmer) could sit down with an actual USER, who was not a programmer, and debug it. In my opinion, one of the biggest advantages of COBOL, from the organizational point of view, is that it was so easily maintained.
Spaghetti code? That's an absolutely crap thought process to dislike an entire language because of poor coders. Those exist with every language.
It exists, because its good. Simple as that.
Every 3 to 5 years this topic comes up. It's almost like some new batch of CompSci graduates start to evaluate the state of the industry, and share their "discoveries" with the world. Except it is the same old discoveries couched in modern terms.
Software that did not function as intended? Such an amazing surprise!
I'd swear I read the same article at the end of the 90's, before y2k .
Slashdot, fix the reply notifications... You won't get away with it...
I belive that all larger mainframe customers run on modern hardware. Mainframes are still developed and upgrade regulary. You can even run previous version togheter with current version of the hardware in your mainframe cluster. Additional machines can be hot added and work migrated live between the machines.
Mainframe have all the bells and whistels of the "cloud" and have had for several years.
My work place recently replaced the tape storage system to a new one, or rather the 2 tape storage systems as we run geographically disperesed clusters of mainframe in order to provide guaranteed uninterruptable service.
One of the things that continues to fascinate me is the tendency of computer folks to create new programming languages -- claiming to be 'better' than their predicessors for solving problems but most often just different and frequently worse. Compared to the development issues I have experiences writing C, C++, shell scripts, various assemblers and macro languages, Fortran, APL, various Basics, Forth, Focal and many others whos names I have forgotten over the last 50 years, Cobol was trivial both to write and to generate. Wordy but boring, it just did its job. If I were doing an accounting application it would just make sense to use something like Cobol. Problem is that with IT, marketers are continually dusting off and renaming old ideas -- new doesn't necessarily mean better. Sometimes old just means it works. And the word obsolete gets thrown around a lot -- especially with regards to Cobol. Have any of us ever really questioned what it means? Obsolete in my mind means replaced by better approaches, not just different, Effectively it seems to mean paid for and understood, therefor bad, from the perspective of those folks who make their living from selling stuff. From an implementers perspective, and the businesses that pay for it, there is a lot to say for suitability for a purpose.
Viewed through the eyes of a modern programmer, COBOL is indeed a joke. A horrible one. It violates nearly every single principle of good language design in what appears to be a misguided attempt to make programming "friendly." A CS undergrad would get a poor grade turning in something like COBOL as a Programming Languages 101 project.
But for a language first specified in 1959 (when computing didn't even have the Integrated Circuit yet), it's a work of staggering genius; they didn't HAVE all those rules of good language design to fall back on! At the time, FORTRAN had been out for all of two years and LISP for one; hardly enough time to have much experience with knowing what not to do, and neither of those languages targeted the same problem domain.
COBOL made modern computing accessible and useful to businesses. It's programs have maintained decent backwards compatibility for about half a century. And for all it's foibles, all those hundreds of millions of lines of COBOL actually work. They may be a disgusting kludge, a result of decades of compromises, but these gigantic black boxes of spaghetti Work. And there's no reason to think they'll stop doing so any time soon. Nor any reason to believe that replacing them would be in any way cost-effective.
...these days there's JAVA for the masochists!
COBOL.
cockroach.
I think it's pretty obvious.
It takes a week for a programmer to learn COBOL. A month at most to be proficient. Of course depending on dialect and environment, it can take more to be productive, but that's true also for COBOL programmers coming from other backgrounds. That means there will be no big shortage of programmers as big companies can train in-house in a matter of days.
The problem with COBOL is that it will erode your sanity with mindless repetition and superfluous verbosity. If you are put to make COBOL programs, make a generator for the most common tasks. It won't save you perhaps such a big amount of time, but it'll make life more interesting.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
For those teams that actually get a training budget, it'll be 2 days for one member of the 10 strong team per year. I last got training that I didn't pay for myself in 2000.
Not just COBOL! What people don't understand is COBOL is the glue language of the mainframe. COBOL is the easiest and most productive way to write CICS, IMS, DB2, MQ, etc applications. Sure, you can use other languages, but IBM has invested decades in making their technologies easy to access from COBOL.
What is going to hurt is the brain drain when people retire who are experts in IBM's huge, over-engineered technologies like CICS, IMS, and DB2. A reasonably motivated programmer could get a Mike Murach book and learn enough COBOL to be productive in a fairly short time. What is going to be difficult to replace are people who know CICS, which is an operating system within an operating system and inhumanly complex.
And, since you can't run CICS on Linux, how would you learn it? About the only way to learn it is to get a job working with mainframes, but of course employers only want experts with 5+ years experience. Eventually, maybe they'll get desperate enough to train someone. There's the rub: The short-sighted technology industry has let two or three GENERATIONS come along and learn Linux and Java. Everyone has been chasing the existing CICS experts, not making more. Now, generations have never used an IBM mainframe. If a company started today training in-house programmers, it could take years to develop a new generation of CICS experts. That's what you get for being short-sighted and focusing only on the next quarter.
I hope the impending brain drain hurts companies so bad, and causes them to lose so much money, that they start investing in training once more.
Does anybody know what language(s) are used for the "Dead Hand" second-strike control system that the Russians were working on during the Cold War? Personally, I'd nominate them as the programming languages that will outlive us all...
It is a bromide perpetrated by ITAA and business groups that we can't find enough programmers to replace the ones who are retiring.
The simple truth is that no one wants to PAY what people are worth, and there is rampant age discrimination:
http://www.itbusinessedge.com/cm/blogs/tennant/yes-age-discrimination-is-worse-in-it-than-in-other-fields/?cs=38549
Be willing to hire, retrain, or do whatever it takes to employ people over 35 and this so-called problem will be
shown to be the chimera that it really is.
Aye, but you call that living?
Science is all about firing a drunk pig out of a cannon just to see what happens.
as will Java, the new Cobol. So what?
-><- no
"Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works.
Actually, that's not true. COBOL programs are more durable because the COBOL architecture is very simple. Almost all of the work other than raw I/O was done in the COBOL code itself. Modern-day systems are heavily dependent on many external components, almost all of which are constantly evolving. So the "if it ain't broke, don't fix it" approach is actually more of a "how long can you afford to delay upgrading before the whole thing collapses beyond repair?"
Even legacy programs didn't actually get better with time. Once you reach a certain point, it's more like you move the bugs around. The old "pressing on a ballon" analogy goes way back.
It's not about COBOL. It's about knowing something about mainframe programming that would get you the job.
http://stackoverflow.com/questions/4433165/learning-cobol-without-access-to-mainframe
Heh. In my job search I have actually been, well, surprised might not be the right word, but amused, at all the COBOL, FORTRAN, and mainframe postings. One thing I think they are getting themselves into trouble with though is all the postings I have seen require decades of experience in the technology, so they seem to be trying to replace retiring boomers with similarly skilled people, but not creating entry level or training paths.
That would help yes, but another part of the problem is, with these older technologies, many companies are only interested in drop-in replacements. There are few (if any) companies out there taking on entry or mid level developers for mainframe stuff, so once the current crop of experienced people run out they are going to be in trouble.
The "Update"
and the "Print"
At least that's what a lecturer told me many years ago when I did COBOL at uny. I didn't get on with it initially, then I got bored and opened the book... Then I learned that what the lecturer was telling me was his idea of what COBOL ought to look like and not generic. It got a little more interesting after that (along with the student competition to see how many errors we could make the compiler generate with the minimal amount of syntax errors - one mis-placed full-stop managed to get it to the limit of 999 once)
I've not written a COBOL program for over 30 years now. I don't miss it.
-G
It violates nearly every single principle of good language design...
Whose principles are those? (That was rhetorical)
they didn't HAVE all those rules of good language design...
Again whose rules? (That was rhetorical, too)
There are no physical laws and mathematical rules that state what good design is. None. There are some folks who promoted themselves as being the "ones who know what's correct" but there are no "rules".
If the code:
then the code and language is a wonderful design. Everything else is arbitrary.
Because using the standards expressed in the parent, Perl is the biggest piece of shit EVAR!
I witnessed an argument in a CS class years ago between the professor (he started it by being a condescending prick) and a student who had a MSEE and being forced to take the class (C++) because his years of embedded design and coding in C++ didn't count because he didn't have a class in it. When the engineer pressed the professor about these "rules" and logically analyzed them, the professor being intellectually beat, said in exasperation, "It's the way _I_ want it! OK!?"
So, whenever I see folks spouting off about these rules, they are parroting something for a professor or from a book by an "expert" or it the way they think it should be.
..to fix the Y10K bug.
As a guy who worked on some pretty complex financial software, I can tell you this; If you come to a company and say "Hey, look. Your software is outdated, and just not cool anymore. Let us fix it." They will say "OK, how much will it cost, how many times will you screw up (and you WILL) and how much will it cost in lost productivity, development and training time?" In other words, prove to me that the cost and risk outweighs the benefits of leaving my not-cool but working structure in place? Know what? You can't. When you are talking about financials, companies are justifiably VERY risk-averse. And yeah, people laughed at COBOL when I was coding, and even back in the 70s when I was learning. This is an old argument and the fact is COBOL will be around a very long time whether our new compsci grads like it much or not. They aren't paying the bills and looking at cash flow. They just see all that legacy code and say they could do it better. Maybe you can. But you're not gonna.
MAINLINE.
PERFORM WHINE-WHINE-PROCESS UNTIL COMPUTERS-DIE = 'Y'.
STOP-RUN.
WHINE-WHINE-PROCESS.
DISPLAY 'COBOL is ancient.'.
DISPLAY 'COBOL is something my grandfather wrote.'.
DISPLAY 'COBOL is wordy.'.
DISPLAY 'COBOL code is spaghetti code.'.
DISPLAY 'All COBOL programmers will eventually die or retire.'.
DISPLAY 'COBOL is only used by banks and insurance companies.'.
DISPLAY 'COBOL is hard to use when compared with a modern language like java.'.
DISPLAY 'COBOL is hard to use when compared to C++.'.
Still some of that around here.
SHOOT ME I KNOW COBOL
We've seen for quite a few years that many companies expect new employees to "hit the ground running", with nothing more than a cursory new employee orientation. Training, especially on-the-job training and formal mentorship/apprenticeship models, have largely fallen by the wayside. In other words, hiring managers want employees who have all the skills to do exactly the job the company needs, in exactly the way they think they need it done. Then they are surprised when they can't find someone who exactly matches that profile.
[For the record, I am not one of the bitter long-term unemployed who have been stung by this. I was schooled in engineering, got hired as an engineer right out of school, and am happily employed as such today. But I am cognizant of the largely artificial obstacles that many of my peers face]
It is about documentation. I am an employee of a company that had one of their main systems in COBOL and we converted it to Java. Performance wasn't nearly a concern and we have SLAs with customers. The problem we faced not only in converting COBOL to Java, but also C to Java, is that no one knows everything the application does.
Programmers make undocumented changes and suddenly if you do a conversion to another language you are missing features that you didn't even know were there. You should never have to look at COBOL code or C code to rewrite an application. There should be a business document that says what the application does at a high level and you design/write code based on that.
It isn't about, "if it isn't broke, don't fix it", companies are handcuffed because of lack of documentation. When we were able to retire our mainframe, we were able to prop up 4-5 web servers for less money. Mainframe costs these days almost require sacrificing your first born.
Yes, companies can spend far more time and effort on customizing an ERP system to meet their needs than the system itself costs. Then, when new releases of the system come out, the customizations need to be done again. The other alternative is to change the company's systems to match the ERP. That's what my employer did when it outgrew the previous system and realized that it was too difficult to keep customizing the system. It meant changing lots of little things throughout the company. For example, every part number had to change to match the rules for the new ERP system. All said, it was probably cheaper to make the changes in the company than in the ERP, and now we can upgrade to new releases without much difficulty.
It isn't just the financial sector, its the medical sector, major distributors, casinos, and more, who use mainframes and similar (I work on an iSeries which at our scale is very much a mainframe - especially in reliability). COBOL and also RPGLE (looks like C/Pascal now) form the back end of many systems because of their ease of programming and especially because they are good at business math. Front end we have web facing apps; javascript/php/etc; RESTful services, and more. New development occurs everyday and is far more modern in its application that your aware. It isn't a land of green screens and such, but those do have their place.
The technology is anything but outdated, if anything we are as modern if not more. The key difference is dead nuts reliability, both in code and hardware. Downtime usually is when the site fails.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
And this is why it's good to arm yourself with solid languages like COBOL, because in 10 years when something finally needs to be replace your the one guy who can.
If you have any contact with COBOL in your profession, check out OpenCOBOL.org.
With a free COBOL compiler, you have an option of moving this ancient code onto a modern platform with fast CPUs. If you find it lacking, start coding!
I've tested it for Linux and Cygwin, and it works.
http://www.coboloncogs.org/
The only true part is that the only people still working as programmers who cut their teeth on COBOL are baby boomers and will be retiring sometime in the next two decades.
So what?
Comment removed based on user account deletion
COBOL was the very first language I learned when I was a fourteen-year-old freshman in high school, way back during the Carter administration. I found out decades later that my great aunt, Grace Hopper (of "There's a bug in the system" fame,) helped develop it and it's successor, SNOBOL. It was used as the pedagogical platform in my school district for teaching data processing principles, which are (sadly) orthogonal to programming principles. I still have my Shelly & Cashman ANSI COBOL -- Introduction to Computer Programming text, which used examples from payroll processing and accounting report generation, the dominant paradigms of the mainframe world, to convey programming concepts like looping and conditionals. Ironically, it's sitting on my reference shelf right next to K&R. The book even came with a plastic flowchart symbol template, conveniently printed with a scale along the edge for measuring the physical width of an output column on your fanfold paper to help you determine your PICTURE clauses, and a list of the ASCII control codes for chain printers. Recursion was impossible in COBOL (the compiler tossed an error if a CALL referenced itself) and the idea of a UI was equally a non-starter, with dynamic input functionality at the INPUT $VAR level of BASIC. In retrospect, it was an amazingly poor way to introduce programming principles, and I'm not surprised that FORTRAN, then BASIC, and ultimately Java, took over from it. Still, I can claim (in my best Gerard Butler THIS-IS-SPARTA! voice) that I-PROGRAMMED-COBOL-ON-PUNCHCARDS! :)
I went to college and was going to specialize in VB.NET and RPG or COBOL and during the first RPG class, I changed focus to web programming. That emulated IDE with zero assistance was so ancient and backwards and slow and mistake-inducing, it was unuseable. The unfortunate line splitting was unreadable. I chose midrange and mainframe programming because of the money and guaranteed job but I dropped it pretty darn quickly because it wasn't worth any amount of money to put up with that. I also was the best programmer my advanced VB programming teacher had ever seen. I got a 105% on the final project. I started programming because I was good at it, not because of the money or any other reason. So if someone like me isn't willing to deal with COBOL and RPG, good luck finding someone else. Companies just need to dump it.
I'm now head IT manager at a medium-sized company and we have to dump our current CRM because the company behind it got aqcuired by another so there's no support or updates for server 2012 or IE9 and we bought it in 2009. Anyone using COBOL has at least 10+ years of not quite understanding that exact point.
Yet you really don't see similar kool-aid drinking driving the replacement of COBOL. You'd think by sheer chance some dimwit PHB would come in and arbitrarily decide "Oh let's replace all that COBOL code with something written in Ruby on Rails by an intern," because he'd just read about Ruby on Rails on PC magazine and was impressed with how quickly you could develop a web-based "Hello World" application.
Admittedly a probably largish number of PHBs have attempted that and subsequently been fired by incompetence, but you'd think enough of those projects would limp along because they've already spent so much money, effort and time that to admit defeat would mean admitting gross incompetence at every level of management straight up to the CIO. Which, I'm pretty sure, is why Lotus Notes and Citrix are still around.
Funny story, back in the 90's when IBM was replacing Profs with Lotus Notes, some dim-witted PHB decided "Oh well PCs can do anything that mainframes can do, so let's write a Lotus Notes replacement to RETAIN!" RETAIN being the mainframe-based app they use for trouble ticket tracking and bug fixing across, I'm pretty sure, all their products. Well long story short, that project went on for a couple of years and then quietly disappeared. A decade later, they were still using and actively maintaining RETAIN. I wouldn't be surprised if it were still being used and maintained to this very day, even after IBM's acquisition of Rational.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
If you're already proficient in a programming language, you can pick up the basics of COBOL in an afternoon (OpenCOBOL is pretty easy to install). I did just that last week. Totally educational. Modern programmers don't know how good they have it!
-- This sentence is false.
Dusts off CV! Do I still have to use those damn punch cards? If so I will require a new Braddle!
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
The main reason why it was so successful is that the DBMS is a first class citizen within the language. I have yet to see any other major language that has picked up on this point.
Do you think the TCO of changing .NET or Java platforms every couple of years is cheap?
No way José!
Joel Spolsky addressed the issue some time ago: http://www.joelonsoftware.com/articles/fog0000000339.html
COBOL developers are not retiring, they are being pushed out in favor of younger, cheaper, visa workers. Or, better yet, offshore the work.
COBOL devs are not retiring, they are being replaced by much cheaper offshore workers.
For an American, learning COBOL is only useful for training your offshore replacement.
Everybody hates it, but it will survive nuclear holocaust so you have to give it some respect.
I haven't thought of anything clever to put here, but then again most of you haven't either.
I work for a large bank. When I mean large, I mean one of the top three. I have to regularly review code changes going into the Mainframe (yes, we have a mainframe). I see programs that not only have comments that go back into 1980, I see ports of programs that appear to come from times even earlier than that.
Management has spent the last 6 years feverishly attempting to get rid of the entire mainframe and everything that goes with it, and bring everything into "a distributed environment", but so far we are still here. And what's more, I see more new programs going in than I see old programs being retired. That tells me we're here for a few more years, and maybe a few more years after that. COBOL isn't going away, at least not until the last Russian programmer dies.
If telephones are outlawed, then only outlaws will have telephones.
First off, the acronym is CoBOL, for Common Business Oriented Language. For thoses with snark about JAVA/Java...
Now, I'm pretty sure that, when most enterprises big or small set out to write new things these days, they're not including CoBOL in the implementation trade space. Yes, you can do a lot of things with the language that the originators didn't contemplate (I wrote a linked list program in my undergrad endeavor), but why hurt yourself in the process? The Indiana Jones knife-vs-gun scene comes to mind.
What's going on now is that, in the world, a bit of critical business logic is captured and exercised in the name of CoBOL, and folks saddled with it are afraid of messin' with what works for two reasons:
1. Afraid of not translating it completely in the new implementation, and not discovering that until the customer sees the result.
2. Afraid of differences in processing in the underlying tools that won't be identified until after the customer sees the result.
Notice the 'customer' in each of these fears. Some endeavors don't cotton to customer beta testing...
So, until 1) compelling business cases can be made for conversion, and 2) the risk of migration to something newer/better/sexier can be effectively communicated and managed, usually by folk who don't understand software, stuff like CoBOL will persist.
If you want to earn boatloads of money, train yourself and become proficient in COBOL, zOS, DB2 and how it all connects together. Some people I know (in their 30s) have these skills, charge $2000 per DAY, and have companies lining up to hire them. As the article says, they will never be out of a job.
If the code:
Works as designed.
Easy to ubderstand.
Easy to maintain.
You can't say there aren't rules, and then turn around and cite some. If you, modern programmer with experience with modern languages, were forced to use COBOL for a new IT code project, you'd run away screaming in short order. You'd wonder what demons had possessed your management to commit such an act of lunacy. That's not exactly the hallmark of a language considered "good" by any stretch of the imagination.
If that's your starting point, (and indeed, they are the starting point for guidelines for programming language design), then COBOL is indeed a failure (in comparison to modern languages; at the time it was state-of-the-art.) COBOL must be twisted and turned to perform much basic work... the only reason it works at all is through thousands of man-years of programming effort producing work at a pace that would make the most green IT code jockey look like a super-productive-genius. A superficial "COBOL 101" tutorial is easy to understand, but production COBOL code generally is not. And it's certainly NOT easy to maintain; the modularity we take for granted today simply isn't present.
Perl was, and remains, staggeringly useful for the tasks for which it was originally designed: as a sysadmin's "swiss army knife." By modern standards COBOL doesn't even work well for what it was designed for, but there weren't any alternatives at the time.
Again, as I stated in my original post, in comparison to the other languages of the time (besides assembler, there were all of two of them: LISP and FORTRAN, both of them in their infancy, and neither targeting towards the same problem set) COBOL was a revelation/revolution. But if it was a quality language by modern standards, it'd still be in use for new projects, yet it's virtually never used for new work.
I say this with no due respect--Fuck that language. 800 lines of Job Control Language to write "Hello World". Yeah, no.
As much as everyone hates Classic ASP, its what I'm good at, so it'd be nice to be able to continue to make a paycheck coding with it. But to my dismay, Microsoft keeps stating that it will eventually discontinue support for it on its server product line. And then there's perfectly good "abandonware" alternatives to IIS such as Halcyon iASP and Chili!Soft who's creators and owners simply shelved their product and don't seem to be interested in making a profit conducting business with it, and yet, they won't release the source code to make it free and open source either (sure would be nice and gracious since they don't seem to care about it anymore). I just don't get why the masses are giving Classic ASP the "cold shoulder". There's tons of websites out there still using it, and business owners don't want to spend the money rewriting their website all over again from scratch. Fortunately PHP is a lot like Classic ASP, so I've been doing PHP work on the side just as a safety net when it does die off like so many others have. At least I'll be useful when they finally make the move to convert.
Or better yet, translate their COBOL to Java and show the company how you can replace their mainframe with a cheaper solution.
I work for a fortune 1000 company. I spent a year in 2009 rewriting COBOL batch system to Java.
Old system - $1 million a year mainframe did nightly work in X hours
New system - 4 off the shelf x86 systems in Java do the nightly work in X/2 hours, for much much less money.
Took a few people a year to do. Will pay for itself pretty fast. Really no reason for most things not to move...
I have programed in a couple languages. Nothing serious, just the exposure. I don't think it really matters what language software is written in, it can be done badly. The problem I see with a lot of software is that the modules aren't re-examined when updates or additions are made. After a while, you get bloated modules that are eventually orphaned in favor of another module as another programmer comes along. or worse, another sub contractor comes along and the tie to the original programmer is completely lost along with the notes from the project.
Why are those COBOL applications still around, because they just work.
The business isn't worried about the latest version of the OS, or a library, or a VM (.net, jvm, etc...) breaking their mission critical applications, because they're backward compatible.
And why did it work? Noooo, not because Cobol is so great, or because programmers back then were so much better. The difference is simply that they had time to test it, and test it, and test it again, before it was finally deemed ready for shipping.
Today you get bananaware. Yes, bananaware. Matures at the customer.
Today, the deadline determines shipping date. Not "when it's done", but when the manager set some arbitrary point in time. Whatever we have at that point, we'll ship.
Now add that they hire the cheapest temps they can find instead of programmers with experience, and whoever has more than 2 years of XP tries to get the hell out and into some management position because the pay, let's face it, stinks, and you know why no program will EVER replace those dinosaurs.
They were programmed in a time when companies accepted that good software costs money.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Hire the retirees to train new developers in new languages to rewrite the software before it's too late.
I haven't seen a VCR in anyone's living room in a long time.
Yes, the latest and greatest zEnterprise mainframe will likely run your 1969 payroll software unmodified, or at worst with just a bit of (well-documented) work. I'm sure there are loads of features that have been added since the 360 days, but deep down inside those 5.5GHz processors beats an old, transistorized heart.
Facts do not cease to exist because they are ignored. - Aldous Huxley
I am a rare animal, starting off in the Pick environment, I worked with Wang VS COBOL for a handful of years and it did interactive green screen stuff, pretty damned well. In fact, before GUI was common, the way in which interactive programming was implemented in the Wang VS environment made it kinda, well, sort of standardized your interface for you a bit. Just saying. Never did big iron IBM CICS stuff, which the CICS guys always made it sound difficult, like you had to be ordained or knighted to do it. But the Wango-Tango did just fine. In fact the Wang VS system was decent in it's way, another casuality of "Open Systems". Anyhow back to my U2 programming, which everyone told me would be gone 20 years ago.
Someone wants to convert COBOL programs to RPG? What, and the CICS COBOL to RPG? I've seen that - a "language" that was intended to allow monkeys (management speak for secretaries) to produce reports, hundreds of lines long, running online stuff?
*gah!*
You can write bad code in anything.
And forever? Well, there's the story about the COBOL programmer who, in 1999, couldn't stand any more Y2K crap, and had himself put into cold sleep until after the year 2000. Unfortunately, his records got misplaced, and he slept on..and on, and on. Finally, they wake him up, and tell him it's the year 9998. He's shocked, and thinks of everyone he knows is long gone, but he's in the far future. Then he asks why they woke him up, and they tell him that it's about to roll over the year 10,000, and there are these COBOL programs....
mark, who long ago left a number of programs at a number of companies with "PERFORM 1000-DUMMY-PARAGRAPH THROUGH 1000-DUMMY-PARAGRAPH-EXIT WHILE (blah, blah, blah....)
Nah just need to up H1b to 300k from 115k. That will fix it.
Learn COBOL. Write some code to get familiar with it. Especially learn about VSAM and also the sometimes-critical sequential file matching algorithm. Learn some of the mainframe utilities, especially SORT.
Then go out and earn some money with it. The law of supply and demand dictates that as the older programmers retire or die, someone will be paid to do the work, and the money will go up as the supply of programmers shrinks.
Here is a link to IBM's mainframe linux: Linux on System z - Why
About the "system z" thing; IBM calls mainframes "z series", their aix machines "p series" and the intel servers "x series".
I don't know where the "z" came from for mainframe; I'm guessing "p" is for Power chips in the aix boxes, and "x" would be "x86".
Be aware that "mainframe" doesn't always mean IBM.
The most surprising mainframe I encountered last year was a Burroughs mainframe that is still in production for a large social services department (thankfully I just had to read data extracted from it, but the character conversions were sometimes surprising (no, it used Field Data, not EBCDIC nor Ascii in case you were wondering)).
Almost as surprising was a corporation that has a UNISYS mainframe at the center of their IT universe.
Yeah, mainframes are hanging in there.
Your doing it wrong.
Oddly, I have had experience in previous jobs with Profs, Notes and Citrix. My first job after college was working as a civilian employee of the US Department of Defense at a US military base as a computer programmer. We had Profs there, but its use was restricted to upper level military (maybe Lt. Col. and above) and high grade civilian employees. Yes, I'm sure it worked great - on the mainframe - but it was rather infamous for not being able to talk well at all to non-IBM mainframes. We kept it around because the general who ran our base loved it and refused to use any other mail program, so we kept it around merely to placate him. I kid you not - as soon as he retired, our Profs system was shut down permanently as his successor had no interest in using it. The upper military and civilian employees had to maintain two email accounts while that general who loved Profs was there - one just for Profs in case he sent them email or they needed to email him and one email account on our Unix mail server where everybody who wasn't the general preferred to send email.
My previous employer used Notes. Almost everybody in IT hated it when we switched to it. I will simply say what I said at the time - we picked Notes because non-technical managers could use it, not because it was any good.
The same previous employer also tangled with Citrix. I'll skip a long story that made us look bad with regard to Citrix and simply say that yes, it sucks. I've always felt that it was bought and used mostly by PHB types who don't know any other way to do things except the Windows way.
When you say mainframe without protected memory are you talking about hardware made last week or mid- to late-last century? I ask because if the hardware is THAT old it could probably be replaced by a mini-ATX system or Raspberry Pi and all the C in the world would run on it. It makes no sense to me that corporations would actually buy something new (made last week) that would HAVE to run COBOL because they didn't want to pay programmers the extra to convert that legacy code to run on more modern, protected memory systems. Now, I know it is probably happening, but WHY GOD WHY?!?!?! If it's the bottom line they are worried about they are doing more harm than good by perpetuating legacy code on legacy hardware. [shakes head in disbelief]
NT.
I can remember from my COBOL career over 30 years ago, that the problem then, and sure to be far worse now, is that a long-lived program became more complex with each update, and most programmers would do it quick and dirty to meet deadlines. The language has a certain elegance, but how it has been used can be anything but.
COBOL is the Latin of programming languages. Latin is used precisely because it is a "dead" language, and thus stable.
Table-ized A.I.
1, Most of the Replace Cobol failures were business failures, where the current, usually young Managers didn't understand the business knowledge distilled into the Cobol code. I was there for two of the Cobol ones and three PL/1 replacements in the Swiss Banking System, all BTW failures.
2. Cobol has NO PROBLEM going forward, PL/1, being much more complex is harder, but in any case the cost of writing an up to date compiler, or more realistically a front end to GCC or LLVM is nothing ( 10$ M), required only for a post 86_64 architecture, and the hardest part, the corner test cases is DONE.
3. For say $ 250'000 you would find lots of good programmers willing to learn either language.
There also exist compilers for both to both C and C++, but they don't help since the real wierdness,or brilliance is in the code, not its written expression which gets obscured in the translation.
MFG, omb
From the comments here, it seems to be. Most of you have no idea on what you are talking about.
If what the article says is true, then why can't legions of 50-something, 60-something EXPERIENCED COBOL programmers find jobs? Oh, wait! I almost forgot: many of these jobs have been sent to India! If experienced U.S.-native COBOL programmers are either retired or soon-to-retire, it's because they're being forced to and the corporate heads and powers-that-be in D.C. give every appearance of not giving a damn.
I ran into a DOZEN or so COBOLers. All but me were AARP members--I still got a year before AARP sends me my enrollment kit.
So a COBOL programmer is given a 5-year prognosis. He arranges with a hospital to be cryogenically preserved until a cure is found. On the appointed day, they prepare him, and he starts to feel a chill.
Next thing he knows, the chill is fading. The nurse uniforms look all futuristic. Injection devices are like on Star Trek, not piercing the skin. The hospital room decor is like in the 2001 movie.
He grabs a passing doctor and asks "So, did they cure my disease?" "No. The year is now 2999." "Huh? Why on earth did you thaw me out?" "Because you're the only COBOL programmer they could find, and Y3K is about to hit."/P
The people that bash Cobol are the ones that never learned how to type. They never learn to appreciate that it's easier to read the code and maintain it. It's just too much work for them to type.
funny all you have to do to know COBOL ia attend a university that cant afford an all PhD computer sci faculty -they call it Computer Information Systems then and guess what they teach COBOL.
Business has responded to the tons of obsolete COBOL code out there, by filling in the gap with zillions of fresh BAs and MBAs implementing corporate policies juggling millions of dollars, in Microsoft Access.
Star Trek transporters are just 3d printers.
So you can shift thru a 10GB of data file and process it out to 15 separate files with help of a few temporay DB2 table for some heavy lifting cross-referencing within 10s on your modern CPU? That was the runtime of my statistics extraction job running in a production environment on a mainframe?
I guess most x86 plattforms whould take longer time to load the data into memory.
ELSE NEXT SENTENCE. ... for all of us that remember punch cards and line printers.
--
Attempting to communicate is the beginning of misunderstanding.