>wrap it up in APIs that you can call as a stored procedure via the database

The previous company I worked for went this route because it creates an easy
way to connect to your RPG program from any language that can all an SQL
stored procedure.  The problem with this approach is all in the change
management. We had an environment with a separate dev machine running change
management software (name purposely left out) that didn't do a good job of
managing the stored procedures (IMO).

A stored procedures definition is stored in system tables, and there are
only one set of them on a machine, which made moving from dev, to test, to
QA, to production problematic because the stored procedure had to be deleted
and recreated each time (you couldn't just move the object). In the end I
believe we ended up writing our own exit point extensions within the change
management software to handle everything.

I think stored procedures are fine for a handful, but when I left it was
reaching levels of 1500+ stored procedures and that was quite the task to
manage.

If you have Java knowledge in your shop I still think a Java front-end
calling RPG business logic as needed creates a easy UI design front. The
only problem with an approach like this is that unless you have a Java
person that can do RPG or vice versa it gets difficult to debug applications
in a timely manner because you have to involve other people as soon as it
leaves your language.

Having your business logic in a separate language than your front end
definitely comes at a cost, but so does putting your business logic in Java
or PHP if that isn't part of your long term goal and it gets dumped after a
few years of use.  This is definitely something to think long and hard about
before introducing a new language/approach into your shop.

Anyways, those are my thoughts on the matter :-)
Aaron Bartell

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Colin Williams
Sent: Monday, February 27, 2006 2:27 AM
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] How are you modernising your as400 applications?

Following from the long discussion re PHP/SQL/App Modernisation,

I would be interested to find out how most of us are going about the Iseries
Application Modernisation process.

I have always been a fan of the route where you keep your existing RPG
business logic, wrap it up in APIs that you can call as a stored procedure
via the database, and create a nice browser from end, using Java or whatever
else you prefer, but also use some direct access from front end to DB via
SQL. That way you dont have to use the big-bang approach, but can modernise
as and when.

Just interested to find out what others have done or prefer, have no
personal axe to grind
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a
message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.


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.