Re: How are you modernising your as400 applications? -- WEB400

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

This is the approach we take as well.  Our CM software (name also
purposely withheld) does handle stored procedures.  After much trial
and error, we figured out how to get them promoted from dev to test to
production.  I do wish external stored procedures were objects that
could be SAVRST'ed (and that the command would handle the database
table entries under the covers).

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

Did you have that many web apps, or were you going back and forth from
the web app server to the database?  That's the situation we had
gotten ourselves into (the latter that I described).  Before I knew
any RPG, I had our RPG developers write lots of little utility
programs, and I'd string them together with Net.Data to create
applications.  Net.Data doesn't make you use SQL stored procedures as
long as the RPG program is not on the same system as the webserver, so
we didn't have the stored procedure issue we're now facing since we
started using WAS.

What we have created for ourselves is some lousy performance now that
our site is much more active than when we created it seven years ago. 
But now that I know a little RPG and ILE concepts, we write
subprocedures instead of stand-alone utility programs and string those
together with RPG or CL front-end programs.  Then we make one call
from either WAS or Net.Data to the back end.

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

I think that 5250 and RPG bred a culture of the "do-it-all" programmer
that can do both back-end and UI work.  I've seen beautiful 5250 apps
and ugly ones, but the difference between beauty and ugliness in 5250
is much smaller than in GUI apps (IMHO).  I'm forseeing the day in my
shop when we will have people that specialize in UI and others that
specialize in the back-end.  Even if the back-end guys get into
Java/JSP, they'll still just write a basic interface and the UI
specialists will make it pretty.

But that's easy for my shop, we have 30 or so programmers on staff. 
We can have a couple of UI specialists and feed them enough work to
keep them busy.  It's going to be much tougher on the small shops that
the iSeries is famous for.

Mike E.