Re: Thinking out loud about a new RPG web framework

Aaron wrote:

Again, let's use the strengths of the iSeries.

Agreed. A unix/wintel box can't handle thousand jobs to support thousand users, where most of the time these jobs are waiting for I/O. The "i" (i.e. S/38 .. AS/400, etc) is designed for this. To be used in a business environment where we have lots of I/O and data being manipulated and pumped around and relatively few processing (calculations). As opposed to the more scientific/engineering environment where there is much more processing and a lot less I/O and data pumping. In these environments the client/server approach works best, and can be easily supported by unix/wintel boxes who have maybe 10-20 processes running which serve the 1000 users. The "i" is designed so that the application for each user runs centrally on the server (host), in it's own job, and where all the data resides.

Date: Mon, 9 Jun 2008 06:39:37 -0500
From: aaronbartell@xxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Thinking out loud about a new RPG web framework

3. In a robust environment where we're talking about of 10,000 or more

logged in users of a business system, e-commerce, and the like, you start
getting into a server farm of iseries.

Maybe my customers are different, or I haven't asked them *exactly* what
they user their different boxes for, but I just don't think an iSeries
server farm would be necessary. This is yet another advantage of an iSeries
in that you can expand your hardware by either adding RAM/DASD to an
existing machine or just upgrade machines - no need for a server farm to
facilitate thousands of users. I would even go as far to say (and sys
admins correct me if I am wrong), but we have "virtualized" server farms
*inside a single iSeries by nature of the way the OS was written. I can
split up hardware to be allocated to specific duties and give priorities of
execution to different jobs all the way down to how big of a timeslice a job
should get once it's turn comes in the round-robin processing execution
scenario.

A database server has to have the state stored in it, and you have to get

to the right database server, unless you can keep multiple database servers
synched in real time. Which we need to do anyway for high availability, but
there's a differnce between high availability synching for failover and
keeping multiple production systems in synch, such as two or n way synching
between the databases to start with instead of one way to the high
availability backup server.

I still get the feeling this approach is designing a system based on how a
Windows sys admin would approach the situation. Many iSeries shops take the
two machine approach - one for the actively running jobs and one for
hot-swap-failover in case the main one goes down. Eliminates a bunch of
complexity because then you don't need to be concerned about the things you
brought up. Again, let's use the strengths of the iSeries.

Aaron Bartell
http://mowyourlawn.com
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

_________________________________________________________________
Jouw nieuws en entertainment, vind je op MSN.nl!
http://nl.msn.com/