RE: Web apps on the AS/400

I'm sorry about my outburst, Jim.  I know of course that there places where
it will be difficult for WebSphere and Java to make an inroad.  But let me
explain why I am so passionate about this.

First, EVERYONE can learn Java.  It's really not that difficult a language.
The syntax is comparable to C, and if you've started dabbling in RPG IV,
then you know the concepts required to use Java.  There are two types of
Java programmers: class creators and class consumers.  Class creators are
the wild-eyed scary people like me who learn all the intricacies of OO
technology and learn how to make classes that other people use.  Class
creators are roughly akin to people who write compilers.  Class consumers,
on the other hand, are application programmers.  They use the classes
written by class creators, just like they would use a new BIF in RPG IV.
There's really no difference.  So, given a set of classes written by a good
class creator, application programmers should be able to write code in Java
just as easily as they do in any other language.  Let me give you an example
of code written using some classes I've written:

-------
Jdb400KeyedFile orderHeaderFile = new Jdb400KeyedFile("MYLIB/ORDHDRL1");
Jdb400KeyedFile orderDetailFile = new Jdb400KeyedFile("MYLIB/ORDDTLL1");

orderTotal = new BigDecimal(0.00);
orderDetailFile.SETLL(orderNumber)
while (orderDetailFile.READE(orderNumber))
{
    orderTotal = orderTotal.add(orderDetailFile.getNumeric("ODXAMT");
}

orderHeaderFile.CHAIN(orderNumber);
orderHeaderFile.setField("OHTOT", orderTotal);
orderHeaderFile.UPDAT();

orderHeaderFile.CLOSE();
orderDetailFile.CLOSE();
-------

I'm pretty sure you can figure out what this is doing.  Why?  Because I
wrote classes that are meaningful for our business use.  You may say to
yourself, though, "Who is going to write these classes?"  That's a good
question.  The truth is that for any one shop, you'll need one or two class
creators who can write these types of classes, or else you'll need to
contract out for them.  But once they're written, they can be used over and
over, and extended as you need.

Even more important, though, is the fact that by using JSP, servlets and a
good message-based client/server architecture, you don't even need to do
this much.  Instead, you need some classes to generate HTML widgets and some
classes that communicate with a server.  Now, all your business logic is
written in RPG as server programs, and you call those server programs
whenever you need data.  Your servlet simply calls a server, builds a
widget, and passes the widget to a JSP.  And that's the extent of
programming in Java you need.

With CGI, you need programmers who understand both RPG and HTML, and they
have to understand how to merge data with HTML tags to create meaningful
screens.  With the servlet/JSP approach, a UI designer creates the JSPs,
knowing he is going to have some widgets to place on the screen.  The
servlet program simply moves the data back and forth between the widgets and
the server.  And the server programmer does the bulk of the work in RPG,
just like it's always been done.

New skills?  Yeah, a UI designer is needed.  But you need one of those
anyway, and you can get a decent UI design pretty cheap these days.  I know
people who design entire websites for a few thousand dollars; you can easily
get them to leave gaps in the website where your application widgets are
going to go.  The servlet programming you'll need to do inhouse, most
likely, but these days I don't usually write a servlet much over 50 lines of
code.  The bulk of the code is in the RPG server program.

But instead of promoting this most simple and elegant of solutions, people -
people who should know better - insist on telling you to make do with
band-aids and half solutions which will be all but useless inside of six
months when you want to make substantial changes to your website.  These are
the same folks who told you to subtract 28 from your year in order to make
your Y2K problems go away.  And even that had a better rationale, since the
problem really would go away with time.  Instead, your problem will grow
with every change you need to make.  And don't think that won't happen:
nearly every website out there has had some pretty substantial changes over
the last year.  And the companies with those websites usually have a pretty
sizable number of CGI programmers working on the sites.

So, what will it take to make you try JSP and servlets?  A how-to on
WebSphere?  A detailed guide for developing a web application?  Or how about
a step-by-step primer on putting a green screen application on the web?  If
the last one will do it for you, just pick up a copy of my book.

I guess I'm just tired of people defending crappy ideas and bad
architectures.  I was the Manager of Architecture at System Software
Associates when executive management made the decision to go to Unix.  I
railed at the idea, explaining that they were on architecturally shaky
ground rewriting a major ERP application to use embedded SQL just for the
sake of "platform independence".  They refused to listen to me, and if you
know anything about BPCS, you know the results.  I've seen other, similar
occurences in my career, and I hate to see the same thing happen here.

We're at a crossroads, a turning point, and what could be the beginning of a
fantastically fun and exciting new chapter of the AS/400's existence.  The
combination of tools available has brought us an environment where the
AS/400 can truly shine as an application server, while at the same time
allowing us to build wonderful, sophisticated graphical applications.  But
if we stumble now down some architectural dead ends, wasting this golden
opportunity, then by the time we realize our mistake, we may have found
ourselves working on a platform that time has passed by.

Screen scrapers, SQL and CGI-RPG are solutions that don't address the
fundamental business issues; they solve the immediate symptoms without
curing the disease.  And that disease - the scepter of massive, rigid,
bugridden, unmaintainable systems - threatens the very life and livelihood
of the AS/400 itself and those of us who program on it.  Everything we do
that delays the cure of the disease compounds that threat.

Joe


> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of Jim Franz
> Sent: Friday, March 16, 2001 7:14 PM
> To: MIDRANGE-L@midrange.com
> Subject: Re: Web apps on the AS/400
>
>
> Joe - from your quick bio, your obviously way ahead of many of us, and
> have had the opportunity to be on the cutting edge. Java has also
> obviously
> matured. It's good that we have someone like you to lead the charge.
> However, many shops, restricted by management, budgets, other projects,
> etc will, through no fault of their own, take a while getting there.
> I think the qty of S36 & RPGIV questions on this list should give you a
> clue.
> The one exception I will make to your previous statement, is that CGI is
> not an architecturally sound approach.CGI has been THE standard
> for dynamic
> web serving for many years. It is still the standard for much of the web.
> It is the old, tried & true, sound method. It is not an RPG invention, or
> even an IBM invention. It's been on the 400 for years. Java will
> overtake CGI some day. When ILE came along, many saw the clear
> advantages, but it didn't render RPGIII as unfit for use.
> Keep leading the charge, and build us some tools that make it easier to
> learn.
> jim
>
> ----- Original Message -----
> From: "Joe Pluta" <joepluta@PlutaBrothers.com>
> To: <MIDRANGE-L@midrange.com>
> Sent: Friday, March 16, 2001 10:05 PM
> Subject: RE: Web apps on the AS/400
>
>
> > John, I've spent a lot of time on this particular question.  In
> general, I
> > try to be fair and tell people that certain solutions are better for
> certain
> > situations, and each one has its own place.  For example, when I give my
> > presentations at COMMON, I stress the fact that there are
> occasions where
> > screen scrapers are the right solution.
> >
> > But I'll be honest here.  I'm tired of being PC (Programmatically
> Correct).
> > I haven't spent nearly 25 years developing code to sit back now and
> waffle,
> > especially when the answers are clear cut.  So here it is:
> >
> > 1. The AS/400 is the best midrange machine on the planet.  Period.
> > 2. RPG and DB2/400 beat any other combination for business rules
> > development.
> > 3. OO is the best technology to develop tag-based UI.
> > 4. Java is the best commercially available OO language.
> > 5. JavaServer Pages are the best browser-based development solution.
> >
> > These are my opinions, certainly, but I have coded millions of lines of
> code
> > over the years.  I have written operating systems, development tools,
> > shrinkwrapped packages and custom applications.  I've used ten different
> > hardware platforms, eight different operating systems (that's
> NOT counting
> > variants) and over a dozen languages, three of which I wrote myself.
> >
> > Tell me how procedural code is better than OO for designing
> widgets.  And
> > then have the code to back it up.  Show me another commercially
> viable OO
> > language that runs on as many platforms as Java.  Explain to me
> how CGI is
> a
> > better UI model than JSP.  It can't be done.  My list, while
> surely based
> on
> > opinion, is awfully hard to contest in fact.
> >
> > Now, I don't dispute the fact that there are times when the best is the
> > enemy of the good.  Like I said, screen scrapers have their
> place: namely,
> > when you've lost the source to an application but need to get it on the
> web.
> > Similarly, CGI-RPG has a place: in shops that refuse to learn
> Java, or are
> > running their machine at 99+% CPU already.  But like screen scraping,
> > CGI-RPG is a dead-end technique that adds nothing to your technological
> > toolbox - as they used to say at Digital, it's "a bag on the side of the
> > box".  And I'm tired of seeing it promoted as anything but a
> bandaid and a
> > shortcut.
> >
> > Sure, use CGI-RPG to learn the browser.  Use screen scrapers
> for tactical
> > solutions.  Heck, get FrontPage and put up a website.  It doesn't hurt.
> But
> > don't expect me to sit here and say with a straight face that CGI-RPG or
> > screen scrapers are an architecturally sound approach for any sort of
> > strategic development.  In my oh so obviously not very darned humble
> > opinion, they simply aren't.
> >
> > <grumble>
> >
> > And ONE of these days I'll stop beating around the bush and say what I
> > mean... <grin>
> >
> >
> > > -----Original Message-----
> > > From: owner-midrange-l@midrange.com
> > > [mailto:owner-midrange-l@midrange.com]On Behalf Of jpcarr@TREDEGAR.COM
> > > Sent: Friday, March 16, 2001 8:04 PM
> > > To: MIDRANGE-L@midrange.com
> > > Subject: RE: Web apps on the AS/400
> > >
> > >
> > >
> > > Joe Pluta said
> > > >I won't write CGI-RPG, Brad.  It's a strategically unsound
> architecture,
> > > in my opinion, and I choose not to pursue >it.  There's nothing
> > > CGI-RPG can
> > > provide that I can't get through servlets or JavaServer Pages.
> > > >My opinion stands.
> > >
> > >
> > >
> > > Joe
> > >
> > > Net.Data,   RPG-CGI,   Java   each have their strengths and weaknesses
> > > depending on the Application needed,  The shop it will run
> in,  and the
> > > current skill set of the staff that will develop and maintain
> the code.
> > >
> > > No right answer,  No one solution that fits all.
> > >
> > > Servlets, and JSP's  in a shop that has pressing deadlines
> and let's say
> > > "not state of the art" skill sets  may not be a good  "Tactical"
> solution
> > > if all they want is some existing reports etc in the browser.
> > >
> > > Stategically ?  Net.Data and CGI is not the end all and be all.
> however
> > > for a shop that just within the last 6months learned RPGIV
> and can read
> a
> > > data base file and format the output like is shown on
> Easy400.com or in
> > > Brad's eRPG book,  CGI may  be a good way to get ... lets say
> > > "Comfortable"
> > > with the Browser,  HTTP server,  etc.
> > >
> > > Set and Setting(which shop, which skillset, which budget, what
> trainging,
> > > etc)  have a big effect when considering a "Tactical" solution to help
> you
> > > on your way to learn new stuff.
> > >
> > > End-all-be-all ?   Java seems this season's pick for that.   ( there
> have
> > > been many seasons though).
> > > Should people learn it?  You Bet !   Can they be putting up
> some simple
> > > stuff in the mean time  with Net.data or RPG-CGI and get a level
> > > of comfort
> > > with the browser interface ?   You Bet !
> > >
> > > Just my opinion
> > >
> > > John Carr
> > >
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---