Get out your crystal balls


New Year Predictions

Well the festive season is over, and with many of us making and breaking resolutions for the New Year, I thought I would make January “Modernization Prediction Month” at Neomotus. I have reached out to my friends and colleagues in the modernization and migration world and asked them to let me have their predictions for market trends and modernization strategies for the coming 12 months. If any predictions come in I will post them here.

2009 is code conversion time
To get the ball rolling here is one of my modernization strategy predictions for the next 12 months. I think 2009 is going to be the year that COBOL and RPG application owners get serious about converting their application code base to either Java or C#.

What, this can’t be, Paul Holland telling people to convert COBOL to Java!  Anyone who has worked with me will know that I have spent the last 10 years advocating strongly against such a strategy, but times they are a changing.

For the last couple of years I have been involved with several DEC VMS migration projects. In many cases the applications were written in PASCAL or FORTRAN. Naturally, no one wanted to preserve the PASCAL or FORTRAN source code during the modernization project. In fact the goals were not only to migrate the application functionality, but to convert the code base to a more modern language. No argument from me. The lack of skilled PASCAL and FORTRAN resources meant that the systems were becoming impossible to maintain, the application cost of ownership was increasing as scarce resources became more expensive and difficult to recruit, and the lack of standards compliance and development flexibility became a risk to the business.
I believe that we are now seeing the same factors starting to apply to RPG and COBOL applications.
In my mind there is no doubt that these issues would have even higher profile if the offshore outsourcing industry hadn’t started in the Y2K boom. Indian outsourcing firms built up large numbers of young COBOL and RPG programmers at that time, and it is largely this resource pool that has postponed a more rapid reduction in these legacy programming skills.

I am not saying that the lack of COBOL skills has reached a crisis level, although I certainly do think that there is an accute lack of RPG skills. What I am saying is that CIOs must anticipate that RPG and COBOL programming resources are going to be increasingly difficult to find and good ones are going to be expensive. How long is it going to be before COBOL and RPG have the same issues as PASCAL and FORTRAN? In 2007 Micro Focus, the open systems COBOL giant, did a survey of its customers and found that 75% of CIOs expected to need more COBOL resource over the next 5 years and 73% were already having a hard time finding trained COBOL professionals. As for RPG the availability of skilled resources is even more of an issue and the conversion exodus may have already started. This is even being recognized by IBM with some of its recent announcements.

But conversion doesn’t work

Reading from the old Paul Holland hymn book – "if you try to convert COBOL to Java you get JOBOL". It’s true I have yet to see a COBOL conversion tool that produces object oriented, non-verbose, well structured Java or C# code. However, if you accept the premise that you need to get away from where you are, automated conversion into a code base that can be maintained by Java and C# programmers, even if they complain about its structure, is a far less expensive and less risky route than rewriting. Once you have made the change then you can chip away at structure during the on-going maintenance of the application. However, for automated conversion to be viable it must ensure that the applications functionality is at least preserved and where possible improved.

Furthermore, I think the market is currently getting the conversion tools it deserves. I have no doubt that with more market demand, conversion tool vendors will produce better products. Ceratinly there are more players in the market. Look at the work my good friend Thomas Sykora is doing with his ML-iMPACT RPG conversion product, or Steve Heffner’s XTRAN converter. Veryant have already developed a COBOL to Java converter, they just choose to market it as a COBOL compiler. How long before it's positioned as a viable COBOL conversion solution? Vendors such as Software Mining and Jazillian have been working on converters for years, and TSRI has had a history of successful code convresion projects. Who knows, even Micro Focus might be working on the ultimate COBOL to Java converter. They certainly have all the pieces they the need to produce such a product. After all wouldn’t that be a bit like Exxon working on developing alternative energy sources?


