Re: How are you modernising your as400 applications?

Aaron-

My previous company also used the stored procedure route.  But you said:

> 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).

 I would disagree. There is only one QSYS2/SYSROUTINES table on each
machine, but you could have multiple definitions for each stored proc.
Either with a differenet alias library name or a different parameter
list.   AT my old company, the only time the procedure definition was
updated/created was when we deployed on a new machine, or the
parameters changed.   Moving from dev to QA to prod did not require a
change to the definition. We just moved the object.  If you are
interested in the details, check the article
http://www.ignite400.org/news/news2003031001.htm

Regardless, managing 1500+ procedures sounds cumbersome!

Also no matter what approach is chosen ( stored procs, web services,
PCML) you need to determine a mechanism for the UI to communicate with
the backend.  You could write a generic "request handler" so that for
any new functionality in the UI, you are just creating a new request.
The new request would be sent to the existing request handler, which
would forward the request to the appropriate program/service program
or Java method.

-Sarah


On 2/27/06, albartell <albartell@xxxxxxxxx> wrote:
> >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.
>
> --
> 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.
>
>