Re: EGL: Integration or Migration?

On Thu, Jun 5, 2008 at 4:24 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

Personally, I don't feel that anybody will rewrite their order entry
systems in EGL. I've been wrong before, but there's just no way. Same
with an MRP generation. And in fact, that's my measuring stick: if an
EGL-generated MRP program can't do a generation within 100% of the time
of a native RPG solution, then EGL isn't a viable replacement. That's
in fact *exactly* what I told my attendees yesterday at the conference:
EGL is a great integration tool, but it isn't something you would us to
rip and replace existing logic.

Well, there are two reasons that Java hasn't replaced RPG: productivity
and performance. When I talk about productivity, I mean how fast you
can respond to changes in the external business environment, and as a
procedural language RPG has that down all over Java. Now, the fact that
EGL puts a procedural face on Java takes away a lot of that argument.
EGL is the Java that Jon Paris could get his head around. However, that
still leaves performance, and I'll stick with my 100% goal. It's not
that you can't do random access from Java - the Java toolbox supports
this quite nicely - it's just not fast enough.

The fact that EGL generates COBOL might address that issue, but somebody
needs to prove to me that high-end applications can be written that way.

As to the top 10 features, there's little in RPG that makes it more
palatable than EGL except its integration to DB2. The fact that RPG is
so close to the database is what makes it so powerful. Most of the
language constructs, especially things like procedures, are actually
done better in EGL. But when it comes down to just plain blisteringly
fast business logic, I'll still do my work in RPG.

Joe

My definition of migration doesn't include "rip and replace" but
rather a movement toward RBD/EGL as the primary development
environment for new business apps or those apps that require a major
overhaul for other justifiable reasons. I don't see how any non-ISV
business can honestly provide a positive ROI for any "rip and replace"
strategy.

With the ever increasing server performance that is available to even
the smallest of the SMB market, I think the actual elapsed time
differential between 100% and 125% will become a moot point if it
hasn't already. Also, with the repackaging of RBD, the COBOL
generation function is now available to all RBD users so I assume an
SOA architecture could be implemented using COBOL instead of Java. It
would be interesting to see someone on the EGL team implement your
portion of the RSDC scheduling app using the COBOL-Gen functionality.

BJ