When I get asked this, my first impression is that the person asking feels all alone in their use of the language, almost ashamed, believe it or not.
The media, tool /software vendors, consultants, and even college professors have made the statements telling us all how COBOL is the "old" and we should be doing the "new". They've done a good job promoting the fact that if you are using the new gadget then you must be missing out.
My answer to them is always the same. COBOL is an ever advancing language and is as current and modern as anything else out in the market. COBOL is in use every day in literally thousands of companies.
But the number is shrinking.
And I believe it is because of this perception that "we must be all alone".
Well, I've got news for everyone... COBOL is still alive and kicking.
The problem is that no one is waving a flag saying "We use COBOL".
Yes, usage is down. The numbers will continue to shrink until reaching an equilibrium or point of balance.
Here's why - Back when COBOL took the stage, there were only so many options available to a company. Nowadays, there are literally hundreds if not thousands of ways to create and deploy a business application.
How many companies will be using COBOL in 5 or 10 years? Idunno.
I think a very scientific number will be "a bunch of them". Not as many as there were, but enough to be significant.
Today thousands of software companies, banks, insurance companies, manufacturers, and credit card processing companies are spending millions of dollars on their COBOL applications. And they will continue to do so.
As for those of us who write COBOL applications and are trying to figure out what they should focus on for the future, my advice is simple:
Learn a framework like .NET and become somewhat language independent. Learn as much as you can about how to leverage things like .NET and other technologies that are used within your shop. And use your expertise with COBOL to become the expert at briding that gap.
 |
