SAP Business Information Warehouse On OS 390

SAP Business Information Warehouse on OS/390
Prepare, install, and configure your SAP BW on OS/390 Administer your SAP BW databases Recommended sizing approaches
Seungrahn Hahn Patrick Horkan Christoph Laube Gert Ruland
ibm.com/redbooks
SG24-5681-00
International Technical Support Organization SAP Business Information Warehouse on OS/390
September 2000
Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix E, Special notices on page 119.
First Edition (September 2000) This edition applies to SAP Business Information Warehouse 1.2B (SAP R/3 4.5B). Data server uses DB2 UDB for OS/390 Version 6 (5665-DB2) with OS/390 V2R7. Application server uses AIX 4.3.3 (5765-603) as an operating system. This document created or updated on September 11, 2000. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. HYJ Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 2000. All rights reserved. Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Chapter 1. SAP Business Information Warehouse (BW) overview 1.1 Why use Business Information Warehousing . . . . . . . . . . . . . . . . 1.2 Why use BW on SAP R/3 on OS/390 . . . . . . . . . . . . . . . . . . . . . . 1.3 The architecture of SAP Business Information Warehouse . . . . . . 1.3.1 The components of the Business Information Warehouse. . . 1.3.2 How things are done with SAP BW . . . . . . . . . . . . . . . . . . . . 1.3.3 BW data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 Database Management System (DBMS). . . . . . . . . . . . . . . . 1.3.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.6 The presentation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 The terminology used in this redbook . . . . . . . . . . . . . . . . . . . . . . Chapter 2. Our system environment . . . . . . . . . 2.1 OS/390 for SAP BW and R/3 database server 2.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Software environment. . . . . . . . . . . . . . . 2.2 AIX for SAP BW and R/3 application server . . 2.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 System setup for SAP BW . . . . . . . . . . . 2.2.4 System setup for SAP R/3 . . . . . . . . . . . 2.3 Windows NT for Presentation Server . . . . . . . 2.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 . .1 . .2 . .4 . .4 . .6 . .6 . .8 . .9 . .9 . 10 . 13 . 14 . 14 . 15 . 19 . 20 . 20 . 20 . 22 . 22 . 22 . 22 . 25 . 26 . 28 . 30 . 30 . 31 . 31 . 32
Chapter 3. Preparing OS/390 and AIX . . . . . . . . . . . . . . . . . . . . . . . 3.1 Pre-installation checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Defining the configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Installation prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Database server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Application server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Database server and application server connectivity testing . 3.3.4 DASD initialization on the database server . . . . . . . . . . . . . .
Copyright IBM Corp. 2000
iii
3.3.5 Configuring OSA-2 on the database server. . . . . . . . . . . . . . . 3.3.6 Installing DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.7 Configuring SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.8 Customizing OS/390 UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.9 Customizing TCP/IP on the database server . . . . . . . . . . . . . 3.3.10 Customizing the ICLI Server . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.11 Customizing RACF or equivalent . . . . . . . . . . . . . . . . . . . . . 3.3.12 Set OS/390 dispatching and I/O priorities . . . . . . . . . . . . . . . 3.3.13 Customizing TCP/IP on the central instance . . . . . . . . . . . . . 3.3.14 Setting up the ICLI client . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.15 Testing connectivity -- central instance and database server 3.4 Installing SAP BW on DB2 for OS/390 . . . . . . . . . . . . . . . . . . . . . . 3.4.1 General notes on the installation from AIX . . . . . . . . . . . . . . . 3.4.2 Hints and tips -- installing with AIX . . . . . . . . . . . . . . . . . . . . . Chapter 4. Preparing DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Inside the SAP BW database . . . . . . . . . . . . . . . . . . . . . . 4.2 Prerequisites of DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 OS/390 setup for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Setting up RRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Customizing DB2 parameters . . . . . . . . . . . . . . . . . . . . . . 4.6 DB2 system database requirements . . . . . . . . . . . . . . . . . 4.6.1 DB2 catalog and directory database size . . . . . . . . . 4.6.2 Additional DB2 catalog indexes . . . . . . . . . . . . . . . . 4.7 Preparing the DB2 log . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 DB2 Binding for the ICLI server . . . . . . . . . . . . . . . . . . . . 4.9 DB2 authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Maintaining DB2 catalog statistics . . . . . . . . . . . . . . . . . 4.10.1 RUNSTATS utility considerations . . . . . . . . . . . . . . 4.10.2 Updating DB2 catalog statistics manually . . . . . . . . 4.10.3 Maintaining catalog statistics for R/3 cluster tables . 4.11 Post-installation tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.1 Reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.2 DB2 temporary database (DSNDB07). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 32 . 33 . 34 . 34 . 34 . 36 . 37 . 39 . 40 . 42 . 42 . 43 . 43 . 43 . 47 . 47 . 47 . 48 . 48 . 48 . 50 . 51 . 52 . 52 . 53 . 54 . 54 . 54 . 55 . 56 . 58 . 58 . 58 . 59 . 59 . 60 . 60 . 61 . 62 . 62 . 62
Chapter 5. Installing SAP BW OS/390 with AIX Application Servers. 5.1 SAP BW installation overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 SAP BW pre-installation: data gathering . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Gathering the SAP notes via SAPNet R/3 Frontend . . . . . . . . . 5.2.2 Searching for SAP notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Downloading patches and other information from SAPSERVx . 5.2.4 Searching for installation documentation . . . . . . . . . . . . . . . . . 5.3 SAP BW pre-installation: system check . . . . . . . . . . . . . . . . . . . . . .
iv
5.4 SAP BW pre-installation: final preparation phase . . . . . . . . . . 5.5 SAP BW installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Starting BW installation . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Building the BW database . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 Loading the BW database. . . . . . . . . . . . . . . . . . . . . . . . 5.5.4 R3SETUP problem solving . . . . . . . . . . . . . . . . . . . . . . . 5.6 SAP BW post installation: completing the install . . . . . . . . . . . 5.6.1 Summary of the BW database . . . . . . . . . . . . . . . . . . . . 5.6.2 Summary of the SAP R/3 source system . . . . . . . . . . . . 5.6.3 SAPGUI/BWGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.4 BW Patch installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Installing the R/3 PlugIn PI 99 or PI-A 99 for SAP BW . . . . . . 5.7.1 PlugIn -A 99 pre-installation: data gathering . . . . . . . . . . 5.7.2 PlugIn -A 99 pre-installation: system check . . . . . . . . . . 5.7.3 PlugIn -A 99 pre-installation: final preparations. . . . . . . . 5.7.4 PlugIn -A 99 installation . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.5 PlugIn -A 99 post-installation: completing the installation 5.8 What to do with those leftover CD-ROMs . . . . . . . . . . . . . . . . 5.9 Useful URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 6. Managing SAP BW database . 6.1 Administrators workbench . . . . . . . . . . 6.2 SAP R/3 tools . . . . . . . . . . . . . . . . . . . . 6.3 DB2 utilities . . . . . . . . . . . . . . . . . . . . . 6.4 Backup and recovery strategy . . . . . . . Chapter 7. Tests performed at ITSO . 7.1 Loading the ODS . . . . . . . . . . . . . . 7.2 Updating the InfoCube . . . . . . . . . . 7.3 Aggregate build . . . . . . . . . . . . . . . 7.4 .Running queries . . . . . . . . . . . . . . 7.5 Incremental DataPackage update . . 7.6 Partitioning tables in SAP BW . . . . 7.6.1 Partitioning in the ODS . . . . . . 7.6.2 Partitioning in the InfoCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 64 . 66 . 66 . 67 . 67 . 68 . 69 . 70 . 71 . 71 . 71 . 72 . 73 . 73 . 73 . 75 . 75 . 76 . 76 . 79 . 79 . 80 . 81 . 81 . 83 . 83 . 84 . 85 . 85 . 86 . 86 . 86 . 87 . 89 . 89 . 90 . 91 . 91 . 91 . 92 . 93
Chapter 8. Sizing, performance, and tuning considerations . 8.1 Special considerations for BW applications . . . . . . . . . . . . . 8.1.1 BW administration tasks . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 Using RUNSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 General sizing and tuning approach . . . . . . . . . . . . . . . . . . . 8.2.1 Pre-installation and planning phase . . . . . . . . . . . . . . . 8.2.2 Pilot or evaluation phase . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Production start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.4 Running BW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Appendix A. Whats new in SAP BW 2.0. . . . . . . . . . . . . . . . . . . . . . . . . . 95 Appendix B. DB2 Installation parameters . . . . . . . . . . . . . . . . . . . . . . . . 97 B.1 DSNZPARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.2 IRLMPROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 B.3 DB2 parameters using a SAP transaction . . . . . . . . . . . . . . . . . . . . . . . 104 Appendix C. How to set up RRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Appendix D. Enterprise Storage Server (ESS) . . . . . . . . . . . . . . . . . . . 115 Appendix E. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Appendix F. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 F.1 IBM Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 F.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 F.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 F.4 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
vi
Figures
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. SAP BW architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Table structure of an InfoCube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Business Explorer example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Test system environment for SAP BW application . . . . . . . . . . . . . . . . . . 13 A storage class definition for SAP applications . . . . . . . . . . . . . . . . . . . . . 17 A storage group definition for SAP applications. . . . . . . . . . . . . . . . . . . . . 17 Physical SAP BW system configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 28 I/O configuration for the FDDI connection . . . . . . . . . . . . . . . . . . . . . . . . . 33 ICLI environment file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 ICLI started procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Allocating DB2 active log data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 An example of DB2 catalog updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Sample SQL statements for updating catalog statistics for cluster tables . 57 Sample SQL statements to avoid deadlock . . . . . . . . . . . . . . . . . . . . . . . . 57 DB2 installation parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 DB2 buffer pool allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 DB2 storage sizes and connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 DB2 trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 DB2 locks and IRLM definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 DB2 archive log parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 DB2 active log parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 DB2 application parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 DB2 operation and DDF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Sample JCL to define an RRS LOGR couple data set . . . . . . . . . . . . . . 110 Sample couple data set definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Sample JCL to define RRS log streams . . . . . . . . . . . . . . . . . . . . . . . . . 112 Sample RRS started task procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
vii
viii
Tables
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Official names and usage in this redbook . . . . . . . . . . . . . . . . . . . . . . . . . 11 SMS naming convention for SAP applications. . . . . . . . . . . . . . . . . . . . . . 16 Information about DB2 systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 User ID definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 SAP BW definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 User ID information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Physical volume information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 File system allocation for SAP BW code installation . . . . . . . . . . . . . . . . . 21 User ID setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 TCPIP definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Other definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Statistics of the DB2 objects of SAP BW . . . . . . . . . . . . . . . . . . . . . . . . . . 47 DB2 parameter checked by R3SETUP (BW). . . . . . . . . . . . . . . . . . . . . . . 49 Highly recommended IRLM parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Recommended DB2 bufferpool allocation . . . . . . . . . . . . . . . . . . . . . . . . . 50 DB2 installation panel DSNTPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 New indexes created against the DB2 catalog tables during R3SETUP . . 52 DB2 authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Installation activities and runtime durations . . . . . . . . . . . . . . . . . . . . . . . . 60 SAPNet R/3 Frontend Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 AIX file system layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 AIX language filesets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 R3SETUP input required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Debugging file and locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 R3SETUP problem-solving tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 R/3 Profile parameter changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 SAP BW DB2 UDB 6.1 OS/390 database statistics. . . . . . . . . . . . . . . . . . 70 SAP R/3 DB2 UDB 6.1 OS/390 database statistics. . . . . . . . . . . . . . . . . . 71 File system size for PlugIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 PlugIn variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Useful URLs - SAP logon required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Useful URLs - Public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 TP parameters for JCL submitted with FTP out of SAP R/3 . . . . . . . . . . . 80
ix
Preface
This redbook explores the SAP Business Information Warehouse (BW) 1.2B on the S/390 system. It takes a close look at the tasks and functions that are specific to the S/390 environment. It is designed to assist S/390 technical specialists, DB2 database administrators, and SAP Basis consultants in implementing this technology. This redbook offers valuable information that includes: An overview of BW The preparation of the BW installation The BW installation process Recommendations on administering BW databases to: improve query response time, improve performance of loading databases, update delta information, gather database statistics, and more. Preliminary sizing recommendations based on tests and SAP recommendations We assume that the readers have already installed the SAP R/3 system and are familiar with SAP applications, terminology, prerequisites, documentation, and technology.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization Poughkeepsie Center. Seungrahn Hahn is a Business Intelligence specialist at the ITSO. Before joining the ITSO, she worked as an IT specialist in physical database design, performance tuning, the data sharing implementation with DB2 for OS/390, and BI application solutions in IBM Korea. Patrick Horkan is an IT Architect in the IBM ERP Competency Center, The Americas. He has been working with SAP R/3 on DB2 for OS/390 for many years, and is certified as an SAP R/3 and SAP BW Technical Consultant. He joined IBM in December 1997. Christoph Laube manages a competence center of OS/390 consultants at SCHUMANN AG in Cologne, Germany. His task is to build consulting teams for server consolidation and SAP R/3 on OS/390. He has worked in IT for 22
xi
years with 15 years spent on MVS and OS/390. He has over 10 years of experience in migration projects in the area of OS/390, DB2, and multiplatform environments. Recently he participated in a pilot study of porting UNIX/Informix applications to OS/390 UNIX. Christoph is the region manager of GUIDE SHARE Europe for the German Region, and formerly led the OS/390 working group. Gert Ruland is a BI specialist at the S/390 New Technology Center, Montpellier, France. Before joining NTC Montpellier he worked for IBM Germany in the S/390 division as a system engineer and sales representative. He has 22 years of experience in different areas of IT. Thanks to the following people for their contributions to this project: Jan Baisden International Technical Support Organization, Poughkeepsie Center David Bennin Rich Conway Robert Haimowitz Vasilis Karras International Technical Support Organization, Poughkeepsie Center Terry Barthel Alfred Schwab Denny Sell Ella Buslovich International Technical Support Organization, Poughkeepsie Center Benno Staebler Joachim Rese SAP R/3 on DB2 for OS/390 Porting team: Business Warehouse, IBM Germany Christine Gaul-Gaensslen Customer support for SAP R/3 on DB2 for OS/390, IBM Germany Michael Sheets IBM SAP International Competency Center - S/390 Lee Siegmund IBM Dallas System Center
xii
Don Geissler Scott Bell IBM ERP Competency Center, The Americas
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Please send us your comments about this or other Redbooks in one of the following ways: Fax the evaluation form found in IBM Redbooks review on page 133 to the fax number shown on the form. Use the online evaluation form found at http://www.redbooks.ibm.com/ Send your comments in an Internet note to redbook@us.ibm.com
xiii
xiv
Chapter 1. SAP Business Information Warehouse (BW) overview

SAP Business Information Warehouse (BW) is an SAP strategic product architecture that gives you immediate access to data that is relevant to decision-making, and allows you to flexibly analyze it. In this chapter we briefly describe: Why you should use SAP BW Why you should use SAP BW on S/390 The architecture of SAP BW The terminology we used
1.1 Why use Business Information Warehousing

For your company to succeed, you need fast access to reliable information, and the ability to flexibly analyze it. The quality of your business decisions is directly dependent on the quality of the available information. The more current the information and the faster you can obtain it, the more relevant it is. In a world where good Customer Relationship Management (CRM) is a growing competitive advantage, you have to know where to focus in specific situations. Such focus is impossible without having reliable information to base decisions on, so it is important for your company to be able to quickly extract the important data and present it in such a way that intelligent business decisions can immediately be derived. The modern solution for this is Business Information Warehousing (BW). BW offers managers an array of possibilities to easily define and satisfy their information needs. Put simply, a BW system gathers all the information needed to answer your requests from your production data. This data gathering can be scheduled for off hours on a daily or weekly basis, thus making it as current as possible without disrupting your operating environment. BW stores all information in its own database in a very sophisticated way that is specially prepared to handle your queries on it. For example, certain aggregation and summarization is already done, without having to be calculated when you query for it. As a result, your queries on the data will be satisfied on each level in a very fast and efficient way.
BW provides a steadily-growing base of knowledge about your companys business and your customers behavior (for example, the results of certain marketing campaigns), and about the relationships between these factors. BW can extract, store, and provide quick and easy access to all this business knowledge. You, in turn, can use this knowledge to make successful business decisions by querying BW. BW can help you determine the future direction of your company. This is why more and more customers are using it.
1.2 Why use BW on SAP R/3 on OS/390

