sap business information warehouse on os 390

ibm.com/redbooks

SAP Business Information Warehouseon OS/390

Seungrahn HahnPatrick Horkan

Christoph LaubeGert Ruland

Prepare, install, and configure your SAP BW on OS/390

Administer your SAP BW databases

Recommended sizing approaches

http://www.redbooks.ibm.com/


SAP Business Information Warehouseon OS/390

September 2000

SG24-5681-00

International Technical Support Organization

© Copyright International Business Machines Corporation 2000. All rights reserved.Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

First Edition (September 2000)

This edition applies to SAP Business Information Warehouse 1.2B (SAP R/3 4.5B). Data server usesDB2 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 OrganizationDept. HYJ Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Before using this information and the product it supports, be sure to read the general information inAppendix E, “Special notices” on page 119.

Take Note!

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1. SAP Business Information Warehouse (BW) overview . . . . 11.1 Why use Business Information Warehousing . . . . . . . . . . . . . . . . . . . . 11.2 Why use BW on SAP R/3 on OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 The architecture of SAP Business Information Warehouse . . . . . . . . . . 4

1.3.1 The components of the Business Information Warehouse. . . . . . . 41.3.2 How things are done with SAP BW . . . . . . . . . . . . . . . . . . . . . . . . 61.3.3 BW data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.4 Database Management System (DBMS). . . . . . . . . . . . . . . . . . . . 81.3.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.6 The presentation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 The terminology used in this redbook . . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapter 2. Our system environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1 OS/390 for SAP BW and R/3 database server . . . . . . . . . . . . . . . . . . 14

2.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.2 Software environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 AIX for SAP BW and R/3 application server . . . . . . . . . . . . . . . . . . . . 192.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3 System setup for SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.4 System setup for SAP R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Windows NT for Presentation Server . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 3. Preparing OS/390 and AIX . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Pre-installation checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Defining the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3 Installation prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Database server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.2 Application server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.3 Database server and application server connectivity testing . . . . 313.3.4 DASD initialization on the database server . . . . . . . . . . . . . . . . . 32

© Copyright IBM Corp. 2000 iii

3.3.5 Configuring OSA-2 on the database server. . . . . . . . . . . . . . . . . 323.3.6 Installing DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.7 Configuring SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.8 Customizing OS/390 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.9 Customizing TCP/IP on the database server . . . . . . . . . . . . . . . 343.3.10 Customizing the ICLI Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.11 Customizing RACF or equivalent . . . . . . . . . . . . . . . . . . . . . . . 373.3.12 Set OS/390 dispatching and I/O priorities . . . . . . . . . . . . . . . . . 393.3.13 Customizing TCP/IP on the central instance . . . . . . . . . . . . . . . 403.3.14 Setting up the ICLI client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.15 Testing connectivity -- central instance and database server . . 42

3.4 Installing SAP BW on DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . 433.4.1 General notes on the installation from AIX . . . . . . . . . . . . . . . . . 433.4.2 Hints and tips -- installing with AIX . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 4. Preparing DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1 Inside the SAP BW database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Prerequisites of DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 OS/390 setup for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4 Setting up RRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5 Customizing DB2 parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6 DB2 system database requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.6.1 DB2 catalog and directory database size . . . . . . . . . . . . . . . . . . 514.6.2 Additional DB2 catalog indexes . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.7 Preparing the DB2 log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.8 DB2 Binding for the ICLI server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.9 DB2 authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.10 Maintaining DB2 catalog statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.10.1 RUNSTATS utility considerations . . . . . . . . . . . . . . . . . . . . . . . 544.10.2 Updating DB2 catalog statistics manually . . . . . . . . . . . . . . . . . 554.10.3 Maintaining catalog statistics for R/3 cluster tables. . . . . . . . . . 56

4.11 Post-installation tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.11.1 Reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.11.2 DB2 temporary database (DSNDB07). . . . . . . . . . . . . . . . . . . . 58

Chapter 5. Installing SAP BW OS/390 with AIX Application Servers . . 595.1 SAP BW installation overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 SAP BW pre-installation: data gathering . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.1 Gathering the SAP notes via SAPNet R/3 Frontend . . . . . . . . . . 605.2.2 Searching for SAP notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2.3 Downloading patches and other information from SAPSERVx . . 625.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 . . . . . . . . . . . . . . . . 645.5 SAP BW installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.5.1 Starting BW installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.5.2 Building the BW database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.5.3 Loading the BW database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.5.4 R3SETUP problem solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.6 SAP BW post installation: completing the install . . . . . . . . . . . . . . . . . 695.6.1 Summary of the BW database . . . . . . . . . . . . . . . . . . . . . . . . . . 705.6.2 Summary of the SAP R/3 source system . . . . . . . . . . . . . . . . . . 715.6.3 SAPGUI/BWGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.6.4 BW Patch installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.7 Installing the R/3 PlugIn PI 99 or PI-A 99 for SAP BW . . . . . . . . . . . . 725.7.1 PlugIn -A 99 pre-installation: data gathering . . . . . . . . . . . . . . . . 735.7.2 PlugIn -A 99 pre-installation: system check . . . . . . . . . . . . . . . . 735.7.3 PlugIn -A 99 pre-installation: final preparations. . . . . . . . . . . . . . 735.7.4 PlugIn -A 99 installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.7.5 PlugIn -A 99 post-installation: completing the installation . . . . . . 75

5.8 What to do with those leftover CD-ROMs . . . . . . . . . . . . . . . . . . . . . . 765.9 Useful URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Chapter 6. Managing SAP BW database . . . . . . . . . . . . . . . . . . . . . . . . 796.1 Administrator’s workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.2 SAP R/3 tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.3 DB2 utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.4 Backup and recovery strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Chapter 7. Tests performed at ITSO . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.1 Loading the ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2 Updating the InfoCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.3 Aggregate build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.4 .Running queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.5 Incremental DataPackage update. . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.6 Partitioning tables in SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.6.1 Partitioning in the ODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.6.2 Partitioning in the InfoCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 8. Sizing, performance, and tuning considerations . . . . . . . . 898.1 Special considerations for BW applications . . . . . . . . . . . . . . . . . . . . 89

8.1.1 BW administration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908.1.2 Using RUNSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.2 General sizing and tuning approach . . . . . . . . . . . . . . . . . . . . . . . . . . 918.2.1 Pre-installation and planning phase . . . . . . . . . . . . . . . . . . . . . . 918.2.2 Pilot or evaluation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.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 . . . . . . . . . . . . . . . . . . . . . . . . 97B.1 DSNZPARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97B.2 IRLMPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103B.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123F.1 IBM Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123F.2 IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123F.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123F.4 Referenced Web sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125IBM 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52. Table structure of an InfoCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83. Business Explorer example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104. Test system environment for SAP BW application . . . . . . . . . . . . . . . . . . 135. A storage class definition for SAP applications . . . . . . . . . . . . . . . . . . . . . 176. A storage group definition for SAP applications. . . . . . . . . . . . . . . . . . . . . 177. Physical SAP BW system configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 288. I/O configuration for the FDDI connection . . . . . . . . . . . . . . . . . . . . . . . . . 339. ICLI environment file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3610. ICLI started procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3711. Allocating DB2 active log data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5312. An example of DB2 catalog updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5613. Sample SQL statements for updating catalog statistics for cluster tables . 5714. Sample SQL statements to avoid deadlock . . . . . . . . . . . . . . . . . . . . . . . . 5715. DB2 installation parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10416. DB2 buffer pool allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10517. DB2 storage sizes and connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10518. DB2 trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10619. DB2 locks and IRLM definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10620. DB2 archive log parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10721. DB2 active log parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10722. DB2 application parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10823. DB2 operation and DDF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10824. Sample JCL to define an RRS LOGR couple data set . . . . . . . . . . . . . . 11025. Sample couple data set definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11026. Sample JCL to define RRS log streams . . . . . . . . . . . . . . . . . . . . . . . . . 11227. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 112. SMS naming convention for SAP applications. . . . . . . . . . . . . . . . . . . . . . 163. Information about DB2 systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184. User ID definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195. SAP BW definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206. User ID information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217. Physical volume information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218. File system allocation for SAP BW code installation . . . . . . . . . . . . . . . . . 219. User ID setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2910. TCPIP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2911. Other definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2912. Statistics of the DB2 objects of SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . . 4713. DB2 parameter checked by R3SETUP (BW). . . . . . . . . . . . . . . . . . . . . . . 4914. Highly recommended IRLM parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 5015. Recommended DB2 bufferpool allocation . . . . . . . . . . . . . . . . . . . . . . . . . 5016. DB2 installation panel DSNTPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5117. New indexes created against the DB2 catalog tables during R3SETUP . . 5218. DB2 authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5419. Installation activities and runtime durations . . . . . . . . . . . . . . . . . . . . . . . . 6020. SAPNet R/3 Frontend Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6021. AIX file system layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6322. AIX language filesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6323. R3SETUP input required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6424. Debugging file and locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6625. R3SETUP problem-solving tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6826. R/3 Profile parameter changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6927. SAP BW DB2 UDB 6.1 OS/390 database statistics. . . . . . . . . . . . . . . . . . 7028. SAP R/3 DB2 UDB 6.1 OS/390 database statistics. . . . . . . . . . . . . . . . . . 7129. File system size for PlugIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7330. PlugIn variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7331. Useful URLs - SAP logon required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7632. Useful URLs - Public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7733. 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.2Bon the S/390 system. It takes a close look at the tasks and functions that arespecific to the S/390 environment. It is designed to assist S/390 technicalspecialists, DB2 database administrators, and SAP Basis consultants inimplementing 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 queryresponse time, improve performance of loading databases, update deltainformation, gather database statistics, and more.

• Preliminary sizing recommendations based on tests and SAPrecommendations

We assume that the readers have already installed the SAP R/3 system andare 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 worldworking at the International Technical Support Organization PoughkeepsieCenter.

Seungrahn Hahn is a Business Intelligence specialist at the ITSO. Beforejoining 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, TheAmericas. He has been working with SAP R/3 on DB2 for OS/390 for manyyears, and is certified as an SAP R/3 and SAP BW Technical Consultant. Hejoined IBM in December 1997.

Christoph Laube manages a competence center of OS/390 consultants atSCHUMANN AG in Cologne, Germany. His task is to build consulting teamsfor 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 ofexperience in migration projects in the area of OS/390, DB2, andmultiplatform environments. Recently he participated in a pilot study ofporting UNIX/Informix applications to OS/390 UNIX. Christoph is the regionmanager of GUIDE SHARE Europe for the German Region, and formerly ledthe 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 IBMGermany in the S/390 division as a system engineer and salesrepresentative. He has 22 years of experience in different areas of IT.

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

Jan BaisdenInternational Technical Support Organization, Poughkeepsie Center

David BenninRich ConwayRobert HaimowitzVasilis KarrasInternational Technical Support Organization, Poughkeepsie Center

Terry BarthelAlfred SchwabDenny SellElla BuslovichInternational Technical Support Organization, Poughkeepsie Center

Benno StaeblerJoachim ReseSAP R/3 on DB2 for OS/390 Porting team: Business Warehouse, IBMGermany

Christine Gaul-GaensslenCustomer support for SAP R/3 on DB2 for OS/390, IBM Germany

Michael SheetsIBM SAP International Competency Center - S/390

Lee SiegmundIBM Dallas System Center

xii SAP Business Information Warehouse on OS/390

Don GeisslerScott BellIBM 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 yourcomments about this or other Redbooks in one of the following ways:

• Fax the evaluation form found in “IBM Redbooks review” on page 133 tothe 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 [email protected]

xiii

http://www.redbooks.ibm.com/contacts.html


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 productarchitecture that gives you immediate access to data that is relevant todecision-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 isdirectly dependent on the quality of the available information. The morecurrent the information and the faster you can obtain it, the more relevant it is.

In a world where good Customer Relationship Management (CRM) is agrowing competitive advantage, you have to know where to focus in specificsituations. Such focus is impossible without having reliable information tobase decisions on, so it is important for your company to be able to quicklyextract the important data and present it in such a way that intelligentbusiness decisions can immediately be derived.

The modern solution for this is Business Information Warehousing (BW). BWoffers managers an array of possibilities to easily define and satisfy theirinformation needs.

Put simply, a BW system gathers all the information needed to answer yourrequests from your production data. This data gathering can be scheduled foroff hours on a daily or weekly basis, thus making it as current as possiblewithout disrupting your operating environment.

BW stores all information in its own database in a very sophisticated way thatis specially prepared to handle your queries on it. For example, certainaggregation and summarization is already done, without having to becalculated when you query for it. As a result, your queries on the data will besatisfied 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’sbusiness and your customers’ behavior (for example, the results of certainmarketing campaigns), and about the relationships between these factors.

BW can extract, store, and provide quick and easy access to all this businessknowledge. You, in turn, can use this knowledge to make successful businessdecisions by querying BW.

BW can help you determine the future direction of your company. This is whymore 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 onan OS/390 system would be the most expensive solution. On the contrary, thediscussions and experiences that the project team had with customers usingor intending to use BW on OS/390 clearly showed that there are verycompelling reasons why they chose this platform and why they considerOS/390 to be the best possible solution.

These customers can be divided into two groups: those who already haveOS/390 systems or S/390 platforms, and those who would enter a newplatform with OS/390. Their main reasons for using BW on OS/390 are asfollows.

For customers already using OS/390 systems1. 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; thismeans:

– 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, anddatabases in a most flexible way, without having to IPL or redefineparameters for each change.

– Hardware growth benefits all applications and systems.

For customers using OS/390 as a new platformThese reasons for using SAP on OS/390 for BW were cited by both groups ofcustomers:

1. Availability

– S/390 platforms and storage subsystems are well known for highavailability in the marketplace.

– Using the Parallel Sysplex facilities will increase availability to thehighest possible level.

– Changes to hardware and software can be made in flight, withoutdisrupting applications.

2. Security

– OS/390 is acknowledged to be one of the most secure systems--and allcustomers want the best possible protection for strategic data, such asthat stored in BW systems.

– OS/390 UNIX System Services is especially secure, because RACF isused for security instead of standard UNIX security.

– If BW data may be accessed from the Internet, thus making securityconcerns particularly important.

3. Accounting, tuning and measurement

A BW application will contain a large and ever-increasing mountain ofdata, so it is particularly important to track (and probably, bill) the userswho are producing and using this data. For accurate accounting, you firstneed to perform measurements, collecting data from the system and thesubsystems, so users are fairly charged.

Accurate and continuous measurement is the base for all system tuningactivities, as well--and you also need measurement data to predict yoursystems and storage growth and to contract service level agreements withyour 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 usedby every employee who makes business decisions.

For more than twenty years, OS/390 has performed measurement andaccounting 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 thetools needed for these tasks in a BW environment are already availableand ready for you to use.