What did you think of this article?

  • No trackbacks exist for this post.

  • 1/14/2009 5:57 AM Frans wrote:
    The factors leading to initiating of code conversion from the "old" structured languages are well described. How to get the best maintainable source-code as a result of such a conversion process needs careful consideration. The "quality" factor of the results and it's maintainability is crucial for the usability of applications for the future.
    Reply to this
  • 1/16/2009 6:22 PM John Rhodes wrote:
    Interesting blog, Paul. I will be happy to add a prediction. Modernization has been a career for me - the first half working on modernization from the mainframe to System 38, AS/400, IBM i, etc., and the last half helping folks move off the IBM i or at least move to more modern technologies like Java. Automated migration has been the holy grail of this whole exercise.


    1. As your blog states, syntax translators and cross compilers are getting better and better. Sykora, PKS, Semantic Designs, and many others are doing some interesting things, and despite the complexity of the problem at some point this nut will be cracked -probably not in 2009 though.

    2. Refactoring tool vendors are also getting better and gaining traction, with tooling like Databorough coming along to the point where it is an economically viable option. This type of option is particularly interesting where the code needs to be maintained and enhanced once migrated, i.e. getting around the "JOBOL" problem you bring up. I predict at some point this type of tool will be quite successful, and will even overtake the syntax translation approach.

    3. As fast as both classes of modernization tooling improve and there is more business generated for folks in the application modernization business, the legacy code base gets larger faster than it is remediated. For example, I know of one bank that is creating close to 5 million lines of hand written, instantly legacy COBOL per year.

    So I predict that there will be more business in 2009 than in 2008, despite the economic conditions. And more in 2010 than in 2009.

    John Rhodes
    Reply to this
    1. 1/16/2009 7:41 PM Paul Holland wrote:

      Thanks for your comments. I agree with each of your points. At the risk of sounding like a broken record I think "The Legacy" issue is the biggest problem facing CIOs today. Even in these tough times I can't imagine any CIO saying to his CEO, "well let's just leave everything the way it is". In fact in the current econmic environment change is being forced on many companies, and CIOs are being asked to do more with less. Combine these factors with the possibility for the rapid ROI many modernization strategies can deliver and it certainly makes sense for CIOs to start to examine the modernization tools and processes available to them.

      Reply to this
  • 1/17/2009 2:07 PM Frans wrote:
    In this context it is worthwhile to look also at IBM's 'new' procedural language EGL. An interesting alternative which is relatively cheap to implement and maintain for existing applications.
    Reply to this
  • 1/17/2009 3:10 PM John Rhodes wrote:
    I completely agree. In fact, I have been looking quite hard at EGL as the result of customer demand, and we have started working with the tool at ADC Austin Tech. PKS and Databorough both have automated migration tooling here for IBM i RPG and COBOL.
    Advantages as I see it:
    • It is procedural, so procedural languages map to it.
    • It is easier for a legacy programmers to learn, yet powerful enough to generate an enterprise RIA application.
    • Lots of legacy hooks, i.e. HATS, etc.
    The only question is will IBM see it through to a larger developer base. They give every indication they will, but there is always reluctance to adopt a new programming language at the enterprise level.
    Reply to this
  • 1/23/2009 11:50 AM Randy Brown wrote:

    Yes, conversion of COBOL to JAVA is a good idea but you can't go from a procedural base language to JAVA. You are right - you get JOBOL which is trash.

    The best method I know of is to mine/harvest the business rules from COBOL applications. You can then re-think and re-architect the applications into a methods/classes structure. This method will save countless dollars/euros in the long run and make the applications run more efficiently and allow them to be actually maintainable.

    Even though this approach is more expensive, it will have a more instant payback to the company. Documentation will be up to date and resources more attainable to support and enhance the applications.

    Just an idea; I could be wrong.
    Reply to this
  • 2/21/2009 6:41 PM Randy Brown wrote:
    Paul, while I agree that COBOL will have to be fazed out, I don't think it will happen in my lifetime. The main problem with COBOL is the Monolithic sized programs that I and many other wrote back in the 1980's before structured programming took hold. Many more programs grew in length due to enhancements made to them.

    The short term (5 - 10 year) solution would be to componentize these large, unmaintable programs into smaller function based programs. This in turn will allow easier business rule harvesting and migration to more modern programming languages.

    Just my opinion; I could be wrong.
    Reply to this
  • 4/16/2009 12:30 PM Cyrus Montakab wrote:
    In the Java or JABOL issue, surely it depends on the "intelligence" of translator?

    I mean, Can a good developer who knows COBOL and Java, rewrite a COBOL program properly - without involving a Business-Analyst to extract rules first? IMHO the answer is yes. Can he produce a fairly good quality code? I think so, but it depends on how long would you give him (e.g. to unwind all those GOTO statements).

    Lets get more technical: What actual characteristics, qualities, standards, should the translation posses in order to be a "good" translation?

    I don't want to go into too much technical detail here, but I have started listing such characteristics on">

    Over the next few weeks - I am planning to regularily add to the items in my blogs. I look forward to your feedback and contribution

    Finally, Can we get a "translator" to produce code with same type of qualities? I think we can, but it is not going to be a simple parser/generator type approach. You need to get the system to understand coding patterns: COBOL and Java.

    It has taken a lot of hard work for us to generate good quality "maintainable" code. Lets have a better definition what is/is not Jabol !!

    Cyrus Montakab
    Reply to this
  • 7/16/2009 3:18 AM roulette winning wrote:
    Even in these tough times I can't imagine any CIO saying to his CEO, "well let's just leave everything the way it is". In fact in the current economic environment change is being forced on many companies, and CIOs are being asked to do more with less.
    Reply to this
  • 8/3/2009 6:10 AM juegos de casino en linea wrote:
    In many cases the applications were written in PASCAL or FORTRAN. Naturally, no one wanted to preserve the PASCAL or FORTRAN source code during the modernization project. In fact the goals were not only to migrate the application functionality, but to convert the code base to a more modern language.
    Reply to this
Leave a comment

Submitted comments are subject to moderation before being displayed.


 Email (will not be published)


Your comment is 0 characters limited to 3000 characters.