Sap Business Information Warehouse On Os 390

SAP Business
Information Warehouse
on OS/390
Prepare, install, and configure your SAP
BW on OS/390
Administer your SAP BW

databases
Recommended sizing
approaches
Seungrahn Hahn
Patrick Horkan
Christoph Laube
Gert Ruland
ibm.com/redbooks
SG24-5681-00
International Technical Support Organization
SAP Business Information Warehouse

on OS/390
September 2000
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix E, “Special notices” on page 119.
First Edition (September 2000)
This edition applies to SAP Business Information Warehouse 1.2B (SAP R/3 4.5B). Data server uses
DB2 UDB for OS/390 Version 6 (5665-DB2) with OS/390 V2R7. Application server uses AIX 4.3.3
(5765-603) as an operating system.
This document created or updated on September 11, 2000.
Comments may be addressed to:

IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 2000. All rights reserved.

Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Chapter 1. SAP Business Information Warehouse (BW) overview . . . .1

1.1 Why use Business Information Warehousing . . . . . . . . . . . . . . . . . . . .1
1.2 Why use BW on SAP R/3 on OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . .2
1.3 The architecture of SAP Business Information Warehouse . . . . . . . . . .4
1.3.1 The components of the Business Information Warehouse. . . . . . .4
1.3.2 How things are done with SAP BW . . . . . . . . . . . . . . . . . . . . . . . .6
1.3.3 BW data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
1.3.4 Database Management System (DBMS). . . . . . . . . . . . . . . . . . . .8
1.3.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.3.6 The presentation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
1.4 The terminology used in this redbook . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 2. Our system environment . . . . . . . . . . .. . . . .. . . . . .. . . . . 13

2.1 OS/390 for SAP BW and R/3 database server . .. . . . .. . . . . .. . . . . 14
2.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 14
2.1.2 Software environment. . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 15
2.2 AIX for SAP BW and R/3 application server . . . .. . . . .. . . . . .. . . . . 19
2.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 20
2.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 20
2.2.3 System setup for SAP BW . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 20
2.2.4 System setup for SAP R/3 . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 22
2.3 Windows NT for Presentation Server . . . . . . . . .. . . . .. . . . . .. . . . . 22
2.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 22
2.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . .. . . . . 22
Chapter 3. Preparing OS/390 and AIX . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Pre-installation checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Defining the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Installation prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Database server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Application server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Database server and application server connectivity testing . . . . 31
3.3.4 DASD initialization on the database server . . . . . . . . . . . . . . . . . 32
© Copyright IBM Corp. 2000 iii

3.3.5 Configuring OSA-2 on the database server. . . . . . . . . . . . . . . . . 32
3.3.6 Installing DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.7 Configuring SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.8 Customizing OS/390 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.9 Customizing TCP/IP on the database server . . . . . . . . . . . . . . . 34
3.3.10 Customizing the ICLI Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.11 Customizing RACF or equivalent . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.12 Set OS/390 dispatching and I/O priorities . . . . . . . . . . . . . . . . . 39
3.3.13 Customizing TCP/IP on the central instance . . . . . . . . . . . . . . . 40
3.3.14 Setting up the ICLI client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.15 Testing connectivity -- central instance and database server . . 42
3.4 Installing SAP BW on DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.1 General notes on the installation from AIX . . . . . . . . . . . . . . . . . 43
3.4.2 Hints and tips -- installing with AIX . . . . . . . . . . . . . . . . . . . . . . . 43
Chapter 4. Preparing DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 47

4.1 Inside the SAP BW database . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 47
4.2 Prerequisites of DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 47
4.3 OS/390 setup for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 48
4.4 Setting up RRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 48
4.5 Customizing DB2 parameters . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 48
4.6 DB2 system database requirements . . . . . . . . . . . . . . . . . . . . .. . . . . 50
4.6.1 DB2 catalog and directory database size . . . . . . . . . . . . .. . . . . 51
4.6.2 Additional DB2 catalog indexes . . . . . . . . . . . . . . . . . . . .. . . . . 52
4.7 Preparing the DB2 log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 52
4.8 DB2 Binding for the ICLI server . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 53
4.9 DB2 authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 54
4.10 Maintaining DB2 catalog statistics . . . . . . . . . . . . . . . . . . . . .. . . . . 54
4.10.1 RUNSTATS utility considerations . . . . . . . . . . . . . . . . . .. . . . . 54
4.10.2 Updating DB2 catalog statistics manually . . . . . . . . . . . .. . . . . 55
4.10.3 Maintaining catalog statistics for R/3 cluster tables . . . . .. . . . . 56
4.11 Post-installation tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 58
4.11.1 Reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 58
4.11.2 DB2 temporary database (DSNDB07). . . . . . . . . . . . . . .. . . . . 58
Chapter 5. Installing SAP BW OS/390 with AIX Application Servers. . 59

5.1 SAP BW installation overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 SAP BW pre-installation: data gathering . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Gathering the SAP notes via SAPNet R/3 Frontend . . . . . . . . . . 60
5.2.2 Searching for SAP notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.3 Downloading patches and other information from SAPSERVx . . 62
5.2.4 Searching for installation documentation . . . . . . . . . . . . . . . . . . 62
5.3 SAP BW pre-installation: system check . . . . . . . . . . . . . . . . . . . . . . . 62
iv SAP Business Information Warehouse on OS/390

5.4 SAP BW pre-installation: final preparation phase . . . . . . . . . . .. . . . . 64
5.5 SAP BW installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 66
5.5.1 Starting BW installation . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 66
5.5.2 Building the BW database . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 67
5.5.3 Loading the BW database. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 67
5.5.4 R3SETUP problem solving . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 68
5.6 SAP BW post installation: completing the install . . . . . . . . . . . .. . . . . 69
5.6.1 Summary of the BW database . . . . . . . . . . . . . . . . . . . . .. . . . . 70
5.6.2 Summary of the SAP R/3 source system . . . . . . . . . . . . .. . . . . 71
5.6.3 SAPGUI/BWGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 71
5.6.4 BW Patch installation . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 71
5.7 Installing the R/3 PlugIn PI 99 or PI-A 99 for SAP BW . . . . . . .. . . . . 72
5.7.1 PlugIn -A 99 pre-installation: data gathering . . . . . . . . . . .. . . . . 73
5.7.2 PlugIn -A 99 pre-installation: system check . . . . . . . . . . .. . . . . 73
5.7.3 PlugIn -A 99 pre-installation: final preparations. . . . . . . . .. . . . . 73
5.7.4 PlugIn -A 99 installation . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 75
5.7.5 PlugIn -A 99 post-installation: completing the installation .. . . . . 75
5.8 What to do with those leftover CD-ROMs . . . . . . . . . . . . . . . . .. . . . . 76
5.9 Useful URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 76
Chapter 6. Managing SAP BW database . .. . . . . .. . . . .. . . . . .. . . . . 79

6.1 Administrator’s workbench . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 79
6.2 SAP R/3 tools . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 80
6.3 DB2 utilities . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 81
6.4 Backup and recovery strategy . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 81
Chapter 7. Tests performed at ITSO . . . . .. . . . . .. . . . .. . . . . .. . . . . 83

7.1 Loading the ODS . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 83
7.2 Updating the InfoCube . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 84
7.3 Aggregate build . . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 85
7.4 .Running queries . . . . . . . . . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 85
7.5 Incremental DataPackage update . . . . . .. . . . . .. . . . .. . . . . .. . . . . 86
7.6 Partitioning tables in SAP BW . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 86
7.6.1 Partitioning in the ODS . . . . . . . . . .. . . . . .. . . . .. . . . . .. . . . . 86
7.6.2 Partitioning in the InfoCube . . . . . .. . . . . .. . . . .. . . . . .. . . . . 87
Chapter 8. Sizing, performance, and tuning considerations . . .. . . . . 89

8.1 Special considerations for BW applications . . . . . . . . . . . . . . .. . . . . 89
8.1.1 BW administration tasks . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 90
8.1.2 Using RUNSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 91
8.2 General sizing and tuning approach . . . . . . . . . . . . . . . . . . . . .. . . . . 91
8.2.1 Pre-installation and planning phase . . . . . . . . . . . . . . . . .. . . . . 91
8.2.2 Pilot or evaluation phase . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 92
8.2.3 Production start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 93
v
8.2.4 Running BW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Appendix A. What’s new in SAP BW 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . 95
Appendix B. DB2 Installation parameters . . . . . . . . . . . . . . . . . . . . . . . . 97

B.1 DSNZPARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.2 IRLMPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.3 DB2 parameters using a SAP transaction . . . . . . . . . . . . . . . . . . . . . . . 104
Appendix C. How to set up RRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Appendix D. Enterprise Storage Server (ESS) . . . . . . . . . . . . . . . . . . . 115
Appendix E. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Appendix F. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

F.1 IBM Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
F.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
F.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
F.4 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
vi SAP Business Information Warehouse on OS/390

Figures
1. SAP BW architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Table structure of an InfoCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Business Explorer example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Test system environment for SAP BW application . . . . . . . . . . . . . . . . . . 13
5. A storage class definition for SAP applications . . . . . . . . . . . . . . . . . . . . . 17
6. A storage group definition for SAP applications. . . . . . . . . . . . . . . . . . . . . 17
7. Physical SAP BW system configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. I/O configuration for the FDDI connection . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. ICLI environment file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. ICLI started procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11. Allocating DB2 active log data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12. An example of DB2 catalog updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13. Sample SQL statements for updating catalog statistics for cluster tables . 57
14. Sample SQL statements to avoid deadlock . . . . . . . . . . . . . . . . . . . . . . . . 57
15. DB2 installation parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
16. DB2 buffer pool allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
17. DB2 storage sizes and connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
18. DB2 trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
19. DB2 locks and IRLM definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
20. DB2 archive log parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
21. DB2 active log parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
22. DB2 application parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
23. DB2 operation and DDF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
24. Sample JCL to define an RRS LOGR couple data set . . . . . . . . . . . . . . 110
25. Sample couple data set definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
26. Sample JCL to define RRS log streams . . . . . . . . . . . . . . . . . . . . . . . . . 112
27. Sample RRS started task procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
© Copyright IBM Corp. 2000 vii

viii SAP Business Information Warehouse on OS/390
Tables
1. Official names and usage in this redbook . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. SMS naming convention for SAP applications. . . . . . . . . . . . . . . . . . . . . . 16
3. Information about DB2 systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. User ID definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. SAP BW definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. User ID information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Physical volume information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. File system allocation for SAP BW code installation . . . . . . . . . . . . . . . . . 21
9. User ID setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. TCPIP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Other definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Statistics of the DB2 objects of SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . . 47
13. DB2 parameter checked by R3SETUP (BW). . . . . . . . . . . . . . . . . . . . . . . 49
14. Highly recommended IRLM parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 50
15. Recommended DB2 bufferpool allocation . . . . . . . . . . . . . . . . . . . . . . . . . 50
16. DB2 installation panel DSNTPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
17. New indexes created against the DB2 catalog tables during R3SETUP . . 52
18. DB2 authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
19. Installation activities and runtime durations . . . . . . . . . . . . . . . . . . . . . . . . 60
20. SAPNet R/3 Frontend Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
21. AIX file system layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
22. AIX language filesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
23. R3SETUP input required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
24. Debugging file and locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
25. R3SETUP problem-solving tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
26. R/3 Profile parameter changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
27. SAP BW DB2 UDB 6.1 OS/390 database statistics. . . . . . . . . . . . . . . . . . 70
28. SAP R/3 DB2 UDB 6.1 OS/390 database statistics. . . . . . . . . . . . . . . . . . 71
29. File system size for PlugIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
30. PlugIn variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
31. Useful URLs - SAP logon required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
32. Useful URLs - Public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
33. TP parameters for JCL submitted with FTP out of SAP R/3 . . . . . . . . . . . 80
© Copyright IBM Corp. 2000 ix

x SAP Business Information Warehouse on OS/390
Preface
This redbook explores the SAP Business Information Warehouse (BW) 1.2B
on the S/390 system. It takes a close look at the tasks and functions that are
specific to the S/390 environment. It is designed to assist S/390 technical
specialists, DB2 database administrators, and SAP Basis consultants in
implementing this technology.
This redbook offers valuable information that includes:

• An overview of BW
• The preparation of the BW installation
• The BW installation process
• Recommendations on administering BW databases to: improve query
response time, improve performance of loading databases, update delta
information, gather database statistics, and more.
• Preliminary sizing recommendations based on tests and SAP
recommendations
We assume that the readers have already installed the SAP R/3 system and
are familiar with SAP applications, terminology, prerequisites, documentation,
and technology.
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 Poughkeepsie
Center.
Seungrahn Hahn is a Business Intelligence specialist at the ITSO. Before

joining the ITSO, she worked as an IT specialist in physical database design,
performance tuning, the data sharing implementation with DB2 for OS/390,
and BI application solutions in IBM Korea.
Patrick Horkan is an IT Architect in the IBM ERP Competency Center, The

Americas. He has been working with SAP R/3 on DB2 for OS/390 for many
years, and is certified as an SAP R/3 and SAP BW Technical Consultant. He
joined IBM in December 1997.
Christoph Laube manages a competence center of OS/390 consultants at

SCHUMANN AG in Cologne, Germany. His task is to build consulting teams
for server consolidation and SAP R/3 on OS/390. He has worked in IT for 22
© Copyright IBM Corp. 2000 xi

years with 15 years spent on MVS and OS/390. He has over 10 years of
experience in migration projects in the area of OS/390, DB2, and
multiplatform environments. Recently he participated in a pilot study of
porting UNIX/Informix applications to OS/390 UNIX. Christoph is the region
manager of GUIDE SHARE Europe for the German Region, and formerly led
the OS/390 working group.
Gert Ruland is a BI specialist at the S/390 New Technology Center,

Montpellier, France. Before joining NTC Montpellier he worked for IBM
Germany in the S/390 division as a system engineer and sales
representative. He has 22 years of experience in different areas of IT.
Thanks to the following people for their contributions to this project:
Jan Baisden
International Technical Support Organization, Poughkeepsie Center
David Bennin
Rich Conway
Robert Haimowitz
Vasilis Karras
Terry Barthel
Alfred Schwab
Denny Sell
Ella Buslovich
Benno Staebler
Joachim Rese
SAP R/3 on DB2 for OS/390 Porting team: Business Warehouse, IBM
Germany
Christine Gaul-Gaensslen
Customer support for SAP R/3 on DB2 for OS/390, IBM Germany
Michael Sheets
IBM SAP International Competency Center - S/390
Lee Siegmund
IBM Dallas System Center
xii SAP Business Information Warehouse on OS/390

Don Geissler
Scott Bell
IBM ERP Competency Center, The Americas
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Please send us your

comments about this or other Redbooks in one of the following ways:
• Fax the evaluation form found in “IBM Redbooks review” on page 133 to
the fax number shown on the form.
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Send your comments in an Internet note to redbook@us.ibm.com
xiii
xiv SAP Business Information Warehouse on OS/390
Chapter 1. SAP Business Information Warehouse (BW) overview
SAP Business Information Warehouse (BW) is an SAP strategic product

architecture that gives you immediate access to data that is relevant to
decision-making, and allows you to flexibly analyze it.
In this chapter we briefly describe:

• Why you should use SAP BW
• Why you should use SAP BW on S/390
• The architecture of SAP BW
• The terminology we used
1.1 Why use Business Information Warehousing

For your company to succeed, you need fast access to reliable information,
and the ability to flexibly analyze it. The quality of your business decisions is
directly dependent on the quality of the available information. The more
current the information and the faster you can obtain it, the more relevant it is.
In a world where good Customer Relationship Management (CRM) is a

growing competitive advantage, you have to know where to focus in specific
situations. Such focus is impossible without having reliable information to
base decisions on, so it is important for your company to be able to quickly
extract the important data and present it in such a way that intelligent
business decisions can immediately be derived.
The modern solution for this is Business Information Warehousing (BW). BW

offers managers an array of possibilities to easily define and satisfy their
information needs.
Put simply, a BW system gathers all the information needed to answer your
requests from your production data. This data gathering can be scheduled for
off hours on a daily or weekly basis, thus making it as current as possible
without disrupting your operating environment.
BW stores all information in its own database in a very sophisticated way that
is specially prepared to handle your queries on it. For example, certain
aggregation and summarization is already done, without having to be
calculated when you query for it. As a result, your queries on the data will be
satisfied on each level in a very fast and efficient way.
© Copyright IBM Corp. 2000 1

BW provides a steadily-growing base of knowledge about your company’s
business and your customers’ behavior (for example, the results of certain
marketing campaigns), and about the relationships between these factors.
BW can extract, store, and provide quick and easy access to all this business
knowledge. You, in turn, can use this knowledge to make successful business
decisions by querying BW.
BW can help you determine the future direction of your company. This is why
more and more customers are using it.
1.2 Why use BW on SAP R/3 on OS/390

You may have heard that performing Business Information Warehousing on
an OS/390 system would be the most expensive solution. On the contrary, the
discussions and experiences that the project team had with customers using
or intending to use BW on OS/390 clearly showed that there are very
compelling reasons why they chose this platform and why they consider
OS/390 to be the best possible solution.
These customers can be divided into two groups: those who already have
OS/390 systems or S/390 platforms, and those who would enter a new
platform with OS/390. Their main reasons for using BW on OS/390 are as
follows.
For customers already using OS/390 systems

1. Existing skills in OS/390 and DB2 can be used:
– There is no need to build up new skills and hire additional staff.
– There is less learning involved; therefore, a quicker start is possible.
2. Production data (the base for deriving BW data) is already on OS/390; this
means:
– There are no connectivity problems.
– There is high speed data transfer.
– You have secure interfaces.
3. Important data is on a proven platform:
– You can avoid increasing IT complexity.
– Proven existing backup and recovery mechanisms can be used.
– Existing automation can be used and new jobs can easily migrate to it.
– You can use existing systems management procedures.
– You can keep the number of servers small (server consolidation results
in reduced costs).
2 SAP Business Information Warehouse on OS/390

1. Scalability
– One hardware system powers multiple LPARs, systems, and
databases in a most flexible way, without having to IPL or redefine
parameters for each change.
– Hardware growth benefits all applications and systems.
For customers using OS/390 as a new platform

These reasons for using SAP on OS/390 for BW were cited by both groups of
customers:
1. Availability
– S/390 platforms and storage subsystems are well known for high
availability in the marketplace.
– Using the Parallel Sysplex facilities will increase availability to the
highest possible level.
– Changes to hardware and software can be made in flight, without
disrupting applications.
2. Security
– OS/390 is acknowledged to be one of the most secure systems--and all
customers want the best possible protection for strategic data, such as
that stored in BW systems.
– OS/390 UNIX System Services is especially secure, because RACF is
used for security instead of standard UNIX security.
– If BW data may be accessed from the Internet, thus making security
concerns particularly important.
3. Accounting, tuning and measurement
A BW application will contain a large and ever-increasing mountain of
data, so it is particularly important to track (and probably, bill) the users
who are producing and using this data. For accurate accounting, you first
need to perform measurements, collecting data from the system and the
subsystems, so users are fairly charged.
Accurate and continuous measurement is the base for all system tuning
activities, as well--and you also need measurement data to predict your
systems and storage growth and to contract service level agreements with
your users or IT customers that you will be able to fulfill.
All these considerations are especially important in a BW application,
which holds strategic information for your company and will likely be used
by every employee who makes business decisions.
For more than twenty years, OS/390 has performed measurement and
accounting tasks as “normal business”, processing large amounts of data,
Chapter 1. SAP Business Information Warehouse (BW) overview 3

handling great numbers of users, and providing parallelism--so all the
tools needed for these tasks in a BW environment are already available
and ready for you to use.
UNIX and PC systems simply do not offer the measurement and
accounting capabilities of OS/390. So if you need detailed information
about database activity or storage usage to do measurement, tuning,
accounting, service-level design or IT growth projections, OS/390 can be
the solution--and these OS/390capabilities become even more important if
you enter a multi-customer service center environment.
1.3 The architecture of SAP Business Information Warehouse

SAP Business Information Warehouse (SAP BW) is a data warehouse
solution tailored to SAP R/3. It comes with a specially tailored SAP R/3
system, where you only can run SAP BW. It is a separate application (an
add-on) that is independent from SAP R/3 and has its own release and
shipment cycle. It consists of:
• The SAP BW kernel , which is the same as the SAP R/3 kernel.
• The SAP BW application code, which is written in advanced business
application programming (ABAP).
• The SAP BW database server, which contains all user data and system
data.
• The SAP BW frontend, which consists of the SAPGUI, the normal SAP R/3
graphical user interface, and Business Explorer, hosted by MS EXCEL,
which is the interface for the analytical part of SAP BW.
Reference
SAP R/3 on DB2 for OS/390: Implementing with AIX or Windows NT
Applications Servers, SG24-4945
1.3.1 The components of the Business Information Warehouse

Figure 1 on page 5 shows the three-level layered components of BW, which is
a data warehouse solution:
• Top layer: BW’s client components for the end user
• Middle layer: BW server
• Bottom layer: the OLTP systems from which source data is extracted

1.3.1.1 Business Explorer
Business Explorer is a graphical user interface (GUI), hosted by MS EXCEL,
that provides analyzing and viewing functions for end users. SAP provides
several ready-made reports for the standard R/3 system.
Business Explorer
Report Catalog Browser
Reporting and Analysis for

Reporting and Analysis
Excel
BAPI
OLAP Processor
InfoCubes
Meta Data Meta Data Manager Data Manager
Repository
Business Information Operational

Staging Engine Data Store
Warehouse Server
BAPI
Non R/3 Production Production OLTP

Data Extractor Data Extractor Reporting
Non R/3 OLTP Applications R/3 OLTP Applications
Figure 1. SAP BW architecture overview
1.3.1.2 Business Information Warehouse Server

• The OLAP processor manages the supply of data that is requested by a
user for analysis. It interfaces with the Meta Data Manager to get
information about where to get the data, and with the data manager to get
the actual data. The interface to the Business Explorer of the SAP BW
frontend is the Business Application Interface (BAPI).
• Data Manager takes care of the data in the InfoCubes and Operational
Data Store. InfoCubes is the container for the data tables for OLAP
processing, and the Operational Data Store (ODS) holds the data in flat
file-type tables.

