From: Jon Paris
"In my opinion, there is still an opportunity for an enterprising software
company to make money from creating a tool that offers reverse engineering
to a graphical representation of legacy RPG systems and then onwards to
forward engineering to Java without locking the developer into any kind of
proprietary technology either at run-time or design-time, and I have
thought
about taking the plunge in this direction on many occasions...."
DataBorough have been doing this for some time with their X-Analysis and
related tools. There are other tools out there but theirs is probably the
most advanced and with the longest track record.
Funny you should mention X-Analysis, Jon! I just wrote an article that
talked about this:
http://www.mcpressonline.com/mc?.6b507acf
While X-Analysis is a pretty cool tool, it really isn't much more than a
Probe/Abstract or Hawkeye (albeit it with some cool features). Where-used
is a way different animal than logic analysis.
I know the difference, because my Focus/2000 product was perhaps the most
successful Y2K enabling tool in the industry, and it performed complete
automatic re-engineering of programs for Y2K based on exhaustive field
analysis (for example, identifying year fields based no their relationship
to date fields).
The extraction part -- just finding where dates were used in such a way as
to require modification -- was a huge effort. Trying to further extend that
to generalized logic diagramming is an order of magnitude harder, and using
that information to migrate to another language is nearly impossible.
They break out the data flow and business rules and provide a pseudo code
description of what is going on.
This is the X-Extract product. As far as I can tell, the product works well
enough if your code is already "process normalized" -- that is, the business
rules are nicely encapsulated inside "if/endif" clauses. I would bet
anything that it works reasonably well for standardized code and gets quite
cranky with spaghetti code.
That's why in my article I pointed out that documenting your programs
properly is the first step; this can help you separate your actual business
rules logic from other code, making life easier for analysis tools.
They are offering re-engineering services
to Java based on the tool and appear to have just started offering a DIY
option. This part of the tool set is known as X-Migrate.
Yeah, but the majority of this portion is little different than any other
migration project: give us some code and well do a proof of concept. If you
like it, we'll show you how we did it and then we can contract to do more,
or you can buy our tool and do it yourself.
This is actually exactly the same way I do my PSC/400 conversion proof of
concept. Because even though PSC/400 is a completely automated tool, every
single application has rules and programming techniques that are different,
and there's an initial learning curve for each system. And while PSC/400
only has to automate the UI process, X-Migrate has to somehow automatically
break out every business rule from every possible permutation of RPG
opcodes. As procedures and BIFs and data structures and pointers become
more complex, I can't even begin to imagine how they do it.
Joe
midrange.com