UNIX and PC systems simply do not offer the measurement andaccounting capabilities of OS/390. So if you need detailed informationabout database activity or storage usage to do measurement, tuning,accounting, service-level design or IT growth projections, OS/390 can bethe solution--and these OS/390capabilities become even more important ifyou 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 warehousesolution tailored to SAP R/3. It comes with a specially tailored SAP R/3system, where you only can run SAP BW. It is a separate application (anadd-on) that is independent from SAP R/3 and has its own release andshipment 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 businessapplication programming (ABAP).

• The SAP BW database server, which contains all user data and systemdata.

• The SAP BW frontend, which consists of the SAPGUI, the normal SAP R/3graphical user interface, and Business Explorer, hosted by MS EXCEL,which is the interface for the analytical part of SAP BW.

1.3.1 The components of the Business Information WarehouseFigure 1 on page 5 shows the three-level layered components of BW, which isa 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

SAP R/3 on DB2 for OS/390: Implementing with AIX or Windows NTApplications Servers, SG24-4945

Reference


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

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 getinformation about where to get the data, and with the data manager to getthe actual data. The interface to the Business Explorer of the SAP BWfrontend is the Business Application Interface (BAPI).

• Data Manager takes care of the data in the InfoCubes and OperationalData Store. InfoCubes is the container for the data tables for OLAPprocessing, and the Operational Data Store (ODS) holds the data in flatfile-type tables.

Business Explorer

Report Catalog Browser

Reporting and Analysis forExcel Reporting and Analysis

OLAP Processor

Data ManagerMeta Data Manager

Staging Engine

BAPI

BAPI

InfoCubes

OperationalData Store

Meta DataRepository

Non R/3 ProductionData Extractor

Non R/3 OLTP Applications

ProductionData Extractor

OLTPReporting

R/3 OLTP Applications

Business InformationWarehouse Server


• The Staging engine is responsible for loading the data that is extractedfrom the application data. The interface to the extracted data is suppliedby SAP BW, in the case of SAP R/3 and SAP R/2 systems. For other OLTPapplications, you have to develop it yourself.

• Meta Data Manager keeps track of the data warehouse environment andstores its tables in the Meta Data Repository.

1.3.1.3 OLTP systemsAt the bottom of the Figure 1 on page 5 are the production systems, fromwhich the data is extracted and loaded into SAP BW.

Administrator WorkbenchThe Administrator Workbench tool can also help in BW administration. ThisSAPGUI-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 ofSAP BW and SAP R/3.