• The Staging engine is responsible for loading the data that is extracted
from the application data. The interface to the extracted data is supplied
by SAP BW, in the case of SAP R/3 and SAP R/2 systems. For other OLTP
applications, you have to develop it yourself.
• Meta Data Manager keeps track of the data warehouse environment and
stores its tables in the Meta Data Repository.
1.3.1.3 OLTP systems

At the bottom of the Figure 1 on page 5 are the production systems, from
which the data is extracted and loaded into SAP BW.
Administrator Workbench
The Administrator Workbench tool can also help in BW administration. This
SAPGUI-based tool is used for BW implementation, maintenance,
customizing, scheduling, and monitoring.
The Business Content (BCT)

BCT is meta data information used to assist in synchronizing the meta data of
SAP BW and SAP R/3.
1.3.2 How things are done with SAP BW

This is the normal flow of tasks, from a user’s perspective:
1. Using the Administrator Workbench:
a. Define the structures you want to analyze, using the Administrator
Workbench (this includes InfoCube and ODS).
b. Define the structures from which you want to extract the data.
c. Define the schedule for the initial load and the following additional
loads.
This information is stored in the Meta Data Repository.
d. Perform the update of the InfoCube.
e. Perform the additional tasks for building the InfoCubes, such as
building the aggregates.
2. Using Business Explorer:
a. Perform the data analysis, by predefined reports or ad hoc reports.
1.3.3 BW data structures

The basic building blocks of the BW data structures are called characteristics
and key figures . The generic term for both is InfoObjects . When you want to

create the data warehouse on your BW system, you start by creating your
InfoObjects.
Characteristics are the elements of a company’s business, for example

company code, product, material, customer group, fiscal year, period, or
sales region. They may have a hierarchical structure; products, for example,
may be grouped together into product groups. Characteristics are stored in
dimension tables.
Key figures are the values or quantities in a company’s business, such as

sales revenue, sales quantity, or fixed costs. They are stored in fact tables.
A fact table contains all the key figures at the lowest level of detail. A
dimension table contains characteristics that are required both in reporting
and in the analysis of the key figures. Dimension tables are independent of
one another. Only the fact table connects dimension tables through key
figures.
The largest organizational unit is an InfoCube; see Figure 2 on page 8 for an

example. You can think of an InfoCube as a data mart. An InfoCube is used to
answer specific end-user queries and to provide information for specific
analysis. It consists of a number of tables that are put together in a extended
star schema. A large fact table is surrounded by several dimension tables.

M aster
SID
Attr
S ID S ID
SID SID Table
M a ste r Attr
Table
Attr SID
Attr
D im en s io n
S ID S ID
Table tab le Tem p M a ste r
Tab Table
SID
S ID D im en sio n FACT D im en sio n Attr
M a ster Table tab le tab le
S ID M aster
SID S ID D im en s io n Table
Attr M a ster Table tab le
SID
Attr
S ID S ID
F act Tab le Table Table
Dimen sion SID

Attr SID Tem p
M a ste r M a ste r Attr Tab
M a ste r
SID Tab le SID SID SID

Attr Attr Attr
Temp Tab
SID Attr
Figure 2. Table structure of an InfoCube
Dimension tables are linked to the fact table using surrogate keys. A
surrogate key is used as a unique key within each dimension table. The
master data table and the dimension table are linked by system-generated
identifications called Set IDs that are stored in Set ID (SID) tables.
The master table contains attributes of characteristics, while the dimension

table contains the representation of the characteristics. Master tables contain
information that can be used by other InfoCubes. Thus, the dimension table
with its associated SID table and its master data table builds one dimension.
1.3.4 Database Management System (DBMS)

The SAP BW database server, as the normal SAP R/3 database server, is
based in a vendor product. The DB2 UDB for OS/390 Version 6.1 should be
used as the hosting database manager. As an add-on to this database, there
is a special interface called Integrated Call Level Interface (ICLI). For detailed

information about ICLI, refer to SAP R/3 on DB2 for OS/390: Planning Guide
SAP R/3 Release 4.5B, SC33-7964.
1.3.5 Security
Access to reports that contain sensitive data must be restricted to authorized
persons only. SAP BW provides various controls on different levels. Access
rights may defined for a report as a whole, or for certain key figures (for
example, salary in a personnel InfoCube), or even for specific values of a
characteristic (for example, a certain cost center). You manage access rights
with the Administrator Workbench.
1.3.6 The presentation layer

The presentation layer is made up of the normal SAPGui and the MS EXCEL-
hosted Business Explorer; see Figure 3 on page 10. This interface is easy to
understand and to use.

Figure 3. Business Explorer example
1.4 The terminology used in this redbook

Official titles of software can be quite long, and the problem is compounded
when they are used in combinations. Also, these titles are commonly used in
shorter versions by both the writers and readers of this redbook. Therefore,
we decided to use the shorter versions in this publication (unless there was a
likelihood of confusion over which specific product we are discussing); see
Table 1 on page 11 for the titles we used.

Table 1. Official names and usage in this redbook
Official product name Shorter version used in this redbook
DB2 UDB for OS/390 DB2
SAP R/3 Application server Application Server
SAP R/3 Database server DB server
SAP R/3 Central Instance Central Instance
SAP Business Information Warehouse SAP BW or BW
SAP Business Information Warehouse SAP BW DB server

Database Server
SAP Business Information Warehouse SAP BW Application server

Application Server
SAP Business Information Warehouse SAP BW Central Instance

Central Instance

Chapter 2. Our system environment
This chapter provides details about the systems we used during our tests.
Because our tests were based on the functionality of the SAP Business
Information Warehouse (BW), and the performance difference according to
design options, we used only part of the S/390 system.
As shown in Figure 4, we used:

• One S/390 LPAR with:
– One DB2 UDB 6.1 subsystem as the SAP BW database server
– One DB2 UDB 6.1 subsystem as the SAP R/3 database server
• One RS/6000 with AIX as an SAP BW application server
• One RS/6000 with AIX as an SAP R/3 application server
• Multiple Windows/NT machines as presentation servers (SAPGUI)
• FDDI connections between the database server and the application
servers
RS/6000 F50
SAP BW
9.12.0.73 1.2B T 9672-X77 (1 LPAR)
SAPGUI O
Application K
E OS/390 V2R7
Server N OSA I
-
C DB2 V6
R
(Central instance) I
N
TOKEN- L DBH1
T G RING I
o
k AIX 4.3.3
e S
n
- ALE E
R
RS/6000 F50 R DB2 V6
i
n
g
OSA V DB2Q
SAP R/3 E
4.5B F
FDDI R
D S
Application D
9.12.0.75 Server I
-
R
SAPGUI I
N
G
AIX 4.3.3 ESS

Shark
Figure 4. Test system environment for SAP BW application

Because SAP BW is designed to run in a 3-tier architecture environment, we
assumed that different groups of system programmers need to work together.
Therefore, we divided our work from the viewpoint of the SAP R/3 server-level
concept based on the hardware platforms as follows:
• S/390 platform for the database server
• RS/6000 platform for the application server
• Netfinity for the presentation server
2.1 OS/390 for SAP BW and R/3 database server

OS/390 was used as a database server for the SAP BW database and for the
SAP R/3 production database.
2.1.1 Hardware
We used the following hardware in our tests:
Processor
We used an IBM 9672-X77, which is a 7-way processor of the G6 family. We
ran 15 LPARs on this processor, and the OS/390 system that we used for this
redbook ran on one of the LPARs. We were given two shared processors at
first and later were assigned two additional shared processors. All time
estimates are related to the four-processor environment, unless stated
otherwise.
We did not see any degradation of our LPAR from the other LPARs on our
server. The OS/390 we ran always got as much power as it required.
Even though the 9672-X77 ran in a Parallel Sysplex with three other 9672
machines and three Coupling Facilities, our LPAR did not participate in the
sysplex. It worked as a standalone system.
Storage
We had 1024 MB of real storage and 64 MB of expanded storage. We did not
see any memory constraints.
Enterprise Storage Server (ESS)

We used 10 volumes of ESS DASD (Shark) for the source SAP R/3
databases, and 12 volumes of ESS DASD for the SAP BW database. After
installation of SAP BW, all volumes had about 50 to 80 percent free space.
We recommend that you have at least 10 volumes for SAP BW installation.

The ESS provides a highly available, scalable, easy-to-manage storage
subsystem that complements the strengths of S/390.
The logical disk architecture of the ESS spreads data across all the available
disks, reducing the requirement for data placement to avoid hot spots.
Additional physical storage capacity can be added nondisruptively. For more
information about ESS, refer to Appendix D, “Enterprise Storage Server
(ESS)” on page 115.
The volumes resided on an IBM ESS subsystem which was connected by

multiple controllers via switched ESCON. A pair of 2 volumes for each
database used one controller. Each controller had 2 ESCON paths. All DASD
was shared with the other LPARs.
We did not see major impacts to our work from the I/O subsystem. The DASD
response time we saw was about 3 to 5 milliseconds.
Connectivity
The OS/390 LPAR used two OSA-2 Adapters on the 9672-X77, which are
also shared by other LPARs:
• The EN-TR OSA-2 Adapter connected to a 16 Mb token-ring LAN and was
used for non-BW access to OS/390.
• The FDDI OSA-2 Adapter was used for all SAP BW and SAP R/3
application server-to-database server communication. These definitions
are not specific for SAP R/3 or BW.
For more information about connectivity, refer to SAP R/3 on DB2 for OS/390:
Connectivity Guide, SC33-7965.
2.1.2 Software environment

We used the following software and customized the system based on the
recommendations for our tests.
2.1.2.1 OS/390 Layout

We used OS/390 Version 2.7 at RSU9907 with ahead maintenance we
identified in OSS note 81737. Our operating system was produced by cloning
from a master, which is the normal way to produce systems in ITSO.
Workload Manager (WLM)

For our tests, the WLM setup was as simple as possible. We only used the
system-provided service classes SYSTEM, SYSSTC, TSO and BATCH.
SYSTEM is given distinct address spaces automatically. All other work,
except BATCH or TSO, is in service class SYSSTC, including the DB2
Chapter 2. Our system environment 15

address spaces and the ICLIs for a production SAP R/3 and BW. The
definitions to the service classes apply to standard recommendations in the
planning guide. See SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3
Release 4.5B, SC33-7964 for details.
We did not experience situations where one of our jobs or DB2 or ICLI was
waiting for CPU, storage or DASD resources claimed by other address
spaces in the system.
System Managed Storage (SMS)

We defined SMS for SAP application databases as shown in Table 2. (We did
not use SMS for DB2 system databases.)
Table 2. SMS naming convention for SAP applications
SAP BW appl. SAP R/3 appl.
Number of volumes 12 10
Storage group SGSAPBW SGSAPR3
Storage class SAPBW SAPR3
Management class default default
Data class default default
VSAM data set alias SAPBW SAPR3
In all constructs, additional parameters, such as those used for performance

or availability, were not used. Management class and data class were set
corresponding to system standards. That specifically means that DB2 data
sets are not migrated in any way.
We changed an ACS routine (definition of storage class and storage group) to

make these definitions effective. Figure 5 on page 17 shows the definition of
the storage class. Figure 6 on page 17 shows the storage definition that
connects storage class with storage group.
Storage class SAPBW includes all data sets that use SAPBW as a first
qualifier. All data sets that belong to storage class SAPBW are created in the
volumes that belong to storage group SGSAPBW. Of course, 12 volumes
were defined in the storage group SGSAPBW for the SAP BW application.

PROC STORCLAS
FILTLIST JANLOG INCLUDE(DB2V510U.ARCHLOG%.**)
FILTLIST SAPBWDS INCLUDE(SAPBW.**)
FILTLIST SAPR3DS INCLUDE(SAPR3.**)
/* FILTLIST REQ_SMS INCLUDE('LIBRARY','PIPE','HFS') */
....
WHEN (&DSN = &SAPBWDS)
DO
SET &STORCLAS = 'SAPBW'
EXIT
END
WHEN (&DSN = &SAPR3DS)
DO
SET &STORCLAS = 'SAPR3'
EXIT
END
.....
Figure 5. A storage class definition for SAP applications
PROC STORGRP
WHEN ( &STORCLAS = 'SAPBW' )
DO
SET &STORGRP = 'SGSAPBW'
EXIT
END
WHEN ( &STORCLAS = 'SAPR3' )
DO
SET &STORGRP = 'SGSAPR3'
EXIT
END
Figure 6. A storage group definition for SAP applications
ICLI server
Integrated Call Level Interface (ICLI) comes with OS/390 and provides a
remote SQL connection between application servers and database servers.
For SAP BW 1.2B, ICLI for SAP R/3 kernel 4.5B was needed. If your system
does not have the ICLI component, ask your OS/390 system programmer to
install it. See SAP OSS Note 81737 and the planning guide for more
information about ICLI Server.

During the execution of R3SETUP for BW installation, one DB2 plan and
three DB2 packages were created, as shown in Table 3, and the plan was
granted to the user ID of ICLIRUN automatically.
In our test, we used ICLIBLU as the ICLI server name, and user ID ICLIBLU
as a user who runs ICLI server. Therefore, we granted user ID ICLIBLU the
authority to run the plan explicitly, and authorized user ID ICLIBLU to run
started task ICLIBLU in the RACF database. For more information about ICLI,
refer to SAP R/3 on DB2 for OS/390: Implementing with AIX or WIndows NT
Application Servers, SG24-4945.
2.1.2.2 DB2 layout

We used DB2 V6.1 at PutLevel 9911 and checked Note 81737 for additional
required maintenance.
In order to test the functions of the SAP BW application, we needed test data.
Possible sources to extract such data from, as described by SAP R/3, are:
• SAP R/3
• SAP R/2
• Non-SAP source
We generated test data into flat files.
We had two DB2 systems in the same OS/390, as shown in Table 3.

Table 3. Information about DB2 systems
SAP BW application SAP R/3 application
DB2 subsystem name DBH1 DB2Q
IRLM name IRH1 IRLQ
HLQ of DB2 data set DB2V61H1 DB2V610Q
DB2 Load library DSN610.SDSNLOAD (V6) DSN610.SDSNLOAD (V6)
ICLI plan name FOMEP45B FOMEP45B
ICLI package name FOME45B1, FOME45B2, FOME45B1, FOME45B2,

FOME45B3 FOME45B3
All DB2 system parameters were configured as recommended in SAP R/3 on

DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964. You can
find the initial DB2 setup parameters of our DB2 system as shown in
Appendix B, “DB2 Installation parameters” on page 97.

There are minor differences between SAP R/3 and BW, from the DB2
perspective. If you already have an SAP R/3 system at your location, you can
refer to those DB2 system parameters for the SAP BW system; see the SAP
BW Installation manual for details.
2.1.2.3 Network connectivity

TCP/IP was used as the communication protocol between the OS/390 and
RISC/6000 running AIX. Access to our OS/390 system for TSO was on a
different LAN than the OSA-2 adapter that was used for OMVS. These LANs
were both token rings, running 16 Mb. IBM Personal Communications was
used for access TSO and OMVS. SAP and BW connectivity used the FDDI
OSA-2 adapter in the 9672 that is shared by other LPARs. For more
information about connectivity, refer to SAP R/3 on DB2 for OS/390:
Connectivity Guide, SC33-7965, or ask your network administrator.
We did not find any significant delays caused by connectivity during our tests.
2.1.2.4 User information

Table 4 shows the user ID information at the database server. These
definitions were all defined in RACF.
Table 4. User ID definitions
User ID RACF group ID OMVS user Remark
sapr3 (GID) Group ID
bluadm SAPR3 UID(0) SAP system administrator ID
ICLIBLU SAPR3 UID(0) ICLI server user ID
SAPADM1, SAPR3 SAP user IDs for tests

SAPADN2,
SAPADM3
• ICLIBLU should be authorized to run ICLI server under its ID (RACF).

• SAPR3 should be defined and authorized properly by DB2 before the
execution of R3SETUP.
2.2 AIX for SAP BW and R/3 application server

At least one UNIX system or NT server is needed for the SAP BW or SAP R/3
application server, respectively. We used two RS/6000s with AIX as SAP
application servers.

2.2.1 Hardware
We used two IBM RS/6000 F50 systems of the same size, one for SAP R/3
and the other for SAP BW, as follows:
• Two CPUs
• 1 GB of Memory
• 50 GB of disk space
• CD-ROM (important for installation)
• IBM token ring adapter
• IBM FDDI adapter
2.2.2 Software
We installed the following software in each AIX machine:
• IBM AIX Version 4.3.3
• SAP BW Version 1.2B central instance
• Maintenance required from SAP Note 81737
• FDDI Driver: SK-NET FDDI PCI Adapter V2.2
2.2.3 System setup for SAP BW

Before we installed the SAP BW code, we set up our SAP BW application
server. We decided to use several variables, and defined them as shown in
Table 5.
Table 5. SAP BW definitions
Our definition Remark
SAP system name BLU 3 byte
SAP mount /sapcd
ICLI procedure name ICLIBLU
Hostname erprisc1
IP address 10.1.1.73
Subnet mask 255.255.255.0
FDDI interface fi0
LANG= en_US

Our definition Remark
Language (additional) ISO8859-1

German de_DE
Language translation ISO8859-1
User information
Table 6. User ID information
User ID UID Remark
root 0
bluadm 205
sapadm1 202 SAPGUI user
Volume information
We created two volume groups in the physical volume, as shown in Table 7.
Table 7. Physical volume information
Volume group name Physical volume Partition size
sapgrp hdisk3 16
sap2grp hdisk2 64
File systems and raw devices

We allocated several file systems based on the recommendations in the
installation manual. But during our test, we met several storage shortage
problems, so we increased the size of those file systems. Table 8 shows the
file system allocation after the SAP BW installation.
Table 8. File system allocation for SAP BW code installation
File system name Description Space used Volume Permission

