RE: Web apps on the AS/400 -- MIDRANGE-L

Joe,

this argument seems familiar.  <bg>  But remember, you're comparing the best
case Java scenario with the worst (or next to worst case ie 1 man shop) RPG
scenario.  

There's nothing wrong with people learning new things, for example, RPGer
learning some HTML.  All they need to do is wrap their data in <td>'s assign
classes for stylesheets and they can be plugged in using SSIs similar to
JSPs.

Brad

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
> Sent: Saturday, March 17, 2001 12:07 AM
> To: MIDRANGE-L@midrange.com
> Subject: 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
> +---
> 
+---
| 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
+---