Front cover

Domino 6 for iSeries

Best Practices Guide
de
Guidelines for deploying Domino in
small and large environments

Selecting the right backup and

recovery strategy

Quickstart to performance
monitoring and tuning

Birgit Roehm
Paul Culpepper
Duane Fitzpatrick
Jennifer Ginder
Sirpa Lepisto
Gerri Passe
Marko Stefancic
John van den Berg

ibm.com/redbooks
International Technical Support Organization

Domino 6 for iSeries Best Practices Guide

June 2004

SG24-6937-00
 Note: Before using this information and the product it supports, read the information in “Notices” on
page xix.

First Edition (June 2004)

This edition applies to Version 5, Release 2, Modification 0 of OS/400 (product number 5733-SS1) and
Version 6.0.2 of Domino 6 for iSeries (5733-LD6).

© Copyright International Business Machines Corporation 2004. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xx

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

Part 1. Deployment, administration, and performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Deploying Domino 6 for iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Environmental planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 User distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Site distribution and server placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 Network bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.4 Client access method and strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.5 LPAR requirements and guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.6 Domino partitioning planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.7 Mail file size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.8 Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.9 Third party products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.10 SMTP architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.11 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.12 SSL accelerators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.13 Fault tolerance solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.14 Backup and recovery requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.15 Domino Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.16 File directory structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.17 Transaction logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.18 Policy-based system administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Hardware planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Special considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Software installation guidelines and resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1 OS/400 and program temporary fixes prerequisites . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.2 Basic install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.3 Installation best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.4 iSeries Access for Windows and iSeries Navigator tips and tricks . . . . . . . . . . . . 26
1.4 Configuration guidelines and recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.1 TCP/IP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.2 Virtual hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.3 Adapter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5 Securing your Domino environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.5.1 iSeries security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5.2 Domino security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

© Copyright IBM Corp. 2004. All rights reserved. iii

 1.6 National language support considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.6.1 Domino 6 compared to Domino R5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.6.2 Localization and NOTES.INI settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.6.3 Web preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.6.4 iSeries Navigator changes in V5R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.6.5 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 2. Administering your Domino environment . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.1 Document your Domino environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.2 Getting the most out of your Domino Directory: revisited . . . . . . . . . . . . . . . . . . . . . . . 48
2.2.1 Getting the most out of your Domino Directory on Domino 6 for iSeries . . . . . . . 48
2.3 ID management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.1 ID file naming standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.2 Creating ID files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.3 Managing ID files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.3.4 Recovering ID files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.5 Roaming users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.3.6 Additional recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.4 Managing your Domino templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5 Mail file management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5.1 Enterprise mail management policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.5.2 Mail policy implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.6 Maintaining your Domino environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.6.1 Recommended maintenance schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.6.2 System databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.6.3 Change management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.6.4 Tips for using the Domino Administrator client . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.6.5 IBM iSeries Access for Windows and iSeries Navigator tips . . . . . . . . . . . . . . . . 73
2.7 LPAR and Domino clustering administration guidelines . . . . . . . . . . . . . . . . . . . . . . . . 88
2.7.1 LPAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.7.2 Domino clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.8 Lotus software compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.9 Backup and recovery strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.10 Upgrade from previous versions of Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.10.1 Why upgrade to Domino 6? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.10.2 Planning your upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
2.10.3 Interoperability issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.10.4 Creating your upgrade plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.10.5 Upgrading your environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2.10.6 Tips and tricks for the upgrade process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.11 Maintenance tips and resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.12 Special considerations for large Domino deployments . . . . . . . . . . . . . . . . . . . . . . . 104
2.12.1 Administration guidelines and recommendations . . . . . . . . . . . . . . . . . . . . . . . 104
2.12.2 Enterprise integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.12.3 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2.12.4 Defining organizational responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Chapter 3. Monitoring Domino performance on the iSeries . . . . . . . . . . . . . . . . . . . . 121

3.1 Ten minute checklist for spotting performance problems . . . . . . . . . . . . . . . . . . . . . . 122
3.2 Using Management Central to monitor system health . . . . . . . . . . . . . . . . . . . . . . . . 123
3.2.1 Setting up Management Central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.2.2 Work with system performance monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.3 Using Collection Services to monitor Domino and iSeries performance . . . . . . . . . . . 134

iv Domino 6 for iSeries Best Practices Guide

 3.3.1 Designing a data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
3.3.2 Starting and stopping a data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.3.3 Using Collection Services data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.3.4 Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.3.5 QAPMDOMINO database reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Chapter 4. Tuning Domino performance on the iSeries . . . . . . . . . . . . . . . . . . . . . . . 171

4.1 iSeries performance tuning for Domino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.1.1 Work with System Status (WRKSYSSTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.1.2 Work with Active Jobs and Work with System Activity . . . . . . . . . . . . . . . . . . . . 184
4.1.3 Run priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
4.1.4 Work with disk status (WRKDSKSTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
4.1.5 Network Status (NETSTAT) and other communication information . . . . . . . . . . 200
4.1.6 System values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
4.1.7 Integrated File System (IFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
4.1.8 Authority lookups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
4.2 Domino performance tuning for iSeries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
4.2.1 Transaction logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
4.2.2 Domino memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
4.2.3 Mail file sizes and indexing large Domino databases . . . . . . . . . . . . . . . . . . . . . 238
4.2.4 HTTP tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Part 2. Managing your environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Chapter 5. Backup and recovery of Domino 6 for iSeries: Concepts. . . . . . . . . . . . . 243

5.1 Domino implementation on the iSeries system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
5.1.1 Domino objects on the iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
5.1.2 Future release changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
5.2 Choosing the right backup strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
5.2.1 Backup methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
5.2.2 Save and restore comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
5.3 Transaction logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
5.3.1 Flushing and hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
5.3.2 DBIID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
5.3.3 Domino server crashes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
5.3.4 Transaction logging basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
5.3.5 Set up transaction logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Chapter 6. Backup and recovery using OS/400 commands . . . . . . . . . . . . . . . . . . . . 257

6.1 What to save and when. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
6.1.1 Recommended saving frequency for Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
6.2 Backing up Domino databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
6.2.1 Backup of entire Domino data directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
6.2.2 Backup of individual Domino databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
6.2.3 Backup of mail databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
6.2.4 Backup of Domino objects outside of the Domino data directory . . . . . . . . . . . . 263
6.3 Incremental backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
6.3.1 Saving changes since the last full backup (cumulative) . . . . . . . . . . . . . . . . . . . 265
6.3.2 Saving changes since the last incremental backup . . . . . . . . . . . . . . . . . . . . . . 265
6.4 OS/400 SAVE menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
6.5 Recovery of Domino for iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
6.5.1 Recover an entire iSeries server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
6.5.2 Recover Domino data directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
6.5.3 Recover Domino mail files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Contents v
 6.5.4 Recover individual Domino databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
6.5.5 Recover changed objects (from an incremental backup) . . . . . . . . . . . . . . . . . . 273
6.5.6 Recover Domino program code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
6.5.7 Recreate a Domino server configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
6.6 Tips and techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
6.6.1 Save files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
6.6.2 Scheduled backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
6.6.3 Save databases while Domino server is running . . . . . . . . . . . . . . . . . . . . . . . . 285
6.6.4 Restore databases while Domino server is running . . . . . . . . . . . . . . . . . . . . . . 286
6.7 Tips for beginners: System management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
6.7.1 User profile requirements for backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
6.7.2 Determine used disk space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
6.7.3 Determine Domino data directory size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
6.7.4 Initialize tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
6.7.5 Find Domino objects on the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
6.8 Common SAV/RST problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Chapter 7. Backup and recovery using BRMS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
7.1.1 If you have never worked with BRMS/400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
7.1.2 Using iSeries Navigator client versus OS/400 commands . . . . . . . . . . . . . . . . . 295
7.1.3 Backup scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
7.1.4 BRMS/400 entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
7.2 Using BRMS iSeries Navigator client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
7.2.1 The BRMS iSeries Navigator client window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
7.2.2 Moving from OS/400 BRMS commands to BRMS iSeries Navigator client . . . . 302
7.3 Configuring a Domino backup strategy in iSeries Navigator . . . . . . . . . . . . . . . . . . . . 304
7.3.1 Creating a backup policy for daily online incremental backups. . . . . . . . . . . . . . 304
7.3.2 Advanced Job Scheduler: Predefined backup schedules . . . . . . . . . . . . . . . . . . 315
7.3.3 Create backup policies for weekly, monthly, and yearly backups . . . . . . . . . . . . 316
7.3.4 Backing up additional (non-Domino) data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
7.4 BRMS/400 concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
7.4.1 Link lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
7.4.2 The BRMS maintenance task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
7.4.3 Print BRMS reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
7.4.4 Review and create move policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
7.4.5 Media pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
7.4.6 Adding media volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
7.4.7 Backup to a save file or an IBM Tivoli Storage Manager server . . . . . . . . . . . . . 323
7.4.8 Checklist for iSeries Navigator Domino backup configuration . . . . . . . . . . . . . . 324
7.5 Tips and troubleshooting iSeries Navigator backups . . . . . . . . . . . . . . . . . . . . . . . . . 325
7.5.1 Tips for iSeries Navigator backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
7.5.2 Troubleshooting tips for Domino backup and recovery. . . . . . . . . . . . . . . . . . . . 326
7.6 Restoring Domino databases with iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . 326
7.7 Quickstart for using OS/400 commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
7.7.1 How BRMS objects relate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
7.7.2 Initialize BRMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
7.7.3 Customizing the BRMS defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
7.7.4 Domino backups in a 24x7 environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
7.7.5 What happens when BRMS runs Domino backups . . . . . . . . . . . . . . . . . . . . . . 344
7.7.6 Domino restore methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
7.7.7 Tips and troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
7.7.8 More information on using BRMS for Domino backups . . . . . . . . . . . . . . . . . . . 352

vi Domino 6 for iSeries Best Practices Guide

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino . . . . . . . . 353
8.1 Introduction to IBM Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
8.1.1 IBM Tivoli Storage Manager basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
8.1.2 Data Protection for Domino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
8.2 Installation of Data Protection for Domino on OS/400 . . . . . . . . . . . . . . . . . . . . . . . . 357
8.3 IBM Tivoli Storage Manager server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
8.3.1 IBM Tivoli Storage Manager node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
8.3.2 IBM Tivoli Storage Manager Policy Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
8.4 Data Protection for Domino on OS/400 configuration . . . . . . . . . . . . . . . . . . . . . . . . . 361
8.4.1 Running the dominstall program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
8.4.2 Creating directory and configuration files: Data Protection for Domino instances 363
8.4.3 Modifying Data Protection for Domino configuration files . . . . . . . . . . . . . . . . . . 364
8.4.4 Include/exclude processing options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
8.4.5 Setting QShell environment variables for Data Protection for Domino . . . . . . . . 368
8.4.6 Verifying Data Protection for Domino configuration . . . . . . . . . . . . . . . . . . . . . . 370
8.4.7 Configuring Data Protection for Domino for partitioned Domino servers . . . . . . 372
8.5 Using Data Protection for Domino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
8.5.1 Backup of Domino databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
8.5.2 Archival of transaction log extents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
8.5.3 Backup strategies for Domino servers using Data Protection for Domino . . . . . 381
8.5.4 Automating backup operations with Data Protection for Domino . . . . . . . . . . . . 383
8.5.5 Scheduling Data Protection for Domino operations on OS/400 . . . . . . . . . . . . . 383
8.6 Recovering Domino servers and databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
8.6.1 Recovering a Domino database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
8.6.2 Performing disaster recovery with Data Protection for Domino . . . . . . . . . . . . . 393
8.7 Considerations and best practices for Data Protection for Domino on OS/400 . . . . . 395
8.7.1 Monitoring operations with Data Protection for Domino . . . . . . . . . . . . . . . . . . . 397
8.8 Sample configuration files and scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
8.8.1 Sample configuration files for Data Protection for Domino . . . . . . . . . . . . . . . . . 399
8.8.2 Sample scripts for scheduled Data Protection for Domino operations . . . . . . . . 401

Chapter 9. Antivirus protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

9.1 e-mail content security and virus threats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
9.1.1 Threat of malicious code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
9.1.2 Spam prevention and content filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
9.1.3 Complete protection for your environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
9.1.4 Implementing an acceptable e-mail usage policy for your organization . . . . . . . 411
9.2 Solutions for antivirus protection and content security for Domino on OS/400 . . . . . . 412
9.2.1 Anti-spam features of Lotus Domino 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
9.3 Symantec AntiVirus/Filtering for Domino 3.0 for OS/400 . . . . . . . . . . . . . . . . . . . . . . 415
9.3.1 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
9.3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
9.3.3 Installing Symantec AntiVirus/Filtering for Domino . . . . . . . . . . . . . . . . . . . . . . . 417
9.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
9.3.5 Configuring Symantec AntiVirus/Filtering for Domino . . . . . . . . . . . . . . . . . . . . . 418
9.3.6 Log database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
9.3.7 Quarantine database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
9.3.8 LiveUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
9.4 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 . . . . . . . . . . . . . . . . . . . . . . . . 422
9.4.1 Installing Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 . . . . . . . . . . . . 424
9.4.2 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 components. . . . . . . . . . 427
9.4.3 ScanMail basic configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
9.4.4 Configuring antivirus protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

Contents vii
 9.4.5 Best practices for using ScanMail in your environment . . . . . . . . . . . . . . . . . . . 440

Part 3. Sizing and IBM Eserver Workload Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Chapter 10. Sizing tips and techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

10.1 Useful Domino for iSeries sizing tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Chapter 11. Using the IBM Eserver Workload Estimator . . . . . . . . . . . . . . . . . . . . . . 463

11.1 Other products and references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
11.2 Workload Estimator introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
11.3 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
11.4 WLE terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
11.4.1 Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
11.4.2 Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
11.5 General Domino sizing concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
11.5.1 Concurrent users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
11.5.2 Number of Domino partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
11.5.3 Domino clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
11.6 Domino mail sizing concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
11.7 Domino application sizing concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
11.7.1 Considerations for characterizing existing applications . . . . . . . . . . . . . . . . . . 487
11.8 iSeries options in WLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
11.9 Understanding the WLE results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
11.10 Additional insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
11.11 Consolidating Domino servers from other platforms . . . . . . . . . . . . . . . . . . . . . . . . 499
11.11.1 Capabilities of various iSeries and AS/400 models. . . . . . . . . . . . . . . . . . . . . 501
11.12 Additional resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

Part 4. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

Appendix A. Quickstart to IBM Eserver Workload Estimator . . . . . . . . . . . . . . . . . . . 507

IBM Workload Estimator: Customer Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Customer example: 500 Domino users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Customer example: 10,000 Domino users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

Appendix B. Information to collect for Domino troubleshooting . . . . . . . . . . . . . . . . 573

Domino hangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Domino server hangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Domino HTTP hangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Domino server crashes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
High CPU utilization in Domino job(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

Appendix C. Common configuration problems that affect Domino performance . . 589

Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Summary of problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
How to identify the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
How to fix the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Network routing - ARP storms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Summary of problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
How to identify the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
How to fix the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Activity Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Summary of problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
How to identify the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
How to fix the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600

viii Domino 6 for iSeries Best Practices Guide

Daylight Savings Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Summary of problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
How to identify the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
How to fix the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Server based mail rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Summary of problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
How to identify the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
How to fix the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
System requirements for downloading the Web material . . . . . . . . . . . . . . . . . . . . . . . 612
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

Contents ix
x Domino 6 for iSeries Best Practices Guide
Figures

1-1 Example Domino partition configuration for mail and applications . . . . . . . . . . . . . . 11

1-2 List of Domino servers in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1-3 iSeries Navigator — Domino plug-in context menu . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1-4 BRMS interface in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1-5 Example of a 5250 emulation session menu for Domino administrators . . . . . . . . . . 32
1-6 The Domino commands menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2-1 Sample spreadsheet for documenting a Domino environment . . . . . . . . . . . . . . . . . 48
2-2 Enable view logging on the View properties -> Advanced tab. . . . . . . . . . . . . . . . . . 51
2-3 Mail retention and intellectual capital collection concept . . . . . . . . . . . . . . . . . . . . . . 58
2-4 Setting a database quota and warning threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2-5 Router/SMTP — Restrictions and Controls — Maximum message size . . . . . . . . . . 62
2-6 Router/SMTP — Restrictions and Controls — Transfer Controls for low priority mail 63
2-7 Example of a mail rule for e-mails with more than 50 recipients . . . . . . . . . . . . . . . . 63
2-8 Send command to multiple servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2-9 Starting a Domino server using iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2-10 Stopping a Domino server using iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2-11 WRKDOMSVR menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2-12 WRKDOMSVR type server list in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . 76
2-13 WRKACTJOB example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2-14 Viewing and managing active jobs in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . 78
2-15 Job properties window in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2-16 WRKSBS command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2-17 Active subsystems in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2-18 Stopping a subsystem in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2-19 Stop Subsystem prompt in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2-20 Run Command in iSeries Navigator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2-21 Run Command window in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2-22 Example of Commands list in Management Central . . . . . . . . . . . . . . . . . . . . . . . . . 87
2-23 Process diagram of monitoring and tuning your Domino system. . . . . . . . . . . . . . . 111
3-1 Creating a new monitor in iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3-2 Metric tab on the New Monitor window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3-3 Threshold 1 settings in the New Monitor window. . . . . . . . . . . . . . . . . . . . . . . . . . . 128
3-4 Management Central: Starting a monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3-5 Create new job monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3-6 Create Domino Server monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3-7 Create Domino Server monitor - Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3-8 Job monitor window - Customized view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
3-9 Display Event log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
3-10 Collection Services Properties - Data to Collect . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3-11 Starting Domino Collection Services using iSeries Navigator . . . . . . . . . . . . . . . . . 138
3-12 Example of an Average CPU Utilization graph for one week. . . . . . . . . . . . . . . . . . 141
3-13 Finding Collection Services data using iSeries Navigator . . . . . . . . . . . . . . . . . . . . 143
3-14 Print Performance Report to find Collection Services data . . . . . . . . . . . . . . . . . . . 144
3-15 Create a query against the MCO data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3-16 Define the Query screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3-17 Specify File Selections screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3-18 Define the TOTALPER field in the Define Result Fields screen . . . . . . . . . . . . . . . 146
3-19 Select and Sequence Fields screen example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

© Copyright IBM Corp. 2004. All rights reserved. xi

 3-20 Select Records for the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3-21 Select JBCPU and TOTALPER fields for Query report . . . . . . . . . . . . . . . . . . . . . . 148
3-22 Defining Query report breaks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3-23 Settings for the Select Output Type and Output Form screen . . . . . . . . . . . . . . . . . 149
3-24 Define Database File Output screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3-25 Save and run query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3-26 Display query results using the RUNQRY command. . . . . . . . . . . . . . . . . . . . . . . . 151
3-27 Example of the Data Transfer from iSeries window. . . . . . . . . . . . . . . . . . . . . . . . . 152
3-28 File Details window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
3-29 Transfer properties window - Conversion setting. . . . . . . . . . . . . . . . . . . . . . . . . . . 153
3-30 Error message from iSeries Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
3-31 Lotus 1-2-3 spreadsheet - Output of Collection Services . . . . . . . . . . . . . . . . . . . . 154
3-32 Choose Data Source in Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3-33 Create New Data Source window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
3-34 General tab of the iSeries ODBC Driver Connect window. . . . . . . . . . . . . . . . . . . . 156
3-35 Server tab of the iSeries ODBC Driver Connect window . . . . . . . . . . . . . . . . . . . . . 157
3-36 Select a default table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3-37 Select the new data source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3-38 Select columns for the Domino transactions report . . . . . . . . . . . . . . . . . . . . . . . . . 159
3-39 Filtering the query using the DTETIM field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3-40 Sort by DTETIM and DMSRVN fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3-41 Saving a query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3-42 Query Wizard - Finish window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
3-43 New Worksheet option on the Import Data window . . . . . . . . . . . . . . . . . . . . . . . . . 161
3-44 Example of raw data in Microsoft Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3-45 Step 1 of the PivotTable wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3-46 Use the default range of data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
3-47 Place the PivotTable report on a new worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . 163
3-48 PivotTable field list window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
3-49 Drop the DTETIM field on the Drop Category Fields Here section of the PivotChart 164
3-50 Drop the DMSRVN field on the Drop Series Field Here section of the PivotChart . 164
3-51 Drop the DMTRNS field on the Drop Data Items Here section of the PivotChart . . 165
3-52 Example PivotChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3-53 The final results from our example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4-1 Output from the TASKINFO advanced analysis macro . . . . . . . . . . . . . . . . . . . . . . 177
4-2 WRKSYSSTS screen before ending jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
4-3 Top of the WRKSYSSTS screen after ending the ROUTER job. . . . . . . . . . . . . . . 178
4-4 Top of the WRKSYSSTS screen after ending the QPADEV002F job. . . . . . . . . . . 179
4-5 Top of the WRKSYSSTS screen after ending the HTTP job. . . . . . . . . . . . . . . . . . 179
4-6 System Summary Information report example from GO DISKTASKS menu. . . . . . 181
4-7 WRKACTJOB screen defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
4-8 WRKACTJOB sorted by CPU % . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4-9 WRKACTJOB: Pool and Pty columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
4-10 Work with System Activity command showing jobs and LIC tasks . . . . . . . . . . . . . 191
4-11 Changing the run priority of a job via iSeries Navigator. . . . . . . . . . . . . . . . . . . . . . 195
4-12 The domino_classes stream file to alter the run priorities of Domino jobs. . . . . . . . 197
4-13 DSPLNK output used for finding the ASP that Domino is running in . . . . . . . . . . . . 198
4-14 WRKDSKSTS and the % Busy column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
4-15 WRKDSKSTS and an unbalanced disk unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
4-16 NETSTAT *CNN and port 1352 in LISTEN status . . . . . . . . . . . . . . . . . . . . . . . . . . 202
4-17 Subset of TCP/IP Connections screen - accessed with F15 from NETSTAT *CNN 203
4-18 Retransmission information from the NETSTAT *CNN screen . . . . . . . . . . . . . . . . 203
4-19 Configured TCP/IP interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

xii Domino 6 for iSeries Best Practices Guide

4-20 Configured TCP/IP routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
4-21 Local host table - CFGTCP option 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
4-22 Domain information - CFGTCP option 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
4-23 Communications trace and the RST packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
4-24 Setting QMCHPOOL system value based on WRKSYSSTS/Reserved Size value 213
4-25 Work with Shared Pools to set the minimum size for a shared storage pool. . . . . . 217
4-26 Main Storage Option in the Display Attributes screen . . . . . . . . . . . . . . . . . . . . . . . 222
4-27 DSPLNK output showing the file format of a Domino template . . . . . . . . . . . . . . . . 223
4-28 Stream file properties in the iSeries Navigator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
4-29 Authority Lookup exceptions in a component report . . . . . . . . . . . . . . . . . . . . . . . . 225
4-30 Using EDTF to review ownership information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
4-31 Display Object Authority screen and the Owner field. . . . . . . . . . . . . . . . . . . . . . . . 227
4-32 Domino console when issuing SHOW MEMORY DUMP command . . . . . . . . . . . . 236
4-33 Stream file contents from the SHOW MEMORY DUMP command . . . . . . . . . . . . . 237
5-1 Configuring Archive style transaction logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
6-1 SAVE menu options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
6-2 OS/400 Save menu - Page 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
6-3 Sample backup CL program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
6-4 Schedule backup CL program to iSeries Job Scheduler - Part 1. . . . . . . . . . . . . . . 284
6-5 Schedule backup CL program to iSeries Job Scheduler - Part 2. . . . . . . . . . . . . . . 284
6-6 WRKJOBSCDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
6-7 Open database locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
6-8 Overall disk usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
6-9 Display the size of a Domino data directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
6-10 Display the size of Domino databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
6-11 Check transaction log usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
6-12 Objects owned by QNOTES user profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
7-1 The BRMS iSeries Navigator client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
7-2 Policy not formatted for iSeries Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
7-3 Backup policy properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
7-4 Naming a backup policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
7-5 Online Lotus server data backup checked. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
7-6 All Domino servers selected for the daily backup . . . . . . . . . . . . . . . . . . . . . . . . . . 306
7-7 Shutdown Integrated Servers window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
7-8 Select the Backup Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
7-9 Media Retention settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
7-10 Select the Media Pool for the backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
7-11 Add Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
7-12 Add media volumes to BRMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
7-13 Select media storage location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
7-14 Initialize tape volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7-15 Summary of the policy settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7-16 Add volume to BRMS pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
7-17 New backup policy created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
7-18 Management Central Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
7-19 The Advanced Job Scheduler window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
7-20 New Schedule example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
7-21 Customize User Data for the backup policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
7-22 BRMS default link lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
7-23 BRMS Run Maintenance Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
7-24 Select reports to print. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
7-25 Move policy properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
7-26 Add media pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Figures xiii
 7-27 Add media to media pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
7-28 Backup Policy properties - During Backup settings . . . . . . . . . . . . . . . . . . . . . . . . . 324
7-29 Select type of information to restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
7-30 Select the directory to be restored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
7-31 Select the date of the save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
7-32 Restore directory or select files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
7-33 Select files to restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
7-34 Restore summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
7-35 WRKPCYBRM *SYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
7-36 The weekly media policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
7-37 BRMSDAY control group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
7-38 BRMSWEEK control group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
7-39 Control group for full backup after incremental backup . . . . . . . . . . . . . . . . . . . . . . 339
7-40 Monthly backup control group attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
7-41 BRMSMONTH control group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
7-42 BRMSSYS control group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
7-43 Weekly backup of user data except Domino data . . . . . . . . . . . . . . . . . . . . . . . . . . 343
8-1 Data Protection for Domino on OS/400 architecture . . . . . . . . . . . . . . . . . . . . . . . . 356
8-2 Installation of Data Protection for Domino (RSTLICPGM) . . . . . . . . . . . . . . . . . . . . 358
8-3 Running dominstall command in QShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
8-4 The export command in QShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
8-5 Result of querying access to Lotus Domino server with domdsmc . . . . . . . . . . . . . 371
8-6 Result of querying access to IBM Tivoli Storage Manager server using domdsmc . 372
8-7 Result of running the selective backup for a single Domino database . . . . . . . . . . 377
8-8 Results of running the incremental backup command . . . . . . . . . . . . . . . . . . . . . . . 379
8-9 Transaction log archiving with Data Protection for Domino . . . . . . . . . . . . . . . . . . . 380
8-10 Scheduled Data Protection for Domino jobs on OS/400 . . . . . . . . . . . . . . . . . . . . . 384
8-11 Restoring a Domino database with Data Protection for Domino . . . . . . . . . . . . . . . 387
8-12 Prompting for databases to restore - PICK parameter. . . . . . . . . . . . . . . . . . . . . . . 388
8-13 The query pending command - show restored databases awaiting activation . . . . 390
8-14 Activation of restored Domino databases without applying transaction log changes 391
8-15 Activation of restored Domino databases to specific point in time. . . . . . . . . . . . . . 392
8-16 Domino console messages - transaction log operations during database activation 392
9-1 Sample FTP commands to transfer ScanMail installation file to the iSeries . . . . . . 425
9-2 The ScanMail configuration command CFGSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
9-3 Output of running the CFGSM command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
9-4 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 user interface . . . . . . . . . . . 431
9-5 The Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 registration form . . . . . 432
9-6 Update Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 settings . . . . . . . . . 433
9-7 Server Program document runs hourly updates - virus pattern file and scan engine 434
9-8 Real-time mail scan — the scan options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
9-9 Real-time mail scan “Action on Viruses” options . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
9-10 Real-time mail scan Virus Notification options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
9-11 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 - Virus Top Ten . . . . . . . . . 448
10-1 Example table of existing system characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . 460
11-1 Workload Estimator Terms and Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
11-2 WLE Basic Workload Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
11-3 WLE Domino mail workload definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
11-4 Number of partitions for Domino workload instance . . . . . . . . . . . . . . . . . . . . . . . . 471
11-5 WLE Default mail workload settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
11-6 WLE Inbound Cluster Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
11-7 WLE Inbound Cluster Replication parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
11-8 WLE Mail workload - clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

xiv Domino 6 for iSeries Best Practices Guide

11-9 WLE application rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
11-10 WLE iSeries user options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
11-11 WLE Immediate Solution selected system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
11-12 WLE results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
11-13 WLE Growth Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
11-14 WLE solution comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
A-1 WLE for PAG - Edit Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
A-2 WLE for PAG - iSeries User Options panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
A-3 WLE for PAG - Disk Storage Percent Full . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
A-4 WLE for PAG - Basic Workload Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
A-5 WLE for PAG - Add 3 Domino workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
A-6 WLE for PAG - Estimation Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
A-7 WLE for PAG - Changed Estimation Identification. . . . . . . . . . . . . . . . . . . . . . . . . . 514
A-8 WLE for PAG - changed Basic Workload Selection window . . . . . . . . . . . . . . . . . . 515
A-9 WLE for PAG - Domino #1 Workload definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
A-10 WLE for PAG - Notes mail (100MB) title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
A-11 WLE for PAG - Notes mail (100MB) parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
A-12 WLE for PAG - Notes mail (300MB) workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
A-13 WLE for PAG - Sametime chat (application) workload . . . . . . . . . . . . . . . . . . . . . . 520
A-14 WLE for PAG - Sametime chat workload definition . . . . . . . . . . . . . . . . . . . . . . . . . 521
A-15 WLE for PAG - Initial Immediate and Growth Solutions. . . . . . . . . . . . . . . . . . . . . . 522
A-16 WLE for PAG - change growth rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
A-17 WLE for PAG - Selected Immediate and Growth Solutions . . . . . . . . . . . . . . . . . . . 524
A-18 WLE for PAG - PDF of WLE results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
A-19 WLE for PAG - Save All Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
A-20 OSTI- Initial high level diagram of potential solution . . . . . . . . . . . . . . . . . . . . . . . . 529
A-21 WLE for OSTI - Disk Storage Percent Full. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
A-22 WLE for OSTI - Add Domino workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
A-23 WLE for OSTI - Estimation Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
A-24 WLE for OSTI - changed Basic Workload Selection window. . . . . . . . . . . . . . . . . . 533
A-25 WLE for OSTI - Notes mail (100MB) title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
A-26 WLE for OSTI - Notes mail (100MB) parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 535
A-27 WLE for OSTI - Notes mail (300MB) workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
A-28 WLE for OSTI - Mail workload with Inbound Cluster Replication. . . . . . . . . . . . . . . 537
A-29 WLE for OSTI - Notes mail (600MB) workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
A-30 WLE for OSTI - Inbound Cluster Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
A-31 WLE for OSTI - iNotes Web Access workload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
A-32 WLE for OSTI - Sametime chat workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
A-33 WLE for OSTI - Sametime chat workload definition. . . . . . . . . . . . . . . . . . . . . . . . . 542
A-34 WLE for OSTI - Domino appl’ns workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
A-35 WLE for OSTI - Domino appl’ns workload definition . . . . . . . . . . . . . . . . . . . . . . . . 544
A-36 WLE for OSTI - Selected System solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
A-37 WLE for OSTI - Selected System Workload Growth Factors. . . . . . . . . . . . . . . . . . 546
A-38 WLE for OSTI - Selected System (Normal Operations). . . . . . . . . . . . . . . . . . . . . . 547
A-39 WLE for OSTI - Navigate->Notes mail (600MB) workload. . . . . . . . . . . . . . . . . . . . 548
A-40 WLE for OSTI - deselect Inbound Cluster Replication. . . . . . . . . . . . . . . . . . . . . . . 549
A-41 WLE for OSTI - changed Notes mail (600MB) workload . . . . . . . . . . . . . . . . . . . . . 550
A-42 WLE for OSTI - Selected System solutions (fail over mode) . . . . . . . . . . . . . . . . . . 551
A-43 WLE for OSTI - PDF of WLE results (fail over mode) . . . . . . . . . . . . . . . . . . . . . . . 552
A-44 WLE for PAG - Save All Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
A-45 OSTI - Modified high level diagram of potential solution . . . . . . . . . . . . . . . . . . . . . 554
A-46 WLE for OSTI - File -> Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
A-47 WLE for OSTI - Restore Saved Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555

Figures xv
 A-48 WLE for OSTI - Restore saved estimation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
A-49 WLE for OSTI - Basic Workload Selection (after restoring saved WLE file) . . . . . . 557
A-50 WLE for OSTI - Expert Workload Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
A-51 WLE for OSTI - change LPAR Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
A-52 WLE for OSTI - add logical partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
A-53 WLE for OSTI - add Workload to new LPAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
A-54 WLE for OSTI - add new Domino workload to LPAR. . . . . . . . . . . . . . . . . . . . . . . . 561
A-55 WLE for OSTI - change names of logical partitions . . . . . . . . . . . . . . . . . . . . . . . . . 562
A-56 WLE for OSTI - Partition Controller workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
A-57 WLE for OSTI - define Domino #7 workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
A-58 WLE for OSTI - define new Domino dev/test workload . . . . . . . . . . . . . . . . . . . . . . 564
A-59 WLE for OSTI - initial results after adding LPAR . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
A-60 WLE for OSTI - change growth rate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
A-61 WLE for OSTI - Selected System after changing growth rate . . . . . . . . . . . . . . . . . 567
A-62 WLE for OSTI - results with LPARs - pdf format . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
A-63 WLE for OSTI - Immediate Solution LPAR Information . . . . . . . . . . . . . . . . . . . . . . 569
A-64 WLE for OSTI - Growth Solution LPAR Information . . . . . . . . . . . . . . . . . . . . . . . . 570
A-65 WLE for OSTI - Growth Solution comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
B-1 Fields to fill in on Dump Entries to Printer from Licensed Internal Code Log Screen 577
B-2 Example call stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
C-1 Network retransmission information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
C-2 Example of a retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
C-3 CFGTCP option 2 - Work with TCP/IP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
C-4 iSeries Navigator displaying active lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
C-5 Example of an ARP broadcast in a communications trace . . . . . . . . . . . . . . . . . . . 596
C-6 Example of a changing MAC address in a conversation . . . . . . . . . . . . . . . . . . . . . 597
C-7 CFGTCP option 2 with preferred bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
C-8 Example of the output from the DSPLOG command . . . . . . . . . . . . . . . . . . . . . . . . 601
C-9 Example of the output from F9 when in the Additional Message Information screen 602
C-10 SHOW SERVER command to check the Elapsed time parameter . . . . . . . . . . . . . 602
C-11 Mail rules in the Domino Directory configuration document. . . . . . . . . . . . . . . . . . . 608

xvi Domino 6 for iSeries Best Practices Guide

Tables

1-1 Server naming convention example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1-2 Domino 6 for iSeries installation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2-1 Lotus products supported by Domino 6 for iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3-1 Methods for manipulating and viewing performance data on a PC . . . . . . . . . . . . . 142
3-2 QAPMDOMINO database fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
4-1 Paging and faulting levels for storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4-2 Relationship between mail file size, document size, and number of documents . . . 238
5-1 Domino libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
5-2 Domino directories in the IFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
5-3 Save/restore comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
7-1 Naming differences iSeries Navigator - 5250 emulation environment . . . . . . . . . . . 298
7-2 Backup schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
8-1 Processing of Domino databases using selective and incremental backup . . . . . . 376
8-2 Required scheduled scripts for Data Protection for Domino backups . . . . . . . . . . . 383
9-1 Software requirements for Symantec AntiVirus/Filtering 3.0 for Domino on iSeries 417
9-2 ScanMail programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
9-3 ScanMail temporary directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
9-4 ScanMail databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
9-5 Access Control List for ScanMail databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
10-1 Mail file size ranges and number of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
10-2 Rules of thumb: user types according to mail file sizes . . . . . . . . . . . . . . . . . . . . . . 457
11-1 WLE - Default concurrency rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
11-2 WLE application examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
11-3 Web Document Library Estimated Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
11-4 iSeries Dedicated Server for Domino performance details . . . . . . . . . . . . . . . . . . . 501
11-5 Further iSeries servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
11-6 Domino workloads on first generation of 270 and 8xx models . . . . . . . . . . . . . . . . 502
11-7 Mail workloads for 170 and 7xx models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
11-8 Simple mail users on 6xx and Sxx models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
A-1 Mail file size ranges and user types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
C-1 Results of testing Domino 6 mail rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607

© Copyright IBM Corp. 2004. All rights reserved. xvii

xviii Domino 6 for iSeries Best Practices Guide
Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are
inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and
distribute these sample programs in any form without payment to IBM for the purposes of developing, using,
marketing, or distributing application programs conforming to IBM's application programming interfaces.

© Copyright IBM Corp. 2004. All rights reserved. xix

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® Freelance Graphics® OS/400®
AS/400e™ IBM® PartnerWorld®
AS/400® ibm.com® POWER4™
Balance® iNotes™ QuickPlace®
ClusterProven® iSeries™ Redbooks™
developerWorks® Lotus Discovery Server™ Redbooks(logo) ™
Domino Designer® Lotus Enterprise Integrator® S/390®
Domino.Doc® Lotus Notes® Sametime®
Domino® Lotus Workflow™ Tivoli®
DB2 Universal Database™ Lotus® TotalStorage®
DB2® MVS™ WebSphere®
DRDA® Netfinity® xSeries®
eServer™ Notes® zSeries®
^™ Operating System/400® 1-2-3®
™ OS/2®

The following terms are trademarks of other companies:

Intel, Intel Inside (logos), and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, and service names may be trademarks or service marks of others.

xx Domino 6 for iSeries Best Practices Guide

Preface

This IBM Redbook is a collection of Domino® 6 related topics that are important pieces of
information and are either not covered in other documents, or the existing information is
outdated because it applies to older versions of Domino, such as Domino V5.x. As such, the
topics vary widely and range from Domino deployment, performance monitoring and tuning to
Antivirus protection. This redbook complements and updates the content of existing
redbooks, for example, IBM Lotus Domino 6 for iSeries Implementation, SG24-6592; and
Domino for iSeries Sizing and Performance Tuning, SG24-5162-01.

This book takes into account that there are two different types of Domino administrators and
users: The first type consists of users that come from the iSeries™ world and are
implementing a Domino environment on their existing system with lots of iSeries experience.
The second user type includes experienced Domino administrators that are about to move or
have moved their Domino environment to the iSeries from another platform. Thus, wherever
possible and necessary, we have added information for both user types. Please keep this in
mind when you read information that seems very basic or obvious - it might be news for “the
other user type”!

Part 1 of this book covers Domino deployment, administration, and performance monitoring
and tuning.

Part 2 describes the various backup and recovery methods that are available for Domino on
iSeries and helps you to determine which backup and recovery strategy is right for you.
Antivirus protection is also covered in Part 2.

Part 3 teaches you what needs to be considered when sizing a Domino environment and
explains how to use the IBM Eserver Workload Estimator.

Part 4 gives you a quickstart to use the Workload Estimator based on fictitious customer
environments. It also helps you to solve some Domino performance problems and tells you
what information you need to collect for Domino troubleshooting.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the
International Technical Support Organization, Rochester Center.

© Copyright IBM Corp. 2004. All rights reserved. xxi

 The IBM® redbook team (from left to right): John van den Berg, Gerri Passe, Marko Stefancic, Jennifer
Ginder, Birgit Roehm, Sirpa Lepisto, Duane Fitzpatrick. Not in this picture: Paul Culpepper.

Birgit Roehm is a Project Leader at the International Technical Support Organization,

Rochester Center. She writes on various aspects of WebSphere® and Domino. Before
joining the ITSO in 2003, Birgit worked in iSeries Advanced Technical Support, Germany,
responsible for Domino and WebSphere on iSeries.

Paul Culpepper is a Consulting IT Architect for the Strategy and Technical Enablement
Group for IBM Software Services for Lotus® in Phoenix, AZ. He has over 10 years of
technical expertise with messaging architectures and Lotus Products. He has been involved
in the design and deployment of many of the largest Domino environments in the U.S. His
areas of expertise are Lotus Notes® and Domino infrastructure design, messaging
migrations, deployment, messaging and collaborative strategies, and TCO improvement.

Paul Culpepper

xxii Domino 6 for iSeries Best Practices Guide

Duane Fitzpatrick is a Messaging Engineer for Bank One, located in Columbus, Ohio. He
has over eight years experience working as a Domino administrator and developer in small,
medium and large Domino environments, including recent Domino for iSeries experience as a
Technical Specialist for The Kroger Company (while writing this redbook). He also has over
nine years experience with the AS/400® and iSeries servers. He holds dual Principal Lotus
certifications in Notes/Domino Release 4, Release 5 and Release 6. He holds a Master of
Business Administration degree from the University of Louisville.

Jennifer Ginder is a Staff Software Engineer in the IBM Rochester Support Center. She has
six years of experience with the iSeries specializing in Domino, performance, and work
management. She holds a Bachelor of Science degree from Carleton College.

Sirpa Lepisto is an IT Specialist from IBM Finland. She joined IBM in 1999 and is working
with the iSeries System Support Team. Her areas of expertise include Domino for iSeries,
operating system technical support, and iSeries software support. Before joining IBM, she
worked over 10 years as a system operator and system specialist in various IBM platforms,
including S/34,S/36,S/38 and AS/400 (iSeries). She is a Certified Lotus Professional (CLP) in
Domino R5 system administration.

Gerri Passe is a Senior Information Technology Specialist with the IBM Advanced Technical
Sales Support organization in Rochester, MN. She holds a Bachelor of Arts degree in
Mathematics. During the last four years at IBM, she has been focused on Lotus Domino for
iSeries and related solutions. Her prior experience at IBM has included working in the thin
client technology area and seven years as an IBM AS/400 Systems Engineer in southern
Minnesota. Also, her first nine years at IBM were spent working in the mainframe
(VM/VSE/MVS™) area. Gerri has worked on several previous redbooks and has spoken at
numerous IBM and customer conferences such as COMMON and iSeries Technical
conferences.

Marko Stefancic is the Chief Technology Officer and co-owner of the Genis
(http://www.genis.si), which is based in Slovenia. Marko attended the Faculty of
Economics of the University in Ljubljana and now lives with his wife in Kranj. He is an IBM
Certified Instructor and holds principal certifications in Lotus, iSeries and IBM DB2® with
more than 10 years of consulting experience. Currently he is responsible for Lotus
technologies, IBM DB2 Content Manager and IBM eServer™ iSeries consulting,
implementation and support services.

John van den Berg has worked in IBM for almost 25 years, as a Hardware and Software
Support Customer Engineer in The Netherlands. He was the DW/36 and OS/400® Office
Vision specialist in his department, and is now a Lotus CLP in Domino R5 Administration and
a certified Domino for iSeries specialist. Since 3 years he works in the IBM Strategic
Outsourcing department, specializing in Domino for iSeries, while participating in iSeries
outsourcing projects.

A special thanks goes to Debra Landon, ITSO Rochester, for her help and support throughout
the project.

Thanks to the following people for their contributions to this project:

Tom Gray
Marv Kulas
Joanna Pohl-Miszczyk
Craig Schmitz
Jenifer Servais
Janet Willis
International Technical Support Organization, Rochester Center

Preface xxiii
 Terry Ackman
David Bhaskaran
Charlie Carroll
Swinder Dhillon
Melissa S. Fichtinger
Terrence Forrest
Mike Gordon
Dave Johnson
Paul Koeller
Gary Lakner
Clayton McDaniel
Laurie Miller
Ted Mongeon
Tony Mueller
Jeff Parker
Tony Perkins
Joe Peterson
Lee Prissel
Leif Rush
Walter Scanlan
Tracy Smith
William Smith
Steve Sparrow
Fant Steele
Mervyn Venter
Aditya Wresniyandaka
IBM Rochester

Bob Stegmaier
Will Witten
IBM Dallas

Terry Dimka
IBM Bethesda

Sabine Jordan
IBM Germany

Kim Greene
Kim Greene Consulting, Inc.

Sarah Gordon
John McArdle
Ron Ruggles
Symantec Corporation

Michael Eberl
Rolf Rennemo
Juergen Saamen
Trend Micro, Inc

Yvonne Lyon, editor

International Technical Support Organization, San Jose Center

xxiv Domino 6 for iSeries Best Practices Guide

Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with
specific products or solutions, while getting hands-on experience with leading-edge
technologies. You'll team with IBM technical professionals, Business Partners and/or
customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus,
you'll develop a network of contacts in IBM development labs, and increase your productivity
and marketability.

Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html

Comments welcome
Your comments are important to us!

We want our Redbooks™ to be as helpful as possible. Send us your comments about this or
other Redbooks in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an Internet note to:
[email protected]
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JLU Building 107-2
3605 Highway 52N
Rochester, Minnesota 55901-7829

Preface xxv
xxvi Domino 6 for iSeries Best Practices Guide
 Part 1

Part 1 Deployment,
administration, and
performance
Part 1 of this book covers Domino deployment, administration, and performance monitoring
and tuning.

© Copyright IBM Corp. 2004. All rights reserved. 1

2 Domino 6 for iSeries Best Practices Guide
 1

Chapter 1. Deploying Domino 6 for iSeries

In this chapter we describe best practices for architecting, installing, configuring, and
maintaining a Domino environment. The concepts apply to small, medium, and large Domino
environments. We highlight considerations specific to the iSeries platform, where applicable.

This chapter covers the following topics:

򐂰 “Environmental planning” on page 4
򐂰 “Hardware” on page 18
򐂰 “Software installation guidelines and resources” on page 20
򐂰 “Configuration guidelines and recommendations” on page 33
򐂰 “Securing your Domino environment” on page 36
򐂰 “National language support considerations” on page 43

© Copyright IBM Corp. 2004. All rights reserved. 3

1.1 Environmental planning
There are many things to consider when deploying Lotus Domino 6 on iSeries prior to
architecture design and installing the code base. When planning your new environment,
please consider the Environmental planning checklist prior to architecting your infrastructure.

This section describes each item on the basic checklist for planning your environment. We
recommend that you gather this information for planning and documenting your environment.
Retain the documentation for your reference and for auditing purposes.

1.1.1 User distribution

Before planning your physical server topology it is important that you understand the user
distribution of your environment, that is, how are your organization's users distributed? You
should consider geography, logical grouping (business units), language requirements, client
access methods and workload balancing, if available, when planning your user distribution.
These criteria will dictate how you distribute users and servers in your environment.

For instance, you may want to group logical Domino partitions by location or business unit for
ease of administration (for example the Chicago office or Legal Department). Depending on
client access methods, you may want to balance your Domino Web Access (iNotes) users
and your Notes 6 client users for proper load balancing.

Here are the input parameters commonly used for server sizing exercises:
򐂰 Number of registered users: The number of users defined in the directory to be homed
on a particular Domino server.
򐂰 Client conversion factor: A ratio describing the workload of a Domino Web Access
(iNotes) user relative to a Lotus Notes client user.
򐂰 User concurrency: Expected percentage of registered users active at any given time.
򐂰 Percentage Lotus Notes clients: The percentage of users expected to use a Lotus
Notes client.
򐂰 Percentage Domino Web Access (iNotes) clients: The percentage of users expected to
use Domino Web Access (iNotes).
򐂰 Number of Domino partitions: The number of Domino servers per physical iSeries
server or OS/400 LPAR.
򐂰 Average mail database size: Average size of each mail database in megabytes (MB).
򐂰 Transaction log volatility: The percentage of the total data expected to change per day.
򐂰 Backup cycle: The number of days worth of transaction logs that need to be supported.
򐂰 Domino servers in a cluster: The number of member servers in the cluster.
򐂰 Open databases allowed: Percentage expected of open mail databases.

Keep in mind that, when determining user topology, it is very common to achieve what seems
like an even distribution by basing your user spread on a count of registered users. Therefore,
by viewing the Domino Directory, it is easy to determine which servers have fewer users.
However, one thing to consider is that not all users in a Domino environment use resources
equally. The workload which results is never uniform across a given user population. Some
users are light, some medium, and some heavy in terms of the resources they require from
their server. Thus, if possible, it is much better to try to determine a workload balance as
opposed to a user count balance. This usually involves an assessment of the number of
transactions processed by a server and, since it is often a limiting factor, the amount of disk
space required for each user.

4 Domino 6 for iSeries Best Practices Guide

 The Tivoli® Analyzer component of the Domino 6 Administrator client can provide
information along with recommended changes to distribute load more evenly. For more
information, please refer to the IBM Tivoli Analyzer for Lotus Domino Web site at:
http://www.ibm.com/software/tivoli/products/analyzer-lotus-domino/library.html

1.1.2 Site distribution and server placement

Site distribution/server placement is another important factor for planning your infrastructure.
A Domino server topology describes the physical placement of servers in the Domino
environment. The best practices of designing a server topology focus on:
򐂰 Minimizing network traffic
򐂰 Leveraging available bandwidth
򐂰 Enabling efficient and rapid replication and routing strategies
򐂰 Minimizing total cost of network and servers
򐂰 Minimizing the number of network routers through which Domino network traffic must pass
򐂰 Minimizing the number of servers in the environment
򐂰 Providing for disaster recovery and high availability
򐂰 Physical location of administration staff with appropriate skill sets
򐂰 Minimizing the overhead generated by roaming users
򐂰 Optimizing the workflow features of Domino
򐂰 Optimizing access to back end database systems

The best practices that enable a design to achieve these goals include centralizing servers as
much as possible, meaning co-locating servers in a single site rather than in different sites.
All other things being equal, hosting users from a centrally located server enables an
organization to:
򐂰 Take advantage of economies of server scaling.
This reduces the number of servers in the environment and ensures maximum usage of
available resources, that is, no server "overkill".
򐂰 Reduce the amount of mail routing in the environment.
Fewer servers means less routing since more mailboxes are located on the same server.
򐂰 Reduce the amount of replication in the environment.
There is no need to replicate user applications between servers in the same location, as
users can get to either server equally well.
򐂰 Reduce wide area network (WAN) traffic and speed replication and routing between
servers.
Administrative databases, such as the Domino Directory or the AdminP database, must
replicate to every server. In a centralized environment they are replicated over a
high-speed LAN connection. The same is true for mail that must route between servers.

However, centralizing servers should be carefully analyzed. Some items to consider are:
򐂰 Increased WAN costs.
򐂰 Dependency on WAN reliability.
򐂰 Exposure to performance issues in extreme situations. In LAN based environments, for
example, the time to open an average message (10 KB) may be .05 seconds while in WAN
environments with 1/10 the available bandwidth, it is .5 seconds. Either is quite
acceptable. However, in the same LAN environment, the time required to open a message
100 times the size (1 MB) would be about 5 seconds, while in the WAN environment this
would take 50 seconds.

Chapter 1. Deploying Domino 6 for iSeries 5

 In order to determine the best solution around server centralization, an analysis must be
performed which takes into account the following items:
򐂰 Hardware costs per user in remote and central scenarios
򐂰 Service level agreement (SLA) requirements for response time
򐂰 Per user bandwidth requirements for Domino/Notes to meet these SLAs
򐂰 Network costs to provide required bandwidth
򐂰 Client strategy

1.1.3 Network bandwidth

Determining available network bandwidth and usage is critical to planning and configuring a
Domino environment on iSeries. Once you determine the Peak Concurrency for your user
communities, it is possible to calculate the Required Per-User Bandwidth as the product of
the Effective Bandwidth Requirement and the Peak Concurrency ratio. If this bandwidth is
then made available to the users across all network links between the client and the server,
then the users should realize reasonable performance from the Notes environment under all
but the most extreme conditions.

Perform network analysis to determine the network requirements for the Domino
environment. The following information details the methodology used to determine these
requirements:
1. The first step in the methodology is profiling user’s Notes usage. This is done by
monitoring network packets sent and received by the client workstation, isolating Notes
packets by monitoring for Notes server IP addresses. Analysis should be run and data
collected for a number of workstations, and the analysis should be repeated numerous
times for all clients, at different times during the workday.
2. Once the data is collected, total data transmissions should be summed and divided by the
number of seconds for the session for each client to arrive at a value for Kbps required for
the session. Obviously the numbers can vary widely. If the user sends notes with a large
file or spreadsheet attached, the Kbps/session would be high; if the user is sending a
simple text note, then it's low. Therefore, the requirements for each session should be
averaged. This average becomes the Actual Bandwidth Requirement for an Active Notes
User.
3. Next, determine the effective bandwidth requirement factoring in network efficiency. This
number will be larger than the actual bandwidth requirement due to losses for overhead.
This factor will differ for different network protocols and network environments.
4. Then, consider peak concurrency. Peak concurrency describes the highest percentage of
users that are actually communicating with the server at the same moment in time. Notes'
client-server architecture allows many functions to be accomplished without
communication with a server. For instance, in a mainframe environment, every keystroke
results in a transmission and reception with the host since the terminal has no processing
power. In contrast, the act of typing a Notes e-mail message does not result in any
communications between the Lotus Notes client and Domino server because this is all
handled internally at the client. Typically, the only actions that result in transmissions are
reading or writing a document. For this reason, peak concurrency is typically lower than
mainframe concurrency, although the size of each transmission is typically larger.
There are a couple of options for determining Peak Concurrency. One option is to use
known, industry standard peak concurrency ratios for Lotus Notes. These tend to range
from around 25% to 35% in most cases, with the higher percentage representing a more
intensive group of Notes users. Alternatively, Notes servers will report on peak
concurrency over time in terms of the number of users accessing a server. If the total
population of users is known, then the peak concurrency ratio can be determined by
dividing the server reported peak concurrency by the total population.

6 Domino 6 for iSeries Best Practices Guide

 Based on this methodology, you can properly plan for the number of concurrent users you can
support using this formula. For the following example, assume 1/3 of your user population is
concurrent, and your WAN link is at 60% utilization. From your analysis your average
concurrent user is utilizing 4k.
Multiplication factor = (1/[bandwidth per active user]) x 3 x 0.60 = percentage factor

Therefore, (1/4) x 3 x 0.60 = .45

Total concurrent users = bandwidth x percentage factor

So for this example, having a T1 (1.544 MB) connection between your sites, you could
support 695 concurrent users (1.544MB x .45 = 695).

While the above formulas will provide fine planning data, in an evolving environment it is
important to repeat these procedures over time. Maturation of Notes users will change their
usage patterns, as will deployment and maturation of Notes applications. We suggest that
this analysis be repeated every 3 months during Notes implementation and/or migration from
a different environment, and every 6 - 12 months in a fully deployed environment.

Please note that Notes and Domino 6 can significantly reduce network bandwidth using
compression techniques:
򐂰 Network port compression
򐂰 Attachment compression
򐂰 Streaming replication

Note: A compressed attachment cannot be compressed again by network compression.

Certain types of data are more compressible than others and the compression ratios will differ
accordingly. For example, JPG image files are already compressed and cannot be made
significantly smaller by subsequent compression. In most cases, network and attachment
compression can reduce the amount of data moved by up to 50%.

Streaming replication uses far fewer request and acknowledgements between the client and
server (or between servers) to provide much more efficient and shorter replication times.

1.1.4 Client access method and strategy

The client strategy plays an important role when sizing servers and deciding on user and site
distribution. Prior to implementation, you need to carefully plan the client access methods that
will be used to access Lotus Domino mail and applications. The method in which users
access their mail and applications will have a direct impact on the user and site distribution as
well as server sizing. For instance, prior to your architecture design, you should carefully map:
򐂰 User access via Domino Web Access (iNotes) or browser (Web access to mail)
򐂰 Lotus Notes 6 client (local versus server replica)
򐂰 Roaming user requirements (new in Domino 6)
򐂰 IMAP/POP3
򐂰 Multi-user workstation access

It is best to have a corporate policy for which methods of access will be supported within the
proposed environment. Then appropriate capacity planning can be done and a structured
approach to user distribution can be put in place. Refer to Chapter 10, “Sizing tips and
techniques” on page 455 for more information about the impact certain access methods have
on the system size.

Chapter 1. Deploying Domino 6 for iSeries 7

 Notes 6 client
Lotus Notes 6 users are people who use the Lotus Notes client to access Domino servers
and databases and have a Notes ID, a Person document, and, if they use Notes Mail, a mail
file. The business requirements for these users dictate a robust, secure full client for
accessing Domino mail and applications.

Alternative client strategies

For those users who do not meet minimum requirements for client hardware specifications or
for those users who share workstations and need a “kiosk” based environment, Domino Web
Access (iNotes) and roaming user client models can provide full messaging functionality:
򐂰 Domino Web Access (iNotes):
Domino Web Access (iNotes) can provide robust functionality for users who need to
access e-mail, calendar, contacts and To do's, plus collaborative and e-business
applications through a browser, such as Internet Explorer. That functionality is available
whether they are online or disconnected from the network.
򐂰 WebMail:
WebMail refers to internet mail access in which the database is web enabled and runs
JavaScript to make the client look similar to the Lotus Notes client. Users with WebMail
clients use HTTP to interact with mail on the Domino server.
򐂰 POP3 and IMAP:
The Post Office Protocol (POP3) is an internet based electronic mail protocol server
implementation for accessing mail remotely. The Internet Message Access Protocol
(IMAP) provides a superset of POP3 functionality with a different interface. Along with
accessing mail remotely, users with IMAP clients can interact with and manage mail
directly on a Domino server that runs the IMAP service.
򐂰 Domino Access for Microsoft® Outlook:
If your user community remains on Microsoft Outlook, you can use Domino either as an
IMAP server or use the Domino Access for Microsoft Outlook connector or the MS Outlook
2002 Connector for more robust functionality.
򐂰 Roaming user:
Users who access Notes from more than one Lotus Notes client can access their
customized settings and personal information automatically from any Lotus Notes client in
the domain. Data for these so-called roaming users replicates between the user's machine
and a roaming user server, where these files are stored. Any changes the user makes to
personal files replicate to the roaming user server. This enables the roaming user to have
a consistent experience from any Lotus Notes client.
򐂰 Multi-user workstation:
Use the multi-user installation if your enterprise has multiple users who share a single
workstation. When users log onto the system, they run the Lotus Notes 6 client setup and
their own personal data files — that is, BOOKMARK.NSF, NAMES.NSF, and other files —
are created. Multi-user installation applies to Microsoft Windows® (Win 32) users only.
The multi-user installation is only supported for Lotus Notes client installations, it is not
supported for the Domino Administrator client or the Domino Designer®.

8 Domino 6 for iSeries Best Practices Guide

1.1.5 LPAR requirements and guidelines
Prior to architecture design, you should carefully plan the functions each Domino partition
and physical iSeries server will provide to the user community.

There are three primary reasons for using OS/400 LPARs:

򐂰 Code stream
򐂰 Isolation
򐂰 Availability

Code stream
Before Domino 6.0.3 and 6.5, when the Domino multi-versioning capability was introduced,
Domino for iSeries did not support multiple versions of the Domino code stream on the same
physical server unless you installed the different versions on separate LPARs. For more
information on the general concepts on multiple versions of Domino on one system prior to
Domino versions 6.0.3 and 6.5, refer to the redbook Coexistence of Multiple Lotus Domino
Releases in an LPAR Environment on the IBM eServer iSeries Server, SG24-6593, which is
available at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246593.html?Open

Multi-versioning itself is not a feature of the Domino server and is not a modification to the
“core” function that is part of the support of Domino server function. How multi-versioning
works is specific to the iSeries implementation for Domino. The support for multi-version
capable releases of Domino is designed to promote flexibility and add value to Domino
implementations for Domino for iSeries customers.

For more information about multi-versioning, please refer to the work-in-progress white paper
entitled Introduction to Multi-versioning Domino for iSeries, which is available at:
http://www.ibm.com/servers/enable/site/domino/downloads/multiversion.pdf

Also see the redbook Lotus Domino 6 for iSeries Multi-Versioning Support on the IBM
eServer iSeries Server, SG24-6940, at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246940.html?Open

Isolation
LPARs may make sense to isolate separate functions, such as these:
򐂰 Multiple Lotus products:
If you plan to run additional Lotus products on your iSeries such as Lotus Instant
Messaging and Web Conferencing (Sametime®), Lotus Team Workplace (QuickPlace®)
or Lotus Domino Document Manager (Domino.Doc®). Some versions of Domino are not
supported in conjunction with these additional products, for example, Lotus Team
Workplace only runs with Domino 5.x versions and the various Lotus Web Conferencing
versions require different Domino 5.x, Domino 6, or Domino 6.5 versions.
For the most recent information, please refer to the Lotus Software for iSeries
Compatibility Guide at:
http://www.ibm.com/servers/eserver/iseries/domino/domino6/releasesupport4up.pdf
򐂰 SMTP mail routing
Will your iSeries be running Domino partitions that require exposure to the Internet? As an
example, if Domino partitions will be running SMTP functions, then — for security
purposes — you may want to consider a separate partition for these Domino servers.
Similar considerations should be made for Extranet based applications.

Chapter 1. Deploying Domino 6 for iSeries 9

 Availability
You can take full advantage of the iSeries inherent hardware reliability and highly available
and scalable disk subsystems to implement a high availability solution with failover
capabilities. You usually implement this on Domino 6 for iSeries by creating a Domino cluster
across multiple LPARs.

Important: Clustering between Domino partitions (subsystems) within the same partition,
or between Domino partitions in separate LPARs, within a single iSeries server, has a
single point of failure. This is the primary partition and the entire system’s common
hardware. We recommend that, where clustering is implemented for true high availability,
you use a separate system, that is similarly configured, as the cluster partner.

Validating your LPAR configuration

The LPAR Validation Tool (LVT) is available to assist you in the design of LPAR systems and
to provide an LPAR validation report that reflects the system requirements while not
exceeding LPAR recommendations. You can find information about the LVT tool at the
following Web site:
http://www.ibm.com/servers/eserver/iseries/lpar/systemdesign.htm

Tip: You should consider all of your LPAR requirements before using the Workload
Estimator. You could invalidate the estimates generated by Workload Estimator if you add
more LPARs to your iSeries after purchasing your hardware since your estimate could not
factor in the additional overhead generated by adding more LPARs.

Resources
The following list of documents related to logical partitioning and Domino provides in-depth
information:
򐂰 Topic: “Plan for logical partitions” on the iSeries Information Center Web site, at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzait/rzaitoverview.htm
򐂰 Redbook Slicing the AS/400 with Logical Partitioning: A How to Guide, SG24-5439, at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG245439.html?Open
򐂰 Redbook LPAR Configuration and Management: Working with IBM ^ iSeries
Logical Partitions, SG24-6251, at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246251.html?Open
򐂰 Planning for Domino on iSeries: Resources, Subsystems, Partitioning, and Clustering by
Thomas Myer and Daniel Hill, at:
http://www.ibm.com/servers/esdd/articles/domino_iseries.html
򐂰 Redbook IBM Lotus Domino 6 for iSeries Implementation, SG24-6592, at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246592.html?Open
򐂰 Redbook Domino for iSeries Domino for iSeries Sizing and Performance Tuning,
SG24-5162, at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG245162.html?Open
򐂰 Also, refer to the chapters related to sizing, Workload Estimator, and performance tuning
in this redbook.

10 Domino 6 for iSeries Best Practices Guide

1.1.6 Domino partitioning planning
Planning your Domino partitioning is critical to building a fault tolerant and robust messaging
and collaboration environment. Careful consideration should be made when planning clusters
between Domino partitions and physical iSeries machines. In addition to the mail Domino
partition topology, it is important to define any other requirements your environment may
have, such as administrative servers, hubs, and SMTP servers, as well as other potential
application requirements such as Lotus Instant Messaging and Web Conferencing
(Sametime). Refer to “Number of Domino partitions” on page 474 for more information.

The example in Figure 1-1 shows a 12 processor iSeries configured with two LPARs. The
primary LPAR has five active Domino servers using nine processors to run the mail
environment. There is one inactive Domino partition used for restores. The second LPAR has
two Domino servers using three processors for the application environment. This example is
one possible configuration. You can create a configuration on your iSeries that fits your
business requirements.

*Prim ary Partion (9 processors) - Mail

*Secondary Partition (3 processors) - LEI, Application and Test

Primary Mail Hub

Restore Application

System LPAR

Figure 1-1 Example Domino partition configuration for mail and applications

Server naming convention

The Domino 6 Administrator Help article entitled “Table of Domino naming requirements”
should be used as a guideline for your Domino environments’ naming convention. Using an
unusual or non-standard naming convention may cause problems in your environment. It is
also a best practice to coordinate your Domino server naming standards with your
organization’s naming standards for servers and DNS entries. Table 1-1 on page 11 is a
sample of a server naming convention.

Table 1-1 Server naming convention example

Server type Location Server function Server number

DOM = Domino server CHI = Chicago M = Mail server 01 = server number

Server types include: Determine an Functions include: Server number by

DOM = Domino abbreviation for each A = Administration Hub location and server
location. B = Backup function
D = Database
H = Hub
M = Mail
AP = Application

Chapter 1. Deploying Domino 6 for iSeries 11

 Thus, here are some examples of server names:
򐂰 DOMCHIM01: Domino Partition for Chicago responsible for Mail
򐂰 DOMCHIB01: Domino Partition for Chicago responsible for Backup

1.1.7 Mail file size

Planning mail file sizes and defining mail retention policies is critical for determining proper
capacity and disk storage for your iSeries, as well as managing a healthy infrastructure. A
large percentage of customers are incorporating a mail file size (or date) restriction and an
archival process for user's mail files. Refer to “Enterprise mail management policy” on
page 58 for more information on this topic.

1.1.8 Indexing
Domino 6 included some major changes to the Global Text Retrieval (GTR) engine used to
build and maintain views and full-text indexes. The new release of the GTR engine in
Domino 6 is 4.1 compared to version 3.4 used in Domino R5. In addition, Domino uses the
NSF buffer manager for memory services, which improves caching and balances memory
between NSF and FT. Furthermore, a new search processor results in closer integration of
text retrieval and significantly faster Boolean processing.

Benefits
Some of the benefits of the new GTR engine are:
򐂰 Performance gains:
– Better handling of booleans
– FTSearch Limit used by engine
– Caching of result data since GTR now uses the Unified Buffer Manager (UBM)
򐂰 Resource utilization improvements:
– Lower indexing memory footprint (6 MB per document limit is gone), GTR memory use
improved, now using Notes Memory Services
򐂰 Capacity:
– Up to 16 terabytes per index (versus 2 gigabytes before)

Planning for full text indexing

Here are some planning considerations for the full text indexing feature in Domino 6:
򐂰 Consider the disk space required to accommodate the full text indexes. For a new Domino
environment, plan for additional 30% to 40% of the size of the databases being full text
indexed.
򐂰 If you use LDAP services, be sure that you have created full-text indexes for your Domino
Directory (if this database can be reached by LDAP searches) or any secondary Domino
Directory present on your servers which are “LDAP enabled.”
򐂰 Understand how the full text indexing of attachments works on the iSeries. Domino for
iSeries uses the Verity KeyView filter for retrieving text from binary attachments. The
supported formats include:
– Adobe Acrobat PDF
– Microsoft Word
– Corel WordPerfect
– Lotus 1-2-3®
– Microsoft Excel

12 Domino 6 for iSeries Best Practices Guide

 – Lotus Freelance Graphics®
– Microsoft PowerPoint
– HTML
– And many others
The default setting enables the Verity KeyView filter. There is a NOTES.INI setting that
allows administrators to shut off the filter without having to change the indexing options on
all databases that have the binary attachment option turned on.
򐂰 Plan what full text indexing options you will use for databases containing encrypted
documents. Users cannot see the contents of an encrypted field without the appropriate
keys, but users can search on information stored in encrypted fields with or without the
appropriate keys. Users can sometimes guess possible values such as $40,000 or
$50.000 for an encrypted salary field.

1.1.9 Third party products

Determining which third party tools, such as virus scanning, content scanning, monitoring
tools, etc., you will be deploying is important for planning scalability and architecture for your
iSeries deployment. Impacts to performance should be noted where third party tools are
required.

Note: If you are moving from a another platform to iSeries, it is important to check whether
or not your current toolset have equivalent ports for the iSeries platform.

1.1.10 SMTP architecture

Planning your SMTP architecture is an important part of your security policy for your Domino
on iSeries deployment because of the exposure that Domino partition will have to the Internet.
For security purposes, it is recommended that you LPAR your SMTP exposure or manage a
dedicated SMTP environment outside of your secured iSeries Domino infrastructure.

Also, it is wise to understand the differences in code streams, especially if you have not
migrated to an R5 SMTP server. The architecture is different between Domino R4.x and
Domino R5/Domino 6.

1.1.11 Services
It is important to plan the services your Domino server will provide since OS/400 and Domino
both provide some of the same Internet protocols. As a result, it is possible to get port
conflicts if not configured correctly. Services such as SMTP, POP3, IMAP, HTTP, and LDAP
need to be configured so that they do not conflict. For more information, please refer to
Installing and Managing Domino 6 for iSeries (i400help.pdf) at:
http://www.lotus.com/ldd/notesua.nsf/0b345eb9d127270b8525665d006bc355/505c677e79adb59100
256c44003288ee?OpenDocument

1.1.12 SSL accelerators

If you are planning heavy, secure HTTP access to your iSeries either for Domino applications
or Domino Web Access (iNotes), it is important to consider performance. One thing you might
consider is using an SSL accelerator product for speeding up transactions for secure Web
access. See the following Web sites for some of the solutions that are available:
http://www.whalecommunications.com
http://www.fineground.com/
http://www.neoteris.com/

Chapter 1. Deploying Domino 6 for iSeries 13

 http://www.redlinenetworks.com/
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzajc/rzajcaccel2058.
htm

1.1.13 Fault tolerance solutions

It is important to plan your fault tolerance and clustering architecture prior to deployment.
How will you cluster servers for users — between LPARs or separate physical servers? You
might want to isolate your clustered servers on separate systems to allow maintenance
cycles to occur on the servers without disrupting user activity.

1.1.14 Backup and recovery requirements

A Domino server often contains important business information that may not exist elsewhere
in your organization. For example, users may rely on e-mail for important communications
that are not documented anywhere else or an on-line customer service application might
contain records that do not exist in printed form.

Consider these four areas when planning for the backup and recovery for your Domino
environment:
򐂰 Determine and document your backup and recovery business requirements
򐂰 Decide what type of transaction logging to use
򐂰 Decide which backup method to use
򐂰 Decide what files to back up

We discuss these areas in detail in Chapter 5, “Backup and recovery of Domino 6 for iSeries:
Concepts” on page 243 in this book.

Backup and recovery planning tips

The following tips are provided to help you decide upon your backup and recovery strategy:
򐂰 Consider recovery time and effort as well as backup time when choosing a strategy.
򐂰 Consider integrating your Domino and iSeries backups into your enterprise backup and
restore strategy if you already have one in place. This enables the Domino and iSeries
teams to take advantage of enterprise economies of scale.
򐂰 Be sure you understand how the different backup options affect the availability of Domino
resources to your users. Some OS/400 SAVE commands for example require that you
end all subsystems running Domino servers before starting the backup job.

Resources
You may find the following documentation helpful when planning and setting up your Domino
backup and recovery strategy:
򐂰 Chapter 17, “Managing Backup and Recovery” from Installing and Managing Domino 6 for
iSeries (i400help.pdf).
򐂰 For information about planning a backup strategy for your iSeries server, see the manual
Backup and Recovery, SC41-5304. If you are new to the iSeries, also see the descriptions
of using the Save menu and using the SAVxxx and RSTxxx commands. This book comes
with your OS/400 software. It is also available in the iSeries supplemental manual library
in the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c4153046.pdf

14 Domino 6 for iSeries Best Practices Guide

1.1.15 Domino Directory structure
The support for directory synchronization between the OS/400 System Distribution Directory
(SDD) and the Domino Directory was removed with Domino 6 for iSeries. You can deploy a
similar solution in Domino 6 by having SDD publish information to an iSeries LDAP server.
Then set up your Domino Directory to use the iSeries LDAP directory. Setting up a regular
replication schedule provides a similar solution to the former directory synchronization
support.

Tip: With OS/400 V5R1 or later, system directory services (LDAP) is always started by
default when TCP is started. It automatically binds to port 389 on all configured IP
addresses. This can cause a port conflict when you start up a Domino server that runs the
LDAP task. You have several configuration options to prevent this from happening. For
more information, see the following Web site:
http://www.ibm.com/eserver/iseries/ldap

The iSeries platform is ideal for implementing the new centralized directory architecture in
Domino 6. The extremely fast internal connections between servers on an LPAR or between
LPARs enables spoke or mail servers to use configuration directories.

Resources
These documents provide additional information:
򐂰 For more information on setting up and using a centralized directory with Domino, see the
topic “Planning a central directory architecture for a domain” in the Domino 6 Administrator
Help database.
򐂰 Refer to Chapter 19, “Setting Up the Domino Directory” in Administering the Domino
System, Volume 1 available at:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument

1.1.16 File directory structure

We recommend giving the data directory the same name as the Domino server, particularly if
you plan to have multiple Domino servers on the same iSeries server. This makes it easy to
identify which data directory belongs to which Domino server. Grouping all these Domino
server data directories as subdirectories under one directory (/domino/ in our example)
makes it easy to locate the Domino server data directories and collectively back up or restore
these directories.

The default naming convention for the data directory in the Domino Server Setup wizard is
/domino/servername/data. If you want to shorten the directory path, you can specify the path
as /domino/dominoservername. The /data directory is not really necessary, but you can keep
the full default path to be consistent with the configuration defaults when using the Domino
Server Setup wizard if you prefer.
Example: /domino/domsvr1/data

For additional considerations regarding IFS and performance, refer to “Integrated File System
(IFS)” on page 218 and to “Mapping drives to the iSeries IFS” on page 33.

Chapter 1. Deploying Domino 6 for iSeries 15

1.1.17 Transaction logging
Transaction logging provides added reliability and availability to server data. It does this by
writing all database changes in a special format to a transaction log file in addition to storing
those changes in memory. These changes are later made to the appropriate databases. This
gives you:
򐂰 Faster database recovery and better server availability in the event of a crash without data
loss.
򐂰 Backup solutions that allow you to restore a database to the last database update.
򐂰 Improved responsiveness on your servers while providing more thorough disaster
recovery by exploiting Domino 6 transaction logging (and its new view logging feature).
Enhanced logging, along with other Domino 6 performance improvements, helps increase
the number of users supported by each of your servers. This is an excellent way to
decrease your organization's total administrative and equipment costs.

Transaction logging checklist

Use this checklist for your transaction logging planning:
1. Allocate space for the log files. On the iSeries, it is not required to use a dedicated,
mirrored device, but you need to plan for extra disk space since the extent (TXN) files can
occupy up to 8 GB of space for each Domino server.
2. Plan a backup strategy. We recommend that you archive the transaction logs daily using
incremental backups. Schedule weekly full database backups. You will then be prepared if
you have a media failure.
3. Decide which servers and databases will use transaction logging. Transaction logging is
available for servers running Domino 5 and later. Consider enabling transaction logging for
all databases on the server, except for high transaction system databases like
MAIL.BOX(es), LOG.NSF and DOMLOG.NSF. You will need to disable transaction logging
each time the Domino server creates these databases.
4. Select a Domino-compatible backup utility. The utility must be able to use the backup and
recovery methods of the Domino C API Toolkit (Release 5 or later).
5. Choose the logging style that fits your needs: archived, circular, and linear
6. Set up a Domino server for transaction logging.

Resources
These resources can help you with planning and setting up transaction logging for your
environment:
򐂰 Chapter 55, “Transaction Logging and Recovery” in Administering the Domino System,
Volume 2, Lotus software documentation, available at:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument
򐂰 The paper “Why you need Transactional Logging” describes the benefits of transaction
logging. It is available at the following Web site:
http://www.lotus.com/ldd/notesua.nsf/572150f5ef0dfb1385256cb8005224be/ffa56f8938579a
4585256d2b005bbd6c?OpenDocument
򐂰 “Assessing the impacts of new transaction logging features” by Jim Powers on LDD Today:
http://www.lotus.com/ldd/today.nsf/aa2db969526197dd85256b56004e5a7b/c7632f2b5dbbd265
85256b9d0072b9fb?OpenDocument
򐂰 “More on Domino 6 transaction logging” by Jim Powers on the LDD Today Web site at:

16 Domino 6 for iSeries Best Practices Guide

 http://www.lotus.com/ldd/today.nsf/Lookup/More_D6_Trans_Logging?OpenDocument

1.1.18 Policy-based system administration

We recommend that you establish and maintain standard settings and configurations using
the policy-based administration features in Domino 6. Policies can also automate redundant
administrative tasks. Policy documents in Domino 6 include:
򐂰 Archive settings document to create and to modify a set of rules that define how
documents are selected and archived.
򐂰 Desktop settings document to dynamically update desktop settings and configurations for
users, including custom Welcome pages.
򐂰 Registration settings document to register users with the same settings.
򐂰 Setup settings document to define first-time user setup configurations.
򐂰 Security settings document to manage passwords and administer Execution Control Lists
(ECLs.)

In the planning phase, determine these policies:

򐂰 Create organizational policies to assign settings to all users in specific organizational
units.
An organizational policy automatically applies to all users registered in a particular
organizational unit. If you move a user within the hierarchical structure — for example,
because the user transfers from the Sales department to the Marketing department — the
organizational policy for the corresponding certifier ID is automatically assigned to the
user. The new policy settings become effective the first time users authenticate with their
home server.
򐂰 Create explicit policies to assign settings to individual users or groups.
An explicit policy assigns default settings to individual users or groups. For example, to set
a six-month certification period for contract workers in all departments, create an explicit
policy and then assign it to each contract employee or to the group that includes all
contract employees.
There are three ways to assign an explicit policy:
– During user registration
– Editing the user's Person document
– Using the Assign Policy tool

You can also assign an exception attribute to either an organizational or explicit policy. You
use an exception to allow the user to override a policy setting that is otherwise enforced
throughout an organization. When you create an exception policy, you specify only the
settings that will not be enforced. Then when you assign the exception policy, it exempts
users from enforcement of those settings only.

Exception policies are a way to give someone in an organization special treatment, possibly
because of their position or job requirements, for example, those employees who need to
exceed the organizational Registration setting that enforces a mail database quota of 60 MB.

We recommend using exceptions sparingly because exception policies defeat the

enforcement of policy settings. We recommend creating explicit policies for small groups with
special business requirements as a best practice.

Chapter 1. Deploying Domino 6 for iSeries 17

 Tip: Use the policy viewer tool in the Domino 6 Administrator client to view the settings for
each policy, the settings by functional area, or the settings assigned to a specific users.
You can also view effective policies on different levels in the policy hierarchy, which helps
you to understand the impact of changing a policy setting. The policy viewer tool is on the
People and Groups tab in the Domino 6 Administrator.

Resources
For more information on policies, refer to the following resources:
򐂰 Topic "Policies" in Domino 6 Administrator Help
򐂰 Chapter 9, “Using Policies” in Administering the Domino System, Volume 1
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument
򐂰 LDD article entitled Policy-based system administration with Domino 6 by Bob Balfe and
Dick McCarrick found at:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/d78ede75b351cf81
00256be9005b7d35?OpenDocument&Highlight=0,internet,site

1.2 Hardware
This section includes a basic hardware planning checklist, setup guidelines and special
considerations for the iSeries.

1.2.1 Hardware planning

Hardware planning is a very important part of your Domino environment. You should consider
your immediate needs as well as anticipate the growth requirements of your organization.
Refer to Chapter 10, “Sizing tips and techniques” on page 455 for sizing guidelines and
Chapter 11, “Using the IBM Eserver Workload Estimator” on page 463 for information on
using the IBM Eserver Workload Estimator to determine the right hardware for your
implementation. You need the output from these tools to start the rest of your planning
process. Use the server specifications from the Workload Estimator to complete the rest of
the checklist. For step by step instructions, please refer to the “Plan for hardware and
software” section on the iSeries Information Center Web site at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Hardware planning checklist

Hardware planning for the iSeries is thoroughly addressed in several sources. Please refer to
the iSeries Information Center for more information. We recommend using the checklist below
as a guide for planning and documenting your Domino for iSeries environment:
򐂰 Server specifications:
– Specific model and configuration of the server
򐂰 Hardware specifications:
– Expansion units, migration towers, advanced servers, and racks
– Removable media storage devices
– Display stations
– Printers
– Communication controllers, hubs, routers, and modems

18 Domino 6 for iSeries Best Practices Guide

 򐂰 Location considerations:
– Computer room floor plan
– Physical security
– Raised floors
– Stacking units
– Size and weight considerations
– Service clearances
– Sample site plan
– Packaging dimensions
򐂰 Power:
– Know your server power requirements
– Know your compatible hardware requirements
– Know your uninterruptible power supply (UPS) needs
򐂰 Cables:
– Have your server order and your existing system information available for reference
– Have an idea of your cabling requirements and site layout
– Determine your cabling needs, for example ASCII, twinaxial, Operations Console,
modem, optical, Ethernet, High-speed link (HSL)
򐂰 Environment:
– Acoustics
– Air quality
– Altitude
– Bonding to a signal reference grid (SRG)
– Earthquake environments
– Electromagnetic interference
– Environmental requirements
– FCC emissions statement
– Floors
– Humidity
– Lighting
– Neutral-to-ground voltage
– Physical security
– Raised floors
– Stacking units
– Temperature

1.2.2 Special considerations

Though the overall installation process is similar, there are special considerations for
upgrading existing iSeries hardware, when migrating to an iSeries server from a different
iSeries server, or when consolidating Domino servers from multiple platforms to the iSeries.

Upgrading existing iSeries hardware

We define an upgrade as the target server retains the same serial number as the source
server. You can upgrade from one IBM iSeries server, hardware feature, or OS/400 release
to another iSeries server, hardware feature or OS/400 release. For more information about
upgrading your existing iSeries hardware, refer to the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Chapter 1. Deploying Domino 6 for iSeries 19

 Migrating from a different iSeries
A data migration is the process of moving data from one server to another. Be aware that
there are OS/400 versioning issues to consider for migration. For details, see the Lotus
Software for iSeries Compatibility Guide at:
http://www.ibm.com/servers/eserver/iseries/domino/domino6/releasesupport4up.pdf

Also refer to the iSeries Information Center Web site for information about planning and
performing your migration.

Consolidating Domino servers to the iSeries

At its core, server consolidation is an enabling technology encompassing not just hardware,
but software, services and, most importantly, the systems management disciplines and best
practices to optimize and simplify your existing information technology infrastructure.

You can contact your Lotus representative or ISSL Sales Specialist for documented
approaches for preparing or organizing your consolidation effort.

The best online resource we found on this topic is Appendix A, “Consolidation” in the redbook
Upgrading to Lotus Notes and Domino 6, SG24-6889.

For more information about iSeries consolidation solutions, see the Server Consolidation
solutions Web site at:
http://www.ibm.com/servers/eserver/iseries/scon/

Dedicated Server for Domino, iSeries for Domino (DSDplus)

Prior to V5R2, the Dedicated Server for Domino (DSD) iSeries servers only had the ability to
be upgraded within the DSD model line. This is no longer true for the 820 DSD 4-way
processor, which can now be upgraded to a base 830 or 840 processor. This allows larger
Domino users to scale even further without having to purchase a new iSeries server. Domino
server consolidations from multiple Intel® boxes to one iSeries server are taking place, so
this new upgrade option is a welcome choice. More information can be found at the
Dedicated Server for Domino Web site at:
http://www.ibm.com/servers/eserver/iseries/domino/dsd1.html

Also, specially priced 810 and 825 models called iSeries for Domino are now available. To
qualify for the special price, these configurations require the purchase of certain Lotus
software (One Domino server license plus x Lotus Notes clients — depending on the model).
For more information, see the iSeries for Domino Web site at:
http://www.ibm.com/servers/eserver/iseries/domino/is4domino.html

We recommend that you evaluate the availability of system upgrades for any DSD/DSDplus
server whether you purchase it new or used.

1.3 Software installation guidelines and resources

You should plan and document your Domino installation as thoroughly as your environmental
planning. This section contains a compilation of information found in several different
documents from several sources. You can use this as a reference to obtain the information
you need to install Domino 6 for iSeries.

We address the following areas in this section:

򐂰 OS/400 and program temporary fixes prerequisites

20 Domino 6 for iSeries Best Practices Guide

 򐂰 Basic install
򐂰 Installation best practices
򐂰 iSeries Access for Windows and iSeries Navigator tips and tricks

1.3.1 OS/400 and program temporary fixes prerequisites

Before loading any software, you should verify that your iSeries meets at least the minimum
hardware requirements to run Domino 6. If you use the Workload Estimator and sizing tips
and techniques in this redbook, this should not be an issue.

You should then determine what iSeries software to install, including the current program
temporary fixes (PTFs). A PTF on the iSeries is similar to a service pack on the Windows
platform. You can install PTFs as individual fixes or as cumulative fixes known as group
PTFs. Refer to the following Web site for common questions and answers related to
preventive maintenance on the OS/400 Operation System and Domino:
http://www.ibm.com/servers/eserver/iseries/domino/domptfgi.htm

Whether or not you are upgrading from a previous release of OS/400 and Domino or installing
Domino 6 for the first time on your iSeries, please refer to the iSeries Support Recommended
fixes Web site for the most recent information:
http://www-912.ibm.com/s_dir/slkbase.nsf/recommendedfixes

If you are upgrading from a previous release of Domino for iSeries, you should also verify that
you can upgrade to Domino 6 and V5R2 from your current version of Domino and OS/400.
You can find this information on the Domino 6 for iSeries system requirements Web site at:
http://www.ibm.com/servers/eserver/iseries/domino/domino6/sysreqs.html

For example, administrators running OS/400 V5R2 on their iSeries servers must upgrade
from Domino for iSeries 5.0.8 or above (or 5.0.9 or above for users running Domino for
iSeries on an iSeries i890 server).

OS/400 requirements
Here is a list of the software requirements for running Domino 6 for iSeries. Again, please
check the iSeries Support Recommended fixes Web site for the most recent information.
򐂰 IBM Operating System/400® (OS/400®), 5722-SS1, Version 5 Release 1 or higher with
the latest PTFs applied.
򐂰 OS/400 — Host servers, 5722-SS1 option 12.
򐂰 TCP/IP Connectivity Utilities for iSeries, 5722-TC1.
򐂰 IBM Developer Kit for Java™, 5722-JV1 plus the 1.3 JDK option for 5722-JV1, which is
option 5.
򐂰 OS/400 — QShell Interpreter, 5722-SS1 option 30.

Note: It should be observed that the scope of this book is Domino 6 for iSeries running on
OS/400 V5R2. Please check the Domino 6 for iSeries Web site for information on Domino
6 and OS/400 compatibility at:
http://www.ibm.com/servers/eserver/iseries/domino/domino6/

PTF requirements
Here is the current list (January 2004) of individual and group PTFs required for Domino 6 for
iSeries. For the most recent PTF requirement information, please refer to:
http://www.ibm.com/servers/eserver/iseries/domino/support/ptf.htm#v5r2

Chapter 1. Deploying Domino 6 for iSeries 21

 Individual PTFs
򐂰 Product: 5722-SS1, OS/400:
– SI06611: OSP-UNPRED Errors after multiple readlink() calls
– SI05952: JVA-RUN-INCORROUT JDBC classes incompatible with JDK 1.1.8
– SI06410: OSP-QZRUIDTF, unable to display file with incorrect CCSID
򐂰 Product: 5722-DG1, IBM HTTP Server for iSeries:
– SF99098:IBM HTTP Server for iSeries V5R2 group PTF
– SI06002: HTTPSVR — Domino Apache plug-in for Domino 6
– SI06368: HTTPSVR — Add support for Domino 6
򐂰 Domino Maintenance Updates (MUs):
Fix packages for Domino are called Maintenance Updates (MUs). Domino for iSeries MUs
are typically distributed as OS/400 PTFs. These PTFs can be obtained via Web download
or ordered on the phone. For more information, see the Lotus Domino Critical Fix Packs
Web site at:
http://www.ibm.com/servers/eserver/iseries/domino/support/cfp/index.htm

Group PTFs
A group PTF is a single PTF order number that provides a logical set of PTFs affecting a
specific function. Information on all group PTFs by release can be found at the Preventive
Service Planning Web page at:
http://www-912.ibm.com/s_dir/sline003.NSF/ALLPSPBYREL?OpenView&Start=1&Count=30&Collapse
=1#1
򐂰 DB2/400 Group PTF:
If you are moving data between DB2/400 and Domino, it is suggested that you order the
latest DB2/400 Group PTF that is available for your OS/400 release. More information is
available at the IBM Software Technical Document — DB2/400 Group PTF Information
Web site:
http://www-912.ibm.com/s_dir/slkbase.nsf/4086d1dc7efffb0a862565d80076c024/e1bfadb199
55c444862565c2007ceabe
򐂰 Java Group PTF:
If you are using Java, it is suggested that you order the latest Java Group PTF. See the
Preventive Service Planning Web page noted above for more information about the
availability of iSeries group PTFs.
򐂰 IBM HTTP Server for iSeries Group PTF:
If you are using the IBM HTTP Server (original with Domino R5 or powered by Apache
with Domino 6) it is suggested that you install the latest HTTP Group PTF. See the
Preventive Service Planning Web page noted above for more information about the
availability of iSeries group PTFs and refer to the HTTP Server (powered by Apache)
plug-in for Domino 6 on iSeries Web page for specific PTFs that are required:
http://www.ibm.com/servers/eserver/iseries/domino/apache.html#requiredptfs
򐂰 BRMS Group PTF:
If you are using Backup, Recovery, and Media Services for iSeries (BRMS), it is
suggested that you order the latest BRMS Group PTF that is available for your OS/400
release. See the Backup and recovery solution Group PTFs Web page for additional
information:
http://www.ibm.com/servers/eserver/iseries/service/brms/group.htm

22 Domino 6 for iSeries Best Practices Guide

1.3.2 Basic install
This section is a summary of the basic install tasks for Domino 6 for iSeries. It assumes that
the iSeries configuration, including LPARs, and current software updates is complete. It
identifies several sources containing pertinent information and directs you to the most helpful
excerpts of each source. The resources for this section include:
򐂰 Installing and Managing Domino 6 for iSeries
http://www.lotus.com/ldd/notesua.nsf/0b345eb9d127270b8525665d006bc355/505c677e79adb5
9100256c44003288ee?OpenDocument
򐂰 The IBM Redbook, IBM Lotus Domino 6 for iSeries Implementation, SG24-6592
򐂰 Lotus Notes, Domino, and Domino Designer Release Notes 6.0.2
http://www.lotus.com/ldd/doc/domino_notes/6.0.2/readme.nsf
򐂰 Knowledge Collection: Domino 6 for iSeries, Reference #7002762
http://www.ibm.com/support/docview.wss?rs=203&q=domino+6+install+iseries&uid=swg2700
2762&loc=en_US&cs=utf-8&lang=en
򐂰 Lotus provides assistance for customers and business partners who are installing Domino
for iSeries for the first time. Refer to the First Install Customer Assistance Web site at:
http://www.ibm.com/servers/eserver/iseries/domino/support/fica.htm

1.3.3 Installation best practices

Before installing Domino for iSeries, you should read Chapter 3 “Installing Domino on your
iSeries server” from the manual Installing and Managing Domino 6 for iSeries. This chapter
describes the special authorities needed by your OS/400 user profile, and the necessary
steps to verify the installation. The following topics are covered in this section:
򐂰 iSeries authorities required for installing Domino
򐂰 Installing the code
򐂰 Installation tips and tricks

iSeries authorities required for installing Domino

Here is a summary of the authorities you need to install Domino 6 for iSeries:
򐂰 To install the Domino software, your user profile must have the following special
authorities:
– All object access (*ALLOBJ)
– Security administration (*SECADM)
򐂰 To configure a Domino server, your user profile must have the following special
authorities:
– All object access (*ALLOBJ)
– System configuration (*IOSYSCFG)
– Job control (*JOBCTL)
– Security administration (*SECADM)

We recommend temporarily assigning the authorities needed for installation and

configuration to one or two members of the Domino administration team. The Domino
administration team uses the special authorities for installation and configuration tasks, then
relinquishes the authorities after completing the tasks.

Chapter 1. Deploying Domino 6 for iSeries 23

 Installing the code
Installing Domino 6 for iSeries is much simpler than previous versions of Domino for iSeries.
Table 1-2, from the IBM Redbook, entitled IBM Lotus Domino 6 for iSeries Implementation,
SG24-6592, lists the three ways to install. Refer to the appropriate section of that redbook for
more details as listed in the “Redbook section” column below.

Table 1-2 Domino 6 for iSeries installation methods

Method Invoked from Media Recommendation Redbook
(when to use) section

Domino Server - iSeries Navigator CD located in Recommended Section 3.3,

Installation - EZ-Setup either iSeries “InstallShield”
wizard - setup.exe or local PC Required if doing on page 50
workstation remote installation
CD-ROM drive (CD in PC workstation
CD-ROM drive)

Uses InstallShield

LODRUN OS/400 CL CD located in Section 3.2,

command iSeries “LODRUN” on
CD-ROM drive page 41

RSTLICPGM OS/400 CL OS/400 save Required if installing Section 3.5,

command file (SAVF) from OS/400 save “RSTLICPGM”
files on page 69

Note: The licensed product number for Domino 6 for iSeries changed to 5733-LD6.
Domino 6.5 for iSeries uses product number 5733-L65. The licensed product code for
Domino R5 for iSeries was 5769-LNT.

CD versus file
If you feel more comfortable using a GUI interface, then follow the recommended installation
method of using the Domino Server Installation wizard. The CD installation takes longer than
the RSTLICPGM installation method since the installation files are decompressed on the fly,
then transferred from the PC workstation to the iSeries during the installation.

If you feel comfortable using the RSTLICPGM installation method, it will be faster, since the
save files are decompressed before you install and they already reside on the iSeries (you
have to transfer the files via FTP to the iSeries prior to installation). Install instructions can be
found in the readme1st.pdf file. You will need to run the RSTLICPGM command twice, once
for the *BASE code and once for option 1 (C API toolkit). There are only two save files for
Domino 6 for iSeries compared to seven for Domino R5 for iSeries.

Attention: Starting with Domino for iSeries 6.0.3 and 6.5.0 it is possible to install and run
multiple versions of Domino on one iSeries system or LPAR. Installing these multi-version
capable releases of Domino for iSeries requires the installation of an additional “product
option” — which is the actual Domino version code. Please refer to the redbook Lotus
Domino 6 for iSeries Multi-Versioning Support on the IBM eServer iSeries Server,
SG24-6940 for detailed information on how to install multi-version capable Domino
releases.

A guideline is 30 to 180 minutes for a basic install. The actual installation time will vary
depending on the hardware resources available on your system and the method of installation
you choose.

24 Domino 6 for iSeries Best Practices Guide

Installation tips and tricks
Here are some tips and tricks for your Domino for iSeries installation:
򐂰 Tip: Remove beta or pre-release versions. Before installing the Domino 6 software, you
must remove any beta or pre-release versions. To remove the beta or pre-release version,
make sure all Domino servers are stopped and no users are running any Domino
commands (such as WRKDOMSVR), then enter the following OS/400 command:
DLTLICPGM LICPGM(5733LD6)
򐂰 Tip: Don’t be surprised by the length of time the installation takes. Be patient. You can
monitor the RSTLICPGM program using the WRKACTJOB command to verify if it is
running correctly. You will see a status update on the bottom left hand side of your
emulator window.
򐂰 Tip: In releases prior to Domino 6 for AIX®, Solaris, Linux, iSeries and zSeries®
platforms, the clock type used by the Domino server defaulted to the 12 hour format. On
Domino 6, the default clock type is inherited from the operating system date/time format
configuration. The Domino 6 server inspects a locale keyword named “d_t_fmt” in a
category “LC_TIME” to decide the default clock type. As a result, you might see the time
format used by the Domino server has changed to a different format after upgrading. You
can use the NOTES.INI setting “ClockType=12_HOUR” or “ClockType=24_HOUR” to
override the system default clock type.
򐂰 Trick: You can schedule a batch job to install Domino 6 for iSeries. For details on how to
perform a batch installation, refer to Appendix B “Installing Domino in batch mode” in
Installing and Managing Domino 6 for iSeries. You can find this document on the Lotus
Documentation Web site at:
http://www.lotus.com/ldd/notesua.nsf/0b345eb9d127270b8525665d006bc355/505c677e79adb5
9100256c44003288ee?OpenDocument

Important: Appendix B “Installing Domino in batch mode” in the document Installing

and Managing Domino 6 for iSeries contains incorrect syntax in one of the steps. An
additional set of single quotation marks are needed in the command string for this to
work properly. The following is the correct command string for Step 3 in the section
“Remote batch installation using the remote CD-ROM drive”:
RUNRMTCMD CMD('LODRUN DEV(*OPT) DIR(''/os400/intleng/batch/ent'')')
RMTLOCNAME(remote-name *ip) RMTUSER(myuserid) RMTPWD('password')

Domino 6.0.3, Domino 6.5 and higher: The Domino library structure for multiversion
capable Domino releases has changed. You might need to take this into consideration
when doing a remote or batch installation. For more information please see “Future
release changes” on page 247.

򐂰 Trick: You receive message “Option *Base not restored” on your 5250 workstation
emulation console.
– If you have Domino servers already installed on this LPAR or iSeries (not partitioned),
verify that all Domino servers have been stopped. The RSTLICPGM command will not
work if one or more Domino servers are running.
Resolution: Stop all Domino servers, then issue the command again.
– Another possible reason for this error message is that the save files could have been
damaged unexpectedly when transferred to the iSeries.
Resolution: Transfer the save files to the installation directory again, then reissue the
RSTLICPGM command.

Chapter 1. Deploying Domino 6 for iSeries 25

 򐂰 Trick: You receive message “Object has a signature that is no longer valid” in the
RSTLICPGM job log.
This is likely the result of installing Domino to a system that has the more stringent levels
of object signature validation enabled for restore operations.
Resolution: When installing Domino for iSeries on OS/400 V5R1 or later, the system value
QVFYOBJRST must be set to a value of 3 or lower prior to installing Domino. After
installation of Domino for iSeries has completed, the system value may be changed back
to a more restrictive setting. An example of changing the system value QVFYOBJRST is
provided here:
CHGSYSVAL SYSVAL(QVFYOBJRST) VALUE('1')
򐂰 Trick: Message LNT0993 will be issued as follows: “Option 1 not valid for the current
release of the product”.
Most of the installation options and their related directory paths were changed in
Domino 6. However, for upward compatibility of CL programs that use the LODRUN
command for batch installations, this command still syntactically allows you to specify
previous Domino R5 directory paths. The LODRUN command will not fail but will ignore
the incorrect specified option for installation.
Resolution: The Domino 6 installation paths to be used in batch mode can be found in
Appendix B "Installing Domino in batch mode" of the document Installing and Managing
Domino 6 for iSeries.
򐂰 Trick: Identification of Language Pack installs during Domino install.
When installing or upgrading the Domino product onto an iSeries server where Language
Packs have already been installed, the process replaces the translated templates with
English templates. If a Language Pack already exists on your server when you issue the
LODRUN command, the message in Example 1-1 appears in the job log:

Example 1-1 LODRUN job log example

ONE OR MORE NON-ENGLISH LANGUAGE VERSIONS OF DOMINO FILES WERE PREVIOUSLY
ADDED TO THIS SYSTEM USING THE LOTUS DOMINO LANGUAGE PACK INSTALLER.
INSTALLATION OF THIS ENGLISH VERSION OF DOMINO WILL OVERWRITE THE
NON-ENGLISH VERSIONS OF THE DOMINO FILES. IF THE NON-ENGLISH LANGUAGE
VERSIONS ARE REQUIRED, THE LOTUS DOMINO LANGUAGE PACK INSTALLER NEEDS TO
BE USED TO REAPPLY THEM AFTER THIS INSTALLATION COMPLETES.

Resolution: Once the LODRUN command has completed, you will need to reapply the
Language Pack for your preferred language for the release of Domino you just installed.

Important: If you have a Domino server with a language pack installed and your
environment requires this language support, do not upgrade Domino until language
packs for that Domino release are available.

1.3.4 iSeries Access for Windows and iSeries Navigator tips and tricks
This section describes new features in iSeries Navigator and iSeries Access for Windows as
they apply to best practices for Domino for iSeries. We also include some tips and tricks for
beginning, intermediate, and experienced administrators.

26 Domino 6 for iSeries Best Practices Guide

 Note: In V5R2, the iSeries Client Access Family was renamed to the iSeries Access
Family and Operations Navigator is now called iSeries Navigator. For more information,
refer to the iSeries Access Web site at:
http://www.ibm.com/servers/eserver/iseries/access/

You can use iSeries Navigator to graphically manage both your iSeries server and the
Domino servers (as well as IBM Lotus Team Workplace (QuickPlace) servers) configured on
your iSeries from a Windows workstation. Through the Domino for iSeries support in iSeries
Navigator, you can:
򐂰 View the status of all Domino servers on your iSeries server.
򐂰 Use the context menu (right mouse button) to perform administrative tasks on a Domino
server, such as starting and stopping the server, determining the properties of a server,
and changing the NOTES.INI file for the server, and more.

More information can be found in section 2.2.3 “iSeries Access for Windows” of the redbook
IBM Lotus Domino 6 for iSeries Implementation, SG24-6592.

New features in iSeries Access for Windows

The iSeries Access for Windows, previously called “Client Access Express for Windows” in
V5R1 and earlier OS/400 releases, offers an all-inclusive client solution for accessing and
using resources from your Windows desktop over a TCP/IP connection. It includes 5250
emulation, access to DB2 Universal Database™ (UDB) for iSeries through its Data Transfer
function, and utilizes iSeries NetServer for working with the OS/400 integrated file system
(IFS) and printers. It also includes iSeries Navigator, the OS/400 GUI, for administering
iSeries and AS/400 servers.

New features in V5R2 include:

򐂰 New version of Personal Communications 5250 emulator (V5.5)
򐂰 Support for Windows XP (also available via PTF for V5R1)
򐂰 Kerberos server authenticates, eliminates sign-on
򐂰 Enhancements to database access
򐂰 iSeries Access for Web and Host Publisher now run on WebSphere Application Server V4

For more information, refer to the iSeries Access for Windows Web site at:
http://www.ibm.com/servers/eserver/iseries/access/expresslinks.htm

New features in iSeries Navigator

There are several new features in the V5R2 iSeries Navigator tool, including easier
installation of plug-ins, and updated Domino and BRMS plug-ins. Other V5R2 enhancements
are found in performance management related areas, for example, the significant new
function of graphically displaying performance data as part of the Performance Tools for
iSeries plug-in. Here is a list of the enhancements:
򐂰 System Status — Equivalent of WRKSYSSTS command
򐂰 System monitor enhancements — New monitors
򐂰 Collection Services enhancements
򐂰 Performance Tools for iSeries as a plug-in
򐂰 PM/400 in V5R2

For more information, refer to the iSeries Navigator Web site at:
http://www.ibm.com/servers/eserver/iseries/navigator/index.html

Chapter 1. Deploying Domino 6 for iSeries 27

 Additional information can also be found in Appendix D of the redbook Managing OS/400
with Operations Navigator V5R1 Volume 5: Performance Management, SG24-6565 available
at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/sg246565.html

Installation of plug-ins
An iSeries Navigator plug-in is a separately installable component of iSeries Navigator that
may be installed on your workstation. To install any plug-ins, you must start iSeries NetServer
on your iSeries and share the iSeries integrated file system (IFS) folder where the iSeries
Navigator code containing the plug-ins is installed. See section 3.6 entitled “Installing the
iSeries Navigator Domino plug-in” in IBM Lotus Domino 6 for iSeries Implementation,
SG24-6592.

To install iSeries Navigator plug-ins, click the Install Plug-ins link on the bottom right hand
corner of the iSeries Navigator window. This displays the Install Plug-ins dialog window
where you can select the server from which to install the plug-ins.

Important: A plug-in may require a certain minimum level of OS/400 and a specific
licensed program to be installed on your iSeries before it will appear in the list of supported
plug-ins. Refer to the Help Topics in iSeries Navigator for more information.

For the current list of available plug-ins, go to the iSeries Navigator Available Plug-ins Web
site at:
http://www.ibm.com/servers/eserver/iseries/navigator/availplugins.html

Domino plug-in
The Domino plug-in is needed if you want to manage your Domino environment using iSeries
Navigator. Installing the plug-in adds folders and objects to the hierarchy tree, choices to
menus, and additional property pages to the property sheet for a folder or object in iSeries
Navigator.

You can install the Domino plug-in after installing iSeries Navigator on your workstation and
installing the Domino software on your iSeries. You can then perform the following tasks
using iSeries Navigator:
򐂰 Configure Domino for iSeries servers
򐂰 Access Domino for iSeries server properties
򐂰 Start and stop Domino for iSeries servers
򐂰 Launch the Domino Administrator client
򐂰 Register Domino users
򐂰 View or modify a Domino server’s NOTES.INI file

Tip: Although the Domino plug-in is installed as a subcomponent of iSeries Navigator, it is

delivered via the Domino for iSeries CD. You should update the Domino plug-in to the latest
version every time you install a new release of Domino onto your iSeries server.

For more information, refer to the article entitled “Operations Navigator on iSeries...and why
it's good for Domino” by Thomas Myer and Daniel Hill at:
http://www.ibm.com/servers/esdd/articles/opsnav/index.html#8

You can also refer to section 3.6, “Installing the iSeries Navigator Domino plug-in” in the
redbook IBM Lotus Domino 6 for iSeries Implementation, SG24-6592.

28 Domino 6 for iSeries Best Practices Guide

BRMS plug-in
The BRMS iSeries Navigator client, a graphical user interface that plugs into iSeries
Navigator, was introduced in V5R1 and further enhanced in V5R2. With the BRMS plug-in
you can manage BRMS operations, across several systems, from a single Windows desktop.

For more information, refer to the BRMS graphical user interface Web page at:
http://www.ibm.com/servers/eserver/iseries/service/brms/brmsplugin.htm

Tips and techniques for using the BRMS iSeries Navigator client can be found here:
http://www.ibm.com/servers/eserver/iseries/service/brms/plugintips.htm

The BRMS graphical user interface student guide is available at:

http://www.ibm.com/servers/eserver/iseries/service/brms/pluginguide.htm

Getting started with iSeries Navigator

The previous section described the many features available through the Domino or BRMS
plug-ins for iSeries Navigator, but how do you get started? Here are step-by-step instructions
for displaying your Domino servers and BRMS features in iSeries Navigator.

These are the steps to display your Domino servers in iSeries Navigator:
1. Open iSeries Navigator. Create a connection to your iSeries server if you have not already
done so. If you have multiple LPARs on your iSeries, create a connection to each LPAR.
2. Click the iSeries server or LPAR name to expand the list of options. iSeries Navigator will
probably prompt you for your iSeries user ID and password at this point.
3. Click Network.
4. Click Servers.
5. Click Domino.
6. You will see a list of your Domino servers in the right hand pane of iSeries Navigator as
shown in Figure 1-2.

Figure 1-2 List of Domino servers in iSeries Navigator

Chapter 1. Deploying Domino 6 for iSeries 29

 7. Right-click any of the Domino servers for a menu of tasks you can perform as shown in
Figure 1-3.

Figure 1-3 iSeries Navigator — Domino plug-in context menu

8. Select the task you want to perform, such as starting or stopping a Domino server, viewing
the Domino server Properties or selecting the Server Administration option to open the
Domino 6 Administrator client.

Here are the steps to display the BRMS features in iSeries Navigator:
1. Open iSeries Navigator. Create a connection to your iSeries server if you have not already
done so. If you have multiple LPARs on your iSeries, create a connection to each LPAR.
2. Click the iSeries server or LPAR name to expand the list of options. iSeries Navigator will
probably prompt you for your iSeries user ID and password at this point.
3. Click Backup, Recovery and Media Services.
4. The list of BRMS features is displayed in the right hand pane of iSeries Navigator. You
also see a list of BRMS tasks in the bottom right hand side of iSeries Navigator that you
can execute with a single mouse click, as shown in Figure 1-4.

30 Domino 6 for iSeries Best Practices Guide

Figure 1-4 BRMS interface in iSeries Navigator

5. Click the feature or task you want to perform. Additional prompts for each task are
displayed before executing a function.

Tips and tricks

Learning and using command line (CL) commands can be confusing for administrators new
to Domino for iSeries. Domino administrators may not be familiar with 5250 workstation
emulation commands, but have experience with running Domino on other platforms. iSeries
administrators may not be familiar with the common commands for administering a Domino
environment. Following are some suggestions that can help.

Create a menu of common commands

There are several OS/400 commands you need to learn to administer Domino for iSeries.
While it is important for you to learn these commands, we suggest that the iSeries team
create a menu of common commands for the Domino administrators to use from a
5250 workstation emulation session. Figure 1-5 shows an example of this concept.

Chapter 1. Deploying Domino 6 for iSeries 31

 AS25 Utilities 00/00/00
Menu 00:00:00
Select one of the following:
1. Work with Domino Servers 31. Restore Domino IFS Files
2. Hold Domino Server Monitor 32. Work with Backup Control Groups
3. Release Domino Server Monitor 33. Go to BRMS Main Menu
11. Work with Active Jobs
12. Work with Jobs in QBATCH 41. Go to OS/400 Main Menu
13. Display Backup Log Information
14. Work with Scheduled Jobs 90. Sign Off
15. Display System Status
16. Display Disk Status
17. Work with Printer Output
18. Display Messages
19. Display QSYSOPR Messages
21. Send a page to iSeries Tech

Selection or command
===>_____________________________________________________________________________
__________________________________________________________________________________
F3=Exit F4=Prompt F9=Retrieve F12=Cancel
F13=Information Assistant F16=AS/400 main menu

Figure 1-5 Example of a 5250 emulation session menu for Domino administrators

We recommend that all administrators learn the OS/400 commands needed to manage a
Domino for iSeries environment. Entering the commands manually is usually much faster
than using a menu system.

You can request a list of OS/400 commands specific for Domino by typing the following
command on the 5250 emulation screen command line:
GO CMDDOM

You can execute options from the Domino Commands menu, as shown in Figure 1-6.

32 Domino 6 for iSeries Best Practices Guide

 CMDDOM Domino Commands

Select one of the following:

Commands
1. Add Domino Application ADDDOMAPP

3. Configure Domino Server CFGDOMSVR

4. Change Domino Server CHGDOMSVR
5. Display Domino Console DSPDOMCSL
6. End Domino Server ENDDOMSVR

8. Submit Domino Command SBMDOMCMD

9. Start Domino Server STRDOMSVR
10. Work with Domino Console WRKDOMCSL
11. Work With Domino Servers WRKDOMSVR

Selection or command
===>

F3=Exit F4=Prompt F9=Retrieve F12=Cancel F16=Major menu

Figure 1-6 The Domino commands menu

Mapping drives to the iSeries IFS

Be very careful when you map a drive to an iSeries IFS that runs a Domino server. You must
first shut down the Domino server before you map a drive to a server’s data directory. The
drive mapping process on most Windows platforms can lock important files, thus causing
your Domino server to crash.

You have several options:

򐂰 Shut down your Domino server before mapping the drive. Move or copy the files you need.
Disconnect the mapped drive. Restart the Domino server.
򐂰 Use 5250 workstation emulation commands to move or copy the file from the Domino data
directory to another directory on the iSeries that is not under a server data directory.
Domino locks many files when the server is up, so be careful what files you move or copy.
You can then map a drive to the directory you moved the file to and copy the file to your
local system.
򐂰 Use iSeries Navigator to copy or move files. Again, be careful what files you move or copy.

Attention: Using a mapped drive or the drag-and-drop feature of iSeries Navigator could
possibly cause issues with OS/400 object ownership. Verify that the object is still owned by
the QNOTES user profile after you copy or move a file. Do this either by executing the
command WRKLNK, then select option 9 in a 5250 emulation session or by right-clicking
the file in iSeries Navigator and selecting the file’s properties.

1.4 Configuration guidelines and recommendations

This section contains configuration guidelines and recommendations for the following topics:
򐂰 TCP/IP configuration
򐂰 Virtual hosts
򐂰 Adapter configuration

Chapter 1. Deploying Domino 6 for iSeries 33

1.4.1 TCP/IP configuration
This section identifies the resources you need for planning and configuring the TCP/IP
interface(s) on your iSeries. This topic is well documented, so we list the sources you need.

What’s new in V5R2

New TCP/IP functionality added to the iSeries server in V5R2 includes the following features:
򐂰 IPv6: Internet Protocol version 6 (IPv6) is the latest version of Internet Protocol. It is
designed to gradually replace Internet Protocol version 4 (IPv4). You have to write your
own applications using the OS/400 APIs to implement this feature in V5R2.

Note: Though much of the Domino 6 documentation says you can enable IPv6 support
for SMTP, POP3, IMAP, LDAP and HTTP services, IPv6 support is not available for
Domino for iSeries as of 6.0.2 CF1. Lotus plans to implement this feature in a future
Domino 6 release. Refer to the iSeries section of the Domino 6.0.2 CF1 Release Notes
for more information.

򐂰 PPPoE: Remote access services is introducing PPP over Ethernet (PPPoE) with this
release. You can now support a PPPoE connection to your ISP through your iSeries
server.
򐂰 Virtual IP address support: In the event of an adapter failover you can now use proxy
Address Resolution Protocol (ARP), along with virtual IP, to provide seamless availability
to clients.

Virtual IP address support

Virtual IP Address (VIPA) support is a very powerful feature with many different applications.
Since VIPAs are not bound to a single physical interface, they provide a simple way to define
system wide IP addresses. They allow the iSeries to be known by a single IP address, even
when it is attached to many different networks.

The V5R2 implementation of VIPA incorporates the ability to do proxy ARP for a Virtual IP
Address. Proxy ARP allows for the iSeries to respond to ARP requests for the Virtual IP
Address. This simplifies fault tolerance, especially for locally attached LAN devices as the
configuration of indirect routes in the local LAN attached hosts is no longer necessary. The
proxy ARP for VIPA allows local LAN hosts to see the virtual IP addresses.

When configuring your iSeries for Domino 6, the primary advantage that is gained by setting
up VIPA is the added failover capability, which would be invisible to Domino. By configuring
Domino for iSeries server(s) to use a virtual IP address, rather than a static IP address, your
Domino server(s) continue to function properly as long as one of the physical interfaces
associated with the virtual IP address stays active. The IP routing tables adjust seamlessly to
route IP traffic to a different physical adapter in the event that an interface fails for some
reason. To some extent, load balancing can also be achieved with VIPA, but we feel that
using Domino clustering is a much more practical solution.

In general, we recommend implementing Domino clustering for load balancing and failover
functionality instead of VIPA as a best practice. While there are no known problems running
Domino for iSeries using VIPA when correctly configured, it is not commonly used.

Firewall and port considerations

The ports used by Domino depend on the services enabled. Here are the main default ports
Domino uses for the most common services:
򐂰 HTTP/HTTPS: Ports 80 and 443 for the Web Administrator and iNotes Web Access

34 Domino 6 for iSeries Best Practices Guide

 򐂰 LDAP/SSL-LDAP: Ports 389 and 636
򐂰 Native Notes access: 1352 for server to server and client to server connectivity
򐂰 SMTP: Port 25
򐂰 POP3: Port 110
򐂰 IMAP: Port 143
򐂰 Lotus Instant Messaging and Web Conferencing (Sametime):
– Tunnels through HTTP/HTTPS ports 80 and 443 for the Connect client
– Uses native port 1533 for the Connect client
– Uses port 1516 for server to server connectivity

Resources
Here is a list of resources for configuring TCP/IP for Domino and iSeries:
򐂰 For step by step instructions, refer to Section 2.3 in IBM Lotus Domino 6 for iSeries
Implementation, SG24-6592 available for download at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246592.html?Open
򐂰 For general information about configuring TCP/IP for Domino servers, refer to the
Domino 6 Administrator Help topic “Planning the TCP/IP network”.
򐂰 For information about virtual IP and PPPoE on the iSeries, refer to iSeries IP Networks:
Dynamic!, SG24-6718 available at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/SG246718.html?Open
򐂰 For specific information about TCP/IP in V5R2, refer to the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm
򐂰 Learn the basics of TCP/IP and an overview of the latest developments in the world of
TCP/IP and the Internet from the redbook TCP/IP Tutorial and Technical Overview,
GG24-3376 at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/gg243376.html?Open
򐂰 All You Need to Know When Migrating from IBM Firewall for AS/400, SG24-6152 at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/SG246152.html?Open

1.4.2 Virtual hosts

A virtual host, also referred to as a Web site alias, maps multiple DNS names to a single IP
address. This allows users to enter different URLs to access a Web site. For example, you
want either www.acme.com or acme.com to provide access to the Acme Web site.

Virtual hosts in Domino

Entering an alias is also useful if you want to change the DNS name for the Web site. You can
retain the links to a previous DNS name, for example, if the company name changes.
Additionally, virtual hosts allow an administrator to change the contents of these two sites with
settings contained within the virtual host document in the Domino Directory. Virtual hosts may
have their own default home pages and directory mappings, but they must take the SSL
security layer configuration from the main or "parent" Web site.

Resources
The following is a list of resources related to Domino Web functionality:
򐂰 Building Web applications in Domino 6: Web site rules by John Chamberlain
http://www.lotus.com/ldd/today.nsf/f01245ebfc115aaf8525661a006b86b9/b86a878b9ae5ee0d
85256ad8000813a6?OpenDocument

Chapter 1. Deploying Domino 6 for iSeries 35

 򐂰 For information about hosting Web sites and virtual hosts in Domino 6, refer to the
Domino 6 Administrator Help topic “Hosting Web sites”.
򐂰 Chapter 12, “Planning the Service Provider Environment” and Chapter 34-17, “Hosting
Web sites” in Administering the Domino System, Volume 1
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument

1.4.3 Adapter configuration

It is crucial to correctly configure the network adapter(s) on your iSeries for best network
performance and Domino performance. Incorrect configuration can result in additional CPU
usage and poor user response time due to transmission bottlenecks or the retransmitting of
dropped packets. Since it can be difficult to locate the information you need for configuring
adapters on your iSeries, we recommend the two resources below for best practices
guidelines.

The document entitled “OS/400 Ethernet - 100 Mbps (FC2838 / FC2849), 1 Gigabit
(FC2760 / FC5701 STP or UTP), or 1 Gigabit (FC2843 or FC5700 Fiber), and Full Duplex
(CRTLINETH, CHGLINETH)” contains recent information on the adapters and configurations
supported on the iSeries. Refer to the article on the iSeries and AS/400 Technical Support
Web site at:
http://www.ibm.com/support/docview.wss?rs=203&q=duplex+iSeries+auto&uid=nas1990a2cc52f1f
b76186256665004727bf&loc=en_US&cs=utf-8&lang=en

You can also refer to the iSeries: Networking Ethernet on iSeries 400 book for detailed
information about understanding, configuring, managing, tuning, and troubleshooting
Ethernet support on the iSeries. The book is available at:
http://www.ibm.com/support/docview.wss?uid=nas1990a2cc52f1fb76186256665004727bf&aid=1

1.5 Securing your Domino environment

We suggest that you separate the Domino server administration from operating system server
administration, if your organization's IT structure allows this. There are advantages and
disadvantages to this suggestion. Our reasoning is that this structure enables a series of
checks and balances, with each background contributing to the overall effectiveness of the
Domino and system support.

Whatever structure you choose, you need to develop a set of security documentation for your
organization if they are not already in place.

There are four basic types of security documents needed for any security implementation:
򐂰 Policies are the driving documents for the business. These are typically high level
statements about the security needs of the business. Your organization probably already
has policy documents for the organization as a whole. You build and, if necessary, expand
on these to develop the security policies for your Domino and iSeries environments.
򐂰 Guidelines provide overall guidance on how to support and maintain security in the
enterprise.
򐂰 Standards are established rules on what will and will not happen in an enterprise. Audits
may cover all four types of documents, but the auditor will really focus on the standards set
down by a company. Standards typically cover things like minimum password strength,
password expiration intervals, server operating systems and physical environments,
Internet and dial-in access controls, background checks for administrators, and auditing
requirements.

36 Domino 6 for iSeries Best Practices Guide

 򐂰 Procedures typically include specific steps on how to implement security within an
enterprise. This will be the bulk of your Domino security documentation, covering
everything from how to control Domino and X.509 certifiers to what to do when users have
forgotten their Notes or Internet passwords to what steps to take when an employee
leaves an organization. Procedures are developed after the security framework is in place.

The Domino and iSeries security teams are responsible for initial direction, feedback, and
auditing of these documents. The team must include representatives from each department
within the enterprise. With this approach, the security documents created will meet the needs
of the entire company. This has the added benefit of creating buy-in from the participating
departments.

We recommended a periodic audit of your environment for consistent application of standards

and policies. This would be beneficial from both a security and an administrative standpoint.

1.5.1 iSeries security considerations

We suggest creating a list of roles and the OS/400 access required for each role. Create a
group profile for each role with the appropriate access, then assign the group profile to users
when created or when a user’s role changes on the team. Team members may temporarily
require higher levels of access to accomplish the goals of a specific project, like a Domino
server upgrade or to install new software such as Lotus Instant Messaging and Web
Conferencing (Sametime).

Bearing in mind that your organization’s needs may differ, of course, here is a list of
recommended roles and guidelines for OS/400 access:
򐂰 Senior iSeries server administrators (SrAdmin):
– QSECOFR access to the iSeries and OS/400 features and security
򐂰 Junior iSeries server administrators (JrAdmin):
– All object access (*ALLOBJ)
– Security administration (*SECADM)
򐂰 Domino software installation/configuration (DomSoftInst):
– All object access (*ALLOBJ)
– Security administration (*SECADM)
– System configuration (*IOSYSCFG)
– Job control (*JOBCTL)
򐂰 Domino senior administrators (DomSrAdmin):
– All object access (*ALLOBJ)
– Security administration (*SECADM)
– Job control (*JOBCTL)
– Access to start and end Domino servers
– Access to check PTF and software installation information
򐂰 Domino junior administrators (DomJrAdmin):
– Access to run display type commands for the Domino servers
– Job control (*JOBCTL)
򐂰 Management reporting access (MgtRepAcc):
– Grants reader access to the library and database tables that contain the Collection
Services data, if you use this feature of Domino 6 and V5R2.

Chapter 1. Deploying Domino 6 for iSeries 37

1.5.2 Domino security considerations
Domino has several layers of security to protect your data assets. This section describes the
recommendations for administrator access, digital signatures, database ACLs, Domino
server access, ID files and passwords, execution control list (ECL) and Internet client
authentication configuration.

Administrator access
You can define several levels of Domino administration for your organization, depending on
the access required to various administration resources. Create a group for each role, then
set the administration access for these roles in the Domino server document. For example,
your organization might have the following roles or some combination of these roles:
򐂰 Full Access Administrators:
Domino 6 introduced the Full Access Administration feature that replaces the need to run
a Lotus Notes client locally on a server. It resolves access control problems -- for example,
such as those caused when the only managers of a database ACL have left an
organization.
We highly recommend using this feature only as needed. If you have an issue that
requires the Full Access Administration feature, grant the access temporarily, fix the issue,
then remove the access.
We recommend creating an ID file for each user that requires the Full Access
Administration feature using a special OU with a naming convention like John
Doe/FullAccessAdmin/YourDomain. Each administrator must use the FullAccessAdmin ID
file and enable the Full Access Administration option in the Domino 6 Administrator client
to gain this level of access.
We also recommend that you audit how the full access administrator access privilege is
used:
– Configure the Event Handler to send notification through EVENTS4.NSF when full
access administration privileges are invoked.
– Any database activity performed by an administrator using full access administrator
access is recorded in the database activity log, under Database Properties. Monitor
this log on important databases such as your Domino Directory.
򐂰 Administrators:
Assign this level to senior level administrators who manage servers, databases and
operating system level settings.
򐂰 Database administrators:
Assign this level to mid level administrators who don’t need Manager access to databases
or authority to run operating system level commands.
򐂰 Full remote console administrators:
Assign this level to database administrators, view-only administrators, and systems
administrators who may use the remote console to issue commands.
򐂰 View-only administrators:
Assign this level to administrators who can use the remote console to issue only those
commands that provide system status information, but not commands that affect the
server’s operation.
򐂰 System administrators:
Assign this level to administrators who can issue any operating system level command
based on their security level to the operating system.

38 Domino 6 for iSeries Best Practices Guide

򐂰 Restricted system administrators:
Assign this level to administrators who can only issue a predefined list of operating system
level commands.

Note: Refer to the topic “Restricting administrator access” in the Domino 6 Administrator
Help for a complete description of each role.

We recommend creating a group for each role, then enter the group names in the server
document for each server in your environment. We also recommend creating a policy for each
role with a registration setting containing the correct group. New administrators will inherit the
correct administrator access during the Notes ID creation process.

There are two additional roles that are not specifically addressed on the Security tab on the
server document. It should be noted that these roles must have at least Editor access to the
master Domino Directory for the domain to complete their tasks.
򐂰 Certificate authority administrator (CAA):
This role is for administrators who create, modify, and configure certifiers and add or
remove certification and registration authority administrators. As a best practice, designate
at least two CAAs for each certifier. You then have a backup if one leaves the organization.
򐂰 Registration authority administrator:
This role is for administrators who register Notes users and Domino servers, approve or
deny Internet certificate requests, and, if necessary, revoke Internet certificates.

Important: We recommend that you thoroughly test the certification authority feature in
Domino 6 before implementing it in your production environment. There are several
steps required to set up this feature. It is also recommended that you understand the
differences between using the certification authority and the standard method for
registering Notes users and servers. Refer to the topic “Administering a Domino CA” in
the Domino 6 Administrator Help for more information.

Digital signatures
Digital signatures assure a reader that the writer's identity is genuine and that information has
not changed since the user saved the document. A digital signature includes the user's
hierarchical name, the name of the certifier of the User ID, and the date the document was
saved.

Here are some best practices for digital signatures:

򐂰 Provide each Notes user with a unique ID file and password. The ID file contains
encryption keys and certificates that Domino servers use to verify the authenticity of the
file.
򐂰 To provide additional security, Notes/Domino allows the use of a password to encrypt
sensitive portions of an ID file.

Database ACLs
Every Domino database has an ACL that specifies the level of access that users and servers
have to that database. Access levels assigned to users determine the tasks that they can
perform in a database, while those assigned to servers determine what information within the
database the servers can replicate.

Chapter 1. Deploying Domino 6 for iSeries 39

 Here are the recommended best practices for database ACLs:
򐂰 Set -Default- access to "No access." Setting Default to No Access limits database access
to those users and groups specified in the ACL. You cannot delete Default from the ACL
list.
򐂰 Anonymous access should not be allowed. By default, anonymous is set to no access.
򐂰 The default access for the user who creates the database (Database creator user name)
is Manager. Confirm this is the planned access level for this person before you put the
database into production. Generally, developers should not be given Manager or Designer
access to their applications on a production system. They should follow a change control
process to move changes and fixes from development to test to production.
򐂰 The default access for the LocalDomainServers group is Manager. Depending on the
application, the group should have at least Designer access to allow replication of
database design changes across the domain.
򐂰 Disallow wildcard entries. The chance is too great that you will enable access to the wrong
users. There is also a chance that an OU change for a user could lock the user out of the
application. You may use a wildcard such as */SVR/ACME to include all servers in a group.
򐂰 To control the changes a database receives from a database replica, add full hierarchical
server names to an ACL.
򐂰 Assign User types to database ACL entries. This prevents users from finding a back door
into your database.
򐂰 Make sure that the names of terminated employees are removed from the ACLs of all
databases in your organization. The AdminP process will do this automatically for most
databases.
򐂰 If possible, add new names to existing groups in the ACL rather than listing names
individually. This recommendation will require additional security planning for your
database or application.
򐂰 Use an "Administrators" group instead of individual IDs for administrators directly in the
ACLs of production databases.
򐂰 Use the server administration process to keep the ACL up to date.

Domino server access

Limiting access to the Domino server is the first level of security that Domino enforces after a
user or server gains access to the server on the network. We recommend the following
methods to secure the Domino server:
򐂰 Use the Allow Access and Deny Access fields on the Domino Server document to specify
which Notes users and Domino servers are authorized to access the server.
򐂰 Limit the number of users who can create databases, replicas, and templates on a Domino
server to restrict access to the server, and to prevent a proliferation of databases and
replicas on the server.
򐂰 Cross-certify Notes user IDs and Domino server and certifier IDs so that Notes users and
Domino servers in different hierarchically certified organizations correctly identify users
and servers in other Notes organizations.
򐂰 Password-protect the server console to prevent unauthorized users from entering
commands at the server console. If feasible, secure the server console with a Smartcard
to prevent unauthorized access.
򐂰 Specify which Notes users and Domino servers can access the server as a passthru
server and specify the destinations they may access.

40 Domino 6 for iSeries Best Practices Guide

򐂰 In multiple server environments, be careful about who is put on the trusted server list. If
you list a server as trusted in the Domino Server document, that server asserts the
identities of users to the Domino server and thus is trusted by the Domino server to have
authenticated those users.
򐂰 Assign multiple passwords to certifier IDs to prevent one user from controlling a certifier
ID.
򐂰 Compare Domino public keys in user IDs with the public key stored in the Domino
Directory to prevent unauthorized users from using illicitly obtained IDs to authenticate
with Domino.
򐂰 Restrict administrator access by assigning different types of administrator access to
individuals based on the tasks they need to perform on the Domino server (see “ID files
and passwords” below).

ID files and passwords

Specify the level of password quality you want enforced for the ID when registering user or
server IDs or creating certifier IDs. The higher the level, the more complex the password and,
therefore, the more difficult it is for an unauthorized user to guess the password. Password
quality level is enforced when users enter a password for new IDs or when users change the
password for an existing ID.
򐂰 For optimal security, specify a password quality level of at least 8.
򐂰 Have users choose passwords that consist of random, alphanumeric strings that include
mixed uppercase and lowercase letters, numbers, and punctuation. An entire phrase is
better than a single word because it is easy to remember, difficult to guess, and generally
longer than a single-word password.
򐂰 Include a misspelled word in phrases to make it more difficult for attackers to guess at the
phrase.
򐂰 When an identification token (a Notes ID) is deauthorized, the public key is removed from
the Domino Directory, which prevents a user from using the ID file. The administration
interface using the password management facility can set a value to “lock out” the ID file
on a per-user basis. Messages are logged to the server console when someone tries to
access a server to which they do not have access. Administrators can set up Event
Handlers to record the occurrence of these events.

Execution control list (ECL)

As in Lotus Domino R5, you use an ECL to set up workstation data security in Domino 6. An
ECL protects user workstations against active content from unknown or suspect sources, and
can be configured to limit the action of any active content that does run on workstations. See
the article “The execution control list” in the Domino 6 Administrator Help for more
information.

In Lotus Domino R5, you had to e-mail your users a button with a formula command to update
the ECL on their local workstations. In Domino 6, you can enforce a consistent ECL on each
workstation assigning a policy with a security setting. See the article “Setting up Notes users”
in the Domino 6 Administrator Help for more information on specifying a default workstation
execution control list.

Smartcards
Beginning with Lotus Notes 6, you can use a Smartcard with your user ID to login to Notes,
provided you have a Smartcard reader installed on your computer. Once your user ID is
enabled for Smartcard login, you are prompted for your Smartcard Personal Identification
Number (PIN) in place of your Notes password. One of the major differences between

Chapter 1. Deploying Domino 6 for iSeries 41

 entering your Notes password for login and entering a Smartcard PIN for login is that if you
enter the wrong PIN too many times, the Smartcard locks and requires administrator
intervention.

The advantage of using a Smartcard with Notes is that you use a Smartcard to lock your
user ID. Without a Smartcard, you only need your user ID and your Notes password to access
Notes. When using a Smartcard, you need your user ID, your Smartcard, and your Smartcard
PIN to access Notes. Also, because you carry your Smartcard with you (just as you would
carry a credit card with you), you are much less vulnerable to user ID theft.

Refer to the following resources for more information about using Smartcards with Lotus
Notes and Domino 6:
򐂰 “Password-protection for Notes and Domino IDs” topic in the Domino 6 Administrator Help
򐂰 “Lotus Notes and Domino 6 Security Standards” article at the following Web site:
http://www.lotus.com/products/rnext.nsf/0/a2685e8c2814040f85256ae900775c9c?OpenDocum
ent

Internet client authentication

You can select the level of restriction Domino uses when authenticating users in Domino
Directories and LDAP directories. This applies to all Internet protocols (HTTP, LDAP, IMAP,
POP3). The Internet Authentication setting on the Security -> Internet Access section of the
server document makes servers less vulnerable to security attacks by refining how Domino
searches for names and authenticates Internet clients. Domino also uses this setting when a
Java applet hosted on a Domino server authenticates users with the Domino IIOP protocol.

"Fewer name variations" is the default, and recommended, setting for Domino 6 servers.

Internet Site documents

Internet Site documents make it easier for administrators to configure and manage Internet
protocols in their organizations. For example, prior to Domino 6, if you wanted to set up a
Web site in your organization, it was necessary to configure each Domino server in the
domain with Mapping documents, Web realms, and File Protection documents. If you had
virtual servers and virtual hosts, you had to do the same thing for them. In Domino 6, you can
configure a Web Site document so that all servers and hosts use it to get configuration
information for a Web site, including mapping information, file protection information, and
Web realm authentication information. You may create a separate Internet Site document for
other Internet protocols, such as IMAP, POP3, SMTP Inbound, LDAP, and IIOP, that can
provide protocol configuration information for a single server, or for multiple servers in your
Domino environment.

Please remember that if you use an Internet site document to configure one Internet protocol
on a server, you must also use Internet site documents for all Internet protocols on that
server. For example, you cannot set up an LDAP Internet Site document and, on the same
server, use the Server document to configure HTTP.

Here are our recommendations for configuring the addressing of Web sites for proper
operation and greatest security:
򐂰 Use DNS host names wherever possible to identify your Web sites. Note that the host
name field allows multiple values to handle the case where a Web site has a number of
host name aliases.
򐂰 Use an IP address to identify a site only if it is explicitly required. There are only two
common cases where an IP address is required:
– If a site supports SSL

42 Domino 6 for iSeries Best Practices Guide

 – If you know the site will be accessed by clients that do not send Host headers.
򐂰 Make sure that the Internet Sites view is sorted so that all sites identified by IP addresses
appear below sites identified by host names. Otherwise the IP-address sites may "hide"
host name sites.
򐂰 Do not create a default Web site on a server connected to the Internet or to any network
where security is a concern. Let the server reject requests that cannot be mapped to a
Web site.

Resources
Here is a list of resources related to Internet client authentication:
򐂰 Chapter 42, “Setting Up Name-and-Password and Anonymous Access to Domino
Servers” in Administering the Domino System, Volume 2
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument
򐂰 Refer to the topic “Controlling the level of authentication for Internet clients” in the
Domino 6 Administrator Help for more information about Internet authentication.
򐂰 Refer the topic “Internet Site documents” in Domino 6 Administrator Help for more
information about configuring Internet Site documents.
򐂰 developerWorks : Lotus LDD Today article “A tutorial on Web site addressing” by John
Chamberlain at:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/8f68a440f2182b1e
88256a9a005d40da?OpenDocument

1.6 National language support considerations

This section contains some optional national language topics, including these:
򐂰 Domino 6 compared to Domino R5
򐂰 Localization and NOTES.INI settings
򐂰 Web preferences
򐂰 iSeries Navigator changes in V5R2

This section also lists additional resources about national language support and globalization
for Domino 6 and the iSeries.

1.6.1 Domino 6 compared to Domino R5

Unlike Domino R5, fully translated versions of the Domino 6 product are not available.
Instead, Domino uses OS/400 locales. This means the installation process for a national
language version of Domino 6 is now different from the process for the Domino R5
installation. To deploy Domino 6 in a language other than English, you must first install the
English version of Domino 6, then add the translated language objects from the specific
Domino 6 Language Pack CD.

For details on national language support, refer to 3.7, “National language support” and
Appendix B, “Additional national language support considerations” in IBM Lotus Domino 6 for
iSeries Implementation, SG24-6592.

A new feature with Domino 6 is the ability to deploy more than one language on a Domino
server or have Domino servers with differing languages through the use of a language pack
and multilingual database support. For detailed information on this type of environment, see
the Domino administration documentation or the Domino Administrator 6 Help database.

Chapter 1. Deploying Domino 6 for iSeries 43

1.6.2 Localization and NOTES.INI settings
Regardless of the language of Domino 6 for iSeries that is installed, international users may
need to customize how Domino displays the date, the time, and the separator character that
is being used. You can easily update the layout of these parameters by adding a specific
statement in the Domino server’s NOTES.INI file. There are NOTES.INI settings for the
localization of your Domino server, including date/time and sorting sequence settings.

Date/time settings
Here is a list of NOTES.INI settings that affect the localization of a Domino 6 server:
򐂰 Date time setting
򐂰 ClockType
򐂰 DateOrder
򐂰 TimeSeparator
򐂰 DateSeparator

You might also want to include these settings:

򐂰 TimeZone
򐂰 DSTLaw
򐂰 DST_Begin_Date
򐂰 DST_End_Date

Sort sequence settings and other locale specific issues

Domino 6 for iSeries normally uses the locale setting for the QNOTES user profile to
determine sorting and language settings.

If you run Domino servers with different languages, set the NOTES.INI parameter as follows:
COUNTRY_LANGUAGE= language (for example sl-SI for Slovenia)

In the case of an upgrade from Domino R5, you might need to change the locale for the
QNOTES user profile using the following command, which uses the country of Slovenia as an
example:
CHGUSRPRF USRPRF(QNOTES) LOCALE('/qsys.lib/qnotes.lib/sl_si.locale') SETJOBATR(*ccsid
*datfmt *datsep *decfmt *srtseq *timsep)

The *srtseq parameter sets the sorting sequence for your Domino server.

Again, more information on setting these NOTES.INI parameters and changing the locale
settings for a user can be found in Appendix B, “Additional national language support
considerations” of the redbook IBM Lotus Domino 6 for iSeries Implementation, SG24-6592.

1.6.3 Web preferences

Domino 6 offers a new feature called Web preferences to make your Domino Web
applications appear smarter by letting you set time zone and regional preferences for your
browsers. You can take advantage of this new feature for the application development or
server setup. For more information on this feature, refer to the LDD Today article “Making
Web browsers look smarter with Domino 6” by Dale Schultz at:
http://www.lotus.com/ldd/today.nsf/lookup/WebPref

44 Domino 6 for iSeries Best Practices Guide

1.6.4 iSeries Navigator changes in V5R2
Although the CL commands, menus, panels, and messages for Domino 6 have not been
translated into any other languages, the iSeries Navigator plug-in interface has been
translated into Brazilian Portuguese, French, Italian, German, Japanese, Korean, Simplified
Chinese, Traditional Chinese, and Spanish. These translated interfaces are installed as part
of the Language Pack installation process.

1.6.5 Resources
Here are some other references for your convenience:
򐂰 Section 3.7, “National language support” in IBM Lotus Domino 6 for iSeries
Implementation, SG24-6592
򐂰 Chapter 20, ‘Using national language versions of Domino” in Installing and Managing
Domino 6 for iSeries (i400help.pdf)
򐂰 Help topic “Setting up language preferences” in Domino 6 Administrator Help
򐂰 Lotus Domino for iSeries FAQs at:
http://www.ibm.com/servers/eserver/iseries/domino/faqs/pack.htm
򐂰 Technote 1112457, “Change in Notes/Domino EMEA Language Delivery Plan Starting in
5.0.12” at:
http://www.ibm.com/support/docview.wss?rs=0&q=localization&uid=swg21112457&loc=en_US
&cs=utf-8&cc=us&lang=en
򐂰 Article: “What's New with Domino 6 and V5R2” by Dan Hill available at:
http://www.ibm.com/servers/enable/site/domino/v5r2/v5r2.pdf
򐂰 Section 12.3.1, “Language differentiation” in Upgrading to Lotus Notes and Domino,
SG24-6889
򐂰 Globalizing your e-business Web site at:
http://www.ibm.com/software/globalization/software/lotus.jsp
򐂰 Section entitled “Adding an alternate language and name to a user ID” starting on page
5-38 in Administering the Domino System, Volume 1.

Chapter 1. Deploying Domino 6 for iSeries 45

46 Domino 6 for iSeries Best Practices Guide
 2

Chapter 2. Administering your Domino

environment
In this chapter we describe the best practices for administering your Domino for iSeries
environment. It includes updates to proven administration processes and procedures. It also
includes references to the current resources for Domino and iSeries administrators.

© Copyright IBM Corp. 2004. All rights reserved. 47

2.1 Document your Domino environment
We recommend that you document your Domino environment and keep the documentation
current. Retain the document in a database or LAN drive where it is accessible by your
Domino administration team. Figure 2-1 shows an example of a basic spreadsheet you can
use to start your documentation. Customize it for your environment and documentation
requirements.

Avg. # of Avg.
# processors & Notes Client/ Avg. mail Classification of
Server Location primeshift registered Concurrent # of Apps
MHZ HTTP/ Outlook file size applications
CPU users users

DOMCHIM01 Chicago 2 way -450MHZ 5% CPU 750 Notes Client 35% 120MB 50 Simple workflow
(500MB)
DOMCHIM02 Chicago 2 way -400MHZ 10% CPU 540 Outlook Clients 35% 100MB mail
DOMCHIH01 Chicago 4 way 500MHZ 10% CPU --- --- --- --- --- Domino mail routing &
rep
DOMRocAP01 Rockford 1 way 450MHZ 25% CPU 400 Notes Clients 15% --- 250 Simple workflow
(1.5GB)
DOMDAYAP01 Dayton 2 way 500MHZ 15% CPU 200 Browsers 15% --- 10 Salesforce automation
(DB2 integration)
(2GB)
DOMDAYIM01 Dayton 4 way 500MHZ 10% CPU 1290 --- 20% --- --- Lotus Instant
Messaging (Sametime
Chat) server
Firewall Chicago 1 way 500 MHZ 5% CPU --- --- ---

SendMail Chicago 1 way 450 MHZ 5% CPU SMTP Mail Gateway

Gateway

Figure 2-1 Sample spreadsheet for documenting a Domino environment

2.2 Getting the most out of your Domino Directory: revisited

The IBM Redbook Getting the Most From Your Domino Directory, SG24-5986, contains the
most complete information for beginning, intermediate, and skilled Domino administrators for
managing your Domino Directory. It includes information on understanding the Domino
directory services, planning directory services, and setting up, configuring, administering and
using Domino directory services. Chapter 7 describes directory integration of your Domino
directory services with industry standard products.

2.2.1 Getting the most out of your Domino Directory on Domino 6 for iSeries
This section contains some updates that are specific to Domino 6 and the iSeries platform
and some tips and tricks you can use in your environment.

Automate regular maintenance of your Domino Directory

Use a CL program to compact files that are normally in use before running your full backup
each week. We recommend issuing a COMPACT command with the -B option to run over
your NAMES.NSF, ADMIN4.NSF, LOG.NSF, and any other crucial databases in your
environment to keep your databases and server healthy. This should be done with the
Domino servers down. This maintenance should complete before the full backup for the week
is performed since Domino assigns new DBIIDs to databases when using this method of
compacting. Example 2-1 lists a CL program that you can modify to automate the Domino
Directory maintenance in your environment.

Example 2-1 Sample CL program for compacting Domino databases

0001.00 /*----------------------------------------------------------------*/
0002.00 /* AUTHOR- XXXXXXX */
0003.00 /* DATE UPDATED- 12/16/02 */
0004.00 /* PROGRAM TAKES DOWN THE HUB SERVER AND COPIES THE NAB THEN REBUILDS */

48 Domino 6 for iSeries Best Practices Guide

0005.00 /* THE SERVER CONFIGURATION VIEWS NEEDED TO RUN A SERVER. THESE NABS */
0006.00 /* ARE USED TO MITIGATE CORRUPTION AND HELPS SERVER STARTUP TIME. */
0007.00 /* SEE SYSTEM API REFERENCE SYSTEM API REFERENCES OS/400 WORK MANAGEMENT APIS*/
0008.00 /* SC41-5878 FOR A DESCRIPTION OF THE QWDRSBSD API */
0009.00 /*----------------------------------------------------------------*/
0010.00
0011.00 PGM PARM(&SERVER)
0012.00
0013.00 DCL VAR(&SERVER) TYPE(*CHAR)
0014.00 DCL VAR(&SBS) TYPE(*CHAR)
0015.00 DCL VAR(&RCVVAR) TYPE(*CHAR) LEN(256) /*API +
0016.00 VARIABLE */
0017.00 DCL VAR(&RCVLENBIN) TYPE(*CHAR) LEN(4) +
0018.00 VALUE(X'00000100')
0019.00 DCL VAR(&CURACTJOB) TYPE(*CHAR) LEN(4) /*NUMBER +
0020.00 OF CURRENT*/
0021.00 DCL VAR(&HEXZERO) TYPE(*CHAR) LEN(4) +
0022.00 VALUE(X'00000000') /*HEX ZERO*/
0023.00 DCL VAR(&FMTNAM) TYPE(*CHAR) LEN(8) +
0024.00 VALUE('SBSI0100')
0025.00 DCL VAR(&ERRCODE) TYPE(*CHAR) LEN(4) +
0026.00 VALUE(X'00000000') /*RETURNS ERRORS AS +
0027.00 EXCP. MSGS*/
0028.00 DCL VAR(&STATUS) TYPE(*CHAR) /*RETURNS STATUS OF +
0029.00 SUBSYSTEM*/
0030.00 DCL VAR(&PAGESTRING) TYPE(*CHAR) LEN(100) /*PAGER VARIABLE*/
0031.00 CHGVAR VAR(&SBS) VALUE(&SERVER)
0032.00 CHGVAR VAR(&PAGESTRING) VALUE('(&SERVER *CAT ''NAB +
0033.00 REBUILDING, DOWN FOR 15 MIN)')
0034.00 MONMSG MSGID(CPF0000)
0035.00 MONMSG MSGID(CPA0000)
0036.00 ADDLIBLE LIB(QNOTES)
0037.00 EZPAGE PGERID(MGORDON) PGRTXT(&PAGESTRING)
0038.00 DEL OBJLNK('/NOTES/yourserver/NAMES.REBUILDING')
0039.00 ENDDOMSVR SERVER(&SERVER)
0040.00 MONMSG MSGID(CPF0000)
0041.00 DLYJOB DLY(200)
0042.00 CHECKSBS: CALL PGM(QWDRSBSD) PARM(&RCVVAR &RCVLENBIN +
0043.00 &FMTNAM &SBS &ERRCODE)
0044.00 MONMSG MSGID(CPF0000)
0045.00 MONMSG MSGID(CPA0000)
0046.00 MONMSG MSGID(LNT0000)
0047.00 CHGVAR VAR(&STATUS) VALUE(%SST(&RCVVAR 29 10))
0048.00 CHGVAR VAR(&CURACTJOB) VALUE(%SST(&RCVVAR 734))
0049.00 IF COND(&CURACTJOB ¬= &HEXZERO) THEN(DO) /*STILL ACTIVE*/
0050.00 ENDDOMSVR SERVER(&SERVER) OPTION(*IMMED)
0051.00 ENDDO
0052.00
0053.00 CPY OBJ('/notes/yourserver/names.nsf') +
0054.00 TOOBJ('/notes/yourserver/names.rebuilding') +
0055.00 REPLACE(*YES) OWNER(*KEEP)
0056.00 MONMSG MSGID(CPF0000)
0057.00 STRDOMSVR SERVER(&SERVER)
0058.00 DLYJOB DLY(220)
0059.00 SBMDOMCMD CMD('LOAD COMPACT NAMES.REBUILDING -D') +
0060.00 SERVER(&SERVER)
0061.00 DLYJOB DLY(1200)
0062.00 SBMDOMCMD CMD('LOAD FIXUP NAMES.REBUILDING ') SERVER(&SERVER)
0063.00 DLYJOB DLY(9000)
0064.00 SBMDOMCMD CMD('LOAD COMPACT NAMES.REBUILDING') SERVER(&SERVER)

Chapter 2. Administering your Domino environment 49

 0065.00 DLYJOB DLY(600)
0066.00 SBMDOMCMD CMD('LOAD UPDALL NAMES.REBUILDING -T ($USERS) -R ') +
0067.00 SERVER(&SERVER)
0068.00 DLYJOB DLY(1800)
0069.00 SBMDOMCMD CMD('LOAD UPDALL NAMES.REBUILDING -T +
0070.00 ($SERVERACCESS) -R') SERVER(&SERVER)
0071.00 DLYJOB DLY(1800)
0072.00 SBMDOMCMD CMD('LOAD UPDALL NAMES.REBUILDING -T +
0073.00 ($REGISTERGROUPS) -R') SERVER(&SERVER)
0074.00 DLYJOB DLY(300)
0075.00 SBMDOMCMD CMD('LOAD UPDALL NAMES.REBUILDING -T +
0076.00 ($EXTERNALDOMAINNETWORKADDRESSES) -R') +
0077.00 SERVER(&SERVER)
0078.00 DLYJOB DLY(300)
0079.00 SBMDOMCMD CMD('LOAD UPDALL NAMES.REBUILDING -T +
0080.00 ($GROUPS) -R') SERVER(&SERVER)
0081.00 DLYJOB DLY(300)
0082.00 SBMDOMCMD CMD('LOAD UPDALL NAMES.REBUILDING -T +
0083.00 ($LOCATIONS) -R') SERVER(&SERVER)
0084.00 DLYJOB DLY(300)
0085.00 SBMDOMCMD CMD('LOAD UPDALL NAMES.REBUILDING -T +
0086.00 ($SERVERCONFIG) -R') SERVER(&SERVER)
0087.00 DLYJOB DLY(300)
0088.00 SBMDOMCMD CMD('DBCACHE FLUSH') SERVER(&SERVER)
0089.00 DLYJOB DLY(900)
0090.00 CPY OBJ('/notes/yourserver/names.rebuilding') +
0091.00 TOOBJ('/notes/yourserver/names.gnabak') +
0092.00 REPLACE(*YES) OWNER(*KEEP)
0093.00
0094.00 MONMSG MSGID(CPF0000)
0095.00 ENDPGM

Enable view logging where it makes sense

If you have transaction logging enabled on your Domino server, consider the use of view
logging for important views. If a Domino server crashes and view indexes need to be rebuilt,
they can be incrementally rebuilt quickly from the transaction logs instead of being fully rebuilt
manually. This, in essence, reduces server startup time after a crash as well as database
access time after media recovery.

View logging should not be used for every view since there is some performance cost, though
minimal, associated with view logging. The guideline is to only enable view logging where a
real benefit would be realized from doing so. For more information this topic, refer to the LDD
Today article “Assessing the impacts of new transaction logging features” by Jim Powers at:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/c7632f2b5dbbd2658525
6b9d0072b9fb?OpenDocument&Highlight=0,view,logging

Use Domino Designer to enable view logging. In Designer, open a view or folder, select the
Advanced tab, and check “Logging - Include updates in transaction log” at the bottom of the
panel as shown in Figure 2-2. You must enable view logging on a view by view basis.

50 Domino 6 for iSeries Best Practices Guide

Figure 2-2 Enable view logging on the View properties -> Advanced tab

Note: If you enable view logging in a template, all databases created from that template
and all databases whose designs are replaced from that template have those views
logged.

View logging for the $Users and $ServerAccess views in your Domino Directory is set by
default in the Domino Directory template (pubnames.ntf). This enables users to have access
to a server sooner after a server recovery than if the view was not view logged.

Please be aware that customized templates are neither certified nor supported. Standard
practice for Lotus Support for customers who open incidents resulting from a customized
template will be to instruct the customer to revert back to the stock template and see if the
problem still occurs. If it does, Lotus Support will troubleshoot the problem as it exists in the
stock template (in other words they will not troubleshoot the customized template). If the
problem does not exist in the stock template, Lotus Support shall recommend the customer to
remove the modifications and submit an enhancement request of the desired functionality for
the next release.

Use the Extended Directory Catalog for directory consolidation

Lotus introduced the extended directory catalog (EDC) in Domino 5.0.5. EDC replaced the
cascading address book feature in previous versions of Domino. An EDC combines the
advantages of a Domino Directory and a condensed Directory Catalog. It aggregates entries
from multiple Domino directories into a single directory database as does the condensed
Directory Catalog, but it retains the individual documents and the multiple, sorted views
available in the Domino Directory to facilitate quick name lookups. See the Lotus Domino
Administrator 6 Help article entitled “Extended Directory Catalogs” for more information.

LDAP enhancements in Domino 6

Lightweight Directory Access Protocol (LDAP) is a standard Internet protocol for searching
and managing entries in a directory, where an entry is one or more attributes associated with
a distinguished name. Running the LDAP task on a Domino server enables the LDAP service
to process LDAP client requests from clients such as Netscape Mail, Microsoft Internet

Chapter 2. Administering your Domino environment 51

 Explorer, and Lotus Notes clients for tasks such as mail addressing. In Domino 6, you can
also use an LDAP directory for client authentication or for ACL group authorization.

Domino and Notes offer these LDAP features in addition to the LDAP service:
򐂰 Lotus Notes client support for LDAP. For more information, see the Notes 6 Help.
򐂰 A command-line utility called ldapsearch, for searching LDAP directories
򐂰 Migration tools that use LDAP to import entries from another LDAP directory and register
the entries in Domino
򐂰 LDAP C API Toolkit

Tip: The administration server for your Domino Directory automatically runs the LDAP
server task and manages the LDAP schema for the entire domain in Domino 6. You need
to be aware of this if you want to run LDAP on Domino servers other than the
administration server. See the Lotus Domino Administrator 6 Help article entitled “The
LDAP Service” for more information.

For more information, refer to Chapters 20 - 22 in Administering the Domino System,

Volume 1, available at:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602bf85
256b5800681d38?OpenDocument

2.3 ID management
Domino uses ID files to identify users and to control access to servers. Every Domino server,
Notes certifier, and Notes user must have an ID. When you register users and servers,
Domino can automatically create their IDs. While the overall process for creating, managing
and recovering Notes IDs has not changed dramatically in the past few years, the tools and
features available greatly improved.

This section describes the new features regarding creation, management and recovering
Notes ID files in Domino 6 for iSeries. It also identifies several additional resources for your
convenience.

2.3.1 ID file naming standards

We recommend creating and following ID file naming standards. You can use the following
standards or use your own when creating user IDs. We also recommend using consistent
case, preferably all lower case letters, when naming your ID files. This helps ensure proper
management and storage on a file system.

User IDs
We recommend using [lastname + first initial].id for naming user ID files, where the middle
initial is added for unique naming and the last name is contained to the first 7 characters. The
user ID file for John Smithson, for example, is smithsoj.id using this standard.

Server IDs
We recommend using [server name].ID for naming server ID files. The server ID file for the
DOMCHIM01 server is domchim01.id using this standard.

52 Domino 6 for iSeries Best Practices Guide

 Certifier IDs
We recommend using [OU1 Designation + “_” + Organization/Domain] + .id for naming
certifier ID files. The certifier ID file for the Finance OU of the ACME organization is
finance_acme.id.

2.3.2 Creating ID files

You have several options for creating users in Domino 6 for iSeries and V5R2:
򐂰 Domino 6 Administrator client
򐂰 Domino 6 Web Administrator client
򐂰 iSeries Navigator

Domino 6 Administrator client

You can use the Basic user registration in the Domino 6 Administrator client to assign users
basic settings, such as a name and password, and to add users to existing groups. To make
registration fast and easy, Basic registration uses default values for all other user settings.

The Advanced registration option offers all the settings included in Basic registration and also
allows you to change default settings and apply advanced settings to users.

This method does not create an OS/400 user profile for the Domino user.

The most notable change is the “Use the CA process” feature when registering a new user.
This option enables you to specify a certifier without having access to the certifier ID file or
certifier password. See the Domino 6 Administrator Help for more information.

We recommend using these new features if you need them in your environment:
򐂰 Create mail file replicas on all the Domino servers in a cluster.
򐂰 Assign an explicit policy.
򐂰 Assign an appropriate password quality based on your organization’s standards.
򐂰 Set the user’s Internet password and synch it to their Notes password.
򐂰 Set mail file owner access to a maximum of Editor.
򐂰 Set the location to store the ID file: In Domino Directory, in File and/or in mail file.
Storing the Notes ID file in all three locations is sometimes required for business reasons,
though it is not recommended because this practice can greatly complicate your support
procedures.

򐂰 Supply roaming user settings if your organization decides to implement this feature.

Refer to the Domino 6 Administrator Help article “Using Advanced Notes user registration
with the Domino Administrator” for complete information.

You can use the User Registration feature in the Domino 6 Administrator client to create user
accounts that do not require a Notes ID. The Domino 5 Administrator client required you to
create a Notes ID for every user you created with that tool. To disable the automatic creation
of a Notes ID, uncheck the Create a Notes ID for this person field on the Basics tab.

Domino 6 Web Administrator client

In Domino 6, registering users with the Web Administrator client is almost identical to
registering users with the Domino Administrator. Web registration for Notes users requires the
use of the Domino server-based certification authority (CA). You need to understand what the
Domino CA is, as well as how to set it up and use it. See the Domino 6 Administrator Help

Chapter 2. Administering your Domino environment 53

 article entitled “Domino server-based certification authority” for more information on how to
set up this feature.

This method does not create an OS/400 user profile for the Domino user.

iSeries Navigator
From an administrator workstation connected to the iSeries, you can use iSeries Navigator to
create an OS/400 user profile and register the user for Domino at the same time. You can also
use this method to register an existing iSeries user as a Domino user. The workstation used
for this needs a Lotus Notes client connection to the iSeries and an iSeries Access for
Windows connection to the iSeries server. The Other tab on the Domino Registration tab
allows you to specify where to save the user’s ID file.

Tip: To create an OS/400 user profile, your Domino administrator’s OS/400 user profile
must have at least *SECADM special authority. Please remember that you do not have to
create an OS/400 user profile for every Domino user. Create an OS/400 user profile only
for Domino users requiring access to the iSeries via tools such as iSeries Access for
Windows or iSeries Navigator.

Domino for iSeries Single Logon

Domino for iSeries Single Logon is a security feature that provides password synchronization
for users of Microsoft Windows, Lotus Notes, and OS/400. It is different than the multi-server
session-based authentication in Domino, also known as single sign-on (SSO), that allows
Web users to log in once to a Domino or WebSphere server, then access other Domino or
WebSphere servers in the same domain. iSeries Single Logon allows users to log on once
and not have to separately log on to the Lotus Notes client or to iSeries Access. You can
obtain the English version of the Single Logon feature and installation instructions from the
following Web site:
http://www.ibm.com/eserver/iseries/domino/singlelogon.htm

2.3.3 Managing ID files

We mentioned in the Creating ID files section that you have three options for storing the
Notes ID during the user registration process: In Domino Directory, in File and/or in mail file.
The “in Domino Directory” and “in File” options have been standard options for several
Domino versions. Storing the Notes ID in the mail file is new in Domino 6. This option is only
available with iNotes™ Web Access and allows Notes users to read their mail while using
iNotes Web Access.

Tip: We recommend that you keep the new “in mail file” option in mind when creating your
strategy for managing Notes ID files and for supporting user issues with lost IDs or
forgotten passwords.

Storing ID files
Storing and securing Notes ID files can be tedious, but there are several best practices
options depending on the size of your organization, administration resources and business
requirements.

Here are some options for storing and securing Notes ID files for Domino administrators:
򐂰 Store a copy of the most recent ID file with the known password on a secured LAN drive.
Users retain the current name, certificates and encryption keys associated with the ID
when you restore their ID files using this option.

54 Domino 6 for iSeries Best Practices Guide

 򐂰 Store the original ID file with the original password on a secured LAN drive. Users lose all
name changes, certificates and encryption keys when you restore their ID files using this
option.
򐂰 Store the original ID file or a copy of the most recent ID file in a Lotus Notes database.
This option has the same advantages and disadvantages of the previous two options, but
there is a risk that you could not access the database if the Domino server is down.
򐂰 Store the ID files on the iSeries. This option has the same advantages and disadvantages
of the option above. You can take complete advantage of the iSeries security to restrict
access to these files. Refer to Appendix D in IBM Lotus Domino 6 for iSeries
Implementation, SG24-6592 for instructions for copying files to the iSeries.

We recommend that you exercise great care in sending a Notes ID and password to a user.
The file contains the user’s identity in your Domino environment. Prevent unauthorized use of
the Notes ID by using a consistent, secure procedure, for example, sending the Notes ID and
password to the user’s manager.

2.3.4 Recovering ID files

To recover from loss of, or damage to, an ID file, recommend that your users keep a backup
copy of their ID file(s) in a secure place. For example, on a disk stored in a locked area.
Requesting the ID file from the Domino administrator is the next level of recovery. To prevent
problems that occur when users lose or damage ID files or forget passwords, set up Domino
to recover ID files.

We recommend that your organization designates several administrators who will act as a
group to recover IDs and passwords. We recommend having two or more administrators work
together to recover ID files instead of a single administrator. Designating a group of
administrators helps to prevent a breach of security by one administrator who has access to
all ID files. You can specify that only a subset of the group be present during the actual ID
recovery.

Before you can recover ID files, an administrator who has access to the certifier ID file must
specify recovery information, and the ID files themselves must be made recoverable. You can
set up ID recovery for user IDs at any time. If you do so before you register users, ID recovery
information is automatically added to user IDs the first time that users authenticate with their
home servers. If you set up ID recovery information after you have registered Notes users,
recovery information is automatically added to the user IDs the next time users authenticate
with their home servers.

Caution: If your users will be enabling Smartcards to use with their Notes IDs, set up ID
recovery information for these IDs before any Internet keys are pushed onto the
Smartcard. Otherwise, the ID file recovery process will not be able to restore those keys.

Here are some resources that include step by step instructions:

򐂰 Domino 6 Administrator Help topics “ID recovery”, “Setting up ID recovery“, “Preparing IDs
for recovery” and “Recovering an ID”
򐂰 “ID and password recovery” by Timothy Speed and Mary LaRoche from the Iris Today
Archives Web site at this URL:
http://www.lotus.com/ldd/today.nsf/f01245ebfc115aaf8525661a006b86b9/2bc078be1aa60952
85256af70059dd3a?OpenDocument

Chapter 2. Administering your Domino environment 55

2.3.5 Roaming users
A new feature in Domino 6.0.1 enables users to access Notes with their customized settings
and personal information automatically from any Lotus Notes client in the domain. Data for
these users, known as roaming users, replicates between the user's machine and a roaming
user server, where these files are stored. When a roaming user logs on from a different Lotus
Notes client, it automatically retrieves the user's ID file, Personal Address Book, bookmarks,
and journal from the roaming user server. Any changes the user makes in these files replicate
to the roaming user server. This enables the roaming user to have a consistent experience
from any Lotus Notes client.

We mention the roaming user feature in this section because it can add another level of
complexity to managing ID files in your Domino 6 environment. The ID file can be stored on
the roaming user server or in the user’s Personal Address Book. Please be aware of this
issue when resolving ID file issues for roaming users.

2.3.6 Additional recommendations

We recommend that you configure and test the password verification and the new security
settings features in Domino 6.

Password verification
You can enable password verification so that a Notes user can authenticate with a server only
after providing the correct password that is associated with the user ID in the Person
document. If an unauthorized user obtains an ID and learns the ID's password, the owner of
the ID can use password verification to change the password and prevent the unauthorized
user from continuing to use the ID to authenticate with servers.

We recommend using this feature in scenarios such as an administrator leaving your

organization, but you cannot delete or disable the user account due to signing or
configuration issues. You can enable password verification and set a specific password for the
ID file in the Person document. Only the ID file with the correct password can access the
Domino environment.

Password verification is also used in conjunction with security policy settings to enforce an
organization’s password expiration and password quality policies. Domino 6 provides
features such as change/grace intervals and expiration intervals.

Restriction: You must disable password checking, change/grace intervals and expiration
in the user's Person document for Notes users set up to use Smartcards. Otherwise,
Smartcard users will eventually be locked out.

Refer to the Domino 6 Administrator Help topic “Verifying user passwords during
authentication” for more information.

Security policy settings

You can control how users work with Notes by using a policy or multiple policies. A policy is a
document that identifies a collection of individual policy settings documents. Each of these
policy settings documents defines a set of defaults that apply to the users and groups to
which the policy is assigned. Once a policy is in place, you can easily change a setting, and it
will automatically apply to those users to whom the policy is assigned.

Use security settings to set up administration ECLs and define password-management

options, including the synchronization of Internet and Notes passwords. Be careful using

56 Domino 6 for iSeries Best Practices Guide

 policies in a mixed release environment. Policies are not supported from a Domino 6 server to
Notes Release 4 clients. There is limited support for archiving and registration settings from a
Domino 6 server to Notes R5 clients.

Refer to the Domino 6 Administrator Help topic “Creating a security policy settings document”
for more information.

2.4 Managing your Domino templates

We recommend that you read two LDD Today articles that describe the best practices for
managing Domino templates. There are some new features in Domino 6 that can help you
manage your environment more efficiently by managing templates more efficiently. Please
refer to the following articles for more information:
򐂰 The Trouble with Templates, Part 1 by David Byrd and Timothy Speed, available at:
http://www.lotus.com/ldd/today.nsf/a2535b4ba6b4d13f85256c59006bd67d/f7d87dd9a0cd75f4
85256d7100564ea5?OpenDocument
򐂰 The Trouble with Templates, Part 2 by David Byrd and Timothy Speed, available at:
http://www.lotus.com/ldd/today.nsf/a2535b4ba6b4d13f85256c59006bd67d/4f985c009c77293e
85256d91004f1aa6?OpenDocument
򐂰 You can also refer to the LDD Today article entitled Enhancements to Notes/Domino 6.0.1
and 6.0.2 for descriptions of all the latest template features. It is available at:
http://www.lotus.com/ldd/today.nsf/9148b29c86ffdcd385256658007aaa0f/aa8e5890daeef5e2
85256cd40062831a?OpenDocument

2.5 Mail file management

The storage of large amounts of e-mail impacts the performance and scalability of a
corporate messaging system. All e-mail systems, regardless of vendor, are nothing more than
highly specialized databases. The more data stored in these databases, the slower the basic
operations of these systems become and the approach to system scalability becomes limited.
These databases not only store electronic communications, but documents, calendars,
address books, and valuable intellectual capital. All of these entries are constantly indexed to
increase performance, and as more entries are created, it takes longer to perform common
e-mail tasks, such as delivery of messages into the message store, as well as opening and
searching messages.

By not limiting and controlling the current mail environment through implementation of a mail
retention policy, you are at risk of experiencing the following difficulties:
򐂰 Significant impacts to system performance and administration.
򐂰 Significant redundancy of data and duplication of storage requirements, resulting in higher
hardware and administration costs (higher total cost of ownership (TCO)).
򐂰 Losing critical intellectual capital to the organization by managing valuable information to
the business in individual mail files. Data is lost to the organization as users delete mail or
leave the organization.
򐂰 Inefficient sharing of intellectual capital. Critical business information is not available to
others who may require this information – current intellectual capital is only accessible by
individuals in their own mail file.

Chapter 2. Administering your Domino environment 57

2.5.1 Enterprise mail management policy
Many organizations are moving to a mail retention policy. There are many reasons for this
move, including cost reductions, legal liability, SEC requirements, and more efficient data
management (to mention a few). An Enterprise Mail Management policy dictates within the
organization how messages should be maintained and for how long. It defines the rules for
both the organization’s IT organization and the user community on what constitutes business
related e-mail messages as well as the disposition of those messages. An effective policy
statement will include identification of how the organization’s messaging system should be
used by users, identifies both internal and external requirements for how long messages
should be maintained, and how those messages are purged from the system.

Mail retention policies typically address one or both of the following situations:
򐂰 Preserving key corporate data for an appropriate length of time.
򐂰 Deleting data that has outlived its usefulness and that is taking up needed disk storage
space.

When the policy is aimed at keeping disk consumption to a minimum, often an automated tool
is employed to enforce the policy, since users typically do not clean up old mail on their own.
This tool may operate on criteria such as document age, document size, content (for example,
no MP3 attachments allowed), document type, or overall mail file size. In addition, alternative
document management mechanisms are typically provided for storage of critical information
that should be made available to the organization as a whole.

Example: Mail retention and intellectual capital collection concept

Figure 2-3 shows an example of a storage system designed for retaining mail in a searchable
archive. Such solutions are used at many organizations where strict retention requirements
are mandated by the business.

Mail Retention and Intellectual

Capital Collection Concept

Record Categorization

Mail Files
Data
Data
Document Mgt
System Sync Mail Quota
(for example Engine Enforcement
Domino.Doc) Data

Data
Data
Retention Conditions
Database

User Community

Figure 2-3 Mail retention and intellectual capital collection concept

58 Domino 6 for iSeries Best Practices Guide

 Considerations
You should carefully examine an approach to mail retention and evaluate common tools that
will provide a better solution to accessing intellectual capital and storing mail data within the
organization. A common approach to establishing a mail retention policy involves:
򐂰 Working with business leaders to establish requirements and gain sponsorship.
򐂰 Creating the business policy.
򐂰 Creating the technical policy to enforce the business policy (for example, 90 day retention,
100 MB mail file quota).
򐂰 Deciding on whether to delete mail, save it to archival storage (delete versus save), or
store it in a document management system.
򐂰 Determining mechanisms for storage and archival of mail and intellectual capital.
򐂰 Education of the user community. If the policy includes acceptable use provisions, then it
is wise to have it become a signed document that becomes part of each user’s personnel
file. Users should understand that the policy comes from the business leadership.

2.5.2 Mail policy implementation

To implement the mail policies, you can use Domino 6 configuration document settings, mail
file quotas, and IBM or third party tools. To offer the user a more structured alternative to
excessive mail use, an archiving and an oversize mail solution needs to be implemented.

Archiving mail
The objective is to separate the active mail from the old mail. This requires the use of two mail
files. The active mail file should be small in size, so it can more easily be managed and so the
indexer does not take much resource every time new mail is delivered. The archive mail file
should only be accessed whenever an old e-mail needs to be retrieved. This means that you
will see low user activity on this mail file. As this mail file does not require immediate updates,
the load of the indexer is limited as well.

Tip: Archiving the active mail file to an archive mail file on the same server is not
recommended. Though the archive mail file does not take up as many resources as the
active mail file, maintaining the indexes and doing full text searches by the user still require
server resources. We suggest putting the archive mail file on a server dedicated for mail
archiving or archiving mail on the local workstation.

The most important question to ask is, which messages should be moved to the archive file,
and which should not. To keep things simple, on the active mailbox you can set a cutoff date,
for example, 60 days. You can then have a replica of the mail file on a Domino server which is
dedicated to storing archiving mail files, or you can let the user store the archive mail file on
the local hard drive. In the latter case, backup of the archive becomes more tedious. For this
reason, this section assumes that you are placing the archive on a dedicated Domino server.
The mail file stored on this server does not have a cutoff date set. Because deletions that are
made by a cutoff date do not replicate, they are not removed from the archive file.

The replication schedule between the mail server and the archive mail server (or the personal
replication schedule, in the case of a local copy) can be set to replicate only once a day, or
even less frequently. This prevents the users from only using their archive mail, because their
most recent messages will not be in there. This is why one archive mail server can service
many regular, or active mail servers. Also, if you make this a billable service, not everyone
would require this, which would lower the number of required archiving servers.

Chapter 2. Administering your Domino environment 59

 Quotas on mail files
On both, active and archive mail files, it is advisable to use quotas to enforce the SLA-agreed
maximum sizes. To set a quota on one or more databases, follow these steps:
1. Start the Domino Administrator client.
2. Click File ->Open Server.
3. Enter the name of the server where the databases you want to set the quotas on reside
and click OK.
4. Click Files and select the databases for which you want to set the quota.
5. Click Tools ->Database.
6. Select Quotas.
7. You can now set the quota for all selected databases.

The example in Figure 2-4 sets the database quota to 50 MB and the warning threshold to
40 MB.

Figure 2-4 Setting a database quota and warning threshold

In Domino 6, you have three options for the action taken when a quota is exceeded:
򐂰 Deliver anyway (don’t obey quotas): Mail will be delivered to the user’s mail file
regardless of the mail file size.
򐂰 Non-deliver to originator: Messages are returned to the sender with a delivery failure
notification. The notification states that the recipients mail file has exceeded the quota.
򐂰 Hold mail and retry: The Router temporarily holds incoming messages in MAIL.BOX until
space is available in the mail file. Messages that cannot be delivered before the
configured expiration time (default =1 day) are returned to the sender as undeliverable.
You can specify how the server handles held messages.

60 Domino 6 for iSeries Best Practices Guide

 Note: We do not recommend using the last option, “Hold mail and retry” since it could
severely affect your Router performance and bloat your MAILxx.BOX files. Give your users
adequate time between the warning threshold and the database quota to clean up their
mail files, then run proper database maintenance to prevent undeliverable messages due
to exceeding the database quota.

We recognize from our experience in real world situations that there are exceptions to every
rule, especially mail database quotas. The policy-based management feature in Domino 6
offers more flexibility for setting and enforcing mail database quotas than in previous Domino
releases. We recommend creating mail database policy settings for each type of user in your
organization. For example, executives, knowledge workers, graphics designers, and
administrative support staff have different business requirements for mail file size. If you can’t
create settings and policies to address the specific needs of your users, consider the options
below or a combination of options to accomplish the best practice of managing mail file size.

Handling attachments
The main reason that mail files grow so large is the use of attachments. Even though e-mail is
not designed to be a file transfer system, it is often used as such. This does not need to be a
problem. However, users often do not detach the files from their messages once they have
received them. This leads to large mail files and also larger messages when the “reply with
history” button is used.

The most effective way to address this issue is to train users to not include attachments on
their reply e-mails, by using one of the following menu options or buttons:
򐂰 Actions -> Reply -> Reply without Attachment(s)
򐂰 Actions -> Reply to All -> Reply without Attachment(s)
򐂰 Reply -> Reply without Attachment(s)
򐂰 Reply to All -> Reply without Attachment(s)

Some organizations use custom agents to remove attachments from e-mails in a mail file.
There are many possibilities for this solution, including deleting all attachments from e-mails,
saving attachments locally and deleting, and deleting all e-mails with attachments. If your
organization pursues this option, consider writing the application outside of the mail file so
you do not have to modify your standard mail template.

Single Copy Object Store (SCOS)

To use disk space more efficiently, you can set up shared mail on each mail server after you
set up the Domino mail system. Shared mail, sometimes referred to as the Single Copy
Object Store (SCOS), offers an alternative to message-based mail, allowing servers to store a
single copy of messages received by multiple recipients in a special central database, or
object store. Every server using shared mail contains one or more of these object stores, or
shared mail databases, to hold all shared messages.

After you enable shared mail on a server, all mail databases on the server automatically use
the shared mail database to store the content of new messages, unless you explicitly exclude
a database from using shared mail. You do not need to configure each user's mail file
individually for shared mail use. You can refer to the Domino 6 Administrator Help topic
“Shared Mail Overview” for more information on this feature. However, this feature is not
widely used because it adds an additional level of complexity to your environment.

Chapter 2. Administering your Domino environment 61

 Using message restrictions in configuration documents
From the server configuration document, you can set various restrictions:
򐂰 From the Router/SMTP -> Restrictions and Controls -> Restrictions tab, you can set the
maximum message size and the sizes of messages that you want to force to low priority.
The configuration shown in Figure 2-5 defines a Maximum message size of 10 MB. All
messages between the size of 5 MB and 10 MB will be sent as low priority automatically.
If you want to set the maximum message size for Domino Web Access (iNotes) users, you
must set the Maximum Post Data (in kilobytes) field on the Domino Web Engine section of
the Server document and the Maximum size of request content field under HTTP Protocol
Limits on the HTTP section of the Internet Protocols tab. The default setting for these two
fields is 10 MB. These two settings can be increased or decreased to control the size of
e-mail attachments for Domino Web Access (iNotes) users in Domino 6.

Figure 2-5 Router/SMTP — Restrictions and Controls — Maximum message size

Tip: The value after the word “and” is a computed field equal to the Maximum message
size. If you still see a zero after the “and”, press <F9> to recalculate the value.

򐂰 On the Router/SMTP -> Restrictions and Controls -> Transfer Controls tab, you can set
times at which low priority messages should be routed. The example in Figure 2-6 shows
that low priority messages will be routed between 12:00 AM and 6:00 AM. We also
recommend changing the value of the Low priority delay notification field to “Only if priority
changed for policy reasons”. The sender then receives a notification that the Domino
server changed the e-mail to low priority because of a policy put in place by the Domino
administrators.

62 Domino 6 for iSeries Best Practices Guide

Figure 2-6 Router/SMTP — Restrictions and Controls — Transfer Controls for low priority mail

򐂰 There is a mail rule in Domino 6 that detects e-mails being sent to a large number of
users. You can setup this mail rule in the server configuration document on the
Router/SMTP -> Restrictions and Controls -> Rules tab. With the server configuration
document in Edit mode, click the New Rule... button. Figure 2-7 shows an example of a
rule that changes the routing state of an e-mail to held if it is sent to more than 50
recipients.

Figure 2-7 Example of a mail rule for e-mails with more than 50 recipients

Chapter 2. Administering your Domino environment 63

 Restriction: The recipient count rule counts the number of Notes recipients and SMTP
recipients separately. If either count is greater than the limit specified in your rule, then the
rule is executed. Domino does not compute the combined total of Notes recipients and
SMTP recipients. Please be aware of this when creating a recipient count rule.

Mail management tools

There are several (third party) tools and applications available to assist you in enforcing your
mail usage SLA. We included references to the following products, though the list is by no
means exhaustive.
򐂰 The ISSL Domino Mail Manager asset:
IBM Software Services for Lotus (ISSL) offers an asset that provides an enterprise with a
tool that can assist in managing the message store. Domino Mail Manager was designed
to help enterprises manage their Domino mail servers by providing the capabilities to
capture messages for archiving, purging messages that have met retention requirements,
purging duplicate attachments from a single users mail file, and purging large attachments
from the mail file. This asset is sold as a Service offering.
򐂰 CommonStore for Lotus Domino:
CommonStore for Lotus Domino is part of the IBM Content Manager portfolio of products.
CommonStore provides the capabilities to allow users to store message content in the
Content Manager solution from IBM. This includes single documents, file attachments, or
entire folders. The archived content is easily accessible from the Lotus Notes client.
Content can also be indexed and searched through the addition of the IBM Lotus
Discovery Server™. Additionally, the ISSL Domino Mail Manager asset also integrates
with Common Store allowing for automated message archiving.
As of this writing, IBM Content Manager CommonStore does not run natively on the
iSeries. You must run it on an external Intel server or on an IXS/IXA.
See the following redbook and Web site for more information:
– IBM Content Manager CommonStore for Domino, Exchange, and SAP, SG24-6405
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246405.html?Open
– DB2 CommonStore for Lotus® Domino Web site at
http://www.ibm.com/software/data/commonstore/lotus/
򐂰 IBM Tivoli Storage Manager:
Tivoli Storage Manager is IBM’s enterprise backup solution. When integrated with Tivoli
Data Protection for IBM Lotus Domino, it allows organizations to capture the entire
message store and store it on backup media such as magnetic tape and optical storage.
IBM Tivoli Storage Manager server can also be integrated with IBM CommonStore to
allow for further off loading of Content Management data.
򐂰 IBM Lotus Document Manager (Domino.Doc):
The IBM Lotus Document Manager software is an Enterprise Document Management
system based on the Domino platform. Using Document Manager in conjunction with an
Enterprise Mail Management strategy allows an organization to deploy a highly robust
content store for archived messages and key Intellectual Capital. Messages can be moved
from the users mail file and stored in the Document Manager store allowing it to be
indexed as well as providing for full text search capabilities. Document Manager can be
augmented with Domino Mail Manager to provide for an automated solution for capturing
messages and storing them in a searchable archive. Finally, IBM Tivoli Storage Manager
server can be deployed to further off-load message content to magnetic tape and WORM
media.

64 Domino 6 for iSeries Best Practices Guide

 򐂰 Search for an IBM Business Partner or solution on the IBM PartnerWorld® Web site at:
http://www.developer.ibm.com/bpconnections/bpcms.nsf/Public.FindaBP?OpenForm&NL=en
򐂰 Sherpa Software’s Mail Attender:
http://www.sherpasoftware.com/MANotesOverview.shtml
򐂰 Avalon Business Systems’ ReduceMail Pro:
http://www.reducemail.com
򐂰 Percussion ServerAdmin Plus Web site:
http://www.percussion.com/products/saplus/index.htm
򐂰 Search the Lotus Sandbox using the keyword “mail” to find tools, sample code, and
databases that you can incorporate into your environment:
http://www.lotus.com/ldd/sandbox.nsf/e7425656e0c80508852567540065d7f9/$searchForm?
SearchView

2.6 Maintaining your Domino environment

This section describes best practices for maintaining your Domino environment. It includes:
򐂰 Recommended maintenance schedule
򐂰 System databases
򐂰 Change management
򐂰 Tips for using the Domino Administrator client
򐂰 IBM iSeries Access for Windows and iSeries Navigator tips

2.6.1 Recommended maintenance schedule

A major part of every Domino administrator’s job is maintaining the Domino servers. You
need to ensure that:
򐂰 The server is backed up regularly.
򐂰 Users can access the server quickly and consistently.
򐂰 Mail is routed properly.
򐂰 Administration Process requests are carried out.
򐂰 Databases are replicating correctly.
򐂰 Server hardware is functioning.
򐂰 Databases are active and maintained (a task you share with the manager of each
database).

Daily monitoring checklist

You should perform the following tasks on a daily basis:
1. Check server accessibility and availability:
– Check that all required services on the Domino servers are running.
– Ping the servers’ IP address.
– Use a server monitoring tool, such as Tivoli, Percussion, or DYS, to check for server
availability outages.

Chapter 2. Administering your Domino environment 65

 2. Review the STATISTICS database:
This database should be leveraged to see day-to-day activity and should be visited right
after server accessibility:
– Look at the Alarms view:
This view provides a snapshot of alarms generated by Notes, based on the threshold
settings defined in the Statistics Monitoring. Information logged here is the most critical
to examine first. Define a procedure for follow-up on these areas such as trouble
tickets or some other follow-up mechanism.
– Look at the Events view:
This view provides a snapshot of threshold events based on the Statistics Monitoring
defined above. Define a procedure for follow-up on these areas such as using trouble
tickets or some other follow-up mechanism.
3. Review the Notes Log database:
– Review all views:
Use the Log Analysis tool to search these views effectively. Define search strings
specific to problems such as process starts and stops, failed processes or error
conditions, corruption problems, network problems, agent manager problems, security
problems, SMTP problems.
– Replication events views:
You should focus on the Replicator initiating server, for example the replication hubs.
Use the Notes search tool to find problem areas such as failed replications due to ACL
issues, server availability and network problems.
– Mail Routing Events view:
Generally this view only needs to be looked at if you have known mail delivery
problems such as Domino-to-Domino mail routing or Domino-to-Internet mail routing.

Tip: Use the Domino 6 Web Administration Tool if you prefer to view the above information
in a graphic representation.

4. Check MAIL.BOX(es) on all servers:

Look at Pending or Dead mail, although the Statistics & Events should have captured this
first. Perform a Refresh on the Database to make sure that mail is moving.
5. Server tasks:
First ensure that all general tasks that all servers need are running, then look at:
– Mail server(s) specifically
– SMTP mail server(s) specifically
– Application server(s) specifically
– Review tasks either through the Domino 6 Administrator or using a 5250 emulation
screen.
– Use a Web browser to make sure that access to the HTTP process for mail is working.
6. Did daily backups complete successfully?
Incorporate a Backup Matrix that shows what backups went successfully.

66 Domino 6 for iSeries Best Practices Guide

7. Check SMTP mail routing — test that SMTP mail is functioning properly:
– Check Internet to Domino/Domino to Internet mail routing. Use an account originating
from each Notes Named Network (validate $MIMEtrack in Document properties to
track server hops).
– Check that Internet mail can be held in mail queues. Check the MAIL.BOX(es) on the
Domino SMTP servers for dead or pending mail. Domino monitoring can be leveraged,
for example, configure the Domino events monitor to notify your administrators if there
are more than 500 e-mails pending in a MAILx.BOX on your Domino SMTP server.
– Check Mail queues on Internet mail relay servers.
– Check Mail queues on Virus Scanning SMTP servers.
8. Check daily server downs:
Recycle Domino servers to maintain performance. This is not as necessary on the iSeries
platform as on other Domino platforms.

Weekly server tasks

You should perform the following tasks on a weekly basis:
1. Monitor disk space utilization and consumption patterns:
Log weekly the amount of used versus free disk space for charting. This will show disk
space consumption trend activity — when to add more disk space or reduce file sizes.
Make sure threshold values have been set using Statistics Monitoring. The OS/400
commands for monitoring disk space utilization are listed in “Ten minute checklist for
spotting performance problems” on page 122.
2. Weekly Domino server backups:
– Verify that all backups completed successfully during the week. Note any backup
problems — have a process for follow-up on backup issues.
– Check that backups are stored offsite.
– Check if replication between recovery servers and mail servers has completed
successfully.
3. Database maintenance routines:
– Check to make sure all FIXUP, UPDALL, and COMPACT routines have run
successfully. See “FIXUP” and “COMPACT” on page 68 for more information about
these two tasks. Look for databases that need maintenance, for example, check the
Database/Sizes view in the Notes Log to see %Used and database size. Use
COMPACT and UPDALL on databases with more than 10% white space, identified as
databases with less than 90% Used.
– Verify that the Design task ran successfully. Verify that there are no missing templates.
4. Check server statistics for performance and availability:
Look at server health using whatever tool(s) available. Check statistics for disk
consumption and mail usage (Domino and SMTP) to identify trends and devise proactive
plans for maximizing performance and availability.
5. Cluster analysis:
Run the Cluster Analysis in the Domino 6 Administrator weekly to find out problems. The
most common issue is to make sure that all replicas exist on the correct servers. Run
Cluster Analysis from the Server -> Analysis tab in the Domino 6 Administrator. Click
Tools -> Analysis -> Cluster on the right hand side of the window to display the Cluster
Analysis prompt window. Select the appropriate options for your analysis, then review the
output.

Chapter 2. Administering your Domino environment 67

 6. Messaging usage:
– Document the number of inbound and outbound Internet messages delivered and the
size of messages, including message transfer times. It is important to understand when
messages leave your site to the Internet domain to verify you meet the SLA established
with your user community.
– Document the number of Notes messages delivered and the size of messages. You
need this information for planning and proactive actions required for your environment.
7. Agent monitoring

Monthly server tasks

You should perform the following tasks on a monthly basis:
1. Scheduled server downtime:
– Perform any activities that require a server to be down, for example, installing a PTF.
– Perform database maintenance on the NAMES.NSF, BUSYTIME.NSF, CATALOG.NSF,
NOTES.LOG, CLDBDIR.NSF databases using Run Domino Command
(RUNDOMCMD). For information on RUNDOMCMD please see “Running Domino
tasks when the Domino server is not active” on page 84.
– Perform MAIL.BOX maintenance. Rename the mail.box(es) to mail.old, then let the
Domino server create new mail.box(es) when it restarts. Copy any undelivered
messages to the new mail.box(es).
2. Review recurring problems:
Develop action plans to address any recurring problems in your environment or make
plans to avoid potential problems.
3. Test backups and the validity of data restoration:
Check for good data restoration. Verify if it can be used effectively and reliably.
4. Review monthly server statistics for performance and availability:
Look at server health using whatever tools are available. Check statistics for disk
consumption and Notes and SMTP mail usage to identify trends and devise proactive
plans for maximizing performance and availability.
5. Run a Cluster Analysis:
Run a monthly Cluster Analysis in the Domino 6 Administrator to uncover any problems
not previously identified in the weekly analysis. Identify trends and devise proactive plans
for maximizing performance and availability, if needed.

FIXUP
If a corrupted database is in Domino 6 format and you are not using transaction logging, you
can use the FIXUP task to repair it. If the database is in Domino 6 format and you are using
transaction logging, you must use the -J option with the FIXUP task to repair the corrupted
database, then back up the database immediately afterwards, since the database instance ID
(DBIID) has changed. In Domino 6, you will receive the following message if you try to run
FIXUP on a logged database without the -J option:
Recovery Manager: Preserving backups by skipping fixup of logged DB without -j switch,
DB=/LOTUS/DATA/DOMBRMS/admin4.nsf

COMPACT
When documents and attachments are deleted from a database, Domino tries to reuse the
unused space, rather than immediately reducing the file size. Sometimes Domino is not able

68 Domino 6 for iSeries Best Practices Guide

 to reuse the space or, because of fragmentation, can't reuse the space effectively until you
compact the database. There are three styles of compacting:
򐂰 In-place compacting with space recovery:
This style of compacting recovers unused space in a database but does not reduce the
size of the database on disk. Databases retain the same DBIIDs, so the relationship
between the compacted databases and the transaction log remains intact.
This style of compacting is used on all databases enabled for transaction logging when
you run COMPACT without specifying any options. Domino also uses this style when you
use the -b option (case sensitive) when compacting any database.
We recommend that you use this compacting method the most frequent since it is the
fastest method and causes the least system impact. We recommend creating a program
document to run COMPACT -b nightly with the -S 10 option. When you specify -S 10,
databases with 10% or more recorded unused space are compacted.
򐂰 In-place compacting with space recovery and reduction in file size:
This style of compacting reduces the file size of databases as well as recovers unused
space in databases. New DBIIDs are assigned to logged databases.
We recommended that you run COMPACT using the -B option on all databases once a
week to optimize disk space. You can use the -S option with this command as well. Use a
certified backup utility to perform full backups of the databases shortly after compacting
has completed.
򐂰 Copy-style compacting:
This is the slowest of the three styles of compacting. Copy-style compacting first creates
copies of databases and then deletes the original databases after compacting completes,
so extra disk space is required to make the database copies.
Domino uses copy-style compacting under the following circumstances:
– By default, when you use a COMPACT option to enable a database property that
requires a structural change to a database
– When you run COMPACT on a database that has a structural change pending that was
initiated from the Database Properties box
– When upgrading the ODS of a database
You usually run copy-style compacting in conjunction with FIXUP and UPDALL -R when
repairing databases.
Copy-style compacting of logged databases (using the -c option) assigns new DBIIDs so
you need to perform full backups of these databases shortly after compacting completes.

2.6.2 System databases

A number of system databases record information that can indicate possible system
problems:
򐂰 The Log file (LOG.NSF) records server-specific information on replication, mail routing,
database activity, and network and modem communications.
򐂰 The Domino Web server log (DOMLOG.NSF) and the Web server log files
(ACCESS-LOG, AGENT-LOG, REFERER-LOG, ERROR-LOG, and CGI-ERROR-LOG)
contain information about Domino Web server requests and commands.

Tip: Domino does not automatically maintain the Web server log files generated by the
HTTP task. You need to remove the files as part of the weekly maintenance tasks.

Chapter 2. Administering your Domino environment 69

 򐂰 The Administration Requests database (ADMIN4.NSF) posts all requests associated with
the Administration Process.
򐂰 The server mailbox (MAIL.BOX) contains dead and pending mail. There may be more
than one MAIL.BOX file.
򐂰 The Statistics database (STATREP.NSF) contains reported events and statistics.

Tip: We recommend that you monitor for NSD objects in your environment. This is
especially important on the iSeries because Domino servers usually restart automatically
after a crash. Refer to “Domino server crashes” on page 581 for more information.

2.6.3 Change management

We strongly recommend that you implement a change management process in your
organization regardless of the size or complexity of your Domino environment. Documenting
changes is extremely helpful in tracking down potential issues and for sharing knowledge on
the Domino and iSeries administration teams. Here is the basic process:
򐂰 Document changes on a change control request form.
򐂰 Review changes with appropriate team members and management.
򐂰 Get approval for each change and any system outages required for it.
򐂰 Communicate the system outage window to the user community.
򐂰 Perform change; document results; perform backout plan if needed.

Document changes on a change control request form

Create a change control form that makes sense for your organization. Some larger
organizations often need a more complex form or more detailed information than small or
medium size organizations, depending on the organizational structure. A simple form
contains this necessary information:
򐂰 Who: Who is implementing or making the change?
򐂰 What: What are you changing? What exact steps will you perform for the change?
򐂰 Why: Why do you want to make this change? Include benefits to the organization.
򐂰 When: What is the schedule for the change?
򐂰 Where: What server or servers require the change?
򐂰 Backout plan: How will you reverse or backout of the change if it fails?
򐂰 Results: What were the results of the change? Did you encounter any problems?

Review changes with appropriate team members and management

Review the change control document with your management and appropriate team members
such as the iSeries team, the network team, the help desk organization(s), and other
stakeholder groups when appropriate. Do not overcomplicate this step. For changes such as
point release upgrades that will fix server issues, this step is primarily informational.

Get approval for each change and any system outages required for it
We recommend getting management approval for each change. Management usually likes to
know if their phone might ring because of a system change or outage. Verify that a system
outage, if required, does not disrupt crucial business functions like monthly or quarterly close
for the accounting department or deadlines for the sales department. You want the outage to
negatively affect as few users as possible. We recommend making changes during regularly
scheduled outages when possible. Use caution in making too many changes at one time.

70 Domino 6 for iSeries Best Practices Guide

 Communicate the system outage window to the user community
After obtaining management approval for a system outage, if you cannot make the change
during a scheduled outage, communicate the system outage window to the user community.
Many organizations work closely with their help desk(s) for this communication. We
recommend posting this on your intranet site as well.

Perform change; document results; perform backout plan if needed

Perform the change during the scheduled time. Document the exact steps you performed,
especially noting any additional steps that you did not list in the change request document.
Use this information to improve your planning for future change request documents.

Since you planned and tested this change, hopefully you will not have any issues. That is a
nice thought, but issues may arise. If the change failed or did not work as expected, execute
the backout plan you documented in the change request form. Verify that your server(s) work
as expected after rolling back the change. Document the issue or issues you encountered.
Use this information to improve your planning for future change request documents.

Tip: Many companies use a simple Lotus Notes database to document and track change
requests. You can also use the workflow features of Lotus Notes to automate the approval
process.

2.6.4 Tips for using the Domino Administrator client

Here are several tips for using the Domino Administrator client to help you be more efficient in
maintaining your Domino environment.

Set up your Administrator preferences

Within the Domino Administrator client, you can set preferences to reduce the repetitive entry
of frequently used settings. Access the Administration preferences window by clicking File ->
Preferences -> Administration Preferences for viewing or editing. We recommend setting
these preferences:
1. Basics preferences: Default domain, domains to manage and Domino Administrator start
up options.
2. Files preferences: Customize which columns appear, the order they appear and limit the
files displayed.
3. Monitoring preferences: Set the default monitoring preferences.
4. Registration preferences: Set default registration preferences that apply whenever you
register new certifiers, servers, and users.
5. Statistics preferences: Set statistics preferences to enable statistics reporting and
statistics charting.

Refer to the Domino 6 Administrator Help topic “Setting Domino Administration preferences”
for more information.

Use Domino server console commands and command abbreviations

For administrators who prefer a command line interface, the console commands and
command abbreviations are a quick and efficient way to perform administration tasks or
gather information about their Domino environment. There is an abbreviation for every
Domino server console command that makes entering the command easier. Refer to the
Lotus Domino Administrator 6 Help article entitled “Domino server commands” for a complete
listing of commands.

Chapter 2. Administering your Domino environment 71

 The help text identifies the abbreviation for each command through underlined letters. For
example the underlined letter “B” for the Broadcast command indicates that you can enter
either <B “your message” >or <broadcast “your message”> at the console to send a
broadcast message.

Use the Server Tasks tab

If you prefer a GUI interface, use the Server -> Status -> Server Tasks view in the
Administrator client to stop, start, and restart tasks. You can also perform actions like initiating
replication, routing mail, securing the console, and shutting down and restarting the server.

Send the same command to multiple servers simultaneously

There is a new feature in the Domino 6 Administrator client that enables you to send a
Domino server console command to multiple servers or a server group at one time. This is
very convenient for commands that need to be sent to all servers on a regular basis. To use
this feature, do the following steps:
1. Maneuver to the Domino server console on one of your servers in the Domino 6
Administrator client.
2. Type in the command you want to send to multiple servers, such as TELL ROUTER QUIT.
3. Fill in the fields on the Send Command to Select Servers window, as demonstrated in
Figure 2-8.

Figure 2-8 Send command to multiple servers

4. Click Send.
You can also create server groups that you can use for sending commands instead of
selecting the servers individually each time. See the Domino 6 Administrator Help topic
entitled “Sending commands from the Domino Administrator console” for more information.
We recommend creating server groups by function, for example MailServers or HubServers,
to take full advantage of this feature.

72 Domino 6 for iSeries Best Practices Guide

2.6.5 IBM iSeries Access for Windows and iSeries Navigator tips
Following are the basic 5250 workstation emulation commands for monitoring and
maintaining your Domino for iSeries environment. For each command, we include basic
information, an example of the syntax, and the corresponding feature in iSeries Navigator.
This section also lists the common Domino server jobs on the iSeries. For a more complete
explanation of the commands and the Domino server jobs, refer to 5.1, “Domino server
administration with OS/400 CL commands” in the redbook IBM Lotus Domino 6 for iSeries
Implementation, SG24-6592.

Tip: If you require a 5250 workstation emulation session on a platform other than
Windows, you might consider the emulation products described on the following Web sites:
http://www.businesslink.com
http://www.mochasoft.dk
http://www.pericom-usa.com
http://www.modernminds.com

Start a Domino server

To start a Domino server using a 5250 workstation emulation session, type in the following
command on the command line:
STRDOMSVR servername

To start a Domino server in iSeries Navigator, use the context menu (right mouse click) as
shown in Figure 2-9.

Figure 2-9 Starting a Domino server using iSeries Navigator

Chapter 2. Administering your Domino environment 73

 The iSeries Navigator allows you to start the Domino server only, the controller only, or both
the Domino server and controller. You can read the topic “The Server Controller and the
Domino Console” in the Domino 6 Administrator Help for more information about the Server
Controller feature in Domino 6.

End or stop a Domino server

The End Domino Server (ENDDOMSVR) command allows you to stop a Domino server that
is currently running. You can choose to stop all (*ALL) Domino servers on your iSeries or
LPAR or a specific Domino server. The default behavior is to end the server(s) in a controlled
manner (*CNTRLD). Here is the basic command:
ENDDOMSVR servername

This command stops all the Domino servers on your iSeries or LPAR in a controlled manner:
ENDDOMSVR *ALL

You can also end a Domino server immediately using the *IMMED option. You should end the
Domino server immediately only if the controlled shutdown fails. Data can be lost if Domino
server processes are stopped abruptly.

You can end or stop a Domino server using iSeries Navigator. See Figure 2-10 for an
example of stopping a Domino server.

Figure 2-10 Stopping a Domino server using iSeries Navigator

Notice that you can stop the Domino server without stopping the server controller. There are
times that you might want to work on the Domino server using the new Java Domino Console
instead of a 5250 workstation emulation session. Usually you will stop both the Domino
server and the controller at the same time.

74 Domino 6 for iSeries Best Practices Guide

Use a Domino server's console on the iSeries
The Work with Domino Console (WRKDOMCSL) command allows you to submit Domino
server commands to a specific Domino server. When you use the Domino server console,
you can immediately see the responses from the Domino server. Only one user can run the
WRKDOMCSL command for a specific Domino server at a time. Other jobs can use the
Display Domino Console (DSPDOMCSL) command to view the console messages for the
same Domino server.

Enter this command in a 5250 emulation session and press the Enter key:
WRKDOMCSL servername

Note: WRKDOMCSL may only be done by one person at a time from an OS/400
command line.

There is no corresponding command for WRKDOMCSL in iSeries Navigator. Instead, you will
open the Domino 6 Administrator client to the server you selected in iSeries Navigator and
use the Administrator client console. Right-click a Domino server, then select Properties.

You can also start the Domino Console Java application from iSeries Navigator, connect to
the desired server, then submit commands to a Domino server. To start the Domino Console
from iSeries Navigator, select File -> Start -> Domino Console.

Display a Domino server's console

Use the following command to view a Domino server console when someone else is already
running the WRKDOMCSL command:
DSPDOMCSL servername

Like the WRKDOMCSL command, there is no corresponding command that works the same
way as DSPDOMCSL in iSeries Navigator, but you can again use the Administrator client’s
console function. To do so, select Properties from a server’s context menu. You can also use
the Domino Console Java application to display a Domino server console.

Work with Domino servers in an LPAR or system

The Work with Domino Servers (WRKDOMSVR) command provides a menu to manipulate
certain aspects of the Domino servers on your iSeries server. From this menu, you can
perform any of the following actions to one or more Domino servers:
򐂰 Start a server
򐂰 End a server
򐂰 Change the server configuration
򐂰 Display the server console
򐂰 Work with the server console
򐂰 Work with OS/400 jobs associated with the server
򐂰 Change the working directory
򐂰 Work with OS/400 object links that are associated with the server
򐂰 Edit the NOTES.INI file

Enter this command in a 5250 workstation emulation session and press the Enter key to see
all Domino servers configured on your iSeries or LPAR:
WRKDOMSVR

Enter the following command and press the Enter key to work with a specific Domino server:
WRKDOMSVR servername

Chapter 2. Administering your Domino environment 75

 Figure 2-11 shows an example of the menu that is displayed when you use the
WRKDOMSVR command. Notice the options available at the top of the screen.

Work with Domino Servers

System: AS25
Type options, press Enter.
1=Start server 2=Change server 5=Display console 6=End server
7=Submit command 8=Work console 9=Work server jobs
11=Change current directory 12=Work object links 13=Edit NOTES.INI

Domino Domino
Opt Server Subsystem Status
___ PROJECTS PROJECTS *ENDED
___ DOMAV DOMAV *STARTED
___ DOMBRMS DOMBRMS *STARTED
___ DOMCLUS2 DOMCLUS2 *STARTED
___ DOMTDP DOMINO05 *ENDED
___ DOMREST DOMREST *STARTED

Bottom
Parameters or command
===>___________________________________________________________________________
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Sort by name
F11=Display library F12=Cancel F17=Top F18=Bottom F24=More keys

Figure 2-11 WRKDOMSVR menu

The Domino server list in iSeries Navigator is the equivalent to the WRKDOMSVR command.
You can perform most of the same options from iSeries Navigator using the File menu and
the context menu. Figure 2-12 shows an example of using the context menu to work with
Domino servers in iSeries Navigator.

Figure 2-12 WRKDOMSVR type server list in iSeries Navigator

76 Domino 6 for iSeries Best Practices Guide

Work with active jobs
The Work with Active Jobs (WRKACTJOB) command allows you to work with performance
and status information for the active jobs in the current LPAR or system. You use the
command to verify that Domino server jobs are running correctly and to view important
information about your system. The default behavior for this command is to show all active
jobs for all subsystems, sorted by subsystem name.

Enter this command and press the Enter key to see all the active jobs for your iSeries or
current LPAR:
WRKACTJOB

Enter this command and press the Enter key to work with the active jobs for a specific
subsystem:
WRKACTJOB subsystem_name

Figure 2-13 shows all the active jobs for the DOMAV subsystem. You can press the F10 key
to see the system statistics for the entire system, for example the CPU % in the upper left
hand corner of the screen and the CPU % used by each of the jobs in the DOMAV
subsystem. This display is especially helpful when you troubleshoot spikes in CPU usage.
You can determine what job is the root of the problem. More information on troubleshooting
Domino performance issues and the WRKACTJOB display can be found in Appendix B,
“Information to collect for Domino troubleshooting” on page 573 and Appendix C, “Common
configuration problems that affect Domino performance” on page 589.

Work with Active Jobs AS25

00/00/00 00:00:00
CPU %: .0 Elapsed time: 00:00:00 Active jobs: 260

Type options, press Enter.

2=Change 3=Hold 4=End 5=Work with 6=Release 7=Display message
8=Work with spooled files 13=Disconnect ...

Opt Subsystem/Job User Type CPU % Function Status

___ DOMAV QSYS SBS .0 DEQW
___ ADMINP QNOTES BCI .0 PGM-ADMINP SELW
___ AMGR QNOTES BCI .0 PGM-AMGR SELW
___ AMGR QNOTES BCI .0 PGM-AMGR CNDW
___ CALCONN QNOTES BCI .0 PGM-CALCONN CNDW
___ COLSRV400 QNOTES BCI .0 PGM-COLSRV400 SELW
___ EVENT QNOTES BCI .0 PGM-EVENT SELW
___ LOGASIO QNOTES BCI .0 PGM-LOGASIO CNDW
___ QNNINSTS QNOTES BCH .0 PGM-QNNINSTS EVTW
More...
Parameters or command
===>__________________________________________________________________________
F3=Exit F5=Refresh F7=Find F10=Restart statistics
F11=Display elapsed data F12=Cancel F23=More options F24=More keys

Figure 2-13 WRKACTJOB example

Here are the steps to display and work with active jobs in iSeries Navigator:
1. Open iSeries Navigator. Create a connection to your iSeries server if you have not already
done so. If you have multiple LPARs on your iSeries, create a connection to each partition.
2. Click the iSeries server or LPAR name to expand the list of options. iSeries Navigator will
probably prompt you for your iSeries user ID and password at this point.

Chapter 2. Administering your Domino environment 77

 3. Click Work Management.
4. Click Active Jobs.

After displaying the active jobs in the right hand pane of the iSeries Navigator window, you
can right-click one of the jobs for options such as hold, monitor, and show details about the
job. As an example, please see the options for the AMGR job in Figure 2-14. You can also
click any of the Work Management tasks in the bottom right pane of iSeries Navigator to
execute tasks such as monitor system performance, view system status, and monitor jobs.

Figure 2-14 Viewing and managing active jobs in iSeries Navigator

Double-clicking on a job displays its properties. Figure 2-15 on page 79 shows an example of
the job properties window for the Adminp job under the DOMAV subsystem. As a Domino
administrator, you will usually not work with these properties. An experienced iSeries
administrator can change job properties here, but the changes are only valid until the next
time you restart the job, subsystem, or LPAR. It does not change the default settings for the
job.

78 Domino 6 for iSeries Best Practices Guide

Figure 2-15 Job properties window in iSeries Navigator

Work with subsystems

The Work with Subsystems (WRKSBS) command enables you to end a subsystem, display
the subsystem description, and work with subsystem jobs. When stopping a subsystem, first
attempt to stop it using *CNTRLD, the default behavior. If after twenty minutes the subsystem
has not stopped, use the *IMMED option.

Enter the following command and press the Enter key to work with all subsystems on your
iSeries system or partition:
WRKSBS

Enter the following command and press the Enter key to work with one specific subsystem:
WRKSBS subsystem_name

Figure 2-18 on page 82 shows an example of the screen that displays when you use the
WRKSBS command. Notice the options available at the top of the screen.

Chapter 2. Administering your Domino environment 79

 Work with Subsystems
System: AS25
Type options, press Enter.
4=End subsystem 5=Display subsystem description
8=Work with subsystem jobs

Total -----------Subsystem Pools------------

Opt Subsystem Storage (M) 1 2 3 4 5 6 7 8 9 10
___ DOMAV .00 2
___ DOMBRMS .00 2
___ DOMCLUS2 .00 2
___ DOMREST .00 2
___ QBATCH .00 2
___ QCMN .00 2
___ QCTL .00 2
___ QINTER .00 2 3
___ QSERVER .00 2
___ QSPL .00 2 4
More...
Parameters or command
===>___________________________________________________________________________
F3=Exit F5=Refresh F11=Display system data F12=Cancel
F14=Work with system status

Figure 2-16 WRKSBS command output

Here are the steps to display and work with active subsystems in iSeries Navigator:
1. Open iSeries Navigator. Create a connection to your iSeries server if you have not already
done so. If you have multiple LPARs on your iSeries, create a connection to each partition.
2. Click the iSeries server or LPAR name to expand the list of options. iSeries Navigator will
probably prompt you for your iSeries user ID and password at this point.
3. Click Work Management.
4. Click Subsystems.
5. Click Active Subsystems.

After displaying the active subsystems, you can double-click a subsystem to display the jobs
running under that subsystem. Figure 2-17 shows all of the jobs running in the DOMAV
subsystem. You can right-click one of the jobs for options such as hold, monitor, and details
about the job. You can also click any of the Work Management tasks in the bottom right pane
of iSeries Navigator to execute tasks such as monitor system performance, view system, and
monitor jobs.

80 Domino 6 for iSeries Best Practices Guide

Figure 2-17 Active subsystems in iSeries Navigator

End a subsystem
The Domino server subsystem is not ended when you end your Domino server controlled
(with the *CNTRLD option), so you must end the Domino server subsystem manually when
you run maintenance tasks or when you upgrade your Domino server program version.

If you end the Domino server immediately (with the *IMMED option), the subsystem is also
ended.

Important: Do not end the Domino server subsystem using the End Subsystem
(ENDSBS) command while the Domino server is still active! Always end the Domino server
before you end the Domino server subsystem, or data can be lost.

To end a subsystem after ending the corresponding Domino server, type the following
command, then press Enter.
ENDSBS subsystem_name

To end the subsystem named domperf, for example, type in the following command, then
press Enter:
ENDSBS domperf

To end a subsystem in iSeries Navigator, go to the Active Subsystems view as described in

“Work with subsystems” on page 79. Right-click the subsystem you want to end, then click
Stop from the menu as shown in Figure 2-18.

Chapter 2. Administering your Domino environment 81

 Figure 2-18 Stopping a subsystem in iSeries Navigator

The Stop Subsystem window shown in Figure 2-19 is displayed. You can usually accept the
default options by clicking OK. We recommend using the *IMMED stop option only if
absolutely necessary.

Figure 2-19 Stop Subsystem prompt in iSeries Navigator

82 Domino 6 for iSeries Best Practices Guide

After ending the subsystem, it will disappear from the list in iSeries Navigator. The subsystem
starts up again automatically when you start the Domino server associated with the
subsystem.

Edit a (text) file

The Edit File (EDTF) command allows you to edit a file, such as NOTES.INI or another text
file. To edit the Domino server’s NOTES.INI file with EDTF, you can run the command directly,
or you can select option 13 (Edit NOTES.INI) from the Work with Domino Servers
(WRKDOMSVR) menu.

To edit the NOTES.INI file for a Domino server, type in the following command, then press
Enter:
EDTF path/file

For example, to edit the NOTES.INI file for the DOMAV Domino server, type in the following
command, then press Enter:
EDTF 'lotus/data/domav/notes.ini'

You have several options if you want to edit a NOTES.INI file in iSeries Navigator:
򐂰 Option 1: From the Domino servers view:
a. Maneuver to the Domino server list (See “Work with Domino servers in an LPAR or
system” on page 75 for instructions.)
b. Right-click the Domino server related with the NOTES.INI file you want to edit.
c. Select Properties.
d. Select the Initialization File tab.
e. Click the Edit button.
򐂰 Option 2: From the File Systems view:
a. Select the iSeries server or LPAR where your Domino server is located.
b. Click File systems.
c. Click Integrated File System.
d. Click Root.
e. Click Lotus.
f. Click Data.
g. Select the desired Domino server name, for example, DOMAV.

Note: These instructions are describing the most common subdirectory structure for
Domino. You have to use the actual directory structure for your Domino servers.

h. Find the NOTES.INI file in the list in the right hand pane and right-click it.
i. Select Edit. You might be prompted for your iSeries user ID and password at this point.
j. After changing the file, click File -> Save to save your changes. Click File -> Exit to exit
the editor.

For additional information, please refer to Appendix C, “Editing stream files in the OS/400
integrated file system (IFS)” of the redbook IBM Lotus Domino 6 for iSeries Implementation,
SG24-6592.

Chapter 2. Administering your Domino environment 83

 Change the configuration of a Domino server
You can change the configuration of an existing Domino server on your iSeries using the
Change Domino Server (CHGDOMSVR) command. Use this command to change specific
characteristics or to add features that were not originally included in the Domino server’s
configuration. For example, if you want to change the Domino server to be a partitioned
server or select another subsystem name, you stop the Domino server and subsystem, use
the CHGDOMSVR command, then restart the Domino server.

To run this command, type the following and press the F4 key:
CHGDOMSVR

The command execution prompts you for the name of the Domino server. You can press F4
again to see a list of Domino servers that are currently configured on your iSeries server or
partition. After entering the Domino server name and pressing Enter, the system retrieves the
current Domino server properties that are eligible to be changed by this command.

To change the configuration of an existing Domino server in iSeries Navigator:

1. Stop the Domino server you want to change. If you want to change the subsystem name
that a Domino server runs under, you must also end the subsystem after ending the
Domino server.
2. Select Properties from the Domino server’s context menu. iSeries Navigator retrieves the
current Domino server properties that are eligible to be changed via this method.
3. Make your changes.
4. Click OK after you saved your changes.
5. Start the Domino server.

Refer to section 4.4, “CHGDOMSVR command” in the redbook IBM Lotus Domino 6 for
iSeries Implementation, SG24-6592 for more information.

Note: The Configure Domino Server (CFGDOMSVR) command is available to configure a

new Domino server or delete an existing Domino server. iSeries Navigator also provides
options to create and delete Domino servers. These commands are explained in detail in
Chapter 4 and Appendix A of the redbook IBM Lotus Domino 6 for iSeries Implementation,
SG24-6592.

Running Domino tasks when the Domino server is not active

All of the Domino commands discussed in the previous sections require that the Domino
server is running. It is sometimes useful to run Domino tasks when the Domino server is not
running. For example, you may want to compact the Domino Directory when the Domino
server is not running.

The Run Domino Command (RUNDOMCMD) command runs an OS/400 CL command in the
context of a particular Domino for iSeries server. It sets up the environment that allows the
command to be run regardless of whether the Domino server is active. When the Domino
server is not active, you can run such batch processing type commands as FIXUP,
COMPACT, and UPDALL.

The RUNDOMCMD is well documented in section 5.1.6, “Running Domino tasks when the
Domino server is not active” of the redbook IBM Lotus Domino 6 for iSeries Implementation,
SG24-6592, including the authorities required to execute the command and examples of the
syntax.

84 Domino 6 for iSeries Best Practices Guide

 Tip: Pay close attention to the syntax example on page 231 in IBM Lotus Domino 6 for
iSeries Implementation, SG24-6592 when using Domino commands with options such as
-R. Here is an example of running UPDALL -R on the NAMES.NSF on the DOMAV server:
RUNDOMCMD SERVER(DOMAV) CMD(CALL PGM(QNOTES/UPDALL) PARM('names.nsf' '-R')) BATCH(*NO)

Submitting Domino jobs

The Submit Domino Command (SBMDOMCMD) command provides a way to submit Domino
server commands to run on an active Domino server. When you submit a Domino server
command, you need to specify the name of the Domino server to which you want to submit
the Domino server command. Any output from the command is shown at the Domino server
console, however, it is possible to redirect the output to a file if you choose.

The command has the following two parameters:

򐂰 The Command (CMD) parameter allows you to enter the command you want to run, for
example:
sh port tcpip
򐂰 The Server name parameter requires you to enter the name of the server for which you
want to run the command.

A successful submission of the command generates the completion message “Domino

command submitted for processing on server DOMAV”, where your server name is
substituted for DOMAV. An incorrect command is considered as being submitted correctly, as
long as the necessary parameters are specified and as long as the server name is correct. If
the command you entered contains syntax errors, the Domino server console displays an
error message.

Here is the general syntax for the SBMDOMCMD:

SBMDOMCMD CMD('server-command file-name') SERVER(server-name)

The syntax for the CMD parameter is the same as what you would enter at the Domino server
console. The following command is an example of running the COMPACT task on the
ADMIN4.NSF database on the DOMAV server using the SBMDOMCMD:
SBMDOMCMD CMD('LOAD COMPACT admin4.nsf') SERVER(DOMAV)

Tip: Before you copy and paste long OS/400 commands into your 5250 workstation
emulation command line, type in CALL QCMD to get more command lines. Long
commands scroll to the additional command lines automatically, making this process much
easier.

Please be sure you understand the authorities and environment variables needed to run
SBMDOMCMD. See the section describing SBMDOMCMD starting on page 123 in Lotus
Domino for AS/400 R5 Implementation, SG24-5592 for more detailed information.

You can run the SBMDOMCMD in iSeries Navigator using the Run Command feature.
Finding the Run Command is not particularly intuitive, so follow these instructions:
1. Open iSeries Navigator.
2. Right-click the iSeries server or LPAR where you want to submit the command.
3. Select Run Command, as seen in Figure 2-20.

Chapter 2. Administering your Domino environment 85

 Figure 2-20 Run Command in iSeries Navigator

4. Key in SBMDOMCMD plus the Domino command you want to submit or select the
command from previously submitted commands. Figure 2-21 shows how you enter the
SBMDOMCMD for running the load compact task on the ADMIN4.NSF database on the
DOMAV server.

Figure 2-21 Run Command window in iSeries Navigator

5. Click OK.

The Run Command window offers you several options:

򐂰 You may type in just SBMDOMCMD on the Run Command window, then click the Prompt
button to display the parameters for the SBMDOMCMD command.

86 Domino 6 for iSeries Best Practices Guide

򐂰 You may run the command on all Domino servers on your iSeries server or LPAR by using
*ALL instead of the server name for the SERVER parameter.
򐂰 You may also schedule the job by clicking the Schedule button and filling in the job
scheduling information.

To check the status of SBMDOMCMD jobs run in iSeries Navigator, follow these instructions:
1. Open iSeries Navigator.
2. Click Management Central.
3. Click Task Activity.
4. Click Commands.
5. Look for entries called “Run Command” on the iSeries server or LPAR where you ran the
command. The first Run Command entry in the list shown in Figure 2-22 is the command
submitted previously (and displayed in Figure 2-21). As you can see, the status is
“Completed”. You can also see the systems or groups where the command ran.

Figure 2-22 Example of Commands list in Management Central

Creating a CL program
Here’s a simple way to create a CL program without using OS/400 application development
tools such as Programming Development Manager (PDM). This method is not officially
supported, but you might find it useful in your environment. We suggest it as an alternative for
Domino administrators or iSeries administrators who do not know PDM, but still need to
create CL programs. You need to have appropriate access on the iSeries to use this method.

Execute the following steps from the iSeries command line:

CRTSRCPF (mylib/myfile)
EDTF FILE(mylib/myfile) MBR(mymbr)
CRTCLPGM PGM(mylib/mymbrcl) SRCFILE(mylib/myfile) SRCMBR(mymbr)

Chapter 2. Administering your Domino environment 87

 Domino server jobs on the iSeries
There are four categories of Domino jobs we can consider for the sake of this discussion:
򐂰 Jobs that are always necessary:
– ADMINP: Administration process
– AMGR: Agent manager
– QNNINSTS: The “Watchdog”
– ROUTER: The mail router
– SERVER: The main server task
– STATLOG: Database activity logger
– UPDATE: The Indexer task
򐂰 Jobs that are often used:
– CLADMIN: Cluster administration process
– CLDBDIR: Cluster Database Directory Manager
– CLREPL: Cluster Replicator
– COLLECT: Statistics collector
– COLSRV400: New in V5R2. Gathers Domino statistics. See 1.5.2, Collection Services
in IBM Lotus Domino 6 for iSeries Implementation, SG24-6592 for more information.
– CONTROLLER: Controls a Domino server
– EVENT: Creates alarms
– HTTP: The Web server
– LOGASIO: Controls transaction logging
– QNNINBRM: Controls the interaction between the Domino server and BRMS
– REPLICA: The replication task
– SCHED: Schedule Manager
– SMTP: Internet Mail Router
򐂰 Jobs that are very likely not used:
– BILLING: Records billing information
– DECS: Domino Enterprise Connection Services
– CALCONN: Calendar connector
– REPORT: Statistic reporter
– STATS: Statistics on demand via e-mail
򐂰 Housekeeping jobs:
– COMPACT: Compacts databases
– DESIGN: Refreshes database design from template
– UPDALL: Updates views and full text indexes
– FIXUP: Checks for and fixes corrupted databases

Please refer to Chapter 8, “Understanding the Domino server jobs” in Domino for iSeries
Sizing and Performance Tuning, SG24-5162-01 for a more thorough explanation of each job.

Also, please refer to “iSeries performance tuning for Domino” on page 172 regarding
performance tuning of these jobs.

2.7 LPAR and Domino clustering administration guidelines

This section contains guidelines for administering LPARs and Domino clustering in your
environment.

88 Domino 6 for iSeries Best Practices Guide

2.7.1 LPAR
The main objective of LPAR is providing users with the ability to split a single iSeries system
into several systems capable of running applications in multiple, independent environments
simultaneously. For example, logical partitioning makes it possible to run Domino servers
using different sets of data on separate partitions, as if it was running independently on
separate physical iSeries systems.

Here are the main areas you need to address in administering LPARs on your iSeries:
򐂰 Retrieving the resources allocated to a partition
򐂰 Changing partition processing resources
򐂰 Saving and restoring partitions
򐂰 System values affected by logical partitioning
򐂰 Securing considerations
򐂰 Date and time processing between partitions
򐂰 Main storage dump processing
򐂰 Managing the hardware resource configuration
򐂰 The IPL process
򐂰 Work management

Resources
Please refer to the resources below for more information on these areas.
򐂰 Topic: “Logical partitions” in the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzaj9/rzaj9iclpar.htm
򐂰 Slicing the AS/400 with Logical Partitioning: A How to Guide, SG24-5439 available at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG245439.html?Open
򐂰 LPAR Configuration and Management: Working with IBM ^ iSeries Logical
Partitions, SG24-6251:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246251.html?Open

2.7.2 Domino clustering

A Domino cluster is a group of two to six servers that provides users with constant access to
data, balances the workload between servers, improves server performance, and maintains
performance when you increase the size of your enterprise. Lotus Notes clients are
re-directed by the Cluster Manager, and Web clients (browsers) are directed and re-directed
by the Domino Internet Cluster Manager (ICM).

Benefits of clustering
These are the main benefits of Domino clusters:
򐂰 High availability of important databases: When a hardware or software problem
occurs, clustered servers redirect database open requests to other servers in the cluster
to provide users with uninterrupted access to these databases. This process is called
failover. Clusters provide failover for business-critical databases and servers, including
passthru server failover to other servers in the cluster. Failover also lets you perform
server maintenance, such as hardware or software upgrades, with little negative effect on
users.
򐂰 Workload balancing: When users try to access databases on heavily-used servers,
Domino can redirect the user requests to other cluster servers so that workload is evenly
distributed across the cluster. Workload balancing of cluster servers helps your system
achieve optimum performance, which leads to faster data access.

Chapter 2. Administering your Domino environment 89

 򐂰 Scalability: As the number of users you support increases, you can easily add servers to
a cluster to keep server performance high. You can also create multiple database replicas
to maximize data availability, and move users to other servers or clusters as you plan for
future growth. As your enterprise grows, you can distribute user accounts across clusters
and balance the additional workload to optimize system performance within a cluster.

Clustering best practices

Here are some best practices for configuring and managing Domino clusters:
򐂰 There are performance impacts when adding multiple Domino servers together into a
cluster. These impacts include CPU utilization, increased I/O, and increased network
traffic. This means that you need to define a Notes Named Network and a port dedicated
for the Domino servers in the cluster. We recommend creating a port called HSL and a
Notes Named Network containing the initials HSL, then create a high speed line (HSL)
connection between the Domino servers, whether they are on the same LPAR, iSeries
server or separate iSeries servers. This approach minimizes the performance impact of
clustering on each of your Domino servers. It is important to note that you must purchase
the HSL software and hardware separately if you plan to implement this best practice.
򐂰 Make administering your cluster easier by dragging and dropping databases into a cluster
and specifying which cluster servers should receive replicas.
򐂰 Create multiple mail replicas and roaming file replicas for users when you register them,
and you can monitor all the servers in a cluster simultaneously.
򐂰 Use the SH CLUSTER command at the Domino server console to display the local
server's cluster name cache, which includes a list of all cluster members and their status,
based on information received during the server's cluster probes.
򐂰 A useful guideline for determining the number of Cluster Replicators to run on each server
is to set up as many Cluster Replicators as there are cluster members, minus one. For
example, if there are four servers in the cluster, enable three CLREPL tasks on each
server in the cluster. This way, there will always be at least one CLREPL task available to
handle replication requests to another server in the cluster.
򐂰 When clustering mail databases, two replicas in a cluster should be adequate to
guarantee availability at any given time for mailboxes, and still keep the overhead of
cluster replication low.
򐂰 Mail database replicas should be distributed roughly evenly among the servers in the
cluster to avoid unreasonable growth of workload on one server in the case of failure of
another server in the cluster.

Tip: Cluster replication overrides any database quotas configured in policies or on specific
databases. Please consider this when planning or maintaining your Domino cluster
environment.

Resources
For more information on Domino clustering, refer to the following resources:
򐂰 Administering Domino Clusters describes how to set up, manage, and troubleshoot
Domino clusters, and is available at this Web site:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument
򐂰 Section 10.2, “Clustering” in Domino for iSeries Sizing and Performance Tuning,
SG24-5162-01.
򐂰 “What is a Domino Cluster?” topic in the Domino 6 Administrator Help.

90 Domino 6 for iSeries Best Practices Guide

2.8 Lotus software compatibility
Figure 2-1 shows the status, at the time this redbook was written, of the compatibility of
Domino 6 for iSeries with other Lotus products. The table also shows recommendations and
workarounds in case of incompatibility. Over time, it is expected that support for some of
these Lotus products will become available. For the most recent information, refer to the
Lotus Software for iSeries Compatibility Guide on the Web at:
http://www.ibm.com/servers/eserver/iseries/domino/domino6/releasesupport4up.pdf

Table 2-1 Lotus products supported by Domino 6 for iSeries

Lotus product Compatibility Recommendations / Workarounds
with Domino 6
for iSeries

IBM Lotus Team No Although a QuickPlace server can run in the same Domino
Workplace domain as a Domino 6 server, QuickPlace cannot currently
(QuickPlace) be installed on top of a Domino 6 server. QuickPlace must
be installed on a specified Release 5 version of Domino.

As an alternative, consider creating a separate OS/400

logical partition (LPAR) to run QuickPlace and Domino 6 on
the same iSeries server. For more information on how to
configure Domino R5 and Domino 6 in an OS/400 LPAR
environment, see the redbook Multiple Domino Versions
Coexistence with LPAR on the IBM eServer iSeries Server,
SG24-6593.

IBM Lotus Instant Yes Has been tested and is compatible with Domino 6 for iSeries.
Messaging and
Web Conferencing Check the Sametime for iSeries Web site for the most
(Sametime) current information about requirements. For example,
Sametime 3.1 requires Domino 6.0.2 and above.

IBM Integrated Yes Has been tested and is compatible with Domino 6 for iSeries.
Domino Fax for
iSeries, 5733-FXD

Lotus Workflow™ Yes Workflow 3.0.1 is compatible with Domino 6 for iSeries.

Domino Document Yes Has been tested and is compatible with Domino 6 for iSeries.
Manager
(Domino.Doc) Domino.Doc 3.1 with 3.5 client works with the Domino
versions 6.0 and 6.0.1. It is not compatible with Domino 6.0.2
or higher.

Lotus Enterprise Yes Has been tested and is compatible with Domino 6 for iSeries.
Integrator® (LEI) 6
for iSeries

Resources
Here is a list of the Web sites for the Lotus Extension Products mentioned in Table 2-1.
򐂰 IBM Lotus Team Workplace (QuickPlace) for iSeries Web site:
http://www.ibm.com/servers/eserver/iseries/quickplace/
򐂰 IBM Lotus Instant Messaging and Web Conferencing (Sametime) for iSeries Web site:
http://www.ibm.com/servers/eserver/iseries/sametime/

Chapter 2. Administering your Domino environment 91

 򐂰 IBM Integrated Domino Fax for iSeries Web site:
http://www.ibm.com/servers/eserver/iseries/domino/related/fxd/
򐂰 Lotus Workflow for iSeries Web site:
http://www.ibm.com/servers/eserver/iseries/domino/workflow/
򐂰 Domino Document Manager (Domino.Doc) for iSeries Web site:
http://www.ibm.com/servers/eserver/iseries/domino/related/domdoc.htm
򐂰 Knowledge Collection: Using Lotus Workflow 3.0.1 with Notes/Domino 6 Technotes:
http://www.ibm.com/support/docview.wss?rs=482&q=7002582&uid=swg27002582&loc=en_US&cs
=utf-8&lang=en
򐂰 Knowledge Collection: Using Domino.Doc with Notes/Domino 6:
http://www.ibm.com/support/docview.wss?rs=203&q=Knowledge+Collection&uid=swg27003708
&loc=en_US&cs=utf-8&lang=en
򐂰 Knowledge Collection: Running QuickPlace on iSeries:
http://www.ibm.com/support/docview.wss?rs=203&q=Knowledge+Collection&uid=swg27003732
&loc=en_US&cs=utf-8&lang=en

2.9 Backup and recovery strategies

This section contains a few tips for Domino and iSeries administrators for backup and
recovery tasks. We acknowledge that this is a very important topic to Domino and iSeries
administrators so we dedicated several chapters to it in this book. Please refer to Part 2,
“Managing your environment” on page 241. It contains best practice information for using
OS/400 save/restore commands, BRMS or Data Protection for Domino.

Tips for Domino administrators

Here are a few tips about backup and recovery for Domino administrators:
򐂰 Never copy or FTP a live logged Domino database. Use the Domino 6 Administrator or
Lotus Notes client instead.
򐂰 To place a new database on a Domino server, FTP it with a different extension, for
example .FTP, then rename the file so it appears instantly to the Domino server.

Tips for iSeries administrators

Here are a few tips about backup and recovery for iSeries administrators:
򐂰 Automate the backup process and verify that the process works as designed.
򐂰 Learn and use the BRMS plug-in for iSeries Navigator. Know what functions are faster to
use in iSeries Navigator and what functions are faster to use in a 5250 workstation
emulation session.

2.10 Upgrade from previous versions of Domino

This section is a summary of the update tasks for Domino 6 for iSeries. Since this book
recommends best practices for Domino 6 for iSeries, it does not contain every detail about
upgrading. It identifies several sources containing pertinent information and directs you to the
most helpful excerpts of each source. The resources for this section include:

92 Domino 6 for iSeries Best Practices Guide

 򐂰 Installing and Managing Domino 6 for iSeries:
http://www.lotus.com/ldd/notesua.nsf/0b345eb9d127270b8525665d006bc355/505c677e79adb5
9100256c44003288ee?OpenDocument
򐂰 The IBM Redbook, IBM Lotus Domino 6 for iSeries Implementation, SG24-6592
򐂰 Lotus Notes, Domino, and Domino Designer Release Notes 6.0.2:
http://www.lotus.com/ldd/doc/domino_notes/6.0.2/readme.nsf
򐂰 Notes/Domino 6 Upgrade Guide:
http://www.lotus.com/ldd/notesua.nsf/0b345eb9d127270b8525665d006bc355/2f6cd8057c3602
bf85256b5800681d38?OpenDocument&Highlight=0,installing,domino
򐂰 Upgrading to Lotus Notes and Domino 6, SG24-6889:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246889.html?Open
򐂰 Knowledge Collection: Domino 6 for iSeries, Reference #7002762:
http://www.ibm.com/support/docview.wss?rs=203&q=domino+6+install+iseries&uid=swg2700
2762&loc=en_US&cs=utf-8&lang=en

2.10.1 Why upgrade to Domino 6?

There are several compelling reasons your organization will want to upgrade to IBM Lotus
Notes and Domino 6. Domino 6 will enable you to harness more value from your
infrastructure, manage more users, increase network efficiency, while at the same time
controlling or reducing total cost of ownership. The improvements made in the new version let
administrators and end users do more with less. Lower costs, fewer resources required,
reduced time and effort — all of these benefits can be achieved by putting Lotus Notes and
Domino 6 to work in your organization.

2.10.2 Planning your upgrade

You have several options when planning your upgrade to Domino 6:
򐂰 Plan and implement the upgrade using your organization’s staff.
򐂰 Plan the upgrade using your organization’s staff, then engage Lotus to review your plan
before implementation. A Solution Assurance Review (SAR) is a technical inspection of a
completed design, performed by subject matter experts who were not involved in the
design. An SAR answers these questions:
– Will the solution work technically?
– Will the solution meet the customer’s requirements and expectations?
– Can we implement the solution successfully?
Contact your IBM Software Services for Lotus Sales Specialist or IBM/Lotus Business
Partner for more information.
򐂰 Engage ISSL to evaluate your environment and make recommendations for your upgrade.
ISSL can also implement the plan for your organization. To learn more about the Lotus
Notes/Domino 6 Assessment offering, or any of the offerings and services available from
IBM Software Services for Lotus, please contact your local IBM Software Services for
Lotus Sales Specialist.

Poor planning and design are common causes for upgrade shortcomings. Consider these key
causes during your planning and design exercises:
򐂰 Incomplete assessment and requirements gathering
򐂰 Inconsistent architecture and design
򐂰 Undefined migration and coexistence plan

Chapter 2. Administering your Domino environment 93

 򐂰 Incomplete test and process validation
򐂰 Lack of an administration and support strategy
򐂰 Lack of communication planning
򐂰 Lack of project management
򐂰 Limited training
򐂰 Incomplete pilot and process validation
򐂰 Ineffective deployment methodologies
򐂰 Lack of transformation management

This section lists the general steps for approaching your upgrade. We recommend that you
document each step in the process thoroughly to make the upgrade proceed as smoothly as
possible. We also include a brief discussion about interoperability issues you should
understand before starting your planning.

2.10.3 Interoperability issues

You need to understand and consider several interoperability issues before you design your
upgrade plan:
򐂰 Notes/Domino release issues
򐂰 Domino Directory issues
򐂰 Index considerations
򐂰 Calendaring and scheduling considerations

Notes/Domino releases
In general, the Notes/Domino products have an excellent record of accomplishment of
backwards compatibility, however, it is important to understand the specific areas that may
cause problems during a migration that extends over a lengthy period. For example when
migrating an environment that contains three major releases of the Domino server code in
use; such as 6.0, 5.x and 4.x (legacy application domain), there are several technical
considerations.

There are two main types of server-to-server interoperability to consider:

򐂰 Server-to-server communication (mail routing, replication and calendar/free-time lookup)
򐂰 Databases shared via replication between servers using different software releases

Organizations have differing environments and do not always implement features in a

common way, so it is difficult to provide a one-size-fits-all recommendation. Although every
effort is made to provide robust interoperability between software releases, it is important that
each organization thoroughly test the features that they specifically require both during the
coexistence period and in the eventual steady-state environment. This is the only way to
ensure that the features needed will work as planned once the upgrade is complete.

Where databases are shared between servers on different software releases, care must be
taken to ensure that when designs are upgraded on one server, they do not have a
detrimental impact on the server running the older version of the software.

There are two main methods to approach this issue:

򐂰 Upgrade designs only after testing that they do not cause any problems on servers with
earlier software releases. This makes sure they can safely be replicated throughout the
environment.
򐂰 Impose a ring-fence around the newer servers so that the servers can replicate updates
but not design element changes. This way, the newer design stays on the servers with the
new software release, while the old design remains intact on the servers with older
releases of the software.

94 Domino 6 for iSeries Best Practices Guide

One important point to consider is the ongoing use of Domino 5.x servers that support the
Lotus Instant Messaging and Lotus Workplace functions. While the Domino 6 Directory is
backwards compatible, if specific interoperability testing has not been completed, it may be
beneficial to not allow the directory design to replicate from Domino 6 servers to these Lotus
Instant Messaging/Lotus Workplace servers.

From the perspective of client interoperability, calendaring and scheduling is usually the most
difficult feature to maintain during a coexistence period. Delegation of a calendar between
users can be an issue if those users are on different releases of the client. More information
on this topic is provided in “Calendaring and scheduling interoperability” on page 96.

Note: A Notes 6 client accessing a Domino 4.x server is not supported.

Domino Directory
In many environments, the Domino Directory contains customizations based on particular
business and application needs. Prior to the upgrade of the directory design to Domino 6, it is
advisable that these views be removed from the design or at least consolidated where
duplicates exist. Removing unnecessary views can significantly reduce the size of the
directory and the amount of time that servers spend indexing its content.

This is especially important when a server restarts with a new version of the server software
but with data in an existing older format. The server will convert all view indexes to a new
updated format. Removing these views will have a positive impact in shortening the amount
of time that the server will require to rebuild the view indexes of the directory.

If some of the customized views are still considered necessary, they can be reproduced in the
new directory.

It is also recommended to clean up the content of the directory such that it is consistent and
accurate before migration or deployment of the new infrastructure. This will remove
unnecessary data that is no longer required and make administration and troubleshooting
much simpler. The following areas are noted as examples:
1. Server documents:
a. Ensure consistency of configurations
b. Disable unused port definitions
c. Remove duplicate named networks
d. Ensure membership in correct named networks
2. Connection documents:
a. Verify schedules and priorities
b. Ensure scheduled replication between cluster members
3. Configuration documents:
a. Server group versus individual configurations
b. Router thread count configurations
c. Consistency of configuration entries across servers with a common role
4. Program documents:
a. Verify schedules
5. Remove all redundant documents
6. Review access control groups

Chapter 2. Administering your Domino environment 95

 Index considerations
View indexes will be recreated by the server using the new Domino 6 format. This will occur
on demand when views are used for the first time or can be run during off hours by an
administrator.

The Domino 6 full-text engine has been improved and like view indexes, full-text indexes will
be updated by the server on demand. An administrator can optionally replace existing full-text
indexes after the server upgrade all at once but beware that the server may take a long time
to complete this process.

Since each server has different data volumes, it is not possible to quantify the amount of time
these processes will take.

To better understand the length of time that the compact and view/full-text index rebuilds
might take, it is best to take a mirror image of the data from a fully loaded production server
(typically from a recent backup). Then test the upgrade, compact, and rebuild of all indexes in
an isolated environment. While the result will not be universally applicable across all other
servers due to variations in such things as hardware, data volume, view/full-text index
complexities, it provides a rough guideline. For example, you could create an estimate in
terms of “minutes per gigabyte of data” that could be scaled based on the data size of a given
server. It must be stressed that this is a rough estimate at best.

Calendaring and scheduling interoperability

Calendaring and scheduling is usually the most difficult feature to maintain during a
coexistence period. Delegation of a calendar between users can be an issue if those users
are on different releases of the client. Since calendaring and scheduling was determined to
be of critical importance, ensuring smooth transitions for users, especially those with
delegated access, is very important.

To reduce the potential for interoperability issues in calendaring and scheduling between
owners and delegates of calendars, the client migration benefits from knowing which users
share responsibility for calendars so that their client upgrades can be scheduled at the same
time or as closely as possible. In this respect, database usage tracking tools that show which
users access a database regularly, are very useful. Armed with this information, it is then
feasible, but more time consuming, to build a client migration schedule which specifically
targets batches of delegated users and the owners of the calendars for which they are
responsible.

Until clients are upgraded to the new release, the mail database design should not be
upgraded to minimize the risk of problems with interoperability.

If client upgrades cannot be timed to coincide closely, then it is advisable to upgrade the
delegated user (typically the administrative assistant) before the owner of the mail database.
However, if the executive is still based on a Domino 4.x server, this creates an unsupported
configuration for the administrative assistant. The best solution in this case is to move the
executive’s mail file to a Domino 6 server, whether or not you upgrade their client to Notes 6.

2.10.4 Creating your upgrade plan

Here are the basic phases for your upgrade to Domino 6:
򐂰 Planning
򐂰 Design
򐂰 Pilot
򐂰 Upgrading your environment
򐂰 Production

96 Domino 6 for iSeries Best Practices Guide

Planning
The planning phase includes documenting the features of Domino 6 that your organization
will use, the performance of Domino 6 in your environment, identifying and obtaining the
resources needed for the project and building your project framework.
򐂰 Evaluate new features.
򐂰 Performance considerations.
򐂰 Identify resources and win management support:
– Human resources such as administrators, help desks staff and early adopters
– Time
– Funding
򐂰 Build your project framework:
– Dates and locations
– Goals and milestones
– Baselines
򐂰 Think about compatibility with third party software and other Lotus products.
򐂰 Gain insights from the upgrade experience of other organizations that use Domino.
Contact your IBM Software Services for Lotus Sales Specialist or IBM/Lotus Business
Partner for possible contacts.

Design
The design step includes evaluating and documenting the following areas:
򐂰 Recommended upgrade path:
a. Domino Administration client for all administrators involved in the upgrade project
b. Pre-upgrade cleanup activities
c. Domino Directory design (can be done when upgrading first administration server)
d. Domino Administration servers
e. Hub servers/SMTP servers
f. Spoke servers
• Mail servers
• Application servers
• Web servers
g. Lotus Notes clients
h. Mail template and application designs
򐂰 Streamlining processes and procedures in your environment using new Domino 6 features
򐂰 New standardized client design:
– Lotus Notes clients
– iNotes Web Access
– Profile considerations
– Multi-user and roaming user
򐂰 Mail file retention and policies
򐂰 Considering the upgrade as an opportunity for server consolidation
򐂰 Global language requirements, if applicable
򐂰 Third party software readiness, if applicable

Chapter 2. Administering your Domino environment 97

 򐂰 Review your upgrade design with experts. We recommend the Solution Assurance
Review (SAR) from ISSL as a valuable exercise for your upgrade.

Pilot
The pilot phase includes testing and piloting tasks as follows:
򐂰 Set up and test the new environment as completely as possible, including the following
areas:
– Directory and core system database designs and interoperability
– Mail; calendaring and scheduling
– Resource reservations
– Critical applications
– Server interoperability, for example, routing and replication
– Sametime/QuickPlace/DEAS server interoperability
– Language packs
– Localized language client software
– Lotus Enterprise Integrator (LEI) or other connectors
– 3rd party products (for example, Antivirus solution, etc.)
– Backup/restore
򐂰 After testing, pilot the environment involving a complete scenario of candidates including:
– Different types of servers
– A healthy load of users
– The support structure
– Your applications
– Globalization and time zone issues
– Clustering
– Mobile users

2.10.5 Upgrading your environment

We recommend creating an upgrade process document that details each step for upgrading
your environment and using it as a checklist. Test the upgrade process defined in this
document before you upgrade your production environment. Here is an example of an
upgrade process document that you can customize for your organization:

Before you upgrade

1. Confirm that the OS/400 level is V5R1 or V5R2.
2. Confirm that 5722-JV1 option 5 is installed (JDK 1.3). If you have to install JDK 1.3, then
you also need to apply (or re-apply) the latest Java Group PTF.
3. Check any products that integrate with the Domino server. For example:
– Trend Micro and Symantec have special versions to run with Domino 6.x
– Lotus Team Workplace (QuickPlace) does not run on Domino 6.0.x at this time.
– LEI 3.x does not run on Domino 6 and higher. If you run LEI, you must upgrade to LEI
6.x.
– Lotus Instant Messaging and Web Conferencing (Sametime) 3.0a and 3.1 both run on
Domino 6.0.2 CF 1 on the iSeries. We recommend that you upgrade Lotus Instant
Messaging to the appropriate level before upgrading to Domino 6.

98 Domino 6 for iSeries Best Practices Guide

4. Confirm that you do not have *MSF mail routing configured for Domino.
Check the NOTES.INI for the value SMTP_Version. If that value equals 1, then you are
configured for *MSF. You have to reconfigure your Domino 5.x server before upgrading to
Domino 6.x. Also check the IFS directory /QIBM/UserData/LOTUS/SMTPMTA to see if
you have a stream file called MTA_SERVERS. Delete this file after shutting down your R5
servers and before doing the Domino 6 code installation.
5. Confirm that you are not using Directory synchronization. It is no longer supported in
Domino 6.
6. Confirm that you are not integrating Domino with the iSeries HTTP server. Be aware that
Domino 6.x integrates only with the iSeries Apache Server, not the old DG1 iSeries HTTP
server.
7. Verify the PTFs listed for Domino and TCP/IP are installed. Also check for necessary
group PTFs as documented in “Group PTFs” on page 22.
8. Be aware that support for cascaded address books ended early in Domino 5.x. Replace
cascaded address books with the Directory Assistance and Directory Catalog. You can
also use the Extended Directory Catalog.
9. Confirm whether you are integrating Domino with WebSphere. If you are, research how
Single sign-on (SSO) changes. Make sure you have a compatible WebSphere version for
Domino 6.x.
10.Upgrade each administrator’s workstation to the new Notes Administrator client version.
11.Upgrade the design of the Domino Directory on the administration server:
a. Backup the Domino Directory to a LAN server or workstation using the Notes or
Administrator client before upgrading its design.
b. Backup custom design elements such as views or agents from NAMES.NSF.
c. Delete full text index for the directories.
d. Set the Domino Directory to not replicate its design on those servers staying on
previous releases.
e. Temporarily disable Directory replication on the administration server.
f. Replace the design of the Domino Directory on the administration server with the
Domino 6 template.
g. Access the Domino Directory via the Administrator client to check that it works.
h. Add back Directory customizations.
i. Turn replication back on and replicate updates to other servers targeted to be
upgraded.
j. Create a new full text index for the Domino Directory and other directories as needed.
k. Update the Security tab on your server document with new security settings.
l. Monitor servers.

Getting ready to install Domino 6

1. If you use LDAP services, delete any full-text indexes created for NAMES.NSF or any
secondary address book used by LDAP.
2. Disable any event monitors.
3. Disable all program documents.
4. If the Domino servers you are upgrading are clustered, restrict all access to these servers
so users are not connecting.

Chapter 2. Administering your Domino environment 99

 5. Complete or purge all requests in the ADMIN4.NSF database by executing the TELL
ADMINP PROCESS ALL command on your administration server.
6. Allow all mail to route out of your MAIL.BOX file(s).
7. Implement your decision on database designs. Make NOTES.INI and program document
changes to disable the DESIGN task, if needed.
8. Delete any databases from your servers that you do not need such as restored mail files
and test databases. Document the list of databases you deleted for future reference.
9. Use COMPACT -B against all databases to recover white space and reduce file size. In
the Domino console, enter:
load compact -B

Note: One of the Domino R5 enhancements was the support for the compacting of
databases even when they are in use. However, databases need to have the R5 ODS
version to allow this. We assume in this step that all your Domino databases have the
R5 ODS version and that NAMES.NSF has been compacted with the server down once
(this was a special requirement for NAMES.NSF when upgrading a Domino server from
Domino 4.x).

If this is not true for your environment, then refer to section 4.11.1 of the Redbook Lotus
Domino for AS/400 R5 Implementation, SG24-5592-01 for instructions on how to
execute the SBMDOMCMD in a properly set up environment to compact Domino
databases when the server is inactive.

10.End the Domino servers on this LPAR or iSeries server in a controlled manner using the
ENDDOMSVR command:
ENDDOMSVR SERVER(*all)
11.Verify all Domino servers on the LPAR or iSeries server are stopped using the
WRKUSRJOB command. Use the DROP ALL and DBCACHE FLUSH commands on the
Domino server console, if needed, to stop user activity.
WRKUSRJOB QNOTES STATUS(*ACTIVE)
12.On your LDAP server(s), rename SCHEMA50.NTF / SCHEMA50.NSF at the OS/400 level
to OLDSCHEMA50.NTF and OLDSCHEMA50.NSF.
13.When the servers are down, back up your Domino servers:
– Save everything in the Domino data directory. Do not use SAVDOMBRM.
– Save all Domino libraries
– Save the /QIBM IFS directory and all subdirectories
14.Verify that the backups completed successfully.
15.Verify that the Domino servers start up correctly after the backups.
16.End the Domino servers again using the ENDDOMSVR command:
ENDDOMSVR SERVER(*all)

Upgrade the Domino code

Run the Domino 6 installation method of your choice, for example LODRUN. See Table 1-2 on
page 24 for installation method options. Monitor the status of the upgrade.

After the installation finishes, confirm it was successful by using the Display Software
Resources (DSPSFWRSC) command or the GO LICPGM menu option 10.

100 Domino 6 for iSeries Best Practices Guide

Post installation tasks
1. If you do not want to run the Domino LDAP job on your administration server, add the
DisableLDAPOnAdmin=1 line to your NOTES.INI before starting the Domino server.
2. At the time this redbook was written there was a known problem with the Server
Availability Index. To prevent the Server Availability Index problem from causing failover,
remove any reference to Server_Availability_Threshold from the NOTES.INI on your
cluster servers. See “Getting ready to install Domino 6 — tips and tricks” on page 102 for
additional information.
3. Delete BUSYTIME.NSF on each Domino server.
4. Move the LOG.NSF, CATALOG.NSF, and MAILxx.BOX files to an upgrade backup folder.
Create such an upgrade backup folder for each Domino server. These folders should not
reside under the server’s data directory.
5. Copy the NOTES.INI file for each Domino server into the appropriate upgrade backup
folder.
6. Start the Domino server(s). If you are upgrading multiple Domino servers on the same
LPAR or iSeries server, stagger your server startups.
7. For each Domino server you have to answer the following question in the Domino server
console: “Upgrade the design of your Domino Directory?” Answer with No since you
already updated the design of the Domino Directory in step 11 on page 99.
8. Answer “Y” (for Yes) when prompted to upgrade the database designs of the
EVENTS4.NSF, ADMIN4.NSF and STATREP.NSF databases.
9. End the Domino server once it completes its first startup running Domino 6.
10.While the Domino server is ended, run COMPACT -C -i against ADMIN4.NSF, LOG.NSF,
STATREP.NSF, NAMES.NSF and any other directory to upgrade their ODS to version 43.
Here is an example of the syntax to run COMPACT -C -i on the NAMES.NSF database on
the DOMPERF server:
RUNDOMCMD SERVER(DOMPERF) CMD(CALL PGM(QNOTES/COMPACT) PARM('NAMES.NSF' '-C -i'))
BATCH(*YES)
11.Start each Domino server again and run the rest of the utilities. Stagger the submitting of
these jobs to avoid overloading your server.
– Run “load COMPACT -C -i” at the Domino server console to upgrade the ODS of the
rest of the databases.
– Run “load UPDALL -RX” at the Domino server console to rebuild views and indexes for
the new GTR search engine in Domino 6. Be aware that CPU utilization is higher than
expected at first because of the index and view rebuilding.

Production
Here is what you need to do after your upgrade:
򐂰 Know the new features and how they work in your environment.
򐂰 Share the wealth of knowledge.
򐂰 Deploy using guidelines stated earlier.
򐂰 Administer and maintain your Domino 6 for iSeries using best practices from this book and
from other IBM/Lotus documentation.

Chapter 2. Administering your Domino environment 101

2.10.6 Tips and tricks for the upgrade process
This section provides tips and tricks for each section of your upgrade process. Please
remember that the upgrade process document above is only an example. We recommend
that you customize and thoroughly test the document for your environment.

Before you upgrade — tips and tricks

򐂰 Tip: Determine your own time frame for the tasks in your project plan. You can even
spread them out over several weeks or months. You can complete a task like upgrading
the administrators’ workstations to the Domino 6 Administrator client well in advance of
your actual upgrade.
򐂰 Tip: Be specific about the Domino version you plan to upgrade to when researching
compatibility with third party products. We found that some third party products work with
Domino 6.0.1, but not with Domino 6.0.2 CF1.
򐂰 Trick: Lotus enhanced the security for designating administrators for specific groups of
tasks and programmability restrictions for agents and applications in Domino 6. The new
features work great if you understand the changes and configure your servers correctly.
Some side effects of incorrectly configured security settings are agents not running at all,
agents running with the authority of the signer instead of the user and Java applications
not working.
򐂰 Trick: Along with security settings, Lotus enhanced agents and how they work in
Domino 6. Be careful if you run a mixed environment of R5 servers and Domino 6 servers.
It is possible to have the same agent act differently running on an R5 server than when it
runs on a Domino 6 server. Refer to the LDD Today article “Decoding the new
Notes/Domino 6 agent features” by Julie Kadashevich available at:
http://www.lotus.com/ldd/today.nsf/DisplayForm/177BBE55C6848AE000256C44003AEE17?Open
Document

Getting ready to install Domino 6 — tips and tricks

򐂰 Trick: Be aware that Lotus Support is working on a hotfix to correct a problem with the
Server Availability Index at 6.x. It will report an inaccurate number on the Domino 6.0.2
CF1 server after the upgrade.
򐂰 Tip: If you upgrade the design of a database to the Domino 6.x design in a clustered
environment, the design changes will replicate to the other servers in the cluster. This
could be a problem if the other servers in the cluster are still at R5.x.
򐂰 Tip: If you decide to upgrade the design of NAMES.NSF to Domino 6, you must have
Notes 6 clients for your administrators that need to register users, rename people, delete
groups and other administrative tasks.
򐂰 Tip: If you do not intend to upgrade any database designs to Domino 6 at this time,
remove the DESIGN task from the ServerTasksat1 line in NOTES.INI. Also, remove the
DESIGN task from your program documents.

Upgrading the Domino code — tips and tricks

򐂰 Tip: We recommend that you understand the installation method you plan to use. Test the
method in a similar system environment so you know the feedback it gives you during the
installation.
򐂰 Trick: Regardless of the installation method, installing Domino 6 can take some time
depending on several variables such as memory, number of processors and number of
Domino servers on your LPAR or iSeries server. Be patient.

102 Domino 6 for iSeries Best Practices Guide

 򐂰 Trick: We spoke with an organization that noticed server documents disappearing in their
Domino Directory. We could not recreate the issue, but we want to warn you about this
intermittent issue.

Post installation tips and tricks

򐂰 Tip: Document and test the actual OS/400 commands you plan to use for post installation
tasks. We found inadvertent syntax errors in OS/400 command examples in some of the
documentation referenced in this manual.
򐂰 Tip: Thoroughly test the new programmability security features in the Domino 6 server
document before your upgrade or migrate. Determine what values you should put in each
field to prevent a disruption in service, such as mail rules not working, for your users.
򐂰 Tip: We recommend that you submit multiple COMPACT tasks to process all the
databases faster. Monitor the iSeries system usage using WRKACTJOB so you do not
overload the iSeries server.

Other upgrade related tips and tricks

Here are some other upgrade related tips and tricks that you might find helpful. These tips
and tricks relate to NOTES.INI, national language support, and mail databases.
򐂰 Tip: Document any custom NOTES.INI settings used by your Domino servers. The
Domino 6 installation and startup adds and deletes settings from your NOTES.INI files
which can cause unpredictable results if you use custom settings. Domino 6 notifies you of
some of the changes in the Notes Log, so monitor it carefully after the first server startup.
򐂰 Trick: The Domino 6 installation and startup sometimes overwrites the clustering settings
in your NOTES.INI file. Understand what the clustering settings should be in Domino 6
and verify them before starting your cluster servers.
򐂰 Tip: If you require national language support, we recommend not to upgrade Domino until
updated language packs for the desired Domino release are available.
򐂰 Tip: Change the ACLs of mail files to Editor and Maximum Internet Access also to Editor.
Users can enable the out-of-office agent and other common tasks with Editor access in
Domino 6. This can prevent users from accidentally deleting their mail files from the
server.

2.11 Maintenance tips and resources

Here are some maintenance tips and best practices that you can use in your environment:
򐂰 Use the tools built into Domino and the Domino Administrator whenever possible, since
they are generally platform independent and can run on any system that your Domino
servers run on. Use program documents in your Domino Directory to easily schedule
administrative tasks on multiple servers.
򐂰 Perform regular maintenance on your Domino servers. See “Daily monitoring checklist” on
page 65 for more information.
򐂰 Limit the number of agents to those you really need. For Domino servers accessed by
Lotus Notes clients, the number should be as low as possible. You can justify a higher
number of concurrent Web agents for Domino servers providing HTTP services for
application performance reasons.
򐂰 Visit the developerWorks® : Lotus Administrator’s Kit Web site regularly to get the latest
information on Domino Administration:
http://www.lotus.com/ldd/adminkit

Chapter 2. Administering your Domino environment 103

 򐂰 To get the latest information on OS/400 V5R2, visit the IBM iSeries Information Center
Version 5 Release 2 (V5R2) Web site at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm
򐂰 To get the latest information on running Lotus Domino for iSeries, see the Lotus Domino
for iSeries Web site:
http://www.ibm.com/servers/eserver/iseries/domino/

2.12 Special considerations for large Domino deployments

There are many new features in Domino 6, iSeries Navigator and OS/400 V5R2 that enable
options for administering large Domino environments. This section describes some of the
options that we consider best practices. The topics include:
򐂰 Administration guidelines and recommendations
򐂰 Enterprise integration
򐂰 Performance considerations
򐂰 Defining organizational responsibilities

2.12.1 Administration guidelines and recommendations

This section contains information about common topics faced by Domino administrators in
large environments and recommendations for best practices. The topics include:
򐂰 Distributed administration
򐂰 Policy-based administration
򐂰 Administering the Notes 6 client

Distributed administration
There are several new features in Domino 6 that enable you to distribute automated
administration tasks between servers and manual administration tasks between groups of
administrators. We recommend that you review these new features to determine the best
approach for your organization.

Administration process tasks

The Administration Process (AdminP) is a program that automates many routine
administrative tasks. Administration servers control how the Administration Process does its
work. By default, the first Lotus Domino server you set up in a domain is the administration
server for the Domino Directory. You can also set up one or more extended administration
servers to distribute the processing of administration requests that modify the Domino
Directory across multiple servers.

The extended administration server distributes the administration responsibilities across

multiple servers which is especially useful for remote administration of servers that are
geographically dispersed. The concept of the extended administration server was developed
in order to make remote administration available to administrators.

An extended administration server can add, modify or delete documents in the Domino
Directory only if they belong to a particular namespace within the Domino Directory. A
namespace is defined by a certification hierarchy, for example, OU=Sales/O=Acme, where
the organization is Acme and the organizational unit is Sales. You can specify the
organization or one or more organizational units as a namespace for which an extended
administration server is used to process administration requests. The traditional
administration server modifies all of the target documents in a Domino Directory which either

104 Domino 6 for iSeries Best Practices Guide

do not belong to any namespace or to which an extended administration server has not been
assigned.

Restriction: All Domino servers in the domain must be at least Lotus Domino 6.0 servers
to use the extended administration server feature.

See the section entitled “Using an extended administration server” in the Domino 6
Administrator Help for more information.

Delegate common administration tasks using extended access control list

The new extended ACL controls give enterprises the ability to delegate administration to
regional administrators without giving them manager access to the Domino Directory. You
can configure these regional administrators to allow them to administer only directory
documents or directory objects related to their own organizational units.

Important: To ensure that the database replicates properly, extended access requires the
use of the advanced database ACL option “Enforce a consistent Access Control List
across all replicas.”

See Chapter 14, “Extended ACL” in Upgrading to Lotus Notes and Domino 6, SG24-6889 for
more information about planning and implementing extended ACLs in your organization.

Policy-based administration
A new technology, introduced in Domino 6, helps you to apply and manage standard
corporate client and desktop-based policies. This technology is called policy-based
administration. With the new policy-based administration model you can control your users’
desktops, security settings, archiving, client setup, and user registration in a structured way.
This will put you, as an administrator, more firmly in control of your environment and also
gives you a flexible way to manage and assist users, down to the client and even the
document or field level, without needing direct access to each user's computer frequently.

As we mentioned in “Policy-based system administration” on page 17, you should thoroughly

plan your implementation of policy-based system administration. We recommend creating
explicit policies instead of using exceptions.

Resources
The following resources help you to plan and setup policies for your environment:
򐂰 See Chapter 15, “Policy-based administration” in Upgrading to Lotus Notes and Domino 6,
SG24-6889 for more information about planning and implementing policies in your
organization.
򐂰 Refer to Chapter 9, “Using Policies” in Administering the Domino System, Volume 1
available at this Web site:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument

Administering the Notes 6 client

There are several new features available for administering the Notes 6 client environment.
They include client installations options, managing the desktop, and automatic upgrades.

Chapter 2. Administering your Domino environment 105

 Client installation options
There are several options for installing the Notes 6 client:
򐂰 Single-user client installation
򐂰 Multi-user installation
򐂰 Shared installation
򐂰 Automated client installations (silent installation)
򐂰 Customized installations
򐂰 Batch file installation
򐂰 Installation with command line utilities
򐂰 Scriptable setup

For details about these options, please see the section entitled “Setting up client installation
for users” starting on page 5-41 in Administering the Domino System, Volume 1.

Managing the desktop

You use a desktop policy settings document to control the user's workspace. Desktop
settings are enforced the first time a user logs in to Notes and runs setup. After the initial
setup, you can use them to update the user's desktop settings or to reinforce them. Users
receive updates to the settings when any of the policy settings change, the desktop policy
settings are then enforced the next time users authenticate with their home server.

We recommend creating desktop policy settings documents for user groups that require
similar desktop configurations such as the help desk, accounting department, and marketing
department.

See the section entitled “Creating a desktop policy settings document” in the Domino 6
Administrator Help for more information.

Automatic client upgrades

Once you have upgraded your users to Notes 6, you will be able to make use of another new
feature called Smart Upgrade. Smart Upgrade notifies users to update their Notes 6 clients to
later releases. Lotus Notes Smart Upgrade uses policies and settings documents to help
manage updates. For more information, see 16.1.5, “Smart Upgrade” in the redbook
Upgrading to Lotus Notes and Domino 6, SG24-6889.

Resources
This is a list of documents related to Lotus Notes client administration:
򐂰 See chapter 7, “Lotus Notes client upgrades” and chapter 16, “Administering the Notes 6
client” in Upgrading to Lotus Notes and Domino 6, SG24-6889 for more information.
򐂰 Refer to the topic “Setting up client installation for users” in the Domino 6 Administrator
Help.
򐂰 See the section entitled “Setting up client installation for users” on page 5-41 in
Administering the Domino System, Volume 1.
򐂰 Distributing Notes Clients Automatically, REDP3693, available at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/redp3693.html?Open

2.12.2 Enterprise integration

This section describes the integration of your Domino and iSeries environment with
enterprise tools. It contains information about the following topics:
򐂰 Spam filtering
򐂰 Antivirus protection

106 Domino 6 for iSeries Best Practices Guide

򐂰 Web caching and Domino content
򐂰 Citrix MetaFrame and Domino 6
򐂰 Storage area networks
򐂰 SSL accelerators

Spam filtering
In a very broad sense, spam is the reception of unsolicited commercial e-mail. Spam is
designed to flood the Internet with mass mailings, attempting to reach the largest audience
possible. A very important aspect of what constitutes spam is that spam has negative effects
on those who receive it.

Many organizations address spam filtering at several levels, for example, at the firewall level,
the Internet mail server level, the Domino server level, and the desktop level. We recommend
that you understand how spam filtering works at all levels in your organization. This
understanding provides you with more problem solving tools when supporting e-mail for your
users.

Please refer to the redbook Lotus Domino 6 spam Survival Guide for IBM eServer,
SG24-6930, for information on the following topics:
򐂰 Spam avoidance techniques
򐂰 How to block spam
򐂰 Domino 6 anti-spam architecture
򐂰 Domino 6 anti-spam features
򐂰 Third party anti-spam products

The redbook is available at

http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/sg246930.html?Open

Some information on spam filtering is also available in Chapter 9, “Antivirus protection” on

page 405 of this redbook.

Antivirus protection
Many organizations also address antivirus protection at several levels, for example, at the
firewall level, the Internet mail server level, the Domino server level and the desktop level. We
recommend that you understand how antivirus protection works at all levels in your
organization. Your organization could possibly take advantage of economies of scale when
purchasing an antivirus solution for the enterprise.

iSeries and virus protection

Files controlled directly by the OS/400 operating system are inherently virus resistant
because the iSeries architecture precludes a program from pretending to be a file. Files in
root directories of the integrated file system (IFS) and mail inbound from the Internet,
however, pose a greater challenge. Some independent software vendors provide tools to
address this issue.

Domino 6 and virus protection

We included a chapter in this book specific to the topic of virus protection for Domino 6 for
iSeries. The products included in the discussion are:
򐂰 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400
򐂰 Symantec AntiVirus/Filtering 3.0 for Domino on iSeries

Please refer to Chapter 9, “Antivirus protection” on page 405 in this book for more
information.

Chapter 2. Administering your Domino environment 107

 Also, we recommend protecting against “mail bomb” viruses by disabling access to the local
workstation using appropriate ECL settings. A best practice is to disable -Default- and -No
Signature- access of applets and Javascript to the workstation. See the topic “ECL security
access options” in Domino 6 Administrator Help for more information.

Web caching and Domino content

Many organizations design their network architecture to minimize the impact of Web browsing
on their network through the use of proxy and caching servers. Domino R5 did not support
the HTTP header rules required to communicate the expiration of Web content to proxy and
caching servers or Web browsers. You can now configure the Domino HTTP server or the
IBM HTTP Server (powered by Apache), available on the iSeries, to include this functionality.

Domino HTTP server

Every HTTP browser request and server response begins with a set of headers that describe
the data that is being transmitted. The caching headers include the Last-Modified header,
Expires header, and Cache-Control header. The Last-Modified header indicates when the
resource or resources used to generate a response were last changed. The Expires header
tells the browser when resources are expected to change. A designer can define a rule to add
Expires headers to responses based on when the designer expects resources to change. The
Cache-Control header provides explicit instructions to browser and proxy server caches, such
as “no-cache” for responses that should not be cached, or “private” for responses that are
cacheable but are specific to a particular browser configuration.

Domino 6 includes the HTTP header, cache information and expiration information
functionality in its HTTP server. You can include configure the HTTP server to include
customized information at the server level for your environment and include customized HTTP
header information in your Domino Web applications.

If the network team in your organization created exception rules for Web content generated
by Domino servers, test the behavior of the Web content when generated by the Domino 6
HTTP server. They can disable the exception rules since Domino 6 provides explicit
instructions for handling Web content.

For information on configuring the Domino HTTP server, refer to the following references:
򐂰 The topic “Web Site rules and global Web settings” in the Domino 6 Administrator Help.
򐂰 The section called “HTTP response header rules”, starting on page Page 34-36, in
Administering the Domino System, Volume 1.

For information on customizing HTTP header information in your Domino Web applications,
see the following references:
򐂰 LDD Today article: “Building Web applications in Domino 6: Browser caching and
response header rules” by John Chamberlain:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/2aa6ecf8f2950190
85256b9c006fd147?OpenDocument&Highlight=0,cache
򐂰 Table 4-7 (Table of CGI variables supported by Domino) in the redbook Domino
Designer 6: A Developer’s Handbook, SG24-6854 at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246854.html?Open

IBM HTTP server (powered by Apache)

The Lotus Domino Administration help text, which ships with Domino 6 for iSeries, documents
how to configure your Domino server to work with Web servers such as Microsoft Internet
Information Services (IIS) and the IBM HTTP Server. Since the printing of that document, the
iSeries development team produced a new plug-in specifically designed to allow you to also

108 Domino 6 for iSeries Best Practices Guide

serve Domino content via an IBM HTTP Server (powered by Apache). With Domino 6 for
iSeries, customers can now choose between two different Web servers on OS/400. Web
content can be served through either the Domino 6 for iSeries HTTP server or the IBM HTTP
Server (powered by Apache). Refer to Chapter 6, “Domino 6 for iSeries Apache plug-in” in
IBM Lotus Domino 6 for iSeries Implementation, SG24-6592 for more information.

We recommend thorough testing of this feature before introducing it into your production
environment because it is not widely used yet.

Citrix MetaFrame and Domino 6

Starting in Domino 6.0.2, Citrix MetaFrame Xpe FR2 supports the Lotus Notes client on
Windows 2000 server using NT and Mac Independent Computing Architecture (ICA) clients.
Citrix ICA Client separates an application's logic so that the server processes tasks, but the
client shows only screen updates.

Tips and tricks

򐂰 Tip: Use the PercentAvailSysResources setting in the NOTES.INI in a Citrix MetaFrame or
Windows Terminal Server environment. For example, if there are 20 data directories on
the terminal server, then the NOTES.INI file in each client data directory could contain the
parameter PercentAvailSysResources=5. This limits each user on the Citrix MetaFrame
server to only five percent of the server's system memory. You assign a portion of memory
to each client by specifying a value from 2 to 100, which represents a percentage of a
system's total physical memory.
򐂰 Trick: Domino Web Access (iNotes) and WebMail are not supported on Citrix MetaFrame
as of this writing.

Resources
These documents contain information about Citrix MetaFrame and Windows Terminal Server:
򐂰 Technote 1098489 entitled “Supported Configurations and Support Policy for Citrix
MetaFrame” available at:
http://www.ibm.com/support/docview.wss?rs=203&q=citrix+%22domino+6%22&uid=swg21098489&lo
c=en_US&cs=utf-8&lang=en+en
򐂰 Redpaper Implementing Windows Terminal Server and Citrix MetaFrame on
IBM ^™®xSeries Servers, REDP-3629 at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/REDP3629.html?Open
򐂰 Technote 1101768 entitled “Is iNotes Access for Microsoft Outlook or iNotes Web Access
Supported on the Citrix Platform?” available at:
http://www.ibm.com/support/docview.wss?rs=0&uid=swg21101768

Storage area networks

As businesses become more and more dependent on information technology to conduct their
operations and stay competitive, the availability of their processing facilities becomes crucial.
Today, most businesses require a high level of availability, which extends to continuous
availability, 24 hours a day and seven days a week (24x7) operation. A lengthy outage could
lead to significant financial losses, loss of credibility with customers, and maybe even a total
failure of business. Therefore, the ability to provide continuous availability for the major
applications is more often than not a necessity for business survival. A key component of a
highly available system is the storage subsystem. It is essential that data is available at all
times and that downtime for data backup and software maintenance is minimized or more
preferably, eliminated.

Chapter 2. Administering your Domino environment 109

 What is a SAN? One definition of a Storage Area Network (SAN) is a high-speed network,
comparable to a LAN, that allows the establishment of direct connections between storage
devices and processors (servers) centralized to the extent supported by the distance of fibre
channel. The SAN can be viewed as an extension to the storage bus concept that enables
storage devices and servers to be interconnected using similar elements as in Local Area
Networks (LANs) and Wide Area Networks (WANs): routers, hubs, switches, directors and
gateways. A SAN can be shared between servers and/or dedicated to one server. It can be
local or can be extended over geographical distances.

A SAN can be used to bypass traditional network bottlenecks. It facilitates direct, high speed
data transfers between servers and storage devices, potentially in any of the following three
ways:
򐂰 Server to storage: This is the traditional model of interaction with storage devices. The
advantage is that the same storage device may be accessed serially or concurrently by
multiple servers.
򐂰 Server to server: A SAN may be used for high-speed, high-volume communications
between servers.
򐂰 Storage to storage: This outboard data movement capability enables data to be moved
without server intervention, thereby freeing up server processor cycles for other activities
like application processing. Examples include a disk device backing up its data to a tape
device without server intervention, or remote device mirroring across the SAN.

Since this is a highly specialized area, please contact your IBM representative or ISSL Sales
Specialist for documented approaches for using a SAN with the iSeries.

For more information about SANs, refer to the following resources:

򐂰 Redbook IBM ^ iSeries in Storage Area Networks: Implementing Fibre Channel
Disk and Tape with iSeries, SG24-6220 available at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246220.html?Open
򐂰 Redbook Introduction to Storage Area Networks, SG24-5470 available at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/SG245470.html
򐂰 IBM TotalStorage® hardware, software, and solutions:
http://www.storage.ibm.com
򐂰 IBM TotalStorage Storage networking:
http://www.storage.ibm.com/snetwork/index.html
򐂰 Tivoli:
http://www.ibm.com/software/tivoli/
򐂰 IEEE:
http://www.ieee.org
򐂰 Storage Networking Industry Association:
http://www.snia.org

SSL accelerators
SSL accelerators have already been discussed in “Environmental planning” on page 4.
Please refer to 1.1.12, “SSL accelerators” on page 13.

110 Domino 6 for iSeries Best Practices Guide

2.12.3 Performance considerations
This section contains an overview of performance considerations for a large Domino
environment and information about monitoring tools in Domino 6. This book features detailed
information about performance monitoring in chapter “Monitoring Domino performance on the
iSeries” on page 121. We have also included a chapter on “Tuning Domino performance on
the iSeries” on page 171.

Overview
When looking at performance, you also need to look at capacity and tuning, by monitoring the
resources used in your system. Figure 2-23 shows the flow of the initial sizing, the monitoring,
and either the tuning actions to be undertaken or the adding of additional resource to adjust
the initial sizing.

Initial sizing

Monitor

Tune Add resource

Inside resource limits Outside resource limits

Figure 2-23 Process diagram of monitoring and tuning your Domino system

Monitoring your Domino servers

Monitoring your Domino and iSeries servers in a large Domino environment is a daunting
task. Both Domino 6 and the iSeries provide statistical data on the behavior, usage, and load
of the operating system and the Domino servers that run on it. Use information from both
sources to determine whether to tune your workload or to add resources to accommodate the
workload. To identify and analyze trends, you must recognize the characteristics of the
workloads on your servers. We recommend that you integrate the monitoring of your Domino
and iSeries environment with your organization’s enterprise monitoring tools to take
advantage of economies of scale and the current skill sets of your staff.

Here is an overview of the tools you can use:

򐂰 Management Central in iSeries Navigator
򐂰 iSeries Collection Services with new Domino integration
򐂰 Statistic collector task in Domino
򐂰 Domino Simple Network Management Protocol agent
򐂰 IBM Tivoli Analyzer for Lotus Domino

Management Central and iSeries Collection Services

Please refer to Chapter 3, “Monitoring Domino performance on the iSeries” on page 121 for
information on the Management Central feature in iSeries Navigator and the iSeries
Collection Services feature that now includes Domino information. This chapter also includes
step by step instructions for creating reports from the iSeries Collection Services data store.

Chapter 2. Administering your Domino environment 111

 Statistic collector task in Domino
Domino continuously generates and updates server statistics, which you can collect and
monitor in a number of ways. From the server, you can use the Show Statistic or Show
Platform Statistic commands. From the Domino Administrator, you can create statistics
profiles and charts. The Statistic collector task (also called the Collector task) must be
running on the server or on a server designated to collect statistics from one or more other
servers. It collects server statistics and stores them in the server’s Monitoring Results
database (STATREP.NSF).

Refer to the section called “Statistics and the Domino system” starting on page 52-24 in
Administering the Domino System, Volume 1.

Domino Simple Network Management Protocol agent

The Domino Simple Network Management Protocol (SNMP) agent enhances the monitoring
and control features of Domino by enabling third-party management stations, which use
industry standard SNMP, to manage aspects of the Domino server.

The agent provides:

򐂰 Out-of-band server status through the Domino Management Information Base (MIB)
򐂰 Control of a Domino server through SNMP
򐂰 Real-time alerts on server status
򐂰 Forwarding of Domino events as SNMP traps
򐂰 Domino statistics through the MIB

The Domino SNMP agent supports SNMP version 1. For more information about
implementing the Domino SNMP agent in your environment, consult chapter 53, “Using the
Domino SNMP Agent” in Administering the Domino System, Volume 2.

IBM Tivoli Analyzer for Lotus Domino

The IBM Tivoli Analyzer for Lotus Domino includes two integrated system-management tools:
the Server Health Monitor, which offers real-time assessment and recommendations for
server performance, and Activity Trends, which provides data collection, data exploration, and
resource balancing. The IBM Tivoli Analyzer for Lotus Domino is a separate product offering
from Tivoli Systems.

The Server Health Monitor determines server health by calculating health statistics and
comparing them against preset thresholds. The Server Health Monitor reports the
information, pinpoints problematic server components, and provides short-term and
long-term recommendations for restoring server health.

Activity Trends collects and stores activity statistics as current observations and historical
trends. The activity statistics relate to the server, databases, users, and connections of users
to databases. You can explore the collected data to see how database workload is distributed
across servers. Using the data, Activity Trends recommends a resource-balancing plan.
Then, working with the Domino Change Manager, which is a part of the Domino server,
Activity Trends provides a workflow that facilitates implementing the recommended changes.

For more information on the IBM Tivoli Analyzer for Lotus Domino, refer to Chapter 54, “Using
IBM Tivoli Analyzer for Lotus Domino” in Administering the Domino System, Volume 2 and to
the IBM Tivoli Analyzer for Lotus Domino Web site at:
http://www.ibm.com/software/tivoli/products/analyzer-lotus-domino/

112 Domino 6 for iSeries Best Practices Guide

 Resources
Here are two additional information sources related to these Domino server monitoring tools:
򐂰 The topics entitled “IBM Tivoli Analyzer for Lotus Domino” and “Domino Change Manager”
in Domino 6 Administrator Help.
򐂰 See chapters 52 - 56 in Administering the Domino System, Volume 2 for more information
on monitoring the Domino server.

2.12.4 Defining organizational responsibilities

This section contains an example of defining roles and responsibilities in your organization.
The example documents the Domino team and the iSeries team. We recommend that you
create similar documentation for each department that interacts with the Domino team.

Overview
Domino for iSeries brings together different environments, which were until recently far apart:
The iSeries environment and the Domino environment, both with a history of their own. It is,
therefore, absolutely essential for a successful implementation of Domino for iSeries, that the
people in these environments communicate and establish a mutual understanding of each
others’ backgrounds and methods of work.

Introduction to environment backgrounds

This section addresses the background of each environment. We then list areas where
environments might overlap, which could cause conflicting interests between the
organizational groups. Finally, we provide recommendations on how to solve these conflicts.

iSeries background
The iSeries environment is highly automated. In most cases it is monitored from one central
point, called the operations department. The main objectives of the operations department
are to keep the system up and running, monitor performance, and react to any incidents
which might hamper the availability and performance of the system. In addition, iSeries
operators also start, stop, and restart tasks running in the system, and they restart (IPL) the
entire system if needed. Users are concerned about availability of the system, maintenance
windows (downtime), and performance requirements. So they often work out an SLA with the
operations department. A job scheduler task, such as the Advanced Job Scheduler, is very
often used to run jobs at a predetermined time or when certain predefined conditions are met.
This is for example used for running housekeeping jobs and the subsequent restart of an
application or task.

Domino background
In most distributed implementations of Domino, the operating platform (for instance, NT or
AIX) is usually dedicated to the Domino server. Because of this, OS level access is often
restricted to Domino administrators. SLAs are, therefore, made by the Domino administration
group, since they control the service end-to-end. The Domino administrator usually goes to
the operating system of the server to accomplish the following tasks:
򐂰 Perform maintenance on the OS, such as examining the log files or changing the IP
address.
򐂰 Access a database in local mode to modify the ACL, in case it becomes corrupted or was
misconfigured (such as excluding anyone from having manager access).
򐂰 Examine the contents of the NOTES.INI file.
򐂰 In case of a server crash, examine the last messages on the Domino server console for
further investigation into the cause of the crash.

Chapter 2. Administering your Domino environment 113

 򐂰 Reboot the Domino server after a crash.
򐂰 Reboot the Domino server as a preventive measure, based upon monitoring information,
before a crash takes place.

Note: The latter two tasks can also be performed by an automated monitoring utility.

򐂰 Reboot the Domino server to let a changed NOTES.INI parameter take effect (one that is
only read during startup of the Domino server).
򐂰 Reboot the server at OS level to clean up all Domino processes and free up all resources
allocated by Domino after a crash.
򐂰 Run Domino maintenance utilities, such as COMPACT and FIXUP, in an offline mode.
򐂰 Restore databases from backup.

Conflicting interests
From the backgrounds mentioned above, you can see that when Domino is installed on an
iSeries, there are areas where the iSeries and Domino administration groups have
overlapping activities, such as:
򐂰 Emergency stopping and starting of the Domino server
򐂰 Scheduled stopping and starting of the Domino server
򐂰 Backup and restore activities
򐂰 Monitoring and maintaining hardware and OS
򐂰 Setting up of SLAs
򐂰 Monitoring of application (Domino) behavior
򐂰 Application (Domino) maintenance
򐂰 Tuning and monitoring of servers
򐂰 Application development, for instance, DB2 access

To avoid a situation where both groups claim they need to perform one or more of these
activities, careful consideration needs to be made when deciding which activity is most
applicable to which group. Before assigning responsibilities, the following questions should be
considered:
򐂰 Can the operation be completed entirely from the Domino environment? If so, the Domino
administrators are the most likely candidates for the operation.
򐂰 Can the operation be completed entirely from the iSeries environment? If so the iSeries
administrators are the most likely candidates for the operation.
򐂰 Which group does the user community see as owner of the system. This is the group
whom the user contacts in case of failure. Since a chain is only as strong as its weakest
link, we recommend that all groups be consulted or at least notified before any “user
noticeable” action is taken.

Based upon the previous considerations, assigning the tasks can be done as follows:
򐂰 Emergency stopping and starting of the Domino server:
This should be a joint effort between the Domino and iSeries administration groups. In
case a Domino server is not functioning properly, the Domino group investigates the
problem and notifies the iSeries group. If the Domino group identifies that the Domino
server requires a restart, the iSeries administrators should be the ones to issue the
commands to stop and start the server (for example at the iSeries system console). Even

114 Domino 6 for iSeries Best Practices Guide

 though there are several ways to accomplish this outside the Domino server console and
let the Domino administrator issue the restart, you should consider these facts:
– In the case of a crash, normal shutdown procedures often do not work. So the server
might not release all resources, or not come down at all.
– In determining whether Domino has ended normally and released all address spaces,
you must have the right skills and access level for the iSeries. These are also required
to fix any complications after a crash.
– To determine the cause of a crash, often a dump is required for root cause analysis by
IBM. This can only be generated from a 5250 workstation emulation session. Naturally,
good cooperation between the two groups is of vital importance, particularly in this
situation. Communication should be as direct as possible to ensure a quick restoration
of service.
򐂰 Scheduled stopping and starting of the Domino server:
If this is a requirement on an as-needed basis, such as a configuration change, then the
Domino group issues a request with the iSeries group to have this done at an agreed time.
When this is a requirement from the iSeries group, for instance to perform housekeeping,
the iSeries group will have to consult the Domino group regarding if and when this can be
done, then the iSeries group can perform the restart. If this is a requirement on a regularly
scheduled basis, such as an offline fixup of the directory, then this should be scheduled
from the Domino environment by the use of a program document.
By initiating the scheduled server restart from Domino through a program document, you
can also develop scripts that perform the same function on platforms other than the
iSeries. This way, the Domino administrators keep the overview of what is scheduled for all
servers, regardless of the platform they run on.
򐂰 Backup and restore activities:
Since this operation can be done entirely from the iSeries environment, it is recommended
that the iSeries operations group be assigned to this activity.
򐂰 Monitoring and maintaining the hardware and operating system:
Since this operation can be done entirely from the iSeries environment, it is recommended
that the iSeries administrator group be assigned to it. For any changes to the operating
system, such as the installation of new PTFs, the iSeries group should inform the Domino
group before making any changes, as this can also affect the Domino server.
򐂰 Setting up SLAs:
In the case of a mixed environment, the user community is usually unaware of the type of
server on which their mail file or application resides. Even in an environment where
Domino runs exclusively on the iSeries, the user community looks at Domino as a whole,
including the non-iSeries related issues. Therefore, it is recommended that the Domino
group creates the SLAs with the user community. For aspects that are not performed by
the Domino group, such as backup and restore, these should be made in cooperation with
the iSeries group, but for the end-user visible activities, just the Domino group should be
involved.
򐂰 Monitoring application (Domino) behavior:
The iSeries group should monitor the Domino server the same way they monitor any other
application on the system. They can take advantage of additional tools which are provided
with Domino, such as Domino Console support. When they see something going wrong,
they should consult the Domino group before taking action.
The Domino group should monitor the server the same way they would monitor Domino on
any other platform. Regardless of who restarts the Domino server after a problem, the
Domino group should inform the iSeries group before taking action. Any issues which are

Chapter 2. Administering your Domino environment 115

 inside the Domino environment, such as ACL changes, replication problems, and mail
routing problems, can and should be handled by the Domino group alone.
򐂰 Application (Domino) maintenance:
Where maintenance does not require a server restart or upgrading of the Domino code,
this can be done by the Domino group. If it does involve a server restart or an upgrade of
the Domino code, it is still the responsibility of the Domino group, but the iSeries group
must be informed before any changes are made. This is especially true when upgrading
the Domino code, as this could also require PTFs to be installed on the iSeries (for
OS/400 or TCP/IP for example).

General recommendations
A written agreement should be drawn up between the groups, specifying exactly who can do
what. This agreement should not be static, but evaluated from time to time. Changes may be
required if things work a little differently from what you planned.

Exchange knowledge between the groups. The Domino group should have an adequate
understanding of what iSeries is all about. The iSeries group should have an adequate
understanding of what Domino administration is all about. The physical locations of the
Domino and iSeries groups should not be too far apart, to ensure there is good
communication between the two groups. Usually communication improves when people
actually know each other and are not talking to an anonymous voice at the other end of a
phone line.

To avoid conflicts of interest, both groups should be part of the same department. This can
reduce issues about budget, personnel, and so forth. Synchronize the change processes.
The two groups should make use of the same resources for entering and approving changes
to their environment. When this proves impossible, both groups should at least give each
other access to their individual change processes and make them part of the approval cycle.

Domino SLA
In this section we state the subjects to cover in an Domino-only SLA with the end user.
However, the details are very much dependent on your organization, and general guidelines
are difficult to establish. Note that only parameters which can be measured should be
incorporated in an SLA.

Subjects to cover might include:

򐂰 Domino server availability (for example, 98% available on a 24/7 basis)
򐂰 Domino cluster availability (for example, 99,5% available on a 24/7 basis)
򐂰 Application availability (for example, 97%, cannot be higher than server and/or cluster
availability)
򐂰 Mail delivery time (for example, 95% within 2 hours)
򐂰 Mail file restore time (for example, 90% of requests within 2 hours)
򐂰 ID creation time (for example, within 24 hours)
򐂰 Problem response time (for example, 90% fixed within 8 hours)
򐂰 Help desk wait time (for example, 95% less than 30 seconds)
򐂰 Directory lookup time (for example, 5 minutes)
򐂰 Password reset time (for example, 95% less than 2 hours)
򐂰 Group creation time (for example, 90% less than 2 hours)
򐂰 Mail usage
򐂰 Maintenance windows
򐂰 Backup and restore
򐂰 Application promotion to production
򐂰 Replication performance

116 Domino 6 for iSeries Best Practices Guide

iSeries SLA
This section describes the subjects that might be covered in an iSeries SLA in relation to
Domino running on the iSeries system:
򐂰 CPU utilization for Domino
򐂰 Availability of iSeries itself and Domino
򐂰 Backup and recovery time
򐂰 When to perform housekeeping
򐂰 How long the housekeeping takes
򐂰 What is included in the housekeeping
򐂰 Performance
򐂰 Problem solving time
򐂰 Maintenance (this might be included in an SLA because keeping up to date with your
maintenance level is very important when running Domino in an iSeries environment)
򐂰 Organizational responsibilities

Other roles and responsibilities

Here are some other roles and responsibilities that you can use to create the SLAs for your
organization.

End user
򐂰 Perform their primary job function
򐂰 Report Notes-related problems to on-site support or a help desk
򐂰 Cooperate with support to resolve problems
򐂰 Participate in desktop upgrades, hardware and software
򐂰 Be aware of scheduled Notes server outages or upgrades

Application business owner (Subject Matter Expert):

򐂰 Identify business needs for new applications or revisions to existing applications
򐂰 Identify application requirements
򐂰 Verify Notes suitability to task
򐂰 Determine if application is organization-wide or department-based
򐂰 Identify user groups for security and authorization roles
򐂰 Provide input to Application developer
򐂰 Develop/verify application test/acceptance plans and criteria
򐂰 Identify a delegate or backup for this role
򐂰 Make decisions about access levels, role membership, and group memberships
򐂰 Monitor application response time
򐂰 Monitor application contents — specify archival interval for documents
򐂰 Serve as primary decision maker for “their” applications
򐂰 Maintain the “About” and “Using” documents with application and contact information
򐂰 Receive enhancement suggestions to applications from end users

Help desk / support analyst (Level 1 support)

򐂰 Respond to calls from end users
򐂰 Log all calls
򐂰 Resolve the call (if possible) and close it in the problem management system
򐂰 Escalate the call to the next level of support when needed
򐂰 Coordinate with other support personnel as required
򐂰 Publicize scheduled outages to end users

Application developer
򐂰 Develop new applications at request of application business owner
򐂰 Modify existing applications at request of applications business owner

Chapter 2. Administering your Domino environment 117

 򐂰 Provide technical guidance to application business owner
򐂰 Test certify new and changed Notes and Web applications
򐂰 Develop application roll-out schedule with production support
򐂰 Participate in application deployment process
򐂰 Stage new applications for production
򐂰 Specify “global” or “regional” application usage and replication requirements
򐂰 Comply with organizational design and security standards

Network server administrator

򐂰 Manage file system access to network and Notes data directories
򐂰 Troubleshoot and resolve OS and network problems on servers
򐂰 Maintain OS release and patch levels
򐂰 Install and configure server hardware and software
򐂰 Monitor disk space
򐂰 Interface with hardware/OS vendors on specific problems
򐂰 Schedule and monitor server utility programs
򐂰 Investigate and resolve networking problems
򐂰 Maintain/update procedure documents for Computer Operations

Desktop support
򐂰 Provide first level support for all desktop applications
򐂰 Provide first level support for network file and print servers
򐂰 Backup local file and print servers
򐂰 Provide first level support for Notes problems
򐂰 Escalate problems to second level desktop support

IS Management
򐂰 Work with Notes program management to allocate resources
(hardware, software, people) to Notes operations and support
򐂰 Support the organization’s Notes program
򐂰 Ensure support contracts are current and reflect specified service levels
򐂰 Provide administrative support to Notes program

Lotus Technical Support

򐂰 Record and resolve all problems reported by customer
򐂰 Provide Level III Notes support
򐂰 Escalate reported issues to appropriate resources

Hardware vendor(s) technical support:

򐂰 Provide onsite response within specified service levels
򐂰 Resolve reported problems within specified service levels
򐂰 Maintain 24x7 response capability
򐂰 Maintain spare parts inventory onsite (Tier 1 sites only)
򐂰 Provide OS patches and fixes
򐂰 Provide updates to OS
򐂰 Advise on performance and capacity planning metrics and techniques

Information Security
򐂰 Random audit of Notes servers for compliance with customer Information Security Policy
򐂰 Provide guidance to Notes developers and administrators on security issues and
exposures
򐂰 Jointly develop remediation plans for security exposures
򐂰 Assess network security vulnerabilities
򐂰 Develop policy on use of encryption

118 Domino 6 for iSeries Best Practices Guide

򐂰 Advise on physical security issues
򐂰 Periodically conduct penetration testing of network and server security
򐂰 Revise/extend Information Security Policy to cover Notes, if needed

Lotus Instant Messaging/Domino Program Manager

򐂰 Provide overall direction for customer collaboration program
򐂰 Implement Notes-related policies
򐂰 Participate in Notes policy forum
򐂰 Develop plans and time lines for migration and upgrades
򐂰 Negotiate Notes service levels with individual business units
򐂰 Define Notes service offerings
򐂰 Plan and coordinate upgrades to new releases of Notes server and workstation software
򐂰 Stay abreast of Notes product directions
򐂰 Identify improvements in internal processes to improve service delivery
򐂰 Prepare budgets and staff plans for the Notes environment
򐂰 Work with information systems management to integrate Notes support into overall
support plan
򐂰 Oversee Notes-related research and development activities
򐂰 Manage Notes support organization
򐂰 Direct the activities of the Notes integration engineering group

Chapter 2. Administering your Domino environment 119

120 Domino 6 for iSeries Best Practices Guide
 3

Chapter 3. Monitoring Domino performance

on the iSeries
In this chapter we describe different ways to monitor the performance of Domino on the
iSeries. It is not an exhaustive resource on this topic, but it includes the basic information you
need to set up and use the new performance monitoring features of Domino 6 for iSeries,
including:
򐂰 A ten minute performance checklist that can be done from a 5250 workstation emulation
session to determine the potential cause of a performance problem. This ten minute
checklist is designed to help an administrator to quickly narrow down the possible cause of
a performance problem. It is designed to be run on a 5250 workstation emulation session
and gives you a starting point when debugging performance problems.
򐂰 Information on the new Management Central Domino server job monitor. This new
function allows you to keep an eye on the iSeries system health in real time.
򐂰 Information on the iSeries Collection Services with the new Domino 6 integration to
monitor both Domino server and OS/400 statistics using historical data.

© Copyright IBM Corp. 2004. All rights reserved. 121

3.1 Ten minute checklist for spotting performance problems
The ten minute checklist only requires a few iSeries and Domino commands. These
commands allow you to check most of the major OS/400 aspects that could affect
performance. Please note that this is really only a checklist! For complete information on the
commands being used and what they mean to performance, see Chapter 4, “Tuning Domino
performance on the iSeries” on page 171.

Be aware that the first few times you run this checklist, it may take more than ten minutes. It
takes a while to get familiar with the commands and their implications.

Note: Prior to OS/400 V5R1, pools were always called storage pools. The iSeries
Navigator started using the term memory pool in V5R1. Since most CL commands and the
IBM documentation still refers to them as storage pools, we use that term in this book.

For a quick check, run the following commands and write down the output/results:
1. DSPSYSVAL SYSVAL(QMODEL)
– Write down the model number of your iSeries.
See Chapter 11, “Using the IBM Eserver Workload Estimator” on page 463 for MCU
ratings.
2. WRKHDWRSC TYPE(*PRC)
– Write down the Processor Capacity Card and the Interactive Card information.
See Chapter 11, “Using the IBM Eserver Workload Estimator” on page 463 for MCU
ratings.
3. DSPSYSVAL SYSVAL(QMAXACTLVL)
– Make sure that this system value is set to *NOMAX.
See “QMAXACTLVL” on page 212 for information on this system value.
4. WRKACTJOB
– Write down the system CPU and CPU of individual Domino jobs.
See “Work with Active Jobs (WRKACTJOB)” on page 185 for information on CPU.
– Write down the run priority of the Domino jobs.
See “Run priority” on page 192 for information on job run priorities.
– Write down the storage pool the Domino jobs are running in.
See “Work with Active Jobs (WRKACTJOB)” on page 185 to identify a storage pool.
5. WRKSYSSTS
– Write down the paging/faulting in the *MACHINE pool.
See “Main memory” on page 172 for information on paging/faulting.
– Write down the paging/faulting in the storage pool where Domino is running.
See “Main memory” on page 172 for information on paging/faulting.
– Write down any ineligible jobs in the storage pool where Domino is running.
See “Job activity levels” on page 183 for information on jobs going ineligible.
– Write down the % System ASP used and Current unprotect used values.
See “Disk space” on page 175 for information on disk space for the iSeries.

122 Domino 6 for iSeries Best Practices Guide

 Note: Information on storage pools can be found in “Main memory” on page 172.

6. WRKDSKSTS
– Write down the % busy for the disk units in the ASP where Domino is running.
See “Work with disk status (WRKDSKSTS)” on page 197 for information on disk units.
– Write down any disk units that have a % Busy significantly higher than other units.
See “Work with disk status (WRKDSKSTS)” on page 197 for information on disk units.
7. NETSTAT *CNN
– Check port 1352 connections for any retransmissions.
See “Work with TCP/IP Connection Status (NETSTAT *CNN)” on page 201 for
information on retransmissions.
8. WRKDOMCSL SERVER(<ServerName>)
– Run the Domino command: SHOW STAT SEM
• A few semaphore timeouts is okay. More then 10 a day and you should call Support.
– Run the Domino command: SHOW SERVER
• Check Peak # of sessions. Too many sessions may indicate network issues.
• Check Transactions: Last minute. No transactions might mean a server hang.

3.2 Using Management Central to monitor system health

Management Central is a suite of systems management functions that makes managing
many iSeries systems as easy as managing a single system. Use Management Central to
manage multiple iSeries systems through a single central system. Simply select an iSeries to
use as your central system, then add endpoint systems to your Management Central network.
You can create groups of similar or related endpoint systems to make managing and
monitoring your iSeries systems even easier. Your central system will handle the
communications for you. You no longer have to worry about configuring communications
connections to all your iSeries systems or juggling multiple login sessions. You’ll find that
Management Central is scalable, flexible, and easily manipulated to fit the needs of your
environment.

Important: Although Management Central is designed to help you in managing multiple

systems, you can also use the functions discussed in this section if you have only one
iSeries system.

Management Central lets you perform various system management tasks on multiple
systems as quickly and efficiently as you would on a single system. Management Central
makes system administration even easier by allowing you to use sharing. Sharing lets you
give other users permission to view or work with your tasks. Use Management Central to do
all your system administration tasks, including:
򐂰 Collect inventory
򐂰 Manage fixes
򐂰 Packaging and sending data
򐂰 Run commands
򐂰 Schedule tasks and jobs
򐂰 Work with system performance

Chapter 3. Monitoring Domino performance on the iSeries 123

 The scope of this redbook prevents us from discussing all of the tasks you can perform with
Management Central. We concentrate on the system performance monitoring task, including
iSeries performance monitoring and Domino server performance monitoring.

Additional information on Performance Management with iSeries Navigator can be found in

the redbook Managing OS/400 with Operations Navigator V5R1 Volume 5: Performance
Management, SG24-6565 at
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/SG246565.html?Open

3.2.1 Setting up Management Central

Follow these few simple steps to set up your Management Central network (steps 3 to 5 are
only needed when you have more than one iSeries system):
1. Install and access Management Central:
Management Central is an optionally installable component of iSeries Navigator. Be sure
you choose to install this component when you install iSeries Navigator. If iSeries
Navigator is already installed on your workstation, but Management Central is missing,
then you need to add it using the Selective Setup function of IBM iSeries Access for
Windows.
Find and open Management Central in your iSeries Navigator window.
2. Set up your central system:
You choose your central system when you first start Management Central. You can also
change your central system easily at any time.
3. Add endpoint systems:
Endpoint systems are the other systems in your network that you manage with your single
central system. Your central system is automatically added to the list of endpoint systems.
If you have more than one iSeries, you can add your other systems manually or using the
Discover Systems function.
4. Create system groups:
Make the most of Management Central’s ability to manage groups of iSeries systems.
Create groups of iSeries systems, for example based on system functions (all Domino
servers, all WebSphere servers, etc.) or geography, to make managing them easier and
more efficient.
5. Use sharing:
Use sharing to manage your systems more efficiently. You can share systems and system
groups, package and command definitions, and system administration tasks with other
system administrators and operators.

Once you have finished this preliminary work with Management Central, you’re ready to begin
managing your iSeries systems. For more details about installing and configuring
Management Central, refer to the “Getting Started with Management Central” Web page at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzaih/rzaih1b.htm

124 Domino 6 for iSeries Best Practices Guide

3.2.2 Work with system performance monitors
Performance management is a strategy for planning, implementing, controlling, and
measuring iSeries tasks to achieve the best system performance for your environment. The
growth, users, and demands of your unique computing environment determine what is
acceptable system performance for your business needs.

Use Management Central’s monitors to see real-time system performance in an easy-to-use,

easy-to-change graphical interface. Management Central offers an extensive suite of
performance metrics that you can use alone or in concert to pinpoint details of your system
performance.

If you want to collect historical performance data for later analysis, find information about
using Collection Services in “Using Collection Services to monitor Domino and iSeries
performance” on page 134.

Management Central monitors gather and present real-time performance data for your iSeries
systems. You can use monitors to see your system performance as it happens across multiple
systems and groups of systems. The monitors allow you to collect performance data
simultaneously for a wide variety of system metrics, for any system or system group, and for
any length of time. Once you start a monitor, you are free to do other tasks on your iSeries, in
iSeries Navigator, or on your PC. To effectively monitor real-time iSeries system performance,
create a Management Central monitor.

Create a monitor
Creating a new monitor is a quick and easy process that begins at the New Monitor window.
In Management Central, follow these steps:
1. Click Monitors. The available monitor types are displayed in the right pane. Your choices
are System, File, Job, Message or B2B Activity monitors.

Tip: You can also use the Work with Monitors in the Management Central tasks section at
the bottom right hand corner of iSeries Navigator to perform common monitor
administration tasks.

Chapter 3. Monitoring Domino performance on the iSeries 125

 2. We want to create a new System monitor, so for our example, right-click System. Click
New Monitor as shown in Figure 3-1.

Figure 3-1 Creating a new monitor in iSeries Navigator

3. Key in a name and a description for the monitor on the General tab. The description
displays in the monitor list. We called the new monitor “Our first monitor”.
4. View and change your metric information.
Use the New Monitor - Metrics tab to select each metric you want to monitor. You can
edit the collection interval, retention period, maximum graphing value, and display time for
each metric you select. We used the default values for the CPU Utilization (Average)
metric in Figure 3-2.

126 Domino 6 for iSeries Best Practices Guide

Figure 3-2 Metric tab on the New Monitor window

5. Set threshold commands:

Use the Threshold 1 and Threshold 2 tabs to enable thresholds and specify commands to
run on the host or the client whenever thresholds are triggered or reset. Click
Threshold 1, then check the Enable Threshold checkbox.
Our example in Figure 3-3 shows a threshold of 80% CPU Utilization (Average) with the
monitor resetting when the utilization goes below 60%.

Chapter 3. Monitoring Domino performance on the iSeries 127

 Figure 3-3 Threshold 1 settings in the New Monitor window

6. Use the default settings on the Actions tab for our example. Refer to the iSeries Navigator
Help for more information about the logging and alarm options on the Actions tab.
7. On the Systems and Groups tab select the system or systems where you want to run this
monitor. Click Browse to select from a list of systems or groups. We selected the AS25
server for our example.
8. Click OK to save the monitor.

Start and stop a monitor

Once you created your monitor, it is easy to start and stop it. To start a monitor:
1. Open Management Central, if not already open. Click Monitors. Double-click System in
the right pane of the iSeries Navigator window. This displays all System monitors,
including “Our first monitor”.
2. Right-click your monitor. In our example, right-click Our first monitor and select Start, as
shown in Figure 3-4. You should see a confirmation message in the status bar confirming
that the monitor started. The Status field next to the monitor changes to Started.

128 Domino 6 for iSeries Best Practices Guide

Figure 3-4 Management Central: Starting a monitor

Once the monitor has successfully started, the Stop option becomes available on the context
menu. To stop a monitor, right-click your monitor entry and select Stop. You should see a
confirmation message in the status bar confirming that the monitor stopped. The status field
changes to Stopped.

Create a monitor for Domino servers

Creating a monitor for Domino servers is easy. It is important to understand that you cannot
monitor Domino server statistics in Management Central. You can only monitor performance
data for the Domino server jobs. You must use the Collection Services feature to collect
Domino server statistics for monitoring and reporting. See “Using Collection Services to
monitor Domino and iSeries performance” on page 134 for more information.

To create a monitor for Domino servers, follow the steps from the System monitor example
(see “Create a monitor” on page 125), except that this time you have to create a Job monitor.
1. Click Monitors. Select Job.
2. Right-click Job. Click New Monitor as shown in the example in Figure 3-5.

Chapter 3. Monitoring Domino performance on the iSeries 129

 Figure 3-5 Create new job monitor

3. Key in a name and description for the monitor.

4. Click the Servers to Monitor tab. Specifying jobs by their server name enables monitoring
for all jobs in one or more servers without needing to know the exact job names.
An enhancement in OS/400 V5R2 includes the entry Domino Server in the list of available
servers on this tab.
Select Domino Server from the list, then click the Add button. See Figure 3-6 for an
example.

130 Domino 6 for iSeries Best Practices Guide

Figure 3-6 Create Domino Server monitor

5. Click the Metrics tab to set the same threshold settings as in our system monitor example
(80% and 60% for the reset value). However, when defining a job monitor you first have to
select the metric from the Available metrics field. The CPU Percent Utilization metric can
be found under the Job Numeric Values. This is shown in Figure 3-7.

Chapter 3. Monitoring Domino performance on the iSeries 131

 Figure 3-7 Create Domino Server monitor - Metrics

6. Click the Collection Interval tab. Use the default value of 15 minutes for all metrics. You
can customize this setting later if you need to.
7. Click the Actions tab. Use the default values for logging the event. You can customize this
setting later if you want.
8. Click the Systems and Groups tab. Click Browse to select the appropriate endpoint
systems or system group from the list of available systems.
9. Click the Sharing tab if you want to share this monitor with another administrator. The
default setting for sharing is none.
10.Click OK to save your new monitor.
11.The Job Monitor view displays the new monitor in the list. Right-click on the new monitor,
then select Start to enable the monitor.

132 Domino 6 for iSeries Best Practices Guide

View the job monitor status
You can view the status of a job monitor by double-clicking the monitor name. The Job
Monitor window as shown in Figure 3-8 is displayed. This window lists the triggered
thresholds and resets and a list of monitored jobs.

We customized the view to display columns in the order of Subsystem, Job Name and
CPU %. To customize the view, drag and drop the columns to position them in the desired
order. We sorted by subsystem name by clicking on the title of the Subsystem column.
Alternatively, you can click Options -> Columns or press the F11 key to customize this view.
iSeries Navigator retains the columns and sorting you selected. We recommend customizing
this window to best suit the way you work.

Figure 3-8 Job monitor window - Customized view

View the Event log

When you are viewing the Event log, you can specify which events you want to view by
selecting Include from the Options menu. For example, you can view the events for a single
monitor or a specified set of monitors. You can also specify events based on the owner of the
event or the endpoint system(s) or system group being monitored.

To view the event log for all monitors of a particular type of monitor, follow these steps:
1. In iSeries Navigator, expand Management Central.
2. Expand Monitors.
3. Right-click the type of monitor (System, File, Job, etc.) you want and select Event Log.
Figure 3-9 shows the event log for the AS25 system. You can also view the event log
across all your systems.

Chapter 3. Monitoring Domino performance on the iSeries 133

 Figure 3-9 Display Event log

3.3 Using Collection Services to monitor Domino and iSeries

performance
This section contains information on using the Collection Services feature of OS/400 to
collect and analyze performance data about Domino servers. The inclusion of Domino 6 for
iSeries data is new to the Collection Services feature in OS/400 V5R2. We intend for this
section to be a quick start to using Collection Services, not an exhaustive resource.

Administrators running Domino 6 for iSeries on an iSeries with OS/400 V5R2 can use the
Collection Services of OS/400 to collect performance data about their Domino servers. When
Collection Services is configured to collect Domino data, each interval contains statistics for
all active Domino servers that are running the COLSRV400 add-in task. Collection Services
are based on Domino statistics. That is, the statistics displayed when issuing the Domino
console command SHOW STAT. However, Collection Services store only a subset of the data
provided by SHOW STAT. This data is stored in the Management Collection Object (MCO).

We recommend that you perform the following steps when collecting and reporting
performance data about Domino servers:
1. Designing a data collection
2. Starting and stopping a data collection
3. Using Collection Services data

We also include examples and sample reports to help you begin using Collection Services
data in your organization.

3.3.1 Designing a data collection

This section briefly describes how iSeries and Domino performance data collection works in
OS/400 V5R2. We include information about how to plan for the disk space requirements
needed for storing performance data and guidelines for configuring the data collection.

134 Domino 6 for iSeries Best Practices Guide

How data collection works
There is only one Collection Services job QYPSPFRCOL on a system running at any one
time. You may start the Collection Services from several workstations, but there remains a
single Collection Services job. The QYPSPFRCOL job runs in the QSYSWRK subsystem;
however; this job may run more than one thread.

The Collection Services store performance data in an object, which has a type of *MGTCOL.
This object contains an entire life cycle (usually one day) of Collection Services data, for all
collection categories in one place. If Collection Services is started by iSeries Navigator or
PM/400, then by default, these *MGTCOL objects are stored in library QMPGDATA. If
Performance Tools starts the Collection Services, then the default library for *MGTCOL
objects is QPFRDATA. You can also specify your own library to contain the collection object, if
you prefer.

You cannot access a MGTCOL object directly; only system tools, such as iSeries Navigator,
can do so. However, this data is also exported to DB/2 files for the current collection. The
DB/2 files are stored in the same library as your MGTCOL object and have files names such
as QAPMDOMINO (contains Domino data), QAPMDISK (disk data), and so on. If these DB2
files do not exist or you want to use data from previous days, they can be created by
right-clicking a MGTCOL object in iSeries Navigator and choosing “Create Database File
Now...”. You can then use any database query tool on this data (as explained in 3.3.3, “Using
Collection Services data” on page 139). The format of Domino's DB2 table (QAPMDOMINO)
can be found in 3.3.5, “QAPMDOMINO database reference” on page 167.

The QDOMINO job is a collection task from the integration of iSeries Collection Services
with Domino. It runs as a single job per iSeries server or LPAR in the QSYSWRK subsystem.
Like the QYPSPFRCOL job, this service can run continuously and store Domino statistics in
the *MGTCOL object. The QDOMINO job polls all active Domino servers on an iSeries server
or LPAR running the Domino add-in task called COLSRV400.

Domino 6 for iSeries automatically adds the COLSRV400 add-in task to the ServerTasks
entry in each Domino server’s NOTES.INI file when you upgrade or install the server
software. This means that you see one COLSVR400 job on in the WRKACTJOB display for
each active Domino server (under each Domino server’s subsystem).

When Collection Services is not running or is not set up to collect Domino statistics, the
COLSRV400 add-in task on a Domino server does nothing. You can remove the COLSRV400
task from the ServerTasks entry in the Notes.ini file for each Domino server, but we
recommend that you leave it in.

Data collection size considerations

Before you configure the data collection, you should understand the disk consumption
considerations of your collection intervals.

For illustration purposes let's assume that Collection Services is used daily and cycles at
midnight, causing each MGTCOL object to contain one day's worth (approximately 24 hours)
of data collection. Let's next establish a base size for one day's worth of data collection using
the default properties for Collection Services. Using the Standard plus protocol profile with an
interval value of 15 minutes will collect approximately 500 MB of data in one MGTCOL object.
The size actually collected per day using the default properties can vary greatly depending on
system size, usage, and interval value. The 500 MB example typically represents a higher
end system that is heavily used.

Chapter 3. Monitoring Domino performance on the iSeries 135

 The size of one day's worth of data is directly proportional to the number of intervals collected
per collection period. For example, changing the interval rate from 15 minutes to 5 minutes
will increase the number of intervals by a factor of 3 and will increase the size by the same
factor. In our example, the size could grow from 500 MB to 1500 MB for the same one day
period. You usually control the size of the MGTCOL object by the data collection
configuration and expiration settings for the data.

Configuring a data collection

We recommend the following steps when configuring your data collection:
1. Start iSeries Navigator. Select the appropriate iSeries system from My Connections.
Select Configuration and Service -> Collection Services.
Start by using the default data collection settings on both the General and Data to Collect
tabs in the Start Collection Services window.

Note: Collection Services can alternatively be accessed from the Management Central
section in iSeries Navigator. Choose Management Central -> Endpoint Systems ->
<SystemName> -> Configuration and Service -> Collection Services.

2. Run Collection Services for three prime shift days to get an understanding of your
environment. Monitor the disk space consumed by the data files in the Collection Services
section in iSeries Navigator. The size column on the far right of the window displays disk
space used in MB.
3. Reconfigure the Collection Services as needed.
– Collection Services Properties -> General tab
If the data files consume too much disk space, consider changing the Default collection
interval for detail data and Collection retention period. Increasing the Default collection
interval results in lower disk consumption due to fewer collections run during the
period. Changing the Collection retention period settings reduces disk consumption by
expiring data more quickly so it is deleted from disk. We recommend using a 15 minute
collection interval. If you change the collection interval to 60 minutes or more, please
be aware that the data may not be useful.
– Collection Services Properties -> Data to Collect tab
We recommend using the default Collection profile with the setting “Standard plus
protocol”. This profile includes most of the iSeries performance data and the Domino
performance data as you can see in Figure 3-10. However, you can also create a
custom profile that only includes the specific iSeries performance data you want to
reference in the data files. Be sure to include the Domino performance data if you
create a custom profile. Reducing the number of statistics categories reduces disk
consumption.

136 Domino 6 for iSeries Best Practices Guide

 Figure 3-10 Collection Services Properties - Data to Collect

3.3.2 Starting and stopping a data collection

After you have configured or reconfigured Collection Services, you need to start or recycle it
to apply your new configuration. The 5250 workstation emulation command STRPFRMON is
no longer available as of OS/400 V5R1 so there is no direct 5250 workstation emulation
command to start Collection Services. However, there are several ways to start Collection
Services:
򐂰 Start Collection Services from iSeries Navigator.
iSeries Navigator allows you to start Collection Services for a single system or a group of
systems.
򐂰 Use the Performance Tools menu.
This is possible only if you have the Performance Tools licensed program, 5722-PT1,
installed on your system.
򐂰 Start PM/400 on your system.
PM/400 will automatically start Collection Services.
򐂰 Use the Collection Services APIs.
A discussion of Collection Services APIs is beyond the scope of this redbook. Please refer
to the Domino 6 for iSeries Application Development Guide (apdev400.pdf) for more
information.

Chapter 3. Monitoring Domino performance on the iSeries 137

 򐂰 Create and Start System Monitors.
Starting a System monitor causes Collection Services to start, if it is not already started.

This section showcases the use of iSeries Navigator to start and stop data collections.

Starting Collection Services

To start Collection Services, follow these steps:
1. Open iSeries Navigator.
2. Open the iSeries server where your Domino server(s) reside(s).
3. Select Configuration and Service.
4. Right-click Collection Services and select Start Collecting as shown in Figure 3-11.

Figure 3-11 Starting Domino Collection Services using iSeries Navigator

Stopping Collection Services

To stop the Collection Services, follow these steps:
1. Open iSeries Navigator.
2. Open the iSeries server where your Domino server(s) reside(s).
3. Select Configuration and Service.
4. Right-click Collection Services and select Stop Collecting. This can also be seen in
Figure 3-11.

138 Domino 6 for iSeries Best Practices Guide

3.3.3 Using Collection Services data
You have several options for using Collection Services data. We address two options in this
section:
򐂰 Viewing the data using iSeries Navigator
򐂰 Viewing the data using PC workstation tools

In addition, we include resources that reference other available options for using Collection
Services data at the end of this section.

Viewing the data using iSeries Navigator

This section assumes that you configured and started the Collection Services feature and you
now want to view the collected data. The Graph History feature provides a graphical view of
performance data collected over days, weeks, months, or years with Collection Services. You
do not need to have a system monitor running to view performance data. As long as you use
Collection Services to collect data, you can use the Graph History.

We recommend using the Graph History feature in iSeries Navigator for quick snapshots of
small to medium sized data sets such as one day or one week of data. This is useful, for
example, when you are researching performance issues or monitoring specific Domino jobs
on your system. Though the OS/400 object used by the Collection Services job is capable of
retaining large data sets, we recommend exporting the data to DB2 files for more thorough
analysis, such as trending, using PC workstation tools.

Important: You can only view iSeries performance data using the Graph History feature.
You cannot view Domino performance data using this feature. Please see “Viewing the
data using PC workstation tools” on page 142 for instructions for viewing Domino
performance data.

The amount of data that is available to be graphed is determined by the settings that you
selected from the Collection Services properties, specifically the collection retention period.
Use iSeries Navigator to activate PM/400 over multiple systems. When you activate PM/400,
you can use the Graph History function to see data that was collected days ago, weeks ago,
or months ago. You go beyond the real-time monitor capabilities, and have access to
summary or detailed data. Without PM/400 enabled, the graph data field supports 1 to 7 days.

With PM/400 enabled, you define how long your management collection objects remain on
the system, categorized as follows:
򐂰 Detailed data: The length of time that management collection objects remain in the
system before they are deleted. You can select a specific time period in hours or days, or
you can select Permanent. If you select Permanent, the management collection objects
will not be automatically deleted.
򐂰 Graph data: The length of time that the details and properties data that is shown in the
Graph History window remains in the system before it is deleted. If you do not start
PM/400, you can specify one to seven days. If you do start PM/400, you can specify 1 to
30 days. The default is one hour.
򐂰 Summary data: The length of time that the data collection points of a graph can be
displayed in the Graph History window or remain in the system before they are deleted.
No details or properties data is available. You must start PM/400 to enable the summary
data fields. The default is one month.

Chapter 3. Monitoring Domino performance on the iSeries 139

 To view the Graph History of the data that you are monitoring with Collection Services, follow
these steps:
1. Open iSeries Navigator.
2. Open the iSeries server where you configured Domino.
3. Click Configuration and Service.
4. Right-click Collection Services and select Graph History.
5. Select the graph parameters such as Report dates, Metric, Graph interval, Maximum
graphing value, and From/To dates and times.

Important: Graph History includes all available data in the MCO. If data does not exist for
the entire date range you selected, Graph History reports on the data available in the MCO.

6. Click Refresh to see the graphical view.

Once you have launched a Graph History, a window displays a series of graphed collection
points. These collection points on the graph line are identified by three different graphics that
correspond to the three levels of data that are available:
򐂰 A square collection point represents data that includes both the detailed information and
properties information.
򐂰 A triangular collection point represents summarized data that contains detailed
information.
򐂰 A circular collection point represents data that contains no detailed information or
properties information.

Figure 3-12 displays the average CPU utilization at 15 minute intervals for the AS25 server
from August 23, 2003 to August 29, 2003 with a maximum graphing value of 100 percent
busy.

140 Domino 6 for iSeries Best Practices Guide

Figure 3-12 Example of an Average CPU Utilization graph for one week

Another useful feature of the Graph History is the ability to export Graph History to a PC file
for analysis with PC based software. From the Graph History window, click File -> Export.
This gives you the opportunity to save the Graph History data as a file on your PC in any of
the following formats:
򐂰 ASCII Tab Delimited Text (*.txt)
򐂰 Comma Separated Variable (*.CSV)
򐂰 Web Page (*.html)
򐂰 Microsoft Excel 97 (*.xls)
򐂰 Lotus 123 Compatible (*.csv)

Chapter 3. Monitoring Domino performance on the iSeries 141

 Viewing the data using PC workstation tools
There are several methods for viewing and manipulating performance data on your
workstation. Table 3-1 contains examples of methods that include Domino performance data.

Table 3-1 Methods for manipulating and viewing performance data on a PC

Method Advantages Disadvantages

Create database files on the You can report on data This method can be
iSeries from the MCO data, collected for days, weeks, complicated because there are
query the database files, then months or even years. several steps involved.
download the data to a PC
workstation for additional You can create trending The database files can get very
manipulation. reports. large.

Create database files on the Fewer steps involved for this ODBC connectivity is
iSeries from the MCO data, method. sometimes slow and unstable.
query the database files, then
use a PC-based query tool to You can create custom reports You have to thoroughly
create reports. whenever you want. understand the data set to get
accurate reports.

Query the MCO data directly, You can create reusable You can only report on one
then download the file from the queries to summarize the data. collection interval at a time,
iSeries using the Data Transfer usually one day at a time.
utility from IBM iSeries Access Works well for short term
for Windows. monitoring reports.

Create database files on the Very flexible option for reporting Requires additional software
iSeries from the MCO data. and monitoring. license for LEI.
Use a product such as LEI 6 for
iSeries to connect a Lotus Requires Lotus Notes
Notes database application to programming expertise.
the database files.
No charting capabilities in Lotus
Notes.

We recommend that you determine the best method for your environment and organization
based on the skill set and experience of your staff.

In the following example, we query the MCO data directly, then download the data to a PC
workstation for additional manipulation, which is the first option detailed in Table 3-1. There
are three steps involved in doing this:
򐂰 “Find MCO data to query” on page 143
򐂰 “Use Query/400 to create a report” on page 144
򐂰 “Display the results using the RUNQRY command” on page 151, or
“Download the data to Lotus 1-2-3 (or Excel) and display the spreadsheet” on page 151

142 Domino 6 for iSeries Best Practices Guide

Find MCO data to query
Determine the member or collection name and library where the MCO data resides. Here are
two examples of how to do this:
򐂰 Look at the Collection Services view in iSeries Navigator. The example in Figure 3-13
shows the list of objects created by Collection Services, sorted by date. We use the
collection named Q240000021 dated 08/28/03 (August 28, 2003) in library QMPGDATA in
this example. You have to view the properties of the object to determine the library where
its stored.

Figure 3-13 Finding Collection Services data using iSeries Navigator

򐂰 Use the GO PERFORM command, select option 3 - Performance Report, then view the
member name for the date you want to query. The Print Performance Report screen in
Figure 3-14 shows the list of objects created by Collection Services, sorted by date. We
use the member Q240000021 dated 08/28/03 (August 28, 2003) in library QMPGDATA in
this example as well.

Chapter 3. Monitoring Domino performance on the iSeries 143

 Print Performance Report - Sample data

Library . . . . . . QMPGDATA

Type option, press Enter.

1=System report 2=Component report 3=Job report 4=Pool report
5=Resource report

Option Member Text Date Time

_ Q241000039 IN USE 08/29/03 00:00:39
_ Q240000021 08/28/03 00:00:22
_ Q239000034 08/27/03 00:00:34
_ Q238000036 08/26/03 00:00:36
_ Q237000021 08/25/03 00:00:21
_ Q236000043 08/24/03 00:00:44
_ Q235000039 08/23/03 00:00:40
More...
F3=Exit F5=Refresh F11=Work with your spooled output files F12=Cancel
F15=Sort by member F16=Sort by text

Figure 3-14 Print Performance Report to find Collection Services data

Use Query/400 to create a report

To create a query report from your MCO data, do the following steps:
1. Open a 5250 workstation emulation session on the iSeries or LPAR where you collected
the performance data, if you have not already done so.
2. Type STRQRY on the command line and press Enter to work with Query/400.
3. Select Option 1 on the Work with Queries screen to create a new query. Key in the name
you want for this query and the library where you want to store it. Figure 3-15 shows that
we called our query QDOMCS1 in library QGPL.
We recommend creating a library for storing performance queries for your team.

Work with Queries

Type choices, press Enter.

Option . . . . . . 1 1=Create, 2=Change, 3=Copy, 4=Delete

5=Display, 6=Print definition
8=Run in batch, 9=Run
Query . . . . . . . qdomcs1 Name, F4 for list
Library . . . . . QGPL Name, *LIBL, F4 for list

F3=Exit F4=Prompt F5=Refresh F12=Cancel

(C) COPYRIGHT IBM CORP. 1988

Figure 3-15 Create a query against the MCO data

144 Domino 6 for iSeries Best Practices Guide

4. Make sure the options listed below are selected by keying a 1 next to each option as
shown in Figure 3-16, then press Enter to continue.
– Specify file selections
– Define result fields
– Select and sequence fields
– Select records
– Select report summary functions
– Define report breaks
– Select output type and output form

Define the Query

Query . . . . . . : QDOMCS1 Option . . . . . : CREATE

Library . . . . : QGPL CCSID . . . . . . : 65535

Type options, press Enter. Press F21 to select all.

1=Select

Opt Query Definition Option

1 Specify file selections
1 Define result fields
1 Select and sequence fields
1 Select records
_ Select sort fields
_ Select collating sequence
_ Specify report column formatting
1 Select report summary functions
1 Define report breaks
1 Select output type and output form
_ Specify processing options

F3=Exit F5=Report F12=Cancel

F13=Layout F18=Files F21=Select all

Figure 3-16 Define the Query screen

5. Key in the name, library and member of the MCO as shown in the example in Figure 3-17.
The format is *FIRST. You determined the appropriate values for your environment in “Find
MCO data to query” on page 143.
Press Enter to continue to the next screen.

Specify File Selections

Type choices, press Enter. Press F9 to specify an additional

file selection.

File . . . . . . . . . QAPMTJOB Name, F4 for list

Library . . . . . . QMPGDATA Name, *LIBL, F4 for list
Member . . . . . . . . Q240000021 Name, *FIRST, F4 for list
Format . . . . . . . . *FIRST Name, *FIRST, F4 for list

F3=Exit F4=Prompt F5=Report F9=Add file

F12=Cancel F13=Layout F24=More keys

Figure 3-17 Specify File Selections screen

Chapter 3. Monitoring Domino performance on the iSeries 145

 6. Key in the definition for the TOTALPER field based on your system information. Press
Enter to continue to the next screen. The example in Figure 3-18 uses the following
values:
– 900: The total seconds during a 15 minute interval
– 9000: Refers to the processors on your system or LPAR, for example, there are nine
processors on the iSeries server in our example.
– 49: Total number of collection intervals during the collection period, for example there
are 49 fifteen minute intervals between 7 am and 5 pm.

Define Result Fields

Type definitions using field names or constants and operators, press Enter.
Operators: +, -, *, /, SUBSTR, ||, DATE...

Field Expression Column Heading Len Dec

TOTALPER ((jbcpu/(900*9000))/49)*100 6 4

Bottom

Field Field Field Field

INTNUM JBSLIB JBACCO JBTTYE
DTETIM JBNAME JBTYPE JBFLAG
INTSEC JBUSER JBSTYP JBS36E
JBSSYS JBNBR JBTTYP JBPOOL
More...
F3=Exit F5=Report F9=Insert F11=Display text
F12=Cancel F13=Layout F20=Reorganize F24=More keys

Figure 3-18 Define the TOTALPER field in the Define Result Fields screen

7. Select and sequence the fields in the report. Figure 3-19 shows the fields you need to
select and the order to sequence them in. Press Enter twice to confirm the selections and
continue to the next screen. Select the fields in this order:
10 DTETIM
20 JBSSYS
30 JBNAME
40 JBCPU
50 TOTALPER

146 Domino 6 for iSeries Best Practices Guide

 Select and Sequence Fields

Type sequence number (0-9999) for the names of up to 500 fields to

appear in the report, press Enter.

Seq Field Seq Field Seq Field

50 TOTALPER JBTTYP JBWRT
INTNUM JBTTYE JBAW
10 DTETIM JBFLAG JBWI
INTSEC JBS36E JBAI
20 JBSSYS JBPOOL JBPLN
JBSLIB JBPRTY JBPPG
30 JBNAME 40 JBCPU JBPFL
JBUSER JBRSP JBLWT
JBNBR JBSLC JBLRD
JBACCO JBNTR JBDBU
JBTYPE JBDBR JBCPT
JBSTYP JBNDB JBCGT

More...
F3=Exit F5=Report F11=Display text F12=Cancel
F13=Layout F20=Renumber F21=Select all F24=More keys

Figure 3-19 Select and Sequence Fields screen example

8. Select the records and intervals you want to gather and analyze, as shown in Figure 3-20.
Press Enter to continue to the next screen.
– JBUSER: Enter QNOTES, which is the user for all Domino jobs on your system.
– JBCPU: Select jobs using more than 0 % CPU (= GT 0).
– INTNUM: We are looking for the prime shift intervals in our example, that is, 7 am to
5 pm. 7 am would be the 24th interval in the collection. It is selected by specifying the
value GT 23. The last interval we need is the 72nd, so enter LT 73 for the last interval.

Chapter 3. Monitoring Domino performance on the iSeries 147

 Select Records

Type comparisons, press Enter. Specify OR to start each new group.

Tests: EQ, NE, LE, GE, LT, GT, RANGE, LIST, LIKE, IS, ISNOT...

AND/OR Field Test Value (Field, Number, 'Characters', or ...)

JBUSER EQ 'QNOTES'
AND JBCPU GT 0
AND INTNUM GT 23
AND INTNUM LT 73

Bottom

Field Field Field Field

TOTALPER JBSLIB JBTYPE JBS36E
INTNUM JBNAME JBSTYP JBPOOL
DTETIM JBUSER JBTTYP JBPRTY
INTSEC JBNBR JBTTYE JBCPU
JBSSYS JBACCO JBFLAG JBRSP
More...
F3=Exit F5=Report F9=Insert F11=Display text
F12=Cancel F13=Layout F20=Reorganize F24=More keys

Figure 3-20 Select Records for the report

9. Select the report summary functions as shown in Figure 3-21. We summarize the JBCPU
and TOTALPER fields in our report.

Select Report Summary Functions

Type options, press Enter.

1=Total 2=Average 3=Minimum 4=Maximum 5=Count

---Options--- Field Text Len Dec

JBSSYS Subsystem Name 10
JBNAME Job Name 10
1 JBCPU CPU Milliseconds 11 0
1 TOTALPER ((jbcpu/(900*9000))/49)*100 6 4

Bottom
F3=Exit F5=Report F10=Process/previous F11=Display names only
F12=Cancel F13=Layout F18=Files F23=Long comment

Figure 3-21 Select JBCPU and TOTALPER fields for Query report

10.We define the report breaks next. The example in Figure 3-22 shows that we set the Break
Level at 1 for the JBSSYS field and 2 for the JBNAME field.

148 Domino 6 for iSeries Best Practices Guide

 Define Report Breaks

Type break level (1-6) for up to 9 field names, press Enter.

(Use as many fields as needed for each break level.)

Break Sort
Level Prty Field Text Len Dec
1 10 JBSSYS Subsystem Name 10
2 20 JBNAME Job Name 10
JBCPU CPU Milliseconds 11 0
TOTALPER ((jbcpu/(900*9000))/49)*100 6 4

Bottom
F3=Exit F5=Report F10=Process/previous F11=Display names only
F12=Cancel F13=Layout F18=Files F23=Long comment

Figure 3-22 Defining Query report breaks

11.Press the Enter key four times to accept your entries and the default values on the next
three screens.
12.Select the output type and output form. We recommend selecting the options in
Figure 3-23. Press Enter to continue to the next screen.

Select Output Type and Output Form

Type choices, press Enter.

Output type . . . . . . . . . . . 3 1=Display

2=Printer
3=Database file

Form of output . . . . . . . . . . 2 1=Detail

2=Summary only

Line wrapping . . . . . . . . . . N Y=Yes, N=No

Wrapping width . . . . . . . . . Blank, 1-378
Record on one page . . . . . . . N Y=Yes, N=No

F3=Exit F5=Report F10=Process/previous

F12=Cancel F13=Layout F18=Files

Figure 3-23 Settings for the Select Output Type and Output Form screen

13.Define a database output file. The example in Figure 3-24 sends the output to the
DOMACT file in the QGPL library.
For this type of performance snapshot, we recommend replacing the member if it already
exists. Or, you can customize this query each time you run it to send the output to a
different file. We named the file by the month and year we ran the query. Naturally, you can
create your own naming standard.

Chapter 3. Monitoring Domino performance on the iSeries 149

 Define Database File Output

Type choices, press Enter.

(The printed definition shows the output file record layout.)

File . . . . . . . . . DOMACT0803 Name, F4 for list

Library . . . . . . QGPL Name, F4 for list
Member . . . . . . . . *FILE Name, *FIRST, *FILE, F4 for list

Data in file . . . . . 4 1=New file, 2=Replace file

3=New member, 4=Replace member
5=Add to member

For a new file:

Authority . . . . . *LIBCRTAUT *LIBCRTAUT, authorization list name,
*CHANGE, *ALL, *EXCLUDE, *USE

Text . . . . . . . . A25 DOMINO ACTIVITY

Print definition . . . N Y=Yes, N=No

F3=Exit F4=Prompt F5=Report F10=Process/previous

F12=Cancel F13=Layout F18=Files

Figure 3-24 Define Database File Output screen

14.Press F3 to save your query.

15.You can choose to run your query now or use the Run Query (RUNQRY) command to run
it later. Figure 3-25 shows the Exit this Query screen where we opted to save the query
and run it in batch.

Exit this Query

Type choices, press Enter.

Save definition . . . Y Y=Yes, N=No

Run option . . . . . . 2 1=Run interactively

2=Run in batch
3=Do not run

For a saved definition:

Query . . . . . . . QDOMCS1 Name
Library . . . . . QGPL Name, F4 for list

Text . . . . . . . . QUERY FOR DOMINO ACTIVITY

Authority . . . . . *CHANGE *LIBCRTAUT, authorization list name,

*CHANGE, *ALL, *EXCLUDE, *USE

F4=Prompt F5=Report F12=Cancel F13=Layout

F14=Define the query

Figure 3-25 Save and run query

150 Domino 6 for iSeries Best Practices Guide

Once you have created the output file using Query/400, you can display them. Here are two
options for viewing your data:
򐂰 Display the results using the RUNQRY command
򐂰 Download the data to Lotus 1-2-3 (or Excel) and display the spreadsheet

Display the results using the RUNQRY command

To display the results using RUNQRY, issue the following command
RUNQRY QRY(*NONE) QRYFILE((QGPL/DOMACT))

The result is shown in Figure 3-26.

Display Report
Report width . . . . . : 2199
Position to line . . . . . Shift to column . . . . . .
Line ....+....1....+....2....+....3....+....4....+....5....+....6....+....7..
Interval Elapsed
Interval Date Interval Subsystem Library Job
Number Time Seconds Name Name Name
000001 24 030828015537 2 DOMBRMS QUSRNOTES CHRONOS
000002 24 030828020000 301 QSYSWRK QSYS QDOMINO
000003 24 030828020000 301 DOMREST QUSRNOTES AMGR
000004 24 030828020000 301 DOMREST QUSRNOTES AMGR
000005 24 030828020000 301 DOMREST QUSRNOTES UPDATE
000006 24 030828020000 301 DOMREST QUSRNOTES COLSRV400
000007 24 030828020000 301 DOMREST QUSRNOTES SCHED
000008 24 030828020000 301 DOMREST QUSRNOTES CALCONN
000009 24 030828020000 301 DOMREST QUSRNOTES ADMINP
000010 24 030828020000 301 DOMREST QUSRNOTES AMGR
000011 24 030828020000 301 DOMREST QUSRNOTES EVENT
000012 24 030828020000 301 DOMREST QUSRNOTES LOGASIO
000013 24 030828020000 301 DOMREST QUSRNOTES SERVER
000014 24 030828020000 301 DOMAV QUSRNOTES AMGR
More...
F3=Exit F12=Cancel F19=Left F20=Right F21=Split

Figure 3-26 Display query results using the RUNQRY command

Download the data to Lotus 1-2-3 (or Excel) and display the spreadsheet
To download the information into a Lotus 1-2-3 spreadsheet use the Data Transfer From
iSeries Server application (which is part of IBM iSeries Access for Windows). You may also
download the file in Microsoft Excel format if you wish. To do so:
1. Start the data transfer program by selecting Start -> Programs -> IBM iSeries Access
for Windows -> Data Transfer From iSeries Server.
2. Enter your system, library, file and member names where you placed your output file. In
Figure 3-27, we entered AS25 as the server name and QGPL/DOMACT as the library, file
and member names.
3. In the PC section, select File as the Output device, then enter a file name such as
domact.123.

Chapter 3. Monitoring Domino performance on the iSeries 151

 Figure 3-27 Example of the Data Transfer from iSeries window

4. Click Details in the PC pane. Make your selections regarding your download file. We
chose to create a new WK4 file as shown in Figure 3-28.
5. Click OK to save your selections.

Figure 3-28 File Details window

6. Select File -> Properties in the Data Transfer from iSeries Server window. Select Convert
CCSID 65535 as shown in Figure 3-29. Click OK to save your selection.

152 Domino 6 for iSeries Best Practices Guide

Figure 3-29 Transfer properties window - Conversion setting

7. You can now click Transfer Data from iSeries.

The application connects to the iSeries, then pulls the data into rows into a Lotus 1-2-3
spreadsheet. You receive a window confirming the status of your transfer.

Tip: If you receive an error message like the one in Figure 3-30, click OK. The transfer
should still work.

Figure 3-30 Error message from iSeries Access

8. Open the spreadsheet in Lotus 1-2-3. The spreadsheet lists the Domino servers broken
down by subsystem with totals by subsystem and entire system at the bottom.
The Lotus 1-2-3 spreadsheet looks like the example in Figure 3-31 when you open the file.
The spreadsheet includes totals by subsystem and by system. We added the borders
around the subsystem and system totals to bring these cells to your attention. If you
decide to further use this information by creating charts or graphs, we recommend saving
the file in the most recent file format of Lotus 1-2-3.

Chapter 3. Monitoring Domino performance on the iSeries 153

 Figure 3-31 Lotus 1-2-3 spreadsheet - Output of Collection Services

Resources
򐂰 For a complete list of the Domino statistics collected by Collection Services, please refer to
Chapter 19, “Integrating iSeries Collection Services with Domino”, starting at page 147 in
Installing and Managing Domino 6 for iSeries (I400HELP.PDF).
򐂰 Collection Services section on the iSeries Information Center Web site at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzahx/rzahxcollectdatacs.htm
򐂰 Chapter 4, section “Using the Management Collection Object API to read Domino
collection data” in the Domino 6 for iSeries Application Development Guide
(apdev400.pdf).

3.3.4 Sample reports

Here are some sample reports designed to help you monitor and troubleshoot performance
issues in your Domino 6 for iSeries environment. Before you start writing your own reports,
we recommend that you read 3.3.5, “QAPMDOMINO database reference” on page 167 to
learn more about the QAPMDOMINO file and information about using this data.

The sample reports include:

򐂰 Domino transactions
򐂰 Mail delivered
򐂰 Peak concurrent users

154 Domino 6 for iSeries Best Practices Guide

We show the detailed steps for the Domino transactions report, then identify the steps that
are different for the other two reports. We provide these examples so you can use the general
concept to create your own customized reports.

We made some assumptions when creating these reports. Please make the appropriate
changes when creating reports in your environment. The assumptions are:
򐂰 Microsoft Excel 2002 SP-2 with Microsoft Query option is installed
򐂰 You need to have at least intermediate level Microsoft Excel skills
򐂰 iSeries Access for Windows V5R2 with ODBC drivers is installed
򐂰 We generated the data files from the MGTCOL object to the QMPGDATA library
򐂰 You need appropriate security access to the iSeries objects in the QMPGDATA library

Domino transactions
Here are the instructions for the Domino transactions report using a pivot table in Microsoft
Excel 2002. This report enables you to view the trends in the number of transactions
processed by your Domino server(s) for a specific period of time. We will look at the number
of Domino transactions during a two hour period from Noon until 2:00 PM for the three
Domino servers on the AS25 iSeries system.

Here are the steps:

1. Open Microsoft Excel 2002. Create a new workbook if you do not already have one.
2. Click Data -> Import External Data -> New Database Query.
3. Select <New Data Source>, then click OK, as shown in Figure 3-32.

Figure 3-32 Choose Data Source in Excel

4. On the Create New Data Source window, key in the name of your new data source. Select
the iSeries Access ODBC Driver. We used the name bpdomcol4 in the example in
Figure 3-33.

Chapter 3. Monitoring Domino performance on the iSeries 155

 Figure 3-33 Create New Data Source window

5. Click the Connect button.

6. On the iSeries ODBC Driver Connect window, select the name of your iSeries system from
the list. You can optionally type in a new description for the connection if you prefer. We
selected the AS25 server and retained the default description in the example in
Figure 3-34.

Figure 3-34 General tab of the iSeries ODBC Driver Connect window

156 Domino 6 for iSeries Best Practices Guide

7. On the Server tab, change the SQL default library field to the library where you store the
QAPMDOMINO file.
In our example in Figure 3-35, we stored the file in the QMPGDATA library. You can accept
the defaults for the remaining values on this page and the rest of the tabs by clicking OK.
The iSeries ODBC Driver connects to the data source, then displays the Create New Data
Source window again.

Figure 3-35 Server tab of the iSeries ODBC Driver Connect window

8. You can now select a default table, but you are not required to do so. We selected
QAPMDOMINO as the default table in our example in Figure 3-36 since we want to pull all
the data for this report from that table. Click OK.

Chapter 3. Monitoring Domino performance on the iSeries 157

 Figure 3-36 Select a default table

9. Select the data source you just created in the Choose Data Source window, then click OK.
We selected the data source bpdomcol4 in Figure 3-37.

Figure 3-37 Select the new data source

10.The Microsoft Query Wizard connects to the AS25 server, then displays a list of fields in
the QAPMDOMINO table since we specified it as the default table.
If you did not select a default table, then you need to select the QAPMDOMINO table from
the list of tables now.
Select the DTETIM column in the Available tables and columns box, then click > to add it
to the Columns in your query box on the right side of the window shown in Figure 3-38.
Repeat this process for the DMSRVN and DMTRNS columns. After adding the three
columns to the query, click Next. Note that you can reorder the columns in your query by
using the up and down arrows.

158 Domino 6 for iSeries Best Practices Guide

Figure 3-38 Select columns for the Domino transactions report

11.In our example, we filter the data to the two hour window we want to include on the report.
See Figure 3-39 for an example of how to filter your data using the DTETIM field. Click
Next to continue to the next window.

Figure 3-39 Filtering the query using the DTETIM field

12.We want to sort by the DTETIM and DMSRVN fields on the Sort Order window. See
Figure 3-40. Click Next to continue.

Chapter 3. Monitoring Domino performance on the iSeries 159

 Figure 3-40 Sort by DTETIM and DMSRVN fields

13.Save your query by clicking Save Query. We named the query 12-2frombpdomcol4 in
Figure 3-41. We recommend giving your queries meaningful names.

Figure 3-41 Saving a query

14.We selected the Return Data to Microsoft Excel option on the Query Wizard - Finish
window in Figure 3-42. You can also view the data or edit the query in Microsoft Query or
build an OLAP Cube if you prefer. Click Finish.

160 Domino 6 for iSeries Best Practices Guide

Figure 3-42 Query Wizard - Finish window

15.You should see the Import Data window now. In the example in Figure 3-43, we selected
the New worksheet option. Click OK.

Figure 3-43 New Worksheet option on the Import Data window

16.Microsoft Query dumps the query data into your worksheet. The result is shown in
Figure 3-44.

Chapter 3. Monitoring Domino performance on the iSeries 161

 Figure 3-44 Example of raw data in Microsoft Query

17.Click Data -> PivotTable and PivotChart Report. We used the PivotTable and PivotChart
Wizard to create our report. Use the default value of Microsoft Excel list or database at the
top of the window, then click PivotChart Report (with PivotTable report) at the bottom
part of the window as can be seen in Figure 3-45. Click Next.

Figure 3-45 Step 1 of the PivotTable wizard

18.On the Step 2 window, accept the default setting for the data range by clicking Next. See
Figure 3-46.

162 Domino 6 for iSeries Best Practices Guide

Figure 3-46 Use the default range of data

19.Click Finish on the Step 3 window to put the PivotTable report on a new worksheet like the
example in Figure 3-47.

Figure 3-47 Place the PivotTable report on a new worksheet

20.Excel displays the PivotTable Field list window with the fields we selected on the query as
can be seen in Figure 3-48.

Figure 3-48 PivotTable field list window

Chapter 3. Monitoring Domino performance on the iSeries 163

 21.Drag each field to the appropriate section of the PivotChart. You may need to move the
PivotTable Field list window to the left before dragging each field so you can clearly see
the PivotChart.
First select DTETIM and drag it to the Drop Category Fields Here section on the lower end
(category axis) of the PivotChart. Refer to Figure 3-49 for an example.

Figure 3-49 Drop the DTETIM field on the Drop Category Fields Here section of the PivotChart

22.Next drag the DMSRVN field to the Drop Series Field Here section on the right side (series
axis) of the PivotChart like the example in Figure 3-50.

Figure 3-50 Drop the DMSRVN field on the Drop Series Field Here section of the PivotChart

164 Domino 6 for iSeries Best Practices Guide

23.Now drag the DMTRNS field to the Drop Data Items Here section in the center (data field)
of the PivotChart like the example in Figure 3-51.

Figure 3-51 Drop the DMTRNS field on the Drop Data Items Here section of the PivotChart

24.Close the PivotTable Field list by clicking the X in the upper right corner of the window. The
chart now looks like the example in Figure 3-52.

Figure 3-52 Example PivotChart

Chapter 3. Monitoring Domino performance on the iSeries 165

 25.You can now manipulate how the data is displayed. We changed the following to get the
chart in Figure 3-53:
– We changed the DTETIM values to show only 15 minutes increments instead of
5 minute increments. Click DTETIM on the PivotChart, deselect all values, then select
the values to display.
– We changed the chart type to 3-D column

Figure 3-53 The final results from our example

26.Select File -> Save to save your spreadsheet.

Mail delivered
To get the combined number of inbound and outbound mail messages placed into a server's
MAIL.BOX, select the DMMLBX field instead of selecting the DMTRNS field in step 10 on
page 158 (Figure 3-38 on page 159).

Peak concurrent users

Select the DMUSRP field instead of selecting the DMTRNS field in step 10 on page 158 to
get the peak number of concurrent users since the server was started.

Ideas for other reports

Here are some ideas for other reports that you can create and some tips for creating them:
򐂰 Mail delivered vs CPU utilization report
򐂰 Domino transactions vs CPU utilization report

166 Domino 6 for iSeries Best Practices Guide

 These reports can be created by joining the QAPMDOMINO file with the QAPMJOBS file
using the DTETIM (time) and DMSUBS (subsystem) fields. Be sure to use the CPU
percentage formula listed in Figure 3-18 on page 146.

3.3.5 QAPMDOMINO database reference

The QAPMDOMINO file contains data collected by the Domino for iSeries category. It
contains one record per interval for each Domino server active on the system. Table 3-2 lists
all fields in the file with a description and its data attribute.

For information about how Collection Services generates this file and where the data comes
from, refer to the section called “Performance data files: Collection Services system category
and file relationships” in the iSeries Information Center at
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzahx/rzahxcatfilerelat
ion.htm

Note: These are the data types (attributes) used in Table 3-2:
򐂰 C(x) = Character (characters)
򐂰 B(x,y) = Binary (Digits, Decimal Places)
򐂰 PD(x,y) = Packed Decimal (Digits, Decimal Places)

Table 3-2 QAPMDOMINO database fields

Field Description Attribute

INTNUM Interval number: The nth sample database interval based on PD (5,0)
the start time specified in the Create Performance Data
(CRTPFRDTA) command.

DTETIM Interval date (yymmdd) and time (hhmmss): The date and C (12)
time of the sample interval.

INTSEC Elapsed interval seconds: The number of seconds since the PD (7,0)
last sample interval.

DTECEN Century digit: where 0 indicates 19XX and 1 indicates 20XX. C (1)

DMSUBS Server subsystem. C (10)

DMJNAM Server job name. C (10)

DMJUSR Server job user. C (10)

DMJNBR Server job number. C (6)

DMSRVN Server name (first 25 characters if the name is longer than C (25)
this field).

DMSSDT Server start date time in yyyymmddhhmmss. C (14)

DMDBPM Database.BufferPool.Maximum.Megabytes: The configured B (9,0)

maximum size for database control pools that may be used.

DMDBPP Database.BufferPool.Peak.Megabytes: Maximum amount of B (9,0)

the buffer pool that has been used by Domino over the life of
the server.

DMDBPR Database.Database.BufferPool.PerCentReadsInBuffer: B (5,2)

Percentage of database reads present in buffer pool.

Chapter 3. Monitoring Domino performance on the iSeries 167

 Field Description Attribute

DMDBCH Database.DbCache.Hits: Number of hits to the database B (18,0)

cache.

DMDBCL Database.DbCache.Lookups: Number of lookups to the B (18,0)

database cache.

DMNLCH Database.NAMELookupCacheHits: Number of cache hits B (18,0)

when doing name lookups in the server's name and address
book.

DMNLCL Database.NAMELookupCacheLookups: Number of lookups B (18,0)

in the server's name and address book.

DMASPN Platform.LogicalDisk.1.AuxStoragePool: The number of the B (4,0)

auxiliary storage pool (ASP) that includes the Domino data
directory.

DMASPU Platform.LogicalDisk.1.PctUsed: Percent of total disk space B (5,2)

used in the ASP that includes the Domino data directory.
Note: This metric is calculated by the server and is based on
an internal sample interval as configured for the server.

DMASPB Platform.LogicalDisk.1.PctUtil: Percent of time the drives are B (5,2)

busy reading or writing in the ASP that includes the Domino
data directory.
Note: This metric is calculated by the server and is based on
an internal sample interval as configured for the server.

DMTRNS Server.Trans.Total: Number of transactions. B (18,0)

DMUSRO Server.Users: Number of users with open sessions on the B (9,0)

server. (This is the current value at the time the data was
sampled.)

DMUSRP Server.Users.Peak: Peak number of concurrent users since B (9,0)

the server was started.

DMUSRT Server.Users.Peak.Time: Time that last peak users occurred C (14)

(YYYYMMDDHHMMSS).

DMMLCP Mail.TotalPending: Number of outbound mail messages in B (9,0)

this server's MAIL.BOX waiting to be processed by the
Domino Router job. Mail will be pending until the Router job
wakes up and moves outgoing mail from MAIL.BOX to the
destination mail servers. If a mail server cannot be contacted,
the message will remain pending in MAIL.BOX. (This is the
current value at the time the data was sampled.)

DMMLWR Mail.WaitingRecipients: Number of inbound mail messages B (9,0)

in this server's MAIL.BOX waiting to be processed by the
Domino Router job. Mail will be waiting until the Router job
wakes up and moves incoming mail from MAIL.BOX into user
mail files. (This is the current value at the time the data was
sampled.)

DMMLBX Mail.Delivered: Combined number of inbound and outbound B (18,0)

mail messages placed into this server's MAIL.BOX.

DMCMCD Domino.Command.CreateDocument: Count of B (18,0)

'CreateDocument' URLs that have come into the server.

168 Domino 6 for iSeries Best Practices Guide

Field Description Attribute

DMCMDD Domino.Command.DeleteDocument: Count of B (18,0)

'DeleteDocument' URLs that have come into the server.

DMCMED Domino.Command.EditDocument: Count of 'EditDocument' B (18,0)

URLs that have come into the server.

DMCMOA Domino.Command.OpenAgent: Count of 'OpenAgent' URLs B (18,0)

that have come into the server.

DMCMOB Domino.Command.OpenDatabase: Count of B (18,0)

'OpenDatabase' URLs that have come into the server.

DMCMOD Domino.Command.OpenDocument: Count of B (18,0)

'OpenDocument' URLs that have come into the server.

DMCMOF Domino.Command.OpenForm: Count of 'OpenForm' URLs B (18,0)

that have come into the server.

DMCMOI Domino.Command.OpenImageResource: Count of B (18,0)

'OpenImageResource' URLs that have come into the server.

DMCMOV Domino.Command.OpenView: Count of 'OpenView' URLs B (18,0)

that have come into the server.

DMCMSD Domino.Command.SaveDocument: Count of B (18,0)

'SaveDocument' URLs that have come into the server.

DMCMTU Domino.Command.Total: Count of all URLs that have come B (18,0)

into the server.

DMRQ1M Domino.Requests.Per1Minute.Total: Total requests over the B (9,0)

past minute. (This is the current value at the time the data was
sampled.)

DMNPT1 NET.*: Domino port (1 of 4) for which data is being reported. C (32)
Note: The asterisk (*) in the node name indicates the name of
the port.

DMNBR1 NET.*.BytesReceived: Number of network bytes received for B (18,0)

this port. Note: The asterisk (*) in the node name indicates
the name of the port.

DMNBS1 NET.*.BytesSent: Number of network bytes sent for this port. B (18,0)
Note: The asterisk (*) in the node name indicates the name of
the port.

DMNSI1 NET.*.Sessions.Established.Incoming: Number of Incoming B (9,0)

sessions established for this port. Note: The asterisk (*) in the
node name indicates the name of the port.

DMNSO1 NET.*.Sessions.Established.Outgoing: Number of Outgoing B (9,0)

sessions established for this port. Note: The asterisk (*) in the
node name indicates the name of the port.

DMN* Note: The above 5 fields are repeated for ports 2, 3,

and 4.

Chapter 3. Monitoring Domino performance on the iSeries 169

 The QAPMDOMINO file
Here are some things you should know about the data stored in the QAPMDOMINO file:
򐂰 We stated previously that the data stored in the QAPMDOMINO file is a subset of the
items you see when you submit the SHOW STAT command at the Domino server console.
򐂰 There is one record per Domino server per collection interval in the QAPMDOMINO file.
You can select only one server by filtering on the field DMSRVN. This field contains the
first 25 characters of the Domino server name.
򐂰 The DTETIM field contains the date and time of the sample interval in the format date
(yymmdd) and time (hhmmss). The time portion uses the 24 hour clock. You can use the
greater than and less than filters to select the dates and times you want to include in your
reports. Here are some examples for the DTETIM field:
– August 31, 2003 11:15 AM = 030831111500
– September 1, 2003 2:30 PM = 030901143000
򐂰 Since Collection Services stores the data from the SHOW STAT command, the value in
the DMJNAM (server job name) field is always SERVER.
򐂰 Domino statistics reset when you restart the Domino server. Please remember this when
creating your reports, especially for statistics that indicate peak values. There is a field
called DMSSDT that stores the last server start date and time in yyyymmddhhmmss
format.
If you restart just the Domino HTTP server, the Domino.Command.* values will reset to
zero also. The same is true for the Mail.* stats when ROUTER is restarted. The way how
you restart these tasks is important for the statistics to be reset. For example, if you issue
a TELL HTTP RESTART, the statistics are not reset. If you issue a TELL HTTP QUIT
followed by LOAD HTTP, then the statistics are reset.
򐂰 When creating reports using the number of Domino transactions, please remember that all
transactions do not have the same impact on Domino server performance. Transactions
generated from the COMPACT task or the Indexer task, for example, require more server
resources than other types of transactions.

170 Domino 6 for iSeries Best Practices Guide

 4

Chapter 4. Tuning Domino performance on

the iSeries
Domino is a complex application. To get the best performance out of a Domino server running
on the iSeries, you must tune both the iSeries OS/400 and the Domino server. Therefore this
chapter is divided into two main sections.

The first section contains information on tuning the OS/400 for a Domino server. It discusses
memory management, direct access storage device (DASD), communications (TCP/IP), and
other operating system concepts.

The second section contains information on configuring a Domino server to run on an iSeries.
It discusses Domino memory management, transaction logging, indexing large files, and
other Domino configuration options.

© Copyright IBM Corp. 2004. All rights reserved. 171

4.1 iSeries performance tuning for Domino
To get the best performance out of your Domino server running on the iSeries, you need to
tune both the iSeries and the Domino server. This section is designed to help you tune the
iSeries for optimal performance. Tuning the iSeries involves four steps:
1. Set a goal, for example, faster response time.
2. Measure the existing performance on the iSeries. Refer to Chapter 3, “Monitoring Domino
performance on the iSeries” on page 121.
3. Change one parameter or setting at a time.
4. Once the change has taken effect, measure the performance again and see if you have
met the goal you set in step 1. If not, go back to step 3 and make another change.

Important: Turning on the iSeries performance adjuster (see “QPFRADJ” on page 215)
will not tune all aspects of your iSeries OS/400. There are some options that you have to
configure manually.

Tuning the iSeries means that you try to allocate the available system resources to users or
batch jobs that are in most need of those resources. Remember, there is an absolute and
finite limit to the number of resources in the system, and all jobs in the system compete for the
available resources. Once all the resources have been used up, all that tuning really achieves
is to take resources away from one job and give them to another. You cannot increase
available resources, but only reallocate them.

We cover resources, tuning, and allocation, such as memory, DASD, job attributes, CPU, disk
arms, system values, and the integrated file system (IFS) in these sections:
򐂰 “Work with System Status (WRKSYSSTS)” on page 172
򐂰 “Work with Active Jobs and Work with System Activity” on page 184
򐂰 “Run priority” on page 192
򐂰 “Work with disk status (WRKDSKSTS)” on page 197
򐂰 “Network Status (NETSTAT) and other communication information” on page 200
򐂰 “System values” on page 209
򐂰 “Integrated File System (IFS)” on page 218
򐂰 “Authority lookups” on page 224.

4.1.1 Work with System Status (WRKSYSSTS)

The Work with System Status (WRKSYSSTS) screen allows you to view and/or alter several
aspects of your iSeries OS/400. The aspects discussed in this section are:
򐂰 “Main memory” on page 172
򐂰 “Disk space” on page 175
򐂰 “Job activity levels” on page 183
The best way to view the information discussed in this section is to use the Intermediate
assistance level. Once you are on the Work with System Status screen, press F21 to access
the different assistance levels. Select option 2 for Intermediate and press Enter.

Main memory
A storage pool is a logical division of main memory that is reserved for processing a group of
jobs. In the OS/400, all main storage is divided into logical allocations called storage pools. If
you enable the iSeries performance adjuster, then the system can manage most aspects of
the storage pools. For information on the iSeries performance adjuster, please refer to
“QPFRADJ” on page 215.

172 Domino 6 for iSeries Best Practices Guide

 Note: Prior to OS/400 V5R1, the pools were always called storage pools. The iSeries
Navigator started using the term memory pool in V5R1. Since most CL commands and
IBM documentation still refers to them as storage pools, we use that term in this book.

By default, all Domino partitions run in the base (*BASE) storage pool. This is pool number 2
on the Work with System status (WRKSYSSTS) screen. You can manually change a Domino
partition to run in a different storage pool. The purpose of separate storage pools is to
guarantee a certain amount of memory to a group of jobs which will not be paged out by other
jobs that need memory.

There are two storage pools that you need to focus on when tuning an iSeries for Domino.
Those two pools are the machine (*MACHINE) storage pool and whichever storage pool the
Domino partition is running in. The *MACHINE storage pool is pool number 1 on the Work
with System Status (WRKSYSSTS) screen. As previously stated, Domino servers runs in the
*BASE storage pool by default, however, you can configure a Domino server/partition to run in
another shared pool or private pool.

For suggestions on deciding which storage pool to run a Domino partition in and how to
change the Domino configuration so it runs in another storage pool, see section 6.3 of the
IBM redbook Domino for iSeries Sizing and Performance Tuning, SG24-5162.

The machine pool (*MACHINE)

The machine pool does not process work from user jobs. The machine pool processes the
work from the Licensed Internal Code (LIC) and communications data (like TCP/IP). The size
for this memory pool is specified in the system value QMCHPOOL. For more information on
this system value see “QMCHPOOL” on page 212.

Important: You should apply OS/400 V5R2 PTF MF30750. It can help reduce the faulting
levels in the *MACHINE pool when a Domino server is configured on the iSeries.

The base pool (*BASE)

The base pool is where Domino partitions run by default. It contains all of the memory that is
not allocated by other (private or shared) storage pools. The *BASE pool contains storage
that can be shared by many subsystems. The system values QBASPOOL and QBASACTLVL
can alter the size and activity levels of the *BASE pool. For more information on these system
values see “QBASPOOL” on page 214 and “QBASACTLVL” on page 214.

Domino performance will be negatively impacted if the paging and faulting for the storage
pool Domino is running in or for the *MACHINE storage pool gets too high. Domino is
concerned with the values in the Non-DB Paging and Faulting columns. Table 4-1 tells you
what paging and faulting values are considered too high.

Note: Please keep in mind that the response time on your system is the real determining
factor of performance. The faulting/paging values listed in Table 4-1 are good guidelines.
However, there are other factors that influence the performance of your system. For
example, if your system has adequate disk, it can likely sustain higher fault rates than
these guidelines and still have good response times.

Chapter 4. Tuning Domino performance on the iSeries 173

 Table 4-1 Paging and faulting levels for storage pools
Storage Pool Maximum Non-DB Faults Maximum Non-DB Pages

*MACHINE 10 NA

Storage Pool where Domino 100 per physical processor 300 per physical processor
runs (*BASE by default)

Please note that, if the paging and faulting increases at night when no one is signed on, it still
affects performance. However, since no one is signed on to notice, it may not be necessary to
change memory allocations.

Important: Keep an eye on the Elapsed time field of the WRKSYSSTS screen. Keep the
time frame of the observation period between 5 and 30 minutes. If the observation period
is less than 5 minutes, then occasional peak loads tend to skew the data. If the time period
is over 30 minutes, then important data may be lost because counters holding some of the
data may get wrapped.

To refresh the WRKSYSSTS screen and keep the Elapsed time incrementing, use the F5
key. To reset the WRKSYSSTS screen and set the Elapsed time back to zero, use the F10
key.

Reasons why paging and faulting get too high

The following list describes some common reasons why paging and faulting gets too high in a
storage pool where a Domino partition is running:
򐂰 The NSF Buffer pool is too large.
You should try to make sure that the NSF Buffer pool total for all Domino partitions running
in a single storage pool does not exceed about 3/8 of the memory in that storage pool.
If the NSF Buffer pool total exceeds about 3/8 of the memory in the storage pool, it can
increase the paging and faulting rates. See “NSF_BUFFER_POOL_SIZE_MB” on
page 230 for more information on how to correctly set this parameter.
򐂰 Other Domino buffer pools are too large.
Domino has several other buffer pools - like the NIF Pool that handles indexing. You can
control the other buffer pools by setting the PercentAvailSysResources parameter in the
NOTES.INI. By default, each Domino server assumes it has 100 percent of the system’s
physical memory available to it. This means if you have four Domino partitions, all four
believe they have 100 percent of the main memory. Naturally, it is not possible for four
Domino partitions to each allocate 100 percent of the main memory for its buffer pools.
However, the iSeries allows this configuration to occur and the Domino servers end up
“stealing” memory from each other which increases the paging and faulting.
The PercentAvailSysResources parameter was introduced with Domino release 5.0.4.
This parameter allows you to assign a portion of the physical memory to each Domino
server by specifying a value from 2% to 100%. This percent value represents an absolute
percentage of the systems’s total physical memory. On the iSeries, the
PercentAvailSysResources memory calculations are based on the total system main
memory size if the Domino server is running in the *BASE pool or on the actual storage
pool memory if the Domino partition is running in a shared or private pool.
For more information on correctly setting the PercentAvailSysResources parameter, see
“PercentAvailSysResources” on page 233.

174 Domino 6 for iSeries Best Practices Guide

򐂰 There is not enough memory for the Domino servers configured to run in the storage pool.
If you cannot lower the various Domino buffer pools to lower the paging and faulting to
acceptable levels, then you should consider shifting more memory into the storage pool
that Domino is running in and out of other non-essential storage pools.
If you cannot shift more memory to the storage pool where Domino is running, then you
are running Domino in a memory constrained environment. If you are running Domino in a
memory constrained environment, then you should change the main storage options of
the IFS objects Domino uses to *MINIMIZE. For more information on the new main
storage options in OS/400 V5R2, see “Change Attribute (CHGATR) command - main
storage options” on page 219.

Disk space
As stated previously, there is a finite number of resources on any system. This limit changes
from system to system, but it is finite. There is a limited amount of disk space (DASD) on the
iSeries and if you hit the limit, the iSeries will IPL itself. This is bad! You do not want an
unplanned IPL. Therefore, you need to keep an eye on the DASD. If you are getting close to
the limit (100% used), then you have to get rid of some of the objects taking up disk space.

The Work with System Status (WRKSYSSTS) screen allows you to monitor the amount of
DASD used on your system. The fields on the upper right-hand side of the screen provide
information on DASD.

The System ASP field shows the amount of DASD configured in the system auxiliary storage
pool (ASP). The % system ASP used field shows how much of the DASD in the system ASP
has been used to this point. So, if the system ASP has 87 GB and 51% has been used, that
means there is about 42.6 GB of DASD left to be used in the system ASP before it is full.

The Total field shows how much DASD is available to the entire iSeries. This includes the
system ASP, any configured user ASPs, and any configured independent ASPs. If the Total
field and the System ASP field are the same, then there are no user or independent ASPs
configured on this system.

The Current unprotect used field shows how much temporary storage is currently in use on
the iSeries. Temporary storage is included in the % system ASP used field. Temporary
storage is released when the job using that storage ends. The Maximum unprotect field
shows the maximum amount of temporary storage in use on the iSeries at one point in time.
The Maximum unprotect field is the maximum since the last IPL.

If the storage on your system is quickly approaching 100%, you need to figure out where that
storage is being used.

The first thing you need to do is decide if the storage being used is temporary storage - is the
Current unprotect used field increasing rapidly? Or is the storage being used permanent
storage - is Current unprotect used field not increasing as fast as the % system ASP used
field? (Permanent storage is not released when the job that used it ends.)

If most of the storage driving the iSeries to 100% DASD utilization is temporary storage, then
you need to figure out which job is using the temporary storage and why. See “Finding the
root cause behind rapidly increasing temporary storage” on page 176.

If most of the storage driving the iSeries to 100% DASD utilization is permanent storage, then
you need to figure out what new objects are taking up space on your system. See “Finding
objects taking up permanent storage” on page 180.

Chapter 4. Tuning Domino performance on the iSeries 175

 Finding the root cause behind rapidly increasing temporary storage

Tip: Make sure you have the latest OS/400 PTFs related to temporary storage applied to
your system. To find the list of OS400 PTFs relating to temporary storage, go to the
following Web site and search for a document called Temporary Storage PTFs:
http://www-912.ibm.com/s_dir/slkbase.nsf/slkbase

The first step to find the root cause behind rapidly increasing temporary storage is to identify
the job using all the temporary storage. There are two parts to this process.

The first part is to identify a list of likely jobs. To generate that list, use the TASKINFO
advanced analysis macro in the iSeries System Service Tools.

Important: You need to be careful when you access the iSeries System Service Tools. The
tools that are pointed to in this chapter are not dangerous and will not break anything on
your iSeries as long as you follow the instructions carefully. However, there are other tools
in the System Service Tools that can alter or damage your operating system if you do not
use them correctly.

1. Start the iSeries System Service Tools using the command:

STRSST
2. Enter your SST user ID and password.
3. Select option 1 to Start a service tool.
4. Select option 4 for Display/Alter/Dump.
5. Select option 1 for Display/Alter storage.
6. Select option 2 for Licensed Internal Code (LIC) data.
7. Select option 14 for Advanced analysis.
8. Page down to the TASKINFO macro and place a 1 in front of it. Press Enter.
9. Enter the following string of characters in the Options field and press the Enter key:
-ALL -F 5 -TF 2 -SORT 7

Note: To get the correct output, it is important to get the spaces in this string in the
correct places. The Options string is -ALL <space> -F <space> 5 <space> -TF <space>
2 <space> -SORT <space> 7.

Where:
– -ALL means output all active jobs and tasks on the iSeries.
– -F 5 means output the first five frames of the call stack for each job/task.
– -TF 2 means timestamps will be output in a date/time format rather than an 8 byte
timestamp.
– -SORT 7 means that all the jobs/tasks will be sorted in descending order by the delta
temporary auxiliary storage used. (This is the total temporary storage allocated minus
the temporary storage deallocated.)
If you need help on this macro or if you want to see other options, place -H in the Options
field and press Enter.

176 Domino 6 for iSeries Best Practices Guide

 Important: The AuxStgDelta field in the TASKINFO output is not perfect. The iSeries can
only track storage that is freed if the same job that allocated the storage, deallocates the
storage. So if JOB1 allocates the storage, then JOB1’s storage allocation increases. And if
JOB1 deallocates that storage, then JOB1’s storage deallocation increases. However, if
JOB2 deallocates the storage from JOB1, then JOB1’s storage deallocation does not
increase and the statistics are no longer 100% accurate.

Even though the temporary storage output from the TASKINFO macro is not perfect, it is
still the fastest way to find out which jobs are allocating a lot of temporary storage. Once
you have that information, you can check each job one at a time and see how much
temporary storage it really has allocated.

10.Write down the first 15 jobs listed in the output from the TASKINFO macro.

This list of likely jobs gives you a starting point. See Figure 4-1 for an example of the output
from the TASKINFO advanced analysis macro. Notice that each job and task starts with the
work Task and then the task number. Also notice that the AuxStgDelta is the number of pages
allocated in Hex (a page is 4 KB.)

Display Formatted Data

Page/Line. . . 1 / 11
Columns. . . : 1 - 78
Find . . . . . . . . . . .
....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
Task 1: TDE=B000200003D16000 TaskName=MASOSERVICETASK TimeSinceRun=38:31
00030 QQu-QuQueue WaitObjCaller=FFFFFFFFC18917B4 module masoServicePgm offset
--AuxStgAlloc(pages)=0x00012D65 AuxStgReleased=0x00000000 AuxStgDelta=0x00012D
ISF=FA82F0F64AFFFCE0 NIA=FFFFFFFF80444214 module QuQueueCodeBla offset 0x2A4
ISF=FA82F0F64AFFFD80 NIA=FFFFFFFFC18917B4 module masoServicePgm offset 0x64
ISF=FA82F0F64AFFFE80 NIA=FFFFFFFF804F5E48 module rmInitialRoutine offset 0x48
ISF=FA82F0F64AFFFEC0 NIA=0000000000000000 Not valid instruction address
Stack unwind complete
Task 2: TDE=B00020000957F000 TaskName=MSTHREAD SERVER QNOTES 021960
15 WaitObj=D27B3BA1A901F790 SLW-LO Soc Select LgWait WaitObjCaller=FFFFFFFFB11
00008DD1000
--AuxStgAlloc(pages)=0x0025B8AF AuxStgReleased=0x0024C1AB AuxStgDelta=0x0000F7
ISF=FADC40210EFFDCE0 NIA=FFFFFFFFFE69A02C module RmprLongWaitRcvQueue offset 0
ISF=FADC40210EFFDE40 NIA=FFFFFFFFB11DB7E8 module CfSync offset 0x308
ISF=FADC40210EFFDF40 NIA=FFFFFFFFCC56CFE8 module LoSelectManager offset 0x1448
ISF=FADC40210EFFE7A0 NIA=FFFFFFFFB1051324 module LoSocketApi offset 0x6AC4
More...
F2=Find F3=Exit F4=Top F5=Bottom F10=Right F12=Cancel

Figure 4-1 Output from the TASKINFO advanced analysis macro

Note: In Figure 4-1 above, notice that Task #1 is a LIC task. We know that
MASOSERVICETASK is a LIC talk because there is no job user or job number listed.

Task #2 is a job. It lists a job name (SERVER), job user (QNOTES), and job number
(021960).

The TASKINFO macro breaks up multi-threaded jobs like SERVER. Each thread has its
own task dispatching element (TDE) and is listed separately in this output. Therefore, it
would be normal to see SERVER job 021960 again in this list.

Chapter 4. Tuning Domino performance on the iSeries 177

 The second part of identifying the job taking the bulk of the temporary storage involves
monitoring the WRKSYSSTS screen while ending each job from the list you just created
when running the TASKINFO macro. Each time you end a job from your list, watch the
Current unprotect used field. Notice how much it decreases to see if you found the job taking
the bulk of the temporary storage.

Example
Your iSeries has 100 GB of main memory. Yesterday evening your system was only 50% used
(the % System ASP used field was only 50% and the Current unprotect used was only 5 GB
when you went home last night). You noticed this morning, that your storage space was
rapidly increasing. The % System ASP used now reads 85%, the Current unprotect used now
reads 40 GB, and both values are rising. This means that a job on your system is currently
using around 35 GB of temporary storage and not releasing it. Perform these steps to find the
job that is using too much temporary storage:
1. Follow steps 1 to 10 on page 177 to make a list of the 15 jobs that have allocated the most
temporary storage. Here is a partial list for the sake of this example:
ROUTER/QNOTES/022012
QPADEV002F/BOBBY/346852
HTTP/QNOTES/022120
ADMINP/QNOTES/021996
SERVER/QNOTES/021960
2. Now start ending the jobs one at a time while watching the Current unprotect used field on
the WRKSYSSTS screen.
Figure 4-2 shows the WRKSYSSTS screen before you end any jobs.

Work with System Status AS09

08/31/03 16:14:16
% CPU used . . . . . . . : 2.4 Auxiliary storage:
% DB capability . . . . : .0 System ASP . . . . . . : 99.74 G
Elapsed time . . . . . . : 00:00:01 % system ASP used . . : 85.1512
Jobs in system . . . . . : 263 Total . . . . . . . . : 99.74 G
% perm addresses . . . . : .007 Current unprotect used : 39876 M
% temp addresses . . . . : .013 Maximum unprotect . . : 39876 M

Figure 4-2 WRKSYSSTS screen before ending jobs

The first job on the list is a Domino job. Domino jobs do not handle the ENDJOB command
correctly (see “Domino server crashes” on page 581 for more information), so you must
access the Domino console (using the WRKDOMCSL SERVER(<ServerName>) command) and
issue the command TELL ROUTER QUIT to end the ROUTER job. Once ROUTER ends,
check the WRKSYSSTS screen again. Remember to press the F10 key to reset the
statistics and get the latest information for the Current unprotect used field.
Figure 4-3 shows the WRKSYSSTS screen after you end the ROUTER job from your list.

Work with System Status AS09

08/31/03 16:15:18
% CPU used . . . . . . . : 2.4 Auxiliary storage:
% DB capability . . . . : .0 System ASP . . . . . . : 99.74 G
Elapsed time . . . . . . : 00:00:01 % system ASP used . . : 84.6582
Jobs in system . . . . . : 263 Total . . . . . . . . : 99.74 G
% perm addresses . . . . : .007 Current unprotect used : 39398 M
% temp addresses . . . . : .013 Maximum unprotect . . : 39876 M

Figure 4-3 Top of the WRKSYSSTS screen after ending the ROUTER job.

178 Domino 6 for iSeries Best Practices Guide

 Notice that the Current unprotect used field only decreased by about 500 MB. This means
that the ROUTER job from your list was not responsible for the large amount of temporary
storage allocated on your iSeries.
3. The next job on your list is an interactive job (QPADEV002F/BOBBY/346852), not a
Domino job. Find out what user BOBBY is doing and see if you can end the job. Assuming
BOBBY says it is okay, issue the End Job command to end the job:
ENDJOB JOB(346852/BOBBY/QPADEV002F)
Once the QPADEV002F job ends, check the WRKSYSSTS screen again. Remember to
press the F10 key to reset the statistics.
Figure 4-4 shows the WRKSYSSTS screen after you end the QPADEV002F job from your
list.

Work with System Status AS09

08/31/03 16:17:26
% CPU used . . . . . . . : 2.4 Auxiliary storage:
% DB capability . . . . : .0 System ASP . . . . . . : 99.74 G
Elapsed time . . . . . . : 00:00:01 % system ASP used . . : 84.3512
Jobs in system . . . . . : 263 Total . . . . . . . . : 99.74 G
% perm addresses . . . . : .007 Current unprotect used : 39085 M
% temp addresses . . . . : .013 Maximum unprotect . . : 39876 M

Figure 4-4 Top of the WRKSYSSTS screen after ending the QPADEV002F job.

Notice that the Current unprotect used field only decreased by about 300 MB. This means
that the QPADEV002F job from your list was not responsible for the large amount of
temporary storage allocated on your iSeries.
4. The next job on your list is another Domino job. Access the Domino console again
(WRKDOMCSL SERVER(<ServerName>)) and issue the command TELL HTTP QUIT to end the
HTTP job. Once HTTP ends, check the WRKSYSSTS screen again. Remember to press
the F10 key to reset the statistics and get the latest information for the Current unprotect
used field.
Figure 4-5 shows the WRKSYSSTS screen after you end the HTTP job from your list.

Work with System Status AS09

08/31/03 16:19:06
% CPU used . . . . . . . : 2.4 Auxiliary storage:
% DB capability . . . . : .0 System ASP . . . . . . : 99.74 G
Elapsed time . . . . . . : 00:00:01 % system ASP used . . : 51.7512
Jobs in system . . . . . : 263 Total . . . . . . . . : 99.74 G
% perm addresses . . . . : .007 Current unprotect used : 5789 M
% temp addresses . . . . : .013 Maximum unprotect . . : 39876 M

Figure 4-5 Top of the WRKSYSSTS screen after ending the HTTP job.

Notice that the % System ASP used dropped down to 51% and the Current unprotect
used is down to about 5.8 GB. This is just about where the system was when you went
home last night. This means that the HTTP job was responsible for the large amount of
temporary storage allocated.

Chapter 4. Tuning Domino performance on the iSeries 179

 Now that you have identified the job that took all of the unexpected temporary storage, you
need to think about what that job is responsible for. You also need to think about any changes
made recently that might have affected that job. For instance, in our example, the HTTP job
was responsible for the excessive temporary storage allocation, so think about any new
applications you might have launched yesterday (since that is the last time everything looked
okay on your system) that may have caused all the extra memory allocation.

If you cannot figure out what caused the extra memory allocation, restart the jobs you ended.
Monitor the % System ASP used field and Current unprotect used field on the WRKSYSSTS
screen closely. See if this problem happens again. If it does, you have two options:
1. Try to figure out, by yourself, what is causing the problem.
Assume it is the same job taking the excessive temporary storage as the last time. To
confirm that assumption, use the WRKJOB command and menu option 3 to see
approximately how much temporary storage is currently allocated to the job.
If the temporary storage allocation is very high for that job, then you must identify which
thread is taking the bulk of that storage. (The information in “High CPU utilization in
Domino job(s)” on page 583 in the appendixes can help you.)
Once you identify the thread taking the bulk of the temporary storage for the job, then you
must figure out what that thread is doing. Check the call stack for the thread or run Domino
commands like TELL HTTP SHOW THREAD STATE.
This can be a very complex issue. It could be a problem with OS/400, Java, Domino, a
third party application, or an application you coded. Complete instructions for debugging
this issue could fill another entire redbook. It is outside the scope for this redbook.
2. Contact IBM Support for assistance in finding the root cause of the problem.
Call Lotus Support if a Domino job is responsible for the excessive temporary storage
allocation. Call IBM SupportLine if a non-Domino job is responsible for the excessive
temporary storage allocation.

Finding objects taking up permanent storage

When the % System ASP used field increases, but the Current unprotect used field
(temporary storage) is not increasing on the WRKSYSSTS screen, then you have a problem
with permanent storage. Permanent storage does not decrease when the job that created it
ends. This means you have to identify where the new objects taking up space on your system
are located. Are they in a library? Are they in the Domino data directory? Are they on an
output queue?

The Disk Space Tasks menu (GO DISKTASKS) provides the option for collecting disk space
information. This helps in showing how storage is being used on your system. After collecting
the information, you can specify what information to include in a report and then print the
report.

Information on the Disk Space Tasks menu and how to use it is located in an IBM Knowledge
Base document called ‘Go DISKTASKS Overview’. It can be found on the following Web site:
http://www-912.ibm.com/s_dir/slkbase.nsf/slkbase

Once you gather the information, we suggest that you start by printing out a System
Summary Information report. This gives you a basic overview of all the storage space in use
on the iSeries. The output looks like Figure 4-6.

The reports are always printed from the most recent data collected. Make sure that the
collection you ran completed successfully by checking the Information collected data and
time field. Notice that Figure 4-6 has a date of August 4th, 2003 and a time of 11:01 PM.

180 Domino 6 for iSeries Best Practices Guide

 Display Spooled File
File . . . . . : QPEZDISK Page/Line 1/1
Control . . . . . Columns 1 - 78
Find . . . . . .
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
Disk Space Report
5722SS1 V5R2M0 020719
System Information
Information collected . . . . . . . . . : 08/04/03 23:00:01 Machine ty
System ser
Total disk space on system in 1,000,000
bytes . . . . . . . . . . . . . . . . : 87745 Customize
Main storage size in megabytes . . . . . : 12288 Report t
Asp devi
% of Size in
Description Disk 1,000,000 bytes
User libraries 48.60 42648.18
User directories 8.37 7341.38
Folders and documents .02 19.30
QSYS 2.73 2397.35
Other IBM libraries 5.26 4618.77
More...
F3=Exit F12=Cancel F19=Left F20=Right F24=More keys

Figure 4-6 System Summary Information report example from GO DISKTASKS menu

There are many permanent objects on the iSeries that may be taking storage. The three most
common objects that we see related to Domino and permanent storage are:
1. Spooled files:
You should regularly delete spooled files on your iSeries. The OS/400 Operational
Assistant menu allows you to schedule regular cleanup of objects such as spooled files. It
is recommended that you enable the cleanup feature of the OS/400 Operational Assistant.
To enable this feature and configure it, use the GO CLEANUP menu and option 1. The
default number of days to keep spooled files is seven days. This means that spooled files
that are older than seven days will be deleted when the night cleanup task runs if you do
not change the defaults.
2. Temporary Domino files:
Domino creates many temporary files when it runs. We call them temporary files because
they are not required for Domino and they are usually deleted automatically. The list below
gives you a few of the most common temporary files. They can all be deleted manually
using the RMVLNK command when the Domino server is ended. In general, you should
not delete these files when the Domino server is active.

Note: It is a good idea to periodically end the Domino server and delete the files listed
below. We recommend doing this at least once a month:
򐂰 By default, the Domino server must touch every stream file in the Domino data
directory during startup. So the more files you have in the data directory, the longer
it takes to start the server.
򐂰 By default, the Domino server function DbDirMan runs every minute in the SERVER
job. DbDirMan touches all of the stream files in the Domino data directory. So the
more files you have in the data directory, the longer DbDirMan runs and the more
CPU the SERVER job takes.

Chapter 4. Tuning Domino performance on the iSeries 181

 – nsd_yyyymmdd_hh:nn:ss.nsd:
These files are the Notes System Diagnostics (NSD) files. They are automatically
created on the iSeries when a Domino server crashes.
yyyy is the year, mm is the month, dd is the day, hh is the hour, nn is the minute, and ss
is the second that the crash occurred. If you are not actively investigating a crash
related to these NSDs, the files can be deleted.
– STxxxxxx.TMP:
These files are created by inbound SMTP messages when the NOTES.INI parameter
SMTPSaveImportErrors is set to 1 or 2. xxxxxx is a random six digit number.
If you are not actively investigating a problem with inbound SMTP messages, these
files can be deleted and the SMTPSaveImportErrors can be disabled. To disable the
parameter, set it to 0 or delete the entry from NOTES.INI, then restart the Domino
server.
– IDBxxxxx.DTF:
These files are created by the UPDALL and UPDATE tasks when they are indexing
databases. xxxxx is a random five digit number.
Normally, these files are only temporary and they should be deleted when the jobs are
done indexing the databases. However, if something abnormal occurs, like a Domino
server crash, these files are lost by the jobs that created them and they will not be
automatically deleted.
If you end the Domino server and these files still exist, it is safe to manually delete
them via iSeries Navigator or with the RMVLNK command.
– memory_iiiiiiii_yyyy_mm_dd@hh_nn_ss.dmp:
These files are created in the IBM_TECHNICAL_SUPPORT subdirectory of the
Domino data directory when a Domino administrator issues the SHOW MEMORY
DUMP command. iiiiiiii is the iSeries system name, yyyy is the year, mm is the month,
dd is the day, hh is the hour, nn is the minute, and ss is the second that the memory
dump was taken.
If you are not actively using these files to investigate a memory leak on your Domino
server, then it is safe to delete them the next time you end the Domino server.
– dcntrlrMMDDXXXX.log:
These files are created by the Domino 6 Java Console feature. They contain all the
data from the Domino console including Domino commands that you issue and their
output. MM is the month, DD is the day, and XXXX is a timestamp.
If you are not actively using these files to debug a problem with your Domino server,
then it is safe to delete them the next time you end the Domino server.
– SEMDEBUG.TXT:
This file is used to hold output from the semaphore debug parameters. It is located in
the IBM_TECHNICAL_SUPPORT subdirectory of the Domino data directory. If you
have enabled semaphore debug (Debug_Capture_Timeout) in the NOTES.INI, then
the output is placed in this stream file. If you do not turn off semaphore debug, then the
file will keep growing in size.
If you are not actively using this file to debug a Domino server hang or a Domino
performance problem, then you can delete the file the next time you end the Domino
server.

182 Domino 6 for iSeries Best Practices Guide

 – htthr_xxx_xxx_xxxx.log
These files are created when you enable HTTP thread logging in Domino 6. (In
Domino 5, the HTTP thread logging files started with the letters req.) xxxx are numbers
and letters that can represent thread IDs, session IDs, or date timestamps.
Starting with Domino 6.0.2 CF1, these files are no longer located in the Domino data
directory. At Domino 6.0.2 CF1, they are now automatically located in the
IBM_TECHNICAL_SUPPORT subdirectory of the Domino data directory.
If you are not actively debugging an HTTP problem, you can delete these files the next
time you end the Domino server.
3. Transaction logs used by BRMS online incremental save:
If you configure your Domino server to run BRMS online incremental saves
(CHGDOMSVR ADLSVR(*BRMS)) but do not run a BRMS online incremental save, then
you can have a problem with permanent storage.
When you configure your Domino server for BRMS online incremental saves, you get a
new job called QNNINBRM that runs in the Domino subsystem. This job has several tasks.
One of those tasks is to take the transactions logs from the directory you configured and
place them into the subdirectory called BRMS/INCRSAVE when the transaction logs fill
up. If you configure your Domino transaction logs for 4 GB and the transaction logs hit that
4 GB limit, then the QNNINBRM job will copy the transaction logs into the
BRMS/INCRSAVE subdirectory so you do not get an error on your transaction logging.
The idea is that when you run the BRMS online incremental save, BRMS will save the
transaction logs in the BRMS/INCRSAVE subdirectory and then delete them. If however,
you never run a BRMS online incremental save, then those files will never be deleted.
Therefore, you should not configure your Domino server for BRMS online incremental
saves if you do not plan to run a BRMS online incremental save.

Job activity levels

Another important value on the Work with System Status (WRKSYSSTS) screen is
information on jobs state transitions. This information is located on the bottom half of the
screen. To display the transition data, you may have to press F11 at least once to display
other columns.

The columns you want to look at are entitled Max Active, Active->Inel, and Wait->Inel. Inel
stands for ineligible.

An ineligible job has work to do, but the iSeries is unable to accept more work at the present
time.

If a job goes ineligible, the things it needs to run that were in main memory or cache will
probably be paged out before the job gets back to the processor. This means that the job will
have to spend time getting the things it needs back into main memory or cache before it can
do its actual work. Therefore, the job will run longer and slow down performance. Remember,
cache is faster than main memory which is faster than disk I/O.

During normal system operations, you want zero jobs to be going ineligible. Be aware, jobs
going from the active state to the ineligible state (Active->Inel) will affect performance faster
than jobs going from a wait state to the ineligible state (Wait->Inel). However, both state
transitions are bad for performance. How much work an iSeries can handle is controlled by a
concept called activity levels.

Chapter 4. Tuning Domino performance on the iSeries 183

 An activity level is set in two places:
򐂰 The first place controls the entire system. It is the system value QMAXACTLVL. For more
information on this system value, see “QMAXACTLVL” on page 212.
򐂰 The second place is controlled by the Max Active column on the Work with System Status
screen. This controls all the processes running in a particular storage pool.
Each storage pool has its own value for the Max Active column. The *MACHINE pool is set
to ++++ which means the value is too large to be displayed. This is normal for the
*MACHINE pool and it cannot be changed.
If you see jobs going ineligible in a storage pool, you should increase the Max Active value
for that storage pool. For more information on this, see “Activity Level” on page 598.

4.1.2 Work with Active Jobs and Work with System Activity
There are two commands that allow you to monitor the CPU utilization on the iSeries. Those
commands are Work with Active Jobs (WRKACTJOB) and Work with System Activity
(WRKSYSACT). While these commands show similar information, they are not exactly the
same.

A few of the differences are as follows:

򐂰 The WRKACTJOB command is available on all iSeries running OS/400.
The WRKSYSACT command is only available if you have installed the iSeries
Performance Tools (5722-PT1).
򐂰 WRKACTJOB shows only jobs.
WRKSYSACT shows jobs and LIC tasks.
򐂰 WRKACTJOB shows the original run priority.
WRKSYSACT shows the current run priority. This is important if QDYNPTYADJ is
enabled. For information on this system value see “QDYNPTYADJ and QDYNPTYSCD” on
page 217.
򐂰 WRKACTJOB shows which storage pool a job is running in.
WRKSYSACT does not contain information on storage pools.
򐂰 WRKACTJOB does not contain any information on how many processors are active in the
LPAR.
WRKSYSACT shows the number of currently active processors for an LPAR that shares
processors.
򐂰 WRKACTJOB combines all secondary threads together under the initial thread of a
multithreaded job.
WRKSYSACT lists each thread individually on the screen.
򐂰 WRKACTJOB shows all the jobs currently active on the system (LPAR).
WRKSYSACT only shows the jobs (threads) and LIC tasks that are currently taking CPU
on the system (LPAR).

As you can see from this list, the WRKACTJOB and WRKSYSACT commands show a lot
more than just the CPU utilization. Next we discuss the information these commands provide
that relates to Domino and performance.

184 Domino 6 for iSeries Best Practices Guide

Work with Active Jobs (WRKACTJOB)
We start by describing the information on the WRKACTJOB screen since it is available on all
iSeries systems.

CPU
The primary use for the Work with Active Jobs command is to view the CPU in use on the
system. WRKACTJOB can display the total CPU in use on the system. It also displays the
CPU used by each job. The data can represent a snapshot of what the CPU looks like right
now or an average of what the CPU has looked like over the past few hours. If you know what
the CPU on your system normally looks like, you can use this command to find possible
problems relating to performance or looping jobs. (To know what your system looks like, you
should be monitoring the performance on your system. See Chapter 3, “Monitoring Domino
performance on the iSeries” on page 121.)

You can display the CPU data in a couple of ways. The default is to sort the jobs by name in
their respective subsystems. This allows you to see all the Domino jobs for one server
grouped together under their subsystem. You can also sort the jobs by the percentage of CPU
they are using. To sort the jobs by CPU, place your cursor on the CPU % column and press
F16. This will sort the jobs in descending order by the CPU percentage they are using.

For an example of how the WRKACTJOB output looks by default, see Figure 4-7. Notice the
CPU % field at the top left. This is the CPU for the entire system. There is also a column
called CPU %. That column shows the CPU percentage in use for a single job.

Work with Active Jobs AS09

09/04/03 17:00:20
CPU %: 8.1 Elapsed time: 00:04:25 Active jobs: 210

Type options, press Enter.

9=Exclude 10=Display call stack 11=Work with locks
12=Work with threads 14=Work with mutexes ...

Opt Subsystem/Job User Type CPU % Function Status

DOMCLUS1 QSYS SBS .0 DEQW
ADMINP QNOTES BCI .0 PGM-ADMINP SELW
AMGR QNOTES BCI 1.0 PGM-AMGR SELW
AMGR QNOTES BCI .0 PGM-AMGR CNDW
CALCONN QNOTES BCI .0 PGM-CALCONN CNDW
CLDBDIR QNOTES BCI 4.2 PGM-CLDBDIR CNDW
CLREPL QNOTES BCI .0 PGM-CLREPL SELW
COLSRV400 QNOTES BCI .0 PGM-COLSRV400 SELW
EVENT QNOTES BCI .1 PGM-EVENT SELW
More...
Parameters or command
===>
F3=Exit F5=Refresh F7=Find F10=Restart statistics
F11=Display elapsed data F12=Cancel F23=More options F24=More keys

Figure 4-7 WRKACTJOB screen defaults

Chapter 4. Tuning Domino performance on the iSeries 185

 Important: Notice the Elapsed time field in the top center of the screen. This shows how
long the data on the screen has been collecting. So if the Elapsed time is two seconds, you
have a snapshot of what the CPU looks like in the past two seconds. If the Elapsed time is
20 minutes, the data on the screen shows the average CPU utilization over the past 20
minutes.

An elapsed time of 2 to 30 minutes is a good time span to look at. When the elapsed time
is less than two minutes, the data may be skewed by a sudden spike of activity. When the
elapsed time is greater than 30 minutes, the data you are looking at may be too general to
spot any problems. If you are trying to debug a performance problem that started 20
minutes ago and you are looking at an elapsed time of 4 hours, then the performance
problem will be hidden by the 3 hours and 40 minutes where the system was running fine.

For an example of how WRKACTJOB looks when you sort the jobs by CPU, see Figure 4-8.

Notice that the CPU % field in the top right corner shows that the system is running at 72%.
However, the jobs listed only show about 47%. In this situation, it is likely that a LIC task is
generating the missing 25% of CPU utilization. To find out which LIC task is taking 25% of the
CPU, use the WRKSYSACT command. See “Work with System Activity (WRKSYSACT)” on
page 190.

Work with Active Jobs AS09

09/04/03 14:56:23
CPU %: 72.0 Elapsed time: 00:26:03 Active jobs: 210

Type options, press Enter.

9=Exclude 10=Display call stack 11=Work with locks
12=Work with threads 14=Work with mutexes ...

Opt Subsystem/Job User Type CPU % Function Status

SERVER QNOTES BCI 11.3 PGM-SERVER SELW
SERVER QNOTES BCI 8.2 PGM-SERVER SELW
SERVER QNOTES BCI 6.2 PGM-SERVER SELW
SERVER QNOTES BCI 5.1 PGM-SERVER SELW
SCHED QNOTES BCI 4.9 PGM-SCHED SELW
LWD MSTEF BCI 3.8 PGM-LWD TIMW
EVENT QNOTES BCI 3.6 PGM-EVENT SELW
EVENT QNOTES BCI 2.4 PGM-EVENT SELW
EVENT QNOTES BCI 1.1 PGM-EVENT SELW
More...
Parameters or command
===>
F3=Exit F5=Refresh F7=Find F10=Restart statistics
F11=Display elapsed data F12=Cancel F23=More options F24=More keys

Figure 4-8 WRKACTJOB sorted by CPU %

For examples of using CPU values to identify a problem, see “Daylight Savings Time” on
page 600 and “Server based mail rules” on page 606.

186 Domino 6 for iSeries Best Practices Guide

Run priorities
Jobs running on the iSeries have several attributes. One of those attributes is run priority. The
run priority of a job tells you how likely a job is to get system resources.

For example, if you are having problems with response times from a Web browser, you should
look at the run priority of the HTTP job. By default, the Domino HTTP job has a run priority
of 20. Once you know the run priority of the job having problems (HTTP), then you look at
other jobs that are taking a lot of CPU in your system and check their run priorities. If you
have another job taking 40% of the CPU and it has a better run priority (like 15), then that job
will get to use the system resources before the HTTP job.

For more information on what a job run priority is and how to change it, see “Run priority” on
page 192.

Important: The run priority displayed on the WRKACTJOB screen is the run priority that a
job started with or the run priority you changed the job to with the Change Job (CHGJOB)
command. If you have QDYNPTYADJ enabled (see “QDYNPTYADJ and QDYNPTYSCD”
on page 217), then the system may be changing the job’s run priority. That dynamic run
priority change is not displayed on the WRKACTJOB screen.

The QDYNPTYADJ changed run priority is displayed on the Work with System Activity
(WRKSYSACT) screen. This command is part of the iSeries Performance tools
(5722-PT1).

The Work with Active Jobs screen can show you the run priority of any job in the system,
including Domino jobs. To view this data, do the following steps:
1. Enter the WRKACTJOB command:
WRKACTJOB
2. Press F11 until you see a column called Pty.
The Pty column shows the run priority of a job. See Figure 4-9.

Notice that all Domino jobs have a run priority of 20. That is the default run priority for all
Domino jobs.

Also notice that there are now two CPU columns. One column is CPU % and the other
column is CPU. The CPU % column is the same one we discussed above in “CPU” on
page 185. The new CPU column shows the total processing unit time used by the job,
expressed in seconds. That is, it shows how many seconds the job has been in the processor.

Chapter 4. Tuning Domino performance on the iSeries 187

 Work with Active Jobs AS09
09/02/03 12:25:43
CPU %: 4.1 Elapsed time: 00:05:08 Active jobs: 211

Type options, press Enter.

2=Change 3=Hold 4=End 5=Work with 6=Release 7=Display message
8=Work with spooled files 13=Disconnect ...
--------Elapsed---------
Opt Subsystem/Job Type Pool Pty CPU Int Rsp AuxIO CPU %
AMGR BCI 2 20 26.6 0 .0
AMGR BCI 2 20 18.0 0 .0
CALCONN BCI 2 20 11.3 0 .0
COLSRV400 BCI 2 20 9.7 0 .0
EVENT BCI 2 20 554.0 0 .1
QNNINSTS BCH 2 20 .0 0 .0
REPLICA BCI 2 20 10.5 0 .0
ROUTER BCI 2 20 34.3 0 .0
SCHED BCI 2 20 40.0 0 .0
More...
Parameters or command
===>
F3=Exit F5=Refresh F7=Find F10=Restart statistics
F11=Display thread data F12=Cancel F23=More options F24=More keys

Figure 4-9 WRKACTJOB: Pool and Pty columns

Storage pools
When reviewing job and system performance, there are times when you need to know which
storage pool a job is running in. By default, Domino jobs run in the *BASE storage pool. The
*BASE pool is pool number 2. Since Domino jobs can be configured to run in other shared or
private pools on the iSeries, you need a way to check which storage pool a job is actually
using.

To determine in which storage pool a job is running, use the WRKACTJOB screen.
1. Enter the Work with Active Jobs command:
WRKACTJOB
2. Page down and find the job you want to look at.
3. Press F11 until you see a column called Pool.
This column shows you which storage pool a particular job is running in.

See Figure 4-9 to view the Pool column. Notice that all of the Domino jobs shown are running
in the default *BASE pool which is pool number 2.

For information on what to do with the storage pool data once you find it, refer to “Work with
System Status (WRKSYSSTS)” on page 172.

Threads
OS/400 V4R2M0 introduced the concept of threads to the iSeries.

Each piece of work on the iSeries is performed in a job and each job has a unique name to
identify it within the system. All jobs, with the exception of system jobs, run in a subsystem. A
job is a collection of one or more threads. Each job has at least one thread which is referred to
as the initial thread. The initial thread is created when the job starts. Some jobs on the iSeries

188 Domino 6 for iSeries Best Practices Guide

have additional threads called secondary threads. A secondary thread inherits its attributes
from the job that started it - so all secondary threads have the same run priority, time slice,
etc.

A thread represents an independent unit of execution within a program. Each thread has its
own run environment, such as a call stack. However, a thread shares many of the resources
that are assigned to the job to which the thread belongs.

Many Domino jobs are multithreaded. For instance, the SERVER, HTTP, and UPDATE jobs
are all multithreaded at Domino 6.

There are a two things you need to be aware of on the WRKACTJOB screen that relate to
threads and Domino performance. The first thing is how the information displayed on the
WRKACTJOB screen relates to threads. The second thing is how to display the number of
threads currently running in a job. We now discuss some of the details:
򐂰 The WRKACTJOB command groups all threads together under their related job.
This means that some statistics that you see on the WRKACTJOB screen relate to only
the initial thread in the job and some statistics relate to all the threads in a job (initial and
secondary).
These are some of the statistics that relate to only the initial thread in the jobs:
– Status:
The job’s status that is listed on the WRKACTJOB screen under the Status column
represents the current status of the initial thread. The secondary threads will have their
own status independent of the initial thread.
To view a secondary thread’s status, use the WRKJOB command (with the appropriate
job information) and then option 20 on the Work with Job screen.

Note: If you make a change to the status of a job (for instance, if you hold a job
using option 3 on the WRKACTJOB screen), then you will be changing the status of
all the threads in that job — not just the initial thread.

– Function:
The function that the job is currently running is listed on the WRKACTJOB screen
under the Function column. The Function represents the current function that the initial
thread is running.
– Call Stack:
Option number 10 on the WRKACTJOB screen allows you to display the call stack for
the initial thread of a particular job. Remember, each thread has its own call stack.
To view the call stack of a secondary thread, use the WRKJOB command (with the
appropriate job information), menu option 20 on the Work with Job screen, and then
option 10 to display the call stack of the thread you select.
Here are some of the statistics that relate to all of the threads in a job:
– CPU %:
The CPU percentage for a job is listed on the WRKACTJOB screen under the CPU %
column. The CPU percentage is the combined CPU used by all the threads in the job,
not just the initial thread.

Chapter 4. Tuning Domino performance on the iSeries 189

 – Run priority:
The run priority of a job is unique statistic on the WRKACTJOB screen.
We stated previously that all secondary threads inherit their attributes from the job that
starts them. This would mean that all threads have the same run priority. So it should
not matter that the Pty column is displaying the run priority of the initial thread, because
all threads should share the same run priority.
However, there is an exception to this rule. The SERVER job has been hardcoded by
IBM development to allow secondary threads to change their run priority as needed for
better performance. This information will not be displayed on the WRKACTJOB screen
or the Work with Threads screen. It is only displayed on the WRKSYSACT screen.
So technically, the run priority displayed on the WRKACTJOB screen only represents
the run priority of the initial thread. However, in most cases, the run priority of the initial
thread is the same as the run priority for all the threads in a job.
򐂰 The WRKACTJOB screen groups all threads together under their respective jobs.
This means that you can see how many threads are currently running in a particular job.
To view this information, issue the WRKACTJOB command and press F11 until you see
the column called Threads.
The number of threads currently active in a job can be useful when debugging
performance problems related to Domino.
For example, imagine your Domino SERVER job normally has 200 threads running under
it. One day you start noticing slow response times when connecting to the Domino server
from a Lotus Notes client. You check WRKACTJOB and notice that the SERVER job has
over 1000 threads running under it. This could mean that you are having network
problems that are causing your Notes sessions to disconnect and then the Lotus Notes
clients attempt to establish another connection using a different thread. Or it could mean
that someone set a NOTES.INI parameter that is affecting the number of threads running
in the SERVER job. An example for such a parameter is the
SERVER_MAX_CONCURRENT_TRANS=-1 which should never be set on an iSeries
running Domino 5 or Domino 6.

Work with System Activity (WRKSYSACT)

The Work with System Activity (WRKSYSACT) command is only available if you have loaded
the iSeries Performance Tools (5722-PT1) on your system. It shows some of the same
information as the WRKACTJOB command. But it also shows some unique information.

CPU
Just like the WRKACTJOB command, WRKSYSACT shows CPU information. It shows both
the system CPU (although it is broken up into maximum CPU, minimum CPU, and average
CPU) and individual process CPU. We use the term process here because WRKSYSACT
shows both jobs and LIC tasks.

In Figure 4-10 on page 191, there are both jobs (threads) and LIC tasks. You can identify a
LIC task by the lack of a job user (the User column) and a job number (the Number column).
RMTMSAFETA is a LIC task, as is CFINT01.

190 Domino 6 for iSeries Best Practices Guide

 Note: CFINTxx is the TDInterupt task. It moves processes from the TDE queue to the
processor. There is one CFINTxx task for each processor and the xx is a number (like
CFINT01).

In the past, this task was also used to throttle back interactive work in iSeries Server
models. The Server models were designed for batch work, not interactive. If too much
interactive work was run on a Server model, the CFINTxx task took CPU to slow down the
interactive work.

This means that it used to be very common to see the CFINTxx task listed on the
WRKSYSACT screen taking a lot of CPU on Server models. CFINTxx is no longer used for
this purpose, however, it still moves processes from the TDE queue to the processor, so it
will still show up in WRKSYSACT. The difference is that CFINTxx is usually taking less
than 1% of the CPU on new systems.

Unlike the WRKACTJOB command, WRKSYSACT only shows the processes actively taking
CPU on the system. It does not list processes that are inactive. To be considered active, a job
or task must use at least one-tenth of 1% (.1%) of the processing unit or perform one I/O
operation.

Also, the WRKSYSACT command does not show all the threads grouped together under the
job that started them. Instead, each individual thread is considered a separate process. This
can be useful when you are trying to identify which thread(s) is generating excessive CPU in
a multithreaded job. Notice the SERVER job in Figure 4-10. The job name (SERVER), user
(QNOTES), and number (021960) are all the same, so this is the same job. However, the
thread number is different. One is thread 0000001B and one is thread 00000014.

Work with System Activity AS09

09/03/03 11:44:35
Automatic refresh in seconds . . . . . . . . . . . . . . . . . . . 5
Elapsed time . . . . . . : 00:00:05 Average CPU util . . . . : 2.8
Number of CPUs . . . . . . : 2 Maximum CPU util . . . . . : 3.5
Overall DB CPU util . . . : .0 Minimum CPU util . . . . . : 2.1
Current processing capacity: 2.00
Type options, press Enter.
1=Monitor job 5=Work with job
Total Total DB
Job or CPU Sync Async CPU
Opt Task User Number Thread Pty Util I/O I/O Util
SERVER QNOTES 021960 0000001B 20 .2 0 0 .0
RMTMSAFETA 0 .2 0 0 .0
SCHED QNOTES 021994 00000002 20 .2 0 0 .0
SERVER QNOTES 021960 00000014 20 .2 0 0 .0
CFINT01 0 .1 0 0 .0
More...
F3=Exit F10=Update list F11=View 2 F12=Cancel F19=Automatic refresh
F24=More keys

Figure 4-10 Work with System Activity command showing jobs and LIC tasks

For an example of how WRKSYSACT and CPU information can help identify problems, see
“High CPU utilization in Domino job(s)” on page 583.

Chapter 4. Tuning Domino performance on the iSeries 191

 Important: There is another LIC task that may show up in the WRKSYSACT screen. It is
the HVLPTASK. A Logical Partition (LPAR) now allows the use of shared processing pools.
The HVLPTASK does not consume real CPU time. It does not affect the performance of a
partition or a job within this partition. CPU time shown to be consumed by HVLPTASK is
only for accounting purposes on an LPAR that uses shared processors.

The CPU time reported for HVLPTASK is a function of the processing capacity assigned to
the partition. The CPU time charged to HVLPTASK scales with the amount of work being
done by real jobs — thus making the system CPU percent utilization behave appropriately
— going from 0 to 100 in direct proportion to the amount of real work going on.

For example: LPAR A has a capacity of 0.9 processor units and it is defined to use one
virtual processor. When the partition is idle, HVLPTASK is consuming 0% of the CPU time.
As the CPU time consumed by real jobs in the partition goes from 0 to 0.9 processor units
(that is the maximum CPU resource allowed), reported system CPU utilization for the
partition will go from 0% to 100% . Reported CPU utilization for HVLPTASK will go from 0%
to 10% and reported CPU utilization by real jobs will go from 0 to 90%.

The morale of this story is, if you are using LPARs with shared processors, do not panic if
you see a task called HVLPTASK taking a lot of CPU on the WRKSYSACT screen. This is
normal for that kind of LPAR configuration.

Run priority
The Work with System Activity screen shows the current run priority for the process. As
stated in the WRKACTJOB section, if you have QDYNPTYADJ enabled (see “QDYNPTYADJ
and QDYNPTYSCD” on page 217), then WRKACTJOB may not show the current run priority.
The WRKSYSACT screen will always show the current run priority, even if QDYNPTYADJ has
changed the run priority.

The WRKSYSACT screen will also show the true run priority of the SERVER threads. As
stated previously in the WRKACTJOB section, the SERVER job is hardcoded so its threads
can change run priority to improve performance. So you should not be surprised if you see
one thread in the SERVER job with a run priority of 20 and another thread in the same
SERVER job with a run priority of 21.

LPAR processor information

The WRKSYSACT screen also contains information on how many processors are currently in
use in the LPAR. The field that contains that information is called Current processing capacity.

The current processing capacity specifies the percentage of the current capacity that is being
used in the LPAR. For an LPAR sharing physical processors, the current processing capacity
represents the share of the physical processors in the pool it is running. For an LPAR using
dedicated processors, the current processing capacity represents the number of virtual
processors that are currently active in the LPAR.

4.1.3 Run priority

Before we describe the performance benefits that you can gain by altering job run priorities,
you need to understand a few things about jobs on the iSeries.

Note: Changing the run priority of a Domino job can help improve response time if the
system CPU is high and the change is made wisely. If the system CPU is low, changing a
job’s run priority does not usually improve response time or performance.

192 Domino 6 for iSeries Best Practices Guide

Background information on jobs and run priorities
A job is a structure in which elements of work are performed on behalf of a user and the
operating system. Each job has at least one thread associated with it.

Some of the different job types are interactive, batch, and batch immediate. The term
interactive has a very specific meaning in OS/400. It refers to a 5250 emulation session with
some strong performance implications. An interactive job becomes active for a short period of
time and then waits for the user’s next request. A batch job runs for long periods of time. A
batch job runs in the background and usually does not require user interaction.

Jobs have several attributes such as run priority, time slice, language feature, CCSID (Coded
Character Set Identifier), and date format/separators.

The run priority is used when a job competes against other jobs for system resources like
CPU. Run priority is a value that ranges from 0 (highest priority) to 99 (lowest priority). So the
smaller the value for the run priority, the better the job's chance of getting system resources.

For example, there are two jobs that want to use the CPU. One job has a run priority of 20, the
other job has a run priority of 50. The job with the run priority of 20 gets to use the CPU first.
The other job has to wait.

When enabled, the dynamic priority scheduler (see “QDYNPTYADJ and QDYNPTYSCD” on
page 217) will adjust job priorities within priority bands, depending on each job's use of
system resources. The priority bands are as follows:
򐂰 Priorities 10-16 are in band 1
򐂰 17-22 are in band 2
򐂰 23-35 are in band 3
򐂰 36-46 are in band 4
򐂰 47-51 are in band 5
򐂰 52-89 are in band 6

Attention: You should never set a Domino job’s run priority to less than 10. Any jobs that
are given a priority of 0 through 9 are put in the high-priority band 0. By default, only
system jobs and subsystems get these priorities.

This band is always checked first by the task dispatcher before any other dynamic priority
bands are checked. If a job in this band becomes processor bound (by looping), the job
can lock the system.

By default, an interactive job has a run priority of 20, a batch job has a run priority of 50, and
a Domino batch immediate job has a run priority of 20 on the iSeries.

Things to consider before changing a job’s run priority

Now that you have the background information, how can you use that information to wisely
alter the run priorities of a Domino job?

First you need to decide if changing the run priorities will help performance. Changing the
priority of a job does not necessarily slow down or speed up a job. Only on a busy system,
where jobs are constantly fighting for resources, will the run priority change the amount of
time it takes for a job to run.

For example, if eight jobs want to use the system processors at the same time and your
iSeries has eight processors, then it does not matter if one job has a higher run priority than
the other jobs. All eight jobs can use the eight processors at the same time. However, take
that same example and substitute an iSeries that only has one processor. Now you can see a

Chapter 4. Tuning Domino performance on the iSeries 193

 difference. The job with the higher run priority gets to use the single processor before the jobs
with the lower run priorities. This means that the job with the higher run priority will finish its
work before the other jobs.

The second step is to break the Domino jobs up into two different groups. One group will
include the Domino jobs that behave like interactive jobs. The other group will include Domino
jobs that act like batch jobs:
򐂰 HTTP and SERVER act like interactive jobs. Users issue requests from clients and wait for
the results. When the user issues the request, one of the job’s threads becomes active.
After the request has been processed, the thread waits for the user’s next request which
may not occur for a few minutes. If the user’s request takes a long time to process, then
the user experiences poor response time and complains about performance.
򐂰 AMGR, UPDATE, and REPLICA act like batch jobs. They handle activities that the server
requests (not the user). Once they start processing an activity, they could run for a long
period of time. End users are not waiting for a response to their requests, so the amount of
time it takes to complete the activity is not as important as for other jobs.

The third step is to decide what your goal in changing the run priorities is. If your goal is to get
faster response time for your users that access Domino via a Web browser, then you have to
figure out how to make the HTTP job’s run priority higher than the other jobs that are taking
CPU on the system. This does not necessarily mean that you need to change the HTTP run
priority from 20 to 15.

This leads us to the final step, which is to plan your changes and look at the possible
consequences. In the HTTP example from the previous step, we said that you do not
necessarily want to change the HTTP run priority to 15. Changing the HTTP run priority to 15
may be the simplest solution, but it may not be the right solution. You need to look at your
system and see what is preventing HTTP from getting time in the processor(s). Maybe the
UPDATE task is constantly running and is taking all the CPU. In that situation you can change
the UPDATE job’s run priority from 20 to 25. This still has the desired effect of making the
HTTP run priority higher than other jobs (UPDATE) that are taking CPU, but it will not hurt
jobs like SERVER or 5250 interactive sessions. If you had changed the HTTP job to 15, then
the SERVER job may start experiencing problems with response time because HTTP has a
higher run priority. So you could end up with a different set of users complaining about
performance which does not solve your problem.

Tip: When changing run priorities, change the priority to a different band. If you want to
change UPDATE so it does not compete with HTTP, change UPDATE from 20 (which is
band 2 with run priorities 17-22) to 25 (which is band 3 with run priorities 23-35).

Be careful when changing the run priorities of certain jobs critical to your server. If your
server primarily handles SMTP mail, do not lower the run priority of ROUTER or SMTP.
Even though ROUTER and SMTP act more like batch jobs than interactive jobs, they are
critical for SMTP mail. If you lower the run priority, you could end up with a lot of mail stuck
in MAIL.BOX waiting for processor time so it can be delivered.

Changing the run priority for a job affects all the threads within the job.

Changing a Domino job’s run priority

Now that you have decided to change a job’s run priority, you need to know how. We describe
two basic ways to change the run priority of a Domino job.

The first way is dynamic using iSeries Navigator. The second way is static using a 5250
emulation session.

194 Domino 6 for iSeries Best Practices Guide

Dynamic change
Changing a run priority dynamically means that the run priority is changed immediately. It
also means that if the job ends and restarts, the job will start up with the original run priority.

Modifying a run priority dynamically is a good way to test your changes. You can alter the run
priority of a job and see what kind of effect it has on the rest of the system. If you do not like
the effect, you can easily change the run priority back to the original value.

To change a job’s run priority dynamically with iSeries Navigator, follow these steps:
1. Start iSeries Navigator.
2. Connect to the system where Domino is running.
3. Select Work Management -> Active Jobs.
4. Scroll down until you find the job for which you want to change the run priority.
5. Right-click that job and select Properties.
6. Click the Performance tab.
7. Change the Run Priority field (see Figure 4-11).
8. Click OK.

Figure 4-11 Changing the run priority of a job via iSeries Navigator

Chapter 4. Tuning Domino performance on the iSeries 195

 Static change
Changing a Domino job’s run priority statically means that the run priority will not change until
you end and restart the Domino job. This is a more lasting change. Every time the Domino job
is restarted, it will pick up this new run priority automatically.

To change a Domino job’s run priority statically via a 5250 emulation, follow these steps:
1. Create a class that defines the new run priority you want to use:
CRTCLS CLS(QUSRNOTES/PRIORITY25) RUNPTY(25)
The new class must be in the QUSRNOTES library.
2. Change the owner of the new class to QNOTES:
CHGOBJOWN OBJ(QUSRNOTES/PRIORITY25) OBJTYPE(*CLS) NEWOWN(QNOTES)
3. Create an empty stream file in the /QIBM/UserData/LOTUS/NOTES directory called
domino_classes. Use the Edit File (EDTF) command to create the file with the correct
code page.:
EDTF STMF('/QIBM/UserData/LOTUS/NOTES/domino_classes')
4. Populate the new stream file with the following information:

Note: The servername is the common name, not the hierarchical server name.

SERVER=servername
CLASS=classname
TASKS=taskname

Note: The domino_classes stream file is referenced by all Domino servers on an

OS/400 instance.

To change the run priority of a Domino job in a specific Domino partition, specify the
server with the keyword SERVER and then reference the class and tasks that you want
to use the new run priority. See Figure 4-12.

Notice that the UPDATE job and REPLICA jobs in server DOMPERF will start with the
run priority defined in the PRIORITY25 class. The CLREPL job in server DOMCLUS1
will start with the run priority defined in the PRIORITY36 class.

5. Once you finished populating the domino_classes file, save the information and exit the
Edit File screen by pressing F3 twice.
6. Change the owner of the new domino_classes stream file to QNOTES:
CHGOWN OBJ('/QIBM/UserData/LOTUS/NOTES/domino_classes') NEWOWN(QNOTES)
7. End and restart your Domino server(s) to pick up the changes:
ENDDOMSVR SERVER(<ServerName>)
STRDOMSVR SERVER(<ServerName>)

196 Domino 6 for iSeries Best Practices Guide

 Edit File: /QIBM/UserData/LOTUS/NOTES/domino_classes
Record : 1 of 6 by 8 Column : 1 59 by 74
Control :

CMD ....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+
************Beginning of data**************
___ SERVER=DOMPERF
___ CLASS=PRIORITY25
___ TASKS=UPDATE,REPLICA
___ SERVER=DOMCLUS1
___ CLASS=PRIORITY36
___ TASKS=CLREPL
************End of Data********************

F2=Save F3=Save/Exit F12=Exit F15=Services F16=Repeat find

F17=Repeat change F19=Left F20=Right

Figure 4-12 The domino_classes stream file to alter the run priorities of Domino jobs

Restriction: All Domino jobs/tasks can have their run priority changed with this method
with the exception of the QNNINSTS and the SERVER jobs. These jobs are hardcoded to
pick up their run priority from the class who’s name matches the name of the subsystem for
the Domino server. It is strongly recommended that you do not change the run priority in
the base (DOMINO02) class for two different reasons:
򐂰 QNNINSTS does most of its work when the Domino server is starting/stopping. You do
not want to negatively impact your Domino server when it is starting or stopping by
changing the run priority of a job responsible for starts/stops.
򐂰 SERVER is designed so that secondary threads’ run priority can change dynamically
while the Domino server is running. Development designed it this way for better
response times. Even if you modify the run priority of SERVER, the code design will
change your modification.

4.1.4 Work with disk status (WRKDSKSTS)

The Work with Disk Status (WRKDSKSTS) screen allows you to view a few aspects of your
iSeries OS/400 direct access storage devices (DASD).

Some of the things you can see is:

򐂰 How many disk units you have configured in an ASP
򐂰 How busy the disk arms are
򐂰 How full each disk unit is

The two aspects that affect Domino performance the most are how busy the disk arms are
and if any disk arms are significantly busier than the other disk arms in the ASP.

Note: Each individual disk unit has a single disk arm. So if you have 12 disk units, you
have 12 disk arms.

Chapter 4. Tuning Domino performance on the iSeries 197

 Each disk I/O causes the disk arm to move. If there is a lot of disk I/O, then the arms are
constantly moving. If another I/O request comes in when the arm is already moving
(performing another I/O), the new I/O has to wait. If enough disk I/O’s have to wait, it will
negatively impact performance.

When a disk arm becomes more than 30% busy, you may start to notice performance issues
with a Domino server. When a disk arm becomes more than 40% busy, you will notice
performance issues with your Domino server.

Before you look at the statistics on the WRKDSKSTS screen, you must know which ASP your
Domino server is configured in. The quickest way to check this is to use the Display Link
(DSPLNK) command.
1. Find the path name of your Domino data directory. Use the WRKDOMSVR command. On
the Work with Domino servers menu press F11 twice for the Path column. This displays
the path of your Domino data directory.
2. Use the Display Link command to output data on the files in the Domino data directory:
DSPLNK OBJ('/LOTUS/DATA/DOMPERF/*') OUTPUT(*PRINT) DETAIL(*EXTENDED) DSPOPT(*ALL)
This command will create a spooled file called QSYSPRT.
3. Search the spooled file for the word Auxiliary.
Auxiliary storage pool number 1 is the system ASP. See Figure 4-13 for an example of the
output from the DSPLNK command.

Display Spooled File

File . . . . . : QSYSPRT Page/Line 13/4
Control . . . . . Columns 1 - 78
Find . . . . . . Auxiliary
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
Object . . . . . . : /LOTUS/DATA/DOMAV/admin4.nsf
Type . . . . . . . . . . . . . . . . . : STMF
File ID . . . . . . . . . . . . . . . : X'0000000000000001841C65AF000020A7
Owner . . . . . . . . . . . . . . . . : QNOTES
System object is on . . . . . . . . . : Local
Auxiliary storage pool . . . . . . . . : 1
Object overflowed . . . . . . . . . : No
Coded character set ID . . . . . . . . : 37
Hidden file . . . . . . . . . . . . . : No
PC system file . . . . . . . . . . . . : No
Read only . . . . . . . . . . . . . . : No
Need to archive (PC) . . . . . . . . . : Yes
More...
F3=Exit F12=Cancel F19=Left F20=Right F24=More keys

Figure 4-13 DSPLNK output used for finding the ASP that Domino is running in

Now that you know which ASP your Domino server is running in, you can use the
WRKDSKSTS command to see how busy the disk arms in your ASP are. Follow the steps
listed below to see how busy the disk arms are:
1. Use the Work with Disk Status command to access information on internal disk units:
WRKDSKSTS
2. Press F11 to see which ASP the disk units are configured to run in.
3. Find the disk units configured in the ASP where Domino is running. So if your Domino
data directory is in ASP number 1, then look for the disk units in ASP 1.

198 Domino 6 for iSeries Best Practices Guide

4. Once you identify the disk units in the ASP where Domino is running, press F11 again to
return to the other statistics.
5. Periodically press the F5 key to refresh the statistics.
Watch the Elapsed time field. You are looking for an elapsed time of 5 to 30 minutes. If the
elapsed time is under 5 minutes, then the data can be skewed by an I/O spike that is only
temporary.
When the elapsed time becomes greater than 30 minutes, press the F10 key to restart the
statistics.
6. Once you have an elapsed time between 5 and 30 minutes, start watching the % Busy
column.

As stated previously, when disk units become more than 30% busy, you may start to notice
performance problems.

If the disk units in the ASP where Domino runs are averaging more than 30% busy on a
typical work day, then you may want to consider buying additional disk units or moving some
workload out of that ASP. See Figure 4-14 for an example of such a system.

Adding disk units would probably improve Domino performance. (This example is a close call.
Performance may be okay, but you should closely monitor the % Busy for any increases.)

Work with Disk Status AS09

09/03/03 11:47:25
Elapsed time: 00:19:42

Size % I/O Request Read Write Read Write %

Unit Type (M) Used Rqs Size (K) Rqs Rqs (K) (K) Busy
1 6717 6442 79.4 1.1 11.1 .0 .1 24.6 5.9 28
2 6717 6442 79.4 1.0 10.8 .0 .0 17.7 4.0 30
3 6717 6442 79.4 1.2 5.0 .0 .0 4.0 5.2 32
4 6717 6442 79.5 1.1 9.7 .0 .0 17.3 6.4 34
5 6718 13161 79.5 1.4 19.6 .0 .0 4.0 22.3 38
6 6718 13161 79.4 1.2 14.9 .0 .0 9.1 19.2 32
7 6718 13161 79.4 1.4 16.6 .0 .0 8.6 21.8 36
8 6718 13161 79.4 1.0 17.0 .0 .0 12.3 20.6 28
9 6718 13161 79.4 1.1 23.2 .0 .0 19.6 28.6 30
10 6718 13161 79.4 1.0 19.7 .0 .0 16.9 22.4 32
11 6718 13161 79.4 1.4 24.7 .0 .0 25.9 23.8 36
12 6718 17548 79.4 1.0 6.2 .0 .0 5.7 6.3 32
13 6718 13161 79.5 1.2 14.1 .0 .0 16.8 11.0 34
More...
Command
===>
F3=Exit F5=Refresh F12=Cancel F24=More keys

Figure 4-14 WRKDSKSTS and the % Busy column

Another important thing to check on the WRKDSKSTS screen is how busy the disk arms are
in relation to other disk arms in the same ASP. If one or two disk arms are significantly busier
than the other disk arms in the same ASP, then you may have a problem with how the data is
distributed on the disk units.

Chapter 4. Tuning Domino performance on the iSeries 199

 The iSeries uses a concept called single-level storage, which among other things, attempts to
evenly distribute data across multiple disk units. Normally, this works great and you can see
good performance as a result. Occasionally, one or two disk units have data on them that is
more frequently accessed than other disk units in the same ASP. When this happens,
performance can be negatively impacted because everyone wants to access the data at the
same time and the disk arms can only process one request at a time.

Important: When you are looking for problems with disk units balancing, you must have an
elapsed time greater than 10 minutes. Anything under 10 minutes could be skewed by a
spike in usage and should be ignored.

If this happens, you should attempt to redistribute the data across other disk units in the ASP.
For information on how to do this, you can either contact the IBM iSeries SupportLine or
search the iSeries Information Center for the Trace ASP Balance® (TRCASPBAL) and Start
ASP Balance (STRASPBAL) commands at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

See Figure 4-15 for an example of a single disk unit (#6) being accessed too often. In this
situation, you should consider redistributing the data to other disk units in the ASP.

Work with Disk Status AS25

09/03/03 12:10:53
Elapsed time: 00:20:01

Size % I/O Request Read Write Read Write %

Unit Type (M) Used Rqs Size (K) Rqs Rqs (K) (K) Busy
1 6713 6442 89.6 1.2 4.0 1.2 .0 4.0 .0 1
3 6713 7516 89.6 .0 .0 .0 .0 .0 .0 0
5 6713 7516 89.6 .6 4.0 .6 .0 4.0 .0 1
6 6713 6442 89.6 1.2 4.0 1.2 .0 4.0 .0 33
7 6713 7516 89.6 .0 .0 .0 .0 .0 .0 0
8 6713 7516 89.6 .0 .0 .0 .0 .0 .0 0
9 6713 7516 89.6 .6 4.0 .6 .0 4.0 .0 2
10 6713 7516 89.6 .0 .0 .0 .0 .0 .0 0
12 6713 6442 89.6 .1 .0 .0 .0 .0 .0 3
13 6713 7516 89.6 .0 .0 .0 .0 .0 .0 0
14 6713 7516 89.6 .0 .0 .0 .0 .0 .0 0
15 6713 6442 89.6 .0 .0 .0 .0 .0 .0 0
16 6713 7516 89.6 .0 .0 .0 .0 .0 .0 0
More...
Command
===>
F3=Exit F5=Refresh F12=Cancel F24=More keys

Figure 4-15 WRKDSKSTS and an unbalanced disk unit

4.1.5 Network Status (NETSTAT) and other communication information

There are several aspects relating to TCP/IP and network configuration that can affect
Domino performance on an iSeries. We discuss the most common issues in this section:
򐂰 “Work with TCP/IP Connection Status (NETSTAT *CNN)” on page 201
򐂰 “Configure TCP/IP (CFGTCP)” on page 204
򐂰 “Work with Line Descriptions (WRKLIND)” on page 207
򐂰 “Communications Trace and Resets (RST)” on page 207

200 Domino 6 for iSeries Best Practices Guide

Work with TCP/IP Connection Status (NETSTAT *CNN)
The Work with TCP/IP Connection Status (NETSTAT *CNN) screen displays a lot of
information about connections to the iSeries. There are several things to look at, but we only
mention two items as they relate directly to Domino and performance:
򐂰 “Ports in a LISTEN state” on page 201
򐂰 “Retransmissions” on page 202

Ports in a LISTEN state

A port is a 16-bit number used to communicate between the Transmission Control Protocol
(TCP) or higher level protocol and an application process. A TCP port identifies the ultimate
destination within a system. Each process that wants to communicate with another process
identifies itself to the TCP/IP protocol by one or more ports.

Ports are analogous to network and system addresses. Just as an internet address identifies
a system on a network, a port identifies a destination on a system. An application (such as a
Domino server) may wait for incoming service requests on a port. A client application (such
as a Lotus Notes client) sends requests to a specific iSeries and port. Ports numbered less
than or equal to 1023 are generally reserved for use by standard TCP and User Datagram
Protocol (UDP) application programs such as Simple Mail Transfer Protocol (SMTP) on
port 25, TELNET on port 23, and Post Office Protocol (POP3) on port 110.

A Domino server commonly uses the following ports:

򐂰 1352 for Lotus Notes client connections
򐂰 80 for Web browsers connecting to the Domino HTTP job
򐂰 110 for POP3 clients connecting to the Domino POP3 job
򐂰 25 for inbound SMTP messages connecting to the Domino SMTP job
򐂰 389 for Lightweight Directory Access Protocol (LDAP) queries

For a Domino server to work properly, the correct ports must be in a LISTEN state on the
iSeries. When a port is in LISTEN status, it is listening for new connection requests from a
client. If a Lotus Notes client attempts to connect to a Domino server on port 1352 and there
is no port 1352 in a LISTEN state, then the Lotus Notes client gets an error that the server is
not responding.

To check your ports, use the NETSTAT *CNN command. All the ports in LISTEN status are
listed at the beginning. See Figure 4-16 for an example of the NETSTAT *CNN command.
Notice the local port 1352 in a LISTEN state. This is a Domino server listening for new
connection requests.

Tip: The NETSTAT *CNN screen also has a column called Idle Time. This column is very
useful when debugging a Domino server hang. Every time a client attempts to connect to a
port in a LISTEN state, it resets the Idle Time. In Figure 4-16, you can see that the idle time
is 1 second.

If you were experiencing a server hang related to a network or DNS problem, you may see
a very large idle time for port 1352. This would tell you that even though a Lotus Notes
client is attempting to connect to the Domino server, it is never making it to the iSeries.
Something in the network is preventing it from getting to the iSeries.

Chapter 4. Tuning Domino performance on the iSeries 201

 Work with TCP/IP Connection Status
System: AS25
Type options, press Enter.
3=Enable debug 4=End 5=Display details 6=Disable debug
8=Display jobs

Remote Remote Local

Opt Address Port Port Idle Time State
* * 10319 014:47:32 Listen
* * 10319 014:47:32 *UDP
* * 1352 000:00:01 Listen
* * smtp 421:02:28 Listen
* * 2050 000:08:05 Listen
10.1.92.18 as-mgtc > 63045 010:21:16 Established
10.1.92.31 ldap 6599 000:00:17 Time-wait
10.1.92.35 as-mgtc > 44078 029:31:45 Established
10.1.132.97 3089 6595 000:01:00 SYN-sent
10.1.132.166 1063 telnet 000:00:00 Established
10.1.132.199 1922 telnet 000:06:24 Established
10.1.132.199 2044 telnet 000:05:14 Established
More...
F3=Exit F5=Refresh F9=Command line F11=Display byte counts F12=Cancel
F15=Subset F22=Display entire field F24=More keys

Figure 4-16 NETSTAT *CNN and port 1352 in LISTEN status

Retransmissions
A retransmission occurs when a data packet (like a TCP packet) must be resent. A
retransmission can occur if the local system does not receive an acknowledgement for a
packet it sent. A retransmission can also occur if the data in the checksum does not equal the
number of bits in the TCP packet.

Retransmissions are not supposed to be common. If you see a lot of retransmissions, then
you are having a problem and it can affect performance.

To identify if Domino is having a problem with retransmissions, you can use the information on
the NETSTAT *CNN screen by doing the following steps:
1. Run the NETSTAT *CNN command to access the data:
NETSTAT *CNN
2. Press the F15 key to display a subset of the data on the Work with TCP/IP Connection
Status screen.
3. Type 1352 on the Local port range: Lower value field and press Enter twice.
See Figure 4-17 for an example of the screen you should now have displayed.
4. Place a 5 in front of a connection and press Enter.
Pick any connection other than the ones in a LISTEN state.
5. Page down and look for the retransmission information as shown in Figure 4-18.
Make note of how many retransmissions this conversation has had.
6. Press the F12 key to return to the Subset of TCP/IP Connections screen and display
another connection. Repeat steps 4 and 5 for several connections.

202 Domino 6 for iSeries Best Practices Guide

If most of the connections have several retransmissions, then you are having a problem and
you should check your network to resolve it.

The retransmission problem could also be related to an issue with checksums. See
“Checksum” on page 590 for more details.

Subset of TCP/IP Connections

System: AS09
Type options, press Enter.
3=Enable debug 4=End 5=Display details 6=Disable debug
8=Display jobs

Remote Remote Local

Opt Address Port Port Idle Time State
* * 1352 000:00:28 Listen
* * 1352 000:02:20 Listen
* * 1352 000:09:43 Listen
* * 1352 000:00:06 Listen
10.1.132.160 1763 1352 000:02:08 Established
10.1.132.161 1764 1352 000:03:08 Established
10.1.132.162 1766 1352 000:03:18 Established
10.1.132.162 1863 1352 000:01:08 Time-wait
10.1.132.163 1883 1352 000:02:06 Established
10.1.132.165 1893 1352 000:02:07 Established
10.1.132.166 1963 1352 000:03:12 Established

Bottom
F3=Exit F5=Refresh F9=Command line F11=Display byte counts F12=Cancel
F15=Subset F22=Display entire field F24=More keys

Figure 4-17 Subset of TCP/IP Connections screen - accessed with F15 from NETSTAT *CNN

Display TCP Connection Status

System: AS09
Retransmission information:
Total retransmissions . . . . . . . . . . . . : 68
Current retransmissions . . . . . . . . . . . : 4
Send window information:
Maximum size . . . . . . . . . . . . . . . . : 65340
Current size . . . . . . . . . . . . . . . . : 65340
Last update . . . . . . . . . . . . . . . . . : 3066131755
Last update acknowledged . . . . . . . . . . : 263459402
Congestion window . . . . . . . . . . . . . . : 65535
Slow start threshold . . . . . . . . . . . . : 64240
Precedence and security:
Precedence . . . . . . . . . . . . . . . . . : 0
Initialization information:
Maximum segment size . . . . . . . . . . . . : 1452
Initial send sequence number . . . . . . . . : 263129149
Initial receive sequence number . . . . . . . : 3066123334

Bottom
Press Enter to continue.
F3=Exit F5=Refresh F6=Print F8=Display jobs F9=Command line
F12=Cancel F14=Display port numbers F24=More keys

Figure 4-18 Retransmission information from the NETSTAT *CNN screen

Chapter 4. Tuning Domino performance on the iSeries 203

 Configure TCP/IP (CFGTCP)
How you configure TCP on your iSeries can affect the performance of the Domino server. In
this section, we discuss two types of configuration settings that can greatly impact the
performance of your Domino server:
򐂰 Interfaces and routes (which is found under menu options 1 and 2 on the Configure
TCP/IP (CFGTCP) screen)
򐂰 Host table and domain information (which is found under menu options 10 and 12 on the
CFGTCP screen).

Interfaces and routes

By default, the iSeries load balances network traffic across any configured network interface
that shares a common route. As a result, if you have multiple adapters, a different adapter
may be used to send data from the machine than the adapter that was used when data came
into the machine. This is normal and can help performance.

Unfortunately, some network switches cannot handle this configuration. Some switches
generate a route table that include the IP address of the host and the MAC address of the
adapter that owns the IP address. When the adapter used for incoming traffic is different from
the adapter used for outgoing traffic, this can confuse the switch and cause it to send out ARP
broadcasts to build a new route table. If this happens often, then you can experience
performance problems related to this.

Use CFGTCP menu options 1 and 2 to determine if you could be experiencing this problem.
1. By looking at the CFGTCP menu option 1, you can identify if your system has multiple
adapters. Menu option 1 is the Work with TCP/IP Interfaces screen. Count the number of
active line descriptions on that screen. To see if a line description/interface is active, press
the F11 key to display the Interface status column. Do not count the *LOOPBACK line.
See Figure 4-19 for an example of a system with multiple adapters (ETHLINE and
ETHLIN2).

Work with TCP/IP Interfaces

System: AS09
Type options, press Enter.
1=Add 2=Change 4=Remove 5=Display 9=Start 10=End

Internet Subnet Line Line

Opt Address Mask Description Type

10.1.92.12 255.255.255.128 ETHLINE *ELAN

10.1.92.14 255.255.255.128 ETHLINE *ELAN
10.1.122.15 255.255.255.128 ETHLIN2 *ELAN
10.1.122.16 255.255.255.128 ETHLIN2 *ELAN
10.1.122.35 255.255.255.128 ETHLIN2 *ELAN
127.0.0.1 255.0.0.0 *LOOPBACK *NONE

Bottom
F3=Exit F5=Refresh F6=Print list F11=Display interface status
F12=Cancel F17=Top F18=Bottom

Figure 4-19 Configured TCP/IP interfaces

204 Domino 6 for iSeries Best Practices Guide

2. By looking at CFGTCP menu option 2, you can identify how many routes your system has
defined and if they are bound to specific interfaces. If each route is bound to a specific
interface, then this problem cannot occur.
If the routes are not bound, then you could experience a performance problem. See
Figure 4-20 for an example of a system that is not configured to use bound routes. Notice
that the Preferred Interface column shows *NONE instead of an IP address. This means
the route is unbound.

Work with TCP/IP Routes

System: AS09
Type options, press Enter.
1=Add 2=Change 4=Remove 5=Display

Route Subnet Next Preferred

Opt Destination Mask Hop Interface

*DFTROUTE *NONE 10.1.92.1 *NONE

*DFTROUTE *NONE 10.1.122.1 *NONE

Bottom
F3=Exit F5=Refresh F6=Print list F11=Display type of service
F12=Cancel F17=Top F18=Bottom

Figure 4-20 Configured TCP/IP routes

For complete information on route binding and the problems it can cause, see “Network
routing - ARP storms” on page 593.

Host table and domain information

A Domino server frequently has to resolve its own name. (When we talk about name
resolution, we are talking about the process of identifying the IP address that corresponds to
a particular Domino server name.) There are two ways a Domino server can resolve its name
on the iSeries. The first way is by looking up the information in the local host table on the
iSeries. The second way is by going to the Domain Name Server (DNS) defined in the iSeries
TCP/IP configuration.

If the Domino server has to go to an external DNS to resolve its name, then it is sending a
packet out on the network and it has to wait for a response to come back on the network. This
takes time and increases the traffic on the network. Thus it is quicker to allow the Domino
server to resolve its name in the local host table. Use menu options 10 and 12 on the
CFGTCP menu to configure this.

Menu option number 10 on the CFGTCP menu is the local host table. Just like a host table on
a PC, this local host table contains a list of names and their corresponding IP addresses. It is
recommended that you list the Domino server name in this table. List both the common name
and the fully qualified TCP/IP name. For an example of how this is defined, see Figure 4-21
and look at the entry for the Domino server called DOMPERF.

Chapter 4. Tuning Domino performance on the iSeries 205

 Work with TCP/IP Host Table Entries
System: AS09
Type options, press Enter.
1=Add 2=Change 4=Remove 5=Display 7=Rename

Internet Host
Opt Address Name

10.1.92.12 DOMSMTP
DOMSMTP.ACME.COM
10.1.92.14 DOMPERF
DOMPERF.ACME.COM
10.1.122.16 DOMCLUS1
DOMCLUS1.ACME.COM
10.1.122.35 AS09
AS09.ACME.COM
127.0.0.1 LOOPBACK
LOCALHOST
Bottom
F3=Exit F5=Refresh F6=Print list F12=Cancel F17=Position to

Figure 4-21 Local host table - CFGTCP option 10

Menu option number 12 on the CFGTCP menu contains information on your domain and
Domain Name Server (DNS). In general, you will get better performance with a Domino
server by making the iSeries check its local host table before doing a DNS query.

To make the iSeries check its local host table before querying the DNS, set the Host name
search priority field to *LOCAL. However, do not set this field to local if you have a DNS
configured on the local iSeries. It will not function correctly. See Figure 4-22 for an example of
an iSeries configured to check its local host table first.

Change TCP/IP Domain (CHGTCPDMN)

Type choices, press Enter.

Host name . . . . . . . . . . . 'AS09'

Domain name . . . . . . . . . . 'ACME.COM'

Domain search list . . . . . . . 'ACME.COM ITSO.ACME.COM'

Host name search priority . . . *LOCAL *REMOTE, *LOCAL, *SAME

Domain name server:
Internet address . . . . . . . '10.1.66.47'
'10.1.100.16'
'10.1.101.16'

Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys

Figure 4-22 Domain information - CFGTCP option 12

206 Domino 6 for iSeries Best Practices Guide

Work with Line Descriptions (WRKLIND)
Communications on the iSeries occurs over lines. When you configure a new line on the
iSeries, you have to set several options. Some of the options you have to configure are the
physical resource that the line will use on the iSeries, the controller for the line, the line speed,
the maximum frame size, and duplex information. We discuss the maximum frame size (also
known as maximum transmission unit or MTU) in this section.

Important: The only comment we make about the Duplex configuration parameter is that
the Duplex setting on the line description must match the Duplex setting on the switch. If
your switch is set to *HALF, do not set the line description to use *FULL Duplex.

The MTU is usually configured at the line description level. To confirm that is true for your
system, check the TCP/IP route (CFGTCP option 2) and TCP/IP interface (CFGTCP
option 1).
1. Access the Configure TCP/IP menu:
CFGTCP
2. Select menu option 2.
3. Use option 5 to display the routes.
4. Check the Maximum transmission unit field.
If the value in that field is *IFC, then you must check the TCP/IP interfaces.
5. Press F12 to get back to the Configure TCP/IP menu.
6. Select menu option 1.
Make note of the active line descriptions on this screen.
7. Use option 5 to display the interfaces.
8. Check the Maximum transmission unit field.
If the value in that field is *LIND, then the MTU size is set at the line description level.

To check the MTU on the line description, enter the Work with Line Descriptions (WRKLIND)
command. Find the line descriptions you wrote down in step 6, place a 5 in front of the line
and press Enter to display its configuration. Look at the Maximum frame size field. This field
shows the MTU size for the line.

A lot of customers configure the MTU size large when using fiber or copper. Since the iSeries
and the lines can handle 8 KB, it is believed that a setting of 8 KB will make conversations
faster. The problem is that most switches will not transfer an 8 KB frame/packet. Most
switches will break the frame up into smaller frames. This takes time. The more frames that
need to be broken up into smaller frames, the more time it takes. This can severely impact
your network performance and thus your Domino performance.

We have found that an MTU of 1496 bytes is a good size for most Domino servers. Consult
your network administrator for more information on MTUs and your switch’s ability to handle
large frames.

Communications Trace and Resets (RST)

Sometimes you suspect a network problem, but you cannot find it. An iSeries
communications trace can help you identifying problems with your network. There are many
informations a communications trace can show you. We are only discussing one of them in
this section.

Chapter 4. Tuning Domino performance on the iSeries 207

 For information on how to read an iSeries communications trace, search for the command
STRCMNTRC in the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Or look at the IBM reference called iSeries TCP/IP Troubleshooting at:

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzaku/rzakumst.pdf

We are discussing communication resets in this section. There is a known problem that can
affect Domino server performance that is identified by resets (RST) in a communications
trace.

There are many reasons why a reset can occur during a TCP/IP conversation - none of the
reasons are good. A reset is always a bad thing and if you are seeing lots of resets in an
iSeries communications trace, you should try to find the underlying problem causing them.

One of the possible underlying problems relates to a concept called a linger value. Linger
refers to how long a socket/session waits to close. The Domino server has a linger value
of 20. The OS/400 will reset (RST) any TCP conversation in a TIMEWAIT state which has not
closed. The default close time for TCP on the iSeries is 120 seconds. Due to this
configuration, when the Domino linger pops after 20 seconds a RST is sent because TCP has
not closed the session. This results in a lot of resets and can affect performance.

To see if you might be experiencing this linger problem, do the following steps:
1. Identify the active lines on your system that Domino could be using:
CFGTCP option 1
2. Start a communications trace against one of the lines. You may have to trace all lines.
STRCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN) MAXSTG(16M) USRDTA(*CALC)
The CFGOBJ parameter is the name of one of the active lines you found in step 1.
3. Let the trace run for a few minutes and then end it using the following command:
ENDCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN)
4. Print the communications trace with the PRTCMNTRC command:
PRTCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN) CODE(*ASCII) SLTCTLD(*ALL) FMTTCP(*YES)
FMTBCD(*YES)
This creates a spooled file called QPCSMPRT.
5. Review the communications trace and search for RST.
You can use the WRKJOB OPTION(*SPLF) command and option 5 to display the
QPCSMPRT file that contains the trace data.
Use the Find field and the F16 key to search the spooled file for RST.
See Figure 4-23 for an example of an RST.
Count the number of times a RST occurs against a Domino conversation. A Domino
conversation can be identified by its ports. A Domino conversation will occur on ports like
1352 - for Lotus Notes clients and the SERVER job, 80 - if running the Domino HTTP job,
25 - if running the Domino SMTP job, etc.
You must use your own judgement to determine if you are seeing too many RST packets.
As an example, if you ran a 5 minute trace and count 60 RST packets, then you should
consider investigating your network configuration to fix this problem.

208 Domino 6 for iSeries Best Practices Guide

 Display Spooled File
File . . . . . : QPCSMPRT Page/Line 13977/42
Control . . . . . Columns 15 - 92
Find . . . . . . RST
+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9..
Data Record Controller Destination Source Frame
Length Timer Name MAC Address MAC Address Format Comma
------ --------------- ---------- ------------ ------------ ------ -----
50 16:46:03.26229 000629EC6099 00D00234FFFC ETHV2 Type
Frame Type : IP DSCP: 0 Length: 40 Proto
Src Addr: 10.1.46.119 Dest Addr: 10.1.92.14
IP Header : 450000287B3640007F063B85090A2E770905048F
IP Options : NONE
TCP . . . : Src Port: 1994,Unassigned Dest Port: 1352,Unassign
SEQ Number: 2605728169 ('9B5041A9'X) ACK Number: 34969
Code Bits: RST Window: 0 TCP O
TCP Header : 07CA00159B5041A9D06E8AE9500400002A9B0000
. . . . . : 000000000000B1E0 0FC0
More...
F3=Exit F12=Cancel F19=Left F20=Right F24=More keys

Figure 4-23 Communications trace and the RST packet

One of the reasons that may be causing the problem of too many RST packets is the linger
issue. To fix the linger issue, change the TCP closed timewait timeout attribute. To change the
TCP closed timewait timeout attribute to a value that will avoid this problem, use the following
command:
CHGTCPA TCPCLOTIMO(18)

Note: There is a PTF available to fix this problem. The APAR number is MA27594. The
related PTF number is MF31068.

You can search the APAR database at

http://www-912.ibm.com/n_dir/nas4apar.nsf/nas4aparhome

for the latest information on this APAR/PTF.

4.1.6 System values

An iSeries system value contains control information for the operation of certain parts of the
system. For example, the system date and time is set using system values. You can change
system values to define the OS/400 working environment. There are several system values
that can affect performance. In this section we discuss those system values.

QTOTJOB and QADLTOTJ

The QTOTJOB and QADLTOTJ system values work together.

The QTOTJOB system value specifies how much auxiliary storage should be allocated for
jobs during the Initial Program Load (IPL). The term jobs, for this system value, includes
active jobs, jobs on a job queue, and jobs having output on an output queue.

The QADLTOTJ specifies the additional number of jobs that need storage allocated when the
initial number of jobs (the system value QTOTJOB) is reached. Auxiliary storage is allocated
whenever the number of jobs in the system exceeds the number for which storage has been
allocated.

Chapter 4. Tuning Domino performance on the iSeries 209

 The QTOTJOB default value is shipped as 30. This is not large enough for any iSeries
running Domino. A change to this system value takes place at the next IPL.

The QADLTOTJ default value is shipped as 10. This setting usually does not need to be
changed. A change to this system value takes effect immediately.

To figure out what the QTOTJOB system value should be set to, use the WRKSYSSTS
command. On the Work with System Status screen, there is a field called Jobs in system. The
value for that field represents the total number of user and system jobs that are currently in
the system. The total includes jobs on job queues waiting to be processed, jobs currently
active, and jobs that have completed running but still have output on output queues to be
produced. Be aware, if you start a multithreaded Domino job like HTTP, the Jobs in system
value will increase by 1. The Jobs in system field on the Work with System Status screen and
the QTOTJOB system value both represent jobs, not threads.

Important: Clear output queues regularly. The OS/400 reserves auxiliary storage for a job
as long as there is at least one spooled output file for that job (even though the job may be
inactive). The more files there are in the output queues, the more jobs you see on the Work
with System Status screen.

The iSeries allows you to schedule cleanup tasks such as deleting spooled files from
output queues using the OS/400 Operational Assistant. It is recommended that you enable
the cleanup features of the OS/400 Operational Assistant. To enable this feature and
configure it, use the Cleanup Tasks menu and option number 1.

Access this menu by issuing the command:

GO CLEANUP

The default deletion interval for spooled files is 7 days. This means that spooled files that
are older than 7 days will be deleted when the night cleanup task runs if you do not change
the defaults.

Setting QTOTJOB
In general, you do not want the number of jobs in the system to be greater than the
QTOTJOB system value. Therefore, monitor the Jobs in system field on the Work with
System Status screen for a few days. Take the greatest value in that field and multiply it by
1.1. This increases the value by 10%. Take the result of this equation and use that as the
value for QTOTJOB.

For instance, if the greatest value you saw in the Jobs in system field was 220, then you
would take 220 times 1.1:
220 x 1.1 = 242

Take the result of that equation and set the QTOTJOB system value to that number:
CHGSYSVAL SYSVAL(QTOTJOB) VALUE(242)

Tip: Use common sense when setting QTOTJOB. If the total number of jobs in the system
is greater than 1000, then a 10% buffer is probably too large. You do not need 100 or more
extra job structures with nothing in them. Use a smaller percentage like 3% - 5%.

Performance implications of QTOTJOB setting

It is important to set the QTOTJOB system value correctly. If you set the value too big, the IPL
can take a long time to complete. If you set the value too small, then you could invoke the
following performance problem:

210 Domino 6 for iSeries Best Practices Guide

If the number of jobs in the system becomes larger than the QTOTJOB system value, then
there can be a system delay. The delay occurs because when the number of jobs in the
system becomes greater than QTOTJOB, then the system must allocate auxiliary storage to
carve out space for the number of jobs in the QADLTOTJ system value.

For example, if you set QTOTJOB to 100 and QADLTOTJ to 10, then when job number 101
wants to start (or is scheduled on a job queue) on your system there is a pause. The pause is
the system allocating auxiliary storage for 10 new job structures. These new job structures
are used for the next 10 jobs that start on the system. Once those 10 job structures are used,
if job number 111 wants to start, then there is another pause while 10 more job structures are
allocated from auxiliary storage. These pauses keep happening as long as the number of jobs
in the system keeps increasing. This is why you have to set QTOTJOB correctly.

QACTJOB and QADLACTJ

The QACTJOB and QADLACTJ system values work together. They are similar to the
QTOTJOB and QADLTOTJ system values.

The QACTJOB system value specifies how much auxiliary storage should be allocated for
active jobs during the Initial Program Load (IPL). The term jobs, for this system value,
includes only active jobs. It does not include jobs on a job queue or jobs having output on an
output queue. Therefore, QTOTJOB should always be larger than QACTJOB.

The QADLACTJ specifies the additional number of jobs that need storage allocated when the
initial number of active jobs (the system value QACTJOB) is reached. Auxiliary storage is
allocated whenever the number of active jobs in the system exceeds the number for which
storage has been allocated.

The QACTJOB default value is shipped as 20. This is not large enough for any iSeries
running Domino. A change to this system value takes place at the next IPL.

The QADLTOTJ default value is shipped as 10. This setting usually does not need to be
changed. A change to this system value takes effect immediately.

To figure out what the QACTJOB system value should be set to, use the WRKACTJOB
command. On the Work with Active Jobs screen, there is a field called Active Jobs. The value
in that field represents the total number of user and system jobs currently active on the
system. These are jobs that have started processing and not yet ended. The jobs numbered
here do not include jobs waiting to run on job queues or jobs that have ended with output on
an output queue. Again, be aware, if you start a multithreaded Domino job like HTTP, the
Active Jobs value will increase by 1. The Active Jobs field on the Work with Active Jobs
screen and the QACTJOB system value both represent jobs, not threads.

Setting QACTJOB
In general, you do not want the number of active jobs in the system to be greater than the
QACTJOB system value. Therefore, monitor the Active Jobs field on the Work with Active
Jobs screen for a few days. Take the greatest value in that field and multiply it by 1.1. This
increases the value by 10%. Take the result of this equation and use that as the value for
QACTJOB.

For instance, if the greatest value you saw in the Active Jobs field was 180, then you would
take 180 times 1.1:
180 x 1.1 = 198

Take the result of that equation and set the QACTJOB system value to that number:
CHGSYSVAL SYSVAL(QACTJOB) VALUE(198)

Chapter 4. Tuning Domino performance on the iSeries 211

 Tip: Use common sense when setting QACTJOB. If the total number of active jobs in the
system is greater than 1000, then a 10% buffer is probably too large. You do not need 100
or more extra job structures with nothing in them. Use a smaller percentage like 3% - 5%.

Performance implications of QACTJOB setting

It is important to set the QACTJOB system value correctly. If you set the value too big, the IPL
can take a long time to complete. If you set the value too small, then you could invoke the
following performance problem:

If the number of active jobs in the system becomes larger than the QACTJOB system value,
then there is a slight system delay. The delay occurs because when the number of active jobs
in the system becomes greater than QACTJOB, then the system must allocate auxiliary
storage to carve out space for the number of jobs in the QADLACTJ system value.

For example, if you set QACTJOB to 80 and QADLTOTJ to 10, then when job number 81
wants to start on your system there is a pause. The pause is the system allocating auxiliary
storage for 10 new job structures. These new job structures are used for the next 10 jobs that
start on the system. Once those 10 job structures are used, if job number 91 wants to start,
then there is another pause while 10 more job structures are allocated from auxiliary storage.
These pauses keep happening as long as the number of jobs in the system keeps increasing.
This is why you have to set QACTJOB correctly.

QMAXACTLVL
The QMAXACTLVL system value sets the number of threads (not jobs) that can compete for
processor resources and main storage at the same time. For all active subsystems, the sum
of all threads running in all storage pools cannot exceed QMAXACTLVL. If a thread cannot be
processed because the activity level has been reached, then the thread is marked ineligible
until another thread reaches a time slice end or goes into a long wait.

Setting QMAXACTLVL
The default for QMAXACTLVL is *NOMAX. This system value should be left at *NOMAX and
the activity level on the system should be controlled at the storage pool level. A change to this
system value takes effect immediately.

QMCHPOOL
The QMCHPOOL system value sets the size of the *MACHINE storage pool. The *MACHINE
pool is storage pool number 1 on the Work with System Status (WRKSYSSTS) screen. The
machine pool does not process work from user jobs. The machine pool processes the work
from the Licensed Internal Code (LIC) and communications data (like TCP/IP).

You must be careful when changing the size of this storage pool because the entire system
performance can be impacted if the pool is too small.

The QMCHPOOL default value is shipped as 20000 KB. A change to this system value takes
effect immediately.

Note: This value can be changed by the iSeries performance adjuster. If you have the
QPFRADJ system value set to 1, 2, or 3 (0 means that the performance adjuster is turned
off), then this system value is dynamically changed by the iSeries. This means that you do
not have to worry about setting this value correctly if you have the performance adjuster
turned on.

212 Domino 6 for iSeries Best Practices Guide

Setting QMCHPOOL
If you do not plan to run with the performance adjuster enabled, then you will have to
manually set the QMCHPOOL system value. To manually set the QMCHPOOL system value,
we offer the following suggestions.

Allow the iSeries to run with the Domino workload for a couple of days. Then pick a busy time
of day and check the Reserved Size column on the Work with System Status screen for the
*MACHINE pool. You can set the QMCHPOOL system value to a value of two times the
reserved size for the *MACHINE pool.

For example:
WRKSYSSTS

Check the Reserved Size column for pool number 1 on the Work with System Status screen.
(See Figure 4-24.)

Notice that the Reserved Size is 579.75 MB:

579.75 MB x 1024 = 593664 KB

Take the Reserved Size times 2:

593664 KB x 2 = 1187328 KB

Set the QMCHPOOL system value to that number.

CHGSYSVAL SYSVAL(QMCHPOOL) VALUE(1187328)

Tip: When changing QMCHPOOL on the green screen, use Kilobytes. When changing
QMCHPOOL from the iSeries Navigator, use Megabytes.

Work with System Status AS09

08/19/03 16:32:01
% CPU used . . . . . . . : 13.5 Auxiliary storage:
% DB capability . . . . : .0 System ASP . . . . . . : 87.74 G
Elapsed time . . . . . . : 00:00:03 % system ASP used . . : 47.4539
Jobs in system . . . . . : 359 Total . . . . . . . . : 87.74 G
% perm addresses . . . . : .007 Current unprotect used : 3552 M
% temp addresses . . . . : .012 Maximum unprotect . . : 3569 M

Type changes (if allowed), press Enter.

System Pool Reserved Max -----DB----- ---Non-DB---

Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 985.77 492.75 +++++ .0 .0 .5 1.5
2 9325.78 1.77 426 .0 .0 .0 .0
3 1853.55 .19 21 .0 .0 .7 .7
4 122.87 .00 6 .0 .0 .0 .0

Bottom
Command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Restart
F11=Display transition data F12=Cancel F24=More keys

Figure 4-24 Setting QMCHPOOL system value based on WRKSYSSTS/Reserved Size value

Chapter 4. Tuning Domino performance on the iSeries 213

 QBASPOOL
The QBASPOOL system value sets the minimum size of the *BASE storage pool. The *BASE
pool is storage pool number 2 on the Work with System Status (WRKSYSSTS) screen. By
default, all Domino servers run in the *BASE pool.

The QBASPOOL system value is set by default to 5% of the main storage with a minimum
value of 2000KB. A change to this system value takes effect immediately.

This system value is very important to Domino if you are running with the iSeries performance
adjustor enabled (QPFRADJ set to 2 or 3) and your Domino servers are running in the default
*BASE storage pool. The QBASPOOL system value is important because the performance
adjuster cannot decrease the *BASE pool to a value less than the QBASPOOL system value.
Therefore, if you set your QBASPOOL system value correctly, then performance adjuster
cannot starve your Domino servers of memory.

How iSeries performance adjuster works

When the performance adjuster is enabled (QPFRADJ system value is set to 2 or 3), it
monitors the jobs running in the different storage pools. If a storage pool needs more memory
for the jobs running in it, then the performance adjuster can increase the size of that storage
pool. When the performance adjuster increases the size of a storage pool, it takes the
required memory from the *BASE pool. So, if the performance adjuster wants to increase the
size of the *INTERACT storage pool by 10 MB, then it decreases the *BASE storage pool by
10 MB. However, if decreasing the *BASE storage pool by 10 MB would make it smaller than
the QBASPOOL, then the performance adjuster cannot increase the size of the *INTERACT
storage pool.

Setting QBASPOOL
To correctly set the QBASPOOL system value on an iSeries where Domino is the main
application and running in the *BASE storage pool do the following steps:
1. Add the NOTES.INI parameter settings for NSF_BUFFER_POOL_SIZE_MB of all Domino
partitions together.
2. Multiply that number by 2.666.
3. Convert that value from MB to KB by multiplying the number by 1024.
4. Set the QBASPOOL system value:
CHGSYSVAL SYSVAL(QBASPOOL) VALUE(xxxxxx)
Where xxxxxx is the number of KB you calculated using the steps listed above.

Note: Use common sense when setting QBASPOOL. If the number you calculated in the
steps listed above is greater then the amount of main storage available outside of the
*MACHINE storage pool on your iSeries, then you cannot set QBASPOOL to that value.
Either decrease the Domino servers NSF_BUFFER_POOL_SIZE_MB or increase the
amount of main storage on your iSeries. If you cannot do either, then just set QBASPOOL
as close to the number you calculated as possible.

QBASACTLVL
The QBASACTLVL system value sets the activity level for the *BASE storage pool. The
*BASE pool is storage pool number 2 on the Work with System Status (WRKSYSSTS)
screen. By default, all Domino servers run in the *BASE pool.

The QBASACTLVL system value is set by default to 6. This value is not large enough for any
iSeries running Domino in the *BASE storage pool. A change to this system value takes effect
immediately.

214 Domino 6 for iSeries Best Practices Guide

 Note: This value is changed by the iSeries performance adjuster. If you have the
QPFRADJ system value set to 1, 2, or 3 (0 means that the performance adjuster is turned
off), then this system value is dynamically changed by the iSeries. This means that you do
not have to worry about setting this value correctly if you have the performance adjuster
turned on.

Setting QBASACTLVL
If you do not intend to enable the iSeries performance adjuster, then here is a general rule of
thumb for setting the QBASACTLVL system value:

Take the number of Domino partitions and multiply that by 120.

So if you have four Domino partitions (4 x 120 = 480), then try setting QBASACTLVL to 480.

Once you set QBASACTLVL, monitor the Work with System Status (WRKSYSSTS) screen
for ineligible jobs in the *BASE storage pool. If you set QBASACTLVL too low, then you can
see jobs going ineligible on this screen. If jobs are going ineligible in the *BASE storage pool,
then increase the QBASACTLVL system value in small increments, like 50.

QPFRADJ
The QPFRADJ system value is the iSeries performance adjuster. This system value specifies
whether the system should adjust values during initial program load (IPL), at regular intervals
for system pool sizes and activity levels, or not make any automatic adjustments.

The QPFRADJ system value is set by default to 2. A change to this system value takes effect
immediately.

The possible values are as follows:

򐂰 0
No automatic performance adjustment is made by the system. The existing values for
system pool sizes and activity levels are used. (Performance adjuster is turned off.)
򐂰 1
Each time you perform an initial program load (IPL), the system examines the machine
configuration information and makes performance adjustments to achieve good utilization
of system resources. (Performance adjuster is enabled.)
򐂰 2
Each time you perform an initial program load (IPL) and periodically thereafter, the system
examines the machine configuration, jobs running on the system, storage requirements,
and so on, and makes performance adjustments to achieve effective utilization of system
resources. (Performance adjuster is enabled.)
򐂰 3
The system periodically examines the machine configuration, jobs running on the system,
storage requirements, and so on, and makes performance adjustments to achieve
effective utilization of system resources. No performance adjustment occurs at IPL.
(Performance adjuster is enabled.)

If you plan to enable performance adjuster on a system where Domino runs, then it is
recommended that you change QPFRADJ to 3.

Chapter 4. Tuning Domino performance on the iSeries 215

 Performance implications of QPFRADJ
Be aware, that enabling the iSeries performance adjuster can expose you to a very specific
performance problem. The problem is caused because the performance adjuster is relatively
slow to react to changes. However, this is the intended way the performance adjuster works. It
should not rush to allocate massive resources into the first spike of activity it detects. If it did,
then it would be spending a lot of system resources just in shifting memory from one storage
pool to another.

Here is a typical scenario that describes this problem:

򐂰 A company sends a lot of e-mails during the business day. The bulk of the workload on the
iSeries is Domino sending mail. While this is happening, the performance adjuster is
shifting resources to provide Domino with what it needs to run properly.
򐂰 At night, the Domino users are not active and the bulk of the workload is now in a different
storage pool with jobs running backups, batch jobs, and other cleanup tasks. The
performance adjuster shifts the resources to this other storage pool so the nighttime tasks
have the resources they need to run.
򐂰 The next morning, the Domino users come back and start trying to connect to the server -
all of them around the same time. At this point, the performance adjuster starts to move
the memory back into the storage pool that Domino runs in, but this takes time (as
mentioned earlier, the performance adjuster is not quick to respond to changes). While the
performance adjuster is moving resources back into the storage pool where Domino runs,
end users may notice slow response times.

There are three different solutions to this problem:

1. You can run each Domino server in its own private pool. The iSeries performance adjuster
will not change the settings for a private pool.
2. If the Domino server runs in the *BASE pool, then use the QBASPOOL system value to
set a minimum for the *BASE pool. The performance adjuster cannot lower the memory in
the *BASE storage pool lower than the QBASPOOL system value.
3. If the Domino server runs in a shared pool, then use the Work with Shared Pools
(WRKSHRPOOL) screen to set a minimum for the shared pool that Domino runs in. (The
settings on this screen are used by the system if QPFRADJ is set to 2 or 3.) This will
guarantee that a minimum amount of memory remains allocated to the shared pool for
Domino.
See Figure 4-25 for an example of the WRKSHRPOOL screen.
Notice that the total main storage for the iSeries is 12288 MB.
In this example, we defined that a single Domino server is running in *SHRPOOL1 and we
do not want that storage pool to get smaller than approximately 800 MB.
Notice that *SHRPOOL1 has a minimum requirement of 6.5% of the total main storage for
the system.
This means that the minimum size that the iSeries performance adjuster can make
*SHRPOOL1 is approximately 800 MB (12288 MB x .065 = 798.72 MB).

216 Domino 6 for iSeries Best Practices Guide

 Work with Shared Pools
System: AS09
Main storage size (M) . : 12288.00

Type changes (if allowed), press Enter.

-----Size %----- -----Faults/Second------

Pool Priority Minimum Maximum Minimum Thread Maximum
*MACHINE 1 6.61 100 10.00 .00 10.00
*BASE 1 3.99 100 5.00 .50 200
*INTERACT 2 1.00 100 10.00 2.00 100
*SPOOL 2 1.00 100 5.00 1.00 100
*SHRPOOL1 2 6.50 100 10.00 2.00 100
*SHRPOOL2 2 1.00 100 10.00 2.00 100
*SHRPOOL3 2 1.00 100 10.00 2.00 100
*SHRPOOL4 2 1.00 100 10.00 2.00 100
*SHRPOOL5 2 1.00 100 10.00 2.00 100
*SHRPOOL6 2 1.00 100 10.00 2.00 100
More...
Command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F11=Display text
F12=Cancel

Figure 4-25 Work with Shared Pools to set the minimum size for a shared storage pool

QDYNPTYADJ and QDYNPTYSCD

The QDYNPTYADJ and QDYNPTYSCD system values work together.

The QDYNPTYSCD system value allows you to turn on and off the dynamic priority
scheduler. The task scheduler uses this value to determine the algorithm for scheduling jobs
running on the system.

The QDYNPTYADJ system value controls whether the run priority of interactive jobs is
dynamically adjusted to maintain high performance of batch jobs processing on iSeries
Server models hardware. This value is only effective on systems that are rated for both
interactive and non-interactive throughput and have dynamic priority scheduling
(QDYNPTYSCD) enabled.

The QDYNPTYSCD system value is shipped with a default of 1 (which is enabled). A change
to this system value takes place at the next IPL.

The QDYNPTYADJ system value is shipped with a default of 1 (which is enabled). A change
to this system value takes place at the next IPL.

It is recommended that you leave these system values enabled. They are designed to help
performance on systems with a lot of batch jobs (like Domino) and few interactive jobs.

QPRCMLTTSK
The QPRCMLTTSK system value allows you to turn on and off the processor multi-tasking
capability if the iSeries supports this feature. If it is enabled, then each physical processor will
act like two separate processors. So a one-way system can act like a two-way with this
feature enabled.

Chapter 4. Tuning Domino performance on the iSeries 217

 The QPRCMLTTSK system value is shipped with a default of 1 (which is enabled). If the
hardware does not support this feature, then the system value will be changed to 0 during the
next IPL (this is also true when you change this value manually but your system does not
support processor multi-tasking). A change to this system value takes effect at the next IPL.

On a Logically Partitioned (LPAR) system, this system value controls the behavior of all
partitions (LPARS). This change can only be made from the primary partition. Make sure that
all configured LPARS can support this feature before turning it on.

4.1.7 Integrated File System (IFS)

The integrated file system (IFS) is a part of OS/400 that supports stream input/output and
storage management similar to personal computer and UNIX operating systems. The
integrated file system is made up of several parts:
򐂰 root (where Domino databases usually reside)
򐂰 QOpenSys (compatible with UNIX open standards like POSIX)
򐂰 QSYS.LIB (libraries and objects from your iSeries)
򐂰 UDFS (User Defined File System - Domino databases can also reside here)
򐂰 QDLS (documents and folders)
򐂰 QOPT (optical file media)
򐂰 And other file systems structures

In each new release of the operating system, commands and features are added to the IFS.
OS/400 V5R2M0 has two new IFS items that relate to Domino on the iSeries.
򐂰 The first new item is a command called Convert Directory (CVTDIR). This command
allows you to change your directory formats from *TYPE1 to *TYPE2. See “Convert
Directory (CVTDIR) command - *TYPE1 versus *TYPE2” on page 218.

Note: Directory format *TYPE2 is not new in OS/400 V5R2M0. The command CVTDIR
is the new item in V5R2M0.

OS/400 V5R1M0 had an API called Convert Directory (QP0FCVT2) which would
convert directory formats from *TYPE1 to *TYPE2. However, this API was only
available by PTF (it was not shipped with the operating system initially). This PTF is part
of CUM Package V05R01M00_GA_010 and higher. Refer to Info APAR II13161 for the
latest PTF numbers.

򐂰 The second new item is an attribute for the Change Attribute (CHGATR) command. The
new attribute is used to configure the main storage option (*MAINSTGOPT) of stream
files. See “Change Attribute (CHGATR) command - main storage options” on page 219.

Convert Directory (CVTDIR) command - *TYPE1 versus *TYPE2

The Convert Directory (CVTDIR) command is new in OS/400 V5R2M0. This command allows
you to change the format of a directory from *TYPE1 to *TYPE2.

The *TYPE2 directory format only applies to the root, QOpenSys, or UDFS sections of the
IFS.

The *TYPE2 directory format provides the following enhancements:

򐂰 Better performance when creating/deleting and saving directories and files.
򐂰 Improved reliability and recoverability after abnormal terminations.

218 Domino 6 for iSeries Best Practices Guide

򐂰 New functionality such as handling up to one million links per object (*TYPE1 could only
handle 32,767 links per object), supporting case renames (for example, changing A to a),
and automatic name sorting in iSeries Navigator.

Important: *TYPE2 requires the names to be valid UTF-16 names. This differs from
*TYPE1, which have UCS2 Level 1 names. For this reason, invalid or duplicate names may
be found during a conversion. When a name is found to be invalid or a duplicate, the name
is changed to a unique, valid, UTF-16 name, and message CPIA08A is sent to the joblog
listing the original name and the new name. Combined characters or invalid surrogate
character pairs contained in a name may cause an object to be renamed. Surrogate
characters and combined characters include characters with umlauts and accented
characters, for example: ÅåÄäÖö.

For more information on this topic, refer to the iSeries Information Center for V5R2M0 at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

There are a few restrictions when running the CVTDIR command:

򐂰 Only directories in root (/) and QOpenSys file systems, and in basic User ASPs can be
converted or estimated.
򐂰 The system must be in a restricted state if the directories in the root (/) or QOpenSys file
systems are being converted.
򐂰 You must have *ALLOBJ authority to use this command.
򐂰 When you have specified OPTION(*CONVERT), the job cannot be canceled. If the
system abnormally ends while processing the conversion, the conversion will complete
during the ensuing IPL.
򐂰 The caller of this API must be able to own several objects that are created by the convert
directory function. In order for this API to run correctly, we recommend that the calling user
profile has Maximum Storage Allowed set to *NOMAX.

There are options with the CVTDIR command to estimate how long it will take to convert all
the files specified. It is suggested that you use the *ESTIMATE option before converting your
files systems so you know about how long the conversion operation will take. It is also
suggested that you save your entire IFS before running the conversion. (This is not because
the CVTDIR command has problems. This is a general recommendation whenever you are
changing large aspects of your iSeries system.)

For complete information on the CVTDIR command and its options, see the iSeries
Information Center for OS/400 V5R2M0 at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Important information for OS/400 V5R3: In OS/400 V5R3, the conversion from the
*TYPE1 to the *TYPE2 directory format occurs automatically, while the system is running.
You cannot use the CVTDIR command anymore to convert. Instead, you can use the
CVTDIR command to monitor the progress of the conversion that is going on in the
background.

Change Attribute (CHGATR) command - main storage options

OS/400 V5R2M0 has a new storage enhancement that applies to Integrated File System
(IFS) stream files like Domino databases. This new enhancement allows you to change the
behavior of how a stream file is accessed. The option is designed to be adjusted based on the
amount of memory (main storage) available to your Domino server. This option can reduce
page faults and improve response times when properly used.

Chapter 4. Tuning Domino performance on the iSeries 219

 Important: This new enhancement only works on *TYPE2 stream files. Please see “How
to determine your file format” on page 222 for information on how to determine the file
format of your Domino files.

To understand this new enhancement, you must understand how data in a stream file is
retrieved from disk when it is accessed by an application like Domino. The iSeries has a
concept called block transfer size. Block transfer size describes the number of bytes that are
paged into memory when a page fault occurs. A page fault occurs when a program tries to
access data that is not currently in memory. The new enhancement allows you to adjust the
block transfer size.

The command used to change the main storage behavior of an IFS stream file is Change
Attributes (CHGATR). The CHGATR command has existed in previous releases of OS/400.
In V5R2M0 there is a new attribute for the CHGATR command called *MAINSTGOPT (Main
Storage Option). The three possible values for *MAINSTGOPT are *NORMAL (which is the
default), *DYNAMIC, and *MINIMIZE.

Note: There is another new attribute for the CHGATR command in OS/400 V5R2M0. That
attribute is called *DISKSTGOPT (Disk Storage Option). The disk storage option is
available to further reduce the amount of DASD used by *TYPE2 stream files. The disk
storage option has the same three possible values: *NORMAL, *DYNAMIC, and
*MINIMIZE.

In general, the disk storage option does not affect performance. However, there are
exceptions. For example, the *MINIMIZE value will use less disk space, but you should
only set this on stream files that are rarely accessed. If you use the *MINIMIZE option on a
file that is frequently accessed, you will negatively impact performance.

*Normal
Use the default main storage option *NORMAL when there is low contention for main storage.
We refer to this kind of environment as a memory rich environment. In a memory rich
environment, performance is optimized by using a larger block transfer size. This option can
help to minimize the number of disk I/O operations.

The *NORMAL main storage option uses a block transfer size of 16 KB.

*Minimize
Use the *MINIMIZE main storage option when there is a limited amount of memory available
for the application which is accessing the stream file. We refer to this kind of environment as
a memory constrained environment. In a memory constrained environment it is appropriate to
only bring into memory the data which the application is sure to use, so a smaller block
transfer size is used.

Note: To identify if you are running Domino in a memory constrained environment, see the
section on Memory in “Work with System Status (WRKSYSSTS)” on page 172.

The *MINIMIZE main storage option uses a block transfer size of 8 KB.

220 Domino 6 for iSeries Best Practices Guide

The *MINIMIZE option also changes other aspects of the stream file and how memory is
used. For instance, when a page fault occurs for a stream file using the *MINIMIZE option,
the data currently in memory is pushed out more aggressively in order to make room for the
incoming data. Also, when the read/write operation needs more than 8 KB, the file system
compensates for the smaller block transfer size by detecting logical page crossings and reads
the correct number of pages into main storage in a single I/O operation. This avoids the two
or more page faults that would otherwise occur and applies to non-sequential I/O operations.

*Dynamic
The *DYNAMIC main storage option attempts to provide the best of both types of memory
environments. In a memory rich environment, the algorithms associated with the *DYNAMIC
option work to behave as though the *NORMAL option was specified. And in cases when
main storage is constrained, the algorithms work to behave as though the *MINIMIZE option
was specified. This option utilizes system tuning information to help it determine whether the
current memory environment is constrained.

The *DYNAMIC main storage option uses a block transfer size of 12 KB.

The *DYNAMIC option only has an effect when the paging option for the storage pool is set to
*CALC. When the storage pool’s paging option is set to *FIXED, then the block transfer size
of 12 KB is still used, but the paging behavior is the same as the *NORMAL option.

Example
Here is an example of the CHGATR command to change a single Domino database:
CHGATR OBJ('/LOTUS/DATA/DOMPERF/mail/bob.nsf') ATR(*MAINSTGOPT) VALUE(*MINIMIZE)

Note: You do not need to end your Domino server before running the CHGATR command
to alter the main storage option of Domino files. It is safe to run this command with the
Domino server active.

Example of the CHGATR command to change all databases in a single Domino subdirectory:
CHGATR OBJ('/LOTUS/DATA/DOMPERF/mail/*') ATR(*MAINSTGOPT) VALUE(*MINIMIZE)

This attribute can also be set from iSeries Navigator. Simply right-click on the stream file you
wish to change and select Properties. In the Properties box, go to the Storage tab as shown
previously in Figure 4-28 on page 224.

The default block transfer size on OS/400 V5R2M0 and previous releases is 16 KB.

Check main storage option using 5250 emulation session

Use the example instructions listed below to check the current main storage option of an
existing IFS stream file via a 5250 emulation session. In this example, we are checking the
main storage option of a Domino mail file called BOB.NSF in the Domino data directory
/LOTUS/DATA/DOMPERF/MAIL:
1. Use the WRKLNK command to access the stream file:
WRKLNK OBJ(‘/LOTUS/DATA/DOMPERF/MAIL/BOB.NSF’)
2. Place an 8 in front of the stream file and press Enter to Display attributes.
3. Page down once to find the Main storage option field. This is the current main storage
option of the stream file as can be seen in Figure 4-26.

Chapter 4. Tuning Domino performance on the iSeries 221

 Display Attributes

Object . . . . . . : /LOTUS/DATA/DOMPERF/mail/BOB.NSF

Last access date/time . . . . . . . . : 08/19/03 15:33:58

Data change date/time . . . . . . . . : 08/19/03 14:29:14
Attribute change date/time . . . . . . : 08/19/03 14:29:14

Size of object data in bytes . . . . . : 621880

Allocated size of object . . . . . . . : 883444
File format . . . . . . . . . . . . . : *TYPE2
Size of extended attributes . . . . . : 0
Storage freed . . . . . . . . . . . . : No
Disk storage option . . . . . . . . . : *NORMAL
Main storage option . . . . . . . . . : *MINIMIZE

Auditing value . . . . . . . . . . . . : *NONE

Object domain . . . . . . . . . . . . : *SYSTEM

More...
Press Enter to continue.

F3=Exit F12=Cancel F22=Display entire field

Figure 4-26 Main Storage Option in the Display Attributes screen

For complete information on the main storage option changes in V5R2M0 and for test results
run against Domino servers with *MINIMIZE, *DYNAMIC, and *NORMAL, see the IBM paper
entitled V5R2 Stream File Performance Enhancements by Dave Johnson and Mike
Nordstrom:
http://www.ibm.com/servers/eserver/iseries/perfmgmt/pdf/ifsperf.pdf

How to determine your file format

If you are running OS/400 V5R2M0, then it is likely that your Domino server is already using
*TYPE2 file formats for your Domino stream files. However, you should confirm this by
checking the attributes of your Domino files.

Note: The *TYPE1 format was the default format for releases prior to V4R4M0. All new
Domino servers created on OS/400 V4R4M0 or higher releases were automatically
created with the *TYPE2 file format. However, if you moved a server with SAV/RST or
upgraded the OS/400 release without changing the Domino server, then the file format for
the stream files may still be *TYPE1.

There a few different ways to check the attributes of stream files.

The fastest way to check your Domino stream files is to use the DSPLNK command:
DSPLNK OBJ('/LOTUS/DATA/DOMPERF/*') OUTPUT(*PRINT) OBJTYPE(*STMF)
DETAIL(*EXTENDED) DSPOPT(*ALL)

This command creates a spooled file called QSYSPRT that can be searched. See
Figure 4-27 to see what the output from this command looks like.

222 Domino 6 for iSeries Best Practices Guide

 Display Spooled File
File . . . . . : QSYSPRT Page/Line 10/1
Control . . . . . Columns 1 - 78
Find . . . . . . File format
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
Display Attributes Page 10
5722SS1 V5R2M0 020719 AS09 08/21/03 15:25:21
Object . . . . . . : /LOTUS/DATA/DOMPERF/admin4.ntf
Type . . . . . . . . . . . . . . . . . : STMF
File ID . . . . . . . . . . . . . . . : X'000000000000000185F7CB9100006D13
Owner . . . . . . . . . . . . . . . . : QNOTES
System object is on . . . . . . . . . : Local
Auxiliary storage pool . . . . . . . . : 1
Object overflowed . . . . . . . . . : No
Coded character set ID . . . . . . . . : 819
Hidden file . . . . . . . . . . . . . : No
PC system file . . . . . . . . . . . . : No
Read only . . . . . . . . . . . . . . : No
Need to archive (PC) . . . . . . . . . : Yes
Need to archive (AS/400) . . . . . . . : Yes
Last access date/time . . . . . . . . : 08/21/03 05:00:24
Data change date/time . . . . . . . . : 08/21/03 05:05:11
Attribute change date/time . . . . . . : 08/21/03 05:05:11
Size of object in bytes . . . . . . . : 1605632
Allocated size of object . . . . . . . : 1835008
File format . . . . . . . . . . . . . : *TYPE2
Size of extended attributes . . . . . : 0

Figure 4-27 DSPLNK output showing the file format of a Domino template

You can also check stream files individually using the Display Attributes option (8) on the
Work with Object Links (WRKLNK) screen. There is no command for the Display Attributes
option, so this must be done one stream file at a time.

The file format can also be found using the iSeries Navigator (see Figure 4-28):
1. Go to the File Systems -> Integrated File System section.
2. Drill down into your Domino data directory.
3. Select a Domino database and right-click.
4. Select Properties.
5. Go to the Storage tab and look at the File Format field.

Chapter 4. Tuning Domino performance on the iSeries 223

 Figure 4-28 Stream file properties in the iSeries Navigator

4.1.8 Authority lookups

If you are using the iSeries tools to analyze your performance data, then you might notice a
lot of authority lookup exceptions. An authority lookup is the process whereby the Licensed
Internal Code (LIC) determines if a particular user profile is authorized to access a specific
object. Each time the iSeries has to do an authority lookup it uses CPU. In the past, authority
lookups could cost significant amounts of CPU. This is no longer true. We have seen cases
where the iSeries was handling thousands of authority lookups a second and the CPU used
by the lookups was less than 1%.

If you run a component report against the performance data you are gathering (see
Chapter 3, “Monitoring Domino performance on the iSeries” on page 121 for information on
how to gather performance data), there is a section that contains information on different
exceptions, such as authority lookup exceptions. Figure 4-29 on page 225 shows an example
of a component report and the exception data. Notice the authority lookup exceptions. While
the numbers seem large, they are probably not generating much CPU.

To run a component report:

1. Access the Performance menu:
GO PERFORM
2. Find the library where you are gathering performance data:
Select menu option 2 to Collect performance data. The third parameter down identifies the
library you are storing performance data in. Write down the library name.
3. Exit the Collect Performance Data screen without changing anything by pressing F12.

224 Domino 6 for iSeries Best Practices Guide

4. Now Print a report by selecting menu option 3.
Type in the library name you found in step 2 at the top of the Print Performance Report
screen and press Enter.
5. Place a 2 for Component report in front of the data you want to look at and press Enter.
6. Press F6 twice to print the entire report.
7. Type in a name for the output on the Specify Report Options screen and press Enter.
This creates a spooled file called QPPTCPTR.
8. To find that spooled file, use the Work with Submitted Jobs (WRKSBMJOB) command:

Display Spooled File

File . . . . . : QPPTCPTR Page/Line 1/29
Control . . . . . Columns 1 - 78
Find . . . . . .
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
-------------------------------------------- Exceptions Per Second -
Itv Binary Decimal Flp Decimal Aut PAG
End Size Overflow Overflow Overflow Data Lookup Fault
----- ------- -------- -------- -------- -------- -------- -------
08:48 .0 .0 .0 .0 .0 1005.6 .
08:50 .0 .0 .0 .0 .0 2878.0 .
08:51 .0 .0 .0 .0 .0 3524.2 .
09:56 .0 .0 .0 .0 .0 2605.4 .
10:32 .0 .0 .0 .0 .0 2716.2 .
10:33 .0 .0 .0 .0 .0 1103.9 .
13:05 .0 .0 .0 .0 .0 1104.5 .
13:07 .0 .0 .0 .0 .0 1131.0 .
13:17 .0 .0 .0 .0 .0 1008.5 .
Component Report
More...
F3=Exit F12=Cancel F19=Left F20=Right F24=More keys

Figure 4-29 Authority Lookup exceptions in a component report

If you decide you want to get to the root cause behind the authority lookups on a system that
is primarily dedicated to Domino, then check the following conditions.

Make sure that all objects used by the Domino server are owned by QNOTES. The best
authority for a user profile to use is *PUBLIC or owner. This is because *PUBLIC and owner
authority information is stored in the object. When private authority is used, the system must
perform an authority lookup which causes an authority lookup exception.

Since most of the objects Domino uses are in the Domino data directory or in the QNOTES
library, those are the two places you should look.

To check ownership in the Domino data directory, use the EDTF command.
1. Find the Domino data directory for your server using the WRKDOMSVR command. Press
F11 until you see a column called Path.
Write down the value in the Path column. That is your Domino data directory.
2. Use the EDTF command to look at ownership.
EDTF STMF('/LOTUS/DATA/DOMPERF')
Where /LOTUS/DATA/DOMPERF is the name of the Domino data directory you
determined in step 1.

Chapter 4. Tuning Domino performance on the iSeries 225

 3. See Figure 4-30 and notice the Owner column.
In almost every case, this should be QNOTES for the objects in the Domino data directory.
(There may be a third party product that requires a different owner for the files related to
that product.)

Directory: /LOTUS/DATA/DOMPERF
Position to : Record : 14 of
New File :
2=Edit 4=Delete File 5=Display 6=Path Size 9=Recursive Delete

Opt Name Size Owner Changed Used

browser.cnf 16K QNOTES 06/19/03 10:16 09/01/03 16:28
busytime.ntf 256K QNOTES 09/05/03 05:05 09/05/03 05:05
canadien.dic 1,152K QNOTES 06/19/03 10:13 07/30/03 20:00
catalog.ntf 1,152K QNOTES 09/05/03 05:05 09/05/03 05:05
cca50.ntf 2,048K QNOTES 09/05/03 05:05 09/05/03 05:05
certlog.ntf 384K QNOTES 09/05/03 05:05 09/05/03 05:05
certpub.ntf 768K QNOTES 09/05/03 05:00 09/05/03 05:00
certreq.ntf 1,280K QNOTES 09/05/03 17:45 09/05/03 17:45
cldbdir4.ntf 512K QNOTES 09/05/03 05:05 09/05/03 05:05
clusta4.ntf 384K QNOTES 09/05/03 05:05 09/05/03 05:05
csrv50.ntf 1,152K QNOTES 09/05/03 05:05 09/05/03 05:05
da50.ntf 640K QNOTES 09/05/03 05:05 09/05/03 05:05
dba4.ntf 384K QNOTES 09/05/03 05:05 09/05/03 05:05
dbdirman.ntf 256K QNOTES 09/05/03 05:05 09/05/03 05:05
More...

F3=Exit F12=Cancel F16=Sort F17=Position to F22=Display entire field

Figure 4-30 Using EDTF to review ownership information

There is no easy way to check the ownership of the objects in the QNOTES library. All of the
commands like WRKOBJOWN will show you what a profile does own, but not what it should
own. To check ownership in the QNOTES library, you can use the Work with Objects
(WRKOBJ) command.
1. Use the Work with Objects command to see all the objects in the QNOTES library:
WRKOBJ OBJ(QNOTES/*ALL) OBJTYPE(*ALL)
2. Use option 5 to display the ownership of each object on the Work with Objects screen.
The Owner field is in the top right of the Display Object Authority screen. See Figure 4-31
and notice that QNOTES is the owner of the object.

226 Domino 6 for iSeries Best Practices Guide

 Display Object Authority

Object . . . . . . . : ADMINP Owner . . . . . . . : QNOTES

Library . . . . . : QNOTES Primary group . . . : *NONE
Object type . . . . : *PGM ASP device . . . . . : *SYSBAS

Object secured by authorization list . . . . . . . . . . . . : *NONE

Object
User Group Authority
QNOTES *ALL
*PUBLIC *EXCLUDE

Bottom
Press Enter to continue.

F3=Exit F11=Display detail object authorities F12=Cancel F17=Top

F18=Bottom
(C) COPYRIGHT IBM CORP. 1980, 2002.

Figure 4-31 Display Object Authority screen and the Owner field

If you confirm or fix the ownership of all the objects in the QNOTES library and the Domino
data directory, but the number of authority lookup exceptions is still higher than you want,
then contact IBM SupportLine for assistance in finding the cause behind the exceptions.

Remember though, this will probably not impact your performance greatly. The newer iSeries
models (7xx, 150, 170, 8xx, 250, and 270) handle thousands of authority lookup exceptions
with very little CPU used and very little impact to performance.

4.2 Domino performance tuning for iSeries

As stated previously, to get the best performance out of your Domino server running on the
iSeries, you have to tune both the iSeries and Domino. This section describes parameters
and configuration options within the Domino environment that can influence the performance
of your Domino server(s).

The topics covered include where to put your transaction logs for best performance, Domino
memory buffers, indexing large mail files and the impact on performance, and tips for tuning
the Domino HTTP job.

4.2.1 Transaction logging

Important: Several papers and books have talked about placing the Domino transaction
logs on separate physical drives for performance reasons. This is not usually true on the
iSeries platform. This section contains information to help you decide where you should
place the Domino transaction logs on the iSeries platform.

Before we discuss transaction logging, we need to discuss storage management on the

iSeries. On an iSeries, disk storage is called auxiliary storage. You may also hear disk
storage referred to as direct access storage device (DASD).

Chapter 4. Tuning Domino performance on the iSeries 227

 Many other computer operating systems require you to take responsibility for how information
is stored on disks. When you create a new file, you must tell the system where to put the file
and how big to make it. You must balance files across different disk units to provide good
system performance. If you discover later that a file needs to be larger, you need to copy it to
a location on a disk that has enough space for the new, larger file. You may need to move
other files to maintain system performance.

The iSeries OS/400 takes responsibility for managing the information in auxiliary storage.
When you create a stream file (for example, a Domino database), an SQL table, or any other
OS/400 object, the system places it in the best location for good performance. In fact, it may
spread the data in the object across multiple disk units. When you add more data to the
object, the system assigns additional space on one or more disk units.

This unique architecture is referred to as single-level storage. It allows main storage, auxiliary
storage, and virtual storage to work together accurately and efficiently on the iSeries. With
single-level storage, applications ask for data by name, not by where the data is located.

An auxiliary storage pool (ASP) is a group of disk units on your iSeries. Conceptually, each
ASP on your system is a separate pool of disk units for single-level storage. The system
spreads data evenly across the disk units within an ASP. There are three types of ASPs:
򐂰 System ASP: By default, that is where every object on the iSeries is placed.
򐂰 User ASP: You must create the user ASP before you can place any objects in it.
򐂰 Independent ASP: This is a relatively new concept to the iSeries. Like a user ASP, you
must create an independent ASP before you can place any data in it. However, unlike a
user ASP, an independent ASP can be dynamically changed to be used with a different
iSeries.

For more information on ASPs, see the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Now that you understand the basics of storage management on the iSeries, we can start to
discuss Domino transaction logging and performance.

Domino transaction logging was a new feature in Domino 5. It was originally touted as a
performance improvement. In general, it does not improve performance. However,
transaction logging is good to implement for other reasons. Transaction logging can decrease
the amount of time it takes to recover after a Domino server crash. It can also increase data
reliability. (Meaning it can help prevent databases from becoming corrupt.) Transaction
logging is also essential for running incremental saves. While transaction logging does not
improve performance on the iSeries, it can negatively impact performance on the iSeries if it
is implemented incorrectly.

There is a great deal of documentation (including technotes and white papers) regarding how
to configure Domino transaction logging. Several of these documentation sources make the
following recommendation:
“The transactional logs must be on a separate physical drive for there to be any
performance improvement.”

On the iSeries, this would translate to placing the transaction logs in a separate user auxiliary
storage pool (ASP).

Go to the following URL:

http://www.ibm.com/software/lotus/support/

228 Domino 6 for iSeries Best Practices Guide

Then search for a white paper called ‘Transaction Logging and How it Operates’ for an
example for these instructions.

What the paper does not say is that this information is only correct for an operating system
that is disk constrained.

When transaction logging is enabled on a server, the amount of I/O increases. This is due to
how transaction logging works. In a disk constrained environment, if you add the additional
I/O overhead from transaction logging, you will negatively impact performance. By placing the
transaction logs on separate physical drives, you do not add the extra I/O overhead to the
disks servicing the Domino server. In an environment that is not disk constrained, this is not
true.

To determine if your iSeries is disk constrained, you need to check how busy your disk units
are on a typical work day. To check your disk units, use the Work with Disk Status
(WRKDSKSTS) command.
1. Run the Work with Disk Status command:
WRKDSKSTS
2. Press the F5 key repeatedly to refresh the statistics.
3. Watch the Elapsed time field in the upper left-hand corner of the screen.
You want an elapsed time of 2 to 20 minutes. It is okay for a unit to be very busy for a
short period of time. If the elapsed time gets larger than 20 minutes, then press F10 to
reset the statistics.
4. Once the Elapsed time is between 2 and 20 minutes, check the % Busy column (the last
column on the right).
– You want the % Busy for all disk units to be below 30%.
– If any disk unit is averaging over 30%, then you are having a load balancing problem.
(See the section entitled “Work with disk status (WRKDSKSTS)” on page 197.)
– If most of the disk units are averaging over 30%, then you are disk constrained.

If your iSeries is disk constrained, you have three options for implementing transaction
logging without adversely affecting performance:
򐂰 One option is to decrease the workload on the iSeries and thus lower the disk % Busy.
Once the disk % Busy is averaging under 30%, you should be able to configure
transaction logging in the ASP where Domino runs without impacting performance.
򐂰 Another option is to add more disks to the ASP where Domino runs and balance the
existing data across the new disk units. Then you should be able to configure transaction
logging in the ASP where Domino runs without impacting performance.
򐂰 The last option is to add more disks to your system and create a user ASP. Place the new
disk units into the new user ASP. Then you can configure the transaction logs to use the
new user ASP and avoid impacting performance on the ASP where Domino runs.

The latter two solutions require you to add more disk units. If you simply move existing disk
units into a user ASP for transaction logging, then you are reducing the number of disk units
(arms) to handle I/O for the Domino server and you negatively impact performance.

Chapter 4. Tuning Domino performance on the iSeries 229

 Note: View logging is a new Domino 6 feature that allows transaction logging of view
elements. Its purpose is to give faster access to a database with complex views after
corruption. It does this by preserving the view information in the transaction log and
eliminating the need for a view rebuild. View logging greatly reduces the restart time of
large databases, but this feature comes with some small performance cost. Therefore, it
should not be enabled on all views.

4.2.2 Domino memory management

Domino is an application suite that has its own work and memory management functions that
are a layer on top of the iSeries work and memory management.

We discussed the iSeries work and memory management in “iSeries performance tuning for
Domino” on page 172. This section will discuss three different Domino memory management
values that can be altered by administrators to improve Domino performance and lower CPU:
򐂰 “NSF_BUFFER_POOL_SIZE_MB” on page 230
򐂰 “PercentAvailSysResources” on page 233
򐂰 “Notes_SHARED_DPOOLSIZE” on page 234

NSF_BUFFER_POOL_SIZE_MB
NSF_BUFFER_POOL_SIZE_MB is a NOTES.INI parameter that allows an administrator to
specify the maximum size of the NSF Buffer pool. The NSF Buffer pool handles I/O transfers
between the Notes Index Facility (NIF) and disk storage. If this parameter is not set in the
NOTES.INI, then a Domino Server will allocate 3/8 of the memory (up to a default maximum
of 748 MB) available in the storage pool it is running in for the NSF Buffer pool. The 748 MB
maximum is only the default maximum. You can manually set the NSF Buffer pool to a value
larger than 748 MB.

There are two different reasons to want change the NSF Buffer pool size:
1. The NSF Buffer pool is attempting to allocate more memory than the iSeries storage pool
has available.
The iSeries uses single-level store. This means that you can run a Domino server with
NSF_BUFFER_POOL_SIZE_MB set to 300 in a storage pool that is set to 200 MB. In this
case, the iSeries simply treats DASD like memory and paging/faulting will increase to
cover the additional 100 MB the Domino server tried to allocate for memory. The Domino
server will run fine, but the CPU and performance could probably be better.
In general, you should try to make sure the combined total of all the NSF Buffer pools for
all Domino partitions running in a single storage pool does not exceed about 3/8 of the
memory in that storage pool.
For example, a Domino administrator configures two Domino 6 partitions on a single
OS/400 instance. The administrator sets NSF_BUFFER_POOL_SIZE_MB to 500 for each
server. The *BASE storage pool where the Domino partitions are running has 800 MB
allocated. The Domino partitions may try to allocate 1000 MB from a storage pool that only
has 800 MB. The paging/faulting for the *BASE storage pool will be higher than normal to
compensate for this. Both CPU and performance will be negatively impacted. The
administrator should either decrease the NSF_BUFFER_POOL_SIZE_MB for the Domino
partitions or increase the size of the *BASE storage pool.

230 Domino 6 for iSeries Best Practices Guide

2. The NSF Buffer pool is too small for the Domino server.
The Domino server performs better if it reads the indexing information it needs from the
NSF Buffer pool rather than from DASD. If the NSF Buffer pool is too small, then the
Domino server has to read the requested information from DASD rather than the NSF
Buffer pool. This means more I/O operations and higher CPU.

How to set the NSF_BUFFER_POOL_SIZE_MB correctly

To figure out if the NSF_BUFFER_POOL_SIZE_MB is set correctly, use the SHOW STAT
DATABASE command in the Domino console.

Tip: The quickest way to set the NSF_BUFFER_POOL_SIZE_MB correctly is to use the
Database.DbCache.HighWaterMark parameter from the SHOW STAT DATABASE
command. If you divide the value of that parameter by 3, that is a good value for your NSF
Buffer pool. There are two things you need to keep in mind if you use this method to set the
NSF Buffer pool:
򐂰 As stated previously, you still want to make sure that all the Domino partitions in a
single storage pool do not allocate more than about 3/8 of the available memory for that
storage pool.
򐂰 The Database.DbCache.MaxEntries defaults to 3 times the value of the NSF Buffer
pool. So if you set the NSF Buffer pool to 25 MB, then the DbCache is 75 databases.
However, if you average 300 concurrent users and each user opens one database, then
a DbCache of 75 is probably too small.
If you set the NSF_BUFFER_POOL_SIZE_MB parameter under 100, you probably
should set the NSF_DBCACHE_MAXENTRIES parameter to the average number of
concurrent users. (You can use the Domino command SHOW STAT SERVER.USERS.*
to gather information on concurrent users.)

1. You can access the Domino console with the following command:
WRKDOMCSL SERVER(servername)
2. Once you are in the Domino console, issue the Domino command:
SHOW STAT DATABASE
3. Press the F5 key to refresh the screen and see the output.
4. Press the F6 key to print the output listed on the screen to a spooled file.
The spooled file will be called QSYSPRT
5. Run the SHOW STAT DATABASE command four or five times over the course of one
hour.

Important: You want to evaluate the size of the NSF Buffer pool when the Domino server
is being utilized by the end users, so do not run the SHOW STAT DATABASE command in
the middle of the night or during the weekend. Also make sure that the Domino server has
been running for at least two hours before using the output from that command.

You do not have to enable Platform Statistics to get this data.

Chapter 4. Tuning Domino performance on the iSeries 231

 Here is a list of the parameters to pay attention to from the SHOW STAT DATABASE
command:
򐂰 Database.Database.BufferPool.Maximum.Megabytes
This value should match the value set in NSF_BUFFER_POOL_SIZE_MB. This is the
maximum size that the NSF Buffer pool can be.
򐂰 Database.Database.BufferPool.Peak.Megabytes
This value displays the peak amount of memory allocated to the NSF Buffer pool so far.
This value is reset every time the Domino server ends.
򐂰 Database.Database.BufferPool.PerCentReadsInBuffer
This value displays the percentage of requests that could be read from NSF Buffer pool.
Remember, reading from the buffer is faster and uses less resources than reading from
DASD.
򐂰 Database.DbCache.CurrentEntries
This is the current number of entries in the database cache.
򐂰 Database.DbCache.HighWaterMark
This is the peak number of entries in the database cache since the Domino server started.
򐂰 Database.DbCache.MaxEntries
This is the number of entries that can be cached concurrently in the database cache.

The NSF_BUFFER_POOL_SIZE_MB is too small

򐂰 If Database.Database.BufferPool.Peak.Megabytes equals
Database.Database.BufferPool.Maximum.Megabytes and
Database.DbCache.HighWaterMark equals Database.DbCache.MaxEntries.

OR
򐂰 If Database.Database.BufferPool.PerCentReadsInBuffer is lower than 95% and
Database.DbCache.HighWaterMark is about equal to Database.DbCache.MaxEntries.

In either of these cases, you should consider increasing NSF_BUFFER_POOL_SIZE_MB.

In general, the amount of the increase should not exceed 10% of the current value. After you
increase the NSF Buffer pool, you need to restart the Domino server for the changes to take
effect and review the data again.

Important: Remember, you need to let the Domino server run for at least two hours before
you review this data again.

The NSF_BUFFER_POOL_SIZE_MB is too large

򐂰 If Database.Database.BufferPool.PerCentReadsInBuffer is between 94% and 99%, but
Database.DbCache.MaxEntries is about 40% larger than
Database.DbCache.HighWaterMark.

If this is true, then you can decrease NSF_BUFFER_POOL_SIZE_MB. In general, the

amount of the decrease should not exceed 10%. After you decrease the NSF Buffer pool, you
need to restart the Domino server for the change to take effect and then review the data
again.

232 Domino 6 for iSeries Best Practices Guide

The NSF_BUFFER_POOL_SIZE_MB is just right
򐂰 If Database.DbCache.MaxEntries is larger than Database.DbCache.HighWaterMark, but
only if it is not more than 20% larger.

OR
򐂰 If Database.Database.BufferPool.PerCentReadsInBuffer is between 94% and 99%, but
only if Database.DbCache.MaxEntries is about equal to
Database.DbCache.HighWaterMark.

If this is the case, then you do not have to change the NSF_BUFFER_POOL_SIZE_MB.

PercentAvailSysResources
Domino has a lot of different buffer pools. For example, there is the NSF Buffer pool, the
DPOOL, and the NIF pool. Some of these buffer pools you can control individually - like
NSF_BUFFER_POOL_SIZE_MB controls the NSF Buffer pool.

The NOTES.INI parameter PercentAvailSysResources allows you to control all of the buffer
pools. It does not override any buffer pool values that you set specifically. So if you set both
PercentAvailSysResources and NSF_BUFFER_POOL_SIZE_MB, then the NSF Buffer pool
will take its value from the NSF_BUFFER_POOL_SIZE_MB parameter and not from
PercentAvailSysResources.

By default, each Domino server assumes it has 100 percent of the system’s physical memory
available to it. This means if you have four Domino partitions, all four believe they have 100%
of the main memory. The iSeries allows this configuration to occur. However, it causes the
Domino servers to “steal” memory from each other which increases the paging and faulting
and negatively impacts performance.

PercentAvailSysResources was introduced in Domino 5.0.4 and it still works in Domino 6.

This parameter allows you to assign a percentage of the physical memory to each Domino
server by specifying a value from 2% to 100% which represents an absolute percentage of
the systems’s total physical memory.

Important: On the iSeries, the PercentAvailSysResources memory calculations are based

on the total system main memory size if the Domino server is running in the *BASE pool or
on the actual storage pool memory if the Domino partition is running in a shared or private
pool.

There are no calculations to help you set the PercentAvailSysResources. The most important
thing to remember, is that you do not want your Domino partitions to attempt to allocate more
memory then the iSeries has available. If all of your Domino partitions run in the same
storage pool, then this means that the total of all the Domino partitions
PercentAvailSysResources should not be greater than 100.

Example
A user has four Domino servers configured in a single LPAR. The LPAR has 100 GB of main
memory. The *BASE storage pool has 70 GB of memory and shared storage pool number 5
has 5 GB of memory.

Three of the Domino partitions are configured to run in the *BASE storage pool. The fourth
Domino partition runs in shared storage pool number 5. Two of the Domino partitions running
in the *BASE pool are very busy mail servers. The third Domino partition in the *BASE pool is
a busy administration server. The fourth Domino partition running in shared storage pool
number 5 is a seldom used development server.

Chapter 4. Tuning Domino performance on the iSeries 233

 A starting point for this configuration could be accomplished as follows:
򐂰 Set PercentAvailSysResources to 20 in both of the busy mail servers.
Since they are running in the *BASE storage pool, this means that they are allocating 20%
of the total LPAR main memory. So each Domino server is allocating 20 GB.
򐂰 Set PercentAvailSysResources to 30 for the busy administration server.
Since this Domino partition is also running in the *BASE storage pool, this means that it is
allocating 30% of the total LPAR main memory. So this Domino server is allocating 30 GB
of memory.
򐂰 Set PercentAvailSysResources to 50 for the seldom used development server.
This Domino partition is running in a separate shared storage pool, not the *BASE storage
pool. This means that it is allocating 50% of the memory in the storage pool, not 50% of
the total LPAR main memory. So this Domino server is allocating 2.5 GB of memory.

Notice that if you add all four Domino partitions PercentAvailSysResources values, you end
up with 120. This does not mean you are trying to allocating 120% of the memory on the
system. Remember, the fourth Domino partition was not running in the *BASE storage pool,
so it was only allocating 2.5 GB, not 50 GB.

In this example configuration, the Domino servers are allocating 72.5 GB out of a possible
100 GB.

Once you set the PercentAvailSysResources parameter, you must restart the Domino server
for the change to take effect. Once the change takes effect, you should monitor the Domino
server memory and the iSeries memory to see if you need to alter any parameters further. For
instance, if you notice problems with buffer pools like the DPOOL, you can either change
PercentAvailSysResources or add the parameter Notes_SHARED_DPOOLSIZE to change
the size of the DPOOL.

Notes_SHARED_DPOOLSIZE
The DPOOL is another piece of the Domino memory management puzzle. The DPOOL
memory is predominantly allocated for use as database buffers (to avoid reading from disk).

On the iSeries platform, the default shared DPOOL is 12000000 (which is 11719 KB). The
minimum value is 1000000. Individual Domino functions may override the default value.

On the iSeries, we have found that smaller DPOOL allocation sizes can help performance. It
can reduce the amount of fragmentation inside the DPOOLs. It can also reduce CPU,
because smaller pools mean less time spent searching an particular pool for free space.

You can control this DPOOL memory allocation with either an iSeries environment variable or
a NOTES.INI parameter.
򐂰 Use the iSeries environment variable if you want all the Domino partitions on a single
OS/400 instance to use the same default DPOOL allocation size.
򐂰 Use the NOTES.INI parameter if you want to set an individual Domino partition’s default
DPOOL allocation size without affecting other Domino partitions on the same OS/400
instance.

Both the NOTES.INI parameter and the environment variable are the same:
Notes_SHARED_DPOOLSIZE.

234 Domino 6 for iSeries Best Practices Guide

To set the environment variable, use the following command:
ADDENVVAR ENVVAR('Notes_SHARED_DPOOLSIZE') VALUE(1048576) LEVEL(*SYS)

Important: The environment variable is case sensitive. Enter it exactly as it is listed in this
documentation. Also note, the value for this variable is in bytes.

To set the NOTES.INI parameter, add Notes_SHARED_DPOOLSIZE=1048576 to the

NOTES.INI of the server you want to change.

So, how do you decide if you should change the DPOOL allocation size? And what should
you change the allocation size to?

There is no simple formula or rule to follow. To decide if you should change the DPOOL
allocation size, you must consider the following statistics:
򐂰 What is the % used in each of the existing DPOOLs?
The higher the % used, the better the pool is being utilized. If the pool is being utilized
optimally, then the performance is better. (Optimal utilization would mean lower CPU and
better response times.)
򐂰 How many searches did the Domino server have to make while looking for free space?
The higher the number of searches made, the longer it takes to find free space and the
worse the performance.
򐂰 How many times did the Domino server fail to find free space in a single DPOOL?
Each time the Domino server fails to find free space for an allocation, it must check
another DPOOL. The more DPOOLs that Domino has to search, the longer it takes to find
free space and the worse the performance is.

To look at this information, use the SHOW MEMORY DUMP command in the Domino
console. This command will output information to a stream file about the memory in use on
your active Domino server. When you run this command, it gives you the name of the stream
file it created when it is done dumping the information. See Figure 4-32.

Note: You do not want to look at DPOOL allocation information immediately after starting a
server. Allow the Domino server to run for a couple of business days before reviewing this
information. Do not count holidays or weekends because you want to see how the Domino
server handles DPOOL allocations when the server is actively being used.

Chapter 4. Tuning Domino performance on the iSeries 235

 Work with Domino Console
Server: DOMPERF
Previous subcommands and messages:
Activity Logging: Not Enabled
Server Controller: Not Enabled
Diagnostic Directory: /LOTUS/DATA/DOMPERF/IBM_TECHNICAL_SUPPORT
Console Logging: Not Enabled
Console Log File: /LOTUS/DATA/DOMPERF/IBM_TECHNICAL_SUPPORT/console.log

> SHOW MEMORY DUMP

> SHOW MEMORY DUMP

Memory Available: 2,048 Mbytes

08/25/2003 15:52:58 Created memory dump file '/LOTUS/DATA/DOMPERF/IBM_TECHN

ICAL_SUPPORT/memory_RCHAS09_2003_08_25@15_52_50.dmp'
Enter a Domino subcommand.
===>

F3=Exit F5=Refresh F6=Print F9=Retrieve

F17=Top F18=Bottom F21=Command line

Figure 4-32 Domino console when issuing SHOW MEMORY DUMP command

The summary information contained in the output, shows how much space has been
allocated in each DPOOL and how many times the Domino server searched the DPOOL
looking for free space. See this information in Figure 4-33. It was displayed by using the
EDTF command, option 5 to display the memory dump, and then searching for the phrase
“Summary”.
EDTF STMF('/LOTUS/DATA/DOMPERF/IBM_TECHNICAL_SUPPORT')

236 Domino 6 for iSeries Best Practices Guide

 Browse : dmp
Record : 1202 of 2800 by 18 Column : 1 146 by 131
Control : Summary

...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+....0....+....1....+....2....+....3.
Summary:
# Bytes
1196 35047858 Pool
0 0 Malloc
----------------
1196 35047858 Total

largest P o o l A l l o c a t i o n s Free List Iterations

pool addr size used free total skip search failure success frees total alloc
1 F20789C777001000 11719K 11716K 99% 272b 2402 1576 826 39 787 620 6481 3715
s 2 D9956E99C2001000 256K 11K 4% 0b 564 0 564 0 564 478 1112 564
s 3 C123536C0D001000 256K 12K 4% 0b 571 0 571 0 571 484 1111 571
s 4 E8B1383E58001000 256K 10K 3% 0b 578 0 578 0 578 507 1139 578
s 5 D03F1D10A3001000 256K 11K 4% 0b 580 0 580 0 580 492 1121 580
s 6 F7CD01E2EE001000 256K 13K 4% 0b 565 0 565 0 565 474 1087 565
s 7 DF5AE6B539001000 256K 11K 4% 0b 552 0 552 0 552 463 1066 552
s 8 C6E8CB8784001000 256K 11K 4% 0b 593 0 593 0 593 522 1177 593
s 9 EE76B059CF001000 256K 11K 4% 0b 550 0 550 0 550 467 1060 550
10 E267E950FE001000 11719K 9888K 84% 658K 1011 3 1008 1 1007 745 3593 1731
11 C830F9A843001000 11719K 8715K 74% 2225K 795 1 794 1 793 696 1927 805
12 C4F4AD56AE001000 11719K 4009K 34% 0b 161 0 161 0 161 80 244 161

13 system shared memory pools

47 MB total pools size
33 MB total pools used

70.35% pool utilization

1.22 pools visited per allocation
0.22 pools skipped
1.01 pools searched
1.50 free blocks searched per allocation
1.68 free blocks searched per free

Figure 4-33 Stream file contents from the SHOW MEMORY DUMP command

Notice that the Summary has 12 pools and the average utilization is almost 70%. This is very
good. Also notice the low number of failures when searching for free space. For this example,
you do not have to alter the DPOOL allocation size.

If the utilization was smaller or if the number of failed searches was much higher, then you
might want to lower the DPOOL allocation size using the Notes_SHARED_DPOOLSIZE
parameter. We have found that 1048576 is a good value to lower the DPOOL to.

Once you change the size of the DPOOL allocation, you must restart Domino and gather the
same data (SHOW MEMORY DUMP) for review. (If the first data collection occurred after the
server ran for three days, then the next collection should probably occur after the server runs
for three days.

Chapter 4. Tuning Domino performance on the iSeries 237

4.2.3 Mail file sizes and indexing large Domino databases
The Rochester Domino performance lab ran various tests to determine the effect on
performance of large mail file sizes. Table 4-2 shows some of these test results. They also
looked at the relationship between mail file size, document size, and number of documents in
a mail file, and found that the mail file size has less impact on performance than document
count, when using large mail files and small documents. For example, they compared:
򐂰 A 700 MB mail file and a 100 MB mail file, both with 25 KB documents.
Result: The 700 MB mail file uses three times the CPU as the 100 MB mail file.
򐂰 A 700 MB mail file with 100 KB documents and a 700 MB mail file with 25 KB documents.
Result: The mail file with the 25 KB documents used two times as much CPU as the mail
file with the 100 KB documents.

Table 4-2 Relationship between mail file size, document size, and number of documents
CPU Utilized Mail File Size Average Document Size Document Count

5.2% 100 MB 25 KB 4096

16.0% 700 MB 25 KB 28672

8.0% 700 MB 100 KB 7196

5.0% 100 MB 100 KB 1024

Another finding of these tests is, that in Domino 6.x, the number of documents in the INBOX
affects CPU as much as document count. The greater the number of documents in INBOX,
the higher the impact on CPU at session start. This means, that if you can limit the number of
documents in the INBOX to about 25% of the total documents in the mail file, then you will not
notice a high CPU utilization at session start.

Please keep in mind that these tests were done on a large iSeries system with thousands of
users, so the reported CPU utilization is not accurate for your system. However, the
relationship between the CPU utilization can be ported to your environment.

Details on this benchmarking study can be found in the IBM Redpaper, Sizing Large-Scale
Domino Workloads on iSeries, REDP-3802-00, available at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/redp3802.html

Indexing large Domino databases

The indexer task has been redesigned in Domino 6 and is now much more efficient. The
performance lab and IBM’s own Domino 6 on iSeries installation in Rochester have measured
performance improvements of up to 50% compared to Domino 5.

4.2.4 HTTP tips

The best tip for tuning the Domino 6 HTTP server is to review the code for any applications
that use HTTP. The best HTTP performance improvements come from writing intelligent
applications.

The Domino 6 HTTP server no longer uses the command caching that existed in the
Domino 5 HTTP server. The command cache in Domino 5 was a special cache that cached
complete HTTP responses to NSF requests. This was removed from Domino 6 HTTP
because it was not significantly improving performance and it was occasionally causing
problems because old cached data could be shown rather than new data.

238 Domino 6 for iSeries Best Practices Guide

Consider using the new @SetHTTPHeader function, which allows applications to set HTTP
response headers. Application developers can use this function to set headers that control
browser caching behavior and improve performance.

Likewise, consider using the new Entity tags (ETags) introduced in Domino 6.0.1 for cache
validation. ETags, which were introduced in HTTP/1.1, are server-defined tokens that
uniquely identify multiple instances or versions of the same resource. ETags can significantly
improve server performance by increasing the effectiveness of browser-side caching.

Information on these new items is discussed in the LDD article ‘A Preview of Browser-side
Caching Enhancements’ at:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/89d4c3dd32c1773e8525
6c9300671756?OpenDocument&Highlight=0,http,cache

Also consider using HTTP rules (such as the HTTP response header rules) to improve
performance in your Web applications. Information on HTTP response header rules can be
found in the LDD article ‘Building Web Applications in Domino 6: Browser Caching and
Response Header Rules’ at:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/2aa6ecf8f29501908525
6b9c006fd147?OpenDocument&Highlight=0,http,cache

That said, there are a couple of things you can do to improve the general performance of the
Domino 6 HTTP server.

One of the general performance improvements in the Domino 6 HTTP server is that the HTTP
server uses HTTP 1.1 specifications. HTTP 1.1 supports persistent connections. This means
that once a client and server open an HTTP connection, it remains open until the client or
server specifically requests the connection be closed. While the connection is open, the client
can send multiple (but separate) requests, and the server can respond to them in the order in
which they are received. Clients are also free to send multiple requests without waiting for the
responses, in effect, pipelining the requests. For example, a client may do this when
requesting all graphic images from a particular page. It can also make the requests
sequentially, then listen for responses from the server.

You can enable/disable this functionality in the Domino Directory Server document. The field
is called HTTP persistent connections and it is located under the Internet Protocols ->
HTTP tab. Persistent connections are enabled by default in Domino 6.

Persistent connections are especially useful in the following scenario:

򐂰 The browser opens a connection and retrieves a page containing multiple images.
򐂰 The browser opens a second connection and retrieves images over both connections.
򐂰 The browser closes the second connection and maintains the first connection. The
server/browser closes this connection after a time-out or when the browser goes to
another site.

For clients, persistent connections can make a noticeable difference on slow networks (for
example, 56 KB modems) when rendering a page. On fast networks (especially
100 MB/second), persistent connections aren't as beneficial because the cost of establishing
a connection is very low compared to polling persistent connections.

Another option that can improve the performance of the Domino 6 HTTP server is allowing
your HTTP server to run Web agents concurrently. This can be enabled in the Domino
Directory Server document. The field is called Run web agents concurrently and it is located
under the Internet Protocol -> Domino Web Engine tab.

Chapter 4. Tuning Domino performance on the iSeries 239

 Important: You must understand your Web agents before you enable this option. All of
your Web agents (including Java applications) must be thread safe. If you enable this
option and you have applications that are not thread safe, the results will be unpredictable.
They could include incorrect data being displayed, bad data being written to the database,
or even a Domino server crash.

240 Domino 6 for iSeries Best Practices Guide

 Part 2

Part 2 Managing your

environment
Part 2 of this book describes the various backup and recovery methods that are available for
Domino on iSeries and helps you to determine which backup and recovery strategy is right for
you. Antivirus protection is also covered in Part 2.

© Copyright IBM Corp. 2004. All rights reserved. 241

242 Domino 6 for iSeries Best Practices Guide
 5

Chapter 5. Backup and recovery of

Domino 6 for iSeries: Concepts
The iSeries is a platform where you can run almost every technology or application you can
imagine (Linux, Windows, Domino, WebSphere, you name it!) — and it is very important that
you know your system when planning your server backups. Domino might be “just another”
software solution running on your system, among all the others. Although your server could
be dedicated to run only Domino, it is very common that the Domino server is not the only
solution running on your iSeries system.

What kind of backup strategy will best fit your demands depends on your environment. If you
are already using special backup software, such as Backup, Recovery, and Media Services
for iSeries for your regular system backups, you can take full advantage of it. Or you may
have IBM Tivoli Storage Manager somewhere in your network to back up all kind of data
from different platforms. IBM Tivoli Storage Manager can also be utilized for your Domino
data backups. Or perhaps you don’t have any additional backup software, then you can use
OS/400 native commands.

In this chapter we show you how to develop and plan your backup strategy using either
OS/400 commands and iSeries devices (tapes and save files), or using backup software that
allows for online backups, such as Backup, Recovery, and Media Services for iSeries or IBM
Tivoli Storage Manager for Mail: Data Protection for Lotus Domino for OS/400, Version 5.2.0.

Note: Throughout this book we use the term BRMS for the Backup, Recovery, and Media
Services for iSeries software product. We use the term Data Protection for Domino for the
IBM Tivoli Storage Manager for Mail: Data Protection for Lotus Domino for OS/400,
Version 5.2.0 software.

© Copyright IBM Corp. 2004. All rights reserved. 243

5.1 Domino implementation on the iSeries system
Domino for iSeries takes advantage of the iSeries single-level storage architecture. Domino
databases and programs are spread across all iSeries disk units, along with other iSeries
objects. OS/400 automatically manages the allocation of disk space so that you do not have
to decide which databases to store on which particular disk drive. To back up information from
the iSeries system, you back up logically (by library or directory), not physically (by disk unit).

5.1.1 Domino objects on the iSeries

When you install Domino for iSeries, several new objects are created on your system. These
objects are created in the OS/400 library system as well as in the iSeries integrated file
system (IFS - the IFS provides a directory and file structure similar to PC operating systems
(DOS, Windows) or UNIX operating systems).

The new objects, their purpose, and their locations are as follows:
򐂰 The QNOTES user profile is created and will be used by Domino and Notes applications
running on the iSeries. This user profile is intended for system functions and for integration
with the underlying OS/400 security mechanisms only. Therefore, it does not have a
password and you cannot use the QNOTES user profile to sign on to the iSeries server.

Important: The QNOTES user profile MUST be the owner of all Domino objects.

򐂰 The libraries QNOTES and QUSRNOTES are created:

– OS/400 objects, such as programs (*PGM) and service programs (*SRVPGM), are
placed in the QNOTES library.
– During Domino server configuration, miscellaneous objects, such as the following, will
be placed in the QUSRNOTES library:
• Domino subsystem descriptions (each Domino for iSeries server runs as an
application in its own subsystem).
• All data queues and job queues for the servers.
• The status of the servers (user spaces used by the Work with Domino Servers
(WRKDOMSVR) command to show the status of the Domino servers, such as
*STARTED or *ENDED).
򐂰 If you install the Domino software option 1 (C API Release 6 toolkit), the library
QNOTESAPI is created.

Note: Depending on the Domino options and toolkits you install, more libraries will be
created. Please refer to Table 5-1 on page 246 for a complete list.

򐂰 Basic Domino program files are stored in the /QIBM/ProdData/LOTUS/NOTES directory in

the iSeries integrated file system (IFS).
򐂰 The /QIBM/UserData/LOTUS/NOTES directory is created in the IFS. When you
develop/install programs that will be accessed by Domino, you must add symbolic links to
the programs in this directory.
򐂰 The Domino plug-in for iSeries Navigator is installed in the
/QIBM/ProdData/GUIplugin/LOTUS.DOMINO IFS directory.

244 Domino 6 for iSeries Best Practices Guide

 Attention: These are the objects for Domino 6.0.2 but may change in future releases, so
make sure you carefully read the release notes of each new Domino release.

What does not happen during the installation process is the creation of the data directory for
the Domino server (in comparison to other platforms). The data directory for a Domino 6 for
iSeries server is created when the Domino server is configured (for example, using
CFGDOMSVR). During server configuration you have to specify an individual data directory
for each server. On other platforms, the Domino data directories use the default path of
/Domino/servername/Data, so you can keep this structure on iSeries too, but you are free to
specify any other path. So, if you have multiple Domino servers, you have multiple data
directories.

Each Domino for iSeries server runs as an application in its own subsystem. So if you have
multiple Domino servers you also have multiple subsystem descriptions in QUSRNOTES.

Attention: When setting up a Domino server, do not specify the Domino product directory
(/QIBM/ProdData/...) or the Domino user directory (/QIBM/UserData/...) for the location of
the server’s data directory. If you do so, the setup programs fails with message LNT0102 -
Path specified not valid. For more information see Chapter 3, “Installing Domino on your
iSeries Server” in the Domino 6 for iSeries Help database (I400HELP.NSF).

Tip: You can use the Work with Domino servers menu (accessed with the WRKDOMSVR
command) to display information about your Domino configuration:
򐂰 Subsystem name and status is displayed first.
򐂰 Press F11 once to see the library name and the Domino version.
򐂰 Press F11 again to display the path of your Domino data directories.

Press F3 to exit.

For more information about Domino server configuration, please refer to the redbook IBM
Lotus Domino 6 for iSeries Implementation, SG24-6592.

Domino libraries on the iSeries

OS/400 libraries contain programs for the Domino 6 for iSeries product, programs that are
available for your Domino developers to copy to their workstations, and customization
information such as subsystem descriptions.

Attention: When you install Domino 6 for iSeries, you can select to install the base code
only, or to install the base code and option 1, which is the C API Release 6 toolkit.

Since Domino 6 for iSeries, the C++ APIs and the Lotus Extension Toolkit are no longer
included with the software but are downloadable from the developerWorks : Lotus Web site
(formerly known as Lotus Developer Domain) at:
http://www.lotus.com/ldd/toolkits

For more information on Domino installation, please refer to Chapter 3 of the redbook IBM
Lotus Domino 6 for iSeries Implementation, SG24-6592.

Chapter 5. Backup and recovery of Domino 6 for iSeries: Concepts 245

 Depending on the options and toolkits you install, various libraries will be created on your
system. Table 5-1 lists all possible libraries and their contents.

Table 5-1 Domino libraries

Library Content Additional information

QNOTES Domino code Installed with option *BASE

QNOTESAPI C APIs Installed with option 1

QNOTESCPP C++ APIs Downloadable from developerWorks :

Lotus

QNOTESLSKT LotusScript Extension Toolkit Downloadable from developerWorks :

Lotus

QUSRNOTES Server instance information Customization information such as

subsystem and job descriptions

Domino files in the IFS

Directories in the iSeries integrated file system contain product information, customization
files, and databases. As mentioned earlier, several directories will be created in the IFS.
Table 5-2 lists these IFS directories and their contents.

Table 5-2 Domino directories in the IFS

Directory Content Additional information

/QIBM/ProdData/LOTUS/NOTES Product information

/QIBM/UserData/LOTUS/NOTES Customization information

Domino data directory, for example: Domino data directory Individual directory for each
/Domino/servername/Data server. Is chosen at
configuration time.

/QIBM/ProdData/LOTUS/* Various files for Domino 3rd party Domino software

options (API toolkits), symlinks to *SRVPGMs and
Domino.doc, Sametime *PGMs

/QIBM/UserData/LOTUS/* Various files for Domino 3rd party Domino software

options (API toolkits), symlinks to *SRVPGMs and
Domino.doc, Sametime *PGMs

Important: The library names and IFS paths may change in future releases, so be sure
you carefully read the release notes of each new Domino release.

Other important data

When you set up your Domino environment (that is, register server and users, create
certificates, etc.) you have to decide where to put your ID files. You may also enable SSL to
secure your Web clients’ connection to the Domino server. Be sure that these files are in a
secure place and your backup strategy includes those too.

Attention: We don’t recommend using directory/database links outside your data directory
because these links are not saved when you save your Domino data directory. If you use
directory/database links, be sure you include the correct directory path in your backup
strategy. See “Backup of Domino objects outside of the Domino data directory” on
page 263 for how to back up databases outside your data directory.

246 Domino 6 for iSeries Best Practices Guide

5.1.2 Future release changes
In this version, Domino for iSeries 6.0.2, you need to use separate OS/400 logical partitions
(LPARs) to implement multiple Domino releases on one iSeries system. This is not true
anymore starting with Domino versions 6.0.3 and 6.5. The Domino for iSeries development
team has provided a solution that supports multiple releases of Domino for iSeries on the
same LPAR, also called multi-version capable releases. The multi-version capable releases
are Domino for iSeries 6.0.3 (5733-LD6) and later, and Domino for iSeries 6.5 (5733-L65)
and later. All releases of Domino for iSeries prior to 6.0.3 and 6.5, including all R5 releases,
are not multi-version capable.

In a multi-version capable environment, any number and mix of multi-version capable Domino
versions and releases can be installed at the same time. For example, you can install Domino
6.5, 6.5.1 and 6.0.4 on the same OS/400 partition. These releases and versions do not have
to be installed or removed in any particular order.

Note: Multi-version capable releases and non-multi-version capable releases are not
compatible and therefore cannot be installed on the same OS/400 partition. For example,
you cannot install a Domino 6.0.2 server on the same OS/400 partition as a Domino 6.0.3
or a Domino 6.5 server.

Directory and library changes

The implementation of multi-versioning resulted in changed libraries and directory paths in
the IFS. You must be aware of this change when planning and working on your backup
strategy.

Each multi-version capable Domino release is installed into its own release-dependent library
and directory structure. For example, if you install Domino for iSeries 6.0.3, you install it to
library QDOMINO603. The release also has its own execution path
/QIBM/ProdData/LOTUS/DOMINO603. Domino for iSeries 6.5.0 uses the library
QDOMINO650 and the IFS file directory /QIBM/ProdData/LOTUS/DOMINO650. When
Domino for iSeries 6.0.4 becomes available, it will be installed into library QDOMINO604 and
to the IFS directory /QIBM/ProdData/LOTUS/DOMINO604, and so on.

To make sure that you save all necessary Domino product information of future releases you
must carefully read the release notes of every new release, as the appropriate library and
directory names will be specified there. You must then add these new libraries and IFS
directories to your backup routines.

However, if you already backup all your system data periodically, for example once a week,
using GO SAVE option 22 or equivalent commands, such as SAVLIB LIB(*IBM)
ACCPTH(*YES) for libraries and SAV OBJ(('/QIBM/ProdData')
('/QOpenSys/QIBM/ProdData')) UPDHST(*YES) for directories, the new objects are backed
up automatically.

For more information about the SAVE menu, please refer to 6.4, “OS/400 SAVE menu” on
page 266.

For more information about multi-versioning see the white paper at:
http://www.ibm.com/servers/enable/site/domino/downloads/multiversion.pdf

and the redbook Lotus Domino 6 for iSeries Multi-Versioning Support on the IBM eServer
iSeries Server, SG24-6940.

Chapter 5. Backup and recovery of Domino 6 for iSeries: Concepts 247

5.2 Choosing the right backup strategy
When planning your backup strategy you have to find out what data is vital to your business
and what is not so important. You must be prepared to recover from disasters (such as a site
loss or hardware loss) and from human errors, such as accidentally deleting a critical
database. Even though total disasters are very unlike, you must still be prepared for them.
While iSeries disk units can be protected against data loss due to hardware failures by using
RAID-5 or mirroring, it could happen that multiple disk units fail at the same time. Although
this is a very unlikely scenario, it is not impossible.

To recover from total disaster you must have a valid backup of your entire iSeries server. You
have to be able to restore the whole system from scratch, which means you need to have
backups of your Licensed Internal Code, configuration objects, operating system, licensed
programs, user libraries, folders and integrated file system (IFS). In this chapter we
concentrate on the IFS, where your Domino data resides, but we want to make sure you
understand the importance of full system backups.

As discussed earlier in “Domino objects on the iSeries” on page 244, there are Domino
related program and configuration objects (libraries and IFS directories/files) plus your
Domino data directories (in the IFS). The program objects don’t need to be saved as often as
your user data, although you should take a backup copy of your software product every time
you update to a new release or apply fixes. However the user data is the one changing all the
time and you should take good care of it.

After you have decided what you need to back up, you have to plan when to do it. What is the
size of your backup window? You may have an environment that needs to be up and running
24x7 (for 24 hours each and every day of the week), thus making it impossible to stop the
Domino server(s) for a backup. If so, you need a tool that allows you to back up your Domino
server(s) while they are active (so-called online backup). Or you can have servers running
just during normal office hours, giving you the opportunity to take the server down during the
night for backups, thus having no need for online backups.

Here are some more considerations you need to take into account when planning your
backup strategy:
򐂰 Think about the way you handle your backup media. You may be saving to tapes, save
files or perhaps to another server. Be sure that you also have off-site storage in a safe
place.
򐂰 How long do you need to retain tape cartridges before reusing them for new backups?
򐂰 Are you saving full databases? Or are you planning for incremental backups (saving
changed objects)?
򐂰 How many backup versions do you need?

You should consider activating transaction logging for better Domino data integrity and faster
startups after a server crash, but there is no advantage in transaction logging regarding
Domino backups unless you use BRMS or Data Protection for Domino.

Attention: User ASPs (Auxiliary Storage Pool) or Independent ASPs as well as LPARs
and IBM ClusterProven® are not covered within this book. For more information on these
topics, please refer to the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

248 Domino 6 for iSeries Best Practices Guide

5.2.1 Backup methods
The iSeries offers several alternative methods to back up your business critical information.
These methods include:
򐂰 Using OS/400 save and restore commands
򐂰 Using BRMS
򐂰 Using Data Protection for Domino

In this section we show how you can manage your backups and backup storage and how
BRMS and Data Protection for Domino can help you to keep track of the media which
otherwise may be difficult to maintain.

Using OS/400 save and restore commands

When using OS/400 save and restore commands, you need to make sure that no one (not
even the server itself) is using the data you are backing up. Because Domino database files
tend to change many times during the day (user actions, agents, mail delivery, new records,
etc.) and some Domino databases are always open (such as NAMES.NSF and LOG.NSf) you
have to stop the server before saving the data. This makes sure you have a complete and
valid backup.

See Chapter 6, “Backup and recovery using OS/400 commands” on page 257 for details on
this backup/restore option.

Backup window
If your backup window is not large enough to allow for the traditional Domino backup method
of shutting down the server(s) during backups, consider the following possibilities:
򐂰 Your tape device may be a bottleneck. Consider replacing it with newer, faster technology.
If that is impossible but you have enough disk space, you can take advantage of OS/400
save files. Writing directly to disk is usually much faster than writing to tape. After the
“save-to-disk” is complete, you can restart the Domino server. Then you start the
“save-to-tape” process (backing up the save files), which can take place immediately
afterwards or at a later time, depending on your backup strategy (for example, you may
have other backups writing to tape at the same time you are saving your Domino data to
save files).
򐂰 Use Domino replication or clustering to achieve increased availability as explained in
Domino replication and Domino clustering. You can use Domino clustering just for your
backups or for high availability and workload balancing. Remember that you need extra
disk space and the CPU load may increase when enabling replication or clustering.

Domino replication and Domino clustering

Although Domino replication and Domino clustering can be used in conjunction with any of
the backup methods mentioned, it is especially useful when you need to end your Domino
servers in order to save them using OS/400 save commands.

If 24x7 availability is necessary for your environment, you can reduce the downtime of your
servers by utilizing Domino replication and clustering capabilities. The replicas can exist on
the same system on a partitioned Domino server or on a different server or even a different
platform with a different Domino version. You can consider the following possibilities:
򐂰 Use clustered servers:
Servers in a Domino cluster replicate between each other in real-time to keep data
synchronized. Cluster replication ensures that all changes, whether to databases or to the
cluster membership itself, are immediately passed to the appropriate database on the
clustered server(s).

Chapter 5. Backup and recovery of Domino 6 for iSeries: Concepts 249

 You can take advantage of this function for your backup strategy by replicating (cluster
replication) all important databases to one server and then bringing this server down for
the backup while the other Domino server can still serve your users.
򐂰 Use a dedicated backup server:
With this method, you set up a partitioned Domino server and replicate your databases to
this “backup server”. Then, as part of your backup routines, you will bring this server down
and save the data.

Attention: Remember that neither clustering nor replication protects your data from
human errors, such as deleting a wrong document. After the replication process is done
you will have an exact copy of the database and the document will still be deleted. In
addition, some critical files such as NOTES.INI and ID files, are not replicated.

The iSeries platform is known to be a very scalable and reliable platform but before
implementing partitioned servers please review Chapter 11, “Using the IBM Eserver
Workload Estimator” on page 463 and Chapter 10, “Sizing tips and techniques” on page 455.

More information about Domino clustering and replication can be found in the Lotus Domino
Administration 6 Help database.

Using BRMS
Backup, Recovery, and Media Services for iSeries, 5722-BR1 (BRMS), helps you to
implement a disciplined approach to managing your backups and provides you with an
orderly way to retrieve lost or damaged data. Using BRMS, you can manage your most
critical and complex backups, including online backups of various kinds of Lotus servers,
simply and easily. BRMS uses Lotus APIs for the online backup. You are also able to recover
your system fully in the event of a disaster or complete system failure.

In addition to the backup/restore functionality, BRMS also keeps information of your backup
media from creation to expiration and an inventory list of all your media.

BRMS allows for different types of backups:

򐂰 Complete system backup of your iSeries server:
– You should take complete system backups for disaster recovery every time you load
PTFs, install new software, etc.
– Print out the recovery report and keep it with your media in a secure place.
򐂰 Full online backups of your Domino data
򐂰 Incremental online backups of Domino databases
– This method needs Domino transaction logging (archive style).
– It provides for restore of databases to a certain point in time.
See Chapter 7, “Backup and recovery using BRMS/400” on page 293 for details on BRMS.

Using Data Protection for Domino

IBM Tivoli Storage Manager is a client/server solution which has a central system managing
your storage services (backup, recovery) in a network. Tivoli Storage Manager clients, like
Data Protection for Domino (5698-DPD), connect through the network to the central system
to store or retrieve saved databases. The Tivoli Storage Manager will keep information of
your saved storage. You can schedule automatic backups using either Job Scheduler for
iSeries (part of OS/400) or Advanced Job Scheduler for iSeries (licensed program 5722-JS1).

250 Domino 6 for iSeries Best Practices Guide

 When archive style transaction logging is enabled you can take a full advantage of Data
Protection for Domino. For example, you are able to perform incremental backups and
restore Domino databases to a certain point in time. Data Protection for Domino can handle
archived transaction logs so you can choose the exact time for your restore. Your transaction
logs are managed by the product. More information of the transaction logging please see
“Transaction logging” on page 252.

Be aware that Data Protection for Domino is backing up Domino database files (*.nsf and
*.ntf) and transaction logs only and is not capable to save non-database Domino data, such
as Notes ID files, NOTES.INI or any other system configuration files. Therefore you need to
have other methods to back up the rest of the system. Perhaps you have BRMS or another
backup program installed on your iSeries that you can utilize to take care of your system data;
otherwise use iSeries native commands. Please refer to Chapter 6, “Backup and recovery
using OS/400 commands” on page 257 for more information of using OS/400 commands.See
Chapter 7, “Backup and recovery using BRMS/400” on page 293 for BRMS backups.

See Chapter 8, “Backup and recovery using Tivoli Data Protection for Domino” on page 353.

Important: Do not use online Lotus server backups in place of complete system backups.
Lotus server online backups only back up Lotus server databases. However, it is important
to also back up other important Lotus server and non-Lotus server system data on a
regular basis.

5.2.2 Save and restore comparison

Table 5-3 lists the functions and objects than can be saved and restored using OS/400 save
commands, BRMS/400, and Data Protection for Domino.

Table 5-3 Save/restore comparison

Objects to be saved and restored OS/400 BRMS Data Protection
commands for Domino

Documents in a database yes / noa yes / noa yes / noa

Online point-in-time database no yesb yesb

Individual database, online no yes yes

Individual database, offline yes yes yes

ID files, keyrings yes yes no

Domino program objects yes yes no

Whole IFS yes yes no

Folders yes yes no

Libraries yes yes no

SAVSYS yes yes no

a. You have to restore the whole database to a different directory first and then copy individual
documents.
b. Needs archive style transaction logging.

Chapter 5. Backup and recovery of Domino 6 for iSeries: Concepts 251

5.3 Transaction logging
Since Domino R5, you have been able to improve the data integrity of your Domino servers by
using transaction logging. When transaction logging is enabled, all changes made to a
database are captured and written to the transaction log. This happens after a transaction
has completed. A transaction is a related series of changes made to a database on a server.
For example, opening a new document, adding text, and saving the document is one
transaction. The logged transactions are then written to disk, either when resources are
available or when scheduled.

Transaction logging keeps a sequential record of every data operation. If a database

becomes corrupted, you can “roll back” the database to a point before it was corrupted and
replay changes from the transaction log. So in most situations, you no longer need to run the
FIXUP task to recover databases following a system failure. Excluding FIXUP results in
quicker server restarts, since FIXUP must check every document in each database, while a
transaction log recovery applies or undoes only those transactions not written to disk at the
time of the system failure.

Each Domino Server partition uses its own dedicated transaction log, it consists of one or
more transaction log extents, binary files with a .TXN extension. A log extent is one of the log
files into which the transaction logs are written. Transaction log extent names are in the form
of Sxxxxxxx.TXN, where x represents a seven-digit number that is unique to that server.
Domino fills each extent sequentially before writing data to a new one. The log extent size is
64 MB. The default directory for transaction logs is /logdir in your Domino servers’ data
directory.

When transactions are written to the logs, an undo record and a redo record are usually
committed for each transaction. First an UNDO log record is generated in the event of a
system outage. This is done before a change is written to a database. Before committing a
transaction, a REDO record is also generated. It is used to re-apply a transaction from the
transactional log to the database in the event that it was not written (flushed) to the NSF
before a server outage. Undo and redo records ensure that if a change is half done it will be
fully undone, and if a change was completely done then it will be fully re-done to the NSF.

One exception to this is for attachments. It is important to note that attachments are logged as
redo only, so if the database is recovered using media recovery, you get back the last copy of
the attachment (once they are done, they stay done). If, however, the server crashes with
uncommitted attachment updates, they will not be undone, since an undo record is never
created for them.

New to Domino 6 (ODS 43) compared to Domino R5 (ODS 41) is that views and shared mail
(SCOS - Single Copy Object Store) can now also be logged.

5.3.1 Flushing and hardening

Once changes are written to the transaction log, these changes must also eventually be
hardened to the database. This occurs through a process called flushing.

Databases are cached in memory while they are open (in the UBM, the Unified Buffer
Manager). Writes to the database actually are written to the in-memory copy of the database.
They are then immediately sent to the transaction logs. Later, changes that were made to the
memory-cached version of the database are moved to the actual NSF file, thus updating the
database.

252 Domino 6 for iSeries Best Practices Guide

 There is no fixed interval for this, as the UBM determines when flushing will occur. It is usually
done when server activity is low. The DBIID (Database Instance ID) is used to correlate
updates in the transaction logs and in-memory to the respective database. It is important to
note, however, that usually the information is read and flushed from the in-memory database
rather than from the transaction log. Changes written to transaction logs are only used during
crash recovery.

5.3.2 DBIID
When you enable transaction logging, Domino assigns a unique database instance ID
(DBIID) to each Domino database. When Domino records a transaction in the log, it includes
this DBIID. During recovery, Domino uses the DBIID to match transactions to databases. The
DBIID is stored in the file header, along with the Database ID and Replica ID, although there
is no relation between them.

New DBIIDs
Some database maintenance activities, such as using the COMPACT command with options,
cause Domino to reconstruct the database in a way that old transaction log records are no
longer valid. When this happens, a new DBIID is assigned to the database. Changing the log
path or maximum log size does not change the DBIID.

Domino assigns a new DBIID when:

򐂰 You enable transaction logging for the first time.
򐂰 System logging is disabled, then re-enabled.
򐂰 You run the COMPACT task with an option. The DBIID does not change when running
COMPACT with no switches or COMPACT -b.
򐂰 You run the FIXUP task on corrupted databases (FIXUP -j).
򐂰 You move a Domino database from a logged server to another logged server or from an
unlogged server to a logged server.

Every time a database receives a new DBIID, the following informational message is send to
the Domino console:
08/26/2003 21:22:20 Recovery Manager: Assigning new DBIID for
/Domino/siputest/Data/demo3.nsf (need new backup for media recovery)

After a new DBIID is assigned, all new transactions recorded in the log for that database use
the new DBIID. Therefore, you need to take a new full backup of the database. This full
backup captures the database in its current state with the new DBIID. Then, if you have to
restore the database, Domino applies only the new transactions related to the new DBIID.

The Data Protection for Domino incremental backup feature automatically recognizes a
DBIID change and runs a full backup of the database. For more information see 8.5.3,
“Backup strategies for Domino servers using Data Protection for Domino” on page 381.

It is not possible to automatically include new databases, or databases with a changed DBIID
in BRMS online incremental backups for Domino versions older than Domino 6.0.3 or 6.5.
However, Domino 6.0.3 and Domino 6.5 in addition with BRMS PTFs provide this function.
For additional information on this new feature, please refer to “Troubleshooting” on page 349.

More information about DBIID and COMPACT can be found in the Domino Administrator
Help database.

Chapter 5. Backup and recovery of Domino 6 for iSeries: Concepts 253

5.3.3 Domino server crashes
Domino automatically performs database recovery during the restart of a server after a
system failure or Domino server crash. Transaction logs are played back for databases that
were open during the failure. The Recovery Point is determined for each NSF requiring log
updates, it is the oldest log information that needs to be re-applied to databases. The
databases are restored to the exact moment of the outage, guaranteed to restore any data
from completed transactions. Partial transactions will be undone and rolled back to the last
good state in an effort to avoid corruption in the database. The partial work will be removed
from the database before the restart completes and the database is made available for use.

You should not move databases away from a server or copy them over from another server
before a recovery restart completed. Otherwise, the database may be missing a significant
amount of changes that are only stored in the transaction log and if the database is not found
during the restart, these changes are not restored.

5.3.4 Transaction logging basics

This section provides background information you need to know before enabling transaction
logging on your Domino server(s).

Transaction logging styles

When setting up transaction logging, you can choose between three different styles of
transaction logging. The transaction logging style you should choose depends on the backup
strategy you are implementing:
򐂰 Circular logging: You create a fixed size transaction log (up to 4 GB) for circular logging.
When the log fills up, the Domino server reuses it and overwrites existing data, starting at
the oldest transaction. So the size of the transaction log cannot grow over the fixed
amount. Circular (or linear) logging is a good choice if you are not using BRMS or Data
Protection for Domino as it will improve restarting the Domino server after a failure without
using too much system resources (mainly disk). This is the default logging style.
򐂰 Linear logging: Linear logging is similar to circular logging, except the size of the
transaction log can exceed 4 GB. Use linear logging if you have a busy server with lots of
database changes causing many transactions that need to be written to the log.
򐂰 Archive logging: Use archive logging only if you are using BRMS or Data Protection for
Domino for your backups. Archive style logging automatically creates new log files after
the maximum size is exceeded. Data in existing logs is not overwritten until the backup
program archives them. Archiving means that the backup program has made a backup of
the log and reported it to Domino server. After this, the log extents will be reused.

Attention: Do not enable Domino BRMS incremental save with archive logging
(CFGDOMSVR/CHGDOMSVR) if you are not going to implement incremental backups
because this will cause the creation of extra log files and fill up your disk. More information
on this topic can be found in “When performing full online backups” on page 345.

Transaction log size

As a rule of thumb, the daily log size is usually 3% to 5% of the total size of active databases
on the server. However, every installation is different and therefore needs to determine its
own log size. Factors that influence the size of the transaction logs are:
򐂰 How many transactions occur per day (assuming you back up at least once a day). It is
important to remember that not all transactions come from users. An agent could create
new documents. You may have a program updating databases or the changes may occur
through replication.

254 Domino 6 for iSeries Best Practices Guide

 򐂰 How many databases you have.
򐂰 The amount of documents and how often they change (create, delete, update).

Tip: “Determine Domino data directory size” on page 289 can help you determine the
usage and size of your transaction logs.

Transaction log directory

In the example shown in Figure 5-1 on page 256, we use the default Log path of /LOGDIR
under the Domino data directory.

Although it is highly recommended by Lotus to put the transaction log on a separate disk drive
this is not true for the iSeries platform because of iSeries’ unique single-level storage (ASP)
concept.

Note: For information about transaction logging related performance issues, please refer
to Chapter 4, “Tuning Domino performance on the iSeries” on page 171.

Disabling transaction logging for a specific database

Because transaction logging increases your systems’ CPU utilization and disk storage
requirements, you might want to disable transaction logging for databases that don’t need to
be logged. (According to the IBM Eserver Workload Estimator you should prepare for a
10-24% CPU increase depending on the value specified in the TRANSLOG_Performance
parameter.)

You might have databases that are easily recreated, or that have frequent changes, such as
MAIL.BOX, causing a lot of transactions but with no need to recover them to a certain point in
time.

When you set up transaction logging all Domino R5 and higher databases (ODS 41 and
higher) are automatically logged. Then you disable transaction logging for databases not
requiring it on an individual basis:
򐂰 When creating a new database, choose Disable transaction logging on the Advanced
Databases Options dialog.
򐂰 For an existing database, choose Disable transaction logging on the Database
Properties, Advanced tab.
򐂰 Using the Domino Administrator client, on the Files tab, you select the database, then
Tools -> Database -> Advanced Properties, then select Disable transaction logging.
򐂰 Use COMPACT -t for the database.

5.3.5 Set up transaction logging

To set up transaction logging for BRMS or Data Protection for Domino, you need to configure
for archive style logging. Using the Domino Administrator, open the Server document in edit
mode and set the appropriate transaction log parameters on the Transaction Logging tab as
shown in Figure 5-1.

Chapter 5. Backup and recovery of Domino 6 for iSeries: Concepts 255

 Figure 5-1 Configuring Archive style transaction logging

Notice that there is a little trick when enabling archive style transaction logging. First choose
the circular logging style to be able to enter a maximum log size. Then choose Archived
logging style; you don’t have to save the document between the change.

Attention: The system will not stop creating new log extents if there is no backup program
cleaning the old ones. This might fill up all available disk space and finally crash the
iSeries! For more information, see IBM Lotus TechNote #1088895 at:
http://www.ibm.com/support/docview.wss?rs=0&uid=swg21088895

The next time you start your server, the transaction log is created. The message “Please wait,
creating new transaction logs in directory:” is displayed in the Domino console and a DBIID is
assigned to every database (unless specifically disabled).

Important: You should take a full backup after transaction logging is enabled.

For more information about transaction logging, please refer to the IBM Technical Support
Search site at:
http://www.ibm.com/support/search/index.html
Search for document number 7003410 (Commonly Asked Questions About Transaction
Logging), #7002566 (Knowledge Collection: Transaction Logging on a Domino R5.x Server),
and #7002802 (Transactional Logging and How it Operates).
Some additional information and references can also be found in “Transaction logging” on
page 16.

256 Domino 6 for iSeries Best Practices Guide

 6

Chapter 6. Backup and recovery using

OS/400 commands
In this chapter we show you how to utilize OS/400 save and restore commands and the
iSeries Job Scheduler to run your daily Domino backups. The Job Scheduler is part of the
iSeries operating system, so it is a no-charge product. Without BRMS or Data Protection for
Domino you cannot take online backups, but you can use Domino replication and clustering
capabilities to increase the uptime of your Domino server, as discussed in “Domino replication
and Domino clustering” on page 249.

If you are new to iSeries and your environment allows you to restrict the server usage for
nightly backups, you may find the SAVE menu a good starting point for backing up your
Domino data. If you are an experienced iSeries user or if you have a complex environment,
you can use the examples given in this chapter to create your own CL programs to extend
your existing backup strategy with saving the Domino environment.

Starting with examples of daily backups, we explain how to save your Domino data directory
or individual databases, and how to check what has been saved. We also give you some
information on common problems and a few tips about system management — for example,
how to initialize tapes and create save files, and how to determine disk usage. Then we
explain which other important data needs to be saved to recover your iSeries system in case
of a complete data loss.

We are using both tape devices and iSeries save files. You may find a combination of these
methods also useful for your backup strategy.

© Copyright IBM Corp. 2004. All rights reserved. 257

6.1 What to save and when

Important: DO NOT use OS/400 SAV/RST commands to save or restore Domino

databases while the Domino server is running. This is not supported and could cause
corrupted databases.

If you need the ability to save and restore Domino databases from an active Domino
server, you MUST use Backup, Recovery, and Media Services for iSeries or Data
Protection for Domino. Both tools use Domino APIs to save and restore Domino
databases.

This restriction also includes copying new databases to an active Domino server using
OS/400 commands, like CPY or MOV.

If you need to copy new databases to an active Domino server, you can use Domino
functions. For more information, see “Save databases while Domino server is running” on
page 285.

After you have installed the Domino 6 for iSeries software and configured your Domino
servers, you need to set up the Domino server backup routines. You need to decide what
data is important for your business and how often you need to back it up. Is once a day
enough? Or do you need to schedule additional backups for specific databases or
subdirectories? We assume that you already have a backup plan for the Domino databases
that are critical for your environment. If you don’t have a plan yet, please review 5.2,
“Choosing the right backup strategy” on page 248 which is helpful in determining what data
you need to back up and where it resides.

After all necessary Domino fixes are installed, you should take a backup copy of the Domino
code, that is, the libraries and directories that contain your Domino information. You may
already have a scheduled backup routine that saves all system data periodically, which from
now on also includes Domino. To manually save it, you can use the iSeries SAVE menu or
equivalent commands.

Save your Domino data directory daily. When using iSeries commands, you have to shut
down the server before starting the backup. If you have critical databases that need to be
backed up more often than once a day, but you cannot shut down the Domino server, then it
is helpful to use additional Domino functions. For example, you can manually copy or
replicate Domino databases using the Lotus Notes client. Or set up an additional Domino
server and use it for clustering or scheduled replication of your critical databases. You can
prevent users from accessing the extra server and use it only for backup purposes, or you can
also utilize it for workload balancing. More information on this topic can be found in “Domino
replication and Domino clustering” on page 249.

If your environment allows you to shut down the whole iSeries system for the duration of the
backups, and your backup window is large enough, you can use the OS/400 SAVE menu. You
may find the combination of saving the entire system data (option 21 - Entire system backup)
and All user data backup (option 23) suitable to your environment to completely back up the
entire iSeries. For example, save your user data daily using option 23 and save the entire
system once a month using option 21. In addition, it is highly recommended to run an entire
system save also after system changes/upgrades, such as PTF installation.

To run large unattended backups you must have a tape device that can handle multiple tapes
without user intervention. Remember that the entire system backup can take hours,
depending on the amount of saved data and the tape device being used.

258 Domino 6 for iSeries Best Practices Guide

Don’t forget that by default the Domino server "lives" at night, running maintenance tasks at 1,
2, 3 and 5 o'clock in the morning. So make sure that your backup window is large enough
before running an entire system backup.

Tip: The maintenance tasks may have been customized on your Domino server. In
addition, there may also exist scheduled replications, program documents, etc. during the
night. Therefore you must verify your Domino environment with the Domino administrator
before shutting down the Domino server for the backup.

By default, Domino runs the following tasks at night:

ServerTasksAt1=Catalog,Design
ServerTasksAt2=UpdAll
ServerTasksAt3=Object Info -Full
ServerTasksAt5=Statlog

See 6.4, “OS/400 SAVE menu” on page 266 for more information about saving the entire
system and licensed programs.

Additional information about our environment

We are using a tape device for our backup and restore examples because this is the most
common save media. In addition, we also included a section on using save files (see 6.6,
“Tips and techniques” on page 279). We do not explain every backup or restore procedure for
both methods, but we provide a few examples to give you an understanding of the differences.

We use the parameter OUTPUT(*PRINT) to produce a spool file. This allows you to verify
what exactly was backed up (or not). Please note that by default the printout produces a line
for each object that was saved or restored because it uses *ALL for the INFTYPE parameter
(type of output information). On a large Domino system this listing may be very large. In fact,
it may exceed the maximum size of an allowed printout. As an alternative you might want to
specify OUTPUT(*PRINT) in combination with INFTYPE(*SUMMARY) or INFTYPE(*ERR) to
get either just a summary of how many objects were saved/restored or just a listing of the
objects that failed to save or restore. Use the command Work with All Spooled Files
(WRKSPLF) to find the appropriate spool file.

Most of our examples are based on our test server called “DOMREST”. So whenever we
specify this name (as the server name or in a path), you need to replace it with your Domino
server name.

The following media are used in our examples:

򐂰 Tape device TAP01
򐂰 Save file called WEEKLY1 in library DOMINOSAVE

Please remember to replace these values with your own values.

Chapter 6. Backup and recovery using OS/400 commands 259

 Tip: Backing up to a save file can be much faster than saving to a tape device, depending
on the tape and disk units available.

In our test environment, we saved 800 MB using the rather slow tape device QIC-2GB
(DC) and tape cartridges DC9250. This lasted over 23 minutes compared to less than
4 minutes when using save files.

In a second step, we then saved the save file to tape, and that again took over 23 minutes.
However, we could restart the Domino server immediately after saving the data to the save
file and thus experienced a much shorter downtime.

The disadvantage of this approach is that the save files need extra disk space, so
depending on your system, you may or may not be able to use this approach.

6.1.1 Recommended saving frequency for Domino

This section details the recommended saving frequency for the various Domino objects. The
Domino objects are listed in 5.1.1, “Domino objects on the iSeries” on page 244.

Daily backups
The daily backup routine should include:
򐂰 Domino data directories
򐂰 /QIBM/UserData/LOTUS/* directory
򐂰 QUSRNOTES library

If this is not a new iSeries installation, you probably already have a daily backup routine for
user data. You should verify that the Domino data directory is included in it.

Weekly backups
In addition to the data saved on a daily base, you should save the following data weekly:
򐂰 QNOTES* libraries
򐂰 Entire IFS
End all applications that use integrated file system (IFS) data to avoid object locks.

Attention: If you cannot put your iSeries into restricted state, there may be objects that are
in use and therefore locked at the time of saving. Locked objects will not be saved. Check
the joblog or history log for unsaved objects.

Monthly backups
It is recommended to save the entire iSeries system monthly. This saves everything, including
Domino program objects and user databases.

In addition, save your entire system every time you update the system to a new release or
apply PTFs.

260 Domino 6 for iSeries Best Practices Guide

6.2 Backing up Domino databases
It is recommended to keep all Domino databases within your Domino data directory or one of
its subdirectories. This makes your backup planning much easier and you don’t have to worry
about backing up other directories. It is also less likely that you may forget to save any
Domino databases.

If you are developing and/or using programs that are accessed by a Domino server, you
should also plan to back up the /QIBM/UserData/Lotus directory. This directory contains
customization information such as symbolic links to your applications and information about
partitioned Domino servers. It is updated, for example, when you configure new Domino
servers.

6.2.1 Backup of entire Domino data directory

These are the steps to save a Domino data directory:
1. Sign on to the iSeries using a user profile that has *JOBCTL and *SAVSYS special
authorities.
2. End your Domino server before starting the backup. Do not restart the server until the
save has completed! On any iSeries command line type:
ENDDOMSVR SERVER(domrest)
If you are using the Java Server Controller use:
ENDDOMSVR SERVER(domrest) OPTION(*CNTRLD) JSC(*YES)

Note: Substitute domrest with your server name throughout this example.

Before you continue, you should verify that no jobs related to this Domino server remained
active. If you have only one Domino server on your system, you can use the command:
WRKUSRJOB USER(QNOTES) STATUS(*ACTIVE)
This displays all active jobs running under the QNOTES user profile. Press F5 to refresh
the screen until no more active jobs are shown.
Alternatively, if you have more than one Domino server on your system, type:
WRKDOMSVR
Then press Enter. On the Work with Domino Servers menu, use option 9 (Work server
jobs) for the Domino server you just ended. Refresh the screen with the F5 key until there
are no more active jobs.
3. Use the Save Object (SAV) command to back up the Domino data directory and all
subdirectories.
To use tape device TAP01 type:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
Substitute TAP01 with your tape device (and don’t forget the extension) if necessary.
Using the OUTPUT(*PRINT) parameter gives you a detailed report of the saved objects by
directory.

Chapter 6. Backup and recovery using OS/400 commands 261

 Note: By default, the printout produces a line for each object that was saved (or
restored) because it uses *ALL for the INFTYPE parameter (type of output information).
On a large Domino system this listing may be very large. In fact, it may exceed the
maximum size of an allowed printout.

As an alternative you might want to specify OUTPUT(*PRINT) in combination with

INFTYPE(*SUMMARY) or INFTYPE(*ERR) to get either just a summary of how many
objects were saved or just a listing of the objects that failed to save.

In this case, the above SAV command would be:

SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
INFTYPE(*SUMMARY)

4. After your backup has completed you can restart your Domino server. Type:
STRDOMSVR SERVER(domrest)

Tip: Once the backup is complete you see a message at the bottom of the screen that
states how many objects were saved. If you see a message that says “xxx object not
saved”, you should determine the reason for it. See 6.6, “Tips and techniques” on
page 279 for possible problems.

6.2.2 Backup of individual Domino databases

Important: Always end your Domino server before running OS/400 SAV/RST commands.

This section describes how to back up individual Domino databases or directories in case you
need to make extra backups in addition to your daily Domino data directory saves. For
example, you may want to create a backup copy before making programming changes or
before testing a new agent. Or you may want to make an archive copy at the end of an
accounting period.

To back up individual databases, do the following steps:

1. Sign on with a user profile that has *JOBCTL and *SAVSYS special authorities.
2. End the Domino server before saving (ENDDOMSVR).
3. Use the Save Object (SAV) command to save the databases.

Examples
򐂰 To back up a specific database called CUSTINF.NSF in the Domino data directory
/lotus/data/domrest to tape device TAP01:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest/custinf.nsf')
򐂰 To back up all Domino databases in subdirectory DEPT57 to tape device TAP01, type:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest/dept57/*.nsf')
򐂰 To back up database HRINFO.NSF in the DEPT57 subdirectory, type:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest/dept57/hrinfo.nsf')
򐂰 To back up all databases starting with “HR” in the Domino data directory, type:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest/hr*.nsf')

262 Domino 6 for iSeries Best Practices Guide

 򐂰 To back up a subdirectory and all its contents (no specific file type), for example the
CUSTOMER directory, type:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest/customer')

6.2.3 Backup of mail databases

Your mail files are automatically saved when backing up the Domino directory (including all
subdirectories) but you might need more frequent backups of your mail databases than of
your other Domino data. Or you may have a separate backup server to which you replicate
your Domino mail databases and you don’t want to back up the entire Domino data directory.
Our example uses TAP01 as the save media and /lotus/data/domrest as the Domino data
directory.

Be sure your Domino server is ended before issuing any of the following commands:
򐂰 To back up all Domino files in the mail subdirectory, type:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest/mail/*.nsf')
򐂰 To back up several individual mail files, type:
SAV DEV('/qsys.lib/tap01.devd') OBJ(('/lotus/data/domrest/mail/user1.nsf')
('/lotus/data/domrest/mail/user2.nsf') ('/lotus/data/domrest/mail/user3.nsf'))

Tip: If you need to save or restore databases while the Domino server is running, there are
additional steps involved. For more information, please refer to “Save databases while
Domino server is running” on page 285.

6.2.4 Backup of Domino objects outside of the Domino data directory

Attention: DO NOT place Domino databases outside of the Domino data directory. It may
make your backup planning difficult and, if you need to save the whole IFS, it could take a
long time. This is not a recommended scenario.

In this example we assume that some of your Domino databases may exist outside of the
Domino data directory. You may have directory/database links or other databases stored
somewhere in the IFS. Be aware that this is not a recommended scenario and that it is highly
recommended to store Domino databases only within the Domino data directory.

Known location of Domino databases

If you know where your data is located, you can add the appropriate directory (or directories)
to be backed up together with your Domino data directory, as detailed in the following
example:
1. End the Domino server:
ENDDOMSVR SERVER(DOMREST)
2. Save the Domino data directory and the directory containing your databases. In this
example we save the Domino data directory (/lotus/data/domrest) and the directory
containing the databases outside of the Domino directory (directory /test - located in the
root of the IFS) with all subdirectories to tape device TAP01:
SAV DEV('/qsys.lib/tap01.devd') OBJ(('/lotus/data/domrest') ('/test'))
OUTPUT(*print)

Chapter 6. Backup and recovery using OS/400 commands 263

 Unknown location of Domino databases
If you don’t place the Domino files into one or more defined directories and they can exist
anywhere in the IFS (in either the root directory or the /QOpenSys directory) you need to
either back up the entire IFS, or to first find out where the objects are.

To back up the whole IFS except for the QSYS.LIB file system, the QDLS file system, and
directories that contain static program product information, use the following command:
SAV DEV('/qsys.lib/tap01.devd') OBJ(('/*') ('/qsys.lib' *OMIT) ('/qdls' *OMIT)
('/QIBM/ProdData' *OMIT) ('/QOpenSys/QIBM/ProdData' *OMIT)) OUTPUT(*print)

Or use the SAVE menu options 21 or 22 to run the backup, see “OS/400 SAVE menu” on
page 266 for more information.

You must end the Domino server before running this command. There might be also other
applications that should be ended before running the SAV.

Remember that this can take a long time depending on the size of your IFS and, if your
system is not in a restricted state, there will be objects that are locked and are therefore not
saved. You need to determine whether the save operation was successful or not. You can use
the printed output (parameter OUTPUT(*PRINT)) of the save operation or the joblog or
history log to do this.

It might be difficult to find out in which directories your Domino databases are located. If you
are using database/directory links, you can find their locations from the Domino Directory
(NAMES.NSF). If you don’t have any idea where the objects are, you have to search the
whole iSeries. More information on how to search for Domino objects can be found in “Find
Domino objects on the system” on page 291.

6.3 Incremental backups

OS/400 provides the capability to save only objects that have changed either since a specific
date and time, or since the last save operation. This type of save capability is sometimes
called an incremental backup. You may find this option very useful if you have databases that
do not change very often.

Note: When saving a Domino database, an incremental backup always saves the entire
database, not only changed documents.

.We explain the two most common strategies for incremental backups in this section:
򐂰 Saving changes since the last full backup (cumulative)
򐂰 Saving changes since the last incremental backup

Our examples assume a complete save of the Domino data directory every Sunday and then
incremental saves from Monday to Saturday.

Attention: Incremental backups reduce the backup time, but the restore needs longer
because you have to restore the complete Domino data directory first, then all changed
objects. Depending on your backup strategy and the day you have to recover, you may
need to restore the full backup plus up to six incremental backups.

264 Domino 6 for iSeries Best Practices Guide

6.3.1 Saving changes since the last full backup (cumulative)
With this strategy, you save all Domino databases that have changed since your last full
backup. For example, assume that you save your entire Domino server on Sunday night. On
Monday night, you would then save everything that has changed since the last complete save
on Sunday night. On Tuesday, you again save everything that has changed since the last
complete save on Sunday — and so on, until Sunday night, when you perform the next
complete backup.

The advantage of this strategy is that it makes your recovery simple. You only need to restore
the last full backup and the most recent incremental backup. The disadvantage of this
strategy is that your backups become larger (both in media usage and duration) every day
until your next complete backup.
.

Important: Your Domino servers must be ended before using OS/400 SAV or RST
commands! Do not start the server during backups.

To set up a nightly incremental backup of all databases that have changed since the last full
backup, do the following steps:
1. Set up a full backup to run every Sunday night. Be sure you specify the parameter
UPDHST(*YES) on the SAV command so the system updates the object information with
the date and time of the most recent backup.
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
UPDHST(*YES)
2. On Monday night use the following command:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
CHGPERIOD(*LASTSAVE)
3. On Tuesday night use the same command:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
CHGPERIOD(*LASTSAVE)
4. Run this command every night until Sunday when you perform the next full backup.

Note: By default, the printout produces a line for each object that was saved because it
uses *ALL for the INFTYPE parameter (type of output information). On a large Domino
system this listing may be very large. In fact it may exceed the maximum size of an allowed
printout.

As an alternative you might want to specify OUTPUT(*PRINT) in combination with

INFTYPE(*SUMMARY) or INFTYPE(*ERR) to get either just a summary of how many
objects were saved or just a listing of the objects that failed to save.

6.3.2 Saving changes since the last incremental backup

With this strategy, you save only objects that have changed since the most recent backup.
For example, assume that you save your entire server on Sunday night. On Monday night you
would save everything that has changed since Sunday night. On Tuesday night, you save
everything that has changed since Monday night. On Wednesday night, you save everything
that has changed since Tuesday night, and so on.

Chapter 6. Backup and recovery using OS/400 commands 265

 The advantage of this strategy is that the size of your incremental backups is smaller (both in
media usage and duration). The disadvantage is that recovery is more complex. You first
need to restore the last full backup, then you must restore each incremental backup. This
may take a lot of time depending on which day of the week you need to recover.

To perform a nightly incremental backup of what has changed since the previous incremental
backup, you must adjust the CHGPERIOD parameter for EACH save operation. For example:
1. End your Domino server(s).
2. Perform a complete backup on Sunday, Aug. 24 at 22:00. Be sure you specify the
parameter UPDHST(*YES) on your SAV command so the system updates the object
information with the date and time of the most recent backup.
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
UPDHST(*YES)
3. On Monday, Aug. 25 at 21:00, use the command:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
CHGPERIOD(082403 220000) UPDHST(*YES)
4. On Tuesday, Aug. 26 at 20:00, use the command:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)
CHGPERIOD(082503 210000) UPDHST(*YES)
5. And so on until Sunday when you perform the next full backup. Remember that every time
you run the SAV command you must edit the CHGPERIOD parameter to match the time
and date of the previous backup.

6.4 OS/400 SAVE menu

The OS/400 SAVE menu (accessed by the GO SAVE command) gives you options to save
your entire system, your system data, your user data, or individual OS/400 objects, such as
files, libraries, documents, IFS objects, etc. This is a simple way to make sure you have a
good backup of your entire server, no matter what backup strategy you decide to use. Menu
option 21 (Entire system) is the basis for all save strategies.

We give a short introduction to options 21, 22, and 23 from the SAVE menu in this section.
These options save your entire system, your system data, or your user data.

We do not go into much detail on the OS/400 SAVE menu because its options and how to use
them are very well explained in the iSeries Information Center available on the Web at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm
򐂰 Choose Systems management -> Backup and recovery -> Back up your server ->
Save your server with the GO SAVE command
򐂰 Or choose Systems management -> Backup and recovery -> Backup your server ->
Save your server with the GO SAVE command -> Use GO SAVE: Options 21, 22 and
23

Important: Before performing system backups see the manual Backup and Recovery
Version 5, SC41-5304 at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/sm04/c4153046.pdf

266 Domino 6 for iSeries Best Practices Guide

There are some rare cases when your system needs to be in restricted state, like running the
Save System (SAVSYS) command. This means that no user can sign on and all applications
must be closed. The only active workstation is your system console, which runs under the
controlling subsystem (QCTL or QBASE), all other subsystems are ended.

Performing an entire system backup using SAVE menu option 21 is one of these situations. It
must be started from the system console and the first task that is performed is to end all
active subsystems immediately. This is the reason why you must end your Domino servers
before starting the save procedure. As mentioned before, Domino servers need to be ended
in a controlled manner through the ENDDOMSVR command, do not use the ENDSBS
command to bring down your Domino servers!

Ending Domino servers and applications

To end your Domino servers in a controlled manner if your system needs to be in a restricted
stat, enter one of the following commands:
ENDDOMSVR SERVER(domrest) OPTION(*CNTRLD)

If you are using the Java Server Controller, use the command:
ENDDOMSVR SERVER(MyServer) OPTION(*CNTRLD) JSC(*YES)

Or use the following command on the Domino console:

QUIT

Another easy way to end your Domino server(s) manually is to use the Work with Domino
Servers (WRKDOMSVR) menu option 6.

Before you continue you should verify that no Domino 6 for iSeries related jobs are active any
more. Use the WRKUSRJOB USER(QNOTES) STATUS(*ACTIVE) command to see all
active jobs running under the QNOTES user profile. Press the F5 key to refresh the screen
until no jobs are shown.

You may also have other applications running on your iSeries server which need to be ended
in a certain way, such as Websphere Application Server, so please make sure you properly
shutdown any applications running on your system before continuing.

Attention: Before using SAVE menu options 21, 22 or 23 you must be familiar with your
iSeries environment. Some of the things you need to know are:
򐂰 How to safely end your applications
򐂰 How to use the tape device
򐂰 How to answer QSYSOPR messages
򐂰 Where your iSeries system console is

See Figure 6-1 for an overview of these SAVE menu options, the related commands, and
what objects are saved. If you are already using a CL program to perform your saves, then
this diagram could be helpful to verify that your backup program covers all necessary data.

Chapter 6. Backup and recovery using OS/400 commands 267

 Figure 6-1 SAVE menu options

Type GO SAVE on any iSeries command line and press Enter. Press the PageDown key to
see the second page as shown in Figure 6-2.

268 Domino 6 for iSeries Best Practices Guide

 SAVE Save
System: AS25
Select one of the following:

Save System and User Data

20. Define save system and user data defaults
21. Entire system
22. System data only
23. All user data

Save Document Library Objects

30. All documents, folders, and mail
31. New and changed documents, new folders, all mail
32. Documents and folders
33. Mail only
34. Calendars

More...
Selection or command
===>

F3=Exit F4=Prompt F9=Retrieve F12=Cancel F13=Information Assistant

F16=AS/400 Main menu

Figure 6-2 OS/400 Save menu - Page 2

The following conditions apply to all three options:

򐂰 The system must be in restricted state.
򐂰 You can schedule them to run within the next 24 hours.

Option 21: Entire system

򐂰 This option saves all your iSeries system data, including Domino programs, product files
and databases.
򐂰 It is recommended to save your entire system monthly and after system changes, such as
PTF installation.

To save the entire system you need to put your system into restricted state which means no
users can access the server and all applications must be closed. The backup is the only job
running on your system, so before the backup starts, the command ENDSBS *ALL *IMMED is
automatically executed as explained in the previous section. Therefore you should carefully
schedule your full backup to weekends or other possible time frames - depending on your
environment. The backup may last several hours. The duration depends on your system, the
amount of data that needs to be backed up, and the tape device you are using.

To save the entire iSeries system you must sign on to the system console with a user profile
that has at least *SAVSYS and *JOBCTL special authorities. The QSECOFR user profile has
all the needed authorities but you may use another profile with adequate authorities.

Option 22: System data only

򐂰 This option saves system data only, that is, libraries and directories that contain iSeries
licensed programs, no user data.
򐂰 It is recommended to save your system data weekly.

Chapter 6. Backup and recovery using OS/400 commands 269

 To save just the system data, such as libraries and directories that contain information for
iSeries licensed programs, but no user data (such as your Domino data directory), you can
use SAVE menu option 22, System data only. This will also bring your system to the restricted
state so remember to end your Domino servers first.

Option 23: All user data

򐂰 This option saves user data only, including your Domino data directory, no product data.
򐂰 It is recommended to save your user data daily.

Use this option only if your backup window is large enough, meaning that you can restrict
access to the iSeries server and shutdown all applications for the duration of the backup.

To save all your user data, including your Domino data directory, you can also use the OS/400
SAVE menu. This option is a very easy and safe way to back up all your user data. The
drawback is that your system needs to be in restricted state when running this and depending
on the amount of user data you need to save, this might take a long time. So use this option
only if your backup window is large enough.

6.5 Recovery of Domino for iSeries

As explained before, Domino 6 for iSeries programs and product files reside in libraries in the
QSYS.LIB file system on your iSeries system. Domino databases reside in the integrated file
system (IFS) in a directory path that you specify when configuring your Domino server(s). So
your backup strategy for Domino for iSeries must include backing up both the libraries
(infrequently) and the database directories (frequently).

You may need to recover Domino for a variety of reasons, for example:
򐂰 User or operator error, such as deleting a database or running a month-end procedure
twice
򐂰 Damage to your server, such as fire or flood
򐂰 Hardware problems, such as a disk failure

Attention: The iSeries system provides disk protection options (mirrored protection and
device parity protection) to increase availability and to ensure that a failure of a single disk
unit does not cause loss of data. You can find more information about disk protection in the
manual OS/400 Backup and Recovery, Version 5, SC41-5304 at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/sm04/c4153046.pdf

Sometimes you must recover your entire server. At other times, you must restore a specific
directory or a single database. This section provides general information and step-by-step
instruction for the following situations:
򐂰 Recover an entire iSeries server
򐂰 Recover Domino data directory
򐂰 Recover Domino mail files
򐂰 Recover individual Domino databases
򐂰 Recover changed objects (from an incremental backup)
򐂰 Recover Domino program code
򐂰 Recreate a Domino server configuration

Important: Your Domino server(s) must be ended before using any iSeries SAV or RST
commands! Do not start the server during backup or restore operations.

270 Domino 6 for iSeries Best Practices Guide

6.5.1 Recover an entire iSeries server
If you are faced with a system disaster, such as a site loss or the failure of an unprotected disk
unit, you must restore your entire iSeries system from a backup. Because the iSeries system
is a highly integrated system, you must recover objects in the correct sequence to rebuild the
proper links between objects.

Attention: This is NOT an instruction for disaster recovery! For complete instructions on
performing a full system recovery, see the manual iSeries Backup and Recovery, Version
5, SC41-5304-06 at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/sm04/c4153046.pdf

Start with reading Chapter 4. “Selecting the Right Recovery Strategy” and Appendix D,
“Recovering your server”.

System recovery steps

This is a brief overview of the steps needed to recover from scratch.

You start with installing the Licensed Internal Code from your SAVSYS media. Then you
install the Operating System, also from your SAVSYS media.

After the Operating System is installed, you have to recover the following items, using the
commands specified:
򐂰 User profiles, using RSTUSRPRF
򐂰 Configuration objects, using RSTCFG OBJ(*ALL)
򐂰 All *IBM and user libraries, using RSTLIB SAVLIB(*NONSYS)
򐂰 All folders, using RSTDLO DLO(*ALL) SAVFLR(*ANY)
򐂰 The entire IFS, using command RST OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT))
򐂰 The authorities, using RSTAUT USRPRF(*ALL)

6.5.2 Recover Domino data directory

If you are faced with a problem that requires recovering only your Domino data directory, you
can use the Restore Object (RST) command to reload your Domino directory(ies) from tape.
See the following example:
1. Sign on to your iSeries system using a user profile that has *SAVSYS and *JOBCTL
special authorities and *USE authority to the RST command.
2. End the Domino server, if it is not already ended:
ENDDOMSVR SERVER(<ServerName>)
3. Mount the tape that has the most recent backup copy of the Domino data directory for the
server.
4. Use the RST command to restore your data directory. For example, if your Domino data
directory is /lotus/data/domrest and your tape device is TAP01, use the following
command:
RST DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest')
5. Restart the Domino server:
STRDOMSVR SERVER(<ServerName>)

Chapter 6. Backup and recovery using OS/400 commands 271

6.5.3 Recover Domino mail files
If you need to recover one or more mail databases from your backup media, use the Restore
Object (RST) command. The following is a high level description of the steps needed to do
this:
1. Sign on to your iSeries with a user profile that has *SAVSYS and *JOBCTL special
authorities and *USE authority to the RST command.
2. Stop the Domino server hosting the mail database(s) that you want to recover:
ENDDOMSVR SERVER(<ServerName>)
3. Mount the tape that has the most recent backup of the mail databases.
4. Use the Restore Object (RST) command. For example, to recover all databases to the
MAIL subdirectory from device TAP01, use the following command:
rst dev('/qsys.lib/tap01.devd') obj('/domino/data/mail/*')

Examples
The name of a user's mail database is usually the user's ID (short name). However, the
Domino administrator has the option to use different names for mail database files.
򐂰 To recover a specific user's mail database, such as the mail database for user GNELSON,
use the RST command and specify the database name:
RST DEV('/qsys.lib/tap01.devd') OBJ('/domino/data/mail/gnelson.nsf')
򐂰 You can specify more than one file on the RST command. To recover the mail databases
for GNELSON, LSMITH, and JPETERS, use the following command:
RST DEV('/qsys.lib/tap01.devd') OBJ(('/domino/data/mail/gnelson.nsf')
('/domino/data/mail/lsmith.nsf') ('/domino/data/mail/jpeters.nsf'))

6.5.4 Recover individual Domino databases

You might need to recover a specific Domino database or a group of databases. Use the
Restore Object (RST) command. The following is an example of the steps for recovering all
files to the HRDPT subdirectory:
1. Sign on to your iSeries using a user profile that has *SAVSYS and *JOBCTL special
authorities and *USE authority to the RST command.
2. Stop the Domino server that contains the databases you want to recover.
ENDDOMSVR SERVER(<ServerName>)
3. Mount the tape that has the most recent backup of the mail databases.
4. Use the Restore Object (RST) command. So, to recover all databases to the HRDPT
subdirectory from device TAP01, use this command:
RST DEV('/qsys.lib/tap01.devd') OBJ('/domino/data/hrdpt/*.nsf')

Examples
Substitute your server’s data directory for /DOMINO/DATA and your tape device or save file
name for TAP01 in the following examples.
򐂰 To recover the database called HRINFO to the HRDPT subdirectory (folder), use this
command:
RST DEV('/qsys.lib/tap01.devd') OBJ('/domino/data/hrdpt/hrinfo.nsf')
򐂰 To recover all Domino databases to the CUSTSVC subdirectory, use this command:
rst dev('/qsys.lib/tap01.devd') obj('/domino/data/custsvc/*.nsf')

272 Domino 6 for iSeries Best Practices Guide

 򐂰 To recover all Domino databases which names begin with “INV” to the main data directory
of your server, use this command:
rst dev('/qsys.lib/tap01.devd') obj('/domino/data/inv*.nsf')

6.5.5 Recover changed objects (from an incremental backup)

To reduce the length of your backup window, your backup strategy might be to back up only
changed objects from your Domino server during the business week as explained in 6.3,
“Incremental backups” on page 264.

Note: When a database has not changed since the last full backup, or between
incremental backups, it is not saved on any following incremental backup. The database is
only saved after it has changed again or when a full backup is run.

Remember, there are two possible incremental backup strategies:

򐂰 Saving changes since the last full backup (cumulative)
򐂰 Saving changes since the last incremental backup

Depending on the backup strategy that was used, there are differences in how you need: to
restore your Domino data:
򐂰 Restore full Domino data directory or entire subdirectory (such as the mail directory):
– From a cumulative backup:
When you used this strategy, you must first restore the last full backup, then the latest
backup that contains the changed objects. See “Recover Domino data directory from a
cumulative backup” on page 274 and “Recover all changed objects to a specific
Domino subdirectory” on page 275 for instructions.
– From an incremental backup:
When you used this strategy, you first need to restore the last full backup, then you
must restore each incremental backup up to the day you need to recover. See
“Recover Domino directory from a daily incremental backup” on page 274 and
“Recover all changed objects to a specific Domino subdirectory” on page 275 for
instructions.
򐂰 Restore a single Domino database:
When performing an incremental backup you always save the full Domino database and
not only changed documents. So an incremental backup of a database contains the
complete database with the latest changes. Therefore, it does not matter which
incremental backup strategy was used, you always restore the most recent backup of the
database. The difference is which tape you need to use for the restore operation:
– If the database has not changed since the last full backup, you need to restore the
database from the full backup (because this is actually the most recent backup of the
database).
– If the last change was on Tuesday, then the most recent backup of that database is on
the Tuesday tapes. So if you need to restore the database on Friday, then you restore
the database from the Tuesday tapes.
See “Recover a specific Domino database from an incremental backup” on page 275 for
instructions.

So when you need to recover data from an incremental backup, you must first determine the
recovery sequence and the location of the needed copy (or copies) of each database, based
on your backup strategy.

Chapter 6. Backup and recovery using OS/400 commands 273

 Recover Domino data directory from a cumulative backup
Use these instructions if your incremental backup strategy is cumulative. This means that
every night you back up everything that has changed since the last complete backup.

To recover your entire Domino data directory, do the following steps:

1. Sign on to your iSeries using a user profile that has *JOBCTL and *SAVSYS special
authorities and *USE authority to the RST command.
2. Stop the Domino server to ensure that no one is using the databases:
ENDDOMSVR SERVER(<ServerName>)
3. Locate the tapes from your most recent complete backup. Mount the correct tape in the
tape unit.
4. Then use the Restore Object (RST) command as follows:
rst dev('/qsys.lib/tap01.devd') obj('/domino/data/<ServerName>') OUTPUT(*print)

Note: By default, the printout produces a line for each object that was restored because
it uses *ALL for the INFTYPE parameter (type of output information). On a large
Domino system this listing may be very large. In fact it may exceed the maximum size of
an allowed printout.

As an alternative, you might want to specify OUTPUT(*PRINT) in combination with

INFTYPE(*SUMMARY) or INFTYPE(*ERR) to get either just a summary of how many
objects were restored or just a listing of the objects that failed to restore.

5. Locate and mount your most recent backup tapes (containing the changed objects).
6. To recover all the changed objects on the tape (everything that has changed since your full
backup), use the following command:
rst dev('/qsys.lib/tap01.devd') obj('/domino/data/<ServerName>') OUTPUT(*print)

Recover Domino directory from a daily incremental backup

Assume that every night you back up only objects that have changed since the previous
backup. To restore the entire Domino directory, do the following steps:
1. Sign on to your iSeries using a user profile that has *JOBCTL and *SAVSYS special
authorities and *USE authority to the RST command.
2. Stop the Domino server:
ENDDOMSVR SERVER(<ServerName>)
3. Locate the tapes from your most recent complete backup. For example, if you run your last
complete backup on Sunday, use that tape. Mount the correct tape in the tape unit.
4. To recover the entire Domino data directory, use the Restore Object (RST) command:
RST DEV('/qsys.lib/tap01.devd') OBJ('/domino/data/<ServerName>') OUTPUT(*print)
5. Locate and mount your first incremental backup tape(s) file containing the changed
objects. For example, if you performed a full backup on Sunday night, locate your backup
media from Monday night.
6. To recover all the changed objects (everything that has changed since the previous night)
use the following command:
RST DEV('/qsys.lib/tap01.devd') OBJ('/domino/data/<ServerName>') OUTPUT(*print)
7. Repeat steps 5 and 6 for each incremental backup until your directory is current. For
example, if you are restoring the data on Thursday, you still need to recover the backups
from Tuesday and Wednesday.

274 Domino 6 for iSeries Best Practices Guide

 This may take some time, because you first have to restore the complete backup from
Sunday, then unmount the tape and mount the Monday tape, restore the data, unmount the
tape, mount the Tuesday tape, restore, unmount the tape, mount the Wednesday tape,
restore the data, unmount the tape, etc.

Recover all changed objects to a specific Domino subdirectory

To recover all Domino databases in the CUSTSVC subdirectory, you use the same approach
as when recovering the entire Domino data directory. You only need to change the directory
path. Do the following steps:
1. Sign on to your iSeries using a user profile that has *JOBCTL and *SAVSYS special
authorities and *USE authority to the RST command.
2. Stop the Domino server:
ENDDOMSVR SERVER(<ServerName>)
3. Locate the tapes from your most recent complete backup. Mount the correct tape in the
tape unit.
4. To recover the entire CUSTSVC subdirectory from your last full backup using the TAP01
device, use the following command:
RST DEV('/qsys.lib/tap01.devd') OBJ('/domino/data/<ServerName>/custsvc')
OUTPUT(*print)
5. If your incremental backup tapes are cumulative, mount your most recent incremental
backup tape. Use the same restore command as used in step 4 again to recover the
changes.
Otherwise, if you save changes since the last incremental backup, you need to repeat step
4 for each incremental backup. Start with the oldest tape and work forward. More details
can be found in “Recover Domino directory from a daily incremental backup” on page 274.

Recover a specific Domino database from an incremental backup

To recover the database named HRINFO to the HRDPT subdirectory under the Domino data
directory, do the following steps:
1. Sign on to your iSeries using a user profile that has *JOBCTL and *SAVSYS special
authorities and *USE authority to the RST command.
2. Stop the Domino server:
ENDDOMSVR SERVER(<ServerName>)
3. Locate the tape (or save file) that contains the most recent backup of the database and
mount the tape in the tape unit.
4. To recover the database, use the following command:
rst dev('/qsys.lib/tap01.devd') obj('/domino/data/<ServerName>/hrdpt/hrinfo.nsf')
OUTPUT(*print)

6.5.6 Recover Domino program code

Sometimes you may need to reload the Domino product after a damaged object or another
abnormal situation. You may have found your product to be in *ERROR status when
displaying the installed licensed programs. You can recover the Domino code from the
installation CD. Make sure you use the same version of the Domino code as currently
installed. Remove any installed HotFixes before reloading the code.

Depending on your problem, you may only have to re-install the Domino program code
without having to reload Domino server data directories.

Chapter 6. Backup and recovery using OS/400 commands 275

 Tip: You can determine if you have any fixes installed by using the DSPPTF 5733LD6
command. But how can you distinguish between a HotFix or a Critical FixPack (formerly
known as QMU)?

See the Lotus Knowledge Base document 1093944 at the Lotus Domino Support site
http://www.ibm.com/support/docview.wss?rs=463&context=SSKTMJ&q=%2bdomino+%2bptf+%2bho
tfix&uid=swg21093944&loc=en_US&cs=ISO-8859-1&lang=en+en

Note that this document is for Domino R5 and identifying SAxxxxx as a HotFix. However, in
Domino R6 HotFixes are named SExxxxxx, so you should review any PTF installed to
product 5733LD6.

More information on PTFs can be found on the Domino for iSeries Web site at:
http://www.ibm.com/servers/eserver/iseries/domino/domptfgi.htm

Before you start the installation, it is recommended to print the list of installed licensed
programs to verify that you are installing the correct Domino version and options. Only the
Domino options *BASE and 1 are installable from CD, all other options are downloadable from
the developerWorks : Lotus site at:
http://www.lotus.com/ldd/toolkits

See the installation documentation of these additional options on the Web.

Note: The installable options change with the introduction of multi-version capable
releases (Domino 6.0.3, Domino 6.5, and higher). Please refer to the release notes of
these releases for additional install options.

To reload the Domino code from the installation CDs:

1. Sign on to an iSeries 5250 emulation screen with a user profile that has at least *ALLOBJ
and *SECADM special authorities.
2. Print the list of installed licensed programs by issuing the command:
DSPSFWRSC *PRINT
Search for product 5733LD6 (Domino 6.x) or 5733L65 (Domino 6.5 and higher). Verify the
installed version and options and make sure you have all options available for install (on
CD or downloaded from the developerWorks : Lotus Web site).
3. End all your Domino servers, if not already stopped. You can either use the command
ENDDOMSVR *ALL to end all servers at once or end the servers individually by server
name, using command ENDDOMSVR SERVER(<ServerName>).
4. Verify that all Domino servers are ended and there are no Domino related jobs active
using the command:
WRKUSRJOB USER(QNOTES) STATUS(*ACTIVE)
There should be no active jobs running under the QNOTES user profile. You can refresh
the screen by pressing the F5 key, do not continue until all jobs have ended.
5. End the Domino related subsystems before continuing by using the command:
ENDDOMSVR SERVER(*ALL) OPTION(*IMMED)
This will end all Domino related subsystems. Do not use this command unless you have
verified that there are no active Domino related jobs as explained in step 4.

276 Domino 6 for iSeries Best Practices Guide

6. Use the command:
DSPPTF LICPGM(5733LD6) for Domino 6.x
DSPPTF LICPGM(5733L65) for Domino 6.5.x
to determine which PTFs (Critical FixPacks) are currently installed as you may want to
re-install them after the Domino code is installed.
7. Remove any installed HotFixes, use the RMVPTF command:
RMVPTF LICPGM(5733LD6) SELECT(Sxxxxxx) RMV(*PERM)
Use LICPGM(5733L65) if you are using Domino 6.5.x.
8. Print and review the joblog for any errors using the command:
DSPJOBLOG OUTPUT(*PRINT)
9. Sign off the current session to eliminate file locking issues, etc. Sign on again with the
same user profile (which has at least *ALLOBJ and *SECADM special authorities).
10.Install the Domino 6 for iSeries code from the CD using the command:
LODRUN DEV(*OPT) DIR('/OS400')
You can also use the Java based Install Shield. For more information on how to install
Domino see 1.3, “Software installation guidelines and resources” on page 20 and the
redbooks IBM Lotus Domino 6 for iSeries Implementation, SG246592 and Lotus Domino 6
for iSeries Multi-Versioning Support on the IBM eServer iSeries Server, SG24-6940 on the
IBM Redbooks Web site at:
http://www.redbooks.ibm.com
11.Print and review the joblog for any errors during software installation using the command:
DSPJOBLOG OUTPUT(*PRINT)
12.Check that the product is correctly installed and match the list of installed versions and
options with the list printed in step 2 on page 276. To do so, type GO LICPGM, press
Enter, then select option 10 - Display installed licensed programs. Page down until you see
the 5733LD6 (or 5733L65) product. The installed status should look similar to this:
Licensed Installed
Program Status Description

5733LD6 *INSTALLED Lotus Domino 6 for iSeries

5733LD6 *INSTALLED C API Release 6
You might not have the C API Release 6 installed. You may see more options if you have a
multi-version capable Domino release installed, or if you have downloaded and installed
additional options from the developerWorks : Lotus Web site.

Attention: 5733LD6 (or 5733L65) shows the status *NOPRIMARY if your OS/400
primary language is not English (=2924). This is not an error!

If the status is *ERROR you should remove the Domino 6 for iSeries product and then
start the recovery again from step 10. To remove 5733LD6, type:
DLTLICPGM LICPGM(5733LD6)
Display the joblog to see that the job completed normally, use the command:
DSPJOBLOG OUTPUT(*PRINT)
Start over with step 10 to reinstall the code.
13.Re-install Critical FixPacks and/or HotFixes if you had any. Follow the instructions that
came with the fix.

Chapter 6. Backup and recovery using OS/400 commands 277

 14.Start the Domino server:
STRDOMSVR <ServerName>
15.Verify from the Domino console that the server starts correctly, you can use the
WRKDOMSVR command and press enter, choose option 8 work console.

6.5.7 Recreate a Domino server configuration

There may be a situation where you need to recreate Domino related files, such as the
/qibm/userdata/lotus/LOTUS_SERVERS file which contains information about partitioned
servers.

In a situation like that you have to recreate the server configuration and the associated
objects using the command CFGDOMSVR with parameter RPLCFG(*NO).

Important: Follow these instructions only if you know how the Domino server was
previously configured!

1. Sign on to the iSeries with a user profile that has at least *ALLOBJ, *SECADM, *JOBCTL,
and *IOSYSCFG special authorities.
2. End the Domino server.
3. Verify the Domino data directory name and path by issuing the command WRKDOMSVR.
On the Work with Domino Servers menu press F11 twice to display the Domino data
directories. Write down the directory and path information.
4. Backup the Domino data directory if you don't have a valid copy. You can back up your
data directory to either a tape device or a save file. Refer to 6.2.1, “Backup of entire
Domino data directory” on page 261 and 6.6.1, “Save files” on page 280 for detailed
instructions.

Warning: Issuing the CFGDOMSVR SERVER(<ServerName>) OPTION(*REMOVE)

command deletes the Domino data directory. Therefore you must make sure to have a
valid backup of your Domino data directory!

5. After verifying that you have a complete backup of your Domino data directory, remove
your Domino server. The Domino servers’ subsystem must be ended or you are not able
to remove the server (ENDSBS). Enter the following command to remove the Domino
server:
CFGDOMSVR SERVER(<ServerName>) OPTION(*REMOVE)
6. You might need to recreate parts of the Domino data directory path before you are able to
continue. Verify which parts of the path still exist using the WRKLNK command. You need
all directories in the path except for the Domino data directory itself (for example, if your
path is /domino/data/<ServerName> you need to make sure that /domino/data exists. To
recreate the data directory path, use the following commands:
MD DIR('/domino')
MD DIR('/domino/data')
Use the path and directory information you have written down in step 3 on page 278.
7. Change the ownership of the directories to QNOTES by issuing the commands:
CHGOWN OBJ('/domino') NEWOWN(QNOTES)
CHGOWN OBJ('/domino/data') NEWOWN(QNOTES)

278 Domino 6 for iSeries Best Practices Guide

 8. Restore your Domino data directory, again using the information from step 3 on page 278,
by entering the following command:
RST DEV('/qsys.lib/mylib.lib/mysavf.file') OBJ('/domino/data/<ServerName>')

Note: To restore from tape, use DEV('/QSYS.LIB/TAPxx.DEVD')

More detailed instructions on how to restore a Domino data directory can be found in
6.5.2, “Recover Domino data directory” on page 271.
9. Copy the NOTES.INI file to another directory. The CFGDOMSVR command replaces the
existing NOTES.INI and you need to replace the newly created NOTES.INI by the original
file later. In our example we copy the NOTES.INI to the root directory:
CPY OBJ('/domino/data/<ServerName>/notes.ini') TODIR('/')
10.Reconfigure the Domino server using your original configuration files. A very important
parameter on this command is RPLCFG(*NO) - using this parameter makes sure that the
existing Domino configuration files are used (ID files and NAMES.NSF).
Replace all path information with the correct values for your configuration. Our example
uses /DOMINO/DATA/<ServerName> for the data directory (DTADIR) and
/DOMINO/DATA/ID/ as the path for the Domino ID files (CERTID, ADMID, SVRID).
CFGDOMSVR SERVER(<ServerName>) OPTION(*FIRST) DTADIR('/domino/data/<ServerName>')
RPLCFG(*NO) CERTID('/DOMINO/DATA/ID/CERT.ID') ADMID('/DOMINO/DATA/ID/USER.ID')
SVRID('/DOMINO/DATA/ID/SERVER.ID')
Press F4 and verify the user ID and password parameters.
Make any changes needed to comply with the previous Domino server configuration, for
example to the Server Name (SERVER), Organization (ORG), Administrator's
Name/Password/Length (ADM), Timezone (TIMEZONE), the TCP/IP port options
(TCPOPT), and Advanced Services (ADVSRV) parameters.
Please refer to Chapter 4 of the redbook IBM Lotus Domino 6 for iSeries Implementation,
SG24-6592 for a detailed description of the CFGDOMSVR command and its parameters.

11.Delete the new NOTES.INI that was created during the CFGDOMSVR command:
RMVLNK OBJLNK('/domino/data/<ServerName>/notes.ini')
12.Move the previously saved NOTES.INI back to the data directory:
MOV OBJ('/NOTES.INI') TOOBJ('/domino/data/<ServerName>/NOTES.INI')
13.Change the object ownership of the NOTES.INI file:
CHGOWN OBJ('/domino/data/<ServerName>/NOTES.INI') NEWOWN(QNOTES)
14.Restart your Domino server.

6.6 Tips and techniques

This section explains some additional techniques, such as using save files instead of tapes
as the backup media, how to schedule backups and how to save and restore Domino
databases while the Domino server is active. For details, please refer to these subsections:
򐂰 “Save files” on page 280
򐂰 “Scheduled backups” on page 282
򐂰 “Save databases while Domino server is running” on page 285

Chapter 6. Backup and recovery using OS/400 commands 279

6.6.1 Save files
A save file is a specific file type that can be used with the OS/400 save and restore
commands. You use the same save commands but your save device is a save file on disk,
instead of a tape. Once you have saved your Domino directory (or any other data) to a save
file, you can restore it from there, exactly like from tape.

It is recommended to back up your save files to a location outside of your server for
disaster/recovery reasons in a second step. For example, you can save them to tape or you
can send them to another iSeries system where you may have a faster tape device.

Because save files reside on your disk you need to make sure that you don’t exceed or fill up
your available disk space. In our examples, to save disk space, we reuse the save files every
time we run the SAV command, using parameter CLEAR(*ALL). This allows the backup
command to overwrite existing data. If you want to follow this example, you need to make sure
that you back up the save file to tape or move it to another system before reusing it.

Create save files

It might make sense in your environment to create a dedicated library for your save files.
However, this is not necessary and you can use the QGPL library as well or any other user
library to store your save files. To create a new library type:
CRTLIB LIB(DOMINOSAVE) TEXT('Library for DOMINO save files')

Use the Create Save File (CRTSAVF) command to create a new save file called WEEKLY1 in
library DOMINOSAVE:
CRTSAVF FILE(DOMINOSAVE/WEEKLY1) TEXT('SAVF for DominoServer data directory')

The user profile you are using for backing up the Domino server data needs to have *ALL
authority to the save file (to be able to overwrite the existing data). To give *ALL authority to
user profile SAVDOMINO for save file WEEKLY1 in library DOMINOSAVE type:
GRTOBJAUT OBJ(DOMINOSAVE/WEEKLY1) OBJTYPE(*FILE) USER(SAVDOMINO) AUT(*ALL)

Using save files

This section explains how to use save files in save and restore operations and how to save a
save file to tape.

Backup to save file

To back up data to a save file, you use the same SAV command as when you save to a tape
device. The only difference is the DEV parameter.

For example, to save the Domino data directory /lotus/data/domrest to tape device TAP01 you
use the command:
SAV DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)

To save to save file WEEKLY1 in library DOMINOSAVE you use the command:
SAV DEV('/qsys.lib/dominosave.lib/weekly1.file') OBJ('/lotus/data/domrest')
OUTPUT(*print)

Restore from save file

To restore from a save file, you use the same command as when restoring from tape. The
difference is again in the parameter DEV.

280 Domino 6 for iSeries Best Practices Guide

For example, to restore the Domino data directory /lotus/data/domrest from save file
WEEKLY1 in library DOMINOSAVE, use the following Restore Object (RST) command:
RST DEV('/qsys.lib/dominosave.lib/weekly1.file') OBJ('/lotus/data/domrest')

Note: This example restores the Domino directory from the save file on disk. In real life you
are probably restoring from the backup copy of the save file on tape. See “Restore data
from save file that was saved to tape” on page 281 for details.

Save save file to tape

After you have used your save file in a backup procedure, you should save it to tape to have
a valid backup outside of your system. Use the command Save Save File Data
(SAVSAVFDTA) to back up a save file to tape.

For example, to save the save file WEEKLY1 in library DOMINOSAVE to tape device TAP01,
type the following statement:
SAVSAVFDTA SAVF(DOMINOSAVE/WEEKLY1) DEV(TAP01) OUTPUT(*PRINT)

Note: When using the parameter OUTPUT(*PRINT) a spooled file of saved objects in the
save file WEEKLY1 is produced. By default one line for each object that was saved is
produced. On a large Domino system this listing may be very large.

Note that the save file object itself is not backed up, only the content of the save file. You can
print out the content of the tape using the command:
DSPTAP DEV(TAP01) OUTPUT(*PRINT)

When doing this, you will not see an indication of WEEKLY1 but the label reads “SAV + the
date you saved the file”, for example, SAV20030824. Note also the sequence number (for
example 00008) if you have multiple saves on one tape. A good practice would be to print out
the content of the tape and keep it in a secure place, together with the tape.

Attention: Using save files requires additional disk space! Remember to clear the save file
after you have saved it to tape, otherwise you may be filling up your disk space.

Restore data from save file that was saved to tape

If you need to restore a Domino data directory, that was first backed up to a save file, then
moved to tape using the SAVSAVFDTA command, you actually perform a “normal” restore
from tape. So the command is:
RST DEV('/qsys.lib/tap01.devd') OBJ('/lotus/data/domrest') OUTPUT(*print)

Tip: Use either the LABEL name (SAVxxxxxxxx) or the sequence number SEQNBR to
restore the correct file, if you have multiple saves on the tape.

More information on save files

More information on save files and how to use them can be found in the iSeries Information
Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Also, Part 8, Backup and Recovery Tools and Techniques of the manual Backup and
Recovery, Version 5, SC41-5304 contains information on this topic. See:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/sm04/c4153046.pdf

Chapter 6. Backup and recovery using OS/400 commands 281

6.6.2 Scheduled backups
To automate your backups, you can write a CL program and schedule it to run daily through
the iSeries Job Scheduler. The iSeries Job Scheduler is a free program installed on every
iSeries system by default. We give you an example for saving your Domino data directory.
You need to have basic CL programming skills, such as how to edit and create CL programs
in order to use this sample program.

For more information about CL programming, go to the iSeries Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Choose Programming -> CL -> Related information and see the manual CL Programming
Version 5, SC41-5721.

Sample program
The following program saves our Domino data directory to tape device TAP01. In our example
we:
򐂰 First end the Domino server in a controlled manner, then we wait 10 minutes before
ending the server immediately. Ending the server immediately ends the Domino
subsystem. Normally, there should be no Domino jobs remaining active when ending the
Domino server immediately, otherwise the controlled shutdown of the Domino server has
not yet finished or some of your jobs are hanging.

Attention: We found that sometimes the Domino for iSeries “watchdog” job restarts the
Domino server when the server is ended immediately while jobs are still active -
because the “watchdog” thinks the Domino server ended in error. Which means, that
the Domino server will be active again when you start the backup and thus the backup
might not be complete and valid.

It is therefore highly recommended to use the Domino APIs to retrieve the server status
instead of ending the server immediately after a hardcoded timeframe. An example of
such a CL program can be downloaded from the Additional materials directory of this
redbook. See Appendix D, “Additional material” on page 611 for instructions on how to
download the code example.

In our example we have a 10 minute wait before ending the server immediately. This may
not be enough for your environment and you should test manually how long it normally
takes to bring your server down if you want to pursue this approach. End the Domino
server manually at the time you plan to schedule your backup for and record the time. Test
this at least two times on different days, check the time needed and change the DLYJOB
value in the CL program if needed. Note that the delay is in seconds. Recreate the
program after changing it.
As an alternative to the hard-coded 10 minute wait you could change the program to use a
loop with a short delay and a check to see if the server has ended. For example, loop
15 times with a one minute delay each time through the loop. By doing that, the backup
begins as soon as the server has ended rather than always having to wait 10 minutes.
You would also have an additional time buffer in case a server shutdown takes longer than
normal.
򐂰 Clear the tape before using it (parameter CLEAR(*ALL)) so any existing data on the tape
is overwritten.

282 Domino 6 for iSeries Best Practices Guide

 Important: This sample program assumes that you are only backing up the Domino
data directory.

Do not use the CLEAR(*ALL) parameter if you are using this program as part of a
backup routine where you save other data before the Domino data directory!

򐂰 Update the history information (parameter UPDHST(*YES)) so, if we like, we can run
incremental backups after this full backup.
򐂰 Use the parameters OUTPUT(*print) and INFTYPE(*ALL). This prints a detailed report of
saved objects. If you have a large Domino environment and the detailed report is too large,
use INFTYPE(*SUMMARY) or INFTYPE(*ERR) instead.
򐂰 Restart the Domino server after the save operation.
򐂰 Before the job ends, we also print the joblog. This helps to diagnose what happened when
the program run.

Figure 6-3 shows the sample program.

0001.00 PGM
0002.00 MONMSG MSGID(CPF0000)
0003.00 ENDDOMSVR SERVER(DOMREST) /* End the Domino Server +
0004.00 normally */
0005.00 DLYJOB DLY(600) /* Wait 10 minutes for the Domino +
0006.00 Server to end , increase time if it's not +
0007.00 enough */
0008.00 ENDDOMSVR SERVER(DOMREST) OPTION(*IMMED) /* This will +
0009.00 end the subsystem monitor job */
0010.00 ALCOBJ OBJ((QUSRNOTES/DOMREST *SBSD *EXCL)) +
0011.00 WAIT(120) /* Check if the subsystem is +
0012.00 still active */
0013.00 MONMSG MSGID(CPF1002) EXEC(GOTO CMDLBL(NOSAVE)) /* +
0014.00 Server did not end normally */
0015.00 SAV DEV('/qsys.lib/tap01.devd') +
0016.00 OBJ(('/lotus/data/domrest')) +
0017.00 OUTPUT(*print) ENDOPT(*REWIND) +
0018.00 INFTYPE(*ALL) UPDHST(*YES) CLEAR(*ALL) /* +
0019.00 Save Domino data directory and all +
0020.00 subdirectories to tape device TAP01 */
0021.00 NOSAVE: DLCOBJ OBJ((QUSRNOTES/DOMREST *SBSD *EXCL))
0022.00 STRDOMSVR SERVER(domrest) /* Start the Domino server */
0023.00 DSPJOBLOG OUTPUT(*PRINT)
0024.00 ENDPGM: ENDPGM
****************** End of data ***************************************

Figure 6-3 Sample backup CL program

Schedule sample program

To schedule this CL program to run every Sunday night at 22:00, we use the iSeries native
Job Scheduler. To add a job to the scheduler:
1. Use the Work with Job Schedule Entries (WRKJOBSCDE) command and press Enter.
When the Work with Job Schedule Entries menu appears, press the F6 key to add an
entry.
2. In our example (shown in Figure 6-4) we call the job “savdomweek” and it will run once a
week on Sundays at 22:00. Press F10 for additional parameters.

Chapter 6. Backup and recovery using OS/400 commands 283

 Add Job Schedule Entry (ADDJOBSCDE)

Type choices, press Enter.

Job name . . . . . . . . . . . . savdomweek Name, *JOBD

Command to run . . . . . . . . . call dominosave/fulldomino

Frequency . . . . . . . . . . . *weekly *ONCE, *WEEKLY, *MONTHLY

Schedule date, or . . . . . . . *none Date, *CURRENT, *MONTHSTR...
Schedule day . . . . . . . . . . *sun *NONE, *ALL, *MON, *TUE...
+ for more values
Schedule time . . . . . . . . . 22:00 Time, *CURRENT

Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys

Figure 6-4 Schedule backup CL program to iSeries Job Scheduler - Part 1

3. We want this job to run from the QBATCH job queue and we use the user profile
SAVDOMINO which will be the actual user in the submitted job. See Figure 6-5 for the
additional parameters.

Add Job Schedule Entry (ADDJOBSCDE)

Type choices, press Enter.

Additional Parameters

Omit date . . . . . . . . . . . *NONE Date, *NONE

+ for more values
Recovery action . . . . . . . . *SBMRLS *SBMRLS, *SBMHLD, *NOSBM
Job description . . . . . . . . *USRPRF Name, *USRPRF
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Job queue . . . . . . . . . . . qbatch Name, *JOBD
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
User . . . . . . . . . . . . . . savdomino Name, *JOBD, *CURRENT
Message queue . . . . . . . . . *USRPRF Name, *USRPRF, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Text 'description' . . . . . . . Weekly full Domino Data Directory save.

Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys

Figure 6-5 Schedule backup CL program to iSeries Job Scheduler - Part 2

284 Domino 6 for iSeries Best Practices Guide

 4. Press Enter and the job SAVDOMWEEK is added to the job scheduler as shown in
Figure 6-6.

Work with Job Schedule Entries AS25

08/27/03 09:37:37

Type options, press Enter.

2=Change 3=Hold 4=Remove 5=Display details 6=Release
8=Work with last submission 10=Submit immediately

Next
-----Schedule------ Recovery Submit
Opt Job Status Date Time Frequency Action Date
SAVDOMTAPF SAV 08/25/03 14:33:54 *ONCE *SBMRLS
SAVDOMWEEK SCD *SUN 22:00:00 *WEEKLY *SBMRLS 08/31/03
SAVESAVF SAV 08/25/03 15:44:07 *ONCE *SBMRLS
STRTCP SAV 05/17/02 07:45:00 *ONCE *SBMRLS
TTLCHGJRNR SCD *ALL 00:05:00 *WEEKLY *SBMRLS 08/28/03
TTLMOM SCD *ALL 00:05:00 *WEEKLY *SBMRLS 08/28/03
ZONDAG HLD *ALL 00:01:00 *WEEKLY *SBMRLS 08/28/03
Bottom
Parameters or command
===>
F3=Exit F4=Prompt F5=Refresh F6=Add F9=Retrieve
F11=Display job queue data F12=Cancel F17=Top F18=Bottom

Figure 6-6 WRKJOBSCDE

6.6.3 Save databases while Domino server is running

You may have situations when you need to save a Domino database but you can’t shut down
the Domino server. In this case, you can use Domino tools to make a new copy or a replica of
the database somewhere outside of your Domino data directory. Then, as the next step, you
can save this new file using OS/400 commands without bringing the server down.

To make a new copy of a database using the Lotus Notes client, choose File -> Database ->
New Copy, or for a new replica, choose File -> Replication -> New Replica.

You can place the new database on your local workstation and then copy and paste it to a
shared drive on the iSeries IFS (or use FTP if you prefer). Or you can map a directory outside
the Domino data directory first and create the copy/replica directly on this shared drive.

Attention: Do not share the Domino data directory.

Map network drive

To copy a file to an iSeries IFS directory using a mapped drive, you need to share the
directory through an iSeries NetServer file share. For more information about NetServer file
shares go to the iSeries Information Center on the Web at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

Choose Networking -> TCP/IP -> iSeries NetServer to display the appropriate information.

Chapter 6. Backup and recovery using OS/400 commands 285

 FTP put
If you don’t want to use a shared file, you can always store the database on your local
workstation and then use FTP to copy it to the iSeries.

To copy a Domino database called “SAVETEST.NSF” from the local workstation (C:\Program
Files\Lotus\notes\data) to the iSeries system (AS25) directory called “/transfer/dominodb”
using the MS-DOS Prompt, do the following steps:
1. On the MS-DOS Prompt window change the current directory to the directory where
SAVETEST.NSF resides:
cd program files\lotus\notes\data
2. Start an FTP connection to the iSeries system where you want to copy the file:
ftp as25
If you receive a “Connection refused” message, this means that the FTP server is not
started on your iSeries system. Ask your system administrator to start the FTP server.
3. Enter your iSeries user ID and password when prompted, press Enter after each entry.
4. Change to binary format, type bin and press Enter.
5. Change to the target directory:
cd /transfer/dominodb
Press Enter.
6. Copy the file, type:
put savetest.nsf
Press Enter.
7. Type quit to exit the FTP session and press Enter.
8. To exit the MS-DOS prompt, type exit and press Enter.
9. Make sure QNOTES is the owner of the database you just FTPed to the system:
CHGOWN OBJ(’/transfer/dominodb/savetest.nsf’) NEWOWN(QNOTES)

6.6.4 Restore databases while Domino server is running

There may be situations when you need to restore a Domino database from a backup but
because you cannot bring the Domino server down, you cannot restore it directly to your
Domino data directory. Also, if a user accidentally deleted some documents but not the entire
Domino database, you might want to recover only these documents. In this case, you also
use a restored copy of the database (outside the Domino data directory) and copy the
missing documents over to the still existing database.

You need to perform additional steps to recover the database:

1. First you restore the file to another directory in the IFS, outside your Domino data directory
structure.
In our example we restore the file called DATABASE.NSF from tape device TAP01 to the
directory /dominotest located in the root of the IFS:
RST DEV('/qsys.lib/tap01.devd')
OBJ(('/domino/data/<ServerName>/database.nsf' *INCLUDE '/dominotest/database.nsf'))

286 Domino 6 for iSeries Best Practices Guide

 2. Then you copy/replicate the file or the missing documents to your Domino data directory
using a Lotus Notes client.
You need to have access from your Lotus Notes client to that directory for the
copy/replication. Therefore, in our example, we have mapped the /dominotest directory
using a NetServer file share as drive “F:” (see “Map network drive” on page 285 for
information on how to map a drive).
Open the database in the Lotus Notes client from Server Local and use the Browse
button to navigate to DATABASE.NSF on the F: drive as shown in Figure 6-7.

Figure 6-7 Open database locally

Once the database is open in your Lotus Notes client, you can either replicate the entire
database or use the copy-and-paste function to copy the missing documents from the
restored database to the original database.

Important: To prevent unwanted replication between the databases you should check
the Temporarily disable replication box in the database’s Replication Settings.

3. After you have copied/replicated the needed data you can delete the restored database
using Domino functions or using iSeries commands. Use iSeries operating system
commands only if the restored file is not under the Domino data directory.

6.7 Tips for beginners: System management

This section provides information on some basic system management tasks, such as these:
򐂰 User profile requirements for backups
򐂰 Determine used disk space
򐂰 Determine Domino data directory size
򐂰 Initialize tapes
򐂰 Find Domino objects on the system
򐂰 Common SAV/RST problems

Chapter 6. Backup and recovery using OS/400 commands 287

6.7.1 User profile requirements for backups
To save your Domino data directory you must use a user profile that has several special
authorities. We recommend that you create a dedicated user profile for your backups.

The minimum authority requirements are *SAVSYS and *JOBCTL special authorities, and
*USE object authority to the QUSRNOTES library.

This user profile also needs *USE authority to the SAV and RST commands.

If you use save files, the user profile needs to have *ALL authority to the save files to overwrite
existing data.

To prevent authority issues we recommend that you also grant *ALLOBJ special authority to
this user profile. However, this special authority is not required.

6.7.2 Determine used disk space

Before you start a backup, you need to make sure you have enough initialized tapes. As tape
devices and tape cartridges are different, we cannot tell you the exact amount of tapes
needed for a backup, but we can show you how to find out the overall disk usage as well as
the storage occupied by a Domino server.

Use the Work with System Status (WRKSYSSTS) command to display the overall disk usage
as shown in Figure 6-8.

Work with System Status AS25

08/21/03 15:55:37
% CPU used . . . . . . . : 3.5 Auxiliary storage:
% DB capability . . . . : .0 System ASP . . . . . . : 171.7 G
Elapsed time . . . . . . : 00:43:58 % system ASP used . . : 50.5825
Jobs in system . . . . . : 336 Total . . . . . . . . : 171.7 G
% perm addresses . . . . : .013 Current unprotect used : 3425 M
% temp addresses . . . . : .028 Maximum unprotect . . : 3966 M

Type changes (if allowed), press Enter.

System Pool Reserved Max -----DB----- ---Non-DB---

Pool Size (M) Size (M) Active Fault Pages Fault Pages
1 361.12 214.17 +++++ .0 .0 .1 .5
2 4195.67 1.92 290 .0 .0 1.1 1.5
3 511.99 .01 232 .0 .0 .1 .6
4 51.19 .00 5 .0 .0 .0 .0

Bottom
Command
===>
F3=Exit F4=Prompt F5=Refresh F9=Retrieve F10=Restart
F11=Display transition data F12=Cancel F24=More keys

Figure 6-8 Overall disk usage

Verify the System ASP value and the % system ASP used value. In our example the total
amount of disk space in the system ASP is 171,7 GB of which 50.58% are used
(171,7 GB x 0,506 = 86.8 GB).

288 Domino 6 for iSeries Best Practices Guide

 Attention: Notice that in our example there are no User ASPs or iASPs configured on the
system. All disk storage is under the System ASP which is the default configuration.

6.7.3 Determine Domino data directory size

Important: Be vary careful when using the EDTF command. Do not use EDTF to edit
Domino databases, that may cause database corruption.

We found that using the EDTF command is an easy way to determine the size of a
directory. However, the command is not really intended to do this.

To see how much storage is occupied by your Domino server use the command:
edtf '/lotus/data/'

Substitute /lotus/data/ with the appropriate path of your configuration.

Our example assumes that all partitioned Domino server directories are under the /lotus/data/
directory. This allows us to display all Domino server data directories at once.

Enter the number 6 in front of the desired Domino server and press the Enter key. This
displays the size of that data directory as shown in Figure 6-9.

Directory: /lotus/data/
Position to : Record : 1 of 6
New File :
2=Edit 4=Delete File 5=Display 6=Path Size 9=Recursive Delete

Opt Name Size Owner Changed Used

DOMAV *DIR QNOTES 08/21/03 01:30 08/21/03 16:45
DOMBRMS *DIR QNOTES 08/20/03 17:59 08/21/03 16:51
DOMCLUS2 *DIR QNOTES 08/21/03 02:00 08/21/03 16:47
domtdp *DIR QNOTES 08/21/03 16:00 08/21/03 16:00
domtdptl *DIR QNOTES 08/14/03 16:51 08/14/03 16:51
DOMREST 667,901K QNOTES 08/21/03 15:03 08/21/03 16:39

Bottom

F3=Exit F12=Cancel F16=Sort F17=Position to F22=Display entire field

Figure 6-9 Display the size of a Domino data directory

Chapter 6. Backup and recovery using OS/400 commands 289

 To see the size of individual Domino databases enter 2 (2=Edit) in front of your server’s data
directory and press Enter. You see the contents of the data directory and file sizes. Press F3
to exit.

Directory: /lotus/data/DOMREST
Position to : Record : 1 of 142
New File :
2=Edit 4=Delete File 5=Display 6=Path Size 9=Recursive Delete

Opt Name Size Owner Changed Used

notes.ini 8K QNOTES 08/26/03 17:32 08/27/03 18:55
doc *DIR QNOTES 08/14/03 16:43 08/27/03 19:25
domino *DIR QNOTES 08/14/03 16:44 08/27/03 19:25
HELP *DIR QNOTES 08/14/03 16:43 08/27/03 19:25
INOTES *DIR QNOTES 08/14/03 16:44 08/27/03 19:25
AgentRunner.nsf 512K QNOTES 08/27/03 05:00 08/27/03 05:00
activity.ntf 1,280K QNOTES 08/27/03 18:01 08/27/03 18:01
admin4.ntf 1,792K QNOTES 08/27/03 18:01 08/27/03 18:01
alog4.ntf 384K QNOTES 08/27/03 18:01 08/27/03 18:01
archlg50.ntf 512K QNOTES 08/27/03 18:01 08/27/03 18:01
billing.ntf 384K QNOTES 08/27/03 18:01 08/27/03 18:01
binary.gif 8K QNOTES 06/19/03 05:14 08/07/03 15:16
More...

F3=Exit F12=Cancel F16=Sort F17=Position to F22=Display entire field

Figure 6-10 Display the size of Domino databases

Tip: You can determine transaction log usage by displaying the contents of the transaction
log directory. In our case these files are located in the /logdir directory under the Domino
server’s data directory. To display the size of the transaction log files, enter 2 in front of the
appropriate subdirectory. See Figure 6-10 for an example.

Directory: /lotus/data/domrest/logdir
Position to : Record : 1 of 4
New File :
2=Edit 4=Delete File 5=Display 6=Path Size 9=Recursive Delete

Opt Name Size Owner Changed Used

nlogctrl.lfh 8K QNOTES 08/27/03 17:54 08/27/03 17:54
S0000000.TXN 66,560K QNOTES 08/27/03 18:42 08/27/03 18:42
S0000001.TXN 66,560K QNOTES 08/26/03 17:32 08/27/03 17:54
S0000002.TXN 66,560K QNOTES 08/26/03 17:32 08/27/03 17:54

Bottom

F3=Exit F12=Cancel F16=Sort F17=Position to F22=Display entire field

Figure 6-11 Check transaction log usage

Note the Changed date in Figure 6-10. This value gives you the date and time when the log
extent was last changed.

290 Domino 6 for iSeries Best Practices Guide

6.7.4 Initialize tapes
Every new tape cartridge has to be initialized before the first use. This is done with the
Initialize Tape (INZTAP) command:
INZTAP DEV(TAP01) NEWVOL(DOMINO) CHECK(*NO)

This command initializes the tape in device TAP01 using Volume identifier DOMINO (every
volume needs to have a name). The parameter CHECK(*NO) must be used when you are
initializing a new tape.

Before starting a backup, make sure you have enough initialized tapes for the amount of data.

6.7.5 Find Domino objects on the system

You can use iSeries Navigator to find out where your Domino objects are. To do so:
򐂰 Open the Navigator, go to My Connections and select the correct iSeries server.
򐂰 Click Users and Groups -> All Users.
򐂰 Right-click the QNOTES user profile. From the context menu select User Objects ->
Scan for Owned Objects as shown in Figure 6-12.

Figure 6-12 Objects owned by QNOTES user profile

򐂰 Click OK to continue on the Scan for Owned Objects box.

After a while all objects owned by QNOTES are displayed and you can copy this list for
example to a Microsoft Exel file (.xls) by selecting File -> Export.

Chapter 6. Backup and recovery using OS/400 commands 291

6.8 Common SAV/RST problems
This is a list of common problems that can occur when saving and restoring Domino data
including possible reasons and solutions:
򐂰 You run the SAV command to back up your Domino data directory and receive a message
at the bottom of your screen, indicating:
977 objects saved. 20 objects not saved.
This happens when your Domino server is active during the save operation and thus
causing object locks. End the Domino server before running the SAV command.
򐂰 You receive the following message when running the SAV command:
Specified value on DEV parameter not valid.
You have misspelled the DEV parameter on your SAV command. Check that it is written
correctly. For example, if you are using tape device TAP01, the correct value is
“/qsys.lib/tap01.devd”.
򐂰 You are saving to a save file and receive the message:
Save file WEEKLY3 in DOMINOSAVE already contains data. (C G)
The save file you are saving to is not empty and you have not specified the parameter
CLEAR(*ALL) on your SAV command. Type G (= Go) and press Enter.
򐂰 Miscellaneous problems may occur, such as not being able to see a database in a Lotus
Notes client. This is most probably an ownership problem. The QNOTES user profile
needs to be the owner of every Domino database. Check the ownership with the EDTF
command (see “Determine Domino data directory size” on page 289).

292 Domino 6 for iSeries Best Practices Guide

 7

Chapter 7. Backup and recovery using

BRMS/400
In this chapter we discuss the various possibilities for backing up and restoring your iSeries
Domino environment when using Backup, Recovery, and Media Services for iSeries, IBM
licensed program 5722-BR1, (BRMS/400).

In the first section we describe backing up your Domino environment using the functions
provided by the BRMS plug-in provided in iSeries Navigator. The second section offers a
quickstart method for backing up your Domino environment with BRMS using OS/400
commands.

We also discuss why you would choose to use one of the backup scenarios, or a combination
of them, for your backup strategy. The chapter contains tips for setting up and using your
Domino backups as well as troubleshooting information. We show where BRMS stores
temporary data when backing up Domino servers, and what you can do, and must not do,
with that data.

Note: For simplicity, we are using the term BRMS throughout this chapter for the Backup,
Recovery, and Media Services for iSeries (5722-BR) product.

© Copyright IBM Corp. 2004. All rights reserved. 293

7.1 Introduction
BRMS/400 has been available for many years and has proved to be a very reliable product for
backing up AS/400 and iSeries system and user data. Since Domino was introduced on the
AS/400 and iSeries systems, BRMS/400 was enhanced to include Domino environment
objects in the backup procedures (also called Online Lotus Server backup). With BRMS you
can configure automated backups while also maintaining media information such as retention
periods and the location of your media. BRMS not only manages your saved data, but also
provides the ability to eliminate downtime for backups. With the use of BRMS you can
perform true online backups (without synchronization points). In addition, you can perform
true incremental backups, with the possibility to recover to a point in time.

The most important step to begin with, when implementing BRMS on your system, is a review
of your business needs related to the backup and recovery strategy. Dedicated Domino
backups may be possible, or, in a 24x7 environment, you may need to perform Domino online
backups. In addition, other restrictions may require online incremental backups. Using
clustered Domino servers, to back up one and leave the other running may also be a solution.

There is a lot of information available on the Backup, Recovery, and Media Services Web site
at:
http://www.ibm.com/servers/eserver/iseries/service/brms/

This information is kept up-to-date as new versions of the OS/400 operating system, of
BRMS/400, of Domino for iSeries, or iSeries Navigator are released. New functions may be
added or existing functions may (and will) be enhanced in new versions of the products or by
installing Program Temporary Fixes (PTFs). Therefore it is always a good practice to first
reference the latest information provided on this Web site before you configure changes to
your current backup procedures or start to implement a new backup environment. Pay special
attention to the Support section to make sure that you installed the latest available PTFs for
the different OS/400, Domino for iSeries, and BRMS versions. An example of very useful
information on this Web site is the News section where you not only find information on V5R2
enhancements, but also on upgrading BRMS to V5R2.

7.1.1 If you have never worked with BRMS/400

This section contains basic information to help you get familiar with BRMS if you have never
used the product before.

Backup, Recovery, and Media Services for iSeries (BRMS/400) provides just what its name
says, a solid program that you can use to back up and restore iSeries data. The product
keeps track of where the saved information resides and for what period this data should be
retained. With the use of the iSeries Job Scheduler, which is part of the iSeries operating
system, BRMS can be fully automated to back up your Domino environment (and naturally
also the rest of your iSeries data) without user intervention. After installing the licensed
program, you run a command to initially set up your BRMS environment.

This command analyzes the available resources on the system to be used for BRMS and
creates a set of default backup objects. You can use these objects to run your backups
manually or schedule backups with the iSeries Job Scheduler. After completing a backup,
you run a command to generate BRMS reports that contain information about which data was
saved and to which location. In addition, reports are generated that tell you exactly which
steps to take for restoring your system and user data in case of a disaster recovery. You must
print these reports daily, as they are the starting point for restoring your complete system. The
reports are not needed when the system is still running and you only want to restore Domino
databases. In this case you can use the recovery information from the BRMS screen options.

294 Domino 6 for iSeries Best Practices Guide

 The default settings can be used to back up your entire OS/400 and iSeries Domino
environment. However, we recommend that you review these settings and, when needed,
alter them to meet the backup and recovery needs for your situation.

There are many parameters you can use to alter the default setup of BRMS. In this chapter
we show you how to set up BRMS for Domino using the iSeries Navigator. As setting up
BRMS using OS/400 green screen commands is explained thoroughly in several other
places, we only discuss the most important parameters in this publication. For detailed
information on fine tuning BRMS backups, refer to Backup, Recovery and Media Services
Version 5, SC41-5345-03.

7.1.2 Using iSeries Navigator client versus OS/400 commands

Here are some considerations regarding why you might prefer one method over the other:
򐂰 To configure BRMS for Domino using iSeries Navigator is a step-by-step approach,
guided by many help text windows. It requires only basic knowledge of the BRMS product
and the iSeries Navigator client to build a solid backup and recovery strategy.
򐂰 If you have never worked with BRMS before, then it is best practice to start using the
iSeries Navigator client to configure your backups.
򐂰 If you are already experienced in using OS/400 commands to configure BRMS, you may
rather choose this method to set up your Domino backups. Some objects in the iSeries
Navigator client are named differently than in the OS/400 environment, and, in addition,
the approach is somewhat different.
򐂰 If you have set up your Domino backup strategy using OS/400 BRMS commands in the
past and the current configuration is working as desired, then we advise you to stay with
this approach.
򐂰 If you are not familiar with configuring BRMS using iSeries Navigator, it is best practice not
to change your current OS/400 green screen settings using the iSeries Navigator client
until you fully understand the consequences of the changes you make.

No matter which method you choose to use, the resulting backup strategy should be the
same, as it must be based on the requirements that are set by your company’s environment.

7.1.3 Backup scenarios

Before you start backing up your Domino environment, you should first review the available
backup scenarios. There are several ways to back up your Domino environment and you can
use one or more of them, depending on the situation in your company. You may also use a
combination of these methods, depending on the purpose of the Domino server or databases.

We discuss these backup scenarios:

򐂰 Full dedicated backups
򐂰 Backing up a clustered environment
򐂰 Full online backups
򐂰 Selective backups
򐂰 Incremental online backups

Attention: It is critical that you do not replace your complete system backup with online
Lotus Server backups. Only Domino databases are backed up using the online Lotus
Server backups. Other important Domino data, including libraries, files in the Lotus Server
IFS directories, and other non-Lotus Server system data, should also be backed up on a
regular basis (such as QUSRSYS, QGPL, etc.).

Chapter 7. Backup and recovery using BRMS/400 295

 Full dedicated backups
Full dedicated backups require the Domino server(s) to be ended until the backup process
has completed. This scenario has the advantage that no Domino databases are locked during
the backup process and that all databases are saved. A disadvantage is that your users are
not able to work with the server during the backup, the backup process runs longer than with
an incremental backup, and scheduled Domino tasks or agents cannot run until the server is
up and running again.

A dedicated backup is typically run once a month on an iSeries system mainly running
Domino servers or once a week when you run additional applications on your iSeries system.

If you have the possibility to perform full dedicated backups, this may be the best backup
method for you. A full dedicated save, with the Domino server ended, will generally be faster
than an online full backup (where the Domino server stays active). Recovery of a database
will generally also be faster when restoring a Domino database from a full dedicated backup.

Backing up a clustered environment

In a clustered Domino environment you may choose to end one of the clustered servers,
perform the backup, and restart the server. Make sure you do not use the clustering
possibilities of Domino to completely replace the backups of your server(s). When an error
occurs with the clustered environment, you may not be able to rebuild the configuration. Also,
a corrupted database may already be replicated to the other server(s) in the cluster and you
will no longer have a correct copy of the database. So it is strongly recommended to back up
all your Domino servers on a regular base.

Full online backups

A full online backup saves the Domino server's databases and templates while the Domino
server is active. Because the Domino server is active, there may be occasions when BRMS
cannot access a database to save it. This is the exception, not the norm. However, since this
can occur, you should monitor the logs after a save to confirm that the save completed
normally with no errors. The advantage to this type of backup is that users can continue
working while the backup is running.

A full online backup can be run daily. In addition, a weekly or monthly full dedicated backup is
recommended to save all objects in the Domino data directory, including those not saved by
the full online backup, such as ID files and configuration files.

Selective backups
The easiest way to perform a selective backup of a specific database is to end the Domino
server and use the OS/400 SAV command (see Chapter 6, “Backup and recovery using
OS/400 commands” on page 257 for information on this). This makes sure that the database
is not locked and the backup runs error free.

When you want to save multiple databases, you can create a link list containing those
databases and run it in a BRMS backup policy (or a backup control group in OS/400 green
screen terms) that you specifically create for selective backups. The Domino server must be
ended for this kind of backup, as you are not using SAVDOMBRM, which is intended for
online backups of Domino databases. Note that SAVDOMBRM should not be run from a
command line, it must be used from within a control group.

You may choose to use selective backups when not all Domino data needs to be saved on a
daily basis. Other reasons for performing selective backups are in situations when you need
to keep a copy of the database for later use or to copy the database to a Domino server in a
network that is not connected to the local Notes Named Network.

296 Domino 6 for iSeries Best Practices Guide

 Incremental online backups
Instead of performing full backups of Domino databases every time, incremental backups are
a possibility. The basis for incremental online backups is always a full backup. The first
incremental backup then saves all data that has changed since the last full backup.
Consecutive backups save all changes that occurred since the last incremental backup. To
restore such a database, you must first restore the full backup followed by the consecutive
incremental backups. However, BRMS takes care of the right sequence — it automatically
restores the full backup first, followed by the incremental backups.

Setting up online incremental backups for Domino requires some additional configuration
steps, however, it has many advantages over the previous methods. Your users can continue
to work while the backups run. In addition, the amount of data saved is less compared to
backing up the full server data so the backup is faster and less backup storage capacity is
needed. A second advantage of online incremental backups is the possibility to restore a
database to a point in time.

Note: Although you generally have less data to save with an incremental backup approach
there may be cases where you may have more data to save, compared to a full online
backup. This may occur at very busy Domino servers where for example large attachments
are sent while the backup is running.

Incremental backups require the setup of transaction logging on the Domino server. Although
transaction logging is needed for online incremental backups it also offers the advantage of a
faster restart after a Domino server ended in error. For information on transaction logging and
how to set it up for BRMS, please refer to 5.3, “Transaction logging” on page 252.

More disk space is required compared to full backups when performing online incremental
backups because of the archival logs. Archival logs are copied when they are full. These
copied archival logs remain on the iSeries system until an incremental backup is run, then
they are deleted. So on a busy Domino server your disk usage will increase because of these
archival log files until the next incremental backup has run.

7.1.4 BRMS/400 entities

Before you start to use BRMS for backing up your Domino environment it is good practice to
understand the entities that are used within BRMS. In this section we describe the entities
that make up the BRMS environment (and are created by it). For additional information about
BRMS entities see the manual Backup, Recovery and Media Services Version 5,
SC41-5345-03.

Where applicable, we discuss the naming and functional differences between iSeries
Navigator and the OS/400 5250 emulation environment. See Table 7-1 for the object
differences that have to be considered.

Important: It is recommended not to switch between the iSeries Navigator and the OS/400
approach. Once you started using iSeries Navigator, you should stay with this interface,
because changing backup control groups or other configuration changes in the OS/400
environment while having scheduled backups in iSeries Navigator is confusing and might
cause errors.

Chapter 7. Backup and recovery using BRMS/400 297

 Table 7-1 Naming differences iSeries Navigator - 5250 emulation environment
iSeries Navigator object OS/400 environment object(s)

Backup policy Backup control group and media policy

Note: The backup policy in iSeries Navigator contains

information from both OS/400 environment objects.

No equivalent in iSeries Navigator Backup policy

Changes only backup Cumulative backup

Media pool Media class

Disk pool Auxiliary storage pool

Global properties System policy

Before you start using BRMS you should review the objects that are created by the product.
You can use the default objects created by BRMS or alter some of them to meet your desired
situation. Note that several items, such as some backup link lists, cannot be changed in the
iSeries Navigator client interface. In addition, you can create similar objects of your own and
only use those objects for your backups. The following objects are to be considered:
򐂰 Backup policy/Backup control group:
The backup policy in the OS/400 command environment and the backup policy in iSeries
Navigator are two different entities. They have little in common and it is important to
understand the differences.
A backup policy in iSeries Navigator is a set of rules that controls what is backed up and
where it is backed up. It contains information about actions to perform before, during, and
after the backup.
In OS/400, a backup policy defines attributes such as the media policy, the backup device,
the default weekly activity, and much more. The items to be backed up are defined and
listed in the backup control group.
However, in the OS/400 environment, you do not need to use a backup policy as you could
also define these values directly in the control group attributes.
So a backup policy in iSeries Navigator combines the settings that are separately defined
in the backup control group and in the media policy, and, if used, in the backup policy or
system policy in an OS/400 environment.
򐂰 System policy:
In the OS/400 environment you can use the system policy to define global settings for your
backups. Control groups and the backup policy can use nested settings for several
parameters. For example, in a control group you can enter the value *SYSPCY to point to
the appropriate value for that parameter in the system policy. In addition, when you use the
value *BKUPCY for a parameter in a control group, and use *SYSPCY for that parameter
in the backup policy, then again the actual value used is the global setting taken from the
system policy.
So you could use the system policy for global settings, the backup policy for most backups,
or use a control group with the actual values entered for specific backups. It is also
possible to use a mixture of actual and nested settings in a control group or the backup
policy.
򐂰 Media policy:
The media policy contains information about where your media is located, for how long the
backups should be retained, and if save files should be used.

298 Domino 6 for iSeries Best Practices Guide

 A media policy is only used in the 5250 emulation session environment. In iSeries
Navigator, the information defined in a media policy is included in the backup policy.
򐂰 Backup link list, exclude list:
Several default backup link lists are created when BRMS is installed on the iSeries
system. Additional backup lists specifically to be used for Domino backups are created
during BRMS initialization when Domino servers are configured on the system.
BRMS can be initialized using OS/400 commands or using the iSeries Navigator client. In
iSeries Navigator, select the Perform maintenance and cleanup option in the BRMS tasks
pane (the right bottom pane shown in Figure 7-1 on page 301). Information on how to
initialize BRMS using OS/400 commands can be found in “Customizing the BRMS
defaults” on page 333.
One or more backup link lists can be configured to run in a backup policy. In the 5250
environment you add them to a backup control group in order to include or exclude IFS
objects in the backup process.
򐂰 Media:
Media is the common name for tape cartridges where the saved data is written to. In
addition, BRMS is able to back up data to a save file or to a IBM Tivoli Storage Manager
server.
򐂰 Move policy:
You can create and use move policies if you want BRMS to keep track of tape media
locations and moves. BRMS move policies define the movement of media between
storage locations and the time the media stays in a location. Using move policies is
optional.
An example for using a move policy is to store media in a safe place while the data it
contains is not actively needed but must still be kept (for example for auditing reasons).
Then, when the media is expired, it may be transported back so it can be used again for
future backups. A move policy holds the description of the rotation cycle of the tapes. You
create move policies depending on your company’s requirements.
Examples for move policies are HOME, VAULT, a storage room, or a different company
office to store the tapes securely away from the iSeries system for disaster fallback.
򐂰 Storage location:
Storage locations are places where the tape media is stored, such as OFFSITE,
AMSTERDAM, VAULT, or ROOM425.

Important: Using move policies and storage locations implies that you follow the BRMS
information and move the media to the different locations. The actual location of tape
media should match the information kept in BRMS. For that reason it is strongly advised to
configure BRMS for manual movements, so you are sure the tape media information in
BRMS matches the actual location of the media.

򐂰 Media pool/Media class:

In the iSeries Navigator client, the type of media used is described by the media pool,
such as QIC2GB, FMT3570, or 3590E. In OS/400, a media pool is called a media class.
򐂰 Backup device:
A backup device is a tape device in iSeries terminology, such as TAP01. It can also be a
tape library (for example, TAPMLB01) or an IBM Tivoli Storage Manager server (TIVSVR).

Chapter 7. Backup and recovery using BRMS/400 299

 򐂰 Save file or IBM Tivoli Storage Manager server:
With BRMS you can also choose to back up to save files. You do not have to create save
files yourself, BRMS will create them for you. After the save operation has finished, you
can then back up the save file to tape.
In iSeries Navigator, an additional configuration step is needed for using save files. You
are not able to create a backup policy that uses save files directly. Instead, you must first
create the backup policy, then change it to use save files. Naturally, you can also change
an existing backup policy.
The same is true when you wish to use a IBM Tivoli Storage Manager server for the
backups.
In an OS/400 command environment you use backup control group attribute settings for
this. BRMS will backup to a save file when you define a media policy of SAVF and a
backup device of *MEDCLS in the backup control group.
Backing up data to a save file has the advantage that the time needed for a backup is
shorter than when backing up to tape media. However, you need enough disk space for
the save files.
In a second step, you then save the save files to tape, which frees the used disk space
and makes sure you have a valid backup on tape.
To save the save files to tape, select the Back up save files option in the BRMS tasks
pane (the right bottom pane shown in Figure 7-1 on page 301) in iSeries Navigator. In the
OS/400 environment use the Save Save Files using BRM command (SAVSAVFBRM).
You can use the Work with Save Files command (WRKSAVFBRM) command to delete old
save files. Make sure that you do not delete any data that you may still need to restore.

7.2 Using BRMS iSeries Navigator client

iSeries Navigator is part of iSeries Access for Windows, 5722-XE1. We do not describe
iSeries Access for Windows here; installation and configuration of iSeries Access for
Windows is described thoroughly in the manual iSeries Access for Windows-Setup,
SC41-5507-03.

iSeries Navigator allows you to install the BRMS plug-in. Note that you do not need to have
the iSeries Navigator Domino plug-in installed to run Domino backups with BRMS.

You can use the BRMS iSeries Navigator client to back up and restore Domino objects and
recover your Domino servers. It is best practice to use the iSeries Navigator client to
configure and maintain your backup environment if you never worked with BRMS in an
OS/400 environment. The iSeries Navigator windows are easy to understand and follow.
Thorough online help is provided to guide you through the setup and maintenance.

This product is constantly enhanced and maintained. Make sure you check the IBM Web
sites on a regular basis to stay up-to-date with the product. For information about the latest
enhancements, see the Overview and what’s new section on the IBM eServer iSeries
Information Center at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm

For information on the latest BRMS and iSeries Navigator PTFs, see the following URL:
http://www.ibm.com/servers/eserver/iseries/service/brms/support.htm

300 Domino 6 for iSeries Best Practices Guide

 For more information on installing and configuring iSeries Navigator, visit the iSeries
Navigator Web site at:
http://www.ibm.com/servers/eserver/iseries/navigator/

You can read or download the BRMS iSeries Navigator client student guide at:
http://www.ibm.com/servers/eserver/iseries/service/brms/pluginguide.htm

7.2.1 The BRMS iSeries Navigator client window

Open iSeries Navigator for a system where BRMS (and the appropriate plug-in) is installed.
As shown in Figure 7-1, you can then review and set up your backup policies, move policies,
and media information.

Figure 7-1 The BRMS iSeries Navigator client

The iSeries Navigator client window consists of these four panes:

򐂰 The Environment: My Connections pane on the upper left allows you to access
Management Central and the iSeries systems that have been configured under My
Connections. Here you can find many (default) system management tasks as well as the
plug-ins for special functions, such as BRMS or Domino.

Chapter 7. Backup and recovery using BRMS/400 301

 򐂰 The upper right pane shows selected functions/items from Management Central or My
Connections. For example, if you click Backup Policies all configured backup policies
(backup control groups in OS/400) are displayed here. Note that it shows the system name
and the selected function in the title bar (As25: Backup Policies in our example).
򐂰 The left bottom pane is the My Tasks pane which can be customized. For example, you
can add the Perform maintenance and cleanup task from BRMS. Note that you must first
select one of the items from the My Connections pane before you can add tasks that
belong to that particular section.
򐂰 The bottom right pane displays tasks that belong to the function selected in the
Environment : My Connections pane. For example, when BRMS is selected in My
Connections, then the Backup, Recovery and Media Services Tasks are shown. To help
you understand the different options click Help for related tasks.

Figure 7-1 on page 301 shows all default backup policies (created during the installation of
BRMS) and entries for the existing Domino servers on this system.

Note: The BRMS maintenance task will create default backup policies for all Domino
servers that are configured on a system when the BRMS maintenance task runs. You are
not able to delete these backup policies using iSeries Navigator as iSeries Navigator
considers that they might be needed in scheduled backups. You need to use OS/400
commands to delete backup policies that are created by the maintenance task.

Also be aware that running the maintenance task again (which should run daily), will again
recreate default backup policy entries for existing Domino servers.

7.2.2 Moving from OS/400 BRMS commands to BRMS iSeries Navigator client
If you start using the BRMS iSeries Navigator client after you have used/configured BRMS in
the OS/400 command environment all previously configured BRMS objects will automatically
be added to the iSeries Navigator client and show up on the respective windows. You also
find any previously scheduled BRMS backup jobs in the Job Scheduler or the Advanced Job
Scheduler when used.

When opening or starting a backup policy that was previously created as a control group in
the OS/400 environment for the first time in iSeries Navigator, it must first be formatted for
iSeries Navigator.

As explained in “BRMS/400 entities” on page 297, in the OS/400 environment you have the
backup control group and the media policy as separately configurable objects while in iSeries
Navigator you have the backup policy which combines the settings of these two. Also, you
might use an OS/400 backup policy and/or system policy.

The reformatting is needed because this works differently in iSeries Navigator, that is, the
values for the media policies are set directly in the backup policy and they do not point to a
value anywhere else (such as the backup policy or the system policy in the OS/400
environment).

So when you use iSeries Navigator to start or open a backup policy that was previously
created in OS/400 as a control group, you will be asked to review and set these values. The
values that are shown by default are the resolved values from the settings in the OS/400
control group. The message shown in Figure 7-2 is displayed when you select the backup
policy for the first time.

302 Domino 6 for iSeries Best Practices Guide

Figure 7-2 Policy not formatted for iSeries Navigator

Clicking Close launches the policy properties window which is shown in Figure 7-3. Here you
are able to review and set the values for this backup policy. Clicking the OK button activates
the backup in iSeries Navigator.

Figure 7-3 Backup policy properties

Important information for users of previous versions of BRMS/400

This topic contains important information on the use of previously created OS/400 control
groups and media policies in iSeries Navigator:
򐂰 When you create a backup policy in the iSeries Navigator version of BRMS, a media policy
is dynamically created. BRMS-supplied media policies that you may have used in previous
versions of BRMS are no longer used in backup control groups. Therefore, changes you
make to the attributes of the IBM-supplied media policies are not reflected in the iSeries
Navigator version of the backup policy. However, changes made to other, non-IBM
supplied policies are reflected in iSeries Navigator.
򐂰 In addition, the backup policies in iSeries Navigator do not support the hierarchical
structure of attributes in the backup control groups of previous versions. If you format an
existing backup policy for iSeries Navigator, any backup control group attribute that
references the backup policy or system policy is resolved to the actual value when
displayed in iSeries Navigator. Therefore, any attributes you change in the backup policy
or system policy do not affect the iSeries Navigator backup policies. The exceptions to this
are the “sign off exceptions”, and “subsystems to check” controls in the system policy,
which are used in iSeries Navigator.

Chapter 7. Backup and recovery using BRMS/400 303

 򐂰 Following are some examples of how iSeries Navigator creates full and incremental media
policies when seen from the Work with Control Groups (WRKCTLGBRM) command. Note
that the name is made up out of a letter, the date and a sequence number, and is no
longer relevant to BRMS when used from the iSeries Navigator client, as an example:
Z031020004 Z031020005
Z031020002 Z031020003
򐂰 When the Advanced Job Scheduler licensed program, 5722-JS1, is installed on your
iSeries system, and you also installed the plug-in for it in iSeries Access for Windows on
your PC, then all BRMS backups that are scheduled will automatically default to be
scheduled in the Advanced Job Scheduler. If you still want to schedule jobs in the OS/400
default job scheduler, you must remove the Advanced Job Scheduler plug-in from iSeries
Access for Windows on your PC.

7.3 Configuring a Domino backup strategy in iSeries Navigator

Whether you use the OS/400 commands or the iSeries Navigator client to create your backup
policies, it is important to first create a business strategy for backing up your Domino
environment. When configuring BRMS to back up Domino databases, we advise to create
backup policies that provide daily, weekly, monthly and yearly backups.

In addition to backing up your Domino environment, you can also save system and user data
using the iSeries Navigator client.

Next, we discuss how to configure the following backup strategy for the Domino environment:
򐂰 Daily online incremental Domino server backup
򐂰 Weekly full online Domino server backup
򐂰 Weekly backup of entire IFS except online Lotus data
򐂰 Monthly full iSeries system backup
򐂰 Yearly full iSeries system backup

Note that we explain the set up and show the appropriate windows only for a daily backup
policy. The iSeries Navigator windows that you use when setting up a weekly, monthly or
yearly backup are the same as for a daily backup. What is different are the selections you
make on these windows, the naming of the objects, or the retention periods.

Retention schedule
To make sure that all data is available long enough and overlaps the following backup period
we chose the following retention schedule:
򐂰 35 days for daily backups
򐂰 42 days for weekly backups
򐂰 365 days for monthly backups
򐂰 1825 days for yearly backups

Attention: You may need to use different retention periods for your backup media,
according to any legal rules that may apply for your country or company.

7.3.1 Creating a backup policy for daily online incremental backups

The following is an example of how to set up a daily backup of your Domino for iSeries
environment. We discuss most windows that are shown in the iSeries Navigator client when
configuring Domino BRMS backups (we do not show all windows, as many of them are self
explanatory, or almost identical to the preceding windows).

304 Domino 6 for iSeries Best Practices Guide

 Note: Be aware that you are working in a GUI environment where responses may take
longer than when working in a 5250 emulation environment. The network is an important
factor in this area. Be patient when exploring the iSeries Navigator interface for the first
time, this allows you to get used to the performance in your environment.

Do not extensively click iSeries Navigator items while you are waiting for a response as this
will slow down the response time and may even cause hangs in the application (so you
might have to restart the iSeries Navigator client).

Follow these instructions to configure a backup policy from the iSeries Navigator client:
1. From the iSeries Navigator window shown in Figure 7-1 on page 301, click Create a
backup policy under the Backup tasks in the Backup, Recovery, and Media Services
Tasks pane (bottom right pane). This starts the New Backup Policy wizard.
It is recommended to use the Help option to inform yourself about this function if this is the
first time you are creating a backup policy using iSeries Navigator.
2. Click Next when you are ready to continue. This displays the window shown in Figure 7-4.
Here you fill in the name of the backup policy and, if desired, a description of the new
policy.

Figure 7-4 Naming a backup policy

3. Click Next to Select a Backup Strategy as shown in Figure 7-5. As explained earlier, we
chose the online incremental backup strategy for the daily backups. Therefore select Back
up Lotus server data online.
Notice the Help button, which explains the four choices available on this window.

Chapter 7. Backup and recovery using BRMS/400 305

 Figure 7-5 Online Lotus server data backup checked

4. Click Next to display a list of Domino servers on the iSeries system. See Figure 7-6.
Select the Domino servers you wish to save. All Domino servers are checked by default.
For our example we want to save all Domino servers on the system, so we leave all
servers checked. Click Next to continue.

Figure 7-6 All Domino servers selected for the daily backup

306 Domino 6 for iSeries Best Practices Guide

5. On the Shut Down Integrated Servers window, as seen in Figure 7-7, you are asked
whether you want to shut down the Integrated servers for the backup. Integrated servers
refers to the Integrated xSeries Server and the Integrated xSeries Adapter.
Note that the default setting ends any existing integrated servers. This is not needed for
Domino server backups so you can select No, leave my integrated servers running and
click Next once again.

Figure 7-7 Shutdown Integrated Servers window

6. The following windows depend on your system configuration. For example, if you are using
user-defined file systems, you are asked whether you want to unmount them. Or there
might be a window regarding your LPAR configuration. Use the help function if you are not
sure about what to select on these windows. Step through these windows until you arrive
at the Backup Activity window shown in Figure 7-8.

Chapter 7. Backup and recovery using BRMS/400 307

 Figure 7-8 Select the Backup Activity

7. On the Backup Activity window you select whether you want to run a full backup or
whether to save changes only. Select the Changes only and Changes since last backup
(incremental) radio buttons to save only the changes. Note that the backup change type
(cumulative or incremental) does not apply to Domino backups. Click Next to continue to
the Media Retention window in Figure 7-9.

Figure 7-9 Media Retention settings

308 Domino 6 for iSeries Best Practices Guide

8. Enter 35 days for both incremental and full backups. Note that these settings can be
overwritten when the backup policy is run or scheduled if you leave the appropriate box
checked. Click Next to continue to the Select Backup Devices window (Figure 7-10).

Figure 7-10 Select the Media Pool for the backup

9. We selected TAP01 for the backup tape device. After selecting the tape device click Next
to proceed to the Add Media window, as shown in Figure 7-11.

Note: You must select one of the devices that are available on your system and appear
in the selection box on the Select Backup Devices window (Figure 7-10).

You can change this selection to use a save file or an IBM Tivoli Storage Manager
server later in the configuration process. This procedure is explained in “Backup to a
save file or an IBM Tivoli Storage Manager server” on page 323.

Chapter 7. Backup and recovery using BRMS/400 309

 Figure 7-11 Add Media

10.You are asked whether you want to add the media that you are about to use for the
backup. You can also choose to add it later. Or you might already have added the needed
media to the media pool.
In this example we choose to add the media to the BRMS configuration. Click Next to
continue.
11.On the following window, see Figure 7-12, tape volumes can be added. You can either
enter the volume names one by one. Or you can add several tape volumes at a time,
which is very convenient when adding a group of new tapes to the media pool.
In this example we fill in the number 3 for the amount of Volumes to add, starting with the
Volume name MED100. The iSeries Navigator client will then automatically add 3 tape
volumes named MED100, MED101, and MED102.
Note that the text on the window provides extra help information about the task you are
performing.

310 Domino 6 for iSeries Best Practices Guide

Figure 7-12 Add media volumes to BRMS

12.After adding the volumes you are asked where the tapes should be located; see
Figure 7-13. In addition, you can add new locations.

Figure 7-13 Select media storage location

In our example we used the Home location for the new tapes. Click Next to continue to
the Initialize Volumes window as shown in Figure 7-14.

Chapter 7. Backup and recovery using BRMS/400 311

 Figure 7-14 Initialize tape volumes

13.On the Initialize Volumes window, you have the option to initialize individual tape volumes
and check for active files. In addition, there is the choice to unload, rewind, or leave the
tape media at its position after the initialization.
Click Next to continue to the Summary window as shown in Figure 7-15.

Figure 7-15 Summary of the policy settings

312 Domino 6 for iSeries Best Practices Guide

14.Here you see all the settings that have been entered on the previous windows. If needed
you can go back and change some settings.
After clicking Finish an animated window is displayed. Here you see all actions that are
currently carried out, such as creating the backup policy, adding volumes to BRMS and
initializing them. Figure 7-16 is an example of this animated window:

Figure 7-16 Add volume to BRMS pane

Note: BRMS automatically protects data that is written on previously used tape volumes.
So when a tape volume is already registered in BRMS and you try to change the volume
name or to initialize the tape volume an error message is displayed. You are then asked to
cancel the operation or to ignore the warning and continue without initializing or renaming
the tape volume.

15.Once the configuration has finished you receive a completion message where you are
asked whether you want to run the backup policy immediately, schedule it for later, or end
the configuration without further action. See Figure 7-17 for this message.
It is recommended to schedule the daily backup policy to run on different dates. This
avoids starting the backups manually every day.

Figure 7-17 New backup policy created

16.Click the Schedule button to proceed.

As we decided to allow overrides for the Backup Activity and the Media Retention (refer
back to Figure 7-8 on page 308 and Figure 7-9 on page 308), it is now possible to change
these settings. However, we have already configured the correct settings, so we do not
change anything here. Click OK to continue for both options.
There are two scheduling options. The configuration window depends on whether you are
using the Management Central Scheduler, which is the OS/400 default job scheduler or
the Advanced Job Scheduler product. See “Management Central Scheduler” on page 314,
“Advanced Job Scheduler” on page 314, and “Advanced Job Scheduler: Predefined
backup schedules” on page 315 for the appropriate configuration in your environment.

Chapter 7. Backup and recovery using BRMS/400 313

 Management Central Scheduler
See Figure 7-18 for the Management Central Scheduler configuration window.

Figure 7-18 Management Central Scheduler

These are the options you can configure for the Management Central Scheduler:
򐂰 Run the backup policy only once. You also select the date and time for the backup job.
򐂰 Run the backup policy daily. You have to select the time when you want the job to run.
򐂰 Run a weekly backup. You select the day of week and time you want the job to run.
򐂰 Run a monthly backup. You select the day of the month when you want it to run. Note that
you can either select the number of the day or the first or last day of the month.

The Summary information is updated every time you change an entry on the window.

For our example of a daily backup, check the Daily box and fill in the time of day when you
want the backups to run.

Advanced Job Scheduler

If you have the Advanced Job Scheduler installed (IBM licensed program 5722-JS1) and you
also installed the Advanced Job Scheduler plug-in to the iSeries Navigator client, your
scheduled backup jobs default to the Advanced Job Scheduler.

In this case, the New Scheduled Job window is displayed when you click the Schedule button
on the New Backup Policy - Policy Created window (shown previously in Figure 7-17 on
page 313).

Enter a name for the job on the General tab. Then select the Schedule tab to schedule your
daily backup, as can be seen in Figure 7-19.

314 Domino 6 for iSeries Best Practices Guide

 Figure 7-19 The Advanced Job Scheduler window

Here you have check boxes for the days of week and you can enter the time when you want
the job to run. You can run the backup once or schedule it periodically. In addition you can
select specific days for the backups which is needed for quarterly or yearly backups.
򐂰 For a daily backup schedule, choose the days Monday through Saturday
򐂰 For a weekly (full) backup choose Sunday

Note that selected dates are automatically highlighted in the calendar pane.

All other tabs are not specific to Domino backups, they control the job attributes, where
notification messages are sent, settings for automated recovery, and communications
settings that can be used to schedule the job remotely.

There is help text available for many functions on this window.

7.3.2 Advanced Job Scheduler: Predefined backup schedules

It is best practice to create the schedules for your backup policies in advance when using the
Advanced Job Scheduler in your environment. Doing so provides you with a default set of
schedules you can choose from when you need to schedule a backup policy in the future.

It is recommended to create default schedules for daily, weekly, monthly and yearly backups.

To prepare your schedules, do the following steps:

1. In iSeries Navigator select My Connections -> Your_System.
2. Expand your system and select the Work Management level.
3. Right-click Advanced Job Scheduler and select Properties from the context menu.

Chapter 7. Backup and recovery using BRMS/400 315

 4. On the Advanced Job Scheduler Properties window, select the Schedules tab. Click New
to create a new schedule.
5. Name the schedule and fill in the appropriate values. Note that you cannot define the time
for the jobs to run on the New Schedule window. The time is defined when you actually
use a prepared schedule to run a task.
6. Click OK to save your settings

These schedules can then be used in the future for all scheduling tasks, such as Domino
backup policy tasks or other jobs that you would like to run with the same schedule. See
Figure 7-20 for an example of the New Schedule window.

Figure 7-20 New Schedule example

7.3.3 Create backup policies for weekly, monthly, and yearly backups
As you know, a solid backup strategy consists not only of daily online incremental backups.
The next step is to create weekly, monthly, and yearly backup policies and schedule them to
run automatically.

Do not forget to also schedule the BRMS maintenance job to run daily, and print the BRMS
reports so you are prepared in case of a disaster. These jobs can also be scheduled from
iSeries Navigator.

Note that there is no backup strategy that fits all situations, so you must work out a strategy
that is best for the situation in your business. However, you can use our example as the basis
for setting up your own backup strategy.

Weekly backups
It is recommended to run full backups weekly when you run online incremental backups on a
daily base.

When setting up a weekly full backup policy you need to make the following changes from the
setup of the daily backup policy explained in “Creating a backup policy for daily online
incremental backups” on page 304:
1. The first change is in step 7 on page 308. Select Full backup instead of Changes since
last backup (see Figure 7-8 on page 308).

316 Domino 6 for iSeries Best Practices Guide

 2. The second difference is the setting for the tape media retention days in step 8 on
page 309 (Figure 7-9 on page 308). Enter 42 for weekly backups as explained in
“Retention schedule” on page 304.

Monthly and yearly backups

The monthly and yearly backups in our example backup strategy are full dedicated iSeries
system backups, that is, all Domino servers, all user jobs and subsystems are ended before
the backup jobs start to run.

You can use the default backup policy *System for the full backups or create your own. You
are not able to change the policy when using the default *System backup policy. Therefore, if
you want to run additional tasks before or after the full system backup, you should create your
own backup policy. It is best practice to use the New Based on option from the original
backup policy and only change the settings you require.

Note: Be aware that performing the Domino backup policies does not save all your system
data. You must also perform full system backups on a regular basis to be able to recover in
case of data loss.

7.3.4 Backing up additional (non-Domino) data

Our example backup strategy in 7.3, “Configuring a Domino backup strategy in iSeries
Navigator” on page 304 assumes that the iSeries system is dedicated to Domino and does
not run other applications apart from Domino for iSeries. Therefore we chose to run full
iSeries system backups only monthly.

It is important to understand that in this strategy, not all data that belongs to the Domino
environment is saved daily or weekly, such as the NOTES.INI file and the Domino program
files.

Therefore, if you want to save this additional Domino data more often or if you run additional
iSeries applications, you may want to create backup policies that run link list backups, that
save user and system libraries, or IFS objects.

You can create a backup policy that combines several iSeries objects. To do so:
1. On the select a Backup Strategy window, shown in Figure 7-5 on page 306, select Back
up a customized set of objects (see step 3 on page 305) and click Next.
2. On the following window you can choose between IBM-supplied data or User data. Select
User data and click Next to continue.
3. Now, in the Customize User Data window, as shown in Figure 7-21, you are able to select
the objects that you want to include in the backup policy.

Chapter 7. Backup and recovery using BRMS/400 317

 Figure 7-21 Customize User Data for the backup policy

Note that you can select All directories which then makes the Select Lotus servers for
online backup selection unavailable. This is because the Lotus servers will automatically
be included in the All directories backup. If you select to Exclude Lotus server online
backup items under All directories, you can again select Select Lotus servers for online
backup check box.
More configuration windows are presented when clicking Next, depending on the choices
you make on this window.

7.4 BRMS/400 concepts

This section contains some basic information on BRMS concepts such as:
򐂰 “Link lists” on page 318
򐂰 “The BRMS maintenance task” on page 319
򐂰 “Print BRMS reports” on page 320
򐂰 “Review and create move policies” on page 321
򐂰 “Media pools” on page 322
򐂰 “Adding media volumes” on page 322
򐂰 “Backup to a save file or an IBM Tivoli Storage Manager server” on page 323
򐂰 “Checklist for iSeries Navigator Domino backup configuration” on page 324

Most information in this section is again based on the iSeries Navigator interface.

7.4.1 Link lists

In order to be able to save IFS data that is not saved daily and to assist you when creating
your backup strategy, default link lists are provided by BRMS. See Figure 7-22 for the default
link lists created by BRMS:

318 Domino 6 for iSeries Best Practices Guide

 Figure 7-22 BRMS default link lists

The link lists can be used for the following purposes:

򐂰 QALLSPLF: Backs up all printed output
򐂰 QIBMLINK: Backs up all IBM directories in the IFS
򐂰 QIFSXCLLTS: Backs up the complete IFS without all Lotus data
򐂰 QLTSEXCL: Backs up the full IFS without online Lotus data
򐂰 QLTSXCLONL: Backs up all Lotus databases except the online data
򐂰 QLNKOMTLTS: Is checked by QIFSXCLLTS for items to omit
򐂰 QLNKOMTONL: Is checked by QLTSEXCL for items to omit
򐂰 QLTSOMTONL: Is checked by QLTSXCLONL for items to omit

The fact that some of these link lists are checked by other link lists during execution allows
users to add their own omit entries to the dynamic lists. For instance, any entry in
QLNKOMTONL will be omitted from the backup when the QLTSEXCL list is executed. An
example of a file to include in QLNKOMTONL is the NOTES.INI file. This provides the
possibility to run the QLTSEXCL list with the Domino servers up and running. Note that the
dynamic lists are updated by BRMS when the Domino configuration has changed and the
maintenance job runs.

The new lists must not be added to any other list, they are static, and any omit entries are
automatically picked up by the dynamic lists:
򐂰 The entries in the QLNKOMTLTS list are added to the QIFSXCLLTS list
򐂰 The entries in the QLTSOMTONL list are added to the QLTSXCLONL list
򐂰 The entries in the QLNKOMTONL list are added to the QLTSEXCL list

For more information about what is included and excluded in the omit lists, see “How to
initialize BRMS” at:
http://www.ibm.com/servers/eserver/iseries/service/brms/dominitbrm.htm

7.4.2 The BRMS maintenance task

Running the maintenance task updates BRMS with the latest configuration information.
Therefore it is best practice to immediately run the BRMS maintenance task after you
configured additional Domino servers or removed Domino servers from your iSeries system.
It is also best practice to schedule the BRMS maintenance task to run once a day, for instance
one hour after the backups have run. Note that there must not be any BRMS backup task
running when the maintenance task is started.

To start or schedule the BRMS maintenance task in iSeries Navigator, select Perform
maintenance and cleanup from the Backup, Recovery and Media Services Tasks pane
(right bottom section) on the Series Navigator window shown in Figure 7-1 on page 301.
Figure 7-23 shows the Run Maintenance Options - Media tab.

Chapter 7. Backup and recovery using BRMS/400 319

 Figure 7-23 BRMS Run Maintenance Options

As you can see, the maintenance task also takes care of expiring media, running move
policies, etc. In addition, the backup history and backup log entries are deleted, and several
reports are created, including the disaster recovery report.

7.4.3 Print BRMS reports

The BRMS maintenance job not only cleans up old data and performs tape volume moves if
selected, it also creates database files containing information about where the data is stored.
When you use the BRMS print reports option, data from these databases is placed in output
queues from which you can then print the information. This provides you with the information
needed to restore all data in case of a disaster.

Select Print reports from the Backup, Recovery, and Media Services Tasks pane (right
bottom section) on the Series Navigator window shown in Figure 7-1 on page 301. You can
then select which reports to print, as shown in Figure 7-24.

When you select to print the Disaster recovery report, BRMS creates a recovery list that
guides you through all steps needed to perform a full system recovery. Make sure that you
obtain the printout of this list daily. In addition, if you have a network printer connected, or a
remote system, we advise to send the output to a remote printer. It is best practice to
schedule the print jobs to run on a daily basis, so you will have the necessary information
available, in case disaster recovery might be needed.

Note: The Disaster recovery report does not show the steps needed for recovering a
system when you used save files or to an IBM Tivoli Storage Manager server. This is so
because you cannot back up an entire system to save files or an IBM Tivoli Storage
Manager server. Refer to the redbook iSeries Tivoli Storage Manager and Backup
Recovery and Media Services Integration: a Unique Combination, SG24-7031 for more
information.

320 Domino 6 for iSeries Best Practices Guide

 Figure 7-24 Select reports to print

7.4.4 Review and create move policies

You can use move policies to configure a move scenario for the media pools if you want
BRMS to help you in keeping track of where your tapes are located. The only move policy that
is automatically created is the OFFSITE move policy.

To access the Move Policies, select My Connections -> Your_System -> Backup,
Recovery and Media Services -> Move Policies or expand the Movement tasks in the
Backup, Recovery and Media Services Tasks pane. See Figure 7-25 for an example of the
move policies properties.

Figure 7-25 Move policy properties

Chapter 7. Backup and recovery using BRMS/400 321

7.4.5 Media pools
Before you can add new media to BRMS, there must be a media pool to add it to. Media pools
are automatically created when you install BRMS or when the BRMS maintenance job runs.
BRMS finds all devices capable of handling a certain type of media, then creates a media
pool for each type. Remember, one of the steps when creating a backup policy is to select the
media pool that will be used for this backup policy.

To create a new media pool manually, select My Connections -> Your_System -> Backup,
Recovery and Media Services -> Media -> Media Pools. Right-click an existing media pool
and select New based on. This results in the window shown in Figure 7-26.

Figure 7-26 Add media pool

Enter a name for the pool and select the desired Density from the drop-down box. Note that
you can also select whether to use the media capacity that is associated with the density of
the media in this pool or you can type in the maximum capacity manually.

Clicking the Advanced box allows you to (optionally) store additional information for this
media pool, such as the manufacturer, part number of the media type, and information on
where the tape media was obtained from.

7.4.6 Adding media volumes

When you open the Media option in the BRMS section of iSeries Navigator you can access
not only the Media Pools but also the Tape Volumes.

Right-clicking Tape Volumes allows you to add media to any media pool. Select Add to
launch the Add Media wizard. All available media pools are displayed as can be seen in
Figure 7-27.

After selecting a media pool you are able to add the tape volumes. This involves exactly the
same tasks as when adding tape volumes to a media pool during the creation of a backup
policy. Therefore, please refer to steps 11, 12, and 13 on page 312 and the related figures.

322 Domino 6 for iSeries Best Practices Guide

 Figure 7-27 Add media to media pool

7.4.7 Backup to a save file or an IBM Tivoli Storage Manager server

When you want to use a save file or an IBM Tivoli Storage Manager server for your backups,
you must first create a backup policy and configure it using a tape device for the backups.
Then, in a second step, you need to change this backup policy for the save file or the IBM
Tivoli Storage Manager server.

To change a backup policy, double-click it in the Backup Policies pane (upper right in the
iSeries Navigator window) which opens the Backup Policy properties. Then click the During
button. This displays the During Backup window. Select the Where tab to select the backup
media. The Where tab is shown in Figure 7-28.

In addition, you can find tabs for the Media, Save File, and TSM Server Retention settings as
well as the Activity tab.

Chapter 7. Backup and recovery using BRMS/400 323

 Figure 7-28 Backup Policy properties - During Backup settings

You can now select a Save file or a TSM server from the Where to back up drop-down menu
for this backup policy. The configurable settings change depending on your selection:
򐂰 When you select to back up to a save file you also have the option to specify the storage
pool where the data should be stored and disk pool storage limits. In addition, if you
decide to allow the backup of save files to tape media, you can also configure the Media
Devices Settings for saving the save files to tape.
򐂰 If you select to use an IBM Tivoli Storage Manager server for the backups, you can select
the server name, connection names, and storage locations. In addition, you can use the
Manage TSM Servers button and edit information for configured servers or add
configurations for additional IBM Tivoli Storage Manager servers.

See the help text for more information on the different objects and choices.

7.4.8 Checklist for iSeries Navigator Domino backup configuration

The following is a list of the tasks you have to perform in order to set up your BRMS Domino
backup environment:
1. Decide on your backup strategy according to your company’s needs and the capabilities of
your backup devices.
2. Install the BRMS software on the iSeries system and iSeries Access for Windows with the
iSeries Navigator client on your PC.
3. Configure a connection for every iSeries system that hosts your Domino server(s) and
BRMS in the iSeries Navigator client window.

324 Domino 6 for iSeries Best Practices Guide

 4. Verify that the automatically created backup policies match your Domino server
configuration. Run the BRMS maintenance task if you do not find backup policies for the
Domino server(s) that exist on your system.
5. Use the automatically created backup policies or create your own backup policies to
configure your daily, weekly, monthly, and yearly backups for the backup strategy you
decided upon in step 1 on page 324.
6. Check the available media pools and add new ones if desired.
7. Add media volumes to BRMS, using the available media pools or media pools you added.
8. Reconfigure your backup policy if you want to use a save file or an IBM Tivoli Storage
Manager server instead of a tape device or a tape library.
9. After completing the configuration, schedule both the maintenance task and the print
reports task to run daily.
10.Schedule the backup policies, according to your backup strategy, in the Management
Central Job Scheduler or the Advanced Job Scheduler.
11.Perform a test run of all backup policies and scheduled jobs to make sure that all jobs run
error free.

7.5 Tips and troubleshooting iSeries Navigator backups

This section provides some tips for using iSeries Navigator as well as a few tips on
troubleshooting your BRMS Domino backups. For additional troubleshooting information, also
regarding the OS/400 commands approach, please see 7.7.7, “Tips and troubleshooting” on
page 348 in this chapter.

7.5.1 Tips for iSeries Navigator backups

Here we offer some tips for your backup operations:
򐂰 Be patient when using the iSeries Navigator client.
You may have started a long running task where the iSeries Navigator window is not
updated for a long time. In addition, the iSeries Navigator client is a graphical user
interface, which is more dependent on network performance than 5250 emulation
sessions because more data is transferred over the network. After having worked with the
iSeries Navigator client for a while, you will get a feeling for the performance of the client in
your environment. Avoid clicking multiple buttons or selections while waiting for the next
window to be displayed.
򐂰 It is recommended to run an incremental backup just before the full backup when
performing daily incremental and full online weekly backups.
The reason for this is that you lose the point in time recovery possibility between the last
incremental and the full backup. Since the transaction log files are attached to the next full
backup, they cannot be used by the previous full backup any more.
򐂰 Make sure that you select a limited period of time when displaying the backup and
recovery log.
If you select all dates and all times, there may be hundreds of lines to browse through.
This might take a long time depending on your network, for example when using a slow
dial-up connection.
򐂰 Run a full recovery test at least once every year so you are sure that your backup and
recovery procedures are reliable.

Chapter 7. Backup and recovery using BRMS/400 325

 򐂰 Do not switch between the iSeries Navigator and the OS/400 command interface
approach.
As mentioned earlier, it is best practice to stay with the iSeries Navigator interface once
you have started to use it because changing backup control groups or other configuration
changes in the OS/400 environment while having scheduled backups in iSeries Navigator
is confusing and might cause errors.

7.5.2 Troubleshooting tips for Domino backup and recovery

Here are some tips for your backup and recovery operations:
򐂰 You are able to monitor the status of the job in Management Central after you started a
backup policy from iSeries Navigator. Either in the Task Activity section or in the
Scheduled Tasks section - depending on whether you selected to run the task immediately
or whether you scheduled the task. Use F5 to refresh the window when checking the
status of the job in Management Central.
򐂰 Use a 5250 emulation session when you suspect an error in the backup job but you are
not able to find the error while using the iSeries Navigator client.

7.6 Restoring Domino databases with iSeries Navigator

The iSeries Navigator offers the possibility to restore Domino databases through the Restore
Wizard. This provides a step by step approach to restore Domino data, with many help panels
to guide you through the restore process. In addition, you can also schedule the restore
process, so it can take place when the restore resources are available or when it fits in the
daily production routines. This is how you start the restore process in iSeries Navigator:
1. Select Restore iSeries data from the Backup, Recovery and Media Services Tasks pane
(right bottom section) on the Series Navigator window shown in Figure 7-1 on page 301.
2. Click Next twice to skip the help text window and to select the default setting of Restore
using backup history. This brings you to the Select Type of Information window shown in
Figure 7-29.

Figure 7-29 Select type of information to restore

326 Domino 6 for iSeries Best Practices Guide

3. Select A directory or its files and click Next to proceed to the window where you can
specify the path of the directory you want to restore. See Figure 7-30. Note that you can
browse the backup history for saved directories to find the path of the object that you want
to restore.

Figure 7-30 Select the directory to be restored

4. Once you have selected the path click Next to select the version of the data you want to
restore. You can restore the most current version, select a date and time, or choose just a
date. First you select a date to restore then you can choose the time. See Figure 7-31.
Clicking the Details button displays the release of the objects to be restored, the backup
policy used, the size of the objects, and a lot more information about the objects.

Figure 7-31 Select the date of the save

Chapter 7. Backup and recovery using BRMS/400 327

 5. Click Next. The following window, as shown in Figure 7-32, gives you the choice to
restore:
– The entire directory including all files (Domino databases)
– Selected files from the directory
– The directory only

Figure 7-32 Restore directory or select files

6. Choose Select files in the directory to restore and click Next. You are now able to
select the database file(s) from a list as shown in Figure 7-33. After selecting the
appropriate file(s) click Next once again.

Figure 7-33 Select files to restore

7. The following two windows provide the possibility to restore the file with a different name,
or to a different location, or both.

328 Domino 6 for iSeries Best Practices Guide

 8. On the last window, as shown in Figure 7-34, you can choose to perform the restore
operation immediately (by clicking Finish) or schedule it for later.

Figure 7-34 Restore summary

Note that in this example there are no Volumes needed for the restore operation. This is
due to the fact that this backup was performed to an IBM Tivoli Storage Manager server.
If the data would reside on a tape rather than on an IBM Tivoli Storage Manager server,
the volume(s) to be loaded would be listed in the Volume box.

7.7 Quickstart for using OS/400 commands

There is plenty of information available for using BRMS in the OS/400 command
environment. However, this information is spread across various books and on the Web. This
section provides a quickstart reference for setting up Domino backups using the OS/400
BRMS commands, combining the information available in the different sources.

We discuss the following topics:

򐂰 “How BRMS objects relate” on page 329
򐂰 “Initialize BRMS” on page 330
򐂰 “Objects created by default” on page 331
򐂰 “Customizing the BRMS defaults” on page 333
򐂰 “Review and customize the setup” on page 334
򐂰 “Domino backups in a 24x7 environment” on page 344
򐂰 “What happens when BRMS runs Domino backups” on page 344
򐂰 “Domino restore methods” on page 347
򐂰 “Tips and troubleshooting” on page 348

7.7.1 How BRMS objects relate

It is easy to get confused about how all objects relate to each other when you first start
working with BRMS. As some configuration objects share the same parameters, it may not
always immediately be clear which setting prevails over another.

Chapter 7. Backup and recovery using BRMS/400 329

 Please refer to 7.1.4, “BRMS/400 entities” on page 297 for an introduction to the various
BRMS objects.

The policies are very important, as they describe the way how BRMS will act on the objects
that the specific policy is used for. As an example, let us look at the backup control group
level, where you can see the control group attributes. You can choose to point to the backup
policy (*BKUPCY), or to the system policy (*SYSPCY), or you can choose a policy you
created yourself for the Media policy parameter in the control group attributes.

When browsing through the options and parameters you will notice that many of them have
the backup policy (*BKUPCY) as the default setting. This means, that when you use this
control group for your backups, the settings in the backup policy define which value is really
used for that parameter. However, the value for that parameter in the backup policy may well
be *SYSPCY, so BRMS takes the value from the system policy instead.

If BRMS is new for you, you definitively want to keep a clear overview of the configuration. In
this case, it is best practice to not leave the defaults in the parameters referring to the backup
or system policies, but to alter the values to actual objects of your own choice.

BRMS does not check for typing errors for all parameters and as typing errors might cause
your backups to fail, it is recommended to use the F4 key to prompt for available values
whenever possible.

If you want to automate a backup process for which you created a control group, add the
control group to the iSeries Job Scheduler. You can use option 6 (Add to schedule) on the
Work with Backup Control Groups (WRKCTLGBRM) screen to do this. Again, to avoid typing
errors, we advise not to add the backup job to the job scheduler manually.

In addition to the backup jobs, we advise you also schedule the BRMS maintenance job and
the Print BRMS reports job on a daily basis. The maintenance job must not run while backups
are running, so it is good practice to schedule it after the daily backups have finished. This job
cleans up old BRMS logs and keeps the BRMS configuration up-to-date with any changes. In
addition, this job creates BRMS information data in several databases that can be printed
using the Start Recovery using BRM (STRRCYBRM) command with parameter
ACTION(*REPORT) - which is the default setting for this parameter.

Notes:
򐂰 To start working with BRMS, type GO BRMS.
򐂰 To find all commands related to BRMS, type GO CMDBRM.

7.7.2 Initialize BRMS

You can start to set up your BRMS backups after the BRMS licensed program is installed, the
PTFs are applied, and your Domino environment is configured.

The first thing to do is to initialize BRMS. Initializing BRMS automatically finds the available
system resources, such as tape devices, for the BRMS environment and creates the default
BMRS objects. Control groups for Domino backups are automatically generated if Domino
servers exist on the system when BRMS is initialized.

After adding or removing one or more Domino servers, the BRMS configuration needs to be
updated by running one of the initialization commands. To perform the initialization again
after you changed your Domino server configuration, enter one of the following commands:

330 Domino 6 for iSeries Best Practices Guide

򐂰 INZBRM OPTION(*DATA)
򐂰 STRMNTBRM

Running either one of these commands automatically detects the Domino servers and
creates the necessary objects in BRMS that allow you to set up a backup strategy for your
Domino environment.

Objects created by default

After running one of the BRMS initialization commands, the following objects exist on your
system. You can use the listed OS/400 commands to verify the objects.
򐂰 Default system backup control groups (WRKCTLGBRM *BKU or WRKCTLGBRM):
– *BKUGRP
– *SYSGRP
– *SYSTEM
򐂰 BRMS control groups for backing up Domino servers separately, for example:
– QLTSDOM00
– QLTSDOM01
– QLTSDOM02
– QLTSDOM03
򐂰 A single BRMS control group to back up all Domino servers in sequence:
– QLTSSVR
򐂰 Two empty *EXIT entries in the first and last position in the Domino backup control groups.
These pre- and post-processing exits are needed for Domino BRMS backups to run
correctly.
򐂰 Media policies, including one for Domino backups (WRKPCYBRM *MED):
– ARCHIVAL
– FULL
– INCR
– QLTSSVR
– SAVF
– SAVSYS
– SYSTEM
򐂰 Storage Locations. There are default entries for tape libraries or an IBM Tivoli Storage
Manager server if they are available on the system (WRKLOCBRM):
– *HOME
– VAULT
– TAPMLB01
– TIVSVR
򐂰 Containers (WRKCLSBRM *CNR):
– If Containers are used for your tapes, the classes can be added here.
򐂰 Devices that can be used by BRMS (WRKDEVBRM), for example:
– TAP01
– TAP02
– TAP03
– TAP04
– TAPMLB01 (for a tape library)

Chapter 7. Backup and recovery using BRMS/400 331

 򐂰 Media classes for the media formats of the devices (WRKCLSBRM *MED):
– QIC1000
– QIC120
– QIC150
– QIC2DC
– QIC2GB
– QIC5010
– QIC525
– SAVSYS
򐂰 Move policy (WRKPCYBRM *MOV):
– OFFSITE
򐂰 The system policy (WRKPCYBRM *SYS)
Entering the WRKPCYBRM *SYS command displays the options to work with the system
policy. You need to verify and change some of these settings. Figure 7-35 shows these
options.

BRMSYSPCY System Policy

System: AS25
Select one of the following:

1. Display or Change system policy

2. Work with sign off exceptions
3. Work with subsystems to check before IPL
4. Change network group
5. Change presentation controls
6. Change notification controls
7. Change IPL controls
8. Display log

Selection or command
===>

F3=Exit F4=Prompt F9=Retrieve F10=Commands F12=Cancel F13=Functions

Figure 7-35 WRKPCYBRM *SYS

Note: The BRMS system policy has the following default settings that should be
checked and changed if necessary before you start using BRMS for backups:
򐂰 Output queue: If possible, it is better to send the BRMS reports to a remote output
queue at a secure location.
򐂰 Day start time: This value also affects the media and control groups.
򐂰 Change presentation controls (option 5): Make sure the presentation controls are
equal to your defaults.
򐂰 Change IPL controls (option 7): Check the earliest and latest time to allow an IPL. If
set incorrectly, your system may not perform an IPL when you planned it to happen.

332 Domino 6 for iSeries Best Practices Guide

 򐂰 The default backup policy (WRKPCYBRM *BKU):
The backup policy shows the default parameters that are used for BRMS backups that use
*BKUPCY as parameter values in their configuration. Note that by default the backup
policy specifies *SYSPCY for some parameters, so actually the values from the system
policy are used.
򐂰 The recovery policy (WRKPCYBRM *RCY):
The recovery policy contains the values that are used during recovery processes. By
default, the parameters are set to use the same values as were used during the save
operation of the object.
򐂰 Various exclude lists (WRKLBRM):
– QALLSPLF
– QIBMLINK
– QIFSXCLLTS
– QLNKOMTLTS
– QLNKOMTONL
– QLTSEXCL
– QLTSOMTONL
– QLTSXCLONL

Note: V5R2M0 PTF SI07016 (or later) provided additional exclude lists. The list above
is based on this PTF level.

7.7.3 Customizing the BRMS defaults

After you have initialized BRMS and created the default objects you should review your
company’s backup strategy to implement BRMS in a way that meets these requirements.
Don’t forget that national laws may require special media retention periods for legal and/or tax
reasons. Although many of the default objects, such as the control groups, can be used right
away for backups, they can only be a starting point for your own implementation.

We now explain how to configure the following backup strategy as an example of a possible
solution:
򐂰 The Domino servers are saved daily through online incremental backups. This means that
the Domino servers stay active during the backups, the users can continue working, and
only changes are saved.
򐂰 Then, during the weekends, a full online backup of the Domino servers is performed. This
again means that the Domino servers are active and the users can continue working.
򐂰 Once a month the entire OS/400 system is backed up in a restricted state, so all Domino
servers are ended, and, in addition to the weekly backup, also the operating system and
all licensed programs are saved.
򐂰 The yearly backup is equal to the monthly backup, that is, all data from the system is
saved. The difference is that the retention period for the tape media is five years.
򐂰 Additionally, a control group is created that allows to perform an operating system backup
just before any change is done to the iSeries operating system, such as installing PTFs or
a new OS/400 release.

Chapter 7. Backup and recovery using BRMS/400 333

 Attention:
򐂰 Together with the control groups specifically created for Domino, three additional control
groups are automatically created to back up OS/400 data (*BKUGRP, *SYSGRP, and
*SYSTEM). Although they are useful for backups, they are not specifically created for a
Domino environment. When backing up Domino databases with a *LINK list, as in the
*BKUGRP and the *SYSTEM control groups, make sure that the Domino servers are
ended. The *LINK entry causes error messages when it tries to save databases that are
in use.
򐂰 Make sure you never use the OS/400 SAV command to back up Domino databases in
the IFS while the Domino server is active. This will very likely result in corrupted
databases.

You can schedule the control group entry backups in the iSeries Job Scheduler, or, when
available, in the Advanced Job Scheduler (5722-JS1).

After configuring BRMS according to your needs, the first thing you should do is to perform a
full backup of your system. Use the STRBKUBRM CTLGRP(*SYSTEM) command to let
BRMS know that all objects were saved once.

The second important step is to make sure that all backup control groups run error free. You
rely on the automated backups in the future so it is important that you make sure that all data
is saved and that you are able to restore the saved objects and recover the Domino
environment. Make sure you test all control groups before going into production.

To check if a BRMS backup procedure has completed successfully, use the Display Log for
BRM (DSPLOGBRM) command to display the BRMS job log. Note that by default you only
see the messages of the current date displayed. However, you can change the date to display
BRMS logs from other days.

Data other than Domino

Your iSeries system might not be dedicated to run only Domino servers, there might be other
applications that change data on the system. So in addition to backing up the Domino data
you should also backup this user data, and, in any case (whether the system is dedicated to
Domino or not), all iSeries operation system objects that might change daily/often. This could
be user profiles, configuration data, and user libraries.

See Backup, Recovery and Media Services Version 5, SC41-5345-03 for more information on
backing up system and user data.

Note: It is important that you do not replace your full system backups with only Domino
server backups.

Apart from the Domino server databases, there are other important Domino server objects,
such as libraries, Domino server data in the IFS, and other system data that should be
saved on a regular basis.

When a full disaster recovery of your iSeries system is required, you absolutely need a
recent full system backup to start rebuilding the system.

Review and customize the setup

After you have initialized BRMS and decided on the backup strategy, you should review the
current configuration settings before you start to back up your Domino servers. Check the
setup and customize where needed to meet your company’s or system backup requirements.

334 Domino 6 for iSeries Best Practices Guide

Review or configure the following configuration items:
򐂰 The system, backup, and recovery policies:
The default values for the BRMS environment are taken from these policies. Use the
commands:
WRKPCYBRM *SYS
WRKPCYBRM *BKU
WRKPCYBRM *RCY
򐂰 The move policies:
The Home location parameter tells BRMS where to put the tape after it completes all its
moves. You must start with modifying the move policies, as the parameters in the media
policies refer to them. To change the move policies, use the command:
WRKPCYBRM *MOV
We do not further describe the configuration of move policies, as they are not needed for a
quickstart to BRMS. For more information on configuring move policies, refer to chapter 6
of the manual Backup, Recovery and Media Services Version 5, SC41-5345-03.
򐂰 The link lists:
When using a link list, you can configure whether Domino database objects should be
included or excluded from your backups. In addition, you can create link lists for other IFS
objects that you want to be backed up, such as Domino ID files that you stored in a
directory apart from the Domino data directory, or non-Domino objects. Before going into
production, you must test the backups, including the link lists, as it is easy to make typing
mistakes. In addition, other objects from applications like Websphere or HTTP servers
may cause locks for objects in link lists.
See 7.4.1, “Link lists” on page 318 for a complete list of link lists (and their purpose and
possibilities) created during BRMS initialization. Deleted default link lists are automatically
recreated when the BRMS maintenance job runs.
Note that in our sample backup strategy we run an entire system save once a month. This
includes data such as the NOTES.INI or ID files. Therefore we do not use link lists in our
example to include or omit data. However, if you change the configuration of your Domino
servers more often (so files like the NOTES.INI files change often), you may want to
change the Domino backup strategy to make sure to save those files more frequently.
򐂰 The media policies:
BRMS checks the Storage location parameter in the media policy to find out where to get
the tape for the backup. This parameter is set to *ANY by default. It is typically used when
when multiple types of tape media are available. To alter the settings of the media policies
or create your own use the command:
WRKPCYBRM *MED
Another important parameter in the media policies is the retention period for the media.
For our sample backup strategy we use:
– 35 days for daily backups
– 42 days for weekly backups
– 365 days for monthly backups
– 1825 days for yearly backups
It is important that tapes containing backups do not expire before all data on them is no
longer needed. The retention periods we chose for our strategy ensure that for all periods.
Note that in your company you may need to configure longer retention periods.

Chapter 7. Backup and recovery using BRMS/400 335

 It is a good practice to name the media policies according to their purpose. This allows for
easier administration and use. For example, BRMSWEEK for weekly backups and
BRMSMONTH for the monthly backups.
Figure 7-36 shows our weekly media policy as an example.

Display Media Policy

Media policy . . . . . . . . . . : BRMSWEEK

Retention type . . . . . . . . . : 2 1=Date, 2=Days,
3=Versions, 4=Permanent
Retain media . . . . . . . . . : 42
Move policy . . . . . . . . . . : *NONE
Media class . . . . . . . . . . : *SYSPCY
Storage location . . . . . . . . : *ANY
Save to save file . . . . . . . : *NO
ASP for save files . . . . . . : *SYSTEM
Save file retention type . . . : 4 1=Date, 2=Days,
3=Permanent, 4=None
Retain save files . . . . . : *NONE
ASP storage limit . . . . . . : *SYS
Secure media . . . . . . . . . . . *NO
Text . . . . . . . . . . . . . . : Media Policy for Weekly Backups

Press Enter to continue.

More...
F3=Exit F12=Cancel

Figure 7-36 The weekly media policy

򐂰 Review and create backup control groups:

You can use the automatically created control groups or create your own. The BRMS
initialization procedure creates default control groups for you, however, separate control
groups for Domino and for the remaining system objects are created. So you might want to
combine them into newly created control groups. The command to launch the Work with
Backup Control Groups menu is:
WRKCTLGBRM
Note that the automatically created control groups refer back to the backup policy, so you
need to check the Default weekly activity parameter in the backup policy for the actual
value.
Again, it is good practice to name the control groups according to their purpose, just like
the media policies.
You are able to end and restart subsystems or job queues before and after your backups.
This can individually be defined for each control group using option 9 (Subsystems to
process) on the Work with Backup Control Groups menu.

Important: Make sure you never end a Domino server subsystem when the server is
still active when configuring a control group to include the ending of subsystems.

Ending the subsystem of an active Domino server is equal to a forced power down on
other platforms and may cause database corruptions on your Domino server.

336 Domino 6 for iSeries Best Practices Guide

 For our sample Domino backup strategy you need to create the following control groups:
– BRMSDAY
For the daily backups, performs an online incremental backups of the Domino servers.
– BRMSWEEK
Performs an incremental backup of all Domino servers followed by a full online backup.
– BRMSMONTH
Performs a backup of the entire OS/400 system or LPAR in restricted state.
– BRMSYEAR
Runs the same backup as BRMSMONTH but the retention period of the tape media is
longer.
– BRMSSYS
Is intended for full LPAR or OS/400 system backups, just before and right after applying
PTFs.

Note: You may choose to perform an online incremental backup of the Domino servers
daily, and an equal but full online backup during the weekends. In this case it is not
needed to use separate control groups, as the weekly backups can be added to the
daily backups with an F entry in the Weekly Activity parameter. You may want to change
the name of the control group to something like DOMBCKUP to reflect its purpose.

Table 7-2 shows the backup schedule. F stands for a full backup and I for an incremental
backup in the Weekly Activity column.

Table 7-2 Backup schedule

Control Group Full Media Incremental Weekly Activity Description
Policy Media Policy SMTWTFS

BRMSDAY BRMSDAY BRMSDAY I I I I I I Daily Backup

BRMSWEEK BRMSWEEK BRMSWEEK F Weekly Backup

BRMSMONTH BRMSMONTH BRMSMONTH F Monthly Backup

BRMSYEAR BRMSYEAR BRMSYEAR F Yearly Backup

BRMSSYS BRMSSYS BRMSSYS F SAVSYS

These control groups look as follows:

– BRMSDAY:
The daily backup is an incremental backup which runs on weekdays from Monday to
Saturday.
See Figure 7-37 for details. Note that the Default activity parameter values ( I I I I I I)
reflect the days of the week, starting on Sunday (which is blank).

Chapter 7. Backup and recovery using BRMS/400 337

 Edit Backup Control Group Entries AS25

Group . . . . . . . . . . : BRMSDAY
Default activity . . . . . IIIIII
Text . . . . . . . . . . . Incremental online backup of all Lotus servers

Type information, press Enter.

Backup
Seq Items Exit command

10 *EXIT
20 *EXIT QNOTES/SAVDOMBRM SERVER('PROJECTS') CTLGRP(BRMSDAY)
30 *EXIT QNOTES/SAVDOMBRM SERVER('DOMAV') CTLGRP(BRMSDAY)
40 *EXIT QNOTES/SAVDOMBRM SERVER('DOMBRMS') CTLGRP(BRMSDAY)
50 *EXIT QNOTES/SAVDOMBRM SERVER('DOMCLUS2') CTLGRP(BRMSDAY
60 *EXIT QNOTES/SAVDOMBRM SERVER('DOMTDP') CTLGRP(BRMSDAY)
70 *EXIT

Bottom

F3=Exit F5=Refresh F10=Change item F11=Display main F12=Cancel

Figure 7-37 BRMSDAY control group

– BRMSWEEK:
In our example the BRMSWEEK control group runs an incremental online backup,
followed by a full online backup of all Domino servers on Sundays. The control group is
basically equal to the daily backup. The difference is in the Default activity parameter
where you only configure the F for the full backup on Sundays. See Figure 7-38.

Group . . . . . . . . . . : BRMSWEEK
Default activity . . . . . F
Text . . . . . . . . . . . Full online backup of all Lotus servers

Figure 7-38 BRMSWEEK control group

Important: When performing daily online incremental backups and weekly full backups,
you need to be aware of the following considerations.

There is no possibility to restore to a point in time that lies between the last incremental
backup and the next full backup. So to make sure you can restore to a point in time also for
the day that lies between the last incremental and the full backup, it is recommended to
take an additional incremental backup just before the full backup. The reason for this is that
the transaction logs are “attached” to the full backup.

We recommend that you create one control group entry per Domino server with all I’s for a
daily incremental backup, and a second line for the same Domino servers with an F for a
full backup on the days you want a full backup taken. An example of this is shown in
Figure 7-39. Note that the exits at lines 10 and 40 are empty, and the exits at lines 20 and
30 apply to the same Domino server. The Default activity (F) is ignored when actual values
are filled in for the Weekly Activity.

338 Domino 6 for iSeries Best Practices Guide

 Display Backup Control Group Entries AS25

Group . . . . . . . . . . : ALLDAYS
Default activity . . . . : F
Text . . . . . . . . . . : Backup user data except online Domino data

Auxiliary Weekly Retain Save SWA

Backup List Storage Activity Object While Message
Seq Items Type Pool Device SMTWTFS Detail Active Queue
10 *EXIT *DFTACT
20 *EXIT IIIIIII *NO
30 *EXIT F *NO
40 *EXIT *DFTACT

Bottom
Press Enter to continue.

F3=Exit F11=Display exits F12=Cancel

Figure 7-39 Control group for full backup after incremental backup

– BRMSMONTH:
The BRMSMONTH control group first ends the Domino servers, then makes a full
backup of all iSeries system data followed by an IPL.
One of the first jobs during a full system backup is to end all subsystems on the iSeries
system. As mentioned earlier, ending the subsystem of an active Domino server may
result in corrupted databases.
BRMS assists you to fully automate your backups, so you probably don’t want to end
the Domino servers manually before a monthly backup. Therefore you can add an
entry to the control group where a program is started to end the Domino servers
gracefully. It is strongly advised to do so!
Ending Domino servers with the default ENDDOMSVR *CNTRLD command does not
always immediately end the servers. For example, a server is not ended as long as a
replication (which could be a nightly maintenance task) runs. For that reason, you
should create a program that ends all servers gracefully. Such a program ends the
servers in a controlled parameter, checks for active jobs in the Domino subsystems,
and ends the Domino subsystems after all jobs in the appropriate subsystems have
ended. To avoid that a backup cannot run because of a Domino server shutdown
problem you can add the command to immediately end the Domino servers after a
certain wait time to this program. It is recommended to perform several shutdown tests
at the time when the backup normally runs to find out the correct wait time. Make sure
that you test the program before using it in a production environment.
An example of a Control Language (CL) program that ends all servers gracefully is the
EndDominoServers.txt file provided in Appendix D, “Additional material” on page 611 .
Such an exit in the control group looks as follows:
20 *EXIT CALL PGM(QGPL/ENDDOMINO)
The monthly and yearly backup also includes the sign off of interactive users.
You can use the appropriate parameter in the control group attributes to send a
warning message to interactive users so they know that the backup is about to start.
See Figure 7-40 where the Sign off interactive users parameter is set to *YES, and the
Sign off limit is set to 15 minutes.

Chapter 7. Backup and recovery using BRMS/400 339

 Change Backup Control Group Attributes

Group . . . . . . . . . . . . . . . . : BRMSMONTH

Type information, press Enter.

Media policy for:

Full backups . . . . . . . . . . . . . BRMSMONTH Name, F4 for list
Incremental backups . . . . . . . . . BRMSMONTH Name, F4 for list
Backup devices . . . . . . . . . . . . . TAP01 Name, F4 for list

Parallel device resources:

Minimum resources . . . . . . . . . . *NONE 1-32, *NONE, *AVAIL
Maximum resources . . . . . . . . . . 1-32, *AVAIL, *MIN
Sign off interactive users . . . . . . . *YES *YES, *NO, *BKUPCY
Sign off limit . . . . . . . . . . . . . 15 0-999 minutes, *BKUPCY
Default weekly activity . . . . . . . . F SMTWTFS(F/I), *BKUPCY
Incremental type . . . . . . . . . . . . *BKUPCY *CUML, *INCR, *BKUPCY

More...
F3=Exit F4=Prompt F12=Cancel

Figure 7-40 Monthly backup control group attributes

The users will receive a message that tells them that the backup is about to begin. The
message is sent every five minutes, where the timer is counted back to zero, and when
a user is still signed on at that time, the system ends the user job.
You receive the following message:
Please sign off within 05 minutes to allow backups to process.
Figure 7-41 shows the entries in the BRMSMONTH control group. Note the *EXIT
entry on position 20, where the Domino servers are ended with a CL program.
Apart from this *EXIT entry, the control group is equal to the automatically generated
*SYSTEM control group.

340 Domino 6 for iSeries Best Practices Guide

 Display Backup Control Group Entries AS25

Group . . . . . . . . . . : BRMSMONTH
Default activity . . . . : F
Text . . . . . . . . . . : Backs up the entire system

Auxiliary Weekly Retain Save SWA

Backup List Storage Activity Object While Message
Seq Items Type Pool Device SMTWTFS Detail Active Queue
10 *EXIT *DFTACT
20 *EXIT *DFTACT
30 *SAVSYS *DFTACT
40 *IBM *DFTACT *NO *NO
50 *ALLUSR *SYSBAS *DFTACT *ERR *NO
60 *ALLDLO *DFTACT *NO *NO
70 *LINK *ALLAVL *DFTACT *YES *NO
80 *EXIT *DFTACT
Bottom
Press Enter to continue.

F3=Exit F11=Display exits F12=Cancel

Figure 7-41 BRMSMONTH control group

– BRMSYEAR:
The BRMSYEAR control group is equal to the BRMSMONTH control group, only the
retention period of the media policy BRMSYEAR is set to 1825 days.
– BRMSSYS:
Figure 7-42 shows the control group BRMSSYS, where the system data is saved, and
which may be used before and after applying PTFs. Again, note the *EXIT entry at
position 20 where the Domino servers are ended gracefully, this is needed as a
SAVSYS operation ends all subsystems.

Chapter 7. Backup and recovery using BRMS/400 341

 Edit Backup Control Group Entries AS25

Group . . . . . . . . . . : BRMSSYS
Default activity . . . . . *BKUPCY
Text . . . . . . . . . . . Backs up all system data

Type information, press Enter.

Auxiliary Weekly Retain Save SWA

Backup List Storage Activity Object While Message
Seq Items Type Pool Device SMTWTFS Detail Active Queue

10 *EXIT *DFTACT
20 *EXIT *DFTACT
30 *SAVSYS *DFTACT
40 *IBM *DFTACT *NO *NO
50 *EXIT *DFTACT

Bottom
F3=Exit F5=Refresh F10=Change item
F11=Display exits F12=Cancel F24=More keys

Figure 7-42 BRMSSYS control group

There are a lot more possibilities to implement a backup strategy. For example, if you also
run other applications next to Domino on your iSeries server, you may need to perform a
backup of your system and user data periodically. When you decide to run a user data
backup during the weekends with the Domino servers ended, you should back up the
following objects:
– User profiles
– System configuration
– All user libraries
– DLOs
– The IFS without online Domino data
– The NOTES.INI files of all Domino servers

Note: The following example is just for your reference. It shows a possible weekly
backup. It would fit together with a daily full online Domino backup, which is not
discussed in this chapter. However, depending on your business environment, it may
well be the best solution for your backup requirements.

See Figure 7-43 for an example of a control group that ends all Domino servers and saves
all user data except Domino data (which was saved during the daily backups).

342 Domino 6 for iSeries Best Practices Guide

 Display Backup Control Group Entries AS25

Group . . . . . . . . . . : BRMWEEK
Default activity . . . . : F
Text . . . . . . . . . . : Backup user data except online Domino data

Auxiliary Weekly Retain Save SWA

Backup List Storage Activity Object While Message
Seq Items Type Pool Device SMTWTFS Detail Active Queue
10 *EXIT *DFTACT
20 *SAVSECDTA *DFTACT *NO
30 *EXIT *DFTACT
40 *SAVCFG *DFTACT *NO
50 *ALLUSR *SYSBAS *DFTACT *ERR *NO
60 *ALLDLO *DFTACT *NO *NO
70 QLTSEXCL *LNK *ALLAVL *DFTACT *NO *NO
90 *EXIT *DFTACT

Bottom
Press Enter to continue.

F3=Exit F11=Display exits F12=Cancel

Figure 7-43 Weekly backup of user data except Domino data

򐂰 Enrolling the tapes:

After you have reviewed and changed the settings in the BRMS configuration you have to
enroll the tapes that will be used for the backups. (If not using save files or an IBM Tivoli
Storage Manager server for your backups).
BRMS includes the ability to keep track of media expiration dates and to make them
available again to be used after they have expired. This means that you do not have to
keep track of the names or expiration time of the tapes. In fact, the tape volume names are
normally not used anywhere outside of BRMS. In addition, you can choose to set up
preset usage counters so tapes can be taken out of the BRMS backup process when they
are used for a certain period or for a certain number of times.
Do not name the tapes after the backup type, control group type or date, such as DAY01,
MONDAY or WEEK21. This is because all tapes can be used for any backup type once
they have expired and become available again for new backups. If you use tapes that were
previously used for backups in an environment where the tape labels had a relation to the
data on the tape, consider renaming the tapes. In general, it is better to label the tapes in
a numbered way. In addition, you can identify the tapes with BAR-code labels depending
on the tape unit or tape library. You must pay special attention to initialize and label the
tapes exactly as they are added to BRMS.
Use the commands Add Media to BRM (ADDMEDBRM) for standalone tape drives and
Add Media Library Media to BRM (ADDMLMBRM) for tape libraries. Make sure you
specify the media class and storage location where the tape resides. You can also use the
Add Media Information to BRM (ADDMEDIBRM) command to enter information about new
media. Note that the actual tape is not initialized with that command. Another possible
command is Work with Media Library Media (WRKMLMBRM)

Chapter 7. Backup and recovery using BRMS/400 343

 Note: The ADDMEDBRM command does not initialize the tape media by default, that is,
you can add tape volume names to BRMS without even having them loaded in the tape
unit. However, your BRMS backup jobs fail when the labels of the added media in BRMS
and the actual labels of the tapes do not match.

Therefore, it is good practice to initialize your tapes to be used for BRMS backups with the
ADDMEDBRM command and use the INZ(*YES) parameter to make sure the tapes are
added to BRMS and initialized with the correct name.

7.7.4 Domino backups in a 24x7 environment

So far we described backup strategies where the Domino servers are ended once a week for
the full backups. However, in a 24x7 environment, the servers need to stay active, and you
may only be able to end them once a month, or even less. If the Domino environment needs
to be available 24x7, the best solution is to configure clustered servers on separate iSeries
systems. In this case you need sufficient processing power and network capabilities, and if
possible, separate network adapters for user and server traffic. One Domino server in the
cluster can then be ended to perform a full dedicated backup, while the other server(s) stay
active, and the users can continue their work on that server.

On an iSeries system dedicated to Domino, you can choose to end the Domino servers on a
monthly basis. Then the monthly backup consists only of a *SAVSYS, together with the items
that were omitted from the daily and weekly backups. During the daily backups you can
perform online incremental backups, and run full online backups during the weekends. The
QLTSEXCL list (which includes all IFS data except online Lotus data), is used to back up all
IFS data other than the online Domino data. Note that any entries in the QLNKOMTONL list
are considered automatically when running the QLTSEXCL list. Entries in the QLNKOMTONL
list should be the NOTES.INI files of all Domino servers.

In addition, when a system is mainly used for Domino, you can choose to only back up the
*ALLUSR objects, with the Save While Active possibility, and keep the Domino servers active.

When you have other applications running next to Domino, depending on your situation, you
can shut down all applications during the backup but keep Domino active. The QLTSXCLONL
list can be run daily to back up all but the online data from Domino. This makes sure that the
Domino directory structure is saved, which is essential for any future restore operation. The
QLTSXCLONL list can be added to the control groups that are used for daily backups. Note
that the QLTSOMTONL list must contain the entries for the user omits, such as all NOTES.INI
files.

Make sure you check the backup log files to see if the backups run without errors.

7.7.5 What happens when BRMS runs Domino backups

BRMS takes care of the information where the data is stored. When the media retention flow
is set up correctly there is no need for you to keep track of where the data resides - apart from
printing the daily reports.

Use the WRKMEDIBRM command to find out on which tape your data from a certain backup
job resides. Enter option 9 (Work with saved objects) on the line with the date and the *LINK
you want the information for and you see the saved directories. Continue entering option 9
until you see the list of objects that are on that tape media. See “Restoring individual Domino
databases” on page 347 for the options to restore the database.

344 Domino 6 for iSeries Best Practices Guide

Domino databases are saved in groups of 50 by default, so the media information shows an
entry for each group of 50 saved objects.

A full online backup consists of two files. First the database files, and secondly the changed
files, which contain the changes that were performed on the databases while they were
saved. Databases are locked for the time of the backup procedure by BRMS. Therefore, when
running online backups, the database updates that are performed during the backup are
stored in temporary directories. After the backup has ended, this data is saved as a separate
backup item.

To bind the backup of the databases to the changed files and associated transaction log files,
BRMS uses a concept called a package. When a full online backup is run, the package ID
(PKGID) parameter from the SAVBRM command is used to specify whether a new package is
saved or a subsequent package with changes belonging to a previous package is saved.
When restoring the data later, it is also restored in two parts, first the database, and then the
changes to that database. During the backup, the RCYEXITPGM parameter is used to
specify a Domino server exit program. The exit program binds the packages together and is
called before the restore and after the recovery of the object.

When you use the WRKMEDIBRM command to look at the saved information, the numbering
of the saved items may be somewhat confusing. Only the initial element (*LINK) is shown in
the saved items list. The number of elements in the package is shown just right of the Saved
Items column. After performing a full online Domino server backup, the number is a 2, as the
databases and the changes to those databases were saved as separate items. Each time an
incremental online backup is run, the number is increased by 1. The maximum number of
packages is 99, so you can run one full online backup followed by 97 incremental backups.

When you look at the online Domino recovery reports from BRMS, all items of a package are
listed, as a package with the databases and one with the changes may exist on different
media volumes.

Where temporary data is stored

When you use the WRKLNK command to explore the IFS, you can find several directories
that are used for full Domino online backups and online incremental backups. You should not
alter or delete any information from these directories, as this will damage the objects needed
for backup and restore of your Domino environment. In addition there are files in the
/tmp/brms directory that may be needed for problem determination, also, this data should not
be removed or altered.

Note: The following information was correct at the time this redbook was written. It may be
subject to change in the future, with new releases of the OS/400 operating system, Lotus
Domino, or PTFs. This information is provided to help you understand what is done on the
system during Domino backups, so use it only as a reference.

When performing full online backups

Databases are saved in groups when performing full online backups. The default is
50 databases in a group, but you can change that value to a maximum of 120. See “Change
the backup group size:” on page 352 for how to change this. The database is not locked for
users or agents during the backup, so changes can still occur. The changes are temporarily
stored in a directory depending on the database path. Note that <DATADIR> in the list below
is not an actual name, but the data directory of your Domino server.

Chapter 7. Backup and recovery using BRMS/400 345

 These are the subdirectories:
򐂰 /<DATADIR>/BRMSCHGS/demo
򐂰 /mail
򐂰 /HELP
򐂰 /INOTES

The first group of (50) databases is saved, followed by the changes that were created during
that save, then the next group is saved, again followed by its changes. When the full save has
completed, all directories are cleared. There may be data left in those directories when a
backup operation was cancelled while running. This data is never cleared automatically.

When performing incremental online backups

For an incremental online backup, archival transactional logging must be enabled. In addition,
the Domino server must be configured to run the QNNINBRM task. This is done with the
CHGDOMSVR ADLSRV(*BRMS) command for an existing Domino server. For a new Domino
server, specify the ADLSVR(*BRMS) parameter on the CFGDOMSVR command. This adds
the QNNINBRM task to the ServerTasks line in the NOTES.INI file of the Domino server.

Depending on the configured value for transaction logging in the Domino server document,
several transaction log files are automatically created. One file is created for each 64 MB, so
you would see 10 files when you configured a transaction log size of 600 MB. When a
directory name (such as logdir) is entered in the server document, it will be created in the
Domino server’s data directory by default. By filling in the full path of the directory you can
create the transaction log file anywhere else in the IFS. An example of a place and naming for
those files is
/<DATADIR>/logdir/S0000003.TXN

During normal operation, with transaction logging active, the transaction log files are filled
with changes that occur on Domino databases. When a log file runs full, then the QNNINBRM
job takes care of copying the log file to the /DATADIR/BRMS directory. When an incremental
save occurs, the log files from this subdirectory are moved to the /DATADIR/INCRSAVE
subdirectory. The full moved log files in that subdirectory are then saved.

There is always a partially filled (that is, not yet full) active transaction log file that the server is
currently using. At the time of the incremental backup this active log file is copied to two
places, /DATADIR/BRMS/COPIEDLOG and /DATADIR/BRMS/INCRSAVE. The log files are
deleted from the INCRSAVE directory after a successful backup. The logdir subdirectory is
not cleared and the COPIEDLOG directory is cleared just before copying in the current partial
log file, at the start of an incremental backup.

So, the following events occur before or during the backup operation:
1. A user space, such as servername_02QUSRNOTES is created.
2. The names of the databases to be copied and saved are put in the user space.
3. The currently active (partially filled) transaction log extent is copied to the
/BRMS/COPIEDLOG and the /BRMS/INCRSAVE directories.
4. The full, copied transaction logs that need to be saved during the backup are moved to the
/BRMS/INCRSAVE directory.
5. The /BRMS/INCRSAVE directory is saved.
6. The /BRMS/INCRSAVE directory is cleared.

346 Domino 6 for iSeries Best Practices Guide

7.7.6 Domino restore methods
In this section we provide a short description of the different restore possibilities and
properties. For an explanation of the possible backup scenarios refer to 7.1.3, “Backup
scenarios” on page 295.

Restoring a full Domino server

It is best practice not to restore a full Domino server through the RSTOBJ and RST
commands. If the SERVER.ID file is available it is very easy to use the OS/400 Domino
commands to reconfigure the server. After recreating the server instance, you can then use
the BRMS commands to restore the Domino data directory with the Domino databases that
make up the server. Make sure that you do not start the Domino server before you are sure
that all IFS directories and Domino databases are restored to their original location.

Restoring individual Domino databases

When an individual Domino database needs to be restored it does not make a difference
whether you used a dedicated, an online, or an incremental online backup to save the
database.

To restore a database, type GO BRMS, choose option 4 (Recovery) followed by option 2

(Perform recovery).

As Domino databases are stored in the Integrated File System (IFS) you can also use the
WRKLNKBRM command to display all the data paths that were saved by BRMS.

If you have worked with BRMS before, you may have used the WRKMEDIBRM command to
find an object on media and restore it from that screen. This is also possible for Domino
databases, however the WRKMEDIBRM command shows only the groups (*LINK) in which
the Domino databases were saved, and not the individual databases. This means, that you
have to search all *LINK items at a particular date (option 9) for the actual Domino database
you want to restore. If you have many Domino databases, this might not be very efficient and
take some time. It is much better to use the BRMS recovery screens instead (GO BRMS
option 4 or the WRKLNKBRM command).

It is best practice, to let BRMS handle the restore and just select the objects you want to
restore starting from the BRMS recovery screens.

Restoring a database to a certain point in time

When running online incremental backups, you can restore a database to a certain point in
time. To do this, you need to create a data area and fill in the date and time for the database
to be restored. The data area exists only temporarily in the temporary library that belongs to
your interactive job. So after you signed off the iSeries system you must recreate the data
area for subsequent restores to a point in time.

Best practice for restoring databases to a point in time is to use the iSeries Navigator client as
shown in 7.6, “Restoring Domino databases with iSeries Navigator” on page 326.

Performing online incremental backups and restoring databases when using the OS/400
command environment is explained in detail on the Online Lotus Server backup Web site at:
http://www.ibm.com/servers/eserver/iseries/service/brms/domino.htm

Chapter 7. Backup and recovery using BRMS/400 347

7.7.7 Tips and troubleshooting
Following are some useful tips to make BRMS work better for you, and the things to be
checked when an error occurs with your backup. We have also included the most common
BRMS error messages at the end of this section.

Tips
򐂰 You should check the BRMS Web site on a regular basis for the latest information about
program temporary fixes (for both individual PTFs and Group PTFs). You can find this
information under the Support link. We recommend that you review the Web site at least
once every two weeks:
http://www.ibm.com/servers/eserver/iseries/service/brms/
In addition, we recommend that you regularly check the Recommended Fixes Web site,
which holds information for all iSeries products and is also updated on a regular basis:
http://www-912.ibm.com/s_dir/slkbase.nsf/recommendedfixes
򐂰 Perform full online or dedicated backups daily if you have the possibility to do so. The
availability of a full backup of your Domino server data allows for faster recovery in case of
an emergency. Whether you have this possibility depends on factors such as the available
time frame, the amount of data to save, the backup device, and, if using a network
connection, the network.
򐂰 Do not set up transaction logging for online incremental backups while performing only full
backups. BRMS does not clean up and save full transaction log files during full backups
and your system disks will fill up with data.
򐂰 When starting to use BRMS for your backups, first perform an initial full save of the system
with BRMS. This provides a recovery starting point for BRMS.
򐂰 Create a dedicated OS/400 user profile that is used to run the backups with BRMS.
Change the job scheduler job entries to use this user profile when running BRMS backup
jobs. Grant sufficient authority to this user and make sure this user is not able to log on to
the iSeries system. We advise to create a user profile with user class *SYSOPR (with its
special authorities *JOBCTL and *SAVSYS) and to add the *ALLOBJ special authority.
It is better not to run the BRMS backup jobs with the user profile of an actual user, as the
settings of that user profile may be subject to change later, which can affect the BRMS
backups. It is also easier to separate between user messages and BRMS messages when
a special BRMS user is used for backups.
򐂰 Test all your configured BRMS backups before going into production with BRMS and avoid
unattended (for example nightly) backups before they were tested. You may return to the
office the next morning and nothing or only parts are saved because a scheduled BRMS
job did not run error free.
򐂰 When you see that a scheduled nightly backup did not complete successfully pay special
attention to any message that a control group is waiting for to be answered (such as a tape
error message in the QSYSOPR message queue). When you resolve the error, the control
group entries will resume to run. However, you might have entries in the control group that
you do not want to run in the morning. For example, you might have implemented a
system IPL to be run after the backup which is launched by resolving the error message.
Use DSPLOGBRM to check the BRMS log information messages. Check the job log of the
user that ran the BRMS backup when the BRMS log shows that not all databases have
been saved. If you find a database that was not saved, it might have been in use at the
time the backup was running. Check that there is no Domino agent running, or if the
database is damaged. Check if it is saved correctly the next day if the database seems to
be OK.

348 Domino 6 for iSeries Best Practices Guide

򐂰 BRMS is not case sensitive for backups, that is, is does not matter in what case the
Domino data path is, including mixed case. Also if you change the case of an existing
Domino data path (not the path itself), BRMS still runs the backups without error.
However, BRMS is case sensitive for restores, that is, if you manually type the path for the
restore, it must exist in the same case in the IFS of the iSeries system.
If you first create a directory for a Domino server (for example to copy a SERVER.ID file to
it) and then run the CFGDOMSVR command to configure a new server using that ID file, it
is better to keep the text case equal to the created directory path. This avoids double
entries in the WRKMEDIBRM list later which might mislead you because the exact same
path is listed twice in the list. This problem occurs if you saved both the Domino server
path with a BRMS backup and also a *LINK backup of the full IFS. The Domino servers
data path is stored in the stream file /QIBM/UserData/LOTUS/LOTUS_SERVERS which
can be edited to change the case for the path.
򐂰 Run a disaster recovery test once the BRMS configuration is complete and tested. Run
this test at least once a year to make sure that you can rely on the backup and recovery
strategy you implemented. Depending on your situation, you can restore the backups to a
separate system during the test so the production environment is not influenced by the
restore.
򐂰 When you copy control groups, be aware of the control group parameter (CTLGRP) in the
*EXIT command line. This parameter points to the original control group name - because
the control group is copied with all its settings. As the new control group has a different
name, you need to change the CTLGRP parameter in the *EXIT. To change this
parameter, use the command WRKCTLGBRM. Enter option 2 to Edit entries and press
F11 to Display Exits. Then move the cursor to the correct Exit line and press F10. Change
the name of the control group parameter to the name of the new control group. If you do
not change this parameter to the control group name you just created, the backup will end
in error.
򐂰 When you copy control groups, be aware of the control group parameter in the *EXIT
command line, as the new control group will have a name that is different from the original
one. You have to change the *EXIT entry for the Domino backup. In the entry, there is also
the control group parameter, and when you copy a control group, this parameter is copied
from the original. If you do not change this parameter to the control group name you just
created, the backup will end in error.
򐂰 Many BRMS options can be used from the BRMS menu which is accessed through the
GO BRMS command. Type GO CMDBRM to go to the BRMS Commands menu when you
search for a specific BRMS command with its parameters.
򐂰 Schedule to run the BRMS maintenance job every day and analyze the created recovery
reports to address any problems in the backup procedures.

Troubleshooting
When you are not familiar with BRMS, or if you are configuring it for the first time on your
system, your backups may not run as expected. Following are some troubleshooting tips for
this situation:
򐂰 When you receive a message that no tape drive could be assigned for the backup but you
are sure that there is a device available, check the storage location entry in the BRMS
device description and the storage location field in the media policy. You may have used
*MEDCLS for the backup device in the control group to indicate that BRMS must look for a
device that supports the density for the media class specified in the media policy. When
you use only one tape unit for the backups, we recommend that you put the device name
for that tape drive in the backup device field in the control group.

Chapter 7. Backup and recovery using BRMS/400 349

 򐂰 When tapes show as expired right after a backup took place, check that you installed
option 18 of the OS/400 operating system, which are the Media and Storage Extensions.
After installing this option run the INZBRM *DATA command to initialize BRMS.
򐂰 If option 18 of the operating system is installed and there are still problems with the tape
expiration function, the media monitor function may not be activated in the system policy
settings. Use WRKPCYBRM *SYS to check the parameter. Make sure it is set to *YES so
BRMS keeps track of tape media information.
򐂰 When the backup job shows to have run successfully in the BRMS job log, but nothing was
saved, check the entries in the Weekly Activity field in the control group that was started. It
shows the days of the week that the backup should run. There may not be an F for a full
backup or an I for an incremental backup in the field of the day you expected it to run. If the
field contains the value to refer to the backup policy, then check the default Weekly Activity
field there. Or you may have changed the default settings for the presentation controls in
the system policy. If you did so, make sure that they match the task you want to be
performed.
򐂰 A newly created database or a database with a new database identifier ID (DBIID) is not
saved when you run an incremental backup, you must save the full database first.

Important: The BRMS online incremental backup support for Domino databases was
extended for Domino 6.0.3 and Domino 6.5.

The new support detects:

򐂰 When a new database has been added to the server since the last *FULL save of
the Domino server.
򐂰 If a DBIID of a database has changed since the last full save of the database.
򐂰 If a non-logged Domino database has had a change made to it since the last full
save of the database was done.

If any of these conditions are found for a Domino database, then an online full save of
just that database will be done automatically.

Prerequisites:
򐂰 Domino 6.0.3 or 6.5
򐂰 BRMS PTFs SI10612 (OS/400 V5R1) or SI10615 (OS/400 V5R2)

For details on this enhancement, please refer to:

http://www.ibm.com/servers/eserver/iseries/service/brms/domIncremental.htm
http://www.ibm.com/servers/eserver/iseries/service/brms/domIncrementalEnhancement.
htm

򐂰 When the backup job is submitted from the job scheduler, but does not seems to end,
check the job queue QBATCH in library QGPL. Use the command WRKJOBQ QBATCH.
The subsystem QBATCH may not be active if the backup job is still there. The reason may
be that you added the subsystem to the Subsystems to process list in the control group.

350 Domino 6 for iSeries Best Practices Guide

򐂰 Your backup seems to run error free and the BRMS log shows that the backup ended
successfully, but one or more databases are not saved.
To gather more information about the backup job, you can set an environment variable in
the control group. The entry is case sensitive and must be written in capital letters. It
creates a file in the '/tmp/brms/' directory that starts with qnninsdb* and ends with a
timestamp. You can then check the file after the backup. Do not attempt to open the file
when the backup is still running as BRMS would no longer be able to write data to it. Make
sure you scope this environment variable to the *JOB and not the system (because then it
would disappear after the control group ends). You might experience a slight performance
degradation as there is extra information logged about your backup job.
To set the debug variable, add an *EXIT entry in the control group you want to debug,
(remember to leave an empty *EXIT at the top and bottom) that looks like this:
ADDENVVAR ENVVAR('DEBUG_QNNINSDB') VALUE(1) LEVEL(*JOB)
Enter this *EXIT entry just after the first empty *EXIT in the control group.

Important: Remember to remove the debugging *EXIT after the debug is done. If you
keep the entry in the control group, the directory with the debug data will grow
extensively and fill up your iSeries disks.

Common BRMS error messages

In this section, we describe the cause of some common BRMS error messages and what you
can do to avoid or to resolve them:
򐂰 LNT0977: The Domino server cannot be saved or restored.
This message indicates that a BRMS backup is already running and that you cannot start
a second one for this Domino server.
Make sure that no backup is running, for example, an existing backup job may be waiting
for a reply to a message.
If you are sure that there is no backup running and you keep getting this error message,
there may be a user space object left in library QUSRNOTES. This can happen if a
previous backup ended in error or has been cancelled while it was running. To resolve this
problem, delete the user space with a name such as “DOMBRMS_xxQUSRNOTES” from
the library. xx stand for number that can vary.
򐂰 LNT0970: Unexpected error encountered by SAVDOMBRM command, reason code 11.
This error message may occur when the time to back up a group of Domino items took
longer than the default maximum time-out setting of 15 minutes. Reason code 11 stands
for a time-out error. As mentioned earlier, BRMS saves Domino databases in groups of 50
by default. When there are large files in a group, then the backup time may exceed the
default setting and the error message is shown. Another cause for exceeding the
maximum time is a message on the system console that a tape needs to be changed.
There are two solutions to this problem and they can also be combined. You can change
the number of databases to be backed up in a group to a smaller value, or allow more time
for the group to complete the backup process. Both changes can be set by variable
settings in the NOTES.INI file.
To find out which group of objects caused the error, you need to look at the time stamp of
the last successful save message (that says that 50 objects were saved), and the
timestamp of the failure message. Then count the amount of time that passed and allow
some more minutes for the backup.
Again, note that without the parameter in the NOTES.INI, the default is 15 minutes, so
when the error occurred, this 15-minute time proved not to be long enough for the group.

Chapter 7. Backup and recovery using BRMS/400 351

 Here are the two main approaches you can try:
– Change the backup group size:
To change the default number of 50 Domino databases that are backed up in one
group, add the following line to the NOTES.INI of the Domino server that is backed up:
SAVDOMBRM_FILES_IN_GROUP=xx
where xx is the amount of files in the group.
– Change the maximum time allowed for backup groups:
To allow more than 15 minutes for a group to be backed up, add the following line to the
NOTES.INI file of the Domino server you are backing up:
BACKUP_TIMEOUT=xx
In this statement, xx is the number of minutes you want to allow a backup group to run
before a time-out occurs.
Note that this variable is only available in Domino 6.
򐂰 The following three messages sometimes occur:
BRMS Log Manager Started
Error 11 occurred in QNNINBRM
Transactional Logging must be enabled for this function
These three messages show up in the Domino console right after each other, and they
indicate that the Domino server was configured for BRMS backups, but transaction
logging was not enabled in the server document. This is not an error when you start up a
Domino server for the first time, and thus did not have the chance yet to enable
transaction logging.

7.7.8 More information on using BRMS for Domino backups

For more information on using BRMS for Domino backups, refer to the following
documentation and information:
http://www.ibm.com/eserver/iseries/infocenter
In addition, you can refer to the following publications:
򐂰 IBM Lotus Domino 6 for iSeries Implementation, SG24-6592, Chapter 17
򐂰 Backup, Recovery and Media Services Version 5, SC41-5345-03

352 Domino 6 for iSeries Best Practices Guide

 8

Chapter 8. Backup and recovery using

Tivoli Data Protection for Domino
In this chapter we describe backup and recovery of Domino servers running on OS/400 using
the IBM Tivoli Storage Manager for Mail: Data Protection for Lotus Domino for OS/400,
Version 5.2.0 software.

Note: Throughout this book, we use the term Data Protection for Domino for the IBM
Tivoli Storage Manager for Mail: Data Protection for Lotus Domino for OS/400, Version
5.2.0 software.

Data Protection for Domino is an IBM Tivoli software module that provides online “hot”
backups and restores of Lotus Domino databases to an IBM Tivoli Storage Manager server.

Topics in this section include:

򐂰 Introduction to IBM Tivoli Storage Manager
򐂰 Installation of Data Protection for Domino on OS/400
򐂰 IBM Tivoli Storage Manager server configuration
򐂰 Data Protection for Domino on OS/400 configuration
򐂰 Using Data Protection for Domino
򐂰 Recovering Domino servers and databases
򐂰 Considerations and best practices for Data Protection for Domino on OS/400
򐂰 Sample configuration files and scripts

© Copyright IBM Corp. 2004. All rights reserved. 353

8.1 Introduction to IBM Tivoli Storage Manager
IBM Tivoli Storage Manager protects organization’s data against hardware failures and other
errors by storing backup and archive copies of data in online or offline storage. It can scale to
protect hundreds of computers from laptops to mainframes, running on different operating
systems, connected via the Internet, WANs, or LANs. The centralized Web-based
management, smart data move and store techniques, and comprehensive policy-based
automation work together to minimize data protection administration costs and the impact on
both computers and networks.

8.1.1 IBM Tivoli Storage Manager basics

IBM Tivoli Storage Manger uses a client/server architecture for backup and restore. Data
storage and system management is provided on a central IBM Tivoli Storage Manager
server. Administration of the IBM Tivoli Storage Manager server is achieved through either a
Web interface or using the command line interface on the server. IBM Tivoli Storage Manager
server 5.2 is currently supported on 10 different platforms including OS/400 PASE V5R1 and
later.

Clients (nodes) connect through the network to the central server to store and retrieve saved
data. IBM provides client software for 19 different operating systems. There is an additional
product available, IBM Tivoli Storage Manager for Storage Area Networks, which allows for
backup/restore and archive/retrieve data transfer over a Storage Area Network (SAN) instead
of the LAN. OS/400 client support is limited to the Tivoli Storage Manager API client, which
can be used together with Backup, Recovery, and Media Services for iSeries to back up
OS/400 user data.

In addition to the IBM Tivoli Storage Manager client software, IBM also provides Tivoli
Storage Manager for Data Protection modules. These specialized clients facilitate backup and
recovery for application servers, databases, ERP systems, network attached storage, mail
and groupware servers. IBM Tivoli Storage Manager for Mail Data Protection for Lotus
Domino protects Lotus Domino data using Domino APIs for the backup.

All IBM Tivoli Storage Manager managed client data is stored in the IBM Tivoli Storage
Manager storage repository, which can consist of different storage devices, such as disk,
tape, or optical devices, and is controlled by the IBM Tivoli Storage Manager server. IBM
Tivoli Storage Manager concentrates on managing data objects instead of managing and
controlling backup tapes. Data objects can be files, directories, or raw logical volumes that
are backed up from the client systems; they can be objects such as tables or records from
database applications, or simply a block of data that a client system wants to store on the
server storage.

An IBM Tivoli Storage Manager system usually consists of a dedicated server with attached
tape storage and clients connected to the server through the network.

For more information on IBM Tivoli Storage Manager visit the IBM Tivoli Storage Manager
Web site at:
http://www.ibm.com/software/tivoli/products/storage-mgr

For detailed technical information see the redbook IBM Tivoli Storage Management
Concepts, SG24-4877, which can be found at:
http://www.redbooks.ibm.com/redbooks/pdfs/sg244877.pdf

354 Domino 6 for iSeries Best Practices Guide

8.1.2 Data Protection for Domino
IBM Tivoli Storage Manager for Mail 5.2 Data Protection for Lotus Domino on OS/400
(throughout this chapter we refer to this product as Data Protection for Domino) is a software
module of the IBM Tivoli Storage Manager that provides online “hot” backups and restores for
Lotus Domino servers. Data Protection for Domino communicates with an IBM Tivoli Storage
Manager server using the IBM Tivoli Storage Manager application program interface (API).
Data Protection for Domino uses Lotus Domino APIs for backups of Notes databases and
transaction logs on Lotus Domino servers. This allows for 24x365 operation of Lotus Domino
servers while performing data backups and restores. The Data Protection for Domino
architecture is shown in Figure 8-1. Data saved with Data Protection for Domino is stored and
managed on an IBM Tivoli Storage Manager server.

Data Protection for Domino provides the following functions to Domino for iSeries:
򐂰 Centralized, online, incremental backup of Lotus Domino databases
򐂰 Storage for multiple backup versions of Domino databases
򐂰 Archival of Lotus Domino transaction log files, when archival logging is in use
򐂰 Archival of the currently used (write to) transaction log file
򐂰 Restore of a Lotus Domino database from a backup and subsequent application of
changes made since the backup from the transaction log
򐂰 Restore of Domino databases to a specific point in time
򐂰 Recovery of one or more archived transaction logs independent of a database recovery
򐂰 Recovery from the loss of the transaction log
򐂰 Automatic expiration of database backups based on version limit and retention period
򐂰 Expiration of archived transaction logs when no longer needed for restore

Attention: Data Protection for Domino on OS/400 provides backup and recovery only for
Domino databases, templates and transaction logs. Periodically you must also backup
other files in the Domino data directory (for example NOTES.INI, ID files, etc.), libraries
containing the Lotus Domino binary files, and system data. This can be achieved with
OS/400 save commands or using Backup, Recovery, and Media Services for iSeries.

Data Protection for Domino provides two types of database backups: Incremental and
selective. In addition to these database backups, there is also a log archive function.
򐂰 The incremental backup provides a conditional backup function that creates a full online
backup of Domino databases, when necessary. The specific conditions that determine
when a new backup is necessary vary depending on whether the database is logged or
not. Details can be found in Table 8-1 on page 376.
򐂰 The selective backup unconditionally backs up the specified databases, unless they are
explicitly excluded from the backup procedure through exclude statements.
򐂰 When archival logging is in effect, changes to logged databases can be captured in
between full backups, by archiving the transaction log.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 355
 OS/400 Domino Server
IBM Tivoli
Transaction Logs Storage
Manager
Lotus Data Tivoli Server
Domino Protection Storage backup
for Manager
APIs on restore
OS/400 Domino APIs for
OS/400
Domino databases
on OS/400

Figure 8-1 Data Protection for Domino on OS/400 architecture

Data Protection for Domino is available for all operating systems supported by Lotus
Domino 6. It offers the same functionality on all supported platforms and provides the same
configuration options and user interface (except for Microsoft Windows platforms where Data
Protection for Domino uses a graphical user interface). Thus, system administrators used to
working with IBM Tivoli Storage Manager products find a familiar environment on all
platforms.

On iSeries, Data Protection for Domino is a standard licensed program. The user interface for
Data Protection for Domino is implemented in the QShell environment and all configuration is
performed using text files which are stored in the “root” file system of the OS/400 IFS. There
is no graphical user interface for Data Protection for Domino on OS/400.

Data Protection for Domino commands

All Data Protection for Domino actions are performed by invoking the domdsmc program and
the appropriate command and parameters in QShell. The same method is also used for
scripts, please see “Backup strategies for Domino servers using Data Protection for Domino”
on page 381 for more information.

The Data Protection for Domino command line syntax is:

domdsmc command required_parameters optional_parameters

Commands can be a single or multiple word(s), for example restore or query domino. All
commands have abbreviations, they are indicated by upper case letters in IBM Tivoli
manuals.

If a command requires specification of (a) Domino database(s), the full database name can
be passed to the command or you can use wildcards (* and ?). Wildcards cannot be used for
directory names. We advise that you always use double quotes around database
specifications.

All optional parameters start with a forward slash (“/”), values are passed to the parameters
using the equal sign (“=”). There are also abbreviations available for all optional parameters.

Commands, database specifications and optional parameters are separated by spaces.

The following command is an example for a QShell Data Protection for Domino command:
domdsmc restore “doclib*.nsf” /pit=08/15/2003,10:00 /activate=yes

356 Domino 6 for iSeries Best Practices Guide

 Attention: If you are running domdsmc commands while the Domino server is stopped, do
not start this Domino server before all Data Protection for Domino processing finished. A
Domino server with transaction logging enabled will crash if the logger task for this partition
(LOGASIO job) is already running on the system.

Online help is provided for all domdsmc commands with the help command. The help
command without parameters displays all available help. To display online help for a specific
command, add the command name as a parameter, for example:
domdsmc help restore

A description of all Data Protection for Domino commands and parameters can be found in
the IBM Tivoli Storage Manager for Mail 5.2, Data Protection for Lotus Domino for UNIX and
OS/400, Installation and User’s Guide. This manual is available with the product and can also
be downloaded from the Tivoli Web site at:
http://publib.boulder.ibm.com/tividd/td/ITSMFM/SC32-9056-01/en_US/PDF/c3290561.pdf

8.2 Installation of Data Protection for Domino on OS/400

Installation of Data Protection for Domino is implemented in the same way as any other
OS/400 licensed program. It should be performed by an OS/400 administrator.

Prerequisites for Data Protection for Domino are:

򐂰 OS/400 V5R1M0 or later
򐂰 OS/400 QShell Interpreter (OS/400 Option 30)
򐂰 Lotus Domino Server R5.0.1 or later (Lotus Domino 6 is also supported)
򐂰 Tivoli Storage Manager API 5.2.0 (included with Data Protection for Domino)

The Data Protection for Domino code must be installed on the iSeries server running the
Domino server(s).

Important: Due to restrictions with the usage of the QOpenSys file system, you must
follow special installation instructions if you wish to install the IBM Tivoli Storage Manager
API 5.2.0 (5733-197) on the same iSeries system as the IBM Tivoli Storage Manager
server for PASE OS/400 (5698-ISX). For these instructions, please refer to the Redbooks
Technote called Installing Tivoli Storage Manager and Tivoli Storage Manager APIs on the
Same IBM iSeries Server, Technote 0293, at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/tips0293.html?Open

The installation media for Data Protection for Domino on OS/400 includes both products that
have to be installed on the iSeries server:
򐂰 Tivoli Data Protection for Domino (5698-DPD)
򐂰 Tivoli Storage Manager APIs (5733-197)

Important: Before performing the installation of 5733-197 (Tivoli Storage Manager APIs)
you must check if there is a previous version of this product installed and in use. You
should verify that all programs that use Tivoli Storage Manager APIs (for example Backup,
Recovery, and Media Services for iSeries connected to an IBM Tivoli Storage Manager
server) are compatible with version 5.2.0 before installing the Tivoli Storage Manager
APIs 5.2.0.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 357
 The user performing the installation of Data Protection for Domino needs *ALLOBJ and
*JOBCTL special authorities to use the RSTLICPGM (Restore Licensed Program) command.
The installation can be performed from CD ROM or from a save file.

These are the steps to install Data Protection for Domino on OS/400 using an installation CD:
1. Sign on to OS/400. Use a user profile with *ALLOBJ and *JOBCTL special authorities (for
example, QSECOFR).
2. Insert the installation media into the iSeries CD ROM drive.
3. Enter RSTLICPGM on an OS/400 command line and press F4.
4. On the next screen you must enter the product ID and the location of the installation files:
a. Enter 5698DPD for the Data Protection for Domino product.
b. Enter the device name OPT01 (you need to check which device you are using for
installation).
c. Enter 2924 as the Language for the licensed program, regardless of your locale setting
or primary language.
You do not need to customize any other options on the Restore Licensed Program
screen.
d. Press Enter to start the installation.
5. Repeat installation steps 1 to 4 to install the Tivoli Storage Manager APIs. Use 5733197
for the Product parameter in step 4a.

Figure 8-2 shows the Restore Licensed Program screen.

Restore Licensed Program (RSTLICPGM)

Type choices, press Enter.

Product . . . . . . . . . . . . 5698DPD Character value

Device . . . . . . . . . . . . . OPT01 Name, *SAVF
+ for more values
Optional part to be restored . . *BASE *BASE, 1, 2, 3, 4, 5, 6, 7...
Type of object to be restored . *ALL *ALL, *PGM, *LNG
Language for licensed program . 2924 Character value, *PRIMARY...
Output . . . . . . . . . . . . . *NONE *NONE, *PRINT
Release . . . . . . . . . . . . *FIRST Character value, *FIRST
Replace release . . . . . . . . *ONLY Character value, *ONLY, *NO

Bottom
F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys

Figure 8-2 Installation of Data Protection for Domino (RSTLICPGM)

358 Domino 6 for iSeries Best Practices Guide

 Attention: The Data Protection for Domino command program (DOMDSMC) is located in
the QACDTDPLD library. The program is installed with *PUBLIC authority *EXCLUDE.
Any user wanting to use the commands must have either *ALLOBJ authority, or be granted
explicit access to the program.

For more information and installation instructions see Chapter 2 “Installing Data Protection for
Domino” of the IBM Tivoli Storage Manager for Mail 5.2, Data Protection for Lotus Domino for
UNIX and OS/400, Installation and User’s Guide.

8.3 IBM Tivoli Storage Manager server configuration

Before you start the configuration of Data Protection for Domino, the IBM Tivoli Storage
Manager system administrator in your organization must create an appropriate configuration.
This includes the definition of a new client for the IBM Tivoli Storage Manager server and
customization of parameters for data storage and retention. The client is defined as a new
IBM Tivoli Storage Manager node. This node is connected to the Policy Domain, which
defines storage and retention of client data.

We provide only brief information about the configuration needed on the IBM Tivoli Storage
Manager server side. If you are not familiar with IBM Tivoli Storage Manager you should read
the IBM Tivoli Storage Manager Administrator’s Guide. The IBM Tivoli Storage Manager for
OS/400 PASE, Administrator’s Guide, Version 5.2 can be obtained from the Internet at:
http://publib.boulder.ibm.com/tividd/td/ITSM400/GC23-4694-01/en_US/PDF/anrpgd51.pdf

More information on IBM Tivoli Storage Manager concepts and architecture can also be found
in the redbook IBM Tivoli Storage Management Concepts, SG24-4877.

8.3.1 IBM Tivoli Storage Manager node

Each Data Protection for Domino instance must be registered as a different node on the IBM
Tivoli Storage Manager server. That means: multiple Lotus Domino server partitions on the
same iSeries server require different Data Protection for Domino instances and this requires
different nodes on the IBM Tivoli Storage Manager server. The process of setting up a node
name, password, and preferences is called registration.

The definition of an IBM Tivoli Storage Manager node for Data Protection for Domino on
OS/400 includes:
򐂰 Node name: We recommend using the Domino server name.
򐂰 Password: This is an initial password to access the IBM Tivoli Storage Manager server.
򐂰 Policy Domain: All Data Protection for Domino nodes should be using this special Policy
Domain.
򐂰 Backup Delete Allowed: This must be set to “no” to allow expiration of archived transaction
log extents.

Node name and password are required for the configuration of a Data Protection for Domino
instance on OS/400.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 359
8.3.2 IBM Tivoli Storage Manager Policy Domain
A Policy Domain defines rules for storage and retention of data backed up by nodes to an
IBM Tivoli Storage Manager server. A Policy Domain contains more layers of subordinate
entities, which provide configuration and operation flexibility. The most important
configuration concepts of Policy Domains are the Management Class and the Backup Copy
Group.

The Backup Copy Group contains definitions where to store data and data retention rules.
The IBM Tivoli Storage Manager server provides hierarchical storage management, so you
can store data first on disk and migrate it later to tape or optical media. Data retention rules
define how long data will be kept on the IBM Tivoli Storage Manager server or how many
versions of that data will be stored. The IBM Tivoli Storage Manager server provides
automatic management of storage and expiration of data.

The Management Class contains Backup Copy and Archive Copy groups and associates
data with them. Each node is connected to one Management Class defined as the default in
the Policy Domain. You can override the Management Class definition for files on the client
by explicitly defining INCLUDE statements. Data Protection for Domino stores all objects as
backup objects on the Storage Manager so an Archive Copy Group is not required, although
it can exist. For more information on include/exclude options see Chapter 9, ”Policy
Management” in the redbook IBM Tivoli Storage Management Concepts, SG24-4877.

Tip: We recommend that you define a separate Policy Domain for your Data Protection for
Domino nodes. Use the default Management Class with the settings required for your
Domino data.

All database backup objects are complete file backups so the normal version controls
available through IBM Tivoli Storage Manager server policies apply. According to your needs
for the number of backup versions to be kept, and the retention period of these backup
versions, set the following parameters in the Backup Copy Group:
򐂰 Versions Data Exists: Specifies the number of versions (full backups) of Domino
databases and transaction logs that are being kept on the IBM Tivoli Storage Manager
server.
򐂰 Versions Data Deleted: Specifies the number of versions (full backups) of Domino
databases and transaction logs that are being kept on the IBM Tivoli Storage Manager
server after a database or transaction log has been deleted from the Lotus Domino server.
򐂰 Retain Only Version: Specifies the number of days to retain the last backup version of a
file that has been deleted from the client file system.
򐂰 Retain Extra Versions: Specifies the number of days to retain a backup version after that
version becomes inactive. A version of a file becomes inactive when the client stores a
more recent backup version, or when the client deletes the file from the workstation and
then runs a full incremental backup. The server deletes inactive versions based on
retention time.

You can use the default values for the Backup Copy Group parameters “Copy Frequency”,
“Copy Mode” and “Copy Serialization” because they are not applicable to Data Protection for
Domino.

Be sure to set the retention period for inactive transaction log files to be equal to or greater
than the retention period of the database backup objects. This ensures the files are available
as long as any inactive database file may need them, so a point in time recovery of an inactive
database backup version can be accomplished. This can be done by using the same
Management Class for the transaction log files and for the database files.

360 Domino 6 for iSeries Best Practices Guide

8.4 Data Protection for Domino on OS/400 configuration
During configuration of Data Protection for Domino, you will specify which Lotus Domino
server(s) you want to back up, and on which IBM Tivoli Storage Manager server you want to
store the data. You can also configure backups for partitioned Domino servers. This is
discussed in detail in 8.4.7, “Configuring Data Protection for Domino for partitioned Domino
servers” on page 372.

Before configuring Data Protection for Domino, you must check if Tivoli Data Protection for
Domino (5698-DPD) and the Tivoli Storage Manager APIs (5733-197) are installed on your
iSeries system. Use the Display Software Resources (DSPSFWRSC) command or the GO
LICPGM menu.

Configuration of Data Protection for Domino must be performed using an OS/400 user ID
having *ALLOBJ special authority.

Tip: Throughout this chapter we use OS/400 file manipulation commands to configure
Data Protection for Domino. If you are more familiar with UNIX style commands, you can
use those in QShell to configure the product.

These are the steps needed to configure Data Protection for Domino on OS/400:
1. Run dominstall to configure the basic parameters and setup object permissions for Data
Protection for Domino objects. This is explained in “Running the dominstall program” on
page 362.
2. Create the IFS directory for the Data Protection for Domino configuration files and logs
and copy the provided sample configuration files to this directory. See “Creating directory
and configuration files: Data Protection for Domino instances” on page 363 for details.
3. Set QShell environment variables. Refer to 8.4.5, “Setting QShell environment variables
for Data Protection for Domino” on page 368.
4. Configure the options files (dsm.opt and dsm.sys) for Data Protection for Domino. Refer to
“Modifying Data Protection for Domino configuration files” on page 364.
5. Configure the preferences file (domdsm.cfg) for Data Protection for Domino as explained
in “Modifying Data Protection for Domino configuration files” on page 364.

After setting up the initial configuration you have the possibility to check the connection to the
IBM Tivoli Storage Manager server and to the Lotus Domino server to verify that Data
Protection for Domino is configured correctly.

Configuration of Data Protection for Domino is performed using text files and through the
QShell environment. For administrators familiar with the product from other platforms this
provides a familiar environment.

For OS/400 administrators not used to UNIX style configurations and commands we provide
basic instructions for configuration and operation in the following sections of this chapter. If
you would like to learn more about QShell, please see the QShell reference on the Web at:
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/info/rzahz/rzahz.pdf

For further information on configuring Data Protection for Domino on OS/400 see the IBM
Tivoli Storage Manager for Mail 5.2, Data Protection for Lotus Domino for UNIX and OS/400,
Installation and User’s Guide.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 361
 New to QShell?
򐂰 To start a QShell session, enter the QSH command in an 5250 emulation session.
򐂰 In QShell, you enter commands after the “===>” sign. The response to a command is
displayed in the area above this line.
򐂰 When a command finished processing, a $ sign appears and you can enter the next
command. You can use all standard POSIX (UNIX style) commands in QShell.
򐂰 To quit a QShell session, press the F3 key.
򐂰 You can temporarily leave QShell by pressing the F12 key. Then, when you later return
to QShell (using the QSH command again), all shell parameters and current directory
are preserved.
򐂰 It is possible to enter OS/400 commands without leaving the QShell environment by
pressing the F21 key (press F12 to return to QShell).

8.4.1 Running the dominstall program

The dominstall program configures the locations of the binaries for Data Protection for
Domino and the Lotus Domino server(s). It also sets applicable object permissions. The user
executing the dominstall program must have *ALLOBJ authority.

The steps required for completing the dominstall configuration are:

1. Start the QShell environment:
QSH
2. To start the dominstall program, you first have to switch to the Data Protection for
Domino installation directory:
cd /usr/tivoli/tsm/client/domino/bin
3. Call the dominstall program:
dominstall
Refer to Figure 8-3 to see the results of running this program.

QSH Command Entry

$
> cd /usr/tivoli/tsm/client/domino/bin
$
> dominstall

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-3 Running dominstall command in QShell

362 Domino 6 for iSeries Best Practices Guide

 4. Now, dominstall prompts you for the location of the Data Protection for Domino binaries:
Using the Data Protection for Lotus Domino client, domdsmc, installed in /QSY
S.LIB/QACDTDPLD.LIB.
Is that correct?.
(Yes (Y)/No (N))
Enter Y and press Enter.
5. Next, dominstall prompts you for the location of the Lotus Domino binaries:
Using the Domino, libnotes.SRVPGM, installed in /QSYS.LIB/QNOTES.LIB.
Is that correct?.
(Yes (Y)/No (N))
Enter Y and press Enter.
6. The last step is to specify the location of the NOTES.INI file for the Domino server you are
adding Data Protection for Domino to:
Unable to locate Domino file.
Please specify the directory where notes.ini is installed.
Enter the full path to NOTES.INI, for example:
/LOTUS/DATA/DOMTDP

You have now finished the dominstall program. dominstall will display a message stating
successful installation at the end of the configuration:
return code from system is 0
Data Protection for Domino installation process has successfully completed
$

8.4.2 Creating directory and configuration files: Data Protection for Domino
instances
By default, the configuration files are stored in /usr/tivoli/tsm/clients/domino/bin, but we
recommend using a special directory for each Data Protection for Domino instance. This way
you can easily add new instances to back up additional Domino servers. For further
information see 8.4.7, “Configuring Data Protection for Domino for partitioned Domino
servers” on page 372.

Data Protection for Domino directories

So you should create one directory for each Data Protection for Domino instance (that is for
each Lotus Domino server partition). We suggest creating this directory (directories) under
/usr/tivoli/tsm and naming them according to the Lotus Domino server name(s). For example:
CRTDIR (‘/usr/tivoli/tsm/domtdp’)

This will create a new directory called domtdp under /usr/tivoli/tsm.

In addition to the configuration files, the directory can also contain log files and QShell scripts
for scheduled jobs for this instance of Data Protection for Domino.

Attention: If you are storing Data Protection for Domino logs in this directory, you have to
grant *RWX data authority to user QNOTES for the directory. For example:

CHGAUT OBJ('/usr/tivoli/tsm/domtdp') USER(QNOTES) DTAAUT(*RWX)

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 363
 Data Protection for Domino configuration files
Data Protection for Domino on OS/400 uses the following files to store its configuration data:
򐂰 domdsm.cfg: The Data Protection for Domino preferences file:
This file contains preferences specific to Data Protection for Domino such as which Lotus
Domino server this instance will backup, date/time format and logging options.

Important: The domdsm.cfg file should not be edited manually. All parameters in this
file must be set using the domdsmc set command.

򐂰 dsm.opt: The IBM Tivoli Storage Manager client options file:

The client options file is the main configuration file for all IBM Tivoli Storage Manager
clients. It contains the configuration definition for the IBM Tivoli Storage Manager server
this client is connecting to and some other processing options.
򐂰 dsm.sys: The IBM Tivoli Storage Manager system options file:
The system options file contains information about the IBM Tivoli Storage Manager
servers this client accesses. This file can also contain communication parameters, backup
and restore processing options and authorization options. Usually you have one dsm.sys
file for all Data Protection for Domino instances.

The domdsm.cfg and dsm.opt files should be stored in the appropriate Data Protection for
Domino instance directory of each Domino server while dsm.sys in located in the
/usr/tivoli/tsm/client/api/bin directory.

Creating Data Protection for Domino configuration files

The configuration files can easily be created by copying the sample files provided in the Data
Protection for Domino installation directory. Use the Copy (CPY) command to do this:
CPY OBJ('/usr/tivoli/tsm/client/domino/bin/domdsm.cfg.smp')
TOOBJ('/usr/tivoli/tsm/<your_instance_directory>/domdsm.cfg')

CPY OBJ('/usr/tivoli/tsm/client/domino/bin/dsm.opt.smp')
TOOBJ('/usr/tivoli/tsm/<your_instance_directory>/dsm.opt')

CPY OBJ('/usr/tivoli/tsm/client/api/bin/dsm.sys.smp')
TOOBJ('/usr/tivoli/tsm/client/api/bin/dsm.sys')

8.4.3 Modifying Data Protection for Domino configuration files

Before you can actually start using Data Protection for Domino on OS/400, you must
configure at least:
򐂰 The IBM Tivoli Storage Manager server this instance of Data Protection for Domino will
connect to.
򐂰 The path to NOTES.INI of the Lotus Domino server this instance of Data Protection for
Domino will backup.

Modifying dsm.sys configuration file

Parameters for the connection from the client node to the IBM Tivoli Storage Manager server
are defined in the dsm.sys configuration file. This file contains the server name,
communication parameters and node name.

You can edit the dsm.sys file using the Edit File (EDTF) command:
EDTF STMF('/usr/tivoli/tsm/client/api/bin/dsm.sys')

364 Domino 6 for iSeries Best Practices Guide

 Tip: You can also edit configuration files for Data Protection for Domino using iSeries
Navigator.

You must enter information about the IBM Tivoli Storage Manager server this client will
connect to. This includes the following information:
򐂰 servername is the name for this IBM Tivoli Storage Manager server configuration.
The servername does not have to match the IBM Tivoli Storage Manager server name.
This name is used to define all configured parameters of this server for the Data
Protection for Domino instance. If you have more instances of Data Protection for Domino
running on the same iSeries server, you should use the different instance names for this
parameter. For more information see “Configuring Data Protection for Domino for
partitioned Domino servers” on page 372.
򐂰 commmethod defines the communication method for the connection to the IBM Tivoli
Storage Manager server. The only supported communication method is tcpip.
򐂰 tcpport defines the TCP port number for the communication with the IBM Tivoli Storage
Manager server. The default port is 1500.
򐂰 tcpserveraddress is the TCP/IP address or DNS name of the IBM Tivoli Storage Manger
server.
򐂰 nodename is the name of the Data Protection for Domino node as specified in the IBM
Tivoli Storage Manager configuration.

You can obtain the correct information for your environment from your IBM Tivoli Storage
Manager server administrator.

Password handling options in dsm.sys

It is also possible to specify the password handling options (client to IBM Tivoli Storage
Manager server) in the dsm.sys file. The preferred type for the password access option is
GENERATE. This enables the client to automatically generate a new password when the old
one expires on the server.

If you do not set the password handling to GENERATE, you will have to enter a password
each time you start Data Protection for Domino. You can also provide the password to the
domdsmc program with the ADSMPWD=password parameter.

Password handling options are set with the following two parameters:
򐂰 PASSWORDACCESS GENERATE: This option sets the password handling to automatic
generation.
򐂰 PASSWORDDIR: This defines the directory where the tsm.pwd file containing the
passwords will be stored. The default directory for tsm.pwd is /usr/tivoli/tsm/client/api/bin.

For more information on the different client authentication options, see section 6.10.3 “Client
authentication” in the redbook IBM Tivoli Storage Management Concepts, SG24-4877.

Attention: When using the current version (Version 5.2.0) of Data Protection for Domino
with OS/400 you have to create a blank tsm.pwd file manually before using the
PASSWORDACCESS GENERATE option. You can create this file using the EDTF
command, for example:
EDTF STMF('/usr/tivoli/tsm/client/api/bin/tsm.pwd')

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 365
 You can see an extract from the sample dsm.sys file in Example 8-1. We also provide the full
dsm.sys file for our environment in 8.8.1, “Sample configuration files for Data Protection for
Domino” on page 399.

Example 8-1 Sample dsm.sys file for Data Protection for Domino on OS/400
SErvername ITSOBPTSM
COMMmethod TCPip
TCPPort 1500
TCPServeraddress itsobptsm.itsobp.com
NODENAME DOMTDP
PASSWORDACCESS GENERATE
PASSWORDDIR /usr/tivoli/tsm/client/api/bin

If your Data Protection for Domino instances will be accessing different IBM Tivoli Storage
Manager servers, you can specify more servers in one dsm.sys file. For more information see
8.4.7, “Configuring Data Protection for Domino for partitioned Domino servers” on page 372.

Modifying dsm.opt configuration file

The IBM Tivoli Storage Manager server to which an instance of Data Protection for Domino
will connect to is defined in the dsm.opt file. This file is located in the directory of this
particular Data Protection for Domino instance (in our example it is /usr/tivoli/tsm/domtdp).
You can edit the sample file you copied in “Creating Data Protection for Domino configuration
files” on page 364 using the EDTF command:
EDTF STMF('/usr/tivoli/tsm/domtdp/dsm.sys')

The only parameter you have to modify in this file is SErvername — the name of your IBM
Tivoli Storage Manager server. The SErvername parameter has to match the server name
you entered in the dsm.sys file. The example configuration for our environment is:
servername ITSOBPTSM

You can see the dsm.opt file for our environment (server DOMAV) in Example 8-6 on
page 400.

Attention: If you are modifying the supplied sample configuration files, many of the lines
start with an asterisk (“*”), that means, they are marked as comments. If you modify any of
these lines, please make sure you delete the leading “*”.

Modifying domdsm.cfg preferences file

The domdsm.cfg file defines preferences specific to Data Protection for Domino on OS/400.
This file is located in the instance directory of Data Protection for Domino.

You should not use the EDTF command to change the domdsm.cfg configuration file. Data
Protection for Domino provides a special set command for changing parameters in the
domdsm.cfg. For example, you can set the date format to the American style using:
domdsmc set dateformat=1

For the basic configuration of Data Protection for Domino, you have to modify:
򐂰 The path to the NOTES.INI file with the parameter notesinipath:
This parameter specifies which Lotus Domino server this Data Protection for Domino
backs up and restores, for example:
domdsmc set notesinipath=/lotus/data/domtdp

366 Domino 6 for iSeries Best Practices Guide

 򐂰 Include subdirectories in the backup operations using the parameter subdir:
The default setting is not to back up Domino databases in subdirectories. To back up all
databases on a Domino server, including subdirectories, you have to set the value for
parameter subdir to YES, for example:
domdsmc set subdir=yes
򐂰 The date formatting style with the parameter dateformat:
You should use the same date format as set on the IBM Tivoli Storage Manager server.
To set the date format to MM/DD/YYYY, use the following command:
domdsmc set dateformat=1
You can list all preferences for a Data Protection for Domino instance with the query
preferences command:
domdsmc query preferences
Please refer to Example 8-5 on page 400 to see the domdsm.cfg file for server DOMAV in our
environment.

8.4.4 Include/exclude processing options

Optionally, you can configure include/exclude options for your instance of Data Protection for
Domino. Include/exclude processing determines which files are included in backups.

Since Data Protection for Domino on OS/400 deals only with Domino databases and
transaction log files (if archival logging is enabled on the Domino server), you do not need to
exclude any non-Domino files from the backup. You can use include/exclude options to limit
backups to a subset of the Domino databases.

Include/exclude are defined as statements beginning with these words:

򐂰 INCLUDE:
The include statement explicitly includes files for backup processing. If you are using
include statements for Domino databases, you have to include the two parts that are
stored on the IBM Tivoli Storage Manager server - the database itself and its .DATA part.
An example statement is:
INCLUDE DOCLIB.NSF
INCLUDE DOCLIB.NSF.DATA
򐂰 EXCLUDE:
The exclude statement explicitly excludes files from backup processing. You can exclude
Domino databases with a single statement. An example is:
EXCLUDE MAIL.BOX
In Data Protection for Domino, file names are relative to the Domino data directory. If there
are multiple include/exclude statements, they are processed from bottom to top.

Include/exclude options can be defined in two ways:

򐂰 Directly in the dsm.sys file: Include/exclude options are specified directly in the dsm.sys
file under the appropriate SErvername parameter definitions for this Data Protection for
Domino instance.
򐂰 In a separate file that is defined in dsm.sys: You can use a special variable called
INCLEXCL in the dsm.sys file. This variable defines the path and filename of a file that
contains the include/exclude options. Enter the INCLEXCL variable under the appropriate
SErvername parameter definitions, for example:
INCLEXCL /usr/tivoli/tsm/domtdp/inclexcl

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 367
 In this file (in our example, /usr/tivoli/tsm/domtdp/inclexcl), all include/exclude processing
options are defined.

Note: In most environments, include/exclude options will not be used.

For more information on this topic see Appendix D of the IBM Tivoli Storage Manager for
Mail 5.2, Data Protection for Lotus Domino for UNIX and OS/400, Installation and User’s
Guide and Chapter 6, “Backup-archive client” in the redbook IBM Tivoli Storage Management
Concepts, SG24-4877.

8.4.5 Setting QShell environment variables for Data Protection for Domino
Data Protection for Domino uses environment variables to determine where the installation
directories are, which configuration files to use, and where to write log files. If you are using
Data Protection for Domino on OS/400 interactively in QShell, you have to set these variables
before using the product. If you are scheduling backup jobs with scripts, you set the
environment variables in the script. Variables are set with the export command in QShell.

Tip: This is easiest when you use different users for different Lotus Domino server
partitions, that is Data Protection for Domino instances. You can also use scripts to set
environment variables before working interactively with different instances.

QShell environment variables are stored in the .profile file in the user’s /home/username
directory, for example in the /home/tdpuser/.profile file. If the /home/<username> directory
does not exist for the user that will be using Data Protection for Domino, you must create it
first:
CRTDIR DIR(‘/home/<username>’)

Data Protection for Domino provides an example file called sample.profile.smp which can be
modified for your system. This file is located in the /usr/tivoli/tsm/client/domino/bin directory.

Copy the sample.profile.smp file, then modify it:

CPY OBJ('/usr/tivoli/tsm/client/domino/bin/sample.profile.smp')
TOOBJ('/home/<username>/.profile') REPLACE(*YES)

EDTF STMF('/home/<username>/.profile')

Attention: If this user already has a .profile file with modifications, you must edit the file
and merge changes from the sample.profile.smp file manually!

Modify/add the following variables in the .profile file:

򐂰 DOMI_LOG:
Defines the path to the directory for the Data Protection for Domino logs (the default log
file name is domdsm.log).
DOMI_LOG=/usr/tivoli/tsm/domtdp
򐂰 DOMI_CONFIG:
Defines the path to the domdsm.cfg file, for example:
DOMI_CONFIG=/usr/tivoli/tsm/domtdp/domdsm.cfg

368 Domino 6 for iSeries Best Practices Guide

򐂰 DSMI_LOG:
Defines the path to the directory for the IBM Tivoli Storage Manager APIs logs (the default
log file name is dsierror.log). You should use one common APIs log file for all Data
Protection for Domino instances.
DSMI_LOG=/usr/tivoli/tsm/client/api
򐂰 DSMI_CONFIG:
Defines the path to the dsm.opt file.
DSMI_CONFIG=/usr/tivoli/tsm/domtdp/dsm.opt

Note: The DOMI_CONFIG and DSMI_CONFIG variables must point to the files you
created in 8.4.2, “Creating directory and configuration files: Data Protection for Domino
instances” on page 363. DOMI_LOG should point to the same directory, if you want to
store log files there.

򐂰 PATH:
At the end of the PATH variable you must append the path to the data directory of the
Lotus Domino server and the path to the Data Protection for Domino installation directory.
A sample path statement is shown below:
PATH=$PATH:/qibm/userdata/lotus/notes:/qibm/proddata/lotus/notes:/lotus/data/domtdp:
/usr/tivoli/tsm/client/domino/bin
򐂰 QIBM_MULTI_THREADED:
For Data Protection for Domino to work correctly you must set the
QIBM_MULTI_THREADED variable to YES before using the product
(QIBM_MULTI_THREADED=Y).
򐂰 LANG:
The language that Data Protection for Domino uses is controlled by the OS/400 user's
locale setting. Therefore you should add the LANG variable to .profile. Its value
determines the language of Data Protection for Domino messages and outputs. If LANG is
not specified, EN_US is used. For example, to set the locale to German:
LANG=/QSYS.LIB/DE_DE.LOCALE

Important: In the supplied sample.profile.smp file, long entries (for example path or export
statements) are broken into multiple lines using the \ character.

You must write each entry in the .profile file on a single line in OS/400 (use F19 and F20 to
move left and right), otherwise it will not work.

You must also correct the export line in the supplied sample file and put
QIBM_MULTI_THREADED on the same line as all other exports for it to work correctly.

Example 8-2 shows a changed .profile file. Please refer to Example 8-7 on page 400 for the
.profile used for our environment.

Please note that the PATH statement is broken into two lines because of space restrictions.

Example 8-2 Sample .profile file for QShell Data Protection for Domino environment
DOMI_DIR=/usr/tivoli/tsm/client/domino/bin
DOMI_LOG=/usr/tivoli/tsm/domtdp
DOMI_CONFIG=/usr/tivoli/tsm/client/domino/bin/domdsm.cfg
DSMI_DIR=/usr/tivoli/tsm/client/api/bin
DSMI_LOG=/usr/tivoli/tsm/domtdp

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 369
 DSMI_CONFIG=/usr/tivoli/tsm/domtdp/dsm.opt
PATH=$PATH:/qibm/userdata/lotus/notes:/qibm/proddata/lotus/notes:/lotus/data/domtdp:/usr/ti
voli/tsm/client/domino/bin
QIBM_MULTI_THREADED=Y
LANG=/QSYS.LIB/EN_US.LOCALE
export DOMI_DIR DOMI_CONFIG DOMI_LOG DSMI_DIR DSMI_CONFIG DSMI_LOG PATH QIBM_MULTI_THREADED

8.4.6 Verifying Data Protection for Domino configuration

Before using Data Protection for Domino on OS/400 for backup and recovery of your Lotus
Domino server, you should verify if everything is set up correctly. As mentioned before, all
Data Protection for Domino commands are entered in the QShell environment.

To see if Data Protection for Domino is configured properly, you must do the following steps:
1. Check environment variables in QShell.
2. Verify access from Data Protection for Domino to the Lotus Domino server.
3. Verify access from Data Protection for Domino to the IBM Tivoli Storage Manager server.

Check environment variables in QShell

Environmental variables in QShell define the operating parameters for Data Protection for
Domino. To display the environment variables of the current user, use either the set or the
export command in QShell.

All configured environment variables will be displayed in the QShell session. Verify if all
variables set in the .profile file are exported and have correct values. You can see the result of
running the export command on our test system in Figure 8-4. For information on the required
environment variables, please refer to 8.4.5, “Setting QShell environment variables for Data
Protection for Domino” on page 368.

If you do not see Data Protection for Domino environment variables listed in the result of the
export command, you have to check the .profile file in the /home/username directory for
errors.

QSH Command Entry

$
> export
DOMI_CONFIG=/usr/tivoli/tsm/domav/domdsm.cfg
DOMI_DIR=/usr/tivoli/tsm/client/domino/bin
DOMI_LOG=/usr/tivoli/tsm/domav
DSMI_CONFIG=/usr/tivoli/tsm/domav/dsm.opt
DSMI_DIR=/usr/tivoli/tsm/client/api/bin
DSMI_LOG=/usr/tivoli/tsm/domav
HOME=/home/TDPUSER
HOSTID=10.1.92.31
HOSTNAME=AS25.itsobp.com
HOSTTYPE=powerpc
ICU_DATA=/QIBM/ProdData/OS400/icu/data
LOGNAME=TDPUSER

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-4 The export command in QShell

370 Domino 6 for iSeries Best Practices Guide

Verify access from Data Protection for Domino to the Lotus Domino server
Data Protection for Domino uses Lotus Domino APIs to communicate with a Lotus Domino
server. You can check if Data Protection for Domino can connect to your Lotus Domino
server using the following QShell command:
domdsmc query domino

If Data Protection for Domino can connect to your Lotus Domino server, the command will
result in displaying basic information about this server (name, version, and transaction
logging style). An example of running this command on our test system is provided in
Figure 8-5.

If you get an error message running the domdsmc query domino command, you have to check
the path to NOTES.INI in the domdsm.cfg file.

QSH Command Entry

> domdsmc query domino

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/domav/domdsm.log log file has been pruned succes

sfully.

Domino Server Information

-------------------------

Domino Server Name: DOMTDP

Domino Server Level: 6.0
Domino Server Build: 191
Logging: Archive

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-5 Result of querying access to Lotus Domino server with domdsmc

Verify access to the IBM Tivoli Storage Manager server

Data Protection for Domino uses Tivoli Storage Manager APIs to communicate with the IBM
Tivoli Storage Manager server over the network. You can verify whether you are able to
access the IBM Tivoli Storage Manager server (and which parameters are set) using the
domdsmc query adsmserver command. Since this is the first time you are accessing the IBM
Tivoli Storage Manager server, you must also supply the password using the
/ADSMPWD=password option. The complete command to query access to the IBM Tivoli
Storage Manager server for the first time is:
domdsmc query adsmserver /adsmpwd=<password>

You must provide your IBM Tivoli Storage Manager node password on the command.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 371
 This command will access the IBM Tivoli Storage Manager server configured in the dsm.sys
file and display information about the server (server name, TCP/IP address, version, etc.) as
well as basic configuration parameters for this Data Protection for Domino node (node name,
Policy Domain, active policy set, default management class). You can see the results of
running this command on our test system in Figure 8-6.

If you get an error querying the IBM Tivoli Storage Manager server, you have to check the
password supplied with the admspwd option and the dsm.sys and dsm.opt files for correct
configuration parameters.

QSH Command Entry

> domdsmc query adsm /ADSMPWD=tivoli

IBM Tivoli Storage Manager for Mail:
Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.
ACD5221I The /usr/tivoli/tsm/domav/domdsm.log log file has been pruned succes
sfully.
Tivoli Storage Manager Server Connection Information
----------------------------------------------------
Nodename ............................... DOMTDP
NetWork Host Name of Server ............ ITSOBPTSM.ITSOBP.COM
TSM API Version ........................ Version 5, Release 2, Level 0
Server Name ............................ TSMITSOBP
Server Type ............................ OS/400 PASE
Server Version ......................... Version 5, Release 2, Level 0.1
Compression Mode ....................... OFF
Domain Name ............................ ITSOBP
Active Policy Set ...................... STANDARD
Default Management Class ............... STANDARD
$

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-6 Result of querying access to IBM Tivoli Storage Manager server using domdsmc

After running all three verifications successfully, you can start using Data Protection for
Domino for the backup and recovery of your Lotus Domino server.

8.4.7 Configuring Data Protection for Domino for partitioned Domino servers
Lotus Domino server partitioning lets you run multiple Domino servers on a single iSeries
system without using OS/400 logical partitioning (LPAR). Each partitioned Domino server has
its own Domino data directory and NOTES.INI file, but all partitioned servers share the same
code base and libraries.

Each Domino server requires a separate Data Protection for Domino instance for backup and
recovery. We also suggest that you create and use separate user IDs for different instances
of Data Protection for Domino.

372 Domino 6 for iSeries Best Practices Guide

Each Data Protection for Domino instance requires:
򐂰 A directory for the configuration and log files.
򐂰 Separate entries in the dsm.sys file (/usr/tivoli/tsm/client/api/dsm.sys) describing the
connection to the IBM Tivoli Storage Manager server.
򐂰 A domdsm.cfg configuration file for the connection to the Domino server.
򐂰 The dsm.opt configuration file containing the link to the IBM Tivoli Storage Manager server
specified in the dsm.sys file.
򐂰 Different OS/400 user IDs with QShell environment variables set in the .profile file of each
user’s /home/username directory.

The best way to set up additional Data Protection for Domino instances after the first instance
has been configured (see 8.4, “Data Protection for Domino on OS/400 configuration” on
page 361) is:
1. For each additional instance, create a new directory for the configuration and log files.
2. Copy the content of the first Data Protection for Domino instance directory into the new
directory(ies).
See “Creating directory and configuration files: Data Protection for Domino instances” on
page 363.
3. Create new OS/400 user ID(s).
The new user ID(s) must have *ALLOBJ special authority.
4. Copy the .profile file of the original user into the .profile file(s) of the new user(s).
The .profile file is located in the /home/<username> directory.
5. Modify the new .profile file(s).
You must change the following parameters in the new .profile file(s) to point to the different
instance directory(ies) and the respective configuration files:
– DOMI_LOG: new instance directory
– DOMI_CONFIG: domdsm.cfg file in new instance directory
– DSMI_LOG: new instance directory
– DSMI_CONFIG: dsm.opt file in new instance directory
You must also change the PATH variable to include the appropriate data directory for this
Domino server partition.
See 8.4.5, “Setting QShell environment variables for Data Protection for Domino” on
page 368
6. Modify the dsm.sys configuration file.
Change the dsm.sys file (located in /usr/tivolitsm/client/api/bin) and add all parameters
describing the connection to the IBM Tivoli Storage Manager server for each instance (see
Example 8-3 for a dsm.sys file containing entries for multiple Domino servers). Even if all
partitions will connect to the same IBM Tivoli Storage Manager server you must have
different configuration parameters for each Data Protection for Domino instance. You
must define all parameters for each instance as described in “Modifying Data Protection
for Domino configuration files” on page 364. If you have more than one Domino partition
on the same iSeries system, we recommend that you use the Domino server partition
name for the servername parameter instead of the name of the IBM Tivoli Storage
Manager server.
In Example 8-3 we have created three connections to the same IBM Tivoli Storage
Manager server for three different instances of Data Protection for Domino. As suggested,
the connections are using the Domino server name for the SErvername parameter.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 373
 Example 8-3 dsm.sys file containing configuration for multiple Domino server partitions
SErvername DOMAV
COMMmethod TCPip
TCPPort 1500
TCPServeraddress itsobptsm.itsobp.com
NODENAME DOMAV
PASSWORDACCESS GENERATE
PASSWORDDIR /usr/tivoli/tsm/client/api/bin

SErvername DOMCLUS2
COMMmethod TCPip
TCPPort 1500
TCPServeraddress itsobptsm.itsobp.com
NODENAME DOMCLUS2
PASSWORDACCESS GENERATE
PASSWORDDIR /usr/tivoli/tsm/client/api/bin

SErvername DOMTDP
COMMmethod TCPip
TCPPort 1500
TCPServeraddress itsobptsm.itsobp.com
NODENAME DOMTDP
PASSWORDACCESS GENERATE
PASSWORDDIR /usr/tivoli/tsm/client/api/bin
EXCLUDE *.BOX
EXCLUDE LOG.NSF

7. Modify the domdsm.cfg configuration file.

The domdsm.cfg file (located in each new instance directory) contains configuration
parameters for the Domino server partition this instance of Data Protection for Domino will
backup and restore. Parameters in the domdsm.cfg file are changed using the domdsmc
set command.
You must change the notesinipath parameter to point to the data directory of this particular
Domino server. You should also set the SUBDIR and DATEFORMAT parameters (for
more information see “Modifying domdsm.cfg preferences file” on page 366).
8. Modify the dsm.opt configuration file.
The dsm.opt file defines the name of the IBM Tivoli Storage Manager server this instance
will connect to. This is defined using the servername variable. Thus, you must change the
value of this variable to the server name you specified in the dsm.sys file in step 6.

After you have created new Data Protection for Domino instances you should verify if
everything is configured correctly by logging on to OS/400 with the new user ID(s) and
running the tests described in 8.4.6, “Verifying Data Protection for Domino configuration” on
page 370.

You will also have to create or modify scheduled scripts (see “Backup strategies for Domino
servers using Data Protection for Domino” on page 381) with correct parameters before you
will be able to schedule backup and archival operations.

Each time you want to use a certain Data Protection for Domino instance, you have to log on
to OS/400 with the appropriate instance user. You can then check whether you are accessing
the correct Domino server partition by running the following command in QShell:
domdsmc query domino

374 Domino 6 for iSeries Best Practices Guide

8.5 Using Data Protection for Domino
As explained before, Lotus Domino server backups are implemented via the Lotus Domino
server backup API. This API enables backup solutions, such as Data Protection for Domino,
to back up Domino databases online (online means while the Domino server is active). In
addition to online backup, the Domino server APIs allow for incremental backups of Domino
databases and point in time recovery when using transaction logging. Data Protection for
Domino provides backup and recovery capabilities for Domino databases as well as archive
and retrieve options for Domino transaction log extents.

For more information on transaction logging and how to configure it, please refer to
Chapter 5.3, “Transaction logging” on page 252.

Important: For complete disaster recovery, you also need to back up other elements of
Domino and OS/400 on a regular basis (weekly or monthly, depending on your business
requirements). You can do this using the OS/400 save commands and iSeries tape or
DVD-RAM drives or using BRMS. For more information and detailed instructions on the
use of OS/400 save commands, see Chapter 6, “Backup and recovery using OS/400
commands” on page 257.

An online backup of Domino databases with Data Protection for Domino stores a snapshot of
this database on the IBM Tivoli Storage Manager server. Databases stored on an IBM Tivoli
Storage Manager server using Data Protection for Domino have full referential integrity, no
matter what type of transaction logging is used on the Domino server.

Archival of Domino transaction log extents with Data Protection for Domino stores full
transaction log files that are no longer used by the Domino server. The Domino server then
reuses archived log extents and overwrites them with new data.

When designing an appropriate Domino backup strategy for your organization, the main
considerations are as follows:
򐂰 Business requirements and overall enterprise backup strategy
򐂰 Backup window size
򐂰 Storage capacity and network throughput

The backup strategy also determines the appropriate transaction logging style for your
environment. See 5.2, “Choosing the right backup strategy” on page 248 for more information
on this topic.

8.5.1 Backup of Domino databases

Data Protection for Domino offers two different options for backing up Domino databases:
򐂰 Selective backup provides an unconditional online backup of all specified Domino
databases. Selective backup is used for a full backup of Domino server databases.
򐂰 Incremental backup provides a conditional online backup of all specified Domino
databases. The incremental backup saves only databases with new DBIIDs, or
non-logged databases that have been changed since the last backup, to the IBM Tivoli
Storage Manager server. The incremental backup command also performs removal of
deleted Domino databases from the IBM Tivoli Storage Manager server.

Data Protection for Domino always backs up the full Domino database(s) to the IBM Tivoli
Storage Manager server, not just changed documents, no matter what type of backup
(selective or incremental) has been chosen.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 375
 Domino databases can be explicitly excluded or included in the backup processing using
include/exclude options. For more information, see 8.4.4, “Include/exclude processing
options” on page 367. This is a rarely used option, but it is important to remember it when
debugging why some databases are not backed up.

Table 8-1 details whether a Domino database will be saved by a selective or incremental
backup.

Table 8-1 Processing of Domino databases using selective and incremental backup
Database type / changes from last backup Selective backup Incremental backup

New database on server yes yes

Database with new DBIID yes yes

Non-logged database / no changes yes no

Non-logged database / changes yes yes

Logged database / no changes yes no

Logged database / changes yes no

Deleted database not removed removed

For both incremental and selective backups, it is required to specify which Domino
database(s) will be backed up. You can either use the database name(s) or wildcards. An
asterisk (“*”) can be used to select all databases. The database specification is relative to the
Domino data directory. Database selection is not case sensitive, "*" must always be in double
quotes, otherwise double quotes are optional.

Subdirectory processing can be optionally specified using the SUBDIR=YES option. If you
always want to include all subdirectories in your backup processing, you should specify this
option in the Data Protection for Domino preferences configuration (in the domdsm.cfg
configuration file, see “Modifying domdsm.cfg preferences file” on page 366).

The most common selection formulas for database processing using selective backup are:
򐂰 Selection of all database files and all subdirectories in the Domino data directory:
domdsmc selective “*” /subdir=yes
򐂰 Selection of a specific database, for example DOCLIB.NSF:
domdsmc selective “doclib.nsf”
򐂰 Selection of all database files in a specific directory and its subdirectories, for example the
mail directory:
domdsmc selective “mail/*” /subdir=yes
򐂰 Selection of all database files starting with “doc”:
domdsmc selective “doc*”

You can query the Domino server for a list of databases on the server. Use the query domino
command to do so. You can further refine your query by adding a selection parameter:
domdsmc query domino “*” /subdir=yes
domdsmc query domino “cust*” /subdir=yes

The first command will display a list of all databases on the Domino server. The second
command will list all databases starting with “cust”.

376 Domino 6 for iSeries Best Practices Guide

Output of the selective and incremental backup commands provide information on databases
that are being processed and database and network statistics for each database.
Recommended backup types and frequencies for the different backup strategies are listed in
8.5.3, “Backup strategies for Domino servers using Data Protection for Domino” on page 381.

The selective backup command

The selective backup command provides an unconditional backup function that performs a
full online backup of Domino databases. The backup is performed for all specified databases
if they are not specifically excluded from the backup operation using include/exclude
statements (see 8.4.4, “Include/exclude processing options” on page 367).

For example, the selective command for backing up all databases on the Domino server is:
domdsmc selective “*” /subdir=yes

To back up a specific Domino database (in our example, DOCLIBTDP.NSF) the command is:
domdsmc selective “doclibtdp.nsf”

You can see the results of running a selective backup for the single Domino database
DOCLIBTDP.NSF in Figure 8-7.

QSH Command Entry

> domdsmc selective "doclibtdp.nsf"

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/logs/domdsm.log log file has been pruned success

fully.

Starting Domino database backup...

Initializing Domino connection...
Querying Domino for a list of databases, please wait...
Logging on to the Tivoli Storage Manager server, please wait...

Backing up database doclibtdp.nsf, 1 of 1.

Full: 0 Read: 127139840 Written: 127139840 Rate: 702.02 Kb/Sec

Backup of doclibtdp.nsf completed successfully.

Total Domino databases inspected: 1

Total Domino databases backed up: 1
Total Domino databases excluded: 0

Throughput rate: 702.01 Kb/Sec

Total bytes transferred: 127,139,840
Elapsed processing time: 176.86 Secs

$
===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-7 Result of running the selective backup for a single Domino database

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 377
 The selective backup command does not perform removal of deleted Domino databases from
the IBM Tivoli Storage Manager server.

The incremental backup command

The incremental backup command provides a conditional backup function that performs a
backup of specified Domino databases if they are eligible for backup. The Data Protection for
Domino incremental command does not provide an incremental backup of Domino databases
with point in time restore by itself. If you want to use this functionality, please refer to 8.5.3,
“Backup strategies for Domino servers using Data Protection for Domino” on page 381.

A Domino database is eligible for incremental backup if:

򐂰 This database is not excluded from processing by include/exclude options and
򐂰 This database is specified in the selection options of the incremental command and
򐂰 This database has never been saved by Data Protection for Domino (no active backup
exists on the IBM Tivoli Storage Manager server) and
򐂰 This database is not transaction logged and was changed since the last backup or
򐂰 This database is logged and the DBIID changed since the last backup

The following command is an example of the incremental command to back up all changed
databases (see selection criteria above) on the Domino server:
domdsmc incremental “*” /subdir=yes

The results of executing the incremental backup command in our environment is shown in
Figure 8-8.

In our example, the Domino server is using transaction logging and only one non-logged
database was changed since the last backup (DBDIRMAN.NSF). Thus, this database was
saved.

378 Domino 6 for iSeries Best Practices Guide

 QSH Command Entry
> domdsmc incremental "*" /subdir=yes

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/logs/domdsm.log log file has been pruned success

fully.

Starting Domino database backup...

Initializing Domino connection...
Querying Domino for a list of databases, please wait...
Logging on to the Tivoli Storage Manager server, please wait...
Querying Tivoli Storage Manager server for a list of database backups, please
wait...

Backing up database dbdirman.nsf, 1 of 1.

Full: 0 Read: 746496 Written: 746496 Rate: 553.11 Kb/Sec

Backup of dbdirman.nsf completed successfully.

Total Domino databases inspected: 99

Total Domino databases backed up: 1
Total Domino databases excluded: 0
Total Domino backup objects expired: 0

Throughput rate: 314.50 Kb/Sec

Total bytes transferred: 746,496
Elapsed processing time: 2.32 Secs

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-8 Results of running the incremental backup command

8.5.2 Archival of transaction log extents

A Domino server using archive transaction logging writes all transactions to transaction log
extent files which are never deleted from disk. Therefore, the backup software must allow to
archive transaction log extents not used anymore by the Domino server. If you do not archive
these extent files, the Domino server will eventually use all available disk space for these files
and will crash when no more disk space is available.

The Data Protection for Domino archivelog command queries the Domino server to find out
which transaction logs are eligible for archiving and stores these log extents on the IBM Tivoli
Storage Manager server. Once log extent files are archived, the Domino server is notified by
Data Protection for Domino that these log extent files can now be reused. Data Protection for
Domino 5.2.0 on OS/400 also archives the currently filling transaction log extent file which
can be used for disaster recovery purposes.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 379
 The command for archiving logs from the Domino server is:
domdsmc archivelog

You can see the result of running this command in Figure 8-9. In our example, only one
transaction log extent file (currently filling) was saved to the IBM Tivoli Storage Manager
server.

QSH Command Entry

> domdsmc archivelog

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/logs/domdsm.log log file has been pruned success

fully.

Starting Domino transaction log archive...

Initializing Domino connection...
Logging on to the Tivoli Storage Manager server, please wait...

Archiving transaction log file /lotus/data/domtdptl/S0000000.TXN

Full: 0 Read: 67109888 Written: 67109888 Rate: 706.00 Kb/Sec
Archive of /lotus/data/domtdptl/S0000000.TXN completed successfully.

Total Domino transaction log files ready for archive: 1

Total Domino transaction log files archived: 1

Throughput rate: 706.00 Kb/Sec

Total bytes transferred: 67,109,888
Elapsed processing time: 92.83 Secs

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-9 Transaction log archiving with Data Protection for Domino

Data Protection for Domino also provides an option for conditional archival of transaction log
extents by specifying a high and low threshold for space utilization. This condition enables the
administrator to specify when log archiving will start (for example, when 80% of the
transaction log space is reached), and when archiving will stop. For more information, see the
IBM Tivoli Storage Manager for Mail 5.2, Data Protection for Lotus Domino for UNIX and
OS/400, Installation and User’s Guide.

Expiration of Domino transaction log extents on the IBM Tivoli Storage Manager server is
performed through the inactivatelogs command. This command causes the expiration of a
log extent file when all transactions in this file are no longer needed. The transaction logs are
often shared among multiple databases and there may be references to many database
entries in the transaction log. When all databases associated with the transaction logs are no
longer active, then the transaction log entries are no longer needed, the log will be eligible for
expiration, and will be deleted on the IBM Tivoli Storage Manager server.

380 Domino 6 for iSeries Best Practices Guide

 If you are using archival style transaction logging, it is very important to follow the backup and
archiving guidelines detailed in “Incremental backup strategy for the Domino server” on
page 382.

8.5.3 Backup strategies for Domino servers using Data Protection for Domino
The business requirements for your Domino server(s) regarding availability and operation
efficiency are the basis for your backup strategy. Data Protection for Domino provides flexible
options for backing up Domino databases, from daily full backups to incremental backups of
changes to databases.

Here are some important considerations to keep in mind when defining your backup strategy:
򐂰 What is the amount of data to be saved from the Domino servers?
򐂰 What is the length of the backup window on the IBM Tivoli Storage Manager server?
򐂰 What is the available storage space for the backups?
򐂰 What are the restore time requirements?
򐂰 What are considerations for transaction logging on the Domino server?

These are the two most widely used backup strategies with Data Protection for Domino:
򐂰 Full daily backups of all Domino databases:
Full daily backups require more storage space (amount of data on the Domino server
multiplied by the number of backup versions stored on the IBM Tivoli Storage Manager
server) but provide faster restore times. This backup type is possible on Domino servers
not using transaction logging at all or Domino servers using circular or linear transaction
logging. If transaction logging is in use on a Domino server, it is possible to do a point in
time recovery from the last backup of a Domino database.
A full backup is implemented using the selective and incremental commands, depending
on the type of transaction logging style being used. This is explained in more detail in “Full
daily backup strategy for the Domino server” on page 382.
򐂰 Incremental daily backups of changes to Domino databases and weekly full backups:
Incremental backups require less storage space and allow for point in time restores.
However, restoring the data usually takes longer because the archived transaction logs
required for the activation of the database(s) must also be retrieved from the IBM Tivoli
Storage Manager server. Domino servers must use archive transaction logging for this
type of backup.
With this strategy, on a weekly basis, all databases are saved to the IBM Tivoli Storage
Manager server using the selective backup command. Then, on a daily basis, the
transaction log extent files are archived (using the archivelog command), new databases
(new DBIID) and changed non-logged databases are backed up using the incremental
command. For more information see “Incremental backup strategy for the Domino server”
on page 382.

Depending on the various transaction logging styles, there are differences in the backup
operations required for a complete backup protection of your Domino servers:
򐂰 For Domino servers with no transaction logging, full daily backups must be performed.
򐂰 For Domino servers using archive style transaction logging, full backups can be performed
weekly and only new databases and transaction logs are processed daily.

All backup strategies must also include the inactivation of deleted databases and transaction
logs if they are archived.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 381
 Full daily backup strategy for the Domino server
A full backup of Domino databases saves all changed or new databases to the IBM Tivoli
Storage Manager server. The backup operation must also include expiration of deleted
databases (by using the weekly incremental backup command for Domino servers with
transaction logging enabled).

A full backup with Data Protection for Domino without transaction logging requires:
򐂰 Daily incremental backups:
A Data Protection for Domino incremental backup for a Domino server without transaction
logging saves all databases that were changed since the last backup.
Domino servers without transaction logging require full backups daily!

A full backup with Data Protection for Domino with circular or linear transaction logging
enabled requires:
򐂰 Daily selective backups:
The Data Protection for Domino selective backup performs a backup of all databases on
the Domino server.
򐂰 Weekly incremental backups:
The incremental backup for a Domino server with circular transaction logging is used to
inactivate deleted Domino databases on the IBM Tivoli Storage Manager server. On the
day of the incremental backup you must also perform the daily selective backup.

Incremental backup strategy for the Domino server

The incremental backup strategy requires that archive style transaction logging is enabled on
the Domino server. Incremental backups need less backup time and less space to store the
data. This backup strategy also enables full point in time recovery for Domino databases,
although restore times are longer when using incremental backups.

An incremental backup strategy with archive transaction logging enabled requires:

򐂰 Hourly log archiving:
The frequency of log archiving depends on business requirements for disaster recovery
and on the number of changes in the databases. With Data Protection for Domino, you
can schedule hourly log archives and specify a threshold parameter. When doing so, log
archiving occurs only when the predefined percentage of disk space is filled with
transaction logs. For more information see 8.5.2, “Archival of transaction log extents” on
page 379.

Attention: It is very important that you archive your transaction logs regularly when
archive style transaction logging is enabled or your transaction log extents will fill up all
available disk space and the Domino server will eventually crash.

򐂰 Daily incremental backups:

This backup will inactivate deleted Domino databases and save new databases
(databases with changed DBIIDs) as well as non-logged databases that have changed.
򐂰 Weekly selective backups:
The Data Protection for Domino selective backup performs a backup of all databases on
the Domino server to the IBM Tivoli Storage Manager server.

382 Domino 6 for iSeries Best Practices Guide

 򐂰 Weekly inactivation of archived transaction logs:
Inactivation of archived transaction logs should be performed after the weekly selective
backup. This activity will allow non-essential transaction log files to expire.

Note: Data Protection for Domino can also perform full daily backups of all databases
when archive style transaction logging is enabled. In this case, you must adjust the
operation frequency for your selective backups and inactivation of transaction logs from
weekly to daily.

8.5.4 Automating backup operations with Data Protection for Domino

If you wish to automate your backup operations with Data Protection for Domino, you can do
so by running scripts (on all platforms). On iSeries, these scripts are QShell scripts. A QShell
script is similar to other UNIX shell scripts - it is stored in a text file in the IFS and contains the
sequence of commands to be executed.

Sample scripts for Data Protection for Domino operations on OS/400 are provided in the
installation directory of the product. We have modified these scripts for our Data Protection
for Domino environment. Please refer to 8.8.2, “Sample scripts for scheduled Data Protection
for Domino operations” on page 401 for more information on these modified scripts and to
Appendix D, “Additional material” on page 611 for information on how to download them.

The required scripts for Data Protection for Domino operations and their recommended
frequencies are listed in Table 8-2.

Table 8-2 Required scheduled scripts for Data Protection for Domino backups
Backup requirement / Transaction logging Hourly script Daily script Weekly script

Full backup / No transaction logging N/A dominc N/A

Full backup / Circular or linear logging N/A domsel dominc

Incremental backup / Archive logging domarc dominc domsel

domina

These scripts must be stored in the respective directories of your Data Protection for Domino
instances.

A QShell script can be started manually within QShell by entering its name on the command
line. The more common method for running QShell scripts is to enter the QSH command and
add the script name as a parameter, for example:
QSH CMD('/usr/tivoli/tsm/domav/domarc')

8.5.5 Scheduling Data Protection for Domino operations on OS/400

The number and type of scheduled operations needed depends on the type of transaction
logging and the backup requirements in your organization. The recommended operations and
their frequencies are detailed in 8.5.3, “Backup strategies for Domino servers using Data
Protection for Domino” on page 381.

On the iSeries, you can use the Job Scheduler for iSeries or the Advanced Job Scheduler to
schedule your Data Protection for Domino backup operations. Other Data Protection for
Domino platforms use the IBM Tivoli Storage Manager scheduler for centralized scheduling
and management, however there is no IBM Tivoli Storage Manager client scheduler available
for the iSeries platform.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 383
 To schedule Data Protection for Domino operations on OS/400, add the appropriate QShell
script to the OS/400 Job Scheduler using the Add Job Schedule Entry (ADDJOBSCDE)
command.

The following example schedules script dominc (Data Protection for Domino incremental
backup) to run every day at 22:00 hours:
ADDJOBSCDE JOB(DOMTDPINC)
CMD(QSH CMD('/usr/tivoli/tsm/domtdp/dominc'))
FRQ(*WEEKLY)
SCDDAY(*ALL)
SCDTIME(‘22:00')

Scheduled jobs can be verified using the Work with Job Schedule Entries (WRKJOBSCDE)
command. Figure 8-10 shows the jobs scheduled for our Domino server. Alternatively you
can use iSeries Navigator to check for scheduled jobs.

Work with Job Schedule Entries AS25

08/12/03 15:44:34

Type options, press Enter.

2=Change 3=Hold 4=Remove 5=Display details 6=Release
8=Work with last submission 10=Submit immediately

Next
-----Schedule------ Recovery Submit
Opt Job Status Date Time Frequency Action Date
DOMTDPARC SCD *ALL 10:00:00 *WEEKLY *SBMRLS 08/13/03
DOMTDPARC SCD *ALL 16:00:00 *WEEKLY *SBMRLS 08/12/03
DOMTDPINA SCD *SUN 22:00:00 *WEEKLY *SBMRLS 08/17/03
DOMTDPINC Chg *ALL 22:00:00 *WEEKLY *SBMRLS 08/13/03
DOMTDPSEL SCD *SUN 22:00:00 *WEEKLY *SBMRLS 08/17/03
More...
Parameters or command
===>
F3=Exit F4=Prompt F5=Refresh F6=Add F9=Retrieve
F11=Display job queue data F12=Cancel F17=Top F18=Bottom

Figure 8-10 Scheduled Data Protection for Domino jobs on OS/400

For more information on the OS/400 Job scheduler see Chapter 12, “Job Scheduling” in
AS/400e™ Work Management, SC41-5306-03. This book can be obtained from the Web at:
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c4153063.pdf

The Job scheduler is also covered in Chapter 6, “Backup and recovery using OS/400
commands” on page 257 and Chapter 7, “Backup and recovery using BRMS/400” on
page 293.

8.6 Recovering Domino servers and databases

To restore a Domino database with Data Protection for Domino, you retrieve the database
from the IBM Tivoli Storage Manager server to the Domino server. The database can be
restored to the same or a different file name or directory, but it can only be restored to the
Domino server it was saved from.

384 Domino 6 for iSeries Best Practices Guide

 Domino databases that have been backed up from Domino on iSeries can only be restored
back to Domino servers on the iSeries. However, if you move your Domino server(s) to a
different LPAR or to another iSeries system, you can still restore the databases using the
same Data Protection for Domino configuration.

In conjunction with other OS/400 backup solutions (for example BRMS), you can use Data
Protection for Domino for disaster recovery.

8.6.1 Recovering a Domino database

Restoring a Domino database (or group of databases) with Data Protection for Domino is
normally a two step process:
1. The databases are retrieved from the IBM Tivoli Storage Manager server:
The first step is to retrieve the Domino database(s) over the network from the IBM Tivoli
Storage Manager server. Retrieved databases are in an offline status and thus not
available to the Domino server. These restored files have a suffix of “.dad” (for example:
doclib.nsf.dad).
2. The databases are activated on the Domino server:
The second step is to activate the database(s). This function brings the database(s) online
for use by the Domino server. In addition, if transaction logging is enabled on the Domino
server, you can use the activation procedure to apply updates from transaction logs to the
database(s) to facilitate point in time recovery. For Domino servers using circular logging,
changes are applied from transaction logs available on disk. For Domino servers using
archival logging, Data Protection for Domino retrieves the archived transaction logs that
are needed for point in time recovery.

You are also able to retrieve and activate (a) Domino database(s) in one step. However, if
doing so, you are not able to apply updates from the transaction log.

The main advantages of restoring databases in two steps are faster activation when restoring
multiple databases and the option to specify a point in time for application of transaction log
changes.

Important: After you restore and activate a Domino database you must perform a full
backup of this database because a restored database is new to the Domino server and
therefore gets a different DBIID than the original database assigned.

A restored database can be saved with either an incremental or selective Data Protection
for Domino backup. You will not be able to perform subsequent point in time restores until
a full backup has been performed.

Retrieving Domino databases from IBM Tivoli Storage Manager server

A Domino database (or a group of databases) is retrieved from the IBM Tivoli Storage
Manager server using the restore command. The retrieved Domino databases are
temporarily stored as offline databases in the Domino database directory with the suffix
“.dad”.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 385
 When retrieving Domino databases from the IBM Tivoli Storage Manager server, you have to
specify the following parameters:
򐂰 The name(s) of the Domino database(s). On this parameter you can specify a single
Domino database or a group of databases using a wildcard (“*”). When using the wildcard
“*”, it must be enclosed in double quotes, otherwise double quotes are optional.
The command to restore the database called DOCLIB1.NSF is:
domdsmc restore “doclib1.nsf”
You can see result of running this command in Figure 8-11.
򐂰 Optionally you can specify (a) new filename(s) for the restored database(s). To do so, use
the INTO=new_db_name.nsf parameter.
If you are restoring a database to the original file name and thus overwriting the original
database, the Domino server takes the original database offline before proceeding with
the retrieval from the IBM Tivoli Storage Manager server. If the original database is in use
when the restore process is started, the restore is canceled with the error “The database is
in use and cannot be taken offline”.
The command to restore DOCLIB.NSF to the new database name “RESTORE.NSF” is:
domdsmc restore “doclib.nsf” /into=restore.nsf
The database is restored to its original filename if you do not specify the INTO parameter.
When restoring multiple databases, using “/into=“ together with the equals sign (=)
restores the databases with the original names. For example:
domdsmc restore "*" /into=newdir/=
restores all databases into the newdir subdirectory, using their original names.
If you need to keep the existing subdirectory structure, use two equals signs (==). Issuing
domdsmc restore "*" /into=newdir/== /subdir=yes
restores all databases and their subdirectories in the newdir subdirectory.
򐂰 To restore a specific version of a database, use the PIT=date,time parameter. When using
PIT, the restore command retrieves the most recent database backup image taken before
the specified point in time.

Note: The date format is set in the domdsm.cfg configuration file. Time is always in
24-hour format. If the DATEFORMAT parameter is not specified in domdsm.cfg, then
the OS/400 system date format is used.

The following command retrieves the most recent version of DOCLIB.NSF before
08/20/2003, 15:00 from the IBM Tivoli Storage Manager server:
domdsmc restore “doclib.nsf” /pit=08/20/2003,15:00
If there is no version of the database older than the specified date and time found on the
IBM Tivoli Storage Manager server, Data Protection for Domino will return an error stating
that no databases matching the criteria were found on the server.

386 Domino 6 for iSeries Best Practices Guide

 QSH Command Entry

> domdsmc restore doclib1.nsf

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/domtdp/domdsm.log log file has been pruned succe

ssfully.

Starting Domino database restore...

Initializing Domino connection...

Logging on to the Tivoli Storage Manager server, please wait...
Querying Tivoli Storage Manager server for a list of database backups, please
wait...

Restoring database doclib1.nsf, 1 of 1,

to /LOTUS/DATA/domtdp/doclib1.nsf.dad
Full: 0 Read: 125042688 Written: 125042688 Rate: 1,284.15 Kb/Sec
Total database backups inspected: 1
Total database backups requested for restore: 1
Total database backups restored: 1
Total database activated: 0

Throughput rate: 1,284.15 Kb/Sec

Total bytes transferred: 125,042,688
Elapsed processing time: 95.09 Secs
$

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-11 Restoring a Domino database with Data Protection for Domino

򐂰 To activate a database as soon as it is retrieved from the IBM Tivoli Storage Manager
server, use the optional ACTIVATE=YES parameter. This brings the database online to
the Domino server immediately after the restore operation, but no changes from the
transaction logs are written to the restored database. The command to retrieve and
activate the database DOCLIB.NSF in one step is:
domdsmc restore “doclib.nsf” /activate=yes

To finish restoring databases, they are subsequently rolled forward (if selected to the
appropriate point in time) from the transaction logs through the use of the /applylogs option on
the activatedbs command (if ACTIVATE=YES has not been selected). For more information
see “Activation of databases” on page 389.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 387
 Interactive selection of databases for restore — the PICK parameter
There is a user interface available with Data Protection for Domino to select restorable
Domino databases and database versions. The PICK parameter displays a list of all Domino
databases stored on the IBM Tivoli Storage Manager server and allows for interactive
selection of databases to be retrieved from the server. By default, the PICK parameter
displays only the most recent version of Domino databases on the IBM Tivoli Storage
Manager server.

To display a list of databases starting with “doc” (and subsequently select databases from the
list), issue the following command:
domdsmc restore “doc*” /pick

Figure 8-12 shows the result of this command. Please note the different options to scroll, to
select databases, and to start or cancel processing.

QSH Command Entry

> domdsmc restore "doc*.nsf" /pick

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/domtdp/domdsm.log log file has been pruned succe

ssfully.

Starting Domino database restore...

Initializing Domino connection...

Logging on to the Tivoli Storage Manager server, please wait...
Querying Tivoli Storage Manager server for a list of database backups, please
wait...

IBM Tivoli Storage Manager for Mail Scrollable PICK Window - Restore
# DB Backup Date Size A/I Logged Database File
---------------------------------------------------------------------
--
1. | 08/08/03 13:44:36 121.25MB A Yes doclibtdp.nsf
2. | 08/08/03 13:45:57 121.25MB A Yes doclibtdpr.nsf
3. | 08/08/03 15:55:14 15.00MB A Yes doclib1.nsf
|
|
0---------10--------20--------30--------40--------50--------60-------
-7
<U>=Up <D>=Down <T>=Top <B>=Bottom <R#>=Right <L#>=Left
<G#>=Goto Line # <#>=Toggle Entry <+>=Select All <->=Deselect All
<#:#+>=Select A Range <#:#->=Deselect A Range <O>=Ok <C>=Cancel
pick>

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-12 Prompting for databases to restore - PICK parameter

388 Domino 6 for iSeries Best Practices Guide

Use the PICK=SHOWALL parameter if you would like to select and restore a specific version
of a Domino database. This parameter displays a list of all (active and inactive) databases
stored on the IBM Tivoli Storage Manager server. The command to list all versions of all
Domino databases stored on the server is:
domdsmc restore “*” /pick=showall

This command displays all Domino databases that can be retrieved with Data Protection for
Domino. How many versions and how old the Domino databases can be is controlled by
settings in the Policy Domain (for more information see 8.3, “IBM Tivoli Storage Manager
server configuration” on page 359).

Activation of databases
The second step of database recovery is activation. In this step, the restored database is
brought online for use by the Domino server. Database activation is performed using the
activatedbs command.

If your Domino server is configured for transaction logging you can also apply changes from
the transaction logs to the restored database(s). Changes can be applied to any point in time
between the first available full backup and the current time and date. This is always possible
with archive style transaction logging (if you have valid backups). In case of circular logging,
point in time activation depends on the availability of transaction logs (with circular style
transaction logging, the transaction logs are regularly overwritten).

If you are restoring multiple databases to a Domino server that uses archive style transaction
logging, it is best to first retrieve all databases from the IBM Tivoli Storage Manager server
before running activation. This way the required archived transaction logs will be fetched from
the IBM Tivoli Storage Manager server only once. Also, application of changes to all restored
databases will be performed at once for all databases awaiting activation.

To check which databases are awaiting activation, use the query pendingdbs command:
domdsmc query pendingdbs

The result of running this command is shown in Figure 8-13.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 389
 QSH Command Entry
> domdsmc query pending

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/domtdp/domdsm.log log file has been pruned succe

ssfully.

Pending Database List

---------------------

Domino Server: DOMTDP

--------------

Backup Time Stamp Size A/I Logged Database Title Database Fi

le
--------------------- ---------- --- ------ -------------- -----------
--
08/08/03 13:48:08 119.25MB A Yes Document Librar doclib1.nsf

$
===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-13 The query pending command - show restored databases awaiting activation

As mentioned before, activation of Domino databases is performed using the activatedbs

command. Running this command brings all databases awaiting activation online. The
command syntax is:
domdsmc activatedbs

See Figure 8-14 for the result of running this command in our environment with one database
awaiting activation.

390 Domino 6 for iSeries Best Practices Guide

 QSH Command Entry

> domdsmc activatedbs

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.

ACD5221I The /usr/tivoli/tsm/domtdp/domdsm.log log file has been pruned succe

ssfully.

Starting Domino database activation...

Initializing Domino connection...

Logging on to the Tivoli Storage Manager server, please wait...

Activating database doclib1.nsf, 1 of 1,

Activate of doclib1.nsf completed successfully.

Total pending databases inspected: 1

Total pending databases requested for activation: 1
Total pending databases activated: 1

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-14 Activation of restored Domino databases without applying transaction log changes

Provided that your Domino server uses transaction logging (archive, linear or circular style),
the activation process can also apply changes from the transaction log(s) to the database(s)
using the APPLYLOGS parameter. If you specify this parameter without a date and time, the
changes are applied up to the current date and time, otherwise they are applied to the
specified point in time.

Applying changes to the current date and time allows you to recover a database to the last
known good state, that is before it was deleted or corrupted. To activate a database and apply
changes to the current date and time (that is, to the last data written into the transaction log),
issue the following command:
domdsmc activatedbs /applylogs

More often you will be restoring a database to a certain point in time, for example before
some documents were accidentally deleted or modified. In this case you must specify the
desired date and time on the APPLYLOGS parameter, for example:
domdsmc activatedbs /applylogs=08/15/2003,10:00

The date format is set in the domdsm.cfg configuration file; time is always in 24-hour format. If
the DATEFORMAT parameter is not specified in domdsm.cfg, then OS/400 system formatting
is used.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 391
 Figure 8-15 shows the results of a point in time database activation with Data Protection for
Domino.

The Domino console will also display transaction log messages when restoring a database to
a point in time. Refer to Figure 8-16 for an example.

QSH Command Entry

> domdsmc activatedbs /applylogs=08/08/2003,15:40

IBM Tivoli Storage Manager for Mail:

Data Protection for Lotus Domino
Version 5, Release 2, Level 0.0
(C) Copyright IBM Corporation 1999, 2003. All rights reserved.
ACD5221I The /usr/tivoli/tsm/domtdp/domdsm.log log file has been pruned succe
ssfully.

Starting Domino database activation...

Initializing Domino connection...

Logging on to the Tivoli Storage Manager server, please wait...

Starting transaction log file processing...

Restoring transaction log file S0000010.TXN

to /lotus/data/domtdptl/S0000010.TXN
Full: 0 Read: 67109888 Written: 67109888 Rate: 1,114.23 Kb/Sec
Restore of S0000010.TXN completed successfully.

Transaction log file processing completed successfully.

Activating database DOCLIB1.NSF, 1 of 1,

Activate of DOCLIB1.NSF completed successfully.

Total pending databases inspected: 1

Total pending databases requested for activation: 1
Total pending databases activated: 1

Total archived log backups requested for restore: 1

Throughput rate to restore log files: 1,114.21 Kb/Sec
Total bytes transferred to restore log files: 67,109,888
Elapsed processing time to restore log files: 58.82 Secs
$

===>

F3=Exit F6=Print F9=Retrieve F12=Disconnect

F13=Clear F17=Top F18=Bottom F21=CL command entry

Figure 8-15 Activation of restored Domino databases to specific point in time

Media Recovery Replay (0 MB): 100%

08/08/2003 15:47:27 Recovery Manager: Media Recovery complete for /LOTUS/
DATA/domtdp/DOCLIB1.NSF.dad, last update applied.

Figure 8-16 Domino console messages - transaction log operations during database activation

392 Domino 6 for iSeries Best Practices Guide

8.6.2 Performing disaster recovery with Data Protection for Domino
Recovering the complete Domino server assumes a scenario of total failure of the iSeries
system the Domino server was running on, or massive data corruption on that Domino server.
The recovery of a Domino server with Data Protection for Domino requires you to restore both
databases and transaction logs. Disaster recovery might also involve restoring the Domino
server to another iSeries system or rebuilding the original system from scratch. You might
have to first restore or install the operating system (OS/400), the appropriate PTFs and the
Domino code.

Disaster recovery of a Domino server on iSeries might involve doing the following steps:
1. Verify that the Lotus Domino prerequisites are met on the iSeries system which will host
the Domino server.
For information on Lotus Domino prerequisites see “Software installation guidelines and
resources” on page 20.
2. Install Lotus Domino on OS/400.
The Lotus Domino server code must be same version and hotfix level as the server you
are restoring. For more information on installing Lotus Domino on OS/400 see “Installation
best practices” on page 23 and the redbook IBM Lotus Domino 6 for iSeries
Implementation, SG24-6592.
3. Restore the latest version of the SERVER.ID file for this Domino server from your OS/400
backup or other archive.
SERVER.ID is not backed up using Data Protection for Domino.
4. Configure the new Domino server using the same parameters as for the original Domino
server.
You can configure the Domino server either through iSeries Navigator or using the
Configure Domino Server (CFGDOMSVR) command. You should configure the new
server with the same parameters (directory, server tasks, etc.) as used for the original
server. If the original server was the only server in your organization, configure the new
server as “First server or stand-alone server”, otherwise configure the new server as an
“Additional Domino server”.
5. Turn on archive style transaction logging.
If you configured the Domino server as an additional server, just stop and restart the
Domino server. This will create the transaction logs based on the configuration of the
original server from the Domino Directory. If you have configured a stand-alone Domino
server, you must change the transaction log settings in the Server document in the
Domino Directory of the new server. After configuring archive logging you must restart the
Domino server to activate it.
Once archival logging is activated, you must stop the server once again before performing
the next step.
6. Install Data Protection for Domino.
For installation instructions please see 8.2, “Installation of Data Protection for Domino on
OS/400” on page 357.
7. Configure a Data Protection for Domino instance.
For configuration instructions please refer to 8.4, “Data Protection for Domino on OS/400
configuration” on page 361. You have to use the same nodename and configuration as for
the original server. If available, you can use your backup of the directory containing the
Data Protection for Domino configuration files.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 393
 8. Restore all databases you want to recover using Data Protection for Domino.
The Domino server must be stopped during the restore operation. Restore the databases
with the appropriate Data Protection for Domino commands (refer to 8.6.1, “Recovering a
Domino database” on page 385 for details) but do not activate the restored databases. To
restore all Domino databases from the IBM Tivoli Storage Manager use the command:
domdsmc restore “*” /subdir=yes
9. Restore the transaction log extent to be used in the disaster recovery procedure.
In most cases this will be the last transaction log extent archived prior to the data loss.
This is done using the following command:
domdsmc restorelogarchive
This transaction log will be used to rebuild the transaction log control file. Write down the
name of this transaction log.
10.Delete the contents of the Domino transaction log directory except for the transaction log
extent you restored in step 9.
You can use the Work with Object Links (WRKLNK) command to display the transaction
log directory and delete all files, except the one noted in step 9 (use option 4 = Remove to
do so). The command is:
WRKLNK ‘/LOTUS/DATA/DOMTDP/LOGDIR/*.*’
11.Enable the recreation of the transaction log control file nlogctrl.lfh in NOTES.INI.
To do so, modify the NOTES.INI file of the new Domino server using option 13 on the
Work with Domino Servers (WRKDOMSVR) screen. Add the following setting:
TRANSLOG_Recreate_Logctrl=1
If this entry already exists in NOTES.INI, change the setting to 1.
12.Run fixup on a database you are not recovering (for example on LOG.NSF).
Issue the following command on an OS/400 command line to run fixup against LOG.NSF:
RUNDOMCMD SERVER(<servername>) CMD(CALL PGM(QNOTES/NFIXUP) PARM(LOG.NSF))
After fixup completes, the TRANSLOG_Recreate_Logctrl entry in NOTES.INI will
automatically be reset to 0.
13.Activate the databases.
See “Activation of databases” on page 389 for information. When you activate your
databases, all transactions will be applied to the current date and time. For disaster
recovery this represents the last archive of your transaction logs. Use the applylogs
parameter if you want to restore the databases to a different point in time. The command
to apply logs to the current date and time is:
domdsmc activatedbs
14.Start the Domino server using the Start Domino Server (STRDOMSVR) command:
STRDOMSVR SERVER(<servername>)
15.Install all Domino add-on programs and applications as used on the original server.
If this overwrites any of the recently restored databases, you should restore and activate
these databases again from the backup.
16.Modify NOTES.INI with any customizations that were in effect on the original server.
We recommend that you copy the modifications from a saved version of NOTES.INI to
NOTES.INI on the new server. It is not advisable to copy the whole original file over the
new one.

394 Domino 6 for iSeries Best Practices Guide

 17.Replicate with all Domino servers that contain copies of the databases.
By replicating with all servers that contain copies of the databases you synchronize any
changes made to the databases on other Domino servers during disaster recovery.
18.Use Data Protection for Domino to perform full backups of all databases.
The DBIIDs of the recovered databases have not changed. As a result, these backups
must be performed as selective backups, not incremental backups. To perform a backup of
all databases you can use the command:
domdsmc selective “*” /subdir=yes
19.Use Data Protection for Domino to archive the transaction log.
The transaction log used in the recovery procedure will be modified and available for
archiving. This transaction log will also have the ID of the current logger on this Domino
server.

Tip: If you have a full backup of your entire system - including all Domino data - you can
restore the system and the Domino server from this backup first and then continue with
step 8 on page 394.

8.7 Considerations and best practices for Data Protection for

Domino on OS/400
To design a successful Data Protection for Domino implementation on OS/400, you must
consider:
򐂰 Backup of OS/400 libraries and files and Domino data not saved by Data Protection for
Domino
򐂰 IBM Tivoli Storage Manager system
򐂰 Data Protection for Domino configuration
򐂰 Network design

Backup of OS/400 libraries and files and additional Domino data

Data Protection for Domino only backs up Domino database files and transaction log extents.
A complete backup of a Domino server must also include all other files in the Domino data
directory (such as ID files, NOTES.INI, etc.) and the Domino libraries. For a disaster recovery
of an iSeries server it is also required to have a valid backup of the OS/400 system libraries,
other product libraries, and IFS files.

You can use the native OS/400 save and restore commands to back up this data. For more
information and recommendations on procedures and frequencies of these backup
operations, see Chapter 6, “Backup and recovery using OS/400 commands” on page 257.

IBM Tivoli Storage Manager system

An IBM Tivoli Storage Manager system is usually designed as a centralized backup solution
for different enterprise systems. Data Protection for Domino is just one possible client node
using the IBM Tivoli Storage Manager resources (storage, network bandwidth) of an IBM
Tivoli Storage Manager server. So it is necessary to involve different functional teams in the
deployment of a Data Protection for Domino solution.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 395
 Such a project team should include people from these areas:
򐂰 IT infrastructure planning
򐂰 IBM Tivoli operations and administration
򐂰 OS/400 operations and administration
򐂰 Lotus Domino operations and administration
򐂰 Network design and operations

When designing a Data Protection for Domino solution, you must take into consideration:
򐂰 Business requirements for backup and disaster recovery
򐂰 Amount of data in Domino databases — for full backup
򐂰 Daily/weekly changes of data — for log sizes and log extent archival
򐂰 Available network throughput
򐂰 Available storage on IBM Tivoli Storage Manager server

These tips will help you managing your Data Protection for Domino environment:
򐂰 We recommend that you create a separate Policy Domain for your Data Protection for
Domino nodes. For transaction log archiving, the log extents must be stored as long as the
full database backups are kept on the IBM Tivoli Storage Manager server. This is easily
achievable if you use the same Management Class for full backups and transaction log
archiving.
򐂰 Each Domino partition requires its own Data Protection for Domino instance and each of
these instances is a node to the IBM Tivoli Storage Manager server. This means you must
create a separate node for each Data Protection for Domino instance.
򐂰 To optimize the recovery process, use collocation for the file space containing the
transaction log files if they are stored on sequential media on the IBM Tivoli Storage
Manager server. The transaction log files are normally stored in a separate file space from
the database files on the IBM Tivoli Storage Manager server.

Data Protection for Domino configuration

Here is a list of requirements and recommendations when using Data Protection for Domino:
򐂰 As you know, all Data Protection for Domino operations are performed in QShell and
configuration is achieved using text files. Thus, operators of a Data Protection for Domino
environment must have a basic knowledge of QShell (or other UNIX shells) in addition to
their Domino and OS/400 skills.
򐂰 We recommend that you create different directories for each Data Protection for Domino
instance and use these directories to hold all configuration and log files. For more
information on this topic see 8.4, “Data Protection for Domino on OS/400 configuration” on
page 361.
򐂰 The default configuration parameters provided with Data Protection for Domino are
optimized for operation of the product on OS/400. It is not recommended to change the
default parameters without consulting IBM Software support.
򐂰 For better performance of Data Protection for Domino on OS/400 we recommend
increasing the size of the internal TCP buffer in the IBM Tivoli Storage Manager APIs
configuration to 512 KB. This value is configured in the dsm.sys file (located in
/usr/tivoli/tsm/client/api/bin) separately for each node (instance) with the parameter
TCPBUFFSIZE, for example:
TCPBUFFSIZE 512
Although it uses more memory, a larger TCP buffer can improve communication
performance. Test your performance before setting this parameter to determine the effect
of the change.

396 Domino 6 for iSeries Best Practices Guide

 򐂰 If you are running multiple Lotus Domino server partitions on one iSeries system, you can
schedule parallel Data Protection for Domino backup sessions. In our tests we have been
able to back up several instances at the same time without decreasing the throughput rate
of each backup. This way we have been able to use more available network bandwidth for
the data transfer from our iSeries to the IBM Tivoli Storage Manager server.

Network design
Data Protection for Domino transfers data to and from the IBM Tivoli Storage Manager server
over the TCP/IP network. The duration of backup and restore operations is therefore directly
correlated to the network throughput between the iSeries system running Data Protection for
Domino and the IBM Tivoli Storage Manager server. You must allocate appropriate network
bandwidth for backup and restore operations when you are designing your backup solution.

Data Protection for Domino uses the Tivoli Storage Manager APIs for communication with the
IBM Tivoli Storage Manager server and you can expect network performance to be similar to
Backup, Recovery, and Media Services for iSeries (which uses the same APIs). Please refer
to the BRMS application client performance Web site at:
http://www.ibm.com/servers/eserver/iseries/service/brms/adsmperf.htm

This Web site lists performance considerations and measurements for different iSeries
servers and network speeds for BRMS using the Tivoli Storage Manager APIs.

Here are some general observations, relevant to Data Protection for Domino, that can be
concluded from these tests:
򐂰 Performance appears to be proportional to the CPW (Commercial Processing Workload)
available for the backup job.
򐂰 Performance appears to be proportional to the available network bandwidth.
򐂰 Performance on older iSeries models may be limited if the communications IOA is
attached to a shared multi-function IOP.
򐂰 CPU utilization typically increases proportionally with the effective network data rate.
򐂰 Performance when saving large objects is always better than saves of small objects.

Due to the increasing amounts of data held in Domino databases and mail files, we
recommend setting up a separate network for backup and recovery operations with the IBM
Tivoli Storage Manager server. This includes a separate network adapter on your iSeries and
a separate network backbone for connecting all nodes (including Data Protection for Domino)
to the IBM Tivoli Storage Manager server. Use a network speed of 1 GB/second or higher.

This design ensures very fast incremental and full backups. According to the performance
tests mentioned above, the network throughput can be as fast as 59 GB per hour on an
iSeries model 820 with 3200 CPW over a 1 GB Ethernet network. Restoring and recovering
databases over a separate backup/restore network does not significantly impact the
performance of the Domino server. Having a separate network also enables frequent log
archiving operations without impacting the users of this Domino server.

8.7.1 Monitoring operations with Data Protection for Domino

Data Protection for Domino writes some basic information about its operations in text log files
stored in the IFS. The results of running Data Protection for Domino operations can be
redirected to text files.

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 397
 Note: The Data Protection for Domino iSeries job does not write messages to the OS/400
joblog.

Logging information can be found in the domdsm.log file (located in the Data Protection for
Domino instance directory). The domdsm.log file contains the following information:
򐂰 Which Data Protection for Domino operation was started?
򐂰 When was the operation started?
򐂰 Basic configuration parameters for Data Protection for Domino preferences.
򐂰 Summary results of running the operation, including statistical information.

The results of Data Protection for Domino operations are displayed in the console and can be
redirected to a test file. Use the “>>” operator in QShell to do so. This output includes
information on:
򐂰 Each database being processed
򐂰 Size of database
򐂰 Network throughput and statistics

Information about objects stored on the IBM Tivoli Storage Manager server and session
statistics can also be found in the Activity Log of the IBM Tivoli Storage Manager server.

8.8 Sample configuration files and scripts

As explained in 8.3, “IBM Tivoli Storage Manager server configuration” on page 359, the
entire configuration and scheduled operation of Data Protection for Domino is achieved using
text files and scripts. In this section we provide sample configuration files and QShell scripts
from our environment. You can copy and modify these text files to be used in your Data
Protection for Domino projects. For your convenience you can download these files from the
ITSO repository Web site. Please refer to Appendix D, “Additional material” on page 611 for
instructions on how to do this.

Our Data Protection for Domino environment consisted of three Domino server partitions on
two different iSeries servers:
򐂰 System 1 - AS25:
– DOMAV/AV/ITSOBP - A Domino server with archival transaction logging enabled
– DOMCLUS2/SVR/ITSOBP - A Domino server not using transaction logging
򐂰 System 2 - AS09:
– DOMTDP/SVR/ITSOBP - A Domino server with archival transaction logging enabled

This section shows the configuration files and scripts for the DOMAV Domino server. The files
for our other Data Protection for Domino instances are similar to these files and are not listed
here, in the interest of space limitations.

Attention: Due to space constraints, some of the lines are split into two lines in our sample
files. You must enter them on a single line in your files to work correctly.

Don’t forget to change the path information to your Data Protection for Domino instance
directory when using these files.

398 Domino 6 for iSeries Best Practices Guide

8.8.1 Sample configuration files for Data Protection for Domino
The configuration files needed for a Data Protection for Domino instance are:
򐂰 dsm.sys: The IBM Tivoli Storage Manager system options file (Example 8-4)
򐂰 domdsm.cfg: The Data Protection for Domino preferences file (Example 8-5)
򐂰 dsm.opt: The IBM Tivoli Storage Manager client options file (Example 8-6)

You need only one dsm.sys file per OS/400 instance (iSeries server or LPAR), but different
domdsm.cfg and dsm.opt files for each Data Protection for Domino instance.

In addition to the Data Protection for Domino configuration files, the user running the domdsmc
commands also needs a .profile file in his home directory (see Example 8-7). We recommend
that you use different OS/400 user IDs for different Data Protection for Domino instances.

Example 8-4 Sample dsm.sys client system options file

************************************************************************
* Data Protection for Lotus Domino Client System Options File *
* Location: /usr/tivoli/tsm/client/api/bin/dsm.sys *
************************************************************************

SErvername DOMAV
COMMmethod TCPip
TCPPort 1500
TCPServeraddress ITSOBPTSM.ITSO.COM
NODENAME DOMTDP
PASSWORDACCESS GENERATE
PASSWORDDIR /usr/tivoli/tsm/client/api/bin
TCPBUFFSIZE 512

SErvername DOMCLUS2
COMMmethod TCPip
TCPPort 1500
TCPServeraddress ITSOBPTSM.ITSO.COM
NODENAME DOMCLUS2
PASSWORDACCESS GENERATE
PASSWORDDIR /usr/tivoli/tsm/client/api/bin
TCPBUFFSIZE 512

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 399
 Example 8-5 Sample domdsm.cfg preferences file
************************************************************************
* Data Protection for Lotus Domino Preferences File *
* Location: /usr/tivoli/tsm/domav/domdsm.cfg *
************************************************************************

BUFFers 3
BUFFERSIze 1024

LOGFile domdsm.log
LOGPrune 60

REPlace yes
SUBDir yes
MOUNTWait yes

NOTESIniPath /lotus/data/domav

LastPruneDate

Example 8-6 Sample dsm.opt options file

************************************************************************
* Data Protection for Lotus Domino Options File *
* Location: /usr/tivoli/tsm/domav/domdsm.cfg *
************************************************************************

Servername DOMAV

Example 8-7 Sample .profile file for Data Protection for Domino instance user
************************************************************************
* Profile file for Data Protection for Domino instance DOMAV user *
* Location: /home/domavbku/.profile *
************************************************************************

DOMI_DIR=/usr/tivoli/tsm/client/domino/bin
DOMI_LOG=/usr/tivoli/tsm/domav
DOMI_CONFIG=/usr/tivoli/tsm/domav/domdsm.cfg
DSMI_DIR=/usr/tivoli/tsm/client/api/bin
DSMI_LOG=/usr/tivoli/tsm/domav
DSMI_CONFIG=/usr/tivoli/tsm/domav/dsm.opt

PATH=$PATH:/qibm/userdata/lotus/notes:/qibm/proddata/lotus/notes:/lotus/data/domav:/usr/tiv
oli/tsm/client/domino/bin

QIBM_MULTI_THREADED=Y

LANG=/QSYS.LIB/DE_DE.LOCALE

export DOMI_DIR DOMI_CONFIG DOMI_LOG DSMI_DIR DSMI_CONFIG DSMI_LOG PATH QIBM_MULTI_THREADED

400 Domino 6 for iSeries Best Practices Guide

8.8.2 Sample scripts for scheduled Data Protection for Domino operations
Each Data Protection for Domino instance uses its own scripts for scheduled operations. The
following four script files are sufficient for all scheduled Data Protection for Domino tasks for
one Domino server partition.

These are the sample scripts for scheduled Data Protection for Domino operations provided
in this section:
򐂰 Domarc: Log archiving to the IBM Tivoli Storage Manager server (Example 8-8 below)
򐂰 Domina: Log inactivation on the IBM Tivoli Storage Manager server (Example 8-9 on
page 402)
򐂰 Dominc: Data Protection for Domino incremental backup (Example 8-10 on page 403)
򐂰 Domsel: Data Protection for Domino selective backup (Example 8-11 on page 404)

The use of these sample scripts will result in multiple log files — one common log file
(domdsm.log) which is also used by the interactive domdsmc commands, and several log files
that use the respective script name plus the extension “.log” (for example dominc.log).

Again, when using these scripts, don’t forget to change the paths to your Data Protection for
Domino instance directory, configuration files, and log files.

Example 8-8 Sample domarc script for log archiving with Data Protection for Domino
#!/usr/bin/qsh
#
# ===================================================================
# Domarc file is used to do a scheduled archiving of transaction
# logs to IBM Tivoli Storage Manager server
# ===================================================================
export DOMI_DIR=/usr/tivoli/tsm/client/domino/bin
export DOMI_CONFIG=/usr/tivoli/tsm/domav/domdsm.cfg
export DSMI_DIR=/usr/tivoli/tsm/client/api/bin
export DSMI_CONFIG=/usr/tivoli/tsm/domav/dsm.opt
export LOG_DIR=/usr/tivoli/tsm/domav
export QIBM_MULTI_THREADED=Y

# ===================================================================
# Update PATH with the Domino server data directory
# ===================================================================
export PATH=$PATH:/qibm/userdata/lotus/notes:/qibm/proddata/lotus/notes:/lotus/data/domav

# ===================================================================
# Put a date and time stamp in a log file for yourself.
# ===================================================================

date >> ${LOG_DIR}/domarc.log

# ===================================================================
# Now call the commandline to do the backups.
# ===================================================================
cd ${DOMI_DIR}
${DOMI_DIR}/domdsmc archivelog -adsmoptfile=${DSMI_CONFIG }-logfile=${LOG_DIR}/domdsm.lo g
>> ${LOG_DIR}/domarc.log

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 401
 Example 8-9 Sample domina script for transaction log inactivation
#!/usr/bin/qsh
#
# ===================================================================
# Domina file is used to do a scheduled inactivation of transaction
# logs stored on IBM Tivoli Storage Manager server
# ===================================================================
export DOMI_DIR=/usr/tivoli/tsm/client/domino/bin
export DOMI_CONFIG=/usr/tivoli/tsm/domav/domdsm.cfg
export DSMI_DIR=/usr/tivoli/tsm/client/api/bin
export DSMI_CONFIG=/usr/tivoli/tsm/domav/dsm.opt
export LOG_DIR=/usr/tivoli/tsm/domav
export QIBM_MULTI_THREADED=Y

# ===================================================================
# Update PATH with the Domino server data directory
# ===================================================================
export PATH=$PATH:/qibm/userdata/lotus/notes:/qibm/proddata/lotus/notes:/lotus/data/domav

# ===================================================================
# Put a date and time stamp in a log file for yourself.
# ===================================================================

date >> ${LOG_DIR}/domina.log

# ===================================================================
# Now call the commandline to do the backups.
# ===================================================================
cd ${DOMI_DIR}
${DOMI_DIR}/domdsmc inactivatelogs -adsmoptfile=${DSMI_CONFIG}-logfile=${LOG_DIR}/domds
m.log >> ${LOG_DIR}/domina.log

402 Domino 6 for iSeries Best Practices Guide

Example 8-10 Sample dominc script for Data Protection for Domino incremental backup
#!/usr/bin/qsh
#
# ===================================================================
# Dominc file is used to do a scheduled incremental backup of Domino
# databases including subdirectories
# ===================================================================
export DOMI_DIR=/usr/tivoli/tsm/client/domino/bin
export DOMI_CONFIG=/usr/tivoli/tsm/domav/domdsm.cfg
export DSMI_DIR=/usr/tivoli/tsm/client/api/bin
export DSMI_CONFIG=/usr/tivoli/tsm/domav/dsm.opt
export LOG_DIR=/usr/tivoli/tsm/domav
export QIBM_MULTI_THREADED=Y

# ===================================================================
# Update PATH with the Domino server data directory
# ===================================================================
export PATH=$PATH:/qibm/userdata/lotus/notes:/qibm/proddata/lotus/notes:/lotus/data/domav

# ===================================================================
# Put a date and time stamp in a log file for yourself.
# ===================================================================

date >> ${LOG_DIR}/dominc.log

# ===================================================================
# Now call the commandline to do the backups.
# ===================================================================
cd ${DOMI_DIR}
${DOMI_DIR}/domdsmc incremental "*" /subdir=yes -adsmoptfile=${DSMI_CONFIG} -logfile=${L
OG_DIR}/domdsm.log >> ${LOG_DIR}/dominc.log

Chapter 8. Backup and recovery using Tivoli Data Protection for Domino 403
 Example 8-11 Sample domsel script for Data Protection for Domino selective backup
#!/usr/bin/qsh
#
# ===================================================================
# Domsel file is used to do a scheduled selective backup of all
# Domino databases including subdirectories
# ===================================================================
export DOMI_DIR=/usr/tivoli/tsm/client/domino/bin
export DOMI_CONFIG=/usr/tivoli/tsm/domav/domdsm.cfg
export DSMI_DIR=/usr/tivoli/tsm/client/api/bin
export DSMI_CONFIG=/usr/tivoli/tsm/domav/dsm.opt
export LOG_DIR=/usr/tivoli/tsm/domav
export QIBM_MULTI_THREADED=Y

# ===================================================================
# Update PATH with the Domino server data directory
# ===================================================================
export PATH=$PATH:/qibm/userdata/lotus/notes:/qibm/proddata/lotus/notes:/lotus/data/domav

# ===================================================================
# Put a date and time stamp in a log file for yourself.
# ===================================================================

date >> ${LOG_DIR}/domsel.log

# ===================================================================
# Now call the commandline to do the backups.
# ===================================================================
cd ${DOMI_DIR}
${DOMI_DIR}/domdsmc selective "*" /subdir=yes -adsmoptfile=${DSMI_CONFIG} -logfile=${LOG
_DIR}/domdsm.log >> ${LOG_DIR}/domsel.log

404 Domino 6 for iSeries Best Practices Guide

 9

Chapter 9. Antivirus protection

In this chapter we describe the threats your Domino environment is exposed to by malicious
code, and we give an overview on e-mail content security options. Different options for
antivirus and spam protection and content filtering are presented for Domino servers running
on OS/400. We also provide a quick start for implementing Trend Micro ScanMail for Lotus
Notes 2.6 for OS/400 in your environment and best practices for this solution.

Important: Throughout this chapter you will find information and material from Symantec
Corporation and Trend Micro, Inc. This material was reprinted by permission of Symantec
Corporation and Trend Micro, Inc.

This chapter discusses the following topics:

򐂰 e-mail content security and virus threats
򐂰 Solutions for antivirus protection and content security for Domino on OS/400:
– Anti-spam features of Lotus Domino 6
– Symantec AntiVirus/Filtering for Domino 3.0 for OS/400
– Trend Micro ScanMail for Lotus Notes 2.6 for OS/400

Note: We have described Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 in more
detail than Symantec AntiVirus/Filtering 3.0 for Domino on iSeries because of the available
skills in the team that wrote this redbook. This does not mean that we recommend one
product over the other.

© Copyright IBM Corp. 2004. All rights reserved. 405

9.1 e-mail content security and virus threats
Organizations today are highly dependent on distributed computing environments for all
operations. Computers and other devices are connected to global networks which enable
modern IT systems. In addition to many easily recognizable advantages, the Internet
revolution brought proliferation of very dangerous malicious code.

Computer viruses and worms can spread through computer networks with lightning speed
using different points of entry (e-mail, network shares, peer-to-peer systems, etc.). The
payloads carried by these viruses are also getting more and more dangerous - from the ability
to take over control of the computer to the orchestrated distributed denial of service attacks
which can bring down the entire Internet.

Each organization must take the threats it is exposed to very seriously. The cleanup costs and
loss of productivity caused by each occurrence of malicious code can run into billions of
dollars. It is essential for every organization to design and implement an antivirus policy and
technologies as part of the overall IT security.

e-mail provides a new ubiquitous form of communication that is being used as the primary
channel in many organizations. Design and low cost of Internet e-mail allowed proliferation of
unwanted messages and mass mailings. This reception of unsolicited commercial e-mail is
often referred to as spam.

Spam is the only known form of advertising that is more expensive for its audience than for
the advertiser. Due to the significant loss of productivity, organizations all over the world are
spending large amounts of money combating spam.

The easy transfer of information and documents also carries new risks for organizations.
Nowadays it is very easy to transmit sensitive or inappropriate information undetected to
unauthorized recipients.

Spam and unauthorized transfer of sensitive information is being addressed using solutions
for content security. They provide filtering and journalling of e-mail messages using simple
rules or complex algorithms. Content security solutions can help organizations to drastically
decrease the amount of spam in user’s mailboxes and capture sensitive information being
transmitted.

The Domino server as an e-mail and groupware server is usually one of the first entry points
that has to be addressed for antivirus and content security in the organization. In this chapter
we provide an overview of the options available for antivirus protection of Domino servers
running on an iSeries system and content security of Domino e-mail messages.

9.1.1 Threat of malicious code

Any computer program or code written by an ill-intentioned programmer that causes
unexpected results, unauthorized use of computer resources or damage to computer systems
is defined as malicious code. Computer viruses represent the majority of all known malicious
code. Other major types are worms and trojans.

Viruses
A computer virus is a program that has the ability to replicate and spread between different
computers. Viruses attach themselves to different types of computer files and are spread
when files are copied or distributed between individuals. Most computer viruses also cause
intentional damage, for example they destroy files, format the hard drive, or crash the
operating system. Viruses without damaging code (they might just display a message on the

406 Domino 6 for iSeries Best Practices Guide

screen) can still cause damage by consuming disk space and memory, and degrading the
overall performance of your computer.

Macro viruses
A special kind of computer viruses are macro viruses. They are written in the popular
programming language Visual Basic and usually infect word processing and spreadsheet
files. Macro viruses spread easily due to the ubiquity of Microsoft Office programs.

Worms
A computer worm is a self-contained program that is able to spread functional copies of itself
or its segments to other computer systems. The propagation usually takes place via network
connections or e-mail attachments.

Trojans
A trojan is malicious code that performs unexpected or unauthorized actions. A trojan
program preforms a malicious function in addition to regular operations of the program. The
main difference between a trojan and a virus is the inability to replicate.

Blended threats
Most new viruses today are a combination of different types, for example computer viruses
that are trojan, but with the virus-like or worm-like ability to replicate. So a blended threat
utilizes multiple methods and techniques to transmit and spread an attack. This type of
blended attack is also the most dangerous type. According to Symantec, blended threats
increased nearly 20% during the first half of 2003 over the last half of 2002.

These are characteristics of blended threats:

򐂰 Causes harm: Some attacks have been known to launch a denial of service attack at a
target IP address, to deface Web servers and to leave trojan horses behind for later
execution.
򐂰 Multiple methods of propagation: These threats automatically scan for one of the many
vulnerabilities it understands in order to compromise a system. The propagation methods
include:
– Embedding into the HTML files of infected server
– Infecting any visitors to that Web site
– Sending out e-mail from compromised servers with a worm in the attachment
򐂰 Multiple points of attack: For example, Nimda, a blended threat, injected malicious code
into each .exe file on the system, raised the privilege level of the guest account, created
world read and writable network shares, made numerous registry changes, and injected
script code into HTML files. Damage to many points of the system makes cleanup
especially difficult.
򐂰 Spreads without human intervention: Unlike viruses, which rely on people to spread
the infected files, blended threats are automated always scanning the Internet for
vulnerable servers to attack.
򐂰 Exploits vulnerabilities: Blended threats take advantage of known vulnerabilities such
as buffer overflows, HTTP input validation vulnerabilities, and known default passwords as
common points of exploitation. Once unauthorized administrative access is gained on a
server, the information stored at the root level can be opened up.

For detailed information on blended threats, please refer to the article “The New Danger:
Blended Threats” on the Symantec Web site at:
http://enterprisesecurity.symantec.com/content.cfm?articleid=967&PID=9929124&EID=0

Chapter 9. Antivirus protection 407

 Facts
Several years ago, most viruses spread primarily via floppy disk, but the Internet has
introduced new virus distribution mechanisms. With e-mail now used as an essential
business communication tool, viruses are spreading faster than ever. Viruses attached to
e-mail messages can infect an entire enterprise within minutes, costing companies millions of
dollars annually in lost productivity and cleanup expenses.

Viruses won't go away anytime soon: More than 60,000 have been identified, and, according
to the International Computer Security Association (ICSA, http://www.icsalabs.com),
400 new ones are created every month. With numbers like this, it's safe to say that most
organizations will regularly encounter virus outbreaks. No one who uses computers is
immune to viruses.

The life cycle of a virus begins when it is created, and basically never ends, because most
viruses are never completely eradicated. The following outline describes some stages in the
life of a virus:
򐂰 Creation: Until recently, creating a virus required good knowledge of a computer
programming language. Today, anyone with a basic programming knowledge can create
a virus. Viruses can even be created using automated virus construction kits.
򐂰 Discovery: There are several possibilities to discover a new virus, for example:
– The virus enters a site (via the e-mail system, downloaded files, etc.). Once the
infection is discovered by the user, the suspicious code is sent to the antivirus software
vendor for appropriate action.
– Antivirus software itself may discover it based on the used heuristic technology. For
example, the antivirus software detects suspicious code (possibly a new virus) in a mail
attachment. Depending on the antivirus configuration, the suspicious attachment might
be automatically send to the software vendor who will then take appropriate action.
Another configuration option offered by some vendors is to move suspicious mails into
the quarantine database/directory and to decide individually what to do with it, for
example, delete it or (better) send it manually to the antivirus software vendor.
򐂰 Assimilation: When a new virus is discovered, antivirus software developers may need to
modify their virus pattern files so that it can detect the new virus. This can take anywhere
from a couple of minutes to some hours, depending on the methods used by the vendor,
and the virus type. Typically today the virus definition files are updated within minutes.
Therefore regular updates of virus pattern files are very important. As new viruses are
found often, ideally, the antivirus software should be configured to perform signature file
updating automatically.
򐂰 Eradication: Because not all users use up-to-date virus protection software and patch
their operating systems as new vulnerabilities are discovered, it is hard to eradicate a
virus. However, if enough users take appropriate action, the threat imposed by a virus is
no longer major.

Important: Recent studies show that attacks are being released quicker.

Some years ago, when a new operating system vulnerability was discovered, it took
several months to years before somebody took advantage of that vulnerability. Now the
time from discovery to outbreak shortened greatly. For example, the Blaster worm, which
was one of the biggest threats in August 2003 (while we were writing this redbook), used a
well-known Microsoft security flaw that had been announced only 26 days before.

There are many things you can do to protect your environment against malicious software,
also called “malware”. At the top of the list is using a powerful antivirus product, and keeping

408 Domino 6 for iSeries Best Practices Guide

 it up-to-date with the latest virus pattern files. For more information about protecting your
Domino environment, see 9.2, “Solutions for antivirus protection and content security for
Domino on OS/400” on page 412.

9.1.2 Spam prevention and content filtering

Preventing unwanted content from entering or leaving the corporate network is an essential
necessity for organizations using the Internet, e-mail, and the Web. Even though a virus
infection is still the primary concern regarding corporate security, e-mail content filtering is
becoming a key element of corporate security strategies. Policy enforcement, spam, legal
liability, and regulatory compliance are increasingly driving the need to scan e-mail for
confidential data, inappropriate content, intellectual property, and unsolicited e-mail.

Therefore, in addition to antivirus protection, most organizations must also provide:

򐂰 Spam prevention: Protection from inbound unsolicited e-mail messages.
򐂰 Content security: Filtering outbound e-mail messages for inappropriate content and
confidential information.

The solutions for spam prevention and content security are often separate from the Domino
environment, but they are getting more and more integrated in antivirus products running on
the Domino server.

Spam – unsolicited e-mail

In a very broad sense, spam is the reception of unsolicited commercial e-mail.

Spam is designed to flood the Internet with mass mailings, attempting to reach the largest
audience possible. Most often spammers are merely trying to sell a dubious product, such as
diplomas of unaccredited universities, get-rich-quick schemes, or discounts on prescription
drugs. In a real world example, spam is the equivalent of receiving flyers, mailers, contest
entries, and other junk mail items routinely sent to thousands of households without the
residents having explicitly requested them. The difference, for the average spammer, is not
having to pay printing fees or postage, which makes spam infinitely less expensive than
traditional junk mail.

A very important aspect of what constitutes spam is that spam has negative effects on those
who receive it. Spam is the only form of advertising that is more expensive for its audience
than for the advertiser. It is not simply a case of getting a few extra mail messages a day and
taking a minute or two to delete them. Spam is not targeted at any specific group or person. It
is sent to everyone. Therefore, it can be a very expensive nuisance.

Advertisers pay very small sums of money to acquire huge spamming lists and lists of e-mail
addresses. These lists are gathered from various sources, often with questionable methods,
and sold to anyone who wishes to send out spam. Advertisers then use these lists for
spamming, trying to reach the broadest audience possible.

Spam prevention software solutions and services reduce the amount of spam delivered to the
users in the organization by checking the content of messages and the validity of the sender
or e-mail server.

e-mail content filtering

e-mail is the primary portal through which information flows to external parties. Either through
malice or accident, employees may be responsible for incidents where the e-mail system is
the transport mechanism for material containing information that is confidential, offensive or
breaches privacy.

Chapter 9. Antivirus protection 409

 Through e-mail exchange over the Internet, organizations are faced with many business risks.
The most common risks are:
򐂰 The cost of leaked confidential information
򐂰 The impact of embarrassing incidents appearing in the media
򐂰 The potential legal exposure
򐂰 Loss of productivity

The cost of leaked customer or confidential information can be huge. Customer lists, price
lists and internal memos can easily be forwarded out of the organization by any individual with
access to Internet e-mail. Corporations are also getting more concerned about privacy and
legal exposure, especially in the light of new regulations and legislation in this field.

E-mail content filtering products implement a set of rules that reflect the confidentiality policy
of a company and thus minimize accidental or careless communications by employees.

9.1.3 Complete protection for your environment

The threats of malicious code, spam and e-mail security issues are encouraging more and
more organizations to implement at least some kind of protection. Due to the emergence of
blended attack type viruses and a high amount of spam, it has become important to design
and implement a comprehensive protection for the organization’s IT environment. For a
complete protection of the IT environment in your organization you must implement
appropriate security policies and enforce them with specialized solutions.

Complete antivirus and content security protection for your environment must include:
򐂰 An overall IT security policy
򐂰 Acceptable usage policies for e-mail, the Web, unauthorized files and content, other
Internet activity, etc.
򐂰 Software solutions to protect all points of entry in your IT environment
– Firewall and intrusion detection systems for network level security
– Antivirus software for:
• Workstations and mobile devices
• Server systems
• E-mail and groupware systems
• Internet access systems (for example HTTP traffic)
• e-mail content security
򐂰 Continuous policy monitoring and enforcement as well as end-user education

A more detailed discussion on the topic of comprehensive antivirus protection and content
security is out of the scope of this Redbook. A good starting point to find more information is
the CERT Coordination Center Web page at:
http://www.cert.org

Protect your Domino on iSeries environment

The best protection for your Domino environment running on the iSeries is composed of
these elements:
򐂰 An acceptable e-mail usage policy for your organization. We provide sample steps to
implement such a policy in 9.1.4, “Implementing an acceptable e-mail usage policy for
your organization” on page 411.

410 Domino 6 for iSeries Best Practices Guide

 򐂰 An antivirus and content security solution running on the Domino server or on another
system between the Internet and your Domino environment. This redbook explains the
different options available for Domino on iSeries in 9.2, “Solutions for antivirus protection
and content security for Domino on OS/400” on page 412.

Especially, Windows platforms running a Domino server also require antivirus protection for
the operating system itself. This is not necessary for the iSeries platform because until now
no viruses have been discovered for OS/400. This includes malicious code that could hide
inside RPG and CL programs (or any *PGM object), or inside physical and logical files (or any
*FILE object). Also, it is important to note that OS/400 cannot run .exe files, so viruses
contained in such files cannot affect the iSeries itself.

However, this does not mean that organizations running their Domino server(s) on iSeries are
immune to malicious code stored in the iSeries IFS (allowing for network shares through
Windows), Domino databases or transferred via Domino mail. In fact, the most prevalent ways
of spreading malicious code during the last years have been e-mail and Windows file shares.

9.1.4 Implementing an acceptable e-mail usage policy for your organization

An acceptable e-mail usage policy includes rules and procedures for handling e-mail
messages and content exchanged inside the organization and outside company boundaries
across the Internet. This policy is based on the overall IT security policy and is usually part of
a suite of usage policies for end-users in the organization. A successful implementation of
antivirus and content security policy in any organization includes human and technological
aspects. The implementation project must be staffed by people from Human Resources (HR),
Operations, and the Legal and IT departments.

These are the main steps to introduce an e-mail policy in your organization:
1. Obtain commitment and sponsorship from senior management for the antivirus and
content security implementation. The most important step is to ensure that the upper
management in an organization is aware and understands the technical and legal risks to
the organization. In addition to management, HR or Operations management must be
involved because an e-mail policy is primarily a behavioral issue rather than a technical
one.
2. Create an acceptable e-mail usage policy suitable for your organization. The e-mail usage
policy must be based on the corporate policies for handling sensitive information, privacy
and workplace conduct. The main foundations of the policy are risks and costs your
organization is exposed to by malicious code and unauthorized e-mail messages. This
policy should include attachment handling, procedures for sending sensitive information
and definition of inappropriate e-mail content.
3. Distribute your acceptable e-mail usage policy and introduce it to all e-mail users. Ensure
that all staff managers are aware and supportive of the initiative and the business reasons
driving it.
4. Educate your users on the policy with the focus on the acceptable business usage. As
privacy concerns are also strong among e-mail users, policy education should reinforce
that content filtering is an automated process and nobody has the time or inclination to sit
around looking at all messages.
5. Monitor the e-mail flow for policy compliance. The most effective content filtering is done
by the users themselves and not by an automated technology and it is therefore important
to monitor e-mail patterns and policy compliance. Useful reports include high impact users
(for example, users sending e-mails with large attachments) and the most common policy
deviations (for example multimedia attachments indicating non-business content).

Chapter 9. Antivirus protection 411

 6. Enforce the e-mail policy using software solutions. The e-mail filtering rules used by the
product must match your acceptable e-mail usage policy. This policy must also define the
handling of messages that violate the policy (quarantine, deferred delivery, deletion or
manual review).
The policy enforcement should be implemented in steps to calm potential user
disagreement. Content filtering rules must also be monitored and adjusted to new threats
or changes in organizational e-mail policy.
7. Notify users of possible policy violations. User notifications should be limited only to
internal users and other IT customers. This automatic message should include information
on the type of violation and the handling procedure. The reply should also suggest that
you contact the e-mail Security Administrator if the e-mail rule triggering is incorrect or
invalid.
8. Review the policy and content filter rules. This is a continuous process to refine your policy
and rules to fit the changing business and technological environment. If legislation and
your internal rules permit, you can also generate reports of the offending users having the
most policy violations and present them to management. In some organizations this
process can be performed by HR or Operations staff, thus relieving IT personnel.

The acceptable e-mail usage policy is an issue that all organizations must address. Its
realization includes organizational changes and implementation of appropriate technology.

9.2 Solutions for antivirus protection and content security for

Domino on OS/400
A complete solution for antivirus protection and content security for Domino on OS/400
consists of using the Domino 6 anti-spam features and implementing a third-party antivirus
product.

Server side anti-spam features were introduced to Domino 6 due to large costs of managing
e-mail. They provide fine configuration granularity of the Domino SMTP server and e-mail
filtering options. These features alone do not constitute adequate protection from computer
viruses or provide satisfactory content security.

Specialized third-party products from vendors of antivirus and security software provide
pattern based antivirus protection, feature rich content security and spam protection.

At the time this redbook was written, there were two products available for antivirus protection
and content security for Domino on OS/400:
򐂰 Symantec AntiVirus/Filtering for Domino 3.0 for OS/400 (details can be found in 9.3,
“Symantec AntiVirus/Filtering for Domino 3.0 for OS/400” on page 415).
򐂰 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 (details can be found in 9.4, “Trend
Micro ScanMail for Lotus Notes 2.6 for OS/400” on page 422).

Implementation of one of these products with proper configuration of the Domino anti-spam
features delivers adequate antivirus protection and e-mail content security for the Domino
server. It is important to note that protection of Domino server alone does not protect your
organization, you must also provide protection on all elements of your computing environment
(such as your user’s workstations).

412 Domino 6 for iSeries Best Practices Guide

9.2.1 Anti-spam features of Lotus Domino 6
A deliberate design goal of Domino 6 was the introduction of features for content security and
spam control to the server. With Domino 6, IBM provided a number of server side tools which
help organizations to deal with spam and give a basic content security option. It is very
important to note that these features alone do not provide adequate protection from computer
viruses. You must also implement a third-party product for antivirus protection.

The anti-spam features of Domino 6 are composed of:

򐂰 SMTP connection controls that stop inbound spam messages from the Internet.
򐂰 Server mail rules that filter messages before they are delivered to the user.
򐂰 Server relay controls which prevent unauthorized use of your Domino server as a mail
relay.

From the perspective of e-mail content security, the first two sets of features are most useful.
However, it is important to note that you must also implement server relay controls in your
organization. This prevents the unauthorized usage of server resources and network
bandwidth for distribution of spam messages to other users on the Internet.

SMTP connection controls

The SMTP connection controls consist of:
򐂰 DNS Blacklist filters enable the Domino server to query an external blacklist site to check if
mail you are receiving is from a reputable source. These filters provide protection from
mail originating from servers that are being exploited or could be exploited by spammers
to send unauthorized e-mails. There are many different blacklists maintained on the
Internet.
򐂰 Intended Recipient Controls which provide verification that the intended recipient of the
inbound mail exists in the Domino Directory before accepting the message.
򐂰 Disabling Routing of Mail to Groups prevents users (inside or outside of your organization)
to send messages to many recipients with one message.
򐂰 Inbound Connection Controls specify how the Domino SMTP server will handle inbound
connection requests. These controls can be used to allow or deny SMTP connections to
the Domino server.
򐂰 Inbound Sender Controls limit SMTP connections to the Domino server based on the
sender or recipient of the e-mail.

All of these SMTP connection controls prevent e-mail messages from being accepted on the
Domino server. Because unauthorized messages never enter your environment, this saves
network bandwidth and server resources.

For more information on the SMTP connection controls and configuration of the features see
Chapter 4, “Domino 6 Server anti-spam features” of the redbook Lotus Domino 6 spam
Survival Guide for IBM Eserver, SG24-6930.

Server mail rules

The Domino 6 e-mail delivery controls are implemented using server mail rules. Server mail
rules provide filtering of the messages that are routed in your Domino environment. The
power of the server mail rules lies in the possibility of using different conditions and factors
against which the messages should be checked. You can configure server mail rules to
prevent questionable or unauthorized messages from reaching your end users or you can
only log messages that could potentially present a content security risk.

Chapter 9. Antivirus protection 413

 Server mail rules can use the message header, the body of the message, or even the form
which a mail message is using to determine whether to act on it. The combination of
conditions and actions is large; this offers you absolute control over which messages are
delivered or logged in your environment. With these rules, you can filter out known spam
senders, messages that contain questionable content, or even prevent your own users from
sending out a message to a large number of recipients.

Tip: One of the most powerful uses of server mail rules is the filtering of messages
containing a large number of recipients or attachments. Often this kind of messages is
questionable for the organization due to the impact on server resources and network
bandwidth. These messages can be moved to a database or held pending in MAIL.BOX for
further analysis.

Each server mail rule consists of two components:

򐂰 The conditions that need to be met
򐂰 The actions you want to take with the message if the conditions are met

The conditions define filters for which e-mail messages will be processed by the Domino
server mail rules. There are three parts to a condition:
1. The message item to examine. This is the particular field you want to specify (for example,
From, Subject, Body, and so on).
2. A logical operator or qualifier. Currently the following comparisons are supported:
– Contains <text> and does not contain <text>
– Is and is not
– Is less than <number> and is greater than <number>
3. The value to check for. This identifies the content to search for in the message item or the
comparison number.

You can have multiple conditions connected with Boolean operators (AND and OR) to form a
logical expression.

The following actions are available when a message matches the conditions:
򐂰 Journal this message: This action copies the message to a journalling database and
then delivers the message.
򐂰 Move to database: This action moves the message to a specified database (for example
quarantine).
򐂰 Don't accept message: The message is not accepted by the Domino server and the
originator receives a rule violation report (for SMTP messages this depends on the
sending server).
򐂰 Don't deliver message: The message is accepted in MAIL.BOX and silently deleted or a
non-delivery report is returned to the sender.
򐂰 Change routing state: The routing state of the message is changed to “held” and the
administrator can manually deal with the messages.

Server mail rules are configured and enabled in the Server configuration document for each
Domino server. In Domino 6, up to 100 server mail rules can be specified. Active server mail
rules are registered as monitors for all MAIL.BOX files used on the server. For more
information on Domino server mail rules and a sample configuration see “Mail file
management” on page 57.

414 Domino 6 for iSeries Best Practices Guide

 Before rolling out mail rules on your production Domino servers, you must plan for the
performance implications that could be imposed on your servers. For more information see
the section on Server based mail rules in Appendix C, “Common configuration problems that
affect Domino performance” on page 589.

9.3 Symantec AntiVirus/Filtering for Domino 3.0 for OS/400

Symantec provides a broad range of content and network security software and appliance
solutions to individuals, enterprises, and service providers. The company products include
client, gateway, and server security solutions for virus protection, firewall, and virtual private
network, vulnerability management, intrusion detection, Internet content, and e-mail filtering,
as well as remote management technologies and security services to enterprises and service
providers.

The Symantec integrated security solutions include:

򐂰 Firewall/VPN to protect data and assets without slowing down performance.
򐂰 Intrusion detection that acts as a "security force" inside the perimeter to spot intruders that
penetrate the outer defenses.
򐂰 Policy compliance management helps to define and enforce policies from a central
location as well as probe for network vulnerabilities and suggest remedies.
򐂰 Virus protection/content filtering offers critical protection from Internet-borne threats for the
desktop through the gateway for individuals all the way up to the largest enterprise.
򐂰 Symantec's enterprise administration tools provide secure, economical, centralized
network management for rolling out new PCs or migrating existing PCs to new operating
systems.
򐂰 Symantec's Client Security product, including Symantec Antivirus Corporate Edition and
Symantec Client Firewall, provide desktop protection, from virus outbreaks or malicious
hacker attacks.

Symantec AntiVirus/Filtering for Domino is a complete, customizable, and scalable antivirus

and filtering solution. It protects your Lotus Domino servers from viruses and destructive
programs and lets you specify the actions to take, and notifications and alerts to issue, when
a threat is detected. Additionally, Symantec AntiVirus/Filtering for Domino lets you filter e-mail
subject lines and message bodies for undesirable content, such as offensive language,
confidential information, and spam e-mail. The criteria that are used to identify threats are
customizable. You can create and save multiple sets of criteria for use by Symantec
AntiVirus/Filtering for Domino. In addition to OS/400, Symantec AntiVirus/Filtering is also
supported on AIX, Windows 2000, Linux (Red Hat and SuSE), and Solaris.

Symantec AntiVirus/Filtering for Domino secures your Lotus Domino environment against
virus attacks and unwanted content by protecting databases on Lotus Domino servers and
monitoring e-mail that is routed through the servers. Symantec AntiVirus/Filtering for Domino
operations are transparent to the users.

This section gives you an introduction into the functions and handling of the product. If you
need more information, please contact Symantec or refer to the Symantec product
documentation, for example the Symantec AntiVirus™/Filtering for Domino™ for OS/400
Implementation Guide.

Chapter 9. Antivirus protection 415

9.3.1 Functions
As mentioned before, Symantec AntiVirus/Filtering offers protection against virus attacks and
unwanted content. This section gives you some details about these two functions.

Protection against virus attacks

You can configure Symantec AntiVirus/Filtering for Domino to do any of these operations:
򐂰 Eliminate viruses automatically on detection.
򐂰 Eliminate or filter e-mail that contains unwanted content.
򐂰 Quarantine infected documents and e-mail for administrator review.
򐂰 Delete infected items.
򐂰 Repair infected attachments when possible.

Symantec AntiVirus/Filtering for Domino runs as a Domino server task. Every time that you
start the server, Symantec AntiVirus/Filtering for Domino protection begins. When viruses or
content violations are detected, you can have Symantec AntiVirus/Filtering for Domino send
e-mail notifications to specified administrators, document or e-mail authors, and to the
intended e-mail recipients.

Virus scanning of documents in Domino databases can be done in real-time (prior to be

routed), scheduled or on-demand. All of Symantec AntiVirus/Filtering database scan
operations support incremental scanning, which can reduce the time needed for the scan
operation. Symantec AntiVirus/Filtering also provides the concept of a scan window. This is
the time slot allocated for scheduled scan operations.

Configuration, administration, and reporting of Symantec AntiVirus/Filtering for Domino is

performed via Domino databases and can be accomplished using any Lotus Notes client. The
product provides full support for multi-server environments with centralized configuration and
monitoring.

Virus definition updates are retrieved from Symantec at predetermined times or regular
intervals, or can be downloaded from an internal, centralized server. Symantec also provides
regular updates to the antivirus scanning and repair engine. The engine updates are
automatically applied as new virus definitions are downloaded — without stopping the
real-time scanning or re-starting servers.

The performance of the product is optimized by multi-threading, which processes multiple

requests and scans simultaneously, to maximize scan speed and available bandwidth.
Performance optimization is performed automatically, based on the number of processors and
memory available.

Protection against unwanted content

In addition to Real Time, Scheduled, and Scan Now scans, the integration of content filtering
into Symantec AntiVirus/Filtering for Domino enhances protection by blocking e-mail and
database writes based on content, and filtering e-mail for spam messages in real time.

Using content filtering features, you can do the following operations:

򐂰 Search the subject lines or contents of e-mail messages for offensive language,
confidential information, and content with potential legal consequences.
򐂰 Identify spam e-mail to delete, based on document attributes such as attachment size or
extension, document sender, and Domino or Internet domain.
򐂰 Search for messages with particular subject lines.

416 Domino 6 for iSeries Best Practices Guide

 To search for unwanted content, you create Content Filtering Rules. When the content or
some attribute of a document violates a rule, Symantec AntiVirus/Filtering for Domino takes
action according to the settings that you supplied for that rule.

You can set up as many content filters (rules) as needed. Each rule specifies the e-mail
category to search (subject line, sender, or attachment size, for example), and defines the
condition that will trigger a content violation.

For example, you could set up a rule to filter e-mail with attachments that exceed 3 MB in size.
Symantec AntiVirus/Filtering for Domino would then catch any e-mail messages with
attachments that exceed 3 MB and, like other scans, would process the e-mail according to
your configuration settings. You can enable or disable content filtering at any time.

9.3.2 Prerequisites
The software requirements for Symantec AntiVirus/Filtering 3.0 for Domino on iSeries differ
for Domino R5.x and Domino 6. Table 9-1 lists these prerequisites.

Table 9-1 Software requirements for Symantec AntiVirus/Filtering 3.0 for Domino on iSeries
Domino R5.x Domino6

OS/400 V4R4 or later OS/400 V5R1 or later

Domino Server R5 version 5.0.8 or later Domino Server 6 version 6.0

AS/400 Developer Kit for Java, 5769-JV1 AS/400 Developer Kit for Java, 5769-JV1

OS/400 QShell Interpreter (OS/400 Option 30) OS/400 QShell Interpreter (OS/400 Option 30)

9.3.3 Installing Symantec AntiVirus/Filtering for Domino

If you have multiple Lotus Domino partitions on the same server, separate Symantec
AntiVirus/Filtering for Domino databases are required for each partition. Setup detects and
lets you specify on which partitions to install. Older versions of Norton AntiVirus for Lotus
Notes must be uninstalled before installing Symantec AntiVirus/Filtering for Domino.

Choose one of the following methods to install Symantec AntiVirus/Filtering for Domino:
򐂰 Install from a CD (recommended)
򐂰 Install from a save file

To install the product from a CD:

1. Sign on with the QSECOFR user profile.
2. Shut down the Lotus Domino server(s).
3. Place the CD into the primary OS/400 CD-ROM drive, then type the following command:
LODRUN *opt
You will be asked on which Domino servers to install Symantec AntiVirus/Filtering for
Domino.
4. After the Symantec AntiVirus/Filtering for Domino install completes, restart the Lotus
Domino server(s).
5. When the Lotus Domino server is restarted, the Symantec AntiVirus/Filtering for Domino
databases are created from templates that are placed in your default Domino data
directory.

Chapter 9. Antivirus protection 417

9.3.4 Implementation
Symantec AntiVirus/Filtering for Domino is completely integrated into the Lotus Domino
environment. It is comprised of the following Lotus databases:
򐂰 Settings (SAV.NSF): Contains the protection and notification settings for your Lotus
Domino servers. So you configure protection and notification using this database.
򐂰 Log (SAVLOG.NSF): Contains server messages, product version information, reports of
virus incidents or content violations, scan summaries, and predefined statistical reports.
򐂰 Quarantine (SAVQUAR.NSF): Contains quarantined and backup documents.
򐂰 Help (SAVHELP.NSF): Contains online help for Symantec AntiVirus/Filtering for Domino.
򐂰 Definitions (SAVDEFS.NSF): Needed for replication of virus definitions. Must be created
manually.

All scanning is configured and initiated from the Settings database (SAV.NSF). All reports and
virus dispositions are handled through the Log database (sAVLOG.NSF). Information about
the product and how to use it is provided in the Help database (sAVHELP.NSF). In addition, if
you plan to replicate updated virus definitions, you must create a Definitions database
(SAVDEFS.NSF) in which the updated virus definitions are stored.

9.3.5 Configuring Symantec AntiVirus/Filtering for Domino

After you have installed the product, you need to configure your virus protection and content
filtering settings. To access Symantec AntiVirus/Filtering for Domino configuration, open your
Lotus Notes client and select Database -> Open from the File menu. Select the server, open
the sav directory, and select the Symantec AV/F Settings database (SAV.NSF).

In addition, you can view and manage some Symantec AntiVirus/Filtering for Domino
operations directly from the Domino server console window.

Setting Global AntiVirus Options

Global AntiVirus Options let you specify various settings that apply to all scans (such as the
databases and file extensions to exclude from scans, the directories for temporary files,
signed document handling, logging, notifications, etc.). When you specify settings in the
Global AntiVirus Options, the settings apply to Real Time scanning, all Scan Now scans, and
all Scheduled Scans. Changes made, for example, while you are setting up Global AntiVirus
Options for an on-demand (Scan Now) scan, also apply to Real Time scanning and
Scheduled Scans

Global Virus Notification settings

An important Global AntiVirus Option is the notification of users about a virus incident. These
users are:
򐂰 Administrators: A notification is sent to administrators to advise them of infected
workstations. You can define a custom text, report the action taken by Symantec
AntiVirus/Filtering for Domino, and include violation information from the log.
򐂰 Document Author: A notification is sent to the author of the infected document. If your
policy is to quarantine infected documents, let authors know whom to contact to release
the document. If your policy is to delete infected attachments, advise authors to scan the
source before sending the attachment again. The notification can include a custom text,
information about the action taken by Symantec AntiVirus/Filtering for Domino, and
violation information from the log.

418 Domino 6 for iSeries Best Practices Guide

򐂰 Document Recipients: A notification is sent to the intended recipients of the infected
document. If your policy is to quarantine infected documents, let users know whom to
contact to release the document. If your policy is to delete infected attachments, advise
them to contact the document author to resend an uninfected version. You can include the
same type of information as in Document Author notifications.

Configuring scans
Symantec AntiVirus/Filtering for Domino lets you set up scans to run immediately or on a
schedule, or to monitor in real time. You can choose from the following three types of scans,
depending on the type of protection that the server requires:
򐂰 Real Time: Real Time scanning monitors database writes and e-mail as it is routed
through the server in real time. Real Time scanning is your best insurance to detect and
eliminate viruses before they can spread.
򐂰 Scan Now: Scan Now scans are on-demand scans that you can invoke at any time. You
can include all databases in your default Data directory or select specific databases or
directories to scan. The scan begins when you click Start the Scan. You can also restrict
the scan to documents that have been modified before a specified date.
򐂰 Scheduled Scans: Scheduled Scans run automatically and without administrator
intervention. Use Scheduled Scans to make sure that your databases remain virus-free.
You can also restrict the scan to documents that have been modified since the start time
of the last Scheduled Scan.

Defining and modifying Content Filtering Rules

To create a rule, you specify the basics and then set up as many conditional expressions as
required to categorize the objectionable content that you are trying to block. You can then
specify how to handle the document (or attachment) that contains objectionable content.

After creating a rule, you can enable or disable it. You can also enable or disable specific
Content Filtering Rules in the listing of rules. So when you are ready to process a rule, make
sure that it is enabled individually. Then enable Rules processing.

The Content Filtering Options apply to all content filtering scanning. They include processing
and content filtering violation notifications.

How content filtering works

e-mail or database writes that match an expression in a Content Rule may violate the rule,
depending on whether the rule contains AND expressions or OR expressions. If the rule
contains AND expressions, then all expressions must evaluate to true for Symantec
AntiVirus/Filtering for Domino to trigger a content violation for the entire rule. However, if the
rule contains OR expressions, only one expression must evaluate to true for Symantec
AntiVirus/Filtering for Domino to trigger a content violation for the rule. You can change,
delete, enable, or disable any rules that you create.

Symantec AntiVirus/Filtering for Domino handles e-mail with content violations according to
the action that you configure for the rule. You can choose one of the following actions (one
action per rule):
򐂰 Log only: Logs the content violation in the Symantec AntiVirus/Filtering for Domino Log
database, but does nothing else.
򐂰 Delete the offending attachments: Deletes only the attachment or attachments that
have violated (or matched) the rule. The condition or conditions of the rule itself must
specify the attachment name, size, extension, and so forth, or this action won't work.

Chapter 9. Antivirus protection 419

 򐂰 Delete all attachments: Deletes every attachment that belongs to the e-mail, regardless
of which attachment or attachments contain the content violation.
򐂰 Quarantine the document: Moves the e-mail to the Log/Quarantine database and lists it
as a Quarantined item.

Content Violation Notifications settings

Symantec AntiVirus/Filtering for Domino allows you to notify different users about the content
violation. These users are:
򐂰 Administrators: When selecting this option, a notification is sent to the administrators to
advise them that a content violation has occurred.
򐂰 Document Author: A notification is sent to the author of the infected document. If your
policy is to quarantine infected documents, let authors know whom to contact to release
the document. If your policy is to delete infected attachments, advise them to scan the
source before sending the attachment again.
򐂰 Document Recipients: A notification is sent to the intended recipients of the infected
document. If your policy is to quarantine infected documents, let users know whom to
contact to release the document. If your policy is to delete infected attachments, advise
them to contact the document author to resend an uninfected version.

9.3.6 Log database

The Log database stores server messages, reports of virus incidents or content filtering
violations, scan summaries, and predefined statistical reports. On the Lotus Notes client, you
can view these types of data in several views. Symantec AntiVirus/Filtering for Domino lets
you view virus and content filtering data separately.

Server messages and incidents are reported with the following severities:
򐂰 Information (blue): No violation occurred with the event.
򐂰 Warning (green): A violation occurred with the event, but was removed.
򐂰 Critical (red): A violation occurred with the event, and remains.

To prevent the Log database from becoming too large, a purge agent runs every night at
1:00 AM when enabled. By default, virus incidents are purged after 365 days. Other Log
entries are purged after 30 days.

9.3.7 Quarantine database

If you configured it to do so, Symantec AntiVirus/Filtering for Domino can isolate scanned
documents that it has found to be suspicious in the Quarantine database. When an e-mail is
quarantined, Symantec AntiVirus/Filtering for Domino places the entire e-mail message and
any attachments in the Quarantine, regardless of which part of the document is infected or
has offending content. It does not forward any part of the e-mail. Symantec AntiVirus/Filtering
for Domino can also quarantine infected Lotus Domino database documents.

The Quarantine stores two types of documents:

򐂰 Quarantined documents
򐂰 Backup documents

Symantec AntiVirus/Filtering for Domino displays Quarantined documents separately from

Backup documents. All views show when the document was quarantined, which database
was affected, who authored the document, and which virus detection or content violation rule
was involved. The views also show whether the document has been released, that is,
restored to its original database to complete processing as originally planned.

420 Domino 6 for iSeries Best Practices Guide

Quarantined documents
Quarantined documents are infected documents that have not been repaired or documents
with content violations. While suspicious documents are in Quarantine, administrators can
manage them by reviewing and taking action on them as permitted. Actions include deleting
the document or attachment, saving the attachment or adding a new one, and releasing the
document. Quarantined infected documents must be repaired (or their infected attachments
deleted) before they can be released. For a document with a content violation, you can edit
the document in the Quarantine to remove the violation and then release it.

To prevent the Quarantine database from becoming too large, a purge agent runs every night
at 1:00 AM when enabled. By default, Symantec AntiVirus/Filtering for Domino purges entries
after 30 days. However, you can routinely purge quarantined documents from the Quarantine
and Backup document views.

How documents get quarantined

Symantec AntiVirus/Filtering for Domino quarantines documents only when the following
occurs:
򐂰 Content filtering is configured to quarantine or copy documents when a content violation
has occurred in an e-mail message or attachment (as specified by the Content Filtering
Rule).
򐂰 Real Time scanning, Scan Now scans, or Scheduled Scans are configured to quarantine
documents after a virus is detected.
򐂰 Real Time scanning, Scan Now scans, or Scheduled Scans are configured to repair
infected attachments, but quarantine any documents that have attachments that cannot
be repaired.

Actions to take on quarantined documents

Before you can release an infected item from the Quarantine, you must ensure that it no
longer contains infected attachments or attachments that violate Content Filtering Rules. You
can save, delete, or replace attachments of quarantined items.

You can take actions on an infected document, attachment, or content violation in any of the
following ways:
򐂰 Save Attachments: Saves a copy of the attachment or attachments to a location that you
choose. Saving quarantined attachments provides the same safety measure as placing
them in the Backup Documents view.
򐂰 Add Attachment: Adds the file that you select to the quarantined document. Before
releasing a document from the Quarantine, you can add a newly repaired compressed file,
replace an infected file with a known good copy, or add a procedural file with instructions
to scan a workstation.
򐂰 Delete Attachments: Removes the attachments and prompts you before deleting each
one. When you delete attachments, the quarantined item remains in the Quarantine view
without the attachments.
򐂰 Release: Releases the document from the Quarantine and restores it to its original
database. The quarantined item remains in the Quarantine until Symantec
AntiVirus/Filtering for Domino purges it or you delete it.

Backup documents
As a data safety precaution, administrators can configure Symantec AntiVirus/Filtering for
Domino to store a backup copy of any document that contains content violations or infected
attachments. That way a copy is available if anything happens to the original.

Chapter 9. Antivirus protection 421

 Managing Backup Documents
You can configure Symantec AntiVirus/Filtering for Domino to make a backup copy of infected
documents before they are repaired or deleted in the Quarantine database. The Backup
Documents view shows when the item was backed up, which database was involved, who the
author was, and the name of the infected document, e-mail, or e-mail attachment. You can
manage the Backup Documents view in much the same way as the Quarantine Document
list, except that you cannot add or delete attachments, or release documents to their original
databases.

9.3.8 LiveUpdate
Symantec AntiVirus/Filtering for Domino relies on up-to-date information to detect and
eliminate viruses. One of the most common reasons you may have a virus problem is that you
have not updated your protection files since you installed the product. Symantec regularly
supplies updated virus definitions files, which contain information about all newly discovered
viruses.

With LiveUpdate, Symantec AntiVirus/Filtering for Domino connects automatically to

Symantec sites and determines if your virus definitions need updating. If so, it downloads the
proper files and installs them in the proper location.

If you do not want to permit direct access to the Internet from your Domino servers or you are
running proxy servers, you can set up an internal LiveUpdate server with LiveUpdate
Administrator and configure Symantec AntiVirus/Filtering for Domino to access the internal
LiveUpdate server instead.

9.4 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400
Trend Micro is a global provider of comprehensive antivirus and Internet content security. Its
products and services deliver a framework for coordinated enterprise protection throughout
the virus outbreak life cycle. Trend Micro specializes in high-performance virus protection and
content security products and services, with advanced centralized management capabilities
that are scalable for any enterprise or desktop. Trend Micro's product and services categories
are designed to address all major areas of the enterprise including:
򐂰 Desktop and client: Virus protection for the enterprise, end-user or home user.
򐂰 e-mail and groupware: Virus protection for Lotus Notes or Microsoft Exchange.
򐂰 Internet gateway: Stops viruses and spam at the SMTP, HTTP, and FTP server gateway.
򐂰 File server and storage: Virus protection for multiple servers and domains.
򐂰 Management: Centralized management of the antivirus strategy across the enterprise.

ScanMail for Lotus Notes offers comprehensive virus protection and content security for the
Lotus Domino environment. It scans viruses hidden in databases and e-mail attachments,
and it also protects collaboration tools such as Lotus Instant Messaging and Lotus Web
Conferencing (Sametime) and Lotus Team Workplace (QuickPlace). ScanMail is designed to
operate as a native Domino server application and thus provides administrators with a
familiar, intuitive interface. In addition to OS/400, it supports AIX, S/390®, Microsoft
Windows 2000, Sun Solaris, Red Hat and SuSE Linux.

ScanMail for Lotus Notes detects and removes viruses before infections can spread to the
desktop. It scans and cleans attachments and document content on all entry points, including:
򐂰 e-mail attachments in real-time at the router.
򐂰 Databases and modified data during replication.

422 Domino 6 for iSeries Best Practices Guide

򐂰 Attachments by monitoring database events, scanning immediately before the document
is closed.
򐂰 Existing attachments in mailboxes and Domino databases to root out old infections.

Administrators can specify which databases are to be scanned, and users are prevented from
overwriting a clean document with an infected version. On-demand database scanning
cleans existing infections.

ScanMail helps administrators enforce company e-mail policies, increase overall server
efficiency and minimize virus outbreaks by blocking certain file types and e-mail.
Administrators can create rules to block, delay, and prioritize e-mail. A corporate policy can
be implemented to deal with virus incidents in several ways: alert the administrator, isolate
the infected file for later cleaning or other action, or delete the infected file.

The Trend Micro scanning engine uses both, rule-based and pattern recognition technologies
and includes MacroTrap technology, which detects and removes macro viruses. Frequent
virus pattern updates are accomplished through a Web-based download. This update
mechanism is used also for the scan engine download and update. The automatic update of
the pattern file and scan engine does not require to shutdown ScanMail.

The configuration interface for ScanMail is fully integrated with the Domino server and
supports remote management from any Lotus Notes workstation, Web browser, or Domino
R6 Administration Client.

ScanMail maintains a comprehensive activity log, detailing for each infected file, the origin,
name and destination of the file, date the file was received, identity of any virus found, and the
action taken. Java-based charts help administrators identify virus infections throughout the
enterprise environment. Reports from different servers can be consolidated through Notes
database replication.

By using a multi-threaded scan engine and memory scanning, ScanMail is able to maximize
efficiency and minimize impact on Lotus Notes servers. Administrators can also identify
servers that don’t require scanning, eliminating redundant scanning.

A trial version of Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 can be obtained from
the Trend Micro Web site:
http://www.trendmicro.com/en/products/email/smln/evaluate/trial.htm

This trial version is the full functional product and can be used for 30 days from the date of
installation. The only limitation of the trial version is that no automatic updates of the pattern
file and scan engine are possible. If you wish to continue using the product after the 30 days,
you can upgrade the trial version to the full version without reinstallation.

The basic installation and configuration steps when evaluating the product in your
environment are:
򐂰 Installation of Trend Micro ScanMail for Lotus Notes 2.6 for OS/400
򐂰 Basic Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 configuration
򐂰 Scanning configuration

You can use the information in this chapter for the basic setup of the product in your
environment, for example when evaluating the product.

Detailed documentation for Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 is available
on the Trend Micro Web site:
http://www.trendmicro.com/download/product.asp?productid=10&show=doc

Chapter 9. Antivirus protection 423

 Important: We have been using a beta version of Trend Micro ScanMail for Lotus Notes
2.6 for OS/400 when writing this redbook. There is the possibility that slight differences
between the final code and the beta code exist, for example, database designs could
change or options could have a different text associated with them. Please keep this in
mind if you encounter any differences.

The following topics are covered in this section:

򐂰 “Installing Trend Micro ScanMail for Lotus Notes 2.6 for OS/400” on page 424
򐂰 “Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 components” on page 427
򐂰 “ScanMail basic configuration” on page 429
򐂰 “Configuring antivirus protection” on page 434
򐂰 “Best practices for using ScanMail in your environment” on page 440

9.4.1 Installing Trend Micro ScanMail for Lotus Notes 2.6 for OS/400
This section describes the installation of Trend Micro ScanMail for Lotus Notes 2.6 for
OS/400 on your system and then adding ScanMail to the Domino server(s).

Hardware and software prerequisites

To use ScanMail for Lotus Notes on an iSeries system, you need the following hardware and
software:
򐂰 Lotus Domino R 5.x and above (including Domino 6)
򐂰 OS/400 Version 4, Release 5 or later
򐂰 64MB RAM
򐂰 350MB disk space available for program files
򐂰 100MB disk space available for swap files
򐂰 Internet access (for virus pattern file and scan engine downloads)

The licensed program identifier for Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 is
1TSMN99.

Note: Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 also supports the
multiversioning capable Domino releases 6.0.3 and 6.5.

Installing Trend Micro ScanMail for Lotus Notes 2.6 for OS/400
This section provides information only for the installation of Trend Micro ScanMail for Lotus
Notes 2.6 for OS/400 product but no information for the Trend Micro Control Manager Agent.
You can find more information about that product and installation instructions in the Trend
Micro documentation.

Installation of Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 is performed in two steps:
򐂰 Installing Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 on the iSeries
򐂰 Adding ScanMail to the Domino server

Installation and configuration of Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 must
be performed with the QSECOFR user ID or using a user ID with comparable security
authorization.

The downloaded installation package consists of the following files:

򐂰 The save file, smln.savf, which contains Scan Mail and eManager.

424 Domino 6 for iSeries Best Practices Guide

򐂰 The save file, cmagent.savf, which contains the Control Manager Agent. (Note that we are
not providing any installation or configuration information for the Trend Micro Control
Manager Agent in this redbook.)
򐂰 In addition to these save files, the installation package includes the readme.txt file, which
contains installation instructions and the latest information about the product.

To install Trend Micro ScanMail for Lotus Notes 2.6 for OS/400, you first have to transfer the
save file to the target iSeries system. You can use FTP for this file transfer:
1. On the iSeries, create a save file called SMLN in library QGPL (or any other library) by
entering the following command:
CRTSAVF FILE(QGPL/SMLN)
2. Transfer the ScanMail installation file (smln.savf) from your PC to the QGPL library using
FTP in binary mode. Figure 9-1 shows the Windows Command Prompt FTP to transfer the
save file to the iSeries (the commands you need to enter are highlighted).

C:\smlninst>ftp
ftp> open as25
Connected to as25.
220-QTCP at RCHASM25.
220 Connection will close if idle more than 5 minutes.
User (as25:(none)): QSECOFR
331 Enter password.
Password:
230 QSECOFR logged on.
ftp> binary
200 Representation type is binary IMAGE.
ftp> put smln.savf qgpl/smln (replace
200 PORT subcommand request successful.
150 Sending file to member SMLN in file SMLN in library QGPL.
250 File transfer completed successfully.
ftp: 319297440 bytes sent in 62.01Seconds 5149.21Kbytes/sec.
ftp>

Figure 9-1 Sample FTP commands to transfer ScanMail installation file to the iSeries

3. Use the Restore Licensed Program (RSTLICPGM) command to install Trend Micro
ScanMail for Lotus Notes 2.6 for OS/400 after the FTP transfer has finished:
RSTLICPGM LICPGM(1TSMN99) DEV(*SAVF) SAVF(QGPL/SMLN)
4. To check if the installation of ScanMail was successful, use the Display Software
Resources (DSPSFWRSC) command. The OS/400 licensed product resource ID to look
for is 1TSMN99.

Adding ScanMail to the Domino server

Before you can start using ScanMail you must add the product to the Domino server. You can
add ScanMail to a single Domino server or to Domino partitions.

This configuration procedure performs the following operations:

򐂰 Creates the ScanMail program files in the Domino library.
򐂰 Creates the temporary directory or directories for ScanMail operations.
򐂰 Copies templates and other ScanMail files to the Domino data directory or directories.
򐂰 Creates and signs new ScanMail databases.

Chapter 9. Antivirus protection 425

 The procedure to set up Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 is as follows:
1. End all Domino servers that ScanMail is being installed on. Use the End Domino Server
(ENDDOMSVR) command. The command to stop the server called DOMAV:
ENDDOMSVR DOMAV
2. Before proceeding with the next step, you must check if the Domino server has indeed
ended. Use the Work with Domino Servers (WRKDOMSVR) to display the status of your
Domino servers.
3. To start the setup procedure for ScanMail, use the ScanMail Configuration (CFGSM)
command and press F4.

Important: If you do not press F4 but start the CFGSM command directly by pressing
Enter, Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 will be configured using the
default parameters and in trial mode for all Domino partitions on your system.

4. You must enter the following information about the Trend Micro ScanMail for Lotus Notes
2.6 for OS/400 environment in the configuration screen (see Figure 9-2):
– Server name is the name of the Domino server for which you are configuring ScanMail.
You must use the common name of your Domino server, for example DOMAV. You
can enter only one server name.
If you want to configure Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 for all
Domino partitions on your system, you can use the value *ALL for the Server name
parameter.
– Temporary directory specifies the location of the temporary directory or directories for
ScanMail tasks. These directories are used to detach files from e-mail messages and
Notes documents for on-disk scanning. The default location for the ScanMail
temporary directory is the SMLN\SMTEMP subdirectory in the Domino server’s data
directory. For more information on the temporary directories refer to “ScanMail
temporary directories” on page 428.
– ScanMail serial number specifies the license key for the product which enables the full
version.
– User profile specifies the user ID under which the Lotus Domino server runs, usually
QNOTES.

426 Domino 6 for iSeries Best Practices Guide

 ScanMail Configuration (CFGSM)

Type choices, press Enter.

Server name . . . . . . . . . . 'DOMAV'

Temporary directory . . . . . . *SMLN

ScanMail serial number . . . . . XXXX-9999-9999-9999-9999

User Profile . . . . . . . . . . 'QNOTES'

Bottom
F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display
F24=More keys

Figure 9-2 The ScanMail configuration command CFGSM

5. The output shown in Figure 9-3 is displayed when running the CFGSM command. It
informs you about the progress of the configuration. Once the configuration program
completed the setup, you receive the message “Press Enter to continue”.
This completes the configuration of ScanMail on the Domino server.

Restart Analysis (0 MB): 100%

08/29/2003 14:06:18 /LOTUS/DATA/DOMAV/
Signing smconf.ntf...
Creating smconf.nsf...
Signing smency.ntf...
Creating smency.nsf...
Signing smvlog.ntf...
Creating smvlog.nsf...
Signing smquar.ntf...
Creating smquar.nsf...

===>

F3=Exit F4=End of File F6=Print F9=Retrieve F17=Top

F18=Bottom F19=Left F20=Right F21=User Window

Figure 9-3 Output of running the CFGSM command

9.4.2 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 components
As mentioned earlier, the procedure of adding ScanMail to the Domino server
installs/updates several components, such as adding program files to the Domino library,
creating temporary directories for ScanMail operations, creating ScanMail Domino
databases, and adding NOTES.INI variables. This section describes these ScanMail
components in detail.

Chapter 9. Antivirus protection 427

 ScanMail program files
Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 uses program files to perform
operations on the Domino server. Most of these programs are Domino server tasks and are
stored in the Domino executable directory (\QIBM\UserData\LOTUS\NOTES). Table 9-2 lists
these program files.

Table 9-2 ScanMail programs

Program name Description

dbscan.pgm For manual database scanning. Scans the databases you specify on demand.

repscan.pgm Real-time database scanning. Scans documents in all Domino databases

except the MAIL.BOX database(s).

pupdate.pgm This update program downloads new pattern files and scan engines from the
Trend Micro Web site.

pscan.pgm Scheduled database scanning. Runs according to your configuration. You can
select the time the scan runs and which databases are scanned.

tmmscan.pgm Real-time e-mail scanning. Scans every e-mail message sent to the
MAIL.BOX database(s).

libsmlnred.srvpgm libsmlnred sets flags on new e-mail messages or updated documents to

indicate they have not been scanned.

vsapi.srvpgm vsapi.srvpgm is the ScanMail scan engine.

ScanMail temporary directories

Each type of ScanMail scanning operation uses its own temporary directories. Those
temporary directories are used to detach files from e-mail messages and Notes documents
for on-disk scanning. With Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 you can also
configure memory-based scanning. In this case, the temporary directories are used to scan
files that are to large to fit into the allocated memory.

By default, the temporary directories location is in the SMLN\SMTEMP subdirectory under the
Domino data directory. For example:
\lotus\data\domav\smln\smtemp\...

All temporary directories and the processes that are using them are listed in Table 9-3.

Table 9-3 ScanMail temporary directories

Temporary directory ScanMail task

\smln\mailtemp\ Real-time e-mail scanning (tmmscan)

\smln\reptemp\ Real-time database scanning (repscan)

\smln\dbtemp\ Manual database scanning (dbscan)

\smln\ptemp\ Scheduled database scanning (pscan)

Important: Every Domino server needs its own temporary directories, they cannot be
shared.

428 Domino 6 for iSeries Best Practices Guide

 ScanMail Domino databases
ScanMail uses Domino databases for configuration, logging and integration with the Domino
environment. The databases used by Trend Micro ScanMail for Lotus Notes 2.6 for OS/400
are listed in Table 9-4.

Table 9-4 ScanMail databases

Database name Database description

SMCONF.NSF Contains the main configuration information.

SMVLOG.NSF Stores and manages all ScanMail logging events.
SMQUAR.NSF Contains the documents and attachments in the Quarantine.
SMHELP.NSF Contains the Help database.
SMENCY.NSF Stores the virus pattern file and the scan engine.
SMMSG.NSF Stores all messages that ScanMail produces.
SMADM5.NSF Copies the ScanMail design into the Domino server administration
database.
SMTIME.NSF Moves scheduled e-mail messages to and from MAIL.BOX and stores
them in the interim.
SMFTYPES.NSF Lists recognized file types.
SMBACKUP.NSF This is a backup of SMCONF.NSF when updating from
ScanMail 2.5x to 2.6.

ScanMail NOTES.INI entries

The ScanMail setup program also adds some entries to the NOTES.INI file for integration and
configuration purposes. The changes made to NOTES.INI by CFGSM are:
򐂰 The tmmscan (real-time mail scanner) and repscan (real-time database and replication
scanner) tasks are added at the end of the ServerTasks line, for example:
ServerTasks=Update,Replica,Router,AMgr,AdminP,CalConn,Sched,HTTP,IMAP,LDAP,POP3,
TmmScan,RepScan
򐂰 smlnred is added to the ExtMgr_Addins line as follows:
ExtMgr_Addins=...,smlnred
򐂰 The following variables are added:
– SMStopMail=0
This variable controls the flow of mail when ScanMail is not running.
– SMOutputlevel=2
This variable controls the output level to the Domino console and log.

9.4.3 ScanMail basic configuration

Before you can start configuring the mail and database scanning options you must perform
some basic configuration steps. These steps customize ScanMail for your environment. The
basic configuration steps for Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 include:
1. Configure security for the ScanMail databases.
2. Access the ScanMail user interface.

Chapter 9. Antivirus protection 429

 3. Configure the automatic update of the virus pattern file and scan engine (applicable only
to registered versions).

Security of ScanMail databases

The default ACL configuration for ScanMail databases is Manager. You should change the
ACL for all databases to be more restrictive before using the product. The administrator of the
ScanMail system must have at least Editor access rights and Delete document permission.

You can use the Domino Administrator Manage ACL tool to change the ACL of the ScanMail
databases:
1. From the Domino Administrator Server pane, select the server that stores the databases.
2. Click the Files tab and select the ScanMail databases from the Domino data directory (the
databases are listed in Table 9-4 on page 429).
3. Click Tools -> Database -> Manage ACL.
4. Define access to the ScanMail databases as needed for your environment. An example of
an ACL that suits most environments is shown in Table 9-5.

Table 9-5 Access Control List for ScanMail databases

User Access level

-Default- No Access

Anonymous No Access

ScanMail administrators (usually a group) Manager

Domino Server Manager

LocalDomainServers (if you are using replication) Manager

Optionally you can set visibility and SSL options for all ScanMail databases in the ScanMail
configuration. Visibility allows to hide or display ScanMail databases in the Open Database
dialog box of the Lotus Notes client. The SSL option specifies whether SSL is required for
Web access to this database. For more information see the Trend Micro ScanMail for Lotus
Notes 2.6 for OS/400 documentation.

The ScanMail user interface

All ScanMail configuration, monitoring and reporting can be performed from the Domino
Administrator or using a Web client. From either interface open the ScanMail for Lotus Notes
(SMCONF.NSF) database located in the Domino data directory. Any user with proper ACL
rights can use this database. The ScanMail user interface is shown in Figure 9-4. As you can
see, you can access the ScanMail configuration, the log and quarantine databases, as well as
registration and help.

In order to use a Web client to access the SMCONF.NSF database, the HTTP task must be
started on the Domino server. Access the database by specifying the following URL:
http://yourdominoservername/smconf.nsf

430 Domino 6 for iSeries Best Practices Guide

Figure 9-4 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 user interface

In addition to a Notes or Web client, you can also use the Trend Micro Control Manager to
configure and manage ScanMail.

Automatic updates and registration

The pattern file contains virus signatures used to detect a virus in attachments and
documents. The scan engine compares a file’s binary structure with the virus pattern file,
detects suspicious virus-like behavior, and cleans viruses. Updates of the pattern file and
scan engine are available only to users who have licensed the product.

Tip: When using the evaluation version of Trend Micro ScanMail for Lotus Notes 2.6 for
OS/400, you can manually update the pattern file. To do so, first download the pattern file
from the Trend Micro Web site to your PC. The pattern file name for the iSeries does not
include a "$" sign in the name, so you have to rename the file from lpt$vpn.xxx to
lptvpn.xxx (xxx is the pattern file version). Then FTP this file to the Domino data directory
on the iSeries and change the owner of the file to QNOTES. The ScanMail tasks will
automatically load the new pattern file.

To enable the automatic download of pattern files and scan engines for a licensed version of
Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 you have to register the product first.

Chapter 9. Antivirus protection 431

 These are the steps to configure automatic updates of the pattern file and scan engine:
򐂰 Register the ScanMail product with Trend Micro.
򐂰 Customize the update options - proxy settings.
򐂰 Schedule automatic updates from the Trend Micro Web site using the pupdate program.

To register the product you have to enter your product’s serial number(s) in the Registration
form in the ScanMail configuration database (SMCONF.NSF). You can access this form by
clicking the Registration option in the navigation bar (see Figure 9-4 on page 431). A sample
registration form is provided in Figure 9-5.

Figure 9-5 The Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 registration form

The options for the pupdate task are specified in the Update Setting form. You can access this
form by selecting Update -> Update Setting from the SMCONF.NSF navigation bar.

Here you can specify what will be downloaded and the source for the updates. The default
settings are appropriate for most configurations. An example of the configuration document is
shown in Figure 9-6.

Important: If you are accessing the Internet through a proxy server, you must configure
this in the Proxy Server Settings section of the Update Setting configuration document.

432 Domino 6 for iSeries Best Practices Guide

Figure 9-6 Update Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 settings

As mentioned before, updates of the virus pattern file and the scan engine are performed by
running the pupdate Domino server task. You can schedule regular updates using a Server
Program document. See Figure 9-7 for an example. For additional information on Server
Program documents, please refer to the Lotus Domino 6 Administrator Help.

Chapter 9. Antivirus protection 433

 Figure 9-7 Server Program document runs hourly updates - virus pattern file and scan engine

To check which version of the virus pattern file and the scan engine are running on the server,
do the following steps:
1. In the ScanMail main menu, click General Administration followed by Program Status.
2. Click the arrow next to the Domino server name or double-click the server name. The
program version, the scan engine version, and the virus pattern version are displayed.

For more information on this topic see the Trend Micro ScanMail for Lotus Notes 2.6 for
OS/400 documentation.

9.4.4 Configuring antivirus protection

Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 performs four types of scanning:
򐂰 Real-time e-mail scanning (tmmscan) continuously scans all e-mail messages that are
sent to MAIL.BOX files on the Domino server.
򐂰 Real-time database scanning (repscan) scans modified documents in all specified Domino
databases, except the MAIL.BOX files.
򐂰 Manual database scanning (dbscan) performs a one-time scan on one or more databases
specified in the command line.
򐂰 Scheduled database scanning (pscan) runs a scan according to a specified time
schedule.
After installing Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 all scanning is disabled
except for Real-time e-mail scanning which is enabled by default. So the first step is to
configure and enable additional scanning options you wish to use in your environment. You
can configure nearly the same options for each type of scanning. However, some options are
available only for certain types of scanning.

434 Domino 6 for iSeries Best Practices Guide

 Attention: This quickstart only shows how to configure real-time mail scanning - this is just
a basic antivirus protection. You must also configure real-time or scheduled database
scanning for adequate antivirus protection.

For performance considerations and configuration best practices see 9.4.5, “Best practices
for using ScanMail in your environment” on page 440. You can find detailed instructions and
best practices for ScanMail monitoring and logging in “Monitoring your ScanMail
environment” on page 447.

ScanMail tasks
ScanMail tasks are started in the same way as other Domino server tasks. You can use the
load Domino server command to manually load a task. For example, to load the manual
database scanning task, you enter:
load dbscan

You can stop ScanMail tasks by specifying the quit parameter, for example:
tell dbscan quit

To automatically load ScanMail tasks when the Domino server starts, you have to add the
tasks to the ServerTasks variable in NOTES.INI. The tmmscan and repscan ScanMail tasks
are automatically added to the ServerTasks variable by the ScanMail configuration program
(CFGSM). ScanMail checks the number of MAIL.BOX files on the Domino server and adds
(# of MAIL.BOX files + 1) tmmscan tasks to NOTES.INI, up to a maximum of four tmmscans.

Configuring real-time mail scanning

Real-time e-mail scanning (tmmscan) continuously scans all e-mail messages that are sent to
MAIL.BOX files on the Domino server. It is enabled by default, but you need to configure the
following options:
򐂰 Basic configuration options
򐂰 What to scan
򐂰 How to handle virus incidents
򐂰 Virus incident notification
򐂰 Logging options

You do not have to restart any ScanMail tasks when changing options in the ScanMail
configuration documents. Configuration update is performed automatically.

Real-time e-mail scanning is configured in the ScanMail for Lotus Notes (SMCONF.NSF)
database. The configuration document is accessed by clicking Scan Options -> Mail Scan in
the navigation tree.

Basic configuration options

The basic configuration options for real-time e-mail scanning are:
򐂰 You can see the current status of real-time mail scanning at the top of the configuration
document.
򐂰 Enter the amount of dedicated memory for the tmmscan task in the Scan memory field.
For recommendations and performance considerations see “Memory-based scanning” on
page 445. The default is 5 MB.

Chapter 9. Antivirus protection 435

 What to scan
Next you have to configure which files to scan and for what kind of malicious code:
򐂰 The Files to scan section allows you to define which files will be processed by the
tmmscan task. The best antivirus protection is provided by the Scan all files option
without any exceptions defined. For a detailed discussion on this topic see “Selecting
which files to scan” on page 447.
򐂰 You can define processing of compressed files in the Scan compressed files and Clean
compressed files fields. We recommend enabling the Scan compressed files option.
򐂰 The Scan mail bodies for script viruses option provides protection from embedded script
viruses such as the VBS_BUBBLEBOY worm. We recommend enabling this option.
򐂰 The Scan embedded objects option enables scanning of messages for Object Linking and
Embedding (OLE) objects that have been embedded in attachments or documents. For
maximum protection we recommend enabling this option.

For a complete description of all scanning options refer to the ScanMail documentation. You
can see the configuration for our test environment in Figure 9-8.

Figure 9-8 Real-time mail scan — the scan options

436 Domino 6 for iSeries Best Practices Guide

How to handle virus incidents
The next configuration section is called “Action on viruses”. Here you define how ScanMail
handles virus incidents. For a basic ScanMail configuration you have to define:
򐂰 Action on cleanable files and Action on uncleanable files. These options determine the
handling of infected attachment(s). Possible actions are:
– Pass: Leaves the infected file as is, without cleaning it, and sends it to the recipients.
– Quarantine: Moves the infected file, without cleaning, to the quarantine database. The
recipient receives an e-mail message without the infected attachment.
– Delete: Removes the infected file from the e-mail or Domino document.
– Auto Clean: Cleans the infected file and the cleaned attachments are sent to the
recipients. Trend Micro recommends to keep this default so that cleaned e-mail is
delivered.
– Block: Prevents the entire e-mail message from being delivered.
When ScanMail detects a virus in an e-mail attachment, it acts only upon the infected
attachment. Unless you select the Block action (which blocks the entire message), the
body of the e-mail message and any uninfected files are sent to the recipient.
򐂰 In the Action on special virus types section you can define handling options for trojans,
worms, joke programs and mass mailing viruses. We recommend the delete option for all
three fields.
򐂰 The Action on unscannable files section enables granular control over e-mail messages
that were not scanned because:
– Maximum extract file size is exceeded: This parameter defines the maximum size of
decompressed files that should be handled by ScanMail. This protects your ScanMail
environment from compressed files that would require too much processing resources.
The amount should be set in accordance with your organization’s e-mail policy. Please
note that ScanMail can handle file sizes up to the available disk space on the system,
however, unzipping extremely large files could have a tremendous impact on
performance and disk space on your system.
– Files are password protected: The Password protected files option defines the
handling of files that cannot be scanned because a password is required to open them.
This option should be set in accordance with your organization’s e-mail policy.
– Mail is encrypted: The Encrypted mails option defines the handling of encrypted
e-mails that cannot be scanned. Again, this option should be set in accordance with
your organization’s e-mail policy.
– File has too many compression layers: The Max compression level protects from
files that have too many layers of compression. An authorized file usually needs no
more than 2 layers of compression.
In addition, the Action on unscannable files section allows you to set up notifications to the
administrator, the sender, and the recipient about the status and handling of an offending
e-mail message. Notification best practices are discussed in “Virus incident notification” on
page 442.

The example configuration for the virus incidents handling options in our environment is
shown in Figure 9-9.

Chapter 9. Antivirus protection 437

 Figure 9-9 Real-time mail scan “Action on Viruses” options

Virus incident notification

Finally, to complete the basic real-time e-mail scanning configuration you must define the
virus notification and logging options.

In the Virus notification section you define the notification options and the text of the
messages informing administrators and users about the virus incident. You can configure
different messages for internal and external users.

For real-time e-mail scanning you are able to configure automatic notification of the following
users if a virus is detected in an e-mail message:
򐂰 Administrators can receive information about all incidents or only about uncleanable files.
򐂰 The sender can receive information that his e-mail contained a virus.

438 Domino 6 for iSeries Best Practices Guide

򐂰 The recipients can receive a separate message with the incident information or this
information can be attached to the original message.

Our virus logging configuration can be seen in Figure 9-10.

Figure 9-10 Real-time mail scan Virus Notification options

For more thorough information on virus incident notification see “Virus incident notification” on
page 442.

Logging options
The virus logging options are not selected by default. However, there are two options for
saving information in the Quarantine databases:
򐂰 Save a copy of infected documents in Quarantine database.
When this option is selected, copies of infected documents are saved in the
SMQUAR.NSF database. If you do not select this option, infected attachments and
documents are deleted.

Chapter 9. Antivirus protection 439

 򐂰 Keep a log and a copy of encrypted documents in Quarantine database.
This option writes ScanMail log information and saves a copy of the infected document in
the Quarantine database. The encrypted e-mail messages cannot be scanned.

This completes the basic configuration of Trend Micro ScanMail for Lotus Notes 2.6 for
OS/400. For more information see the product documentation available on the Trend Micro
Web site at:
http://www.trendmicro.com/download/product.asp?productid=10&show=doc

Performance considerations and recommendations for real-time mail scanning can be found
in 9.4.5, “Best practices for using ScanMail in your environment” on page 440.

9.4.5 Best practices for using ScanMail in your environment

Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 provides many configuration options
and customization points. In this section we provide best practices for optimized operations
and maximum performance of Trend Micro ScanMail for Lotus Notes 2.6 for OS/400. This
includes:
򐂰 Best practices for installation and configuration
򐂰 Antivirus protection best practices
򐂰 Performance optimization
򐂰 Monitoring your ScanMail environment
򐂰 Use of Trend Micro Control Manager for centralized configuration and monitoring

Best practices for installation and configuration

Installation and configuration best practices for Trend Micro ScanMail for Lotus Notes 2.6 for
OS/400 include:
򐂰 Testing your antivirus configuration
򐂰 Scheduling regular updates of the pattern file and scan engine
򐂰 Startup order of ScanMail server tasks

Testing your antivirus configuration

You must verify your ScanMail configuration before using it in your environment. This
procedure assures that your system is working properly and virus handling options and
notifications are configured correctly.

The European Institute for Computer Antivirus Research (EICAR) developed a test script that
can be used to test antivirus software. This script is an inert text file whose binary pattern is
included in the virus pattern file from most antivirus vendors. This script is not a virus and
does not contain any program code.

Attention: Never use real viruses to test your antivirus installation!

You can download the EICAR virus file either from the EICAR Web site or from the Trend
Micro Web site. Before you download the EICAR file, you must disable any antivirus software
running on your network or computer. Otherwise, the antivirus software will detect the EICAR
test file as a virus and prevent the download.

To download the EICAR virus file, visit one of the following URLs:
http://www.trendmicro.com/vinfo/testfiles/
http://www.eicar.org/anti_virus_test_file.htm

440 Domino 6 for iSeries Best Practices Guide

Scheduling regular updates of the pattern file and scan engine
New viruses are written and discovered daily. To help protect against these new threats,
Trend Micro provides regular updates to the pattern file and the scan engine. The pattern file
contains virus signatures used to detect viruses in attachments and documents. The scan
engine compares a file’s binary structure with the virus pattern file, detects suspicious
virus-like behavior, and cleans viruses.

It is therefore very important to schedule regular updates to keep up with new threats. Trend
Micro allows for Internet download over HTTP, distribution through replication or distribution
using the Trend Micro Control Manager.

We recommend scheduling hourly updates of the pattern file and the scan engine.
Networking overhead for this operation is minimal and does not impact the Domino server or
the ScanMail operations.

For more information on configuring automatic updates to the ScanMail pattern file and scan
engine see “Automatic updates and registration” on page 431.

Startup order of ScanMail server tasks

Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 uses Domino tasks to perform its
different types of scanning and updates. The ScanMail tasks that are loaded automatically
during the Domino server start are specified in the ServerTasks line in NOTES.INI.

Trend Micro recommends that you change the order of tasks in NOTES.INI to launch
real-time e-mail (tmmscan) and real-time database (repscan) scanning before the Router task
or the Extension Manager is launched. This helps avoiding server operations (mail routing,
replication) without antivirus protection.

We also recommend that ScanMail performs a scan of all MAIL.BOX files before the router
and other ScanMail tasks are started. This setting allows to scan e-mail messages that were
left in MAIL.BOX files after a Domino server crash or abnormal shutdown. This is done using
the manual scanning program (dbscan).

Use the show server command to determine the number of MAIL.BOX files configured on
your Domino server. Number of Mailboxes: displays how many mailboxes have been
configured on your system. The naming conventions for Domino mailboxes are as follows: If
you have only one mailbox configured, then this file is named MAIL.BOX. If you have more
than one mailbox, then the files are named MAILx.BOX, for example MAIL1.BOX and
MAIL2.BOX.

Attention: You must enable and configure Manual scan in your ScanMail configuration for
dbscan to work.

To sum this up: When the Domino server is started, you first scan your MAIL.BOX files then
start the other ScanMail tasks. The following is an example of how the ServerTasks line in
NOTES.INI looks if you are following our recommendations:
ServerTasks=DBScan MAIL1.BOX MAIL2.BOX MAIL3.BOX,TmmScan,TmmScan,RepScan,Update,Replica,
Router,AMgr,AdminP,CalConn,Sched,HTTP,IMAP,LDAP,POP3

In our example, ScanMail will first scan the three MAIL.BOX files (MAIL1.BOX, MAIL2.BOX,
MAIL3.BOX). Then the ScanMail tasks tmmscan and repscan are launched before any other
Domino server tasks are loaded.

Chapter 9. Antivirus protection 441

 Antivirus protection best practices
Best practices for optimal antivirus protection of your environment with Trend Micro ScanMail
for Lotus Notes 2.6 for OS/400 include:
򐂰 ScanMail protection strategy
򐂰 Virus incident notification
򐂰 Stopping e-mail delivery when ScanMail is not active
򐂰 Attachment blocking

ScanMail protection strategy

Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 offers protection against malicious code
for all entry points of your Domino environment. Each organization must design a protection
strategy that provides optimal protection for the enterprise.

Key decision factors for selecting an appropriate ScanMail protection strategy are:
򐂰 What is the overall corporate IT security strategy?
򐂰 What are the available resources (processor, memory) on the Domino servers?
򐂰 Where and how can malicious code enter the Domino environment (for example, e-mail
messages, attached file to a document in Domino databases, script bombs)?

Some recommended strategies for optimal antivirus protection for a Domino environment are:
򐂰 Real-time e-mail scanning for all messages and attachments.
򐂰 Implementation of filter rules for unauthorized attachment types and extensions (for a
recommended list see “Attachment blocking” on page 444).
򐂰 Real-time database scanning for all databases, excluding user mail files, Domino system
databases and other databases that do not change often.
򐂰 Scheduled hourly updates for the virus pattern file and scan engine (refer to “Scheduling
regular updates of the pattern file and scan engine” on page 441).
򐂰 Scheduled weekly scan of all Domino databases.
򐂰 Determine the appropriate number of tmmscan and repscan tasks on your system (for
more information see “Optimal number of scan tasks” on page 446).

This strategy provides very good antivirus protection, while also minimizing the system
resource usage.

Virus incident notification

ScanMail provides options to notify different user types about virus incidents. These
notifications can for example be used to inform the sender of a mail that it contained an
infected attachment and to take appropriate action, or you can warn a recipient that the
attachment in this e-mail message was infected and cleaned.

The notification message contains details about the infection, such as the name of the
infected database, the name of the virus, and the action taken. This information is also
archived in the ScanMail log files.

The notification options in ScanMail are as follows:

򐂰 For real-time e-mail scanning you can configure ScanMail for Lotus Notes to automatically
notify the following users if a virus is detected in an e-mail message:
– Administrator
– Network administrators or managers who need to know when infected files are found
– Sender
– Recipients

442 Domino 6 for iSeries Best Practices Guide

 By default, notifications are sent as separate e-mail messages. However, you can
configure ScanMail to append the notification to the original e-mail. You can send the
default message or compose your own message.
򐂰 For database scanning you can automatically notify the following users:
– Database owner:
The database owner is listed in the Domino database profile. If the Domino database
profile does not contain an owner, ScanMail sends the notification to all users who are
designated as managers in the Notes Access Control List (ACL).
– Domino administrator

Notification messages for real-time e-mail scanning can use either plain text messages, or
you can use rich text format to customize the background, graphics, and text style of
messages. Notification messages for database scanning can only consist of plain text
messages.

Because Lotus Domino uses the server name as the default name for program notification
messages, the server name is used as the return address for ScanMail notification
messages. You might want to change this default setting so that users can reply to ScanMail
notification messages. To select an administrator’s mail account as the default return address,
click the down arrow and select the appropriate user.

It is very important to design an appropriate notification policy for your organization as part of
your antivirus protection strategy. When designing the notification policy you have to consider:
򐂰 Whether you want to send information to end users or only to administrators and IT
support staff.
򐂰 Whether you want to send incident information to senders of infected mails outside of your
organization.
򐂰 Will you send incident information also to the intended recipients of the infected e-mail
message that was stopped on the Domino server?
򐂰 What information and instructions will you provide to the recipients of the notification
message?
򐂰 What are the help desk procedures for dealing with users that have received a
notification?

Stopping e-mail delivery when ScanMail is not active

When stopping the real-time e-mail scanning task (tmmscan), the Domino server continues to
process and deliver e-mail messages but e-mail messages are not scanned for viruses. This
can lead to unscanned messages entering your environment due to a ScanMail crash or
unintentional unload of the tmmscan task.

To avoid this problem, ScanMail provides the SMStopMail variable that can be set in
NOTES.INI:
򐂰 SMStopMail = 0
This setting means that the Domino server continues delivering e-mail without scanning.
򐂰 SMStopMail = 1
This setting configures the Extension Manager to hold e-mail messages in the mailboxes
(MAILx.BOX) and the Domino server does not deliver mails to the recipients. The mails
are held until the real-time scanning task is restarted.

Chapter 9. Antivirus protection 443

 Attention: If you disable real-time e-mail scanning in the ScanMail interface, the Domino
server will continue to deliver e-mail, regardless of the setting for the SMStopMail variable.

We recommend that you set the SMStopMail variable to 1 to prevent unscanned messages
being delivered to the users.

Attachment blocking
Most computer viruses and worms are spread using system files that are normally not sent by
e-mail. You can drastically reduce the possibility of virus spreading through your e-mail
system by blocking files with specific attachments.

We recommend that you block the following attachments on your ScanMail server:
򐂰 .386 Windows Enhanced Mode Driver or Swap File
򐂰 .ACM Audio Compression Manager Driver (Windows) and Windows System File
򐂰 .ASP Active Server Page
򐂰 .AVB Innoculan Anti-Virus Virus Infected File
򐂰 .BAT Batch Processing
򐂰 .BIN Binary File
򐂰 .CLA Java Class File (usually .CLASS but can be shortened)
򐂰 .CLASS Java Class File
򐂰 .CMD OS/2®, WinNT Command File, DOS CP/M Command File, dBase II Program File
򐂰 .CNV MS Word Data Conversion File
򐂰 .COM Executable File
򐂰 .CS* Corel Script
򐂰 .DLL Dynamic Link Library
򐂰 .DRV Device Driver
򐂰 .EXE Executable File
򐂰 .GMS Corel Global Macro Storage
򐂰 .HLP Windows Help File
򐂰 .HTA Hypertext Application (run apps from HTML doc)
򐂰 .HTM,.HTML Hypertext Markup Language (HTML)
򐂰 .HTT Hypertext Template
򐂰 .INF Information or Setup File
򐂰 .INI Initialization file (many)
򐂰 .JS*, JS, JSE JavaScript Source Code
򐂰 .LNK Linker File, Windows Shortcut File
򐂰 .MHT* MS MHTML Document (Archived Web Page)
򐂰 .MPD Mini Port Driver
򐂰 .OCX Object Linking and Embedding (OLE) Control Extension
򐂰 .OV* Program Overlay File (.OVL)
򐂰 .PIF Windows Program Information File
򐂰 .SCR Screen Saver Script
򐂰 .SHS Shell Scrap Object File
򐂰 .SYS System Device Driver
򐂰 .TLB Remote Automation Truelib Files
򐂰 .TSP Windows Telephony Service Provider
򐂰 .VBS Visual Basic Script
򐂰 .VBE Visual Basic Script Encrypted
򐂰 .VXD Virtual Device Driver
򐂰 .WBT WinBatch Script
򐂰 .WIZ Wizard File
򐂰 .WSH Windows Script Host Settings File

444 Domino 6 for iSeries Best Practices Guide

In addition to attachment blocking based on file extension, ScanMail also provides true type
file blocking. True file type blocking provides filtering based on the real content of the file
rather than just the extension. For example, ScanMail can determine that a file is an MS Word
file even if it uses the extension “.bak”.

You can configure file blocking and true type file blocking in the eManager/Filter rules section
of the ScanMail configuration.

Performance optimization
Performance best practices for Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 include:
򐂰 Memory-based scanning
򐂰 Optimal number of scan tasks
򐂰 Impact of real-time database scanning
򐂰 Incremental scanning
򐂰 Selecting which files to scan
򐂰 Trusted servers

Memory-based scanning
Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 provides the option to perform a
memory-based scanning of attachments. This delivers vast performance improvements over
standard on-disk scanning and is the recommended option for all ScanMail installations.

The amount of memory used for memory-based scanning is configured separately for each
scanning type (Mail Scan, Real-time Scan, Manual Scan and Scheduled Scan). The memory
is individually allocated to each ScanMail task and is not shared between tasks. Even if you
run multiple instances of the same scanning task, each instance uses its own block of
memory.

Use the following guidelines as a starting point to determine the appropriate memory for
memory-based scanning:
򐂰 Dedicate the amount of memory that is adequate for most e-mail messages and document
attachments in your environment. If you find that 90% of attachments in your organization
are below 2 MB, you can allocate only 2 MB to each memory-based scanning task.
Do not use the average message size for this sizing as you will not get optimal results.
򐂰 If your organization is limiting the maximum attachment size, you can use this value.
򐂰 Compressed files must be decompressed before scanning. You must dedicate an
appropriate amount of memory for the decompressed files, not the compressed
attachments.
򐂰 Consider the total amount of memory that will be used by all ScanMail tasks on the
Domino server.
For example if you are running 3 tmmscan tasks with 5 MB dedicated memory and 2
repscan tasks with 10 MB dedicated memory, ScanMail is using 35 MB of memory. At the
time of scheduled scans (pscan) you must also add this memory to the total amount.
򐂰 Check the size and utilization of memory on the Domino server (for more information on
how to determine memory utilization see “Domino memory management” on page 230). In
memory starved environments, the negative impact of dedicating memory for ScanMail
will be far greater than the performance improvement of memory-based scanning.

For most organizations the default value of 5 MB for each ScanMail task is suitable.

To enable memory-based scanning, enter the amount of memory (in megabytes) that you
wish to dedicate to each scanning task in the Scan Memory field of the respective ScanMail

Chapter 9. Antivirus protection 445

 configuration document (Mail Scan, Real-time Scan, Manual Scan and Scheduled Scan). To
disable memory-based scanning, enter a zero in the Scan Memory field. You must restart the
ScanMail tasks in order to use the new configuration.

Optimal number of scan tasks

You can create a multitasking scan environment by running more than one instance of
tmmscan or repscan at the same time. For example, running two instances of tmmscan can
double the processing efficiency. However, each instance of tmmscan loaded allocates the
amount of memory specified in the Mail Scan configuration page.

As mentioned earlier, ScanMail automatically adds one more tmmscan task than there are
MAIL.BOX databases on the server. The extra real-time e-mail scanning task ensures that
the delivery of e-mail is not delayed by large attachments. In addition, you should observe the
amount of messages waiting to be processed. If there is a constant backlog of messages in
the MAIL.BOX files, you should increase the number of tmmscan tasks.

You can also increase the number of repscan tasks for Domino servers with a high number of
attachment updates in databases if you have memory and processor resources available.

Before you load multiple instances of a scanning task, you must ensure that the server has
enough memory and processing power to run the additional tasks. To load additional tasks,
simply add the task to the NOTES.INI file or load it from the Domino console. For example, to
load two real-time e-mail scans (tmmscan), change the ServerTasks line in NOTES.INI as
follows:
ServerTasks=dbscan MAIL.BOX,TmmScan,TmmScan,TmmScan,RepScan,Update,Replica,Router,AMgr,
AdminP,CalConn,Sched,HTTP,IMAP,LDAP,POP3

Impact of real-time database scanning

Real-time database scanning can be time-consuming and processor intensive if your Domino
server includes many databases and thousands of frequently updated files. In this case, you
might want to activate real-time scanning only for the databases that are most vulnerable to
virus infections.

For example, user databases are probably more vulnerable to virus infections than Domino
program databases. Documents and attachments in user mail files are protected by real-time
e-mail scanning and do not need to be rescanned. To protect databases that are not modified
frequently, you should use manual or scheduled database scanning.

You can include or exclude databases from a real-time scan in the Real-time Scan
configuration document under the Databases to scan section. After you change the status of
Databases to Scan (by including or excluding different files), you do not need to restart the
ScanMail tasks.

Incremental scanning
If you select the Incremental Scan option for manual (dbscan) and scheduled (pscan)
scanning operations, ScanMail scans only documents that are new or have been modified
since the last manual or scheduled scan. By limiting the scan to these documents, you can
save server resources and time.

Attention: There is the slight possibility that a virus was not found by scheduled or manual
scans because the virus pattern file used at the time of scanning did not yet include this
virus. By using only incremental scans this document will never be rescanned and the virus
will not be caught.

446 Domino 6 for iSeries Best Practices Guide

You can configure incremental scanning by checking the Enabled box in the Incremental
section of the Manual scan and Schedule scan configuration. By default, incremental
scanning is disabled.

Selecting which files to scan

ScanMail can detect viruses in any type of attachments or documents, including UUencode,
BINHEX, and MIME-encoded documents.

You can choose one of the following options for each type of scanning:
򐂰 Scan all files: All attachments or every document is scanned, regardless of the extension.
This option provides the best protection against virus infections, but it also uses the most
system resources. If performance is an issue, you may have to weigh the benefits of
safety against system resource usage.
򐂰 Scan selected files or exclude selected files: By selecting this option, only the file types
you configured are scanned. The file types are recognized using true type matching
technology. This option provides protection against the sources that you think will most
likely be attacked by viruses. The level of protection depends on the files that you select or
exclude.
򐂰 Exclude files by extension/name: This option provides less protection than selecting
files using true type technology. However, it is faster than true type exclusion because
ScanMail does not have to open all attachments, just the ones matching the specified
extension.
򐂰 Scan and clean compressed files: Protects your network from viruses that are hidden in
compressed files. Because compressed files must be expanded before being scanned,
scanning and cleaning compressed files is resource intensive.

Even though most ScanMail installations use the Scan All Files option, which provides the
best protection, you must weigh performance implications against possible threats and select
the appropriate level of scanning for your environment.

Trusted servers
If messages traverse multiple e-mail servers with antivirus protection in your organization, you
can specify which servers are safe and e-mails from them should not be rescanned. This
configuration can save Domino server processor resources.

To define a trusted server, you must first check the Trusted AV Servers option in the Mail Scan
configuration document. You can then enter Domino or SMTP servers to be trusted in the
appropriate fields in the configuration document:
򐂰 For SMTP Servers, enter the fully qualified domain name (FQDN), for example
mail-fw.itsobp.com. If you trust more than one server that receives e-mail from the
Internet, use a semicolon as the delimiter.
򐂰 For Domino servers, you can either click the down arrow and select the servers to trust or
you can type the Domino server names in the text box. When you enter the server name
manually, use the fully qualified name, such as DOMAV/AV/ITSOBP.
We recommend that you optimize your antivirus architecture in a way that e-mail messages
are not rescanned at each Domino server on the route.

Monitoring your ScanMail environment

In this section we provide best practices for:
򐂰 Log and quarantine handling and purging
򐂰 Advanced options for logging and debugging
򐂰 Centralization of virus logs using Domino replication

Chapter 9. Antivirus protection 447

 Log and quarantine handling and purging
Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 keeps a log of all its activities and
saves these logs in the SMVLOG.NSF database, which is located in the Domino data
directory. Each time ScanMail detects a virus, it creates a new log and records the following
information:
򐂰 A unique ID number for the infected document
򐂰 Sender and recipient of the e-mail message or the server and database on which the
infected document was found
򐂰 Attachment name
򐂰 Virus name, file blocked, hotspot name, or script name
򐂰 Action taken on the virus
򐂰 Date and time

ScanMail creates reports about virus activity on Domino servers using this log data. Available
graphical (pie chart) reports are:
򐂰 Top ten viruses detected
򐂰 Top ten servers with the most infected files
򐂰 Top ten databases with the most infected files
򐂰 Top ten users who have the most infected files

The virus log statistics function can be used to create text reports based on querying the virus
logs. A “Virus Top Ten” report is shown in Figure 9-11.

Figure 9-11 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400 - Virus Top Ten

448 Domino 6 for iSeries Best Practices Guide

For better security, ScanMail uses the quarantine database (SMQUAR.NSF) rather than a
quarantine directory to store infected documents. The quarantine logs are organized by date.
You can configure ScanMail to save messages to the Quarantine that are:
򐂰 Infected
򐂰 Encrypted
򐂰 Blocked
򐂰 Password-protected
򐂰 Other designated messages, such as unscannable e-mail messages or documents

The quarantine logs are organized as follows:

򐂰 Infected Documents
򐂰 Encrypted Documents
򐂰 Blocked eMails
򐂰 Blocked Attachments

We recommend that you store at least copies of infected and blocked messages and
attachments in the Quarantine database. This provides an easy recovery option in case
ScanMail damaged the attachment or improperly blocked a message.

You can access the log (SMVLOG.NSF) and Quarantine (SMQUAR.NSF) databases from
the ScanMail configuration database or by opening them directly in the Lotus Notes client or
Web browser. All reporting functionality is provided for the Lotus Notes client and Web
browser.

You must regularly (daily) review the ScanMail logs to find possible virus infection sources in
your organization. The logs also provide you with the insight into virus outbreak patterns in
your organization. In addition, you can use the logs to determine which computers are
infected and must be cleaned by the IT support staff.

Due to the potentially large amount of data stored in the log and quarantine databases,
ScanMail provides maintenance options for log and quarantine purging. You can set this
option by selecting Log Maintenance under the Log option or Database Maintenance under
the Quarantine Manager option in the SMCONF.NSF database.

We recommend that you define and configure the retention for logs and quarantined
documents in your organization. The interval for log files retention will probably be much
longer (for example one year) than for the quarantined documents (for example seven days).

Due to the more powerful options, we recommend the use of Trend Micro Control Manager
over the ScanMail features for logging and reporting.

Advanced options for logging and debugging

You can determine the level of detail that is recorded in the ScanMail logs and displayed on
the Domino console using the SMOutputLevel NOTES.INI variable. The default value is 2.

You can adjust this value to record less or more detailed information. The following values are
possible:
򐂰 SMOutputLevel=1 reports basic information.
򐂰 SMOutputLevel=2 reports information about ScanMail tasks. This is the default value.
򐂰 SMOutputLevel=3 reports detailed information about what ScanMail tasks do.

The default value of 2 is appropriate for most installations. A value of 3 is useful for problem
determination and analysis. You should not enable this option for longer periods of time as
much more information is displayed in the console and logged.

Chapter 9. Antivirus protection 449

 In addition to the different logging levels, the following ScanMail tasks also provide run-time
debug information:
򐂰 Pattern update (pupdate)
򐂰 Real-time e-mail scan (tmmscan)
򐂰 Real-time database scan (repscan)
򐂰 Manual database scan (dbscan)

To enable debugging, use the -debug parameter after the name of the ScanMail task. Debug
logs are written to the SMLOG directory in the Domino data directory.

Centralization of virus logs using Domino replication

For the purpose of centralized monitoring and reporting you can use Domino replication to
centralize ScanMail virus logs on a single Domino server. This is achieved by replicating the
ScanMail log database SMVLOG.NSF.

To set up replication of ScanMail logs you must:

1. Open the ScanMail Configuration database (SMCONF.NSF) and click General
Administration, then Database Settings.
2. Select the Server Names from which you want to replicate the Virus Log Database
(SMVLOG.NSF).
3. Set Enable replication for the Virus Log Database and click Apply Flag Settings.
The replication flag inside the databases of all selected servers will now be changed from
Disabled to Enabled.
4. Include replication of the SMVLOG.NSF database in your regular replication schedule.
The replication schedule depends on organizational requirements for centralized logging
and reporting.

It is important for large organizations to use replication formulas to ensure that the whole log
is not replicated to all servers but only kept on one server.

When possible we recommend the use of Trend Micro Control Manager over the ScanMail
features for centralized reporting due to the more powerful options.

Trend Micro Control Manager

Trend Micro Control Manager 2.5 is the administration console that provides centralized
management and enterprise-wide coordination for Trend Micro antivirus and content security
products and services deployed throughout the network. Control Manager is a core
component of the Trend Micro Enterprise Protection Strategy that addresses the outbreak life
cycle through coordinated delivery of products, services and expertise. Control Manager
includes the Outbreak Commander console which provides necessary outbreak
management-related tasks from a single interface, including the ability to automatically
download and deploy policies prepared by Trend Micro.

Control Manager helps administrators to consistently enforce security policies throughout

their organization, and act quickly to the various stages of a virus outbreak, which is critical for
combating mixed-threat viruses that can appear in multiple areas of the network. By
managing antivirus and content security products through a single console, Control Manager
helps administrators consolidate information regarding virus events or unusual activity and
create graphical reports for analysis and monitoring. Supported antivirus and content security
products are organized into groups that can be remotely managed; servers can be configured
simultaneously in groups or individually through replication. Product information and task
functions are mirrored through Control Manager, making it fast to view and take control of
newly installed products.

450 Domino 6 for iSeries Best Practices Guide

To install Trend Micro Control Manager 2.5 Server on your network, you need the following
items:
򐂰 Hardware:
– Intel Pentium® III processor, 450MHz or higher
– 256MB RAM
– 300MB disk space for server program files
򐂰 Software:
– Microsoft Windows NT® 4.0 with Service Pack 6a; or Microsoft Windows 2000
– Microsoft Internet Information Server (IIS) 4.0 or higher
– Windows Installer (included in Control Manager)
– Any of the following databases:
• Microsoft Data Engine (MSDE)
• Microsoft SQL Server 7.0
• Microsoft SQL Server 2000
• SQL ODBC driver 3.7 or higher

The Trend Micro Control Manager console is implemented using a Web browser, currently
only Internet Explorer is supported.

To install the Control Manager 2.5 Agent for Trend Micro ScanMail for Lotus Notes 2.6 for
OS/400, you need the following minimum hardware and software on your Domino server:
򐂰 OS/400 V4R5M0 or later
򐂰 128MB RAM minimum (256MB or more recommended)
򐂰 50MB free disk space for the program files
򐂰 Trend Micro ScanMail for Lotus Notes 2.6 for OS/400
򐂰 Control Manager 2.5 Server (Build 1246 + Hotfix 1348)

Trend Micro Control Manager is a very useful tool for organizations with multiple Domino
servers or for organizations using other Trend Micro products in addition to ScanMail. The
main advantages of using Trend Micro Control Manager with Trend Micro ScanMail for Lotus
Notes 2.6 for OS/400 are:
򐂰 Centralized virus logging
򐂰 Powerful reporting and analysis options
򐂰 Faster response to virus outbreaks prevention using Outbreak Prevention Services
򐂰 Centralized configuration console
򐂰 Centralized distribution of pattern files and scan engine

Chapter 9. Antivirus protection 451

452 Domino 6 for iSeries Best Practices Guide
 Part 3

Part 3 Sizing and

IBM Eserver Workload
Estimator
Part 3 of this book teaches you what needs to be considered when sizing a Domino
environment and explains how to use the IBM Eserver Workload Estimator.

© Copyright IBM Corp. 2004. All rights reserved. 453

454 Domino 6 for iSeries Best Practices Guide
 10

Chapter 10. Sizing tips and techniques

In this chapter we provide a quick reference to a number of Domino for iSeries sizing tips and
insights. The following crucial tips and techniques have proven useful to other Domino for
iSeries technical specialists. There is also an example sizing estimate questionnaire available
online at the ITSO materials Web site. Please refer to Appendix D, “Additional material” on
page 611 for details on how to access this Web site. This questionnaire will help facilitate a
clearer understanding of the existing Domino infrastructure and plans.

The content of this chapter is highly related to the input required by the IBM Eserver
Workload Estimator (also called WLE in this chapter).

© Copyright IBM Corp. 2004. All rights reserved. 455

10.1 Useful Domino for iSeries sizing tips
Although not all-inclusive, the following helpful sizing tips have been gathered from the
experiences of a number of Domino for iSeries specialists.
1. MCU, CIW and CPW:
Do not use CPW (Commercial Processing Workload) to compare relative Domino
processing capabilities of iSeries models. MCU (Mail and Calendar Users) is the
recommended IBM metric to use for a very rough comparison of different iSeries models.
The use of the MCU metric is especially crucial if you are considering an upgrade to a
POWER4™ iSeries model from an earlier iSeries (SStar based) model. Additional
information on MCU, CPW and CIW (Compute Intensive Workload) can be found in “CPW,
CIW and MCU” on page 497 of this redbook. MCU ratings for the older iSeries models are
included in 11.11.1, “Capabilities of various iSeries and AS/400 models” on page 501.
Descriptions of each metric as well as MCU ratings for the more recent iSeries models are
documented in the iSeries Performance Capabilities Reference Version 5, Release 2
manual which is online at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/as4ppcp8.pdf

Note: For your information, the MCU benchmark characteristics are planned to be
changed in the future for the next generation of iSeries hardware.

2. LPAR:
Understand any OS/400 LPAR (logical partitioning) plans which are being considered for
the Domino environment. It is important to understand that there is overhead associated
with implementing OS/400 logical partitioning. If LPAR is a possibility, be sure and do
Workload Estimator sizing estimates to reflect both an LPARed and a non-LPARed
environment. An example of adding LPAR in the Workload Estimator is provided in step
on page 554.
3. Registered Domino users versus concurrent (active) users:
Typically one of the first questions asked is “what is the total number of registered Domino
users?”. In addition to the number of current and planned future registered users, a more
critical question to ask is “what are the peak user concurrency rates, for both mail and
applications users?” If the performance of existing Domino servers is already being
monitored, then this information may already be known. However, it is recommended that
current Domino statrep (statistics reporting) data, which represents their peak period, be
obtained since it can also provide other useful information (see tip 14 on page 461).
Although, Domino statrep data includes a peak number of (Notes) users statistic, please
remember this statistic is the peak since that Domino server was last started. Also, this
peak number does not indicate the amount or complexity of the users’ work. Please read
the additional information on concurrency which is contained in 11.5.1, “Concurrent users”
on page 472.
4. Mail file sizes:
It is critical to obtain information on Domino users and their mail file sizes. Large mail file
sizes can have a significant impact on CPU utilization on any Domino server platform.
In addition, mail files containing larger numbers of documents will also impact CPU
utilization. For more information on mail file sizes and their impact on CPU, please see the
IBM Redpaper, Sizing Large-Scale Domino Workloads on iSeries, REDP-3802-00, at:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/redp3802.html

456 Domino 6 for iSeries Best Practices Guide

 It is recommended to obtain the approximate number of users in various mail file size
ranges. As an example, please see the mail file size ranges illustrated in Table 10-1. After
the applicable mail file range details have been gathered, use multiple WLE mail workload
definitions as suggested in “Extremely large databases” on page 482. For example, if
there are 500 users in the 300MB to 399MB range, gain consensus as to whether it is
appropriate to use an average mail file size of 350MB for that workload definition.
Depending on the actual number of users in each range, it may also make sense to
combine several ranges into one WLE mail workload.

Table 10-1 Mail file size ranges and number of users

Less than 99MB ______ 100MB to 199MB ______ 200MB to 299MB ______

300MB to 399MB ______ 400MB to 499MB ______ 500MB to 599MB ______

600MB to 699MB ______ 700 to 799MB ______ 800MB to 899MB ______

900MB to 999MB ______ 1000MB to 1099MB ____ continue on if applicable....

Important: The WLE version available since October 2003 has been enhanced so that the
CPU resource requirements on the suggested systems are influenced by the size of the
mail file entered in the defined mail workload(s). Although WLE increases the CPU
requirements as the mail file size increases, it is still important to utilize user categories.
The rough guidelines shown in Table 10-2 may be used, however, it is important to ensure
that they are appropriate for your Domino environment.

5. Concurrent mail user types:

When using the Workload Estimator it is important to carefully consider the selection of
casual, moderate, heavy and/or 3x heavy user types. As mentioned in the WLE online
help, mail workloads with mail file sizes larger than 200MB should probably be classified
as heavy users and those with mail file sizes larger than 500 MB should be classified as
3x heavy users. In any case, it is important to obtain agreement regarding the user types
selected for your environment.

Table 10-2 Rules of thumb: user types according to mail file sizes
Mail file size range User type (Casual/moderate/heavy/3x heavy %)

< 150 MB 80% moderate/20% heavy

150 MB to 200 MB 40% moderate/60% heavy

200 MB to 300 MB 100% heavy

300 MB to 500 MB 40% heavy/60% 3x heavy

>500 MB 100% 3x heavy

6. Type of mail clients and number of users for each:

It is important to have a clear understanding on the types of clients which will be used to
access Domino, such as the Lotus Notes client, Domino Web Access (iNotes Web
Access), Domino Access for Microsoft Outlook (iNotes Access for Microsoft Outlook),
WebMail, POP3, or IMAP. Ensure that the discussion includes any planned, future
changes regarding mail client types.

Chapter 10. Sizing tips and techniques 457

 Please note that Domino Web Access (iNotes Web Access) users consume significantly
more CPU than Lotus Notes clients. Since the browser based client does not have all of
the capabilities of a Lotus Notes client, more of the work must be done by the Domino
server. An example of defining a Domino Web Access (iNotes Web Access) workload
within Workload Estimator is provided in “Customer example: 10,000 Domino users” on
page 526.
In addition, if browser access to Domino is planned, are there plans to use the secure
HTTP protocol (HTTPS) through SSL (Secure Sockets Layer)? If yes, will Domino or a
network appliance/device provide the SSL service? It is important to note that WLE does
not reflect the use of SSL for any browser based mail workloads which are defined. Some
considerations for SSL are mentioned in “SSL accelerators” on page 13. In general, the
estimated impact of SSL being provided by a Domino 6 for iSeries server may be in the
range of 10% to 20%. Additional information on SSL can be found in section 2.8 of the
redbook iNotes Web Access on the IBM Server iSeries Server, SG24-6553.
7. Other mail considerations:
The load on the system also depends on how the users typically work with their mail:
a. Full text indexing:
Understand the existing or planned extent of full text indexing on mail files. There is an
impact on CPU requirements when full text indices are created as well as when a
search is actually done on the mail file. In internal benchmarks using 700 MB mail files,
after the initial building of the indices, their mere existence has a very minimal impact
whereas actual search transactions have a larger impact on CPU requirements.
Although the impact on CPU depends on the frequency of the searches and the size of
the view, an increase of about 20% of the earlier ‘non-search’ CPU utilization was
observed during this internal benchmark. However, the biggest impact on CPU can
occur when a search is done on a mail file which is not already full text indexed. This is
due to an index having to be built dynamically each time a search is done on the mail
file. Also, in this case, the dynamically built index is then discarded. More details on
indexing can be found in 4.2.3, “Mail file sizes and indexing large Domino databases”
on page 238.
b. Local mail replicas:
Be sure to ask the question about how many users work off of their local mail replicas
and what replication interval is used. For example, if a large group of users bring up
their Lotus Notes client in the morning within a short time period and they all have a
replication schedule of every 15 minutes, then the WLE mail workload for that set of
users should be 100% concurrent and perhaps classified as a moderate user. Please
note that when sizing for disconnected users, a disconnected user doing replication will
usually place a somewhat lighter load on the system than a connected user doing the
same number and type of transactions.
c. Modified mail template and/or extensive use of agents?
Depending on the extent and complexity of the modifications or agents, the sizing
estimate done by WLE could produce much lower estimated CPU utilization than that
which is realized after implementation. For example, the impact on CPU can be very
significant if the out of office agent is modified such that it responds to each and every
new mail as opposed to sending responses after a group of new e-mails are received.
8. Domino clustering:
It is critical to understand the existing or planned future use of clustering and its purpose:
high availability, load balancing or both. In addition, if many Domino servers are being
consolidated to a few iSeries systems, ensure that a discussion regarding the occasional
planned downtime and availability requirements has occurred. For more information on
Domino clustering, see 11.5.3, “Domino clustering” on page 475.

458 Domino 6 for iSeries Best Practices Guide

9. Existing Domino environment:
If the Domino servers are currently running on another platform, it is important to obtain a
list of the existing Domino based systems. For each of these systems, the characteristics
to be obtained include:
– Platform
– Purpose (mail, applications, router, and so on)
– Total and used disk space
– MHz per processor and number of processors
– Memory
– Domino servers/registered users on each
– Domino version/release
– Peak period CPU utilization
You can use the table shown in Figure 10-1 to list this information.
The peak period CPU utilization for each of the existing Domino based systems should
reflect the customer’s busiest time. For example, the busiest time for a company may be
seasonal, at month end, at quarter end, or perhaps once a year. If the sizing estimate
must be done using other data since actual data for the busiest period is not available,
ensure that agreement is gained on how much “additional” resources should be added to
the sizing estimate to reflect the expected increase in workload during their busy
time/season.
Also, depending on the environment, a peak period could be 2 hours, an hour, 30 minutes
and so on. Although not seen very often, a peak period for a company may occur during
off shift hours instead of during the daytime prime shift. For example, perhaps there are
applications whose processing must be completed within a certain time frame at night.
Also, the peak period chosen may also depend on which 'peak' your company is willing to
purchase enough processing capacity to handle.
A final suggestion is to use the above gathered peak period CPU utilization for each
existing Domino Intel server and take that percentage of the total MHz for each existing
Domino based server. These numbers can be put in a table to document a “rough”
estimate of the total MHz the customer's Domino workloads are consuming during that
peak period. This total can be helpful in doing a second check on the data used as input to
WLE and the WLE recommendations. For example, an initial solution design which has a
single 8-way iSeries server replacing 100 Intel GHz capable processors should indicate
that the validity of the WLE input parameters and the customer data should be reviewed
again.

Note: If Domino servers from different geographies are being consolidated onto an
iSeries, consider that there may be large numbers of users in different time zones. As a
result, consider that the peak periods for the various Domino servers are most likely
occurring at different times. As a result, do not assume that the system would need to
handle the sum total of all of the peak period workloads. In other words, if the users are
in very different time zones, the peak periods of the various Domino servers being
consolidated onto a single system, for example, would typically be offset from each
other.

Chapter 10. Sizing tips and techniques 459

 System name:

Characteristic:

Platform

Domino server
names
Location

#CPUs and
MHz per CPU
Total disk/
Used disk

Memory
installed

Avg. CPU Util.

(Prime shift)
Peak period
CPU Util.

# of regis-
tered users
Client type

Avg/Peak User
Concurrency
Avg. mail file
size/# of users
# of Apps

Class of
applications

Figure 10-1 Example table of existing system characteristics

10.Other non-Domino mail infrastructures:

As discussed in item 9, gathering similar information on existing non-Domino mail servers
can also be helpful in better understanding the existing environment when doing an initial
assessment of a server consolidation to Domino for iSeries.
11.Domino applications:
Understand the existing or planned applications environment beyond that of mail. If at all
possible, obtain a listing of the current Domino applications and their characteristics. If this
is not feasible due to a very large number of applications, then it is particularly important to
obtain their application servers’ characteristics as described in tip number 9. In addition,
comparing ‘similar’ groupings of applications with the IBM examples as described in ,
“Example applications” on page 483 can be helpful.
It is especially critical to identify any applications which will not run natively on Domino for
iSeries. Also, it is important to check with any existing 3rd party application provider as to
whether or not their application is supported on Domino for iSeries. Although this is
certainly not all inclusive, a few examples of Domino applications which do not currently
run natively on Domino for iSeries are the Blackberry Enterprise Server and Notrix (DB
access tool) solutions. In addition, understand the types of databases which the
applications are accessing. Starting with LEI 6.5, there is a new ODBC driver which now
allows non-DB2 data to be accessed through LEI 6.5, DECS and LC LSX when in a
Domino for iSeries environment. Additional information on application sizing concepts can
be found in 11.7, “Domino application sizing concepts” on page 483.
12.Domino versions:
Understand the existing versions of Domino and Notes being used as well as what is
planned. For example, what are the plans for upgrading to Notes and Domino 6? If

460 Domino 6 for iSeries Best Practices Guide

 Domino 6 is to be used for a Domino for iSeries sizing estimate, will Single Copy Template,
roaming user, or network compression be used? Information on the potential impact of
SCT can be found in redpaper New features of Domino 6.0.1: Single Copy Template,
REDP3681 available at:
http://publib-b.boulder.ibm.com/redbooks.nsf/RedbookAbstracts/redp3681.html?Open
In the case of network compression, careful consideration should be given to the potential
impact on CPU and the estimated network bandwidth savings. It is estimated that a 10%
to 20% impact on CPU may be seen when implementing network compression. For more
details on network compression, there are several articles online at the developerWorks :
Lotus Web site:
http://www.lotus.com/ldd/today.nsf
Additional information on the roaming user feature can be found in “Client access method
and strategy” on page 7 and in “Roaming users” on page 56. It is estimated that a 10%
impact on CPU may occur during the login of roaming users.
13.Network diagram:
If possible, obtain a network diagram of the existing Domino infrastructure. Ideally, it
should include the location of each Domino server and the bandwidth between locations. It
is critical to understand available network bandwidth if the consolidation of geographically
dispersed Domino servers to one or several centralized sites is being considered. For
example, the remote users will most likely no longer have a Domino server in close
proximity to access. Also, it is important to test the overall performance of critical Domino
applications when moving them from a local LAN to a WAN environment. Additional
information on estimating network bandwidth can be found in “Network bandwidth” on
page 6.
14.Domino statistics reporting (statrep) data:
Here is a list of various statistics which can be helpful in understanding an existing Domino
environment:
– Peak number of users: Information on peak user concurrency rates are discussed in
item 3 on page 456 as well as in 11.5.1, “Concurrent users” on page 472.
– Transactions per minute: Although this provides an indicator of how busy a Domino
server is, it should not be used as the sole basis for a sizing estimate. Also, it has been
observed that the transactions per minute rate has varied between Domino releases
for the same amount of work.
– Network statistics: The Net TCP MB sent and received statistics can be divided by the
number of Notes users to determine the kb/user figure. This figure can be very helpful
when considering server consolidation and the impact on network bandwidth.
– Message size: Normally, a message size greater than 1 MB indicates a power user.
– Total number of mail messages routed and messages delivered.
– Application servers: In the Cluster report, check for the number of documents added,
updated and deleted. These statistics can indicate the volatility of applications.
– Number of dropped sessions and number of replication failures: If these are high
numbers (in the thousands), then it could be an indicator of how stressed the server is,
or it may be an indicator of network problems. These may be high due to I/O or
memory constraints on a server, even though CPU utilization may not be all that high.
15.What is the current overall I/T infrastructure?
A clear understanding of the overall I/T environment, including platforms, operating
systems, locations of systems, and staff can be very important when considering a
Domino server consolidation project.

Chapter 10. Sizing tips and techniques 461

462 Domino 6 for iSeries Best Practices Guide
 11

Chapter 11. Using the IBM Eserver

Workload Estimator
In this chapter we provide an introduction to the IBM Eserver Workload Estimator. The
intent of the Workload Estimator (WLE) is to help provide sizing estimates for an iSeries
system running a variety of workloads. These workloads include Domino, Java, WebSphere,
and Linux as well as more traditional OS/400 based applications. WLE can be used to
estimate the size of a new iSeries or AS/400e solution or to estimate an upgrade of an
existing system.

Important: While reading through this chapter, please remember that the Workload
Estimator results are only estimates and highly dependent on the input parameters.

© Copyright IBM Corp. 2004. All rights reserved. 463

11.1 Other products and references
There are also other products available which can be used to produce an iSeries sizing
estimate or a detailed capacity plan. Please note that effective with OS/400 V5R2, the IBM
BEST/1 capacity planner tool is no longer available. Therefore, BEST/1 should not be used to
size a Domino for iSeries system.

There are various other 3rd party sizing and/or capacity planning products available; several
of these products include BMC Patrol Predict and MPG Performance Navigator. However,
prior to using any of them to estimate the size of a Domino for iSeries system, be sure to
confirm that the tool is not based only on CPW but uses a metric like MCU (Mail and
Calendaring users) for Domino workloads. This is especially critical if you will be upgrading to
an iSeries with POWER4 processors like an i825, i870, or i890. For more details on these
metrics, please refer to the V5R2 Performance Capabilities Reference which is online at:
http://www.ibm.com/servers/eserver/iseries/perfmgmt/resource.htm

Also, if an iSeries has been enabled for PM eServer iSeries, the data can be imported into the
Workload Estimator. More details on PM eServer iSeries is online at:
http://www.ibm.com/servers/eserver/iseries/pm/

There was an enhancement in July, 2003 which now allows PM data from an iSeries LPAR to
be imported into WLE. If doing this, do not forget to consider other LPARs’ workloads on that
iSeries as appropriate. For more details on this capability, please refer to the Workload
Estimator tutorials and help information which are available at the following URL:
http://www.ibm.com/eserver/iseries/support/wle/EstimatorServlet

Also, although WLE does not support the import of PM data from an iSeries Dedicated Server
for Domino (DSD) model, a workload reflecting an existing DSD can be manually entered into
WLE. Additional details on how to create an existing workload definition in WLE can also be
found in the online WLE help and tutorials.

As new versions of mail clients, Domino releases, OS/400 releases and iSeries models are
announced, measurements and analysis are done to keep WLE up-to-date with the latest
technology being deployed on the iSeries. Therefore, it is important to continue to use the
latest version of the WLE. Details on the most recent enhancements added to Workload
Estimator can be found in the “What’s New” section of the WLE online help at:
http://www-912.ibm.com/eserver/iseries/support/estimator/html/whatsNew.html

Important: Please note that the Workload Estimator windows shown in this redbook reflect
the WLE version available at the time of writing. Future WLE versions may have different
windows or results. Also, it is recommended to read through Chapter 10, “Sizing tips and
techniques” on page 455 prior to using the Workload Estimator.

464 Domino 6 for iSeries Best Practices Guide

11.2 Workload Estimator introduction
The intent of Workload Estimator is to estimate an appropriately sized iSeries given a specific
set of parameters and assumptions. In this chapter, the focus is on Domino for iSeries
workloads, but it is important to note that there are numerous other workloads which can be
selected in the WLE. For your information, the IBM WLE is a Java servlet-based Web
application available on the Internet at the following URL:
http://www.ibm.com/eserver/iseries/support/wle/EstimatorServlet

Tip: Prior to using the Workload Estimator for the first time, we highly recommend that you
review the online WLE help and any appropriate WLE tutorials. Links to the WLE help and
tutorials appear on all WLE panels. For an example, see Figure 11-1, which shows the
terms and conditions for using the WLE.

Figure 11-1 Workload Estimator Terms and Conditions

Although the WLE is often used to estimate the size of a new iSeries, it can also be used to
estimate an appropriate upgrade for an existing iSeries or AS/400 system. There are two
ways to enter data about an existing system into the Workload Estimator:
1. You can select the Existing workload option on the Workload Selection page and complete
the questions asked about the existing resources of the system.

Chapter 11. Using the IBM Eserver Workload Estimator 465

 2. Existing iSeries system data can be imported directly into the Workload Estimator from
PM eServer iSeries. However, this method does not work with the Dedicated Server for
Domino models; data from these models must be entered into WLE manually. For more
details on how to import PM iSeries data, please see the WLE PM eServer iSeries
Integration tutorial at the following Web site:
http://www.ibm.com/eserver/iseries/support/estimator/html/Tutorial/PMWalkthru.pdf

Important: If you are upgrading an existing system and will be running Domino R5, please
note that the Workload Estimator makes recommendations based on benchmarks run with
Domino 5.0.12. If you run an earlier release of Domino R5, particularly on a POWER4
based iSeries (i825, i870, i890), your CPU utilization could be 10% to 20% higher than if
you were running Domino 5.0.12. There were changes made to Domino 5.0.12 to optimize
performance with the POWER4 based iSeries.

The recommendation or Selected System reported by the Workload Estimator includes the
model, processor, interactive feature, CPW capacity, memory, number of disk arms and
capacity of disk storage (DASD) necessary to support the set of workloads defined by the
user. When providing the sizing recommendation, the Estimator always defaults to the most
recent iSeries models available.

Even though these detailed resource requirements for each WLE recommendation are given,
it is important to remember that just as with every performance estimate (whether a rule of
thumb or a sophisticated model), you always need to treat it as an estimate and not a detailed
capacity planner. This is particularly true with a robust system like the iSeries server that
offers so many different capabilities where each installation will have unique performance
characteristics and demands.

The sizing recommendations that are generated by the Workload Estimator began with
benchmark measurements and performance tests based on well-defined repeatable
workloads. For Domino, most of the measurements that were performed were the
NotesBench consortium benchmark tests. Through the experience of running these
measurements with large numbers of users, as well as feedback from internal and external
customers and business partners, certain performance projections for each resource have
been developed. These are used in the calculation for a recommended system.

To arrive at a recommended system, the Workload Estimator goes through a series of

questions to collect the necessary information needed for calculating the estimated resource
requirements for your solution. As you become more familiar with the Workload Estimator,
you can provide more specific information for particular workloads, thereby leading to a more
accurate estimation.

Tip: Since the WLE provides estimates, consider running it several times with key input
parameters being 10% plus or minus the original set of parameters. These alternate WLE
sizing estimates allow you to see what the impact would be if the original parameters were
off by 10%. Also, depending on the level of confidence in the original input parameters, you
may want to use 20% instead of 10%.

The Workload Estimator is continually being updated to implement the latest iterations of
workloads as well as to reflect new hardware and/or software versions and releases. New
function is being added on a regular basis to keep the information and projections current.
Periodically review the Workload Estimator Web site to view the latest additions and
enhancements:
http://www.ibm.com/eserver/iseries/support/supporthome.nsf/document/16533356

466 Domino 6 for iSeries Best Practices Guide

 Tip: We highly recommend that you look at every WLE parameter for the workloads you
are defining and try to understand its significance and how it might vary depending on your
specific environment. The more often you accept the default values, the less likely it
becomes that the resulting estimated utilizations of the selected system will be on target.

11.3 Benchmarking
The factors needed to determine an applications’ overall impact on system resources include
the number of active or concurrent users, the type of work being performed, the frequency by
which transactions are performed by the users, and the complexity of applications being
deployed.

Although there are other factors to consider which affect the total impact on the system
(communication lines, I/O processors, bus speeds), the parameters mentioned in the previous
paragraph are the critical factors for the Workload Estimator. A series of questions are asked
in WLE to establish a base set of factors which are then used to determine the estimated
resources required to support the desired workloads for your solution.

Because of the diversity of business applications being deployed today, the best way to
appropriately size a system for a given application is to test the behavior of many system
configurations to see how they perform. However, testing or benchmarking would require
extensive hardware and people resources. Because of this, detailed testing is not typically
performed by customers or IBM Business Partners.

A practical alternative is to select a workload that defines the type and frequency of the
transactions performed by users and use this workload to estimate the load on a system.
After the workload is defined, you can then extrapolate the results to a real user environment
without having to run the test on many different system configurations.

This is only meaningful in conjunction with the well-defined workload for the benchmark. In
most cases, the benchmark result does not correlate to the exact type of “real” users working
in your organization. An example of this is the NotesBench workload which is an industry
recognized benchmark used to measure the impact of mail users on a Domino server.

The NotesBench consortium was established to define standard workloads for measuring
Lotus Domino and Notes Benchmarks on different platforms. One specific benchmark that is
of interest when using the Workload Estimator, especially for sizing a messaging workloads,
is the R5Mail workload. The R5Mail script is as follows:
򐂰 Events occurring every 15 minutes
– Read five documents
– Update two documents
– Delete two documents
– Scroll a view once
– Open and close one database
– Open and close one view
– Send one memo to three recipients
– Do three lookups on the Domino Directory
򐂰 Events occurring every 90 minutes
– Schedule one appointment
– Send one invitation

Chapter 11. Using the IBM Eserver Workload Estimator 467

 For many benchmarks being published today, there is a multiplication factor that can be used
to approximate a projection from a benchmark “virtual” user to a “real” user. As a very general
or rough rule of thumb, a NotesBench R5Mail user is approximately equivalent to one-half of
the complexity of a typical mail user. This means that in the Estimator, the number of typical
users supported by a Domino R5 based system is roughly equivalent to one half of the
number of NotesBench users reported for the same system.

For example, if an iSeries Model 840-2461 was tested with 100,500 concurrent NotesBench
users, then that same system should be able to support 50,250 typical mail users. However, it
is important to remember that a benchmark is only that — and that your Domino users and
environment could be drastically different.

Important: Although the typical user is closer to an average “real” user than a NotesBench
R5Mail user, the workload generated by real users in your environment can be drastically
different. This is certainly true for mail, but it is especially true when referring to Domino
applications other than mail. For example, the design of a Domino application can greatly
impact its performance and affect on CPU utilization.

In addition, NotesBench has recently added mail benchmarks for Domino 6. You can find the
iSeries audited NotesBench results and other useful NotesBench information online at:
http://www.notesbench.org

Reviewing the published iSeries and AS/400 benchmarks can help give you an idea of the
data behind the Domino workload in the Estimator. These published reports are also a good
reference point to start with when investigating possible migrations from other platforms. It is
possible to compare the NotesBench results published from another platform for a specific
workload with the results of the same workload on the iSeries to understand how to use WLE
to simulate the existing workload from another platform.

11.4 WLE terminology

When using Workload Estimator for sizing a Domino solution, it is important to understand the
terms used in WLE as they were intended. This section includes a discussion of two
important WLE terms which could be interpreted differently when used within the context of
Domino:
򐂰 Workload
򐂰 Instance

11.4.1 Workload
On the Workload Selection page as shown in Figure 11-2, the term workload refers to the
entire set of parameters of the workload types defined within the WLE (for example, Domino,
or WebSphere). It is possible to select more than one workload of the same type. This allows
the user to size more than one Domino application per session. Also, if both mail and
applications, are selected within one workload, then the Estimator understands that
parameters need to be asked for mail as well as for applications, for that single workload.

468 Domino 6 for iSeries Best Practices Guide

Since your Domino solution can consist of many different applications, the workload selection
part could include as many different Domino workloads as your total business solution
requires. Similarly, for a Domino mail-only solution, it is possible to select multiple Domino
workloads to reflect different types of mail access. For example, one Domino workload could
be for Lotus Notes client users and another could be for IBM Lotus Domino Web Access
(iNotes Web Access) users. In addition, as described in our example customer scenarios
(500 and 10,000 users respectively) which can be found in Appendix A, “Quickstart to
IBM Eserver Workload Estimator” on page 507, multiple workloads should be used if there
are substantial groups of users with average mail files ranging from small to very large in size.

Figure 11-2 WLE Basic Workload Selection

Sometimes, since each Domino workload that is defined in the Workload Estimator can
contain both a mail profile and an application profile, it is possible to have only one Domino
workload defined. For example, you could either define one Domino workload that details
your messaging or mail solution and another Domino workload that details your end-to-end
business application like a Web shopper. Or you could combine both into a single workload.

Tip: It is normally recommended to define separate WLE workloads for Domino mail and
Domino applications. As a result, the WLE output will include separate utilization estimates
for each workload.

Chapter 11. Using the IBM Eserver Workload Estimator 469

 Figure 11-3 WLE Domino mail workload definition

11.4.2 Instance
Some Domino administrators use the term instance or Domino partition to refer to a Domino
server. For example, you may have multiple Domino partitions or instances of Domino on a
single iSeries server or OS/400 logical partition (LPAR). In Workload Estimator, the term
instance in the phrase “the number of partitions being used by this instance of the Domino
workload” (as shown in item 9 in Figure 11-4) actually refers to a specific Domino workload
defined in the Workload Estimator such as “Domino #1” as illustrated in Figure 11-3 above.

In this context, “a Domino workload instance” may be one of multiple applications deployed
on the same Domino server or across multiple Domino servers. Therefore, given the use of
this term in the WLE, you should consider the specific usage type that is being defined, not
the instance of the Domino server.

Note: Normally, the terms Domino partition, Domino server, Domino instance, and Domino
subsystem (on the iSeries) are used interchangeably.

470 Domino 6 for iSeries Best Practices Guide

 Figure 11-4 Number of partitions for Domino workload instance

11.5 General Domino sizing concepts

Due to the diverse Domino solutions being deployed, there are multiple ways to use Workload
Estimator to perform a Domino for iSeries sizing estimate. The following sections describe in
more detail certain Domino-specific parameters that will help when you are faced with the
task of estimating the load of a Domino based business solution and recommending an
appropriate iSeries to support that solution.

The Domino workload within the Workload Estimator has associated questions designed to
assess the planned Domino environment’s workloads. The default values within WLE are
suggested values for new Domino customers who do not yet know how their users will end up
using the application.

For those customers and business partners who are familiar with the characteristics of their
Domino applications and their users’ habits, this section offers some definitions and helpful
hints on how to interpret the Domino workload concepts used by WLE to estimate a
recommended system.
I

Important: If you select Domino R5 for your defined workloads in WLE, please be aware
that WLE currently makes recommendations based on benchmarks run with Domino
5.0.12. If you run an earlier release of Domino R5, particularly on a POWER4 based
iSeries (i825, i870, i890), your CPU utilization may be 10% to 20% higher than if you were
running Domino 5.0.12. There were changes made to Domino 5.0.12 to optimize
performance with the POWER4 based iSeries.

Chapter 11. Using the IBM Eserver Workload Estimator 471

11.5.1 Concurrent users
The number of registered users is the easiest to understand and it is an input variable which is
always simple to obtain. Although this should be one of the first questions to ask, there is no
way to accomplish a proper estimation if the total number of users is the only information you
have.

The number of active or concurrent users is very important when estimating a solution. There
are a couple of ways to report the total number of active users that a customer will be
deploying.

The mail workload defaults, such as concurrency, as shown in Figure 11-5 are values that are
suggested for new Domino customers who do not know the frequency at which their users will
use the application. Again, if you accept the defaults it is very unlikely that they will match the
actual environment. If you know the percentage of users that are active during peak times,
adjusting the concurrency rate for the application accordingly will result in a more accurate
sizing estimate.

Figure 11-5 WLE Default mail workload settings

When you adjust the concurrency ratings within WLE Domino workloads, it is important to
understand how the concurrency ratings are used. For example, if you select one Domino
workload for both mail and applications, and leave the Estimator defaults for concurrency, the
highest total concurrency rating for all of your users is 65%. This is due to the 50% default
mail concurrency and the 15% default application concurrency rating.

472 Domino 6 for iSeries Best Practices Guide

That means, if you have 1000 users and all users work with mail and a Domino application,
then the mail and application workload profiles should have 1000 registered users. If the
default concurrency rates are used, WLE would then calculate using the default
concurrencies for the combined mail and application workload. In this example, 500 users
would be using mail and 150 users would be using the Domino application concurrently for a
total of 650 Domino users concurrently interacting with the server. As a result, 65 percent
(650 out of 1000) of the users would be active and driving utilization on the system.
I

Tip: When using WLE, ensure that the concurrency rates used for each of the Domino
workloads make sense. For example, if there are 1000 Notes users accessing both mail
and applications, then the two defined WLE workloads should normally not have
concurrency rates which add up to more than 100%. Normally, there will be non-active
Notes users due to meetings, education, illness or vacation and so a real-life 100% user
concurrency is highly unlikely.

Table 11-1 shows the specific default values for concurrent users for each Domino usage
type. These default concurrency values are rough rules of thumb and are described in the
online WLE help. They are based on feedback from IBM representatives, Business Partners
and internal and external customers. Note, however, that these values may be significantly
different in your own environment.

Tip: If you have an existing Domino environment and are moving Lotus Notes users to
Domino Web Access (iNotes) or are perhaps adding new Domino Access for MS Outlook
or Domino Web Access users, then it is generally recommended to use the known, existing
Notes user concurrency rate for these new sets of users, assuming their work habits are
similar.

Table 11-1 WLE - Default concurrency rates

Domino usage type WLE - Default concurrency rate

Notes client mail (Lotus Notes client) 50%

Domino Web Access (iNotes Web Access) 15% (see above Tip box)

Domino Access for Microsoft Outlook 15% (see above Tip box)
(iNotes Access for Microsoft Outlook)

WebMail 15%

IMAP mail 15%

POP3 mail 15% (may be up to 100% depending on poll settings)

Applications 15%

Use a 15 minute interval to determine the total number of concurrent users for each Domino
usage type. An active user is then any user who has performed an activity that made a
request to the server within this 15 minute interval. All users that were active at any time in
that 15 minute interval should be counted as concurrent users. Please note that this value
does not correspond to the default time-out (Server_Session_Timeout), where inactive users
are automatically disconnected after the specified time.

Chapter 11. Using the IBM Eserver Workload Estimator 473

 If you use WLE for existing Domino installations, there are a couple of ways to help determine
user concurrency. For connected Lotus Notes client users, SH STAT SERVER shows the
peak number of users; this information can also be found by looking in the collected statrep
data. Additional details on collecting and storing statistics are included in the Lotus Domino 6
Administration help database (HELP6_ADMIN.NSF); this documentation is online at:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602bf85
256b5800681d38?OpenDocument

The peak number of concurrent mail users value is a great starting point. However, please
note that this statistic by default shows the peak number of users since the Domino server
was last started. Also, SH STAT SERVER does not show how much work the users are
generating. Therefore, this is not the place to determine users' complexity.

The 15 minute interval recommendation is a rule of thumb used to determine the number of
concurrent users of the Domino application being deployed. This rule of thumb also applies to
remote users. For example, if all of the remote users were replicating every 15 minutes, then
they would be 100% concurrent. It is important to note that a disconnected user doing
replication will typically place a somewhat lighter load on the system than a connected user
doing the same number and type of transactions.

11.5.2 Number of Domino partitions

The number of partitions or instances calculated in Workload Estimator refers to the number
of Domino partitions. This metric does not refer to the number of Logical Partitions (LPARs)
being configured on the iSeries server.

By using the default of *CALC to determine the number of partitions, WLE uses a value of
3000 concurrently active users per Domino partition. Depending on the workload generated
by each user, it may be possible to support more ore less users per partition. The default of
3000 active users per Domino partition is a good starting point.

There are of course instances in which overriding the Estimator default is appropriate. For
example, in a case where you have 6000 total users with 50% concurrency, splitting them
across two Domino partitions would allow for easier management and flexibility of the servers.
Especially for an application like mail, where each user owns a particular database, a server
may become somewhat more difficult to manage if the number of databases grows
exceedingly large. In addition, the type of workload or applications being implemented may be
a reason to override the default of 3000 active users per partition.

For example, although IBM Lotus Instant Messaging (Sametime) can certainly run on the
same iSeries as other Domino applications like mail, the general recommendation is to run it
in its own Domino partition. One of the reasons to do this, is that this allows you to end the
Lotus Instant Messaging (Sametime) partition on the iSeries to apply Lotus Instant
Messaging (Sametime) fixes without impacting the other Domino servers on that same
iSeries (and vice versa).

Note: For your information, in Domino R4.6 and earlier releases, there was a certain
maximum workload which could be handled efficiently by each Domino server. This made
it necessary for many administrators to limit the number of mail users per server. At the
time, the recommendation was not to exceed 500 to 700 users per server. With Domino R5
and now Domino 6, the implementation was changed to allow each server to support a
much higher number of concurrent users’ workload.

474 Domino 6 for iSeries Best Practices Guide

11.5.3 Domino clustering
It is important to note that clustering defined for a Domino workload is actually Domino
clustering, not OS/400 clustering. Two or more Domino servers on the same or different
hardware (and the same or different operating systems) can be grouped as a cluster. It is
important to remember that to use Domino clustering, you need to purchase a Domino
license that supports partitioning and clustering. A Domino task called cluster replication
(CLREPL) is crucial for clustering. This Domino task ensures that changes made to a
clustered database are replicated immediately, in contrast to normal replication which takes
place periodically.

When Domino databases are clustered, the server performs real-time replication for any
changes that occur to those databases. Therefore, clustering introduces additional processor
and disk space requirements that need to be included in any sizing estimate. For that reason,
and since there are many ways to configure clustering, it is important to interpret and specify
the appropriate information in WLE.

Attention: In reality, not all databases on clustered servers need to be enabled for cluster
replication. However, within WLE, if clustering is specified for a Domino workload instance
then it applies to all of the databases being defined in that instance. For example, if a
Domino workload is defined for 1000 mail users, the clustering configuration is applied to
the total number of all mail databases. Therefore, if 50% of the users are not being
clustered, two separate Domino mail workloads should be defined within WLE.

It is normally recommended to split your mail and applications into separate workloads. In
many cases, your solution may be designed in a way that clustering is deployed on a more
granular level such that not all mail and/or application databases are being clustered. In
addition, by defining separate workloads, the estimated CPU utilization for each workload will
be provided in the WLE results and therefore easier to understand.

The Workload Estimator allows you to indicate how Domino clustering will be used in several
different ways (inbound and/or outbound). Therefore it is important to understand how
Domino clustering is going to be implemented in your Domino for iSeries solution.

Inbound cluster replication

You can select inbound cluster replication for a Domino workload’s planned usage as
shown in Figure 11-6.

Chapter 11. Using the IBM Eserver Workload Estimator 475

 Figure 11-6 WLE Inbound Cluster Replication

Inbound Cluster Replication indicates that databases from another system are clustered to a
Domino server on your system. Specifying Inbound Cluster Replication within WLE results in
an increase in resource requirements for the Selected System.

When the Next arrow button is clicked, another window like the one in Figure 11-7 appears.

476 Domino 6 for iSeries Best Practices Guide

Figure 11-7 WLE Inbound Cluster Replication parameters

Inbound Cluster Replication Mail Attributes

In the Inbound Cluster Replication Mail Attributes section, you need to provide the following
information:
򐂰 Number of Inbound cluster replication mail users:
Enter the total number of registered mail users that will be clustered to this system from
another system.
򐂰 Percent of inbound cluster replication mail users active at the same time (concurrent):
Enter the percent of mail users on the other (source) system who will be active at one time
during a peak period.
򐂰 Type of incoming mail users:
Specify the types of users on the source system. The online help text contains detailed
information on the differences between casual, moderate, heavy and 3x heavy users.
Here are some general guidelines: For users with mail databases larger than 200 MB, it is
most likely appropriate to use the heavy mail user type. For users with mail databases
larger than 500 MB, it is normally appropriate to specify the 3x heavy mail user type. In
addition, please refer to tip 5 on page 457 for additional information on suggested settings
for user types.

Chapter 11. Using the IBM Eserver Workload Estimator 477

 򐂰 Amount of disk storage per registered user needed for inbound cluster replication mail
databases:
Enter the amount of storage you are expecting on average per mail user. It is important to
obtain this information; if this is a new Domino environment and it is not possible to provide
a planned average mail file size, then 100 MB could be entered.
Specifying larger mail databases will not only increase the amount of disk space required
but also the amount of CPU resource required to process the mail workload. Depending
on the number of average mail file size ranges, as mentioned in tip 4 on page 456, it may
be appropriate to enter multiple inbound cluster replication workloads.

Inbound Cluster Replication Application Attributes

In the Inbound Cluster Replication Application Attributes section, you need to provide the
following information:
򐂰 Number of Inbound cluster replication application users:
If applicable, specify the total number of registered application users that will be clustered
from another (source) system to a Domino server on this system.
򐂰 Percent of inbound cluster replication application users active at the same time
(concurrent):
Enter the percent of application users on the other (source) system who will be active at
the same time during a peak period (on that source system).
򐂰 Select the type of inbound cluster replication application:
Select the type of application from the pull down list. More details on each of these types
can be found in the WLE online help by clicking the link “type” in item 7 as shown in
Figure 11-7 on page 477.
򐂰 Inbound cluster replication application rating
This refers to the general complexity rating of the Domino application. Except for the
Custom type of application, the rating for each application type is supplied for you by WLE
and cannot be changed in this parameter.
򐂰 Amount of disk storage needed for inbound cluster replication application databases
Specify the amount of disk space you need for your Domino applications other than e-mail.
This value is a 'cumulative or total applications’ value, not a 'per user' value like that used
for specifying the amount of disk storage for mail databases.

Outbound clustering
Depending on the planned Domino clustering environment, you will most likely need to also
include outbound or outgoing Domino cluster replication workload when using WLE. Within
WLE, the outbound clustering options are the same when defining mail or applications
workloads. As shown in Figure 11-8, WLE asks “How are you implementing clustering for this
mail workload?”. The available options are:
򐂰 None
򐂰 To a different system
򐂰 To the same system

If the databases in this workload are being clustered to a Domino server on a different system
then select “To a different system”. This option will increase the CPU requirements for the
Selected System.

478 Domino 6 for iSeries Best Practices Guide

Specifying “To the same system” indicates that the users/databases defined are being
clustered to a Domino server on the same iSeries system. This option will increase the CPU,
memory, and disk requirements for the Selected System, and will double the number of
partitions that have been either calculated (*CALC) or that the user has specified for that
particular workload.

In addition, the Estimator calculates the amount of disk storage needed for clustering by
adding the amount of disk storage required for the total number of mail databases or in the
case of an application workload, the amount of disk storage required for those applications.
Here is how WLE would calculate the resources needed for clustering based on the input to
the specific clustering questions. In the following example, there are 3000 mail users which
will be clustered on the same system:
1 partition (3000 concurrent users)
+ 1 partition (clustered on the same system)
______________________
2 total partitions

3000 mail databases (3000 concurrent users)

+ 3000 mail databases (3000 replicated databases for clustering)
_______________________
(disk storage for) 6000 total mail databases

Tip: If you have some mail databases and/or Domino applications which will not be
clustered to a different or the same system, then you should define multiple WLE
workloads to reflect the appropriate clustered and non-clustered Domino mail and/or
application workloads.

Chapter 11. Using the IBM Eserver Workload Estimator 479

 Figure 11-8 WLE Mail workload - clustering

Tip: When Domino clustering is involved, it is recommended to run WLE to reflect a

“normal operations” scenario and then run WLE again to reflect a “fail over mode” scenario.
For more information, please see item on page 547 in the WLE appendix.

11.6 Domino mail sizing concepts

As noted previously in the NotesBench benchmark discussion, these benchmark numbers do
not equate to real life users and furthermore, it may not be completely accurate to extrapolate
NotesBench mail users to real life users. The first thing to note is that WLE uses the
NotesBench benchmark value for the number of users that will fit on a system. Then it divides
that by 2. Although the WLE approximates the number of users supported on the system by
dividing any available NotesBench figures by 2, it is important to note that this is only a
starting point. The WLE does this in an attempt to depict an average mail user.

However, not all of the users working with mail servers today are average or “typical”. As a
result, Workload Estimator provides the ability to further classify the mail users’ complexity by
using weighting factors with the casual, moderate, heavy and 3x heavy user types. Please
note that the 3x heavy user type will result in significant increased CPU resources and should
be used only when appropriate. The 3x heavy type of user workload is considered to consist
of approximately 60 transactions per minute. It is suggested that you check your server’s
collected statistics monitoring (STATREP.NSF) database or use the SH STAT command to
verify the number of transactions.

480 Domino 6 for iSeries Best Practices Guide

If your organization has not been using Domino, then the default values of 10% casual,
70% moderate, and 20% heavy mail users may be a good starting point unless your users will
have large mail file sizes. In addition, please remember that WLE defines a casual user as
someone who does not use any calendar functions. Please refer to items 4 and 5 on
page 457 and to Appendix A, “Quickstart to IBM Eserver Workload Estimator” on page 507
for tips regarding mail file sizes and mail user categories. For more details on the mail user
categories, please see the online WLE help. In addition, information on Domino for iSeries
performance and mail workloads can be found in the iSeries Performance Capabilities
Reference Guide for V5R2 at the URL:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/as4ppcp8.pdf

Complex messaging solutions

If you use many agents and extra function with your mail environment, there is only a fine line
between a heavy mail user as defined in Workload Estimator and a Custom Application user.
One possible solution to sizing a very complex messaging solution is to use the Application
profile for Domino in WLE. Alternatively, there is the option to utilize a 3x heavy mail user type
in WLE if appropriate.

For example, within WLE, a mail workload with 100% heavy Lotus Notes client mail users
represents about the same load as an custom application workload with an application rating
of 1.5. This example assumes an average mail file size of 100 MB and it also assumes that
Lotus Notes clients and the same concurrency rates are selected. So if your mail user
workload or profile is very complex, with many views and agents deployed, it may be
appropriate to use the Domino Application profile.

Tip: The mail workload or profile should be used in most cases to estimate a mail
workload. You should only consider using the application profile in cases when you know
your Domino mail environment very well and understand the differences to a standard mail
environment. However, do not use the mail profile to estimate the load of a custom written
or purchased Domino application.

Casual users
Just as it is important to use caution when sizing very heavy mail users, it is also important to
avoid overestimating the number of casual users. As described in the WLE online help, the
casual user does e-mail only (no calendaring) and rarely sends or receives attachments. It is
important to note that new, at first casual users can quickly become more sophisticated and
complex. For example, a Notes user will most likely begin to use the calendaring and
scheduling features as soon as they become more experienced with Notes mail. When
performing a sizing estimate, consider that it is often typical for new Notes users to advance
from being casual users to moderate users in only a few months.

Mail access types

Another factor that has an impact on the workload generated by mail users is the access type.
Mail access types currently supported in the Workload Estimator include:
򐂰 Notes client (Lotus Notes client)
򐂰 iNotes Outlook (Domino Access for Microsoft Outlook)
򐂰 iNotes Web Access (Domino Web Access)
򐂰 WebMail
򐂰 POP3
򐂰 IMAP

Chapter 11. Using the IBM Eserver Workload Estimator 481

 As mentioned before, most of the mail access type profiles in Workload Estimator are based
on information collected from internal benchmarks using the NotesBench suite of workloads.
The recommendations made by WLE are not directly comparable with the audited
NotesBench data. Because the various NotesBench workloads create differing amounts of
work per user, they have been normalized for the Workload Estimator. For a specific mail
access type, the assumption is that each user would do the same amount of work within
15 minutes. The difference would be in the way the user's mail client connects to the server.

With the many mail client choices available, you could support multiple mail access types with
your Domino for iSeries solution. When using WLE for a Domino environment with many
different clients, you should use multiple Domino workloads to define each separate mail
access type.

Concurrent users
The number of concurrent mail users has a significant affect on the overall resource
requirements needed for a Domino mail workload. Based on internal and external feedback
from customers, the default concurrency ratings for each of the mail access types in WLE
have been set to represent a typical mail environment.

For a new Domino mail environment, it may be adequate to keep the defaults. However, if you
are familiar with the way your mail users work or have had Domino mail servers installed for
awhile, please see the discussion about “Concurrent users” on page 472.

Extremely large databases

Another factor that has some affect on the performance and size of a Domino mail solution is
the size of the actual mail databases being deployed along with the size of the Domino
Directory. It has been noted that as the size of these databases grows, the more complex the
average user becomes, which results in overall heavier loads. In addition, a very large
number of documents can also result in heavier loads. Please see 4.2.3, “Mail file sizes and
indexing large Domino databases” on page 238 for more information on performance and
mail file sizes.

The disk storage entered per registered user in WLE currently affects only the recommended
disk capacity. For extreme environments with very large mail databases (for example, over
500 MB) and a huge Domino Directory (for example, over 1 GB), it is possible to account for
the extra load by utilizing the 3x heavy user type and entering the appropriate mail file size in
the defined workload. Alternatively, you may also define a Generic workload or an Existing
workload with the processor resources deemed appropriate for the type of work being
deployed.

The Generic or Existing workloads within WLE are very versatile. They allow a user to enter
various raw parameters of a workload. These parameters include such things as the
interactive and non-interactive CPW processing requirements of a workload, CPU utilization
for an ‘existing’ workload, the amount of memory, the number of disk arms, and the amount of
disk storage for the workload.

When you define mail users with databases larger than 200 MB, it is recommended to specify
those users as heavy users in their own mail workload within WLE. Also, it is recommended
that you define multiple mail workloads in WLE to reflect different numbers of users and their
types with different average mail file size ranges. Please see the sizing tip item number 4 on
page 456 for more information on mail file sizes and item number 5 on page 457 for
suggested user types according to mail file size. However, please remember that these are
only guidelines and can be changed if a deeper understanding of the customer’s Domino
environment suggests the use of different settings.

482 Domino 6 for iSeries Best Practices Guide

 Note: The WLE update from October 2003 included a change to the CPU resource
consumption algorithm for mail files.

11.7 Domino application sizing concepts

When we talk about Domino applications, we are referring to custom written or purchased
Domino databases that implement certain collaboration logic. The logic of those applications
is typically more complex than Domino mail and calendaring.

Sizing Domino applications is a very complex task due to the numerous types of applications
as well as the varying ways in which applications can be designed. Because of these
variations, each application can place very different demands on system components such as
CPU, memory, and disk.

This application discussion concentrates on the interpretation of some of the application

concepts discussed in WLE as well as a short discussion on the Domino application rating
used to rate the complexity of an application. Also, to accompany the application rating
discussion, there are also a few questions that may help in determining a rating of an
application if it does not compare to any of the examples already included in WLE.

Example applications
There are no precise tools available on any Domino platform to simulate the load
characteristics of an application and map the performance to a specific configuration for a
desired number of users. As stated earlier, the most accurate way to size a system for a
specific application is to benchmark the application on a desired platform with the exact
planned resource configuration.

Since that option is not always feasible or available, Workload Estimator directs you to arrive
at a rough estimate of the iSeries capacity you will need by providing examples of several
applications and assisting you in comparing your application to one or more of those
examples.

At the time of writing, WLE utilized 12 example applications that represent typical Domino
applications as illustrated in Table 11-2. There are high level descriptions for each of these
application in the online WLE help text. In addition, more details on some of the applications
such as the workload composition can be found at the following Web site:
http://www.ibm.com/servers/eserver/iseries/domino/d4appsz.htm

Table 11-2 WLE application examples

Application example Rating

Custom (default) 6 (range is from 1 to 11)

Lotus Instant Messaging (Sametime) - Chat .08

Lotus Web Conferencing (Sametime) - Meeting 1.8

Lotus Web Conferencing (Sametime) - 10.7

Audio/Visual

Lotus Team Workplace (QuickPlace) Light 2.6

Publishing

Document Library Application 2.4

Customer Relationship Management 5.5

Chapter 11. Using the IBM Eserver Workload Estimator 483

 Application example Rating

Web Shopper Application 5.3

Web Shopper with DB2 Application 5.6

Domino.Doc - Casual 0.8

Domino.Doc - Moderate 1.5

Domino.Doc - Heavy 4.3

The application rating found in Workload Estimator is a complexity rating of the entire
application. More specifically, the rating is used to determine resource requirement
projections for the different applications.

Using the application rating scale (custom application rating)

Because there are a wide variety of Domino applications being deployed today, a majority of
them are probably not going to compare exactly to the examples described in the Estimator.
Therefore, the ratings specified for the example applications in Workload Estimator can be
used as references when comparing those applications to your applications. Once the
comparison is made, you can make an educated guess at an application rating for your own
application. If your application fits closely to one of the specific examples in WLE, choose the
appropriate example application from the application type list in Table 11-2 on page 483.

If that is not possible and you determine that your application places more or less demand on
the system resources than the example applications, you can select a custom application
rating. If you select the custom application type, it is up to you to specify the application rating
as shown in Figure 11-9. Using the custom application type with the default application rating
of 6.0 is a good starting point if you do not know how heavy the load is, that the application
will put on the system’s resources.

However, it is important to remember that the overall complexity of Domino applications

varies widely. The intent of the default rating within WLE is to represent a 'typical' application
or more specifically, one that falls in the middle of the complexity range provided in Workload
Estimator. An example application that approximates the default application rating of 6.0 is
the Web Shopping Application defined in the online help. More details on this and other
example applications are available at the following Web site:
http://www.ibm.com/servers/eserver/iseries/domino/d4appsz.htm

Although an application rating of 6.0 is a good starting point, in the case of commercial
Domino applications written by Independent Software Vendors (ISVs) and IBM and Lotus
Business Partners, experience shows that increasingly these applications exhibit the
characteristics of an 8 on the Application Rating scale of the Workload Estimator. However
this is a generalization and you cannot rely on this holding true for all ISV applications. So
again, to select a specific rating for your custom application, it is helpful to compare your
custom application with one of the example applications discussed earlier.

484 Domino 6 for iSeries Best Practices Guide

Figure 11-9 WLE application rating

Here is an example of how to estimate your custom application’s rating by comparing it with
an example application. The first task is to figure out which application most closely
resembles your solution. After this is completed, there are several ways to proceed:
򐂰 If it is determined that your application users will generate similar activities as the sample
application, but at different rate, then use an application rating that is proportionately more
or less in the same ratio as the rate difference.
For example, perhaps you are planning to implement a Web shopping application, so that
the users are completing a group of transactions similar to the one described for Web
Shopper, but are going to be completing the sequence at a rate of 180 seconds instead of
90 seconds. Then this application would use a rating that is approximately half the rating
of Web Shopper. Your application is half as heavy as the example.
򐂰 It is also possible that the rate and sequence of transactions for the expected workload is
quite similar to an example in the Estimator, but the users will be completing heavier or
lighter transactions. There is a little more guess work that is required as you proceed with
this type of comparison.

It is important in this second way to have a good knowledge of the complexity of each of the
transactions that are completed. It is then up to you to decide how much of a difference the
transactions are compared to the example application script. See “Considerations for
characterizing existing applications” on page 487 for a list of questions and metrics that are
useful when trying to classify the complexity of an application.

Chapter 11. Using the IBM Eserver Workload Estimator 485

 Users versus HTTP hit rates
When defining a mail or application profile in Workload Estimator, it is necessary to specify a
number of active or concurrent users. For Web applications, such as the Web Shopping
example, it can be difficult to predict the number of concurrently active users.

From an HTTP standpoint, it is a bit easier to discuss hit rates. The HTTP protocol does not
have the concept of a session and, in many cases, the browser users don’t even need to
authenticate. The Web master knows how often a certain URL has been visited, but it is
difficult to find out whether 100 hits have been performed by a single person or by
100 different people.

When you use one of the example Web applications listed in Table 11-2 on page 483 to rate
the complexity of your own application, you also need to specify a number of concurrently
active users to determine how often they are called. These sample applications are described
in detail in the Domino for AS/400: Application Sizing Examples white paper at:
http://www.ibm.com/servers/eserver/iseries/domino/d4appsz.htm

The white paper can help you to calculate the active users even if you know only the HTTP hit
rate. Hit rate values, along with the equivalent number of concurrent users corresponding to
those hit rates, are included in the definition and description of the Web applications in the
white paper. Table 2, “Web Document Library Estimated Sizing” in the white paper (and
partially shown in Table 11-3), allows you to determine a ratio between concurrent users and
hits per second by dividing those two numbers. That way you can determine that (for this
model application) 1 hit per second is generated by 15 active users, or in other words,
100 active users produce 6.6 hits per second.

For example, assume you consider your own Web application to have the same complexity as
the Web Document Library sample application and you expect 120 hits per second. Applying
the ratio described above would result in 1800 (120 times 15) concurrently active users. So
you could specify 1800 registered users and a concurrency rate of 100% or 3600 registered
with 50% active users.
Table 11-3 Web Document Library Estimated Sizing
Model Processor feature # N-way # Concurrent users Hits per second Hits per day

270 2422 1 247 16.5 1,422,720

2423 1 397 26.5 2,286,720

2424 2 777 51.8 4,475,520

820 2425 1 397 26.4 2,286,720

Database capacity
In this context, database refers to a DB2 UDB database and its associated processes, not a
Domino database. Only the time spent in DB2 database code as well as access methods,
such as SQL and Query/400, is considered to be DB2 database processing. The majority of
database processing is therefore when database records are accessed through SQL, ODBC,
JDBC, Query/400, DRDA®, and other database access methods.

This metric is especially important when sizing a Dedicated Server for Domino (DSD) iSeries
model. For an in-depth discussion on the V5R1 Dedicated Server for Domino, refer to the
white paper at:
http://www.ibm.com/eserver/iseries/domino/dsd.htm

486 Domino 6 for iSeries Best Practices Guide

 The reason for discussing the database capacity as part of the Domino sizing concepts for
WLE is because of the way it is used starting with OS/400 V5R1 for DSD systems. The V5R1
DSD logic allows for complementary workloads to be deployed as long as certain criteria are
met. To account for this, the Estimator now allows for complementary workloads to be
projected onto a DSD, but with these requirements in place:
򐂰 Domino must be the majority of the projected total work defined in WLE
򐂰 Projected DB2 UDB utilization is less than the rated DB2 capacity for the model

The rated DB2 capacity is equal to 15% of the CPU for Dedicated Server for Domino models.
For more information on optimizing an application's use of DB2 database processing, refer to
the iSeries Information Center for V5R1 at:
http://publib.boulder.ibm.com/html/as400/v5r1/ic2924/index.htm

Important: Please note that IBM recently announced that the Dedicated Server for
Domino iSeries models will be withdrawn from marketing effective November 21, 2003.
Please go to the following URL for details on the more recent Domino for iSeries models:
http://www.ibm.com/servers/eserver/iseries/domino/is4domino.html

11.7.1 Considerations for characterizing existing applications

Because of the complexity and variety in the Domino applications being deployed, here are
some questions and characteristics that are useful to classify an application that is not
comparable with any of the examples found in WLE:
򐂰 Where is the accessed data located?
– In small Domino databases?
– In a large number of Domino databases?
– In DB2 databases?
򐂰 How is the data structured for accessibility?
򐂰 How is the load distributed on the server?

If the answers to these questions lead to the observation that your solution is quite complex, it
is appropriate to use a fairly high application rating. The following sections offer some
examples of design metrics that may have an impact on the server load or capacity as well as
user response times and can help answer the questions above.

Some application characteristics do not necessarily add extra load to the server which affects
the total performance, but have an affect on the user response time.

After you determine if the application has any of these characteristics, and to what extent, you
can now select an appropriate application rating. There is no exact science to calculate an
application rating based on the design components of an application. However, having
knowledge of the metrics discussed here will help you to determine the appropriate input
values when using WLE.

Many views or agents

One metric that could potentially have a high impact on server performance if not tuned
appropriately is the number of views. If your application has hundreds of views and is
constantly refreshing them, the application could prove to be heavier than expected.

Similarly, the number of agents in an application could cause a significant performance hit.
The number of add-in tasks that are active in the application also has a significant impact on
the server load.

Chapter 11. Using the IBM Eserver Workload Estimator 487

 DB2 access and network overhead
Another factor that impacts the actual load put on the server by an application is the extent to
which the application accesses back end data like DB2. Also, the more network layers and
connections are involved in accessing the data, the bigger the potential for longer response
time.

Applications currently running on another platform

If you plan to deploy a Domino application that is currently running on a platform other than
iSeries, there are a couple of ways to obtain useful information needed to define the profile of
the Domino solution in WLE. As mentioned previously in “Benchmarking” on page 467, it is
possible to use the published NotesBench results from a different platform to help
characterize and define a specific workload for WLE. Also, see the applicable sizing tips in
Appendix 10, “Sizing tips and techniques” on page 455.

11.8 iSeries options in WLE

In addition to the actual Workload definitions, you can specify other environmental
parameters like RAID support, target system family, and target disk full which will affect the
recommended system. These additional parameters can be accessed from the WLE
Navigation bar found in the top left corner of nearly every WLE window.

To define the iSeries option, select Edit -> Options. On the next window click the “Go to
iSeries” link to review and update your iSeries options. The iSeries User Options window, like
the one shown in Figure 11-10 on page 491, appears; this is where you can change the
assumptions which affect the overall iSeries environment that you are estimating.

These options or assumptions affect both the size of the projected workload(s) and the
manner in which the Estimator combines multiple workloads.

In most cases, the Base Calculation Defaults for the OS/400 version, DBCS support and
RAID support will not need to be changed. Options that might need to be changed are:
򐂰 Target Processor Utilization
򐂰 Target Interactive Feature Utilization
򐂰 Target LPAR Processor Utilization
򐂰 Disk Storage Percent Full
򐂰 Disk Attachment Type
򐂰 Disk Storage Type
򐂰 Target Family

Target Processor Utilization

This parameter affects how the WLE tool selects systems. The Estimator attempts to select a
system that will provide processor utilization no greater than the specified Target Processor
Utilization. To select a system that will provide adequate room for incidental growth as well as
base operating system resources, the Workload Estimator defaults range from 50% to 90%
depending on the number of processors.

You may change this value based on specific needs. However, we do not recommend setting
the default utilization for a particular system above its WLE default. For example, if the
70% default for a 2-way system was increased to 85%, it could result in performance
problems during peak usage times, when there are “spikes” in the system utilization. Please
remember that when you adjust this option, the recommendations of the WLE are estimates.
This means that some range (both plus and minus) should be allowed for any estimated
WLE’s selected system’s projected CPU utilization.

488 Domino 6 for iSeries Best Practices Guide

Target Interactive Feature Utilization
The Estimator attempts to select a system whose interactive feature will be used by less than
or equal to the amount specified here. Previously, only one parameter was allowed,
functioning as the target percentage for all n-way systems. However, since larger n-way
systems tend to require a smaller growth buffer (proportionally), multiple defaults for different
n-way systems was added. The target percentage is used to prevent Workload Estimator
from recommending a system which would experience performance problems when “spikes”
occur in the interactive utilization of the included workloads. Since the IBM WLE defaults
should provide an adequate starting point, it is typically recommended to leave the defaults as
they are for the various n-way systems.

If your WLE scenario only includes Domino workloads, then the Interactive Feature Utilization
is not applicable.

Target LPAR Processor Utilization

This WLE selection criteria allows you to set the target processor utilization percentage for all
n-way systems when using LPAR. Again, this target percentage is used to prevent Workload
Estimator from recommending a system which would experience performance problems
when “spikes” occur in the processor utilization of the included workloads. The IBM defaults
should provide a strong starting point for estimating the target percentage your system should
size to on the various n-way systems. Therefore it is normally recommended that these
defaults not be changed.

Disk Storage Percent Full

For each workload defined, the Estimator calculates the minimum amount of disk storage that
will fulfill the workload requirements. Before you select a system for the estimation, the
Workload Estimator adds together the storage for each workload, plus extra storage for
operating system requirements.

If you want the Estimator to calculate extra disk storage as a percentage of the total required,
you can lower this parameter. This is because the parameter is defaulted to 85%. This means
that the Estimator assumes that the defined workload(s) can consume all but 15% of the disk
storage available for the selected system. In other words, the default of 85% means that at
initial installation the iSeries has only 15% of the total disk space free and available to meet
future growth. This should be clearly understood by anyone involved with the Domino for
iSeries solution.

If you lower this value, for example to 70%, then the Workload Estimator would reserve 30%
of the disk storage available and only 70% of the total disk storage is consumed by the
workload(s).

It is recommended to change this value if, for example, you are sizing a mail workload and
you know that your users' mail databases are projected to grow.

Tip: Ensure that it is clearly understood that any proposed solution based on WLE
estimates assumes a specific disk space full percentage. For example, when comparing
two solutions from different vendors be aware of potential differences in disk space full
assumptions. For example, one solution may reflect 70% disk space full while the other
may reflect 100% disk space full.

Chapter 11. Using the IBM Eserver Workload Estimator 489

 Disk Attachment Type
This parameter allows you to change the way in which the disk drives are to be attached on
the selected system. This selection is used by WLE to calculate the number of drives that the
entered workloads require. The newer 2757 SCSI PCI RAID Disk Unit Controller (IOA) can
dramatically increase the number of disk operations that a given drive can perform. Although
the greatest performance gain may be seen when using 2757 cards with the newer 15K RPM
drives, some additional gains may also be seen by using the 2757 card with the earlier 10K
RPM drives. The Original IOA/IOP provides compatibility with versions of the Estimator that
were shipped prior to WLE version 2003.1.

Disk Storage Type

The 15K RPM drives have a faster latency than the other listed disk drives. This means that
they have a faster spinning rate for reading and writing to disk. The benefit to using disk drives
with a faster latency is that, in general, fewer drives are required to perform the same number
of disk operations. For additional details on performance and characteristics of the new
15K RPM drives and 2757, please refer to the V5R2 Performance Capabilities Reference
Guide at the following Web site:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/as4ppcp8.pdf

Target Family
The Workload Estimator defaults to the highest available iSeries technology. As new IBM
iSeries systems are announced, “family designations” will be included in the drop down list.
Unless there is a specific case in which you want to size your solution on a previous
technology system, we suggest that you leave this parameter with the default.

Tip: Although not shown in Figure 11-10, there are buttons at the bottom of the iSeries
User Options window which are helpful, particularly if you use the WLE extensively. For
example, if you have changed options here but would like to reset them back to the
defaults, then press the Load Standard Options button. If you have a favorite set of
options, then the Save My Options and Load My Options buttons can be useful.

490 Domino 6 for iSeries Best Practices Guide

 Figure 11-10 WLE iSeries user options

11.9 Understanding the WLE results

The Selected System that is recommended by WLE is a processor model that will support the
processing, disk, and memory requirements calculated from the questions answered in each
of the workloads defined. All of the systems capable of supporting the work defined are
identified and reported in the Selected System drop-down list as shown in Figure 11-11. WLE
recommends an Immediate Solution system and a Growth Solution system.

The smallest system model capable of supporting the resources required for the defined
workload(s), as well as meeting the criteria specified in “iSeries options in WLE” on page 488
is presented as the recommended system.

Changing any of these options, for example lowering the Disk Storage Percent Full or the
Target Processor Utilization can change the results and thus allow for additional growth.
Alternatively, if you are confident that you understand your workloads completely and know
that there are no plans for growth, you may decide to set the target utilizations a bit higher.

Chapter 11. Using the IBM Eserver Workload Estimator 491

 Figure 11-11 WLE Immediate Solution selected system

The Selected System panel includes the specific processor model, interactive feature,
processor Commercial Processing Workload (CPW), interactive CPW, database capacity,
processor utilization, memory, and the required number of disks and disk capacity.

There are several resources that are reported in the Workload Estimator results (see
Figure 11-12) that need a bit of explanation on how they apply to a Domino solution:
򐂰 Processor CPW
򐂰 Database Capacity
򐂰 Disk Drives
򐂰 Capacity (GB)
򐂰 Growth Solution

492 Domino 6 for iSeries Best Practices Guide

Figure 11-12 WLE results

Processor CPW
The Processor CPW reported in the results of the Workload Estimator should not be treated
as the total CPW in all cases. In some instances, such as the Dedicated Server for Domino,
this metric is actually the non-Domino processor CPW. For a more detailed discussion on the
DSD models and the non-Domino processor CPW, see the white paper “Enhanced V5R1
Processing Capability for the iSeries Dedicated Server for Domino”, which is available on the
Web at:
http://www.ibm.com/servers/eserver/iseries/domino/pdf/dsdjavav5r1.pdf

Also, please refer to item 1 on page 456 for an important sizing tip regarding CPW, CIW and
MCU metrics.

Database Capacity
The Database Capacity metric reported for the Selected System shown in Figure 11-12 is a
measure of the percentage of the overall CPU that is used to perform the DB2 database (not
Domino database) processing. Database processing generally includes processing time in
SQL, ODBC, JDBC, Query/400, DRDA, and other database access methods.

If the database CPU is fully consumed, this does not mean that all of the capacity on the
system is being utilized. It is possible to add more work other than database processing to
take advantage of the remaining cycles.

Chapter 11. Using the IBM Eserver Workload Estimator 493

 Disk Drives
The Disk Drives (arms) value is the number of disk drives required to support the defined
workload(s). This number is determined by the speed of the drives and the number of disk
operations per second necessary to do the work. It does not take into account the disk drive
size available. You should always configure at least this number of disk arms, even if it results
in more disk capacity than needed.

Capacity (GB)
The Capacity shown in Figure 11-12 on page 493 is a separate calculation based on
򐂰 The amount of disk storage defined for the mail databases
򐂰 Plus the storage needed for any application databases
򐂰 Plus disk space required for the operating system
򐂰 Plus extra space for the target disk space full parameter specified in the WLE options
򐂰 Plus disk space required for any other non-Domino defined workload(s)

The calculations for disk capacity and the number of disk drives are done separately. Only
taking one into consideration could result in a number that is too low for the other.

For example, by selecting large disk drives to satisfy the capacity requirements of WLE, there
may not be enough arms for the best performance. Therefore, be sure to obtain a system with
at least the number of disk arms estimated by WLE, even if it results in more disk capacity
than necessary.

It is also worth noting that the value reported for the Selected System requirements is a
minimum requirement. By including more drives, the system will have better parallel access to
the data, which may reduce the data access time significantly.

Growth Solution
A Growth Solution (Figure 11-13 on page 495) is also included in the Workload Estimator
results. It is selected by applying the growth rate, defaulted to 50%, to all of the system
resources used to determine the initial recommended system. It is possible, if the Immediate
Solution is capable of supporting the default 50% growth, to have a Growth Solution with the
same model/feature as that of the Immediate Solution.

494 Domino 6 for iSeries Best Practices Guide

Figure 11-13 WLE Growth Solution

Further information on both the Immediate and Growth Solutions is summarized in the WLE
results output as shown in Figure 11-14.

Chapter 11. Using the IBM Eserver Workload Estimator 495

 Figure 11-14 WLE solution comments

11.10 Additional insights

The Estimator help text for the Domino workload is very helpful in answering questions about
the basic information on the workload. It is impossible to cover all of the Domino material that
is used in sizing and performance measurements necessary. This section covers a few of the
items that are not found in detail in the WLE help text, but that are alwo useful when using the
WLE to help size a Domino solution.

Tip: Before starting any sizing estimate effort, please refer also to Chapter 10, “Sizing tips
and techniques” on page 455. It contains a number of helpful, critical sizing tips gathered
from the experiences of a number of Domino for iSeries technical specialists.

Dedicated Server for Domino

The iSeries Dedicated Server for Domino (DSD) family consists of five models in the
Model 270 and Model 820 processor family. They offer excellent price/performance for
Domino workloads. For optimal performance, these processors require Domino to be running
and to represent the majority of the active workload at all times. For example, the amount of
DB2 processing is restricted on DSD models. For more details, you should refer to the white
paper “Enhanced V5R1 Processing Capability for the iSeries Dedicated Server for Domino”,
which is available on the Web at:
http://www.ibm.com/servers/eserver/iseries/domino/pdf/dsdjavav5r1.pdf

496 Domino 6 for iSeries Best Practices Guide

 Important: Please note that IBM recently announced that the Dedicated Server for
Domino iSeries models would be withdrawn from marketing effective November 21, 2003.
The “successor” for the DSD models are the Domino for iSeries models mentioned in the
next section.

Domino for iSeries models

These newer models are intended to continue the price/performance aspect of the popular
Dedicated Server for Domino (DSD) models. In addition, unlike the DSD models, the Domino
for iSeries models do not have restrictions on the amount of DB2 processing and their
performance is not restricted even if Domino is not active. More details on the Domino for
iSeries models (as well as DSD models) can be found at the Web site:
http://www.ibm.com/servers/eserver/iseries/domino/is4domino.html

CPW, CIW and MCU

The Commercial Processing Workload rating of a system is determined based on specific
workload measurements which are maintained internally within IBM. CPW is designed to
evaluate the system and associated software in a commercial environment. It is not
representative of any specific customer ‘s environment, but generally applies to the
commercial computing environment.

The applications that follow the CPW patterns tend to have many jobs running short
transactions using relatively few CPU instructions and spending much time waiting for I/O to
complete. Usually this is an environment where more time is spent by system code
performing DB2 operations, rather than by the application executing processor instructions.

CPW ratings are best used when the application you are sizing is expected to be used for
traditional business uses such as order entry, billing, etc.

As mentioned in the sizing tip number 1 on page 456, Domino applications should not be
sized using CPW ratings.

One reason is that the ratio of processing time to I/O time for Domino is typically very different
from commercial processing workloads (CPW). More details on CPW and other metrics can
be found in the iSeries Performance Capabilities Reference Version 5 Release 2 manual at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/as4ppcp8.pdf

Important: To compare Domino processing capabilities for various iSeries servers, you
should use the MCU metric. Although, both the MCU and CIW metrics may provide similar
comparisons for certain iSeries models, it is especially recommended to use MCU for
rough comparisons when the i825, i870 and/or i890 models are involved. Do not use CPW
metrics to compare Domino processing capabilities for iSeries systems.

When sizing a Domino application, it is more important to consider the necessary CPU cycles
per user per time versus the time waiting for I/O. For this reason, the Compute Intensive
Workload (CIW) metric was introduced. CIW ratings may be helpful when most of the work by
the application is done within the application code instead of system services. For example, a
Domino Mail and Calendar workload might spend 80% of the total processing time outside of
OS/400, while a CPW workload spends most of its time in OS/400 database code.

Chapter 11. Using the IBM Eserver Workload Estimator 497

 L2 cache
Since the instruction path length tends to be longer than CPW-like workloads, it is very likely
that processors will spend less time switching from task to task. Therefore, it is not as
important to have a big cache. The cache affect is also due in part to the data being
accessed. Because CPW does more I/O, the cache plays a bigger role than it does for CIW.

Some L2 cache is very important for Domino, especially for applications. That is why we
always recommend that you choose those iSeries or AS/400 models for Domino that have L2
cache (see Table 11-4 on page 501 and Table 11-5 on page 502). But Domino applications
that are more CPU-intensive and more comparable to CIW benefit more from additional
processor speed rather than a bigger cache. Also, because CIW-like applications spend more
time on individual processors, they tend to scale better on multiprocessor systems than mail
and/or CPW like workloads.

You can find further information on CIW in Appendix A of the iSeries Performance Capabilities
Reference Guide Version 5 Release 2. You can also see MCU, CIW (and CPW) ratings for
iSeries servers in Appendix C of the same manual.

Typical, Simple, or Mail and Calendaring Users

When using Workload Estimator to size for a Domino mail solution, it is important to
understand the relationships between these three metrics:
򐂰 Simple Mail Users (SMU)
򐂰 Mail and Calendaring Users (MCU)
򐂰 Typical Mail Users
Due to the NotesBench audit rules, we are not allowed to publish results generated by
NotesBench workloads without having them officially audited. Because it is not possible to
audit results for every possible server configuration, the SMU and MCU metrics are used.
򐂰 Simple Mail Users
– Open mail database that contains documents that are 1 KB in size
– Open the current view
– Open five documents in the mail file
– Categorize two of the documents
– Compose two new mail memos 1 KB in size (every 90 minutes)
– Mark several documents for deletion
– Delete documents marked for deletion
– Close the view
򐂰 Mail and Calendaring Users
– Open a mail database that contains documents that are 10 KB in size
– Open the current view
– Open five documents in the mail file
– Categorize two of the documents
– Compose two new mail memos 10 KB in size (every 90 minutes)
– Mark several documents for deletion
– Delete documents marked for deletion
– Create one appointment (every 90 minutes)
– Schedule one meeting invitation (every 90 minutes)
– Close the view

We decided that these two scripts do not represent a typical mail workload. Therefore, as a
rough guideline, we have determined that a typical user is three times as heavy as an SMU
and twice as heavy as an MCU. This means that a given server that can support x number of
Typical users can support 3x SMU and 2x MCU. To translate these metrics into Workload
Estimator terminology, the equivalent of a typical user is a moderate mail user.

498 Domino 6 for iSeries Best Practices Guide

 Registered users versus active users
Note, that so far we have only been talking about active users. Most people asking for the
proper size of a Domino server start with: “We will have xx Domino users....” The number xx
includes typically all users who will use the Domino server at some point in time. In the
terminology of the Workload Estimator, these are called registered users.

The number of registered users is the first question to be answered for each WLE workload.
However, this number alone cannot be used as a basis for sizing; you must answer other
questions like the ones posed by Workload Estimator. The more crucial question is: “What is
the percentage of concurrently active users?” Multiplying that value with the registered users
results in the number of active users.

For example, the Model 810-2469 (7428) is rated at 7900 MCU at 70% CPU utilization. If you
specify a single mail workload of 7900 users in WLE and leave all of the defaults such as 50%
user concurrency (except change the average mail file size to under 100 MB and the user
type to moderate), the Estimator will project a CPU utilization of about 70%. If the
concurrency rating is changed to 100%, and the number of users is changed to 3950 (one
half of the MCU), then the CPU utilization is still about 70%.

11.11 Consolidating Domino servers from other platforms

A question which is often asked is: “How does an iSeries (or AS/400) Model xxx compare to
server yyy running operating system zzz with a processor of nn MHz clock speed?” This
question is very common in situations when someone plans to consolidate multiple servers
from a PC or UNIX platform to one or more iSeries servers. There is no one simple answer,
the correct answer is always: “It depends!”.

It depends on several things:

򐂰 The complexity and type of Domino application you are planning to run, as detailed in the
previous sections.
򐂰 The entire server configuration. That is, processor clock speed (“MHz”) can only set an
upper limit of the potential capabilities at most. Many other factors play an important role
and can further limit the capabilities if they are not sized appropriately, such as the amount
of memory, the number (not size) and speed of disk drives, and the capacity of
communication lines.

While these components can be set by the person who configures the hardware, there are
other factors depending on the internal architecture and design of the server. Such factors
include: bus speed, internal data transfer band width, multitasking overhead, and others.

Having said that, what can you do to estimate the appropriate size of an iSeries server, when
you already know what server is needed on a different platform? Similar to what was stated
for sizing a completely new server, you can use benchmark data to provide an order of
magnitude, as long as you are aware of the limitations of this method.

How important is the processor clock rate (MHz)?

Due to the dramatic developments in the area of processors during the last decade, it seems
to many people that the clock rate of the processor (MHz) appears as the one and only
indication of the speed of a computer system. Although the processor is a very important
component, it is not solely responsible for overall performance.

Chapter 11. Using the IBM Eserver Workload Estimator 499

 There are some facts that describe where the processor speed is more or less important:
򐂰 Capacity is affected by a complicated combination of processor, I/O, and overall efficiency
factors. All applications need a different proportion of these resources. That's why we use
CPW, CIW, MCU, or other kinds of well-defined workloads to classify applications.
򐂰 MHz primarily affects response time of CPU intensive transactions. Some applications are
more processor intensive than others. More importantly, however, is the fact that a short
response time measured for a single transaction does not indicate at all how the server will
be able to handle hundreds or thousands of users.
򐂰 On servers with multiple processors, “adding up the MHz” could underestimate the
capacity of iSeries servers and possibly overestimate the capacity of servers on some
other platforms due to the relative efficiencies of the architectures.
򐂰 When comparing a planned solution to existing Domino servers, it is still helpful to know
the servers’ CPU utilization numbers during the representative peak period. For example,
let’s assume one of the existing Intel based Domino application servers is a 4-way
700 MHz with a peak period CPU utilization of 30%. Therefore, the workloads on that
server consumed roughly 840 MHz (30% of 2800) during the peak period. Details on how
to set up and use Domino platform statistics are contained in the Domino 6 Administration
Help.
Please note that Domino R5 does not support the collection of platform statistics on
Windows 2000 servers. Also, for existing iSeries customers, details on the new Domino 6
integration with OS/400 Collection Services is discussed in 3.3, “Using Collection Services
to monitor Domino and iSeries performance” on page 134.

Tip: As described in the sizing tip number 9 on page 459, it is recommended to obtain a list
of the existing Domino servers’ characteristics (number of processors or CPUs, MHz per
processor, disk used) as well as their peak period CPU utilization.

What about CPW?

As mentioned in “CPW, CIW and MCU” on page 497, the Commercial Processing Workload
should not be used to estimate Domino for iSeries solutions. The following are three main
reasons why CPW should not be used:
򐂰 Most importantly, nearly all Domino applications exhibit quite different behavior than that
defined in CPW.
򐂰 The CPW published for the Dedicated Server for Domino applies only to the non-Domino
workload running on a DSD. More information can be found in the redbook Domino for
iSeries Sizing and Performance Tuning, SG24-5162-01 in section 12.2 entitled “Dedicated
Server performance behavior and capacity.
򐂰 CPW is normally not published for any non-iSeries platform.

Simple Mail Users or Mail and Calendaring Users

If the existing servers have a NotesBench audit published, you can roughly compare the
Simple Mail Users with the NotesBench R4.5 Mail users and the Mail and Calendaring Users
with NotesBench R5 Mail and Calendaring Users. While this method is probably the most
accurate, there are still some restrictions to consider:
򐂰 The term users in SMU, MCU, and NotesBench users should be considered as a
benchmark unit rather than real users. The typical mail users, as described in “Typical,
Simple, or Mail and Calendaring Users” on page 498, may come close to reality in a
mail-only environment, but should never be used to estimate the workload for other
Domino applications.

500 Domino 6 for iSeries Best Practices Guide

 򐂰 Many Domino applications tend to have a more CPU intensive workload, which is more
comparable to CIW as it is to mail users.
򐂰 The benchmarks assume a balanced configuration, that is an appropriate proportion of
CPU, memory, and disk resources, which may not be true for an existing server.
򐂰 When comparing to existing servers, their resources may not be fully utilized.

When keeping the above points in mind, comparing the NotesBench and MCU ratings of
existing servers is still the most reliable method to estimate the appropriate configuration of
an iSeries server. In addition, the CPU clock rating, together with the actual CPU rating can
be used to verify the necessary number and type of iSeries processors.

In any case, the Workload Estimator should also be used to ensure a balanced system, as
described in the previous sections or this chapter.

“Capabilities of various iSeries and AS/400 models” will help you to gather some information
about the different iSeries models and compare it to benchmark data published by the
NotesBench consortium on the Web at:
http://www.notesbench.org

11.11.1 Capabilities of various iSeries and AS/400 models

It is important to know that the MCU ratings for recent iSeries models as well as selected
earlier models can be found in the iSeries Performance Capabilities Reference Guide for
V5R2 which is online at:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/as4ppcp8.pdf

In addition, Table 11-4 and Table 11-6 show the Mail and Calendaring Users (estimated at
70% CPU capacity) for the 270 and 8xx Models announced in 2001. It is important to note
that the 270, 820, 830 and 840 models are being withdrawn from marketing effective
November 21, 2003. The other tables starting on page 502 show the SMU and MCU ratings
of older iSeries and AS/400 models. You may use the tables to compare the potential
capacities of the different iSeries models.

Although the ratings Mail and Calendaring Users and the earlier Simple Mail Users are not
officially the same as the NotesBench ratings, the tables can give you a very rough idea to
compare the capabilities of a certain iSeries model with another server which does have
published NotesBench ratings. When comparing models, it is important to consider the
characteristics of each such as L2 cache, processor speed and number of processors or
CPUs. For example, it is not recommended to run Domino (non-mail) applications on an
iSeries without L2 cache.

Table 11-4 and Table 11-5 describe performance capabilities of the earlier (2001) iSeries
models as they relate to MCU. Table 11-4 lists the DSD models.
Table 11-4 iSeries Dedicated Server for Domino performance details
Model Proc. feature CPUs Chip speed L2 Cache MCU rating Typical mail

820 2458 4 600 MHz 4 MB 11,810 5,905

2457 2 600 MHz 4 MB 6,660 3,330

2456 1 600 MHz 2 MB 3,110 1,555

270 2454 2 600 MHz 4 MB 6,660 3,330

2452 1 540 MHz 2 MB 3,070 1,535

Chapter 11. Using the IBM Eserver Workload Estimator 501

 Table 11-5 lists non-DSD models.
Table 11-5 Further iSeries servers

Model Proc. feature CPUs Chip speed L2 Cache MCU rating Typical mail

840 2461 24 600 MHz 16MB 77,800 38,900

2420 24 500 MHz 8 MB 55,610 27,805

2418 12 500 MHz 8 MB 28,430 24,215

830 2403 8 540 MHz 4 MB 22,900 11,450

2402 4 540 MHz 4 MB 10,680 5,340

2400 2 400 MHz 2 MB 4,490 2,245

820 2438 4 600 MHz 4 MB 11,810 5,905

2437 2 600 MHz 4 MB 6,660 3,330

2436 1 600 MHz 2 MB 3,110 1,555

270 2434 2 600 MHz 4 MB 6,660 3,330

2432 1 540 MHz 2 MB 3,070 1,535

Table 11-6 shows Domino mail workloads for the previous generation of the 270 and 8xx
models. MCU results are based on 70% CPU utilization and should not be compared to the
audited NotesBench numbers.
Table 11-6 Domino workloads on first generation of 270 and 8xx models
Model Proc. feature CPUs Chip L2 Cache MCU Typical Simple
speed rating Mail mail

840 2420 24 500 MHz 8 MB 55,610 27,810 83,420

840 2418 12 500 MHz 8 MB 28,430 14,220 42,650

830 2403 8 540 MHz 4 MB 20,910 10,460 31,370

830 2402 4 540 MHz 4 MB 10,680 5,340 16,020

830 2400 2 540 MHz 2 MB 4,490 2,250 6,060

820 2398 4 500 MHz 4 MB 9,890 4,950 14,840

820 2397 2 500 MHz 4 MB 5,610 2,810 8,420

820 2396 1 450 MHz 2 MB 2,570 1,290 3,860

820 2395 1 400 MHz - 1,650 830 2,480

270 2253 2 450 MHz 4 MB 5,050 2,530 7,580

270 2252 1 450 MHz 2 MB 2,570 1,290 3,860

270 2250 1 400 MHz - 1,600 800 2,400

270 2248 1 400 MHz - 810 410 1,220

502 Domino 6 for iSeries Best Practices Guide

Table 11-7 shows Domino mail workloads for 170 and 7xx models.
Table 11-7 Mail workloads for 170 and 7xx models
Model Proc. CPUs Chip speed L2 MCU Typical Simple
feature Cache rating mail mail

740 2070 12 262 MHz 4 MB 17,860 8,930 26,790

740 2069 8 262 MHz 4 MB 12,350 6,180 18,530

730 2068 8 262 MHz 4 MB 10,960 5,480 16,440

730 2067 4 262 MHz 4 MB 6,900 3,450 10,350

730 2066 2 262 MHz 4 MB 3,530 1,760 5,290

730 2065 1 262 MHz 4 MB 18,70 940 2,810

720 2064 4 255 MHz 4 MB 4,920 2,460 7,380

720 2063 2 200 MHz 4 MB 2,570 1280 3,850

720 2062 1 200 MHz 4 MB 1,340 670 2,010

720 2061 1 200 MHz - 940 470 1,410

170 2388 2 255 MHz 4 MB 3,150 1580 4730

170 2385 1 252 MHz 4 MB 1,550 780 2,330

170 2292 1 200 MHz - 940 470 1,410

170 2291 1 200 MHz - 450 220 670

170 2290 1 200 MHz - 280 140 420

170 2289 1 200 MHz - 190 100 290

Table 11-8 shows the performance capabilities on 6xx and Sxx models. These results are at
70% CPU utilization and should not be compared to the audited NotesBench results. Use
these figures when comparing AS/400 systems only.
Table 11-8 Simple mail users on 6xx and Sxx models
Model Proc. feature CPUs Typical mail Simple mail

600 2129 1 33 100

2134 1 43 130

2135 1 66 200

2136 1 116 350

S10 2118 1 66 200

2119 1 116 350

620 2179 1 123 370

2180 1 166 500

2181 1 300 900

2182 2 666 2000

S20 2161 1 166 500

Chapter 11. Using the IBM Eserver Workload Estimator 503

 Model Proc. feature CPUs Typical mail Simple mail

2163 1 300 900

2165 2 666 2,000

2166 4 1,133 3,400

640 2237 1 466 1,400

2238 2 800 2,400

2239 4 1,533 4,600

S30 2257 1 466 1,400

2258 2 800 2,400

2259 4 1,533 4,600

650 2240 8 2,900 8,700

2188 8 5,500 16,500

2243 12 4,166 12,500

2189 12 7,966 23,900

S40 2207 8 5,500 16,500

2261 12 4,166 12,500

228 12 7,966 23,900

11.12 Additional resources

The following Web sites offer you additional resources for information on estimating sizings
for Domino for iSeries:
򐂰 Links to the Workload Estimator and application sizing information:
http://www.ibm.com/servers/eserver/iseries/domino/d4szintro.htm
򐂰 iSeries Performance Capabilities Reference OS/400 V5R2:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/as4ppcp8.pdf
򐂰 Dedicated Server for Domino and Domino for iSeries models information:
http://www.ibm.com/eserver/iseries/domino/dsd.htm
򐂰 NotesBench consortium:
http://www.notesbench.org

504 Domino 6 for iSeries Best Practices Guide

 Part 4

Part 4 Appendixes
Part 4 of this book gives you a quickstart to use the Workload Estimator based on fictitious
customer environments. It also helps you to solve some Domino performance problems and
tells you what information you need to collect for Domino troubleshooting.

© Copyright IBM Corp. 2004. All rights reserved. 505

506 Domino 6 for iSeries Best Practices Guide
 A

Appendix A. Quickstart to IBM Eserver

Workload Estimator
In this appendix we discuss several example customer scenarios and use the Workload
Estimator (WLE) to produce sizing estimates for appropriate Domino for iSeries solutions. The
two fictitious customers include one with a 500 user Domino environment and another with
10,000 Domino users.

Important: While reading through this appendix, please remember that the Workload
Estimator results are only estimates and highly dependent on the input parameters. It is
recommended that you also read through the information in Chapter 10, “Sizing tips and
techniques” on page 455.

© Copyright IBM Corp. 2004. All rights reserved. 507

IBM Workload Estimator: Customer Scenarios
In this section we describe several WLE example scenarios. Although these customers are
fictitious, the scenarios are derived from a mixture of real customer situations. The examples
include a customer with 500 users and a much larger 10,000 user environment with more
complex requirements such as Domino clustering and OS/400 logical partitioning.

Important: Please note that the Workload Estimator windows shown in this appendix
reflect the WLE version available at the time of writing. Future WLE versions may have
different windows or results.

Customer example: 500 Domino users

In the first example, we have a customer (PAG & Associates) who has never used Domino
and plans on implementing Domino for iSeries. We have gathered the pertinent information
by going through an initial Domino for iSeries sizing questionnaire with the customer and are
ready to use the WLE. A blank copy of an example sizing questionnaire is available for
download at the ITSO materials repository Web site. Please see Appendix D, “Additional
material” on page 611 for details on how to access this repository.

Collecting information from the customer - Sizing questionnaire

Let’s summarize some of the key pieces of information which we have obtained from PAG &
Associates and are now using in Workload Estimator to provide a sizing estimate:
򐂰 There are 500 registered Domino 6 users with an estimated 50% peak user concurrency.
򐂰 All 500 users will use Notes 6 clients for mail and calendaring only; no other applications
except for IBM Lotus Instant Messaging (Sametime).
򐂰 All 500 users will work off their mail files located on the server.
򐂰 The customer plans on enforcing mail quotas: They plan on an average mail file size of
100 MB for 300 users and 300 MB for the other 200 users.
򐂰 The customer understands the WLE defined user types and agrees that 80% moderate
and 20% heavy is appropriate for the 100 MB mail file size users and that 100% heavy is
appropriate for the 300 MB mail users.
򐂰 Of the 500 users, 200 will use IBM Lotus Instant Messaging only (no e-meetings) — a
15% user concurrency is planned.
򐂰 There is no Domino clustering (high availability and/or load balancing is not desired).
򐂰 There is no transaction logging. Backup, Recovery, and Media Services for iSeries,
(BRMS) will not be used; this customer plans on using basic OS/400 backup and recovery
functions since they have sufficient backup windows during which Domino can be
unavailable.
򐂰 The customer will use antivirus software protection for Domino for iSeries.
򐂰 The customer is not planning on using Domino 6 functions such as Single Copy Template,
roaming users or network compression.
򐂰 The customer wants RAID-5 disk protection and has said that a target disk full of 70% is
fine.
򐂰 The customer plans on 10% growth for each of the Domino workloads.

508 Domino 6 for iSeries Best Practices Guide

Creating the 500 user estimate
We first open a browser and then select the WLE link at the following Web site:
http://www.ibm.com/servers/eserver/iseries/domino/d4szintro.htm

Next we must first accept the WLE terms and conditions if this window appears. For an
example of the terms and conditions window, please see Figure 11-1 on page 465. Now it is
time to use the collected customer information and WLE to create a sizing estimate by doing
the following steps:
1. Let’s first make the appropriate changes to the iSeries User Options. Click Edit ->
Options in the window which appears after accepting the terms and conditions (see
Figure A-1).

Figure A-1 WLE for PAG - Edit Options

2. Click the Go to iSeries link in the Series Specific Settings section of the User Options
window. A panel like that shown in Figure A-2 appears. For more details on the User
Options, see “iSeries options in WLE” on page 488.

Appendix A. Quickstart to IBM Eserver Workload Estimator 509

 Figure A-2 WLE for PAG - iSeries User Options panel

3. The defaults of OS/400 V5R2 and RAID support are applicable so scroll down to the Disk
Storage Percent Full parameter. Per the customer’s requirement discussed in the earlier
summary, move the sliding bar from the default of 85% to 70% as shown in Figure A-3.

Figure A-3 WLE for PAG - Disk Storage Percent Full

510 Domino 6 for iSeries Best Practices Guide

4. Click the Save My Options button and then click the Use This Time button. The Basic
Workload Selection window (see Figure A-4) appears.

Figure A-4 WLE for PAG - Basic Workload Selection

Appendix A. Quickstart to IBM Eserver Workload Estimator 511

 5. Since we know that this customer needs three Domino workloads (a mail workload for
100 MB mail file users, one for the 300 MB mail file users and a Lotus Instant Messaging
(Sametime) chat workload), click the Domino Workload link and then use the Add
Workload link to add two more Domino workloads.
The Basic Workload Selection window now looks like the one in Figure A-5.

Figure A-5 WLE for PAG - Add 3 Domino workloads

512 Domino 6 for iSeries Best Practices Guide

6. Before going into each of the three Domino workloads, let’s identify this estimate. If
entered, an estimate identification appears in the WLE results and makes it apparent at a
glance which key assumptions were used. Click the MySolution link (see Figure A-5).
Then click MySolution again and a new window like the one in Figure A-6 appears. This
new window allows for the entry of a description or identification for the WLE estimate.

Figure A-6 WLE for PAG - Estimation Identification

Appendix A. Quickstart to IBM Eserver Workload Estimator 513

 7. As shown in Figure A-7, enter an appropriate description or identification for this estimate,
including the key assumptions and a new solution title. Click the Return button when
finished.

Tip: A recent enhancement to WLE provides a choice between placing the estimation
identification on a separate page in the WLE output or at the top of the WLE results.

Figure A-7 WLE for PAG - Changed Estimation Identification

514 Domino 6 for iSeries Best Practices Guide

8. The Basic Workload Selection window appears as shown in Figure A-8. Notice the new
solution title of “PAG & Associates”. Click the Next button.

Figure A-8 WLE for PAG - changed Basic Workload Selection window

Appendix A. Quickstart to IBM Eserver Workload Estimator 515

 9. Click the Domino #1 link. The Domino #1 workload window appears as shown in
Figure A-9. Click Domino #1 once again to change the title of this workload to something
more descriptive.

Figure A-9 WLE for PAG - Domino #1 Workload definition

516 Domino 6 for iSeries Best Practices Guide

10.Change the Domino #1 title to a more meaningful one, like “Notes mail (100MB)” as
illustrated in Figure A-10. Since this is a mail workload and no clustering is involved, leave
the Applications and Inbound Cluster Replication boxes empty. Click Next.

Important: Although the default of Domino 6 is used in this example, it is important to note
that WLE currently estimates any Domino R5 based recommendations according to data
derived from Domino 5.0.12 benchmarks. If you run an earlier release of Domino R5, your
CPU utilization may be 10% to 20% higher, particularly if you are running it on a POWER4
based iSeries (i825, i870, i890) system. Domino 5.0.12 has changes in it which optimize its
performance on a POWER4 processor.

Figure A-10 WLE for PAG - Notes mail (100MB) title

Appendix A. Quickstart to IBM Eserver Workload Estimator 517

 11.As shown inFigure A-11 on page 518, enter the appropriate parameters to define the
“Notes mail (100MB)” workload. This workload needs to match the customer supplied
information of 300 Lotus Notes client users, 50% peak mail user concurrency, no
transaction logging or Domino clustering, 80% moderate/20% heavy user type, 100 MB
mail file size and an antivirus protection factor. Click Next.

Tip: In this example, leave the number of partitions set to *CALC. The WLE calculates the
number of Domino partitions for mail workloads using the guideline of 3000 concurrent
mail users per Domino partition. For more information on using and overriding this
guideline, please see 11.5.2, “Number of Domino partitions” on page 474.

Figure A-11 WLE for PAG - Notes mail (100MB) parameters

518 Domino 6 for iSeries Best Practices Guide

12.As you just did for the first mail workload, make similar changes to the title of the
Domino #2 workload for the second set of mail users (with 300 MB mail file sizes). Then
enter the associated parameters for the customer’s planned Domino for iSeries
environment as described in “Customer example: 500 Domino users” on page 508. This is
shown in Figure A-12. Click Next when finished.

Figure A-12 WLE for PAG - Notes mail (300MB) workload

Appendix A. Quickstart to IBM Eserver Workload Estimator 519

 13.On the Domino #3 workload panel, select Applications instead of Mail and change the
title of the workload to “Sametime chat” (now: Sametime Instant Messaging) as shown in
Figure A-13. Click Next.

Figure A-13 WLE for PAG - Sametime chat (application) workload

520 Domino 6 for iSeries Best Practices Guide

14.Figure A-14 shows the definition of the “Sametime chat” application workload. We leave
the default concurrency rate of 15% but enter 200 users, change the type of application to
Sametime - Chat and change the application access to Notes client. We also change the
number of partitions to 1 (since Lotus Instant Messaging (Sametime) will run in its own
Domino server instance). Click Next.

Note: “Sametime - Chat” has been renamed to “Sametime Instant Messaging” in the
October 2003 update of WLE.

Tip: If this customer had planned on having a third Domino partition for development or
testing purposes, we could have accounted for it in WLE by specifying two partitions
instead of one in the “Sametime chat” (now: Sametime Instant Messaging) workload.
Currently, increasing the number of partitions for a workload in WLE will increase the
memory requirements. However, in this case, the customer has no such plans.

Figure A-14 WLE for PAG - Sametime chat workload definition

Appendix A. Quickstart to IBM Eserver Workload Estimator 521

 15.WLE now presents the recommended immediate and growth solutions as shown in
Figure A-15. However, the growth solution currently reflects the default growth rate of 50%
and therefore it needs to be changed given the customer’s planned growth rate of 10%. To
change the growth rate, click the link here in the phrase “Growth trends can be changed
here” located under the Growth Solution title (see Figure A-15).

Figure A-15 WLE for PAG - Initial Immediate and Growth Solutions

522 Domino 6 for iSeries Best Practices Guide

16.On the Workload Growth Factors window, check Lock to select it and then change its
value from 50 to 10 as shown in Figure A-16. Click Save.

Figure A-16 WLE for PAG - change growth rate

Appendix A. Quickstart to IBM Eserver Workload Estimator 523

 17.WLE now uses the changed growth rate to update the Growth Solution and presents the
updated results as shown in Figure A-17.

Figure A-17 WLE for PAG - Selected Immediate and Growth Solutions

18.In the left frame, click File -> PDF and the WLE results appear in pdf format as shown in
Figure A-18. This pdf can be printed, saved and e-mailed as appropriate.
For information on interpreting the WLE output, please see “Understanding the WLE
results” on page 491 or go to the WLE online help at:
http://www.ibm.com/eserver/iseries/support/estimator/html/growthHelp.html
Click the Back button in your browser to return to the WLE Selected System window.

Important: In most cases, do not use your browser’s “back” button since doing so will
circumvent WLE’s built-in navigation. This prevents WLE from validating current data
entered in the panel and as a result, WLE may exhibit navigation or other error messages.
To prevent this behavior, always use the navigation arrows within WLE. An exception to this
rule is when you have created a pdf and need to return to WLE.

524 Domino 6 for iSeries Best Practices Guide

Figure A-18 WLE for PAG - PDF of WLE results

19.Since it is always possible that we may need to later revise one or more of the parameters
in this estimate, let’s save all of the workload definitions just created. In the left hand frame
of the window, as shown in Figure A-19, click File -> Save All Workloads. Click Save in
the File download window. In the resulting Save As window, enter a file name (like WLE for
PAG and Associates.xml) and then click Save once again.

Tip: At the time of writing, there is an intermittent problem with saving and restoring WLE
workloads. This problem may occur when you attempt to save WLE workloads and you
have entered an estimation identification. An indicator of the problem is a WLE saved file
which has a 0 KB size. As a result, it cannot be restored since no WLE data was actually
saved. However, this problem is planned to be fixed in the next version of WLE.

Appendix A. Quickstart to IBM Eserver Workload Estimator 525

 Figure A-19 WLE for PAG - Save All Workloads

20.This saved WLE file may be restored later by going back into WLE and choosing the File
and then Restore options in the left hand navigation frame of WLE. Additional details on
saving and restoring WLE files are online at:
http://www.ibm.com/eserver/iseries/support/estimator/html/restorehelp.html

Customer example: 10,000 Domino users

In the second example, we have a customer (OSTI, Inc.) who plans on consolidating most of
their production Domino 6 mail and application workloads from Windows 2000 Intel based
servers to Domino for iSeries. We have gathered the pertinent information by going through
an initial Domino for iSeries sizing questionnaire with the customer. A blank copy of an
example sizing questionnaire is available for download at the ITSO materials repository Web
site. Please see Appendix D, “Additional material” on page 611 for details on how to access
this repository.

In addition, we have obtained their Domino statistics reporting (statrep) data and their Domino
servers network diagram. We also obtained data on their Intel servers, including number of
CPUs, MHz, disk used/total, and peak period CPU utilization. See Chapter 10, “Sizing tips
and techniques” on page 455 for critical sizing tips, particularly when working with more
complex Domino implementations.

526 Domino 6 for iSeries Best Practices Guide

 Important: Obtaining platform statistics is supported when running Domino 6 (but not
Domino R5) on Windows 2000 servers. If possible, it is recommended to enable platform
statistics before collecting Domino statistics reporting (statrep) data. The Domino release
notes contain information on which platforms, if any, do not support the enabling of
platform statistics. Also, more details on enabling platform statistics and collecting statrep
data are available in the Domino Administrator’s guide which can be found in the Lotus
product documentation online at:
http://www.lotus.com/ldd/doc

Collecting information from the customer: Sizing questionnaire

Let’s summarize some of the key pieces of information which we’ve obtained from OSTI, Inc.
and now need to use in WLE to provide a sizing estimate:
򐂰 The customer has Domino 6.0.1 installed on all of their existing servers.
򐂰 Existing Domino production servers: 10 application servers and 12 mail servers. These
are the ones being considered for consolidation.
򐂰 Other Domino servers in the customer environment: Mail routers/SMTP, external Domino
Web server, Domino test/development servers. Currently, the plan is that these are not
consolidated.
򐂰 There are 10,000 registered Domino users currently with a 40% peak mail user
concurrency according to statrep data.
򐂰 There are 10,000 users that have Lotus Notes clients for mail and calendaring. They work
off the server based mail files.
򐂰 The customer plans on adding 2000 new users with planned mail file quotas of 100 MB.
These new users are from a recently acquired company and are not currently using any
e-mail. They will use Domino Web Access (iNotes Web Access); an estimated 15% user
concurrency should be used.
򐂰 The customer is also considering adding instant messaging capability only (Sametime
Instant Messaging workload) for about 6,000 of their 10,000 users (with an estimated 15%
concurrency) and would like these chat users to be reflected in any sizing estimate.
򐂰 Table A-1 shows the mail file size ranges and the types of users that the customer has
agreed to.

Note: Mail file sizes can be found through various means; one way to view all database
sizes is to use the Domino Administrator Files tab. There may also be third party
products which can gather and provide this information.

Appendix A. Quickstart to IBM Eserver Workload Estimator 527

 Table A-1 Mail file size ranges and user types
Number of mail users Approximate mail file size Type of concurrent mail user

4000 (existing Notes users) 100 MB 80% moderate, 20% heavy

4000 (existing Notes users) 300 MB 100% heavy

2000 (existing Notes users) 600 MB 100% 3x heavy

2000 (planned new Domino Web 100 MB (planned) 80% moderate, 20% heavy
Access users)

򐂰 Domino clustering is only done for a subset of the mail users. Namely for those with
600 MB mail file sizes — given that this group consists of employees who have higher
availability requirements.
򐂰 Of the 10,000 Lotus Notes client users, 4,000 also access other Domino applications. The
customer estimates that on average, the majority of their applications are roughly
equivalent to the more complex Customer Relationship Management application example
in WLE; therefore, an application rating of 9.0 is agreed to be appropriate for the Domino
applications workload.
򐂰 According to the representative Domino statrep data, peak application user concurrency is
20%. These Domino applications are not clustered.
򐂰 The total disk used by the Domino applications today is about 150 GB.
򐂰 Many of their Domino applications have “light” access to back end IBM DB2 data (light in
the way WLE defines it).
򐂰 Transaction logging will be used since online incremental Domino backups using BRMS
are planned.
򐂰 The customer will use antivirus software running on the iSeries to protect the Domino for
iSeries servers. The customer agreed to an antivirus protection factor of 15.
򐂰 The customer is not planning on using Domino 6 functions such as Single Copy Template,
roaming users or network compression.
򐂰 The customer wants RAID-5 disk protection and has requested a disk full target of 70%.
򐂰 The customer has asked that any sizing estimate also include 20% growth on all Domino
workloads except for Domino Web Access (iNotes Web Access), which should have no
growth.
򐂰 The customer indicated that the sizing does not need to reflect any test/development
Domino for iSeries servers/partitions.

528 Domino 6 for iSeries Best Practices Guide

Before using WLE, it is helpful to draw a rough sketch of a possible solution scenario. As an
example, here’s one depicting a potential dual iSeries solution for this customer (see
Figure A-20). It assumes that the customer transplants their existing production Domino mail
and application servers as opposed to consolidating into fewer Domino partitions (servers).

iSeries #1 iSeries #2

2000 mail users (100MB) 2000 mail users (100MB)

(2 DPARs) (2 DPARs)

2000 mail users (300MB) 2000 mail users (300MB)

(2 DPARs) (2 DPARs)

1000 (clustered) mail DPAR for clustered 1000

users (600MB) mail users from iSeries #1
Domino clustering
(1 DPAR)
1000 (clustered) mail
DPAR for clustered 1000 users (600MB)
mail users from iSeries #2 (1DPAR)

2000 Domino application 2000 Domino application

users (5 DPARs) users (5 DPARs)

New 1000 iNotes Web New 3000 Sametime chat

Access users (1 DPAR) users (1 DPAR)

New 3000 Sametime chat New 1000 iNotes Web

users (1 DPAR) Access users (1 DPAR)

Figure A-20 OSTI- Initial high level diagram of potential solution

Tip: In Domino server consolidation cases, several sizing estimates are typically needed
before any decision is reached. You may find that you are requested to provide estimates
for both a dual iSeries solution as well as one for multiple smaller iSeries. For example, the
diagram shown in Figure A-20 could be modified to reflect a four iSeries solution
alternative. Thus, if you get into the habit of saving your WLE estimates (as suggested in
step 30 on page 553), returning to WLE to do a different solution scenario is quicker and
easier.

Creating the 10,000 user estimate

After opening a browser and then selecting the WLE link at the following Web site:
http://www.ibm.com/servers/eserver/iseries/domino/d4szintro.htm

we must first accept the WLE terms and conditions. For an example of the terms and
conditions window, please see Figure A-1 on page 509. Now it is time to use the collected
customer information and WLE to create a sizing estimate by following these steps:
1. Let’s first make the appropriate changes to the iSeries User Options. Click Edit ->
Options in the window (compare to Figure A-1 on page 509) which appears after
accepting the WLE terms and conditions.
2. In the User Options window, click the Go to iSeries link in the Series Specific Settings
section.

Appendix A. Quickstart to IBM Eserver Workload Estimator 529

 3. Since the defaults of OS/400 V5R2 and RAID support are applicable, scroll down to the
Disk Storage Percent Full parameter. As the customer has requested, move the sliding
bar from the default of 85% to 70% as shown in Figure A-21.

Figure A-21 WLE for OSTI - Disk Storage Percent Full

4. Click the Save My Options button, then click the Use This Time button. The Basic
Workload Selection window (see Figure A-4 on page 511) appears. From the high level
proposed solution diagram shown in Figure A-20 on page 529, we need to use WLE to
configure one of two “identical” iSeries, each having:
– Three Notes mail workloads (one with inbound cluster replication)
– One applications workload
– A new Domino Web Access (iNotes Web Access) mail workload
– A new Lotus Instant Messaging (Sametime) chat application workload
Click the Domino Workload button and then use the Add Workload button to add five
more Domino workloads.

530 Domino 6 for iSeries Best Practices Guide

5. The Basic Workload Selection window now looks like the one in Figure A-22.

Figure A-22 WLE for OSTI - Add Domino workloads

6. Before going into each of the Domino workloads, let’s identify this estimate. If entered, an
estimate identification appears in the WLE results and makes it apparent at a glance
which key assumptions were used for this particular estimate. Click the MySolution link
(see Figure A-22 above). Then click MySolution again and a new window like the one in
Figure A-6 on page 513 appears. This new window allows for the entry of a description or
identification for this WLE estimate.

Appendix A. Quickstart to IBM Eserver Workload Estimator 531

 7. As shown in Figure A-23, enter an appropriate description or identification for this
estimate, including the key assumptions and a new solution title. Click the Return button
when finished.

Tip: A recent enhancement to WLE provides a choice between placing the estimation
identification on a separate page in the WLE output or at the top of the WLE results.

Figure A-23 WLE for OSTI - Estimation Identification

532 Domino 6 for iSeries Best Practices Guide

8. The Basic Workload Selection window appears as shown in Figure A-24. Notice the new
solution title of “OSTI, Inc”. Click Next.

Figure A-24 WLE for OSTI - changed Basic Workload Selection window

9. Click Domino #1. The Domino #1 workload window appears (compare to Figure A-9 on
page 516). Click Domino #1 again to change the Domino workload title to something
more descriptive.

Appendix A. Quickstart to IBM Eserver Workload Estimator 533

 10.Change the Domino #1 title to a more meaningful one, like “Notes mail (100MB)” as
illustrated in Figure A-25. Since this is a mail workload and no clustering is involved, leave
the Applications and Inbound Cluster Replication boxes empty. Click Next.

Tip: Although the default of Domino 6 is used in this example, it is important to note that
WLE currently estimates any Domino R5 based recommendations according to data
derived from Domino 5.0.12 benchmarks. If you run an earlier release of Domino R5, your
CPU utilization may be 10% to 20% higher, particularly if you are running it on a POWER4
based iSeries (i825, i870, i890) system. Domino 5.0.12 has changes in it which optimize its
performance on a POWER4 processor.

Figure A-25 WLE for OSTI - Notes mail (100MB) title

534 Domino 6 for iSeries Best Practices Guide

11.As shown in Figure A-26, enter the appropriate parameters to define the “Notes mail
(100MB)” workload. This workload needs to match the customer supplied information
such as 4000 Lotus Notes client users, 40% peak mail user concurrency, transaction
logging factor, 80% moderate/20% heavy user type and an antivirus protection factor of
15. Since we are considering dual iSeries systems, we assume that the 4000 Notes mail
users will be split equally across the two systems. In addition, given they plan on
transplanting their existing Domino mail servers, we need to change the number of
partitions from *CALC to 2 as illustrated in the solution diagram in Figure A-20 on
page 529. Click Next when finished.

Tip: As described in the WLE online help, transaction logging can be set to favor runtime,
favor restart recovery or standard, with each having its own impact on CPU. Online
incremental Domino server backups via BRMS require the use of transaction logging; in
addition, “favor runtime” is usually recommended. In this case, since the plan is to use
BRMS for online incremental Domino server backups, we’ve rounded up the transaction
logging factor to 15. As documented in the WLE online help, a general guideline for “favor
runtime” transaction logging is from 10 to 12. The online help also states that this factor
represents the relative amount of CPU resource to be added for transaction logging.

Figure A-26 WLE for OSTI - Notes mail (100MB) parameters

Appendix A. Quickstart to IBM Eserver Workload Estimator 535

 12.As you just did for the first mail workload, make similar changes to the title of the
Domino #2 workload for the second set of mail users (those with 300 MB mail file sizes).
Then enter the associated parameters so that they match the customer’s planned Domino
for iSeries environment as described in “Customer example: 10,000 Domino users” on
page 526. See Figure A-27 for the completed workload definition. Scroll to the bottom of
the window and click Next.

Figure A-27 WLE for OSTI - Notes mail (300MB) workload

536 Domino 6 for iSeries Best Practices Guide

13.Since Domino clustering is being used for the third group of mail users, this mail workload
definition is different from the first two just defined. As shown in Figure A-28, check the box
next to Inbound Cluster Replication. The Mail selection box should already be check
marked. Click Next.

Figure A-28 WLE for OSTI - Mail workload with Inbound Cluster Replication

Appendix A. Quickstart to IBM Eserver Workload Estimator 537

 14.Again, change the title of the Domino #3 workload for the third set of mail users (those with
600 MB mail file sizes). Then enter the associated parameters so that this workload
matches the customer’s planned Domino for iSeries environment as described in
“Customer example: 10,000 Domino users” on page 526. See Figure A-29 for the
completed workload definition. Click Next.

Important: Since this is the group of mail users who are currently using Domino clustering,
select To a different system for item 6 which asks “How are you implementing clustering
for this mail workload?”. See Figure A-29.

Figure A-29 WLE for OSTI - Notes mail (600MB) workload

538 Domino 6 for iSeries Best Practices Guide

15.Since we had selected Inbound Cluster Replication for this mail workload (refer back to
Figure A-28 on page 537), we must enter the correct parameters to reflect this incoming
replication workload from the 1000 clustered mail users on the other iSeries system. This
is shown in Figure A-30. Click Next.

Tip: In item 2 of the Inbound Cluster Replication attributes (see Figure A-30), the “percent
of inbound cluster replication mail users active” refers to those clustered mail users on the
other system (iSeries #2) who are generating replication traffic coming into this system
(iSeries #1) during normal operations (both iSeries systems are available during normal
operations). Also, when WLE calculates its recommendations, it will include another
partition for the Domino server handling the incoming cluster replication workload.

Figure A-30 WLE for OSTI - Inbound Cluster Replication

Appendix A. Quickstart to IBM Eserver Workload Estimator 539

 16.On the Domino #4 workload panel change the title to “iNotes Web Access” and enter the
appropriate parameters to match this customer’s information, as shown in Figure A-31.
Since these are new Domino Web Access (iNotes Web Access) users, we use the agreed
upon user concurrency rate of 15%.
The default concurrency rates used by WLE are found in the online help. To display online
help for a certain topic, click on the appropriate link, for example click the word
Concurrent behind item #2. When finished, close the help window and then click Next to
go to the next workload.

Figure A-31 WLE for OSTI - iNotes Web Access workload

540 Domino 6 for iSeries Best Practices Guide

17.On the next Domino workload window, change the title to “Sametime chat”, select
Applications and deselect Mail as shown in Figure A-32. Click Next.

Figure A-32 WLE for OSTI - Sametime chat workload

Appendix A. Quickstart to IBM Eserver Workload Estimator 541

 18.Enter the appropriate parameters for the planned “Sametime chat” workload as shown in
Figure A-33. To match the customer’s Domino environment, change the type of application
access to Notes and change the application type to Sametime - Chat.

Note: “Sametime - Chat” has been renamed to “Sametime Instant Messaging” in the
October 2003 update of WLE.

Given that this will be a new workload and the customer has estimated the concurrency at
about 15% for the new chat users, let’s leave the default of 15%. As described before in
the solution diagram (Figure A-20 on page 529), we also enter 3000 users and change the
number of partitions to 1 for this workload. Click Next.

Figure A-33 WLE for OSTI - Sametime chat workload definition

542 Domino 6 for iSeries Best Practices Guide

19.As shown in Figure A-34, change the workload title to “Domino appl’ns”, select the
Applications box and deselect Mail. Click Next.

Figure A-34 WLE for OSTI - Domino appl’ns workload

Appendix A. Quickstart to IBM Eserver Workload Estimator 543

 20.Define the “Domino appl’ns” workload as illustrated in Figure A-35 on page 544. We enter
parameters which match the customer provided information as listed in “Customer
example: 10,000 Domino users” on page 526. A very important parameter, which was
discussed with the customer, is the application rating. Also, we assume here that the total
150 GB of disk used for applications is split equitably across each of the two iSeries
systems. Therefore the amount of disk storage entered is 75,000 MB. Click Next.

Figure A-35 WLE for OSTI - Domino appl’ns workload definition

544 Domino 6 for iSeries Best Practices Guide

21.As shown in Figure A-36, WLE presents the Selected System window which includes an
immediate and a growth solution. However, since this growth solution reflects a 50%
growth rate, we need to change the rates to the customer requested 20% for all workloads
except for Domino Web Access (iNotes Web Access). To change the growth rate, click the
link here in the phrase “Growth trends can be changed here” located under the Growth
Solution title.

Figure A-36 WLE for OSTI - Selected System solutions

Appendix A. Quickstart to IBM Eserver Workload Estimator 545

 22.In the Selected System Workload Growth Factors window, change all of the workloads
from 50% to 20%, except for the Domino Web Access (iNotes Web Access) workload
which the customer said will have no growth. Now your WLE window looks like
Figure A-37. Click Save.

Figure A-37 WLE for OSTI - Selected System Workload Growth Factors

546 Domino 6 for iSeries Best Practices Guide

23.WLE now presents an updated Selected System results window, shown in Figure A-38. It
reflects the changed workload growth percentages just entered.
It is important to note that the WLE solutions in Figure A-38 on page 547 reflect normal
operations rather than a fail over mode situation.

Figure A-38 WLE for OSTI - Selected System (Normal Operations)

24.At this point, we save the workloads defined and create a pdf of the WLE results which
reflect a normal operations scenario by using the options in the left hand navigation frame.
25.In addition to the initial estimate, we must use WLE to show the estimated resources
required when operating in a fail over mode, or when one of the iSeries systems is
unavailable due to an unplanned (or planned) downtime. Therefore we need to make an
adjustment to the clustered environment to depict what happens if all 2000 clustered mail
users (with 600 MB mail files) are being serviced by one of the two iSeries systems.

Appendix A. Quickstart to IBM Eserver Workload Estimator 547

 Click on Navigation -> Workload Selection (see Figure A-39) and change the estimation
identification entered in step 7 on page 532 to reflect a fail over mode scenario. Then click
Next to progress through WLE until the previously defined “Notes mail (600MB)”
workload appears.

Note: Although an unplanned downtime may obviously occur at any time, a planned
downtime would normally be scheduled to occur during non-prime or non-peak periods.

Figure A-39 WLE for OSTI - Navigate->Notes mail (600MB) workload

548 Domino 6 for iSeries Best Practices Guide

26.In the Notes mail (600MB) workload window, deselect Inbound Cluster Replication (see
Figure A-40). This is necessary because in a fail over mode, there would be no replication
traffic coming into the first iSeries from the second iSeries system. Click Next.

Figure A-40 WLE for OSTI - deselect Inbound Cluster Replication

Appendix A. Quickstart to IBM Eserver Workload Estimator 549

 27.As shown in Figure A-41, change the number of users from 1000 to 2000 and change
clustering to “None”. These changes are needed to reflect a fail over environment, during
which all 2000 clustered mail users are handled by one of the two iSeries. Also, change
the number of partitions from 1 to 2. This is to account for the previous Domino partition
(for clustering) which WLE will no longer automatically include since we deselected
Inbound Cluster Replication. Click Next.

Figure A-41 WLE for OSTI - changed Notes mail (600MB) workload

550 Domino 6 for iSeries Best Practices Guide

28.Continue going through the other WLE workload definition panels as they are presented
by clicking Next. The updated WLE Selected System results window appears as
illustrated in Figure A-42.

Figure A-42 WLE for OSTI - Selected System solutions (fail over mode)

Appendix A. Quickstart to IBM Eserver Workload Estimator 551

 29.In the left frame, click File -> PDF and the WLE results appear in pdf format as shown in
Figure A-43. This pdf can be printed, saved and e-mailed as appropriate. Click the Back
button in your browser to return to the WLE Selected System window after reviewing the
results. For details on interpreting the WLE results, please see “Understanding the WLE
results” on page 491. Alternatively, click Help -> Estimator Results in the WLE navigation
frame.

Tip: In most cases, do not use your browser’s back button since doing so will circumvent
WLE’s built-in navigation. This prevents WLE from validating current data entered on the
window and as a result, WLE may exhibit navigation or other error messages. To prevent
this behavior, always use the navigation arrows within the WLE windows. An exception to
this rule is if a pdf of the results has just been created and a return to WLE is desired.

Figure A-43 WLE for OSTI - PDF of WLE results (fail over mode)

552 Domino 6 for iSeries Best Practices Guide

30.Since it is always possible that we may need to later revise one or more of the parameters
in this Workload Estimator estimate, let’s save all of the definitions just created. In the left
hand frame of the window, like the one shown in Figure A-44, click on File -> Save All
Workloads. In the File download window, click Save. In the resulting Save As window,
enter a file name like “WLE for OSTI Dual 870s fail over mode.xml” and then click Save.
This saved WLE file may be restored later by going back into WLE by using the File and
Restore options in the left hand navigation frame of WLE.

Tip: At the time of writing, there is an intermittent problem with saving and restoring WLE
workloads. This problem may occur when you attempt to save WLE workloads and you
have entered an estimation identification. An indicator of the problem is a WLE saved file
which has a 0 KB size. As a result, it cannot be restored since no WLE data was actually
saved. However, this problem is planned to be fixed in the next version of WLE.

Figure A-44 WLE for PAG - Save All Workloads

Appendix A. Quickstart to IBM Eserver Workload Estimator 553

 Changing a saved estimate
As it often happens, the WLE estimate we worked on must be changed. In this example, the
customer has decided that they want to see the estimated impact of putting a few
test/development Domino servers in an LPAR (logical partition) on one of the iSeries. In
addition, they want two other LPARs, one for the managing partition (partition controller) and
one for the production Domino servers. Given this request, let’s first modify the initial high
level diagram so that it reflects the addition of logical partitioning. The new diagram is shown
in Figure A-45.

iSeries #1 iSeries #2
LPAR 1 (Managing Partition)

LPAR 2 (Domino Production)

2000 mail users (100MB) 2000 mail users (100MB)

(2 DPARs) (2 DPARs)

2000 mail users (300MB) 2000 mail users (300MB)

(2 DPARs) (2 DPARs)

1000 (clustered) mail DPAR for clustered 1000

users (600MB) mail users from iSeries #1
Domino clustering
(1 DPAR)
1000 (clustered) mail
DPAR for clustered 1000 users (600MB)
mail users from iSeries #2 (1DPAR)

2000 Domino application 2000 Domino application

users (5 DPARs) users (5 DPARs)

New 1000 iNotes Web New 1000 iNotes Web

Access users (1 DPAR) Access users (1 DPAR)

New 3000 Sametime chat New 3000 Sametime chat

users (1 DPAR) users (1 DPAR)

LPAR 3
(Domino Development/Test)

Figure A-45 OSTI - Modified high level diagram of potential solution

1. Start a browser session and go to the WLE Web site:

http://www.ibm.com/eserver/iseries/support/wle/EstimatorServlet

554 Domino 6 for iSeries Best Practices Guide

2. After accepting the WLE terms and conditions, click on File -> Restore in the left hand
navigation frame of WLE as shown in Figure A-46.

Figure A-46 WLE for OSTI - File -> Restore

3. The Restore Saved Estimation window appears (see Figure A-47). Click Browse.

Figure A-47 WLE for OSTI - Restore Saved Estimation

Appendix A. Quickstart to IBM Eserver Workload Estimator 555

 4. Use the Choose File dialog box to select your file and click Open. Your file now appears in
the Restore Saved Estimation window (see Figure A-48). There are no current workloads
defined so click Restore into a New Estimation.

Figure A-48 WLE for OSTI - Restore saved estimation

556 Domino 6 for iSeries Best Practices Guide

5. After it is restored, the Basic Workload Selection window appears (see Figure A-49).

Figure A-49 WLE for OSTI - Basic Workload Selection (after restoring saved WLE file)

6. Click the Expert View button and the Expert Workload Selection window (shown in
Figure A-50) appears. Since we need to add logical partitioning to this estimation, click the
System #1 link.

Appendix A. Quickstart to IBM Eserver Workload Estimator 557

 Figure A-50 WLE for OSTI - Expert Workload Selection

7. As shown in Figure A-51, change the LPAR status from “None” to “Shared”. Click Return.

Figure A-51 WLE for OSTI - change LPAR Status

558 Domino 6 for iSeries Best Practices Guide

 Selecting Shared LPAR tells WLE that it can size each logical partition to incremental
portions of a processor. This results in a Partition Controller (managing) partition being
added as shown in Figure A-52.

Tip: It is helpful to read through the WLE online tutorial which discusses OS/400 logical
partitioning (LPAR). It can be opened by clicking File -> Tutorials -> Logical Partitioning
in the left hand navigation frame of WLE.

8. In the Expert Workload Selection window, click Add Partition for System #1. A new logical
partition, Main #3 is added as shown in Figure A-52. Let’s add a workload to this new
partition which reflects the customer’s desired Domino test and development environment.
Click Add Workload.

Figure A-52 WLE for OSTI - add logical partition

Appendix A. Quickstart to IBM Eserver Workload Estimator 559

 9. A panel, like the one shown in Figure A-53 appears. Click Domino Workload.

Figure A-53 WLE for OSTI - add Workload to new LPAR

560 Domino 6 for iSeries Best Practices Guide

10.A new Domino workload, Domino #7 is added to our Main #3 LPAR (see Figure A-54).
Let’s change Main #3 to a more descriptive LPAR title. Click the Main #3 link.

Figure A-54 WLE for OSTI - add new Domino workload to LPAR

Appendix A. Quickstart to IBM Eserver Workload Estimator 561

 11.In the next WLE window, click Main #3 again and enter “Domino Dev/test”. Click Return.
Similarly, change the Main #1 title to “Domino Prod”. The Expert Workload Selection
window now displays the changed LPAR titles (see Figure A-55). Click Next.

Figure A-55 WLE for OSTI - change names of logical partitions

562 Domino 6 for iSeries Best Practices Guide

12.Proceed through the previously defined Domino workloads. The Partition Controller
workload panel appears (see Figure A-56). Click Next to display the Domino #7 workload.

Figure A-56 WLE for OSTI - Partition Controller workload

13.As illustrated in Figure A-57, change the planned usage for this workload instance to
Applications only. Also, change the title from Domino #7 to “Domino dev/test”. Click Next.

Figure A-57 WLE for OSTI - define Domino #7 workload

Appendix A. Quickstart to IBM Eserver Workload Estimator 563

 14.Enter the appropriate parameters for this Domino development/test workload as illustrated
in Figure A-58. In our example, the customer has indicated that their test Domino partition
sizing estimate should reflect 100 users with an application rating of 9 and a peak user
concurrency of 20%. In addition, light DB2 access will be used and about 10 GB of disk
space will be needed. The customer has also indicated that they may configure 2 Domino
partitions in this test LPAR, so change the number of Domino partitions to 2. Click Next.

Figure A-58 WLE for OSTI - define new Domino dev/test workload

564 Domino 6 for iSeries Best Practices Guide

15.WLE displays the recommendations as shown in Figure A-59.

Figure A-59 WLE for OSTI - initial results after adding LPAR

Appendix A. Quickstart to IBM Eserver Workload Estimator 565

 16.However, we need to change the growth rate for the new workload. To change the growth
rate, click the link here in the phrase “Growth trends can be changed here” located under
the Growth Solution title. Change the growth rate for the Domino dev/test workload to 20%
as shown in Figure A-60 because the customer requested that the 20% growth rate shall
also be used for this workload. Click Save.

Figure A-60 WLE for OSTI - change growth rate

566 Domino 6 for iSeries Best Practices Guide

17.WLE updates its recommendations to reflect the changed growth rate as shown in
Figure A-61.

Figure A-61 WLE for OSTI - Selected System after changing growth rate

Appendix A. Quickstart to IBM Eserver Workload Estimator 567

 18.In the left frame, click File -> PDF to save the WLE results in pdf format as shown in
Figure A-62.

Figure A-62 WLE for OSTI - results with LPARs - pdf format

19.Click the Back button in your browser to return to the WLE Selected System window after
reviewing the results. For details on interpreting the WLE results, please see
“Understanding the WLE results” on page 491. Alternatively, click Help -> Estimator
Results in the WLE navigation frame.

Tip: In most cases, do not use your browser’s back button since doing so will circumvent
WLE’s built-in navigation. This prevents WLE from validating current data entered on the
window and as a result, WLE may exhibit navigation or other error messages. To prevent
this behavior, always use the navigation arrows within the WLE windows. An exception to
this rule is if a pdf has just been created and a return to WLE is desired.

568 Domino 6 for iSeries Best Practices Guide

 Since we have added LPARs to this WLE estimation, the results now also include a
section describing the LPARs (see Figure A-63). Also, although not shown in Figure A-62
on page 568, the estimation identification could have been changed to indicate the
addition of logical partitioning to one of the two iSeries.

Figure A-63 WLE for OSTI - Immediate Solution LPAR Information

Appendix A. Quickstart to IBM Eserver Workload Estimator 569

 Continue scrolling through the pdf file to see the Growth Solution Logical Partition
Information as shown in Figure A-64.

Figure A-64 WLE for OSTI - Growth Solution LPAR Information

570 Domino 6 for iSeries Best Practices Guide

 The WLE results also include a useful comments section on the immediate and growth
solutions. The Growth Solution comments are illustrated in Figure A-65.

Figure A-65 WLE for OSTI - Growth Solution comments

This illustrates how easy it is to restore a saved WLE file and modify it to produce a sizing
estimate which reflects a different assumption or requirement such as logical partitioning.

Tip: As described in the sizing tip number 9 on page 459, it is recommended that a check
be done of the Workload Estimator’s recommended number of processors with the
customer’s existing Domino environment. Although there are no definitive ratio guidelines,
it is important to ensure that the WLE results make sense.

For example, if the Domino customer currently has 100 Intel processors and WLE is
recommending a single 8-way iSeries to replace 100 Intel processors, then it is advisable
to review the customer data and WLE workload definitions again. In addition, although
MHz are only part of a system’s overall performance capabilities, it is suggested that the
total number of MHz consumed during the representative peak period (from the created
server characteristics table) be compared with the WLE’s recommended systems’ total
MHz capability. Do not forget to factor in target processor utilization percentages.

Appendix A. Quickstart to IBM Eserver Workload Estimator 571

572 Domino 6 for iSeries Best Practices Guide
 B

Appendix B. Information to collect for Domino

troubleshooting
In this appendix we provide you with a list of data that can be gathered to assist Lotus
Support in debugging three different problems. The three problems listed in this appendix
were chosen because some of the information collected is specific to the iSeries platform.
The data mentioned in this appendix represents a starting point. Lotus Support may request
additional data later if required.

It is recommended that you track any problems in your Domino environment. Create a
database or paper form that contains information like: Name of the Domino server that had a
problem, date that the problem occurred, time that the problem occurred, type of problem
(crash, hang, high CPU, etc.), number of incident opened with Lotus Support (if you open an
incident), data gathered, solution to the problem.You may also want to keep the information
listed in this appendix in the same place as your tracking data, that way you do not have to
refer back to this appendix when a problem occurs.

In this appendix, we cover:

򐂰 “Domino hangs” on page 574
򐂰 “Domino server crashes” on page 581
򐂰 “High CPU utilization in Domino job(s)” on page 583

Note: Most of the commands listed in this appendix generate spooled files. Spooled files
can be located via several different methods. The two most common methods are the Work
Job (WRKJOB OPTION(*SPLF)) command from a 5250 emulation screen and the Basic
Operations section of the iSeries Navigator.

The iSeries Navigator allows you to drag and the spooled files from the iSeries to your PC.
However, you must sign on to iSeries Navigator using the same user profile you generated
the spooled files with in order to find the files under the Basic Operations section.

The spool files are located under Basic Operations -> Printer Output in iSeries
Navigator.

© Copyright IBM Corp. 2004. All rights reserved. 573

Domino hangs
For the purpose of this appendix, we break the Domino hangs section up into two parts. The
first segment covers server hangs, please refer to “Domino server hangs” on page 574. The
second segment covers HTTP hangs, please see “Domino HTTP hangs” on page 578.

Notes:
򐂰 Domino hangs are notoriously difficult to debug after the Domino server has been
restarted. When the Domino server is restarted, most of the data required to debug the
problem is gone. We strongly recommend that you report the problem to Lotus Support
while it is occurring. If you cannot, then gather the information listed in this section and
Lotus Support will attempt to debug the root cause from this data.
򐂰 Occasionally, Lotus Support may require additional debug turned on to find the root
cause of a Domino server hang or Domino HTTP hang. If this is the case, you must set
the debug and wait for the next hang to occur to capture data. Listed below are some of
the most common debug parameters used. In general you should not set these
parameters without a Lotus Support analyst’s recommendation. Some of these
parameters output a lot of data and should only be enabled when debugging a specific
problem.
SERVER:
Debug_Capture_Timeout=10
Debug_Show_Timeout=1
DEBUG_THREADID=1
HTTP:
HTTPEnableThreadDebug=1 (for the default level)
HTTPEnablePostDataLogging=1 (for client POST data)
HTTPEnableResponseContentLogging=1 (for server response data)
AMGR:
Debug_AMGR=*
LDAP:
LDAPDebug=7
MAIL (both SMTP and NRPC):
DebugRouter=3
SMTPDebug=4
SMTPDebugIO=3 (for debugging inbound SMTP mail problems)
SMTPClientDebug=1 (for debugging outbound SMTP mail problems)
Log_MailRouting=40

Domino server hangs

What is a Domino server hang?

We define a Domino Server hang as the situation when the Domino jobs are still running in
the Domino subsystem, but a Lotus Notes client(s) cannot connect to the Domino server. This
may encompass more than Lotus Notes clients, but the minimum is that Lotus Notes clients
cannot connect to the server.

574 Domino 6 for iSeries Best Practices Guide

Data to gather while a Domino server hang is occurring
The following checklist gives data that must be gathered while the hang is actually happening.
1. Print out information about the jobs currently active on the iSeries:
WRKACTJOB OUTPUT(*PRINT)
This command generates a spooled file called QPDSPAJB.
2. Gather system status information using the following command:
WRKSYSSTS OUTPUT(*PRINT)
This command generates a spooled file called QPDSPSTS.
3. Gather information about TCP/IP connections to the iSeries:
NETSTAT *CNN
Press F6 to print the information on the Work with TCP/IP connect status screen.
This command generates a spooled file called NETSTAT.
4. Run the following Domino console commands. Issue the WRKDOMCSL
SERVER(<servername>) command to access the Domino console. Be aware, the Domino
console may not be responsive. If that is the case, you will not be able to gather this data.
SHOW TASKS
SHOW USERS
SHOW STAT
Press F5 to refresh the screen and see the output from the commands you ran. Then
press F6 to print the information that is currently shown on the Domino console screen.
F6 generates a spooled file called QSYSPRT.
5. Dump the Domino server call stacks:
DMPSVRSTKS SERVER(servername)
This command generates several spooled files all called QSYSPRT.

Attention: The DMPSVRSTKS command is not shipped with Domino 6.0.2 CF1 or
OS/400 V5R2M0. To get this command, you must download the DMPSVRSTKS
application available at:
http://www.ibm.com/servers/eserver/iseries/domino/devtools/dmp/

and load it on your iSeries. This application will also function with earlier releases of
Domino.

Data to gather after the Domino server is restarted

The information listed below can be gathered after you restart the Domino server.
1. Collect the iSeries system history log (QHST):
DSPLOG OUTPUT(*PRINT)
This command generates a spooled file called QPDSPLOG.
2. Gather the iSeries system operator message queue:
DSPMSG MSGQ(QSYSOPR) OUTPUT(*PRINT)
This command generates a spooled file called QPDSPMSG.

Appendix B. Information to collect for Domino troubleshooting 575

 3. Generate a list of the program temporary fixes (PTFs) installed on the iSeries:
DSPPTF OUTPUT(*PRINT)
This command generates a spooled file called QSYSPRT.
4. Make a copy of LOG.NSF for the server that was hanging:
Open the LOG.NSF of the Domino server that hung using a Lotus Notes client. Then issue
File -> Database -> New Copy (make sure you change the file name to something other
than LOG.NSF).
5. Make a copy of the NOTES.INI file for the server that was hanging:
Use the CPY command to make a copy of the NOTES.INI somewhere outside of the
Domino data directory. (Do not put the copy in the root ‘/’ of the IFS.)
6. Print out any licensed internal code logs (VLOGs) from the time of the hang:
a. Start the system service tools using the following command:
STRSST
b. Enter your SST user ID and password.
c. Select option 1 to Start a service tool.
d. Select option 5 for the Licensed Internal Code Log.
e. Select option 2 to Dump Entries to Printer from the Licensed Internal Code log.
i. Set Dump option to 3 for Header and entire entry.
ii. Leave the Entry ID and Entry type as the defaults.
iii. Change the Starting Date/Time to one hour before the hang started.
iv. Change the Ending Date/Time to the time the Domino server was restarted, see
Figure B-1.
v. Press the Enter key.
f. A message will be posted to the bottom of the screen to identify the Print dump
request.
g. Press F12 once to return to the Licensed Internal Code Log screen.
h. Select option 7 to Display the status of the Licensed Internal Code log.
i. Do not exit the system service tools until the field Dump requests not complete field
equals zero.
i. These steps generate a spooled file called QPCSMPRT.

576 Domino 6 for iSeries Best Practices Guide

 Dump Entries to Printer from Licensed Internal Code Log

Type choices, press Enter.

Dump option . . . . . . . . . . . 3 1=Header

2=Header and note entry
3=Header and entire entry
Entry ID:
Starting . . . . . . . . . . . 00000000 00000000-FFFFFFFF
Ending . . . . . . . . . . . . FFFFFFFF 00000000-FFFFFFFF

Entry type:
Major code . . . . . . . . . . 0000 0000-FFFF
Minor code . . . . . . . . . . 0000 0000-FFFF

Starting:
Date . . . . . . . . . . . . . 08/04/03 MM/DD/YY
Time . . . . . . . . . . . . . 11:30:00 HH:MM:SS
Ending:
Date . . . . . . . . . . . . . 08/04/03 MM/DD/YY
Time . . . . . . . . . . . . . 15:00:00 HH:MM:SS

F3=Exit F12=Cancel

Figure B-1 Fields to fill in on Dump Entries to Printer from Licensed Internal Code Log Screen

7. Gather semaphore debug output if available.

To receive the output of the semaphore debug, a file is provided called SEMDEBUG.TXT.
It is located in the IBM_TECHNICAL_SUPPORT subdirectory of the Domino data
directory.
If the file is empty, then you probably do not have semaphore debug turned on. If you are
experiencing occasional server hangs, then you should turn on semaphore debug so you
can capture this data on a future hang.
To turn on semaphore debug, you must have the following NOTES.INI parameters set:
a. Debug_Capture_Timeout=10
b. Debug_Show_Timeout=1
c. DEBUG_THREADID=1

Note: These parameters require a Domino server restart to take effect. These
parameters should not impact performance on your Domino server. Monitor the size
of the SEMDEBUG.TXT file and delete the file if it gets too large (you can delete the
file while the Domino server is active, but do not delete it if a Domino server hang is
currently occurring).

Questions to answer to help narrow down the cause of the hang

Consider the following questions. They help narrow down the cause of a Domino server hang.
1. Which server hung? What time did the hang start?
2. Who is the hang impacting? All users? One user? Every user in one office? Etc.
3. Which clients are failing to connect to the Domino server due to the hang? Lotus Notes
clients? Web Browsers? IMAP Clients? Etc.

Appendix B. Information to collect for Domino troubleshooting 577

 4. Which database(s) cannot be opened because of the Domino server hang? All
databases? One database? Etc.
5. Is anything other than Domino affected? TELNET? FTP? Etc.
6. Are there any Notes System Diagnostics (NSD) files prior to the hang? (Do not go back
further than 24 hours before the hang started. If there are NSDs, include them with the
rest of the data for Lotus Support.)
7. Were any Domino jobs taking more CPU than normal?

Domino HTTP hangs

What is a Domino HTTP hang?

A Domino HTTP hang is when the Domino HTTP job is still running in the Domino subsystem,
but a Web browser cannot connect to the Domino server. Usually, this type of hang will only
affect Web browsers and other clients can connect fine. If the hang affects Lotus Notes
clients, then it is a Domino Server Hang, not a Domino HTTP hang.

Data to gather while a Domino HTTP hang is occurring

The data listed below must be gathered while the hang is actually happening, not after the
restart.
1. Print out information about the jobs currently active on the iSeries:
WRKACTJOB OUTPUT(*PRINT)
This command generates a spooled file called QPDSPAJB.
2. Gather system status information using the following command:
WRKSYSSTS OUTPUT(*PRINT)
This command generates a spooled file called QPDSPSTS.
3. Gather information about TCP/IP connections to the iSeries:
NETSTAT *CNN
Press F6 to print the information on the Work with TCP/IP connect status screen.
This command generates a spooled file called NETSTAT.
4. Run the following Domino console commands. Issue the WRKDOMCSL SERVER(servername)
command to access the Domino console. Be aware, the Domino console may not be
responsive. If that is the case, you will not be able to gather this data.
SHOW TASKS
SHOW USERS
SHOW STAT
TELL HTTP SHOW THREAD STATE
Press F5 to refresh the screen and see the output from the commands you ran.
Next press F6 to print the information that is currently shown on the Domino console
screen.
The F6 generates a spool file called QSYSPRT.
5. Dump the Domino server call stacks:
DMPSVRSTKS SERVER(servername)
This command generates several spooled files all called QSYSPRT.

578 Domino 6 for iSeries Best Practices Guide

 Attention: The DMPSVRSTKS command is not shipped with Domino 6.0.2 CF1 or
OS/400 V5R2M0. To get this command, you must download the DMPSVRSTKS
application available at:
http://www.ibm.com/servers/eserver/iseries/domino/devtools/dmp/

and load it on your iSeries. This application will also function with earlier releases of
Domino.

6. Dump information about the Java Virtual Machine (JVM) for the HTTP job:
DMPJVM JOB(xxxxxx/QNOTES/HTTP)
Where xxxxxx is the six digit job number for the Domino HTTP job.
This command generates a spooled file called QDMPJVM.

Data to gather after the Domino server is restarted due to the hang
The information listed below can be gathered after you restart the Domino HTTP server.
1. Collect the iSeries system history log (QHST):
DSPLOG OUTPUT(*PRINT)
This command generates a spooled file called QPDSPLOG.
2. Gather the iSeries system operator message queue:
DSPMSG MSGQ(QSYSOPR) OUTPUT(*PRINT)
This command generates a spooled file called QPDSPMSG.
3. Generate a list of the program temporary fixes (PTFs) installed on the iSeries:
DSPPTF OUTPUT(*PRINT)
This command generates a spooled file called QSYSPRT.
4. Make a copy of LOG.NSF for the server that is hanging:
Open LOG.NSF of the Domino server that hung using a Lotus Notes client. Then issue
File -> Database -> New Copy (make sure you change the file name to something other
than LOG.NSF).
5. Make a copy of the NOTES.INI file for the server that is hanging:
Use the CPY command to make a copy of the NOTES.INI somewhere outside of the
Domino data directory. (Do not put the copy in the root ‘/’ of the IFS.)
6. Print out any licensed internal code logs (VLOGs) from the time of the hang:
a. Start the system service tools using the following command:
STRSST
b. Enter your SST user ID and password.
c. Select option 1 to Start a service tool.
d. Select option 5 for the Licensed Internal Code Log.
e. Select option 2 to Dump Entries to Printer from the Licensed Internal Code log.
i. Set Dump option to 3 for Header and entire entry.
ii. Leave the Entry ID and Entry type as the defaults.
iii. Change the Starting Date/Time to one hour before the hang started.

Appendix B. Information to collect for Domino troubleshooting 579

 iv. Change the Ending Date/Time to the time the Domino server was restarted.
Compare your entries with Figure B-1 on page 577.
v. Press the Enter key.
f. A message will be posted to the bottom of the screen to identify the Print dump
request.
g. Press F12 once to return to the Licensed Internal Code Log screen.
h. Select option 7 to Display the status of the Licensed Internal Code log.
i. Do not exit the system service tools until the field Dump requests not complete field
equals zero.
i. These steps generate a spooled file called QPCSMPRT.
7. Gather semaphore debug output if available.
To receive the output of the semaphore debug, a file is provided called SEMDEBUG.TXT.
It is located in the IBM_TECHNICAL_SUPPORT subdirectory of the Domino data
directory.
If the file is empty, then you probably do not have semaphore debug turned on. If you are
experiencing occasional server hangs, then you should turn on semaphore debug so you
can capture this data on a future hang.
To turn on semaphore debug, you must have the following NOTES.INI parameters set:
a. Debug_Capture_Timeout=10
b. Debug_Show_Timeout=1
c. DEBUG_THREADID=1

Note: These parameters require a Domino server restart to take effect. These
parameters should not impact performance on your Domino server. Monitor the size
of the SEMDEBUG.TXT file and delete the file if it gets too large. (You can delete the
file while the Domino server is active, but do not delete it if a Domino server hang is
currently occurring.)

Questions to answer to help narrow down the cause of the hang

Consider the following questions. They help narrow down the cause of a Domino HTTP hang.
1. What time did the hang start?
2. Who is the hang impacting? All users? One user? Every user in one office? Etc.
3. Which database(s) cannot be opened because of the Domino HTTP hang? All
databases? One database? Etc.
4. Is anything other than Domino affected? TELNET? FTP? Etc.
5. Are there any Notes System Diagnostics (NSD) files prior to the hang? (Do not go back
further than 24 hours before the hang started. If there are NSDs, include them with the
rest of the data for Lotus Support.)
6. Was the Domino HTTP job taking more CPU than normal?
7. Are any non-Domino products tied into the Domino HTTP job? WebSphere DSAPI filter?
iSeries HTTP Apache Server? Etc.
8. What is your Domino HTTP configuration? Virtual IP? Internet Sites Document (new with
Domino 6)? Web Realms? Multi-Server Session Authentication? Etc.

580 Domino 6 for iSeries Best Practices Guide

Domino server crashes
What is a Domino server crash?

A Domino server crash occurs when multiple Domino jobs end without a user issuing
ENDDOMSVR SERVER(servername) OPTION(*CNTRLD) on the iSeries command line or
QUIT in the Domino console. These two commands end the Domino server in a controlled
manner.

Note: The above commands can also be issued from a program without causing a Domino
server crash.

The following commands have been known to crash a Domino server if the proper steps have
not been taken:
򐂰 ENDJOB
Domino jobs do not correctly process the signal from an End Job (ENDJOB) command. If
you issue an ENDJOB against a single Domino job, it can crash the entire Domino server.
To correctly end a single Domino job, you must use the Domino console command TELL
JOBNAME QUIT (for example: TELL ROUTER QUIT).
򐂰 ENDSBS
The End Subsystem (ENDSBS SBS(sbsname)) command issues an ENDJOB command
against all the jobs running in the subsystem specified by the SBS parameter. As stated
previously, Domino jobs do not handle the ENDJOB command gracefully. You can safely
issue the ENDSBS command against a Domino subsystem if all the Domino jobs running
in that subsystem are already ended.
򐂰 PWRDWNSYS
You must end the Domino server in a controlled manner before issuing the Power Down
System (PWRDWNSYS) command. One of the commands that a PWRDWNSYS runs is
the ENDSBS command. As stated previously, if the Domino server is not already ended,
this ENDSBS will crash Domino.
򐂰 ENDDOMSVR with OPTION(*IMMED)
The *IMMED option should not be used unless the end Domino server (ENDDOMSVR
SERVER(servername) OPTION(*CNTRLD)) command failed to end the Domino server.
The reason for this is that the *IMMED option in the ENDDOMSVR command issues an
ENDSBS *IMMED. If the Domino jobs are still running, this ENDSBS *IMMED will crash
Domino.
򐂰 GO SAVE option 21
To run a complete system save, you go to the SAVE menu and take option 21. This can be
referred to as a GO SAVE option 21. This option issues an ENDSBS SBS(*ALL)
OPTION(*IMMED). As mentioned earlier, an ENDSBS will crash the Domino server if the
Domino jobs are not already ended. Therefore, you should end the Domino server in a
controlled manner before issuing the GO SAVE option 21.

Data to collect after a Domino server crash

Gather the information in the following list to debug the cause of a Domino server crash:
1. Collect any Notes System Diagnostics files (NSDs) that were generated from the crash.
NSDs are usually located in the Domino data directory which you can access with the
command WRKDOMSVR followed by entering option 12 in front of the appropriate
Domino server.

Appendix B. Information to collect for Domino troubleshooting 581

 If the Domino Server has crashed multiple times, send in all the NSDs for the past two
days and the current date.
If you want to learn how to read an NSD file, see Chapter 8 in the Redbook Lotus Domino
for AS/400: Problem Determination Guide, SG24-6051 which can be found at:
http://www.redbooks.ibm.com/redbooks/SG246051.html
2. Make a copy of the LOG.NSF for the server that crashed:
Using a Lotus Notes client, open the LOG.NSF of the Domino server that crashed. Then
issue File -> Database -> New Copy (make sure you change the file name to something
other than LOG.NSF).
3. Collect the iSeries system history log (QHST):
DSPLOG OUTPUT(*PRINT)
This command generates a spooled file called QPDSPLOG.
4. Gather the iSeries system operator message queue:
DSPMSG MSGQ(QSYSOPR) OUTPUT(*PRINT)
This command generates a spooled file called QPDSPMSG.
5. Generate a list of the program temporary fixes (PTFs) installed on the iSeries:
DSPPTF OUTPUT(*PRINT)
This command generates a spooled file called QSYSPRT.
6. Print out any licensed internal code logs (VLOGs) from the time of the crash:
a. Start the system service tools using the following command:
STRSST
b. Enter your SST user ID and password.
c. Select option 1 to Start a service tool.
d. Select option 5 for the Licensed Internal Code Log.
e. Select option 2 to Dump Entries to Printer from the Licensed Internal Code log.
i. Set Dump option to 3 for Header and entire entry.
ii. Leave the Entry ID and Entry type as the defaults.
iii. Change the Starting Date/Time to one hour before the crash occurred.
iv. Change the Ending Date/Time to 30 minutes after the server restarted. Compare
your entries with Figure B-1 on page 577.
v. Press the Enter key.
f. A message will be posted to the bottom of the screen to identify the Print dump
request.
g. Press F12 once to return to the Licensed Internal Code Log screen.
h. Select option 7 to Display the status of the Licensed Internal Code log.
i. Do not exit the system service tools until the field Dump requests not complete field
equals zero.
i. These steps generate a spooled file called QPCSMPRT.

582 Domino 6 for iSeries Best Practices Guide

 Questions to answer to help find the root cause of the server crash
Consider the following questions. They are helpful in finding the cause of a server crash:
1. What time did the Domino server crash? Or what time was the first crash in this sequence
of crashes?
2. Is the Domino server currently running? Or will the Domino server not start?
3. How many times has the Domino server crashed recently? In other words, how many
times has the Domino server crashed in the past week?
4. Has any maintenance (FIXUP/UPDALL/COMPACT) been run on the Domino server in the
past week?

High CPU utilization in Domino job(s)

This section will help you investigate the causes behind a CPU increase on your system.

Things to think about when investigating a CPU issue

The following questions will help you qualify what is happening to the CPU on your iSeries:
򐂰 Is the CPU higher than you expect? Or is the CPU higher than it used to be?
򐂰 What was the CPU like yesterday? Last week?
򐂰 Have you seen CPU spikes in (a) Domino job(s) previously? If so, which job and was there
any pattern? Same time of day? Same day of the week?
򐂰 The high CPU could be caused by a loop or by a large spike in the amount of work that a
job needs to process. For instance, if the ROUTER job starts taking a lot of CPU, the job
could be looping on a single piece of e-mail (which is a problem) or someone might have
just sent a mass mailing to 1000 users (which is normal because a mass mailing can
cause the CPU to spike while it is delivering the messages).

Steps to take to find the root cause of high CPU

The following steps will help you drill down the cause for the additional CPU on your system:
1. Start by determining the job(s) generating the extra CPU.
a. If you have the iSeries Performance Tools (5722-PT1) loaded on the system, you can
use the WRKSYSACT command. This command will list all jobs and tasks on the
iSeries in order of CPU percentage with the process taking the largest amount listed
first.
WRKSYSACT
Press the F10 key to refresh the statistics on the screen.
If the process taking the most CPU is always the same, then this could be the job
generating the excessive CPU.
Write down the job name, job user, and job number.
b. If you do not have the iSeries Performance Tools (5722-PT1) loaded on the system,
you can use the WRKACTJOB command to determine which jobs are taking large
amounts of CPU. The difference between WRKSYSACT and WRKACTJOB is that
WRKSYSACT will show both jobs and tasks. The WRKACTJOB command only shows
jobs.
WRKACTJOB

Appendix B. Information to collect for Domino troubleshooting 583

 Once you are on the Work with Active Jobs screen, sort the jobs by CPU so the jobs
taking the most CPU are at the top of the list. To do so:
i. Place the cursor on the CPU% column.
ii. Press the F16 key to sort the jobs by CPU.
iii. Press F10 to watch the CPU changing and check if the same job(s) are always at
the top of the list.
If the process taking the most CPU is always the same, then this could be the job
generating the excessive CPU.
Write down the job name, job user, and job number.

Important: You must use some judgement when trying to identify a problem job taking
too much CPU. For instance, if the UPDATE job always takes 25% of the CPU on your
system, it may be on the top of the list in WRKACTJOB or WRKSYSACT. But that may
be normal for your system. You may have to look at the second or third job in the list. If
the HTTP job is taking 20% of the CPU and it normally only takes 5%, then this might
be your problem job even though it is not the job with the highest CPU utilization on the
WRKACTJOB or WRKSYSACT screens.

2. Now that you have narrowed down the problem to a job(s), you must identify which
thread(s) in that job is generating the extra CPU:
a. Run the WRKACTJOB command and find the job you identified in step 1.
b. Enter 5 in front of that job and press Enter to work with the job information.
c. Take menu option 20 to display the threads in that job. If you are lucky, the job is single
threaded and you can continue with step 3. However, if there are multiple threads
running in this job, you must continue to check each individual thread to identify which
thread(s) is generating the extra CPU utilization.
i. Under normal conditions a thread can periodically be seen entering and exiting a
RUN status.
ii. The Total CPU column indicates how much time (in seconds) that particular thread
has been in the processor.

Note: The value in the Total CPU column does not directly relate to the CPU
percentage of the job.

iii. If a thread is generating most of the extra CPU utilization, then you may notice it has
a larger value in the Total CPU column than other threads. Or, you may notice that
the thread is constantly in a RUN status.
Remember, more than one thread may be responsible for the excess CPU.
iv. Write down the thread identifier for the thread(s) you believe may be responsible for
generating the extra CPU utilization.

584 Domino 6 for iSeries Best Practices Guide

3. Now that you have identified the job and the thread that may be generating the extra CPU,
you should look at the thread’s call stack and see if you can recognize what that thread is
doing:
a. Domino call stacks usually contain very long procedure names that may not be easily
readable. To make these names easier to read, you can use a special panel group that
is shipped with the Domino server product. This panel group will display longer
procedure names on the Display Call Stack screen. To use this panel group, follow the
steps listed below:
i. Use the Create Library (CRTLIB) command to create a new library:
CRTLIB LIB(NOTESSYS)
ii. Use the Create Duplicate Object (CRTDUPOBJ) command to make a copy of the
panel group in the new library you created:
CRTDUPOBJ OBJ(GWVJOB) FROMLIB(QNOTES) OBJTYPE(*PNLGRP) TOLIB(NOTESSYS)
NEWOBJ(QGWVJOB)
iii. Use the Change System Library List (CHGSYSLIBL) command to add the new
library to your library list. The new library must be listed before the QSYS library.
CHGSYSLIBL LIB(NOTESSYS)

Note: There are a few special things to be aware of when using the
CHGSYSLIBL command:
򐂰 The CHGSYSLIBL command is shipped with a Public = *EXCLUDE authority.
Therefore, only the security officer or a user profile with *ALLOBJ special
authority can use this command.
򐂰 The CHGSYSLIBL command only changes the system portion of the library
list for the job in which the command is entered - this will not change the
system portion of the library list for any other job on the iSeries.
򐂰 The panel group that is used for this function only works well with Domino
jobs. If you attempt to display the call stacks of non-Domino jobs while using
this panel group, you will get incomplete information. You must signoff and
sign back on or run the following command to correct this issue:
CHGSYSLIBL LIB(NOTESSYS) OPTION(*REMOVE)

b. If you are not already on the Work with Threads screen from step 2, then you must get
back to that screen. Run the WRKACTJOB command and find the job that is
generating the extra CPU. Enter 5 in front of that job and press Enter. Take menu
option 20 on the Work with Job screen to list the threads. Now you are back on the
Work with Threads screen.
c. To display a call stack, enter 10 in front of the thread(s) you identified in step 2 and
press Enter.
d. Review the procedures in the call stack and try to identify what that thread is doing.

Appendix B. Information to collect for Domino troubleshooting 585

 Display Call Stack
System: AS09
Job: SERVER User: QNOTES Number: 081142

Thread: 00000084
ILE ILE
Procedure Statement Module program
NSFNoteUpdateExtended2 0000000043 NTUPWRAP LIBNOTES
DbMonitorEvalNote 0000000596 MONITORS LIBNOTES
MonitorEvalNote__FP16DBCONTEXT_STRUCTUiUl9 0000000730 MONITORS LIBNOTES
NSFComputeMainFormula2 0000001431 CNSFWRAP LIBNOTES
Eval__7ComputeFv 0000001764 COMPUTE LIBNOTES
ComputeVariants__8RootNodeFv 0000001397 COMPNODE LIBNOTES
ComputeVariants__14AtFunctionNodeFv 0000001171 COMPNODE LIBNOTES
Execute__10AtAbstractFv 0000001813 ATABSTRACT LIBNOTES
Abstract 0000000001 ABSTRACT LIBNOTES
AbstractInternal 0000000008 ABSTRACT LIBNOTES
DoChunks 0000000005 ABSTRACT LIBNOTES
FindChunksInText 0000000021 CHUNK LIBNOTES
FindEndOfTextChunk 0000000034 CHUNK LIBNOTES
NextLine CHUNK LIBNOTES
Cstrpbrk 0000000004 CSTR LIBNOTES

Bottom
F3=Exit F10=Update stack F11=Display instruction F12=Cancel

Figure B-2 Example call stack

e. In the example call stack listed in Figure B-2, notice the DbMonitorEvalNote procedure
and the FindChunksInText procedure. Monitors are used for both kinds of mail rules -
mail rules that are set in an individuals’ mail file and mail rules that can be set for the
entire Domino server in the Domino 6 code. The procedure FindChunksInText sounds
like the thread is searching for something in the text of a document. This call stack is
telling you to look at mail rules (specifically, look for mail rules that may be searching
the body or subject of an e-mail for certain words or phrases).

Tip: Do not let call stacks scare you. Usually, some procedure in the call stack will tell
you what a particular thread is doing.

For example:
򐂰 UpdateFullTextIndex and FTIndexExt are both doing indexing work.
򐂰 ICConvertMIMEBody is converting a piece of e-mail.
򐂰 DoFreeTimeLookup is doing a freetime lookup in a calendar.

4. If you cannot identify the issue causing the excessive CPU at this point, then you need to
gather some information/traces while the problem is occurring and contact Lotus Support.

586 Domino 6 for iSeries Best Practices Guide

Data to gather while the CPU is running high on your system
1. Collect the joblog for the job(s) you identified in step 1:
DSPJOBLOG JOB(xxxxxx/user/jobname) OUTPUT(*PRINT)
Where xxxxxx is the six digit job number you found in step 1.
This command generates a spooled file called QPJOBLOG.
2. Make a copy of LOG.NSF for the server of the job taking the extra CPU.
Use a Lotus Notes client and open the LOG.NSF database of the Domino server
generating the high CPU utilization. Select File -> Database -> New Copy. Make sure you
change the new file name to something other than LOG.NSF.
3. Collect the iSeries system history log (QHST):
DSPLOG OUTPUT(*PRINT)
This command generates a spooled file called QPDSPLOG.
4. Gather the iSeries system operator message queue:
DSPMSG MSGQ(QSYSOPR) OUTPUT(*PRINT)
This command generates a spooled file called QPDSPMSG.
5. Generate a list of the program temporary fixes (PTFs) installed on the iSeries:
DSPPTF OUTPUT(*PRINT)
This command generates a spooled file called QSYSPRT.
6. Dump the call stack for the job taking the extra CPU:
DMPCLLSTK JOBNUMB(xxxxxx)
Where xxxxxx is the six digit job number you found in step 1.
This command generates a spooled file called QSYSPRT.

Attention: The DMPCLLSTK command is not shipped with Domino 6.0.2 CF1 or
OS/400 V5R2M0. To get this command, you must download the DMPCLLSTK
application available at:
http://www.ibm.com/servers/eserver/iseries/domino/devtools/dmp/

and load it on your iSeries. This application will also function with earlier releases of
Domino.

7. Gather information about TCP/IP connections to the iSeries:

NETSTAT *CNN
Press F6 to print the information on the Work with TCP/IP connect status screen.
This command generates a spooled file called NETSTAT.
8. Collect a TPROFS Performance Explorer Trace (PEX Trace):
a. Create a library to store the data in:
CRTLIB LIB(MYLIB)
b. Add a PEX definition that describes the data you want to collect:
ADDPEXDFN DFN(JOB1) TYPE(*TRACE) JOB((xxxxxx/user/jobname)) TASK(*NONE)
MAXSTG(100000) INTERVAL(5) TRCTYPE(*SLTEVT) SLTEVT(*YES) BASEVT(*PMCO)
Where xxxxxx is the six digit job number you found in step 1.

Appendix B. Information to collect for Domino troubleshooting 587

 Note: This PEX definition is only good while the job you specified in the JOB
parameter is running on the system. Once that job ends, this definition is useless.
You can delete the definition using the Remove PEX Definition command:
RMVPEXDFN DFN(JOB1).

c. Start the PEX trace:

STRPEX SSNID(TRACE1) DFN(JOB1)
Let the trace run for 5 - 6 minutes while the CPU is high.
d. End the PEX trace:
SBMJOB CMD(ENDPEX SSNID(TRACE1) DTALIB(MYLIB)) JOB(ENDPEX)
e. Wait for the batch job to end before proceeding with the next step. Verify the status of
the job using the following command:
WRKSBMJOB
Wait for the job called ENDPEX to have a status of OUTQ.
f. If you have the iSeries Performance Tools (5722-PT1) loaded on your system, then you
can print out the PEX report.
SBMJOB CMD(PRTPEXRPT MBR(TRACE1) LIB(MYLIB) TYPE(*PROFILE)
PROFILEOPT(*SAMPLECOUNT *PROCEDURE)) JOB(PRTPEX)
This command generates a spooled file called QPVPERPT in the batch job you
submitted. In this example, the batch job you submitted is called PRTPEX - use the
command WRKJOB JOB(PRTPEX) to find the spool file.
g. If you do not have the iSeries Performance Tools (5722-PT1) loaded on your system,
then send the library containing the data to Lotus Support.
In our example, that library is called MYLIB.

588 Domino 6 for iSeries Best Practices Guide

 C

Appendix C. Common configuration problems

that affect Domino performance
In this appendix we describe some common configuration problems that can affect Domino
performance. Most of the configurations described in this appendix relate specifically to the
iSeries.

The following configuration issues are discussed in this appendix:

򐂰 “Checksum” on page 590
򐂰 “Network routing - ARP storms” on page 593
򐂰 “Activity Level” on page 598
򐂰 “Daylight Savings Time” on page 600
򐂰 “Server based mail rules” on page 606

© Copyright IBM Corp. 2004. All rights reserved. 589

Checksum
This section describes an issue with the checksum feature when two different platforms
communicate using TCP/IP.

Summary of problem
A checksum is a count of the number of bits in a TCP or UDP packet that is included in the
header of the packet. It is included so that the receiver can check to see whether the same
number of bits that were sent arrived at the destination. If the counts match, then it is
assumed that the complete transmission was received. If the counts do not match, then the
packet must be sent again.

The count is not sent as a simple number. The count is hashed into a value that must be
decoded on the receiving system. This adds an extra check to confirm that the complete
contents of the packet were received.

Different platforms can use different algorithms to hash the checksum number. If the sending
platform and the receiving platform use different algorithms, it is possible that the receiving
system believes the checksum is incorrect even if it is not. This incorrect checksum will cause
the sending system to retransmit the packet. If enough packets need to be retransmitted, it
can affect the performance of the iSeries.

How to identify the problem

To identify this problem, you need to look for retransmissions of TCP packets.
Retransmissions are not supposed to be common, thus if most of your connections have
multiple retransmissions, then you may have a problem with the checksum.

Important: A problem with checksum is only one possible cause of retransmissions. There
are other network issues that can cause retransmissions.

There are two common ways to find retransmissions.

1. Check the TCP/IP Connection Status using the following command:
NETSTAT *CNN
Find connections in an Established status for the Lotus Notes client (local port 1352).
Type 5 in front of those connections and press Enter. Then page down until you see the
retransmission information as shown in Figure C-1.
You should check several different Established connections for local port 1352.

590 Domino 6 for iSeries Best Practices Guide

 Display TCP Connection Status
System: AS09
Retransmission information:
Total retransmissions . . . . . . . . . . . . : 22
Current retransmissions . . . . . . . . . . . : 8
Send window information:
Maximum size . . . . . . . . . . . . . . . . : 65340
Current size . . . . . . . . . . . . . . . . : 65340
Last update . . . . . . . . . . . . . . . . . : 3937272399
Last update acknowledged . . . . . . . . . . : 3647057150
Congestion window . . . . . . . . . . . . . . : 26160
Slow start threshold . . . . . . . . . . . . : 64240
Precedence and security:
Precedence . . . . . . . . . . . . . . . . . : 0
Initialization information:
Maximum segment size . . . . . . . . . . . . : 1452
Initial send sequence number . . . . . . . . : 1190807001
Initial receive sequence number . . . . . . . : 1189943001

Bottom
Press Enter to continue.
F3=Exit F5=Refresh F6=Print F8=Display jobs F9=Command line
F12=Cancel F14=Display port numbers F24=More keys

Figure C-1 Network retransmission information

2. Take a communications trace and look for retransmissions in a conversation:

a. Start the communications trace using the following command:
STRCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN) MAXSTG(16M) USRDTA(*MAX)

Notes:
򐂰 The CFGOBJ parameter is the name of an active line - check CFGTCP option 1.
򐂰 You may have to run a trace on each active line to look for this problem.
򐂰 Do not trace the LOOPBACK line.

b. Let the trace run for a few minutes and then end it using:
ENDCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN)
c. Print the communications trace with the command:
PRTCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN) CODE(*ASCII) FMTTCP(*YES) SLTPORT(1352)
FMTBCD(*NO)
Notice that you are formatting the trace for TCP/IP data on port 1352.
d. Review the communications trace and look for retransmissions.
You can use the command WRKJOB OPTION(*SPLF) and option 5 to display the
QPCSMPRT spooled file that contains the communications trace data.

Appendix C. Common configuration problems that affect Domino performance 591

 Note: Communications traces can be difficult to read. There is a function in the IBM
Support Library Tools (QSPTLIB) that can take a communications trace and break
out a single conversation. It not only breaks out the information for a single
conversation, but it can also list the total number of retransmissions in that
conversation. Use option 6 of the QSPTLIB/CMTMNU menu or the command
QSPTLIB/EXTTCPTRC to Extract TCP/IP trace information.

You must specify at least three components of the conversation to get accurate
retransmission information. For example, you can specify the Source IP Address,
Destination IP Address, and Source Port.

The IBM Support Library Tools for OS/400 can be ordered as a PTF. For V5R2M0
order PTF SE06946, for V5R1M0 order SE02231. Follow the instructions received
with the download to restore the library to your iSeries.

If you are not using the QSPTLIB tools, here are a few things you need to know to
identify a packet retransmission:
򐂰 The retransmission must occur in a single conversation.
– A single conversation is defined by a unique port pair with the same
source/destination address pair.
򐂰 A retransmission occurs when the network packet has a data length greater than
50 bytes and has the same sequence number (SEQ Number).
– For an example, please see the retransmission in Figure C-2:
• The port pair is 3855 and 1352.
• The source/destination addresses are 10.1.1.4 and 10.1.1.16.
• The data length is greater than 50 bytes.
• The SEQ Number is the same for both packets. It is 1277025586.

Display Spooled File

File . . . . . : QPCSMPRT Page/Line 12/4
Control . . . . . Columns 15 - 92
Find . . . . . .
+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9..
Data Record Controller Destination Source Frame
Length Timer Name MAC Address MAC Address Format Comma
104 13:34:02.44714 0006299C7C99 000944AF54BC ETHV2 Type
Frame Type : IP DSCP: 0 Length: 100 Proto
Src Addr: 10.1.1.16 Dest Addr: 10.1.1.4
IP Options : NONE
TCP . . . : Src Port: 3855,Unassigned Dest Port: 1352,Unassigne
SEQ Number: 1277025586 ('4C1DDD32'X) ACK Number: 17728
Code Bits: ACK PSH Window: 65340 TCP O
. . . . . : 3A0000002F000000 02000040020F0001 003D250000000000 0000000000000
94 13:34:02.44894 0006299C7C99 000944AF54BC ETHV2 Type
Frame Type : IP DSCP: 0 Length: 100 Proto
Src Addr: 10.1.1.16 Dest Addr: 10.1.1.4
IP Options : NONE
TCP . . . : Src Port: 3855,Unassigned Dest Port: 1352,Unassigne
SEQ Number: 1277025586 ('4C1DDD32'X) ACK Number: 17728
Code Bits: ACK PSH Window: 65340 TCP O
. . . . . : 3A0000002F000000 02000040020F0001 003D250000000000 0000000000000

Figure C-2 Example of a retransmission

592 Domino 6 for iSeries Best Practices Guide

How to fix the problem
To fix this problem, you have to disable the checksum feature. This is a very simple thing to do
on the iSeries. However, before you turn off checksum, you must make sure that other
applications on the iSeries do not require it. You cannot turn checksum off for Domino only! It
is either on for everything on the iSeries, or off for everything on the iSeries.

Note: One example of a function that requires checksum is Independent Auxiliary Storage
Pools (iASP). This is the function when a set of disks can be switched between two iSeries
systems or partitions.

If nothing else on the iSeries requires checksum, then disable it using the Change TCP/IP
Attributes command:
CHGTCPA UDPCKS(*NO)

CHGTCPA UDPCKS(*NO) is dynamic, so you do not need to restart TCP/IP for the change to
take effect.

Also, the parameter text for UDPCKS says it is the UDP checksum. But in fact, both TCP and
UDP checksums are controlled by this parameter. So changing this attribute to *NO disables
both UDP and TCP checksum on the iSeries.

Network routing - ARP storms

This section describes an issue with the iSeries load balancing feature and switches that use
dynamic route tables.

Summary of problem
You can configure the iSeries to load balance network traffic across any number of network
interfaces that share a common route.

For example: ServerA has four network interfaces on four separate network adapters:
򐂰 10.1.1.1
򐂰 10.1.1.2
򐂰 10.1.1.3
򐂰 10.1.1.4

A single default route is defined to 10.1.1.5 as shown in the default route configuration in
Figure C-3.

Appendix C. Common configuration problems that affect Domino performance 593

 Work with TCP/IP Routes
System: AS09
Type options, press Enter.
1=Add 2=Change 4=Remove 5=Display

Route Subnet Next Preferred

Opt Destination Mask Hop Interface

*DFTROUTE *NONE 10.1.1.5 *NONE

Bottom
F3=Exit F5=Refresh F6=Print list F11=Display type of service
F12=Cancel F17=Top F18=Bottom

Figure C-3 CFGTCP option 2 - Work with TCP/IP Routes

As a result, any adapter can be used to send data from the system. Requests received on
10.1.1.1 may be responded to from the network adapter with the 10.1.1.4 interface. The
response would carry the 10.1.1.1 return address and the 10.1.1.4 MAC address.

All TCP network traffic contains the IP address and the MAC address of the network adapter.
In this situation, the address 10.1.1.1 could be sent with the MAC address of any one of the
network adapters. This is a valid configuration on the iSeries.

Some intelligent switches, such as the Cisco 6509 series, dynamically generate a route table
which includes not only the IP address of each host but the MAC address of the adapter
which owns the IP address. As a result, when the iSeries sends a frame with the IP address
of 10.1.1.1 and the MAC address from the 10.1.1.4 adapter, the switch will purge the entries
for both adapters from it's internal table assuming both are in error. The switch then sends an
ARP broadcast to generate new table entries.

This creates two performance issues:

򐂰 Traffic inbound to the iSeries is held at the switch pending the update to its table.
򐂰 The ARP broadcast will be repeated frequently, creating a network constraint.

How to identify the problem

The following four steps can help you determine if you are experiencing this problem:
1. This issue cannot occur unless you have more than one active network interface cards
(NIC). To determine the number of active NICs on your system:
a. Start iSeries Navigator.
b. Go to the Network -> TCP/IP Configuration -> Lines section.
c. One line corresponds to one NIC, so count the number of active lines.
• Do not count the line called LOOPBACK.
• Confirm that the status of the line is Active.
• Figure C-4 shows only one active line. That means there is only one active NIC on
this iSeries at this time and the problem cannot occur in this example. If there were
multiple NICs active on the iSeries, then you would continue with the next step.

594 Domino 6 for iSeries Best Practices Guide

Figure C-4 iSeries Navigator displaying active lines

2. If there is more than one active NIC on the system, then you need to check the TCP/IP
routes and see if they are bound to specific interfaces. This issue cannot occur if each
active NIC has its own preferred route defined.
a. Enter the following command in a 5250 emulation session:
CFGTCP
b. Select menu option 2 to Work with TCP/IP Routes.
c. The problem described in this section can occur at your site if you have multiple active
NICs but only one configured route for all interfaces (compare to Figure C-3 on
page 594).
3. Find out if your hardware (router/switch) is configured to use dynamic route tables. Each
router/switch is different, so you may have to ask your network administrator. If the
router/switch is configured to use dynamic route tables, then you could be experiencing
this problem. If your router/switch is using static route tables or does not store the MAC
address, then this issue is not occurring.
4. Even if your configuration can experience this problem, it does not mean that you are
experiencing performance problems because of it. To see how much this type of
configuration is affecting your performance, take a communications trace and look for ARP
broadcasts and changing MAC addresses.
a. Start the communications trace using:
STRCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN) MAXSTG(16M) USRDTA(*CALC)
The CFGOBJ parameter is the name of one of the active lines you found in step 1.

Appendix C. Common configuration problems that affect Domino performance 595

 Notes:
򐂰 You may have to run a trace on each active line to look for this problem.
򐂰 Do not trace the LOOPBACK line.

b. Let the trace run for a few minutes and then end it using the following command:
ENDCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN)
c. Print the communications trace with the PRTCMNTRC command:
PRTCMNTRC CFGOBJ(ETHLINE) CFGTYPE(*LIN) CODE(*ASCII) SLTCTLD(*ALL) FMTTCP(*YES)
FMTBCD(*YES)
Notice that the data is formatted for TCP/IP and Broadcast data.
d. Review the communications trace and look for two things:
i. A high number of ARP broadcasts
ii. Changing MAC addresses in a single conversation
e. You can use the WRKJOB OPTION(*SPLF) and option 5 to display the QPCSMPRT file
that contains the communications trace data.
i. To find ARP broadcasts, search for the word ARP (all in capital letters).
Use the Find field and the F16 key to search the spooled file.
Count the number of times an ARP broadcast occurs in your trace.
You must use your own judgment to determine if you are seeing too many ARP
broadcasts.
For example, if you ran a 3 minute trace and count 50 ARP broadcasts, then you
should consider changing your TCP/IP configuration to fix this problem.
Figure C-5 shows an example of an ARP broadcast in an iSeries communications
trace.

Display Spooled File

File . . . . . : QPCSMPRT Page/Line 20/31
Control . . . . . ______ Columns 1 - 78
Find . . . . . . ARP
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
70 S 40 13:33:53.49525 00000C07AC01 0006299C7C99
Frame Type : IP DSCP: 0 Length: 4
Src Addr: 10.1.1.14 Dest Addr: 1
IP Options : NONE
TCP . . . : Src Port: 80,Unassigned Dest Port:
SEQ Number: 0 ('00000000'X) ACK
Code Bits: ACK RST Window
71 R 50 13:33:58.13039 FFFFFFFFFFFF 0004AC5EB196
Frame Type : ARP Src Addr: 10.1.1.5 D
ARP Header : 00010800060400010004AC5EB19609055C2F000000
Data . . . . . : 0000000000000000 0000000000000000 000036CA5863
COMMUNICATIONS TRACE Title: 08/11/03
Record Data Record Controller Destination Source
Number S/R Length Timer Name MAC Address MAC Address
More...
F3=Exit F12=Cancel F19=Left F20=Right F24=More keys

Figure C-5 Example of an ARP broadcast in a communications trace

596 Domino 6 for iSeries Best Practices Guide

 ii. To identify a changing MAC address, search for a conversation on port 1352. To do
this, search for 1352 followed by a comma. Use the Find field and F16 to follow a
conversation and watch the MAC addresses.
Figure C-6 shows an example of a conversation where the source MAC address is
changing even though the source IP address is the same.

Note: Communications traces can be difficult to read. There is an option in the

IBM Support Library Tools (QSPTLIB) that can take a communications trace and
break out a single conversation. Use option 6 of the QSPTLIB/CMTMNU menu
or the command QSPTLIB/EXTTCPTRC to Extract TCP/IP trace information.

The IBM Support Library Tools for OS/400 can be ordered as a PTF. For
V5R2M0 order PTF SE06946, for V5R1M0 order SE02231. Follow the
instructions received with the download to restore the library to your iSeries.

If you are not using the QSPTLIB tools, here are a few things you need to know:
򐂰 A single conversation is defined by the port pair (that is the source port and
the destination port) and the source and destination addresses.
– In Figure C-6 the port pair is 1352 and 3853.
򐂰 To determine if the MAC address is changing, you must find two packets sent
from the iSeries in a single conversation to the same destination that have
different source MAC addresses.
– In Figure C-6, notice that:
• The two packets in the screen capture are in the same conversation
(port pair: 1352/3853) and are both going in the same direction (source
address for both packets: 10.1.1.4 which is the iSeries in this example).
• Notice that the Source MAC Address for those two packets are
different, one is 000944AF54BC and one is 00000C07AC01.

Display Spooled File

File . . . . . : QPCSMPRT Page/Line 22/4
Control . . . . . ______ Columns 23 - 100
Find . . . . . . 1352,
..+....3....+....4....+....5....+....6....+....7....+....8....+....9....+....0
Record Controller Destination Source Frame Numb
Timer Name MAC Address MAC Address Format Command Sent
--------------- ---------- ------------ ------------ ------ ------- ----
13:34:02.14924 0006299C7C99 000944AF54BC ETHV2 Type: 0800
Frame Type : IP DSCP: 0 Length: 40 Protocol: TCP
Src Addr: 10.1.1.4 Dest Addr: 10.1.1.16 Fra
IP Options : NONE
TCP . . . : Src Port: 1352,Unassigned Dest Port: 3853,Unassigned
SEQ Number: 1276843135 ('4C1B147F'X) ACK Number: 1771096846 ('
Code Bits: ACK Window: 65340 TCP Option: N
13:34:02.20190 0006299C7C99 00000C07AC01 ETHV2 Type: 0800
Frame Type : IP DSCP: 0 Length: 158 Protocol: TCP
Src Addr: 10.1.1.4 Dest Addr: 10.1.1.16 Fra
IP Options : NONE
TCP . . . : Src Port: 1352,Unassigned Dest Port: 3853,Unassigned
SEQ Number: 1276843135 ('4C1B147F'X) ACK Number: 1771096846 ('
Code Bits: ACK PSH Window: 8192 TCP Option: N

Figure C-6 Example of a changing MAC address in a conversation

Appendix C. Common configuration problems that affect Domino performance 597

How to fix the problem
If you determine that you are having the issue and it is affecting your Domino performance,
then you need to change the TCP/IP routing to fix this problem.

There are two methods to correct this problem (you only need to use one method):
1. Change the router/switch to use static entries for the Domino system. By creating static
entries, the device never purges it's table, thus avoiding the performance issues.
2. Change the TCP/IP configuration on the iSeries so that each active NIC has its own
preferred route.
Run the Add TCP/IP Route (ADDTCPRTE) command to create a TCP/IP route for each
interface.
ADDTCPRTE RTEDEST(*DFTROUTE) SUBNETMASK(*NONE) NEXTHOP('10.1.1.5')
BINDIFC('10.1.1.2')
Please refer to Figure C-7 to see an example of preferred bindings on the Work with
TCP/IP Routes screen.

Work with TCP/IP Routes

System: AS09
Type options, press Enter.
1=Add 2=Change 4=Remove 5=Display

Route Subnet Next Preferred

Opt Destination Mask Hop Interface

*DFTROUTE *NONE 10.1.1.5 10.1.1.1

*DFTROUTE *NONE 10.1.1.5 10.1.1.2
*DFTROUTE *NONE 10.1.1.5 10.1.1.3
*DFTROUTE *NONE 10.1.1.5 10.1.1.4

Bottom
F3=Exit F5=Refresh F6=Print list F11=Display type of service
F12=Cancel F17=Top F18=Bottom

Figure C-7 CFGTCP option 2 with preferred bindings

Activity Level
This section describes an issue with the iSeries activity levels and jobs going ineligible.

Summary of problem
On the iSeries, activity level refers to how many processes can compete for the CPU(s) at the
same time. A process can be a licensed internal code (LIC) task or a thread in a job.

Here is a simple example: If the activity level is set to ten and there are eleven processes that
want to use the CPU(s) at the same time, then one process goes ineligible. There may be
more than eleven processes on the system, but only eleven of the processes want to use the
CPU(s) at the same time in our example. If thirteen processes wanted to use the CPU(s) at
the same time, then three processes would go ineligible.

598 Domino 6 for iSeries Best Practices Guide

 If a process goes ineligible, then the things it needs to run that were in Main Storage or cache
will probably be paged out before the process gets back into the CPU. This means that the
process will have to spend time getting the things it needs back into Main Storage or cache
before the process can do its actual work. This makes the process run longer and slow down
performance. In an extreme situation, with hundreds of processes going ineligible, the entire
system may seem to freeze up.

During normal system operations, you want zero processes to be going ineligible.

How to identify the problem

The activity level on an iSeries can be set in two different places:
򐂰 The first place is the QMAXACTLVL system value.
This system value determines the maximum activity level for the entire system. This
system value should be set to *NOMAX. The activity levels should be controlled at the
storage pool level.
򐂰 The second place is at the storage pool level.
You can access the storage pool information via the Work with System Status
(WRKSYSSTS) command. Each storage pool has its own activity level. The Max Active
column is the activity level (MPL) for a specific storage pool.

Note: Each process running on the iSeries requires memory. The more processes
running, the more memory in use on the system. If more memory is required than the
amount of memory installed on the system, then the system experiences a high rate of
paging. This paging rate can become so high that the system does (relatively) little other
work. This situation is called page thrashing. The way to control thrashing is called
Multiprogramming Level (MPL).

MPL is a number. It defines the maximum number of processes which may be in RUN
status, per storage pool, at any given instance.

Each storage pool has its own MPL number. That number can be seen on the Work with
System Status (WRKSYSSTS) screen in the Max Active column.

To sum all of this information up:

The Max Active value controls the maximum number of processes which may be eligible
for the CPU(s), per storage pool, at any given instance. So, to keep the system from
thrashing (excessive paging and faulting), you must not set the Max Active value too high.
However, if you set Max Active too low, then jobs go ineligible and take longer to run, thus
slowing performance.

To identify a performance problem with the activity level on your iSeries, you need to check
the Work with System Status (WRKSYSSTS) screen. There are many possible causes for
high paging and faulting in the storage pools, however, this is beyond the scope of this
appendix. We are only covering the problem where the activity level is too small.
1. To check if any processes are going ineligible, use the following command:
WRKSYSSTS
2. Change to Assistance Level 2 (Intermediate) if you are not already using it:
– Press the F21 key to access different assistance levels.
– Select option 2 for the Intermediate level.
– Press Enter.

Appendix C. Common configuration problems that affect Domino performance 599

 3. Back on the Work with System Status screen, press F11 to display the Wait-> Inel and
Active-> Inel columns. Press F10 to restart the statistics.
4. Press F5 periodically and monitor the Wait-> Inel and Active-> Inel columns.

As stated previously, during normal system operations, you want zero processes to be going
ineligible.

If processes are repeatedly going ineligible, then you have problems with the activity level on
your system.

How to fix the problem

If you have problems related to the activity level on your iSeries, then you need to confirm that
the QMAXACTLVL system value is set to *NOMAX and you need to increase the Max Active
value for the storage pool where the processes are going ineligible. To do so:
1. Enter the following command to verify the setting of the QMAXACTLVL system value:
DSPSYSVAL SYSVAL(QMAXACTLVL)
If the value is not set to *NOMAX, change the parameter using the following command:
CHGSYSVAL SYSVAL(QMAXACTLVL) VALUE(*NOMAX)
2. Once you have checked the system value, you need to increase the MPL number for the
storage pool(s) you identified as causing problems. To do so, enter the command
WRKSYSSTS
Type a new value in the appropriate Max Active column and press Enter. The new value
must be larger than the old value.
– Increase the value in the Max Active column by small increments (like 50), then monitor
the Wait-> Inel and Active-> Inel columns for about ten minutes.
– Keep pressing the F5 key during those ten minutes and see if the ineligible process
count goes to zero.
– If processes are still going ineligible after ten minutes, then increase the value in the
Max Active column again. (Repeat as necessary.)

Daylight Savings Time

This section describes an issue related to changing the time on your iSeries. We refer to it as
a Daylight Savings Time problem, because daylight savings forces administrators to change
the system time on the iSeries twice a year. Therefore, the start and end of Daylight Savings
Time is when this issue occurs most often.

Summary of problem
OS/400 does not automatically adjust the operating system time settings for daylight savings.
This is done for a number of reasons. For instance, if you have an application that sorts
entries by timestamps, then there could be two sets of data with the same timestamps in the
fall when daylight savings ends. (When daylight savings ends in the fall, there will be two
hours that span the 1:00 AM to 2:00 AM time period.)

This means that you have to manually change the system time if your geography observes
daylight savings. The Domino server must be stopped before the system time is changed and
restarted after the change.

600 Domino 6 for iSeries Best Practices Guide

 If the system time was changed while Domino was active, you encounter this problem. The
reason for this is that the software clock in the Domino server cannot dynamically pick up
changes to the OS/400 system time. As a result, the Domino server tries to match what it
“thinks” the OS/400 system time should be with what the OS/400 system time actually is,
which generates extra workload. This extra workload shows up as additional CPU utilization
for Domino jobs.

How to identify the problem

There are several ways to identify this problem.

The easiest way is to check the iSeries system history log (QHST) for a message stating that
the time was changed on the iSeries and then checking the Domino server to see if the server
was restarted after the time setting was changed. This is explained in “Check QHST and
Domino server” on page 601.

If for some reason you cannot use the history log and Domino console to identify this
problem, then you need to examine the call stacks of the jobs with high CPU utilization. See
“Examine call stacks of jobs with high CPU utilization” on page 603 for information.

Check QHST and Domino server

Follow the steps listed below to check your iSeries history log and see how long your Domino
server has been running:
1. Check the data in the iSeries system history log (QHST) using the following command:
DSPLOG PERIOD((*AVAIL *BEGIN)) MSGID(CPF1806 CPF1808)
The DSPLOG command displays information in your 5250 emulation session as shown in
Figure C-8. Examine this output to see if any of the following system values were
changed:
– QTIME, QHOUR, QMINUTE, QSECOND
– QUTCOFFSET
If you find messages indicating that at least one of these system values has been
changed, put your cursor on the message and press F1 to access the Additional Message
Information screen. This allows you to see the date and time of the change.

Display History Log Contents

System value QMAXSIGN changed from 000005 to 000005.

System value QSECURITY changed from 50 to 50.
System value QDEVRCYACN changed from *DSCMSG to *DSCMSG.
System value QPWDLMTCHR changed from *NONE to *NONE.
System value QPWDRQDDIF changed from 8 to 8.
System value QUTCOFFSET changed from -0600 to -0500.
System value QVFYOBJRST changed from 3 to 1.
System value QVFYOBJRST changed from 1 to 3.
System value QAUDLVL changed from *AUTFAIL to *NONE.
System value QAUDLVL changed from *NONE to *AUTFAIL.
Bottom
Press Enter to continue.

F3=Exit F10=Display all F12=Cancel

Figure C-8 Example of the output from the DSPLOG command

Appendix C. Common configuration problems that affect Domino performance 601

 Press F9 while in the Additional Message Information screen, to see which job changed
the system value (see Figure C-9).

Display Message Details

Message ID . . . . . . : CPF1806 Severity . . . . . . . : 00

Date sent . . . . . . : 08/08/03 Time sent . . . . . . : 10:03:52
Message type . . . . . : Information
CCSID . . . . . . . . : 65535

From job . . . . . . . . . . . : QPADEV0004

User . . . . . . . . . . . . : JSMITH
Number . . . . . . . . . . . : 020473

Time sent . . . . . . . . . . : 10:03:52.303040

Bottom
Press Enter to continue.

F1=Help F3=Exit F12=Cancel

Figure C-9 Example of the output from F9 when in the Additional Message Information screen

2. If you find that a time related system value was changed, check the Domino server to see
if the server was restarted after the change was made.
Issue the SHOW SERVER command in the Domino console and check the Elapsed time
value as shown in Figure C-10.

Work with Domino Console

Server: DOMPERF
Previous subcommands and messages:

> show server

Lotus Domino (r) Server (Release 6.0.2CF1 for OS/400) 08/12/2003 18:33:09

Server name: DOMPERF/SVR/ITSOBP - DOMPERF on AS09

Server directory: /LOTUS/DATA/DOMPERF
Partition: DOMPERF
Elapsed time: 5 days 09:33:46
Transactions/minute: Last minute: 52; Last hour: 89; Peak: 101
Peak # of sessions: 16 at 08/11/2003 10:16:47
Transactions: 13833 Max. concurrent: 20
ThreadPool Threads: 40
Availability Index: 100 (state: AVAILABLE)
Enter a Domino subcommand.
===>

F3=Exit F5=Refresh F6=Print F9=Retrieve

F17=Top F18=Bottom F21=Command line

Figure C-10 SHOW SERVER command to check the Elapsed time parameter

602 Domino 6 for iSeries Best Practices Guide

 If the elapsed time goes back before the time that the system value was changed and the
Domino server CPU is higher than normal, then you are most likely having this problem.
For example: Using Figure C-9 on page 602 and Figure C-10 on page 602, notice that the
QUTCOFFSET was changed on August 8th, 2003 at 10:03 AM and the Domino server
has been running since 9:00 AM on August 7th, 2003. This means that the server in this
example is most likely having CPU issues related to this problem.

Examine call stacks of jobs with high CPU utilization

If you cannot use the history log and Domino console to identify this problem, then you need
to examine the call stacks of the jobs with high CPU utilization:
1. Use the WRKACTJOB command to identify a Domino job using high amounts of CPU:
WRKACTJOB
Once you are on the Work with Active Jobs screen, sort the jobs by CPU so that the jobs
using the most CPU are at the top of the list.
a. Place your cursor on the CPU% column.
b. Press the F16 key to sort the jobs by CPU.
c. Press F10 repeatedly to reset the statistics and watch the CPU changing.
• You are looking for a Domino job that is taking more CPU than normal.
• Once you identify a Domino job taking more CPU than normal on your system, write
down the job name, job user, and job number.
2. Next use the WRKJOB command to get to the call stack information:
WRKJOB JOB(xxxxxx/QNOTES/jobname)
Where xxxxxx is the six digit job number and jobname is the name of the job taking the
extra CPU (information you noted in step 1).
a. Take menu option 20 to display the threads in that job.
If you are lucky, the job is single threaded and you can continue with step 3. However, if
there are multiple threads running in this job, you must check all individual threads to
identify which thread(s) is generating the extra CPU utilization.
• Under normal conditions a thread can periodically be seen entering and exiting a
RUN status.
• The Total CPU column indicates how much time (in seconds) that particular thread
has been in the processor.

Note: The value in the Total CPU column does not directly relate to the CPU
percentage of the job.

• If a thread is generating most of the extra CPU utilization, then you may notice it has
a larger amount of Total CPU than the other threads. Or, you may also notice that
the thread is constantly in a RUN status.
b. Write down the thread identifier for the thread(s) you believe may be responsible for
generating the extra CPU utilization.
3. Once you find the thread(s) generating the extra CPU utilization, you need to look at the
call stack to find out what that thread is doing.
Domino call stacks usually contain very long procedure names that may not be easily
readable. To make these names easier to read, you can use a special panel group that is

Appendix C. Common configuration problems that affect Domino performance 603

 shipped with the Domino server product. This panel group displays longer procedure
names on the Display Call Stack screen. To use this panel group, follow these steps:
a. Use the Create Library (CRTLIB) command to create a new library:
CRTLIB LIB(NOTESSYS)
b. Use the Create Duplicate Object (CRTDUPOBJ) command to make a copy of the
panel group in the new library you created.:
CRTDUPOBJ OBJ(GWVJOB) FROMLIB(QNOTES) OBJTYPE(*PNLGRP) TOLIB(NOTESSYS)
NEWOBJ(QGWVJOB)
c. Use the Change System Library List (CHGSYSLIBL) command to add the new library
to your library list (the new library must be listed before the QSYS library):
CHGSYSLIBL LIB(NOTESSYS)

Note: There are a few special things to be aware of when using the CHGSYSLIBL
command:
򐂰 The CHGSYSLIBL command is shipped with public *EXCLUDE authority.
Therefore, only the security officer or a user profile with *ALLOBJ special
authority can use this command.
򐂰 The CHGSYSLIBL command only changes the system portion of the library list
for the job in which the command is entered - this does not change the system
portion of the library list for any other jobs on the iSeries.
򐂰 The panel group that is used for this function only works well with Domino jobs. If
you attempt to display the call stacks of non-Domino jobs while using this panel
group, you get incomplete information. You must sign off and sign back on or
issue the CHGSYSLIBL LIB(NOTESSYS) OPTION(*REMOVE) command to correct this
issue.

To display a call stack on the Work with Threads screen, place a 10 in front of the thread(s)
you identified as responsible for the extra CPU and press Enter.
Look at the procedures listed in the call stack and try to identify what that thread is doing.
If the GetTimeOfDay procedure appears repeatedly in the call stack, then you are most
likely having the Daylight Savings Time problem.

604 Domino 6 for iSeries Best Practices Guide

 Important: If OS/400 release V5R2M0 PTF SI07056 is applied on your system, the
GetTimeOfDay procedure does not show up in the call stacks of the jobs running with high
CPU even if you are experiencing this problem.

If you cannot use the history log and Domino console to identify this problem, then you can
use a Performance Explorer (PEX) trace, also called a TPROFS trace.
1. Find a Domino job utilizing a lot of CPU (use the WRKACTJOB command as described
earlier in this section).
Write down the job name, user name, and job number for the job taking the extra CPU.
2. Create a library to store the PEX data in using the following command:
CRTLIB LIB(PEXHOLD)
3. Next, create a PEX definition specific to the job you found in step 1:
ADDPEXDFN DFN(JOBCPU) TYPE(*TRACE) JOB((xxxxxx/QNOTES/jobname)) TASK(*ALL)
MAXSTG(100000) INTERVAL(5) TRCTYPE(*SLTEVT) SLTEVT(*YES) BASEVT(*PMCO)
Where xxxxxx is the six digit job number you wrote down in step 1.
4. Start the PEX trace:
STRPEX SSNID(CPU1) DFN(JOBCPU)
Let the trace run for 3 - 4 minutes while the CPU is high.
5. End the PEX trace:
SBMJOB CMD(ENDPEX SSNID(CPU1) DTALIB(PEXHOLD)) JOB(ENDPEX)
6. Wait for the ENDPEX batch job to end before printing out the PEX report. You can
check the status of this job using the command
WRKSBMJOB
Wait for the job called ENDPEX to have a status of OUTQ.
7. If you have the iSeries Performance Tools (5722-PT1) installed on your system, then
you can print out the PEX report using
SBMJOB CMD(PRTPEXRPT MBR(CPU1) LIB(PEXHOLD) TYPE(*PROFILE) PROFILEOPT(*SAMPLECOUNT
*PROCEDURE)) JOB(PRTPEX)
This command generates a spooled file called QPVPERPT in the batch job you
submitted. In this example, the batch job you submitted is called PRTPEX - use the
command WRKJOB JOB(PRTPEX) to find the spooled file.
8. Display the spooled file and search for the second Histogram section:
WRKJOB JOB(PRTPEX) OPTION(*SPLF)
Search on Histogram in the Find field using F16.
The first Histogram section contains information on libraries and LIC components.
The second Histogram section contains information on procedures and programs.
You are looking for procedures like masolockmutexbla and TimeOfDayClock with high
hit counts to identify if you are having this problem.

How to fix the problem

If you determine that you are having CPU/performance problems related to a time change on
your iSeries, then you must end your Domino server(s). All Domino partitions on this OS/400
instance that have not been ended since the time change occurred must be shutdown to
correct this problem. You must end the Domino server(s) completely before restarting (using

Appendix C. Common configuration problems that affect Domino performance 605

 the command ENDDOMSVR or the Domino console command QUIT). A RESTART SERVER
command from the Domino console does not fix this problem.

Server based mail rules

This section describes CPU problems that can occur when you enable server based mail
rules in Domino 6.

Summary of problem
In Domino 6, you have the ability to set up mail rules on your Domino server. Unlike the mail
rules in Domino R5 that ran in individual user’s mail files, these rules run against the
MAIL.BOX and affect all messages on the server (this includes SMTP and NRPC messages).

When MAIL.BOX receives a new message, the server evaluates the fields in the message
against the registered mail rules. If the message meets a defined condition, then Domino
takes the specified action for that message.

Important: Server based mail rules are not intended to serve as a complete antivirus
solution. Mail rules do allow you to quarantine a message with a known virus attachment,
but they do not have other features that are usually found in antivirus software.

Mail rules are meant to compliment your antivirus software. They can also help you limit
SPAM, control mass mailings, etc.

For more information on the use of antivirus software, please refer to Chapter 9, “Antivirus
protection” on page 405.

One of the conditions allowed in the Domino 6 mail rules is a scan of the Body field of an
e-mail. This means that you can setup a mail rule to search the body of an e-mail for a
particular word.

This is not recommended.

Once a rule is registered, it runs against all new mail. If you have rules configured to search
the body of a message for a particular word, then the CPU utilization of the SERVER task can
increase dramatically. (The Domino 6 mail rules run in the SERVER task.)

This CPU increase is true on all platforms, not just the iSeries.

There is an article on Domino 6 mail rules and performance at the developerWorks : Lotus
LDD Today Web site. The article is called Domino 6 server mail rules and can be found at:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/8c486fc2ccc664e08525
6cbe004588f8?OpenDocument&Highlight=0,rules

This article mentions tests run on a Netfinity® system with four 700 MHz Xeon processors
and 2 GB of memory, running Windows 2000. The tests used an IBM EXP200 array,
configured for RAID0, for the data files. The workload simulated 3,000 Notes 6 mail users.
See Table C-1 for the results of those tests.

Notice that searching the body of e-mails caused the largest increase in CPU.

606 Domino 6 for iSeries Best Practices Guide

 Table C-1 Results of testing Domino 6 mail rules
Total CPU usage (%) SERVER task CPU (%)

Baseline and all runs with 3,000 15 8

Notes 6 mail users

Test 1: 10 rules each with 10 15 8

conditions - 100 unique strings
searched for in the Subject field

Test 2: 25 rules each with 10 16 10

conditions - 250 unique strings
searched for in the Subject field

Test 3: 50 rules each with 10 32 28

conditions - 500 unique strings
searched for in the Subject field

Test 4: 10 rules each with 10 47 38

conditions - 100 unique strings
searched for in the Body field

How to identify the problem

There are two ways to identify this problem. The first method involves three different tasks
and is explained in “Check for mail rules usage” on page 607. The second method involves
setting NOTES.INI debug parameters and is explained in “NOTES.INI debug parameter” on
page 609.

Check for mail rules usage

The first method involves the following tasks:
1. Confirm that your server has registered mail rules.
2. Confirm that the SERVER task CPU is higher than normal.
3. Check the threads in the SERVER task to see what procedures are generating the extra
CPU.

We begin with task 1:

1. Confirm that your Domino server has registered mail rules:
a. Open your Domino Directory using a Lotus Notes client.
b. Open the Configuration document for the Domino server having CPU/performance
problems.
c. Go to the Router/SMTP -> Restrictions and Controls -> Rules tab.
d. Look for rules that are currently enabled.
Rules that are enabled have a green check mark next to them in the Configuration
document.
For an example, please refer to Figure C-11 on page 608. Notice that there are four
enabled mail rules in this Configuration document and that one mail rule is not enabled.

Appendix C. Common configuration problems that affect Domino performance 607

 Figure C-11 Mail rules in the Domino Directory configuration document

2. Confirm that the SERVER task is responsible for the high CPU on your system:
WRKACTJOB
Move the cursor onto the CPU% column.
Press the F16 key to sort the jobs by CPU.
Press the F10 key repeatedly to watch the CPU changing.
See if the SERVER job is taking a large amount of the CPU on the system.
Write down the job number for the SERVER job taking the CPU.
3. Check the threads in the SERVER job generating high CPU to see if they are processing
mail rules:
WRKJOB JOB(xxxxxx/QNOTES/SERVER)
Where xxxxxx is the six digit number of the SERVER job generating extra CPU.
As stated previously, Domino call stacks usually contain very long procedure names that
may not be easily readable. To make these names easier to read, you can use a special
panel group that is shipped with the Domino server product. This panel group displays
longer procedure names on the Display Call Stack screen. To use this panel group, follow
these steps:
– Use the Create Library (CRTLIB) command to create a new library:
CRTLIB LIB(NOTESSYS)
– Use the Create Duplicate Object (CRTDUPOBJ) command to make a copy of the
panel group in the new library you created:
CRTDUPOBJ OBJ(GWVJOB) FROMLIB(QNOTES) OBJTYPE(*PNLGRP) TOLIB(NOTESSYS)
NEWOBJ(QGWVJOB)
– Use the Change System Library List (CHGSYSLIBL) command to add the new library
to your library list (the new library must be listed before the QSYS library):
CHGSYSLIBL LIB(NOTESSYS)
(For more information about the CHGSYSLIBL command, see the Note on page 603.)
On the Work with Job screen, take option 20 to display the threads.

608 Domino 6 for iSeries Best Practices Guide

 Pick a thread that is frequently in RUN status and display its call stack.
To display a call stack on the Work with Threads screen, type 10 in front of the thread
press Enter.
Press the F10 key repeatedly to update the stack and look at the procedures listed.
You are looking for procedures like DbMonitorEvalNote and MonitorEvalNote. If those
procedures keep appearing in the call stack, then you are most likely having the mail rules
problem.

NOTES.INI debug parameter

The second method that can help you to identify this issue is the NOTES.INI debug parameter
called DEBUG_MONITOR=3.

This parameter outputs information from both the execution and trigger of the system rules. If
a rule is triggered, then the Domino console shows the execution and the action immediately
after. If there is no action, then only the execution is shown.

Example C-1 shows the possible output in the Domino console.

Example: C-1 Debug output in Domino console

05:56:26.85 PM DebugMonitorTrace> Db=mail3.box MonitorID=5BB368E6: 2A system rule 2 has
been executed.
05:56:26.85 PM DebugMonitorTrace> Db=mail3.box MonitorID=5BB368E6: 2A system rule 2 action:
$JournalResponsibility changed to 1.

To identify if your CPU/performance problems are related to this issue, you can enable this
debug parameter and watch the output in the Domino console. If the SERVER task CPU is
high and the console is constantly displaying messages about Monitor traces, then you are
probably experiencing this issue.

How to fix the problem

If server based mail rules are causing your performance problems, then you need to review
your rules. Determine if you need all the rules you have configured and decide if you have the
rules listed in the best order possible. Change the rules if needed and disable rules you do
not need. If nothing can be changed or disabled, then you may need to consider buying
additional hardware.

Here are a few things to think about:

򐂰 Fewer rules means less resources used. The reason for this is that all rules that are
registered have to be run. Consequently, limiting the number of rules can help save CPU.
򐂰 Rules are executed in the order they are listed. Therefore, you should place the rules that
are more likely to be triggered at the top of the list. Once a rule is triggered, the other
registered rules do not run against that piece of mail.
򐂰 Place the most common words at the beginning of a rule. If a condition is meet, the
remaining conditions in the rule may not have to be processed.
򐂰 As mentioned previously, do not search the body of the message unless it is really
needed. Searching the body has the most impact on the Server's CPU and memory. Thus,
searching the body can cause undesired results on the performance of the Domino server.

Appendix C. Common configuration problems that affect Domino performance 609

610 Domino 6 for iSeries Best Practices Guide
 D

Appendix D. Additional material

This redbook refers to additional material that can be downloaded from the Internet as
described below.

Locating the Web material

The Web material associated with this redbook is available in softcopy on the Internet from
the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/SG246937

Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks

Select the Additional materials and open the directory that corresponds with the redbook
form number, SG246937.

Using the Web material

The additional Web material that accompanies this redbook includes the following files:
File name Description
TDPSampleFiles.zip Contains the sample script files and sample configuration files from
chapter 8.
Questionnaire.zip Contains a questionnaire that helps you sizing a Domino system
with the Workload Estimator. There are two PDF-files, one in A4
format, one in Letter format.
EndDominoServers.txt A sample program that uses the Domino APIs to retrieve the status
of Domino servers and ends them.

© Copyright IBM Corp. 2004. All rights reserved. 611

System requirements for downloading the Web material
The following system configuration is recommended:
Hard disk space: 1 MB
Operating System: Windows

How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web
material zip file into this folder.
򐂰 The following sample files and scripts are included in TDPSampleFiles.zip:
– .profile.txt
– domdsm.cfg
– domarc.script
– domina.script
– dominc.script
– domsel.script
– dsm.opt
– dsm.sys
See 8.8.1, “Sample configuration files for Data Protection for Domino” on page 399 and
8.8.2, “Sample scripts for scheduled Data Protection for Domino operations” on page 401
for more information.
򐂰 For your convenience, the sizing questionnaire is available in two paper formats: A4 and
Letter.
򐂰 Copy the sample program into a CL source file on the iSeries and create the program. You
can add save commands to this program if you wish to use it just before a save operation.

612 Domino 6 for iSeries Best Practices Guide

Related publications

The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this redbook.

IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks” on page 615.
Note that some of the documents referenced here may be available in softcopy only.
򐂰 IBM Lotus Domino 6 for iSeries Implementation, SG24-6592
򐂰 Lotus Domino 6 for iSeries Multi-Versioning Support on the IBM eServer iSeries Server,
SG24-6940
򐂰 Domino for iSeries Domino for iSeries Sizing and Performance Tuning, SG24-5162
򐂰 Coexistence of Multiple Lotus Domino Releases in an LPAR Environment on the IBM
eServer iSeries Server, SG24-6593
򐂰 iNotes Web Access on the IBM Server iSeries Server, SG24-6553
򐂰 Lotus Domino for AS/400: Problem Determination Guide, SG24-6051
򐂰 Lotus Domino for AS/400 R5 Implementation, SG24-5592
򐂰 Upgrading to Lotus Notes and Domino 6, SG24-6889
򐂰 Lotus Domino 6 spam Survival Guide for IBM eServer, SG24-6930
򐂰 Domino Designer 6: A Developer’s Handbook, SG24-6854
򐂰 Getting the Most From Your Domino Directory, SG24-5986
򐂰 Distributing Notes Clients Automatically, REDP3693
򐂰 New features of Domino 6.0.1: Single Copy Template, REDP3681
򐂰 Installing Tivoli Storage Manager and Tivoli Storage Manager APIs on the Same IBM
iSeries Server, TIPS0293
򐂰 Slicing the AS/400 with Logical Partitioning: A How to Guide, SG24-5439
򐂰 LPAR Configuration and Management: Working with IBM eServer iSeries Logical
Partitions, SG24-6251
򐂰 Managing OS/400 with Operations Navigator V5R1 Volume 5: Performance Management,
SG24-6565
򐂰 IBM Content Manager CommonStore for Domino, Exchange, and SAP, SG24-6405
򐂰 Implementing Windows Terminal Server and Citrix MetaFrame on IBM eServer xSeries
Servers, REDP-3629
򐂰 IBM eServer iSeries in Storage Area Networks: Implementing Fibre Channel Disk and
Tape with iSeries, SG24-6220
򐂰 Introduction to Storage Area Networks, SG24-5470
򐂰 iSeries IP Networks: Dynamic!, SG24-6718
򐂰 All You Need to Know When Migrating from IBM Firewall for AS/400, SG24-6152

© Copyright IBM Corp. 2004. All rights reserved. 613

Other publications
These publications are also relevant as further information sources:
򐂰 Backup and Recovery Version 5, SC41-5304
򐂰 TCP/IP Tutorial and Technical Overview, GG24-3376
򐂰 CL Programming Version 5, SC41-5721
򐂰 Backup, Recovery and Media Services Version 5, SC41-5345-03

Online resources
These Web sites and URLs are also relevant as further information sources:
򐂰 iSeries Information Center:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm
򐂰 Lotus Software for iSeries Compatibility Guide:
http://www.ibm.com/servers/eserver/iseries/domino/domino6/releasesupport4up.pdf
򐂰 Domino for AS/400: Application Sizing Examples:
http://www.ibm.com/servers/eserver/iseries/domino/d4appsz.htm
򐂰 Lotus Notes, Domino, and Domino Designer Release Notes 6.0.2:
http://www.lotus.com/ldd/doc/domino_notes/6.0.2/readme.nsf
򐂰 Installing and Managing Domino 6 for iSeries:
http://www.lotus.com/ldd/notesua.nsf/0b345eb9d127270b8525665d006bc355/505c677e79adb5
9100256c44003288ee?OpenDocument
򐂰 Introduction to Multi-versioning Domino for iSeries:
http://www.ibm.com/servers/enable/site/domino/downloads/multiversion.pdf
򐂰 Policy-based system administration with Domino 6:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/d78ede75b351cf81
00256be9005b7d35?OpenDocument&Highlight=0,internet,site
򐂰 Installing and Managing Domino 6 for iSeries:
http://www.lotus.com/ldd/notesua.nsf/0b345eb9d127270b8525665d006bc355/505c677e79adb5
9100256c44003288ee?OpenDocument
򐂰 Planning for Domino on iSeries: Resources, Subsystems, Partitioning, and Clustering
http://www.ibm.com/servers/esdd/articles/domino_iseries.html
򐂰 Administering Domino Clusters:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument
򐂰 Domino 6 server mail rules and can be found at:
http://www.lotus.com/ldd/today.nsf/62f62847467a8f78052568a80055b380/8c486fc2ccc664e0
85256cbe004588f8?OpenDocument&Highlight=0,rules
򐂰 Administering the Domino System, Volume 1:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument

614 Domino 6 for iSeries Best Practices Guide

 򐂰 Administering the Domino System, Volume 2:
http://www.lotus.com/ldd/notesua.nsf/ddaf2e7f76d2cfbf8525674b00508d2b/2f6cd8057c3602
bf85256b5800681d38?OpenDocument
򐂰 iSeries Performance Capabilities Reference Version 5, Release 2:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/as4ppcp8.pdf
򐂰 iSeries TCP/IP Troubleshooting:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzaku/rzakumst.pdf
򐂰 V5R2 Stream File Performance Enhancements:
http://www.ibm.com/servers/eserver/iseries/perfmgmt/pdf/ifsperf.pdf
򐂰 IBM Tivoli Storage Manager for OS/400 PASE, Administrator’s Guide, Version 5.2:
http://publib.boulder.ibm.com/tividd/td/ITSM400/GC23-4694-01/en_US/PDF/anrpgd51.pdf
򐂰 iSeries Navigator Web site:
http://www.ibm.com/servers/eserver/iseries/navigator/index.html
򐂰 iSeries Access for Windows Web site:
http://www.ibm.com/servers/eserver/iseries/access/expresslinks.htm
򐂰 DB2 CommonStore for Lotus Domino Web site:
http://www.ibm.com/software/data/commonstore/lotus/
򐂰 Tivoli Web site:
http://www.ibm.com/software/tivoli/Description1
򐂰 Sizing Large-Scale Domino Workloads on iSeries, REDP-3802:
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/redp3802.html

How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft
publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at
this Web site:
ibm.com/redbooks

Help from IBM

IBM Support and downloads
ibm.com/support

IBM Global Services

ibm.com/services

Related publications 615

616 Domino 6 for iSeries Best Practices Guide
Index
Policies 17
Symbols Administration Process 70, 88, 104
$ServerAccess view 51 Administration request 104
$Users view 51 Administration Requests database 70
% system ASP used 288 Administration server 52, 104
*ALLOBJ 288 Extended 104
*CALC 474 Administrator background
*DISKSTGOPT 220 Domino 113
*ERROR status 275 iSeries 113
*JOBCTL 261, 288 Administrator preferences 71
*MACHINE pool 122 Basics 71
*MAINSTGOPT 220 Files 71
*DYNAMIC 221 Monitoring 71
*MINIMIZE 220 Registration 71
*NORMAL 220 Statistics 71
*SAVSYS 261, 288 ADMINP task 88
*TYPE2 file format 218 AdminP task 104
.profile file 373, 399 Adobe Acrobat PDF 12
/QIBM/ProdData/LOTUS/DOMINO603 247 Advanced Job Scheduler 113, 250, 302, 304, 313–315,
/QIBM/ProdData/LOTUS/DOMINO604 247 325, 334, 383
/QIBM/ProdData/LOTUS/DOMINO650 247 Advanced user registration 53
@SetHTTPHeader function 239 Agent manager 88
Agents 103, 481
Numerics AIX 422
10K RPM drives 490 Alias 35
15K RPM drives 490 AMGR task 88
24x7 availability 344 Anti-spam 107
24x7 operation 109 Antivirus
2757 SCSI PCI RAID Disk Unit Controller 490 Binary file structure 431
3x heavy user 528 Infected computers 449
5250 workstation emulation 27, 31, 73 Antivirus policy 406
5698-DPD 250 Antivirus protection 107
5722-BR1 250 Antivirus scanning and repair engine
5722-JS1 314 Updates 416
5722-PT1 137, 184, 187, 190, 588 Antivirus software 410, 528, 606
Antivirus software protection 508
APAR 209
A API
ACL 39, 66, 103 QP0FCVT2 218
Extended 105 Application load characteristics 483
Active jobs 77, 211 Application performance 103
Active mail 59 Application rating 528
Active Subsystems view 81 Application Rating Scale 484
Active users 467, 472, 499 Architecture 500
Activity level 183, 598 Archive
Activity Trends 112 Transaction log files 355
Actual Bandwidth Requirement 6 Archive mail file 59
Add TCP/IP Route 598 Archive mail server 59
ADDENVVAR 235 archivelog command 379, 381
ADDJOBSCDE 384 ARP 34
ADDPEXDFN 587, 605 ARP broadcast 204, 594, 596
Address Resolution Protocol See ARP ARP storms 593
ADDTCPRTE 598 AS/400 benchmarks 468
ADMIN4.NSF 70 ASP 123, 228, 255
Administration Independent 228

© Copyright IBM Corp. 2004. All rights reserved. 617

 System 228 To save file 259, 280
User 228 To tape device 259
Assistance level User data 294
Intermediate 172 User profile requirements 288
Attachment compression 7 While Domino server active 285
Attachment handling 61 Backup and recovery 92
Audit 36 Backup and recovery considerations 14
Authority lookup exceptions 224 Backup and recovery strategy 14, 294
Automated client upgrades 106 Backup and restore 354
Automatic system cleanup 181 Backup Copy Group 360
Auxiliary storage 227 Data retention rules 360
Auxiliary storage allocation 209, 211–212 Backup Matrix 66
Auxiliary Storage Pool 228, 248 Backup media 248
Avalon Business System Backup policy 302
ReduceMail Pro 65 Backup strategy 248, 304, 334, 381
Save-to-disk 249
Save-to-tape 249
B Backup system data 395
Backout plan 71 Backup versions 248
Backup Backup window 248, 258, 269–270, 273, 381
/QIBM/UserData/LOTUS/* directory 260 Backup, Recovery, and Media Services for iSeries 293
All user data 258 Backup, Recovery, and Media Services for iSeries See
Automated 282, 294 BRMS
Common problems 292 Balanced configuration 501
Databases outside Domino data directory 263 Balanced system 500–501
Domino code 258 Benchmark 466, 483
Domino data directory 258, 260 Benchmark data 499
Entire IFS 260 Benchmark measurements 466
Entire system 258 Benchmark unit 500
Frequency 260 Benchmarking 467
History log 260 Real user 468
IFS 264 Virtual user 468
Incremental 264, 294 Benchmarks
Advantage 265 AS/400 468
Disadvantage 265 iSeries 468
Since date/time 265 Real life users 480
Incremental - Cumulative 265 Billable service 59
Incremental - Since last full backup 265 BILLING task 88
Individual Domino databases 262 BINHEX 447
Joblog 260 Blackberry Enterprise Server 460
Mail databases 263 Blended threat 407
Multiple versions 355 Block transfer size 220
Object locks 260, 264 BMC Patrol Predict 464
Online 294, 375 BRMS 29, 88, 243, 249–250, 254, 257–258, 354, 508,
OUTPUT(*PRINT) 259 528, 535
QNOTES* libraries 260 Add Media 309
QUSRNOTES library 260 Advanced Job Scheduler 315
Retention Archival logs 297
Legal rules 304 Backup 24x7 environment 344
Retention period 304 Backup Activity 307
Retention schedule 304 Backup and recovery log 325
Sample CL program 282 Backup control group 296, 298, 302, 330–331, 336
Save file 280 Backup device 299
SAVE menu 257–258, 266 Backup Domino ID files 335
Option 21 258 Backup history 327
Option 23 258 Backup link list 299
Save Object (SAV) 261 Backup of clustered environment 296
Scheduled 294 Backup policy 296, 298, 302, 322, 325, 330, 333,
Special authorities 269 335–336
System data 294 *System 317
Tape device 249

618 Domino 6 for iSeries Best Practices Guide

 Monthly 316 Package 345
Weekly 316 Package ID 345
Yearly 316 Point in time recovery 325
Backup scenarios 295 Policies 330
Backup strategy 305, 317 Print reports 320, 325, 344
Backup system data 342 Problem determination 345
Backup to IBM Tivoli Storage Manager server 323 PTFs 294, 348
Backup to save file 309, 323 Recovery policy 333, 335
Backup user data 342 Recovery report 250
Case sensitivity 349 Restore
Complete system backup 250 Domino server 347
Containers 331 Individual Domino database 347
Control Group attributes 330 To point in time 347
Create backup schedule 315 Version 327
Default setup 295 Restore Domino databases 326
Disaster recovery 320 Restore to point in time 297, 338
Disaster recovery report 320 Restore Wizard 326
Disaster recovery test 349 Save files 343
Enroll tapes 343 Save IFS data 318
Entities 297 Save IFS objects 317
Exclude data from backup 335 Save user and system libraries 317
Exclude list 299 Save While Active 344
Full backup 325 Schedule backups 313
Full dedicated backup 296 Selective backup 296
Advantage/Disadvantage 296 Storage location 299, 331, 335, 343
Full online backup 296, 333, 344, 348 System backup 333
Advantage/Disadvantage 296 System policy 298, 330, 332, 335
Frequency 296 Tape device 299
Full online backups of Domino 250 Tape location 311
Full system backup 339 Tape usage counter 343
Full system recovery 320 Tape volume name 310
Full system save 348 Tape volumes 322, 343
GUI 305, 325 Temporary data 345
Include data in backup 335 Tips and recommendations 348
Incremental backup 325 Upgrade to V5R2 294
Incremental online backups of Domino 250 Use save file 299–300
Initialization 330, 336 BRMS environment 294
Default objects 331 BRMS Group PTF 22
Initialize tapes 312 BRMS maintenance job 319, 322, 325, 330, 335, 349
iSeries Navigator client 295 BRMS objects 329
iSeries Navigator Domino backup checklist 324 BRMS online incremental save 183
Link list 318, 334–335, 344 BRMS plug-in 29
Link list backup 317 BRMS reports 316
Maintenance job 316 BRMS Web site 348
Maintenance task 302 BRMS/400 293
Management Central job scheduler 313 Browser caching 239
Media 299 Bus speed 467, 499
Media class 299, 332, 343 BUSYTIME.NSF 101
Media expiration 343
Media location 299
Media policy 299, 331, 335 C
Media pool 299, 321–322 C API Release 6 toolkit 244–245
Media retention period 335 C API toolkit 277
Move policy 299, 321, 332, 335 C++ APIs 245
New Backup Policy wizard 305 CA See Certification authority
Object locks 335 Cache 183, 599
Online incremental backup 297, 333, 344 Cache validation 239
Advantage/Disadvantage 297 Caching headers
Online incremental backup strategy 305 Cache-Control header 108
OS/400 commands 295, 329 Expires header 108
Last-Modified header 108

Index 619
Caching server 108 Collect historical performance data 125
CALCONN task 88 Collection profile 136
Calendar connector 88 Collection retention period 136, 139
Call stack 180, 189 Collection task 135
Capacity planning 464 Configuration 136
CCSID 193 Configure data collection 136
Certificate 246 Data stored in QAPMDOMINO 170
Certification authority 39, 53 Default collection interval 136
Certifier ID files 53 Disk requirements 135
CFGDOMSVR 84, 279 Graph History 139
CFGDOMSVR RPLCFG(*NO) 278 Library QMPGDATA 135
CFGSM 426 Library QPFRDATA 135
CFINT 191 Number of transactions 155
Change Attribute command 218 QAPMDOMINO
Change Domino Server 84 DMSRVN field 170
Change Job 187 DMSSDT field 170
Change management process 70 DTETIM field 170
Backout plan 71 QAPMDOMINO file 167
Change control request form 70 Reports
Change requests 71 Create New Data Source 155
Checksum 202, 590 Domino transactions 155
CHGATR 218, 220 Filter data 159
CHGDOMSVR 84 Import Data 161
CHGSYSVAL 210–211, 600 Mail 166
CHGTCPA 593 Peak concurrent users 166
Cisco 6509 594 PivotTable 162
Citrix ICA Client 109 Save Query 160
Citrix Metaframe 109 Select columns 158
CIW 456, 497 Sort Order 159
CL commands 31 Sample reports 154
CL program 282, 339 Start 137
Schedule 283 From Performance Tools menu 137
CLADMIN task 88 Through PM/400 137
CLDBDIR task 88 Through System monitors 138
Client access methods 7 Using Collection Services APIs 137
Domino Access for Microsoft Outlook 8, 457 Using iSeries Navigator 137
Domino Web Access 8, 457 Statistics categories 136
IMAP 8, 457 Stop
Lotus Notes client 8, 457 Using iSeries Navigator 138
Multi-user workstation 8 View data
POP3 8, 457 As spreadsheet 151
Roaming user 8 Collection points 140
WebMail 8, 457 Display query results 151
Client conversion factor 4 Domino performance data 139
Client strategy 7 Download into spreadsheet 151
ClockType 25, 44 Export Graph History 141
CLREPL task 88, 90, 475 Graphical view 139
Cluster administration process 88 iSeries performance data 139
Cluster Analysis 67 Query/400 144
Cluster Database Directory Manager 88 Using iSeries Navigator 139
Cluster Manager 89 Using workstation tools 142
Cluster replication task 475 Collection Services APIs 137
Cluster Replicator 88, 90 Collection Services job 135
Cluster server 89 Collection Services properties 139
Clustered servers 249 Collection task 135
Clustering architecture 14 Collector task 112
COLLECT task 88 COLSRV400 task 88, 134–135
Collecting statistics 474 Command
Collection Services 27, 88, 129, 134 ADDENVVAR 235
*MGTCOL 135 ADDJOBSCDE 384

620 Domino 6 for iSeries Best Practices Guide

ADDMEDIBRM 343 WRKSHRPOOL 216
ADDMLMBRM 343 WRKSYSACT 184, 583
ADDPEXDFN 587, 605 WRKSYSSTS 172, 210, 212, 214–215, 575, 578,
ADDTCPRTE 598 600
CHGATR 218 Command abbreviations 71
Attributes 220 Command ENDJOB 178
CHGJOB 187 Command line interface 71
CHGSYSVAL 210–211, 600 Command RUNQRY 151
CHGTCPA 209, 593 Command WRKDOMCSL 178
CRTCLS 196 Command WRKJOB 180
CVTDIR 218 Commercial Processing Workload See CPW
DMPCLLSTK 587 CommonStore for Lotus Domino 64
DMPJVM 579 Communication lines 467
DMPSVRSTKS 575, 578 Communication resets
DSPLNK 198, 222 Linger value 208
DSPLOG 575, 579, 582, 587 Communications trace 207
DSPLOGBRM 334, 348 COMPACT 48, 84, 114, 253
DSPMSG 575, 579, 582, 587 Copy-style 69
DSPPTF 576, 579, 582, 587 In-place 69
DSPSYSVAL 600 COMPACT -B 48
ENDCMNTRC 208, 591, 596 COMPACT task 67, 69, 88, 170
ENDDOMSVR 339, 581 Compute Intensive Workload (CIW) See CIW
ENDJOB 581 Compute Intensive Workload See CIW
ENDSBS 581 Concurrent users 467, 472
GO CLEANUP 181 Concurrently active users 499
GO DISKTASKS 180 Configuration problems 589
GO PERFORM 143 Activity level 598
GO SAVE 581 ARP storms 593
Initialize Tape 291 Checksum 590
INZBRM 331 Daylight Savings Time 600
NETSTAT 575, 578, 587, 590 Domino performance 589
NETSTAT *CNN 201 Activity level 598
PRTCMNTRC 208, 591, 596 ARP storms 593
PWRDWNSYS 581 Checksum 590
restore 385 Daylight Savings Time 600
RMVLNK 181 Ineligible jobs 598
RUNDOMCMD 68 Server based mail rules 606
RUNQRY 150 Ineligible jobs 598
SAV 296, 334 Server based mail rules 606
SAVDOMBRM 296 Configure Domino Server 84
SAVSAVFBRM 300 Consistent ECL 41
STRCMNTRC 208, 591, 595 Content filtering 406, 409
STRMNTBRM 331 Content Management 64
STRPEX 588, 605 Content security 406, 409
STRRCYBRM 330 Continuous availability 109
STRSST 176, 576, 579, 582 Control user workspace 106
Work with Job Schedule Entries 283 CONTROLLER task 88
Work with System Status 288 Controlling subsystem 267
WRKACTJOB 184, 211, 575, 578, 583, 603 Convert Directory API 218
WRKCTLGBRM 330 Convert Directory command 218
WRKDOMCSL 578 Corel WordPerfect 12
WRKDSKSTS 229 Corporate messaging system 57
WRKJOB 189 CPU 598
WRKJOBSCDE 384 Domino jobs 122
WRKLNK 223, 345 System 122
WRKLNKBRM 347 total 584, 603
WRKOBJ 226 CPU instructions 497
WRKOBJOWN 226 CPU intensive transactions 500
WRKSAVFBRM 300 CPW 456, 464, 492–493, 497, 500
WRKSBMJOB 225 Non-Domino processor CPW 493

Index 621
Create CL program 87 Include/exclude processing options 367, 376
Create class 196 Incremental backup 253, 375, 378
Create Save File command 280 Incremental backup strategy 382
Critical Fixpack 277 Daily incremental backups 382
Cross-certification 40 Weekly inactivation of archived transaction logs
CRTSAVF 280 383
CVTDIR 218 Weekly selective backups 382
incremental command 381
Incremental daily backups 381
D Installation 357
DASD 175, 197, 227, 466 Instance 363
Permanent storage utilization 175 Logging information 397
Spooled files 181 Management Class 396
Temporary Domino files 181 Offline status 385
Transaction logs 183 Partitioned Domino servers 372
Temporary storage utilization 175 Performance
Data backup 109 Network 397
Data integrity 252 TCPBUFFSIZE 396
Data Protection for Domino 243, 249–250, 254, Point in time recovery 251, 382
257–258, 353 Preferences configuration 376
Activate databases restore command 385
activatedbs command 389–390 Restore databases
APPLYLOGS parameter 391 Activation 389
query pending command 389 Parameters 386
Apply updates from transaction logs 385 ACTIVATE 387
Architecture 356 INTO 386
archivelog command 379, 381 New filename 386
Backup strategy 381 PICK 388
Backups with circular or linear transaction logging PICK=SHOWALL 389
382 PIT 386
Backups without transaction logging 382 Restore a specific version 386
Commands 356 To point in time 391
Configuration 361 Restore Domino database 384
TCPBUFFSIZE 396 Sample configuration files 398
Configuration files 363–364 Scheduled operations 383
Database activation 385 Scripts 383
Database backup Incremental backup 401
Incremental/Selective 355 Log archiving 401
Disaster recovery 393 Log inactivation 401
domdsm.log file 398 Selective backup 401
domdsmc 356 scripts 398
domdsmc restorelogarchive command 394 Selection formulas 376
dominstall program 362 Selective backup 375, 377
Environment variables 368 selective command 381
.profile file 368 Set up additional instances 373
DOMI_CONFIG 368 Subdirectory processing 376
DOMI_LOG 368 Suffix .dad 385
DSMI_CONFIG 369 Weekly full backups 381
DSMI_LOG 369 Data protection for Domino
LANG 369 Incremental backups 251
PATH 369 Data Protection for Domino configuration 396
QIBM_MULTI_THREADED 369 Data Protection for Domino configuration files 399
export command 368 domdsm.cfg 364
set 368 dsm.opt 364
EXCLUDE statement 367 dsm.sys 364
Full daily backup strategy Preferences file 364
Daily incremental backups 382 Storage Manager client options file 364
Daily selective backups 382 Tivoli Storage Manager system options file 364
Weekly incremental backups 382 Data Protection for Domino instance 372
Full daily backups 381–382 Data Protection for Domino operations 396
INCLUDE statement 367

622 Domino 6 for iSeries Best Practices Guide

Data Protection for Domino scripts 383 Debugging problems 573
domarc 383 Debugging ScanMail tasks 450
domina 383 DECS 460
dominc 383 DECS task 88
domsel 383 Dedicated backup server 250
Data reliability 228 Dedicated Server for Domino 20, 464, 486, 493, 496
Data retention rules 360 Delivery failure notification 60
Data transfer 27, 151 Denial of service attack 407
Data Transfer From iSeries Server 151 DESIGN task 88
Database access method 493 Determine transaction log usage 290
Database ACLs developerWorks
Administrators group 40 Lotus 277
Anonymous access 40 Digital signature 39
Database creator 40 Directory Assistance and Directory Catalog 99
-Default- access 40 Directory Catalog 51
Designer access 40 Directory synchronization 15, 99
LocalDomainServers access 40 Disabling Routing of Mail to Groups 413
Manager access 40 Disaster recovery 395
User types 40 Disconnected users 474
Wildcard entries 40 Disk % Busy 229
Database activation 385 Disk arm
Database activity logger 88 % busy 198
Database buffer 234 Disk arms 197, 229, 466, 494
Database copy 285 Disk constrained 229
Database ID 253 Disk drive requirements 499
Database instance ID 68, 253, 256, 350, 375, 381, 385, Disk I/O 198, 220
395 Disk protection
New 253 Device parity protection 270
Database maintenance 68 Mirroring 270
Database ODS 69 RAID 270
Database ownership 292 Disk space 175
Database quota 90 Disk Space Tasks menu 180
Warning threshold 60 Disk space utilization 67
Database quota actions 60 Disk units balancing 200
Database replica 285 Display disk usage 288
Database usage tracking tool 96 Display Domino Console 75
Database.Database.BufferPool.Maximum.Megabytes DMPCLLSTK 587
232 DMPJVM 579
Database.Database.BufferPool.Peak.Megabytes 232 DMPSVRSTKS 575, 578
Database.Database.BufferPool.PerCentReadsInBuffer DNS Blacklist filters 413
232 DNS host names 42
Database.DbCache.CurrentEntries 232 DNS See Domain Name Server
Database.DbCache.HighWaterMark 231–232 Document management system 59
Database.DbCache.MaxEntries 232 Domain Name Server 205
Date and time customization 44 domdsm.cfg 364, 366, 374, 376, 399
DateOrder 44 Configuration Parameters
DateSeparator 44 DATEFormat 367
Daylight Savings Time 600 NOTESIniPath 366
DB2 database processing 486, 493 SUBDir 367
DB2 operations 497 domdsmc 356
DB2 UDB 486 query adsmserver 371
DB2 Universal Database 27 query domino 371
DB2/400 Group PTF 22 query preferences 367
DbDirMan 181 domdsmc archivelog 380
DBIID 68, 253, 256, 350, 375, 381, 385, 395 domdsmc selective 377
New 253 Domino 6 for iSeries
DC9250 260 Supported HTTP servers 108
Dead mail 66 Domino 6 for iSeries HTTP server 109
debug 573 Domino 6 installation 23
DEBUG_MONITOR 609 Domino 6 Web Administration Tool 66

Index 623
Domino 6.0.3 247 Batch 25
Domino 6.5 247 Domino Server Installation wizard 24
Domino Access for Microsoft Outlook 8 LODRUN 24
Domino Access for MS Outlook 473 RSTLICPGM 24
Domino Administrator 8 Tips 25
Domino agents 103 Domino installation prerequisites
Domino anti-spam features 413 Authorization 23
Domino APIs 258 Domino instance 470
Domino application Domino jobs 77, 88, 189
Complexity rating 478 ADMINP 88
Domino application sizing 483 AMGR 88
Domino applications 468, 483, 528 BILLING 88
Domino backup strategy 375 CALCONN 88
Domino C API Toolkit 16 CLADMIN 88
Domino CA 53 CLDBDIR 88
Domino Change Manager 112 CLREPL 88
Domino cluster 89, 249, 344 COLLECT 88
Benefits 89 COLSRV400 88
Database replicas 90 COMPACT 88
Failover 89 CONTROLLER 88
Mail databases 90 DECS 88
Mail replicas 90 DESIGN 88
Performance impacts 90 EVENT 88
Workload balancing 89 FIXUP 88
Workload distribution 89 HTTP 88
Domino clustering 10, 34, 258, 475, 508, 528 LOGASIO 88
High availability 458 QNNINBRM 88
Load balancing 458 QNNINSTS 88
Domino console REPLICA 88
QUIT 267 REPORT 88
Domino console commands 71 ROUTER 88
Domino data directory 15, 223, 245, 248 Run priority 187
Ownership 278 SCHED 88
Domino data directory size 289 SERVER 88
Domino database size 290 SMTP 88
Domino Designer 8 STATLOG 88
Domino Directory STATS 88
$ServerAccess view 51 UPDALL 88
$Users view 51 UPDATE 88
Domino Directory maintenance 48 Domino libraries 245
Domino Directory management 48 QNOTES 244
Domino directory services 48 QNOTESAPI 244
Domino Document Manager 91 QUSRNOTES 244
Domino domain 71 Domino Mail Manager 64
Domino Enterprise Connection Services 88 Domino Mail Manager See ISSL Domino Mail Manager
Domino environment documentation 48 Asset
Domino files in IFS 246 Domino maintenance 103
Domino for iSeries models 487, 497 Domino maintenance schedule 65
DB2 processing 497 Daily tasks 65
Domino for iSeries server properties 28 Monthly tasks 68
Domino for iSeries Web site 276 Weekly tasks 67
Domino hangs 574 Domino Maintenance Updates See MU
Domino HTTP hang 578, 580 Domino memory management 230
Domino HTTP server 108 Domino multi-versioning 9
Domino IFS directories Domino multiversioning 25
/QIBM/ProdData/GUIplugin/LOTUS.DOMINO 244 Domino naming convention 11
/QIBM/ProdData/LOTUS/NOTES 244 Domino objects 244
/QIBM/UserData/LOTUS/NOTES 244 Data queues 244
Domino implementation 244 Job queues 244
Domino installation Subsystems 244

624 Domino 6 for iSeries Best Practices Guide

 User spaces 244 Backup and restore activities 115
Domino partition 4, 9, 11, 249, 470, 474, 518, 550 Emergency stopping and starting 114
Domino performance Monitoring applications 115
Configuration problems 589 Monitoring hardware 115
Activity level 598 Scheduled stopping and starting 115
ARP storms 593 Domino server configuration 245
Checksum 590 Domino server console 75
Daylight Savings Time 600 Domino server console command
Ineligible jobs 598 SHOW STAT 170
Server based mail rules 606 Domino server consolidation 20, 461, 499
Documents in INBOX 238 Domino Server Controller
Large mail file size 238 Start 74
Number of documents in database 238 Domino server crash 182, 228, 581
Domino platform statistics 500 Startup time 50
Domino plug-in 28, 244 Domino server hang 574, 577
Domino prerequisites Domino Server Installation wizard 24
BRMS Group PTF 22 Domino server jobs 73
DB2/400 Group PTF 22 Domino server monitoring checklist 65
Group PTFs 22 Domino server ports 201
IBM HTTP Server for iSeries Group PTF 22 Domino server services 13
Individual and group PTFs 21 Domino Server Setup wizard 15
Java Group PTF 22 Domino server statistics 129
MU Domino server topology 5
PTFs 21 Domino Simple Network Management Protocol agent
Software requirements 21 111
System requirements 21 Domino solutions 471
Domino replication 249, 258 Domino statistics 88
Domino security Domino statistics reporting 461
Cross-certification 40 Application servers 461
Domino public keys 41 Cluster report 461
Domino server access 40 Message size 461
ECL 41 Net TCP MB sent and received 461
Consistent 41 Network statistics 461
Event Handler 41 Number of dropped sessions 461
HTTP 42 Number of replication failures 461
IMAP 42 Peak number of users 461
Internet client authentication 42 Total number of mail messages 461
LDAP 42 Transactions per minute 461
Passthru server 40 Domino subsystem 470, 574
Password management facility 41 Domino subsystem description 244
Password protection for console 40 Domino tasks
Password quality level 41 COLSRV400 134–135
POP3 42 Domino templates 57
Roles Domino user profile
Administrator 38 QNOTES 244
Certificate authority administrator 39 Domino user type
Database administrator 38 3x heavy 457
Full Access Administrators 38 Casual 457
Full remote console administrator 38 Heavy 4, 457
Registration authority administrator 39 Light 4
Restricted system administrator 39 Medium 4
System administrator 38 Moderate 457
View-only administrator 38 Domino version 460
Smartcard 40–41 Domino Web Access 8, 109, 473, 527, 540
Smartcard lock 42 Maximum message size 62
Trusted server list 41 Domino Web Access user 4
Workstation data security 41 Domino Web applications 108
Domino server Domino Web Engine section 62
Administration tasks Domino Web server log 69
Application maintenance 116 Domino work management 230

Index 625
Domino workloads 464 Attachment handling 411
Domino.Doc 58 Inappropriate e-mail content 411
Domino.Doc See Lotus Domino Document Manager Policy violations 412
Domino.Doc See Domino Document Manager Sensitive information 411
Domino.Doc See IBM Lotus Document Manager User education 411
domino_classes file 196 Encryption 118
dominstall 362 Encryption keys 39
DOMLOG.NSF 69 End communications trace 591, 596
DOS attack 406–407 End Domino server
Downtime 109 Wait time 282
DPAR See Domino partition End Subsystem 81
DPOOL 233–234 ENDCMNTRC 591, 596
Allocation size 234 ENDDOMSVR 74, 581
Fragmentation 234 ENDJOB 581
Memory allocation 234 ENDPEX 605
DRDA 486, 493 ENDSBS 81, 581
DSD 464, 486, 493, 496 Enterprise backup solution 64
DB2 capacity 487 Enterprise Document Management 64
dsm.opt 364, 366, 374, 399 Enterprise Mail Management policy 58
Configuration Parameters Enterprise Mail Management strategy 64
Servername 366 Entity tags 239
dsm.sys 364, 373, 399 Environment variable 234
Configuration Parameters 364 Environmental planning
COMMethod 365 Actual Bandwidth Requirement 6
NODEname 365 Effective Bandwidth Requirement 6
PASSWORDACCESS GENERATE 365 Network bandwidth 6
PASSWORDDIR 365 Peak user concurrency 6
Servername 365 Required Per-User Bandwidth 6
TCPPort 365 Server placement 5
TCPServeraddress 365 Site distribution 5
DSPDOMCSL 75 User distribution 4
DSPLNK 222 User topology 4
DSPLOG 575, 579, 582, 587 Workload balance 4
DSPMSG 575, 579, 582, 587 Environmental planning checklist 4
DSPPTF 277, 576, 579, 582, 587 ETags 239
DSPSFWRSC 276 Event Handler 38
DSPSYSVAL 600 EVENT task 88
DST_Begin_Date 44 Exception policy 17
DST_End_Date 44 Execution Control List 17
DSTLaw 44 Execution control list See ECL
Dynamic priority scheduler 193 export command 368, 370
Dynamic priority scheduler See System value Extended ACL 105
DYNPTYSCD Extended administration server
Dynamic route tables 595 Concept 104
DYS 65 Namespace 104
Extended Directory Catalog 99
Extended directory catalog See EDC
E
ECL 17, 41, 56
Consistent 41 F
ECL settings 108 Fail over mode 547
EDC Fail over mode scenario 480
Edit File 83 Failover 34, 89
Edit NOTES.INI 83 Fault tolerance 14
EDTF 83, 289 Faulting 122, 173
Effective Bandwidth Requirement 6 Fax for Domino See IBM Integrated Domino Fax for
EICAR virus file 440 iSeries
e-mail Fibre channel 110
Content filtering 409 File directory structure 15
e-mail journaling 406 File Protection document 42
e-mail usage policy 411 Files preferences 71

626 Domino 6 for iSeries Best Practices Guide

Find Domino objects 291 Host table 205
Firewall protection 410 HotFix 275, 277
Firewall/VPN 415 Remove 277
First Install Customer Assistance 23 HSL 19, 90
Fix corrupted database 88 HTML 13
FixPack 276 HTTP 34, 42
FIXUP task 67–68, 84, 88, 114, 252 Browser-side caching 239
Flushing 252 ETags 239
FTP Persistent connections 239
Put 286 Web agents 239
FTP server gateway 422 HTTP gateway 422
FTSearch Limit 12 HTTP hangs 574
Full Access Administration 38 HTTP hit rate 486
Full daily backups 381–382 HTTP response header rules 239
Full system recovery 250 HTTP response headers 239
Full text index HTTP rules 239
Search transactions 458 HTTP server 238
Full text indexing 12 Command caching 238
Encrypted documents 13 HTTP services 103
Full text indexing of attachments 12 HTTP task 88
Adobe Acrobat PDF 12 HTTP thread logging 183
Corel WordPerfect 12 HTTP/1.1 239
HTML 13 HTTPS 34
Lotus 1-2-3 12 Hub server 97
Lotus Freelance Graphics 13 HVLPTASK 192
Microsoft Excel 12
Microsoft PowerPoint 13
Microsoft Word 12 I
Full text search 59 I/O processors 467
IBM BEST/1 464
IBM Business Partner 484
G IBM Business Partner Web site 65
Gateways IBM ClusterProven 248
FTP server 422 IBM Content Manager portfolio 64
HTTP 422 IBM Eserver Workload Estimator 463
SMTP 422 IBM HTTP Server (powered by Apache) 108–109
GetTimeOfDay procedure 604 IBM HTTP Server for iSeries Group PTF 22
Global AntiVirus Options 418 IBM Integrated Domino Fax for iSeries 91
Global Text Retrieval See GTR search engine IBM iSeries Access for Windows 142, 151
GO LICPGM 277 Selective Setup 124
GO SAVE 266, 581 IBM iSeries SupportLine 200
GO SAVE option 22 247 IBM Lotus Discovery Server 64
Group PTFs 21–22 IBM Lotus Document Manager 64
GRTOBJAUT 280 IBM Software Services for Lotus
GTR search engine 12, 101 ISSL 93
GUI interface 72 IBM Software Services for Lotus See ISSL
IBM Support 180
IBM Support Library Tools (QSPTLIB) 592, 597
H IBM SupportLine 227
Hangs IBM Tivoli Analyzer for Lotus Domino 111–112
Domino server 574, 577 IBM Tivoli Storage Manager 64, 243, 250, 354
HTTP server 574, 578, 580 Configuration for Data Protection for Domino 359
Hardening 252 Node 359
Hardware planning 18 Policy Domain 360
Health statistics 112 Storage devices 354
Heavy user 508, 528 Storage repository 354
High availability 109 IBM Tivoli Storage Manager application program interface
High CPU utilization 583, 587, 603 (API) 355
SERVER task 606 IBM Tivoli Storage Manager for Mail
History log 264 Data Protection for Lotus Domino for OS/400 353
Host Publisher 27 Data Protection for Lotus Domino for OS/400, Version

Index 627
 5.2.0 243 Ineligible 212, 598
IBM Tivoli Storage Manager for Mail 5.2 Data Protection Ineligible jobs 122, 183, 598
for Lotus Domino 355 Information Security Policy 118
IBM Tivoli Storage Manager for Storage Area Networks Initialize tapes
354 Volume identifier 291
IBM Tivoli Storage Manager scheduler 383 iNotes Web Access
IBM Tivoli Storage Manager server 299–300, 309, 320, Storing ID file 54
323, 329, 343 iNotes Web Access See Domino Web Access
Activity Log 398 Install Shield 277
File space 396 Installation
Password access option 365 Domino code 277
IBM Tivoli Storage Manager system 395 Installation methods 24
IBM Workload Estimator See WLE Installation recommendations 24
IBM_TECHNICAL_SUPPORT subdirectory 182 Instance 470
ICA client 109 Integrated file system 270
ICM 89 Integrated servers 307
ID file 52 Intellectual capital 57
ID file location 246 Intended Recipient Controls 413
ID file naming standards 52 Interactive Card 122
ID files Interactive workload 191, 217
Manage 54 Internal data transfer band width 499
Recover 55 Internet Authentication 42
Store 54 Internet certificate 39
ID recovery 55 Internet client authentication 42
IFS 27, 107, 218, 244, 246, 270, 285–286 Internet Cluster Manager See ICM
OS/400 V5R2 changes 218 Internet content security 422
QDLS 218 Internet Information Services 108
QOpenSys 218 Internet keys 55
QSYS.LIB 218 Internet Mail Router 88
root 218 Internet password 53
Storage option Internet Protocol version 4 See IPv4
*MINIMIZE 175 Internet Protocol version 6 See IPv6
Stream file format Internet protocols 13
*TYPE2 218 Internet Site document 42
Stream files Intrusion detection 415
Main storage option 218 INZTAP 291
UDFS 218 IP address 204
IIOP protocol 42 IP routing tables 34
IIS 108 IPL 175, 209, 211, 215
IMAP 8, 35, 42 IPv4 34
IMAP mail 473 IPv6 34
inactivatelogs command 380 iSeries Access Family 27
Inbound Cluster Replication 475, 539 iSeries Access for Web 27
Inbound Cluster Replication Application Attributes 478 iSeries Access for Windows 26, 54, 300
Inbound Cluster Replication Mail Attributes 477 iSeries and Domino administration
Inbound Connection Controls 413 Conflicting interests 114
Inbound Sender Controls 413 iSeries and viruses 411
Incremental backup 375 iSeries Apache Server 99
Incremental backup strategy 382 iSeries architecture 107, 500
incremental command 378, 381 iSeries benchmarks 468
Incremental daily backups 381 iSeries Client Access Family 27
Incremental save 228 iSeries Collection Services 111
Incremental virus scanning 416 iSeries environment variable 234
Independent ASP 228, 248 iSeries for Domino 20
Independent Computing Architecture 109 iSeries HTTP server 99
Independent Software Vendors 484 iSeries IFS
Index capacity 12 Map network drive 33
Indexer task 88, 170 iSeries Information Center Web site 18
Indexing 231 iSeries Job Scheduler 282–283, 294, 302, 304, 313, 330,
Indexing mail files 59 334

628 Domino 6 for iSeries Best Practices Guide

iSeries jobs 188 Job run priority 184, 187
iSeries memory management 230 Job Scheduler for iSeries 250, 383
iSeries Navigator 26, 45, 54, 111, 124, 135–136, 182, Job transition data 183
194, 213, 221, 223, 291, 293, 300, 384, 594 Active->Inel 183
Administrate Domino server 28 Max Active 183
Backup, Recovery and Media Services Tasks 302 Wait->Inel 183
BRMS plug-in 29, 300 Job types 193
Configure Domino server 28 Joblog 264
Create OS/400 user profile and Domino user 54 Jobs
Domino plug-in 244, 300 Batch 193
Environment - My Connections pane 301 Interactive 193
Getting started 29 Multithreaded 210
BRMS features 30 Jobs in system 210
Domino features 29
iSeries Performance Tools plug-in 27
Modify NOTES.INI 28 K
My Tasks pane 302 Kerberos 27
Register Domino users 28
Run Command 85 L
Start Domino server 28 L2 cache 498
Stop Domino server 28 Language Pack 26, 43
View NOTES.INI 28 Large Domino deployments 104
iSeries Navigator Domino functions 27 Large Domino environments 104
iSeries Navigator Domino plug-in 28 LC LSX 460
iSeries Navigator plug-in 28, 45 LDAP 15, 35, 42, 99
iSeries Navigator plug-in installation 28 ACL group authorization 52
iSeries NetServer 285 Client authentication 52
iSeries ODBC driver 156 ldapsearch 52
iSeries operator 113 LDAP C API Toolkit 52
iSeries performance adjuster See System value LDAP services 12
QPFRADJ ldapsearch 52
iSeries performance adjustor 214 LDD Today 57
iSeries Performance Tools (5722-PT1) 135, 184, 187, Legal liability 58
190, 588 LEI 6.5 460
iSeries Single Logon 54 LEI See Lotus Enterprise Integrator
iSeries sizing 464 Library QPFRDATA 135
iSeries storage management 228 LIC 212, 224
iSeries System Service Tools LIC See Licensed Internal Code
TASKINFO 176 Licensed Internal Code 173, 248
iSeries work management 230 Lightweight Directory Access Protocol See LDAP
ISSL 64 Line configuration
ISSL Domino Mail Manager Asset 64 Duplex 207
ISV 484 Maximum frame size 207
ISV applications 484 Linger value 208
IT security policy 411 Linux 243
IXA 64 LNT0102 245
IXS 64 LNT0993 26
Locale setting 25, 44
J Localization
Java applet 42 NOTES.INI settings 44
Java applications 240 Log Analysis 66
Java Domino Console 74 Log extents 256
Java Group PTF 22 Log file 69
Java Server Controller 261, 267 LOG.NSF 69, 582
JDBC 486, 493 LOGASIO task 88
Job Logical partitioning See LPAR
Ineligible 598 Logical partitions 247
QDOMINO 135 Lotus 1-2-3 12, 151
Job attributes 189 Lotus Business Partner 484
Job name 188 Lotus Domino and Notes Benchmarks 467

Index 629
Lotus Domino APIs 355 Maximum size 60
Lotus Domino Document Manager 9 Send mail to large number of users restriction 63
Lotus Domino server backup API 375 Mail file owner access 53
Lotus Domino Web Access 469 Mail file policies 97
Lotus Enterprise Integrator 91, 98 Mail file quota 59, 527
Lotus Extension Toolkit 245 Mail file replicas 53
Lotus Freelance Graphics 13 Mail file retention 97
Lotus Instant Messaging 95, 474, 521 Mail file size 12
Lotus Instant Messaging and Lotus Web Conferencing Mail policy implementation 59
422 Mail problems 66
Lotus Instant Messaging and Web Conferencing 9, 11, Mail quotas 508
35, 37, 91, 98, 508 Mail retention policy 12, 57
Lotus Knowledge Base 276 Mail router 88
Lotus Sandbox 65 Mail rules usage
Lotus servers 250 Check for 607
Lotus software compatibility 9 MAIL.BOX 60, 66, 70, 255, 414, 428, 434–435, 441, 446,
Lotus Software for iSeries Compatibility Guide 20, 91 606
Lotus Support 573 MAIL.BOX maintenance 68
Lotus Team Workplace 9, 27, 91, 98, 422 Main storage 212, 228, 599
Lotus Workflow 91 Maintenance 65
Lotus Workplace 95 Maintenance tips 103
LOTUS_SERVERS 278 Malicious code 406
Low priority delay notification 62 Management Central 111, 123, 301
Low priority messages 62 Central system 124
LPAR 89, 91, 135, 192, 218, 233, 247, 456, 464, 474, Domino server monitor 129
489, 554, 559 Endpoint systems 123–124
Active processors 184 Job monitor 129
Current processing capacity 192 View Event log 133
Multiple Lotus products 9 Job monitor status 133
Resources 89 Customize view 133
SMTP mail routing 9 Manage multiple iSeries systems 123
LPAR requirements 9–10 Monitor 125
LPAR Validation Tool 10 Monitor Domino server jobs 129
LVT See LPAR Validation Tool Monitor metrics 126
Set threshold 127
Settings 126
M Monitor real-time system performance 125
MAC address 204, 594 Monitor type 125
Changing 596 Monitors
Macro virus 407 Start 128
Mail addressing 52 Stop 129
Mail and Calendar Users See MCU Performance metrics 125
Mail and Calendaring Users 498, 500 Setup 124
Mail and Calendaring users See MCU Share a monitor 132
Mail database policy settings Sharing 124
By user type 61 System group 124
Mail environment Management Central Job Scheduler 325
Control 57 Management Class 360, 396
Mail file index 59 Management Collection Object 134, 140, 142
Mail file management 57 Management Information Base 112
Active mail 59 Map network drive 285
Archive mail file 59 Mass mailing 107
Attachment handling 61 Maturation of Notes users 7
Content 58 Maximum Internet Access 103
Document age 58 Maximum mail file size 60
Document size 58 Maximum message size 62
Document type 58 Maximum Post Data 62
Low priority messages 62 MB 12
Mail file quota 59 MCO See Management Collection Object
Mail file size 58 MCO See Management Collection Object
Maximum message size 62

630 Domino 6 for iSeries Best Practices Guide

MCU 456, 464, 497–498, 500–501 Network bandwidth 6
MCU metric 456 Network compression 508, 528
Media and Storage Extensions 350 Network configuration 200
Media information 294 Network diagram 526
Memory constrained environment 175, 220 Network interface cards (NIC) 594
Memory pools 122 Network port compression 7
Memory pools See Storage pools Network routing 593
Memory requirements 499 Network switches 204
Memory rich environment 220 Network traffic
Message Load balancing 593
LNT0993 26 Networking
Message transfer times 68 Route table 594
MHz 499 NIF pool 174, 233
MIB 112 NIF See Notes Index Facility
Microsoft Excel 12 nlogctrl.lfh 394
Microsoft Excel 2002 155 NLS 43
Microsoft Exchange 422 Locale setting 44
Microsoft Internet Explorer 51 Web preferences 44
Microsoft PowerPoint 13 Non-english language versions 26
Microsoft Query 160 Non-logged Domino databases 381
Microsoft Query Wizard 158 Normal operations 547
Microsoft Windows 2000 422 Normal operations scenario 480
Microsoft Word 12 Notes 6 client environment administration 105
Migration 94 Notes 6 client installation options 106
MIME-encoded documents 447 Notes 6 client user 4
Mirroring 248 Notes Index Facility 230
Mixed release environment 57 Notes Log database 66
Moderate mail user 498, 508, 528 Mail Routing Events view 66
Monitor CPU utilization 184 Replication events views 66
Monitor jobs 78 Notes Named Network 90
Monitor system performance 78 Notes password 53
Monitoring checklist 65 Notes System Diagnostics files (NSDs) 182, 581
Monitoring preferences 71 NOTES.INI 279, 441
Monitoring Results database 112 Debug_Capture_Timeout 182
Monitoring tools 111 SERVER_MAX_CONCURRENT_TRANS 190
MPG Performance Navigator 464 ServerTasks 135
MPL See Multiprogramming Level (MPL) NOTES.INI debug parameter 609
MSF 99 DEBUG_MONITOR 609
MTA_SERVERS 99 NOTES.INI parameter
MTU size See Line configuration NSF_BUFFER_POOL_SIZE_MB 230
Maximum frame size PercentAvailSysResources 233
MU NOTES.INI variables 435
Multilingual database support 43 Notes_SHARED_DPOOLSIZE 234
Multiple releases 247 NotesBench 466, 468, 480, 482, 498, 501
Multiprogramming Level (MPL) 599 R5Mail 467
Multithreaded 189 User 468
Multi-user 97 Notrix 460
Multi-user workstation 8 NRPC 606
Multi-version capable Domino release 277 NSD files See Notes System Diagnostics files (NSDs)
Multi-versioning 9, 247 NSD objects 70
NSF Buffer pool 174, 230
NSF_BUFFER_POOL_SIZE_MB 174, 214, 230
N NSF_DBCACHE_MAXENTRIES 231
Namespace 104 Number of threads 212
National language support 43
Netscape Mail 51
NetServer 285 O
NETSTAT 575, 578, 587, 590 Object signature validation 26
NETSTAT *CNN 123, 201 Objects not saved 292
Idle Time 201 ODBC 486, 493
Network adapter configuration 36 ODBC driver 156, 460

Index 631
ODS 69, 252 SHOW SERVER 123
ODS version 101 SHOW STAT SEM 123
OLAP Cube 160 Storage pools 122
Online backup 248 Performance projection 466
Operating system time 600 Performance Report 143
Operations Navigator 27 Performance tests 466
Organization 104 Performance tuning
Organizational groups 113 iSeries 172
Organizational responsibilities 113 Allocate system resources 172
Organizational roles 113 CPU 172
Organizational unit 104 DASD 172
Original IOA/IOP 490 Disk arms 172
OS/400 APIs 34 How to 172
OS/400 backup and recovery functions 508 IFS 172
OS/400 Collection Services 134, 500 Job attributes 172
OS/400 library system 244 Main memory 172
OS/400 LPAR 9 Memory 172
OS/400 object ownership 33 Run Domino in dedicated storage pool 173
OS/400 Operational Assistant System values 172, 209
Automatic cleanup 181 Work with System Status 172
System cleanup 210 WRKSYSSTS 172
OS/400 save and restore commands 249 iSeries performance adjuster 172, 212, 215
OS/400 System Distribution Directory 15 Memory constrained environment 175
OS/400 user profile 53 NIF pool 174
OS/400 V5R2 Performance Capabilities Reference Guide NSF Buffer pool 174
490 PercentAvailSysResources 174
Output queue Processor multi-tasking 217
Clear 210 QPFRADJ 172, 212, 215
Storage pools 173
Non-DB Paging 173
P Paging and faulting 173
Page fault 220 Reasons for paging and faulting 174
Page out 183 Permanent storage 180
Page thrashing 599 Personal Communications 27
Paging 122 PEX definition 587
Paging and faulting 233 Planning your Domino environment 4
PASE 354 Platform Statistics 231
Password expiration 56 PM eServer iSeries 464
Password quality policy 56 PM/400 27, 135, 137, 139
Password synchronization 54 Point in time 355
Password verification 56 Point in time recovery 382
Password-management options 56 Policy 36, 105
PDM 87 Archive settings 17
Peak period 500 Desktop 106
Peak period CPU utilization 526 Desktop settings 17
Peak user concurrency 6, 508 Exception 17
Pending mail 66 Explicit 17
PercentAvailSysResources 109, 174, 233 Mail retention 57
Percussion 65 Organizational 17
Percussion ServerAdmin Plus 65 Override settings 17
Performance considerations 111 Registration settings 17
Performance Explorer (PEX) trace 605 Security settings 17
Performance management 125 Setup settings 17
Performance monitoring Policy compliance management 415
Checklist 122 Policy Domain 360
CPU utilization 122 Backup Copy Group 360
Ineligible jobs 122 Data Protection for Domino
Memory pools 122 Policy Domain 396
Paging and faulting 122 Management Class 360
QMAXACTLVL 122 Policy viewer tool 18
Run priority 122

632 Domino 6 for iSeries Best Practices Guide

Policy-based administration 105 QNOTES 44, 244, 278
POP3 8, 35, 42, 201 QNOTESAPI 244
POP3 mail 473 QOpenSys 218
Port 110 35 QOPT
Port 1352 35 IFS
Port 143 35 QOPT 218
Port 1516 35 QShell 356, 362
Port 1533 35 QShell script 383–384
Port 25 35 domarc 383
Port 389 15, 35 domina 383
Port 443 34 dominc 383
Port 636 35 domsel 383
Port 80 34 Execute 383
Port conflicts 13 QSYS.LIB 218, 270
Ports 34, 201 QSYSOPR messages 267
In use by Domino 201 query domino 376
LISTEN state 201 Query/400 144, 486, 493
POWER4 464, 466, 471, 517, 534 QuickPlace 422
PPP over Ethernet See PPPoE See also Lotus Team Workplace
PPPoE 34 QuickPlace See Lotus Team Workplace
Primary language 277 QUSRNOTES 244
Print Performance Report 143 QUTCOFFSET 603
Private pool 233 QVFYOBJRST system value 26
Process 598 QYPSPFRCOL See Collection Services job
Processor capacity 122
Processor clock speed 499
Processor CPW (Commercial Processing Workload) 493 R
Processor multi-tasking 217 R5Mail workload 467
Processor resources 212 RAID-5 248, 528
Program temporary fixes See PTFs RAID-5 disk protection 508
Programming Development Manager 87 Real-time alerts 112
Proxy ARP 34 Real-time replication 475
Proxy server 108 Recover ID files 55
PRTCMNTRC 591, 596 Recovery
PTF installation 115 Common problems 292
PTFs 21, 99, 260 Documents 286
For temporary storage 176 Domino data directory 271
PWRDWNSYS 581 Domino data directory from incremental backup 274
Domino database from incremental backup 275
Domino licensed program 275
Q Entire system 271
QAPMDISK 135 From daily incremental backup 274
QAPMDOMINO file 167 From Incremental - Cumulative 274
QBASACTLVL 173 From incremental backup 273
QBASE 267 From save file 280
QBASPOOL 173 Mail database 272
QBATCH job queue 284 Save file 280
QCTL 267 Specific Domino database 272
QDLS 218 Subdirectory from incremental backup 275
QDOMINO job 135 While Domino server active 286
QDOMINO603 247 Recovery Point 254
QDOMINO604 247 Recovery server 67
QDOMINO650 247 Recovery time 14
QDYNPTYADJ 184, 187, 192 Red Hat 422
QDYNPTYSCD 193 Redbooks Web site 615
QIC-2GB 260 Contact us xxv
QMAXACTLVL 122, 599 Reduce mail routing 5
QMCHPOOL 173 Reduce replication 5
QNNINBRM job 183 Refresh database design 88
QNNINBRM task 88, 346 Regional preferences 44
QNNINSTS task 88, 197 Registered users 472, 499

Index 633
Registration preferences 71 Option 23 270
Repair corrupted database 68 Save system data 270
Replica ID 253 Save user data 270
REPLICA task 88 Save Save File Data command 281
Replication hub 66 Save System command 267
Replication task 88 Save/restore comparison 251
REPORT task 88 savhelp.nsf 418
Required Per-User Bandwidth 6 savlog.nsf 418
Resource-balancing plan 112 savquar.nsf 418
Response time 173 SAVSAVFBRM 300
Restore SAVSAVFDTA 281
Full system recovery 271 SAVSYS 267
Point in time 355 SBMDOMCMD 85
restore command 385 ScanMail
Restore Domino database 384 ACL 430
Restore Object command 271–272 Activity log 423
Restricted state 267, 337 Administrator tasks 423
Retransmission 123, 202, 590 Attachment blocking 444
RMVPTF 277 Automatic update 432
Roaming user 8, 56, 97, 508, 528 Automatic updates 423
Roaming user server 56 Centralized monitoring and reporting 450
Roaming user settings 53 Compressed file scanning 445
root 107, 218 Configuration 429
Route table Action on cleanable files 437
Dynamic 595 Action on uncleanable files 437
ROUTER task 88 Encrypted mails 437
RPLCFG(*NO) 279 Logging options 438
RST command 271–272 Max compression level 437
Rules 411 Maximum extract file size 437
e-mail usage policy 411 Notifications 437
Run Domino Command 68, 84 Password protected files 437
Run priority 122, 189, 192–193 SSL options 430
Change 195 Testing 440
SERVER job 190 Virus logging options 439
Run Query 150 Virus notification 438
RUNDOMCMD 68, 84 Visibility of databases 430
Configuration command 426
Configuration interface 423
S Configure scanning 435
S/390 422 Consolidated reports 423
Sametime 422 Database security 430
See Lotus Instant Messaging and Lotus Web Confer- dbscan 441
encing dbscan.pgm 428
Sametime See Lotus Instant Messaging and Web Debugging tasks 450
Conferencing Determine file type 447
SAN See Storage Area Network Domino databases 429
SAR 93, 98 Handling of virus incidents 437
sav.nsf 418 Hardware prerequisites 424
savdefs.nsf 418 Incremental Scan 446
SAVE 14 Installation 424
Save Installation package 424
To save file 248 libsmlnred.srvpgm 428
To tape 248 Log purging 449
Save file 249, 280 Logging level 450
CRTSAVF 280 Manual database scanning 434
Dedicated library 280 Memory utilization 445
Reuse 280 Memory-based scanning 428, 445
Save to tape 281 Multitasking scan environment 446
SAVE menu 257–258, 266 NOTES.INI entries 429
SAVE menu options 267 NOTES.INI variables 429
Option 22 270

634 Domino 6 for iSeries Best Practices Guide

Notification options Virus pattern file 441
Database scanning 443 Virus scanning 422
Real-time e-mail scanning 442 Visibility of databases 430
Notification policy 443 vsapi.srvpgm 428
Number of scan tasks 446 What to scan 447
On-demand database scanning 423 ScanMail configuration program 435
Pattern file 431, 441 ScanMail program files 428
Update 431 ScanMail tasks 435, 441
Performance 445 SCHED task 88
Prerequisites Schedule Manager 88
Hardware 424 Scheduled server downtime 68
Software 424 SCOS See Shared mail
Protection strategy 442 SDD 15
pscan.pgm 428 SEC requirements 58
pupdate program 432 Securing the console 72
pupdate.pgm 428 Security
Quarantine database 439 Dial-in access control 36
Quarantine directory 449 Password expiration interval 36
Quarantine purging 449 Password strength 36
Real-time database scanning 434, 446 Policies 36
Real-time e-mail scanning 434 Roles 37
Registration 432 Domino junior administrators 37
Replicate virus logs 450 Domino senior administrators 37
Reports 448 Domino software installation/configuration 37
Top ten viruses 448 Junior iSeries server administrator 37
repscan task 429, 435, 441, 446 Management reporting access 37
repscan.pgm 428 Senior iSeries server administrator 37
Scan engine 431, 441 Standards 36
Update 431 Security Administrator 412
Scan memory 435 Security framework 37
Scanning types 434 Security guidelines 36
Scheduled database scanning 434 Security implementation 36
smadm5.nsf 429 Security policy 56
smbackup.nsf 429 SMTP 13
smconf.nsf 429–430, 435 Security policy settings 56
smency.nsf 429 Selective backup 375
smftypes.nsf 429 selective command 377, 381
smhelp.nsf 429 Semaphore debug 182
smlnred 429 semaphore debug output 577, 580
smmsg.nsf 429 SEMDEBUG.TXT file 182
SMOutputLevel 449 Separator character 44
smquar.nsf 429, 449 Server Availability Index 101–102
SMStopMail 443 Server based mail rules 606
smtime.nsf 429 Server consolidation 20, 499, 526
smvlog.nsf 429, 448 Server Consolidation solutions Web site 20
Software prerequisites 424 Server group 72
SSL options 430 Server health 67
Temporary directories 428 Server Health Monitor 112
tmmscan task 429, 435, 441, 446 Server ID files 52
tmmscan.pgm 428 SERVER job 181
Trial version 423 SERVER job threads 192
True type file blocking 445 Server mail rules 413
Trusted server 447 Actions 414
Update pattern file 441 Conditions 414
Update scan engine 441 Server monitoring tool 65
Updates 441 Server relay controls 413
User interface 430 Server scaling 5
Variable SMOutputlevel 429 Server startup time 50
Variable SMStopMail 429 Server statistics monitoring 480
Virus incident notification 442 SERVER task 88

Index 635
Server to server 110 CPU utilization 456
Server to storage 110 Mail file size range 457
Server_Session_Timeout 473 Moderate mail user 457
ServerTasks 135, 435, 441 Modified mail template 458
Service level agreement See SLA Network compression 461
SH CLUSTER command 90 CPU impact 461
Shared drive 285 Network diagram 461
Shared mail 61 Bandwidth between locations 461
Shared mail database 61 Peak period CPU utilization 459
Shared pool 233 Registered Domino users 456
Shared processing pools 192 Roaming user 461
Sherpa Software CPU impact 461
Mail Attender 65 Server consolidation 461
Short name 272 Domino server characteristics 459
SHOW MEMORY DUMP 235 Single Copy Template 461
Show Platform Statistic 112 Understand overall I/T environment 461
SHOW STAT 170, 480 Volatility of applications 461
SHOW STAT DATABASE 231 Sizing questionnaire 508
SHOW STAT SERVER 474 SLA 6, 60, 68, 113, 115
SHOW STAT SERVER.USERS.* 231 Domino only 116
Show Statistic 112 Application availability 116
Signature 26 Application promotion to production 116
Simple Mail Users 498, 501 Backup and restore 116
Simple Network Management Protocol 112 Directory lookup time 116
Single copy object store See Shared mail Domino cluster availability 116
Single Copy Template 508, 528 Domino server availability 116
Single sign-on 54, 99 Group creation time 116
Single-level storage 200, 228, 244, 255 Help desk wait time 116
Sizing ID creation time 116
Growth 508 Mail delivery time 116
Sizing Domino Mail file restore time 116
3x heavy mail user 457 Mail usage 116
Application characteristics 460 Maintenance windows 116
Applications 460 Password reset time 116
Browser access 458 Problem response time 116
Casual mail user 457 Replication performance 116
Concurrent Domino users 456 iSeries and Domino 117
Concurrent mail user types 457 Availability of iSeries 117
CPW vs. CIW vs. MCU 456 Backup and recovery time 117
Database access 460 CPU utilization 117
Disconnected users 458 Housekeeping 117
Domino clustering 458 Maintenance 117
Domino statistics reporting 461 Organizational responsibilities 117
Domino version 460 Other roles and responsibilities 117
Extensive use of agents 458 Application business owner 117
From non-Domino mail 460 Application developer 117
Full text index impact 458 Desktop support 118
Heavy mail user 457 End user 117
HTTPS 458 Hardware vendor(s) technical support 118
Local mail replicas 458 Help desk 117
LPAR impact 456 Information Security 118
Mail client type 457 IS Management 118
CPU utilization 458 Lotus Instant Messaging/Domino Program
Domino Access for Microsoft Outlook 457 Manager 119
Domino Web Access 457 Lotus Technical Support 118
IMAP 457 Network server administrator 118
Notes client 457 Support analyst 117
POP3 457 Performance 117
WebMail 457 Problem solving time 117
Mail file size 456 Smart Upgrade 106

636 Domino 6 for iSeries Best Practices Guide

Smartcard 40–41, 55 Storage Area Network (SAN) 354
Smartcard lock 42 Storage device 110
Smartcard login 41 Storage management 228
Smartcard Personal Identification Number 41 Storage pool memory 233
Smartcard PIN 41 Storage pools 122, 172–173, 184, 188, 212, 216, 324
SMTP 9, 35, 201, 606 *BASE 173, 188, 214, 230, 233
SMTP architecture 13 *MACHINE 173, 212
SMTP connection controls 413 Memory allocation 214
SMTP gateway 422 Storage subsystem 109
SMTP mail routing 67 Storage to storage 110
SMTP messages 182 Storing ID files 53–54
SMTP server 412 STRCMNTRC 591, 595
SMTP task 88 STRDOMSVR 73
SMTP_Version 99 Streaming replication 7
SMTPSaveImportErrors 182 STRPEX 588, 605
SMU See Simple Mail Users STRPFRMON 137
smvlog.nsf 448 STRSST 176, 576, 579, 582
SNMP 112 Submit Domino Command 85
Socket 208 Subsystem 77
Software maintenance downtime 109 Sun Solaris 422
Solution Assurance Review 93, 98 Supported HTTP servers 108
Solution scenario 529 SuSE 422
Spam 107, 406, 409, 416 Symantec 98
Prevention 409 Symantec Antivirus Corporate Edition 415
Spam e-mail 416 Symantec AntiVirus/Filtering 412, 415
Special authorities 261, 288 Symantec AntiVirus/Filtering 3.0 for Domino on iSeries
Spoke server 97 Software prerequisites 417
SQL 486, 493 Symantec AntiVirus/Filtering for Domino
SSL 35, 246, 458 Block database writes 416
SSL accelerator 13, 110 Block e-mail 416
SSL-LDAP 35 Configuration 418
SSO See Single sign-on Configure content filtering 419
Start communications trace 591, 595 Configure Global AntiVirus Options 418
Start Domino server 73 Content Filtering Rules 417
Statistic collector task 111–112 Content Rule 419
Statistic reporter 88 Content violation
Statistics collector 88 Actions on quarantined documents 421
STATISTICS database 66 Administrator tasks 421
Alarms view 66 Content violation notification 420
Events view 66 Define content filtering rule 419
Statistics database 70 Delete infected items 416
Statistics Monitoring 66–67 Eliminate or filter e-mail with unwanted content 416
Statistics on demand 88 Eliminate viruses automatically 416
Statistics preferences 71 e-mail notifications 416
Statistics profiles 112 Enable/Disable content filtering rule 419
Statistics reporting 526 Global Virus Notification settings 418
STATLOG task 88 Handling of content violations 419
statrep 526 Implementation 418
statrep data 474, 528 Incremental scanning 416
statrep See Domino statistics reporting Installation 417
STATREP.NSF 70, 112, 480 Internal LiveUpdate server 422
STATS task 88 LiveUpdate 422
Stop Domino server 74 Log database 420
Storage Protection against unwanted content 416
Allocation 177 Quarantine 416
Deallocation 177 Quarantine database 420
Storage Area Network 110 Backup documents 421
Server to server 110 Managing Backup documents 422
Server to storage 110 Quarantined documents 421
Storage to storage 110 Repair infected attachments 416

Index 637
 sav.nsf 418 TCP packet
savdefs.nsf 418 Retransmission 590
savhelp.nsf 418 TCP packets 590
savlog.nsf 418 TCP port 201
savquar.nsf 418 TCP/IP configuration 34, 200, 204
Scan window 416 ARP broadcast 204
Send e-mail notifications 416 Bind route to interface 205
Update virus definitions files 422 Domain Name Server 205
Virus definition updates 416 Host name search priority 206
Virus Scan Interfaces 204
On-demand scans 419 IP address 204
Real Time 419 Local host table 205
Scan Now 419 MAC address 204
Scheduled Scans 419 Route 204
Virus scanning 416 Route table 204
Symantec AntiVirus/Filtering for Dominofor OS/400 TCP/IP Connection Status
Implementation Guide 415 NETSTAT 590
Symantec Client Firewall 415 TCP/IP connections 575
Symbolic links 261 TCP/IP conversation
System ASP 228, 288 Communication resets 208
System change 70 TIMEWAIT state 208
System configuration 500 TCP/IP Routes 595
System console 267 TELL HTTP QUIT 179
System job 188 TELL HTTP SHOW THREAD STATE 180
System management tasks 301 TELL ROUTER QUIT 178
System migration 20 TELNET 201
System outage 70 Thread number 191
System recovery 271 Thread safe 240
System status information 575 Threads 188, 598
System Summary Information report 180 Ineligible 212
System upgrade 19 Initial 188
System utilization 473 Multithreaded 189
System value 209 Number 212
QACTJOB 211 Secondary 189
Auxiliary storage allocation 211 Threats
Set 211 Denial of service attacks 406
QADLACTJ 211 Spam 406
QADLTOTJ 209 Unsolicited e-mail 406
QBASACTLVL 173, 214 Virus 406
Set 215 Worms 406
QBASPOOL 173, 214, 216 Threshold settings 66
Set 214 Threshold values 67
QDYNPTYADJ 217 Time format 25
QDYNPTYSCD 217 Time slice 189
QMAXACTLVL 184, 212, 599 Time-out 473
QMCHPOOL 173, 212 TimeSeparator 44
QPFRADJ 172, 212, 214–215 TimeZone 44
QPRCMLTTSK 217 Tivoli 65
QTOTJOB Tivoli Analyzer 5
Auxiliary storage allocation 209 Tivoli Data Protection for IBM Lotus Domino 64
Set 210 Tivoli Storage Manager clients 250
QUTCOFFSET 603 Tivoli Storage Manager for Data Protection modules 354
QVFYOBJRST 26 Total cost of ownership 93
Set QMCHPOOL 213 Total cost of ownership See TCO
Total CPU 584, 603
TPROFS Performance Explorer Trace (PEX Trace) 587
T TPROFS trace 605
Tape 258 Transaction 252
TASKINFO 176 Transaction log 338
TCO 57, 93 Size 254
TCP network traffic 594

638 Domino 6 for iSeries Best Practices Guide

 Usage 290 Trend Micro scanning engine 423
Transaction log extents 252, 375, 379 Trends 111
Archive 379 Trojans 406
Conditional archiving 380 True type matching technology 447
Expiration 380 Typical Domino application 483
Transaction log file 16 Typical Mail Users 498
Transaction log files 325 Typical user 468, 498
Transaction logging 16, 68, 88, 228, 248, 252, 297, 346,
348, 375, 389, 391, 508, 528
Archive style 251, 381, 389 U
Attachments 252 UBM See Unified Buffer Manager
Circular style 389 UCS2 Level 1 219
CPU impact 255 UDFS 218
Database in-memory copy 252 UDP 201
Disabling 255 UDP packets 590
Disk storage requirements 255 Unauthorized users 56
Enable 255 Unified Buffer Manager 12
Extent files 16 UNIX 218
Flushing 252 Unplanned IPL 175
Hardening 252 UPDALL 84, 182
Impact on CPU 535 UPDALL task 67, 88
Log path 255 UPDATE 182
nlogctrl.lfh 394 UPDATE task 88
Partial transactions 254 Update views and full text indexes 88
Recovery 254 Upgrade Domino 21
Recovery Point 254 Upgrade to Domino 6 92
Recreate transaction log control file 394 After the upgrade 101
REDO record 252 Cleanup 97
Roll back 254 Code installation 100
Server crash 254 Considerations
Styles Calendaring and scheduling 96
Archive 254 Client interoperability 95
Circular 254 Database replication 94
Linear 254 Design upgrades 94
UNDO record 252 Domino Directory 95
View logging 50 Full-text index 96
Views 230, 252 Server-to-server communication 94
Transaction logging checklist Testing 94
Backup strategy 16 View indexes 96
Log file space 16 Custom NOTES.INI settings 103
Logging style 16 Design 93, 97
Server and DB selection 16 Interoperability 94
Transaction logging settings 535 Language pack availability 103
Transaction logging style ODS version 101
Archived 16 Pilot phase 98
Circular 16 Planning 93
Linear 16 Post installation tasks 101
Transaction logging styles 254 Pre-installation tasks 98–99
Transactions 467 Reasons 93
Transmission Control Protocol 201 Tips and tricks 102
Trend activity 67 Upgrade backup folder 101
Trend Micro 98 Upgrade plan 96
Centralized management 450 Upgrade process document 98, 102
Trend Micro Control Manager 431, 441, 449–450 UPS 19
Hardware requirements 451 Usage patterns 7
Software requirements 451 User ASP 219, 228
Trend Micro Control Manager Agent 424 User ASPs 248
Hardware requirements 451 User complexity 474
Software requirements 451 User concurrency 4, 508, 527–528
Trend Micro Enterprise Protection Strategy 450 User Datagram Protocol 201
User ID files 52

Index 639
User registration 53 Web site identification 42
User Registration feature 53 WebMail 8, 109, 473
User-defined file system 307 WebSphere 99, 243
UTF-16 219 Websphere 335
UUencode 447 Websphere Application Server 267
WebSphere integration 99
Weekly full backups 381
V Windows 243
V5R2 Performance Capabilities Reference 464 Windows 2000 500
Verity KeyView filter 12 Windows Terminal Server 109
View logging 50, 230 WLE 463, 508
View system status 78 Active users 467, 472
VIPA 34 Add Workload 512
Virtual host 35 Agents 481
Virtual host document 35 Amount of memory 482
Virtual IP Address See VIPA Antivirus protection factor 528, 535
Virtual storage 228 Application complexity rating 484
Virus 406 Application rating 483, 544, 564
Blended threat 407 Custom 484
Life cycle Example applications 483
Assimilation 408 Average mail user 480
Creation 408 Basic Workload Selection 512
Discovery 408 Complexity of applications 467
Eradication 408 Concurrency ratings 472
Macro virus 407 Concurrent mail users 482
Points of attack 407 Concurrent user to HTTP hit rate ratio 486
Points of entry 406 Concurrent users 467, 472
Protection 410 CPU utilization 482
Content security 410 Create PDF 524, 547, 552
Security policies 410 Critical factors 467
Trojan 407 Custom application rating 485
Vulnerabilities 407 Customer Relationship Management application ex-
Worms 407 ample 528
Virus attacks 416 DB2 access 528, 564
Virus definition updates 416 DB2 database processing 486
Virus detection Default concurrency values 473
Heuristic technology 408 Default values 471–472
Virus protection 422 Disk full target 528
Virus protection/content filtering 415 Domino application sizing 483
Virus resistant Domino clustering 475
iSeries 107 Domino instance 470
Virus scan window 416 Domino partition 470
Virus scanning 416 Domino R5 estimate 471, 517
Volume identifier 291 Domino Workload 512
Vulnerabilities 407 Domino-specific parameters 471
Existing applications
W Add-in tasks 487
Watchdog job 88 Back end data access 488
Web Administrator client 53 Data access 487
Web content 108 DB2 access 488
Web preferences 44 Design metrics 487
Web realm 42 Number of agents 487
Web server log files Number of views 487
ACCESS-LOG 69 User response time 487
AGENT-LOG 69 Existing workload 465, 482
CGI-ERROR-LOG 69 Fail over mode scenario 480
ERROR-LOG 69 Growth rate 522, 566
REFERER-LOG 69 Growth solution 522, 545
Web site alias 35 Identify estimate 513
Web Site document 42 Immediate solution 522

640 Domino 6 for iSeries Best Practices Guide

Import PM eServer iSeries data 466 Domino.Doc - Moderate 484
Inbound Cluster Replication 517, 534, 537 Lotus Instant Messaging - Chat 483
iSeries options Lotus Team Workplace 483
Disk Attachment Type 490 Lotus Web Conferencing - Audio/Visual 483
2757 SCSI PCI RAID Disk Unit Controller 490 Lotus Web Conferencing - Meeting 483
Original IOA/IOP 490 Web Shopper Application 484
Disk Storage Percent Full 489 Web Shopper with DB2 Application 484
Disk Storage Type 490 Save definition 553
15K RPM drives 490 Selected System 466
Load My Options 490 Series Specific Settings 529
Load Standard Options 490 Sizing recommendations 466
Save My Options 490 Target disk full 488, 494
Target Family 490 Target system family 488
Target interactive feature utilization 489 Terminology 468
Target LPAR Processor Utilization 489 Terms and conditions 465
Target Processor Utilization 488 Transaction logging factor 535
iSeries User Options 529 Typical mail user 480
Lotus Domino Web Access users 469 Typical user 468
LPAR 554 Upgrade existing system 465
LPAR status 558 User concurrency 518, 535, 564
Mail access type 481 User concurrency rate 540
IMAP 481 User type 518, 535
iNotes Outlook 481 3x heavy 477, 480
iNotes Web Access 481 Average 480
Notes client 481 Casual 477, 480
POP3 481 Heavy 477, 480, 482
WebMail 481 Moderate 477, 480
Mail database size 482 Typical 480
Mail user category 481 Web shopping application 485
Multiple workloads 469 Workload 468
Normal operations scenario 480 WLE example
Notes client users 469 10,000 Domino users 526
Number of disk arms 482 500 Domino users 508
Number of partitions 474, 535, 542 WLE online tutorial 559
Number of users supported on the system 480 WLE terms and conditions 529
Outbound clustering options 478 WLE tutorial 464
To a different system 478 WLE Web site 509, 529, 554
To the same system 478 Work with Active Jobs 77
Peak time 472 Work with Domino Console 75
Projected CPU utilization 488 Work with Domino Servers 75
RAID support 488 Work with Subsystems 79
Registered users 472 Work with System Status 175
Restore Saved Estimation 555 Workflow 71
Result Workload balancing 89
Capacity 494 Workload distribution 89
Database Capacity 493 Workload Estimator See WLE
Disk Drives 494 Workstation data security 41
Growth Solution 491, 494 Worms 406
Immediate Solution 494 WRKACTJOB 77, 211, 575, 578, 583, 603
Immediate Solution system 491 CPU utilization 185
Number of disk arms 494 Elapsed time 186
Processor CPW 493 WRKDOMCSL 75, 578
Recommended system 491 WRKDOMSVR 75, 261, 267
Selected System 491 WRKDSKSTS 123, 197, 229
Sample applications WRKHDWRSC 122
Custom 483 WRKJOBSCDE 283, 384
Customer Relationship Management 483 WRKLNK 223
Document Library Application 483 WRKOBJ 226
Domino.Doc - Casual 484 WRKOBJOWN 226
Domino.Doc - Heavy 484 WRKSAVFBRM 300

Index 641
WRKSBMJOB 225
WRKSBS 79
WRKSHRPOOL 216
WRKSYSACT 583
WRKSYSSTS 122, 175, 210, 212, 214–215, 288, 575,
578, 600
DASD
Current unprotect used 175
Permanent storage utilization 180
System ASP 175
Total 175
DASD utilization 175
Main storage utilization 172
Max Active 184

X
X.509 37

642 Domino 6 for iSeries Best Practices Guide

Domino 6 for iSeries
Best Practices Guide
(1.0” spine)
0.875”<->1.498”
460 <-> 788 pages
 Back cover ®

Domino 6 for iSeries

Best Practices Guide
Guidelines for This IBM Redbook is a collection of Domino 6 related topics that
are important pieces of information and are either not covered in
INTERNATIONAL
deploying Domino in
other documents or the existing information is outdated because TECHNICAL
small and large
it applies to older versions of Domino, such as Domino V5.x. As SUPPORT
environments
such, the topics vary widely and range from Domino deployment, ORGANIZATION
Selecting the right performance monitoring and tuning to Antivirus protection. This
redbook complements and updates the content of existing
backup and recovery
redbooks, for example IBM Lotus Domino 6 for iSeries
strategy Implementation, SG24-6592 and Domino for iSeries Sizing and
BUILDING TECHNICAL
Performance Tuning, SG24-5162-01. INFORMATION BASED ON
Quickstart to
PRACTICAL EXPERIENCE
performance Part 1 of this redbook covers Domino deployment, administration,
monitoring and tuning and performance monitoring and tuning. IBM Redbooks are developed
by the IBM International
Part 2 describes the various backup and recovery methods that Technical Support
are available for Domino on iSeries and helps you to determine Organization. Experts from
IBM, Customers and Partners
which backup and recovery strategy is right for you. Antivirus from around the world create
protection is also covered in Part 2. timely technical information
based on realistic scenarios.
Part 3 teaches you what needs to be considered when sizing a Specific recommendations
Domino environment and how to use the IBM Eserver are provided to help you
implement IT solutions more
Workload Estimator. effectively in your
environment.
Part 4 gives you a quickstart to use the Workload Estimator based
on fictitious customer environments. It also helps you to solve
some Domino performance problems and tells you what
information you need to collect for Domino troubleshooting. For more information:
ibm.com/redbooks

SG24-6937-00 ISBN 0738453315