Using AS/400 as a server platform
Let's examine the same environment implemented using the AS/400 as a server platform.

We've described how we can partition Domino servers on the AS/400, and limit their resources based upon need. Before we discuss the individual Domino servers, let's discuss the need for clustering on the AS/400 versus clustering in the NT environment. In the NT environment, it is typical that if the Domino server crashes, NT crashes as well, or at the very least, that the NT server must be restarted when we restart Domino.

In the AS/400 environment, let's assume that the Domino server crashes (even though Domino server crashes on the AS/400 are much less likely). The Domino server crash does not affect the AS/400, since the crashed Domino server is running within it's own environment -- in AS/400 terms, in it's own subsystem. We are not required to restart the AS/400, but must only restart the subsystem in which the Domino server was running. It should also be noted that Domino for AS/400 has auto-recovery capabilities that will restart a Domino server if it crashes, and has conditions that can be dictated for that restart.

Now, back to our Domino implementation on the AS/400. We do not require that Domino servers on the AS/400 be clustered (although we can do this) for a number of the previously mentioned reasons. We start by configuring a single Domino server providing email and calendaring/scheduling services. For the faint of heart, we can have that also be the backup server and set failover and load balancing. We then add a separate Domino application server by adding a partitioned server to the AS/400.

Increasing the complexity of the Domino environment as we did above, we decide to add virus scanning to SMTP. Again, add another partitioned server on the AS/400 to run SMTP, and install the virus scanner to run on that partitioned server.

We need an application development server so we add yet another partitioned server (we have apparently coined a new acronym, YAPS syndrome!). But again, remember this is a partition on one physical box, not a completely separate device. We configure these Domino servers so that they run in a separate memory pool where we can limit the maximum amount of memory that the server can consume, thus limiting its resources (although making sure it has enough to perform its required tasks). We want to be absolutely sure that our developers can't impact end user performance by taking away processing from our production servers, so we decrease the priority of their server as well. This not only limits processing, but assures that errant code will not attempt to "run away" with the AS/400's CPU.

We can add a QuickPlace server to the AS/400, since QuickPlace is available on the AS/400. Lotus Fax for Domino for the AS/400 will be available very soon (possibly by the time this article is published), so we can add that to the AS/400 as well.

Other than accounting for the total amount of network bandwidth required to access the AS/400, we have not increased our need for server-to-server bandwidth, since communication between the servers takes place internally on the AS/400. The enterprise-wide bandwidth is not consumed by the server replication processes because the replication takes place within the server environment via the internal bus channels. These channels are more robust -- they are based on a 64-bit architecture, not the Wintel-based 32-bit architecture -- and therefore move information at optimal rates (enhanced performance). Enterprise backup can be handled internally in the AS/400, and as of Domino for AS/400 version 5.02a, we can use IBM's BRMS product to backup Domino while the Domino servers are active and the Notes databases are open.