(# block) group bits
/usr/sap/trans Global transport directory for all 514288 sap2grp 771

SAP systems (200 MB)
/sapmnt/BLU Instance-specific data, symbolic 622592 sapgrp 755

links to the data for one system (300 MB)
/usr/sap/BLU Software and data for one SAP 786432 sap2grp 755
system (380 MB)
/tmp/install Installation directory 622592 rootvg 775

(300 MB)

2.2.4 System setup for SAP R/3
We assumed you have already installed SAP R/3 applications at your
installation. In our SAP R/3 system, all setup parameters were defined based
on the SAP R/3 Planning book. We used SAP R/3 system for the tests
regarding business content (BCT). For details, refer to 5.7, “Installing the R/3
PlugIn PI 99 or PI-A 99 for SAP BW” on page 72.
2.3 Windows NT for Presentation Server

In addition to the database server and application server, we also needed at
least a presentation server in order to use SAP R/3 graphical interfaces
(which are also used for SAP BW) on Windows, OS/2, MAC, Motif, or Java
platforms.
2.3.1 Hardware
We used up to four PC systems. (The number of PCs you need depends on
the number of users that are working concurrently.)
• IBM Netfinity 3000
• Pentium II at 350 Mhz
• 64 to 192 MB RAM
• Token Ring Adapter
• SCSI DASD
2.3.2 Software
All products used were at base level, unless otherwise stated.
ITSO standard
• MS Windows NT 4.0 (build level 1381, Service Pack 5)
• Lotus Smart Suite Release 9.5
• Norton Anti-Virus Version 5.02.04
• Adobe FrameMaker Version 5.5.6
• IBM Personal Communication 3270 Version 4.3
What we installed in addition

• SAP Frontend GUI Version 4.5B
• Patches for SAP GUI up to Level 09
• MS Office 2000 (with Excel in Version 9.0.2720)

• IBM Library Reader for Windows 2.02
Notes
• The SAP Frontend Installation for UNIX is described in chapter 6 of the
BW installation manual 51007613.
• We used the download manager of SAPNet, which recently became
available. It was self-explanatory but we encountered some time-out
problems while downloading. Since we did not find the reason, we started
several times and the download manager restarted without doing
completed work again.
• The Frontend Patch Level 09 was cumulative (all previous patches were
included). This patch installs manually: you get a zip file that extracts
about 30 files in one directory, and then you have to manually copy the 30
files into distinct SAP program directories.
• We installed Office 2000 for the SAP Business Explorer BEx. To ensure
we did not miss something needed later, we installed all the EXCEL
components, all converters, filters, and so on. This needs about 500 MB
on DASD.
• The latest OS/390 Library Collection CDs contains the Library Reader
2.02. Be sure to use this version, as it is able to read all books of the
December 1999 collection. Older versions will show error messages such
as book not properly stamped and so on.

Chapter 3. Preparing OS/390 and AIX
This chapter describes the preparation activities you need to perform when
you install SAP BW on DB2 for OS/390 from an AIX application server. It
focuses on SAP BW release 1.2B and the kernel 4.5B.
We grouped these activities into three phases:

1. During Pre-Installation Checking , we identified which functions and PTFs
needed to be installed prior to the SAP BW on DB2 for OS/390 installation.
2. During Defining the Configuration, we created a planning template to
ensure that parameters defined during the prerequisite installation and the
SAP BW on DB2 for OS/390 installation were consistent between the
database server and the central instance.
3. During Installing Prerequisites, we installed the missing functions based
on the findings in the Pre-Installation Checking phase.
The amount of work required will vary for each installation. We recommend
that you allow ample time to carefully complete the first three phases to
ensure that the actual installation of the SAP BW code will go smoothly.
For this task, the implementation project team should have the necessary
skills to configure the various components of the system that are described in
the chapter, consisting of:
• OS/390 system programmer
• DB2 system programmer
• DB2 DBA
• AIX or NT administrator
• SAP BASIS
• OS/390 UNIX
• Network administrator
• Security administrator
• Storage administrator

3.1 Pre-installation checking
The following documentation will be useful during your preinstallation
checking.
References
• Checklist–Installation Requirements: DB2 for OS/390, Material Number:
51006374
• SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B ,
SC33-7964
• Installation of the SAP Business Information Warehouse on UNIX DB2
for OS/390, Material Number: 51007613
• R/3 Installation on UNIX: OS Dependencies , Material Number:
51005979
• OSS Note #149473-DB2/390: 4.5B R/3 Installation on UNIX or WinNT
• OSS Note #81737-DB2/390: APAR List
As a three-tier client/server application, SAP BW on DB2 for OS/390 requires

certain hardware and software to be set up on the database server, on the
central instance, and on the presentation server. You must also set up
communication between them.
Refer to Checklist–Installation Requirements: DB2 for OS/390 51006374 for

the hardware and software requirements needed for the SAP BW on DB2 for
OS/390 installation.
The database server for SAP BW on DB2 for OS/390 runs on any S/390 (or
compatible) processor capable of supporting OS/390 Version 2.6 or higher.
Connectivity from the database server can be achieved in various ways.

• By using ESCON channel feature(s) on the S/390 database server and
ESCON channel adapter(s) on the gateway AIX application server(s).
• By using FDDI OSA-2 feature(s) on the S/390 database server and FDDI
LAN adapter(s) on the gateway AIX or NT application server(s).
• By using Fast Ethernet OSA-2 features on the S/390 database server and
FAST Ethernet adapter(s) on the gateway AIX or NT application server(s).
• By using OSA-EXPRESS Gigabit Ethernet feature(s) on the S/390
database server and Gigabit Ethernet PCI adapter(s) on the gateway AIX
application server(s).

• By using an ESCON, FDDI, or Fast Ethernet connection from the
database server to a router (such as the IBM 2216 Multi protocol Router)
and a LAN connection from that router to the gateway application servers.
One of the means of connection in the preceding list must be used. Refer to
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B,
SC33-7964, and SAP R/3 on DB2 for OS390 Connectivity Guide, SC33-7965,
for specific configuration information.
The central instance runs on any processor that supports AIX Version 4.3.2
or higher, or Windows NT Version 4.0.
The presentation service runs on Windows 3.1, Windows 95, Windows NT,
Motif(UNIX), OS/2, and MacIntosh. Note that a Java version of the GUI is
now also available.
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B,
SC33-7964, describes the preparatory steps and actual settings to be used
during and after installation. The installation guide, Installation of the SAP
Business Information Warehouse on UNIX DB2 for OS/390, 51007613,
directs you to use the values from the SAP R/3 on DB2 for OS/390: Planning
Guide SAP R/3 Release 4.5B over the ones it has listed in the case that any
should differ. The latest SAP R/3 planning guide for SAP R/3 will have the
more recent information.
The R/3 Installation on UNIX: OS Dependencies booklet contains detailed

information on the OS-dependent settings to be used.
Review OSS Notes 142990 and 149473 to get the latest list of the installation
requirements.
Review OSS Note #81737-DB2/390: APAR List to get the latest information
about the software fixes needed.
Chapter 3. Preparing OS/390 and AIX 27

3.2 Defining the configuration
The hardware configuration you need for SAP BW installation is shown in
Figure 7.
D a ta b as e S e rve r
SA PBW
C e n tral In sta nc e
FD D I
LAN
LAN
S A P P res e n tatio n O S /3 9 0 SAP BW

S e rve r DB2
s ys tem d is k s da tab
D D Fa s e d is k s
Figure 7. Physical SAP BW system configuration
System requirements for database server

• IBM S/390 mainframe with an OSA-2 adapter or ESCON channel
• Real and expanded storage
• DASD for OS/390 and DB2 system data sets
• DASD for SAP BW database
• OS/390 Version 2.7 or higher
• OS/390 UNIX enabled
• OSA-2 feature enabled in case you use OSA-2 adapter
• DB2 UDB Version 6 with PTFs

System requirements for application server
• Processors
• Real storage
• DASD (see 5.3, “SAP BW pre-installation: system check” on page 62)
• FDDI adapter or ESCON adapter
• AIX 4.3.3 or higher
These should be verified as adequate by reviewing the Checklist-Installation

Requirements: DB2 for OS/390.
To ensure consistency of definitions between the database server and central

instance, you need to compile all the definitions and parameters that require
coordination as shown in Table 9, Table 10, and Table 11.
Table 9. User ID setup
Description User ID (your value) TSO OMVS
SAP DB Owner No No
ICLI server No Yes
Submit job and OS/390 Yes Yes

UNIX
Table 10. TCPIP definitions
Description DBServer Central Instance
IP address
IP name
Device Address
Table 11. Other definitions
Parameter Description Your value
ICLI connection port
ICLI keep alive port
SAP system name
SAP system number
DB2 subsystem name
DB2 group attach name (Data Sharing only)

3.3 Installation prerequisites
Before the installation of SAP BW can begin, the S390 and the RS/6000
machines must be configured.
However, in the prerequisites installation, some parameters must match

between the database server and the central instance. Use Table 9, Table 10,
and Table 11 on page 29 as references when installing the prerequisites.
3.3.1 Database server setup

Based on our findings during the Pre-installation Checking phase, you should
plan additional tasks to be done prior to the SAP BW on DB2 for OS/390
installation, as follows:
1. Initialize DASD.
See 3.3.4, “DASD initialization on the database server” on page 32.
2. Configure OSA-2.
See 3.3.5, “Configuring OSA-2 on the database server” on page 32.
3. Install DB2 for OS/390.
See 3.3.6, “Installing DB2 for OS/390” on page 33.
4. Configure SMS.
See 3.3.7, “Configuring SMS” on page 34.
5. Customize OS/390 UNIX.
See 3.3.8, “Customizing OS/390 UNIX” on page 34.
6. Customize TCP/IP.
See 3.3.9, “Customizing TCP/IP on the database server” on page 34.
7. Customize High Speed UDP.
8. Set up ICLI Server.
See 3.3.10, “Customizing the ICLI Server” on page 36.
9. Customize RACF.
3.3.11, “Customizing RACF or equivalent” on page 37.
10.Set OS/390 Dispatching and I/O Priorities.
See 3.3.12, “Set OS/390 dispatching and I/O priorities” on page 39.

3.3.2 Application server setup
The following tasks should be performed on the application server:
1. Customize TCP/IP.
See 3.3.13, “Customizing TCP/IP on the central instance” on page 40.
2. Set up the ICLI Client.
See 3.3.14, “Setting up the ICLI client” on page 42.
Note: Because the ICLI code is supplied from OS/390, this step can only
be done after the connection with the database server is set up.
3.3.3 Database server and application server connectivity testing

There will be an opportunity to test basic LAN connectivity on both the
database server and central instance once all prerequisites have been
installed. If possible, you should verify that you are able to reach at least one
other remote IP address on the same network prior to checking connectivity
between the central instance application server and database server.
After each network connection has been verified, you can test connectivity
between the database server and the central instance application server.
Once the connection between the central instance and database server has
been verified, you start the BW installation process. R3SETUP will configure
the ICLI client during the central instance installation phase. When this phase
completes, you can check the communication between the ICLI server and
ICLI client with the R3trans -x command.

3.3.4 DASD initialization on the database server
The SAP BW installation includes thousands of indexes. Therefore, we
recommend that you initialize the volumes that are associated with the DB2
STOGROUPs with a minimum Virtual Table of Contents (VTOC) size of 250
tracks (this recommendation is based on a 3390 DASD unit).
During the installation of SAP BW, a large number of DB2 log records are
generated. Therefore, DB2 logs must tolerate up to 2 GB per hour. Archiving
is required and there must be at least 6 GB of archiving space if you have
DASD archiving. Most of this space can be reclaimed when SAP BW on DB2
for OS/390 is up and running.
Additionally, when you aggregate, you need a large temporary DB2 database
(DSNDB07). You should prepare this temporary database before
aggregation. Most of this space can be claimed after the aggregation
process.
3.3.5 Configuring OSA-2 on the database server
Reference
MVS/ESA Hardware Configuration Definition: User’s Guide, SC33-6468
The OSA-2 feature from the database server can be connected to the FDDI
network as shown in Figure 8.

O S /3 9 0 IP = 1 0 .1 .1 .2 1 2
C H P ID = 0 C
O S A -2 C on tro l U n it
22C0 N um be r
22C4 22 C5 O S A -2 D evic e N um b e rs U n it
A dd res s e s 0 0 /0 1
O S A -2 F e a tu re
FDD I LAN F D D I R in g
FD D I A d a p te r
IP = 1 0 .1 .1 .7 3
A IX o r W in d o ws N T
Figure 8. I/O configuration for the FDDI connection
See SAP R/3 Connectivity Guide, SC33-8965, for details on how to install
and configure the OSA-2 adapter.
3.3.6 Installing DB2 for OS/390
References
• SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B,
SC33-7964
• DB2 for OS/390 V5 Installation Guide, GC26-9008
• BC SAP Database Administration Guide: DB2 for OS/390, Material
Number: 51006377
The DB2 for OS/390 product must have been installed prior to the SAP BW
on DB2 for OS/390 installation.
After completing the SMP/E installation of the DB2 for OS/390 product, we
continued with the setup of DB2 for OS/390 parameters by considering the
recommended values given by SAP. For detailed information about DB2
preparation, refer to Chapter 4, “Preparing DB2” on page 47.

3.3.7 Configuring SMS
References
• DFSMS/MVS V1R5 Implementing System-Managed Storage,
SC26-3123
• DFSMS/MVS V1R5 DFSMSdfp Storage Administration Reference ,
SC26-4920
• DFSMS/MVS V1R5 General Information , GC26-4900
SMS-managed storage is required to store hierarchical file system (HFS)

data sets that are used by OS/390 UNIX. Define at least one volume on disk
to be managed by SMS.
With the SAP BW application, there a large number of DB2 tablespaces and
indexes. We therefore strongly recommend that you use SMS-managed
storage for SAP BW data sets efficiently. This will significantly reduce the
amount of work you have to do to define DB2 Objects.
3.3.8 Customizing OS/390 UNIX
Reference
OS/390 UNIX System Service Planning, SC28-1890
Before customizing TCP/IP, you have to set up an OS/390 UNIX environment,

according to the steps described in OS/390 UNIX System Services Planning,
SC28-1890.
Normal TCP/IP for OS/390 UNIX must also be set up according to the steps
described in OS/390 UNIX System Services Planning.
In our case, we used Standard TCP/IP connectivity over FDDI for the
application server-to-database server communications.
3.3.9 Customizing TCP/IP on the database server
Reference
OS/390 SecureWay Communications Server: IP Configuration , SC31-8513

For successful ICLI server and client communication, the ICLI server must
know which port to monitor for ICLI client connection requests. There are
three methods for specifying the ICLI connection port to the ICLI server:
1. Specify the ICLI connection port in the OS/390 UNIX /etc/services file, in
the <TCPIP>.ETC.SERVICE file, or in <ICLI user ID>.ETC.SERVICES.
These files are interrogated in the order listed if the SERVICENAME or
PORT is not specified as an argument to the fome45bs command.
2. Specify the ICLI connection port via the SERVICENAME argument of the
fome45bs command. This will be used to interrogate the file(s) listed in
option 1. The files will be searched in the order listed for a matching
service name.
3. Specify the ICLI connection port via the PORT argument of the fome45bs
command. This will override any port number derived from a service
name.
We recommend that you use the first method, except when you are running
multiple ICLI servers in the same OS/390 LPAR. See Chapter 9 in SAP R/3
on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B for details. The
redbook team used the third method.
3.3.9.1 Service name and port entries

The connection port used by ICLI and by ICLI keep-alive can be chosen
freely from the available services. The values must match the specification in
the services file and TPPARAM on the central instance.
In our environment, we chose 33666 as the ICLI connection port, and 33667
as the ICLI keep-alive connection port. Note that the keep-alive port number
is not necessary when using TCP/IP. We used the PORT argument of the
fome45bs command to tell the ICLI server which port to monitor for ICLI client
connection requests. We added the following entries to the OS/390 UNIX
/etc/services file to document that the ports are in use.
#
# SAP ICLI ports
#
fome45bs 33377/tcp # SAP ICLI server port

3.3.10 Customizing the ICLI Server
Reference
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B ,
The steps to customize the ICLI server are as follows:

• Define the environment file.
• Define the start up JCL.
The bind and grant activities required for the ICLI server are performed by
R3SETUP during the central instance installation. For more information, see
Chapter 4, “Preparing DB2” on page 47.
3.3.10.1 Define the Environment File

Following are the environment variables used by the ICLI server started task.
In our test, this was defined in the file /u/bluadm/iclienv; see Figure 9.
TRACE=1
ICLI_TRACE_LEVEL=0
ICLI_MSGLEVEL=I
ICLI_TRUSTED_CONNECTIONS=1
NLSPATH=/usr/lib/nls/msg/%L/$H
STEPLIB=DSN610.SDSNLOAD
Figure 9. ICLI environment file
During the testing of ICLI, you can set the ICLI_TRACE_LEVEL to 1, 2, or 3.

However, we recommend that when you load the database, and then begin
running the system, you set the ICLI_TRACE_LEVEL to 0 to reduce the
storage space requirement of the OS/390 UNIX HFS and provide better
performance.
3.3.10.2 Define the startup JCL

You can use the started task technique to start ICLI. The ICLI started task
JCL can be put as a member in SYS1.PROCLIB or another PROCLIB.
Figure 10 on page 37 is a copy of the ICLI server started task JCL, called
ICLIBLU, that we used.

//*********************************************************************
//* *
//* *
//* ICLI server startup for SAP BW on DB2 for OS/390 *
//* *
//* *
//*********************************************************************
//ICLIBLU EXEC PGM=BPXBATCH,TIME=NOLIMIT,REGION=200M,
// PARM='PGM /usr/sbin/fome45bs -PLAN FOMEP45B -LOGDIR /u/bluadm/ -TCP
// -PORT 33666'
//STDENV DD PATH='/u/bluadm/iclienv'
//STEPLIB DD DISP=SHR,DSN=DSN610.SDSNLOAD
//STDERR DD PATH='/u/bluadm/icliserv.err',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRWXU)
//STDOUT DD PATH='/u/bluadm/icliserv.out',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRWXU)
//SYSUDUMP DD SYSOUT=*
//SYSMDUMP DD SYSOUT=*
Figure 10. ICLI started procedure
You can use a copy of the file /u/bluadm/iclitask.jcl (where bluadm is SAP
administrator’s ID) and adapt it to your needs. Remember to specify -TCP for
the protocol in use.
Note that it is possible to use //STDENV DD * and specify variables within this
JCL stream. Some installations have found this to be convenient.
3.3.11 Customizing RACF or equivalent
References
• OS/390 Security Server (RACF) Security , SC28-1915
• OS/390 Security Server (RACF) Support for OpenEdition DCE,
SOMobjects for MVS, and SystemView for MVS , GC28-1924
The following definitions should be established when you configure the

security using RACF or equivalent:
• User definition
• OS/390 UNIX facility
• Started task protection

3.3.11.1 User definition
The following user IDs must be defined to RACF:
• SAP DB owner (in our case, SAPR3)
• ICLI server user ID (in our case, ICLIBLU)
• SAP system administrator ID (in our case, BLUADM)
The RACF commands that you can use to define the group and user ID are
as follows:
ADDGROUP OMVSGRP OMVS(GID(1))

ADDUSER ICLIBLU DFLTGRP(OMVSGRP) OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))
Note that ICLIBLU is defined as an OS/390 UNIX user. The superuser has
UID(0), and can bypass all file security, as well as run any administrative
commands.
3.3.11.2 The OS/390 UNIX facility

OS/390 UNIX uses a new RACF class, FACILITY, and the FACILITY class
profile BPX.DAEMON. If they are not defined on your system, they can be
defined with the following statements:
RDEFINE FACILITY BPX.DAEMON UACC(NONE)

SETROPTS CLASSACT(FACILITY)
SETROPTS RACLIST(FACILITY)
We created an OS/390 UNIX user ICLIBLU and granted it the class profile for
daemon administration, BPX.DAEMON, as can be seen in the following
RACF statements:
PERMIT BPX.DAEMON CLASS(FACILITY) ID(ICLIBLU) ACCESS(READ)

SETROPTS RACLIST(FACILITY) REFRESH
3.3.11.3 ICLI started task

We used the RACF STARTED class to associate the ICLIBLU user ID with
the ICLI started task. When the ICLI procedure is started at the console, it
runs as the ICLIBLU user.

RDEFINE STARTED ICLI.* STDATA(USER(ICLIBLU),GROUP(OMVSGRP))
SETROPTS RACLIST(STARTED) REFRESH
3.3.12 Set OS/390 dispatching and I/O priorities

For information concerning OS/390 dispatching and I/O priorities refer to
Chapter 7 in SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release
4.5B , SC33-7964.
With SAP R/3 4.5B, the ICLI server uses an attachment to Workload Manager
(WLM). In our test, we used WLM. In order to manage ICLI server work
threads using WLM, we did the following:
• We defined the BPX.WLMSERVER profile in RACF:
RDEFINE FACILITY BPX.WLMSERVER
• We gave ICLIBLU user ID read access to this profile:
PERMIT BPX.WLMSERVER ACCESS(READ) CLASS(FACILITY) ID(ICLIBLU)
• We refreshed the access lists to put the changes into effect:
SETROPTS CLASSACT(FACILITY) REFRESH
• We added a new WLM subsystem with the name SAP. To do this, we

started the ISPF application of WLM, chose option 6 (classification rules),
and used option 1 to create a new subsystem. The following entries were
made in this subsystem definition:

Subsystem-Type Xref Notes Options Help
--------------------------------------------------------------------------
Modify Rules for the Subsystem Type Row 1 to 7 of 7
Command ===> ____________________________________________ SCROLL ===> PAGE
Subsystem Type . : SAP Fold qualifier names? Y (Y or N)

Description . . . WLM definition for SAP R/3 4.5B
Action codes: A=After C=Copy M=Move I=Insert rule

B=Before D=Delete row R=Repeat IS=Insert Sub-rule
More ===>
-------Qualifier------------- -------Class--------
Action Type Name Start Service Report
DEFAULTS: SAPICLI ________
____ 1 UI ICLIBLU ___ SAPICLI ________
____ 2 TN GENERIC ___ SAPICLI ________
____ 2 TN DIALOG ___ SAPICLI ________
____ 2 TN UPDATE ___ SAPICLI ________
____ 2 TN UPDATE2 ___ SAPICLI ________
____ 2 TN SPOOL ___ SAPICLI ________
____ 2 TN BATCH ___ SAPICLI ________
3.3.13 Customizing TCP/IP on the central instance
References
for OS/390, Material Number 51007613
SC33-7964
Number: 51006377
On the central instance, we modified the /etc/hosts file. The R3SETUP tool
adds the appropriate ICLI client and keeps alive port entries to the
/etc/services and /usr/sap/trans/bin/TPPARAM files.
3.3.13.1 Hosts file

We added the following entries to the /etc/hosts file:

10.1.1.212 wtsc62f #OS/390 address by UDP from AIX
10.1.1.73 erprisc1 #AIX address by UDP from OS/390
3.3.13.2 Services file

R3SETUP adds the following entries to the /etc/services file:
# SAP specific services
sapdp00 3200/tcp # SAP R/3 dispatcher port
| |
v v
sapdp99 3299/tcp
sapgw00 3300/tcp # SAP R/3 gateway port
| |
v V
sapgw99 3399/tcp
sapmsBLU 3600/tcp # SAP R/3 message server port
# ICLI specific services
sapdb2BLU 33377/tcp # ICLI port
iclikaBLU 33378/tcp # ICLI Keep Alive Port

3.3.14 Setting up the ICLI client
References
SC33-7964
Number: 51006377
The ICLI client code is provided in the OS/390 PTF containing the ICLI
server. The executables FOME45BA(client) and FOME45BK(keep alive) can
be found in the <HLQ>.SFOMDATA, where HLQ is the High Level Qualifier
for your UNIX System Services data sets. R3SETUP will download these to
the /sapmnt/<SAPSID>/exe directory and rename FOME45BA to ibmiclic.o
and FOME45BK to ibmiclika.
3.3.14.1 ICLI client code

The ICLI client code is downloaded by R3SETUP from the OS/390 system
during the installation of the central instance.
If the ICLI server on the OS/390 system is changed, you will have to manually
transfer the members FOME<REL>A and FOME<REL>K from the OS/390
SYS1.SFOMDATA data set to the central instance. Rename FOME<REL>A
to ibmiclic.o and FOME<REL>K ibmiclika, and place them in the
/sapmnt/<SAPSID>/exe/ directory. Ensure that these files belong to
<sapsid>adm and have permissions set to 755(-rwxr-xr-x).
Notes
• <sapsid> is the SAP system name in lowercase.
• <SAPSID> is the SAP system name in uppercase.
3.3.15 Testing connectivity -- central instance and database server

The connectivity between the database server and the central instance can
be tested by using the ping command from the central instance and oping
from the database server.
To test TCPIP protocol, we performed these commands:

• From the central instance:
ping 10.1.1.212

• From within OS/390 UNIX on the database server:
oping -c 1 10.1.1.73
If the ping and oping commands are successful, then the connectivity
between the database server and the central instance has been established.
3.4 Installing SAP BW on DB2 for OS/390
References
for OS/390, Material Number 51007613
• SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B ,
SC33-7964
This section describes the steps we performed during the installation of SAP
BW.
3.4.1 General notes on the installation from AIX

With SAP R/3 4.5B, the installation tool is called R3SETUP. It has a real
graphical interface, the INSTGUI, which provides a more comfortable look
and feel. It also provides integrated help documentation and the ability to
view the activity log during and after installation. When R3SETUP is started,
you are given the option of using the GUI or running from the command line.
Beginning with R/3 4.5B and all New Dimension Products, SAP no longer
uses script files CENTRAL.SH, DATABASE.SH, DBDROP.SH, and
DIALOG.SH.
SAP R/3 now uses script file INSTTOOL.SH to create command files
designed for specific installations. This shell script can be found in the
/<kernel-CD>/UNIX directory.
To generate the command files, the following command must be executed

from the installation work directory:
/<kernel-cd>/UNIX/INSTTOOL.SH
3.4.2 Hints and tips -- installing with AIX

1. There is a large amount of print documentation about installation when
using AIX and related topics contained in the \doc directory created in the