1.3.2 How things are done with SAP BWThis 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 AdministratorWorkbench (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 structuresThe basic building blocks of the BW data structures are called characteristicsand 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 yourInfoObjects.

Characteristics are the elements of a company’s business, for examplecompany code, product, material, customer group, fiscal year, period, orsales region. They may have a hierarchical structure; products, for example,may be grouped together into product groups. Characteristics are stored indimension tables.

Key figures are the values or quantities in a company’s business, such assales 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. Adimension table contains characteristics that are required both in reportingand in the analysis of the key figures. Dimension tables are independent ofone another. Only the fact table connects dimension tables through keyfigures.

The largest organizational unit is an InfoCube; see Figure 2 on page 8 for anexample. You can think of an InfoCube as a data mart. An InfoCube is used toanswer specific end-user queries and to provide information for specificanalysis. It consists of a number of tables that are put together in a extendedstar schema. A large fact table is surrounded by several dimension tables.


Figure 2. Table structure of an InfoCube

Dimension tables are linked to the fact table using surrogate keys. Asurrogate key is used as a unique key within each dimension table. Themaster data table and the dimension table are linked by system-generatedidentifications called Set IDs that are stored in Set ID (SID) tables.

The master table contains attributes of characteristics, while the dimensiontable contains the representation of the characteristics. Master tables containinformation that can be used by other InfoCubes. Thus, the dimension tablewith 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, isbased in a vendor product. The DB2 UDB for OS/390 Version 6.1 should beused as the hosting database manager. As an add-on to this database, thereis a special interface called Integrated Call Level Interface (ICLI). For detailed

FACT

S IDTable

SIDTable

SIDTable

SIDTable

S IDTable

SIDTable

S IDTable

Dimensiontable

SIDTable

Master

Dim ensiontable

D imens iontable

D imens iontable

Master

Master

TempTab

Master Master

MasterSID

Table

Master

Master

TempTab

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SIDAttr

SID Attr

Temp Tab

SID Table

Master

Dimension

Fact Table


information about ICLI, refer to SAP R/3 on DB2 for OS/390: Planning GuideSAP R/3 Release 4.5B, SC33-7964.

1.3.5 SecurityAccess to reports that contain sensitive data must be restricted to authorizedpersons only. SAP BW provides various controls on different levels. Accessrights may defined for a report as a whole, or for certain key figures (forexample, salary in a personnel InfoCube), or even for specific values of acharacteristic (for example, a certain cost center). You manage access rightswith the Administrator Workbench.

1.3.6 The presentation layerThe 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 tounderstand 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 compoundedwhen they are used in combinations. Also, these titles are commonly used inshorter versions by both the writers and readers of this redbook. Therefore,we decided to use the shorter versions in this publication (unless there was alikelihood of confusion over which specific product we are discussing); seeTable 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 WarehouseDatabase Server

SAP BW DB server

SAP Business Information WarehouseApplication Server

SAP BW Application server

SAP Business Information WarehouseCentral Instance

SAP BW 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 BusinessInformation Warehouse (BW), and the performance difference according todesign 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 applicationservers

Figure 4. Test system environment for SAP BW application

Token-Ring

9.12.0.73

9.12.0.75

SAPGUI

SAPGUI

RS/6000 F50

AIX 4.3.3

SAP R/34.5BApplicationServer

AIX 4.3.3

SAP BW1.2BApplicationServer

(Central instance)

RS/6000 F50

ESSShark

OSA

TOKEN-RING

OSA

FDDI

ICLI

SERVERS

OS/390 V2R7

9672-X77 (1 LPAR)

DB2 V6

DBH1

DB2 V6

DB2Q

TOKEN-RING

FDDI-RING

ALE


Because SAP BW is designed to run in a 3-tier architecture environment, weassumed that different groups of system programmers need to work together.Therefore, we divided our work from the viewpoint of the SAP R/3 server-levelconcept 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 theSAP R/3 production database.

2.1.1 HardwareWe used the following hardware in our tests:

ProcessorWe used an IBM 9672-X77, which is a 7-way processor of the G6 family. Weran 15 LPARs on this processor, and the OS/390 system that we used for thisredbook ran on one of the LPARs. We were given two shared processors atfirst and later were assigned two additional shared processors. All timeestimates are related to the four-processor environment, unless statedotherwise.

We did not see any degradation of our LPAR from the other LPARs on ourserver. 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 9672machines and three Coupling Facilities, our LPAR did not participate in thesysplex. It worked as a standalone system.

StorageWe had 1024 MB of real storage and 64 MB of expanded storage. We did notsee any memory constraints.

Enterprise Storage Server (ESS)We used 10 volumes of ESS DASD (Shark) for the source SAP R/3databases, and 12 volumes of ESS DASD for the SAP BW database. Afterinstallation 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 storagesubsystem that complements the strengths of S/390.

The logical disk architecture of the ESS spreads data across all the availabledisks, reducing the requirement for data placement to avoid hot spots.Additional physical storage capacity can be added nondisruptively. For moreinformation about ESS, refer to Appendix D, “Enterprise Storage Server(ESS)” on page 115.

The volumes resided on an IBM ESS subsystem which was connected bymultiple controllers via switched ESCON. A pair of 2 volumes for eachdatabase used one controller. Each controller had 2 ESCON paths. All DASDwas shared with the other LPARs.

We did not see major impacts to our work from the I/O subsystem. The DASDresponse time we saw was about 3 to 5 milliseconds.

ConnectivityThe OS/390 LPAR used two OSA-2 Adapters on the 9672-X77, which arealso shared by other LPARs:

• The EN-TR OSA-2 Adapter connected to a 16 Mb token-ring LAN and wasused for non-BW access to OS/390.

• The FDDI OSA-2 Adapter was used for all SAP BW and SAP R/3application server-to-database server communication. These definitionsare 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 environmentWe used the following software and customized the system based on therecommendations for our tests.

2.1.2.1 OS/390 LayoutWe used OS/390 Version 2.7 at RSU9907 with ahead maintenance weidentified in OSS note 81737. Our operating system was produced by cloningfrom 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 thesystem-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. Thedefinitions to the service classes apply to standard recommendations in theplanning guide. See SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3Release 4.5B, SC33-7964 for details.

We did not experience situations where one of our jobs or DB2 or ICLI waswaiting for CPU, storage or DASD resources claimed by other addressspaces in the system.

System Managed Storage (SMS)We defined SMS for SAP application databases as shown in Table 2. (We didnot use SMS for DB2 system databases.)

Table 2. SMS naming convention for SAP applications

In all constructs, additional parameters, such as those used for performanceor availability, were not used. Management class and data class were setcorresponding to system standards. That specifically means that DB2 datasets are not migrated in any way.

We changed an ACS routine (definition of storage class and storage group) tomake these definitions effective. Figure 5 on page 17 shows the definition ofthe storage class. Figure 6 on page 17 shows the storage definition thatconnects storage class with storage group.

Storage class SAPBW includes all data sets that use SAPBW as a firstqualifier. All data sets that belong to storage class SAPBW are created in thevolumes that belong to storage group SGSAPBW. Of course, 12 volumeswere defined in the storage group SGSAPBW for the SAP BW application.

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


Figure 5. A storage class definition for SAP applications

Figure 6. A storage group definition for SAP applications

ICLI serverIntegrated Call Level Interface (ICLI) comes with OS/390 and provides aremote 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 systemdoes not have the ICLI component, ask your OS/390 system programmer toinstall it. See SAP OSS Note 81737 and the planning guide for moreinformation about ICLI Server.

PROC STORCLASFILTLIST JANLOG INCLUDE(DB2V510U.ARCHLOG%.**)FILTLIST SAPBWDS INCLUDE(SAPBW.**)FILTLIST SAPR3DS INCLUDE(SAPR3.**)/* FILTLIST REQ_SMS INCLUDE('LIBRARY','PIPE','HFS') */....WHEN (&DSN = &SAPBWDS)

DOSET &STORCLAS = 'SAPBW'EXIT

ENDWHEN (&DSN = &SAPR3DS)DOSET &STORCLAS = 'SAPR3'EXIT

END.....

PROC STORGRPWHEN ( &STORCLAS = 'SAPBW' )

DOSET &STORGRP = 'SGSAPBW'EXIT

ENDWHEN ( &STORCLAS = 'SAPR3' )DOSET &STORGRP = 'SGSAPR3'EXIT

END


During the execution of R3SETUP for BW installation, one DB2 plan andthree DB2 packages were created, as shown in Table 3, and the plan wasgranted to the user ID of ICLIRUN automatically.

In our test, we used ICLIBLU as the ICLI server name, and user ID ICLIBLUas a user who runs ICLI server. Therefore, we granted user ID ICLIBLU theauthority to run the plan explicitly, and authorized user ID ICLIBLU to runstarted 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 NTApplication Servers, SG24-4945.

2.1.2.2 DB2 layoutWe used DB2 V6.1 at PutLevel 9911 and checked Note 81737 for additionalrequired 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

All DB2 system parameters were configured as recommended in SAP R/3 onDB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964. You canfind the initial DB2 setup parameters of our DB2 system as shown inAppendix B, “DB2 Installation parameters” on page 97.

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,FOME45B3

FOME45B1, FOME45B2,FOME45B3


There are minor differences between SAP R/3 and BW, from the DB2perspective. If you already have an SAP R/3 system at your location, you canrefer to those DB2 system parameters for the SAP BW system; see the SAPBW Installation manual for details.

2.1.2.3 Network connectivityTCP/IP was used as the communication protocol between the OS/390 andRISC/6000 running AIX. Access to our OS/390 system for TSO was on adifferent LAN than the OSA-2 adapter that was used for OMVS. These LANswere both token rings, running 16 Mb. IBM Personal Communications wasused for access TSO and OMVS. SAP and BW connectivity used the FDDIOSA-2 adapter in the 9672 that is shared by other LPARs. For moreinformation 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 informationTable 4 shows the user ID information at the database server. Thesedefinitions were all defined in RACF.

Table 4. User ID definitions

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

• SAPR3 should be defined and authorized properly by DB2 before theexecution 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/3application server, respectively. We used two RS/6000s with AIX as SAPapplication servers.

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,SAPADN2,SAPADM3

SAPR3 SAP user IDs for tests


2.2.1 HardwareWe used two IBM RS/6000 F50 systems of the same size, one for SAP R/3and 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 SoftwareWe 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 BWBefore we installed the SAP BW code, we set up our SAP BW applicationserver. We decided to use several variables, and defined them as shown inTable 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


User informationTable 6. User ID information

Volume informationWe created two volume groups in the physical volume, as shown in Table 7.

Table 7. Physical volume information

File systems and raw devicesWe allocated several file systems based on the recommendations in theinstallation manual. But during our test, we met several storage shortageproblems, so we increased the size of those file systems. Table 8 shows thefile system allocation after the SAP BW installation.

Table 8. File system allocation for SAP BW code installation

Language (additional) ISO8859-1German de_DE

Language translation ISO8859-1

User ID UID Remark

root 0

bluadm 205

sapadm1 202 SAPGUI user

Volume group name Physical volume Partition size

sapgrp hdisk3 16

sap2grp hdisk2 64

File system name Description Space used(# block)

Volumegroup

Permissionbits

/usr/sap/trans Global transport directory for allSAP systems

514288(200 MB)

sap2grp 771

/sapmnt/BLU Instance-specific data, symboliclinks to the data for one system

622592(300 MB)

sapgrp 755

/usr/sap/BLU Software and data for one SAPsystem

786432(380 MB)

sap2grp 755

/tmp/install Installation directory 622592(300 MB)

rootvg 775

Our definition Remark


2.2.4 System setup for SAP R/3We assumed you have already installed SAP R/3 applications at yourinstallation. In our SAP R/3 system, all setup parameters were defined basedon the SAP R/3 Planning book. We used SAP R/3 system for the testsregarding business content (BCT). For details, refer to 5.7, “Installing the R/3PlugIn 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 atleast 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 Javaplatforms.

2.3.1 HardwareWe used up to four PC systems. (The number of PCs you need depends onthe 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 SoftwareAll 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 becameavailable. It was self-explanatory but we encountered some time-outproblems while downloading. Since we did not find the reason, we startedseveral times and the download manager restarted without doingcompleted work again.

• The Frontend Patch Level 09 was cumulative (all previous patches wereincluded). This patch installs manually: you get a zip file that extractsabout 30 files in one directory, and then you have to manually copy the 30files into distinct SAP program directories.

• We installed Office 2000 for the SAP Business Explorer BEx. To ensurewe did not miss something needed later, we installed all the EXCELcomponents, all converters, filters, and so on. This needs about 500 MBon DASD.

• The latest OS/390 Library Collection CDs contains the Library Reader2.02. Be sure to use this version, as it is able to read all books of theDecember 1999 collection. Older versions will show error messages suchas book not properly stamped and so on.


Chapter 3. Preparing OS/390 and AIX

This chapter describes the preparation activities you need to perform whenyou install SAP BW on DB2 for OS/390 from an AIX application server. Itfocuses 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 PTFsneeded to be installed prior to the SAP BW on DB2 for OS/390 installation.

2. During Defining the Configuration, we created a planning template toensure that parameters defined during the prerequisite installation and theSAP BW on DB2 for OS/390 installation were consistent between thedatabase server and the central instance.

3. During Installing Prerequisites, we installed the missing functions basedon the findings in the Pre-Installation Checking phase.

The amount of work required will vary for each installation. We recommendthat you allow ample time to carefully complete the first three phases toensure that the actual installation of the SAP BW code will go smoothly.

For this task, the implementation project team should have the necessaryskills to configure the various components of the system that are described inthe 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 preinstallationchecking.

As a three-tier client/server application, SAP BW on DB2 for OS/390 requirescertain hardware and software to be set up on the database server, on thecentral instance, and on the presentation server. You must also set upcommunication between them.

Refer to Checklist–Installation Requirements: DB2 for OS/390 51006374 forthe hardware and software requirements needed for the SAP BW on DB2 forOS/390 installation.

The database server for SAP BW on DB2 for OS/390 runs on any S/390 (orcompatible) 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 andESCON channel adapter(s) on the gateway AIX application server(s).

• By using FDDI OSA-2 feature(s) on the S/390 database server and FDDILAN adapter(s) on the gateway AIX or NT application server(s).

• By using Fast Ethernet OSA-2 features on the S/390 database server andFAST Ethernet adapter(s) on the gateway AIX or NT application server(s).

• By using OSA-EXPRESS Gigabit Ethernet feature(s) on the S/390database server and Gigabit Ethernet PCI adapter(s) on the gateway AIXapplication server(s).

• 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 DB2for 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

References


• By using an ESCON, FDDI, or Fast Ethernet connection from thedatabase 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 toSAP 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.2or 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 isnow 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 usedduring and after installation. The installation guide, Installation of the SAPBusiness 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: PlanningGuide SAP R/3 Release 4.5B over the ones it has listed in the case that anyshould differ. The latest SAP R/3 planning guide for SAP R/3 will have themore recent information.

The R/3 Installation on UNIX: OS Dependencies booklet contains detailedinformation on the OS-dependent settings to be used.

Review OSS Notes 142990 and 149473 to get the latest list of the installationrequirements.

Review OSS Note #81737-DB2/390: APAR List to get the latest informationabout 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 inFigure 7.

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

D atabase S erve r

DB2DDF

SA PB WC entral Instance

LANFD D ILA N

S A P P resen tationS erve r

O S /390sys tem d isks

S A P B Wdatabase d isks


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-InstallationRequirements: DB2 for OS/390.

To ensure consistency of definitions between the database server and centralinstance, you need to compile all the definitions and parameters that requirecoordination as shown in Table 9, Table 10, and Table 11.

Table 9. User ID setup

Table 10. TCPIP definitions

Table 11. Other definitions

Description User ID (your value) TSO OMVS

SAP DB Owner No No

ICLI server No Yes

Submit job and OS/390UNIX

Yes Yes

Description DBServer Central Instance

IP address

IP name

Device Address

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/6000machines must be configured.

However, in the prerequisites installation, some parameters must matchbetween 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 setupBased on our findings during the Pre-installation Checking phase, you shouldplan additional tasks to be done prior to the SAP BW on DB2 for OS/390installation, 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 setupThe 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 onlybe done after the connection with the database server is set up.

3.3.3 Database server and application server connectivity testingThere will be an opportunity to test basic LAN connectivity on both thedatabase server and central instance once all prerequisites have beeninstalled. If possible, you should verify that you are able to reach at least oneother remote IP address on the same network prior to checking connectivitybetween the central instance application server and database server.

After each network connection has been verified, you can test connectivitybetween the database server and the central instance application server.

Once the connection between the central instance and database server hasbeen verified, you start the BW installation process. R3SETUP will configurethe ICLI client during the central instance installation phase. When this phasecompletes, you can check the communication between the ICLI server andICLI client with the R3trans -x command.


3.3.4 DASD initialization on the database serverThe SAP BW installation includes thousands of indexes. Therefore, werecommend that you initialize the volumes that are associated with the DB2STOGROUPs with a minimum Virtual Table of Contents (VTOC) size of 250tracks (this recommendation is based on a 3390 DASD unit).

During the installation of SAP BW, a large number of DB2 log records aregenerated. Therefore, DB2 logs must tolerate up to 2 GB per hour. Archivingis required and there must be at least 6 GB of archiving space if you haveDASD archiving. Most of this space can be reclaimed when SAP BW on DB2for OS/390 is up and running.

Additionally, when you aggregate, you need a large temporary DB2 database(DSNDB07). You should prepare this temporary database beforeaggregation. Most of this space can be claimed after the aggregationprocess.

3.3.5 Configuring OSA-2 on the database server

The OSA-2 feature from the database server can be connected to the FDDInetwork as shown in Figure 8.

MVS/ESA Hardware Configuration Definition: User’s Guide, SC33-6468

Reference


Figure 8. I/O configuration for the FDDI connection

See SAP R/3 Connectivity Guide, SC33-8965, for details on how to installand configure the OSA-2 adapter.

3.3.6 Installing DB2 for OS/390

The DB2 for OS/390 product must have been installed prior to the SAP BWon DB2 for OS/390 installation.

After completing the SMP/E installation of the DB2 for OS/390 product, wecontinued with the setup of DB2 for OS/390 parameters by considering therecommended values given by SAP. For detailed information about DB2preparation, refer to Chapter 4, “Preparing DB2” on page 47.

F DDI R ing

O S/390 IP =10.1.1.212C HP ID=0 C

22C0

22C4 22 C5

O SA -2 Featu re

FDD I L AN

FD DI Ada pter

A IX or W in dows NT

IP=10.1.1.73

O SA -2 C on tro l Un itNum ber

O SA -2 D evice N um bers Un itAddresses 00 /01


• DB2 for OS/390 V5 Installation Guide, GC26-9008

• BC SAP Database Administration Guide: DB2 for OS/390, MaterialNumber: 51006377

References


3.3.7 Configuring SMS

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 diskto be managed by SMS.

With the SAP BW application, there a large number of DB2 tablespaces andindexes. We therefore strongly recommend that you use SMS-managedstorage for SAP BW data sets efficiently. This will significantly reduce theamount of work you have to do to define DB2 Objects.

3.3.8 Customizing OS/390 UNIX

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 stepsdescribed in OS/390 UNIX System Services Planning.

In our case, we used Standard TCP/IP connectivity over FDDI for theapplication server-to-database server communications.

3.3.9 Customizing TCP/IP on the database server

• 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

References

OS/390 UNIX System Service Planning, SC28-1890

Reference

OS/390 SecureWay Communications Server: IP Configuration, SC31-8513

Reference


For successful ICLI server and client communication, the ICLI server mustknow which port to monitor for ICLI client connection requests. There arethree 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, inthe <TCPIP>.ETC.SERVICE file, or in <ICLI user ID>.ETC.SERVICES.These files are interrogated in the order listed if the SERVICENAME orPORT is not specified as an argument to the fome45bs command.

2. Specify the ICLI connection port via the SERVICENAME argument of thefome45bs command. This will be used to interrogate the file(s) listed inoption 1. The files will be searched in the order listed for a matchingservice name.

3. Specify the ICLI connection port via the PORT argument of the fome45bs

command. This will override any port number derived from a servicename.

We recommend that you use the first method, except when you are runningmultiple ICLI servers in the same OS/390 LPAR. See Chapter 9 in SAP R/3on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B for details. Theredbook team used the third method.

3.3.9.1 Service name and port entriesThe connection port used by ICLI and by ICLI keep-alive can be chosenfreely from the available services. The values must match the specification inthe services file and TPPARAM on the central instance.

In our environment, we chose 33666 as the ICLI connection port, and 33667as the ICLI keep-alive connection port. Note that the keep-alive port numberis not necessary when using TCP/IP. We used the PORT argument of thefome45bs command to tell the ICLI server which port to monitor for ICLI clientconnection 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

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 byR3SETUP during the central instance installation. For more information, seeChapter 4, “Preparing DB2” on page 47.

3.3.10.1 Define the Environment FileFollowing 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.

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 beginrunning the system, you set the ICLI_TRACE_LEVEL to 0 to reduce thestorage space requirement of the OS/390 UNIX HFS and provide betterperformance.

3.3.10.2 Define the startup JCLYou can use the started task technique to start ICLI. The ICLI started taskJCL 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, calledICLIBLU, that we used.

SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B,

Reference

TRACE=1ICLI_TRACE_LEVEL=0ICLI_MSGLEVEL=IICLI_TRUSTED_CONNECTIONS=1NLSPATH=/usr/lib/nls/msg/%L/$HSTEPLIB=DSN610.SDSNLOAD


Figure 10. ICLI started procedure

You can use a copy of the file /u/bluadm/iclitask.jcl (where bluadm is SAPadministrator’s ID) and adapt it to your needs. Remember to specify -TCP forthe protocol in use.

Note that it is possible to use //STDENV DD * and specify variables within thisJCL stream. Some installations have found this to be convenient.

3.3.11 Customizing RACF or equivalent

The following definitions should be established when you configure thesecurity using RACF or equivalent:

• User definition• OS/390 UNIX facility• Started task protection

//*********************************************************************//* *//* *//* 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=*

• 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

References


3.3.11.1 User definitionThe 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 areas follows:

Note that ICLIBLU is defined as an OS/390 UNIX user. The superuser hasUID(0), and can bypass all file security, as well as run any administrativecommands.

3.3.11.2 The OS/390 UNIX facilityOS/390 UNIX uses a new RACF class, FACILITY, and the FACILITY classprofile BPX.DAEMON. If they are not defined on your system, they can bedefined with the following statements:

We created an OS/390 UNIX user ICLIBLU and granted it the class profile fordaemon administration, BPX.DAEMON, as can be seen in the followingRACF statements:

3.3.11.3 ICLI started taskWe used the RACF STARTED class to associate the ICLIBLU user ID withthe ICLI started task. When the ICLI procedure is started at the console, itruns as the ICLIBLU user.

ADDGROUP OMVSGRP OMVS(GID(1))ADDUSER ICLIBLU DFLTGRP(OMVSGRP) OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))

RDEFINE FACILITY BPX.DAEMON UACC(NONE)SETROPTS CLASSACT(FACILITY)SETROPTS RACLIST(FACILITY)

PERMIT BPX.DAEMON CLASS(FACILITY) ID(ICLIBLU) ACCESS(READ)SETROPTS RACLIST(FACILITY) REFRESH


3.3.12 Set OS/390 dispatching and I/O prioritiesFor information concerning OS/390 dispatching and I/O priorities refer toChapter 7 in SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release4.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 workthreads using WLM, we did the following:

• We defined the BPX.WLMSERVER profile in RACF:

• We gave ICLIBLU user ID read access to this profile:

• We refreshed the access lists to put the changes into effect:

• We added a new WLM subsystem with the name SAP. To do this, westarted the ISPF application of WLM, chose option 6 (classification rules),and used option 1 to create a new subsystem. The following entries weremade in this subsystem definition:

RDEFINE STARTED ICLI.* STDATA(USER(ICLIBLU),GROUP(OMVSGRP))SETROPTS RACLIST(STARTED) REFRESH

RDEFINE FACILITY BPX.WLMSERVER

PERMIT BPX.WLMSERVER ACCESS(READ) CLASS(FACILITY) ID(ICLIBLU)

SETROPTS CLASSACT(FACILITY) REFRESH


3.3.13 Customizing TCP/IP on the central instance

On the central instance, we modified the /etc/hosts file. The R3SETUP tooladds 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 fileWe added the following entries to the /etc/hosts file:

Subsystem-Type Xref Notes Options Help--------------------------------------------------------------------------

Modify Rules for the Subsystem Type Row 1 to 7 of 7Command ===> ____________________________________________ 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 ruleB=Before D=Delete row R=Repeat IS=Insert Sub-rule

More ===>-------Qualifier------------- -------Class--------

Action Type Name Start Service ReportDEFAULTS: 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 ________

• Installation of the SAP Business Information Warehouse on UNIX DB2for OS/390, Material Number 51007613



References


3.3.13.2 Services fileR3SETUP adds the following entries to the /etc/services file:

# SAP specific servicessapdp00 3200/tcp # SAP R/3 dispatcher port

| |v v

sapdp99 3299/tcpsapgw00 3300/tcp # SAP R/3 gateway port

| |v V

sapgw99 3399/tcpsapmsBLU 3600/tcp # SAP R/3 message server port# ICLI specific servicessapdb2BLU 33377/tcp # ICLI porticlikaBLU 33378/tcp # ICLI Keep Alive Port

10.1.1.212 wtsc62f #OS/390 address by UDP from AIX10.1.1.73 erprisc1 #AIX address by UDP from OS/390


3.3.14 Setting up the ICLI client

The ICLI client code is provided in the OS/390 PTF containing the ICLIserver. The executables FOME45BA(client) and FOME45BK(keep alive) canbe found in the <HLQ>.SFOMDATA, where HLQ is the High Level Qualifierfor your UNIX System Services data sets. R3SETUP will download these tothe /sapmnt/<SAPSID>/exe directory and rename FOME45BA to ibmiclic.oand FOME45BK to ibmiclika.

3.3.14.1 ICLI client codeThe ICLI client code is downloaded by R3SETUP from the OS/390 systemduring the installation of the central instance.

If the ICLI server on the OS/390 system is changed, you will have to manuallytransfer the members FOME<REL>A and FOME<REL>K from the OS/390SYS1.SFOMDATA data set to the central instance. Rename FOME<REL>Ato 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).

3.3.15 Testing connectivity -- central instance and database serverThe connectivity between the database server and the central instance canbe tested by using the ping command from the central instance and opingfrom the database server.

To test TCPIP protocol, we performed these commands:

• From the central instance:

ping 10.1.1.212



References

• <sapsid> is the SAP system name in lowercase.

• <SAPSID> is the SAP system name in uppercase.

Notes


• 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 connectivitybetween the database server and the central instance has been established.

3.4 Installing SAP BW on DB2 for OS/390

This section describes the steps we performed during the installation of SAPBW.

3.4.1 General notes on the installation from AIXWith SAP R/3 4.5B, the installation tool is called R3SETUP. It has a realgraphical interface, the INSTGUI, which provides a more comfortable lookand feel. It also provides integrated help documentation and the ability toview 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 longeruses script files CENTRAL.SH, DATABASE.SH, DBDROP.SH, andDIALOG.SH.

SAP R/3 now uses script file INSTTOOL.SH to create command filesdesigned 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 executedfrom the installation work directory:

/<kernel-cd>/UNIX/INSTTOOL.SH

