Re: Dropping the AS/400 as a Web serving platform

< I don't care if storefronts are written in VB (provided that the MS
machine has only token access to my AS/400!).
 That's a big probem for me Joe,you guys dont like giving me any access at
all (hav eto revert to screenscraping or token access with a grudge.:)

< The PCs do all the graphics and the
> static web stuff (thereby offloading the AS/400) and delegate the access
and
> update of persistent information to the AS/400.
>
ADO is perfect for that you can use a disconnected record set-do all the
numbercrunching on the PC an then persist the data back


Professional ASP Data Access isbn-1-861003-92-7 chapter 23 has some
interesting
A/S400 and also DB2 stuff in it.
 cheers Dave






----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Monday, October 01, 2001 5:26 PM
Subject: RE: Dropping the AS/400 as a Web serving platform


> > Our back end will
> > remain AS/400 for some time.  But how long will that be, remains
> > to be seen.
> > When will business decisions based on getting more people to get the job
> > done.  No matter how much business knowledge I have - if there are 5
more
> > programmers for other platforms, other then the one I'm on.  Someone is
> > going to do the math soon.  No matter how much the ROI is on the
AS/400 -
> > people will ignore that when they realize they can get more people
faster
> > and easier then they can find people like myself.  More are being
produced
> > every day from Colleges and universities.
>
> An interesting point, but not without some serious flaws.  The argument
> Andrew makes is that colleges are turning out developers who can use IIS
and
> JSP as opposed to programming on the AS/400.  For what?  Not for
enterprise
> level applications.
>
> Give me a representative 10 AS/400 programmers and 10 college-produced
> IIS/JSP developers, and I'm reasonably certain that there are more members
> in the AS/400 group that understand basic business programming.  In fact,
> given 10 AS/400 programmers and 100 IIS/JSP web application developers,
> there will STILL be more actual business programming knowledge in the
AS/400
> group.
>
> The AS/400 is not home to whiz-bang web applications.  But, in case
anybody
> hasn't noticed, whiz-bang applications aren't actually permeating the
> business marketplace.  Instead, the majority of business web applications
> seem to be storefronts - please correct me if I'm missing something here.
> Frankly, I don't care if storefronts are written in VB (provided that the
MS
> machine has only token access to my AS/400!).  That's because the back end
> still has to be something with reasonable performance and ROI.
>
> The true wave of web-based business applications has yet to even hit us
yet,
> and a large part of that is because the platforms they're built on can't
> handle the scaling.  Some of that is due to the architecture, but those
who
> know my stance on SQL will understand my reasoning there, so I needn't go
> into it.  (But as a side issue, I'm reasonably certain that college
> graduates who have taken the basic SQL courses don't have a clue what a
LEFT
> OUTER JOIN is, nor how to apply it in a business environment, so it's not
> surprising that there are so many SQL performance problems in the
industry.)
> The other part is that somebody who has taken IIS, Java, JSP and SQL in
> college doesn't know the first thing about designing a promotions and
deals
> database.  Or a forecasting module.  Or an MRP generation.  So while you
> might see an amazon.com running on a SQL database (don't quote me, I have
no
> idea what they run), you won't see BPCS written in VB anytime soon.
>
> In fact, you won't see an ERP package - or even a decent module - written
by
> a recent CompSci graduate anytime soon.  How many IIS/JSP developers are
> APICS certified, I wonder?
>
> Which leads to an interesting observation.  Rather than worry about
turning
> the AS/400 into a competitor for IIS, why not concentrate on designing
> systems that take advantage of the undeniable strengths of the AS/400: its
> incredibly fast, robust, highly scalable database, and it's unparalleled
> reliability.  The AS/400 is the best platform for implementing business
> rules ever designed, so why not use that strength, rather than diluting it
> with things it doesn't do quite as well?
>
> Let's start thinking about designing applications where the user interface
> actually isn't tied to the database, where the UI can communicate via a
> fast, flexible interface to the transaction processor.  This way, the user
> can decide to opt for running the UI on their AS/400 (for lower volume
> environments), or put a phalanx of web serving PCs in front of the box,
with
> full failover and load balancing.  The PCs do all the graphics and the
> static web stuff (thereby offloading the AS/400) and delegate the access
and
> update of persistent information to the AS/400.
>
> But this means designing clients and servers - true n-tier solutions.
Even
> though we've been talking about it for decades, the truth is that, with
> SQL-based client applications, we're actually moving away from that
> particular Nirvana.  As more and more business rules find their way into
the
> client, there is less need for a fast server - instead, ALL applications
run
> like crap.  Once you've gotten your user to accept a 2-second wait, you
can
> write as bloated of code as you'd like.
>
> I don't know.  I could be whistling past the graveyard here.  But I still
> think the demise of the AS/400 is overstated and a bit premature.  Until I
> start seeing LotusScript experts who can actually write a shop floor
module,
> I'm going to continue to recommend RPG and the AS/400 for business
> applications.
>
> Joe Pluta
> www.plutabrothers.com
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>