Re: CGI vs JSP...

On Mon, 15 May 2006 12:34:23 -0700
 "Dave Odom" <Dave.Odom@xxxxxxxxxxxx> wrote:
> Brad,
> 
> You have just flushed out a key reason why it is a better
> idea, over
> the long haul, to go with JSP and move away from anything
> that ties you
> to RPG, CL, etc; you can't find enough human resources.

I did?  I can find developers.  Some can, some can't.  One
day you hear about folks can't find work, and then you hear
some can't find programmers (that are willing to move I
guess).

> Why?  Because NO
> ONE except the AS/400/i5/whatever its called today, uses
> those very
> legacy and antiquated languages.   The new paradigm is to
> move away from
> those and into more modern and contemporary languages and
> languages for
> which there are lots of resources.  Even IBM will tell
> you so but not in
> these words as they are not politically correct [read
> tell you what you
> want to hear]).  

No one?  99% of my customers come from Java/Websphere
environments.  RPG shops that get talked into it and regret
it.  I'm not going to bite the hand that feeds me (too hard
at least).

IBM will tell you that because they make money with both
hardward AND software for you to move to this "new
paradigm".  

I'm not saying it's the wrong path at all, just not the
right path for everyone.  

I wear the term "legacy" as a badge of honor with RPG.
 When JSPs are legacy (if they ever get there) then we can
talk about that.  

RPG being antiquated is simply an opinion.  

> Also, seriously consider using SQL (perhaps other types
> of) Stored
> Procedures and Triggers and have your Java call the
> stored procedures. 
> Let DB2 do the work for you.  Its generally more
> efficient and effective
> at data access.  DB2 can save you lots of time accessing
> data via SQL
> and not via READs, WRITES, CHAINs, etc.   That's one of
> the benefits of
> have an RDBMS.   

A lot of my eRPG programs I write or help customers with
use SQL for data access.  Once you show em how it works,
they love it.  For everything except those that only
require simply chains/reads/etc.  Or if you talk them into
building nice ILE interfaces to the data.

But for complex/multi-option input, SQL makes complete
sense.  Or files that they seem to like to change a lot.
 :)   As long as they follow the rule of "don't use SELECT
* from..."

Stored procedures can be a double edged sword.  You may
just wake up one day with over 5000 of them.  Sort of like
when everyone started building logical files and soon your
item master had 150 logicals over it.  :)

Brad
www.bvstools.com