3.4.2 Hints and tips -- installing with AIX1. 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 of the SAP Business Information Warehouse on UNIX DB2for OS/390, Material Number 51007613


References


installation work directory when running INSTTOOL.SH. Thisdocumentation is HTML-based and can be viewed and printed with anyWeb browser.

2. Make sure that the worksheet has been prepared before executing theinstallation shell script and R3SETUP.

3. If you make a mistake in typing an answer during the build process of thecommand file, re-execute the build process from the beginning. One wayto do this is to rename the current command file, CENTRAL.R3S forexample. Then rename the initial command file CENTRAL.R3S.1 toCENTRAL.R3S.

4. The command file will be updated by the R3SETUP program during theinstall process.

5. To use the INSTGUI tool, you will need either Windows 95 or NT, or Motifinstalled on an AIX system.

6. To view the R3SETUP documentation and help files, you will need abrowser that supports frames, such as Netscape.

7. The first time you start the R3SETUP program, it will ask if you want to usethe graphical installation tool. If you answer Yes, it will start INSTGUI foryou.

8. When you later need to restart the installation process, the INSTGUIprogram must be started before the R3SETUP program. The R3SETUPprogram must then be started with the following options:

9. Every time R3SETUP is restarted, it will copy the log from the last run to adifferent file. The current log file will always have the name <commandfile>.log, while the old log is named <command file>.log.<number>. Thefile 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 byINSTGUI are accumulated from the previous failed R3SETUP runs. It canbe difficult to determine which errors occurred in the current execution ofR3SETUP if you do not restart INSTGUI also.

11.The percentage indication on the INSTGUI does not show the percentageof the actual work completed in hours. Instead, it shows the percentage ofsteps completed.

R3SETUP -f <command file> -g <x-term_address>:61312


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

The SAP BW on DB2 for OS/390 installation can only be started if thenetwork connection has been established between the database server andthe central instance. Refer to 3.3.15, “Testing connectivity -- central instanceand 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.

• Installation of the SAP Business Information Warehouse on UNIX DB2for OS/390, Material Number: 51007613

Reference


Chapter 4. Preparing DB2

This chapter describes the tasks you must perform to prepare the DB2system for the SAP Business Information Warehouse (BW) application. Mostrecommendations for the DB2 for SAP BW application are the same as forSAP 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

The SAP BW system has its own structure of DB2 objects, such as a largenumber of databases, tablespaces, and so on. Therefore, prior to installingSAP BW code, you need to prepare your DB2 system to manipulate thoseDB2 objects effectively.

4.2 Prerequisites of DB2

DB2 UDB for OS/390 Version 6 is a prerequisite for the SAP BW applicationbecause 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 allrequired DB2 PTFs for SAP BW are applied to your DB2 system. Check theDB2 PTFs in SAP Note 81737 and recent SAP Notes for possiblemaintenance.

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


4.3 OS/390 setup for DB2

From an OS/390 perspective, these two items should be considered beforeinstalling the SAP BW code.

Large VTOCThe SAP BW installation includes a very large number of data sets. It istherefore recommended that you initialize the volumes that are associatedwith the DB2 storage groups with a large VTOC that is at least 250 tracks ona 3390 DASD unit for BW application. (For SAP R/3 applications, 400 tracksare recommended.) Refer to SAP BW installation documentation for moreinformation.

Separate VSAM user catalogWith regard to the VSAM catalog size of the SAP BW data sets, werecommend that you create a separate user catalog with a size of 20cylinders 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 catalogof the DB2 subsystem, make sure that it is large enough to hold all theinformation 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 kernel4.5B) exploits the Recoverable Resource Manager Service AttachmentFacility (RRSAF). The RRSAF is a DB2 attachment facility that relies on anOS/390 component called OS/390 Transaction Management andRecoverable Resource Manager Services (OS/390 RRS). OS/390 RRSprovides system-wide services for coordinating two-phase commit operationsacross OS/390 products.

Note that if you have already installed SAP R/3 4.5B, there is no extra setupfor 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/390system administrator.

4.5 Customizing DB2 parameters

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


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

Required DB2 system parametersTable 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)

Recommended DB2 system parametersThe recommended DB2 parameters are also listed under SAP R/3 on DB2 forOS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964.

Invalid parameters in DB2 V6The following parameters are no longer valid in DB2 Version 6:

• ALPOOLX

• INBUFF

• OJPERFEH

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 andindexes.

NUMLKUS 0 Zero (0) means there is no limit to the number of pageand 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 inDSNHDECP.

SMFSTAT 1,3 Class 1 provides information about system services anddatabase statistics.Class 3 provides information about deadlocks andtime-outs.SMF record type 102 should be defined.

DECARTH DEC15 It does not allow a precision greater than 15 digits.

DECIMAL . (period)

Chapter 4. Preparing DB2 49

Recommended IRLM parametersThese values are defined in the IRLM start procedure:

Table 14. Highly recommended IRLM parameters

Bufferpools allocationTable 15 shows the recommended DB2 bufferpool settings for SAP BWtablespaces, indexes, work files, and DB2 system databases.

Table 15. Recommended DB2 bufferpool allocation

We recommend that you allocate BP0 as 5000 because the SAP BWapplication uses dynamic SQL, and because a large number of DB2 objectswill be created.

4.6 DB2 system database requirements

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

Parameter Value Recommended value

PC Yes Yes puts the lock control block structure in the IRLMprivate address space, and the program call instructionis 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 mustexpire before the IRLM performs global deadlockdetection processing. This is used only for data sharing.

Buffer pool VPSIZE VPSEQT DWQT VDWQT HPSIZE HPSEQT CASTOUT

BP0 (system) 5,000 50 50 10 0

BP1(work files)

5,000 100 70 50 0

BP2 (4 KBtablespaces)

20,000 50 30 5 40,000 50 YES

BP3 (indexspaces)

30,000 40 30 5 60,000 40 YES

BP4 (VBprotocol)

1,000 10 70 50 0

BP32K(tablespaces)

2,000 50 30 5 4,000 50 YES


4.6.1 DB2 catalog and directory database sizeIn the installation process of SAP BW, a large number of DB2 objects arecreated as shown Table 12 on page 47. This requires a larger catalog anddirectory database than the default size. Table 16 shows the recommendedvalues for DB2 installation panel DSNTPID, which generate a job that createsVSAM data sets for the DB2 catalog and directory database.

For SAP BW applications, we recommend you refer to these values toestimate the size of the DB2 catalog and directory database as well as thesize of main storage. When you are building a new DB2 system for an SAPBW application, you should use the values in Table 16 for DB2 the installationpanel 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 indexesAdditional DB2 indexes against the DB2 catalog and directory are createdduring execution of R3SETUP as shown in Table 17. You must ensure thatsome DASD space is available in the volumes of the DB2 SYSDEFLT storagegroup prior to execution of R3SETUP.

Table 17. New indexes created against the DB2 catalog tables during R3SETUP

4.7 Preparing the DB2 log

Good performance of DB2 logging is very important because the SAP BWinstallation executes heavy Data Definition Language (DDL), insert, update,and delete activity. During SAP BW installation, a large number of DB2 tablesare created and a large number of rows are inserted, which causes a hugenumber of DB2 log records.

In order to run the installation process effectively, we recommend thefollowing:

• Create multiple (more than three) and large DB2 active log data sets totolerate up to 2 GB per hour. We recommend that you have an entire 3390volume available to use for a DB2 log data set. If you encounter a log dataset shortage, R3SETUP will be abended.

During the installation process for SAP BW, more than 6 GB of DB2 logrecords are generated. We recommend that you allocate at least 10 GB ofDASD for a DB2 active log data. (With dual logging, you need double thisamount.)

In case you do not have enough DASD volumes for DB2 log, you probablycould get at least four DB2 log data sets as shown in Figure 11 on page 53with tape archiving.

When a log data set DS01 is filled, log data set DS02 takes it over. Youcan 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 totape, and so on.

Index creator Index name Table name

SAPR3 SYSTABLE~0 SYSTABLES

SAPR3 SYSTBLSP~0 SYSTABLESPACE


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 highlyactive 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 bindsthe default plan FOMEP45B for the ICLI server. Although it is not necessaryto use a plan name other than the default plan name, it is useful to havedifferent 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 binda plan by modifying and submitting a sample job FOME45BB, and authorizethe plan and other DB2 objects by submitting a sample job FOME45BG. Twojobs are located in SYS1.SAMPLIB. For more information about DB2 tasks forthe ICLI server, refer to SAP R/3 on DB2 for OS/390: Planning Guide SAPR/3 Release 4.5B, SC33-7964.

DS01

DS03

DS02

DS04

DS01

DS03

DS02

DS04

LOGCOPY 2LOGCOPY 1


4.9 DB2 authorizations

In this section, we summarize the required DB2 authorization you need toimplement in order to avoid the errors that can occur during the SAP BWinstallation process. Most privileges are automatically granted in the processof R3SETUP.

Table 18. DB2 authorization

R3SETUP creates the bind and grant JCL with defaults, provides anopportunity to modify the defaults, and then submits the jobs. If you look atmember SYS1.SAMPLIB(FOME45BG), you will see what kind of privilegesand authorizations are granted during the installation process. Do not changethe original job because the R3SETUP installation step needs the originalversion of the job. Instead, adapt a copy of the FOME45BG job to yourrequirements.

4.10 Maintaining DB2 catalog statistics

This section describes the maintenance of DB2 catalog table statistics, whichsignificantly affects the elapsed time of analytical queries. With poor DB2catalog information, your query could run up to 50 times longer. Updatingcatalog statistics should be done after loading data into the BW database.

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

User ID DB2 authority Remarks

SAPR3 SYSADM Some privileges are granted duringR3SETUP automatically.But we recommend you grant SAPR3 asDB2 SYSADM.

ICLIRUN Execute on planFOMEP45B andTRACE, MONITOR1,MONITOR2

These are granted during R3SETUPautomatically. If you use different a user IDunder which the ICLI Server runs, you haveto grant the required privileges to the newuser ID manually.


At maintenance (delta update or aggregation)Sometimes the SAP BW system generates new DB2 objects that did not existat data loading, delta updating, and so on. However, DB2 databaseadministrators may not notice this, and therefore, they may not run theRUNSTATS utility for these new objects. This can result in the DB2 optimizerbuilding less than optimal access paths with old statistical information aboutthe data when you run analytical queries.

To avoid this situation, we strongly recommend that you build proceduresusing REXX, COBOL, or any other language that builds RUNSTATS jobs byquerying the DB2 catalog.

4.10.2 Updating DB2 catalog statistics manuallyBecause many SAP BW tables start empty and grow very rapidly, for eachOLAP query against InfoCube, a tablespace scan should be avoided even fora small or empty table, if there is an index that has at least one matchingcolumn for a given SQL statement’s predicates.

Therefore, if you use DB2 Version 5, we recommend that after eachRUNSTATS job, you always perform this set of catalog updates as shown inFigure 12 on page 56. These SQL statements update DB2 cataloginformation for small tables or empty tables. Of course, if RUNSTATS was runfor few tables only, then it is reasonable to do the updates for those tablesonly by specifying database name, tablespace name and/or table namerespectively.

If you use DB2 Version 6, set new DSNZPARM parameter NPGTHRSH=10 toget the same result. You need DB2 APAR PQ33429 for this. For moreinformation, refer to OSS note 192320.


Figure 12. An example of DB2 catalog updates

4.10.3 Maintaining catalog statistics for R/3 cluster tablesThis task is also needed for the SAP BW database; refer to SAP OSS note83335.

In DB2 for OS/390, the R/3 cluster tables need to be accessed in a specialway: the access path should match the index scan, with the matchingcolumns corresponding to the physical cluster’s key columns, and neither sortnor list prefetch should be selected. If the tables are not accessed in this way,there is a possibility of increased lock contention (including deadlocks).

UPDATE SYSIBM.SYSTABLESSET CARDF=50, NPAGES=10WHERE CREATOR = 'SAPR3' AND TYPE='T' AND NPAGES <= 10;

UPDATE SYSIBM.SYSTABLESPACESET NACTIVE=10WHERE CREATOR = 'SAPR3' AND NACTIVE <= 10;

UPDATE SYSIBM.SYSTABSTATSSET CARD=50, NPAGES=10WHERE OWNER = 'SAPR3' AND TSNAME IN

(SELECT NAME FROM SYSIBM.SYSTABLESPACEWHERE CREATOR='SAPR3' AND NACTIVE <= 10) ;

UPDATE SYSIBM.SYSINDEXESSET CLUSTERRATIO=0,FIRSTKEYCARDF=-1, FULLKEYCARDF=-1, NLEAF=-1, NLEVELS=-1

WHERE TBCREATOR = 'SAPR3' AND TBNAME IN(SELECT NAME FROM SYSIBM.SYSTABLESWHERE CREATOR='SAPR3' AND TYPE='T' AND NPAGES <= 10) ;

UPDATE SYSIBM.SYSCOLUMNSSET COLCARDF=-1, HIGH2KEY='', LOW2KEY=''WHERE TBCREATOR='SAPR3' AND TBNAME IN

(SELECT NAME FROM SYSIBM.SYSTABLES WHERE NPAGES <= 10);

DELETE FROM SYSIBM.SYSCOLDISTWHERE TBOWNER = 'SAPR3' AND TBNAME IN

(SELECT NAME FROM SYSIBM.SYSTABLESWHERE CREATOR='SAPR3' AND TYPE='T' AND NPAGES <= 10) ;


In order to ensure that the cluster tables are accessed properly the catalogstatistics for the cluster tables need to be maintained as shown Figure 13.

Figure 13. Sample SQL statements for updating catalog statistics for cluster tables

If deadlocks occur even after catalog update, consider further updates asshown in Figure 14.

Figure 14. Sample SQL statements to avoid deadlock

Monitor your system carefully in order to detect if these catalog changesadversely affect some access paths on the cluster tables.

We recommend that you refer to the latest documentation of SAP; it isavailable as PDF files at:

http://www.s390.ibm.com/os390/bkserv/latest.html

update sysibm.systablesset npages=100, cardf=1000where creator='SAPR3' and name in (select tabname from sapr3.ddnttwhere tabform='T' and tabtype='C' with ur) ;

update sysibm.sysindexesset clusterratio=100, fullkeycardf=1000where tbcreator='SAPR3' and uniquerule='P'and tbname in (select tabname from sapr3.ddnttwhere tabform='T' and tabtype='C' with ur) ;

update sysibm.sysindexesset clusterratio=100, firstkeycardf=1000,fullkeycardf=1000where tbcreator='SAPR3' and uniquerule='P'and tbname in (select tabname from sapr3.ddnttwhere tabform='T' and tabtype='C' ) ;

update sysibm.syscolumnsset colcardf=1000where tbcreator='SAPR3' and keyseq=1 andand tbname in (select tabname from sapr3.ddnttwhere tabform='T' and tabtype='C' ) ;


4.11 Post-installation tasks