installation work directory when running INSTTOOL.SH. This
documentation is HTML-based and can be viewed and printed with any
Web browser.
2. Make sure that the worksheet has been prepared before executing the
installation shell script and R3SETUP.
3. If you make a mistake in typing an answer during the build process of the
command file, re-execute the build process from the beginning. One way
to do this is to rename the current command file, CENTRAL.R3S for
example. Then rename the initial command file CENTRAL.R3S.1 to
CENTRAL.R3S.
4. The command file will be updated by the R3SETUP program during the
install process.
5. To use the INSTGUI tool, you will need either Windows 95 or NT, or Motif
installed on an AIX system.
6. To view the R3SETUP documentation and help files, you will need a
browser that supports frames, such as Netscape.
7. The first time you start the R3SETUP program, it will ask if you want to use
the graphical installation tool. If you answer Yes, it will start INSTGUI for
you.
8. When you later need to restart the installation process, the INSTGUI
program must be started before the R3SETUP program. The R3SETUP
program must then be started with the following options:
R3SETUP -f <command file> -g <x-term_address>:61312
9. Every time R3SETUP is restarted, it will copy the log from the last run to a
different file. The current log file will always have the name <command
file>.log, while the old log is named <command file>.log.<number>. The
file with the highest number will be the newest old log file.
10.We recommend restarting INSTGUI when you are restarting R3SETUP.
The reason is that the number of errors and error messages shown by
INSTGUI are accumulated from the previous failed R3SETUP runs. It can
be difficult to determine which errors occurred in the current execution of
R3SETUP if you do not restart INSTGUI also.
11.The percentage indication on the INSTGUI does not show the percentage
of the actual work completed in hours. Instead, it shows the percentage of
steps completed.

12.Each phase of the database load has a unique name. This name is
assigned to the load process and log associated with a particular phase. If
an error occurs with one of the processes, you must check two logs:
DBBW.log and <process name>.log.
Reference

for OS/390, Material Number: 51007613
The SAP BW on DB2 for OS/390 installation can only be started if the
network connection has been established between the database server and
the central instance. Refer to 3.3.15, “Testing connectivity -- central instance
and database server” on page 42.
The steps needed for SAP BW installation are detailed in Chapter 5,

“Installing SAP BW OS/390 with AIX Application Servers” on page 59.

Chapter 4. Preparing DB2
This chapter describes the tasks you must perform to prepare the DB2
system for the SAP Business Information Warehouse (BW) application. Most
recommendations for the DB2 for SAP BW application are the same as for
SAP R/3. For detailed information about DB2 parameters and administration,
refer to SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B,
SC33-7964, and DB2 UDB for OS/390 Version 6 Installation Guide,
SC26-9008.
4.1 Inside the SAP BW database

After installation of SAP BW 1.2B, you will have a number of databases,
tablespaces, tables, and indexes as shown in Table 12.
Table 12. Statistics of the DB2 objects of SAP BW
Items Statistics of the DB2 objects
Number of DB2 databases 2201
Number of tablespaces 2201
Number of tables 4164
Number of indexes 4459
Average number of rows per table 1655
Number of rows of the largest table 500,585
The SAP BW system has its own structure of DB2 objects, such as a large
number of databases, tablespaces, and so on. Therefore, prior to installing
SAP BW code, you need to prepare your DB2 system to manipulate those
DB2 objects effectively.
4.2 Prerequisites of DB2

DB2 UDB for OS/390 Version 6 is a prerequisite for the SAP BW application
because the BW application utilizes DB2 Version 6 new features. In addition,
before you start to install SAP BW 1.2B, you need to make sure that all
required DB2 PTFs for SAP BW are applied to your DB2 system. Check the
DB2 PTFs in SAP Note 81737 and recent SAP Notes for possible
maintenance.

4.3 OS/390 setup for DB2
From an OS/390 perspective, these two items should be considered before
installing the SAP BW code.
Large VTOC
The SAP BW installation includes a very large number of data sets. It is
therefore recommended that you initialize the volumes that are associated
with the DB2 storage groups with a large VTOC that is at least 250 tracks on
a 3390 DASD unit for BW application. (For SAP R/3 applications, 400 tracks
are recommended.) Refer to SAP BW installation documentation for more
information.
Separate VSAM user catalog

With regard to the VSAM catalog size of the SAP BW data sets, we
recommend that you create a separate user catalog with a size of 20
cylinders for the primary allocation and 5 cylinders of secondary allocation.
This is based on a 3390 DASD unit. If you are going to use the VSAM catalog
of the DB2 subsystem, make sure that it is large enough to hold all the
information contained in the SAP BW data sets.
4.4 Setting up RRS

The Integrated Call Level Interface (ICLI) server for SAP BW 1.2B (R/3 kernel
4.5B) exploits the Recoverable Resource Manager Service Attachment
Facility (RRSAF). The RRSAF is a DB2 attachment facility that relies on an
OS/390 component called OS/390 Transaction Management and
Recoverable Resource Manager Services (OS/390 RRS). OS/390 RRS
provides system-wide services for coordinating two-phase commit operations
across OS/390 products.
Note that if you have already installed SAP R/3 4.5B, there is no extra setup
for RRS necessary for SAP BW. For more details about how to set up RRS,
see Appendix C, “How to set up RRS” on page 109 , or talk to your S/390
system administrator.
4.5 Customizing DB2 parameters

For optimal operations and performance, SAP BW requires specific DB2
parameter settings. A few of them are considered mandatory, and these must
be specified with the stated values in this section. If not, you will get errors at
your execution of R3SETUP.

For the settings we used in our installation, refer to Appendix B, “DB2
Installation parameters” on page 97 .
Required DB2 system parameters

Table 13 shows the required DB2 parameters for setting up SAP BW 1.2B.
Most parameters are defined in DSNZPARM, while some are in DSNHDECP.
Table 13. DB2 parameter checked by R3SETUP (BW)
Parameter Value Remark
CACHEDYN Yes Save prepared, dynamic SQL statement for later use.
DSMAX 7000 Maximum number of DB2 data sets open at a time.

You can have up to 6660 data sets for tablespaces and
indexes.
NUMLKUS 0 Zero (0) means there is no limit to the number of page

and row locks a program can acquire.
ASCCSID 819 US English in ASCII AIX. Defined in DSNHDECP.
ENSCHEME ASCII Specify the default format in which to store data in DB2.
SAP BW application uses ASCII format data, defined in
DSNHDECP.
SMFSTAT 1,3 Class 1 provides information about system services and

database statistics.
Class 3 provides information about deadlocks and
time-outs.
SMF record type 102 should be defined.
DECARTH DEC15 It does not allow a precision greater than 15 digits.
DECIMAL . (period)
Recommended DB2 system parameters

The recommended DB2 parameters are also listed under SAP R/3 on DB2 for
OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964.
Invalid parameters in DB2 V6

The following parameters are no longer valid in DB2 Version 6:
• ALPOOLX
• INBUFF
• OJPERFEH
Chapter 4. Preparing DB2 49

Recommended IRLM parameters
These values are defined in the IRLM start procedure:
Table 14. Highly recommended IRLM parameters
Parameter Value Recommended value
PC Yes Yes puts the lock control block structure in the IRLM
private address space, and the program call instruction
is used to address to the structure.
DEADLOK 5,1 5 specifies the local deadlock detection cycle.

1 specifies the number of local deadlock cycles that must
expire before the IRLM performs global deadlock
detection processing. This is used only for data sharing.
Bufferpools allocation
Table 15 shows the recommended DB2 bufferpool settings for SAP BW
tablespaces, indexes, work files, and DB2 system databases.
Table 15. Recommended DB2 bufferpool allocation
Buffer pool VPSIZE VPSEQT DWQT VDWQT HPSIZE HPSEQT CASTOUT
BP0 (system) 5,000 50 50 10 0
BP1 5,000 100 70 50 0

(work files)
BP2 (4 KB 20,000 50 30 5 40,000 50 YES

tablespaces)
BP3 (index 30,000 40 30 5 60,000 40 YES

spaces)
BP4 (VB 1,000 10 70 50 0

protocol)
BP32K 2,000 50 30 5 4,000 50 YES

(tablespaces)
We recommend that you allocate BP0 as 5000 because the SAP BW

application uses dynamic SQL, and because a large number of DB2 objects
will be created.
4.6 DB2 system database requirements

Several specific requirements for DB2 system databases (such as the DB2
catalog and directory) should be considered prior to installing SAP BW
applications. In this section, we summarize these requirements.

4.6.1 DB2 catalog and directory database size
In the installation process of SAP BW, a large number of DB2 objects are
created as shown Table 12 on page 47. This requires a larger catalog and
directory database than the default size. Table 16 shows the recommended
values for DB2 installation panel DSNTPID, which generate a job that creates
VSAM data sets for the DB2 catalog and directory database.
For SAP BW applications, we recommend you refer to these values to

estimate the size of the DB2 catalog and directory database as well as the
size of main storage. When you are building a new DB2 system for an SAP
BW application, you should use the values in Table 16 for DB2 the installation
panel DSNTPID.
Table 16. DB2 installation panel DSNTPID
Field Standard SAP recommended values
DATABASE 7000
TABLES 3
COLUMNS 20
VIEWS 1
TABLESPACES 1
PLANS 100
PLAN statements 30
PACKAGES 200
PACKAGE statements 30
PACKAGE lists 2
EXECUTED statements 30
TABLES in statement 2
TEMP 4 KB SPACES See 4.11.2, “DB2 temporary database

(DSNDB07)” on page 58
TEMP 4 KB data sets See 4.11.2, “DB2 temporary database

(DSNDB07)” on page 58
TEMP 32 KB SPACES 40 MB
TEMP 32 KB data sets 2

4.6.2 Additional DB2 catalog indexes
Additional DB2 indexes against the DB2 catalog and directory are created
during execution of R3SETUP as shown in Table 17. You must ensure that
some DASD space is available in the volumes of the DB2 SYSDEFLT storage
group prior to execution of R3SETUP.
Table 17. New indexes created against the DB2 catalog tables during R3SETUP
Index creator Index name Table name
SAPR3 SYSTABLE~0 SYSTABLES
SAPR3 SYSTBLSP~0 SYSTABLESPACE
4.7 Preparing the DB2 log

Good performance of DB2 logging is very important because the SAP BW
installation executes heavy Data Definition Language (DDL), insert, update,
and delete activity. During SAP BW installation, a large number of DB2 tables
are created and a large number of rows are inserted, which causes a huge
number of DB2 log records.
In order to run the installation process effectively, we recommend the

following:
• Create multiple (more than three) and large DB2 active log data sets to
tolerate up to 2 GB per hour. We recommend that you have an entire 3390
volume available to use for a DB2 log data set. If you encounter a log data
set shortage, R3SETUP will be abended.
During the installation process for SAP BW, more than 6 GB of DB2 log
records are generated. We recommend that you allocate at least 10 GB of
DASD for a DB2 active log data. (With dual logging, you need double this
amount.)
In case you do not have enough DASD volumes for DB2 log, you probably
could get at least four DB2 log data sets as shown in Figure 11 on page 53
with tape archiving.
When a log data set DS01 is filled, log data set DS02 takes it over. You
can then archive DS01 to tape without I/O contention. In the same way,
when DS02 is filled, it is then switched to DS03. DS02 can be archived to
tape, and so on.

LOGCOPY 1 LOGCOPY 2
DS01 DS02 DS01 DS02
DS03 DS04 DS03 DS04
Figure 11. Allocating DB2 active log data sets
Note the following recommendations:

• Use tape for archiving log data sets.
• Use dual logging and dual archiving.
• Do not share volumes on which DB2 log data sets reside with other highly
active data sets.
• Turn on the DASD Fast Write feature if possible.
• Add as much non-volatile storage (NVS) as you can afford.
4.8 DB2 Binding for the ICLI server

During the installation of the BW system, the installation tool R3SETUP binds
the default plan FOMEP45B for the ICLI server. Although it is not necessary
to use a plan name other than the default plan name, it is useful to have
different plan names for different ICLI servers connected to the same DB2.
If you want to use your own ICLI server-specific plan name, you need to bind
a plan by modifying and submitting a sample job FOME45BB, and authorize
the plan and other DB2 objects by submitting a sample job FOME45BG. Two
jobs are located in SYS1.SAMPLIB. For more information about DB2 tasks for
the ICLI server, refer to SAP R/3 on DB2 for OS/390: Planning Guide SAP
R/3 Release 4.5B, SC33-7964.

4.9 DB2 authorizations
In this section, we summarize the required DB2 authorization you need to
implement in order to avoid the errors that can occur during the SAP BW
installation process. Most privileges are automatically granted in the process
of R3SETUP.
Table 18. DB2 authorization
User ID DB2 authority Remarks
SAPR3 SYSADM Some privileges are granted during

R3SETUP automatically.
But we recommend you grant SAPR3 as
DB2 SYSADM.
ICLIRUN Execute on plan These are granted during R3SETUP

FOMEP45B and automatically. If you use different a user ID
TRACE, MONITOR1, under which the ICLI Server runs, you have
MONITOR2 to grant the required privileges to the new
user ID manually.
R3SETUP creates the bind and grant JCL with defaults, provides an
opportunity to modify the defaults, and then submits the jobs. If you look at
member SYS1.SAMPLIB(FOME45BG), you will see what kind of privileges
and authorizations are granted during the installation process. Do not change
the original job because the R3SETUP installation step needs the original
version of the job. Instead, adapt a copy of the FOME45BG job to your
requirements.
4.10 Maintaining DB2 catalog statistics

This section describes the maintenance of DB2 catalog table statistics, which
significantly affects the elapsed time of analytical queries. With poor DB2
catalog information, your query could run up to 50 times longer. Updating
catalog statistics should be done after loading data into the BW database.
4.10.1 RUNSTATS utility considerations

At installation
In the SAP BW installation directory (in our test environment this was
/tmp/install), there are several JCL templates for the RUNSTATS utility that
are used during execution of R3SETUP.

At maintenance (delta update or aggregation)
Sometimes the SAP BW system generates new DB2 objects that did not exist
at data loading, delta updating, and so on. However, DB2 database
administrators may not notice this, and therefore, they may not run the
RUNSTATS utility for these new objects. This can result in the DB2 optimizer
building less than optimal access paths with old statistical information about
the data when you run analytical queries.
To avoid this situation, we strongly recommend that you build procedures

using REXX, COBOL, or any other language that builds RUNSTATS jobs by
querying the DB2 catalog.
4.10.2 Updating DB2 catalog statistics manually

Because many SAP BW tables start empty and grow very rapidly, for each
OLAP query against InfoCube, a tablespace scan should be avoided even for
a small or empty table, if there is an index that has at least one matching
column for a given SQL statement’s predicates.
Therefore, if you use DB2 Version 5, we recommend that after each

RUNSTATS job, you always perform this set of catalog updates as shown in
Figure 12 on page 56. These SQL statements update DB2 catalog
information for small tables or empty tables. Of course, if RUNSTATS was run
for few tables only, then it is reasonable to do the updates for those tables
only by specifying database name, tablespace name and/or table name
respectively.
If you use DB2 Version 6, set new DSNZPARM parameter NPGTHRSH=10 to

get the same result. You need DB2 APAR PQ33429 for this. For more
information, refer to OSS note 192320.

UPDATE SYSIBM.SYSTABLES
SET CARDF=50, NPAGES=10
WHERE CREATOR = 'SAPR3' AND TYPE='T' AND NPAGES <= 10;
UPDATE SYSIBM.SYSTABLESPACE
SET NACTIVE=10
WHERE CREATOR = 'SAPR3' AND NACTIVE <= 10;
UPDATE SYSIBM.SYSTABSTATS
SET CARD=50, NPAGES=10
WHERE OWNER = 'SAPR3' AND TSNAME IN
(SELECT NAME FROM SYSIBM.SYSTABLESPACE
WHERE CREATOR='SAPR3' AND NACTIVE <= 10) ;
UPDATE SYSIBM.SYSINDEXES
SET CLUSTERRATIO=0,
FIRSTKEYCARDF=-1, FULLKEYCARDF=-1, NLEAF=-1, NLEVELS=-1
WHERE TBCREATOR = 'SAPR3' AND TBNAME IN
(SELECT NAME FROM SYSIBM.SYSTABLES
WHERE CREATOR='SAPR3' AND TYPE='T' AND NPAGES <= 10) ;
UPDATE SYSIBM.SYSCOLUMNS
SET COLCARDF=-1, HIGH2KEY='', LOW2KEY=''
WHERE TBCREATOR='SAPR3' AND TBNAME IN
(SELECT NAME FROM SYSIBM.SYSTABLES WHERE NPAGES <= 10);
DELETE FROM SYSIBM.SYSCOLDIST

WHERE TBOWNER = 'SAPR3' AND TBNAME IN
(SELECT NAME FROM SYSIBM.SYSTABLES
WHERE CREATOR='SAPR3' AND TYPE='T' AND NPAGES <= 10) ;
Figure 12. An example of DB2 catalog updates
4.10.3 Maintaining catalog statistics for R/3 cluster tables

This task is also needed for the SAP BW database; refer to SAP OSS note
83335.
In DB2 for OS/390, the R/3 cluster tables need to be accessed in a special
way: the access path should match the index scan, with the matching
columns corresponding to the physical cluster’s key columns, and neither sort
nor list prefetch should be selected. If the tables are not accessed in this way,
there is a possibility of increased lock contention (including deadlocks).

In order to ensure that the cluster tables are accessed properly the catalog
statistics for the cluster tables need to be maintained as shown Figure 13.
update sysibm.systables
set npages=100, cardf=1000
where creator='SAPR3' and name in (
select tabname from sapr3.ddntt
where tabform='T' and tabtype='C' with ur) ;
update sysibm.sysindexes
set clusterratio=100, fullkeycardf=1000
where tbcreator='SAPR3' and uniquerule='P'
and tbname in (
where tabform='T' and tabtype='C' with ur) ;
Figure 13. Sample SQL statements for updating catalog statistics for cluster tables
If deadlocks occur even after catalog update, consider further updates as

shown in Figure 14.
update sysibm.sysindexes
set clusterratio=100, firstkeycardf=1000,
fullkeycardf=1000
where tbcreator='SAPR3' and uniquerule='P'
and tbname in (
where tabform='T' and tabtype='C' ) ;
update sysibm.syscolumns
set colcardf=1000
where tbcreator='SAPR3' and keyseq=1 and
and tbname in (
where tabform='T' and tabtype='C' ) ;
Figure 14. Sample SQL statements to avoid deadlock
Monitor your system carefully in order to detect if these catalog changes

adversely affect some access paths on the cluster tables.
We recommend that you refer to the latest documentation of SAP; it is

available as PDF files at:
http://www.s390.ibm.com/os390/bkserv/latest.html

4.11 Post-installation tasks
After SAP BW installation, you need to monitor the DB2 system and prepare
some post-installation tasks prior to further tests and production running.
4.11.1 Reorganization
After installation and testing, some data sets (most of them are index spaces)
have more than 20 extents (in extreme cases, they can have more than 100
extents), because the secondary space defined by SAP is too small.
Therefore, we recommend that you run the DB2 reorganization utility for
those indexes (or data sets) in order to achieve better extent management
and to prevent possible extension errors.
4.11.2 DB2 temporary database (DSNDB07)

Aggregation is the process of summarizing detailed level data in InfoCube
horizontally, vertically and chronologically. It executes complex SQLs, which
need a big DB2 temporary database; see 7.3, “Aggregate build” on page 85.
The size of the DB2 temporary database depends on the number of rows you
aggregate. We recommend that you estimate it with your SAP BW consultant
before starting the aggregation process.

Chapter 5. Installing SAP BW OS/390 with AIX Application Servers
This chapter describes the activities we performed when we installed SAP

BW on DB2 for OS/390. The activities can be grouped into six phases:
1. SAP BW pre-installation: data gathering
2. SAP BW pre-installation: system check
3. SAP BW pre-installation: final preparations
4. SAP BW installation
5. SAP BW post-installation: completing the installation
6. Installing the R/3 Plug-in PI 99 or PI-A 99 for SAP BW
5.1 SAP BW installation overview

The installation of SAP BW is a fairly straightforward process that is nearly
identical to the installation of SAP R/3. Following the processes outlined in
this chapter will allow you to accomplish your installation in the shortest
possible time.
The process begins with the gathering of data to support your BW installation
activities, then moves into a checkout of your system, and then to the
documentation of required installation parameters.
When you have all of the required information at hand, the BW installation is
then described in some detail. After the data has been loaded into the system
you will follow the post-installation process, and finally proceed to the
installation of the R/3 PlugIn (previously known as Business Content) into
your SAP R/3 system (if you are connecting to an SAP R/3 source system). If
you are connecting your SAP BW system to a non-R/3 system, the business
content/extractor provider or possibly the implementation partner will provide
the instructions and software necessary to install that component.
The runtime durations experienced by the SAP BW redbook team for each
major step of the installation are contained in Table 19 on page 60 and do not
account for the time between steps where we analyzed the system or let it sit
while we worked on other activities. (Your run times may vary, depending on
network implementation, available hardware, and frequency of problems
encountered.)

Table 19. Installation activities and runtime durations
Installation activities Execution time
Pre-installation: data gathering 4 hours
Pre-installation: system check 1 hour
Pre-installation: final preparations 1 hour
SAP BW installation 4 hours
Completing the installation 1 hour
SAP R/3 Plug In installation 4 hours
5.2 SAP BW pre-installation: data gathering

The first step toward a successful implementation of SAP BW on DB2 for
OS/390 is to gather all of the information that will be needed during the
installation, and to have it available in both softcopy and hardcopy formats.
We found it very easy to include the softcopy data into our project
documentation, and the hardcopy printouts were quite valuable during the
actual installation activities for immediate reference and note taking.
It is worth noting that it will be impossible to correctly install the software

without obtaining and applying the collected reference material prior to actual
installation activities.
5.2.1 Gathering the SAP notes via SAPNet R/3 Frontend

The SAP notes provide input important to the scheduling of installation
activities, which if ignored usually result in an incomplete system that will
soon be deleted. Some of the notes used by the redbook installation team are
listed in Table 20. Your installation project will have to gather the applicable
notes that are available at the time of your particular installation - the notes
are being updated very regularly and new notes can be created at any time.
Table 20. SAPNet R/3 Frontend Notes
Reference item Reference item description
Note 103135 DB2/390: Installing saposcol manually
Note 113457 DB2/390: 4.5A Installation on UNIX or WinNT
Note 116520 Installation/copying client 000 in the BW System

Reference item Reference item description
Note 118901 DB2/390: Transports for 4.5A
Note 121067 Help for BW notes
Note 135873 Additional info on installation BW-BCT 1.2B
Note 137480 INST: 4.5B R/3 Inst. on UNIX - OS Dependencies
Note 142990 INST: 4.5B R/3 Installation on UNIX
Note 144978 Your system has not been installed correctly
Note 149473 SAP R/3 4.5B Installation on UNIX and Windows NT
Note 149686 Known problems when applying BW patches
Note 154342 Applying BW Patch with SPAM leads to error TW103
Note 165121 BW Translation error
Note 165122 BW Translation error
Note 169100 DB2/390: BW Rel. 1.2B SR1 Installation on UNIX or