You may have heard that performing Business Information Warehousing on an OS/390 system would be the most expensive solution. On the contrary, the discussions and experiences that the project team had with customers using or intending to use BW on OS/390 clearly showed that there are very compelling reasons why they chose this platform and why they consider OS/390 to be the best possible solution. These customers can be divided into two groups: those who already have OS/390 systems or S/390 platforms, and those who would enter a new platform with OS/390. Their main reasons for using BW on OS/390 are as follows.
For customers already using OS/390 systems 1. Existing skills in OS/390 and DB2 can be used:
There is no need to build up new skills and hire additional staff. There is less learning involved; therefore, a quicker start is possible. 2. Production data (the base for deriving BW data) is already on OS/390; this means: There are no connectivity problems. There is high speed data transfer. You have secure interfaces. 3. Important data is on a proven platform: You can avoid increasing IT complexity. Proven existing backup and recovery mechanisms can be used. Existing automation can be used and new jobs can easily migrate to it. You can use existing systems management procedures. You can keep the number of servers small (server consolidation results in reduced costs).
1. Scalability One hardware system powers multiple LPARs, systems, and databases in a most flexible way, without having to IPL or redefine parameters for each change. Hardware growth benefits all applications and systems.
For customers using OS/390 as a new platform These reasons for using SAP on OS/390 for BW were cited by both groups of customers:
1. Availability S/390 platforms and storage subsystems are well known for high availability in the marketplace. Using the Parallel Sysplex facilities will increase availability to the highest possible level. Changes to hardware and software can be made in flight, without disrupting applications. 2. Security OS/390 is acknowledged to be one of the most secure systems--and all customers want the best possible protection for strategic data, such as that stored in BW systems. OS/390 UNIX System Services is especially secure, because RACF is used for security instead of standard UNIX security. If BW data may be accessed from the Internet, thus making security concerns particularly important. 3. Accounting, tuning and measurement A BW application will contain a large and ever-increasing mountain of data, so it is particularly important to track (and probably, bill) the users who are producing and using this data. For accurate accounting, you first need to perform measurements, collecting data from the system and the subsystems, so users are fairly charged. Accurate and continuous measurement is the base for all system tuning activities, as well--and you also need measurement data to predict your systems and storage growth and to contract service level agreements with your users or IT customers that you will be able to fulfill. All these considerations are especially important in a BW application, which holds strategic information for your company and will likely be used by every employee who makes business decisions. For more than twenty years, OS/390 has performed measurement and accounting tasks as normal business, processing large amounts of data,
handling great numbers of users, and providing parallelism--so all the tools needed for these tasks in a BW environment are already available and ready for you to use. UNIX and PC systems simply do not offer the measurement and accounting capabilities of OS/390. So if you need detailed information about database activity or storage usage to do measurement, tuning, accounting, service-level design or IT growth projections, OS/390 can be the solution--and these OS/390capabilities become even more important if you enter a multi-customer service center environment.
1.3 The architecture of SAP Business Information Warehouse

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

Figure 1 on page 5 shows the three-level layered components of BW, which is a data warehouse solution: Top layer: BWs client components for the end user Middle layer: BW server Bottom layer: the OLTP systems from which source data is extracted
1.3.1.1 Business Explorer Business Explorer is a graphical user interface (GUI), hosted by MS EXCEL, that provides analyzing and viewing functions for end users. SAP provides several ready-made reports for the standard R/3 system.
Business Explorer
Report Catalog Browser
Reporting and Analysis for Excel
Reporting and Analysis
BAPI
OLAP Processor InfoCubes Meta Data Repository Meta Data Manager Data Manager
Operational
Business Information Warehouse Server
Staging Engine
Data Store
BAPI
Non R/3 Production Data Extractor Non R/3 OLTP Applications
Production Data Extractor
OLTP Reporting
R/3 OLTP Applications
Figure 1. SAP BW architecture overview
1.3.1.2 Business Information Warehouse Server The OLAP processor manages the supply of data that is requested by a user for analysis. It interfaces with the Meta Data Manager to get information about where to get the data, and with the data manager to get the actual data. The interface to the Business Explorer of the SAP BW frontend is the Business Application Interface (BAPI). Data Manager takes care of the data in the InfoCubes and Operational Data Store. InfoCubes is the container for the data tables for OLAP processing, and the Operational Data Store (ODS) holds the data in flat file-type tables.
The Staging engine is responsible for loading the data that is extracted from the application data. The interface to the extracted data is supplied by SAP BW, in the case of SAP R/3 and SAP R/2 systems. For other OLTP applications, you have to develop it yourself. Meta Data Manager keeps track of the data warehouse environment and stores its tables in the Meta Data Repository. 1.3.1.3 OLTP systems At the bottom of the Figure 1 on page 5 are the production systems, from which the data is extracted and loaded into SAP BW. Administrator Workbench The Administrator Workbench tool can also help in BW administration. This SAPGUI-based tool is used for BW implementation, maintenance, customizing, scheduling, and monitoring. The Business Content (BCT) BCT is meta data information used to assist in synchronizing the meta data of SAP BW and SAP R/3.
1.3.2 How things are done with SAP BW

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

The basic building blocks of the BW data structures are called characteristics and key figures . The generic term for both is InfoObjects . When you want to
create the data warehouse on your BW system, you start by creating your InfoObjects.
Characteristics are the elements of a companys business, for example company code, product, material, customer group, fiscal year, period, or sales region. They may have a hierarchical structure; products, for example, may be grouped together into product groups. Characteristics are stored in dimension tables. Key figures are the values or quantities in a companys business, such as sales revenue, sales quantity, or fixed costs. They are stored in fact tables.
A fact table contains all the key figures at the lowest level of detail. A dimension table contains characteristics that are required both in reporting and in the analysis of the key figures. Dimension tables are independent of one another. Only the fact table connects dimension tables through key figures. The largest organizational unit is an InfoCube; see Figure 2 on page 8 for an example. You can think of an InfoCube as a data mart. An InfoCube is used to answer specific end-user queries and to provide information for specific analysis. It consists of a number of tables that are put together in a extended star schema. A large fact table is surrounded by several dimension tables.
SID Attr SID Attr SID Attr
M aster
M a ste r
S ID Table
S ID Table
SID Attr
S ID Table
D im en s io n tab le
Tem p Tab
S ID Table
M a ste r
M a ster
S ID Table
D im en sio n tab le
FACT
D im en sio n tab le
SID Attr
SID Attr
M a ster
S ID Table
D im en s io n tab le
S ID Table
S ID Table
M aster
F act Tab le Dimen sion M a ste r SID Tab le Temp Tab SID Attr
SID Attr
S ID Table
SID Attr
M a ste r
M a ste r
SID Attr
Tem p Tab
SID Attr
SID Attr
SID Attr
Figure 2. Table structure of an InfoCube
Dimension tables are linked to the fact table using surrogate keys. A surrogate key is used as a unique key within each dimension table. The master data table and the dimension table are linked by system-generated identifications called Set IDs that are stored in Set ID (SID) tables. The master table contains attributes of characteristics, while the dimension table contains the representation of the characteristics. Master tables contain information that can be used by other InfoCubes. Thus, the dimension table with its associated SID table and its master data table builds one dimension.
1.3.4 Database Management System (DBMS)

The SAP BW database server, as the normal SAP R/3 database server, is based in a vendor product. The DB2 UDB for OS/390 Version 6.1 should be used as the hosting database manager. As an add-on to this database, there is a special interface called Integrated Call Level Interface (ICLI). For detailed
information about ICLI, refer to SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964.
1.3.5 Security
Access to reports that contain sensitive data must be restricted to authorized persons only. SAP BW provides various controls on different levels. Access rights may defined for a report as a whole, or for certain key figures (for example, salary in a personnel InfoCube), or even for specific values of a characteristic (for example, a certain cost center). You manage access rights with the Administrator Workbench.
1.3.6 The presentation layer

The presentation layer is made up of the normal SAPGui and the MS EXCELhosted Business Explorer; see Figure 3 on page 10. This interface is easy to understand and to use.
Figure 3. Business Explorer example
1.4 The terminology used in this redbook

Official titles of software can be quite long, and the problem is compounded when they are used in combinations. Also, these titles are commonly used in shorter versions by both the writers and readers of this redbook. Therefore, we decided to use the shorter versions in this publication (unless there was a likelihood of confusion over which specific product we are discussing); see Table 1 on page 11 for the titles we used.
10
Table 1. Official names and usage in this redbook
Official product name DB2 UDB for OS/390 SAP R/3 Application server SAP R/3 Database server SAP R/3 Central Instance SAP Business Information Warehouse SAP Business Information Warehouse Database Server SAP Business Information Warehouse Application Server SAP Business Information Warehouse Central Instance
Shorter version used in this redbook DB2 Application Server DB server Central Instance SAP BW or BW SAP BW DB server SAP BW Application server SAP BW Central Instance
11
12
Chapter 2. Our system environment

This chapter provides details about the systems we used during our tests. Because our tests were based on the functionality of the SAP Business Information Warehouse (BW), and the performance difference according to design options, we used only part of the S/390 system. As shown in Figure 4, we used: One S/390 LPAR with: One DB2 UDB 6.1 subsystem as the SAP BW database server One DB2 UDB 6.1 subsystem as the SAP R/3 database server One RS/6000 with AIX as an SAP BW application server One RS/6000 with AIX as an SAP R/3 application server Multiple Windows/NT machines as presentation servers (SAPGUI) FDDI connections between the database server and the application servers
RS/6000 F50
SAPGUI
9.12.0.73
SAP BW 1.2B Application Server

(Central instance)
T o k e n R i n g
T O K E N R I N G
9672-X77 (1 LPAR)
OS/390 V2R7
OSA
I C TOKEN- L I RING S E R V E R S
DB2 V6
DBH1
AIX 4.3.3
ALE
RS/6000 F50
DB2 V6
OSA
F D D I R I N G
DB2Q
SAP R/3 4.5B Application 9.12.0.75 Server

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

OS/390 was used as a database server for the SAP BW database and for the SAP R/3 production database.
2.1.1 Hardware
We used the following hardware in our tests:
Processor We used an IBM 9672-X77, which is a 7-way processor of the G6 family. We ran 15 LPARs on this processor, and the OS/390 system that we used for this redbook ran on one of the LPARs. We were given two shared processors at first and later were assigned two additional shared processors. All time estimates are related to the four-processor environment, unless stated otherwise.
We did not see any degradation of our LPAR from the other LPARs on our server. The OS/390 we ran always got as much power as it required. Even though the 9672-X77 ran in a Parallel Sysplex with three other 9672 machines and three Coupling Facilities, our LPAR did not participate in the sysplex. It worked as a standalone system.
Storage We had 1024 MB of real storage and 64 MB of expanded storage. We did not see any memory constraints. Enterprise Storage Server (ESS) We used 10 volumes of ESS DASD (Shark) for the source SAP R/3 databases, and 12 volumes of ESS DASD for the SAP BW database. After installation of SAP BW, all volumes had about 50 to 80 percent free space. We recommend that you have at least 10 volumes for SAP BW installation.
14
The ESS provides a highly available, scalable, easy-to-manage storage subsystem that complements the strengths of S/390. The logical disk architecture of the ESS spreads data across all the available disks, reducing the requirement for data placement to avoid hot spots. Additional physical storage capacity can be added nondisruptively. For more information about ESS, refer to Appendix D, Enterprise Storage Server (ESS) on page 115. The volumes resided on an IBM ESS subsystem which was connected by multiple controllers via switched ESCON. A pair of 2 volumes for each database used one controller. Each controller had 2 ESCON paths. All DASD was shared with the other LPARs. We did not see major impacts to our work from the I/O subsystem. The DASD response time we saw was about 3 to 5 milliseconds. Connectivity The OS/390 LPAR used two OSA-2 Adapters on the 9672-X77, which are also shared by other LPARs: The EN-TR OSA-2 Adapter connected to a 16 Mb token-ring LAN and was used for non-BW access to OS/390. The FDDI OSA-2 Adapter was used for all SAP BW and SAP R/3 application server-to-database server communication. These definitions are not specific for SAP R/3 or BW. For more information about connectivity, refer to SAP R/3 on DB2 for OS/390: Connectivity Guide, SC33-7965.
2.1.2 Software environment

We used the following software and customized the system based on the recommendations for our tests. 2.1.2.1 OS/390 Layout We used OS/390 Version 2.7 at RSU9907 with ahead maintenance we identified in OSS note 81737. Our operating system was produced by cloning from a master, which is the normal way to produce systems in ITSO.
Workload Manager (WLM) For our tests, the WLM setup was as simple as possible. We only used the system-provided service classes SYSTEM, SYSSTC, TSO and BATCH. SYSTEM is given distinct address spaces automatically. All other work, except BATCH or TSO, is in service class SYSSTC, including the DB2
15
address spaces and the ICLIs for a production SAP R/3 and BW. The definitions to the service classes apply to standard recommendations in the planning guide. See SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964 for details. We did not experience situations where one of our jobs or DB2 or ICLI was waiting for CPU, storage or DASD resources claimed by other address spaces in the system.
System Managed Storage (SMS) We defined SMS for SAP application databases as shown in Table 2. (We did not use SMS for DB2 system databases.)
Table 2. SMS naming convention for SAP applications
SAP BW appl. Number of volumes Storage group Storage class Management class Data class VSAM data set alias 12 SGSAPBW SAPBW default default SAPBW
SAP R/3 appl. 10 SGSAPR3 SAPR3 default default SAPR3
In all constructs, additional parameters, such as those used for performance or availability, were not used. Management class and data class were set corresponding to system standards. That specifically means that DB2 data sets are not migrated in any way. We changed an ACS routine (definition of storage class and storage group) to make these definitions effective. Figure 5 on page 17 shows the definition of the storage class. Figure 6 on page 17 shows the storage definition that connects storage class with storage group. Storage class SAPBW includes all data sets that use SAPBW as a first qualifier. All data sets that belong to storage class SAPBW are created in the volumes that belong to storage group SGSAPBW. Of course, 12 volumes were defined in the storage group SGSAPBW for the SAP BW application.
16
PROC STORCLAS FILTLIST JANLOG INCLUDE(DB2V510U.ARCHLOG%.**) FILTLIST SAPBWDS INCLUDE(SAPBW.**) FILTLIST SAPR3DS INCLUDE(SAPR3.**) /* FILTLIST REQ_SMS INCLUDE('LIBRARY','PIPE','HFS') */ .... WHEN (&DSN = &SAPBWDS) DO SET &STORCLAS = 'SAPBW' EXIT END WHEN (&DSN = &SAPR3DS) DO SET &STORCLAS = 'SAPR3' EXIT END .....
Figure 5. A storage class definition for SAP applications
PROC STORGRP WHEN ( &STORCLAS = DO SET &STORGRP EXIT END WHEN ( &STORCLAS DO SET &STORGRP EXIT END
'SAPBW' ) = 'SGSAPBW'
= 'SAPR3' ) = 'SGSAPR3'
Figure 6. A storage group definition for SAP applications
ICLI server Integrated Call Level Interface (ICLI) comes with OS/390 and provides a remote SQL connection between application servers and database servers. For SAP BW 1.2B, ICLI for SAP R/3 kernel 4.5B was needed. If your system does not have the ICLI component, ask your OS/390 system programmer to install it. See SAP OSS Note 81737 and the planning guide for more information about ICLI Server.
17
During the execution of R3SETUP for BW installation, one DB2 plan and three DB2 packages were created, as shown in Table 3, and the plan was granted to the user ID of ICLIRUN automatically. In our test, we used ICLIBLU as the ICLI server name, and user ID ICLIBLU as a user who runs ICLI server. Therefore, we granted user ID ICLIBLU the authority to run the plan explicitly, and authorized user ID ICLIBLU to run started task ICLIBLU in the RACF database. For more information about ICLI, refer to SAP R/3 on DB2 for OS/390: Implementing with AIX or WIndows NT Application Servers, SG24-4945. 2.1.2.2 DB2 layout We used DB2 V6.1 at PutLevel 9911 and checked Note 81737 for additional required maintenance. In order to test the functions of the SAP BW application, we needed test data. Possible sources to extract such data from, as described by SAP R/3, are: SAP R/3 SAP R/2 Non-SAP source We generated test data into flat files. We had two DB2 systems in the same OS/390, as shown in Table 3.
Table 3. Information about DB2 systems
SAP BW application DB2 subsystem name IRLM name HLQ of DB2 data set DB2 Load library ICLI plan name ICLI package name DBH1 IRH1 DB2V61H1 DSN610.SDSNLOAD (V6) FOMEP45B FOME45B1, FOME45B2, FOME45B3
SAP R/3 application DB2Q IRLQ DB2V610Q DSN610.SDSNLOAD (V6) FOMEP45B FOME45B1, FOME45B2, FOME45B3
All DB2 system parameters were configured as recommended in SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964. You can find the initial DB2 setup parameters of our DB2 system as shown in Appendix B, DB2 Installation parameters on page 97.
18
There are minor differences between SAP R/3 and BW, from the DB2 perspective. If you already have an SAP R/3 system at your location, you can refer to those DB2 system parameters for the SAP BW system; see the SAP BW Installation manual for details. 2.1.2.3 Network connectivity TCP/IP was used as the communication protocol between the OS/390 and RISC/6000 running AIX. Access to our OS/390 system for TSO was on a different LAN than the OSA-2 adapter that was used for OMVS. These LANs were both token rings, running 16 Mb. IBM Personal Communications was used for access TSO and OMVS. SAP and BW connectivity used the FDDI OSA-2 adapter in the 9672 that is shared by other LPARs. For more information about connectivity, refer to SAP R/3 on DB2 for OS/390: Connectivity Guide, SC33-7965, or ask your network administrator. We did not find any significant delays caused by connectivity during our tests. 2.1.2.4 User information Table 4 shows the user ID information at the database server. These definitions were all defined in RACF.
Table 4. User ID definitions
User ID
RACF group ID sapr3 (GID)
OMVS user
Remark Group ID
bluadm ICLIBLU SAPADM1, SAPADN2, SAPADM3
SAPR3 SAPR3 SAPR3
UID(0) UID(0)
SAP system administrator ID ICLI server user ID SAP user IDs for tests
ICLIBLU should be authorized to run ICLI server under its ID (RACF). SAPR3 should be defined and authorized properly by DB2 before the execution of R3SETUP.
2.2 AIX for SAP BW and R/3 application server

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