After SAP BW installation, you need to monitor the DB2 system and preparesome post-installation tasks prior to further tests and production running.

4.11.1 ReorganizationAfter 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 100extents), because the secondary space defined by SAP is too small.Therefore, we recommend that you run the DB2 reorganization utility forthose indexes (or data sets) in order to achieve better extent managementand to prevent possible extension errors.

4.11.2 DB2 temporary database (DSNDB07)Aggregation is the process of summarizing detailed level data in InfoCubehorizontally, vertically and chronologically. It executes complex SQLs, whichneed 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 youaggregate. We recommend that you estimate it with your SAP BW consultantbefore 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 SAPBW 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 nearlyidentical to the installation of SAP R/3. Following the processes outlined inthis chapter will allow you to accomplish your installation in the shortestpossible time.

The process begins with the gathering of data to support your BW installationactivities, then moves into a checkout of your system, and then to thedocumentation of required installation parameters.

When you have all of the required information at hand, the BW installation isthen described in some detail. After the data has been loaded into the systemyou will follow the post-installation process, and finally proceed to theinstallation of the R/3 PlugIn (previously known as Business Content) intoyour SAP R/3 system (if you are connecting to an SAP R/3 source system). Ifyou are connecting your SAP BW system to a non-R/3 system, the businesscontent/extractor provider or possibly the implementation partner will providethe instructions and software necessary to install that component.

The runtime durations experienced by the SAP BW redbook team for eachmajor step of the installation are contained in Table 19 on page 60 and do notaccount for the time between steps where we analyzed the system or let it sitwhile we worked on other activities. (Your run times may vary, depending onnetwork implementation, available hardware, and frequency of problemsencountered.)


Table 19. Installation activities and runtime durations

5.2 SAP BW pre-installation: data gathering

The first step toward a successful implementation of SAP BW on DB2 forOS/390 is to gather all of the information that will be needed during theinstallation, and to have it available in both softcopy and hardcopy formats.We found it very easy to include the softcopy data into our projectdocumentation, and the hardcopy printouts were quite valuable during theactual installation activities for immediate reference and note taking.

It is worth noting that it will be impossible to correctly install the softwarewithout obtaining and applying the collected reference material prior to actualinstallation activities.

5.2.1 Gathering the SAP notes via SAPNet R/3 FrontendThe SAP notes provide input important to the scheduling of installationactivities, which if ignored usually result in an incomplete system that willsoon be deleted. Some of the notes used by the redbook installation team arelisted in Table 20. Your installation project will have to gather the applicablenotes that are available at the time of your particular installation - the notesare being updated very regularly and new notes can be created at any time.

Table 20. SAPNet R/3 Frontend Notes

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

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


5.2.2 Searching for SAP notesWe searched for SAP notes based on the following criteria and updated ourproject plan for the additional activities:

• BW-SYS-DB-DB2

• BW.SYS-DB-DB2

• BW-DB-DB2

• BW

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 orNT

Note 175534 Large BW Systems and Performance of Aggregatebuild

Note 176616 BW Statistics

Note 178376 Problems w/ user exit variables with BW12B patch12

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

Reference item Reference item description

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

5.2.3 Downloading patches and other information from SAPSERVxThe latest SAP code patches and fixes are available via anonymous ftp fordownload 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 documentationFollowing is the documentation downloaded from SAPNet R/3 Frontend:

• Checklist: installation requirements - SAP Material Number 51005873


• SAP R/3 on DB2 for OS/390: Connectivity Guide, SC33-7965

• Installation of the SAP Business Information Warehouse on UNIX DB2 forOS/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 Number51007713

• R/3 Add-On Installation and Delta-Upgrade Guide, Release 4.5B, MaterialNumber 51006041

5.3 SAP BW pre-installation: system check

Now it is time to take the information gathered in 5.2, “SAP BWpre-installation: data gathering” on page 60 and apply the recommendationsto your system where appropriate, and to set aside any instructions that youwill need later in the installation process. It is also time to verify that the basecomponents of your database server and application servers are ready tosupport the installation of SAP BW OS/390 with DB2.

You should have already installed and configured the base components of thesolution by this point in time. These would include the software on the S/390Database Server (OS/390, OS/390 UNIX, TCPIP, JES, DB2) and the software


on the AIX or NT Application Server (AIX, TCPIP, NFS/mounts, etc.). Theinformation necessary to configure these components is found in:



• R/3 Installation on UNIX OS Dependencies, Material Number 51005979

In addition, the manual R/3 Installation on UNIX DB2 for OS390, Release4.5B, Material Number 51006375 may prove to be useful since installing SAPR/3 is nearly identical to installing SAP BW.

We found that R3SETUP looks for adequate free disk space during theinstallation, and we were forced to make the changes before continuing withR3SETUP. The file system sizes we used for the redbook project arecontained in Table 21:

Table 21. AIX file system layout

At this time you should verify that all software maintenance is current or atleast equal to the minimum information contained in Note 81737. Alwaysobtain the most recent copy of Note 81737, as the information changesregularly.

Don’t forget to install the German language fileset on the AIX ApplicationServer. While we have not been able to find a written requirement for this, wehave found nonetheless that it is necessary. You can check this with the AIXcommand locale -a, and then look for the two languages in Table 22.

Table 22. AIX language filesets

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

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 BWpre-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 ofthe information necessary to answer the installation script questionscontained in Table 23. Table 23 shows you the parameters you will need tospecify to R3SETUP and the values we used for the redbook project, and italso 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 installationdirectory

/tmp/install

SAP BW global directory sapmnt/BLU/exe

SAP BW CD-ROM location(on application server)

/sapcd

Message Server portnumber(3600 + SAP system #)

3600

R/2 Gateway no

Sysplex Failover(yes or no)

no

Sysplex FailoverHostname

Sysplex Failover Port #

Pass Tickets(yes or no)

no

DB2 subsystem name DBH1

DB2 Group Attach name

DBServer hostname -OS/390 UNIX

wtsc62oe


It is also necessary to know how to code a jobcard for a batch job. If you donot know the format of your organization’s job card, ask your systemprogrammer to print you a hardcopy.

The final preparation activity is to draw a diagram of your entire SAP BWenvironment. Such a diagram is useful to refer to both during R3SETUP and

DBServer hostname - FTP& Telnet

wtsc62

DB2 plan name for ICLIserver

FOMEP45B

DB2 load library name DSN610.LOADLIB

DB2 runlib library name DB2V6H1.RUNLIB

DB2 Usercat name for BWdata

SAPBW

JES held job class X

ICLI port number 33377

User ID for ICLI Server ICLIBLU

User ID for ftp to OS/390(uid=0 & DB2 sysadm)

BLUADM

OS/390 ICLI code location SYS1.FOMEDATA

SAPOSCOL install(yes for now, no for later)

no

SAPOSCOL destination(RFC destination name)

BWBLU

SAPOSCOL gw host(hostname gw service runson)

erprisc1

SAPOSCOL gw service(from /etc/services)

sapgw00

SAPOSCOL codedirectory in OS/390 OpenEdition(any OS/390 UNIXdirectory)

/u/<sid>/SAPOSCOL

R3SETUP variable name Our value Your value


later as a record of your installation. If feasible, ask the project team to reviewit; 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 identicalto 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 whereto turn if you should encounter problems during installation. In addition, donot forget about the files that can be used for debugging (and the parametersthat turn them on and off). Some of these files are listed in Table 24.

Table 24. Debugging file and locations

5.5.1 Starting BW installationDo not start this activity until you have obtained the values for yourinstallation, as noted in Table 23 on page 64, to use as input to R3SETUP.

Use the instructions contained in Installation of the SAP Business InformationWarehouse on UNIX DB2 for OS/390, Release 1.2B SR-1, 51007613.Additionally, you may want to reference the latest version of the R/3installation guide, R/3 Installation on UNIX DB2 for OS/390, 51006375. Payclose attention to the spelling and capitalization of commands and responses.

The command we entered to start the SAP BW Central Instance ApplicationServer installation was:

./R3SETUP -f CENTRAL.R3S

Filename Created by/location

ICLItrace.<pid>.xxx See environment variableICLI_TRACE_LEVEL

ICLI stderr & stdout See ICLI STC or script

OS/390 SYSLOG SDSF


The command we entered to start the SAP BW Database Server installationwas:

./R3SETUP -f DBBW.R3S

Keep in mind that the installation of SAP products via R3SETUP andINSTGUI is an interactive and iterative process. The GUI interface providedby SAP prompts you to enter installation configuration information, and willprobably be stopped and restarted several times. Don’t get frustrated if thishappens more than you expected. It merely suggests that you probably couldhave spent more time preparing for the installation. Additionally, there are afew tips in 5.5.4, “R3SETUP problem solving” on page 68 to help you with thistask.

5.5.2 Building the BW databaseYou will eventually see the R3SETUP/INSTGUI messages indicating that theSAP BW database is being built. The DDL required to create the DB2 objectsis being executed, and you will have DB2 storage groups, databases, andtablespaces 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 databaseThe database load is more CPU-intensive than previous installation steps.This is because the DB2 database is being loaded with data via INSERT SQLstatements 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 isrunning as a productive environment, the majority of resource consumptionwill be attributed to the ICLI server task.

There are some steps that will automatically execute after the data is actuallyloaded into DB2, and then you will be prompted to check the JCL andcommand syntax that was created for the five DB2 RUNSTATS jobs. Checkthese jobs for accuracy and either allow the system to try to run automaticallyor EXIT R3SETUP and run them manually (don’t forget to update theR3SETUP control file with STATUS=OK if you run them manually).

R3SETUP will then perform some more steps on your behalf and without yourintervention, until you see the message:

./R3SETUP finished.


Note: SAP recommends that you do not modify the installation log filesunless you know exactly what you are doing. Be sure that you arecomfortable performing a reinstallation from the beginning if you shouldhappen to do this incorrectly or inadvertently.

5.5.4 R3SETUP problem solvingWe have provided a few problem-solving hints in Table 25 that may help you ifyou should encounter problems during R3SETUP. However, it is expected thatyou will have a certified SAP installer onsite to perform your installation. Asalways, do not forget to make use of SAPNet R/3 Frontend to search for thelatest 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.R3Se.g. ./R3SETUP -f DBBW.R3S)

INSTGUI doesn’t work Find someone familiar with exporting thedisplay.See if you can run without the INSTGUI.

Connection to DB2 doesn’t work Was the DECHDECP module linked with all ofthe 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 theSAP R/3 on DB2 for OS/390: Planning GuideSAP 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 returncode problems

Ftp the jobs to OS/390 and manually run themfrom there. Don’t forget to update the STATUSfield 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 assistand request customer IDs.

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


5.6 SAP BW post installation: completing the install

Update the profile files (located in /usr/sap/<SID>/SYS/profile/) with therecommended values from SAP and the pertinent values for your site. Theparameters in Table 26 were set for our environment.

Table 26. R/3 Profile parameter changes.

Stop SAP BW and restart it to activate your profile changes.

Initialize the transport environment via SE06 and STMS. SAP providesinformation on how to do this in the online documentation CD-ROM. Log onas SAP* & Client 000 and use transaction SE06 to initialize your SAP BWenvironment as a single system environment (or multi, if you know yourlandscape). Activate your system via transaction STMS.

Apply the SPAM update that is available for your SAP BW 1.2B BASIS kernellevel (ours was 4.5B). At this point you are able to apply the mandatorytransports that are described in the SAP Notes. Start the application of SAPBW Support Patches. Since our version of SAP BW was 1.2B with SR1, thenext Support Patch to be added started with number nine and ended with

Not sure what the problem is Check OS/390 UNIX file systems (df -k).Check AIX file systems (df -k).

SAPGUI - incorrect installationmessage

Check contents of table INSTVERS; if there aretwo rows with the same timestamp, change thesecond entry timestamp to be 1 second later;save your changes.

SAPGUI - screen SAPMSYST inGerman

Check SAPNet R/3 Frontend for notes.

Profile parameters Values

<SID>/system_language=E Set default language to English.

start_menu=RS00 Set default start menu to SAP BWAdministrator 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.

Problem encountered Possible solution


number seventeen. You can check the level of SPAM and applied SupportPackages on your system via transaction SPAM.

Fill out the paperwork to request a license from SAP. This takes only a fewminutes and is best done as soon as possible. Fax the form to the SAPnumber that is pre-printed on the form. SAP is quite speedy and will probablyhave a response to your license request within 24 hours.

Start a client copy of client 000 to client 100, and choose the profileSAP_ALL.

Now it’s time to run backups. Create JCL to perform OS/390 Full VolumeDumps of all volumes, and also scheduled tape backups of your AIXApplication Server.

5.6.1 Summary of the BW databaseA brief summary of the objects created during the installation of SAP BW islisted 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 156DBSL patch number 151


5.6.2 Summary of the SAP R/3 source systemTable 28. SAP R/3 DB2 UDB 6.1 OS/390 database statistics

5.6.3 SAPGUI/BWGUIPrior to installing the SAP Frontend software for PCs and the BusinessExplorer, you have to check the SAPNet R/3 Frontend notes for availablepatches. The patches for Business Explorer will be delivered cumulatively,which is different from the normal patch process. You only have to apply thelatest patch.

To apply a patch means that you have to replace some files on the installationdisk. We recommend that you copy the CD-ROM to a hard disk first and thenreplace the files as described in the SAPNote that refers to the patch. Thenyou may proceed like you would in a normal installation.

Note: You need to select both the SAPGUI and BW Add-ons during theinstallation of the SAPGUI from the presentation CD-ROM.

It is required that you install MS Excel before installing the software forBusiness Explorer. Ensure that all possible options are installed for MS Excel.

5.6.4 BW Patch installationAt installation time there were 17 BW patches for SAP BW 1.2B. The earlyCD-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 BWpatches included, so that will only require the remaining patches to beapplied.

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 number156 with DBSL patch number 151


Be very attentive to notes that refer to BW patch installation. Failure to importthe packages according to the documented procedure will result in manyhours of recovery activities and possibly a reinstallation of the code. Anexample of this is that the SPAM version delivered on the SR1 Release is4.5B/0000. The latest SPAM that we applied updated the SPAM version to4.5B/0004 (and it was the same patch number - SAPKD00027).

The latest Business Explorer patch applied was number nine, and isdescribed 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/3system code has not been modified nor does it coexist with other SAP R/3Add-ons or New Dimension Products; we do not cover the installation of thePI-99 PlugIn at this time.

The installation of the PI-A 99 PlugIn for SAP BW is performed on the SAPR/3 system. The SAP R3up method is utilized for the technical installation,and care is required. Upgrades of SAP BW software via R3up follows thestandard SAP recommendation of first installing it on a non-productionsystem before working on a system that has data or functions you would liketo retain (known as the production system).

It is assumed that the SAP R/3 system is already installed, and merelyrequires the installation of the SAP BW Plugin PI-A 99. If you are connectingyour 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 NTApplication 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 thanR/3, see your software provider and business partners for specific installationinformation.

