The AS/400 has become a popular platform for Lotus Domino implementations, second only to Microsoft Windows NT-based Domino servers. NT skeptics might say this is because it takes about 10 NT servers to match the capabilities of one AS/400. Some optimists like myself consider five NT servers equal to an AS/400. Regardless of who’s doing the estimating, Domino on the AS/400 is not much different than Domino on any other platform. However, the AS/400 has unique qualities that make it an excellent choice for a Domino base.

In this article, I give you some information on how to implement your Domino for AS/400 servers so that you can get the most out of your AS/400 investment. If you are coming into Domino with an AS/400 background, the first thing you need to realize is that Domino operates differently than “traditional” AS/400 applications. Traditional AS/400 applications—typically green-screen, business-critical applications—are I/O-intensive by nature. By comparison, Domino is processor-intensive.

Domino is a dynamic environment. Server tasks are always active within the Domino server, and these tasks may be activated on an event, interactive, or scheduled basis. Being aware of these differences will allow you to approach Domino with the perspective that it will not always act the same as a traditional AS/400 business application. Adding a new application to the server, for example, may change how well Domino performs, depending on the quality of the application and the resources it consumes. You will find this article useful if you are experiencing the following:

• Your AS/400 is reaching the peak of its performance capabilities. Either you do not have the option of upgrading your hardware or your current machine must hold on until you can upgrade.

• Either your AS/400’s performance is not what you expect, or you are having problems with application execution.

• You’re not sure you’re getting the most out of your AS/400 investment.

Domino Scenarios

Domino supports the following scenarios, which may be deployed separately or in combination depending on your organization’s needs:

• With Lotus Notes clients to provide email and calendar with no application usage

• With Lotus Notes clients to support application usage with or without email and calendar

• As a Web server hosting Web-based applications with browser clients

• As an Internet standards-based mail server providing POP3, IMAP4, SMTP, and Web- based mail serving

(For more details on mail protocols, see “E-message in a Bottle,” D. Ellis Green, MC, November 1999.)

Because of Domino’s flexibility and wide range of implementation possibilities, it is difficult to make sweeping proclamations about how Domino will perform on any given AS/400 model. To make life easier, IBM provides baseline sizing information and example configurations.

Sizing a Domino Server

The first step to having a well-performing Domino implementation is choosing the proper AS/400 hardware configuration. This involves sizing the AS/400 for your particular implementation. To assist you in this endeavor, IBM provides a sizing worksheet for configuring an AS/400-based Domino system for mail usage (see www.as400.ibm.com/domino/D4szintro.htm for details). You will also find configuration examples that associate types of Domino-based applications with AS/400 models based on the load you expect to support. If you do not feel comfortable with these worksheets and examples, you should obtain expertise from an IBM Business Partner that has experience in implementing applications on Domino in the AS/400 platform.

Domino Implementations and Partitions

The Enterprise version of the Domino server allows you to partition servers that can run within a single AS/400 machine. On the AS/400, partitioning has significant benefits, as you can place each Domino server into its own subsystem. The subsystem in which the Domino server is installed is specified during the installation process. Each subsystem can then be assigned different memory pool sizes and different job run priorities, allowing complete control of the amount of processor resources consumed by your servers. The greatest benefit of partitioning servers is that you can split Domino servers based on their workloads. Your Domino implementation includes email, calendar, and application usage by both Lotus Notes and Web browser clients. Using partitioned servers in the following manner may increase performance and availability:

• One Domino server handles email and calendar.

• One Domino server handles production applications for both Notes and Web-based clients.

• One Domino server provides an application development test environment.

Separating the servers’ workloads allows you to separate exposure. If a poorly written application causes the performance of the application server to suffer, the users’ ability to access email and calendar functions is not affected. Each server may be taken down, restarted, configured, and administered separately from the others. Using a

partitioned server for application testing allows you to limit the amount of memory available to that server and run it at a higher priority so that its impact on the overall system is limited.