| My buddy Doby! |
Posts
I was listening to a podcast on software engineering radio today. It was talking about AS400 (OK - so IBM re-branded it to iOS - but know one took any notice). Anyhow, AS400 is still being used in hundreds of thousands of places around the world. It might not be anything like as big as Linux in usage, but it is still have huge market.
ReplyDeleteThere are many not-so-well known about technologies out there. Just because they are not on the evening news does not mean they do not exist. COBOL is definitely like that.
Most of my customers use computing for production with as little development as possible. Production makes money, development costs them money. COBOL just keeps chugging. They will move it off a platform when a vendor gets greedy or stupid, but the apps and data are assets, just the way they are.
ReplyDeleteThe problem I have with trying to call COBOL a "modern language" is that it lacks many of the basic features that other modern languages enjoy, namely cross-platform support. (Not to mention homogeneity, local variables, etc.)
ReplyDeleteTo my understanding, "modern" COBOL is, basically, COBOL .Net. Well, .Net is a Microsoft construct, relegated to Windows machines. How does that help me, a mainframe COBOL programmer, move to a "modern" version of COBOL? Answer: it doesn't. I'm stuck, unless and until my employer decides to move all of its eggs to a Windows basket.
But how likely is that? I mean, there are no other options, are there? It's Windows or nothing... or else keep the old-style limited COBOL (no local variables, etc.) running on the same old platform.
And then if my employer DID decide to move to a Windows platform, would they keep the old COBOL programmers? Only as long as the legacy mainframe system is around, I can tell you. Because it would be far cheaper to get a handful of Java devs than to retrain the COBOL fogies how to program in a Windows environment. And guess what? I have met VERY few COBOL programmers who could cognitively even deal with .Net or Windows (heck, FTP befuddles them). One pretty dang good COBOL jockey I have working for me said that he couldn't finish his Java course because it just blew his mind; he couldn't grok the concepts. Well, if Java baffles you, how are you going to take to .Net, Windows APIs, DLLs, OLE, OOP, etc.?
No, in the end, the shorter path is to get a "Windows" programmer and then just get them to program in the language you prefer... be it Java, C, Perl, whatever.
In the end, COBOL will be around for a long time to come. The IBM Big Iron still runs just fine and there are still plenty of people who understand its architecture. Most companies would be loathe to rewrite the system in a new language ($$$), much less move to new hardware ($$$$$). So until forced to move, they're likely to stay right where they are.
Oh, and what happens when the current crop of COBOL jockeys retires or dies off? Same thing as Y2K. The demand will grow, pushing up salary offers, causing more people to learn COBOL to make good money. Heck, if it weren't for Y2K, I probably wouldn't be a COBOL programmer anymore.
In the end, I think the thing that companies need to recognize is that so much more can be done so much better and for so much less (time, money, support) if a more-modern language could be used. And also, if a language that isn't splintered between hardware platforms weren't used.
Just my $0.02. Discuss...
Funny that you would mention COBOL's lack of local variables as a "missing" feature. It is actually THE feature of COBOL which makes it so productive. COBOL programmers are not constrained by the straightjacket of strongly typed languages and do not spend their time arguing with the compiler... Instead they solve the programming problem on hand.
DeleteIf you really want local variables just write callable COBOL subprograms and use the CALL statement to get separately compiled subprograms with their own local workspace.
Again, COBOL's lack of procedure calls with parameter passing and own workspace is in fact a virtue, not a deficiency. That is why COBOL is so productive and less error prone. And when an error is made - it is easier to find and correct. But of course if you wish to insist on putting your head in a sick bed you can always go for Object Oriented COBOL, or some other fancy schmancy modern language.
Mike, its all in how you code it, whether it is portable or not. Micro Focus Visual COBOL runs on Windows, UNIX and Linux platforms, as well as within Azure. While it doesn't run "everywhere", it hits the major platforms... If you take advantage of the .Net framework in your COBOL code, you are correct in that it won't work on any other platform. And same thing if you code it to take advantage of the JVM, it won't work for a .Net deployment.
ReplyDeleteTake a look at these examples:
Non-portable examples
.NET
01 s1 type System.String value “Hello world”.
display s1::Substring(4) *> .NET System.String methods
display s1::Substring(6, 5)
display string::Concat (s1, “ and goodbye”)
JVM
01 s1 type java.lang.String value “Hello world”.
display s1::substring(4) *> Java java.lang.String methods
display s1::substring(6, 11)
display s1::concat (“ and goodbye”)
But you could also code it to be platform independent by doing it this way:
01 s1 string value “Hello world”.
display s1(5:) *> using reference modification
display s1(7:5)
display s1 & “ and goodbye” *> using concatenation
Notice that even with the portable version you can take advantage of the new data types while coding statements that are probably very familiar to the traditional COBOL developer.
I worked with a company not too long ago that took a handful of C# and COBOL developers and combined the two into a very effective team. They were able to slightly modify an existing COBOL-based application and bring it forward with a very slick new interface and plugged it directly into their existing .Net infrastructure. Training was roughly 3 days to get the team started.
As to your argument about using a more modern language, you won't find one. the COBOL language is as modern as anything out there.
Thoughts?
You mentioned local variables as one of the limitations of COBOL... This syntax is now supported within Visual COBOL:
ReplyDeletedeclare i1 as binary-long = 3
display i1
perform varying i2 as binary-long from 1 by 1 until i2 = 8
display i2
end-perform
perform varying s as string through string-collection
display s
end-perform
Funny... I thought I mentioned MAINFRAME COBOL. You know... where COBOL started?
ReplyDeleteI tried your cross-platform code from above... 5 errors, 3 of them severe:
14 IGYDS1089-S "STRING" was invalid. Scanning was resumed at the next area "A" item, level-number, or the start of the next
clause.
14 IGYDS1159-E A "PICTURE" clause was not found for elementary item "S1". "PICTURE X(1)" was assumed.
23 IGYPS0001-W A blank was missing before character ">" in column 28. A blank was assumed.
23 IGYPS2072-S "*" was invalid. Skipped to the next verb, period or procedure-name definition.
Same message on line: 26
26 IGYPS0027-S Non-COBOL character(s) were found starting with "&" in column 23. The characters were discarded.
26 IGYPS0001-W A blank was missing before character ">" in column 41. A blank was assumed.
And the "local variables" code... again... MAINFRAME. There is no "Visual" anything on the mainframe. "Visual" stuff is a Microsoft construct, not IBM (or CA). In the end, there needs to be sub categories of COBOL... Mainframe COBOL, COBOL .Net, COBOL for JVM, etc. But this makes COBOL cease to be A language and makes it MANY languages.
And, this is my point. The "modernization" leaves its roots behind, as though it's the ugly deformed stepchild that's kept in the basement. But there is so much legacy COBOL out there that it needs to be addressed and allowed to still exist.
If there's going to be any traction for COBOL in the non-mainframe world, COBOL has to not ignore its roots nor deny its heritage. Most COBOL programmers came to be so on the mainframe. If I told my coworkers they could write COBOL on the PC, some of them might be interested. But once I tell them, "but there are no viable free compilers (that I've found) and you need to get into .Net or JVM to really get anything done," they would all just say, "oh, well, I don't have time to get into anything new."
So, if 20-year-tenured COBOL programmers can't pick it up, how cross-platform is it really? And how much can you really call it COBOL?
And if JVM or .Net is necessary to be a modern COBOL programmer, why wouldn't such a person just learn C# or Java? It's far more viable and pervasive than COBOL.
Again, just my $0.02.
I apologize that I missed your qualification of "mainframe" COBOL. IBM is a bit behind what the COBOL standards group has been putting forward these past few years and what Micro Focus has provided. I'm not aware of any open version of COBOL being involved with the standards committee either though.
ReplyDeleteYou may be overlooking that the various versions of COBOL from the past are all still supported within Visual COBOL (more old versions than even IBM supports).
So, the 20-year-tenured developers have the option of doing things the way they have been doing things for years, or they can add in some of the new features of the language.
The nice thing is that the new features can be adopted gradually if so desired. This approach allows those same folks to move to things like C# and Java at their pace instead of being forced to wholesale jump into the deep end.
My $0.02 is that COBOL is more than viable.
greet blog.but can anyone give me the answer in my webpage which is asked by shovon and the question is
ReplyDeleteis COBOL dead, do companies still use it?