You must again follow the first five steps at the beginning of this chapter andalso listed here before doing the actual installation of the SAP BW PlugIn -A99. Since the process is the same as for SAP R/3, only an abbreviateddescription 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 gatheringIt is imperative to find as much information as possible to support theinstallation of the SAP BW PlugIn. The first stop should be the SAPNet R/3Frontend, to look for OSS Notes. The next stop should be to look for thespecific installation guide for your particular PlugIn.

Another useful document is the Consultants Guide, ASAP for BWAccelerator; see your SAP business consulting partner if you do not alreadyhave a copy.

5.7.2 PlugIn -A 99 pre-installation: system checkApply any changes requested by the data collected in the previous step.Additionally, ensure that your plan of action has been updated to reflect anyrecommendations for order of processing or for steps that can be added oromitted.

AIX file systems were created to support the installation of the PlugIn. Thespecific file system sizes can be found in Table 29.

Table 29. File system size for PlugIn

5.7.3 PlugIn -A 99 pre-installation: final preparationsObtain a copy of the SAP R/3 pre-installation documentation from your R/3install in case you need to reference any of the specific install data. Ifpossible, it would be useful to have a BASIS-skilled person who was presentfor the SAP R/3 install to assist in the install of the PlugIn. Additionally, it is agood idea to have someone experienced in SAP R/3 upgrades perform theactual console work.

Table 30 shows the PlugIn variables you will need to set and the values weused for the redbook project, and it also has a place to record the values usedduring your installation of the PlugIn.

Table 30. PlugIn variables

PlugIn file systems File system sizes

/tmp/install_plugin 300 MB

/usr/sap/put 300 MB

PlugIn variable name Our value Your value

mode scroll


<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_erprisc2

profile path/name /usrp/sap/WHT/SYS/profileWHT/DVEBMGS01_erprisc2

default profile/name /usr/sap/WHT/SYS/profileDEFAULT.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

PlugIn variable name Our value Your value


5.7.4 PlugIn -A 99 installationSince you will be making a modification to an existing system, you mustensure that you have a complete backup of the R/3 system on which you areabout to install the PlugIn.

Check for any active OP Modes, and disable them according to the PlugIndirections. 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 touse the scroll mode that is available.

After starting the installation, you will be presented with a series of questionsvery 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 eventuallycome to a point where the program will either tell you that all is well and youcan proceed, or that the program found some errors and you need to do someparticular action to resolve the error and then restart the installation of thePlugIn.

If the errors encountered have not been documented by SAP in the OSSnotes, then you will have to enlist the help of an experienced migration andBASIS 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 installationIt is now time to perform any cleanup from errors encountered during theinstallation of the PlugIn, and to complete any remaining steps suggested bythe SAP OSS notes.

At this point, we configured ALE for communication between the SAP R/3system and the SAP BW system.

Since the system we used for the redbook project was not to be used forfurther computing, this was the last step we executed. In the case of aproduction customer system, however, it would now be time to start theadditional customization necessary before turning over a system todevelopers. In particular, there would be immediate customizations in SAPR/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. Forexample, with the SAP BW 1.2B kit we received for this redbook project, wereceived:

• 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 theseCD-ROMs or, at a minimum, keep them in their protective covers inside theinstallation 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 ofinformation 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 BWadministrator’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 associatedindexes, rather than maintaining the indexes during the load. Using theadministrator’s workbench, you have the option of controlling the dropand recreation of indexes against the fact table of the InfoCube duringthe load (or incremental load).

b. You also have the choice to recreate the indexes unconnected to anyload activity.

This is done with normal SQL.

2. Maintaining statistics for the fact table

a. The DB2 optimizer needs information about the tables and indexesinvolved in a query. This information has to be gathered if the tablechanged significantly. You have the option of controlling the gatheringof information after the load (or incremental load).

b. You also have the option of running the statistics independent of anyload 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 calltransaction DB2J and choose Password to enter your password).


To run the jobs on OS/390 successfully, you have to adapt some ProfileParameters with the help of transaction DB2J.

For more information, see Chapter 4 in BC SAP Database AdministrationGuide: DB2 for OS/390, 51003810.

Table 33. TP parameters for JCL submitted with FTP out of SAP R/3

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 nodifference to a basic SAP R/3 installation using DB2 on OS/390 as adatabase server. Use the SAP R/3 management tools to perform the followingtasks:

• Space Management

• Statistics

• Backup

• Recovery

SAP R/3 provides you with a tool to monitor the system and a planning toolfor scheduling DB2 tasks such as gathering statistics and taking backups.

Profile Parameters Description

DB2 run library Library that contains DSNTIAD.

MGMTCLAS,STORCLAS,DATACLAS(SMS)

Optional parameters. If not specified, thedefaults of the corresponding SMS ACSroutine are used.

Volume count Overwrites the value defined inDATACLAS, if needed.

Partitioned data set Existing partitioned data set for uploadingOS/390 jobs.

Console -> Console output data set Sequential data set for receiving therequired part of the System Log. It mustexist and will be overwritten by the nextrequest. The format must be:Organization: PSRecord format: VBRecord length: 133Block size: 27930


6.3 DB2 utilities

To be as consistent as possible, use DB2 utilities only for tasks which are notsupported by SAP BW or SAP R/3. For example, you might store the jobs inSAP R/3 and then use transaction DB2J to submit them. For details for theseutilities, see DB2 UDB for OS/390 Utility Guide and Reference Version 6,SC26-9015. For details about using DB2J, see BC SAP DatabaseAdministration Guide: DB2 for OS/390, 51003810.

Note: If you store jobs in the SAP R/3 system, you need to have access tothat 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 inplace. While workstations have to be backed up occasionally after allworkstation software has been installed or upgraded, most of the backupactivities should be done on the server side. Objects that should be backedup include the DB2 databases that hold BW data and the program sourcecode, DB2 packages, etc.

The tables in SAP BW will normally not be updated continuously, but insteadat certain specific times. You can easily exploit this fact and design a rathersimple backup and recovery strategy: just do a backup of the affectedtablespaces by using the appropriate SAP R/3 tools, DB2 utilities, or OS/390tools.

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 BWby using the Customer Info Cube (SD). We performed the following tests inorder to gain experience and insight into performance and managementissues:

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 thefact table.

7.1 Loading the ODS

To load the ODS, we started by going to the administrator workbench andclicking the ODS tabstrip in order to see the ODS catalog.

Before loading the ODS, we changed the storage parameter of the ODS tableto avoid running out of DASD space. The name of the ODS table is/BIC/B<10-digit-number>. Unfortunately, <10-digit-number> is an internalgeneric identifier which the ODS catalog does not show. To identify<10-digit-number> we checked the ODS catalog to find out the technicalname of the appropriate ODS request set (not the one for InfoSource).

Then we used the data browser (transaction SE16) to query table RSTSODSand specify the technical name of the ODS as ODSNAME. The name of theODS table is retrieved in field ODSNAME_TECH of table RSTSODS.

At this point, we used the database utility (transaction SE14) to change thestorage parameter of the ODS table. See R/3 on DB2 for OS/390 DatabaseAdministration Guide for detailed instructions about this task.

To actually load the ODS, we clicked the InfoSources tabstrip at theadministrator workbench and right-clicked the InfoPackage we wanted to loadto get into the InfoPackage Scheduler. (We decided to load the ODS only andupdate the corresponding InfoCube later. Therefore, we clicked the Data


target tabstrip and selected Only ODS.) After clicking the Schedule tabstripwe started the load.

To improve performance we changed the parameter IDocsSize from 10,000to 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 applicationserver 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 meansapplying all defined update rules to transfer the ODS data into the InfoCube.During this process, a large number of insert operations is performed on theInfoCube fact table.

In order to speed up the InfoCube update, we first dropped indexes on thefact table. This can be done using SAP BW features; see 6.1, “Administrator’sworkbench” on page 79.

At the administrator workbench InfoCube panel, we right-clicked ourInfoCube to get to the InfoCube Performance panel. Clicking Delete indexesdrops the indexes on the fact table. The “Delete InfoCube indexes after eachdata load and then recreate” and the “Also delete and then recreate indexeswith each delta upload” options force SAP BW to delete indexes on the facttable before updating the InfoCube and recreating indexes afterwards.

However, as we wanted to update several requests in parallel, we did not usethese options; that is, we unmarked both fields. Instead, we deleted theindexes by clicking Delete indexes and selected Repair indexes after theentire upload was done. We did this because we did not want one update jobto rebuild the indexes while another update job was still active.

After the deletion of the indexes, we went to the ODS panel at theadministrator workbench. The content of the ODS was listed by InfoSources.To see all requests that belong to one InfoSource, the corresponding nodemust be expanded. Only requests that fit user-defined selection criteria aredisplayed. Select Setting --> Display selection for ODS tree to maintainthese criteria.

For every request we wanted to update into the InfoCube, we right-clicked therequest 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 forrebuilding the indexes. We used a dedicated bufferpool in DB2 for the DB2work space

Consider also running these updates in parallel, in which case you shouldswitch off the automatic index rebuild (see Chapter 6, “Managing SAP BWdatabase” on page 79) and start it manually after the updates. You might alsohave 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. Ifthese queries are used frequently, you should think of defining aggregates.Aggregates store data in a summarized form in order to avoid doingcalculations during reporting. See SAP BW documentation for detailedinformation on defining and using aggregates.

At the administrator workbench, we choose the InfoCubes panel andright-clicked our InfoCube in order to switch to the “Maintain InfoCubeaggregates” panel. A list of all defined aggregates was displayed. Weselected 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 notfind any formula to calculate the amount needed. But to give you an idea, wehad roughly twenty million rows in the fact table requiring roughly 5 IBM3390-002 volumes, including all indexes, and assigned 32 IBM 3390-002volumes 4K work spaces to build the aggregates. This is definitely an upperboundary, but we did not get more precise figures.

7.4 .Running queries

Beginning with DB2 Version 6, the query optimizer has a new feature addedcalled Star Join (APAR PQ28813). It is especially designed for queries thatrun against a star schema or extended star schema set of tables.

Star Join can be enabled or disabled with a parameter in DNZPARM. DB2has to be restarted to activate Star Join.

Since the data model of SAP BW is a star schema (see 1.3.3, “BW datastructures” on page 6), we expected query performance improvements. Toconfirm this, we performed some tests.

Chapter 7. Tests performed at ITSO 85

Our observation was that the amount of improvement depends on the numberof selected rows in the fact table. One test case showed no difference inquery performance. However, in another test where we selected roughlytwice as many rows as in the first case, we saw an improvement of one-thirdin runtime.

Keep in mind that Star Join might have an adverse effect on the performanceof 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 anadditional request is updated into the InfoCube. When doing this, however,you have to decide whether or not the indexes of the fact table should bedropped during the update in order to increase insert performance. Forexample, there might be reporting being done on the InfoCube while theupdate is done and indexes deletion might be not feasible due to a decreasein reporting performance.

After uploading a new request, we had to take care of the definedaggregates. The process of updating aggregates content is known as“roll-up”. At the administrator workbench panel InfoCubes, we right-clickedthe InfoCube to get to the InfoCube Performance panel. We clicked tabstripRoll up of the InfoCube. After entering the highest RequestId we wanted toroll 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 haveto choose the partitioning key carefully; that is, you need to know how thedata will be used. You can use transaction SE14 of SAP R/3 to define thepartitions and the respective key range.

We partitioned the fact table in the ODS and in the InfoCube.

7.6.1 Partitioning in the ODSIt is straightforward to define the partitioning key for the table in the ODS. Thekeys of choice are in an intelligible format. We partitioned on the fiscal periodfield, which is an VARCHAR field.


7.6.2 Partitioning in the InfoCubeIn version 1.2B of SAP BW, the characteristics show up in the fact table onlyin a coded form of a DIMID; see 1.3.3, “BW data structures” on page 6 formore information. Hence, all candidates for partitioning keys are in an internalformat only and you have no prior knowledge of the key ranges. You can usethe 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 ourtest scenario. However, you should consider that you might have to redefinethe 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 theexisting keys into account. If you add more data, it will all be placed into thepartition with the highest key.

In SAP BW Version 2 you will have the option of storing the date in anintelligible format in the fact table. Hence you have a good choice for apartitioning key.

Chapter 7. Tests performed at ITSO 87

Chapter 8. Sizing, performance, and tuning considerations

This chapter describes considerations you should keep in mind whendeciding how to size an S/390 system that runs BW. The considerations arebased on recommendations published by SAP in the document Sizing andPerformance, ASAP for SAP BW Accelerator, Document Version 1.1,available on SAPNet.

What resources you need in order to achieve a particular throughput andresponse time depends on several factors, such as the number of users andthe amount of online and background operations. When this redbook waswritten, there was no sizing data available on the S/390 platform based onbenchmarks or production environments. Therefore, conclusions in thischapter are preliminary. For BW sizing guidelines, contact the IBM SAPInternational Competence Center (ISICC) by e-mail at this address:

[email protected]

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, predefinedsummarization 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 youcan allow many concurrent users or just a few. You can build additionalindexes for your tables if some of them are used very often. In addition, use ofthe DB2 explain feature, the DB2 Performance Monitor (DB2PM), or othertools may provide you with performance data or information that leads you todo partitioning or to allow more processors to work in parallel, resizing bufferpools or changing thresholds.

Even with all that, you may still experience elapsed times or resourceconsumptions that you did not expect because BW systems typically performonline query processing. In other words you cannot predict what any of yourusers will do at any time.

The good news in all this is, modern database systems like DB2 have highlysophisticated 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 queryagainst tables that have never had RUNSTATS run against them. We did thisand saw differences in runtime of factors of 50 and more. DB2 Version 6offers you new functions to do the RUNSTATS automatically, along withreorgs and table loading. You absolutely should use that option.

A consequence for sizing considerations obviously is that all values fordatabase size, CPU consumptions, network traffic and, of course, elapsedtimes are not comparable with other installations. In addition, during ourstudies we received some code changes for the BW application thatdecreased runtimes significantly.

For these reasons, we do not supply here any absolute results of runtimes orresource consumption because such results would have no meaning for you;you would not be able to use them to predict reliable results for your existingor any planned environment.

8.1.1 BW administration tasksIt is important to understand that a regular BW administration (not necessarilySAP BW) consists of two major tasks, and these are ongoing for the entire lifecycle 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 theywork in completely different ways and touch tables in different ways. Youmight need indexes for queries, no impact on data loading, and so on.Conversely, some BW tuning people have told us that data loading often maybe more resource-intensive than queries. This is a rather good message,because it means data loading can be done at times when resourceconsumption is no problem.

You can think of SAP BW as a standard application, in which you will not beable to change the application code. However, there are other areas you willbe 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 asrecommended by SAP. The settings can be found in the Appendix B, “DB2Installation parameters” on page 97.