Partitioning and Domino R5

Prior to R5, IBM’s recommendation was to limit Domino to around 800 active users per partition. (Keep in mind that this means concurrent and active users, not the number of users registered in the Domino name and address book.) This meant that an R4.6 site of 5,000 registered users would run two or three partitioned servers to provide a well- performing email and calendar environment, assuming that no more than half the registered users were active at the same time.

Significant performance improvements were made to Domino for AS/400 with the OS/400 V4R3 and V4R4 updates. For example, Domino R5.01.02 (combined with the proper PTFs) and Domino R5 changed the way that Domino and OS/400 handle thread processing. More information on the update (and PTF requirements) can be found at IBM’s Web site: www.as400.ibm.com/domino/iocp.htm.

When upgrading to R5, those sites currently running multiple Domino partitions solely for mail are in a position to consolidate their Domino mail servers into a single partition. The upside is higher performance and a decreased cost in administration requirements.

Domino Server Tasks

In this section, I will cover the Domino server from the Domino point of view. I will assume that you have a Domino server installed. Perform a Work with Active Jobs (WRKACTJOB) command as shown in Figure 1, and you will see a number of different jobs running in the Domino server’s subsystem. These consist of the Domino server (SERVER) itself and server tasks that are associated with specific functions as shown in Figure 1.

Now I’ll discuss some of the Domino server tasks. This is not a complete list but includes those that have the greatest potential for performance impact.

The Domino agent manager (AGMR) is responsible for running agents. There may be several instances of this running on your system, depending on your server’s configuration. An agent is typically a script or program that automates tasks. Agents have a wide range of uses. They are used to perform everyday tasks, such as executing the Out of Office agent in a user’s mail file. They are also central to application development. For example, an agent can be responsible for updating tables in a DB2 database from within the Domino environment. This flexibility makes agents the most useful and potentially dangerous components in a Domino environment. The wide range of agent usage makes it difficult to determine their impact on the system’s performance, which is why I recommend using a specific Domino partition for testing and application development.

The Domino administrator controls agent execution authority. As shown in Figure 2, you can set the number of agents, which can run concurrently. Your users will need authority to run restricted LotusScript agents, particularly if they are using R5 Notes clients. Without this authority, Rules agents will not be executed. If you are running application-based agents, it is best to schedule these agents to run outside of regular business hours. To ensure your system’s performance, it is imperative that you thoroughly test application-based agents before they are moved to the production environment.

The HTTP task provides Web-serving functionality to the Domino server. Domino is capable of serving HTML and providing Web browser-based access to Domino databases. There are two areas in which you may reduce the load by the HTTP task. These are the Number of Active Threads and Idle Thread Timeout fields. In R5, these are set in the server document under the HTTP subtab under the Internet Protocols tab. In R4.6, they are controlled by parameters entered in the notes.ini file. By default, Domino does not

timeout idle threads; it drops inactive threads only when the number of concurrent threads exceeds the number of active threads available.

Domino R4.6 relies on the Simple Mail Transport Protocol (SMTP) Message Transfer Agents (MTAs) for sending mail. On the AS/400, the SMTP MTA is integrated with the AS/400’s native SMTP. Domino R5 provides native SMTP functionality. You are no longer reliant on AS/400 native SMTP integration unless you must communicate with native AS/400 mail users, such as OfficeVision users. SMTP performs much better on R5 than on R4.6, and it is much easier to configure and maintain than the SMTP MTA on R4.6.

Overall performance may be improved by implementing a partitioned Domino server specifically for SMTP. This removes SMTP processing from impacting user access. You can raise the run priority of the SMTP server to ensure that users and applications have priority over SMTP processing.

The administrative process (ADMINP) assists Domino administrators by automating administrative tasks and is much more prominent in R5 than in the earlier R4.6 versions. Some of the tasks automated by ADMINP include renaming users, creating replicas, moving or deploying databases to multiple servers, moving users’ home mail servers, and managing resources in the resource database. ADMINP is a computationally expensive task. While it may not be possible to completely avoid triggering the administrative process, it is recommended that administrative tasks be performed outside of regular business hours.