NT
Note 175534 Large BW Systems and Performance of Aggregate

build
Note 176616 BW Statistics
Note 178376 Problems w/ user exit variables with BW12B patch

12
Note 187537 SAPBWNews for BW 1.2B Support Package 16
Note 197240 SAP BW 1.2B performance patches
Note 77589 DB2/390: tp profile parameters in TPPARAM
Note 81737 APAR List for SAP R/3 on DB2 for OS/390
5.2.2 Searching for SAP notes

We searched for SAP notes based on the following criteria and updated our
project plan for the additional activities:
• BW-SYS-DB-DB2
• BW.SYS-DB-DB2
• BW-DB-DB2
• BW
Chapter 5. Installing SAP BW OS/390 with AIX Application Servers 61

5.2.3 Downloading patches and other information from SAPSERVx
The latest SAP code patches and fixes are available via anonymous ftp for
download from the SAPSERVx that serves your region.
The files that were download for this redbook system are identified in:
• BW Support Packages KW12B09.CAR - KW12B17
• SPAM Version 4.5B/0011 KD00028.CAR
• All Application Server executables (approximately 35 files)
Note: Always be sure to download the latest fixes and code.
5.2.4 Searching for installation documentation

Following is the documentation downloaded from SAPNet R/3 Frontend:
• Checklist: installation requirements - SAP Material Number 51005873
SC33-7964
• SAP R/3 on DB2 for OS/390: Connectivity Guide, SC33-7965
• Installation of the SAP Business Information Warehouse on UNIX DB2 for
OS/390, Material Number 51007613
• R/3 Installation on UNIX OS Dependencies , Material Number 51005979
• R/3 Installation on UNIX DB2 for OS/390, Material Number 51006375
• PI-A 99, PlugIn 99 for SAP BW, R/3 3.0F - 4.B, Material Number
51007713
• R/3 Add-On Installation and Delta-Upgrade Guide, Release 4.5B, Material
Number 51006041
5.3 SAP BW pre-installation: system check

Now it is time to take the information gathered in 5.2, “SAP BW
pre-installation: data gathering” on page 60 and apply the recommendations
to your system where appropriate, and to set aside any instructions that you
will need later in the installation process. It is also time to verify that the base
components of your database server and application servers are ready to
support the installation of SAP BW OS/390 with DB2.
You should have already installed and configured the base components of the
solution by this point in time. These would include the software on the S/390
Database Server (OS/390, OS/390 UNIX, TCPIP, JES, DB2) and the software

on the AIX or NT Application Server (AIX, TCPIP, NFS/mounts, etc.). The
information necessary to configure these components is found in:
SC33-7964
• R/3 Installation on UNIX OS Dependencies , Material Number 51005979
In addition, the manual R/3 Installation on UNIX DB2 for OS390, Release
4.5B, Material Number 51006375 may prove to be useful since installing SAP
R/3 is nearly identical to installing SAP BW.
We found that R3SETUP looks for adequate free disk space during the
installation, and we were forced to make the changes before continuing with
R3SETUP. The file system sizes we used for the redbook project are
contained in Table 21:
Table 21. AIX file system layout
File system/directory name File system space defined
/sapmnt/<sid> 327 MB
/usr/sap/<sid> 393 MB
/usr/sap/trans 393 MB
/tmp/install 100 MB
directory for Export CD copy 700 MB
At this time you should verify that all software maintenance is current or at
least equal to the minimum information contained in Note 81737. Always
obtain the most recent copy of Note 81737, as the information changes
regularly.
Don’t forget to install the German language fileset on the AIX Application
Server. While we have not been able to find a written requirement for this, we
have found nonetheless that it is necessary. You can check this with the AIX
command locale -a, and then look for the two languages in Table 22.
Table 22. AIX language filesets
Language fileset Output from locale -a command
English en_US.ISO8859-1
German de_DE.ISO8859-1

Now apply the remaining information from the data gathered in 5.2, “SAP BW
pre-installation: data gathering” on page 60.
5.4 SAP BW pre-installation: final preparation phase

The first activity in the final preparation phase is to ensure that you have all of
the information necessary to answer the installation script questions
contained in Table 23. Table 23 shows you the parameters you will need to
specify to R3SETUP and the values we used for the redbook project, and it
also has a place to record the values used during your installation of R/3.
Table 23. R3SETUP input required
R3SETUP variable name Our value Your value
SAP BW system name BLU
SAP BW system number 00
SAP BW installation /tmp/install

directory
SAP BW global directory sapmnt/BLU/exe
SAP BW CD-ROM location /sapcd

(on application server)
Message Server port 3600

