BLOG.NEOMOTUS.COM: Recent Comments

Comment on Get out your crystal balls

2009-08-03T10:10:55Z

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.

Comment on Get out your crystal balls

2009-07-16T07:18:32Z

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.

Comment on Get out your crystal balls

2009-04-16T16:30:27Z

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

http://www.softwaremining.com/blog">http://www.softwaremining.com/blog

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
http://www.softwaremining.com

Comment on Get out your crystal balls

2009-02-21T22:41:25Z

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.

Comment on 2009 modernization market predication from Geoff Baker of Transoft

2009-01-25T13:56:30Z

One capability this prediction seems to ignore is SaaS (and the broader universe of Cloud Computing). Many of the CIOs I talk to are suddenly getting much more serious about these possibilities, some running experiments to learn their viability, and most being delighted in what they are finding. I believe, for some applications, these new approaches will create a potential 'fast path' to renewal.

Comment on Get out your crystal balls

2009-01-23T15:50:59Z

Paul,

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.

Comment on Get out your crystal balls

2009-01-17T19:10:59Z

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.

jdrhodes@adcaustintech.com
http://www.adcaustintech.com

Comment on Get out your crystal balls

2009-01-17T18:07:33Z

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.

Comment on Get out your crystal balls

2009-01-16T23:41:00Z

John,

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.

Paul

Comment on Get out your crystal balls

2009-01-16T22:22:47Z

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.

Predictions:

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
jdrhodes@adcaustintech.com