Before we installed the SAP BW code, we set up our SAP BW application server. We decided to use several variables, and defined them as shown in Table 5.
Table 5. SAP BW definitions
Our definition SAP system name SAP mount ICLI procedure name Hostname IP address Subnet mask FDDI interface LANG= BLU /sapcd ICLIBLU erprisc1 10.1.1.73 255.255.255.0 fi0 en_US
Remark 3 byte
20
Our definition
Remark
Language (additional) Language translation
ISO8859-1 German de_DE ISO8859-1
User information
Table 6. User ID information
User ID root bluadm sapadm1
UID 0 205 202
Remark
SAPGUI user
Volume information We created two volume groups in the physical volume, as shown in Table 7.
Table 7. Physical volume information
Volume group name sapgrp sap2grp
Physical volume hdisk3 hdisk2
Partition size 16 64
File systems and raw devices We allocated several file systems based on the recommendations in the installation manual. But during our test, we met several storage shortage problems, so we increased the size of those file systems. Table 8 shows the file system allocation after the SAP BW installation.
Table 8. File system allocation for SAP BW code installation
File system name /usr/sap/trans /sapmnt/BLU /usr/sap/BLU /tmp/install
Description Global transport directory for all SAP systems Instance-specific data, symbolic links to the data for one system Software and data for one SAP system Installation directory
Space used (# block) 514288 (200 MB) 622592 (300 MB) 786432 (380 MB) 622592 (300 MB)
Volume group sap2grp sapgrp sap2grp rootvg
Permission bits 771 755 755 775
21
2.2.4 System setup for SAP R/3

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

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

Lotus Smart Suite Release 9.5 Norton Anti-Virus Version 5.02.04 Adobe FrameMaker Version 5.5.6 IBM Personal Communication 3270 Version 4.3
What we installed in addition SAP Frontend GUI Version 4.5B

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

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

The following documentation will be useful during your preinstallation checking.
References
ChecklistInstallation Requirements: DB2 for OS/390, Material Number: 51006374 SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B , SC33-7964 Installation of the SAP Business Information Warehouse on UNIX DB2 for OS/390, Material Number: 51007613 R/3 Installation on UNIX: OS Dependencies , Material Number: 51005979 OSS Note #149473-DB2/390: 4.5B R/3 Installation on UNIX or WinNT OSS Note #81737-DB2/390: APAR List As a three-tier client/server application, SAP BW on DB2 for OS/390 requires certain hardware and software to be set up on the database server, on the central instance, and on the presentation server. You must also set up communication between them. Refer to ChecklistInstallation Requirements: DB2 for OS/390 51006374 for the hardware and software requirements needed for the SAP BW on DB2 for OS/390 installation. The database server for SAP BW on DB2 for OS/390 runs on any S/390 (or compatible) processor capable of supporting OS/390 Version 2.6 or higher. Connectivity from the database server can be achieved in various ways. By using ESCON channel feature(s) on the S/390 database server and ESCON channel adapter(s) on the gateway AIX application server(s). By using FDDI OSA-2 feature(s) on the S/390 database server and FDDI LAN adapter(s) on the gateway AIX or NT application server(s). By using Fast Ethernet OSA-2 features on the S/390 database server and FAST Ethernet adapter(s) on the gateway AIX or NT application server(s). By using OSA-EXPRESS Gigabit Ethernet feature(s) on the S/390 database server and Gigabit Ethernet PCI adapter(s) on the gateway AIX application server(s).
26
By using an ESCON, FDDI, or Fast Ethernet connection from the database server to a router (such as the IBM 2216 Multi protocol Router) and a LAN connection from that router to the gateway application servers. One of the means of connection in the preceding list must be used. Refer to SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964, and SAP R/3 on DB2 for OS390 Connectivity Guide, SC33-7965, for specific configuration information. The central instance runs on any processor that supports AIX Version 4.3.2 or higher, or Windows NT Version 4.0. The presentation service runs on Windows 3.1, Windows 95, Windows NT, Motif(UNIX), OS/2, and MacIntosh. Note that a Java version of the GUI is now also available.
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964, describes the preparatory steps and actual settings to be used during and after installation. The installation guide, Installation of the SAP Business Information Warehouse on UNIX DB2 for OS/390, 51007613, directs you to use the values from the SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B over the ones it has listed in the case that any should differ. The latest SAP R/3 planning guide for SAP R/3 will have the more recent information.
The R/3 Installation on UNIX: OS Dependencies booklet contains detailed information on the OS-dependent settings to be used. Review OSS Notes 142990 and 149473 to get the latest list of the installation requirements. Review OSS Note #81737-DB2/390: APAR List to get the latest information about the software fixes needed.
27
3.2 Defining the configuration

The hardware configuration you need for SAP BW installation is shown in Figure 7.
SA PBW C e n tral In sta nc e
D a ta b as e S e rve r
LAN
FD D I LAN
S A P P res e n tatio n S e rve r
O S /3 9 0 s ys tem d is k s
SAP BW DB2 da tabF s e d is k s DD a
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
28
System requirements for application server Processors

Real storage DASD (see 5.3, SAP BW pre-installation: system check on page 62) FDDI adapter or ESCON adapter AIX 4.3.3 or higher These should be verified as adequate by reviewing the Checklist-Installation Requirements: DB2 for OS/390. To ensure consistency of definitions between the database server and central instance, you need to compile all the definitions and parameters that require coordination as shown in Table 9, Table 10, and Table 11.
Table 9. User ID setup
Description SAP DB Owner ICLI server Submit job and OS/390 UNIX
Table 10. TCPIP definitions
User ID (your value)
TSO No No Yes
OMVS No Yes Yes
Description IP address IP name Device Address

Table 11. Other definitions
DBServer
Central Instance
Parameter Description ICLI connection port ICLI keep alive port SAP system name SAP system number DB2 subsystem name DB2 group attach name (Data Sharing only)
Your value
29
3.3 Installation prerequisites

Before the installation of SAP BW can begin, the S390 and the RS/6000 machines must be configured. However, in the prerequisites installation, some parameters must match between the database server and the central instance. Use Table 9, Table 10, and Table 11 on page 29 as references when installing the prerequisites.
3.3.1 Database server setup

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

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

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

The SAP BW installation includes thousands of indexes. Therefore, we recommend that you initialize the volumes that are associated with the DB2 STOGROUPs with a minimum Virtual Table of Contents (VTOC) size of 250 tracks (this recommendation is based on a 3390 DASD unit). During the installation of SAP BW, a large number of DB2 log records are generated. Therefore, DB2 logs must tolerate up to 2 GB per hour. Archiving is required and there must be at least 6 GB of archiving space if you have DASD archiving. Most of this space can be reclaimed when SAP BW on DB2 for OS/390 is up and running. Additionally, when you aggregate, you need a large temporary DB2 database (DSNDB07). You should prepare this temporary database before aggregation. Most of this space can be claimed after the aggregation process.
3.3.5 Configuring OSA-2 on the database server

Reference
MVS/ESA Hardware Configuration Definition: Users Guide, SC33-6468
The OSA-2 feature from the database server can be connected to the FDDI network as shown in Figure 8.
32
O S /3 9 0 C H P ID = 0 C 22C0 22C4 22 C5
IP = 1 0 .1 .1 .2 1 2
O S A -2 C on tro l U n it N um be r O S A -2 D evic e N um b e rs U n it A dd res s e s 0 0 /0 1
O S A -2 F e a tu re
FDD I LAN
F D D I R in g
FD D I A d a p te r IP = 1 0 .1 .1 .7 3 A IX o r W in d o ws N T
Figure 8. I/O configuration for the FDDI connection
See SAP R/3 Connectivity Guide, SC33-8965, for details on how to install and configure the OSA-2 adapter.
3.3.6 Installing DB2 for OS/390

References
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964 DB2 for OS/390 V5 Installation Guide, GC26-9008 BC SAP Database Administration Guide: DB2 for OS/390, Material Number: 51006377
The DB2 for OS/390 product must have been installed prior to the SAP BW on DB2 for OS/390 installation. After completing the SMP/E installation of the DB2 for OS/390 product, we continued with the setup of DB2 for OS/390 parameters by considering the recommended values given by SAP. For detailed information about DB2 preparation, refer to Chapter 4, Preparing DB2 on page 47.
33
3.3.7 Configuring SMS

References
DFSMS/MVS V1R5 Implementing System-Managed Storage, SC26-3123 DFSMS/MVS V1R5 DFSMSdfp Storage Administration Reference , SC26-4920 DFSMS/MVS V1R5 General Information , GC26-4900
SMS-managed storage is required to store hierarchical file system (HFS) data sets that are used by OS/390 UNIX. Define at least one volume on disk to be managed by SMS. With the SAP BW application, there a large number of DB2 tablespaces and indexes. We therefore strongly recommend that you use SMS-managed storage for SAP BW data sets efficiently. This will significantly reduce the amount of work you have to do to define DB2 Objects.
3.3.8 Customizing OS/390 UNIX

Reference
OS/390 UNIX System Service Planning, SC28-1890
Before customizing TCP/IP, you have to set up an OS/390 UNIX environment, according to the steps described in OS/390 UNIX System Services Planning, SC28-1890. Normal TCP/IP for OS/390 UNIX must also be set up according to the steps described in OS/390 UNIX System Services Planning. In our case, we used Standard TCP/IP connectivity over FDDI for the application server-to-database server communications.
3.3.9 Customizing TCP/IP on the database server

Reference
OS/390 SecureWay Communications Server: IP Configuration , SC31-8513
34
For successful ICLI server and client communication, the ICLI server must know which port to monitor for ICLI client connection requests. There are three methods for specifying the ICLI connection port to the ICLI server: 1. Specify the ICLI connection port in the OS/390 UNIX /etc/services file, in the <TCPIP>.ETC.SERVICE file, or in <ICLI user ID>.ETC.SERVICES. These files are interrogated in the order listed if the SERVICENAME or PORT is not specified as an argument to the fome45bs command. 2. Specify the ICLI connection port via the SERVICENAME argument of the fome45bs command. This will be used to interrogate the file(s) listed in option 1. The files will be searched in the order listed for a matching service name. 3. Specify the ICLI connection port via the PORT argument of the fome45bs command. This will override any port number derived from a service name. We recommend that you use the first method, except when you are running multiple ICLI servers in the same OS/390 LPAR. See Chapter 9 in SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B for details. The redbook team used the third method. 3.3.9.1 Service name and port entries The connection port used by ICLI and by ICLI keep-alive can be chosen freely from the available services. The values must match the specification in the services file and TPPARAM on the central instance. In our environment, we chose 33666 as the ICLI connection port, and 33667 as the ICLI keep-alive connection port. Note that the keep-alive port number is not necessary when using TCP/IP. We used the PORT argument of the fome45bs command to tell the ICLI server which port to monitor for ICLI client connection requests. We added the following entries to the OS/390 UNIX /etc/services file to document that the ports are in use.
# # SAP ICLI ports # fome45bs 33377/tcp
# SAP ICLI server port
35
3.3.10 Customizing the ICLI Server

Reference
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B ,
The steps to customize the ICLI server are as follows: Define the environment file. Define the start up JCL. The bind and grant activities required for the ICLI server are performed by R3SETUP during the central instance installation. For more information, see Chapter 4, Preparing DB2 on page 47. 3.3.10.1 Define the Environment File Following are the environment variables used by the ICLI server started task. In our test, this was defined in the file /u/bluadm/iclienv; see Figure 9.
TRACE=1 ICLI_TRACE_LEVEL=0 ICLI_MSGLEVEL=I ICLI_TRUSTED_CONNECTIONS=1 NLSPATH=/usr/lib/nls/msg/%L/$H STEPLIB=DSN610.SDSNLOAD
Figure 9. ICLI environment file
During the testing of ICLI, you can set the ICLI_TRACE_LEVEL to 1, 2, or 3. However, we recommend that when you load the database, and then begin running the system, you set the ICLI_TRACE_LEVEL to 0 to reduce the storage space requirement of the OS/390 UNIX HFS and provide better performance. 3.3.10.2 Define the startup JCL You can use the started task technique to start ICLI. The ICLI started task JCL can be put as a member in SYS1.PROCLIB or another PROCLIB. Figure 10 on page 37 is a copy of the ICLI server started task JCL, called ICLIBLU, that we used.
36
//********************************************************************* //* * //* * //* ICLI server startup for SAP BW on DB2 for OS/390 * //* * //* * //********************************************************************* //ICLIBLU EXEC PGM=BPXBATCH,TIME=NOLIMIT,REGION=200M, // PARM='PGM /usr/sbin/fome45bs -PLAN FOMEP45B -LOGDIR /u/bluadm/ -TCP // -PORT 33666' //STDENV DD PATH='/u/bluadm/iclienv' //STEPLIB DD DISP=SHR,DSN=DSN610.SDSNLOAD //STDERR DD PATH='/u/bluadm/icliserv.err', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=(SIRWXU) //STDOUT DD PATH='/u/bluadm/icliserv.out', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=(SIRWXU) //SYSUDUMP DD SYSOUT=* //SYSMDUMP DD SYSOUT=*
Figure 10. ICLI started procedure
You can use a copy of the file /u/bluadm/iclitask.jcl (where bluadm is SAP administrators ID) and adapt it to your needs. Remember to specify -TCP for the protocol in use. Note that it is possible to use //STDENV DD * and specify variables within this JCL stream. Some installations have found this to be convenient.
3.3.11 Customizing RACF or equivalent

References
OS/390 Security Server (RACF) Security , SC28-1915 OS/390 Security Server (RACF) Support for OpenEdition DCE, SOMobjects for MVS, and SystemView for MVS , GC28-1924
The following definitions should be established when you configure the security using RACF or equivalent: User definition OS/390 UNIX facility Started task protection
37
3.3.11.1 User definition The following user IDs must be defined to RACF: SAP DB owner (in our case, SAPR3) ICLI server user ID (in our case, ICLIBLU) SAP system administrator ID (in our case, BLUADM) The RACF commands that you can use to define the group and user ID are as follows:
ADDGROUP OMVSGRP OMVS(GID(1)) ADDUSER ICLIBLU DFLTGRP(OMVSGRP) OMVS(UID(0) HOME('/') PROGRAM('/bin/sh'))
Note that ICLIBLU is defined as an OS/390 UNIX user. The superuser has UID(0), and can bypass all file security, as well as run any administrative commands. 3.3.11.2 The OS/390 UNIX facility OS/390 UNIX uses a new RACF class, FACILITY, and the FACILITY class profile BPX.DAEMON. If they are not defined on your system, they can be defined with the following statements:
RDEFINE FACILITY BPX.DAEMON UACC(NONE) SETROPTS CLASSACT(FACILITY) SETROPTS RACLIST(FACILITY)
We created an OS/390 UNIX user ICLIBLU and granted it the class profile for daemon administration, BPX.DAEMON, as can be seen in the following RACF statements:
PERMIT BPX.DAEMON CLASS(FACILITY) ID(ICLIBLU) ACCESS(READ) SETROPTS RACLIST(FACILITY) REFRESH
3.3.11.3 ICLI started task We used the RACF STARTED class to associate the ICLIBLU user ID with the ICLI started task. When the ICLI procedure is started at the console, it runs as the ICLIBLU user.
38
RDEFINE STARTED ICLI.* STDATA(USER(ICLIBLU),GROUP(OMVSGRP)) SETROPTS RACLIST(STARTED) REFRESH
3.3.12 Set OS/390 dispatching and I/O priorities

For information concerning OS/390 dispatching and I/O priorities refer to Chapter 7 in SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B , SC33-7964. With SAP R/3 4.5B, the ICLI server uses an attachment to Workload Manager (WLM). In our test, we used WLM. In order to manage ICLI server work threads using WLM, we did the following: We defined the BPX.WLMSERVER profile in RACF:
RDEFINE FACILITY BPX.WLMSERVER
We gave ICLIBLU user ID read access to this profile:
PERMIT BPX.WLMSERVER ACCESS(READ) CLASS(FACILITY) ID(ICLIBLU)
We refreshed the access lists to put the changes into effect:
SETROPTS CLASSACT(FACILITY) REFRESH
We added a new WLM subsystem with the name SAP. To do this, we started the ISPF application of WLM, chose option 6 (classification rules), and used option 1 to create a new subsystem. The following entries were made in this subsystem definition:
39
Subsystem-Type Xref Notes Options Help -------------------------------------------------------------------------Modify Rules for the Subsystem Type Row 1 to 7 of 7 Command ===> ____________________________________________ SCROLL ===> PAGE Subsystem Type . : SAP Fold qualifier names? Description . . . WLM definition for SAP R/3 4.5B Action codes: A=After B=Before C=Copy D=Delete row M=Move R=Repeat Y (Y or N)
Action ____ ____ ____ ____ ____ ____ ____
-------Qualifier------------Type Name Start 1 UI 2 TN 2 TN 2 TN 2 TN 2 TN 2 TN ICLIBLU ___ GENERIC ___ DIALOG ___ UPDATE ___ UPDATE2 ___ SPOOL ___ BATCH ___
I=Insert rule IS=Insert Sub-rule More ===> -------Class-------Service Report DEFAULTS: SAPICLI ________ SAPICLI ________ SAPICLI ________ SAPICLI ________ SAPICLI ________ SAPICLI ________ SAPICLI ________ SAPICLI ________
3.3.13 Customizing TCP/IP on the central instance

References
Installation of the SAP Business Information Warehouse on UNIX DB2 for OS/390, Material Number 51007613
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964 BC SAP Database Administration Guide: DB2 for OS/390, Material Number: 51006377
On the central instance, we modified the /etc/hosts file. The R3SETUP tool adds the appropriate ICLI client and keeps alive port entries to the /etc/services and /usr/sap/trans/bin/TPPARAM files. 3.3.13.1 Hosts file We added the following entries to the /etc/hosts file:
40
10.1.1.212 10.1.1.73
wtsc62f #OS/390 address by UDP from AIX erprisc1 #AIX address by UDP from OS/390
3.3.13.2 Services file R3SETUP adds the following entries to the /etc/services file:
# SAP specific services sapdp00 3200/tcp # SAP R/3 dispatcher port | | v v sapdp99 3299/tcp sapgw00 3300/tcp # SAP R/3 gateway port | | v V sapgw99 3399/tcp sapmsBLU 3600/tcp # SAP R/3 message server port # ICLI specific services sapdb2BLU 33377/tcp # ICLI port iclikaBLU 33378/tcp # ICLI Keep Alive Port
41
3.3.14
Setting up the ICLI client

References
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964
BC SAP Database Administration Guide: DB2 for OS/390, Material Number: 51006377
The ICLI client code is provided in the OS/390 PTF containing the ICLI server. The executables FOME45BA(client) and FOME45BK(keep alive) can be found in the <HLQ>.SFOMDATA, where HLQ is the High Level Qualifier for your UNIX System Services data sets. R3SETUP will download these to the /sapmnt/<SAPSID>/exe directory and rename FOME45BA to ibmiclic.o and FOME45BK to ibmiclika. 3.3.14.1 ICLI client code The ICLI client code is downloaded by R3SETUP from the OS/390 system during the installation of the central instance. If the ICLI server on the OS/390 system is changed, you will have to manually transfer the members FOME<REL>A and FOME<REL>K from the OS/390 SYS1.SFOMDATA data set to the central instance. Rename FOME<REL>A to ibmiclic.o and FOME<REL>K ibmiclika, and place them in the /sapmnt/<SAPSID>/exe/ directory. Ensure that these files belong to <sapsid>adm and have permissions set to 755(-rwxr-xr-x).
Notes
<sapsid> is the SAP system name in lowercase. <SAPSID> is the SAP system name in uppercase.
3.3.15 Testing connectivity -- central instance and database server

The connectivity between the database server and the central instance can be tested by using the ping command from the central instance and oping from the database server. To test TCPIP protocol, we performed these commands: From the central instance: ping 10.1.1.212
42
From within OS/390 UNIX on the database server: oping -c 1 10.1.1.73 If the ping and oping commands are successful, then the connectivity between the database server and the central instance has been established.
3.4 Installing SAP BW on DB2 for OS/390

References
Installation of the SAP Business Information Warehouse on UNIX DB2 for OS/390, Material Number 51007613 SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B , SC33-7964
This section describes the steps we performed during the installation of SAP BW.
3.4.1 General notes on the installation from AIX

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

1. There is a large amount of print documentation about installation when using AIX and related topics contained in the \doc directory created in the
43
installation work directory when running INSTTOOL.SH. This documentation is HTML-based and can be viewed and printed with any Web browser. 2. Make sure that the worksheet has been prepared before executing the installation shell script and R3SETUP. 3. If you make a mistake in typing an answer during the build process of the command file, re-execute the build process from the beginning. One way to do this is to rename the current command file, CENTRAL.R3S for example. Then rename the initial command file CENTRAL.R3S.1 to CENTRAL.R3S. 4. The command file will be updated by the R3SETUP program during the install process. 5. To use the INSTGUI tool, you will need either Windows 95 or NT, or Motif installed on an AIX system. 6. To view the R3SETUP documentation and help files, you will need a browser that supports frames, such as Netscape. 7. The first time you start the R3SETUP program, it will ask if you want to use the graphical installation tool. If you answer Yes, it will start INSTGUI for you. 8. When you later need to restart the installation process, the INSTGUI program must be started before the R3SETUP program. The R3SETUP program must then be started with the following options:
R3SETUP -f <command file> -g <x-term_address>:61312
9. Every time R3SETUP is restarted, it will copy the log from the last run to a different file. The current log file will always have the name <command file>.log, while the old log is named <command file>.log.<number>. The file with the highest number will be the newest old log file. 10.We recommend restarting INSTGUI when you are restarting R3SETUP. The reason is that the number of errors and error messages shown by INSTGUI are accumulated from the previous failed R3SETUP runs. It can be difficult to determine which errors occurred in the current execution of R3SETUP if you do not restart INSTGUI also. 11.The percentage indication on the INSTGUI does not show the percentage of the actual work completed in hours. Instead, it shows the percentage of steps completed.
44
12.Each phase of the database load has a unique name. This name is assigned to the load process and log associated with a particular phase. If an error occurs with one of the processes, you must check two logs: DBBW.log and <process name>.log.
Reference
Installation of the SAP Business Information Warehouse on UNIX DB2 for OS/390, Material Number: 51007613
The SAP BW on DB2 for OS/390 installation can only be started if the network connection has been established between the database server and the central instance. Refer to 3.3.15, Testing connectivity -- central instance and database server on page 42. The steps needed for SAP BW installation are detailed in Chapter 5, Installing SAP BW OS/390 with AIX Application Servers on page 59.
45
46
Chapter 4. Preparing DB2

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

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

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

From an OS/390 perspective, these two items should be considered before installing the SAP BW code.
Large VTOC The SAP BW installation includes a very large number of data sets. It is therefore recommended that you initialize the volumes that are associated with the DB2 storage groups with a large VTOC that is at least 250 tracks on a 3390 DASD unit for BW application. (For SAP R/3 applications, 400 tracks are recommended.) Refer to SAP BW installation documentation for more information. Separate VSAM user catalog With regard to the VSAM catalog size of the SAP BW data sets, we recommend that you create a separate user catalog with a size of 20 cylinders for the primary allocation and 5 cylinders of secondary allocation. This is based on a 3390 DASD unit. If you are going to use the VSAM catalog of the DB2 subsystem, make sure that it is large enough to hold all the information contained in the SAP BW data sets.
4.4 Setting up RRS

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

For optimal operations and performance, SAP BW requires specific DB2 parameter settings. A few of them are considered mandatory, and these must be specified with the stated values in this section. If not, you will get errors at your execution of R3SETUP.
48
For the settings we used in our installation, refer to Appendix B, DB2 Installation parameters on page 97 .
Required DB2 system parameters Table 13 shows the required DB2 parameters for setting up SAP BW 1.2B. Most parameters are defined in DSNZPARM, while some are in DSNHDECP.
Table 13. DB2 parameter checked by R3SETUP (BW)
Parameter CACHEDYN DSMAX
Value Yes 7000
Remark Save prepared, dynamic SQL statement for later use. Maximum number of DB2 data sets open at a time. You can have up to 6660 data sets for tablespaces and indexes. Zero (0) means there is no limit to the number of page and row locks a program can acquire. US English in ASCII AIX. Defined in DSNHDECP. Specify the default format in which to store data in DB2. SAP BW application uses ASCII format data, defined in DSNHDECP. Class 1 provides information about system services and database statistics. Class 3 provides information about deadlocks and time-outs. SMF record type 102 should be defined. It does not allow a precision greater than 15 digits.
NUMLKUS ASCCSID ENSCHEME
0 819 ASCII
SMFSTAT
1,3
DECARTH DECIMAL
DEC15 . (period)
Recommended DB2 system parameters The recommended DB2 parameters are also listed under SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964. Invalid parameters in DB2 V6 The following parameters are no longer valid in DB2 Version 6:
ALPOOLX INBUFF OJPERFEH
49
Recommended IRLM parameters These values are defined in the IRLM start procedure:
Table 14. Highly recommended IRLM parameters
Parameter PC
Value Yes
Recommended value Yes puts the lock control block structure in the IRLM private address space, and the program call instruction is used to address to the structure. 5 specifies the local deadlock detection cycle. 1 specifies the number of local deadlock cycles that must expire before the IRLM performs global deadlock detection processing. This is used only for data sharing.
DEADLOK
5,1
Bufferpools allocation Table 15 shows the recommended DB2 bufferpool settings for SAP BW tablespaces, indexes, work files, and DB2 system databases.
Table 15. Recommended DB2 bufferpool allocation
Buffer pool BP0 (system) BP1 (work files) BP2 (4 KB tablespaces) BP3 (index spaces) BP4 (VB protocol) BP32K (tablespaces)
VPSIZE 5,000 5,000 20,000 30,000 1,000 2,000
VPSEQT 50 100 50 40 10 50
DWQT 50 70 30 30 70 30
VDWQT 10 50 5 5 50 5
HPSIZE 0 0 40,000 60,000 0 4,000
HPSEQT
CASTOUT
50 40
YES YES
50
YES
We recommend that you allocate BP0 as 5000 because the SAP BW application uses dynamic SQL, and because a large number of DB2 objects will be created.
4.6 DB2 system database requirements

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

In the installation process of SAP BW, a large number of DB2 objects are created as shown Table 12 on page 47. This requires a larger catalog and directory database than the default size. Table 16 shows the recommended values for DB2 installation panel DSNTPID, which generate a job that creates VSAM data sets for the DB2 catalog and directory database. For SAP BW applications, we recommend you refer to these values to estimate the size of the DB2 catalog and directory database as well as the size of main storage. When you are building a new DB2 system for an SAP BW application, you should use the values in Table 16 for DB2 the installation panel DSNTPID.
Table 16. DB2 installation panel DSNTPID
Field DATABASE TABLES COLUMNS VIEWS TABLESPACES PLANS PLAN statements PACKAGES PACKAGE statements PACKAGE lists EXECUTED statements TABLES in statement TEMP 4 KB SPACES TEMP 4 KB data sets TEMP 32 KB SPACES TEMP 32 KB data sets
Standard SAP recommended values 7000 3 20 1 1 100 30 200 30 2 30 2 See 4.11.2, DB2 temporary database (DSNDB07) on page 58 See 4.11.2, DB2 temporary database (DSNDB07) on page 58 40 MB 2
51
4.6.2 Additional DB2 catalog indexes

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

Good performance of DB2 logging is very important because the SAP BW installation executes heavy Data Definition Language (DDL), insert, update, and delete activity. During SAP BW installation, a large number of DB2 tables are created and a large number of rows are inserted, which causes a huge number of DB2 log records. In order to run the installation process effectively, we recommend the following: Create multiple (more than three) and large DB2 active log data sets to tolerate up to 2 GB per hour. We recommend that you have an entire 3390 volume available to use for a DB2 log data set. If you encounter a log data set shortage, R3SETUP will be abended. During the installation process for SAP BW, more than 6 GB of DB2 log records are generated. We recommend that you allocate at least 10 GB of DASD for a DB2 active log data. (With dual logging, you need double this amount.) In case you do not have enough DASD volumes for DB2 log, you probably could get at least four DB2 log data sets as shown in Figure 11 on page 53 with tape archiving. When a log data set DS01 is filled, log data set DS02 takes it over. You can then archive DS01 to tape without I/O contention. In the same way, when DS02 is filled, it is then switched to DS03. DS02 can be archived to tape, and so on.
52
LOGCOPY 1
LOGCOPY 2
DS01 DS03
DS02 DS04
DS01 DS03
DS02 DS04
Figure 11. Allocating DB2 active log data sets
Note the following recommendations: Use tape for archiving log data sets. Use dual logging and dual archiving. Do not share volumes on which DB2 log data sets reside with other highly active data sets. Turn on the DASD Fast Write feature if possible. Add as much non-volatile storage (NVS) as you can afford.
4.8 DB2 Binding for the ICLI server

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

In this section, we summarize the required DB2 authorization you need to implement in order to avoid the errors that can occur during the SAP BW installation process. Most privileges are automatically granted in the process of R3SETUP.
Table 18. DB2 authorization
User ID SAPR3
DB2 authority SYSADM
Remarks Some privileges are granted during R3SETUP automatically. But we recommend you grant SAPR3 as DB2 SYSADM. These are granted during R3SETUP automatically. If you use different a user ID under which the ICLI Server runs, you have to grant the required privileges to the new user ID manually.
ICLIRUN
Execute on plan FOMEP45B and TRACE, MONITOR1, MONITOR2
R3SETUP creates the bind and grant JCL with defaults, provides an opportunity to modify the defaults, and then submits the jobs. If you look at member SYS1.SAMPLIB(FOME45BG), you will see what kind of privileges and authorizations are granted during the installation process. Do not change the original job because the R3SETUP installation step needs the original version of the job. Instead, adapt a copy of the FOME45BG job to your requirements.
4.10 Maintaining DB2 catalog statistics

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

At installation In the SAP BW installation directory (in our test environment this was /tmp/install), there are several JCL templates for the RUNSTATS utility that are used during execution of R3SETUP.
54
At maintenance (delta update or aggregation) Sometimes the SAP BW system generates new DB2 objects that did not exist at data loading, delta updating, and so on. However, DB2 database administrators may not notice this, and therefore, they may not run the RUNSTATS utility for these new objects. This can result in the DB2 optimizer building less than optimal access paths with old statistical information about the data when you run analytical queries.
To avoid this situation, we strongly recommend that you build procedures using REXX, COBOL, or any other language that builds RUNSTATS jobs by querying the DB2 catalog.
4.10.2 Updating DB2 catalog statistics manually

Because many SAP BW tables start empty and grow very rapidly, for each OLAP query against InfoCube, a tablespace scan should be avoided even for a small or empty table, if there is an index that has at least one matching column for a given SQL statements predicates. Therefore, if you use DB2 Version 5, we recommend that after each RUNSTATS job, you always perform this set of catalog updates as shown in Figure 12 on page 56. These SQL statements update DB2 catalog information for small tables or empty tables. Of course, if RUNSTATS was run for few tables only, then it is reasonable to do the updates for those tables only by specifying database name, tablespace name and/or table name respectively. If you use DB2 Version 6, set new DSNZPARM parameter NPGTHRSH=10 to get the same result. You need DB2 APAR PQ33429 for this. For more information, refer to OSS note 192320.
55
UPDATE SYSIBM.SYSTABLES SET CARDF=50, NPAGES=10 WHERE CREATOR = 'SAPR3' AND TYPE='T' AND NPAGES <= 10; UPDATE SYSIBM.SYSTABLESPACE SET NACTIVE=10 WHERE CREATOR = 'SAPR3' AND NACTIVE <= 10; UPDATE SYSIBM.SYSTABSTATS SET CARD=50, NPAGES=10 WHERE OWNER = 'SAPR3' AND TSNAME IN (SELECT NAME FROM SYSIBM.SYSTABLESPACE WHERE CREATOR='SAPR3' AND NACTIVE <= 10) ; UPDATE SYSIBM.SYSINDEXES SET CLUSTERRATIO=0, FIRSTKEYCARDF=-1, FULLKEYCARDF=-1, NLEAF=-1, NLEVELS=-1 WHERE TBCREATOR = 'SAPR3' AND TBNAME IN (SELECT NAME FROM SYSIBM.SYSTABLES WHERE CREATOR='SAPR3' AND TYPE='T' AND NPAGES <= 10) ; UPDATE SYSIBM.SYSCOLUMNS SET COLCARDF=-1, HIGH2KEY='', LOW2KEY='' WHERE TBCREATOR='SAPR3' AND TBNAME IN (SELECT NAME FROM SYSIBM.SYSTABLES WHERE NPAGES <= 10); DELETE FROM SYSIBM.SYSCOLDIST WHERE TBOWNER = 'SAPR3' AND TBNAME IN (SELECT NAME FROM SYSIBM.SYSTABLES WHERE CREATOR='SAPR3' AND TYPE='T' AND NPAGES <= 10) ;
Figure 12. An example of DB2 catalog updates
4.10.3 Maintaining catalog statistics for R/3 cluster tables

This task is also needed for the SAP BW database; refer to SAP OSS note 83335. In DB2 for OS/390, the R/3 cluster tables need to be accessed in a special way: the access path should match the index scan, with the matching columns corresponding to the physical clusters key columns, and neither sort nor list prefetch should be selected. If the tables are not accessed in this way, there is a possibility of increased lock contention (including deadlocks).
56
In order to ensure that the cluster tables are accessed properly the catalog statistics for the cluster tables need to be maintained as shown Figure 13.
update sysibm.systables set npages=100, cardf=1000 where creator='SAPR3' and name in ( select tabname from sapr3.ddntt where tabform='T' and tabtype='C' with ur) ; update sysibm.sysindexes set clusterratio=100, fullkeycardf=1000 where tbcreator='SAPR3' and uniquerule='P' and tbname in ( select tabname from sapr3.ddntt where tabform='T' and tabtype='C' with ur) ;
Figure 13. Sample SQL statements for updating catalog statistics for cluster tables
If deadlocks occur even after catalog update, consider further updates as shown in Figure 14.
update sysibm.sysindexes set clusterratio=100, firstkeycardf=1000, fullkeycardf=1000 where tbcreator='SAPR3' and uniquerule='P' and tbname in ( select tabname from sapr3.ddntt where tabform='T' and tabtype='C' ) ; update sysibm.syscolumns set colcardf=1000 where tbcreator='SAPR3' and keyseq=1 and and tbname in ( select tabname from sapr3.ddntt where tabform='T' and tabtype='C' ) ;
Figure 14. Sample SQL statements to avoid deadlock
Monitor your system carefully in order to detect if these catalog changes adversely affect some access paths on the cluster tables. We recommend that you refer to the latest documentation of SAP; it is available as PDF files at:
http://www.s390.ibm.com/os390/bkserv/latest.html
57
4.11 Post-installation tasks

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

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

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

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

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

The SAP notes provide input important to the scheduling of installation activities, which if ignored usually result in an incomplete system that will soon be deleted. Some of the notes used by the redbook installation team are listed in Table 20. Your installation project will have to gather the applicable notes that are available at the time of your particular installation - the notes are being updated very regularly and new notes can be created at any time.
Table 20. SAPNet R/3 Frontend Notes
Reference item Note 103135 Note 113457 Note 116520
Reference item description DB2/390: Installing saposcol manually DB2/390: 4.5A Installation on UNIX or WinNT Installation/copying client 000 in the BW System
60
Reference item Note 118901 Note 121067 Note 135873 Note 137480 Note 142990 Note 144978 Note 149473 Note 149686 Note 154342 Note 165121 Note 165122 Note 169100 Note 175534 Note 176616 Note 178376 Note 187537 Note 197240 Note 77589 Note 81737
Reference item description DB2/390: Transports for 4.5A Help for BW notes Additional info on installation BW-BCT 1.2B INST: 4.5B R/3 Inst. on UNIX - OS Dependencies INST: 4.5B R/3 Installation on UNIX Your system has not been installed correctly SAP R/3 4.5B Installation on UNIX and Windows NT Known problems when applying BW patches Applying BW Patch with SPAM leads to error TW103 BW Translation error BW Translation error DB2/390: BW Rel. 1.2B SR1 Installation on UNIX or NT Large BW Systems and Performance of Aggregate build BW Statistics Problems w/ user exit variables with BW12B patch 12 SAPBWNews for BW 1.2B Support Package 16 SAP BW 1.2B performance patches DB2/390: tp profile parameters in TPPARAM APAR List for SAP R/3 on DB2 for OS/390
5.2.2 Searching for SAP notes

We searched for SAP notes based on the following criteria and updated our project plan for the additional activities: BW-SYS-DB-DB2 BW.SYS-DB-DB2 BW-DB-DB2 BW
61
5.2.3 Downloading patches and other information from SAPSERVx

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

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

Now it is time to take the information gathered in 5.2, SAP BW pre-installation: data gathering on page 60 and apply the recommendations to your system where appropriate, and to set aside any instructions that you will need later in the installation process. It is also time to verify that the base components of your database server and application servers are ready to support the installation of SAP BW OS/390 with DB2. You should have already installed and configured the base components of the solution by this point in time. These would include the software on the S/390 Database Server (OS/390, OS/390 UNIX, TCPIP, JES, DB2) and the software
62
on the AIX or NT Application Server (AIX, TCPIP, NFS/mounts, etc.). The information necessary to configure these components is found in: SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964 SAP R/3 on DB2 for OS/390: Connectivity Guide, SC33-7965 R/3 Installation on UNIX OS Dependencies , Material Number 51005979 In addition, the manual R/3 Installation on UNIX DB2 for OS390, Release 4.5B, Material Number 51006375 may prove to be useful since installing SAP R/3 is nearly identical to installing SAP BW. We found that R3SETUP looks for adequate free disk space during the installation, and we were forced to make the changes before continuing with R3SETUP. The file system sizes we used for the redbook project are contained in Table 21:
Table 21. AIX file system layout
File system/directory name /sapmnt/<sid> /usr/sap/<sid> /usr/sap/trans /tmp/install directory for Export CD copy
File system space defined 327 MB 393 MB 393 MB 100 MB 700 MB
At this time you should verify that all software maintenance is current or at least equal to the minimum information contained in Note 81737. Always obtain the most recent copy of Note 81737, as the information changes regularly. Dont forget to install the German language fileset on the AIX Application Server. While we have not been able to find a written requirement for this, we have found nonetheless that it is necessary. You can check this with the AIX command locale -a, and then look for the two languages in Table 22.
Table 22. AIX language filesets
Language fileset English German
Output from locale -a command en_US.ISO8859-1 de_DE.ISO8859-1
63
Now apply the remaining information from the data gathered in 5.2, SAP BW pre-installation: data gathering on page 60.
5.4 SAP BW pre-installation: final preparation phase

The first activity in the final preparation phase is to ensure that you have all of the information necessary to answer the installation script questions contained in Table 23. Table 23 shows you the parameters you will need to specify to R3SETUP and the values we used for the redbook project, and it also has a place to record the values used during your installation of R/3.
Table 23. R3SETUP input required
R3SETUP variable name SAP BW system name SAP BW system number SAP BW installation directory SAP BW global directory SAP BW CD-ROM location (on application server) Message Server port number (3600 + SAP system #) R/2 Gateway Sysplex Failover (yes or no) Sysplex Failover Hostname Sysplex Failover Port # Pass Tickets (yes or no) DB2 subsystem name DB2 Group Attach name DBServer hostname OS/390 UNIX
Our value BLU 00 /tmp/install sapmnt/BLU/exe /sapcd 3600
Your value
no no
no DBH1
wtsc62oe
64
R3SETUP variable name DBServer hostname - FTP & Telnet DB2 plan name for ICLI server DB2 load library name DB2 runlib library name DB2 Usercat name for BW data JES held job class ICLI port number User ID for ICLI Server User ID for ftp to OS/390 (uid=0 & DB2 sysadm) OS/390 ICLI code location SAPOSCOL install (yes for now, no for later) SAPOSCOL destination (RFC destination name) SAPOSCOL gw host (hostname gw service runs on) SAPOSCOL gw service (from /etc/services) SAPOSCOL code directory in OS/390 Open Edition (any OS/390 UNIX directory)
Our value wtsc62 FOMEP45B DSN610.LOADLIB DB2V6H1.RUNLIB SAPBW X 33377 ICLIBLU BLUADM SYS1.FOMEDATA no BWBLU erprisc1
Your value
sapgw00 /u/<sid>/SAPOSCOL
It is also necessary to know how to code a jobcard for a batch job. If you do not know the format of your organizations job card, ask your system programmer to print you a hardcopy. The final preparation activity is to draw a diagram of your entire SAP BW environment. Such a diagram is useful to refer to both during R3SETUP and
65
later as a record of your installation. If feasible, ask the project team to review it; this gives them an opportunity to see the entire system at a glance.
5.5 SAP BW installation

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

Do not start this activity until you have obtained the values for your installation, as noted in Table 23 on page 64, to use as input to R3SETUP. Use the instructions contained in Installation of the SAP Business Information Warehouse on UNIX DB2 for OS/390, Release 1.2B SR-1, 51007613. Additionally, you may want to reference the latest version of the R/3 installation guide, R/3 Installation on UNIX DB2 for OS/390 , 51006375. Pay close attention to the spelling and capitalization of commands and responses. The command we entered to start the SAP BW Central Instance Application Server installation was: ./R3SETUP -f CENTRAL.R3S
66
The command we entered to start the SAP BW Database Server installation was: ./R3SETUP -f DBBW.R3S Keep in mind that the installation of SAP products via R3SETUP and INSTGUI is an interactive and iterative process. The GUI interface provided by SAP prompts you to enter installation configuration information, and will probably be stopped and restarted several times. Dont get frustrated if this happens more than you expected. It merely suggests that you probably could have spent more time preparing for the installation. Additionally, there are a few tips in 5.5.4, R3SETUP problem solving on page 68 to help you with this task.
5.5.2 Building the BW database

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

The database load is more CPU-intensive than previous installation steps. This is because the DB2 database is being loaded with data via INSERT SQL statements from the R3SETUP program. You will notice that both the ICLI and DB2 are accumulating service units. Keep in mind that, after the installation is completed and your system is running as a productive environment, the majority of resource consumption will be attributed to the ICLI server task. There are some steps that will automatically execute after the data is actually loaded into DB2, and then you will be prompted to check the JCL and command syntax that was created for the five DB2 RUNSTATS jobs. Check these jobs for accuracy and either allow the system to try to run automatically or EXIT R3SETUP and run them manually (dont forget to update the R3SETUP control file with STATUS=OK if you run them manually). R3SETUP will then perform some more steps on your behalf and without your intervention, until you see the message: ./R3SETUP finished.
67
Note: SAP recommends that you do not modify the installation log files unless you know exactly what you are doing. Be sure that you are comfortable performing a reinstallation from the beginning if you should happen to do this incorrectly or inadvertently.
5.5.4 R3SETUP problem solving

We have provided a few problem-solving hints in Table 25 that may help you if you should encounter problems during R3SETUP. However, it is expected that you will have a certified SAP installer onsite to perform your installation. As always, do not forget to make use of SAPNet R/3 Frontend to search for the latest information regarding installation.
Table 25. R3SETUP problem-solving tips
Problem encountered R3SETUP getting started
Possible solution Check spelling, punctuation, and capitalization (e.g. ./R3SETUP -f CENTRAL.R3S e.g. ./R3SETUP -f DBBW.R3S) Find someone familiar with exporting the display. See if you can run without the INSTGUI. Was the DECHDECP module linked with all of the parms in the planning guide? Does ping work? Does traceroute follow the correct path? Are ICLI and DB2 started? Look up ICLI messages in Appendix E of the SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B. Did you make the correct authorizations? Does TPPARAM have the required entries? Is the TP_DOMAIN_<SID> file correct? Is the problem with R3trans or tp? Search for SAP Notes. Ftp the jobs to OS/390 and manually run them from there. Dont forget to update the STATUS field in the R3SETUP.R3S file to the value OK. Check the JES2 parm SWA=ABOVE for STC. Ask BASIS team or consulting partner to assist and request customer IDs. Ask BASIS team or consulting partner to assist and request customer IDs.
INSTGUI doesnt work
Connection to DB2 doesnt work
RUNSTATS - submission or return code problems
Cant logon to service.sap.com Cant logon to sapservx
68
Problem encountered Not sure what the problem is SAPGUI - incorrect installation message
Possible solution Check OS/390 UNIX file systems (df -k). Check AIX file systems (df -k). Check contents of table INSTVERS; if there are two rows with the same timestamp, change the second entry timestamp to be 1 second later; save your changes. Check SAPNet R/3 Frontend for notes.
SAPGUI - screen SAPMSYST in German
5.6 SAP BW post installation: completing the install

Update the profile files (located in /usr/sap/<SID>/SYS/profile/) with the recommended values from SAP and the pertinent values for your site. The parameters in Table 26 were set for our environment.
Table 26. R/3 Profile parameter changes.
Profile parameters <SID>/system_language=E start_menu=RS00 rsdb/obj/buffersize=32768 rsdb/obj/large_buffer_size=32768 rdisp/max_wprun_time=900
Values Set default language to English. Set default start menu to SAP BW Administrator Workbench. See Note 156957. See Note 156957. See Note 25528.
Stop SAP BW and restart it to activate your profile changes. Initialize the transport environment via SE06 and STMS. SAP provides information on how to do this in the online documentation CD-ROM. Log on as SAP* & Client 000 and use transaction SE06 to initialize your SAP BW environment as a single system environment (or multi, if you know your landscape). Activate your system via transaction STMS. Apply the SPAM update that is available for your SAP BW 1.2B BASIS kernel level (ours was 4.5B). At this point you are able to apply the mandatory transports that are described in the SAP Notes. Start the application of SAP BW Support Patches. Since our version of SAP BW was 1.2B with SR1, the next Support Patch to be added started with number nine and ended with
69
number seventeen. You can check the level of SPAM and applied Support Packages on your system via transaction SPAM. Fill out the paperwork to request a license from SAP. This takes only a few minutes and is best done as soon as possible. Fax the form to the SAP number that is pre-printed on the form. SAP is quite speedy and will probably have a response to your license request within 24 hours. Start a client copy of client 000 to client 100, and choose the profile SAP_ALL. Now its time to run backups. Create JCL to perform OS/390 Full Volume Dumps of all volumes, and also scheduled tape backups of your AIX Application Server.
5.6.1 Summary of the BW database

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

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

At installation time there were 17 BW patches for SAP BW 1.2B. The early CD-ROMs that were shipped will require all of the BW patches to be applied. The CD-ROMs that are marked as SR1 already have the first eight BW patches included, so that will only require the remaining patches to be applied.
71
Be very attentive to notes that refer to BW patch installation. Failure to import the packages according to the documented procedure will result in many hours of recovery activities and possibly a reinstallation of the code. An example of this is that the SPAM version delivered on the SR1 Release is 4.5B/0000. The latest SPAM that we applied updated the SPAM version to 4.5B/0004 (and it was the same patch number - SAPKD00027). The latest Business Explorer patch applied was number nine, and is described in SAP Note 0190332.
5.7 Installing the R/3 PlugIn PI 99 or PI-A 99 for SAP BW

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

It is imperative to find as much information as possible to support the installation of the SAP BW PlugIn. The first stop should be the SAPNet R/3 Frontend, to look for OSS Notes. The next stop should be to look for the specific installation guide for your particular PlugIn. Another useful document is the Consultants Guide, ASAP for BW Accelerator; see your SAP business consulting partner if you do not already have a copy.
5.7.2 PlugIn -A 99 pre-installation: system check

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

Obtain a copy of the SAP R/3 pre-installation documentation from your R/3 install in case you need to reference any of the specific install data. If possible, it would be useful to have a BASIS-skilled person who was present for the SAP R/3 install to assist in the install of the PlugIn. Additionally, it is a good idea to have someone experienced in SAP R/3 upgrades perform the actual console work. Table 30 shows the PlugIn variables you will need to set and the values we used for the redbook project, and it also has a place to record the values used during your installation of the PlugIn.
Table 30. PlugIn variables
PlugIn variable name mode scroll
Our value
Your value
73
PlugIn variable name <SID> mount point procedure directory kernel path instance name instance number CI host name DBServer host name Database <SID> mount directories # of processes language help R3startup profile name profile path/name WHT
Our value
Your value
/sapcd/PIA9945b /home/whtadm /usr/sap/WHT/SYS/exe/run WHT 01 erprisc2 WTSC62F WHT /sapcd/PIA9945b option 1 E START_DVEBMGS01_erp risc2 /usrp/sap/WHT/SYS/profile WHT/DVEBMGS01_erpris c2 /usr/sap/WHT/SYS/profile DEFAULT.PFL 19920706 erprisc2 60 (default) NONE import /sapcd/PIA9945b salamanca LOCK
default profile/name DDIC password batch server host name synch. time other software start import mount point R/3 keyword lock dev environment
74
5.7.4 PlugIn -A 99 installation

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

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

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

We have provided a few Internet locations where you can find a lot of information to make the installation go smoother. The URLs listed in Table 31 require an SAP logon and password.
Table 31. Useful URLs - SAP logon required
Useful URLs Part 1 service.sap.com service.sap.com/bw service.sap.com/ocs-download service.sap.com/instguides service.sap.com/notes sapserv3 / sapserv4 / sapservx
What it is SAPNet R/3 Frontend Home Page SAP BW Home Page SAP Download Home Page SAP Installation and Reference Guides SAPNet R/3 Frontend Notes Search SAP Anonymous FTP Servers
76
The URLs listed in Table 32 are available via the public Internet.
Table 32. Useful URLs - Public
Useful URLs Part 2 www.sap.com www.sap.com/bw service.software.ibm.com/support/s390 service.software.ibm.com/support/rs6000 www.pc.ibm.com/support www.ibm.com/erp
What it is SAP Home Page SAP BW home Page IBM S390 service IBM RS6000 service IBM NT service IBM ERP Solutions
77
78
Chapter 6. Managing SAP BW database

In principle, you can perform management tasks at three different levels: 1. Inside SAP BW, using the administrators workbench 2. Inside SAP R/3, using the DBA tools 3. At the DB2 level, using traditional utilities In practice, however, we recommend that you first look to the SAP BW administrators workbench to perform the tasks, then to the SAP R/3 tools, and, as a last resort, to OS/390.
6.1 Administrators workbench

Use the administrators workbench to perform the following tasks: 1. Index management for the fact table a. Quite often it is better to do a load into a table that has no associated indexes, rather than maintaining the indexes during the load. Using the administrators workbench, you have the option of controlling the drop and recreation of indexes against the fact table of the InfoCube during the load (or incremental load). b. You also have the choice to recreate the indexes unconnected to any load activity. This is done with normal SQL. 2. Maintaining statistics for the fact table a. The DB2 optimizer needs information about the tables and indexes involved in a query. This information has to be gathered if the table changed significantly. You have the option of controlling the gathering of information after the load (or incremental load). b. You also have the option of running the statistics independent of any load activity. To initiate this task, SAP BW submits batch jobs with FTP to OS/390. To establish an FTP connection, you must ensure the following: - You have TSO access and a TSO user ID. - Your SAP R/3 user ID is identical to the TSO user ID. - The SAP R/3 system is aware of your TSO password, (you must call transaction DB2J and choose Password to enter your password).
79
To run the jobs on OS/390 successfully, you have to adapt some Profile Parameters with the help of transaction DB2J. For more information, see Chapter 4 in BC SAP Database Administration Guide: DB2 for OS/390, 51003810.
Table 33. TP parameters for JCL submitted with FTP out of SAP R/3
Profile Parameters DB2 run library MGMTCLAS, STORCLAS, DATACLAS(SMS) Volume count Partitioned data set Console -> Console output data set
Description Library that contains DSNTIAD. Optional parameters. If not specified, the defaults of the corresponding SMS ACS routine are used. Overwrites the value defined in DATACLAS, if needed. Existing partitioned data set for uploading OS/390 jobs. Sequential data set for receiving the required part of the System Log. It must exist and will be overwritten by the next request. The format must be: Organization: PS Record format: VB Record length: 133 Block size: 27930
6.2 SAP R/3 tools

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

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

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

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

To load the ODS, we started by going to the administrator workbench and clicking the ODS tabstrip in order to see the ODS catalog. Before loading the ODS, we changed the storage parameter of the ODS table to avoid running out of DASD space. The name of the ODS table is /BIC/B<10-digit-number>. Unfortunately, <10-digit-number> is an internal generic identifier which the ODS catalog does not show. To identify <10-digit-number> we checked the ODS catalog to find out the technical name of the appropriate ODS request set (not the one for InfoSource). Then we used the data browser (transaction SE16) to query table RSTSODS and specify the technical name of the ODS as ODSNAME. The name of the ODS table is retrieved in field ODSNAME_TECH of table RSTSODS. At this point, we used the database utility (transaction SE14) to change the storage parameter of the ODS table. See R/3 on DB2 for OS/390 Database Administration Guide for detailed instructions about this task. To actually load the ODS, we clicked the InfoSources tabstrip at the administrator workbench and right-clicked the InfoPackage we wanted to load to get into the InfoPackage Scheduler. (We decided to load the ODS only and update the corresponding InfoCube later. Therefore, we clicked the Data
83
target tabstrip and selected Only ODS.) After clicking the Schedule tabstrip we started the load. To improve performance we changed the parameter IDocsSize from 10,000 to 100,000. You may gain improvements in overall runtime, if you load the data in parallel. To achieve this you may have to add more batch processes on the application server or may consider to add another application server for this task.
7.2 Updating the InfoCube

After loading the ODS, we wanted to update the InfoCube, which means applying all defined update rules to transfer the ODS data into the InfoCube. During this process, a large number of insert operations is performed on the InfoCube fact table. In order to speed up the InfoCube update, we first dropped indexes on the fact table. This can be done using SAP BW features; see 6.1, Administrators workbench on page 79. At the administrator workbench InfoCube panel, we right-clicked our InfoCube to get to the InfoCube Performance panel. Clicking Delete indexes drops the indexes on the fact table. The Delete InfoCube indexes after each data load and then recreate and the Also delete and then recreate indexes with each delta upload options force SAP BW to delete indexes on the fact table before updating the InfoCube and recreating indexes afterwards. However, as we wanted to update several requests in parallel, we did not use these options; that is, we unmarked both fields. Instead, we deleted the indexes by clicking Delete indexes and selected Repair indexes after the entire upload was done. We did this because we did not want one update job to rebuild the indexes while another update job was still active. After the deletion of the indexes, we went to the ODS panel at the administrator workbench. The content of the ODS was listed by InfoSources. To see all requests that belong to one InfoSource, the corresponding node must be expanded. Only requests that fit user-defined selection criteria are displayed. Select Setting --> Display selection for ODS tree to maintain these criteria. For every request we wanted to update into the InfoCube, we right-clicked the request and chose Update the request. A SAP batch job was scheduled, which performs the update.
84
Note: You have to allocate a sufficient amount of DB2 work space for rebuilding the indexes. We used a dedicated bufferpool in DB2 for the DB2 work space Consider also running these updates in parallel, in which case you should switch off the automatic index rebuild (see Chapter 6, Managing SAP BW database on page 79) and start it manually after the updates. You might also have to add more application servers and batch processes.
7.3 Aggregate build

When the data is in the InfoCube, you can run queries against it. However, depending on the amount of data, some queries might run for a long time. If these queries are used frequently, you should think of defining aggregates. Aggregates store data in a summarized form in order to avoid doing calculations during reporting. See SAP BW documentation for detailed information on defining and using aggregates. At the administrator workbench, we choose the InfoCubes panel and right-clicked our InfoCube in order to switch to the Maintain InfoCube aggregates panel. A list of all defined aggregates was displayed. We selected an aggregate we wanted to fill by highlighting the appropriate row. Then we chose Fill (function key F6) to fill the aggregate. You have to provide DB2 work space for building the aggregates. We did not find any formula to calculate the amount needed. But to give you an idea, we had roughly twenty million rows in the fact table requiring roughly 5 IBM 3390-002 volumes, including all indexes, and assigned 32 IBM 3390-002 volumes 4K work spaces to build the aggregates. This is definitely an upper boundary, but we did not get more precise figures.
7.4 .Running queries

Beginning with DB2 Version 6, the query optimizer has a new feature added called Star Join (APAR PQ28813). It is especially designed for queries that run against a star schema or extended star schema set of tables. Star Join can be enabled or disabled with a parameter in DNZPARM. DB2 has to be restarted to activate Star Join. Since the data model of SAP BW is a star schema (see 1.3.3, BW data structures on page 6), we expected query performance improvements. To confirm this, we performed some tests.
85
Our observation was that the amount of improvement depends on the number of selected rows in the fact table. One test case showed no difference in query performance. However, in another test where we selected roughly twice as many rows as in the first case, we saw an improvement of one-third in runtime. Keep in mind that Star Join might have an adverse effect on the performance of other queries, so it is up to you to decide whether to use it or not.
7.5 Incremental DataPackage update

Usually the data in an InfoCube is updated periodically, which means that an additional request is updated into the InfoCube. When doing this, however, you have to decide whether or not the indexes of the fact table should be dropped during the update in order to increase insert performance. For example, there might be reporting being done on the InfoCube while the update is done and indexes deletion might be not feasible due to a decrease in reporting performance. After uploading a new request, we had to take care of the defined aggregates. The process of updating aggregates content is known as roll-up. At the administrator workbench panel InfoCubes, we right-clicked the InfoCube to get to the InfoCube Performance panel. We clicked tabstrip Roll up of the InfoCube. After entering the highest RequestId we wanted to roll up, we clicked Execute to start the roll-up job.
7.6 Partitioning tables in SAP BW

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

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

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

This chapter describes considerations you should keep in mind when deciding how to size an S/390 system that runs BW. The considerations are based on recommendations published by SAP in the document Sizing and Performance, ASAP for SAP BW Accelerator, Document Version 1.1, available on SAPNet. What resources you need in order to achieve a particular throughput and response time depends on several factors, such as the number of users and the amount of online and background operations. When this redbook was written, there was no sizing data available on the S/390 platform based on benchmarks or production environments. Therefore, conclusions in this chapter are preliminary. For BW sizing guidelines, contact the IBM SAP International Competence Center (ISICC) by e-mail at this address: infoserv@de.ibm.com
8.1 Special considerations for BW applications

BW applications are considered to be complex in terms of the following: The amount of data being stored for rough data over time The amount of data being stored for aggregates, predefined summarization levels, and so on The relationships between the data stored (star scheme) The amount of data you store is highly dependent upon your data definitions. For example, you can have many predefined reports or just a few, and you can allow many concurrent users or just a few. You can build additional indexes for your tables if some of them are used very often. In addition, use of the DB2 explain feature, the DB2 Performance Monitor (DB2PM), or other tools may provide you with performance data or information that leads you to do partitioning or to allow more processors to work in parallel, resizing buffer pools or changing thresholds. Even with all that, you may still experience elapsed times or resource consumptions that you did not expect because BW systems typically perform online query processing. In other words you cannot predict what any of your users will do at any time. The good news in all this is, modern database systems like DB2 have highly sophisticated mechanisms to optimize the internal work that they have to do
89
to satisfy a given query. To demonstrate this, run an aggregate job or a query against tables that have never had RUNSTATS run against them. We did this and saw differences in runtime of factors of 50 and more. DB2 Version 6 offers you new functions to do the RUNSTATS automatically, along with reorgs and table loading. You absolutely should use that option. A consequence for sizing considerations obviously is that all values for database size, CPU consumptions, network traffic and, of course, elapsed times are not comparable with other installations. In addition, during our studies we received some code changes for the BW application that decreased runtimes significantly. For these reasons, we do not supply here any absolute results of runtimes or resource consumption because such results would have no meaning for you; you would not be able to use them to predict reliable results for your existing or any planned environment.
8.1.1 BW administration tasks

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

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

In complex environments like BW applications, a good approach is to try to come as close as possible to a right-sized environment iteratively. Normally, the introduction of BW applications is a project that can be divided into phases, with milestones at the end of each phase. This is also a safe way to prove sizing estimates, and you can do this at the same time. This approach is described in the next section.
8.2.1 Pre-installation and planning phase

You can estimate DASD storage needs, CPU consumption, and memory with the help of tools or by comparing your installation with other, similar installations. The use of tools requires input like the following: The SAP applications you are running The data that you plan to load from the SAP R/3 applications into BW The maximum number of users defined in the system The maximum number of users working in parallel The average number of users working in parallel What the users would probably do (to get a feeling how heavy the load is that they are producing)
91
At this point you may have to estimate these values because you do not know all possible users in your company, or whether they will like the application and how they will use it. The tools will give you values that will not be exactly right for you, but they should not be too far off, as long as you do not deviate from the standards and the defaults of SAP BW. There are tools available to do that. They are not all available for customer use but IBM or SAP can help you by running them in the pre-installation phase and providing you with the results. At the end of this phase you can order the product and the hardware you need to run it, at least for the next phase.
8.2.2 Pilot or evaluation phase

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

With the knowledge gained during the evaluation phase, you are now able to estimate what you will need for production (going live, in terms of SAP). You can compare that with the very first estimates you got to verify what you derived from defaults or tool-input values. It is normal to have these values differ, because in a BW project, the requirements on the BW application typically are subject to continuous changes, as end users see more and more possibilities of how to use it. In fact, an education or learning step is usually included in this phase, which will additionally show the users what they could have.
8.2.4 Running BW
Even in this phase (which is probably neverending) you may see changes (not necessarily always growth) in the amount of data being stored, or changes in the CPU consumption and elapsed time, but you will have gained experience during the earlier phases on how the growth of data impacts these factors. If your measurements were sufficient, you will even be able to predict these impacts. The reason for the ongoing administration is that a BW application is subject to continuously changing queries since the market and the data from which strategic decisions are to be derived are continuously changing as well. As a consequence, the tuning of a BW application is really an ongoing process. You may decide to have one or more people exclusively responsible for BW administration. The value of the system is only as good as the results obtained, which obviously depends primarily on the quality of the queries. Good administration will guarantee that you get your results quickly and that they are most nearly actual, and that you can easily retrieve most results for the end user (who could be one of your business managers looking for data to use as a basis for an important decision).
93
94
Appendix A. Whats new in SAP BW 2.0

In SAP BW 2.0, several changes will be made. Some changes are: New user interface of the administration workbench Introduction of new InfoCube types SAP BW monitoring Handling of the ODS data Performance improvements in several areas, like aggregation and reporting However, most of what is written in this redbook is also valid for SAP BW 2.0. In this appendix, we describe two new features that are relevant for SAP BW on OS/390, which have an impact on the procedures we did during our test session. For detailed information about features of SAP BW 2.0B, refer to: 1. Exploitation of DSNUTILS stored procedures SAP BW performs mass processing that often leads to a significant number of changes in several tables. To ensure optimal access path generation, the SAP BW system updates the DB2 statistic after these changes are performed. SAP BW 1.2B uses the FTP job submission service feature to run the RUNSTATS utility. Starting with SAP BW Release 2.0B, the appropriate DSNUTILS stored procedure is issued instead. This guarantees a very fast and stable way for the statistics update. 2. Partitioning of fact tables SAP BW 2.0B supports partitioning of fact tables based on time characteristics. This gives the BW administrator the ability to handle even huge InfoCubes by an easy-to-use interface. All maintenance tasks, like creation and deletion of partitions, are done by the BW system. With SAP BW 2.0B, partitioning is restricted to fiscal period (info object 0FISCPER) and calendar month (info object 0CALMONTH).
95
96
Appendix B. DB2 Installation parameters

In this appendix, we list DB2 parameters we used in our test system. Some are shown in DSNZPARM and others by using SAP transactions.
B.1 DSNZPARM
//DBH1E JOB (999,POK),'DBH1 INSTALL',CLASS=A,MSGCLASS=T, // NOTIFY=HAIMO,TIME=1440,REGION=0M /*JOBPARM L=9999,SYSAFF=SC62 //*********************************************************************/ //* JOB NAME = DSNTIJUZ */ //* */ //* DESCRIPTIVE NAME = INSTALLATION JOB STREAM */ //* */ //* LICENSED MATERIALS - PROPERTY OF IBM */ //* 5645-DB2 */ //* (C) COPYRIGHT 1982, 1998 IBM CORP. ALL RIGHTS RESERVED. */ //* */ //* STATUS = VERSION 6 */ //* */ //* FUNCTION = DSNZPARM AND DSNHDECP UPDATES */ //* */ //* PSEUDOCODE = */ //* DSNTIZA STEP ASSEMBLE DSN6.... MACROS, CREATE DSNZPARM */ //* DSNTIZL STEP LINK EDIT DSNZPARM */ //* DSNTLOG STEP UPDATE PASSWORDS */ //* DSNTIZP STEP ASSEMBLE DSNHDECP DATA-ONLY LOAD MODULE */ //* DSNTIZQ STEP LINK EDIT DSNHDECP LOAD MODULE */ //* DSNTIMQ STEP SMP/E PROCESSING FOR DSNHDECP */ //* */ //* NOTES = STEP DSNTIMQ MUST BE CUSTOMIZED FOR SMP. SEE THE NOTES */ //* NOTES PRECEDING STEP DSNTIMQ BEFORE RUNNING THIS JOB. */ //* */ //*********************************************************************/ //* //DSNTIZA EXEC PGM=ASMA90,PARM='OBJECT,NODECK' //SYSLIB DD DISP=SHR, // DSN=DSN610.SDSNMACS // DD DISP=SHR, // DSN=SYS1.MACLIB //SYSLIN DD DSN=&&LOADSET(DSNTILMM),DISP=(NEW,PASS), // UNIT=SYSALLDA, // SPACE=(800,(50,50,2)),DCB=(BLKSIZE=800) //SYSPRINT DD SYSOUT=*
97
//SYSUDUMP DD //SYSUT1 DD //SYSUT2 DD //SYSUT3 DD //SYSIN DD DSN6ENV DSN6SPRM
SYSOUT=* UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) * MVS=XA RESTART, ALL, ABEXP=YES, ABIND=YES, AUTH=YES, AUTHCACH=1024, BINDNV=BINDADD, BMPTOUT=4, CACHEDYN=YES, CACHEPAC=32768, CACHERAC=32768, CATALOG=DB2V61H1, CDSSRDEF=1, CHGDC=NO, CONTSTOR=YES, <-- WAS NO DECDIV3=NO, DEFLTID=IBMUSER, DESCSTAT=NO, DLITOUT=6, DSMAX=6000, <-- WAS 3000 EDMPOOL=80000, <-- WAS 14812 EDMDSPAC=0, EDPROP=NO, HOPAUTH=BOTH, IRLMAUT=YES, IRLMPRC=IRH1PROC, IRLMSID=IRH1, IRLMRWT=600, <-- WAS 60 IRLMSWT=300, LEMAX=20, MAXRBLK=100000, <-- WAS 4000 MAXKEEPD=16000, <-- WAS 5000 NPGTHRSH=10, <-- WAS 10000 NUMLKTS=1000, NUMLKUS=0, <-- WAS 10000 OPTHINTS=NO, PARAMDEG=0, RECALL=YES, RECALLD=120, RELCURHL=YES, RETLWAIT=0,
98
DSN6ARVP
DSN6LOGP
RETVLCFK=NO, RGFCOLID=DSNRGCOL, RGFDBNAM=DSNRGFDB, RGFDEDPL=NO, RGFDEFLT=ACCEPT, RGFESCP=, RGFFULLQ=YES, RGFINSTL=NO, RGFNMORT=DSN_REGISTER_OBJT, RGFNMPRT=DSN_REGISTER_APPL, RRULOCK=NO, SEQCACH=BYPASS, SEQPRES=NO, SITETYP=LOCALSITE, SRTPOOL=1000, STARJOIN=DISABLE, <-- or ENABLE SYSADM=HAIMO, SYSADM2=HAHN, SYSOPR1=SYSOPR, SYSOPR2=SYSOPR, TRKRSITE=NO, UTIMOUT=3, <-- WAS 6 DEFAULT XLKUPDLT=YES <-- WAS NO APAR PQ18915 ALCUNIT=BLK, ARCWRTC=(1,3,4), ARCWTOR=YES, ARCPFX1=DB2V61H1.ARCHLOG1, ARCPFX2=DB2V61H1.ARCHLOG2, ARCRETN=9999, BLKSIZE=28672, CATALOG=NO, COMPACT=NO, PRIQTY=1234, PROTECT=NO, QUIESCE=585, <-- WAS 5 SECQTY=154, TSTAMP=NO, UNIT=3390, UNIT2= DEALLCT=(0), MAXARCH=1000, MAXRTU=2, OUTBUFF=4000, TWOACTV=YES, TWOARCH=YES, WRTHRSH=20, ARC2FRST=NO
99
DSN6SYSP
DSN6FAC
AUDITST=NO, BACKODUR=5, CONDBAT=64, CTHREAD=120, <-- WAS 70 DBPROTCL=DRDA, DLDFREQ=5, DSSTIME=5, EXTRAREQ=100, EXTRASRV=100, IDBACK=20, IDFORE=40, IDXBPOOL=BP0, LBACKOUT=AUTO, LOBVALA=2048, LOBVALS=2048, LOGAPSTG=10, LOGLOAD=50000, MAXDBAT=64, MON=NO, MONSIZE=1000000, <-- WAS 8192 PCLOSEN=5, PCLOSET=10, RLF=NO, RLFTBL=01, RLFERR=NOLIMIT, RLFAUTH=SYSIBM, ROUTCDE=(1), EXTSEC=NO, SMFACCT=(1,2,3), <-- WAS 1 SMFSTAT=(1,3), <-- WAS YES STATIME=30, STORMXAB=0, STORPROC=DBH1SPAS, STORTIME=180, TBSBPOOL=BP0, TRACSTR=NO, TRACTBL=16, URCHKTH=1, <-- WAS 0 WLMENV= DDF=AUTO, CMTSTAT=ACTIVE, IDTHTOIN=0, RESYNC=2, RLFERRD=NOLIMIT, TCPALVER=NO, MAXTYPE1=0, TCPKPALV=ENABLE,
100
DSN6GRP
POOLINAC=120 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 DSNAA INCLUDE ADSNLOAD(DSNAA) INCLUDE ADSNLOAD(DSNFSYSP) INCLUDE ADSNLOAD(DSNJARVP) INCLUDE ADSNLOAD(DSNJLOGP) INCLUDE ADSNLOAD(DSNTSPRM) INCLUDE ADSNLOAD(DSNVDIR1) INCLUDE ADSNLOAD(DSNZMSTR) INCLUDE ADSNLOAD(DSN3DIR1) INCLUDE ADSNLOAD(DSN7GRP) ENTRY DSNZMSTR NAME DSNZPARM(R) //* //* CHANGE LOG INVENTORY: //* UPDATE BSDS //* //DSNTLOG EXEC PGM=DSNJU003,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=DSN610.SDSNLOAD //SYSUT1 DD DISP=OLD,DSN=DB2V61H1.BSDS01 //SYSUT2 DD DISP=OLD,DSN=DB2V61H1.BSDS02 //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=*
101
//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 0 AMCCSID=65534, AGCCSID=65534, SCCSID=37, MCCSID=65534, GCCSID=65534, ENSCHEME=ASCII, <--WAS EBCDIC DATE=ISO, DATELEN=0, DECARTH=DEC15, DECIMAL=PERIOD, DEFLANG=IBMCOB, DELIM=DEFAULT, MIXED=NO, SQLDELI=DEFAULT, DSQLDELI=APOST, SSID=DBH1, STDSQL=NO, TIME=ISO, TIMELEN=0, DYNRULS=YES, LC_CTYPE=, COMPAT=OFF END //* //*********************************************************************
102
//* 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 DSNAA INCLUDE ADSNLOAD(DSNAA) INCLUDE ADSNLOAD(DSNARIB) INCLUDE ADSNLOAD(DSNHDECP) ENTRY DSNHDECP MODE AMODE(24),RMODE(24) NAME DSNHDECP(R)
//*
B.2 IRLMPROC
//IRH1PROC PROC RGN=5000K, // LIB='DSN610.SDXRRESL', // IRLMNM=IRH1, // IRLMID=1, // SCOPE=LOCAL, // DEADLOK='5,1', // MAXCSA=6, // PC=YES, // MAXUSRS=7, // IRLMGRP=, // LOCKTAB=, // TRACE=NO // EXEC PGM=DXRRLM00,DPRTY=(15,15), // PARM=(&IRLMNM,&IRLMID,&SCOPE,&DEADLOK,&MAXCSA,&PC, // &MAXUSRS,&IRLMGRP,&LOCKTAB,&TRACE),
103
// REGION=&RGN //STEPLIB DD DSN=&LIB,DISP=SHR //SYSABEND DD SYSOUT=*
B.3 DB2 parameters using a SAP transaction

You can get the following figures by using SAP transaction ST04 and selecting Installation Parameters in the displayed panel.
Figure 15. DB2 installation parameters
104
Figure 16. DB2 buffer pool allocation
Figure 17. DB2 storage sizes and connections
105
Figure 18. DB2 trace
Figure 19. DB2 locks and IRLM definition
106
Figure 20. DB2 archive log parameters
Figure 21. DB2 active log parameters
107
Figure 22. DB2 application parameters
Figure 23. DB2 operation and DDF parameters
108
Appendix C. How to set up RRS

RRS uses five log streams (defined in a couple data set) that are shared by the systems in a sysplex. (In a monoplex environment, you can use a DASD-only log stream.) Every OS/390 image with RRS running needs access to a Coupling Facility and the DASD on which the system logger log streams are defined. The five RRS logs are: RRS RRS RRS RRS RRS archive log (optional) resource manager data log main unit of recovery (UR) state log delayed UR state log restart log
The OS/390 system logger component manages log streams based on the policy information in the LOGR couple data set. The use of a primary and an alternate couple data set is recommended. You need to follow these steps to set up RRS: 1. Add subsystem entries to the SYS1.PARMLIB(IEFSSNxx): SUBSYS SUBNAME(LOGR) INITRTN(IXGSSINT) SUBSYS SUBNAME(RRS) - Issue the SETSSI command to dynamically define the new subsystem: SETSSI ADD,SUBNAME=RRS 2. Define the couple data set and activate the OS/390 system logger. Whether you are running in sysplex or monoplex mode, you have to define a couple data set and activate your system logger. a. Check whether the system logger is already active by issuing the following command from the SDSF panel: D LOGGER,CONN b. If the system logger is not active, define the LOGR couple data sets by using the JCL shown in Figure 24 on page 110. The IXCL1DSU utility formats LOGR, a couple data set.
109
//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) /*
Figure 24. Sample JCL to define an RRS LOGR couple data set
c. Modify the SYS1.PARMLIB(COUPLExx) member to add the couple data set definitions (see Figure 25).
/**********************************************/ /* SAMPLE SYS1.PARMLIB COUPLExx MEMBER */ /**********************************************/ COUPLE SYSPLEX(&SYSPLEX.) PCOUPLE(SYS1.XCF.CDS02) ACOUPLE(SYS1.XCF.CDS03) CLEANUP(30) RETRY(10) DATA TYPE(LOGR) PCOUPLE(SYS1.XCF.LOGR00) ACOUPLE(SYS1.XCF.LOGR01)
Figure 25. Sample couple data set definition
d. To activate the system logger, you can IPL the system. If you want to bring the LOGR couple data sets online without re-IPLing the system, issue the following SETXCF commands: SETXCF COUPLE,TYPE=LOGR,PCOUPLE=(primary_couple_data_set)
110
SETXCF COUPLE,TYPE=LOGR,ACOUPLE=(alternate_couple_data_set) 3. Set up the RRS log streams. a. Ensure that the system logger is already active by issuing the command: D LOGGER,CONN b. Define the log streams for RRS using the sample JCL shown in Figure 26 on page 112. The IXCMIAPU utility adds, updates, lists, or deletes policy data on the LOGR couple data set.
111
//BI390B JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=BI390B //*********************************************************** //* SAMPLE JCL TO DEFINE LOGSTREAMS FOR RRS //*********************************************************** //LOGRPOL EXEC PGM=IXCMIAPU //STEPLIB DD DSN=SYS1.MIGLIB,DISP=SHR //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 LOGSTREAM NAME(ATR.PLEX57.ARCHIVE) DASDONLY(YES) HLQ(LOGR) MODEL(NO) LS_SIZE(1024) STG_SIZE(1024) LOWOFFLOAD(0) HIGHOFFLOAD(80) RETPD(15) AUTODELETE(YES) DEFINE LOGSTREAM NAME(ATR.PLEX57.RM.DATA) DASDONLY(YES) HLQ(LOGR) MODEL(NO) LS_SIZE(1024) STG_SIZE(1024) LOWOFFLOAD(0) HIGHOFFLOAD(80) RETPD(15) AUTODELETE(YES) DEFINE LOGSTREAM NAME(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 LOGSTREAM NAME(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 LOGSTREAM NAME(ATR.PLEX57.RESTART) DASDONLY(YES) HLQ(LOGR) MODEL(NO) LS_SIZE(1024) STG_SIZE(1024) LOWOFFLOAD(0) HIGHOFFLOAD(80) RETPD(15) AUTODELETE(YES)
Figure 26. Sample JCL to define RRS log streams
112
Note
In the previous sample, the RRS log streams are defined on DASD only. If you plan to use RRS across a sysplex environment, you must define the RRS log streams in the Coupling Facility. Review the parameters accordingly. 4. Establish the priority of the RRS address space. The priority of RRS should be higher than other resource managers, such as DB2, CICS, and IMS, and lower than JES and VTAM. 5. Define the RRS subsystem. a. Create the RRS started task procedure, shown in Figure 27, in the SYS1.PROCLIB(RRS).
//RRS PROC GNAME='',CTMEM='' //******************************************************************** //* SAMPLE RRS STARTED TASK PROCEDURE //******************************************************************** //* //* o GNAME=rrsgroupname //* o CTMEM=ctracemembername //* //* Examples of valid parameter strings: //* //* PARM='GNAME=PLEX1 CTMEM=CTIRRS00' //* PARM='CTMEM=CTIRRS00 GNAME=PLEX1' //* PARM='GNAME=PLEX1 ' //* PARM=' CTMEM=CTIRRS00 ' //* //********************************************************************* //RRS EXEC PGM=ATRIMIKE,REGION=0M,TIME=NOLIMIT, // PARM='GNAME=&GNAME CTMEM=&CTMEM' //
Figure 27. Sample RRS started task procedure
6. Start RRS by entering the following command from SYSLOG: START RRS,SUB=MSTR If you need to stop RRS, you can use the SETATRRS CANCEL or FORCE RRS,ARM commands.
113
Automatically activate RRS To activate RRS automatically at each IPL, add the START RRS command in the SYS1.PARMLIB(COMMNDxx) member.
COM=START RRS
114
Appendix D. Enterprise Storage Server (ESS)

This appendix gives the reader who is unfamiliar with the Enterprise Storage Server (ESS) an overview of the device architecture and its unique functions. The ESS is a high-performance RAID-5 storage subsystem, and is a member of the Seascape family. It consists of a storage server and attached disk storage devices. The storage server provides integrated caching and RAID support for the attached disk devices. The ESS can be configured in a variety of ways to provide scalability in capacity and performance. Redundancy within the ESS provides continuous availability. It is packaged in one or more enclosures, each with dual line cords and redundant power. The redundant power system allows the ESS to continue normal operation when one of the line cords is deactivated. The ESS provides the image of a set of logical disk devices to attached servers. The logical devices are configured to emulate disk device types that are compatible with the attached servers. The logical devices access a logical volume that is implemented using multiple disk drives. The following host I/O interface attachments are supported: SCSI-3 Parallel Interface ESCON FC-AL FICON On SCSI-3 interfaces, the ESS emulates a variety of fixed-block devices with either 512 or 520 byte blocks. SCSI-3 is, in general, a superset of SCSI-2. A SCSI-3 disk device can be attached to a SCSI-2 initiator, provided the cabling can be interfaced. Many SCSI-2 initiators attach directly to the cabling specified for the SCSI-3 parallel interface, but are referred to as SCSI-2 initiators because they limit their use of the command set to the SCSI-2 subset. Host systems with SCSI-2 or SCSI-3 interfaces can attach to the ESS. The ESS provides multiple SCSI I/O interfaces (busses), each with multiple SCSI targets, and each with multiple disk logical units. The storage provided by the ESS for SCSI interfaces can be configured so that it is shared among multiple SCSI interfaces if desired.
115
On ESCON interfaces, the ESS emulates one or more IBM 3990 control units attaching variable size IBM 3390 devices in either 3390 or 3380 track format. The ESS provides multiple ESCON interfaces that provide a set of control unit images, each with multiple disk devices. The storage provided by the ESS for ESCON interfaces is configured so that it is accessible from any ESCON interface. The ESS is composed of the following components: The storage server is composed of two clusters that provide the facilities with advanced functions to control and manage data transfer. Should one cluster fail, the remaining cluster can take over the functions of the failing cluster. A cluster is composed of the following subcomponents: Host Adapters - Each cluster has one or more host adapters (HAs). Each host adapter provides one or more host I/O interfaces. A host adapter can communicate with either cluster complex. Device Adapters - Each cluster has one or more device adapters (DAs). Each device adapter provides one or more storage device interfaces. Disk drives are attached to a pair of device adapters, one in each cluster, so that the drives are accessible from either cluster. At any given time, a disk drive is managed by only one device adapter. Cluster Complex - The cluster complex provides the management functions for the ESS. It consists of cluster processors, cluster memory, cache, nonvolatile storage (NVS), and related logic. Cluster Processor - The cluster complex contains four cluster processors (CP) configured as symmetrical multiprocessors (SMP). The cluster processors execute the licensed internal code that controls operation of the cluster. Cluster memory/cache - This is used to store instructions and data for the cluster processors. The cache memory is used to store cached data from the disk drives. The cache memory is accessible by the local cluster complex, by device adapters in the local cluster, and by host adapters in either cluster. Nonvolatile storage (NVS) - This is used to store a nonvolatile copy of active written data. The NVS is accessible to either cluster-processor complex and to host adapters in either cluster. Data may also be transferred between the NVS and cache. Disk Drives - These provide the primary nonvolatile storage medium for any host data stored within the ESS Storage devices. They are grouped into ranks and are managed by the clusters.
116
As a member of the IBM Seascape family, the ESS provides the outboard intelligence required by SAN solutions, offloading key functions from host servers, which frees up valuable processing power for applications. As a comprehensive SAN-based storage solution, the ESS provides considerable management flexibility to meet the fast-paced requirements of the next century. Among the many factors that make the IBM ESS an ideal solution are: Support of all major server platforms including S/390, AS/400, Windows NT, and many varieties of UNIX Fiber channel attachment capability Extensive storage management capabilities through a Web interface used to manage the ESS logical configuration Excellent scalability: - From 400 GB to over 11 TB - Simple selection from 16 standard configurations to meet capacity and performance needs Performance optimized to your heterogeneous environment needs: - High bandwidth and advanced transaction processing capabilities provide solutions for both online and batch applications - Innovations such as Parallel Access Volumes to reduce resource contention and dramatically improve performance through the elimination or reduction of IOSQ for single-host environments - Multiple allegiance, which allows you to dramatically reduce or eliminate IOSQ time for a multiple-host environment - Performance-enhanced CCW commands - I/O priority queuing, which allows users to define the priority of application workloads - Custom volumes, which allows you to create your own custom-sized logical volumes Availability required to support e-business applications - Business continuity through remote copy services - PPRC and XRC - Rapid data duplication through FlashCopy, providing extensive capabilities to exploit, manage, and protect your information in a 24 x 7 environment
Appendix D. Enterprise Storage Server (ESS)
117
- Peer-to-Peer Remote Copy (PPRC), which allows you to create synchronous volume copies via ESCON channels - Extended Remote Copy (XRC), which allows you to create asynchronous volume copies over long distances - Concurrent Copy (CC), which allows you to create volume or data set copies, locally and non-disruptively Storage server availability through redundancy and non-disruptive service with design for no single point of failure or repair More information is available through not only the ESS product manuals, but also a suite of IBM redbooks, including: IBM Enterprise Storage Server, SG24-5465 Implementing the IBM ESS in Your Environment, SG24-5420 Implementing ESS Copy Services in a S/390 Environment , SG24-5680 Implementing ESS Copy Services in a UNIX/NT Environment , SG24-5757 These books are available through the ITSO Web page at:
www.redbooks.ibm.com.
118
Appendix E. Special notices

This publication is intended to help S/390 technical specialists, DB2 database administrators, and SAP Basis consultants to implement SAP BW 1.2B on S/390. The information in this publication is not intended as the specification of any programming interfaces that are provided by SAP or IBM. Contact SAP for more information about what publications are considered to be product documentation. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The information about non-IBM ("vendor") products in this manual has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no
119
guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment. This document contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples contain the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. Reference to PTF numbers that have not been released through the normal distribution process does not imply general availability. The purpose of including these reference numbers is to alert IBM customers to specific information relative to the implementation of the PTF when it becomes available to each customer according to the normal IBM PTF distribution process. The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:
AIX DFSMS/MVS ESCON Netfinity OS/390 UNIX S/390 DB2 DFSMSdfp FICON OS/390 Parallel Sysplex IBM
The following terms are trademarks of other companies: Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything. Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli, and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems Inc., an IBM company, in the United States, other countries, or both. In Denmark, Tivoli is a trademark licensed from Kjbenhavns Sommer - Tivoli A/S. C-bus is a trademark of Corollary, Inc. in the United States and/or other
120
countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries. PC Direct is a trademark of Ziff Communications Company in the United States and/or other countries and is used by IBM Corporation under license. ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.
Appendix E. Special notices
121
122
Appendix F. Related publications

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

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

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

These publications are also relevant as further information sources:
123
SAP R/3 on DB2 for OS/390: Planning Guide SAP R/3 Release 4.5B, SC33-7964 SAP R/3 on DB2 for OS/390: Connectivity Guide, SC33-7965 MVS/ESA Hardware Configuration Definition: Users Guide, SC33-6468 OS/390 UNIX System Service Planning, SC28-1890
Installation of the SAP Business Information Warehouse on UNIX DB2 for OS/390, Release 1.2B SR-1, 51007613
BC SAP Database Administration Guide: DB2 for OS/390, Material Number: 51006377 R/3 Installation on UNIX DB2 for OS/390, 51006375 DB2 UDB for OS/390 Version 6 Installation Guide, SC26-9008 DB2 UDB for OS/390 Utility Guide and Reference Version 6 , SC26-9015
F.4 Referenced Web sites

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

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

Please send me the following: Title Order Number Quantity
First name Company
Last name
Address City Telephone number Invoice to customer number Credit card number
Postal code Telefax number
Country VAT number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment.
126
Glossary
access plan. Plan generated by the DB2 Optimizer of how to access the data in the tables being queried. Administrator Workbench. A tool to control how the data gets from the source systems into the InfoCubes of the Business Information Warehouse. It is used to request and manage data in the source system, InfoSource, InfoCube, InfoObject, Scheduler, and Monitor. aggregation. The process of summarizing atomic (detailed) level data horizontally, vertically and chronologically. BAPI. Business Application Programming Interfaces 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 source system (or systems) and putting it into a warehouse-usable form. data loading. A process of loading data from source systems into the BW InfoCube. data mart. A decision support environment that addresses the common decision support needs of a specific group within the organization (typically a department or geographic area). In BW data marts can be created by queries on a specific aggregate. data warehouse. A database that contains summarized data created from transactional data 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 last extraction. See also full update. dimension. Grouping characteristics that belong together from a content point of view. For example, a customer dimension may contain the customer number, the customer group, and the levels of customer hierarchy. drill down. A technique that allows you to explore the detailed data that was used in creating summary level data. In BW, this is one of the navigation techniques. fact table. A table that contains all key figures (facts) of the InfoCube. It is the central table in the star schema. flat file. A file that contains text. It is used to load information into the data warehouse. It can be comma-delimited, fixed-width, or variable width. full update. A type of database update. Replaces all data. See also delta update. granularity. The level of detail contained in a single record of the fact table. The coarser the granularity, the more the data is summarized before storage. InfoCube. A multidimensional central data container for queries and evaluations. Contains two types of data: key figures and characteristics. InfoObject. Generic term for characteristics and key figures. InfoPackage. A description of data that should be requested from a source system. informational data. Data created from operational data, stored in a format that makes easier business analysis. Analysis can be in the form of decision support (queries), report generation, Executive Information Systems, or statistical analysis. InfoSource. A quantity of InfoObjects grouped together from a business point of view. It can contain 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 place for a significant period of time. Serves as a source system for a data warehouse.
127
master data. Data that remains unchanged over a long period time, for example, customer names and addresses. meta data. Data about data. Meta data describes format, origin, history, and other aspects of data. meta data repository. It contains the various classes of meta data. Monitor. Monitoring tool of the Administrator Workbench to oversee the data request and processing in the Administrator Workbench. multidimensional database. A specialized database that is designed to enable the querying and viewing of large volumes of data based on predefined dimensions such as geography, customer, and product. multidimensional table. See multidimensional database. navigation. Analysis of the InfoCube by displaying different views of the data of a query. navigation attributes. Attributes that allow you to present different views of the data. N-way system. A system with two or more CPUs. OLAP. Online analytical processing. A type of processing used to analyze summarized online transaction processing (OLTP) data. OLAP allows multidimensional views and analysis of that data for decision support processes. OLTP. Online transaction processing. A type of processing of operational data. operational data. Data that is used to run a companys business. It is stored, retrieved, and updated by an OLTP system. operational data store (ODS). An integrated database that contains a copy of extracted data from source systems. query. A selection of InfoObjects (characteristics and key figures) for analysis of the data in an InfoCube. scheduler. The nexus between the source systems and the InfoCubes. schema. The logical and physical definition of data elements, for example, a star schema.
source system. Every system that is available in the Business Warehouse for data extraction. staging engine. Implements data mapping and data transformation during the data loading process. It extracts data from a source system. star schema. A data structure that combines fact tables and dimension tables in a way that provides easy and efficient access to data. SQL. Structured Query Language. A language developed by IBM that provides access to relational database. table. An array of data in a table form. It consists of columns (data values of the same type) and rows (data records). Each record can be identified uniquely by one or several fields. table index. Index used to accelerate data selection from a table. It is similar to a copy of the table reduced to certain fields only and always sorted. think time. The time that the end user spends between two key presses. transaction data. Operational data provided by an OLTP system.
128
Index A
ABAP 4 access plan 127 Administrator Workbench 6, 79, 127 aggregate build 85 aggregation 58 application server 13, 19 setup 31 catalog updates 55 DSNDB07 58 DSNTPID 51 log 52 objects 47 optimizer 79 prerequisites 47 PTFs 47 reorganization 58 RUNSTATS 54, 91 temporary database 58 DB2 parameters 49 debugging 66 delta update 127 dimension 8, 127 dimension table 8 dispatching priority 39 documentation SAP R/3 installation 43 drill down 127
BAPI 5, 127 Business Content (BCT) 6, 22 Business Explorer 5, 9, 127 BW application sizing 91 tuning 91 BW database backup/recovery 81 data loading 67 partitioning 86 BW Patch 71 BWGUI 71
E
Enterprise Storage Server (ESS) 14 ESCON 15, 26
C
characteristic 7, 127 configuration for this study 28 ICLI 36 SMS 34 TCP/IP 42 connectivity 15, 19 testing 31 CRM 1
fact table 7, 127 Fast Ethernet OSA-2 26 FDDI adapter 20 connection 13 Driver 20 FDDI OSA-2 26 full update 127
D
data mart 7, 127 data warehouse 4, 127 database server 13, 14 setup 30 DB2 additional DB2 catalog indexes 52 authorization 54 bufferpools 50 catalog and directory 50
H
hardware application server 19 configuration 28 database server 14
I
ICLI client setup 42 customizing 36
129
environment file 36 security 38 ICLI packages 18 ICLI plan 18 ICLI server 17 customizing 36 DB2 binding 53 startup JCL 36 ICLIRUN 18 InfoCube 7, 127 partitioning 87 update 86 updating 84 InfoObject 6, 127 InfoPackage 83, 127 InfoPackage Scheduler 83 InfoSource 84, 127 installation pre-installation checking 26 steps 45 INSTGUI 44 INSTTOOL.SH location 43 Integrated Call Level Interface (ICLI) 8, 17 IRLM parameters 50
Operational Data Store (ODS) 5 OSA-2 Adapters 15 OSA-EXPRESS 26
P
partitioning 86 performance 89 PI-A 99 72 presentation server 13 , 22 processor 14
R
R3SETUP 44 problem solving 68 RACF 19, 37 RRS 48
S
SAP 20 BASIS 25 notes 61 SAP BW architecture 4 data structure 6 DB2 objects 47 SAP R/3 tools 80 SAP system name 20 SAPGUI 13, 71 SAPOSCOL 65 SID table 8 SMS 34 ACS routine 16 configuring 34 staging engine 6, 128 star schema 7, 128 STARJOIN 83 start up JCL 36 storage 14 System Managed Storage (SMS) 16
K L
key figure 7, 127
legacy system 127
M
master data 128 master table 8 meta data 128 Meta Data Manager 6 multidimensional database 128
N
navigation 128
T
TCP/IP hosts file 40 services file 41 testing 42 think time 128
O
ODS data loading 83 OLAP 128 OLAP processor 5
130
U
URLs 76 user information 19
V
VSAM catalog 48 VTOC 48
W
Workload Manager (WLM) 15
131
132
IBM Redbooks review

Your feedback is valued by the Redbook authors. In particular we are interested in situations where a Redbook "made the difference" in a task or problem you encountered. Using one of the following methods, please review the Redbook, addressing value, subject matter, structure, depth and quality as appropriate. Use the online Contact us review redbook form found at ibm.com/redbooks Fax this form to: USA International Access Code + 1 914 432 8264 Send your comments in an Internet note to redbook@us.ibm.com
Document Number Redbook Title Review
SG24-5681-00 SAP Business Information Warehouse on OS/390
What other subjects would you like to see IBM Redbooks address?
Please rate your overall satisfaction: Please identify yourself as belonging to one of the following groups: Your email address: The data you provide here may be used to provide you with information from IBM or our business partners about our products, services or activities. Questions about IBMs privacy policy?
O Very Good
O Good
O Average
O Poor O Solution Developer
O Customer O Business Partner O IBM, Lotus or Tivoli Employee O None of the above
O Please do not use the information collected here for future marketing or promotional contacts or other communications beyond the scope of this transaction.
The following link explains how we protect your personal information. ibm.com/privacy/yourprivacy/
133
(0.2spine) 0.17<->0.473 90<->249 pages
SAP Business Information Warehouse
on OS/390
Prepare, install, and configure your SAP BW on OS/390 Administer your SAP BW databases Recommended sizing approaches
This redbook explores the SAP Business Information Warehouse (BW) 1.2B on the S/390 system. It takes a close look at the tasks and functions that are specific to the S/390 environment. It is designed to assist S/390 technical specialists, DB2 database administrators, and SAP Basis consultants in implementing this technology. This redbook offers valuable information that includes: - An overview of BW - The preparation of the BW installation - The BW installation process - Recommendations on administering BW databases to: improve query response time, improve performance of loading databases, update delta information, gather database statistics, and more. - Preliminary sizing recommendations based on tests and SAP recommendations We assume that the readers have already installed the SAP R/3 system and are familiar with SAP applications, terminology, prerequisites, documentation, and technology.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL 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

SG24-5681-00 ISBN 0738418943

SAP Business Information Warehouse On OS 390

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Business Information Warehouse On OS 390

Uploaded by

Copyright:

Available Formats

SAP Business Information Warehouse on OS/390

Seungrahn Hahn Patrick Horkan Christoph Laube Gert Ruland

International Technical Support Organization SAP Business Information Warehouse on OS/390

Copyright IBM Corp. 2000