COMPACT, UPDALL, and FIXUP are database maintenance tasks. These tasks may be used to ensure the integrity of Domino databases. They are loaded during their execution and then unloaded upon their completion. The impact of running these tasks is significant, so they should also be run outside of regular business hours.

Removing Tasks from Domino’s Startup

Domino servers rely upon a file called notes.ini for configuration. Notes.ini is located in each server’s data directory. Notes.ini contains much information, but I’m specifically interested in these lines:

ServerTasks=POP3,LDAP,IMAP,HTTP,Replica,Router,Update,Stats,AMgr,Adminp,Sched,
Calconn, Event, QNNINADD
ServerTasksAt1=Catalog,Design
ServerTasksAt2=UpdAll
ServerTasksAt5=Statlog

The ServerTasks line in notes.ini informs Domino of which tasks are loaded upon startup of the Domino server. To remove tasks from Domino’s startup, simply remove these tasks from the ServerTasks line within the notes.ini file and then restart the Domino server.

Lines such as ServerTasksAt1 inform the Domino server of which tasks should be run at 1 a.m. Tasks that run at this time, such as Catalog and Design, are “housekeeping” tasks that perform daily maintenance on the Domino server. Editing the notes.ini file is as easy as executing the Work with Domino Servers (WRKDOMSVR) command and selecting option 13 to edit the notes.ini file for a given server.

If nothing else, you should make sure that your Domino servers are running only those tasks that are required in your specific configuration. A complete list of tasks and their functions is included in the Domino Administrator’s guide.

Looking at Domino from the AS/400

Several commands within the AS/400 environment will give you some insight into the Domino server’s consumption of AS/400 resources.

WRKACTJOB shows system performance by measuring CPU usage of specific Sorting by CPU will give you an overview of which Domino tasks are consuming the CPU at the time you issue the WRKACTJOB command (and when you do any refreshes).

A common problem with Domino servers is the amount of memory in their memory pool and the number of active threads available. The Work with System Status (WRKSYSSTS) command shows this information. If there are not enough active threads available in the memory pool, Domino may experience severe problems. I’ve seen instances in which the Domino server would not even start.

To get an idea of the number of threads you need, do a WRKACTJOB after you have started the Domino server. Press F11 twice to show the number of threads associated with the Domino server’s subsystem. Add up the number of threads running under your Domino servers, keeping in mind that you must add some room for maintenance tasks (such as COMPACT and UPDALL) to run properly. Next, use the WRKSYSSTS command to change the maximum number of threads available to the memory pool in which your Domino server is running. By default, Domino runs in the *BASE memory pool.

If you are on V4R4, change the system value QPFRADJ to 3, which will allow OS/400 to automatically adjust the number of threads and the memory pools. This will give you a base from which to operate.

Movin’ on Up

I recommend that sites currently running Domino for AS/400 upgrade to R5 if they have not already done so. Sites considering a new implementation of Domino should move directly to R5 and skip the R4.6 versions. Performance increases and additional functionality are well worth the work associated with the upgrade. Unfortunately, space limitations keep me from discussing all of the possibilities in configuring the Domino server. In fact, I’ve only scratched the surface. The information in this article represents what I consider to be the most important facets of Domino for AS/400 performance tuning.

References and Related Materials

• “E-message in a Bottle,” D. Ellis Green, MC, November 1999
• Lotus Domino for AS/400—Sizing Information: www.as400.ibm.com/domino/d4szintro.htm
• Performance enhancement in AS/400 Domino 5.0.1.0 QMU: www.as400.ibm.com/domino/iocp.htm

jobs.

Figure 1: WRKACTJOB shows the Domino server and subsystem and some associated server tasks.

Figure 2: The Agent Manager configuration allows you to control the number of concurrent agents and the time that they run.