Re: EGL FUD

On Dec 16, 2007 7:45 PM, Aaron Bartell <albartell@xxxxxxxxx> wrote:

rpg cannot consume sql procedure result sets.

Is this what you are talking about?
http://www.web400.com/Penton/ex01.rpgle.txt

that is sql cli code. the example is selecting from a table. processing a
result set would be similar, only you would call an sql procedure instead of
running the select statement. Either way, it is a ton of work and RPG does
not provide the necessary features for code encapsulation and reuse to make
sql cli a sensible choice.

in contrast, client side tools like C# and crystal reports make consuming
sql procedure result sets so easy, end users can do it.
http://channel9.msdn.com/Showpost.aspx?postid=365508

Concerning your batch comments, I can see where that example could be
beneficial, but there is a lot more done in batch than data IO and green
bar
report creation (which I agree could probably be better served on a web
page). One that comes to mind is an application I just wrote for a
customer
that is submitted to batch and wakes up every so often to check an IFS
folder for XML files, and then processes them using RPG.

working with IFS stream files is a good example where sql procedures come up
short. But a shop I worked at recently did an effective job of processing
many different FTP feeds using SQL procedures by using CPYFRMIMPF/CPYTOIMPF
and a homegrown FTP command in CL, with the batch CL doing the FTP work,
then callling sql procedures to process the data. I would try to do the
same with feeds that are IFS resident.

on the XML front, we could be hitting the limitation of i5 DB2 which limits
it from processing XML. I dont know much about xml schema, but I think I
understand that other databases are making strides to process XML documents
in SQL as if they are database tables.

The shops in question have made considerable investment in the System

i5.

aka Legacy.

"Legacy" is relative to what can be accomplished to meet a business goal.
I
get the feeling you would call anything to do with RPG "legacy" simply
because RPG is involved.

save the "your this, your that" verbiage for your chats with Mr. EGL. ;) (
just joking ) My recent few years experience is shops use RPG because that
is what their programmers know. A lot ( majority ) of the new apps in the
shops I see are not done in RPG because the RPG programmers dont have the
skill set needed to meet the requirements. ( integrating their data into
excel, using crystal reports, writing simple web apps and serving them over
the enterprise intranet from any windows PC. ( configing IIS is easy ))

an i5 application written in sql procedure language is probably the most

portable code you can write on the i5. If you are uncertain what the next
xx
yrs will bring, you best bet is to write as much of your apps in portable
sql as possible. RPG would be the last language you would want to use.

Vendors should be concerned about platform independence because that is a
sale they may not get if they don't support a particular platform. For
xyz
company to be concerned about platform indenpendance, you can read right
through that and see they aren't so sure about the platform they are
developing on and want to be ready to jump ship if need be. That's
probably
because their history of OSes has been less than satisfactory and they
more
than likely have found it acceptable to jump ship every 10 years. Jumping
ship to a new platform (i.e. new OS, new DB possibly) is one of the most
expensive things a homegrown IT department can do.

another advantage to sql procedures in that the pool of sql procedure
programmers is much larger than that of RPG programmers. An i5 sql
procedure shop will see more quality candidates for their programming
positions than the i5 rpg shop.

-Steve