× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 3/11/2012 11:07 PM, Steven Spencer wrote:
Hi,

Yes, I agree that two languages can work together almost as one. OCL
and CL acted as the bridge between the OS and the high-level
RPG. EGL with Web-sphere, I gather, conceptually wants to be the
bridge to modern output.

Actually, I think bridge may not be the best term. EGL is designed from the ground up to have two primary facets: data orientation and visual presentation awareness. EGL's data orientation is predicated on its Record syntax; data is stored in records and records can represent either pure data storage or can have additional annotations regarding their use (such as SQL or MQ, for example). Visual presentation awareness is the idea of creating a GUI page with a WYSIWYG designer that has awareness of the underlying data in the application, a la Microsoft designers. Dropping data on the screen creates data-aware widgets with automatic bi-directional connectivity to the application program, much like a display file.

So what do you get? An environment where you group your data in records (not objects) and you design your UI and bind it directly to your data, eliminating the plumbing.


However, they were designed independently (thus EGL can put out Cobol
code, but not RPG) and I gather EGL will even compete with RPG for
full functionality, as in the RPG to EGL conversion concepts. In that
sense, EGL is claiming to be a lot like Lamsa, Magic and WinDev, a
4GL implementation that is happy to work with the iSeries (QS36F as
well, if you create a data dictionary ?) and will be friendly to your
existing data and apps.

I don't think there will ever be an RPG to EGL conversion that will perform well, any more than there will be a good RPG to Java conversion. The fact that the native I/O of both EGL and Java is SQL makes that unlikely. Instead, EGL is designed to provide fast, integrated development of SQL-based applications with the ability to invoke native RPG business logic (or indeed any ILE or OPM code) very naturally. That's above and beyond what even Java provides.


I included EGL in the jambalaya partly because there is a type of
skepticism, with the Visual-RPG experience of IBM and the continual
rebranding of Websphere and Eclipse products. Now EGL is the way to
go, but I am not sure that everyone sees its long-term future as
bright. These other tools have a 10-20 year lineage of actively
working on iSeries. If we knew that EGL would be actively supported
in 10 years, that might be a help.

Then it should make you more comfortable to know that EGL is over 30 years old. It started life as Cross System Product for mainframe development back in 1981 and has evolved continuously over the years through two new product families (first VAGen and now EGL).

However, technically EGL might fit more in with the new generation of
4GLs that basically bypass RPG, the point of my earlier post. It is
not really trying to enhance RPG, but to supply an alternative
full-platform that will coexist with your RPG.

Not sure what you mean by "enhance RPG". EGL enhances RPG by freeing it from the mundane details of HTML formatting and XML/JSON messaging much the same way that display files hide the complexities of 5250 data streams. It allows RPG programmers to focus on writing sophisticated business logic. And for that, RPG needs no external enhancements; the RPG compiler team is doing quite well with that.


Feel free to correct any misunderstandings on my end.

I hope I've enlightened you. :)



Steven Spencer
Queens, NY

On 3/10/2012 5:12 PM, Steven Spencer wrote:
Personally, starting fresh, I see no purpose in working with RPG and
the jambalaya of EGL, or CGI and PHP, or Java and this and that. Or
Open Access and the three vendors.
Not sure what you mean by "jambalaya" when you refer to EGL. It's a
pretty straightforward open source 4GL with a variety of target
platforms, including Java, COBOL and JavaScript. It's got integrated
support for SQL that's a lot better than any other language I've seen.

And while it doesn't target only the i, it works best with the i,
because it can access the database either through SQL or through direct
calls to ILE programs, including RPG. Why is that important? For the
same reason it's always been important to call native applications:
performance! EGL provides effortless SQL access but when you really
need performance you can always call good old RPG.

And that's just the business logic side! Unlike most languages, EGL
provides a single syntax that works on the server and also works on the
client, and tops it off with a powerful WYSIWYG editor that allows you
to bind controls in your browser directly to functions in your client
which in turn can invoke services on the host. And you can debug it all
the way through using a single workspace!

So, yes, if I had the choice I'd build any application from the ground
up using EGL and RPG. The only change is when I need a fat client on a
handheld device, at which point I'd turn to Android and Java.

Joe
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.