8.1.2 Using RUNSTATSAs previously mentioned, one of the most important things you can do is toensure that RUNSTATS is being executed frequently. (For more informationabout RUNSTATS, also see SAP note 11308 or the SAP R/3 on DB2 forOS/390 Planning Guide, SC33-7964.) The SAP Task RSRV is able to analyzeyour InfoCubes (the fact table 0SD_C01) and will show you by yellowhighlighting if something needs to be done. As we noted earlier, usingRUNSTATS can improve your runtime by a factor of 50 or more, if RUNSTATSwas not run. Be aware that every data loading could generate table spacesthat did not exist before!

8.2 General sizing and tuning approach

In complex environments like BW applications, a good approach is to try tocome as close as possible to a right-sized environment iteratively.

Normally, the introduction of BW applications is a project that can be dividedinto phases, with milestones at the end of each phase. This is also a safe wayto prove sizing estimates, and you can do this at the same time. Thisapproach is described in the next section.

8.2.1 Pre-installation and planning phaseYou can estimate DASD storage needs, CPU consumption, and memory withthe help of tools or by comparing your installation with other, similarinstallations. 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 isthat 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 knowall possible users in your company, or whether they will like the applicationand how they will use it.

The tools will give you values that will not be exactly right for you, but theyshould not be too far off, as long as you do not deviate from the standardsand the defaults of SAP BW.

There are tools available to do that. They are not all available for customeruse but IBM or SAP can help you by running them in the pre-installationphase and providing you with the results.

At the end of this phase you can order the product and the hardware youneed to run it, at least for the next phase.

8.2.2 Pilot or evaluation phaseThe format of the pilot or evaluation phase depends on how the project isdesigned. This phase starts with the base installation of the product,preferably exactly as described in the installation “cookbook” and with nomore installation-specific parameters or exits than necessary. This ensuresthat you at least approach the estimates of phase one.

After that, a BW application is usually loaded with some data so you can testthe functionality of the product and become familiar with its use. This is howwe proceeded. We used flat files with consistent data that generated about1.2 million rows in the details table. (In terms of a BW application, that is asmall 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 yourneeds as you make design, naming, measurement, and maybe tuningdecisions. Keep in mind that you are installing a standard application, sothere is not much more to do in terms of naming and designing in SAP, exceptto prepare the DB2 and OS/390 for it.

At this point you will have already defined the defaults and installationstandards, and will be experiencing different behavior in resourceconsumption or elapsed times. To get the most value out of this phase, youshould constantly monitor what you are doing.

At the end of this phase, you will probably plan to go into production.


8.2.3 Production startWith the knowledge gained during the evaluation phase, you are now able toestimate what you will need for production (“going live”, in terms of SAP). Youcan compare that with the very first estimates you got to verify what youderived from defaults or tool-input values.

It is normal to have these values differ, because in a BW project, therequirements on the BW application typically are subject to continuouschanges, as end users see more and more possibilities of how to use it. Infact, an education or learning step is usually included in this phase, which willadditionally show the users what they could have.

8.2.4 Running BWEven in this phase (which is probably neverending) you may see changes (notnecessarily always growth) in the amount of data being stored, or changes inthe CPU consumption and elapsed time, but you will have gained experienceduring the earlier phases on how the growth of data impacts these factors. Ifyour measurements were sufficient, you will even be able to predict theseimpacts.

The reason for the ongoing administration is that a BW application is subjectto continuously changing queries since the market and the data from whichstrategic decisions are to be derived are continuously changing as well. As aconsequence, the tuning of a BW application is really an ongoing process.

You may decide to have one or more people exclusively responsible for BWadministration. The value of the system is only as good as the resultsobtained, which obviously depends primarily on the quality of the queries.Good administration will guarantee that you get your results quickly and thatthey are most nearly actual, and that you can easily retrieve most results forthe end user (who could be one of your business managers looking for data touse 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 andreporting

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 BWon OS/390, which have an impact on the procedures we did during our testsession.

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 significantnumber of changes in several tables. To ensure optimal access pathgeneration, the SAP BW system updates the DB2 statistic after thesechanges are performed. SAP BW 1.2B uses the FTP job submissionservice feature to run the RUNSTATS utility.

Starting with SAP BW Release 2.0B, the appropriate DSNUTILS storedprocedure is issued instead. This guarantees a very fast and stable wayfor the statistics update.

2. Partitioning of fact tables

SAP BW 2.0B supports partitioning of fact tables based on timecharacteristics. This gives the BW administrator the ability to handle evenhuge InfoCubes by an easy-to-use interface. All maintenance tasks, likecreation and deletion of partitions, are done by the BW system.

With SAP BW 2.0B, partitioning is restricted to fiscal period (info object0FISCPER) and calendar month (info object 0CALMONTH).


Appendix B. DB2 Installation parameters

In this appendix, we list DB2 parameters we used in our test system. Someare 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=*


//SYSUDUMP DD SYSOUT=*//SYSUT1 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND)//SYSUT2 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND)//SYSUT3 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND)//SYSIN DD *

DSN6ENV MVS=XADSN6SPRM 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 NODECDIV3=NO,DEFLTID=IBMUSER,DESCSTAT=NO,DLITOUT=6,DSMAX=6000, <-- WAS 3000EDMPOOL=80000, <-- WAS 14812EDMDSPAC=0,EDPROP=NO,HOPAUTH=BOTH,IRLMAUT=YES,IRLMPRC=IRH1PROC,IRLMSID=IRH1,IRLMRWT=600, <-- WAS 60IRLMSWT=300,LEMAX=20,MAXRBLK=100000, <-- WAS 4000MAXKEEPD=16000, <-- WAS 5000NPGTHRSH=10, <-- WAS 10000NUMLKTS=1000,NUMLKUS=0, <-- WAS 10000OPTHINTS=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 ENABLESYSADM=HAIMO,SYSADM2=HAHN,SYSOPR1=SYSOPR,SYSOPR2=SYSOPR,TRKRSITE=NO,UTIMOUT=3, <-- WAS 6 DEFAULTXLKUPDLT=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 5SECQTY=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 70DBPROTCL=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 8192PCLOSEN=5,PCLOSET=10,RLF=NO,RLFTBL=01,RLFERR=NOLIMIT,RLFAUTH=SYSIBM,ROUTCDE=(1),EXTSEC=NO,SMFACCT=(1,2,3), <-- WAS 1SMFSTAT=(1,3), <-- WAS YESSTATIME=30,STORMXAB=0,STORPROC=DBH1SPAS,STORTIME=180,TBSBPOOL=BP0,TRACSTR=NO,TRACTBL=16,URCHKTH=1, <-- WAS 0WLMENV=

DSN6FAC DDF=AUTO,CMTSTAT=ACTIVE,IDTHTOIN=0,RESYNC=2,RLFERRD=NOLIMIT,TCPALVER=NO,MAXTYPE1=0,TCPKPALV=ENABLE,


POOLINAC=120DSN6GRP 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//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSUT1 DD UNIT=SYSALLDA,SPACE=(1024,(50,50))//SYSLIN DD *

INCLUDE SYSPUNCH(DSNTILMM)INCLUDE ADSNLOAD(DSNZPARM)ORDER DSNAAINCLUDE 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 DSNZMSTRNAME 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//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*


//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)//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSUT1 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND)//SYSUT2 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND)//SYSUT3 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND)//SYSIN DD *

DSNHDECM CHARSET=ALPHANUM,ASCCSID=819, <-- WAS 0AMCCSID=65534,AGCCSID=65534,SCCSID=37,MCCSID=65534,GCCSID=65534,ENSCHEME=ASCII, <--WAS EBCDICDATE=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//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSUT1 DD UNIT=SYSALLDA,SPACE=(1024,(50,50))//SYSLIN DD *

INCLUDE SYSPUNCH(DSNHDECA)ORDER DSNAAINCLUDE ADSNLOAD(DSNAA)INCLUDE ADSNLOAD(DSNARIB)INCLUDE ADSNLOAD(DSNHDECP)ENTRY DSNHDECPMODE 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 andselecting “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 bythe systems in a sysplex. (In a monoplex environment, you can use aDASD-only log stream.) Every OS/390 image with RRS running needs accessto a Coupling Facility and the DASD on which the system logger log streamsare 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 thepolicy information in the LOGR couple data set. The use of a primary and analternate 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 definea couple data set and activate your system logger.

a. Check whether the system logger is already active by issuing thefollowing command from the SDSF panel:

D LOGGER,CONN

b. If the system logger is not active, define the LOGR couple data sets byusing the JCL shown in Figure 24 on page 110. The IXCL1DSU utilityformats LOGR, a couple data set.


Figure 24. Sample JCL to define an RRS LOGR couple data set

c. Modify the SYS1.PARMLIB(COUPLExx) member to add the coupledata set definitions (see Figure 25).

Figure 25. Sample couple data set definition

d. To activate the system logger, you can IPL the system. If you want tobring the LOGR couple data sets online without re-IPLing the system,issue the following SETXCF commands:

SETXCFCOUPLE,TYPE=LOGR,PCOUPLE=(primary_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//SYSPRINT DD SYSOUT=*//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)

/*

/**********************************************//* 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)


SETXCFCOUPLE,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 thecommand:

D LOGGER,CONN

b. Define the log streams for RRS using the sample JCL shown in Figure26 on page 112. The IXCMIAPU utility adds, updates, lists, or deletespolicy data on the LOGR couple data set.

Appendix C. How to set up RRS 111

Figure 26. Sample JCL to define RRS log streams

//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//SYSPRINT DD SYSOUT=*//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 LOGSTREAMNAME(ATR.PLEX57.ARCHIVE) DASDONLY(YES) HLQ(LOGR)MODEL(NO) LS_SIZE(1024) STG_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80)RETPD(15) AUTODELETE(YES)

DEFINE LOGSTREAMNAME(ATR.PLEX57.RM.DATA) DASDONLY(YES) HLQ(LOGR)MODEL(NO) LS_SIZE(1024) STG_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80)RETPD(15) AUTODELETE(YES)

DEFINE LOGSTREAMNAME(ATR.PLEX57.MAIN.UR) DASDONLY(YES) HLQ(LOGR)MODEL(NO) LS_SIZE(1024) STG_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80)RETPD(15) AUTODELETE(YES)

DEFINE LOGSTREAMNAME(ATR.PLEX57.DELAYED.UR) DASDONLY(YES) HLQ(LOGR)MODEL(NO) LS_SIZE(1024) STG_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80)RETPD(15) AUTODELETE(YES)

DEFINE LOGSTREAMNAME(ATR.PLEX57.RESTART) DASDONLY(YES) HLQ(LOGR)MODEL(NO) LS_SIZE(1024) STG_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80)RETPD(15) AUTODELETE(YES)


4. Establish the priority of the RRS address space.

The priority of RRS should be higher than other resource managers, suchas 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 theSYS1.PROCLIB(RRS).

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 FORCERRS,ARM commands.

In the previous sample, the RRS log streams are defined on DASD only. Ifyou plan to use RRS across a sysplex environment, you must define theRRS log streams in the Coupling Facility. Review the parametersaccordingly.

Note

//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'//

Appendix C. How to set up RRS 113

Automatically activate RRSTo activate RRS automatically at each IPL, add the START RRS command inthe SYS1.PARMLIB(COMMNDxx) member.

COM=‘START RRS’


Appendix D. Enterprise Storage Server (ESS)

This appendix gives the reader who is unfamiliar with the Enterprise StorageServer (ESS) an overview of the device architecture and its unique functions.

The ESS is a high-performance RAID-5 storage subsystem, and is a memberof the Seascape family. It consists of a storage server and attached diskstorage devices. The storage server provides integrated caching and RAIDsupport for the attached disk devices. The ESS can be configured in a varietyof ways to provide scalability in capacity and performance.

Redundancy within the ESS provides continuous availability. It is packaged inone or more enclosures, each with dual line cords and redundant power. Theredundant power system allows the ESS to continue normal operation whenone of the line cords is deactivated.

The ESS provides the image of a set of logical disk devices to attachedservers. The logical devices are configured to emulate disk device types thatare compatible with the attached servers. The logical devices access a logicalvolume 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 witheither 512 or 520 byte blocks. SCSI-3 is, in general, a superset of SCSI-2. ASCSI-3 disk device can be attached to a SCSI-2 initiator, provided the cablingcan be interfaced. Many SCSI-2 initiators attach directly to the cablingspecified for the SCSI-3 parallel interface, but are referred to as SCSI-2initiators because they limit their use of the command set to the SCSI-2subset. Host systems with SCSI-2 or SCSI-3 interfaces can attach to theESS.

The ESS provides multiple SCSI I/O interfaces (busses), each with multipleSCSI targets, and each with multiple disk logical units. The storage providedby the ESS for SCSI interfaces can be configured so that it is shared amongmultiple SCSI interfaces if desired.


On ESCON interfaces, the ESS emulates one or more IBM 3990 control unitsattaching variable size IBM 3390 devices in either 3390 or 3380 track format.The ESS provides multiple ESCON interfaces that provide a set of control unitimages, each with multiple disk devices. The storage provided by the ESS forESCON interfaces is configured so that it is accessible from any ESCONinterface.

The ESS is composed of the following components:

The storage server is composed of two clusters that provide the facilities withadvanced functions to control and manage data transfer. Should one clusterfail, the remaining cluster can take over the functions of the failing cluster. Acluster is composed of the following subcomponents:

• Host Adapters - Each cluster has one or more host adapters (HAs). Eachhost adapter provides one or more host I/O interfaces. A host adapter cancommunicate 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. Diskdrives are attached to a pair of device adapters, one in each cluster, sothat the drives are accessible from either cluster. At any given time, a diskdrive is managed by only one device adapter.

• Cluster Complex - The cluster complex provides the managementfunctions 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 clusterprocessors execute the licensed internal code that controls operation ofthe cluster.

• Cluster memory/cache - This is used to store instructions and data for thecluster processors. The cache memory is used to store cached data fromthe disk drives. The cache memory is accessible by the local clustercomplex, by device adapters in the local cluster, and by host adapters ineither cluster.

• Nonvolatile storage (NVS) - This is used to store a nonvolatile copy ofactive written data. The NVS is accessible to either cluster-processorcomplex and to host adapters in either cluster. Data may also betransferred between the NVS and cache.

• Disk Drives - These provide the primary nonvolatile storage medium forany host data stored within the ESS Storage devices. They are groupedinto ranks and are managed by the clusters.


As a member of the IBM Seascape family, the ESS provides the outboardintelligence required by SAN solutions, offloading key functions from hostservers, which frees up valuable processing power for applications. As acomprehensive SAN-based storage solution, the ESS provides considerablemanagement flexibility to meet the fast-paced requirements of the nextcentury.

Among the many factors that make the IBM ESS an ideal solution are:

• Support of all major server platforms including S/390, AS/400, WindowsNT, and many varieties of UNIX

• Fiber channel attachment capability

• Extensive storage management capabilities through a Web interface usedto manage the ESS logical configuration

• Excellent scalability:

- From 400 GB to over 11 TB

- Simple selection from 16 standard configurations to meet capacity andperformance needs

• Performance optimized to your heterogeneous environment needs:

- High bandwidth and advanced transaction processing capabilitiesprovide solutions for both online and batch applications

- Innovations such as Parallel Access Volumes to reduce resourcecontention and dramatically improve performance through theelimination or reduction of IOSQ for single-host environments

- Multiple allegiance, which allows you to dramatically reduce oreliminate IOSQ time for a multiple-host environment

- Performance-enhanced CCW commands

- I/O priority queuing, which allows users to define the priority ofapplication workloads

- Custom volumes, which allows you to create your own custom-sizedlogical volumes

• Availability required to support e-business applications

- Business continuity through remote copy services - PPRC and XRC

- Rapid data duplication through FlashCopy, providing extensivecapabilities to exploit, manage, and protect your information in a 24 x 7environment

Appendix D. Enterprise Storage Server (ESS) 117

- Peer-to-Peer Remote Copy (PPRC), which allows you to createsynchronous volume copies via ESCON channels

- Extended Remote Copy (XRC), which allows you to createasynchronous volume copies over long distances

- Concurrent Copy (CC), which allows you to create volume or data setcopies, locally and non-disruptively

• Storage server availability through redundancy and non-disruptive servicewith design for no single point of failure or repair

More information is available through not only the ESS product manuals, butalso 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 databaseadministrators, and SAP Basis consultants to implement SAP BW 1.2B onS/390. The information in this publication is not intended as the specificationof any programming interfaces that are provided by SAP or IBM. Contact SAPfor more information about what publications are considered to be productdocumentation.

References in this publication to IBM products, programs or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program, or service is notintended to state or imply that only IBM's product, program, or service may beused. Any functionally equivalent program that does not infringe any of IBM'sintellectual property rights may be used instead of the IBM product, programor service.

Information in this book was developed in conjunction with use of theequipment specified, and is limited in application to those specific hardwareand software products and levels.

IBM may have patents or pending patent applications covering subject matterin this document. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, to the IBMDirector of Licensing, IBM Corporation, North Castle Drive, Armonk, NY10504-1785.

Licensees of this program who wish to have information about it for thepurpose of enabling: (i) the exchange of information between independentlycreated programs and other programs (including this one) and (ii) the mutualuse of the information which has been exchanged, should contact IBMCorporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms andconditions, including in some cases, payment of a fee.

The information contained in this document has not been submitted to anyformal IBM test and is distributed AS IS. The information about non-IBM("vendor") products in this manual has been supplied by the vendor and IBMassumes no responsibility for its accuracy or completeness. The use of thisinformation or the implementation of any of these techniques is a customerresponsibility and depends on the customer's ability to evaluate and integratethem into the customer's operational environment. While each item may havebeen 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 environmentsdo so at their own risk.

Any pointers in this publication to external Web sites are provided forconvenience only and do not in any manner serve as an endorsement ofthese Web sites.

Any performance data contained in this document was determined in acontrolled environment, and therefore, the results that may be obtained inother operating environments may vary significantly. Users of this documentshould verify the applicable data for their specific environment.

This document contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examplescontain the names of individuals, companies, brands, and products. All ofthese names are fictitious and any similarity to the names and addressesused by an actual business enterprise is entirely coincidental.

Reference to PTF numbers that have not been released through the normaldistribution process does not imply general availability. The purpose ofincluding these reference numbers is to alert IBM customers to specificinformation relative to the implementation of the PTF when it becomesavailable to each customer according to the normal IBM PTF distributionprocess.

The following terms are trademarks of the International Business MachinesCorporation in the United States and/or other countries:

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, PlanetTivoli, and Tivoli Enterprise are trademarks or registered trademarks of TivoliSystems Inc., an IBM company, in the United States, other countries, or both.In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - TivoliA/S.

C-bus is a trademark of Corollary, Inc. in the United States and/or other

AIX DB2DFSMS/MVS DFSMSdfpESCON FICONNetfinity OS/390OS/390 UNIX Parallel SysplexS/390 IBM �


countries.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and/or othercountries.

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

PC Direct is a trademark of Ziff Communications Company in the UnitedStates and/or other countries and is used by IBM Corporation under license.

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of IntelCorporation in the United States and/or other countries.

UNIX is a registered trademark in the United States and other countrieslicensed exclusively through The Open Group.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarksowned by SET Secure Electronic Transaction LLC.

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

Appendix E. Special notices 121

Appendix F. Related publications

The publications listed in this section are considered particularly suitable for amore detailed discussion of the topics covered in this redbook.

F.1 IBM Redbooks

For information on ordering these publications see “How to get IBMRedbooks” 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 NTApplication 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-ROMsbutton at http://www.redbooks.ibm.com/ for information about all the CD-ROMsoffered, updates and formats.

F.3 Other resources

These publications are also relevant as further information sources:

CD-ROM Title Collection KitNumber

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






• 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 forOS/390, Release 1.2B SR-1, 51007613


• 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/390documentation


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 fewchapters will be published this way. The intent is to get the information out much quicker than theformal publishing process allows.

• E-mail Orders

Send orders by e-mail including information from the IBM Redbooks fax order form to:

• Telephone Orders

• Fax Orders

This information was current at the time of publication, but is continually subject to change. The latestinformation may be found at the Redbooks Web site.

In United StatesOutside North America

e-mail [email protected] information is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)Canada (toll free)Outside North America

1-800-879-27551-800-IBM-4YOUCountry coordinator phone number is in the “How to Order”section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)CanadaOutside North America

1-800-445-92691-403-267-4455Fax phone number is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

IBM employees may register for information on workshops, residencies, and Redbooks by accessingthe 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 developedand written by the ITSO technical professionals; click the Additional Materials button. Employees mayaccess MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Intranet for Employees


http://www.elink.ibmlink.ibm.com/pbl/pbl



http://w3.itso.ibm.com/

http://w3.ibm.com/

http://www.redbooks.ibm.com




mailto:[email protected]




IBM Redbooks fax order form

Please send me the following:

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to


Glossary

access plan. Plan generated by the DB2Optimizer of how to access the data in the tablesbeing queried.

Administrator Workbench. A tool to controlhow the data gets from the source systems intothe InfoCubes of the Business InformationWarehouse. It is used to request and managedata in the source system, InfoSource,InfoCube, InfoObject, Scheduler, and Monitor.

aggregation. The process of summarizingatomic (detailed) level data horizontally,vertically and chronologically.

BAPI. Business Application ProgrammingInterfaces or Business API.

Business Explorer. SAP BW reporting tool.

characteristic. An element of a business such as:company code, product, material, or fiscal year.Also an element of a dimension.

data extraction. Pulling the data out of its sourcesystem (or systems) and putting it into awarehouse-usable form.

data loading. A process of loading data fromsource systems into the BW InfoCube.

data mart. A decision support environment thataddresses the common decision support needs ofa specific group within the organization (typically adepartment or geographic area). In BW datamarts can be created by queries on a specificaggregate.

data warehouse. A database that containssummarized data created from transactionaldata found in the OLTP system.

database. A means of data storage.

database table. See table.

delta update. A type of database update.Refreshes only data changed since the lastextraction. See also full update.

dimension. Grouping characteristics that belongtogether from a content point of view. For example,a customer dimension may contain the customer

© Copyright IBM Corp. 2000

number, the customer group, and the levels ofcustomer hierarchy.

drill down. A technique that allows you to explorethe detailed data that was used in creatingsummary level data. In BW, this is one of thenavigation techniques.

fact table. A table that contains all key figures(facts) of the InfoCube. It is the central table in thestar schema.

flat file. A file that contains text. It is used to loadinformation into the data warehouse. It can becomma-delimited, fixed-width, or variable width.

full update. A type of database update. Replacesall data. See also delta update.

granularity. The level of detail contained in asingle record of the fact table. The coarser thegranularity, the more the data is summarizedbefore storage.

InfoCube. A multidimensional central datacontainer for queries and evaluations. Containstwo types of data: key figures and characteristics.

InfoObject. Generic term for characteristics andkey figures.

InfoPackage. A description of data that should berequested from a source system.

informational data. Data created fromoperational data, stored in a format that makeseasier business analysis. Analysis can be in theform of decision support (queries), reportgeneration, Executive Information Systems, orstatistical analysis.

InfoSource. A quantity of InfoObjects groupedtogether from a business point of view. It cancontain either transaction data or master data.

key figure. Values or quantities such as revenue,costs, number of employees.

legacy system. A system that has been in placefor a significant period of time. Serves as a sourcesystem for a data warehouse.

127

master data. Data that remains unchanged over along period time, for example, customer names andaddresses.

meta data. Data about data. Meta data describesformat, origin, history, and other aspects of data.

meta data repository. It contains the variousclasses of meta data.

Monitor. Monitoring tool of the AdministratorWorkbench to oversee the data request andprocessing in the Administrator Workbench.

multidimensional database. A specializeddatabase that is designed to enable the queryingand viewing of large volumes of data based onpredefined dimensions such as geography,customer, and product.

multidimensional table. See multidimensionaldatabase.

navigation. Analysis of the InfoCube by displayingdifferent views of the data of a query.

navigation attributes. Attributes that allow you topresent different views of the data.

N-way system. A system with two or more CPUs.

OLAP. Online analytical processing. A type ofprocessing used to analyze summarized onlinetransaction processing (OLTP) data. OLAP allowsmultidimensional views and analysis of that data fordecision support processes.

OLTP. Online transaction processing. A type ofprocessing of operational data.

operational data. Data that is used to run acompany’s business. It is stored, retrieved, andupdated by an OLTP system.

operational data store (ODS). An integrateddatabase that contains a copy of extracted datafrom source systems.

query. A selection of InfoObjects (characteristicsand key figures) for analysis of the data in anInfoCube.

scheduler. The nexus between the sourcesystems and the InfoCubes.

schema. The logical and physical definition of dataelements, for example, a star schema.

source system. Every system that is available inthe Business Warehouse for data extraction.

staging engine. Implements data mapping anddata transformation during the data loadingprocess. It extracts data from a source system.

star schema. A data structure that combines facttables and dimension tables in a way that provideseasy and efficient access to data.

SQL. Structured Query Language. A languagedeveloped by IBM that provides access to relationaldatabase.

table. An array of data in a table form. It consists ofcolumns (data values of the same type) and rows(data records). Each record can be identifieduniquely by one or several fields.

table index. Index used to accelerate dataselection from a table. It is similar to a copy of thetable reduced to certain fields only and alwayssorted.

think time. The time that the end user spendsbetween two key presses.

transaction data. Operational data provided by anOLTP system.


Index

AABAP 4access plan 127Administrator Workbench 6, 79, 127aggregate build 85aggregation 58application server 13, 19

setup 31

BBAPI 5, 127Business Content (BCT) 6, 22Business Explorer 5, 9, 127BW application

sizing 91tuning 91

BW databasebackup/recovery 81data loading 67partitioning 86

BW Patch 71BWGUI 71

Ccharacteristic 7, 127configuration

for this study 28ICLI 36SMS 34TCP/IP 42

connectivity 15, 19testing 31

CRM 1

Ddata mart 7, 127data warehouse 4, 127database server 13, 14

setup 30DB2

additional DB2 catalog indexes 52authorization 54bufferpools 50catalog and directory 50

© Copyright IBM Corp. 2000

catalog updates 55DSNDB07 58DSNTPID 51log 52objects 47optimizer 79prerequisites 47PTFs 47reorganization 58RUNSTATS 54, 91temporary database 58

DB2 parameters 49debugging 66delta update 127dimension 8, 127dimension table 8dispatching priority 39documentation

SAP R/3 installation 43drill down 127

EEnterprise Storage Server (ESS) 14ESCON 15, 26

Ffact table 7, 127Fast Ethernet OSA-2 26FDDI

adapter 20connection 13Driver 20

FDDI OSA-2 26full update 127

Hhardware

application server 19configuration 28database server 14

IICLI

client setup 42customizing 36

129

environment file 36security 38

ICLI packages 18ICLI plan 18ICLI server 17

customizing 36DB2 binding 53startup JCL 36

ICLIRUN 18InfoCube 7, 127

partitioning 87update 86updating 84

InfoObject 6, 127InfoPackage 83, 127InfoPackage Scheduler 83InfoSource 84, 127installation

pre-installation checking 26steps 45

INSTGUI 44INSTTOOL.SH

location 43Integrated Call Level Interface (ICLI) 8, 17IRLM parameters 50

Kkey figure 7, 127

Llegacy system 127

Mmaster data 128master table 8meta data 128Meta Data Manager 6multidimensional database 128

Nnavigation 128

OODS

data loading 83OLAP 128OLAP processor 5

Operational Data Store (ODS) 5OSA-2 Adapters 15OSA-EXPRESS 26

Ppartitioning 86performance 89PI-A 99 72presentation server 13, 22processor 14

RR3SETUP 44

problem solving 68RACF 19, 37RRS 48

SSAP 20

BASIS 25notes 61

SAP BWarchitecture 4data structure 6DB2 objects 47

SAP R/3 tools 80SAP system name 20SAPGUI 13, 71SAPOSCOL 65SID table 8SMS 34

ACS routine 16configuring 34

staging engine 6, 128star schema 7, 128STARJOIN 83start up JCL 36storage 14System Managed Storage (SMS) 16

TTCP/IP

hosts file 40services file 41testing 42

think time 128


UURLs 76user information 19

VVSAM catalog 48VTOC 48

WWorkload Manager (WLM) 15

131


IBM Redbooks review

Your feedback is valued by the Redbook authors. In particular we are interested in situations where aRedbook "made the difference" in a task or problem you encountered. Using one of the followingmethods, please review the Redbook, addressing value, subject matter, structure, depth andquality 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 [email protected]

Document NumberRedbook Title

SG24-5681-00SAP Business Information Warehouse on OS/390

Review

What other subjects would youlike to see IBM Redbooksaddress?

Please rate your overallsatisfaction:

O Very Good O Good O Average O Poor

Please identify yourself asbelonging to one of thefollowing groups:

O Customer O Business Partner O Solution DeveloperO IBM, Lotus or Tivoli EmployeeO None of the above

Your email address:The data you provide here maybe used to provide you withinformation from IBM or ourbusiness partners about ourproducts, services or activities.

O Please do not use the information collected here for futuremarketing or promotional contacts or other communications beyondthe scope of this transaction.

Questions about IBM’s privacypolicy?

The following link explains how we protect your personal information.ibm.com/privacy/yourprivacy/




http://www.ibm.com/privacy/yourprivacy/


http://www.ibm.com/privacy/yourprivacy/

(0.2”spine)0.17”<->0.473”

90<->249 pages

SAP Business Information W

arehouse on OS/390

®

SG24-5681-00 ISBN 0738418943

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

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

Administer your SAP BW databases

Recommended sizing approaches

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 recommendationsWe assume that the readers have already installed the SAP R/3 system and are familiar with SAP applications, terminology, prerequisites, documentation, and technology.




sap business information warehouse on os 390

Documents

database server setup

r3 application server

presentation server

icli server

b sap r3

application server setup

r3 database server142

bw data structures