number
(3600 + SAP system #)
R/2 Gateway no
Sysplex Failover no
(yes or no)
Sysplex Failover
Hostname
Sysplex Failover Port #
Pass Tickets no
(yes or no)
DB2 subsystem name DBH1
DB2 Group Attach name
DBServer hostname - wtsc62oe

OS/390 UNIX

R3SETUP variable name Our value Your value
DBServer hostname - FTP wtsc62

& Telnet
DB2 plan name for ICLI FOMEP45B

server
DB2 load library name DSN610.LOADLIB
DB2 runlib library name DB2V6H1.RUNLIB
DB2 Usercat name for BW SAPBW

data
JES held job class X
ICLI port number 33377
User ID for ICLI Server ICLIBLU
User ID for ftp to OS/390 BLUADM

(uid=0 & DB2 sysadm)
OS/390 ICLI code location SYS1.FOMEDATA
SAPOSCOL install no
(yes for now, no for later)
SAPOSCOL destination BWBLU

(RFC destination name)
SAPOSCOL gw host erprisc1

(hostname gw service runs
on)
SAPOSCOL gw service sapgw00

(from /etc/services)
SAPOSCOL code /u/<sid>/SAPOSCOL

directory in OS/390 Open
Edition
(any OS/390 UNIX
directory)
It is also necessary to know how to code a jobcard for a batch job. If you do
not know the format of your organization’s job card, ask your system
programmer to print you a hardcopy.
The final preparation activity is to draw a diagram of your entire SAP BW

environment. Such a diagram is useful to refer to both during R3SETUP and

later as a record of your installation. If feasible, ask the project team to review
it; this gives them an opportunity to see the entire system at a glance.
5.5 SAP BW installation

As previously mentioned, the SAP BW installation process is nearly identical
to the SAP R/3 installation process, and uses the same program (R3SETUP),
albeit with a different input file (DBBW.R3S) for creation of the BW Database.
R3SETUP -f CENTRAL.R3S Central Instance Installation
R3SETUP -f DBBW.R3S Database Instance Installation
See 5.5.4, “R3SETUP problem solving” on page 68 for a few ideas on where
to turn if you should encounter problems during installation. In addition, do
not forget about the files that can be used for debugging (and the parameters
that turn them on and off). Some of these files are listed in Table 24.
Table 24. Debugging file and locations
Filename Created by/location
ICLItrace.<pid>.xxx See environment variable

ICLI_TRACE_LEVEL
ICLI stderr & stdout See ICLI STC or script
OS/390 SYSLOG SDSF
5.5.1 Starting BW installation

Do not start this activity until you have obtained the values for your
installation, as noted in Table 23 on page 64, to use as input to R3SETUP.
Use the instructions contained in Installation of the SAP Business Information

Warehouse on UNIX DB2 for OS/390, Release 1.2B SR-1, 51007613.
Additionally, you may want to reference the latest version of the R/3
installation guide, R/3 Installation on UNIX DB2 for OS/390 , 51006375. Pay
close attention to the spelling and capitalization of commands and responses.
The command we entered to start the SAP BW Central Instance Application

Server installation was:
./R3SETUP -f CENTRAL.R3S

The command we entered to start the SAP BW Database Server installation
was:
./R3SETUP -f DBBW.R3S
Keep in mind that the installation of SAP products via R3SETUP and
INSTGUI is an interactive and iterative process. The GUI interface provided
by SAP prompts you to enter installation configuration information, and will
probably be stopped and restarted several times. Don’t get frustrated if this
happens more than you expected. It merely suggests that you probably could
have spent more time preparing for the installation. Additionally, there are a
few tips in 5.5.4, “R3SETUP problem solving” on page 68 to help you with this
task.
5.5.2 Building the BW database

You will eventually see the R3SETUP/INSTGUI messages indicating that the
SAP BW database is being built. The DDL required to create the DB2 objects
is being executed, and you will have DB2 storage groups, databases, and
tablespaces in place when R3SEUP moves into the next step, which is 5.5.3,
“Loading the BW database” on page 67.
5.5.3 Loading the BW database

The database load is more CPU-intensive than previous installation steps.
This is because the DB2 database is being loaded with data via INSERT SQL
statements from the R3SETUP program.
You will notice that both the ICLI and DB2 are accumulating service units.
Keep in mind that, after the installation is completed and your system is
running as a productive environment, the majority of resource consumption
will be attributed to the ICLI server task.
There are some steps that will automatically execute after the data is actually
loaded into DB2, and then you will be prompted to check the JCL and
command syntax that was created for the five DB2 RUNSTATS jobs. Check
these jobs for accuracy and either allow the system to try to run automatically
or EXIT R3SETUP and run them manually (don’t forget to update the
R3SETUP control file with STATUS=OK if you run them manually).
R3SETUP will then perform some more steps on your behalf and without your
intervention, until you see the message:
./R3SETUP finished.

Note: SAP recommends that you do not modify the installation log files
unless you know exactly what you are doing. Be sure that you are
comfortable performing a reinstallation from the beginning if you should
happen to do this incorrectly or inadvertently.
5.5.4 R3SETUP problem solving

We have provided a few problem-solving hints in Table 25 that may help you if
you should encounter problems during R3SETUP. However, it is expected that
you will have a certified SAP installer onsite to perform your installation. As
always, do not forget to make use of SAPNet R/3 Frontend to search for the
latest information regarding installation.
Table 25. R3SETUP problem-solving tips
Problem encountered Possible solution
R3SETUP getting started Check spelling, punctuation, and capitalization

(e.g. ./R3SETUP -f CENTRAL.R3S
e.g. ./R3SETUP -f DBBW.R3S)
INSTGUI doesn’t work Find someone familiar with exporting the

display.
See if you can run without the INSTGUI.
Connection to DB2 doesn’t work Was the DECHDECP module linked with all of
the parms in the planning guide?
Does ping work?
Does traceroute follow the correct path?
Are ICLI and DB2 started?
Look up ICLI messages in Appendix E of the
SAP R/3 on DB2 for OS/390: Planning Guide
SAP R/3 Release 4.5B.
Did you make the correct authorizations?
Does TPPARAM have the required entries?
Is the TP_DOMAIN_<SID> file correct?
Is the problem with R3trans or tp?
Search for SAP Notes.
RUNSTATS - submission or return Ftp the jobs to OS/390 and manually run them
code problems from there. Don’t forget to update the STATUS
field in the R3SETUP.R3S file to the value OK.
Check the JES2 parm SWA=ABOVE for STC.
Can’t logon to service.sap.com Ask BASIS team or consulting partner to assist

and request customer IDs.
Can’t logon to sapservx Ask BASIS team or consulting partner to assist

and request customer IDs.

Problem encountered Possible solution
Not sure what the problem is Check OS/390 UNIX file systems (df -k).
Check AIX file systems (df -k).
SAPGUI - incorrect installation Check contents of table INSTVERS; if there are

message two rows with the same timestamp, change the
second entry timestamp to be 1 second later;
save your changes.
SAPGUI - screen SAPMSYST in Check SAPNet R/3 Frontend for notes.

German
5.6 SAP BW post installation: completing the install

Update the profile files (located in /usr/sap/<SID>/SYS/profile/) with the
recommended values from SAP and the pertinent values for your site. The
parameters in Table 26 were set for our environment.
Table 26. R/3 Profile parameter changes.
Profile parameters Values
<SID>/system_language=E Set default language to English.
start_menu=RS00 Set default start menu to SAP BW

Administrator Workbench.
rsdb/obj/buffersize=32768 See Note 156957.
rsdb/obj/large_buffer_size=32768 See Note 156957.
rdisp/max_wprun_time=900 See Note 25528.
Stop SAP BW and restart it to activate your profile changes.
Initialize the transport environment via SE06 and STMS. SAP provides
information on how to do this in the online documentation CD-ROM. Log on
as SAP* & Client 000 and use transaction SE06 to initialize your SAP BW
environment as a single system environment (or multi, if you know your
landscape). Activate your system via transaction STMS.
Apply the SPAM update that is available for your SAP BW 1.2B BASIS kernel
level (ours was 4.5B). At this point you are able to apply the mandatory
transports that are described in the SAP Notes. Start the application of SAP
BW Support Patches. Since our version of SAP BW was 1.2B with SR1, the
next Support Patch to be added started with number nine and ended with

number seventeen. You can check the level of SPAM and applied Support
Packages on your system via transaction SPAM.
Fill out the paperwork to request a license from SAP. This takes only a few
minutes and is best done as soon as possible. Fax the form to the SAP
number that is pre-printed on the form. SAP is quite speedy and will probably
have a response to your license request within 24 hours.
Start a client copy of client 000 to client 100, and choose the profile
SAP_ALL.
Now it’s time to run backups. Create JCL to perform OS/390 Full Volume
Dumps of all volumes, and also scheduled tape backups of your AIX
Application Server.
5.6.1 Summary of the BW database

A brief summary of the objects created during the installation of SAP BW is
listed in Table 27.
Table 27. SAP BW DB2 UDB 6.1 OS/390 database statistics
BW DB2 UDB OS/390 object type Number of objects
Storage groups 16
Databases 2201
Tablespaces 2201
Tables 4164
Indexes 4459
AIX BW disp+work patch level July 30, 1999 patch number 156
DBSL patch number 151

5.6.2 Summary of the SAP R/3 source system
Table 28. SAP R/3 DB2 UDB 6.1 OS/390 database statistics
R/3 DB2 UDB OS/390 object type Number of objects
Storage groups 24
Databases 7348
Tablespaces 7348
Tables 16438
Views 3776
Indexes 19,210
AIX R/3 disp+work patch level July 30, 1999 compile date patch number
156 with DBSL patch number 151
5.6.3 SAPGUI/BWGUI
Prior to installing the SAP Frontend software for PCs and the Business
Explorer, you have to check the SAPNet R/3 Frontend notes for available
patches. The patches for Business Explorer will be delivered cumulatively,
which is different from the normal patch process. You only have to apply the
latest patch.
To apply a patch means that you have to replace some files on the installation
disk. We recommend that you copy the CD-ROM to a hard disk first and then
replace the files as described in the SAPNote that refers to the patch. Then
you may proceed like you would in a normal installation.
Note: You need to select both the SAPGUI and BW Add-ons during the
installation of the SAPGUI from the presentation CD-ROM.
It is required that you install MS Excel before installing the software for
Business Explorer. Ensure that all possible options are installed for MS Excel.
5.6.4 BW Patch installation

At installation time there were 17 BW patches for SAP BW 1.2B. The early
CD-ROMs that were shipped will require all of the BW patches to be applied.
The CD-ROMs that are marked as SR1 already have the first eight BW
patches included, so that will only require the remaining patches to be
applied.

Be very attentive to notes that refer to BW patch installation. Failure to import
the packages according to the documented procedure will result in many
hours of recovery activities and possibly a reinstallation of the code. An
example of this is that the SPAM version delivered on the SR1 Release is
4.5B/0000. The latest SPAM that we applied updated the SPAM version to
4.5B/0004 (and it was the same patch number - SAPKD00027).
The latest Business Explorer patch applied was number nine, and is
described in SAP Note 0190332.
5.7 Installing the R/3 PlugIn PI 99 or PI-A 99 for SAP BW

In this section we describe how to implement the PI-A 99 PlugIn since our R/3
system code has not been modified nor does it coexist with other SAP R/3
Add-ons or New Dimension Products; we do not cover the installation of the
PI-99 PlugIn at this time.
The installation of the PI-A 99 PlugIn for SAP BW is performed on the SAP
R/3 system. The SAP R3up method is utilized for the technical installation,
and care is required. Upgrades of SAP BW software via R3up follows the
standard SAP recommendation of first installing it on a non-production
system before working on a system that has data or functions you would like
to retain (known as the production system).
It is assumed that the SAP R/3 system is already installed, and merely
requires the installation of the SAP BW Plugin PI-A 99. If you are connecting
your SAP BW system to an R/3 system, and that system is not yet installed,
see SAP R/3 on DB2 for OS/390: Implementing with AIX or Windows NT
Application Servers, SG24-4945, which documents installation of R/3 on AIX.
If you will be connecting your SAP BW system to a source system other than
R/3, see your software provider and business partners for specific installation
information.
You must again follow the first five steps at the beginning of this chapter and
also listed here before doing the actual installation of the SAP BW PlugIn -A
99. Since the process is the same as for SAP R/3, only an abbreviated
description of each step is presented in the pages that follow.
1. SAP BW PlugIn -A 99 pre-installation: data gathering
2. SAP BW PlugIn -A 99 pre-installation: system check
3. SAP BW PlugIn -A 99 pre-installation: final preparations
4. SAP BW PlugIn -A 99 installation: upgrade

5. SAP BW PlugIn -A 99 post-installation: completing the installation
5.7.1 PlugIn -A 99 pre-installation: data gathering

It is imperative to find as much information as possible to support the
installation of the SAP BW PlugIn. The first stop should be the SAPNet R/3
Frontend, to look for OSS Notes. The next stop should be to look for the
specific installation guide for your particular PlugIn.
Another useful document is the Consultants Guide, ASAP for BW

Accelerator; see your SAP business consulting partner if you do not already
have a copy.
5.7.2 PlugIn -A 99 pre-installation: system check

Apply any changes requested by the data collected in the previous step.
Additionally, ensure that your plan of action has been updated to reflect any
recommendations for order of processing or for steps that can be added or
omitted.
AIX file systems were created to support the installation of the PlugIn. The
specific file system sizes can be found in Table 29.
Table 29. File system size for PlugIn
PlugIn file systems File system sizes
/tmp/install_plugin 300 MB
/usr/sap/put 300 MB
5.7.3 PlugIn -A 99 pre-installation: final preparations

Obtain a copy of the SAP R/3 pre-installation documentation from your R/3
install in case you need to reference any of the specific install data. If
possible, it would be useful to have a BASIS-skilled person who was present
for the SAP R/3 install to assist in the install of the PlugIn. Additionally, it is a
good idea to have someone experienced in SAP R/3 upgrades perform the
actual console work.
Table 30 shows the PlugIn variables you will need to set and the values we
used for the redbook project, and it also has a place to record the values used
during your installation of the PlugIn.
Table 30. PlugIn variables
PlugIn variable name Our value Your value
mode scroll

PlugIn variable name Our value Your value
<SID> WHT
mount point /sapcd/PIA9945b
procedure directory /home/whtadm
kernel path /usr/sap/WHT/SYS/exe/run
instance name WHT
instance number 01
CI host name erprisc2
DBServer host name WTSC62F
Database <SID> WHT
mount directories /sapcd/PIA9945b
# of processes option 1
language help E
R3startup profile name START_DVEBMGS01_erp

risc2
profile path/name /usrp/sap/WHT/SYS/profile

WHT/DVEBMGS01_erpris
c2
default profile/name /usr/sap/WHT/SYS/profile

DEFAULT.PFL
DDIC password 19920706
batch server host name erprisc2
synch. time 60 (default)
other software NONE
start import import
mount point /sapcd/PIA9945b
R/3 keyword salamanca
lock dev environment LOCK

5.7.4 PlugIn -A 99 installation
Since you will be making a modification to an existing system, you must
ensure that you have a complete backup of the R/3 system on which you are
about to install the PlugIn.
Check for any active OP Modes, and disable them according to the PlugIn
directions. Transaction RZ04 may come in handy to help you with this task.
The redbook team did not make use of the upgrade assistant, and decided to
use the scroll mode that is available.
After starting the installation, you will be presented with a series of questions
very similar to the format of the questions for the installation of SAP BW.
Follow the prompts and be used to enter your input accurately.
As you progress through the standard upgrade procedure, you will eventually
come to a point where the program will either tell you that all is well and you
can proceed, or that the program found some errors and you need to do some
particular action to resolve the error and then restart the installation of the
PlugIn.
If the errors encountered have not been documented by SAP in the OSS
notes, then you will have to enlist the help of an experienced migration and
BASIS person familiar with this particular SAP R/3 system before proceeding.
Eventually you will be presented with the message upgrade complete.
5.7.5 PlugIn -A 99 post-installation: completing the installation

It is now time to perform any cleanup from errors encountered during the
installation of the PlugIn, and to complete any remaining steps suggested by
the SAP OSS notes.
At this point, we configured ALE for communication between the SAP R/3
system and the SAP BW system.
Since the system we used for the redbook project was not to be used for
further computing, this was the last step we executed. In the case of a
production customer system, however, it would now be time to start the
additional customization necessary before turning over a system to
developers. In particular, there would be immediate customizations in SAP
R/3 table RSADMIN.

5.8 What to do with those leftover CD-ROMs
The installation kit for this product contains a number of CD-ROMs. For
example, with the SAP BW 1.2B kit we received for this redbook project, we
received:
• CD 4.5B Presentation Windows
• CD BW 1.2B SR1 DB-Export
• CD BW 1.2B SR1 SAP Kernel DB2 for OS/390 Installation
• CD BW 1.2B SR1 Language Disk
• CD 1.2B Online Documentation Business Information Warehouse
• CD Accelerated ASAP BW
• CD PI-A 99 Add-On Installation 3.0F - 3.1I
• CD PI-A 99 Add-On Installation 4.0B - 4.5B
• CD PI-A 99 Add-On Upgrade 40.B - 4.6A
Make sure you follow your site’s policies and procedures for tracking these
CD-ROMs or, at a minimum, keep them in their protective covers inside the
installation kit so they can be located in the future.
5.9 Useful URLs

We have provided a few Internet locations where you can find a lot of
information to make the installation go smoother.
The URLs listed in Table 31 require an SAP logon and password.

Table 31. Useful URLs - SAP logon required
Useful URLs Part 1 What it is
service.sap.com SAPNet R/3 Frontend Home Page
service.sap.com/bw SAP BW Home Page
service.sap.com/ocs-download SAP Download Home Page
service.sap.com/instguides SAP Installation and Reference Guides
service.sap.com/notes SAPNet R/3 Frontend Notes Search
sapserv3 / sapserv4 / sapservx SAP Anonymous FTP Servers

The URLs listed in Table 32 are available via the public Internet.
Table 32. Useful URLs - Public
Useful URLs Part 2 What it is
www.sap.com SAP Home Page
www.sap.com/bw SAP BW home Page
service.software.ibm.com/support/s390 IBM S390 service
service.software.ibm.com/support/rs6000 IBM RS6000 service
www.pc.ibm.com/support IBM NT service
www.ibm.com/erp IBM ERP Solutions

Chapter 6. Managing SAP BW database
In principle, you can perform management tasks at three different levels:

1. Inside SAP BW, using the administrator’s workbench
2. Inside SAP R/3, using the DBA tools
3. At the DB2 level, using traditional utilities
In practice, however, we recommend that you first look to the SAP BW

administrator’s workbench to perform the tasks, then to the SAP R/3 tools,
and, as a last resort, to OS/390.
6.1 Administrator’s workbench

Use the administrator’s workbench to perform the following tasks:
1. Index management for the fact table
a. Quite often it is better to do a load into a table that has no associated
indexes, rather than maintaining the indexes during the load. Using the
administrator’s workbench, you have the option of controlling the drop
and recreation of indexes against the fact table of the InfoCube during
the load (or incremental load).
b. You also have the choice to recreate the indexes unconnected to any
load activity.
This is done with normal SQL.
2. Maintaining statistics for the fact table
a. The DB2 optimizer needs information about the tables and indexes
involved in a query. This information has to be gathered if the table
changed significantly. You have the option of controlling the gathering
of information after the load (or incremental load).
b. You also have the option of running the statistics independent of any
load activity.
To initiate this task, SAP BW submits batch jobs with FTP to OS/390.
To establish an FTP connection, you must ensure the following:
- You have TSO access and a TSO user ID.
- Your SAP R/3 user ID is identical to the TSO user ID.
- The SAP R/3 system is aware of your TSO password, (you must call
transaction DB2J and choose Password to enter your password).

To run the jobs on OS/390 successfully, you have to adapt some Profile
Parameters with the help of transaction DB2J.
For more information, see Chapter 4 in BC SAP Database Administration
Guide: DB2 for OS/390, 51003810.
Table 33. TP parameters for JCL submitted with FTP out of SAP R/3
Profile Parameters Description
DB2 run library Library that contains DSNTIAD.
MGMTCLAS, Optional parameters. If not specified, the

STORCLAS, defaults of the corresponding SMS ACS
DATACLAS(SMS) routine are used.
Volume count Overwrites the value defined in

DATACLAS, if needed.
Partitioned data set Existing partitioned data set for uploading

OS/390 jobs.
Console -> Console output data set Sequential data set for receiving the
required part of the System Log. It must
exist and will be overwritten by the next
request. The format must be:
Organization: PS
Record format: VB
Record length: 133
Block size: 27930
6.2 SAP R/3 tools

See Chapter 5 in BC SAP Database Administration Guide: DB2 for OS/390 ,
51003810, for more detailed information about these DBA tools. There is no
difference to a basic SAP R/3 installation using DB2 on OS/390 as a
database server. Use the SAP R/3 management tools to perform the following
tasks:
• Space Management
• Statistics
• Backup
• Recovery
SAP R/3 provides you with a tool to monitor the system and a planning tool
for scheduling DB2 tasks such as gathering statistics and taking backups.

6.3 DB2 utilities
To be as consistent as possible, use DB2 utilities only for tasks which are not
supported by SAP BW or SAP R/3. For example, you might store the jobs in
SAP R/3 and then use transaction DB2J to submit them. For details for these
utilities, see DB2 UDB for OS/390 Utility Guide and Reference Version 6 ,
SC26-9015. For details about using DB2J, see BC SAP Database
Administration Guide: DB2 for OS/390 , 51003810.
Note: If you store jobs in the SAP R/3 system, you need to have access to
that system in order to submit them.
6.4 Backup and recovery strategy

After the BW is in production, there should be a backup and recovery policy in
place. While workstations have to be backed up occasionally after all
workstation software has been installed or upgraded, most of the backup
activities should be done on the server side. Objects that should be backed
up include the DB2 databases that hold BW data and the program source
code, DB2 packages, etc.
The tables in SAP BW will normally not be updated continuously, but instead
at certain specific times. You can easily exploit this fact and design a rather
simple backup and recovery strategy: just do a backup of the affected
tablespaces by using the appropriate SAP R/3 tools, DB2 utilities, or OS/390
tools.
Chapter 6. Managing SAP BW database 81

Chapter 7. Tests performed at ITSO
We adopted the approach of simulating some of the daily usage of SAP BW

by using the Customer Info Cube (SD). We performed the following tests in
order to gain experience and insight into performance and management
issues:
1. Loading data from flat files into the ODS
2. Loading data from the ODS into the InfoCube
3. Building aggregates
4. Running the queries, with STARJOIN enabled and disabled
5. Running the Incremental DataPackage update
In addition, we tried to partition the fact table in the ODS and InfoCube.
The amount of data we dealt with was approximately 25 million rows for the
fact table.
7.1 Loading the ODS

To load the ODS, we started by going to the administrator workbench and
clicking the ODS tabstrip in order to see the ODS catalog.
Before loading the ODS, we changed the storage parameter of the ODS table
to avoid running out of DASD space. The name of the ODS table is
/BIC/B<10-digit-number>. Unfortunately, <10-digit-number> is an internal
generic identifier which the ODS catalog does not show. To identify
<10-digit-number> we checked the ODS catalog to find out the technical
name of the appropriate ODS request set (not the one for InfoSource).
Then we used the data browser (transaction SE16) to query table RSTSODS
and specify the technical name of the ODS as ODSNAME. The name of the
ODS table is retrieved in field ODSNAME_TECH of table RSTSODS.
At this point, we used the database utility (transaction SE14) to change the
storage parameter of the ODS table. See R/3 on DB2 for OS/390 Database
Administration Guide for detailed instructions about this task.
To actually load the ODS, we clicked the InfoSources tabstrip at the

administrator workbench and right-clicked the InfoPackage we wanted to load
to get into the InfoPackage Scheduler. (We decided to load the ODS only and
update the corresponding InfoCube later. Therefore, we clicked the Data

target tabstrip and selected Only ODS.) After clicking the Schedule tabstrip
we started the load.
To improve performance we changed the parameter IDocsSize from 10,000

to 100,000.
You may gain improvements in overall runtime, if you load the data in parallel.
To achieve this you may have to add more batch processes on the application
server or may consider to add another application server for this task.
7.2 Updating the InfoCube

After loading the ODS, we wanted to update the InfoCube, which means
applying all defined update rules to transfer the ODS data into the InfoCube.
During this process, a large number of insert operations is performed on the
InfoCube fact table.
In order to speed up the InfoCube update, we first dropped indexes on the

fact table. This can be done using SAP BW features; see 6.1, “Administrator’s
workbench” on page 79.
At the administrator workbench InfoCube panel, we right-clicked our

InfoCube to get to the InfoCube Performance panel. Clicking Delete indexes
drops the indexes on the fact table. The “Delete InfoCube indexes after each
data load and then recreate” and the “Also delete and then recreate indexes
with each delta upload” options force SAP BW to delete indexes on the fact
table before updating the InfoCube and recreating indexes afterwards.
However, as we wanted to update several requests in parallel, we did not use

these options; that is, we unmarked both fields. Instead, we deleted the
indexes by clicking Delete indexes and selected Repair indexes after the
entire upload was done. We did this because we did not want one update job
to rebuild the indexes while another update job was still active.
After the deletion of the indexes, we went to the ODS panel at the
administrator workbench. The content of the ODS was listed by InfoSources.
To see all requests that belong to one InfoSource, the corresponding node
must be expanded. Only requests that fit user-defined selection criteria are
displayed. Select Setting --> Display selection for ODS tree to maintain
these criteria.
For every request we wanted to update into the InfoCube, we right-clicked the
request and chose Update the request. A SAP batch job was scheduled,
which performs the update.

Note: You have to allocate a sufficient amount of DB2 work space for
rebuilding the indexes. We used a dedicated bufferpool in DB2 for the DB2
work space
Consider also running these updates in parallel, in which case you should
switch off the automatic index rebuild (see Chapter 6, “Managing SAP BW
database” on page 79) and start it manually after the updates. You might also
have to add more application servers and batch processes.
7.3 Aggregate build

When the data is in the InfoCube, you can run queries against it. However,
depending on the amount of data, some queries might run for a long time. If
these queries are used frequently, you should think of defining aggregates.
Aggregates store data in a summarized form in order to avoid doing
calculations during reporting. See SAP BW documentation for detailed
information on defining and using aggregates.
At the administrator workbench, we choose the InfoCubes panel and

right-clicked our InfoCube in order to switch to the “Maintain InfoCube
aggregates” panel. A list of all defined aggregates was displayed. We
selected an aggregate we wanted to fill by highlighting the appropriate row.
Then we chose Fill (function key F6) to fill the aggregate.
You have to provide DB2 work space for building the aggregates. We did not
find any formula to calculate the amount needed. But to give you an idea, we
had roughly twenty million rows in the fact table requiring roughly 5 IBM
3390-002 volumes, including all indexes, and assigned 32 IBM 3390-002
volumes 4K work spaces to build the aggregates. This is definitely an upper
boundary, but we did not get more precise figures.
7.4 .Running queries

Beginning with DB2 Version 6, the query optimizer has a new feature added
called Star Join (APAR PQ28813). It is especially designed for queries that
run against a star schema or extended star schema set of tables.
Star Join can be enabled or disabled with a parameter in DNZPARM. DB2

has to be restarted to activate Star Join.
Since the data model of SAP BW is a star schema (see 1.3.3, “BW data
structures” on page 6), we expected query performance improvements. To
confirm this, we performed some tests.
Chapter 7. Tests performed at ITSO 85

Our observation was that the amount of improvement depends on the number
of selected rows in the fact table. One test case showed no difference in
query performance. However, in another test where we selected roughly
twice as many rows as in the first case, we saw an improvement of one-third
in runtime.
Keep in mind that Star Join might have an adverse effect on the performance
of other queries, so it is up to you to decide whether to use it or not.
7.5 Incremental DataPackage update

Usually the data in an InfoCube is updated periodically, which means that an
additional request is updated into the InfoCube. When doing this, however,
you have to decide whether or not the indexes of the fact table should be
dropped during the update in order to increase insert performance. For
example, there might be reporting being done on the InfoCube while the
update is done and indexes deletion might be not feasible due to a decrease
in reporting performance.
After uploading a new request, we had to take care of the defined

aggregates. The process of updating aggregates content is known as
“roll-up”. At the administrator workbench panel InfoCubes, we right-clicked
the InfoCube to get to the InfoCube Performance panel. We clicked tabstrip
Roll up of the InfoCube. After entering the highest RequestId we wanted to
roll up, we clicked Execute to start the roll-up job.
7.6 Partitioning tables in SAP BW

Even though partitioning is straightforward in DB/2 UDB on OS/390, you have
to choose the partitioning key carefully; that is, you need to know how the
data will be used. You can use transaction SE14 of SAP R/3 to define the
partitions and the respective key range.
We partitioned the fact table in the ODS and in the InfoCube.
7.6.1 Partitioning in the ODS

It is straightforward to define the partitioning key for the table in the ODS. The
keys of choice are in an intelligible format. We partitioned on the fiscal period
field, which is an VARCHAR field.

7.6.2 Partitioning in the InfoCube
In version 1.2B of SAP BW, the characteristics show up in the fact table only
in a coded form of a DIMID; see 1.3.3, “BW data structures” on page 6 for
more information. Hence, all candidates for partitioning keys are in an internal
format only and you have no prior knowledge of the key ranges. You can use
the given dimension of the request ID (P-dimension in SAP BW parlance),
and then partition according to the load sequence; at least, this worked in our
test scenario. However, you should consider that you might have to redefine
the key ranges, which implies some additional table reorganization.
If you have already loaded the fact table, you can use transaction SE14,
which creates a proposal for the partitioning keys. But it takes only the
existing keys into account. If you add more data, it will all be placed into the
partition with the highest key.
In SAP BW Version 2 you will have the option of storing the date in an
intelligible format in the fact table. Hence you have a good choice for a
partitioning key.
Chapter 7. Tests performed at ITSO 87

Chapter 8. Sizing, performance, and tuning considerations
This chapter describes considerations you should keep in mind when

deciding how to size an S/390 system that runs BW. The considerations are
based on recommendations published by SAP in the document Sizing and
Performance, ASAP for SAP BW Accelerator, Document Version 1.1,
available on SAPNet.
What resources you need in order to achieve a particular throughput and

response time depends on several factors, such as the number of users and
the amount of online and background operations. When this redbook was
written, there was no sizing data available on the S/390 platform based on
benchmarks or production environments. Therefore, conclusions in this
chapter are preliminary. For BW sizing guidelines, contact the IBM SAP
International Competence Center (ISICC) by e-mail at this address:
infoserv@de.ibm.com
8.1 Special considerations for BW applications

BW applications are considered to be complex in terms of the following:
• The amount of data being stored for rough data over time
• The amount of data being stored for aggregates, predefined
summarization levels, and so on
• The relationships between the data stored (star scheme)
The amount of data you store is highly dependent upon your data definitions.
For example, you can have many predefined reports or just a few, and you
can allow many concurrent users or just a few. You can build additional
indexes for your tables if some of them are used very often. In addition, use of
the DB2 explain feature, the DB2 Performance Monitor (DB2PM), or other
tools may provide you with performance data or information that leads you to
do partitioning or to allow more processors to work in parallel, resizing buffer
pools or changing thresholds.
Even with all that, you may still experience elapsed times or resource
consumptions that you did not expect because BW systems typically perform
online query processing. In other words you cannot predict what any of your
users will do at any time.
The good news in all this is, modern database systems like DB2 have highly
sophisticated mechanisms to optimize the internal work that they have to do

to satisfy a given query. To demonstrate this, run an aggregate job or a query
against tables that have never had RUNSTATS run against them. We did this
and saw differences in runtime of factors of 50 and more. DB2 Version 6
offers you new functions to do the RUNSTATS automatically, along with
reorgs and table loading. You absolutely should use that option.
A consequence for sizing considerations obviously is that all values for

database size, CPU consumptions, network traffic and, of course, elapsed
times are not comparable with other installations. In addition, during our
studies we received some code changes for the BW application that
decreased runtimes significantly.
For these reasons, we do not supply here any absolute results of runtimes or
resource consumption because such results would have no meaning for you;
you would not be able to use them to predict reliable results for your existing
or any planned environment.
8.1.1 BW administration tasks

It is important to understand that a regular BW administration (not necessarily
SAP BW) consists of two major tasks, and these are ongoing for the entire life
cycle of your BW application:
1. Periodically loading the data (the batch part)
2. Having queries run properly (the query part means your BW production)
These tasks have their own specific tuning and sizing considerations, as they
work in completely different ways and touch tables in different ways. You
might need indexes for queries, no impact on data loading, and so on.
Conversely, some BW tuning people have told us that data loading often may
be more resource-intensive than queries. This is a rather good message,
because it means data loading can be done at times when resource
consumption is no problem.
You can think of SAP BW as a standard application, in which you will not be
able to change the application code. However, there are other areas you will
be able to tune:
• Design of DB2 tables and indices in terms of performance
• DB2 parameters in general (like buffer pools, threads, and so on)
• OS/390 performance-related topics like WLM or SMS
• Maybe LPAR weighings or capping (or -- if running your OS/390 under VM
-- tuning VM)

We changed the DB2 subsystem as little as possible and all definitions are as
recommended by SAP. The settings can be found in the Appendix B, “DB2
Installation parameters” on page 97.
8.1.2 Using RUNSTATS

As previously mentioned, one of the most important things you can do is to
ensure that RUNSTATS is being executed frequently. (For more information
about RUNSTATS, also see SAP note 11308 or the SAP R/3 on DB2 for
OS/390 Planning Guide, SC33-7964.) The SAP Task RSRV is able to analyze
your InfoCubes (the fact table 0SD_C01) and will show you by yellow
highlighting if something needs to be done. As we noted earlier, using
RUNSTATS can improve your runtime by a factor of 50 or more, if RUNSTATS
was not run. Be aware that every data loading could generate table spaces
that did not exist before!
8.2 General sizing and tuning approach

In complex environments like BW applications, a good approach is to try to
come as close as possible to a right-sized environment iteratively.
Normally, the introduction of BW applications is a project that can be divided

into phases, with milestones at the end of each phase. This is also a safe way
to prove sizing estimates, and you can do this at the same time. This
approach is described in the next section.
8.2.1 Pre-installation and planning phase

You can estimate DASD storage needs, CPU consumption, and memory with
the help of tools or by comparing your installation with other, similar
installations. The use of tools requires input like the following:
• The SAP applications you are running
• The data that you plan to load from the SAP R/3 applications into BW
• The maximum number of users defined in the system
• The maximum number of users working in parallel
• The average number of users working in parallel
• What the users would probably do (to get a feeling how “heavy” the load is
that they are producing)
Chapter 8. Sizing, performance, and tuning considerations 91

At this point you may have to estimate these values because you do not know
all possible users in your company, or whether they will like the application
and how they will use it.
The tools will give you values that will not be exactly right for you, but they
should not be too far off, as long as you do not deviate from the standards
and the defaults of SAP BW.
There are tools available to do that. They are not all available for customer
use but IBM or SAP can help you by running them in the pre-installation
phase and providing you with the results.
At the end of this phase you can order the product and the hardware you
need to run it, at least for the next phase.
8.2.2 Pilot or evaluation phase

The format of the pilot or evaluation phase depends on how the project is
designed. This phase starts with the base installation of the product,
preferably exactly as described in the installation “cookbook” and with no
more installation-specific parameters or exits than necessary. This ensures
that you at least approach the estimates of phase one.
After that, a BW application is usually loaded with some data so you can test
the functionality of the product and become familiar with its use. This is how
we proceeded. We used flat files with consistent data that generated about
1.2 million rows in the details table. (In terms of a BW application, that is a
small amount of data that can easily and quickly be handled in tests.)
After that, you might consider loading all data to be used later for production,
or at least subset of it. You could now begin to tailor the system for your
needs as you make design, naming, measurement, and maybe tuning
decisions. Keep in mind that you are installing a standard application, so
there is not much more to do in terms of naming and designing in SAP, except
to prepare the DB2 and OS/390 for it.
At this point you will have already defined the defaults and installation
standards, and will be experiencing different behavior in resource
consumption or elapsed times. To get the most value out of this phase, you
should constantly monitor what you are doing.
At the end of this phase, you will probably plan to go into production.

8.2.3 Production start
With the knowledge gained during the evaluation phase, you are now able to
estimate what you will need for production (“going live”, in terms of SAP). You
can compare that with the very first estimates you got to verify what you
derived from defaults or tool-input values.
It is normal to have these values differ, because in a BW project, the

requirements on the BW application typically are subject to continuous
changes, as end users see more and more possibilities of how to use it. In
fact, an education or learning step is usually included in this phase, which will
additionally show the users what they could have.
8.2.4 Running BW
Even in this phase (which is probably neverending) you may see changes (not
necessarily always growth) in the amount of data being stored, or changes in
the CPU consumption and elapsed time, but you will have gained experience
during the earlier phases on how the growth of data impacts these factors. If
your measurements were sufficient, you will even be able to predict these
impacts.
The reason for the ongoing administration is that a BW application is subject

to continuously changing queries since the market and the data from which
strategic decisions are to be derived are continuously changing as well. As a
consequence, the tuning of a BW application is really an ongoing process.
You may decide to have one or more people exclusively responsible for BW
administration. The value of the system is only as good as the results
obtained, which obviously depends primarily on the quality of the queries.
Good administration will guarantee that you get your results quickly and that
they are most nearly actual, and that you can easily retrieve most results for
the end user (who could be one of your business managers looking for data to
use as a basis for an important decision).
Chapter 8. Sizing, performance, and tuning considerations 93

Appendix A. What’s new in SAP BW 2.0
In SAP BW 2.0, several changes will be made. Some changes are:

• New user interface of the administration workbench
• Introduction of new InfoCube types
• SAP BW monitoring
• Handling of the ODS data
• Performance improvements in several areas, like aggregation and
reporting
However, most of what is written in this redbook is also valid for SAP BW 2.0.
In this appendix, we describe two new features that are relevant for SAP BW
on OS/390, which have an impact on the procedures we did during our test
session.
For detailed information about features of SAP BW 2.0B, refer to:

1. Exploitation of DSNUTILS stored procedures
SAP BW performs mass processing that often leads to a significant
number of changes in several tables. To ensure optimal access path
generation, the SAP BW system updates the DB2 statistic after these
changes are performed. SAP BW 1.2B uses the FTP job submission
service feature to run the RUNSTATS utility.
Starting with SAP BW Release 2.0B, the appropriate DSNUTILS stored
procedure is issued instead. This guarantees a very fast and stable way
for the statistics update.
2. Partitioning of fact tables
SAP BW 2.0B supports partitioning of fact tables based on time
characteristics. This gives the BW administrator the ability to handle even
huge InfoCubes by an easy-to-use interface. All maintenance tasks, like
creation and deletion of partitions, are done by the BW system.
With SAP BW 2.0B, partitioning is restricted to fiscal period (info object
0FISCPER) and calendar month (info object 0CALMONTH).

Appendix B. DB2 Installation parameters
In this appendix, we list DB2 parameters we used in our test system. Some
are shown in DSNZPARM and others by using SAP transactions.
B.1 DSNZPARM
//DBH1E JOB (999,POK),'DBH1 INSTALL',CLASS=A,MSGCLASS=T,
// NOTIFY=HAIMO,TIME=1440,REGION=0M
/*JOBPARM L=9999,SYSAFF=SC62
//*********************************************************************/
//* JOB NAME = DSNTIJUZ */
//* */
//* DESCRIPTIVE NAME = INSTALLATION JOB STREAM */
//* */
//* LICENSED MATERIALS - PROPERTY OF IBM */
//* 5645-DB2 */
//* (C) COPYRIGHT 1982, 1998 IBM CORP. ALL RIGHTS RESERVED. */
//* */
//* STATUS = VERSION 6 */
//* */
//* FUNCTION = DSNZPARM AND DSNHDECP UPDATES */
//* */
//* PSEUDOCODE = */
//* DSNTIZA STEP ASSEMBLE DSN6.... MACROS, CREATE DSNZPARM */
//* DSNTIZL STEP LINK EDIT DSNZPARM */
//* DSNTLOG STEP UPDATE PASSWORDS */
//* DSNTIZP STEP ASSEMBLE DSNHDECP DATA-ONLY LOAD MODULE */
//* DSNTIZQ STEP LINK EDIT DSNHDECP LOAD MODULE */
//* DSNTIMQ STEP SMP/E PROCESSING FOR DSNHDECP */
//* */
//* NOTES = STEP DSNTIMQ MUST BE CUSTOMIZED FOR SMP. SEE THE NOTES */
//* NOTES PRECEDING STEP DSNTIMQ BEFORE RUNNING THIS JOB. */
//* */
//*********************************************************************/
//*
//DSNTIZA EXEC PGM=ASMA90,PARM='OBJECT,NODECK'
//SYSLIB DD DISP=SHR,
// DSN=DSN610.SDSNMACS
// DD DISP=SHR,
// DSN=SYS1.MACLIB
//SYSLIN DD DSN=&&LOADSET(DSNTILMM),DISP=(NEW,PASS),
// UNIT=SYSALLDA,
// SPACE=(800,(50,50,2)),DCB=(BLKSIZE=800)
//SYSPRINT DD SYSOUT=*

//SYSUT1 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND)
//SYSIN DD *
DSN6ENV MVS=XA
DSN6SPRM RESTART,
ALL,
ABEXP=YES,
ABIND=YES,
AUTH=YES,
AUTHCACH=1024,
BINDNV=BINDADD,
BMPTOUT=4,
CACHEDYN=YES,
CACHEPAC=32768,
CACHERAC=32768,
CATALOG=DB2V61H1,
CDSSRDEF=1,
CHGDC=NO,
CONTSTOR=YES, <-- WAS NO
DECDIV3=NO,
DEFLTID=IBMUSER,
DESCSTAT=NO,
DLITOUT=6,
DSMAX=6000, <-- WAS 3000
EDMPOOL=80000, <-- WAS 14812
EDMDSPAC=0,
EDPROP=NO,
HOPAUTH=BOTH,
IRLMAUT=YES,
IRLMPRC=IRH1PROC,
IRLMSID=IRH1,
IRLMRWT=600, <-- WAS 60
IRLMSWT=300,
LEMAX=20,
MAXRBLK=100000, <-- WAS 4000
MAXKEEPD=16000, <-- WAS 5000
NPGTHRSH=10, <-- WAS 10000
NUMLKTS=1000,
NUMLKUS=0, <-- WAS 10000
OPTHINTS=NO,
PARAMDEG=0,
RECALL=YES,
RECALLD=120,
RELCURHL=YES,
RETLWAIT=0,

RETVLCFK=NO,
RGFCOLID=DSNRGCOL,
RGFDBNAM=DSNRGFDB,
RGFDEDPL=NO,
RGFDEFLT=ACCEPT,
RGFESCP=,
RGFFULLQ=YES,
RGFINSTL=NO,
RGFNMORT=DSN_REGISTER_OBJT,
RGFNMPRT=DSN_REGISTER_APPL,
RRULOCK=NO,
SEQCACH=BYPASS,
SEQPRES=NO,
SITETYP=LOCALSITE,
SRTPOOL=1000,
STARJOIN=DISABLE, <-- or ENABLE
SYSADM=HAIMO,
SYSADM2=HAHN,
SYSOPR1=SYSOPR,
SYSOPR2=SYSOPR,
TRKRSITE=NO,
UTIMOUT=3, <-- WAS 6 DEFAULT
XLKUPDLT=YES <-- WAS NO APAR PQ18915
DSN6ARVP ALCUNIT=BLK,
ARCWRTC=(1,3,4),
ARCWTOR=YES,
ARCPFX1=DB2V61H1.ARCHLOG1,
ARCPFX2=DB2V61H1.ARCHLOG2,
ARCRETN=9999,
BLKSIZE=28672,
CATALOG=NO,
COMPACT=NO,
PRIQTY=1234,
PROTECT=NO,
QUIESCE=585, <-- WAS 5
SECQTY=154,
TSTAMP=NO,
UNIT=3390,
UNIT2=
DSN6LOGP DEALLCT=(0),
MAXARCH=1000,
MAXRTU=2,
OUTBUFF=4000,
TWOACTV=YES,
TWOARCH=YES,
WRTHRSH=20,
ARC2FRST=NO
Appendix B. DB2 Installation parameters 99

DSN6SYSP AUDITST=NO,
BACKODUR=5,
CONDBAT=64,
CTHREAD=120, <-- WAS 70
DBPROTCL=DRDA,
DLDFREQ=5,
DSSTIME=5,
EXTRAREQ=100,
EXTRASRV=100,
IDBACK=20,
IDFORE=40,
IDXBPOOL=BP0,
LBACKOUT=AUTO,
LOBVALA=2048,
LOBVALS=2048,
LOGAPSTG=10,
LOGLOAD=50000,
MAXDBAT=64,
MON=NO,
MONSIZE=1000000, <-- WAS 8192
PCLOSEN=5,
PCLOSET=10,
RLF=NO,
RLFTBL=01,
RLFERR=NOLIMIT,
RLFAUTH=SYSIBM,
ROUTCDE=(1),
EXTSEC=NO,
SMFACCT=(1,2,3), <-- WAS 1
SMFSTAT=(1,3), <-- WAS YES
STATIME=30,
STORMXAB=0,
STORPROC=DBH1SPAS,
STORTIME=180,
TBSBPOOL=BP0,
TRACSTR=NO,
TRACTBL=16,
URCHKTH=1, <-- WAS 0
WLMENV=
DSN6FAC DDF=AUTO,
CMTSTAT=ACTIVE,
IDTHTOIN=0,
RESYNC=2,
RLFERRD=NOLIMIT,
TCPALVER=NO,
MAXTYPE1=0,
TCPKPALV=ENABLE,

POOLINAC=120
DSN6GRP DSHARE=NO,
GRPNAME=DSNCAT,
MEMBNAME=DSN1,
COORDNTR=NO,
ASSIST=NO
END
//*********************************************************************
//* LINK EDIT THE NEW DSNZPARM MEMBER. PUT LOAD MODULE IN SDSNEXIT.
//*********************************************************************
//DSNTIZL EXEC PGM=IEWL,PARM='LIST,XREF,LET,RENT',
// COND=(4,LT)
//ADSNLOAD DD DISP=SHR,
// DSN=DSN610.SDSNLOAD
// DD DISP=SHR,
// DSN=DSN610.ADSNLOAD
//SYSPUNCH DD DSN=&&LOADSET(DSNTILMM),DISP=(OLD,DELETE)
//SYSLMOD DD DISP=SHR,
// DSN=DB2V61H1.SDSNEXIT
//SYSUT1 DD UNIT=SYSALLDA,SPACE=(1024,(50,50))
//SYSLIN DD *
INCLUDE SYSPUNCH(DSNTILMM)
INCLUDE ADSNLOAD(DSNZPARM)
ORDER DSNAA
INCLUDE ADSNLOAD(DSNAA)
INCLUDE ADSNLOAD(DSNFSYSP)
INCLUDE ADSNLOAD(DSNJARVP)
INCLUDE ADSNLOAD(DSNJLOGP)
INCLUDE ADSNLOAD(DSNTSPRM)
INCLUDE ADSNLOAD(DSNVDIR1)
INCLUDE ADSNLOAD(DSNZMSTR)
INCLUDE ADSNLOAD(DSN3DIR1)
INCLUDE ADSNLOAD(DSN7GRP)
ENTRY DSNZMSTR
NAME DSNZPARM(R)
//*
//* CHANGE LOG INVENTORY:
//* UPDATE BSDS
//*
//DSNTLOG EXEC PGM=DSNJU003,COND=(4,LT)
//STEPLIB DD DISP=SHR,DSN=DSN610.SDSNLOAD
//SYSUT1 DD DISP=OLD,DSN=DB2V61H1.BSDS01
//SYSUT2 DD DISP=OLD,DSN=DB2V61H1.BSDS02

//SYSIN DD *
DDF LOCATION=DBH1,LUNAME=SCPDBH1,
NOPASSWD,RESPORT=33367,PORT=33366
//*
//*********************************************************************
//* ASSEMBLE AND LINK EDIT DATA-ONLY LOAD MODULE DSNHDECP.
//* THE FOLLOWING STEPS ARE NEEDED ONLY IF THE
//* VALUES ARE CHANGED FROM THOSE WHICH ARE SHIPPED.
//*********************************************************************
//DSNTIZP EXEC PGM=ASMA90,PARM='OBJECT,NODECK',COND=(4,LT)
//SYSLIB DD DISP=SHR,
// DSN=DSN610.SDSNMACS
//SYSLIN DD DSN=&&LOADSET(DSNHDECA),DISP=(NEW,PASS),UNIT=SYSALLDA,
// SPACE=(80,(50,50,2)),DCB=(BLKSIZE=80)
//SYSIN DD *
DSNHDECM CHARSET=ALPHANUM,
ASCCSID=819, <-- WAS 0
AMCCSID=65534,
AGCCSID=65534,
SCCSID=37,
MCCSID=65534,
GCCSID=65534,
ENSCHEME=ASCII, <--WAS EBCDIC
DATE=ISO,
DATELEN=0,
DECARTH=DEC15,
DECIMAL=PERIOD,
DEFLANG=IBMCOB,
DELIM=DEFAULT,
MIXED=NO,
SQLDELI=DEFAULT,
DSQLDELI=APOST,
SSID=DBH1,
STDSQL=NO,
TIME=ISO,
TIMELEN=0,
DYNRULS=YES,
LC_CTYPE=,
COMPAT=OFF
END
//*
//*********************************************************************

//* LINK EDIT DSNHDECP. *
//* DSNHDECP IS A DATA-ONLY LOAD MODULE CONTAINING DEFAULT VALUES *
//* REQUIRED BY DB2 AND APPLICATION PROGRAMS. *
//* THIS STEP IS CREATED ONLY WHEN THE DEFAULTS SUPPLIED IN *
//* DSNHDECP ARE NOT SUITABLE. *
//*********************************************************************
//DSNTIZQ EXEC PGM=IEWL,PARM='LIST,XREF,LET,RENT',
// COND=(4,LT)
//ADSNLOAD DD DISP=SHR,
// DSN=DSN610.SDSNEXIT
// DD DISP=SHR,
// DSN=DSN610.ADSNLOAD
//SYSPUNCH DD DSN=&&LOADSET(DSNHDECA),DISP=(OLD,DELETE)
//SYSLMOD DD DISP=SHR,
// DSN=DB2V61H1.SDSNEXIT
//SYSUT1 DD UNIT=SYSALLDA,SPACE=(1024,(50,50))
//SYSLIN DD *
INCLUDE SYSPUNCH(DSNHDECA)
ORDER DSNAA
INCLUDE ADSNLOAD(DSNAA)
INCLUDE ADSNLOAD(DSNARIB)
INCLUDE ADSNLOAD(DSNHDECP)
ENTRY DSNHDECP
MODE AMODE(24),RMODE(24)
NAME DSNHDECP(R)
//*
B.2 IRLMPROC
//IRH1PROC PROC RGN=5000K,
// LIB='DSN610.SDXRRESL',
// IRLMNM=IRH1,
// IRLMID=1,
// SCOPE=LOCAL,
// DEADLOK='5,1',
// MAXCSA=6,
// PC=YES,
// MAXUSRS=7,
// IRLMGRP=,
// LOCKTAB=,
// TRACE=NO
// EXEC PGM=DXRRLM00,DPRTY=(15,15),
// PARM=(&IRLMNM,&IRLMID,&SCOPE,&DEADLOK,&MAXCSA,&PC,
// &MAXUSRS,&IRLMGRP,&LOCKTAB,&TRACE),

// REGION=&RGN
//STEPLIB DD DSN=&LIB,DISP=SHR
//SYSABEND DD SYSOUT=*
B.3 DB2 parameters using a SAP transaction

You can get the following figures by using SAP transaction ST04 and
selecting “Installation Parameters” in the displayed panel.
Figure 15. DB2 installation parameters

Figure 16. DB2 buffer pool allocation
Figure 17. DB2 storage sizes and connections

Figure 18. DB2 trace
Figure 19. DB2 locks and IRLM definition

Figure 20. DB2 archive log parameters
Figure 21. DB2 active log parameters

Figure 22. DB2 application parameters
Figure 23. DB2 operation and DDF parameters

Appendix C. How to set up RRS
RRS uses five log streams (defined in a couple data set) that are shared by
the systems in a sysplex. (In a monoplex environment, you can use a
DASD-only log stream.) Every OS/390 image with RRS running needs access
to a Coupling Facility and the DASD on which the system logger log streams
are defined.
The five RRS logs are:

• RRS archive log (optional)
• RRS resource manager data log
• RRS main unit of recovery (UR) state log
• RRS delayed UR state log
• RRS restart log
The OS/390 system logger component manages log streams based on the
policy information in the LOGR couple data set. The use of a primary and an
alternate couple data set is recommended.
You need to follow these steps to set up RRS:

1. Add subsystem entries to the SYS1.PARMLIB(IEFSSNxx):
SUBSYS SUBNAME(LOGR)
INITRTN(IXGSSINT)
SUBSYS SUBNAME(RRS)
- Issue the SETSSI command to dynamically define the new subsystem:
SETSSI ADD,SUBNAME=RRS
2. Define the couple data set and activate the OS/390 system logger.
Whether you are running in sysplex or monoplex mode, you have to define
a couple data set and activate your system logger.
a. Check whether the system logger is already active by issuing the
following command from the SDSF panel:
D LOGGER,CONN
b. If the system logger is not active, define the LOGR couple data sets by
using the JCL shown in Figure 24 on page 110. The IXCL1DSU utility
formats LOGR, a couple data set.

//SAPADM1 JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=BI390B
//***********************************************************
//* SAMPLE JOB TO DEFINE LOGR COUPLE DATASET
//***********************************************************
//STEP1 EXEC PGM=IXCL1DSU
//SYSIN DD *
DEFINEDS SYSPLEX(PLEX57)
MAXSYSTEM(2)
DSN(SYS1.PLEX57.LOGR01) VOLSER(PDGCD1)
CATALOG
DATA TYPE(LOGR)
ITEM NAME(LSR) NUMBER(100)
ITEM NAME(LSTRR) NUMBER(60)
ITEM NAME(DSEXTENT) NUMBER(10)
/*
Figure 24. Sample JCL to define an RRS LOGR couple data set
c. Modify the SYS1.PARMLIB(COUPLExx) member to add the couple

data set definitions (see Figure 25).
/**********************************************/
/* SAMPLE SYS1.PARMLIB COUPLExx MEMBER */
/**********************************************/
COUPLE SYSPLEX(&SYSPLEX.)
PCOUPLE(SYS1.XCF.CDS02)
ACOUPLE(SYS1.XCF.CDS03)
CLEANUP(30)
RETRY(10)
DATA TYPE(LOGR)
PCOUPLE(SYS1.XCF.LOGR00)
ACOUPLE(SYS1.XCF.LOGR01)
Figure 25. Sample couple data set definition
d. To activate the system logger, you can IPL the system. If you want to
bring the LOGR couple data sets online without re-IPLing the system,
issue the following SETXCF commands:
SETXCF
COUPLE,TYPE=LOGR,PCOUPLE=(primary_couple_data_set)

SETXCF
COUPLE,TYPE=LOGR,ACOUPLE=(alternate_couple_data_set)
3. Set up the RRS log streams.
a. Ensure that the system logger is already active by issuing the
command:
D LOGGER,CONN
b. Define the log streams for RRS using the sample JCL shown in Figure
26 on page 112. The IXCMIAPU utility adds, updates, lists, or deletes
policy data on the LOGR couple data set.
Appendix C. How to set up RRS 111

//BI390B JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=BI390B
//***********************************************************
//* SAMPLE JCL TO DEFINE LOGSTREAMS FOR RRS
//***********************************************************
//LOGRPOL EXEC PGM=IXCMIAPU
//STEPLIB DD DSN=SYS1.MIGLIB,DISP=SHR
//SYSABEND DD SYSOUT=*
//SYSIN DD *
DATA TYPE(LOGR) REPORT(YES)
DELETE LOGSTREAM NAME(IXGLOGR.PLEX57.ARCHIVE)
DELETE LOGSTREAM NAME(IXGLOGR.PLEX57.RM.DATA)
DELETE LOGSTREAM NAME(IXGLOGR.PLEX57.MAIN.UR)
DELETE LOGSTREAM NAME(IXGLOGR.PLEX57.DELAYED.UR)
DELETE LOGSTREAM NAME(IXGLOGR.PLEX57.RESTART)
DEFINE LOGSTREAM
NAME(ATR.PLEX57.ARCHIVE) DASDONLY(YES) HLQ(LOGR)
MODEL(NO) LS_SIZE(1024) STG_SIZE(1024)
LOWOFFLOAD(0) HIGHOFFLOAD(80)
RETPD(15) AUTODELETE(YES)
DEFINE LOGSTREAM
NAME(ATR.PLEX57.RM.DATA) DASDONLY(YES) HLQ(LOGR)
DEFINE LOGSTREAM
NAME(ATR.PLEX57.MAIN.UR) DASDONLY(YES) HLQ(LOGR)
DEFINE LOGSTREAM
NAME(ATR.PLEX57.DELAYED.UR) DASDONLY(YES) HLQ(LOGR)
DEFINE LOGSTREAM
NAME(ATR.PLEX57.RESTART) DASDONLY(YES) HLQ(LOGR)
Figure 26. Sample JCL to define RRS log streams

Note
In the previous sample, the RRS log streams are defined on DASD only. If
you plan to use RRS across a sysplex environment, you must define the
RRS log streams in the Coupling Facility. Review the parameters
accordingly.
4. Establish the priority of the RRS address space.

The priority of RRS should be higher than other resource managers, such
as DB2, CICS, and IMS, and lower than JES and VTAM.
5. Define the RRS subsystem.
a. Create the RRS started task procedure, shown in Figure 27, in the
SYS1.PROCLIB(RRS).
//RRS PROC GNAME='',CTMEM=''

//********************************************************************
//* SAMPLE RRS STARTED TASK PROCEDURE
//********************************************************************
//*
//* o GNAME=rrsgroupname
//* o CTMEM=ctracemembername
//*
//* Examples of valid parameter strings:
//*
//* PARM='GNAME=PLEX1 CTMEM=CTIRRS00'
//* PARM='CTMEM=CTIRRS00 GNAME=PLEX1'
//* PARM='GNAME=PLEX1 '
//* PARM=' CTMEM=CTIRRS00 '
//*
//*********************************************************************
//RRS EXEC PGM=ATRIMIKE,REGION=0M,TIME=NOLIMIT,
// PARM='GNAME=&GNAME CTMEM=&CTMEM'
//
Figure 27. Sample RRS started task procedure
6. Start RRS by entering the following command from SYSLOG:

START RRS,SUB=MSTR
If you need to stop RRS, you can use the SETATRRS CANCEL or FORCE
RRS,ARM commands.
Appendix C. How to set up RRS 113

Automatically activate RRS
To activate RRS automatically at each IPL, add the START RRS command in
the SYS1.PARMLIB(COMMNDxx) member.
COM=‘START RRS’

Appendix D. Enterprise Storage Server (ESS)
This appendix gives the reader who is unfamiliar with the Enterprise Storage
Server (ESS) an overview of the device architecture and its unique functions.
The ESS is a high-performance RAID-5 storage subsystem, and is a member

of the Seascape family. It consists of a storage server and attached disk
storage devices. The storage server provides integrated caching and RAID
support for the attached disk devices. The ESS can be configured in a variety
of ways to provide scalability in capacity and performance.
Redundancy within the ESS provides continuous availability. It is packaged in

one or more enclosures, each with dual line cords and redundant power. The
redundant power system allows the ESS to continue normal operation when
one of the line cords is deactivated.
The ESS provides the image of a set of logical disk devices to attached
servers. The logical devices are configured to emulate disk device types that
are compatible with the attached servers. The logical devices access a logical
volume that is implemented using multiple disk drives.
The following host I/O interface attachments are supported:

• SCSI-3 Parallel Interface
• ESCON
• FC-AL
• FICON
On SCSI-3 interfaces, the ESS emulates a variety of fixed-block devices with

either 512 or 520 byte blocks. SCSI-3 is, in general, a superset of SCSI-2. A
SCSI-3 disk device can be attached to a SCSI-2 initiator, provided the cabling
can be interfaced. Many SCSI-2 initiators attach directly to the cabling
specified for the SCSI-3 parallel interface, but are referred to as SCSI-2
initiators because they limit their use of the command set to the SCSI-2
subset. Host systems with SCSI-2 or SCSI-3 interfaces can attach to the
ESS.
The ESS provides multiple SCSI I/O interfaces (busses), each with multiple
SCSI targets, and each with multiple disk logical units. The storage provided
by the ESS for SCSI interfaces can be configured so that it is shared among
multiple SCSI interfaces if desired.

On ESCON interfaces, the ESS emulates one or more IBM 3990 control units
attaching variable size IBM 3390 devices in either 3390 or 3380 track format.
The ESS provides multiple ESCON interfaces that provide a set of control unit
images, each with multiple disk devices. The storage provided by the ESS for
ESCON interfaces is configured so that it is accessible from any ESCON
interface.
The ESS is composed of the following components:
The storage server is composed of two clusters that provide the facilities with
advanced functions to control and manage data transfer. Should one cluster
fail, the remaining cluster can take over the functions of the failing cluster. A
cluster is composed of the following subcomponents:
• Host Adapters - Each cluster has one or more host adapters (HAs). Each
host adapter provides one or more host I/O interfaces. A host adapter can
communicate with either cluster complex.
• Device Adapters - Each cluster has one or more device adapters (DAs).
Each device adapter provides one or more storage device interfaces. Disk
drives are attached to a pair of device adapters, one in each cluster, so
that the drives are accessible from either cluster. At any given time, a disk
drive is managed by only one device adapter.
• Cluster Complex - The cluster complex provides the management
functions for the ESS. It consists of cluster processors, cluster memory,
cache, nonvolatile storage (NVS), and related logic.
• Cluster Processor - The cluster complex contains four cluster processors
(CP) configured as symmetrical multiprocessors (SMP). The cluster
processors execute the licensed internal code that controls operation of
the cluster.
• Cluster memory/cache - This is used to store instructions and data for the
cluster processors. The cache memory is used to store cached data from
the disk drives. The cache memory is accessible by the local cluster
complex, by device adapters in the local cluster, and by host adapters in
either cluster.
• Nonvolatile storage (NVS) - This is used to store a nonvolatile copy of
active written data. The NVS is accessible to either cluster-processor
complex and to host adapters in either cluster. Data may also be
transferred between the NVS and cache.
• Disk Drives - These provide the primary nonvolatile storage medium for
any host data stored within the ESS Storage devices. They are grouped
into ranks and are managed by the clusters.

As a member of the IBM Seascape family, the ESS provides the outboard
intelligence required by SAN solutions, offloading key functions from host
servers, which frees up valuable processing power for applications. As a
comprehensive SAN-based storage solution, the ESS provides considerable
management flexibility to meet the fast-paced requirements of the next
century.
Among the many factors that make the IBM ESS an ideal solution are:
• Support of all major server platforms including S/390, AS/400, Windows
NT, and many varieties of UNIX
• Fiber channel attachment capability
• Extensive storage management capabilities through a Web interface used
to manage the ESS logical configuration
• Excellent scalability:
- From 400 GB to over 11 TB
- Simple selection from 16 standard configurations to meet capacity and
performance needs
• Performance optimized to your heterogeneous environment needs:
- High bandwidth and advanced transaction processing capabilities
provide solutions for both online and batch applications
- Innovations such as Parallel Access Volumes to reduce resource
contention and dramatically improve performance through the
elimination or reduction of IOSQ for single-host environments
- Multiple allegiance, which allows you to dramatically reduce or
eliminate IOSQ time for a multiple-host environment
- Performance-enhanced CCW commands
- I/O priority queuing, which allows users to define the priority of
application workloads
- Custom volumes, which allows you to create your own custom-sized
logical volumes
• Availability required to support e-business applications
- Business continuity through remote copy services - PPRC and XRC
- Rapid data duplication through FlashCopy, providing extensive
capabilities to exploit, manage, and protect your information in a 24 x 7
environment
Appendix D. Enterprise Storage Server (ESS) 117

- Peer-to-Peer Remote Copy (PPRC), which allows you to create
synchronous volume copies via ESCON channels
- Extended Remote Copy (XRC), which allows you to create
asynchronous volume copies over long distances
- Concurrent Copy (CC), which allows you to create volume or data set
copies, locally and non-disruptively
• Storage server availability through redundancy and non-disruptive service
with design for no single point of failure or repair
More information is available through not only the ESS product manuals, but
also a suite of IBM redbooks, including:
• IBM Enterprise Storage Server, SG24-5465
• Implementing the IBM ESS in Your Environment, SG24-5420
• Implementing ESS Copy Services in a S/390 Environment , SG24-5680
• Implementing ESS Copy Services in a UNIX/NT Environment , SG24-5757
These books are available through the ITSO Web page at:
www.redbooks.ibm.com.

Appendix E. Special notices
This publication is intended to help S/390 technical specialists, DB2 database

administrators, and SAP Basis consultants to implement SAP BW 1.2B on
S/390. The information in this publication is not intended as the specification
of any programming interfaces that are provided by SAP or IBM. Contact SAP
for more information about what publications are considered to be product
documentation.
References in this publication to IBM products, programs or services do not

imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not
intended to state or imply that only IBM's product, program, or service may be
used. Any functionally equivalent program that does not infringe any of IBM's
intellectual property rights may be used instead of the IBM product, program
or service.
Information in this book was developed in conjunction with use of the

equipment specified, and is limited in application to those specific hardware
and software products and levels.
IBM may have patents or pending patent applications covering subject matter
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 the IBM
Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY
10504-1785.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and

conditions, including in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
("vendor") products in this manual has been supplied by the vendor and IBM
assumes no responsibility for its accuracy or completeness. The use of this
information or the implementation of any of these techniques is a customer
responsibility and depends on the customer's ability to evaluate and integrate
them into the customer's operational environment. While each item may have
been reviewed by IBM for accuracy in a specific situation, there is no

guarantee that the same or similar results will be obtained elsewhere.
Customers attempting to adapt these techniques to their own environments
do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
Any performance data contained in this document was determined in a

controlled environment, and therefore, the results that may be obtained in
other operating environments may vary significantly. Users of this document
should verify the applicable data for their specific environment.
This document contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples
contain 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.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes
available to each customer according to the normal IBM PTF distribution
process.
The following terms are trademarks of the International Business Machines

Corporation in the United States and/or other countries:
AIX DB2
DFSMS/MVS DFSMSdfp
ESCON FICON
Netfinity OS/390
OS/390 UNIX Parallel Sysplex
S/390 IBM â
The following terms are trademarks of other companies:
Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.

Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet
Tivoli, and Tivoli Enterprise are trademarks or registered trademarks of Tivoli
Systems Inc., an IBM company, in the United States, other countries, or both.
In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli
A/S.
C-bus is a trademark of Corollary, Inc. in the United States and/or other

countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other
countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United

States and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel

Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries

licensed exclusively through The Open Group.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks
owned by SET Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service

marks of others.
Appendix E. Special notices 121

Appendix F. Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
F.1 IBM Redbooks

For information on ordering these publications see “How to get IBM
Redbooks” on page 125.
• Database Administration Experiences: SAP R/3 on DB2 for OS/390 ,
SG24-2078
• SAP R/3 on DB2 for OS/390: Implementing with AIX or Windows NT
Application Servers, SG24-4945
• High Availability Considerations: SAP R/3 on DB2 for OS/390, SG24-2003
• IBM Enterprise Storage Server, SG24-5465
• Implementing the IBM ESS in Your Environment, SG24-5420
F.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs
offered, updates and formats.
CD-ROM Title Collection Kit
Number
System/390 Redbooks Collection SK2T-2177
Networking and Systems Management Redbooks Collection SK2T-6022
Transaction Processing and Data Management Redbooks Collection SK2T-8038
Lotus Redbooks Collection SK2T-8039
Tivoli Redbooks Collection SK2T-8044
AS/400 Redbooks Collection SK2T-2849
Netfinity Hardware and Software Redbooks Collection SK2T-8046
RS/6000 Redbooks Collection (BkMgr) SK2T-8040
RS/6000 Redbooks Collection (PDF Format) SK2T-8043
Application Development Redbooks Collection SK2T-8037
IBM Enterprise Storage and Systems Management Solutions SK3T-3694
F.3 Other resources

These publications are also relevant as further information sources:

SC33-7964
• MVS/ESA Hardware Configuration Definition: User’s Guide, SC33-6468
• OS/390 UNIX System Service Planning, SC28-1890
• Installation of the SAP Business Information Warehouse on UNIX DB2 for
OS/390, Release 1.2B SR-1, 51007613
Number: 51006377
• R/3 Installation on UNIX DB2 for OS/390, 51006375
• DB2 UDB for OS/390 Version 6 Installation Guide, SC26-9008
• DB2 UDB for OS/390 Utility Guide and Reference Version 6 , SC26-9015
F.4 Referenced Web sites

These Web sites are also relevant as further information sources:
• http://www.sap.com/bw SAP BW home page
• http://www.asug.com Americas’ SAP Users’ Group
• http://www.s390.ibm.com/os390/bkserv/latest.html Latest IBM S/390
documentation

How to get IBM Redbooks
This section explains how both customers and IBM employees can find out about IBM Redbooks,
redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
• Redbooks Web Site http://www.redbooks.ibm.com/
Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site.
Also read redpieces and download additional materials (code samples or diskette/CD-ROM images)
from this Redbooks site.
Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few
chapters will be published this way. The intent is to get the information out much quicker than the
formal publishing process allows.
• E-mail Orders
Send orders by e-mail including information from the IBM Redbooks fax order form to:
e-mail address
In United States usib6fpl@ibmmail.com
Outside North America Contact information is in the “How to Order” section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
• Telephone Orders
United States (toll free) 1-800-879-2755
Canada (toll free) 1-800-IBM-4YOU
Outside North America Country coordinator phone number is in the “How to Order”
section at this site:
• Fax Orders
United States (toll free) 1-800-445-9269
Canada 1-403-267-4455
Outside North America Fax phone number is in the “How to Order” section at this site:
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at the Redbooks Web site.
IBM Intranet for Employees

IBM employees may register for information on workshops, residencies, and Redbooks by accessing
the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button.
Look in the Materials repository for workshops, presentations, papers, and Web pages developed
and written by the ITSO technical professionals; click the Additional Materials button. Employees may
access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Redbooks fax order form
Please send me the following:
Title Order Number Quantity
First name Last name
Company
Address
City Postal code Country
Telephone number Telefax number VAT number
Invoice to customer number
Credit card number
Credit card expiration date Card issued to Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.

Glossary
access plan. Plan generated by the DB2 number, the customer group, and the levels of
Optimizer of how to access the data in the tables customer hierarchy.
being queried. drill down. A technique that allows you to explore
Administrator Workbench. A tool to control the detailed data that was used in creating
how the data gets from the source systems into summary level data. In BW, this is one of the
the InfoCubes of the Business Information navigation techniques.
Warehouse. It is used to request and manage fact table. A table that contains all key figures
data in the source system, InfoSource, (facts) of the InfoCube. It is the central table in the
InfoCube, InfoObject, Scheduler, and Monitor. star schema.
aggregation. The process of summarizing flat file. A file that contains text. It is used to load
atomic (detailed) level data horizontally, information into the data warehouse. It can be
vertically and chronologically. comma-delimited, fixed-width, or variable width.
BAPI. Business Application Programming full update. A type of database update. Replaces
Interfaces or Business API. all data. See also delta update.
Business Explorer. SAP BW reporting tool. granularity. The level of detail contained in a
characteristic. An element of a business such as: single record of the fact table. The coarser the
company code, product, material, or fiscal year. granularity, the more the data is summarized
Also an element of a dimension. before storage.
data extraction. Pulling the data out of its source InfoCube. A multidimensional central data
system (or systems) and putting it into a container for queries and evaluations. Contains
warehouse-usable form. two types of data: key figures and characteristics.
data loading. A process of loading data from InfoObject. Generic term for characteristics and
source systems into the BW InfoCube. key figures.
data mart. A decision support environment that InfoPackage. A description of data that should be
addresses the common decision support needs of requested from a source system.
a specific group within the organization (typically a informational data. Data created from
department or geographic area). In BW data operational data, stored in a format that makes
marts can be created by queries on a specific easier business analysis. Analysis can be in the
aggregate. form of decision support (queries), report
data warehouse. A database that contains generation, Executive Information Systems, or
summarized data created from transactional statistical analysis.
data found in the OLTP system. InfoSource. A quantity of InfoObjects grouped
database. A means of data storage. together from a business point of view. It can
contain either transaction data or master data.
database table. See table.
key figure. Values or quantities such as revenue,
delta update. A type of database update. costs, number of employees.
Refreshes only data changed since the last
extraction. See also full update. legacy system. A system that has been in place
for a significant period of time. Serves as a source
dimension. Grouping characteristics that belong system for a data warehouse.
together from a content point of view. For example,
a customer dimension may contain the customer

master data. Data that remains unchanged over a source system. Every system that is available in
long period time, for example, customer names and the Business Warehouse for data extraction.
addresses.
staging engine. Implements data mapping and
meta data. Data about data. Meta data describes data transformation during the data loading
format, origin, history, and other aspects of data. process. It extracts data from a source system.
meta data repository. It contains the various star schema. A data structure that combines fact
classes of meta data. tables and dimension tables in a way that provides
easy and efficient access to data.
Monitor. Monitoring tool of the Administrator
Workbench to oversee the data request and SQL. Structured Query Language. A language
processing in the Administrator Workbench. developed by IBM that provides access to relational
database.
multidimensional database. A specialized
database that is designed to enable the querying table. An array of data in a table form. It consists of
and viewing of large volumes of data based on columns (data values of the same type) and rows
predefined dimensions such as geography, (data records). Each record can be identified
customer, and product. uniquely by one or several fields.
multidimensional table. See multidimensional table index. Index used to accelerate data
database. selection from a table. It is similar to a copy of the
table reduced to certain fields only and always
navigation. Analysis of the InfoCube by displaying
sorted.
different views of the data of a query.
think time. The time that the end user spends
navigation attributes. Attributes that allow you to
between two key presses.
present different views of the data.
transaction data. Operational data provided by an
N-way system. A system with two or more CPUs.
OLTP system.
OLAP. Online analytical processing. A type of
processing used to analyze summarized online
transaction processing (OLTP) data. OLAP allows
multidimensional views and analysis of that data for
decision support processes.
OLTP. Online transaction processing. A type of
processing of operational data.
operational data. Data that is used to run a
company’s business. It is stored, retrieved, and
updated by an OLTP system.
operational data store (ODS). An integrated
database that contains a copy of extracted data
from source systems.
query. A selection of InfoObjects (characteristics
and key figures) for analysis of the data in an
InfoCube.
scheduler. The nexus between the source
systems and the InfoCubes.
schema. The logical and physical definition of data
elements, for example, a star schema.

Index
catalog updates 55
DSNDB07 58
A DSNTPID 51
ABAP 4
log 52
access plan 127
objects 47
Administrator Workbench 6, 79, 127
optimizer 79
aggregate build 85
prerequisites 47
aggregation 58
PTFs 47
application server 13, 19
reorganization 58
setup 31
RUNSTATS 54, 91
temporary database 58
B DB2 parameters 49
BAPI 5, 127 debugging 66
Business Content (BCT) 6, 22 delta update 127
Business Explorer 5, 9, 127 dimension 8, 127
BW application dimension table 8
sizing 91 dispatching priority 39
tuning 91 documentation
BW database SAP R/3 installation 43
backup/recovery 81 drill down 127
data loading 67
partitioning 86
BW Patch 71 E
Enterprise Storage Server (ESS) 14
BWGUI 71
ESCON 15, 26
C
characteristic 7, 127 F
fact table 7, 127
configuration
Fast Ethernet OSA-2 26
for this study 28
FDDI
ICLI 36
adapter 20
SMS 34
connection 13
TCP/IP 42
Driver 20
connectivity 15, 19
FDDI OSA-2 26
testing 31
full update 127
CRM 1
D H
hardware
data mart 7, 127
application server 19
data warehouse 4, 127
configuration 28
database server 13, 14
database server 14
setup 30
DB2
additional DB2 catalog indexes 52 I
authorization 54 ICLI
bufferpools 50 client setup 42
catalog and directory 50 customizing 36

environment file 36 Operational Data Store (ODS) 5
security 38 OSA-2 Adapters 15
ICLI packages 18 OSA-EXPRESS 26
ICLI plan 18
ICLI server 17
customizing 36
P
partitioning 86
DB2 binding 53
performance 89
startup JCL 36
PI-A 99 72
ICLIRUN 18
presentation server 13 , 22
InfoCube 7, 127
processor 14
partitioning 87
update 86
updating 84 R
InfoObject 6, 127 R3SETUP 44
InfoPackage 83, 127 problem solving 68
InfoPackage Scheduler 83 RACF 19, 37
InfoSource 84, 127 RRS 48
installation
pre-installation checking 26
steps 45
S
SAP 20
INSTGUI 44 BASIS 25
INSTTOOL.SH notes 61
location 43 SAP BW
Integrated Call Level Interface (ICLI) 8, 17 architecture 4
IRLM parameters 50 data structure 6
DB2 objects 47
K SAP R/3 tools 80
key figure 7, 127 SAP system name 20
SAPGUI 13, 71
SAPOSCOL 65
L SID table 8
legacy system 127
SMS 34
ACS routine 16
M configuring 34
master data 128 staging engine 6, 128
master table 8 star schema 7, 128
meta data 128 STARJOIN 83
Meta Data Manager 6 start up JCL 36
multidimensional database 128 storage 14
System Managed Storage (SMS) 16
N
navigation 128 T
TCP/IP
hosts file 40
O services file 41
ODS
testing 42
data loading 83
think time 128
OLAP 128
OLAP processor 5

U
URLs 76
user information 19
V
VSAM catalog 48
VTOC 48
W
Workload Manager (WLM) 15
131
IBM Redbooks review
Your feedback is valued by the Redbook authors. In particular we are interested in situations where a
Redbook "made the difference" in a task or problem you encountered. Using one of the following
methods, please review the Redbook, addressing value, subject matter, structure, depth and
quality as appropriate.
• Use the online Contact us review redbook form found at ibm.com/redbooks
• Fax this form to: USA International Access Code + 1 914 432 8264
• Send your comments in an Internet note to redbook@us.ibm.com
Document Number SG24-5681-00

Redbook Title SAP Business Information Warehouse on OS/390
Review
What other subjects would you

like to see IBM Redbooks
address?
Please rate your overall O Very Good O Good O Average O Poor

satisfaction:
Please identify yourself as O Customer O Business Partner O Solution Developer

belonging to one of the O IBM, Lotus or Tivoli Employee
following groups: O None of the above
Your email address:

The data you provide here may
be used to provide you with O Please do not use the information collected here for future
information from IBM or our marketing or promotional contacts or other communications beyond
business partners about our the scope of this transaction.
products, services or activities.
Questions about IBM’s privacy The following link explains how we protect your personal information.
policy? ibm.com/privacy/yourprivacy/

90<->249 pages
0.17”<->0.473”
(0.2”spine)
SAP Business Information Warehouse on OS/390
®
SAP Business Information

Warehouse
on OS/390
Prepare, install, and This redbook explores the SAP Business Information
configure your SAP Warehouse (BW) 1.2B on the S/390 system. It takes a close
INTERNATIONAL
BW on OS/390 look at the tasks and functions that are specific to the S/390 TECHNICAL
environment. It is designed to assist S/390 technical SUPPORT
Administer your SAP specialists, DB2 database administrators, and SAP Basis ORGANIZATION
consultants in implementing this technology.
BW databases
This redbook offers valuable information that includes:
- An overview of BW
Recommended - The preparation of the BW installation BUILDING TECHNICAL
sizing approaches - The BW installation process INFORMATION BASED ON
PRACTICAL EXPERIENCE
- Recommendations on administering BW databases to:
improve query response time, improve performance of
loading databases, update delta information, gather database IBM Redbooks are developed by
statistics, and more. the IBM International Technical
- Preliminary sizing recommendations based on tests and SAP Support Organization. Experts
from IBM, Customers and
recommendations
Partners from around the world
We assume that the readers have already installed the SAP create timely technical
R/3 system and are familiar with SAP applications, information based on realistic
terminology, prerequisites, documentation, and technology. scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:

ibm.com/redbooks
SG24-5681-00 ISBN 0738418943

Sap Business Information Warehouse On Os 390

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sap Business Information Warehouse On Os 390

Uploaded by

Copyright:

Available Formats

SAP Business

Administer your SAP BW

International Technical Support Organization

SAP Business Information Warehouse

First Edition (September 2000)

This document created or updated on September 11, 2000.

Comments may be addressed to:

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

Chapter 1. SAP Business Information Warehouse (BW) overview . . . .1

Chapter 2. Our system environment . . . . . . . . . . .. . . . .. . . . . .. . . . . 13

Chapter 3. Preparing OS/390 and AIX . . . . . . . . . . . . . . . . . . . . . . . . . . 25

© Copyright IBM Corp. 2000 iii

Chapter 4. Preparing DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 47

Chapter 5. Installing SAP BW OS/390 with AIX Application Servers. . 59

iv SAP Business Information Warehouse on OS/390

Chapter 6. Managing SAP BW database . .. . . . . .. . . . .. . . . . .. . . . . 79

Chapter 7. Tests performed at ITSO . . . . .. . . . . .. . . . .. . . . . .. . . . . 83

Chapter 8. Sizing, performance, and tuning considerations . . .. . . . . 89

Appendix A. What’s new in SAP BW 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . 95

Appendix B. DB2 Installation parameters . . . . . . . . . . . . . . . . . . . . . . . . 97

Appendix C. How to set up RRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Appendix D. Enterprise Storage Server (ESS) . . . . . . . . . . . . . . . . . . . 115

Appendix E. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Appendix F. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

vi SAP Business Information Warehouse on OS/390

1. SAP BW architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

© Copyright IBM Corp. 2000 vii

1. Official names and usage in this redbook . . . . . . . . . . . . . . . . . . . . . . . . . 11

© Copyright IBM Corp. 2000 ix

This redbook offers valuable information that includes:

The team that wrote this redbook

Seungrahn Hahn is a Business Intelligence specialist at the ITSO. Before

Patrick Horkan is an IT Architect in the IBM ERP Competency Center, The

Christoph Laube manages a competence center of OS/390 consultants at

© Copyright IBM Corp. 2000 xi

Gert Ruland is a BI specialist at the S/390 New Technology Center,

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

xii SAP Business Information Warehouse on OS/390

We want our Redbooks to be as helpful as possible. Please send us your

SAP Business Information Warehouse (BW) is an SAP strategic product

In this chapter we briefly describe:

1.1 Why use Business Information Warehousing

In a world where good Customer Relationship Management (CRM) is a

The modern solution for this is Business Information Warehousing (BW). BW

© Copyright IBM Corp. 2000 1

1.2 Why use BW on SAP R/3 on OS/390

For customers already using OS/390 systems

2 SAP Business Information Warehouse on OS/390

For customers using OS/390 as a new platform

Chapter 1. SAP Business Information Warehouse (BW) overview 3

1.3 The architecture of SAP Business Information Warehouse

1.3.1 The components of the Business Information Warehouse

4 SAP Business Information Warehouse on OS/390

Reporting and Analysis for

Business Information Operational

Non R/3 Production Production OLTP

Non R/3 OLTP Applications R/3 OLTP Applications

Figure 1. SAP BW architecture overview

1.3.1.2 Business Information Warehouse Server

Chapter 1. SAP Business Information Warehouse (BW) overview 5