siebel 2000 database implementation on os/390 … siebel 2000 database implementation on os/390...

ibm.com/redbooks

Siebel 2000 Database Implementation on OS/390Using NT Siebel Servers

Viviane Anavi-ChaputRichard Corrihons

Louis DoranScott Hall

Vasilis KarrasMichael RuffinLee SiegmundJeffrey Wiese

Siebel 2000 architecture using DB2 database on OS/390

Siebel two- and three-tier implementations on NT and S/390

Siebel database setup with DB2 for OS/390

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


International Technical Support Organization SG24-5953-00

Siebel 2000 DatabaseImplementation on OS/390Using NT Siebel Servers

September 2000

© 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 restrictionsset forth in GSA ADP Schedule Contract with IBM Corp.

First Edition (September 2000)

This edition applies to Siebel 2000 with OS/390 V2R8 and DB2 V6.

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. HYJ Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

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

Before using this information and the product it supports, be sure to read the general information in Appendix H,“Special notices” on page 151.

Take Note!

Contents

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

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

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

Chapter 1. Siebel Systems overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11.1 Siebel product architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1.1 Presentation services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11.1.2 Application services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.1.3 Data services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

1.2 Siebel application framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21.2.1 Core services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.2 Application integration services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.3 Business processes services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.4 Integration services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.5 Design time tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.6 Admin services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.3 Siebel configurations in the S/390 environment. . . . . . . . . . . . . . . . . . . . . .41.3.1 Two-tier configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41.3.2 Three-tier configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

1.4 Siebel clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51.4.1 Connected client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61.4.2 Thin client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61.4.3 Mobile client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

1.5 Siebel application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.5.1 Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.5.2 Siebel Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.5.3 Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91.5.4 File system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

1.6 Siebel database server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101.7 S/390 strengths for Siebel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

1.7.1 OS/390 strengths and value proposition . . . . . . . . . . . . . . . . . . . . . .111.7.2 DB2 strengths and value proposition . . . . . . . . . . . . . . . . . . . . . . . . .121.7.3 Enterprise Storage Server strengths and value proposition . . . . . . . .13

Chapter 2. Preparing the system for Siebel 2000 installation . . . . . . . . . .152.1 ITSO system configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152.2 Installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162.3 Preparing the system environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162.4 Creating user IDs and assigning authorizations . . . . . . . . . . . . . . . . . . . .172.5 DB2 customization on OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

2.5.1 Buffer pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182.5.2 DSNZPARM parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.5.3 DB2 objects for Siebel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

2.6 Stored procedures enablement on OS/390 . . . . . . . . . . . . . . . . . . . . . . . .20

Chapter 3. Configuring database connections to DB2 on S/390 . . . . . . . .213.1 DB2 DDF setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

© Copyright IBM Corp. 2000 iii

3.2 DB2 Connect EE setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.1 Installing DB2 Connect EE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Creating an admin ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3 Configuring DB2 Connect EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.4 Configuring the NT server for client access . . . . . . . . . . . . . . . . . . . 32

3.3 Client PC setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.1 Installing the DB2 Run-Time client . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.2 Configuring the Client PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Testing the Client/Server connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 4. Installing Siebel 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1 Installing Siebel on the NT server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.1 Creating a service owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 Creating the file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.3 Installing the Gateway Server and the Name Server . . . . . . . . . . . . 414.1.4 Installing the Siebel Server and the Enterprise Server . . . . . . . . . . . 454.1.5 Installing the Siebel database server scripts . . . . . . . . . . . . . . . . . . 54

4.2 Installing the Siebel-DB2 database on OS/390 . . . . . . . . . . . . . . . . . . . . 564.2.1 Creating Siebel-DB2 objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.2 Importing seed data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2.3 Validating database objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.4 Importing Siebel repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3 Populating the file system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4 Installing the connected client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 5. Importing data with EIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.1 Preparing EIM interface tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2 Editing the configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3 Running EIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.4 Checking the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Chapter 6. Security considerations for Siebel with DB2 for OS/390 . . . . . 776.1 Siebel internal application security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2 Siebel data security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3 Siebel External Security Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.4 OS/390 security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.5 DB2 for OS/390 security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.5.1 Granting table privileges to a Group User Name . . . . . . . . . . . . . . . 796.5.2 Granting program execution privileges. . . . . . . . . . . . . . . . . . . . . . . 806.5.3 Dynamic Statement Caching considerations . . . . . . . . . . . . . . . . . . 806.5.4 Binding the DB2 Connect packages . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.6 Data transmission security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.6.1 Siebel support for data transmission . . . . . . . . . . . . . . . . . . . . . . . . 826.6.2 DB2 Connect support for data transmission . . . . . . . . . . . . . . . . . . . 82

Chapter 7. Administrating DB2 with Siebel . . . . . . . . . . . . . . . . . . . . . . . . 837.1 DB2 installation recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2 Siebel-DB2 database design recommendations . . . . . . . . . . . . . . . . . . . . 83

7.2.1 Database objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2.2 Free space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.2.3 Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.2.4 EDM pool size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.2.5 Buffer pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.3 Siebel-DB2 database maintenance recommendations . . . . . . . . . . . . . . . 86

iv Siebel 2000 Database Implementation on OS/390

7.3.1 Database reorganization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .867.3.2 Statistics gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

7.4 Siebel-DB2 database recovery recommendations . . . . . . . . . . . . . . . . . . .867.4.1 Recovery to currency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .867.4.2 Disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .877.4.3 Point-in-time recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Chapter 8. DB2 features used by Siebel applications . . . . . . . . . . . . . . . . .978.1 SQL and system performance enhancements in DB2 V6 . . . . . . . . . . . . .97

8.1.1 Dynamic statement caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .978.1.2 ORDER BY clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .988.1.3 Stored procedures to start utilities . . . . . . . . . . . . . . . . . . . . . . . . . . .988.1.4 Index screening in RID list processing. . . . . . . . . . . . . . . . . . . . . . . .998.1.5 Unmatched column join for VARCHAR . . . . . . . . . . . . . . . . . . . . . .1008.1.6 Outer join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1018.1.7 Uncorrelated subquery -- indexable IN predicates . . . . . . . . . . . . . .1018.1.8 Small tables to use indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1028.1.9 DSMAX increased from 10000 to 32767 . . . . . . . . . . . . . . . . . . . . .1038.1.10 225 tables per query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1048.1.11 New built-in functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1048.1.12 Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1048.1.13 Buffers and EDM pools in data spaces . . . . . . . . . . . . . . . . . . . . .1058.1.14 Update with subselect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1068.1.15 Identity columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1078.1.16 Declared temporary tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1088.1.17 Defer defining data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1098.1.18 SET LOG SUSPEND/RESUME command. . . . . . . . . . . . . . . . . . .1098.1.19 Access path selection adjustment . . . . . . . . . . . . . . . . . . . . . . . . .110

8.2 SQL and system performance enhancements in DB2 V7 . . . . . . . . . . . .1108.2.1 Correlated subquery to join transformation . . . . . . . . . . . . . . . . . . .1108.2.2 Self-referencing subselect with UPDATE/DELETE . . . . . . . . . . . . .1118.2.3 Online system parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1118.2.4 Scrollable cursors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111

8.3 Utility enhancements in DB2 V6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128.3.1 COPY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128.3.2 Parallel COPY and RECOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128.3.3 LOAD and REORG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128.3.4 REBUILD index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128.3.5 Fast Log Apply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1128.3.6 Consistent restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1138.3.7 Inline RUNSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1138.3.8 REORG enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1138.3.9 Reuse feature of LOAD, REORG, RECOVER, REBUILD . . . . . . . .1148.3.10 Backup and Recovery of indexes using image copies . . . . . . . . . .114

8.4 Utility enhancements in DB2 V7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1148.4.1 Online REORG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1148.4.2 Consistent restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1148.4.3 Statistics history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

v

Appendix A. Setting up DB2 Connect Personal Edition . . . . . . . . . . . . . . .115

Appendix B. Setting up DB2 DDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

Appendix C. DSNZPARM parameters for DB2 . . . . . . . . . . . . . . . . . . . . . . .125

Appendix D. Siebel-DB2 objects creation . . . . . . . . . . . . . . . . . . . . . . . . . . .131D.1 Create STOGROUPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131D.2 Create databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131D.3 Create table spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132D.4 Create tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133

Appendix E. Adding a temporary database and table spaces . . . . . . . . . .137

Appendix F. Stored procedures enablement. . . . . . . . . . . . . . . . . . . . . . . . .139F.1 RRS setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139F.2 WLM setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142F.3 Testing stored procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144

Appendix G. Enterprise Storage Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .147

Appendix H. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151

Appendix I. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153I.1 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153I.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153I.3 Siebel documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153I.4 Other resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154I.5 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

vi Siebel 2000 Database Implementation on OS/390

Figures

1. Siebel three-tiered architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. Siebel application framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. Siebel two-tier configurations with DB2 database on S/390 . . . . . . . . . . . . . . . 44. Siebel three-tier configurations with DB2 database on S/390 . . . . . . . . . . . . . . 55. Siebel connected client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66. Siebel thin clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77. Siebel mobile client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88. Siebel Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99. ITSO system configurations used in the installation process . . . . . . . . . . . . . . 1510. DB2 Connect initial screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2211. Selecting the product to install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2312. Choosing the type of installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2313. Choosing the destination location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2414. Entering user ID and password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2415. Ready to copy the files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2516. Setup complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2517. Client Configuration Assistant welcome screen . . . . . . . . . . . . . . . . . . . . . . . . 2718. Source option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719. Protocol option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2820. TCP/IP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2821. Database alias name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2922. ODBC option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2923. Node option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3024. Security option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3025. Host option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3126. Completion of configuration for DB2DSB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3127. Testing the connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3228. Successful connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3229. Starting the command line processor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3330. Product selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3431. EIM process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6932. Component Group Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7133. Zipimp.ifb file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7134. Pick Assigned Component selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7235. Parameter Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7336. Typing in the IFB file name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7337. EIM task running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7438. EIM task result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7539. DSNUTILS stored procedure overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9940. Uncorrelated IN subquery improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10241. Client Configuration Assistant initial screen . . . . . . . . . . . . . . . . . . . . . . . . . . 11642. Choosing the manual connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11743. Protocol selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11744. TCP/IP address and DDF Port number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11845. Database name and alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11846. ODBC tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11947. Node option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11948. Security options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12049. Successful connection for DB2 Connect PE . . . . . . . . . . . . . . . . . . . . . . . . . 12050. Connection test successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

© Copyright IBM Corp. 2000 vii

51. Client Configuration Assistant after completing the configuration. . . . . . . . . .121

viii Siebel 2000 Database Implementation on OS/390

Tables

1. RACF user IDs & DB2 authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182. Connectivity parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213. Database and tablespace layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574. DB2 Connect parameters for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

© Copyright IBM Corp. 2000 ix

x Siebel 2000 Database Implementation on OS/390

Preface

This IBM Redbook will help you install and customize Siebel 2000 V6.1applications for OS/390 V2.8 using DB2 V6.1. It is based on the installationexperiences gained while installing Siebel 2000 at the IBM ITSO inPoughkeepsie, New York.

The book contains an overview of Siebel Systems and their two- and three-tierarchitectures in the OS/390 environment. It describes the connections to theSiebel-DB2 database server on S/390, as well as the customization needed forOS/390 and DB2. It provides installation guidelines to set up the Siebelapplications on NT servers and the DB2 database on the S/390 server. The bookgives recommendations on security and database administration issues, as wellas the DB2 features which specifically benefit Siebel. An example of importingdata to the Siebel-DB2 database, using Siebel’s Enterprise Integration Manager,is also provided.

This IBM Redbook will be especially useful for those installing Siebel 2000 onOS/390 for the first time.

You can also download the book from the IBM Redbooks home page at:

http://www.redbooks.ibm.com

Alternatively, you can access the FTP server directly at:

ftp://www.redbooks.ibm.com/redbooks/SG245953.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the worldworking at the International Technical Support Organization PoughkeepsieCenter.

Viviane Anavi-Chaput is a Senior IT Specialist for Business Intelligence andEnterprise Resource Planning with the IBM International Technical SupportOrganization in Poughkeepsie, New York. She writes extensively, teachesworldwide, and presents at international conferences. Before joining the ITSO in1999, Viviane was a Senior Data Management Consultant at IBM Europe,France. She was also an ITSO Specialist for DB2 at the San Jose Center during1990-1994.

Richard Corrihons is an S/390 DB2 Specialist with the IBM Products andSolutions Support Center (PSSC) in Montpellier, France. Richard specializes incustomer proofs of concept and benchmarks in the ERP areas. He holds anElectronic Engineering degree from the Conservatoire National des Arts etMetiers.

Louis Doran is an ERP Solutions Specialist with the North American ERPCompetency Center in Philadelphia. Before joining the ERP group, Lou worked inNetwork Marketing and has a large systems background.

Scott Hall is a member of the Enterprise Solutions Group at Siebel Systems andspecializes in database and mainframe technologies. Scott has 16 years of

© Copyright IBM Corp. 2000 xi

experience in mainframes, focusing on database technologies including DB2 forOS/390.

Vasilis Karras is an Advisory IT Specialist with the IBM International TechnicalSupport Organization in Poughkeepsie, New York. Vasilis provides technicalsupport to ITSO projects and has extensive experience in the areas of OS/390,Database and Networking. He holds a Computer Science degree from BrooklynCollege.

Michael Ruffin is a Consulting Marketing Support Representative from the IBMData Management Enablement and Sales for the Americas and Canadaorganization. Michael joined IBM in 1987 and has worked in the IBM GlobalServices, Software Migration Project Office, OS/390 New Technology Center andServer Consolidation organizations.

Lee Siegmund is a Consulting Marketing Support Representative from the IBMDB2 Relational Support Unit of the Dallas Systems Center. He has worked at IBMfor 29 years. For the past 15 years he has supported DB2, starting with Version 1Release 1 to the current Version 6.

Jeff Wiese is a Market Support Representative in IBM US. He joined IBM in 1973and was a PSR, instructor, SE, and Large Systems Marketing Specialist beforejoining the S/390 New Technology Center in Poughkeepsie, New York.

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

Kathryn ArrellBob HaimowitzInternational Technical Support Organization, Poughkeepsie Center

Bob CarstensenKevin FenningIBM S/390 Marketing

Fred OroscoHugh SmithAnnie TsangIBM Silicon Valley Lab

Ingo MullerIBM Toronto Lab

Ken LlaceraSteve LowenthalFrank LuTony WongSiebel

Thanks also to Al Schwab and Terry Barthel for their editorial assistance, and toElla Buslovich for her graphics assistance.

xii Siebel 2000 Database Implementation on OS/390

Comments welcome

Your comments are important to us!

We want our Redbooks to be as helpful as possible. Please send us yourcomments about this or other Redbooks in one of the following ways:

• Fax the evaluation form found in “IBM Redbooks review” on page 163 to thefax number shown on the form.

• Use the online evaluation form found at http://www.redbooks.ibm.com/

• Send your comments in an Internet note to [email protected]

xiii

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


xiv Siebel 2000 Database Implementation on OS/390

Chapter 1. Siebel Systems overview

Siebel Systems is an industry leader in Customer Relationship Management(CRM) solutions. Siebel provides an integrated family of e-business applicationsoftware enabling multichannel sales, marketing, and customer service systemsto be deployed over the Web, call centers, field, reseller channels, retail, anddealer networks.

Siebel provides a set of horizontal solutions (such as basic functions for allbusinesses or business partners), as well as vertical solutions (including specificand unique solutions for particular industries such as utilities or powercompanies).

This chapter introduces Siebel product architecture and application framework. Itdiscusses the Siebel configurations in the S/390 environment and stresses thevalue of OS/390 and DB2 for the Siebel product.

1.1 Siebel product architecture

Siebel products are logically built on a three-tiered architecture as shown inFigure 1. This three-tiered architecture provides the platform for commonservices to support the various Siebel applications. These services include:

• Presentation services• Application services• Data services

Figure 1. Siebel three-tiered architecture

1.1.1 Presentation servicesPresentation services support Siebel clients and provide them with user interfaceapplets, views, charts and reports. A large variety of clients are supported, suchas traditional connected clients, remote clients, thin clients over an intranet, Java

Object Manager (OM)Object Manager (OM)

Data Manager (DM)Data Manager (DM)

Siebel DatabaseSiebel Database

Applet ManagerApplet ManagerUser Interface (UI)User Interface (UI)

Presentation ServicesApplets, Views, Charts, ReportsNative Siebel interfacesHTML in any browserScripting on dedicated client

Business LogicBusiness Objects, ComponentsBusiness ServicesScripting on all platforms

Database InteractionDynamic SQL GenerationAuto-adapting to UI and OMDatabase specific connector

Data ServicesNo business logicComprehensive data modelPerformance optimized

Application Services

© Copyright IBM Corp. 2000 1

thin clients on non-windows-based operating systems, and HTML clients over theInternet.

1.1.2 Application servicesBusiness logic services provide the class and behaviors of business objects andbusiness components. Developers can also use business services to create theirown class, and using the Siebel scripting tools, develop their own objects withtheir own behaviors.

Database interaction services take the user interface (UI) request for data from abusiness component and generate the SQL necessary to satisfy the request. Theservice translates the call for data into DBMS-specific SQL statements. Eachdatabase supported by Siebel has a DBMS-specific connector optimized for thatparticular DBMS.

1.1.3 Data servicesData storage services provide the data storage for the Siebel data model, whichis a very comprehensive data model that is the basis of the Siebel applications.The model supports the core Siebel products including call center, sales,services, and marketing, as well as the industry vertical products, such aseFinance, eInsurance, eCommunications, and eHealthcare, to name a few.

1.2 Siebel application framework

The Siebel product architecture provides a framework in which users canconfigure a Siebel application to meet their business needs.

Figure 2 gives an overview of the Siebel application framework. For more detailson Siebel’s applications you may also refer to the Web site www.siebel.com.

Figure 2. Siebel application framework

Siebel Application Framework

WebEngine

CollaborationServer

ContentTargeting

ProfileManagement

Inte

grat

ion

Ser

vice

s

E-mail & FAXComm ServerSearch

SmartScript

AssignmentManager

WorkflowManager

BusinessServices

Bus

ines

sP

roce

sses

ProductConfiguration

PricingConfigurator

SyndicatedContent

VirtualBusComps

BusObjectInterfaces EIM

Business Integration Manager

App

licat

ion

Inte

grat

ion

ObjectManager

DataManager

Authentication& Access Control

EnterpriseServer

NetworkSupport

EventManager

DataReplication

Cor

eS

ervi

ces

PersonalizationDesigner

WorkflowDesigner

SmartScriptDesigner

AssignmentAdmin

ModelBuilder

BusObjectDesigner

AppletDesigner

ApplicationUpgrader

IntegrationDesigner

SiebelAnywhere

ServerManager

Run

Tim

eD

eisg

nTi

me

Adm

in

Tools

ReportServer

OLAPDataMart

CampaignManager

BusinessAnalysis

2 Siebel 2000 Database Implementation on OS/390

1.2.1 Core servicesCore services are the framework in which the applications execute. The servicesinclude:

• The enterprise server, which is the middle-tier application server

• The networks that link all of these pieces together

• Facilities like event manager and data replication, which allow sharing databetween multiple Siebel installations as well as between Siebel and otherexternal applications

• The authentication and access control, the security facilities that let in onlythose people who are wanted and allows them to do only what they areauthorized to do.

1.2.2 Application integration servicesApplication integration services allow Siebel applications to converse with theexternal world. Services in this area provide for real-time, near-real-time, andbatch integration with external applications. These services enablecommunications between external applications and Siebel, using populartechnologies, such as COM, CORBA, HTTP, and popular software products suchas IBM MQSeries. Application integration allows Siebel to share and replicatedata with other enterprise applications. These services allow Siebel to be both aclient requesting information, and a server having information requested from it.

1.2.3 Business processes servicesBusiness processes services allow the client to automate business processesthrough the application. The automation includes:

• Assignment of tasks through Assignment Manager• Enforcement of business best practices through Workflow Manager• Reuse of custom business logic through Business Services• Ensuring proper product configuration and pricing through the Product

Configurator and Pricing Configurator

Creation of these business processes is done through Run-Time tools such asPersonalization Designer, Workflow Designer, SmartScript Designer, AssignmentAdministration Views, and the Model Builder.

1.2.4 Integration servicesIntegration services provide the client with user interface and thin client support.This includes building and maintaining your Siebel Web-based applications,providing Web support facilities such as user Profile Management, CollaborationServices and Email and Fax services, as well as advanced Smart Scripting tolead a user through a line of questioning or keyword search for, say, self-servicesupport over the Web. Siebel can also provide personalized eNewslettersthrough Content Targeting services.

1.2.5 Design time toolsDesign time tools provide the services to customize, design, provide integrationpoints, and maintain the application. Siebel tools provide one place to define theapplication, no matter which deployment option is chosen, whether over theInternet or an intranet, connected client, remote client, or hand-held devices. The

Chapter 1. Siebel Systems overview 3

design time services provide the ability to upgrade the application with the touchof a button and have release level conflicts resolved with a minimum amount ofrework.

1.2.6 Admin servicesAdmin services provide one place to monitor and administer the Siebelapplication environment. These services allow the user to administer the SiebelServer either through a graphic user interface (GUI) or from a command line,enabling server-based processes to be launched via a server-based scheduler. Inaddition to application monitoring and management, Siebel Anywhere allows youto manage the upgrade process, including any third-party products that need tobe upgraded or rolled out to the users.

1.3 Siebel configurations in the S/390 environment

Siebel’s software architecture can be physically implemented in two- or three-tierconfigurations in the S/390 environment.

Siebel establishes connectivity from the client to the S/390 DB2 database serverusing DB2 Connect middleware. DB2 Connect can reside on each Siebel client orserver machine. DB2 Connect Personal Edition (PE), or common connectiongateway machines can be used to broker the connections to DB2/390 for multipleSiebel clients and servers -- DB2 Connect Enterprise Edition (EE).

1.3.1 Two-tier configurationsAs shown in Figure 3, the client workstation in two-tier implementations has thecomplete set of Siebel applications.

Figure 3. Siebel two-tier configurations with DB2 database on S/390

There are two connection alternatives:

• Each client workstation has DB2 Connect Personal Edition installed and usesthe client configuration assistant GUI to catalog and establish directconnection between the client workstation and DB2 on S/390. See Appendix

DB2 Connect EE

ClientsConnectionGateway

Database server

Siebel clientSiebel applicationsDB2 Connect PE

Siebel-DB2databaseserver

S/390S/390

DB2DB2DB2DB2

DB2DB2

Siebel clientSiebel applicationsDB2 Run-Time client


A, “Setting up DB2 Connect Personal Edition” on page 115, for setupinformation on DB2 Connect PE.

• One or more workstations have DB2 Connect Enterprise Edition installed andbecome the connection gateway. Connectivity is established from them to theDB2 subsystem on S/390.

Then the DB2 Run-Time client is installed on the other client workstations.They connect to the gateway workstation, which connects to the host. DB2Run-Time client comes with DB2 Connect V6 at no additional cost. Thismethod requires less installation and maintenance on the client workstations.

DB2 Connect EE also provides connection pooling to allow multiple Siebelclients and servers to reuse connections to DB2 for OS/390.

1.3.2 Three-tier configurationsIn three-tier configurations (Figure 4), the Siebel application resides on anintermediary server. DB2 Connect Enterprise Edition is installed on themiddle-tier platform. Connectivity is established from this middle-tier to DB2 onOS/390.

Figure 4. Siebel three-tier configurations with DB2 database on S/390

Siebel clients and servers communicate with DB2 Connect via TCP/IP. DB2Connect supports communication to DB2 for OS/390 via TCP/IP or SNA;however, configuring DB2 Connect to use SNA is more complex, and does notcurrently support connection pooling.

See Chapter 3, “Configuring database connections to DB2 on S/390” on page 21,for setup information on DB2 Connect EE.

1.4 Siebel clients

Siebel applications support three types of clients:

• Connected client• Thin client• Mobile client

Web server

Siebel applicationservers

DB2 Connect EE

Siebel clientWeb browser

Siebel clientDB2 Run-Time client

Clients Application servers Database server

Siebel-DB2databaseserver

S/390S/390

DB2DB2DB2DB2

DB2DB2


1.4.1 Connected clientThe connected client, also known as the Siebel client or the dedicated client, asshown in Figure 5, is a “fat” client; the applications reside on it, but not the data,as it connects directly to the Siebel database server and the Siebel file system toperform its functions. The connected client may also interact with SiebelEnterprise Server components for additional functionality, such as the workflowmanager.

The difference in the two connected clients in Figure 5 is that the client on theupper left is accessing DB2 using DB2 Connect Enterprise Edition (EE) on agateway, while the client on the lower left is accessing DB2 directly using DB2Connect Personal Edition (PE). The reason this is shown is simply for DB2Connect licensing, that is, using DB2 Connect EE’s Run-Time Client code on theclient rather than DB2 Connect PE could reduce the licensing cost, which mightbe a consideration in configuring the solution.

Figure 5. Siebel connected client

1.4.2 Thin clientThe thin client (as shown in Figure 6 on page 7) provides the user interfacewithout containing application code. Like the connected client, thin clients do notstore data locally. Thin clients connect to the Siebel Server either directly orthrough a Web server, but not to any other server. The Siebel Server executes allbusiness logic for the thin client. The thin client types are:

1.4.2.1 HTML clientThis client uses a Web browser and connects to the Siebel Server through a Webserver.

Siebel-DB2 Database Server

ConnectionGateway

Siebel connected clientSiebel applications

DB2 Connect PE

Siebel connected clientSiebel applications

DB2 Run-Time client

Siebel Enterprise Server

DB2DB2DDFDDF

S/390S/390

DB2 Connect EE


1.4.2.2 Java clientThis client runs a Java version of the Siebel GUI. The Java thin client is designedfor use on OS/2 and Sun Solaris operating systems.

1.4.2.3 Siebel thin client for WindowsThis client uses either a browser or a Siebel standalone executable to provide theuser interface, and connects to the Siebel Server (even if the browser interface isused, it does not connect through a Web server).

1.4.2.4 Wireless clientThe wireless client is essentially a thin client enabled on a wireless device. Thewireless client is based on the worldwide Wireless Application Protocol (WAP)standard for mobile, wireless communications and Internet access. SiebelWireless enables field sales and service users of Siebel applications to wirelesslyaccess Siebel data directly from the corporate database.

Figure 6. Siebel thin clients

1.4.3 Mobile clientThe mobile client, typically a laptop computer used by field personnel as shownon Figure 7 on page 8, operates without a real-time connection to any of theservers. The mobile client downloads a portion of the Siebel database and filesystem to the PC. Users access that data locally, without being connecteddirectly to the Database Server, Siebel Server, or file system. The mobile clientmust periodically connect to the Siebel Server to synchronize its local databasewith the Database Server and file system.

S/390 Server

NT Server

Java

HTML

WindowsThin Client Web Server

Siebel applicationsDB2 Connect EE

Wireless

WirelessWirelessClientClientServerServer

S/390S/390

Siebel-DB2 Database Server

Siebel thin clients

DB2DB2DDFDDF


Figure 7. Siebel mobile client

The handheld client (a Personal Data Assistant, or PDA) is essentially anextension of the mobile client, in that the PDA has to synchronize with a mobileclient.

To summarize, connected clients read and write data directly to and from theSiebel file system and database. Mobile clients have a local copy of their data,which is periodically synchronized with the server-based systems, and thin clientsaccess data through Siebel application servers.

1.5 Siebel application servers

The application layer consists of a number of Siebel application servers and thefile system. It is not uncommon to find multiple application servers supporting aSiebel configuration.

Siebel software is coded in C++ and the same code runs on all platforms. Siebelservers can run on NT and many UNIX platforms.

1.5.1 Siebel Enterprise ServerThe Siebel Enterprise Server is a logical grouping of Siebel application servers asshown in Figure 8 on page 9. For example, it supports a group of users accessinga common database, allowing this collection to be administered and configuredas a single logical unit.

The Siebel Enterprise Server comprises:

• One or more Siebel Servers• One Gateway Server• One file system

DDFDDFDB2DB2

S/390S/390

S/390Siebel DB2 Database

Server

NTSiebel Server

andFile System

Mobile client

LocalLocaldatadata


Figure 8. Siebel Enterprise Server

1.5.2 Siebel ServerThe Siebel Server manages one or more components of the Siebel application.Many of the Siebel Server components are multitasking, and can run instances ofthemselves on multiple Siebel servers simultaneously to support increasednumbers of users or larger batch workloads.

These servers provide both batch mode and interactive services on behalf ofSiebel clients. Batch and interactive services can run at the same time. There isno need to have a specific time of day to run batch services because Siebel isdesigned as a 24 x 7 application. Even though batch and online can coexist, it isa good practice to run large Enterprise Integration Manager (EIM) or territoryreassignment processes during off hours due to the remote possibility of locking,EDM pool, and catalog contention issues.

1.5.3 Gateway ServerThe Gateway Server is a logical grouping that contains the Name Server and theoptional Resonate Central Dispatch server, and handles connections betweenclients and servers in a Siebel environment. The Gateway Server also does acertain amount of load balancing by managing session logons.

1.5.3.1 Name ServerThe Name Server provides for persistent backup storage of the configurationinformation for all Siebel servers and serves as the dynamic registry for SiebelServer and component availability information.

1.5.3.2 Resonate Central DispatchThe Resonate Central Dispatch optional product consists of a scheduler thatbrokers Siebel connection requests across Siebel servers and also monitors the

Siebel Enterprise ServerSiebel Enterprise Server

Gateway ServerGateway Server

Name Server

Resonate CentralDispatch

FileFileSystemSystem

SiebelSiebelServerServer




load of each Siebel server, and a dispatch manager that is used to configure andmanage the scheduler.

1.5.4 File systemThe file system is a network-accessible directory located on a Siebel applicationserver. It stores all the physical files created by Siebel applications, such as filescreated by Microsoft Word for Windows, PowerPoint, and other data that is notstored in the database. All files in the file system are compressed and storedusing a specialized naming convention, and users should never access filesdirectly from the file system but only through the Siebel client, which automatesthe compression and naming tasks. All files in the file system are stored in asingle directory, and are distinguished by a filename prefix.

1.6 Siebel database server

In a Siebel system there is only one database server. It contains your businessdata in a set of predefined tables, and provides that data to Siebel servers andconnected clients upon request. Siebel creates over 10,000 tables andassociated indexes in its database.

Note that Siebel’s definition of a server includes “a software program thatprovides a specific kind of service (resource) to client software running on othercomputers.” The reason we point this out is that when, for example, discussingthe database server, there can be confusion as to the platform being referred to.DB2 resides on S/390, but for S/390 DB2 Connect will reside on a differentserver. DB2 Connect could be referred to as the database server as well.

The Siebel database server stores the data used by Siebel enterpriseapplications.

Although Siebel supports several relational database management systems(RDBMSs), when using S/390 for the database layer, the only RDBMS that canbe used is DB2 UDB for OS/390 Version 6.

DB2 Connect V6 on the client or middle tier is the mechanism used tocommunicate with DB2’s Distributed Data Facility (DDF) on S/390.

Siebel connected clients and Siebel server components, including those whichoperate in conjunction with the Siebel thin client, connect to the database servervia DB2 Connect.

Siebel mobile clients download a subset of the database to use data locally, andperiodically synchronize with the database server through the Siebel Server toupdate both the local and the host database.

1.7 S/390 strengths for Siebel

The S/390 platform is engineered to deliver high levels of performance,scalability, availability, integrity, and security needed for your businessapplications. Integrating on the same platform, the capabilities of the OS/390operating system with subsystems such as the DB2 database subsystem and theEnterprise Storage Server (ESS) storage subsystems can significantly leverageSiebel’s performance.


1.7.1 OS/390 strengths and value propositionOS/390 is an integrated enterprise server operating system environment. Itincorporates into one product an open communication server, distributed dataand file services, Parallel Sysplex support, object-oriented programming, andopen application interfaces.

OS/390 continues to build on the classic strengths of MVS: reliability, continuousavailability, serviceability, data integrity, workload management, and security.OS/390 gives you a scalable system that supports massive transaction volumesand large numbers of users with high performance, as well as advanced systemand network management.

Siebel user data is stored on its database server. On S/390, Siebel uses DB2UDB for OS/390 as the database server, which can manage large amounts ofdata on behalf of many users.

1.7.1.1 OS/390 strengthsThe strengths that OS/390 and S/390 bring to the Siebel environment include:

Reliability, availability, and serviceabilitySiebel S/390 customers need continuous data availability and integrity. TheOS/390 computing platform is unmatched in its proven ability to supportmission-critical business applications for the majority of the leading enterprisesacross all industries and geographies. OS/390 is also widely acknowledged asproviding a very high level of security and integrity, unmatched by othercommercial application computing platforms. Siebel benefits from thesecharacteristics.

ScalabilityThe S/390 platform ranges from small uniprocessors to 12-way processors toParallel Sysplex environments that allow you to connect up to 32 OS/390systems. The architecture of the S/390 I/O subsystem and the OS/390 operatingsystem allow data to be transferred into memory from many devicessimultaneously, allowing the processing of data requests for many users at highdata rates. The requests may require accessing data residing in multiple-terabyterepositories.

The DB2 for OS/390 database platform provides the highest degree of scalabilityavailable to customers, with the ability to support in excess of 50,000 users.

Server consolidationsOne of the key selling points of Siebel is that it gives your employees aconsolidated enterprise view of the customer database. Any call center rep orsales rep can see all of the information about any customer. This is not possible ifyou have to split your database because you need multiple servers.

Since the Siebel database server is on OS/390, this opens up the possibility ofconsolidating printing requirements on OS/390 for customers wanting to use highspeed printing capabilities. The OS/390 Print Server provides a greatinfrastructure to satisfy the needs of printing from outside S/390.


System managementOS/390 has many system management capabilities, providing data security,strong operations tools, and the ability to manage diverse workloads. OS/390 hasproven procedures and tools to manage systems in a very efficient way.

Cost of ownershipS/390 is acknowledged by consultants such as IDC, GartnerGroup, Xephon, ITG,and others as having one of the lowest overall costs of ownership in aclient/server environment when calculated over multiple years. CMOS technologyand software pricing actions have drastically reduced the cost of S/390 enterprisecomputing. The cost of deploying a large database supporting very high numbersof users on a single DB2 for OS/390 database instance can be significantly lessthan the cost of implementing and managing multiple database instances onmultiple machines, especially when leveraging existing hardware and supportinfrastructure.

1.7.1.2 Value propositionThe business value of using OS/390 as a database server not only derives fromthe features of S/390 and OS/390 (discussed in the previous section), but howthose points and other facets are applied to the business environment.

Potential value points are:

• Leverage existing S/390 legacy applications with packaged solutions such asERP solutions

• Leverage existing DB2-based data and skills on S/390• Leverage the traditional strengths of S/390• Scalability to connect more and more concurrent users as you integrate all

customer touch points across multiple channels• Flexibility to handle the unpredictable workloads generated by Web-based

transactions• Security protecting customer and partner data, your major business asset for

improving customer loyalty.

With the integration of all the products necessary for true CRM, plus takingcustomer sales and service to the Web, not only does the workload increase but italso becomes less predictable. Rather than a call center that takes calls duringbusiness hours 5 days a week, customers will want to do business 7X24 over thephone and over the Web. With unpredictable transaction rates you need theresilience of S/390's Workload Manager (WLM). This allows a customer to buy amachine for the average workload and expect WLM to manage the peakworkloads without failing.

1.7.2 DB2 strengths and value propositionThe DB2 for OS/390 database subsystem adds to and leverages the S/390 andOS/390 strengths.

1.7.2.1 DB2 strengthsThe strengths DB2 brings to the Siebel applications environment include:

Continuous operation and high availabilityDB2 can operate for long periods without interruption. With data sharing, workcan be transferred between DB2 subsystems within a Parallel Sysplex as resultof a planned or unplanned outage.


Online reorganization provides greater availability during database unload andreload processes.

High data integrityDB2 provides high data integrity through capabilities such as sophisticated lockmanagment and integration with IBM system security products. DB2 also protectsdata from subsystem, media, and application failures with integrated recoveryschemes.

Very large database supportDB2 supports very large tables of up to 16 terabytes, which can also be in ASCIIformat. Data can be compressed in the tables. DB2 works with the S/390 I/Osubsystem to allow the rapid parallel processes needed for very large databasebackup, reorganization, and recovery of data.

Database and system administration aidsTo help database administrators manage their database environments, DB2offers an integrated set of tools and functions, including flexible securitymechanisms, an extensive set of logging and recovery utilities, trace facilities fortuning, and functions and tools to monitor and tune subsystems.

1.7.2.2 Value propositionThe business value of using DB2 UDB for OS/390 as Siebel’s RDBMS not onlyderives from the features of DB2 for OS/390, but how those points, and otherfacets, are applied to the business environment.

• DB2 UDB allows customers to seamlessly scale their Siebel deployment tosupport enterprise-wide deployment -- NT to Parallel Sysplex.

• DB2 offers customers the lowest total cost of ownership for their Siebeldeployment.

• DB2 offers superior software support and reliability -- rated #1 in industrysurveys such as IDC.

• IBM and Siebel have invested dedicated joint engineering resources tooptimize performance on DB2 -- DB2 is the engineering platform for Siebel.

1.7.3 Enterprise Storage Server strengths and value propositionThe Enterprise Storage Server (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 all data across all the availabledisks, reducing the requirement for data placement to avoid hot spots. Additionalphysical storage capacity can be added nondisruptively.

The ESS’s architecture also enables FlashCopy, a data duplicator that allows youto make instant copies of data at the data set and volume level. FlashCopy isintegrated in the DB2 utilities using the concurrent copy interface. This cansignificantly increase application availability when making point-in-time copies.

For more information, see Appendix G, “Enterprise Storage Server” on page 147.


Chapter 2. Preparing the system for Siebel 2000 installation

This chapter provides details about the system configurations we used at theITSO and the preparation of our system environment before installing Siebel2000 software.

2.1 ITSO system configurations

Our middle tier was a Netfinity with Windows NT. The DB2 database server wasan OS/390 system with DB2V6.1 as shown in Figure 9.

Figure 9. ITSO system configurations used in the installation process

Application server systemThe system we used as the application server consisted of the following:

• An IBM Netfinity with Windows NT4.0 with Service Pack 5

• DB2 Connect 6.1 Enterprise Edition with the recommended FixPak 3SA

• Siebel 2000

• Approximately 500 MB of disk for the Siebel software

Database server systemThe system we used for the database consisted of the following:

• OS/390 V2R8 with TCP/IP (OS/390 eNetwork Communication Server TCP/IPV2R8)

• DB2 UDB for OS/390 V6.1 at PUT level 0003 plus additional fixes as per thePUT Buckets

• 6 GB of DASD for the database

Siebel applications

TCP/IP

Siebel client

TCP/IP

Netfinity / NT server S/390 server

Siebel-DB2 database

S/390S/390

Windows client

DB2 Run-TimeDB2 Run-Time DB2 Connect EEDB2 Connect EE DB2 DDFDB2 DDF


Siebel Client systemThe system we used for the client workstation consisted of the following:

• Windows NT with Microsoft Word for Windows (Office 2000)

• DB2 Run-Time Client (formerly called CAE)

• Siebel Client Code

• TCP/IP Port 5000 was used for communications to DB2 Connect EE

2.2 Installation steps

We proceeded with the installation steps in the following order:

1. Prepare the system environment.2. Create user IDs to be used during the installations and tests.3. Customize DB2 and OS/390 environments.4. Install DB2 Connect and configure the connections to the DB2 database on

S/390.5. Install and configure Siebel servers on the NT middle-tier platform.6. Create the Siebel-DB2 objects on S/390 and populate them.7. Create a Siebel Connected Client .

The following sections of this Redbook describe these installation steps.

We used the following Siebel documentation during the installation process:

• Siebel Installation Manual• Siebel Release Notes

2.3 Preparing the system environment

You should make sure that your system environment has the necessary hardwareand software for your installation.

Prepare Windows NT environmentVerify the server and domains. Siebel requires FixPak 3SA which you can find atthe following URL:ftp://ftp.software.ibm.com/ps/products/db2/fixes/english-un/siebel

Prepare Siebel environmentEnsure that all maintenance is applied to Siebel. Refer to the information APARII12440, which lists the latest maintenance for Siebel.

Prepare DB2 OS/390 environmentWe recommend that you provide a separate DB2 subsystem for the Siebel databecause of the point-in-time recovery issues described in 7.4.3, “Point-in-timerecovery” on page 87.

Ensure that all maintenance is applied to DB2 V6 including the refresh, whichadds new functions to DB2. For all new DB2 orders, this refresh will be shipped.For existing customers, an equivalent service level can be obtained by ordering aservice update via PDO (level 0014) or ESO (level 0003) and applying service toPUT 0003.


If you do not apply the correct maintenence on the DB2 subsystem, it mayprevent you from enabling Siebel. For example, if you miss PTF UQ38405 withAPAR PQ30652 which includes the identity columns support, you will not get theSYSIBM.SYSSEQUENCES catalog table and will have trouble starting Siebel.

2.4 Creating user IDs and assigning authorizations

To run the installation tasks and tests, we needed to create user IDs and assignthem user authorizations:

• User IDs with administrative authorizations• User IDs with client user authorizations

User authorizations are managed by RACF, DB2, and Siebel security options.

Regarding client user authorizations, there can be many approaches toimplementing them in a Siebel environment. Their granularity should be based onbusiness requirements. The greater the granularity, the greater the amount andcomplexity of the administration tasks. The Siebel DB2 subsystem consists ofmany databases, table spaces and tables. It is difficult to know exactly whichtables are used in each application. Thus, it is difficult to control access to thedata by allowing users selective access at the table level. Our approach was tolet Siebel security functions control user access to the various applications.These steps are described in detail in Chapter 4, Installing Siebel 2000.

On NTCreate user DB2ADMIN with NT administration authority.

On S/390• Enable DB2 secondary authorization IDs. DB2 installation job DSNTIJEX

builds the sample authorization exits which allow you to provide RACF groupnames as secondary DB2 authorization IDs. For more information refer to DB2UDB for OS/390 - Installation Guide Version 6, section Installation step 6:Define user authorization exit routines: DSNTIJEX, on page 253.

• Create RACF group IDs SSEROLE and SSEEIM.

• The SSEROLE group has Siebel user privileges.SSEROLE will have DB2 authority (select, insert, update, and deleteauthority on all tables) granted to it when the Siebel install scripts are run.

• The SSEEIM group has EIM user privileges (use of storage groups andbuffer pools for EIM temporary tables).

• Create RACF user IDs SIEBEL and SADMIN.

• SIEBEL has tableowner privileges. Grant SIEBEL DB2 sysadm authority.• SADMIN has administrator privileges. Grant SADMIN DB2 dbadm authority• Connect both SIEBEL and SADMIN user IDs to RACF group SSEROLE.

• Create RACF user IDs SIEBEL1 to SIEBEL8.

• SIEBEL1-8 have Siebel user privileges.Those privileges (select, insert, update, and delete authority on all tables)are granted when the Siebel install scripts are run.

• Connect SIEBEL1-8 to the RACF group SSEROLE.

Chapter 2. Preparing the system for Siebel 2000 installation 17

Table 1 summarizes the RACF user IDs and DB2 authorizations we used:

Table 1. RACF user IDs & DB2 authorizations

2.5 DB2 customization on OS/390

You should review the following points in the DB2 customization before you startthe Siebel installation phase.

2.5.1 Buffer poolsYou should check the following buffer pool issues:

• Ensure that the EDM pool size is large enough to handle the Siebel DBDs.We used the value of 100 MB.

• Ensure that buffer pools used by Siebel are active.

Siebel uses 4K, 16K and 32K tablespaces, so a user needs to ensure thatthese buffer pools have been activated.

We activated these buffer pools:

• BP1 = 4K buffer pool• BP2 = 4K buffer pool• BP16K1 = 16K buffer pool• BP32K1 = 32K buffer pool

Using the ISPF DB2 command line option, verify which buffer pools are activeby using the command:

DIS BUFFERPOOL (ACTIVE)

If you are using a buffer pool that is not active (in our case BP1), issue thefollowing command to activate it:

ALTER BUFFERPOOL (BP1) VPSIZE (1000)

Grant use of these buffer pools to the SIEBEL table owner and the SSEEIMgroup.

RACF user ID DB2 authority

SIEBEL sysadm

SADMIN dbadm

SIEBEL1 SSEROLE

SIEBEL2 SSEROLE

SIEBEL3 SSEROLE

SIEBEL4 SSEROLE

SIEBEL5 SSEROLE

SIEBEL6 SSEROLE

SIEBEL7 SSEROLE

SIEBEL8 SSEROLE


2.5.2 DSNZPARM parametersYou should customize the following DSNZPARM and DSNHDECP parameters asrequired by Siebel:

• ENSCHEME

Store the data in ASCII, not EBCDIC.This can be done at the subsystem level by adding ENSCHEME=ASCII. Ifthere is a need to have a mixture of database types in the same subsystem,you can add the parameter CCSID ASCII to the create database command.

• CACHEDYN

Use of dynamic SQL caching improves performance, so we added theparameter CACHEDYN=YES.

• SPRMMXT

The new parameter SPRMMXT -- maximum number of tables in a join -- isused to accommodate some of Siebel's SQL. For this purpose Siebel requiresAPAR PQ31326, which allows an installation to increase the number of tablesspecified in a join statement. After installing this APAR, the DSN6SPRC macroneeds to be modified to set the SPRMMXT value to 40.

• DSMAX

The large number of index data sets we have in Siebel requires a largenumber of open data sets (DSMAX). The temptation is to set DSMAX to itsmaximum value (32767). However, one installation reported the followingshort on storage problem when they set DSMAX to 32767:

– DB2 did not close unused data sets until the DSMAX value was reached.

– Even when not used, the open data sets consumed enough storage tocause VSAM enqueing problems.

– Decreasing DSMAX to 21000 eliminated the VSAM enqueing problem.

So, we recommend that you first try DSMAX (21000).

• IDLEIdle thread time-out should be used.

The DSNZPARM parameters we used are listed in Appendix C, “DSNZPARMparameters for DB2” on page 125.

2.5.3 DB2 objects for SiebelYou should provide the following objects for Siebel:

• Create large VTOCs.

When many indexes are created (which are small VSAM files), it is possiblethat you will fill up the VTOC before filling up the DASD space available. In ourcase, we created a VTOC with 450 tracks. Review your VTOC space after youhave completed your installation.

• Create a large VSAM user catalog.

We had to create a large VSAM user catalog to accommodate all the indexdata sets for Siebel. The VCAT entry of SIEBEL becomes the high-levelqualifier for the VSAM files. You may want to make this an alias entry, or all ofthe many index VSAM files will be cataloged in the master catalog.

Chapter 2. Preparing the system for Siebel 2000 installation 19

• Create a temporary database and temporary table spaces.Siebel uses declarative temporary tables. You need to configure a temporarydatabase and three (4K, 16K and 32K) table spaces to hold these tables. Thejob we used to do this is shown in Appendix E, “Adding a temporary databaseand table spaces” on page 137.

2.6 Stored procedures enablement on OS/390

Siebel uses staging tables for EIM processing. For the data import process, thesetables start out empty, get loaded with data, the data gets manipulated by the EIMprocess, then inserted into the Siebel data model.

RUNSTATS must be run at least once for proper optimization of SQL used duringEIM’s processing. Once DB2 statistics are established for the interface tablesbeing used to import data into the Siebel base tables, the statistics may beadequate for future use. If performance degrades over time because of pooraccess path selection due to invalid statistics, then RUNSTATS should be runagain. When RUNSTATS is required in the middle of an EIM run, Siebel utilizesthe stored procedure DSNUTILS.

You will need to ensure that:

• DSNUTILS is installed and operational.

• The OS/390 Workload Manager (WLM) is enabled to support the storedprocedures.

The setup is described in Appendix F, “Stored procedures enablement” onpage 139.


Chapter 3. Configuring database connections to DB2 on S/390

Enabling three-tier connections to the DB2 database on S/390 requires a set oftasks that is independent from Siebel’s installation. You should enable databaseconnections before starting to install Siebel 2000. The three-tier connectionsinclude:

• DB2 DDF setup• DB2 Connect EE setup• Client PC setup

At the end of the setup tasks, you should be able to successfully test yourconnections and access the DB2 database on OS/390.

For two-tier implementations using DB2 Connect PE, refer to Appendix A,“Setting up DB2 Connect Personal Edition” on page 115.

3.1 DB2 DDF setup

We had an OS/390 V2R8 system with a DB2 V6 database server using thelocation name DB2D. This DB2D instance was our target database for Siebel.

We had a standard installation of DB2 for OS/390 V6 with the recommendedmaintenance applied and DDF facility enabled. Refer to Appendix B, “Setting upDB2 DDF” on page 123 Appendix C, “Setting Up DDF”, to see the parameters weused.

On our system, DDF listened on TCP/IP port 33322.

Once DDF is set up, you can install DB2 Connect EE on Windows NT andestablish the TCP/IP connectivity needed for installing the Siebel software.

Remember, DDF must be up and running in order for DB2 Connect to be able toestablish a connection to DB2 on OS/390. If you have trouble connecting, makesure DDF is running.

3.2 DB2 Connect EE setup

We installed DB2 Connect V6.1 EE on a Netfinity system connected to our DB2DDB2 subsystem on OS/390. This section describes what we did to install DB2Connect EE 6.1 on the NT Server.

To avoid confusion, you should determine all the information you will need beforeyou start this process. Using inconsistent information will prevent you fromestablishing connectivity, and it will be difficult to determine what is incorrect.

Table 1 lists the parameters we used for our installation.

Table 2. Connectivity parameters

Parameter Source Value Used

Protocol Database Services TCP/IP

Target Operating System OS/390


3.2.1 Installing DB2 Connect EEUsing the CD-ROM DB2 Connect EE V6.1 for Windows NT we proceededthrough the installation screens. At the first one, shown in Figure 10, we clickedon Next to proceed.

Figure 10. DB2 Connect initial screen

Hostname SYS1.TCPPARMS(PROFILE)

WTSC04 or 9.12.14.219

Port Number Port number for DRDA inSYS1.TCPPARMS(PROFILE)

33322

Location Name Target Database DB2D

Database Alias For DB2 ConnectFor DB2 Run-Time Client

DB2DSBDB2os390

TSO User ID Valid user ID with RACF andDB2 dbadm

Siebel1

TSO password RACF password S1xxxx



On the product selection screen, we chose DB2 Connect Enterprise Edition asshown in Figure 11 on page 23.

Figure 11. Selecting the product to install

We then chose Typical for the installation type:

Figure 12. Choosing the type of installation

Chapter 3. Configuring database connections to DB2 on S/390 23

We chose to install this product in the directory D:\SQLLIB (see Figure 13).

Figure 13. Choosing the destination location

We had to enter the user name and password for the administrative service asshown in Figure 14 on page 24. This user ID and password combination is aWindows NT logon ID that has admin authority. We chose the default, db2admin.

Figure 14. Entering user ID and password

We also created the DB2ADMIN user on the NT and gave him admin authority asshown in 3.2.2, “Creating an admin ID” on page 26.


Note that, at the end of the installation you must reboot Windows NT and log inusing DB2ADMIN and password to catalog the database descriptors.

The system is ready to start copying files (see Figure 15). This is a chance toreview your choices or you can proceed by clicking Next.

Figure 15. Ready to copy the files

The setup is now complete (Figure 16). Click Finish, create an admin ID, rebootWindows NT, and then log in using the admin ID (DB2ADMIN).

Figure 16. Setup complete


3.2.2 Creating an admin IDTo create the default DB2ADMIN ID, do the following:

Go to user management:Start -> Programs -> Administrative Tool -> User ManagerClick User in the tool bar;Click New User in the pull-down menu.

Fill in the following information:

Username: db2adminFullnameDescriptionPasswordConfirm password

Choose one of the following password options:

User Must Change Password at Next LogonUser Cannot Change PasswordPassword Never ExpiresAccount Disabled

Click groups.

Select Administrators, then click Add.

Click OK on the group memberships window.

Click OK on the New User window.

Click Policy in the tool bar of the User Manager window.

Click User Rights in the pull-down menu.

Click the box for Show Advanced User Rights at the bottom of the User RightsPolicy window.

Click the pull-down menu for Rights and choose the following Advanced UserRights:

Act as part of the operating systemCreate a token objectIncrease quotasLog on as a serviceReplace a process-level token

Click Add each time on the User Rights Policy.

Click OK on the User Rights Policy window.

Reboot the system.


3.2.3 Configuring DB2 Connect EEAfter the system has rebooted and you logged in using DB2ADMIN, go to Start ->Programs -> DB2 for Windows NT -> Client Configuration Assistant to createand catalog database descriptors. On the welcome screen (Figure 17), chooseAdd Database.

Figure 17. Client Configuration Assistant welcome screen

For the Source, choose Manually configure a connection to a DB2 databaseand click Next (Figure 18).

Figure 18. Source option


For the protocol, choose TCP/IP, and OS/390 as the target operating system(Figure 19).

Figure 19. Protocol option

For the TCP/IP configuration, enter the OS/390 fully qualified hostname or the IPaddress of the OS/390 host. Enter the port that is reserved for the DDF in theDB2 instance. In our case, the host name was wtsc04.itso.ibm.com and the portwas 33322 (Figure 20).

Figure 20. TCP/IP parameters


Add the Location name, in our case DB2D, which is the DB2 OS/390 instancename. Enter the Database alias name that will be used by DB2 Run-Time clients.We chose DB2DSB (Figure 21).

Figure 21. Database alias name

Register this database as an ODBC source (Figure 22). This will allow access tothe host database by DB2 Run-Time clients.

Figure 22. ODBC option


We did not specify any node option (Figure 23). Just click Next.

Figure 23. Node option

For the security option (Figure 24), you must choose On the host or AS/400(DCS).

Figure 24. Security option


We did not choose any host options in Figure 25.

Figure 25. Host option

Figure 26 shows that we had successfully configured the connection. We wereready to test the connection by clicking Test Connection.

Figure 26. Completion of configuration for DB2DSB


To test the connection, enter a valid TSO RACF user ID and password, as inFigure 27. The user ID should also be DB2 authorized.

Figure 27. Testing the connection

You should get the message in Figure 28 if the connection is successful. If not,you should check that you can ping the host and that the DDF is running.

Figure 28. Successful connection

You can now close the Client Configuration Assistant.

3.2.4 Configuring the NT server for client accessNext, the NT server has to be configured for client access. The steps are:

1. Update the Windows NT services file with a connection service name, in ourcase DB2DSBC, and a port number/protocol, in our case 5000/TCP. DB2Connect listens on this port for clients accessing the host database. The file toupdate is in the directoryC:\WINNT40\SYSTEM32\drivers\etc\services.

We added the following line to this file:

db2dsbc 5000/tcp #Connection port for instance DB2D


2. To start the command line processor, make sure you are logged in to WindowsNT with a user ID that has admin authority for DB2 Connect. We useddb2admin. Start the DB2 command line processor by choosing:Start -> Programs -> DB2 for WindowsNT -> Command Line Processor;the window in Figure 29 on page 33 will appear.

Figure 29. Starting the command line processor

3. Update the database configuration file with the connection service nameparameters by entering the following commands:update database manager configuration using svcename db2dsbc

db2stop

db2start

Note: The db2stop command will halt your DB2 Connect environment.

4. Exit the command line processor by typing Quit at the DB2 prompt, then typeExit at the next prompt.

The DB2 Connect server is now ready for client access.

3.3 Client PC setup

In a three-tier connection, you need to set up your client PC by installing andconfiguring the DB2 Run-Time client code.

If you have a Windows NT operating system on your client PC, you must first adda user to your Windows NT (see example in 3.2.2, “Creating an admin ID” onpage 26). If you have Windows 95 or up, you may skip this step and proceeddirectly with the installation of the DB2 Run-Time client.


3.3.1 Installing the DB2 Run-Time clientThe DB2 Run-Time client code needs to be installed on the Siebel client PC. Theclient PC operating system we chose was Windows 95. If you have a WindowsNT operating system on your PC, you must first add a user to your Windows NTas described in the previous section.

The CD-ROM we used was DB2, Version 6.1 Run-Time Clients for Windows.When you insert the CD-ROM, you will go through the following series of screensto configure the DB2 Run-Time client.

After the welcome screen, you are asked to select the product to install as shownin Figure 30.

Figure 30. Product selection

The only choice is DB2 Run-Time Client, so choose it and click Next.

For the installation type screen, choose Typical. For the destination screen, wechose the D drive D:\sqllib. On the next screen, we did not choose Netbios.After the files were copied, we received the message Setup is complete, click on

Finish and reboot the machine.

3.3.2 Configuring the Client PCThe steps to configure the Client PC are:

1. Update the services file with a connection service name and port number. Theport number must be the same that was used on the NT server. The servicename is arbitrary. We added the following entry to the file:

C:\Winnt\system32\drivers\etc\servicesdb2dsbc 5000/tcp #Connection to DB Alias DB2DSB on Server

2. To catalog a TCP/IP node, we started the command line processor and issuedthe following command:

catalog tcpip node db2node remote 9.12.2.105 server 5000


Note: The node name is arbitrary. The remote is the IP address of the NTserver and the server has the port number used by both the client PC and theNT server machine.

3. To catalog the database on the client PC we used the following command:

catalog database db2dsb as db2os390 at node db2node

Note: The database name is the DB alias used on the server for DB2D. Thealias db2os390 is the DB alias used on the client.

3.4 Testing the Client/Server connection

To test the client/server connection, issue the db2start command, and then enterthe following command:

connect to db2os390 user siebel1 using s1xxxx

User Siebel1 is an OS/390 TSO RACF user ID and a DB2 authorized user.

A successful connection between the client and the server should result in thefollowing message:

Database Connection InformationDatabase Server = DB2 OS/390 6.1SQL Authorization ID = siebel1

Local Database Alias = db2os390


Chapter 4. Installing Siebel 2000

This chapter describes the steps we followed to install the Siebel software, asfollows:

• Installing Siebel on the NT server• Installing the S/390 Siebel DB2 database• Populating the Siebel file system• Siebel client installation

4.1 Installing Siebel on the NT server

The installation on the NT server includes:

• Creating a Siebel service owner• Creating the Siebel file system• Installing the Siebel Gateway Server and Name Server• Installing the Siebel Server and the Enterprise Server• Installing the Siebel Database Server scripts

4.1.1 Creating a service ownerThe first step is to create a Siebel sevice owner network domain account with theadvanced user rights “log on as a service” and “act as part of the operatingsystem.” This user ID must be part of the Administrators group. It is also requiredto install the Gateway Server.

At the desktop of NT select:

Start -> Program -> Administrative Tools -> User Manager.

Then, under User, select New User and fill in the appropriate data.

Note that the Password Never Expires box must be checked. This is not optionaldue to NT administration configuration requirements.

Next, click Groups.


Highlight the Administrators line and click Add.

Click OK -> Add -> Close.

Special user rights have to be defined to NT.

Back at the User Manager screen, select the Policies pull-down and then selectUser Rights.

Then, on the User Rights Policy window, click the Show Advanced UserRights check box at the bottom of the window. Use the pull-down menu for Right.


Two rights have to be implemented: Logon as a service and Act as part of theoperating system, which are chosen one at a time.

Select Logon as a service, then select Add.

Select Act as part of the operating system, then select Add.

4.1.2 Creating the file systemThe file system consists of a shared directory that is network-accessible to Siebeldedicated clients and to Siebel Servers. The file system we created was \siebfile.

Set up the file system via the following:

1. Create the directory. For example, mkdir G:\siebfile.2. Run Windows Explorer.

Chapter 4. Installing Siebel 2000 39

3. Highlight the \siebfile directory.Click File -> Properties -> Sharing.

Select the Shared As radio button and type in an appropriate name for theshared volume.

4. Click Permissions and choose the appropriate groupname to grant access toevery Siebel Server and Siebel Client. This group will be Everyone on manysystems.

5. Under the Type of Access pull-down picklist, choose Full Control.

6. Click OK to close the Permissions dialog box, and OK again to close the FileProperties dialog box.


4.1.3 Installing the Gateway Server and the Name ServerThe installation of the Gateway Server includes the installation of the NameServer.

1. Insert the Siebel Enterprise Server Programs CD-ROM.

2. In Windows NT Explorer navigate to the directory \gtwysrvr and double-clicksetup.exe.

If the system wants to reboot, you should click Yes to allow the reboot.

3. Select Next on the Welcome Screen. If you have not installed central dispatchyou will see the following message:


4. Click Yes to continue.

5. Select the destination directory. You may need to select Browse to change thepath.


6. In the Gateway Server NT Account Information dialog box, type the SiebelService owner account and password.

7. In the Gateway Server NT Services dialog box, check the Start Automaticallycheck box.

8. Click Next to start copying files.


9. Click Next when installation completes.

Click Finish.


10.Start the Gateway Server.

To start the Gateway Server, navigate to the Windows NT Control Panel anddouble-click on the Service icon. Find and select the Siebel Name Server andclick Start.

4.1.4 Installing the Siebel Server and the Enterprise ServerThe installation of the Siebel Server includes the installation of the EnterpriseServer.

1. Shut down all open programs.

2. Stop any active Siebel Server NT Services except the Siebel Gateway NameServer.

3. Start the Server install programs:Insert the Siebel Enterprise Applications CD-ROM, navigate to the \siebsrvrdirectory and double-click setup.exe.


4. Read the Welcome dialog box and click Next. If you have not installed CentralDispatch, you will see the message:

5. Click Yes to continue.

6. Insure that the Siebel Gateway Name Server Service is running and clickNext.

This is done by selecting Start on the NT desktop, then Setting -> ControlPanel -> Services, then scan to Siebel Gateway Name Server. If this does notindicate Started (it should also indicate Automatic), highlight and selectStartup.

Note: If you try to install the Application Server without the Gateway Serverand the Name Server running, the installation will stop.


7. Select the Typical setup and verify the Destination Folder. Click Next.


8. Verify the Gateway Server Address. Click Next.

9. Specify the Siebel Enterprise Server Information. Click Next.


10.Click Yes.

11.Specify the Siebel File System Location. Click Next.

12.Select the Database Client and Server version. Choose IBM DB2 UniversalDatabase 6.1 for OS/390.


13.Specify the Database Identification (use the DB2 Connect Database Alias)

14.Specify the User Name and Password to be used for Siebel Administration.


15.Specify the Name and Description for the Siebel Server to be installed.

16.Specify Start Automatically for the Siebel Server NT Service.


17.This window is used only if connection brokering was implemented. We did notuse this function, so we simply clicked Next.

18.Select eBriefings and/or eContent Services. We were not implementingeBriefings or eContent Services, so we selected Neither.


19.Specifiy the Java Thin Client Help File URL.We did not implement Siebel Thin Client, so we clicked Next.

20.Click Next to start copying files.

21.Click OK when the Enterprise Server has been successfully installed.


22.Review event log and click Next.

At this point we rebooted NT -- not because of any particular requirement, butbecause we felt it was a good idea to start “fresh” for the next step.

4.1.5 Installing the Siebel database server scripts1. Insert the Siebel Enterprise Applications CD-ROM, navigate to the \dbsrvr

directory, and double-click setup.exe.


2. Select Typical install and verify the Destination Folder.

3. Review the Event Log and click Next.


4. Click Finish at the Setup Complete window.

4.2 Installing the Siebel-DB2 database on OS/390

The following sections show the implementation steps for the Siebel databaseusing DB2 for OS/390.

4.2.1 Creating Siebel-DB2 objectsWe did part of the DB2 setup using traditional DB2 installation techniques,allowing us to manage the placement of data on DASD. We did the rest of theinstallation using Siebel’s automated installation from the application server.

4.2.1.1 Check RACF profiles and user IDsAt this point, you should have your RACF profiles and user IDs already set up asdescribed in 2.4, “Creating user IDs and assigning authorizations” on page 17.You should have:

• RACF groups SSEROLE and SSEEIM.• TSO user IDs SIEBEL and SADMIN with DB2 authorities sysadm and dbadm

granted to them, respectively. Both IDs should also be assigned to the RACFgroup SSEROLE.

Note that DB2 authority will be granted to the group ID SSEROLE during theinstallation of Siebel database scripts. The userid SIEBEL will be used as thetable owner and the TSO session will be started using the SIEBEL userid. TheTSO session will be used to submit the DDL to create the SIEBEL database.

4.2.1.2 Check DB2 buffer poolsAt least three DB2 buffer pools should already be activated as described in 2.5.1,“Buffer pools” on page 18.

Grant use of these buffer pools to the SIEBEL table owner ID and the SSEEIMgroup.


4.2.1.3 Check DB2 installation job DSNTIJUZVerify that DSNZPARM and DSNHDECP values required by Siebel are correctlyset up as described in 2.5.2, “DSNZPARM parameters” on page 19. See alsoAppendix C, “DSNZPARM parameters for DB2” on page 125 for the values weused.

4.2.1.4 Create storage groupsYou should have your VSAM catalog and alias defined as described in 2.5.3,“DB2 objects for Siebel” on page 19.

The DB2 DBA must create the STOGROUPs and grant use of the storage groupsto the SIEBEL table owner ID and the SSEEIM group.

We also recommend that you create STOGROUPs using SMS-managedvolumes. Spreading data sets across the SMS storage group volumes avoidshaving multiple index data sets for the same table on the same volume -- with thepotential for I/O contention problems.

4.2.1.5 Create the Siebel-DB2 databasesThe DB2 DBA must create the Siebel-DB2 databases. The sample configurationfiles provided by Siebel require 10 databases. The database names in thesamples tbspaces.sql and tbspaces.ctl are XXXXX001 through XXXXX010.

We altered the sample names to match our names, that is, we replaced the X’swith useful information (for example, altering XXXXX001 to SIEBEL01). Based onthe database names we chose, we created and submitted a job on the S/390system to create the SIEBEL databases. See Appendix D, “Siebel-DB2 objectscreation” on page 131, for the job we used.

4.2.1.6 Create Siebel table spacesThe Siebel installation scripts will generate the DB2 DDL to create the tablespaces and tables required for Siebel.

The file sea610\dbsrvr\db2390\tbspaces.sql must be changed to specify thecorrect database name, buffer pool name, and parameters, then uploaded to theTSO session and submitted.

Table 3 shows the database and table space layout for Siebel in our installation,which includes 10 databases and 144 tablespaces.

Table 3. Database and tablespace layout

Database Tablespace

SIEBEL01 FFFFF001

SIEBEL02 EEEEE002

SIEBEL03 GGGGG010 through GGGGG017

SIEBEL04 GGGGG001 through GGGGG008

SIEBEL05 HHHHH001, HHHHH002

SIEBEL06 BBBBB024 through BBBBB044CCCCC002DDDDD015 through DDDDD024DDDDD055


4.2.1.7 Create Siebel tablesIn order to create the Siebel tables, two files need to be altered:

• sea610\dbsrvr\db2390\tbspaces.ctl

• sea610\dbsrvr\db2390\generate_ddl.ksh

Look for the CHANGE_ME character string and alter appropriately.

Then issue the generate_ddl.ksh command.

Note: Files that end in .ksh are UNIX Korn Shell scripts that can be executedfrom an NT DOS command line by using the sh command, as in:

sh generate_ddl.ksh

An NT Korn Shell window could be used as well.

This generates an S/390 job stream to define / create tables and indexes andgrants authority to SSEROLE by creating sieb_schema.sql, which is uploaded toTSO and executed.

Note: In our run, there were 4 lines generated that exceeded 80 characters,which would cause an error in the job execution. We edited the file on NT toeliminate this error (by splitting the offending lines):

• EIM_PROD_OPT_T03• EIM_PRODOPTMIX_T03• S_PROD_OPT_IF_T03• S_PRODOPTMIX_I_T03

Doing a find on these names will bring you to the lines that need to be split.

4.2.2 Importing seed dataThis procedure “primes” DB2 with the data needed to allow initial login to theSiebel application. To load the seed data, use the install_siebel.ksh script.

SIEBEL07 AAAAA001 through AAAAA005BBBBB045 through BBBBB060DDDDD005 through DDDDD014

SIEBEL08 BBBBB001 through BBBBB004BBBBB061, BBBBB061CCCCC001DDDDD001 through DDDDD003DDDDD041 through DDDDD054

SIEBEL09 BBBBB006 through BBBBB016DDDDD030 through DDDDD040

SIEBEL10 AAAAA006 through AAAAA008BBBBB017 through BBBBB023BBBBB025 through BBBBB029

Database Tablespace


The script /sea610/dbsrvr/db2390/install_siebel.ksh must now be modified forsource user and password, table owner and password, ODBC connect string, theDB server, Siebel home directory, and the DO_DDL keyword. These aresubstitution variables found at the top of the script.

Navigate to the \sea610\dbsrvr\db2390 directory after making changes and entersh install_siebel. This script will import the Siebel seed data. It took us about 25minutes to run this job in our environment.

4.2.3 Validating database objectsThe script \sea610\dbsrvr\db2390\validate_objects.ksh needs to be modified forsource table owner and password, the ODBC connect string (DB2DSB), and thesiebel home directory g:\sea610\siebsrvr.

Navigate to the \ser610\dbsrvr\db2390 directory after making changes and entersh validate_objects. This script will create the file 390_objects.txt, which lists allthe views and precedures by name and creator (views only).

4.2.4 Importing Siebel repositoryAt this point, the Siebel repository is loaded into the database. The scriptimprep.ksh is modified and executed.

Modify the script \sea610\dbsrvr\db2390\imprep.ksh for source user andpassword (SADMIN), source table owner (SIEBEL), ODBC connect string(DB2DSB), the database server, and SIEBEL home directories (g:\sea610\dbsrvr- g:\sea610\siebsrvr), the database platform (DB2390), and DB_LANG, for whichwe chose ENU (ENglish Us).

Enter sh imprep and press Enter from the \sea610\dbsrvr\db2390 directory.

Upon completion of this step, the database server installation is complete.

4.3 Populating the file system

Correspondence templates and Siebel marketing files are provided with theSiebel Database Server software. A subdirectory called “files” is createdautomatically when you install the Siebel Database Server. You must populatethe file system directory with these file attachments after installing the databaseserver, and before running the Siebel Client. Navigate to the database serverdirectory “files” and copy the contents to the file system.

4.4 Installing the connected client

This section describes the steps we followed to install the connected client.Although client installation and customization are outside the scope of this book,we did a basic install in order to test our installation of the database server onS/390, that is, to actually transfer DB2 data to and from the client. We did this onthe same machine (Windows NT) that the other Siebel servers were installed on.

Note that this installation requires a License Key; make sure it is available.


Insert the Client CD into the reader. Using Windows Explorer, navigate to the seadirectory and then click Setup to initiate the installation of the client.

Click Next.

We altered the path statement to match our environment and clicked Next.


We selected the OS 390 button and clicked Next.

We had installed Microsoft Office 2000, so we simply clicked Next.


We entered our Remote Server and Siebel file system locations and clicked Next.

We entered the Database Alias, Table Owner and SQL ID and clicked Next.


We entered our Server Addresses and clicked Next.

We clicked Next.


We clicked Next.

We clicked Next.


We took the default and clicked Next.

The installation ran a few minutes.


The Event Log is displayed; we clicked Next.

Click Next.


The setup is complete; click Finish.

We then clicked the Siebel Call Center desktop ICON, and logged on.

When logging on the first time, we were presented with the License Key screen,which has to be filled in with the license key obtained from Siebel, before thelogon is completed.


Chapter 5. Importing data with EIM

After installing Siebel 2000 we wanted to test how we could use EnterpriseIntegration Manager (EIM) to import external data into the Siebel database.

The Siebel database uses a highly normalized data model. Loading data directlyinto Siebel base tables is not supported. Due to the complexity of tablerelationships, you must use EIM to import data into Siebel base tables. Youshould not attempt to modify data directly in the physical tables.

A majority of Siebel customers prime the database with their own data using EIM.For example, they will load data such as their current accounts, employees,contacts and products. The Siebel EIM Administration Guide explains therecommended method and order of importing data.

EIM is the high-speed bulk data movement utility to import, export, merge, anddelete data to and from a Siebel database. The EIM utility uses your applicationdefinition and the database definition in the repository to insure the correctplacement of data and the relationship of all key data between tables. This utilityis also used to archive and purge aged production data. Attempting to do batchinserts or updates outside of EIM may result in orphan data in the database.

Figure 31 shows the flow of the EIM process.

Figure 31. EIM process flow

The following prerequisites must be addressed before running EIM:

• A DB2 OS/390 temporary database and table spaces must have been createdfor the declared global temporary tables. See Appendix E, “Adding atemporary database and table spaces” on page 137.

CustomerApplications

Homegrown

application

Readtransform

EIMinterface tables

Export

Import

EIM

ImportExportMergeDeleteArchive(ExportthenDelete)

ImportExportMergeDelete

Siebelrepository

IMPORT.IFB

EXPORT.IFB

MERGE.IFB

DELETE.IFB

DB2 OS/390

DB2 OS/390

Siebel Database

DB2 OS/390

NT server

User writtenprogram

Archive/Restore

Purchasedapplication

Departmentalapplication

Externalfeed

(purchaseddata)

NT files


• The DB2 OS/390 DSNUTILS Stored Procedure must have been installed andthe OS/390 WLM environment must have been set up. See Appendix F,“Stored procedures enablement” on page 139 for more details.

For all EIM processes, you need to complete the following sequential steps:

• Prepare the interface tables

• Edit the EIM configuration file

• Run EIM

• Check results

5.1 Preparing EIM interface tables

Siebel interface tables (IFs) are intermediate database tables that act as astaging area between the Siebel application database and other databases. EIMinterface tables are denormalized tables mapped to the Siebel database via therepository definitions. The repository maps the denormalized EIM interface tablesto the normalized Siebel database, and defines the key relationship betweentables.

Before EIM can be used, the database administrator (DBA) needs to populate theIFs with data to be processed by EIM. This process would be performed by acustomer-written program that would read the customer data and insert it into theEIM IFs.

You then invoke EIM to process this data.

In our test environment we populated the EIM interface table S_ZIPCODE_IF byexporting data from the Siebel base tables.

5.2 Editing the configuration file

After populating the IF tables, do the following:

• Log onto the Siebel system with the Siebel administration ID.

• Verify that the eAI component group is enabled.

Navigate to the enterprise group screen (Choose: Screen -> ServerAdministration -> Enterprise Configuration -> Enterprise ComponentGroups) and check whether the eAI component is enabled (Figure 32 on page71).

If this component is not enabled, follow the instructions for enabling acomponent group in the Siebel Server Administration Guide.


Figure 32. Component Group Components

• Create an EIM interface batch parameter file.

Create the file in the sea610\siebsrvr\admin directory. Siebel provides adefault file (default.ifb) that contains examples of import, export, merge,delete, and purge EIM processes. Figure 33 shows the Zipimp.ifb file wecreated to import the S_ZIPCODE_IF table.

Figure 33. Zipimp.ifb file

Chapter 5. Importing data with EIM 71

5.3 Running EIM

After editing the configuration file, do the following:

• Navigate to the Siebel Server Tasks:

Choose: Screen -> Server Administration -> Servers -> Server Tasks.On the Server Tasks applet select New.

• In the component pick list choose Enterprise Integration Manager (Figure34).

Figure 34. Pick Assigned Component selection

• On the Server Tasks applet choose Parameters.

• Double-click in the value column of the configuration file row (Figure 35).


Figure 35. Parameter Overrides

• Type in the name of the IFB file, zipimp.ifb, then click Close (Figure 36).

Figure 36. Typing in the IFB file name


Note that if the batch number is not supplied in the IFB file, you must supply ithere. This batch number must match the IF_ROW_BATCH_NUM column in the IFtable you are working with.The EIM interface tables can be partitioned on a field such asIF_ROW_BATCH_NUM. This allows you to run parallel EIM batch processes forlarge imports. In this case you would not supply the batch number in the IFB file,but instead supply it on the parameter screen.

• On the Server Task applet screen select Start to run EIM (Figure 37).

Figure 37. EIM task running


5.4 Checking the results

When an import process ends, you should carefully check the results to verifythat data was successfully imported.

• Review the log when completed on the Server Tasks applet screen.

• When the status shows “completed” for the EIM task, double-click on the tasknumber for the EIM task (Figure 38 on page 75).

Figure 38. EIM task result

Our results show that the data import has completed successfully.


Chapter 6. Security considerations for Siebel with DB2 for OS/390

This chapter discusses security considerations that are specific to Siebel andDB2 for OS/390. The discussion mostly refers to the Siebel white paper SecurityConsiderations for Siebel on DB2 for OS/390.

When discussing security we must distinguish between the security requirementsof the infrastructure that is protecting the system, versus the user’s authority toview and modify data.

When using S/390 for the database server, client access of DB2 will require logonvalidation by the OS/390 Security Server, such as RACF, and the appropriateDB2 grant authority. The client architecture is such that each user needs a RACFID. DB2 authority is granted to the user group SSEROLE for all Siebel tables atinstallation time through the use of install scripts. All Siebel users need to beconnected to this user group in RACF. The user group does not have to beSSEROLE, but that is the default.

Siebel for OS/390 requires the RACF and LAN passwords to be identical. TheLAN userid and password act as the login ID and password for the Siebelapplications.

Siebel does not require users to periodically change their password.Nevertheless, periodic changes to RACF passwords are generally required by thesecurity policies in the OS/390 environment. If the RACF password is changed,the passwords for the LAN must also be changed.

Siebel provides the Native Authentication Adapter, Lightweight Data AccessProtocol (LDAP), and Security API security approaches.

6.1 Siebel internal application security

All users must provide a user name and password to connect to the Siebelapplications, irrespective of the access mode (connected client, thin client,mobile, etc.). Each user name and password must be preregistered in the Siebelapplication and be associated with a unique Employee record.

The unique Employee record determines a user’s Visibility to data by associationto Positions and Responsibilities. Responsibilities determine which screens andviews are available to the employee. Positions determine which data rows appearin those views, and which data rows are synchronized to a mobile client's localdatabase.

Attachments, which are not stored in the database, are stored in a compressed,encrypted format on the Siebel file server. Attachments are linked to data rows,and therefore access to attachments is restricted by a user's Responsibilities andPosition.

6.2 Siebel data security

Data access is typically granted to a specific user or group for specific databasetables. Changes in a user's job assignment may require adjustments to thatuser's data access privileges. For example, a sales representative who is


promoted to management may need access to information for multiple territories.Traditional data security measures often require that the database administratorchange a user's access privileges at the database level whenever that user'sresponsibilities change.

Siebel applications enable you to control user access to information from withinthe application. Since the need to know specific information is usually related to aparticular responsibility, Siebel applications define data access by Responsibility,not by user. Each Responsibility provides access to a particular set of views,including the ability to see specified data and take specified actions.

To grant a user access to data and functions, add the user to a Responsibilitywith the proper authority. For example, you would add the name of the new salesmanager to the Sales Manager Responsibility. Personnel assigned to the SalesRepresentative Responsibility can view opportunity and account information, butonly for those opportunities and accounts to which they are assigned. This dataaccess security rule is enforced by the Opportunity list view and Account list view.

In contrast, the manager's Opportunity or Account list views enforce a differentrule: they allow a manager to access all opportunities and accounts assigned tothe manager's employees.

6.3 Siebel External Security Adapter

The External Security Adapter is an interface that enables you to use an externalsystem to authenticate users rather than the traditional approach of using thedatabase. Using the traditional approach, you create a database account for eachSiebel user. When users log on to the Siebel application, the databaseauthenticates the user names and passwords. Using the External SecurityAdapter, you maintain user information in an external authentication system, suchas an LDAP repository.

When users log on to the Siebel application, the External Security Adaptervalidates the user name and password against the information in the externalsystem. If the External Security Adapter finds a match, it retrieves a generic set ofuser credentials (username/password) that are used to gain access to thedatabase. Note that these can be the same credentials for every user if desired.This option may be preferred for enabling direct customer access Siebelapplications via a Web application such as Siebel eSales.

Using the External Security Adapter facilitates administration, because you donot have to create an account for each Siebel user. You can use a few genericdatabase accounts that are used by multiple Siebel users. The External SecurityAdapter that comes with Siebel 6.1 uses an LDAP repository as the externalauthentication system. To implement the External Security Adapter, you need toprovide an LDAP server, such as Netscape's LDAP server. And you must create asingle LDAP repository of user information that is structured to enforce theuniqueness of login names.

You can also create your own external security adapter. You can find the APIdocumentation on the Siebel Support Web site. The title of the document isSiebel 2000 Open Authentication Model: Security Adapter Interfaces.


6.4 OS/390 security

The user name and password used to access Siebel are passed by the DB2Connect middleware to the OS/390 mainframe to establish a connection. Theuser name and password could be user credentials supplied by the ExternalSecurity Adapter (LDAP), if this option has been implemented. All user namesand passwords are required to be pre-registered with the OS/390 SecurityPackage (RACF, ACF/2, TOP SECRET, etc.). This task is performed by anOS/390 security administrator, or by someone who has been delegated thisauthority.

The Security Package authenticates the user name and password and controlsaccess to all resources, including connectivity to the DB2/390 database. AllOS/390 accounting (resource usage) information is associated with this username for charge-back purposes.

Optionally, the user name can be associated with a Group User Name within theOS/390 Security Package to simplify database security privilege administration.Group User Names are created by an OS/390 security administrator, or bysomeone who has been delegated this authority.

Siebel recommends using Group User Names, and suggests associating usernames with the SSEROLE Group. Other optional Group User Names couldinclude:

• SSEEIM for Enterprise Integration Manager (EIM) server processes

• A Siebel Database Administrator Group User Name identical to the chosenTable Owner name (e.g., SIEBEL)

This will allow the DBA to more easily refer to Siebel tables unqualified bytable owner after running the statement

SET CURRENT SQLID = 'SIEBEL'.

The suggested Group User Names may be changed to conform to corporatenaming standards.

6.5 DB2 for OS/390 security

By default, DB2/390 restricts access to database resources unless privileges arespecifically granted. Access to database resources is established in one of thefollowing ways:

6.5.1 Granting table privileges to a Group User NameAccess privileges to use database resources such as tables, views, triggers, etc.are granted to Group User Names such as SSEROLE with GRANT statements.By using Group User Names, the administration of database security issignificantly reduced, because privileges are granted only once to a Group UserName rather than to each Siebel user.

The Siebel installation process allows the installer to specify the Group UserName for client access (e.g., SSEROLE), and the resulting installation scriptsgenerate the appropriate GRANT statements. GRANT statements for otherGroup User Names that may be required must be created manually.

Chapter 6. Security considerations for Siebel with DB2 for OS/390 79

The GRANT statements must be executed by either the Table Owner, a DB2/390Database Administrator (DBADM), or a DB2/390 System Administrator(SYSADM).

6.5.2 Granting program execution privilegesMany corporations using the DB2 for OS/390 platform restrict access to databaseobjects such as tables, views, and triggers, granting users access only to runningthe application programs that use these resources. This prevents users fromcircumventing application security restrictions by accessing data directly viamechanisms other than the Siebel application. This option can be implementedfor Siebel applications as follows:

• Bind the DB2 Connect program packages into a new DB2 Collection with theDYNAMICRULES parameter set to BIND. For detailed instructions, see 6.5.4,“Binding the DB2 Connect packages” on page 81.

This causes DB2 for OS/390 to use the authorization ID of the package forauthorization checking of dynamic SQL statements, rather than using theauthorization ID of the application user.

• Grant EXECUTE privilege on the new packages to the Group User Name forclient access (e.g., SSEROLE).

• Edit the DB2 Connect Command Line Interface initialization filec:\SQLLIB\db2cli.ini on the client PC, adding the following line after bothsections corresponding to Siebel server and Siebel Client ODBC DataSources i.e., [SiebSrvr_SES610] and [SEA DB2DSB c:\sea610\CLIENT] :

CURRENTPACKAGESET= XXXXXXXX

Where XXXXXXXX is the name of the new DB2 collection name.

This step tells DB2 Connect to use the program packages in the newcollection when establishing a connection for a Siebel client or server process.The modified db2cli.ini file should be distributed to all Siebel clients andservers.

6.5.3 Dynamic Statement Caching considerationsSiebel applications take advantage of the DB2/390 Dynamic Statement Cachingfeature to avoid reoptimization of dynamic SQL statements. This feature reusespreoptimized database access plans when a previously optimized SQL statementis executed by the same authorization ID.

6.5.3.1 Installing Siebel with Group User NamesSiebel recommends implementation of Group User Names, because securityadministration is greatly increased if Group User Names are not implemented.

The Siebel application issues the command SET CURRENT SQLID = SSEROLE(or other Group User Name) prior to accessing any database resources, to set acommon DB2 authorization ID for all users. This maximizes the effectiveness ofDynamic Statement Caching for multiple users.

Note that the use of Group User Names does not prevent individual users frombeing identified by OS/390, or as the source of data modifications within theSiebel database.


6.5.3.2 Installing Siebel without Group User NamesCustomers whose security standards preclude the use of Group User Namesmust take additional action to ensure that they will benefit from DynamicStatement Caching:

• Access to DB2/390 resources must be implemented by following the stepsoutlined in 6.5.2, “Granting program execution privileges” on page 80.EXECUTE privilege on the new packages should be granted to each Siebeluser name rather than to a Group User Name.

• The Siebel configuration file uagent.cfg should be edited to remove thefollowing line from the [Server] section:

CurrentSQLID = SSEROLE

This step is necessary because Siebel cannot issue the command SETCURRENT SQLID = SSEROLE if Group User Names are not implemented inthe OS/390 security package. Siebel will use the authorization ID of the DB2package for Dynamic Statement Caching instead of the Group User Name.

6.5.4 Binding the DB2 Connect packagesThis section shows how to bind the DB2 Connect Command Line Interface(DB2CLI) program packages to allow DB2 for OS/390 to use the authorization IDof the package for authorization checking of dynamic SQL statements, ratherthan using the authorization ID of the application user.

1. Create the list of Bind files:

Edit the file c:\SQLLIB\bnd\ddcsmvs.lst and copy the six records beginningwith db2cli (i.e., db2clish.bnd+, db2clisn.bnd+, db2clibh.bnd+, db2clibn.bnd+,db2clims.bnd+. db2cliv2.bnd+) into a new file, e.g., ddcssieb.lst. Remove theplus sign from the last record. Save the file.

2. Open a DB2 Command Line Processor window and run the followingcommands:

• CONNECT TO ssid USER uuuuuuu USING ppppppp

where ssid is the DB2 Connect Database Alias Name for the DB2/390subsystem, uuuuuuu is the user name, and ppppppp is the password. Theuser name should have either SYSADM authority or DBADM + BINDADDauthority, and be part of a Group User Name that allows the user to act asthe Siebel table owner.

If uuuuuuu is not the Siebel table owner, run the following SQL statement:

SET CURRENT SQLID = ttttttttt

where tttttttt is the Siebel table owner.

• BIND @ddcssieb.lst COLLECTION xxxxxxxx BLOCKING ALLDYNAMICRULES BIND OWNER ttttttttt QUALIFIER ttttttttSQLERROR CONTINUE

where xxxxxxxx is the new Collection name and tttttttt is the Siebel tableowner.

3. Run the following SQL statement to grant EXECUTE privilege on the newpackages to the Group User Name for client access (e.g., SSEROLE):

GRANT EXECUTE ON PACKAGE xxxxxxxx.* TO sserole

where xxxxxxxx is the new collection name.

Chapter 6. Security considerations for Siebel with DB2 for OS/390 81

6.6 Data transmission security

Access to Siebel applications by thin client users often occurs via the Internet.Synchronization of mobile clients usually occurs over dial-up telephone lines.

6.6.1 Siebel support for data transmissionTo ensure data transmission security for these situations, Siebel supportscompression and encryption of data between clients and the Siebel ObjectManager and Remote Manager processes.

6.6.2 DB2 Connect support for data transmissionDB2 Connect allows user-friendly password changes, and supports passwordencryption on DRDA connections.

6.6.2.1 Password changeDB2 Connect 6 (FixPak 3SA) now permits users to change their passwordswithout having to log on to their database server. Users can now change theirpasswords in any one of the following ways:

• Using the SQL CONNECT statement from the DB2 Command Line Processor• Requesting a password change from within the ODBC login dialog• Using the password change option of the Client Configuration Assistant• Using the ATTACH command

In addition, application programmers can now take advantage of DB2 Connectenhanced password management to deliver more robust security mechanisms fortheir applications.

6.6.2.2 Password encryption on DRDA connectionsBefore this enhancement, DB2 Connect used to flow clear-text passwords to DB2for OS/390, resulting in a security exposure.

Server support is available in DB2 V6 which includes support for a DRDApassword encryption mechanism. DRDA password encryption allows remoteworkstation users to be authenticated without requiring clear-text passwords toflow in the network. DB2 V6 server supports the DRDA level 6 passwordencryption flows from any compliant DRDA level 6 requester.

Client support is provided by DB2 Connect. DB2 Connect V6 supports DRDAlevel 6 password encryption. To enable DB2 Connect to flow encryptedpasswords, DCS authentication must be set to DCS_ENCRYPT in the DCSdirectory entry.

When the workstation application issues an SQL CONNECT, the workstationnegotiates this support with the DB2 server. If supported, a shared private key isgenerated by the client and server using Diffie-Hellman public key technologyand the password is encrypted using 56-bit DES with the shared private key. Theencrypted password is nonreplayable and the shared private key is generated onevery connect. If the server does not support password encryption, theapplication receives SQLCODE=-30073 (DRDA security manager level 6 notsupported).


Chapter 7. Administrating DB2 with Siebel

This chapter reviews DB2 installation and data administration topics based on:

• Our Siebel installation experience

• Interviews with consultants who have assisted in implementing or tuningSiebel

• Our DB2 experience

7.1 DB2 installation recommendations

We highly recommend that you create a unique DB2 subsystem for Siebel. Thereason is that point-in-time recovery scenarios, discussed later in this chapter,are difficult to manage and implement in a DB2 subsystem shared with otherapplications.

A list of PTFs recommended for OS/390 Siebel installations may be found in theSiebel Release notes. Make sure you have these PTFs installed.

7.2 Siebel-DB2 database design recommendations

When you install the Siebel 2000 database server on DB2 for OS/390, you shouldconsider the following database design issues and recommendations on:

• Database objects• Free space• Locking• EDM pool• Buffer pool

7.2.1 Database objectsThe Siebel 2000 installation process produces the following Siebel-DB2 objects:

• 10 DB2 databases are defined.

• 144 table spaces are defined.

Databases contain a maximum of 32 table spaces.

• There are 1,372 tables defined.

The table spaces contain from 1 to 86 tables with 3 table spaces containingover 50 tables. As a rule of thumb, we recommend that a table space containno more than 100 tables.

Note: Any number of tables per table space greater than one is somewhatarbitrary. Given the number of tables and the challenge of managing the datasets containing those tables (a DB2 table space maps to a VSAM data set),multiple tables per table space (up to 86 as implemented by Siebel 2000)represent a practical strategy.

The table spaces are defined with page sizes of 4K, 16K, or 32K. The largerpage size is due to the fact that over half of the columns defined in the tablesare Varchar or Long Varchar.


• There are 7,322 indexes defined on the 1,372 tables.

54 tables have between 18 and 46 indexes. This number of indexes, althoughhigh, should not be a cause for concern. The Siebel 2000 application, asnoted before, contains a large amount of text, which suggests apreponderance of single-row processing (multiple-row processing tends toinvolve data summarization, which does not apply in general to textapplications). Consequently, the large number of indexes appears to supportsingle-row SQL processing, which is a characteristic of text applications.

There is a characteristic of the Siebel 2000 indexes that requires planning.The indexes frequently contain Varchar data columns. DB2 pads Varcharindex columns to the maximum size of the column. This means that the DASDspace requirements for the indexes will be significant.

Adhering to the Siebel 2000 install process will cause indexes to be generatedwith a primary allocation of 125 4K blocks and a secondary allocation of 2504K blocks. We believe that these allocations may be inadequate for someindexes. However, our testing did not enable us to identify specific indexesthat would require a greater DASD allocation. We recommend that you changethe primary allocation to 48 (keep it small), but raise secondary allocation forthe indexes to 9600.

In this way, small indexes will take minimal space (perhaps as little as theprimary allocation of 48 4K blocks), and larger indexes will not exceed themaximum number of extents.

Some Siebel databases contain a relatively large number of objects. Be aware ofthe impact of such databases:

• The DB2 Database Descriptor (DBD) will be large.

The DBD must be loaded contiguously into the DB2 Environmental DescriptorManager (EDM) pool. DB2 will not load a DBD into an EDM pool if it is largerthan 25% of the pool size.

• Log activity may be significant.

DB2 logs the necessary undo/redo information for the unit of recovery in whichthe DBD was changed. Updating large DBDs can cause significant logging.

• Contention should be considered.

Create, Alter, or Drop of a DB2 object locks the DBD. This may causecontention. The contention on active databases may cause DDL to time-out,or users may be locked out while DDL is being executed.

For these reasons, you may want to consider splitting databases that contain alarge number of DB2 objects.

7.2.2 Free spaceWe recommend that table spaces be defined with zero free space. Since noclustering indexes are defined, the sequencing of data rows is of no significance.If free space is defined along with no explicitly defined clustering index, DB2 willattempt to insert the data (as a result of the SQL Insert) in the sequence of thefirst index defined. There is no reason to believe that this would bring any benefit,while zero free space will produce a saving of DASD.


For indexes, use 20% free space. Since some index keys are large, a lower freespace may not provide any benefit.

7.2.3 LockingFor the LOCKSIZE table space parameter, specify LOCKSIZE(PAGE) unless theSiebel documentation recommends LOCKSIZE(ROW). Use row-level locking onlywhen needed for concurrency. Row-level locking will increase CPU overhead.

Some Siebel applications have large Units of Work. Thus, specifying row-levellocking may require adjustments to the ZPARM parameters NUMLKTS andNUMLKUS, or the table space parameter LOCKMAX. The maximum value forNUMLKUS (locks per user) is 100000. NUMLKUS=0 disables this limit.

7.2.4 EDM pool sizeThe EDM pool size for Siebel implementations may range from 20 MB to 150 MB.The major variants are the number of objects included in the database and theamount of storage devoted to caching of dynamic plans. As the size of the EDMpool increases, consider caching it in a data space.

See Appendix C, “DSNZPARM parameters for DB2” on page 125, for the valueswe used.

7.2.5 Buffer poolsThe following are general recommendations for initially configuring the DB2buffer pools in support of Siebel 2000. These recommendations assume that theDB2 subsystem is dedicated to Siebel, and are presented as percentages of thenumber of buffers you assign to the DB2 buffer pools. For example, if you have100,000 DB2 buffers, you would assign 10% or 10,000 buffers to BP0.

• BP0 - 5%. Restrict BP0 to the DB2 catalog and directory. This facilitates thedynamic SQL that Siebel executes. Actually, 2000 buffers should be enoughfor BP0 when it is used only for catalog and directory.

• BP1 - 15%. BP1 supports tables with 4K pages.

• BP2 - 30%. BP2 is dedicated to the indexes on tables with 4K pages. Indexestend to have a higher buffer reuse. Consequently, we recommend a highbuffer allocation for the index buffers.

• BP7 - 10%. BP7 supports DB2 temporary storage (DSNDB07). The SQLOrder By or Group By, for example, have the potential to require a DB2 sort,which DB2 supports through the use of DSNDB07 work database.

BP7 will also support the temporary tables in their assigned database andshould therefore provide additional buffers for this support. Since thetemporary tables are only used for EIM runs, the installation should be sure tomonitor the BP7 hit ratio during EIM runs and make any necessaryadjustments.

• BP16K1 - 10%. Supports 16K pages.

• BP3 - 10%. Supports the indexes on tables with 16K pages.

• BP32K1 - 10%. Supports 32K pages.

• BP4 - 10%. Supports indexes on 32K pages.

Chapter 7. Administrating DB2 with Siebel 85

7.3 Siebel-DB2 database maintenance recommendations

Here are our recommendations for database reorganization and statisticsgathering for Siebel data.

7.3.1 Database reorganizationWe recommend the following regarding the use of the DB2 REORG utility insupport of Siebel data:

• Do not REORG any Siebel table spaces.

No Siebel indexes are defined explicitly as clustering. The REORG utility willnot resequence a table that does not have a clustering index explicitly defined(its function in this case will be limited to reestablishing free space). Since thebenefit of REORG is minimal given no explicitly defined clustering index, werecommend that you do not execute REORG against Siebel table spaces.

• Use online REORG against Siebel indexes.

There is a benefit to reorganizing indexes: online REORG significantlyreduces the impact of this process.

7.3.2 Statistics gatheringWe recommend that you run RUNSTATS once on Siebel data after the tables areinitially populated. Afterwards, on a monthly basis, run RUNSTATS against theSiebel non-unique indexes. Since there are no clustering indexes defined,statistics like CLUSTERRATIO will be irrelevant. DB2 will cause unique indexesto remain unique, meaning that RUNSTATS will have nothing new to report onthose indexes (that is, the one-to-one mapping of the number of keys to thenumber of rows will continue to persist).

7.4 Siebel-DB2 database recovery recommendations

In a Siebel-DB2 environment you should consider the following recoveryconsiderations:

• Recovery to currency• Disaster recovery• Point-in-time recovery (PIT)

7.4.1 Recovery to currencyRecovery to currency focuses on how you would handle a hardware failure likethe loss of a DASD device.

From the perspective of the Siebel environment, “recovery to currency”considerations are the same as for any DB2 environment. If you are anexperienced DB2 for OS/390 user, your present “recovery to currency” strategycan be applied to your Siebel environment.

If you are a new user of DB2 for OS/390, you will want to do the following:

• Attend classes focused on training in the use of the DB2 recovery/restartutilities.


• Study the DB2 Utility Guide and Reference, focusing on the RECOVER andCOPY utilities.

• Study the DB2 Administration Guide, focusing on the section that addressesoperation and recovery.

• We suggest that you periodically attend either local or national user groupmeetings. They frequently feature speakers addressing recovery-relatedtopics.

7.4.2 Disaster recoveryDisaster recovery addresses how you would handle the loss of your computingcenter.

From the perspective of the Siebel environment, disaster recovery considerationsare the same as for any DB2 environment. If you have disaster recoveryprocedures that address your current DB2 environment, they will also likelyaddress your Siebel disaster recovery requirements. If you do not presently haveDB2 disaster recovery procedures, you will want to evaluate the followingpotential starting points for disaster recovery support:

• Disaster recovery using dump/restore

This is a frequent starting point for disaster recovery support. The scenario in7.4.3.3, “PIT recovery using dump/restore utilities” on page 90, could alsoprovide a starting point in addressing your disaster recovery requirements.

• Documented disaster recovery scenario

See your DB2 Administration Guide. The index will refer you to a section onpreparation for disaster recovery, and to a disaster recovery scenario. If youship off-site copies of both your image copies and archive logs, thedocumented scenario will enable you to recover to the last completed DB2 unitof recovery on the last archive you sent off-site. The scenario is popular;however, it does require practice.

• Disaster recovery with additional hardware

This is a broad topic that varies widely in both user requirement and scenarioimplementation. See 7.4.3.5, “PIT recovery using suspension of DB2updating” on page 92 for a scenario that could also provide a starting point inaddressing your disaster recovery requirements. This scenario will requirehigh-speed hardware to get copies of your DB2 log and data off-site.

7.4.3 Point-in-time recoveryThe usual reason for a point-in-time recovery is an application programming erroror a flawed operational procedure. This exposure is always present, regardless ofyour hardware/software configuration. A point-in-time recovery, in a Siebelenvironment, has the potential to be the most disruptive outage you are likely toencounter

You may need to recover all Siebel-DB2 objects to a prior point in time.Depending on how you have mapped your tables to tablespaces, this could meanrecovering 144 tablespaces and 7322 indexes to a prior point of consistency.Your usual point-in-time recovery techniques, which you probably regard asconventional at this time, may be insufficient in this environment.


A failure in application development, such as a programming defect, or inoperational procedures, such as running a job twice, introduces the requirementfor point-in-time recovery. As much as possible, you will want to avoid PITrecovery with preventive measures such as increased attention to:

• Change management• Problem management• Testing

Each of these disciplines is procedure-oriented and management-driven. Asattention to these disciplines is increased, the need for point-in-time recovery isusually decreased. Unfortunately, the need for point-in-time recovery is neverentirely eliminated. Consequently, you will want to make every effort to avoidhaving to do a point-in-time recovery, but you should be prepared to do one ifrequired.

PIT recovery usually involves resetting a table or group of tables to a prior pointin time when data was determined to be consistent. The challenge in the Siebelenvironment is determining the set of tables that are logically related. It ispossible that you will not be able to determine a subset of the Siebel tables to bereset. You will likely be required to reset all Siebel tables to a prior point ofconsistency.

There are several techniques to effect a point-in-time recovery, including

• PIT recovery using user-written application programs

• PIT recovery using DB2 utilities

The DB2 Quiesce and Copy utilities are the primary tools.

• PIT recovery using a dump/restore scenario

This scenario typically employs non-DB2 utilities.

• PIT recovery using a DB2 conditional restart

Any conditional restart scenario is potentially risky. The benefit of this scenariois the “effectively free” establishment of the point of consistency.

• PIT recovery using suspension of DB2 update activity

DB2 update activity is suspended using the SET LOG command toSUSPEND/RESUME logging. This function was introduced into DB2 Version 6with APAR/PTF - PQ31492/UQ36695.

7.4.3.1 PIT recovery using user-written application programsThis is a strategic direction and not a scenario. It acknowledges that data can becorrupted due to program error. If this happens, you may attempt to correct thecontaminated data with application programs. If you fail to correct the data withapplication programming, a scenario such as one of those following could beused as a last resort. This approach is gaining favor among users striving for highavailability.

In implementing an approach like this, it is important to determine whichtransactions will make the data more corrupt or propagate the errors. Thisinformation then can either be communicated to the end users, or the DBA canuse it to disable the dangerous transaction.


7.4.3.2 PIT recovery using DB2 utilitiesThe scenario for a PIT recovery using DB2 utilities is as follows:

• Determine the set of tables that are logically related.

Typically this is a subset of the tables that make up the application database.However, it may be all Siebel tablespaces and indexes.

• Optionally, execute the QUIESCE utility on all of the tables that are candidatesto be reset if a PIT recovery is required.

This establishes a point of consistency and causes the DB2 buffers for thequiesced tables to be externalized to DASD.

• Execute the COPY utility on all the tablespaces that are candidates to be resetif a PIT recovery is required.

The obvious reason for this step is to back up the data. However, COPY willfail if it cannot externalize the DB2 buffers to DASD. That is the reason weinvoked the QUIESCE utility first (to remove one reason why COPY may fail).

You may want to place your Image Copy output on DASD. With DB2 V6.1,DASD-resident image copies enable parallelism in both the COPY andRECOVER utilities.

• For the second time, execute the QUIESCE utility on all the tables that arecandidates to be reset if a point-in-time recovery is required.

This invocation of QUIESCE will establish a log RBA that will be the point ofconsistency.

• When it is necessary to recover to this point of consistency, RECOVER to theRBA established by the second invocation of the QUIESCE utility.

With the combination of the COPY and the second QUIESCE, the RECOVERTORBA will perform as efficiently as a Recover TOCOPY would perform,assuming no logging during the execution of this scenario.

• When it is necessary to recover to this point of consistency, RECOVER allindexes on all the tables that have been reset to the prior point of consistency.The indexes must be synchronized with the data in the recovered tablespaces.DB2 V6.1. added the functional capability to recover the index from an imagecopy. The recovery of the index from an image copy in V6 is a significantperformance benefit over prior versions of DB2 that rebuild the index (thisincludes reading the table to unload and construct all keys, sorting the keys,and then rebuilding the index).

The benefits of this scenario are:

• There is minimal disruption to the user in preparing for the scenario.

The user may see some slowness in response during the execution of theQUIESCE utility, but this can likely be scheduled during off-hours to minimizethe disruption.

• There is no disruption to the user when COPY is run with Share-LevelChange.

COPY - Share-Level Change allows updates concurrent with utility execution.

• The recovery of the tablespaces will be efficient.


RECOVER TORBA will perform as well as RECOVER TOCOPY, assuming nologging between the execution of the COPY utility and the second execution ofQUIESCE.

However, there is a significant disadvantage to this scenario: The requirement torecover many objects may take too long, thus making this scenario impractical. Ifyou are evaluating the use of this scenario, time it to determine if it meets youravailability requirements.

7.4.3.3 PIT recovery using dump/restore utilitiesThis scenario uses a DB2 command and usually a non-DB2 dump/restore utilityprogram.

• Determine the set of tables that are logically related.

Typically this is a subset of the tables that make up the application database.However, in the Siebel environment, it may be all of the tables.

• Use the DB2 STOP DATABASE command to stop all of the tablespaces thatare logically related.

The STOP DATABASE command will cause the DB2 buffers to be externalizedto DASD, and will cause the VSAM data sets that hold the DB2 data to beclosed. While the tablespaces are stopped, the data will be unavailable tousers. You may evaluate bringing down DB2 as an alternative to the STOPDATABASE command.

• Dump the tablespace and index data sets using your installation’s high-speeddump utility.

You may consider using FlashCopy or SnapShot to dump the data sets. Thedumped data sets represent your point of consistency.

• When it is necessary to recover to this point of consistency, do the following:

– Stop DB2.

– Restore the data sets that were dumped in the previous step.

– Restart DB2.

Because the tablespaces were stopped when backed up, there were nooutstanding units of recovery, and the data was consistent. The restored dataconsists of both the tablespaces and the associated indexes.

The recovery portion of this scenario is faster than the previous one, butpreparing for it is more disruptive to the user. The data is unavailable to the userwhile the tablespaces are stopped and while the data is being dumped. Thelength of time that data is unavailable can be lessened by using FlashCopy orSnapShot.

7.4.3.4 PIT recovery using DB2 conditional restartThis scenario will likely appeal to the more experienced DB2 user. The scenariorequires a DB2 conditional restart, which is a part of DB2 not frequently exercisedby users. Its key advantage is an “almost free” establishment of a point ofconsistency.

The first three steps of the scenario are new and will receive the major part of ourattention here. Once those steps are complete, the remainder of this scenario isconceptually similar to the later steps of the scenario 7.4.3.2, “PIT recovery using


DB2 utilities” on page 89, with the difference that you will recover to currency andnot to an RBA.

• Identify a set of candidate points of consistency.

Consider a list that contains many items (or rows). Each list item has twoentries in columns: The first column is a timestamp, and the second column isthe DB2 Log RBA associated with that time. The list can be quite long (that is,showing many timestamps). This list of timestamps is our set of candidatepoints of consistency.

The list of candidate points of consistency might have an entry for each hourin the day or for each minute in the day. For each entry in the list, you have atimestamp and the corresponding DB2 Log RBA. This allows you to map aspecific time to a DB2 Log RBA.

How do you build a list of timestamps and the associated Log RBAs? You startby defining a dummy database and tablespace. This will be a real DB2database and tablespace, but there will be no activity against the dummytablespace. Siebel will not know about this tablespace.

Once the dummy tablespace is defined, initiate a user-developed procedurethat will periodically QUIESCE that dummy tablespace. Since you will allow noactivity against the dummy tablespace, the QUIESCE will be very fast. TheQUIESCE will cause the Log RBA and the timestamp to be entered intoSYSIBM.SYSCOPY. The entries within SYSIBM.SYSCOPY for the dummytablespace make up your list of candidate points of consistency. If you do theQUIESCE each hour, there will be an entry for the dummy tablespace inSYSIBM.SYSCOPY each hour.

Note that the defined dummy table is only used as an aid in determining anRBA in the log that corresponds to a given time. It is possible to calculate theRBA without the dummy table but the calculation is complex; use of the tableis simpler and less prone to error.

• Select the candidate point of consistency that best meets your requirements.

Suppose you determine that because of an application programming error,data in your Siebel system is inconsistent. This part cannot be automated. Youmust determine when the inconsistencies began to enter your system.Suppose you determine that at 5:00 PM on January 14, 2000, erroneous databegan to enter your system. You make the determination that you want to takeyour system back before that point in time.

You have one more task: Query SYSIBM.SYSCOPY for the dummytablespace entry before 5:00 PM on January 14, 2000. Once you determinethat entry from the list, note the DB2 Log RBA.

Where do you stand now? You have the Log RBA of the nearest time beforethe inconsistencies entered your system. You are now ready to make that LogRBA, which relates to a candidate point of consistency, into a true point ofconsistency.

• Make the best candidate point of consistency into a true point of consistency.

This is the point at which you do the conditional restart. The conditional restartmakes your candidate point of consistency the true point of consistency on theDB2 Log.

There is probably data inconsistency at the Log RBA you identified. You arerunning an active Siebel system and it is likely that at the time you have


identified, there was work in process (including in-flight units of recovery).However, you can make that Log RBA a true point of consistency.

By doing a DB2 conditional restart, you can make the Log RBA you identifiedinto a point of consistency. You will use the CHANGE LOG INVENTORY DB2utility to create a conditional restart control record using the followingstatement:

CRESTART CREATE,FORWARD=YES,BACKOUT=YES,ENDRBA=XXXX

where XXXX is the true point of consistency you determined from yourSYSIBM.SYSCOPY query.

The conditional restart causes DB2 to truncate the log at your true point ofconsistency. Log entries beyond that point are disregarded. Additionally, DB2removes from SYSLGRNGX and SYSCOPY any entries that occurred afterthe true point of consistency.

• Recover all tablespaces to the true point of consistency.

The conditional restart positions you to recover all your tablespaces. Becauseof the conditional restart, use RECOVER to currency, not RECOVER TORBA(recovery to an RBA is common in most point-in-time recovery scenarios).

• Recover all indexes on the tables that have been reset to the prior point ofconsistency.

The indexes must be synchronized with the data in the recovered tablespaces.

7.4.3.5 PIT recovery using suspension of DB2 updatingThis scenario is functionally similar to the scenario in section 7.4.3.3, “PITrecovery using dump/restore utilities” on page 90. The salient features of bothscenarios are:

• Determine the set of objects requiring backup and recovery.• Stop processing.• Dump the set of objects.• Restore the set of objects and restart DB2.

The unique characteristic of the “Point-in-time recovery using suspension of DB2updating” scenario is a new technique to stop DB2 update processing.

The specific characteristics of this “Point-in-time recovery using suspension ofDB2 updating” scenario are:

• Determine the set of objects requiring backup and recovery.

The issues for this step are the same for all point-in-time recovery scenariosusing Siebel. You will likely back up your entire Siebel system.

• Stop processing.

The unique feature of this scenario is the method for stopping the processing.APAR/PTF - PQ31492/UQ36695 provides the ability to “suspend” and“resume” DB2 logging. This has the effect of “freezing” updates to your DB2data while you make copies of the DB2 data and the DB2 log. Specifically,after logging is “suspended”, the DB2 log and the data are consistent. Whenthe SET LOG SUSPEND command is issued, the following occurs:

– A system checkpoint is taken.


The scope of the command is single system-only. In a data sharingenvironment, the command will have to be entered for each member.

– Unwritten log buffers are externalized to DASD.

– The BSDS is updated with the high-written log RBA.

– A log-write latch is obtained to prevent further logging.

Logging is suspended until the resume command is entered.

• Dump the set of objects.

To take maximum advantage of this scenario, you want a high-speed dumpcapability like FlashCopy or SnapShot. With this scenario, you add the DB2log and boot strap data set (BSDS) to your list of objects to be dumped. Thefunction of the APAR discussed above makes the log consistent with the DB2data.

• Restore the set of objects and restart DB2.

With this scenario, you restore both the DB2 data, the BSDS, and the log.Since the log is consistent with the data, the point-in-time recovery scenariorequires only a normal DB2 restart. In-flight units of recovery are backed outjust as with any normal DB2 restart. After the normal DB2 restart, the data willrepresent committed units of recovery at the time that logging was initiallysuspended.

7.4.3.6 PIT recovery considerationsYour strategy should be to avoid a point-in-time recovery if possible, but also toprovide a process that allows it to be performed when necessary. If apoint-in-time recovery must be done, then choose the most effective recoveryscenario consistent with your requirements. Following are the considerations forthe five options previously discussed.

1. PIT recovery using user-written application programs

This is a preferred approach among users when possible. It has the followingbenefits:

– There is little or no disruption to the user.

Data that has not been corrupted will be available to the user. (However,the user may see erroneous data prior to the recovery.)

– There is no loss of data entered between the time the data contaminationwas introduced into the system and the time the contaminated data wascorrected.

– Fewer processor resources are likely to be required than using either of theother techniques.

Remember that this is an ideal and not a rigorous scenario that can bedocumented and tested. You must be prepared to reset your system by doingthe point-in-time recovery when a “programming fix” is not possible orpractical.

Application programming may not be able to repair Siebel system data; ifSiebel defects exist, other point-in-time recovery techniques may be the onlyalternative.


2. PIT recovery using DB2 utilities

This scenario is preferred over the “point-in-time recovery usingDump/Restore utilities” scenario when few tablespaces and indexes are to berecovered. However, the recovery of the number of tablespaces and indexesin a Siebel system may imply an outage of many hours, making this scenariopotentially impractical. If you believe that this scenario may be workable inyour environment, run a benchmark to make sure that your availabilityrequirements can be met.

3. PIT recovery using Dump/Restore utilities

The issue regarding this scenario is the number of tablespaces and indexesthat must be recovered to an established point of consistency. As the numberof tables and indexes to be recovered grows, dump-restore may become thepractical alternative. Dumping packs and restoring data (using features likeFlashCopy or SnapShot) is faster than a recovery-based scenario if theregularly scheduled dumping activities and database nonavailability can betolerated. Note that recovery is required only when errors occur, while backupoccurs on a scheduled basis even if no errors ever occur.

The major disadvantage to this scenario is that the dumping of the data isdisruptive to the user and occurs on a regular basis (usually daily). The Siebelsystem likely must be stopped in order to dump data that is consistent. Otherapplications must also be stopped if they are affected by Siebel beingunavailable.

An additional disadvantage (affecting all scenarios to some degree, butparticularly noticeable in this one) is that work is lost when data is reset to aprior point of consistency. Considering, for example, a once-per-week backupschedule, then, on average, production data for half of a week is lost when apoint-in-time recovery is executed.

4. PIT recovery using a DB2 conditional restart

The main benefit to this scenario is that there is effectively no impact on theuser to create the list of candidate points of consistency.

The time required to actually recover the tablespaces and indexes will likelybe somewhat longer than the time required to do the recovery described insection 7.4.3.2, “PIT recovery using DB2 utilities” on page 89, because thisscenario will likely require more DB2 log processing during the recovery.

Since this scenario contains a conditional restart, anyone using it must firstpractice it. An improperly done conditional restart has the potential of severelydamaging your DB2 subsystem.

In summary, users should consider this scenario when:

– Having no disruption in defining the candidate points of consistency is ofthe greatest significance.

– The long outage to actually perform recovery is acceptable.

– You are willing to practice conditional restart to develop and maintain theskills necessary for its success.

5. PIT recovery using suspension of DB2 updating

This scenario has the advantages of the “Point-in-time recovery usingDump/Restore utilities” scenario with the added benefit that suspendedlogging is less disruptive to the user than stopping/restarting the DB2


subsystem. Data consistency is assured with this scenario through copyingthe log in addition to the data, and then by executing a normal DB2 restart.

The SET LOG SUSPEND/RESUME feature is recommended as the basis foroff-site disaster recovery support.


Chapter 8. DB2 features used by Siebel applications

This chapter describes the benefits that DB2 provides for Siebel applications. Itcovers DB2 V6 functions, including V6 late additions (APARs), and DB2 V7functions that address more specifically Siebel data access and maintenanceperformance requirements.

IBM and Siebel have a long history of cooperation in supporting enterprises thatuse Siebel and DB2 for OS/390 today. This solid partnership made possible theteamwork development, integration, performance analysis, and customer serviceneeded to achieve excellent Siebel results on the S/390 platform.

The S/390 platform offers unmatched capacity and scalability, availability,performance, and manageability to reliably handle your information needs in aCRM solution such as Siebel with DB2.

8.1 SQL and system performance enhancements in DB2 V6

In this section we describe the DB2 V6 functions that are beneficial to Siebel onOS/390. Siebel requires DB2 V6 and DB2 Connect V6 with FixPack 3SA.

DB2 V6 functions that address Siebel requirements are:

• Dynamic statement caching• ORDER BY clause• Stored procedures to start utilities• Index screening in RID list processing• Unmatched column join for VARCHAR• Outer join• Uncorrelated subquery -- indexable IN predicates• Small tables to use indexes• DSMAX increased from 10000 to 32767• 225 tables per query• New built-in functions• Triggers• Buffers and EDM pools in Data Spaces

DB2 V6 new additions via APARs/PTFs are the following:

• Update with subselect -- APAR PQ30383, PQ31272• Identity columns -- APAR PQ30652, PQ30684• Declared temporary tables -- APAR PQ32670• Defer defining data sets -- APAR PQ30999

You can also find a very detailed explanation of those functions in the redbookDB2 UDB for OS/390 Version 6 Performance Topics.

8.1.1 Dynamic statement cachingCRM applications primarily use dynamic SQL statements. Processing of adynamic SQL statement requires two steps: prepare, then execute. Prepare isexpensive because it consists of parsing and syntax checking, catalog searchesfor tables and columns, authorization checking, access path optimization, andcreation of the statement executable.


For cases in which the same dynamic SQL statement is issued repeatedly, theability to cache the previously prepared statement can significantly reduce thecost of running those statements because they will not have to be prepared overand over again.

Dynamic statement caching is activated at two levels:

• The first level is global and permits the caching in the EDM pool of all the SQLdynamic statements submitted to DB2. This level is enabled by setting theCACHE DYNAMIC SQL field to “yes” in the installation panel DSNTIP4. Thecorresponding ZPARM parameter is CACHEDYN. No SQL changes areneeded to benefit from this function.

• The second level applies to a package/plan and is set during the bindoperation by using the KEEPDYNAMIC(YES) option. The storage used by thekept statements is indirectly controlled by setting the MAX KEPT DYN STMTSfield of installation panel DSNTIPE. This function implies programmingmodifications. Siebel does not use the KEEPDYNAMIC(YES) option sinceeach statement is explicitly prepared after commits.

Siebel uses parameter markers that are well suited for statement caching.

8.1.2 ORDER BY clauseDB2 required that all columns referenced in an ORDER BY clause must also benamed in the SELECT list of a query.

DB2 now allows you to specify columns in the ORDER BY clause that are not inthe SELECT list, such as the following statement:

SELECT name FROM q.staff.systables ORDER BY dept, years

You cannot use this enhancement of ORDER BY in conjunction with:

• UNION or UNION ALL• GROUP BY• DISTINCT• Column functions such as MAX, MIN and SUM

This enhancement is important for applications, such as Siebel, that generateSQL statements.

8.1.3 Stored procedures to start utilitiesApplications performing systems management for DB2 on OS/390 require amethod of invoking DB2 utilities without generating JCL and managing batch joboutput.

DB2 provides a stored procedure named DSNUTILS which acts as a wrapperaround DSNUTILB, the main utility program. The DSNUTILS stored procedureenables execution of DB2 utilities from a DB2 application program via the SQLCALL statement. DSNUTILS must run in a WLM environment.

When called, DSNUTILS does the following:

• Dynamically allocates the specified data sets.

• Creates the utility input (SYSIN) stream.

• Invokes DB2 utilities (Program DSNUTILB).


• Deletes all the rows currently in the global temporary table(SYSIBM.SYSPRINT).

• Captures the utility output stream (SYSPRINT) into a global temporary table(SYSIBM.SYSPRINT).

• Declares a cursor to select from SYSPRINT:

DECLARE SYSPRINT CURSOR WITH RETURN FORSELECT * FROM SYSPRINTORDER BY SEQNO;

• Opens the SYSPRINT cursor and returns.

The calling program then fetches from the returned result set (SYSPRINT) toobtain the captured utility output. Figure 39 illustrates this process.

Figure 39. DSNUTILS stored procedure overview

Siebel uses the DSNUTILS stored procedure as an option to invoke RUNSTATSfor Siebel’s EIM staging tables. This allows Siebel to perform RUNSTATSdynamically on Siebel’s temporary tables to get optimal statistics numbers in theDB2 catalog for high application performance. WLM Goal Mode is recommendedto manage the stored procedure address spaces.

8.1.4 Index screening in RID list processingIndex screening predicates reference columns in the index, but are not part of thematching index columns. For example:

SELECT * FROM T WHERE C1 = 1 AND C3 > 4 AND C4 =6;

With an index on T(C1,C2,C3), C3 > 4 is an index screening predicate. It can beapplied when accessing the index, but it is not a matching index predicate like C1= 1. The value of MATCHCOLS in the PLAN_TABLE is 1. C4 = 6 is not an indexscreening predicate. Any column in the index that is not one of the matchingcolumns for the query will be considered for index screening.

Prior to this enhancement, index screening was not used when RID listprocessing was involved. RID list processing is used by:

Ta b leTa b le

E X E C S Q LC A L L D S N U T I L S

E X E C S Q LF E T C H S Y S P R I N T

S c h e d u le s D S N U T IL S

S Y S I B M .S Y S P R IN T

G lo b a l Te m p o r a ry Ta b le

C l ie n ta p p l ic a t io n

D B 2a d d re s s s p a c e

W L Ma d d r e s s s p a c e

S Y S IB M .S Y S R O U T IN E S Ta b leA llo c a te d a ta s e ts d y n a m ic a l lyC re a te s S Y S IN s t re a m

I n v o k e s D B 2 u t il i ty

C a p t u r e s S Y S P R IN Tin to S Y S IB M .S Y S P R IN T

O p e n s th e S Y S P R IN T c u r s o ra n d re tu r n s

S to r e dP ro c e d u r eD S N U T IL S

S Y S IN

S Y S P R IN TS Y S P R IN T

Chapter 8. DB2 features used by Siebel applications 99

• List prefetch for single table access and hybrid join• Index ANDing and ORing during multiple index access

DB2 now allows index screening during RID list processing to filter out additionalrows at index access time. These rows no longer need to be passed on by thedata manager for data page access and evaluation of the predicate. The numberof RIDs that require sorting also decreases by this enhancement because someof the rows have already been “screened out” at index access time. The optimizerfilter factor calculations take this enhancement into consideration during listprefetch, index ANDing and ORing. It is therefore possible to see the optimizerfavoring those access paths more often to achieve better response time.

Siebel benefits naturally from this enhancement every time an applicationperforms a list prefetch, or an index ANDing or ORing.

8.1.5 Unmatched column join for VARCHARSuppose you want to join two tables, but the data types or the length of the joincolumns do not match. DB2 can perform a join in that case, but there is aperformance impact. Because of the mismatch on data type or column length, thejoin predicate is considered stage 2. This means all qualifying rows of the innertable are passed back to the relational data system (RDS) component of DB2 forevaluation of the join predicate. If the join columns have the same data type andcolumn length, the Data Manager (DM) component can deal with the joinpredicate at stage 1.

Example:

SELECT * FROM T1,T2WHERE T1.CHAR10 = T2.CHAR5

Suppose there is an index on T1 (CHAR10). The T1.CHAR10 = T2.CHAR5predicate is considered stage 2 (and the index on T1 cannot be used either)because the column length is not the same. The same is true when the joinpredicate is T1.VARCHAR5 = T2.CHAR5.

This problem is now partially fixed with this enhancement. In order for a predicatewith unequal attributes to qualify as a stage 1 (and also indexable) predicate, ithas to meet the following criteria:

• The predicate is dealing with a string data type (CHAR, VARCHAR,GRAPHIC, or VARGRAPHIC).

• The join predicate is an equal predicate.• The predicate is a Boolean term.

These enhancements have been incorporated in DB2 for nested loop and mergescan joins. Hybrid join does not support this feature.

The problem has only been solved for join predicates on string data types. It hasnot been addressed for numeric data types, such as T1.INTEGERCOL =T2.SMALLINTCOL.

Another problem that is not being addressed by this enhancement is themismatch of attributes on local predicates. For example, the local predicateCHARCOL5 = ’ABCDEF’ is still stage 2 if the column length is smaller than thelength of the literal.


This feature is beneficial to Siebel users who want to build their own queries.

8.1.6 Outer joinWith the introduction of outer join support in DB2 V4, it has become much easierto write SQL outer join statements. This has increased programming productivity.However, the usability of outer join was sometimes limited by some of theperformance downsides of using outer join, since more data needs to beexamined and more processing takes place.

DB2 V6 introduces a large number of outer join performance enhancements,thereby making outer join SQL statement performance very close to that of asimilar inner join statement. In addition, the SQL syntax of the ON clause hasbeen extended to allow you to write SQL that you could not write before.

The outer join enhancements brought in DB2 V6 are extensively described in theredbook DB2 UDB for OS/390 Version 6 Performance Topics. The main itemsare:

• SQL ON clause extensions• Outer join predicates classification• Join simplification• Removal of unnecessary work files• Aggressive predicate evaluation• Predicate transitive closure for outer join• Join order permutation

Siebel benefits immensely from the outer joins for lookup tables. One query canuse up to 30 lookup tables in outer joins with the Siebel base tables.

8.1.7 Uncorrelated subquery -- indexable IN predicatesBefore this enhancement, DB2 did not use a matching index when evaluating theIN predicate against the result set of a noncorrelated subquery. Thenoncorrelated IN subquery predicate is considered a stage 2 predicate. Take thefollowing example:

UPDATE T1SET SDATE = ’01/01/1999’ , STIME = ’20:38:35’

WHEREPROG IN (SELECT MASTER FROM T2 WHERE INCLUDE = ’TODAY’);

where:

• A unique clustering index exists on T1(PROG).• An index exists on T2(INCLUDE, MASTER).

DB2 resolves the noncorrelated subselect using matching index-only access,sorts and removes the duplicates, and puts the results in a workfile. The PROGIN (subselect) is then evaluated. DB2 can use a nonmatching index scan onT1(PROG) or a tablespace scan to access T1 and look for a qualifying row in theworkfile. DB2 cannot use a matching index to look up the values in the subselectbecause the predicate is stage 2.

The DB2 code has been enhanced to evaluate whether it is beneficial to processthe noncorrelated IN subquery in more or less the same way DB2 handles IN listindex access today. However, for noncorrelated IN subqueries, DB2 fetches from


a duplicate free sorted workfile and not a list of values coded by the user. Thesubquery is executed at cursor OPEN time. The matching with the outer queryblock is not done until FETCH time.

Going back to the example at the beginning of this section, the subquery on T2 isstill executed first, the results are sorted in PROG order, and the duplicates areremoved and stored in a workfile at OPEN cursor time. When the program startsFETCHing, instead of accessing the outer table T1 and matching the rows withthe results of the subquery, DB2 now uses the values from the workfile to accessthe index on T1(PROG) using a matching index scan to evaluate the IN predicate.The resulting set of the noncorrelated subselect is evaluated as the outer table ina “nested loop” way, while T1 is now considered to be the inner table.

The noncorrelated IN subquery predicate has become indexable and stage 1.The DB2 optimizer evaluates whether this transformation helps performancebased on the existence of an index on the column specified on the left-hand sideof the IN predicate and the selectivity on the IN subquery predicates. Thisenhancement can be used in SELECT, UPDATE, and DELETE statements.

Figure 40 refers to a query used in a performance measurement study to evaluatethis enhancement. The results show dramatic improvement both in elapsed andCPU time.

Figure 40. Uncorrelated IN subquery improvement

80% of Siebel queries are using extensively uncorrelated subqueries withindexable IN predicates.

8.1.8 Small tables to use indexesA tablespace scan is sometimes selected when statistics are collected on anempty table (i.e., NPAGES=0) or when a table is very small (i.e., NPAGES<10).This is not a good choice if the table actually contains larger amounts of data

V5 w/o enh. V6, V5 with enh.0

10

20

30

40

50

60

70

80

90

100

Elapsed (sec)CPU (sec)

91.2 86.9

0.14 0.0 30.03

W ith enhancem ent:Elap sed tim e im p ro ved 1000 XC P U tim e im pro ved 1000 X

SIN G L E LAB O R ATO R Y Q U ER Y :SE LE C T C 1 F R O M T 1

W H ER E C 1 IN(SE LE C T C 2 FR O M T 2W H ER E C 2='4290005 ')

T 1 = 1.65 M rows, C 1 indexT 2 = 931 K rows, C 2 index

s econ ds


when the queries are executed. In that case, it would be better if the optimizerselected index access rather than a tablespace scan.

A new installation parameter, NPGTHRSH, is introduced that will cause the DB2Optimizer to favor index access for tables whose statistics indicate less than agiven number of pages.

For example, if NPGTHRSH=10, then all tables with NPAGES<10 will tend tofavor index access over tablespace scan. If statistics have not been collected(NPAGES=-1), then NPGTHRSH=502 will cause all tables with NPAGES<502,and all tables with NPAGES=-1 to tend to favor index access over tablespacescan. If NPGTHRSH is set to -1, then all tables will tend to favor index access.

The default for NPGTHRSH is 0, which means the optimizer will select the accesspath based on cost as it normally does.

Incorrect use of this installation parameter may result in some access paths usingindex access when a tablespace scan would actually be more efficient. Queryperformance problems may occur in this case.

8.1.9 DSMAX increased from 10000 to 32767Support has been added to permit allocation of data sets in excess of the 10,000data set limit. This change is made in conjunction with changes introduced inOS/390 Version 2 Release 6 and later releases. Together, they enable DB2 todynamically allocate a much larger number of concurrent data sets.

Systems running on versions of OS/390 that are prior to V2.6 continue to berestricted to the 10,000 data set limit.

The OS/390 Version 2 Release 6 allocation has been changed to remove thearchitectural limit of 10,000 concurrent, dynamically allocated DB2 data sets. Thischange addresses a scalability concern of large DB2 systems. This DB2 check,DSMAX, changes from the prior OS/390 limit of 10,000 data sets to the maximumof 32,767 data sets. Note the following considerations:

Consideration for allocating a high number of data setsWith OS/390 Scheduler Work Area (SWA) below the line, 10,000 open data setsis not generally possible. Therefore, you should consider moving your SWAabove the 16 MB line.

Having a large number of allocated data sets has virtual storage and performanceimplications.

DB2 stop time can take longer because there are lots of data sets to close. If youare not able to specify STC NODETAIL for SMF, there is also a performanceconcern at DB2 shutdown. Abending DB2 instead of waiting for DB2 stopcompletion is not a recommended practice.

Checking the storage allocationCalculation and checking for storage below the 16 MB line is more likely to causea DSNT436I warning or DSNT437I error message from the DSNTINSTinstallation CLIST saying storage below the line exceeds 5 MB and 8 MB withlarger values of DSMAX. The parameter and maximum are shown on installationspanel DSNTIPC.


This enhancement benefits Siebel because Siebel has many data sets; somecustomers have a one-table-to-one-tablespace mapping strategy. As a result,multiple DB2 databases in the DB2 subsystem (for example, development,regression testing, systems testing) can easily exceed the limit of 10,000.

8.1.10 225 tables per queryIn prior releases of DB2, the maximum number of base tables in a query was 15.In Version 6, queries that qualify for Star Join processing may contain up to 225tables in the FROM clause. Other queries are limited to 15 tables in the FROMclause, but it is possible to override this limit. To do so, edit the file DSN6SPRC,which is a member in data set prefix.SDSNMACS, and locate the following line:

&SPRMMXT SETC '15'

Change '15' to a larger value, then reassemble and link the DSNZPxxx file bysubmitting the DSNTIJUZ job.

Note that storage usage should be monitored if the 15-table limit is overriddenwhen a large query consumes an excessive amount of storage during bindprocessing, since this could impact the DB2 subsystem. Refer to APAR PQ31326for more information.

The Siebel recommendation is to update the table value to 40 to accommodatesome of their SQL.

8.1.11 New built-in functionsPerhaps you need some additional SQL functions to be able to ask your question.Like other DB2 users, you want functions to obtain the absolute value, modulus,square root, calendar, and standard deviation, or you want them to manipulatetext. DB2 provides over 60 new built-in functions, making your queries moreflexible and powerful. For example, the new square root function returns theactual value, so that you don't need to get the data and then perform the functionon it. Among the new built-in functions are some that handle advancedtrigonometry functions, such as sine and cosine, and other advanced mathfunctions, such as degree, exponential, and power functions. IBM has improvedthe power of the SQL language so you can answer questions easily.

New built-in functions that will specifically benefit Siebel are:

• LTRIM• RTRIM• UPPER

8.1.12 TriggersWith the addition of triggers, DB2 helps you bring application logic into thedatabase. A trigger defines a set of actions that are to execute when a specificSQL data change operation occurs on a specified base table. The SQL datachange operation includes actions that are initiated by SQL INSERT, UPDATE,and DELETE statements, as well as by actions of referential integrity constraints.

Using triggers, you can:

• Enforce transitional business rules that involve different states of the data. Forexample, use a trigger to enforce a rule that prevents a salary column from


increasing by more than ten percent. The trigger invokes a comparison of thesalary values before and after the increase.

• Automatically update summary data in one table when changes occur inanother table.

• Initiate “alerts” outside the database, such as sending an e-mail notification orscheduling a job on another system.

• Automatically generate values for newly inserted rows.

Siebel uses triggers to set processing flags in tables to mark the rows that will beprocessed by background daemons, which wake up occasionally to perform anoperation based on these flags that have been set.

Users can generate triggers indirectly by defining processing rules which Siebelthen implements through triggers.

8.1.13 Buffers and EDM pools in data spacesOne of the strengths of DB2 is the capacity to exploit large processor resourcesto run large application workloads. Prior to DB2 V6, you allocated a buffer pool ineither the DBM1 address space (virtual pool) or in a hiperspace (hiperpool).

The use of hiperpools helps to relieve the 2 GB addressability limitation of MVSaddress spaces. DB2 hiperpools reside in expanded storage only and may notcontain changed pages. The total size of all hiperpools cannot exceed 8 GB.

DB2 V6 provides an option to define buffer and EDM pools in a data space. Likehiperspaces, data spaces are data only address spaces. That is, no programcode can run in those areas.

Note that data spaces provide a foundation for DB2 to exploit real storage largerthan the 2 GB limit when the 64-bit machine becomes available. Until the newprocessor is available, we recommend that customers consider hiperpools first,before turning to data spaces, when running out of virtual storage in the DBM1address space.

8.1.13.1 Buffer pool in a data spaceUnlike hiperspace, I/O can be directly done against buffers in a data space (pagemovement occurs between the central storage and expanded storage). DB2 canalso put changed pages in a virtual pool that resides in a data space, while apage in a hiperpool must be unchanged or written to DASD before it is allowed tobe moved into the hiperpool.

Each data space can accommodate almost 2 GB of buffers, and any single bufferpool can span multiple data spaces. However, no more than one buffer pool canbe in a single data space. The sum of all data space buffers cannot exceed 8million pages. This limit is independent of the buffer size.

A hiperspace is addressable in 4 KB blocks; in other words, it is pageaddressable. A data space is byte addressable. You cannot put a primary bufferpool into both a hiperpool and a data space.

You define a buffer pool in a data space using a new VPTYPE keyword on theALTER BUFFERPOOL command. The possible VPTYPE parameter values arePRIMARY or DATASPACE, each representing the following:


• VPTYPE(PRIMARY): Allocates a virtual buffer pool in the DBM1 addressspace. The sum of all DB2 virtual buffer pools cannot exceed 1.6 GB.

• VPTYPE(DATASPACE): Allocates a buffer pool in a data space. However, youneed 128 bytes of buffer control storage in the DBM1 address space for eachdata space buffer.

The benefits of using buffer pools in data spaces are as follows:

• They improve the buffer pool hit ratio. Since you can store more pages in adata space than in a virtual pool that resides in a DBM1 address space, pagescan stay longer in memory.

• They allow for more parallel processing to execute prefetch I/O streams forlarge queries.

The main reason for choosing a data space to store your virtual buffer pools is toprovide relief for virtual storage constraints in the DBM1 address space and toprovide greater opportunities for caching very large table spaces or indexes. Ifyou are currently using hiperpools for read-intensive workloads and have notreached any DB2 virtual storage limit, there is no immediate benefit to moving todata spaces until processors are available that address more than 2 GB of realmemory.

8.1.13.2 EDM pool in a data spaceYou can choose to have the part of your EDM pool that contains cached dynamicstatements in a data space. By moving these “skeletons” of prepared dynamicSQL statements to a data space, you reduce the storage you require in the DBM1address space.

If you specify YES for CACHE DYNAMIC SQL, DB2 will calculate a default valuefor the EDMPOOL DATA SPACE SIZE, automatically enabling the usage of adata space for cached dynamic statements.

Whether you are using buffer and/or EDM pools in a data space, take thefollowing into consideration:

• Moving a data page back and forth between the data space and the look-asidepool may result in extra CPU usage.

• When using data spaces, make sure they are completely backed by processorstorage. You do not want to see any paging activity when having to get to thebuffers in the data space.

Because Siebel is primarily using dynamic SQL and this enhancement does allowfor larger EDM pools, it will positively impact customers using dynamic statementcaching.

8.1.14 Update with subselectThis is a new function to allow a subselect in the SET clause of the UPDATEstatement.

The UPDATE statement will accept that a subselect can be specified on the rightside of the SET clause in both a searched and positioned update. We can havetwo types of subselects:

• The scalar subselect returns a single row with a single column.


• The row subselect returns a single row with one or more columns. The numberof columns in the row must match the number of columns that are specified tobe updated.

When using a scalar or row subselect in the SET clause of an UPDATEstatement, the object of the update and the subselect must not be the same.Nevertheless, the columns of the object can be used in the search condition ofthe subselect. Using correlation names to refer to these columns is allowed onlyin a searched UPDATE.

Example:

EXEC UPDATE EMPLOYEESET DEPTSIZE = (SELECT COUNT (*)

FROM DEPT1WHERE DEPTNO = ’P222’)

WHERE WORKDEPT = ’P222’;

Siebel’s Enterprise Integration Manager (EIM), a batch job that loads data in thebase tables, makes extensive use of this new SQL construct.

8.1.15 Identity columnsThis function allows DB2 to automatically generate unique, sequential, andrecoverable values for each row in a table. A column that is defined with the ASIDENTITY attribute is referred to as an identity column. Each table can have oneidentity column. They are ideally suited for generating unique primary key valuessuch as order numbers, employee numbers, stock numbers, or incident numbes.Applications can use identity columns to avoid the concurrency and performanceproblems that can result when an application generates its own unique counteroutside the database.

The values for an identity column can be generated by DB2 or by default. If anidentity column is defined as GENERATED ALWAYS, DB2 always generates thecolumn value and guarantees that each value is unique. Applications are notallowed to provide an explicit value. An identity column that is defined asGENERATED BY DEFAULT enables applications to provide an explicit value forthe column. If a value is not given, DB2 generates one. However, DB2 does notguarantee the uniqueness of the generated value among all the column valuesbut only among the set of values that it previously generated. GENERATED BYDEFAULT is intended to be used for data propagation where the intent is to copythe contents of an existing table, or unload and reload a table.

The counter for an identity column is incremented (or decremented)independently of the transaction. A transaction might see a gap between twonumbers that it generated because other transactions might have beenconcurrently incrementing the same identity counter by inserting rows into thesame table. Applications that must have a consecutive range of numbers shouldtake an exclusive lock on the table or table space that has the identity column.Furthermore, an identity column can appear to have gaps in the generatednumbers if a transaction that generated a value for the identity column rolledback, or a DB2 subsystem that cached a range of values crashed before all thecached values were assigned.

The sequential numbers that DB2 generates for the values of an identity columnhave these additional properties:


• The values must have a numeric data type of SMALLINT, INTEGER, orDECIMAL with a scale of zero (or a distinct type based on one of these types).

• The difference between consecutive values (the increment) can be anyspecified value. The default is 1.

• The counter value for the identity column is recoverable (if DB2 fails, thecounter value is reconstructed from the logs).

• Identity column values can be incremented across multiple DB2 members in adata sharing group while maintaining all of the above properties.

• Identity column values can be cached to give better performance in either adata-sharing or non-data-sharing environment, but caching in a data-sharingenvironment does not necessarily assign values in the order of insert.

8.1.16 Declared temporary tablesThis enhancement introduces a new DB2 function, DECLARE GLOBALTEMPORARY TABLE, which defines a new type of temporary table that hasneither persistent data nor persistent definition and can be dropped automaticallywhen a thread or application process terminates. Unlike DB2’s created tables andcreated global temporary tables, the declared global temporary tables have nodefinitions stored in the DB2 catalog. A declared temporary table can haveindexes and can be modified by DELETE and UPDATE statements. Its rows canbe rolled back (undone) to the last commit or savepoint. It does not require anassociated cursor that is declared WITH HOLD to keep its rows across a commitoperation.

The DECLARE GLOBAL TEMPORARY TABLE statement defines a temporarytable for the current application process and instantiates an empty instance of thetable for the process. A database that is defined AS TEMP (a temp database) anda table space within that database must be created before a declared temporarytable can be defined. DB2 will not implicitly create the table space, so it must becreated using the CREATE TABLESPACE statement. The CREATE DATABASEstatement is enhanced to support TEMP as an additional keyword on the ASclause to allow the database to be defined as one for declared temporary tablesonly.

DECLARE GLOBAL TEMPORARY TABLE is an executable statement that canbe embedded in an application program or issued interactively. It can also bedynamically prepared. No authorizations besides the implicit ones are required toissue the statement. The implicit privileges are not recorded in the DB2 catalogand cannot be revoked.

To refer to a declared temporary table in an SQL statement, you must qualify thetable name with SESSION. If SESSION is not the qualifier for the table, DB2assumes that you are not referring to a declared temporary table. Any static SQLstatement that references a declared temporary table is incrementally bound atruntime. This is because the definition of the declared temporary table does notexist until the DECLARE GLOBAL TEMPORARY TABLE statement is executedin the application process that contains the SQL statements, and the definitiondoes nor persist after the application process finishes running.

The update with subselect function DB2 introduced does not allow the same tableto be referenced in both the update clause and the subselect clause, so Siebelfirst selects the desired rows and saves them in a declared temp table, then uses


the declared temp table in the update with subselect statement to simulate anupdate with a self-referenced subselect statement.

8.1.17 Defer defining data setsThis new support allows DB2 users to use the DEFINE NO option in the CREATETABLESPACE and CREATE INDEX SQL statements to defer the creation ofunderlying VSAM data sets for the created DB2 table space or index space. Theundefined table spaces or index spaces will still have a DB2 catalog entry, but areconsidered as empty when accessed by a SELECT or FETCH operation. Anexisting SQLCODE +100 (sqlcode100) is returned to any application thatattempts to perform a read-only operation.

When the pageset is marked with an undefined state in the DB2 catalog (theSPACE column in SYSTABLEPART or SYSINDEXPART is set to -1), it is treatedas an empty data set until the very first write operation occurs, either throughSQL statements or certain DB2 utilities (such as LOAD). At the first write, DB2resets the undefined status in the catalog and creates the underlying VSAM datasets to allow the write operation.

The undefined status stored in the DB2 catalog will not be modifiable by any DB2ALTER command or any other third-party utilities. DBAs and application packageproviders should consider using the DEFINE NO option if the DDL performance iscritical. The DEFINE NO option provides better management relief on DD limitsand data usabilities by deferring the VSAM DEFINE/OPEN until the very firstwrite.

Deferring the definition of data sets is an enhancement that can be useful forcustomers who use only a subset of modules from the full suite of applicationsprovided by Siebel. Currently, customers receive all application tables, regardlessof which applications they are actually going to use. This install method allowscustomers to add Siebel modules easily after the initial install. On the other hand,it is possible for customers to have hundreds of empty tables and indexes forapplications they will not use. These objects are perfect candidates to be definedusing DEFINE NO.

In Siebel’s case, savings in data sets are especially maximized when we cansave indexes defined on empty table spaces. The recommendation for Siebel isto define all tablespaces with DEFINE YES and all indexes with DEFINE NO.Because segmented tablespaces are used, the total number of tablespaces issmall compared to the number of indexspaces.

8.1.18 SET LOG SUSPEND/RESUME commandUsers have requested a way of temporarily “freezing” updates to a DB2subsystem while the logs and database are copied (e.g. using Enterprise StorageServer FlashCopy or RVA SnapShot) for remote site recovery or priorpoint-in-time recovery usage. This would allow them to recover the DB2subsystem to a point in time without having to experience an extended recoveryoutage, or without having to stop or quiesce the primary system.

APAR PQ31492 adds new options to the -SET LOG command to be able toSUSPEND and RESUME logging for a DB2 subsystem. When a SUSPENDrequest is issued, a system checkpoint is taken (in a non-data sharingenvironment), any unwritten log buffers are written to DASD, the BSDS is


updated with the high written RBA, and the log-write latch is obtained to preventany further log records from being created. This prevents any further updates tothe database until update activity is resumed with a -SET LOG RESUME request.The scope of these commands is single subsystem only, therefore the commandshave to be entered for each member when running in a data-sharingenvironment.

Note: You should avoid using this function while long-running units of recoveryare active because DB2 restart time is lengthened by long-running updates.

Siebel uses the LOG SUSPEND/RESUME function for point-in-time recoverypurposes. See 7.4.3.5, “PIT recovery using suspension of DB2 updating” on page92.

8.1.19 Access path selection adjustmentDB2 V6 introduced the new NPGTHRSH parameter (APAR PQ33429), which willcause the DB2 Optimizer to favor index access for tables which statistics indicatecontain less than a given number of pages. For a given table, if NPAGES is lessthan the NPGTHRSH value, index access for the table will be preferred over atablespace scan.

After the initial install of Siebel, there are many empty or small tables which couldgrow rapidly in size. There are also a number of tables in Siebel which are veryvolatile, meaning that the number of rows can change very quickly and in largeamounts. If a RUNSTATS is run on these tables when they are small, the DB2optimizer would favor a tablespace scan, which would be inappropriate when thetable grows.

We recommend that you use NPGTHRSH = 10 as a startup and adjust later ifrequired.

8.2 SQL and system performance enhancements in DB2 V7

DB2 V7 introduces new functions that are of particular interest to Siebel, such as:

• Correlated subquery to join transformation• Self-referencing subselect with UPDATE/DELETE• Online system parameters• Scrollable cursors

8.2.1 Correlated subquery to join transformationApplication systems, such as Siebel, require certain stage 2 subquery predicatesto be transformed into join operations. The requirement is for UPDATE, DELETE,and SELECT queries with IN, =ANY, or EXISTS subquery predicates that arecurrently evaluated as stage 2 predicates. By transforming the query into a join ofthe outer query table and the subquery table, DB2 can significantly improveperformance in many cases because it can choose the most efficient join orderfor the tables. Users can rewrite SELECT statements of this type as joins in somecases, but they cannot do the same for UPDATE or DELETE.

Example:

UPDATE T1 A SET A.C1 = 1WHERE A.C2 IN (SELECT B.C2


FROM T2 BWHERE A.C3 = B.C3);

Siebel applications greatly benefit from this enhancement. The transaction router,EIM, and some client SQL use this function.

8.2.2 Self-referencing subselect with UPDATE/DELETEAllow DB2 UPDATE/DELETE FROM TABLE with a subselect from the sametable.

Example1: Give each employee whose salary is below the average a salaryincrease of 10%.

UPDATE EMP XSET SALARY * 1.10WHERE SALARY < (SELECT AVG(SALARY)

FROM EMP YWHERE X.WORKDEPT = Y.WORKDEPT);

Example 2: For each department, delete the employee with the most absences.

DELETE FROM EMP XWHERE ABSENT = (SELECT ABSENT = (SELECT MAX(ABSENT)

FROM EMP YWHERE X.WORKDEPT = Y.WORKDEPT);

This enhancement makes SQL in DB2 more powerful, reducing the need fortemporary tables and application programming. Siebel’s EIM import and deleteuse this function.

8.2.3 Online system parametersWith a growing number of customers utilizing DB2 in 24x7 year-round mode, theneed has been growing for online update of some of the major DB2 subsystemparameters. These parameters provide most of the basic configuration data usedby DB2. In previous DB2 versions, parameters could only be loaded once atstartup. DB2 V7 makes it possible to change the subsystem parametersdynamically when DB2 is currently up. The new -SET SYSPARM commandallows the reloading of the DSNZPxxx (subsystem parameters) load module.

With previous DB2 versions you had to stop Siebel application servers to recycle(stop and start) DB2, then restart Siebel application servers, in order to take thenew subsystem parameters into account. This is not needed with DB2 V7. Thus,this function provides more availability and flexibility to Siebel applications.

8.2.4 Scrollable cursorsScrollable cursors provide application programs with a mechanism to haverandom access to a result table with simple SQL and simple logic. ScrollableCursors are most useful to screen-based applications in which the user scrollsbackwards and forwards through the data. Previous DB2 versions providedforward-only cursors, which force screen-based applications to cache the resulttable locally and perform scrolling themselves. Alternatively, to access apreviously fetched row, applications had to close the cursor, reopen the cursorand fetch forward until the desired row was fetched. Because of the additionalstorage requirement, poor performance and unavoidably stale data, this solutionwas limited to small amounts of data.


The Scrollable Cursors provide a solution that enables applications to use apowerful new set of SQL to fetch data via cursor in random order, with optimalperformance, no extra cache requirements in the application, and simple logic,while also providing a means to indicate whether the fetched row must be current.

Siebel doesn’t use this enhancement yet, but they plan to use it.

8.3 Utility enhancements in DB2 V6

DB2 on OS/390 Version 6 offers significant enhancements to the utilities,benefiting the Siebel/DB2 user.

8.3.1 COPYAPAR PQ25084 adds a new CHECKPAGE option to the COPY utility. Byspecifyinfg the CHECKPAGE option on the COPY utility, DB2 invokes routineswhich perform checks on data and index pages to ensure that the backup beingtaken is without errors.

8.3.2 Parallel COPY and RECOVERTo reduce the elapsed time of both COPY and RECOVER, DB2 Version 6 allowsthese utilities to process in parallel. You may COPY a set of DB2 objects(tablespaces or indexes) in parallel. During RECOVER, the tablespaces andindexes may be restored in parallel. In previous releases of DB2, the creation(during COPY) and the restoration (during RECOVER) of image copies wereserialized. Full parallelism can be maintained provided that the copies are madeto DASD. Image copies to tape suspend the parallelism until the tape copy iscreated or restored. To fully exploit this feature, the Siebel-DB2 user has to takeimage copies to DASD.

8.3.3 LOAD and REORGIn DB2 Version 6, the LOAD and REORG utilities can build indexes in parallel.The DB2/Siebel user will exploit the parallel index build feature of REORG(Siebel does not explicitly invoke the DB2 LOAD utility).

8.3.4 REBUILD indexWith support for the recovery of indexes from image copies in DB2 Version 6, it isnot likely that you will use the REBUILD index utility. However, if you find itnecessary to use REBUILD to recreate indexes, the recreating or rebuilding ofthose indexes is done in parallel in DB2 Version 6.

This action forces the final iteration of log processing to occur.

8.3.5 Fast Log ApplyPrior to Version 6 of DB2, the log apply phase of RECOVER (for the RECOVERutility or recovery at restart time) was a serial process. The log record was read,the applicable tablespace page was read, and the recovery at the data page levelwas effected; the process was repeated for subsequent log records.

With Fast Log Apply in DB2 Version 6, the log records are read and sorted bytime of update within page within data set. Tablespace pages are read only once,using list prefetch. Parallel tasks are dispatched at the tablespace (or data set)


level. This significantly improves performance for the DB2/Siebel user duringboth recovery and normal DB2 restart.

Fast Log Apply is also invoked during the Start Database command for LogicalPage List (LPL) recovery and Group Buffer Pool Recovery (GRECP). This isparticularly beneficial to the DB2 data sharing user.

8.3.6 Consistent restartPrior to DB2 Version 6, it was possible for a long-running process that tookinfrequent (or no) commits to severely impact availability. If, during thelong-running task, DB2 were to abnormally terminate, the restart process couldbe lengthy. Furthermore, during the restart process, the DB2 subsystem wouldnot be available to users.

Consistent restart in DB2 Version 6 addresses this issue by introducing a newstate that can apply to the long-running unit of recovery. The new state is“postponed-abort”. The updates to the objects affected by the long-running unit ofrecovery are not backed out at restart time; instead they are put in apostponed-abort state. The DB2 subsystem is made available to the user. A newcommand (RECOVER POSTPONED) is used to complete the recovery of thepostpone-abort objects.

Since some Siebel processes have the potential to do significant updating withfew or no commits, consistent restart can significantly benefit availability for theSiebel-DB2 user.

8.3.7 Inline RUNSTATSDuring the DB2 LOAD, REORG, and REBUILD utilities, inline statistics may becaptured. This provides RUNSTATS statistics without a separate invocation ofRUNSTATS and without reading the tablespace data a second time. DB2/Siebelusers will find this feature particularly beneficial in the REORG utility.

8.3.8 REORG enhancementsThe REORG utility has several enhancements.

8.3.8.1 Online REORGOnline REORG significantly reduces the impact of a planned outage. The onlineReorg utility copies the table space or index space to one or more shadow datasets where the actual reorganization is done. The DB2 log is applied in aniterative fashion to the shadow copy of the data to synchronize it with the actualonline table space or index space.

After the log is applied, the shadow data replaces the unorganized data when theREORG utility changes data set names. The outage is now limited to read-onlyduring the final application of the DB2 log to the shadow copy of the tablespace,and no readers or writers are allowed during the changing of the shadow data setnames to the active data set names.

8.3.8.2 APAR PQ19077With the REORG utility in DB2 Version 6, you can select rows to be discardedduring REORG. The discarded rows may optionally be written to a discard file.


REORG UNLOAD EXTERNAL allows records to be converted to an externalformat for processing by a user-written application program. A LOAD utilitystatement is generated to allow discarded or unloaded rows to be loaded intoanother tablespace.

REORG has made improvements that can reduce potential deadlocks andthereby benefit both performance and availability. Additionally, there have beenimprovements in the DISPLAY UTILITY command and in auto termination ofonline REORG (APARs PQ20032 and PQ18941).

8.3.9 Reuse feature of LOAD, REORG, RECOVER, REBUILDWithout the reuse feature, the RECOVER and REBUILD utilities delete and thenredefine the VSAM data sets that contain tablespaces or indexes. With reuse, thehigh-used VSAM RBA is reset. Given that many tablespaces and indexes in aSiebel environment can be empty, this change can have a significant impact onelapsed recovery times, particularly when it is necessary to do a point-in-timerecovery, possibly recovering all DB2 objects in the Siebel system.

8.3.10 Backup and Recovery of indexes using image copiesThe COPY utility is enhanced to enable you to take a full image copy orconcurrent copy of an index. You can then use the RECOVER utility to recoverthe index by restoring this image copy and then applying the log, just as you havealways done to recover a table space. The process of recovering the indexinstead of rebuilding it can be more efficient and faster.

8.4 Utility enhancements in DB2 V7

DB2 for OS/390 Version 7 offers significant enhancements to the utilities,benefiting the Siebel-DB2 user.

8.4.1 Online REORGThe enhancement to online REORG improves the elapsed time of the SWITCHphase. The present method of renaming data sets is inefficient because of theoverhead involved with access method services (AMS). The improvement to theSWITCH phase is an internal DB2 change that requires no changes in Siebel.

8.4.2 Consistent restartDB2 Version 7 enhances the consistent restart by lifting some of the restrictionsimposed in DB2 Version 6. The RECOVER utility can now be used to recover theobjects associated with postponed aborted units of recovery, and the ability tocancel all postponed aborted units of recovery instead of recovering them.

8.4.3 Statistics historyData can now be stored in the DB2 catalog on a historical basis that will enableyou to do trend analysis. When RUNSTATS stores new information in the DB2catalog tables, it will also store that information in the DB2 Version 7 cataloghistory tables, so that the catalog will hold the current statistics, and the cataloghistory tables will hold historical, including current, statistics. The MODIFYSTATISTICS command will be used to delete the outdated statistics in the historytables.


Appendix A. Setting up DB2 Connect Personal Edition

DB2 Connect Personal Edition (PE) is required for the Connected Siebel Client ina two-tier implementation. The two-tier connections setup includes:

• DDF setup on DB2 for OS/390• DB2 Connect PE setup on a Windows workstation

At the end of the setup tasks, you should be able to successfully test yourconnections and access the DB2 database on OS/390.

We installed DB2 Personal Connect using the CD-ROM for DB2 ConnectPersonal Edition V6.1 on Windows NT.

For DB2 Connect V6, FixPak 3SA is required. It is available from:

http://www-4.ibm.com/software/data/db2/db2tech/indexsvc.html

When we installed the product, we selected DB2 Connect Personal Edition,then Typical on the installation menu. If you select Compact instead of Typical,you will not have all the functions.

Install DB2 Connect on each Siebel connected client workstation to communicateto the OS/390 DB2 database.

In our environment, we needed the following:

• A Windows NT workstation for the installation client• The DB2 Connect Personal Edition V6.1 software with the current FixPak

To avoid confusion, you should determine all the information you will need beforeyou start this process. Using inconsistent information will prevent you fromestablishing connectivity, and it will be difficult to determine what is incorrect.Table 4 on page 116 lists the parameters we used for our installation.


Table 4. DB2 Connect parameters for Windows

Client Configuration AssistantAfter you have installed DB2 Connect on the workstation, start thecustomization wizard as shown in Figure 41 on page 116.

Starting DB2 Connect and adding a databaseChoose Start -> Programs -> DB2 for Windows NY -> Client ConfigurationAssistant. When you start the client configuration assistant for the first time,the window shown in Figure 41appears. Choose the option to add a databaseby clicking Add.

Figure 41. Client Configuration Assistant initial screen


Protocol Database Services TCP/IP

Target Operating System MVS/ESA to OS/390

Hostname SYS1.TCPPARMS(PROFILE)

WTSC04 or 9.12.14.219

Port Number Port number for DRDA inSYS1.TCPPARMS(PROFILE)

33322

Target Database Location Name DB2D

Alias Database Name For DB2 Connect DBSIEBEL

TSO User ID Valid user ID with RACF andDB2 dbadm (use upper case)

SIEBEL1

TSO password RACF password (upper case) S1xxxx


Choosing the sourceChoose the option to manually configure the connection as shown in Figure42, then click Next.

Figure 42. Choosing the manual connection

Choosing the protocolChoose TCP/IP. This adds the option to choose the target operating system.Also choose MVS/ESA or OS/390, as shown in Figure 43.

Figure 43. Protocol selection

Appendix A. Setting up DB2 Connect Personal Edition 117

Specify TCP/IP communication parametersTCP/IP must already be configured before you do this step. We used theTCP/IP address at this point rather than the hostname, as we had not set up ahostname file. We left the Service name blank. The Port number must be thesame Port number that DDF is listening to on OS/390. We used 33322, asshown in Figure 44.

Figure 44. TCP/IP address and DDF Port number

Choosing the target databaseEnter the name of the target database. In our case this was DB2D as shown inFigure 45. DB2D is the location name defined in the DDF parameters onOS/390.

Alias nameEnter the alias name as shown in Figure 45. In our case, this was DBSIEBEL.

Figure 45. Database name and alias


OBDC NameWe used the default to register with ODBC. Click Done to complete thecustomization. See Figure 46.

Figure 46. ODBC tab

Node OptionsWe did not specify any node option, so we just clicked Next.

Figure 47. Node option


Security optionsThis is a new screen in DB2 Connect V6. We had to choose the host to allowDB2 to connect correctly, as shown in Figure 48.

Figure 48. Security options

Customization completeAt this point you should receive confirmation that the connection configurationwas added successfully as shown in Figure 49.

Figure 49. Successful connection for DB2 Connect PE

You can add additional aliases for the database now, or you can do this at themain screen (Client Configuration Assistant).


Testing the connectionThere are three ways to test the connection:

• Use the Test Connection option at the end of the customization.• Use the test button on the primary screen.• Connect to DB2 using the command line processor.

After clicking Test Connection, enter a valid TSO user ID and password inupper case.

A successful connection will result in the message shown in Figure 50.

Figure 50. Connection test successful

Test button on the database screenAt any time, you can click Test on the primary screen. If you receive an errormessage, you should check that:

• DB2 and DDF are started on OS/390.• Your parameters are consistent with source data.• You can ping the connection.• You used uppercase for the TSO user ID and password.

Figure 51 shows the primary screen after our successful configuration.

Figure 51. Client Configuration Assistant after completing the configuration


Appendix B. Setting up DB2 DDF

The following four steps customize DB2 DDF:

1. BSDS changes.

Most DDF parameters are stored in the DSNZPARM module. We used theDSNTIJUZ member in DSN610.NEW.SDSNSAMP to update the DSNZPARMmodule. One of the steps in the DSNTIJUZ JCL is to update the BSDSinformation, using the change log inventory utility. To execute the change loginventory you must stop the DB2 subsystem.

Following is the DSNTIJUZ job step to update the BSDS:

//DSNTLOG EXEC PGM=DSNJU003,COND=(4,LT)//STEPLIB DD DISP=SHR,DSN=DSN610.SDSNLOAD//SYSUT1 DD DISP=OLD,DSN=DSN610.BSDS01//SYSUT2 DD DISP=OLD,DSN=DSN610.BSDS02//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSIN DD *DDF LOCATION=DB2D,LUNAME=SCPDBA1,

NOPASSWD,RESPORT=33323,PORT=33322//*

2. Define DB2 DDF to VTAM - SYS1.LOCAL.VTAMLST.

To enable SNA LU6.2 support, you must also define an APPL in VTAM. Dothis in SYS1.LOCAL.VTAMLST. The LUNAME keyword must be defined inBSDS and the LU must be active, prior to starting DDF communications.

The following shows the APPL definitions in SYS1.LOCAL.VTAMLST:

** **** DB2 V6 LU DEFINITION FOR DRDA **** **

VBUILD TYPE=APPL*SCPDBA1 APPL ACBNAME=SCPDBA1, X

APPC=YES, XATNLOSS=ALL, XAUTH=(ACQ), XAUTOSES=10, XDMINWNL=25, XDMINWNR=25, XDSESLIM=50, XEAS=509, XENCR=NONE, XMODETAB=ISTINCLM, XPARSESS=YES, XSECACPT=ALREADYV, XSONSCIP=NO, XSYNCLVL=SYNCPT, XVERIFY=NONE, XVPACING=2, XVTAMFRR=NO


3. Define DB2 DDF to RACF.

DDF uses UNIX System Services to perform TCP/IP services. Some of theUNIX System Services functions that DDF executes require an authorizeduser with certain privileges. To execute the authorized functions, the user IDassociated with the DDF started task must be defined for UNIX SystemServices as a superuser. To define a user ID as a superuser, you must set theUser Identifier (UID) parameter of the RACF user profile to zero. To set theUID parameter for your DDF user, you can issue one of the following RACFcommands:

ADDUSER userid OMVS(UID(0))

ALTUSER userid OMVS(UID(0))

The ADDUSER RACF command adds a new user profile and should be usedwhen creating a new user for DDF. The ALTUSER RACF command changesthe RACF profile for the existing DDF user. To check whether your DDF userID is already correctly defined to RACF, issue the following RACF command:

LISTUSER userid OMVS

If you specify both a user ID and a group in the RACF Started ProcedureTable, ICHRIN03, for the DDF address space, the group must also have avalid UNIX System Services group ID (GID) setting. To define RACF groups tobe UNIX System Services groups, use the RACF panels or the followingcommand:

ADDGROUP groupid OMVS(GID(n))

where groupid is the name of the RACF group associated with the DDFaddress space, and can be any valid unique identifier.

4. Define DB2 DDF to TCP/IP.

Part of the DDF customization process is to select port numbers whenupdating the BSDS. The DDF statement of the change log inventory has beenenhanced with PORT and RESPORT values. If PORT and RESPORT aredefined, DDF accepts TCP/IP connections from any client that provides validsecurity information. DB2 also allows outbound connections to other DRDAservers using TCP/IP.

To define the port numbers in TCP/IP you must update the TCP/IP PROFILEdata set. In our case, we used SYS1.TCPPARMS member PROFILE. Youmust register the TCP/IP port numbers you have specified during DB2installation or when using the change log inventory utility.

We defined two port numbers required by our DB2 subsystem, DB2D. In thePORT statement you must use TCP as the protocol, and the name of the UNIXSystem Services started procedure (in our case, OMVS). Because DB2 usesUNIX System Services to connect to TCP/IP, the DB2 ports are reserved forthe UNIX System Services address space, and not for the DDF addressspace, xxxxDIST. The PORT definitions are shown here:

SYS1.TCPPARMS(PROFILE)PORT23 TCP INTCLIEN ;33322 TCP OMVS ; DRDA SQL PORT for DB2D33323 TCP OMVS ; DRDA SQL resync port for DB2D

For more detailed information on customizing DDF, refer to WOW! DRDASupports TCP/IP: DB2 Server for OS/390 and DB2, SG24-2212.


Appendix C. DSNZPARM parameters for DB2

This is the job we used to customize the DSNZPARMs:

//DB2DE JOB (999,POK),’DB2J INSTALL’,CLASS=A,MSGCLASS=T, 00000001// NOTIFY=&SYSUID 00000002/*JOBPARM L=9999,SYSAFF=SC04//*******************************************************************/00010000//* JOB NAME = DSNTIJUZ */00020000//* */00030000//* DESCRIPTIVE NAME = INSTALLATION JOB STREAM */00040000//* */00050000//* LICENSED MATERIALS - PROPERTY OF IBM */00060000//* 5645-DB2 */00070000//* (C) COPYRIGHT 1982, 1998 IBM CORP. ALL RIGHTS RESERVED. */00080000//* */00090000//* STATUS = VERSION 6 */00100000//* */00110000//* FUNCTION = DSNZPARM AND DSNHDECP UPDATES */00120000//* */00130000//* PSEUDOCODE = */00140000//* DSNTIZA STEP ASSEMBLE DSN6.... MACROS, CREATE DSNZPARM */00150000//* DSNTIZL STEP LINK EDIT DSNZPARM */00160000//* DSNTLOG STEP UPDATE PASSWORDS */00170000//* DSNTIZP STEP ASSEMBLE DSNHDECP DATA-ONLY LOAD MODULE */00180000//* DSNTIZQ STEP LINK EDIT DSNHDECP LOAD MODULE */00190000//* DSNTIMQ STEP SMP/E PROCESSING FOR DSNHDECP */00200000//* */00210000//* NOTES = STEP DSNTIMQ MUST BE CUSTOMIZED FOR SMP. SEE THE NOTES */00212000//* NOTES PRECEDING STEP DSNTIMQ BEFORE RUNNING THIS JOB. */00214000//* */00217000//*********************************************************************/002200//* 00225000//DSNTIZA EXEC PGM=ASMA90,PARM=’OBJECT,NODECK’ 00230000//SYSLIB DD DISP=SHR, 00240000// DSN=DSN610.SDSNMACS 00250000// DD DISP=SHR, 00260000// DSN=SYS1.MACLIB 00270000//SYSLIN DD DSN=&&LOADSET(DSNTILMM),DISP=(NEW,PASS), 00280000// UNIT=SYSALLDA, 00290000// SPACE=(800,(50,50,2)),DCB=(BLKSIZE=800) 00300000//SYSPRINT DD SYSOUT=* 00310000//SYSUDUMP DD SYSOUT=* 00320000//SYSUT1 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) 00330000//SYSUT2 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) 00340000//SYSUT3 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) 00350000//SYSIN DD * 00360000

DSN6ENV MVS=XA 00370000DSN6SPRM RESTART, X00370001

ALL, X00370002ABEXP=YES, X00370003ABIND=YES, X00370004AUTH=YES, X00370005AUTHCACH=1024, X00370006BINDNV=BINDADD, X00370007

Appendix C. DSNZPARM parameters for DB2 125

BMPTOUT=4, X00370008CACHEDYN=YES, X00370009CACHEPAC=8192, X00370010CACHERAC=8192, X00370011CATALOG=DB2V610D, X00370012CDSSRDEF=1, X00370013CHGDC=NO, X00370014CONTSTOR=YES, X00370015DECDIV3=NO, X00370016DEFLTID=IBMUSER, X00370017DESCSTAT=NO, X00370018DLITOUT=6, X00370019DSMAX=21000, X00370020EDMPOOL=51200, X00370021EDMDSPAC=0, X00370022EDPROP=NO, X00370023HOPAUTH=BOTH, X00370024IRLMAUT=YES, X00370025IRLMPRC=IRLDPROC, X00370026IRLMSID=IRLD, X00370027IRLMRWT=300, X00370028IRLMSWT=300, X00370029LEMAX=20, X00370030MAXRBLK=8192, X00370031MAXKEEPD=5000, X00370032NPGTHRSH=10, XNUMLKTS=1000, X00370033NUMLKUS=50000, X00370034OPTHINTS=NO, X00370035PARAMDEG=0, XPARTKEYU=YES, XRECALL=YES, X00370036RECALLD=120, X00370037RELCURHL=YES, X00370038RETLWAIT=0, X00370039RETVLCFK=NO, X00370040RGFCOLID=DSNRGCOL, X00370041RGFDBNAM=DSNRGFDB, X00370042RGFDEDPL=NO, X00370043RGFDEFLT=ACCEPT, X00370044RGFESCP=, X00370045RGFFULLQ=YES, X00370046RGFINSTL=NO, X00370047RGFNMORT=DSN_REGISTER_OBJT, X00370048RGFNMPRT=DSN_REGISTER_APPL, X00370049RRULOCK=NO, X00370050SEQCACH=BYPASS, X00370051SEQPRES=NO, X00370052SITETYP=LOCALSITE, X00370053SRTPOOL=897, X00370054SYSADM=KARRAS, X00370055SYSADM2=HAIMO, X00370056SYSOPR1=SYSOPR, X00370057SYSOPR2=SYSOPR, X00370058TRKRSITE=NO, X00370059UTIMOUT=6, X00370060XLKUPDLT=NO 00370061

DSN6ARVP ALCUNIT=BLK, X00370062


ARCWRTC=(1,3,4), X00370063ARCWTOR=YES, X00370064ARCPFX1=DB2V610D.ARCHLOG1, X00370065ARCPFX2=DB2V610D.ARCHLOG2, X00370066ARCRETN=9999, X00370067BLKSIZE=28672, X00370068CATALOG=NO, X00370069COMPACT=NO, X00370070PRIQTY=1234, X00370071PROTECT=NO, X00370072QUIESCE=5, X00370073SECQTY=154, X00370074TSTAMP=NO, X00370075UNIT=TAPE, X00370076UNIT2= 00370077

DSN6LOGP DEALLCT=(0), X00370078MAXARCH=1000, X00370079MAXRTU=2, X00370080OUTBUFF=4000, X00370081TWOACTV=YES, X00370082TWOARCH=YES, X00370083WRTHRSH=20, X00370084ARC2FRST=NO 00370085

DSN6SYSP AUDITST=NO, X00370086BACKODUR=5, X00370087CONDBAT=2500, X00370088CTHREAD=100, X00370089DBPROTCL=DRDA, X00370090DLDFREQ=5, X00370091DSSTIME=5, X00370092EXTRAREQ=100, X00370093EXTRASRV=100, X00370094IDBACK=20, X00370095IDFORE=40, X00370096IDXBPOOL=BP2, X00370097LBACKOUT=AUTO, X00370098LOBVALA=2048, X00370099LOBVALS=2048, X00370100LOGAPSTG=0, X00370101LOGLOAD=50000, X00370102MAXDBAT=1000, X00370103MON=YES, X00370104MONSIZE=8192, X00370105PCLOSEN=5, X00370106PCLOSET=10, X00370107RLF=NO, X00370108RLFTBL=01, X00370109RLFERR=NOLIMIT, X00370110RLFAUTH=SYSIBM, X00370111ROUTCDE=(1), X00370112EXTSEC=YES, X00370113SMFACCT=(1,2,3), X00370114SMFSTAT=YES, X00370115STATIME=30, X00370116STORMXAB=0, X00370117STORPROC=DB2DSPAS, X00370118STORTIME=180, X00370119TBSBPOOL=BP1, X00370120


TRACSTR=NO, X00370121TRACTBL=16, X00370122URCHKTH=0, X00370123WLMENV=WLMUTIL 00370124

DSN6FAC DDF=AUTO, X00370125CMTSTAT=ACTIVE, X00370126IDTHTOIN=0, X00370127RESYNC=2, X00370128RLFERRD=NOLIMIT, X00370129TCPALVER=NO, X00370130MAXTYPE1=0, X00370131TCPKPALV=ENABLE, X00370132POOLINAC=600 00370133

DSN6GRP DSHARE=NO, X00370134GRPNAME=DSNCAT, X00370135MEMBNAME=DSN1, X00370136COORDNTR=NO, X00370137ASSIST=NO 00370138

END 01370000//******************************************************************* 01380000//* LINK EDIT THE NEW DSNZPARM MEMBER. PUT LOAD MODULE IN SDSNEXIT. *01390000//******************************************************************* 01400000//DSNTIZL EXEC PGM=IEWL,PARM=’LIST,XREF,LET,RENT’, 01410000// COND=(4,LT) 01420000//ADSNLOAD DD DISP=SHR, 01430000// DSN=DSN610.SDSNLOAD 01440000// DD DISP=SHR, 01450000// DSN=DSN610.ADSNLOAD 01460000//SYSPUNCH DD DSN=&&LOADSET(DSNTILMM),DISP=(OLD,DELETE) 01470000//SYSLMOD DD DISP=SHR, 01480000// DSN=DB2V610D.SDSNEXIT 01490000//SYSPRINT DD SYSOUT=* 01500000//SYSUDUMP DD SYSOUT=* 01510000//SYSUT1 DD UNIT=SYSALLDA,SPACE=(1024,(50,50)) 01520000//SYSLIN DD * 01530000

INCLUDE SYSPUNCH(DSNTILMM) 01540000INCLUDE ADSNLOAD(DSNZPARM) 01550000ORDER DSNAA 01560000INCLUDE ADSNLOAD(DSNAA) 01570000INCLUDE ADSNLOAD(DSNFSYSP) 01580000INCLUDE ADSNLOAD(DSNJARVP) 01590000INCLUDE ADSNLOAD(DSNJLOGP) 01600000INCLUDE ADSNLOAD(DSNTSPRM) 01610000INCLUDE ADSNLOAD(DSNVDIR1) 01620000INCLUDE ADSNLOAD(DSNZMSTR) 01630000INCLUDE ADSNLOAD(DSN3DIR1) 01640000INCLUDE ADSNLOAD(DSN7GRP) 01650000ENTRY DSNZMSTR 01660000NAME DSNZDB2D(R) 01670000

//* 01680000//* CHANGE LOG INVENTORY: 01690000//* UPDATE BSDS 01700000//* 01720000//DSNTLOG EXEC PGM=DSNJU003,COND=(4,LT) 01730000//STEPLIB DD DISP=SHR,DSN=DSN610.SDSNLOAD 01740000//SYSUT1 DD DISP=OLD,DSN=DB2V610D.BSDS01 01750000//SYSUT2 DD DISP=OLD,DSN=DB2V610D.BSDS02 01760000//SYSPRINT DD SYSOUT=* 01770000


//SYSUDUMP DD SYSOUT=* 01780000//SYSIN DD * 01790000DDF LOCATION=DB2D,LUNAME=SCPDB2D, 01790001

NOPASSWD,RESPORT=33323,PORT=33322 01790002//* 02630000//******************************************************************* 02640000//* ASSEMBLE AND LINK EDIT DATA-ONLY LOAD MODULE DSNHDECP. 02650000//* THE FOLLOWING STEPS ARE NEEDED ONLY IF THE 02660000//* VALUES ARE CHANGED FROM THOSE WHICH ARE SHIPPED. 02670000//******************************************************************* 02680000//DSNTIZP EXEC PGM=ASMA90,PARM=’OBJECT,NODECK’,COND=(4,LT) 02690000//SYSLIB DD DISP=SHR, 02700000// DSN=DSN610.SDSNMACS 02710000//SYSLIN DD DSN=&&LOADSET(DSNHDECA),DISP=(NEW,PASS),UNIT=SYSALLDA, 02720000// SPACE=(80,(50,50,2)),DCB=(BLKSIZE=80) 02730000//SYSPRINT DD SYSOUT=* 02740000//SYSUDUMP DD SYSOUT=* 02750000//SYSUT1 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) 02760000//SYSUT2 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) 02770000//SYSUT3 DD UNIT=SYSALLDA,SPACE=(800,(50,50),,,ROUND) 02780000//SYSIN DD * 02790000

DSNHDECM CHARSET=ALPHANUM, X02790001ASCCSID=1252, X02790002AMCCSID=65534, X02790003AGCCSID=65534, X02790004SCCSID=500, X02790005MCCSID=65534, X02790006GCCSID=65534, X02790007ENSCHEME=ASCII, X02790008DATE=ISO, X02790009DATELEN=0, X02790010DECARTH=DEC15, X02790011DECIMAL=PERIOD, X02790012DEFLANG=IBMCOB, X02790013DELIM=DEFAULT, X02790014MIXED=NO, X02790015SQLDELI=DEFAULT, X02790016DSQLDELI=APOST, X02790017SSID=DB2D, X02790018STDSQL=NO, X02790019TIME=ISO, X02790020TIMELEN=0, X02790021DYNRULS=YES, X02790022LC_CTYPE=, X02790023COMPAT=OFF 02790024

END 02970000//* 02980000//******************************************************************* 02990000//* LINK EDIT DSNHDECP. * 03000000//* DSNHDECP IS A DATA-ONLY LOAD MODULE CONTAINING DEFAULT VALUES * 03010000//* REQUIRED BY DB2 AND APPLICATION PROGRAMS. * 03020000//* THIS STEP IS CREATED ONLY WHEN THE DEFAULTS SUPPLIED IN * 03030000//* DSNHDECP ARE NOT SUITABLE. * 03040000//******************************************************************* 03050000//DSNTIZQ EXEC PGM=IEWL,PARM=’LIST,XREF,LET,RENT’, 03060000// COND=(4,LT) 03070000//ADSNLOAD DD DISP=SHR, 03080000// DSN=DSN610.SDSNEXIT 03090000


// DD DISP=SHR, 03100000// DSN=DSN610.ADSNLOAD 03110000//SYSPUNCH DD DSN=&&LOADSET(DSNHDECA),DISP=(OLD,DELETE) 03120000//SYSLMOD DD DISP=SHR, 03130000// DSN=DB2V610D.SDSNEXIT 03140000//SYSPRINT DD SYSOUT=* 03150000//SYSUDUMP DD SYSOUT=* 03160000//SYSUT1 DD UNIT=SYSALLDA,SPACE=(1024,(50,50)) 03170000//SYSLIN DD * 03180000

INCLUDE SYSPUNCH(DSNHDECA) 03190000ORDER DSNAA 03200000INCLUDE ADSNLOAD(DSNAA) 03210000INCLUDE ADSNLOAD(DSNARIB) 03220000INCLUDE ADSNLOAD(DSNHDECP) 03230000ENTRY DSNHDECP 03240000MODE AMODE(24),RMODE(24) 03250000NAME DSNHDECP(R) 03260000

//* 03270000


Appendix D. Siebel-DB2 objects creation

This appendix shows the jobs we used to generate the Siebel-DB2 objects.

D.1 Create STOGROUPs

//CREATEST JOB (999,POK),'STOGROUP',NOTIFY=&SYSUID,// CLASS=A,MSGCLASS=T,TIME=1439,// MSGLEVEL=(1,1)//***//***//***/*JOBPARM SYSAFF=SC04//JOBLIB DD DSN=DB2V610D.RUNLIB.LOAD,DISP=SHR// DD DSN=DSN610.SDSNLOAD,DISP=SHR//CREATEST EXEC PGM=IKJEFT01,DYNAMNBR=20//SYSPRINT DD SYSOUT=*//SYSTSPRT DD SYSOUT=*//SYSOUT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN S(DB2D)RUN PROG(DSNTIAD) PLAN(DSNTIA61)END

//SYSIN DD *CREATE STOGROUP STOGRP01

VOLUMES(SIEBE1,SIEBE2,SIEBE3,SIEBE4,SIEBE5)VCAT DB2V610D;

GRANT USE OF STOGROUP STOGRP01 TO SSEEIM;GRANT USE OF STOGROUP STOGRP01 TO SIEBEL WITH GRANT OPTION;COMMIT;

//

D.2 Create databases

//CREATEDB JOB (999,POK),'CREATE DB',NOTIFY=&SYSUID,// CLASS=A,MSGCLASS=T,TIME=1439,// MSGLEVEL=(1,1)//***//***//***/*JOBPARM SYSAFF=SC04//JOBLIB DD DSN=DB2V610D.RUNLIB.LOAD,DISP=SHR// DD DSN=DSN610.SDSNLOAD,DISP=SHR//CREATEDB EXEC PGM=IKJEFT01,DYNAMNBR=20//SYSPRINT DD SYSOUT=*//SYSTSPRT DD SYSOUT=*//SYSOUT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN S(DB2D)RUN PROG(DSNTIAD) PLAN(DSNTIA61)

Appendix D. Siebel-DB2 objects creation 131

END//SYSIN DD *CREATE DATABASE SIEBEL01 STOGROUP STOGRP01;CREATE DATABASE SIEBEL02 STOGROUP STOGRP01;CREATE DATABASE SIEBEL03 STOGROUP STOGRP01;CREATE DATABASE SIEBEL04 STOGROUP STOGRP01;CREATE DATABASE SIEBEL06 STOGROUP STOGRP01;CREATE DATABASE SIEBEL07 STOGROUP STOGRP01;CREATE DATABASE SIEBEL08 STOGROUP STOGRP01;CREATE DATABASE SIEBEL09 STOGROUP STOGRP01;CREATE DATABASE SIEBEL10 STOGROUP STOGRP01;COMMIT;

//

D.3 Create table spaces

//CREATETS JOB (999,POK),'CREATE TS',NOTIFY=&SYSUID,// CLASS=A,MSGCLASS=T,TIME=1439,// MSGLEVEL=(1,1)//***//***//***/*JOBPARM SYSAFF=SC04//JOBLIB DD DSN=DB2V610D.RUNLIB.LOAD,DISP=SHR// DD DSN=DSN610.SDSNLOAD,DISP=SHR//CREATETS EXEC PGM=IKJEFT01,DYNAMNBR=20//SYSPRINT DD SYSOUT=*//SYSTSPRT DD SYSOUT=*//SYSOUT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN S(DB2D)RUN PROG(DSNTIAD) PLAN(DSNTIA61)END

//SYSIN DD DSN=SIEBEL.TBSPACES.SQL,DISP=SHR//

SIEBEL.TBSPACES.SQLThe following is a sample of what is contained in the SIEBEL.TBSPACES.SQLdata set, which is generated during the install process.

CREATE TABLESPACE FFFFF001IN SIEBEL01USING STOGROUP STOGRP01 PRIQTY 720 SECQTY 720BUFFERPOOL BP32K1LOCKSIZE PAGE;

CREATE TABLESPACE EEEEE001IN SIEBEL02USING STOGROUP STOGRP01 PRIQTY 720 SECQTY 720BUFFERPOOL BP16K1


LOCKSIZE PAGE;

CREATE TABLESPACE GGGGG010IN SIEBEL03USING STOGROUP STOGRP01 PRIQTY 720 SECQTY 720BUFFERPOOL BP16K1LOCKSIZE PAGE;

CREATE TABLESPACE GGGGG011IN SIEBEL03USING STOGROUP STOGRP01 PRIQTY 720 SECQTY 720BUFFERPOOL BP16K1LOCKSIZE PAGE;

(and so forth)

D.4 Create tables

//CREATETB JOB (999,POK),'CREATE TABLE',NOTIFY=&SYSUID,// CLASS=A,MSGCLASS=T,TIME=1439,// MSGLEVEL=(1,1)//***//***//***/*JOBPARM SYSAFF=SC04//JOBLIB DD DSN=DB2V610D.RUNLIB.LOAD,DISP=SHR// DD DSN=DSN610.SDSNLOAD,DISP=SHR//CREATETB EXEC PGM=IKJEFT01,DYNAMNBR=20//SYSPRINT DD SYSOUT=*//SYSTSPRT DD SYSOUT=*//SYSOUT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN S(DB2D)RUN PROG(DSNTIAD) PLAN(DSNTIA61)END

//SYSIN DD DSN=SIEBEL.TABLES.SQL1,DISP=SHR//

SIEBEL.TABLES.SQL1The following is a sample of what is contained in the SIEBEL.TABLES.SQL1 dataset used in the creat e tables JCL. The data set is generated during the installprocess.

CREATE TABLE EIM_ACCNT_DTL (MS_IDENT NUMERIC(15,0) GENERATED ALWAYS AS IDENTITY,ROW_ID VARCHAR(15) NOT NULL,CREATED TIMESTAMP DEFAULT ,CREATED_BY VARCHAR(15),LAST_UPD TIMESTAMP DEFAULT ,LAST_UPD_BY VARCHAR(15),MODIFICATION_NUM NUMERIC(10,0) DEFAULT 0,


CONFLICT_ID VARCHAR(15) DEFAULT '0',IF_ROW_BATCH_NUM NUMERIC(15,0)

DEFAULT 0 NOT NULL,IF_ROW_STAT VARCHAR(30) NOT NULL,NAME VARCHAR(100) NOT NULL,ACCNT_BI VARCHAR(15),ACCNT_BU VARCHAR(50),ACC_PR_LOGO CHAR(1),ASGN_IT_TYPE_NAME VARCHAR(75),ATT_COMMENTS VARCHAR(250),ATT_FILE_EXT VARCHAR(10),ATT_FILE_NAME VARCHAR(200),ATT_FILE_SRC_TYPE VARCHAR(30),COMMENTS VARCHAR(250),EXT_ATTRIB_01 VARCHAR(100),EXT_ATTRIB_02 VARCHAR(100),EXT_ATTRIB_03 VARCHAR(30),EXT_ATTRIB_04 VARCHAR(30),EXT_ATTRIB_05 VARCHAR(30),EXT_ATTRIB_06 VARCHAR(30),EXT_ATTRIB_07 VARCHAR(30),EXT_ATTRIB_08 CHAR(1),EXT_ATTRIB_09 CHAR(1),EXT_ATTRIB_10 CHAR(1),EXT_ATTRIB_11 CHAR(1),EXT_ATTRIB_12 TIMESTAMP,EXT_ATTRIB_13 TIMESTAMP,EXT_ATTRIB_14 NUMERIC(22,7),EXT_ATTRIB_15 NUMERIC(22,7),EXT_ATTRIB_16 NUMERIC(22,7),EXT_ATTRIB_17 NUMERIC(22,7),EXT_ATTRIB_18 NUMERIC(22,7),EXT_ATTRIB_19 NUMERIC(22,7),EXT_ATTRIB_20 NUMERIC(22,7),EXT_ATTRIB_21 NUMERIC(22,7),EXT_ATTRIB_22 NUMERIC(22,7),EXT_ATTRIB_23 NUMERIC(22,7),EXT_ATTRIB_24 NUMERIC(22,7),EXT_ATTRIB_25 NUMERIC(22,7),EXT_ATTRIB_26 TIMESTAMP,EXT_ATTRIB_27 TIMESTAMP,EXT_ATTRIB_28 TIMESTAMP,EXT_ATTRIB_29 TIMESTAMP,EXT_ATTRIB_30 TIMESTAMP,EXT_ATTRIB_31 TIMESTAMP,EXT_ATTRIB_32 TIMESTAMP,EXT_ATTRIB_33 TIMESTAMP,EXT_ATTRIB_34 VARCHAR(50),EXT_ATTRIB_35 VARCHAR(50),EXT_ATTRIB_36 VARCHAR(50),EXT_ATTRIB_37 VARCHAR(50),EXT_ATTRIB_38 VARCHAR(50),EXT_ATTRIB_39 VARCHAR(50),EXT_ATTRIB_40 VARCHAR(50),EXT_ATTRIB_41 VARCHAR(50),EXT_ATTRIB_42 VARCHAR(50),EXT_ATTRIB_43 VARCHAR(50),EXT_ATTRIB_44 VARCHAR(100),


EXT_ATTRIB_45 VARCHAR(100),EXT_ATTRIB_46 VARCHAR(100),EXT_ATTRIB_47 VARCHAR(255),IF_ROW_MERGE_ID VARCHAR(15),IF_ROW_STAT_NUM NUMERIC(10,0),INCL_EXCL_CD VARCHAR(30),IT_COMMENTS VARCHAR(250),IT_EXPERTISE_CD VARCHAR(30),IT_LO_CHAR1 VARCHAR(100),IT_LO_CHAR2 VARCHAR(50),

IT_LO_CHAR3 VARCHAR(50),IT_LO_CHAR4 VARCHAR(250),IT_LO_NUM1 NUMERIC(10,0),IT_LO_NUM2 NUMERIC(10,0),IT_LO_NUM3 NUMERIC(10,0),IT_LO_NUM4 NUMERIC(10,0),LOC VARCHAR(50),NOTE_NOTE LONG VARCHAR,NOTE_NOTE_TYPE VARCHAR(30),NOTE_PRIV_FLG CHAR(1),ORG_SKL_NAME VARCHAR(50),T_ACCNT_ATT_PARROW VARCHAR(15),T_ACCNT_ATT__EXS CHAR(1),T_ACCNT_ATT__RID VARCHAR(15),T_ACCNT_ATT__STA NUMERIC(10,0),T_ACCNT_ATT__UNQ CHAR(1),T_DELETED_ROW_ID VARCHAR(15),T_EXPORTED_ROW_ID VARCHAR(15),T_MERGED_ROW_ID VARCHAR(15),T_NOTEACCNT_SRCROW VARCHAR(15),T_NOTEACCNT__EXS CHAR(1),T_NOTEACCNT__RID VARCHAR(15),T_NOTEACCNT__STA NUMERIC(10,0),T_NOTEACCNT__UNQ CHAR(1),T_ORGEXT_XM_PARROW VARCHAR(15),T_ORGEXT_XM__EXS CHAR(1),T_ORGEXT_XM__RID VARCHAR(15),T_ORGEXT_XM__STA NUMERIC(10,0),T_ORGEXT_XM__UNQ CHAR(1),T_ORGSKILLI_ORGSKI VARCHAR(15),T_ORGSKILLI__EXS CHAR(1),T_ORGSKILLI__RID VARCHAR(15),T_ORGSKILLI__STA NUMERIC(10,0),T_ORGSKILLI__UNQ CHAR(1),T_ORG_EXT_BU_ID VARCHAR(15),T_ORG_EXT_X__EXS CHAR(1),T_ORG_EXT_X__RID VARCHAR(15),T_ORG_EXT_X__STA NUMERIC(10,0),T_ORG_EXT_X__UNQ CHAR(1),T_ORG_EXT__EXS CHAR(1),T_ORG_EXT__RID VARCHAR(15),T_ORG_EXT__STA NUMERIC(10,0),T_ORG_EXT__UNQ CHAR(1),T_ORG_SKILL_ORG_ID VARCHAR(15),T_ORG_SKILL__EXS CHAR(1),T_ORG_SKILL__RID VARCHAR(15),T_ORG_SKILL__STA NUMERIC(10,0),T_ORG_SKILL__UNQ CHAR(1),


XM_NAME VARCHAR(100),XM_TYPE VARCHAR(30))IN SIEBEL04.GGGGG003;GRANT SELECT,INSERT,UPDATE,DELETE ON EIM_ACCNT_DTL TO SSEROLE;CREATE UNIQUE INDEX EIM_ACCNT_DTL_U1 ON EIM_ACCNT_DTL(ROW_ID, IF_ROW_BATCH_NUM)CLUSTER USING STOGROUP STOGRP01 PRIQTY720 SECQTY 720 DEFINE NO CLOSE YES;

(and so forth)


Appendix E. Adding a temporary database and table spaces

Here is the job we used to create the temporary database and table spacesrequired to enable the stored procedures for Siebel:

//CREATETP JOB (999,POK),'CREATE TP',NOTIFY=&SYSUID, 00010023// CLASS=A,MSGCLASS=T,TIME=1439, 00020017// MSGLEVEL=(1,1) 00030017//***/*JOBPARM SYSAFF=SC04//JOBLIB DD DSN=DB2V610D.RUNLIB.LOAD,DISP=SHR// DD DSN=DSN610.SDSNLOAD,DISP=SHR//CREATEDB EXEC PGM=IKJEFT01,DYNAMNBR=20//SYSPRINT DD SYSOUT=*//SYSTSPRT DD SYSOUT=*//SYSOUT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN S(DB2D)RUN PROG(DSNTIAD) PLAN(DSNTIA61)END

//SYSIN DD *CREATE DATABASE SIEBELTP AS TEMP STOGROUP STOGRP01;CREATE TABLESPACE TMPSPAC1

IN SIEBELTPUSING STOGROUP STOGRP01 PRIQTY 720 SECQTY 720BUFFERPOOL BP7;

CREATE TABLESPACE TMPSPAC2IN SIEBELTPUSING STOGROUP STOGRP01 PRIQTY 720 SECQTY 720BUFFERPOOL BP16K11;

CREATE TABLESPACE TMPSPAC3IN SIEBELTPUSING STOGROUP STOGRP01 PRIQTY 720 SECQTY 720BUFFERPOOL BP32K1;

COMMIT;/*//

Appendix E. Adding a temporary database and table spaces 137

Appendix F. Stored procedures enablement

A DB2 stored procedure is a compiled program, stored at a DB2 local or remotedatabase server, that can execute SQL statements. A client application programuses the SQL CALL statement to invoke the stored procedure.

Using the DSNUTILS stored procedure, an application program can start a DB2utility. When called, DSNUTILS dynamically allocates the specified data sets,creates the utility input stream (SYSIN), invokes DB2 utilities (DSNUTILB),deletes all rows currently in the created global temporary table(SYSIBM.SYSPRINT), captures the utility output stream (SYSPRINT), and putsthis output into the created global temporary table (SYSIBM.SYSPRINT).

Stored procedures require the following:

• RRS attachment• WLM-established address space

F.1 RRS setup

OS/390 Recoverable Resource Manager Services (OS/390 RRS) providessystem-wide services for coordinating two-phase commit operations acrossOS/390 products. RRSAF is a DB2 attachment facility that uses OS/390 RRS.

Before you can run an RRSAF application, OS/390 RRS must be started. OS/390RRS runs in its own address space and can be started and stoppedindependently of DB2. Resource Recovery Services (RRS) is an OS/390 SystemLogger application that records events related to protected resources. RRSrecords these events in five log streams that are shared by systems in a sysplex.

System Logger is an OS/390 component that allows an application to log data.You can log data from one system or from multiple systems across the sysplex. ASystem Logger application can write log data into a log stream, which is simply acollection of data.

There are two types of log stream: coupling facility log stream and DASD-only logstream. In a coupling facility log stream, the list structures are used as interimstorage for log data. In a DASD-only log stream, the log data is stored in localstorage buffers on the system. Local storage buffers are data space areasassociated with the System Logger address space, IXGLOGR.

You can use either one for setting up RRS, regardless of whether your system isdata-sharing or non-data-sharing. Typical data-sharing installations use acoupling facility log stream, while typical non-data-sharing installations use aDASD-only log stream.

The following is an example of RRS setup:

• Add subsystem entries to parmlib IEFSSNnn:

SUBSYS SUBNAME(LOGR)INITRTN(IXGSSINT)

SUBSYS SUBNAME(RRS)

• Edit SMS routines and add a data class for log streams, with shrlevel(3,3) andvolume count 1. The default HLQ is IXGLOGR. Edit selections routines to put


log streams and logger couple data sets in the new data class and appropriatestorage classes.

• Activate SMS changes.

• Make sure that IEASYSnn has the following statements:

COUPLE=nnPLEXCFG=MONOPLEXSYSNAME=xxxx

where nn is the COUPLEnn member, and xxxx is your system name.

• Create a COUPLEnn member:

COUPLE SYSPLEX(WTSCPLX1)PCOUPLE(SYS1.XCF.CDS01)ACOUPLE(SYS1.XCF.CDS02)

.

.

.DATA TYPE(LOGR)PCOUPLE(SYS1.XCF.LOGR00)ACOUPLE(SYS1.XCF.LOGR01)

• Allocate data sets

In our environment we used a duplex Coupling Facility.

• Allocate the sysplex couple data sets:

//L06RCPL JOB (999,POK),'L06R ',NOTIFY=&SYSUID,// CLASS=A,MSGCLASS=T,TIME=1439,// REGION=5000K,MSGLEVEL=(1,1)/*JOBPARM SYSAFF=SC04//**************************************************************//* JCL TO FORMAT THE PRIMARY AND ALTERNATE SYSPLEX CDS.//**************************************************************//STEP1 EXEC PGM=IXCL1DSU//STEPLIB DD DSN=SYS1.MIGLIB,DISP=SHR//SYSPRINT DD SYSOUT=*//SYSIN DD *

DEFINEDS SYSPLEX(WTSCPLX1)DSN(SYS1.XCF.CDS02) VOLSER(TOTDS0)MAXSYSTEM(16)CATALOG

DATA TYPE(SYSPLEX)ITEM NAME(GRS) NUMBER(1)ITEM NAME(GROUP) NUMBER(100)ITEM NAME(MEMBER) NUMBER(200)

DEFINEDS SYSPLEX(WTSCPLX1)DSN(SYS1.XCF.CDS03) VOLSER(TOTDS1)MAXSYSTEM(16)CATALOG

DATA TYPE(SYSPLEX)ITEM NAME(GRS) NUMBER(1)

• Allocate the Logger couple data sets:

//DEFLOGRS JOB (999,POK),'LOGR POLICY',CLASS=A,REGION=4M,// MSGCLASS=X,TIME=10,MSGLEVEL=(1,1),NOTIFY=&SYSUID/*JOBPARM SYSAFF=SC04


//STEP1 EXEC PGM=IXCMIAPU//SYSPRINT DD SYSOUT=*//SYSABEND DD SYSOUT=*//SYSIN DD *

DATA TYPE(LOGR) REPORT(YES)

DEFINE STRUCTURE NAME(RRS_ARCHIVE_1) LOGSNUM(1)MAXBUFSIZE(64000) AVGBUFSIZE(262)

DEFINE STRUCTURE NAME(RRS_RMDATA_1) LOGSNUM(1)MAXBUFSIZE(1024) AVGBUFSIZE(252)

DEFINE STRUCTURE NAME(RRS_MAINUR_1) LOGSNUM(1)MAXBUFSIZE(64000) AVGBUFSIZE(158)

DEFINE STRUCTURE NAME(RRS_DELAYEDUR_1) LOGSNUM(1)MAXBUFSIZE(64000) AVGBUFSIZE(158)

DEFINE STRUCTURE NAME(RRS_RESTART_1) LOGSNUM(1)MAXBUFSIZE(64000) AVGBUFSIZE(158)

DEFINE LOGSTREAMNAME(ATR.WTSCPLX1.ARCHIVE) STRUCTNAME(RRS_ARCHIVE_1)LS_DATACLAS(SHARE33)HLQ(LOGR) MODEL(NO) LS_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80) STG_DUPLEX(NO)RETPD(15) AUTODELETE(YES)

DEFINE LOGSTREAMNAME(ATR.WTSCPLX1.RM.DATA) STRUCTNAME(RRS_RMDATA_1)LS_DATACLAS(SHARE33)HLQ(LOGR) MODEL(NO) LS_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80) STG_DUPLEX(NO)RETPD(15) AUTODELETE(YES)

DEFINE LOGSTREAMNAME(ATR.WTSCPLX1.MAIN.UR) STRUCTNAME(RRS_MAINUR_1)LS_DATACLAS(SHARE33)HLQ(LOGR) MODEL(NO) LS_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80) STG_DUPLEX(NO)RETPD(15) AUTODELETE(YES)

DEFINE LOGSTREAMNAME(ATR.WTSCPLX1.DELAYED.UR) STRUCTNAME(RRS_DELAYEDUR_1)LS_DATACLAS(SHARE33)HLQ(LOGR) MODEL(NO) LS_SIZE(1024)LOWOFFLOAD(0) HIGHOFFLOAD(80) STG_DUPLEX(NO)RETPD(15) AUTODELETE(YES)

• Activate Sysplex and System Logger.

IPL to activate Syspex and System Logger. Check to see if the System Logger(IXGLOGR) is active by issuing the D A,ALL command.

Appendix F. Stored procedures enablement 141

• Set up RRS.

Determine naming conventions for the RRS log streams and log stream datasets. The default log stream names are ATR.gname.logstreamname, while thedefault data set names are IXGLOGR.ATR.gname.logstreamname, wheregname (group name) defaults to the Sysplex name. Note that the group nameis supported by RRS and allows for separation of groups such as productionand test RRS groups within a single Sysplex. However, APPC does notsupport group names; it is thus not possible to separate APPC into test andproduction groups within the Sysplex.

Ensure that the log stream data sets are properly defined to DFSMS, i.e., ACSroutines, storage class, group, etc., and SHARE OPTIONS(3,3).

Set up RRS proc (see SYS1.SAMPLIB(ATRRRS)).

• Start RRS

IEF403I RRS - STARTED - TIME=19.20.25 - ASID=01F6.ATR221I RRS IS JOINING RRS GROUP WTSCPLX1 ON SYSTEM SC04

• Start DB2

You may receive the following warning message during DB2’s start up:

DSN7407I -SB1 DSN7GAR1AUTOMATIC RESTART MANAGER REGISTER FAILED.MVS IXCARM RETURN CODE = 0000000C,MVS IXCARM REASON CODE = 00000160

If you receive this warning, ignore it.

F.2 WLM setup

We recommend that you use WLM goal mode which provides a simplerenvironment for running DB2 stored procedures. DSNUTILS stored procedureruns in WLM-established address spaces which are automatically started andstopped in goal mode environments. In the compatibility mode, WLM cannotautomatically start and stop these address spaces, and managing them is theinstallation’s responsibility.

To customize WLM for stored procedure usage, proceed as follows:

• Define a new application environment.

Using the WLM panels, select option 2 to extract definitions from WLMcouple data sets.

In the WLM Definition menu, select option Application Environment tocreate a new application environment.

IXGLOGR IXGLOGR IEFPROC NSW * A=0016 PER=NO SMC=000PGN=N/A DMN=N/A AFF=NONECT=013.584S ET=00127.31WKL=SYSTEM SCL=SYSTEM P=1RGP=N/A SRVR=NO QSC=NO


In order to ensure proper functioning of these stored procedures when theyare executed in parallel, NUMTCB must be set to 1.

The variable &IWMSSNM for the DB2SSN parameter makes it possible to useone JCL for multiple DB2 subsystems. The variable &IWMSSNM representsthe name of the DB2 subsystem for which the address space starts. If avariable is not desired (as for a single DB2 subsystem), then the StartParameters line should look like this:

Start Parameters . . . . DB2SSN=DB2D,NUMTCB=1,APPLENV=DB2DUTIL

• You should now install the new definition on the WLM couple data set andactivate the service policy. Display the status of the new applicationenvironment:

/D WLM,APPLENV=WLMUTIL

The following response appears:

RESPONSE=SC04IWM029I 16.48.57 WLM DISPLAY 543APPLICATION ENVIRONMENT NAME STATE STATE DATAWLMUTIL AVAILABLEATTRIBUTES: PROC=DB2DUTIL SUBSYSTEM TYPE: DB2

• Create JCL for running the WLM-established stored procedures addressspace:

//*************************************************************//* JCL PROCEDURE FOR THE STARTUP OF THE//* DB2 STORED PROCEDURES ADDRESS SPACE//* RGN -- THE MVS REGION SIZE FOR THE ADDRESS SPACE.//* SUBSYS -- THE DB2 SUBSYSTEM NAME.//* NUMTCB -- THE NUMBER OF TCBS TO BE USED TO//* PROCESS STORED PROCEDURE REQUESTS.//*//*************************************************************//WLMUTIL PROC RGN=0K,DB2SSN=DB2D,NUMTCB=1,APPLENV=//IEFPROC EXEC PGM=DSNX9WLM,REGION=&RGN,TIME=NOLIMIT,// PARM='&DB2SSN,&NUMTCB,&APPLENV.'//STEPLIB DD DISP=SHR,DSN=DSN610.SDSNLOAD// DD DISP=SHR,DSN=CEE.SCEERUN//SYSIN DD UNIT=SYSDA,SPACE=(4000,20,20),,,ROUND)//SYSPRINT DD UNIT=SYSDA,SPACE=(4000,20,20),,,ROUND)

Create an Application EnvironmentCommand ===>

Appl Environment Name . . WLMUTILDescription . . . . . . . WLM for DSNUTILS stored ProcSubsystem type . . . . . DB2Procedure name . . . . . DB2DUTILStart parameters . . . . DB2SSN=&IWMSSNM,TCB=1,APPLENV=DB2DUTIL

Limit on starting server address spaces for a subsystem instance:No limit


• Create stored procedures in the DB2 catalog of the subsystem and permitaccess to the new object. Adapt a copy of the member DSNTIJSG of the dataset SDSNSAMP and create the procedure SYSPROC.DSNUTILS. The valueof the parameter WLM ENVIRONMENT must match the entry in the WLMapplication environment (e.g. WLMUTIL). WLM ENVIRONMENT identifies thename of the WLM environment in which the stored procedure is to run whenthe DB2 stored procedure is WLM-established.

F.3 Testing stored procedures

To test stored procedures using WLM, you should compile, link, and run a storedprocedure requester program.

Member DSNTEJ6U of the data set SDSNSAMP prepares and executes thesample program DSN8EPU, which also resides in SDSNSAMP.

//DSNTEJ6U JOB (999,POK),'INSTALL ',CLASS=A,MSGCLASS=T,// NOTIFY=&SYSUID,TIME=1440,REGION=4M/*JOBPARM L=999,SYSAFF=SC04//********************************************************************//* FUNCTION = THIS JCL PREPARES AND EXECUTES A SAMPLE APPLICATION//* PROGRAM, DSN8EPU, THAT DEMONSTRATES THE DB2 UTILITY//* STORED PROCEDURE INKING A DB2 UTILITY.//********************************************************************//JOBLIB DD DISP=SHR,DSN=CEE.SCEERUN// DD DISP=SHR,DSN=DSN610.SDSNEXIT// DD DISP=SHR,DSN=DSN610.SDSNLOAD// DD DISP=SHR,DSN=DSN610.RUNLIB.LOAD//*//********************************************************************//* STEP 1: PRE-COMPILE, COMPILE, AND LINK-EDIT THE CALLING PROGRAM//********************************************************************//PH06US01 EXEC DSNHPLI,MEM=DSN8EPU,// PARM.PC='HOST(PLI),STDSQL(NO),CONNECT(2)',// PARM.PLI=(NOOPTIMIZE,'SIZE(506756)','MARGINS(2,72,0)',// 'SEQUENCE(73,80)',OBJECT,NODECK)//PPLI.SYSIN DD DSN=DSN610.SDSNSAMP(DSN8EPU),// DISP=SHR//PC.DBRMLIB DD DSN=DSN610.DBRMLIB.DATA(DSN8EPU),// DISP=SHR//PC.SYSLIB DD DSN=DSN610.SRCLIB.DATA,// DISP=SHR//LKED.SYSLMOD DD DSN=DSN610.RUNLIB.LOAD(DSN8EPU),// DISP=SHR//LKED.SYSIN DD *INCLUDE SYSLIB(DSNELI)NAME DSN8EPU(R)

//*//********************************************************************//* STEP 2: BIND THE CALLING PROGRAM PACKAGE//********************************************************************//PH06US02 EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)//DBRMLIB DD DSN=DSN610.DBRMLIB.DATA,// DISP=SHR//SYSTSPRT DD SYSOUT=*


//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN SYSTEM(DB2D)BIND PACKAGE(DSN8EP61) MEMBER(DSN8EPU) ACT(REP) ISO(CS)BIND PLAN(DSN8EPU) PKLIST(DSN8EP61.DSN8EPU,DSNUTILS.*) -

ACT(REP) ISO(CS) SQLRULES(DB2)END//*//********************************************************************//* STEP 3: EXECUTE THE STORED PROCEDURE//********************************************************************//PH06US03 EXEC PGM=IKJEFT1B,DYNAMNBR=20 ,COND=(4,LT)//SYSTSPRT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD *DSN SYSTEM(DB2D)RUN PROGRAM(DSN8EPU) PLAN(DSN8EPU) -

LIB('DSN610.RUNLIB.LOAD')END//SYSIN DD *Uid='DIAGNOSEDISPMEPL',Restart='',Utstmt='DIAGNOSE DISPLAY MEPL',Utility='DIAGNOSE';//

Executing the sample program starts the additional DB2 address space forrunning WLM-established stored procedures address space (if not yet started,e.g. DB2DUTIL). The sample program executes a DIAGNOSE DISPLAY MEPLutility.


Appendix G. Enterprise Storage Server

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

The ESS is a high-performance RAID-5 storage subsystem, and is a member ofthe Seascape family. It consists of a storage server and attached disk storagedevices. The storage server provides integrated caching and RAID support for theattached disk devices. The ESS can be configured in a variety of ways to providescalability in capacity and performance.

Redundancy within the ESS provides continuous availability. It is packaged in oneor more enclosures, each with dual line cords and redundant power. Theredundant power system allows the ESS to continue normal operation when oneof 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 arecompatible with the attached servers. The logical devices access a logical volumethat is implemented using multiple disk drives.

The following host I/O interface attachments are supported:

• SCSI-3 Parallel Interface• ESCON• FC-AL• FICON

On SCSI-3 interfaces, the ESS emulates a variety of fixed-block devices witheither 512 or 520 byte blocks. SCSI-3 is, in general, a superset of SCSI-2. ASCSI-3 disk device can be attached to a SCSI-2 initiator, provided the cabling canbe interfaced. Many SCSI-2 initiators attach directly to the cabling specified forthe SCSI-3 parallel interface, but are referred to as SCSI-2 initiators because theylimit their use of the command set to the SCSI-2 subset. Host systems withSCSI-2 or SCSI-3 interfaces can attach to the ESS. The ESS provides multipleSCSI I/O interfaces (busses), each with multiple SCSI targets, and each withmultiple disk logical units. The storage provided by the ESS for SCSI interfacescan be configured so that it is shared among multiple SCSI interfaces if desired.

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

The storage server is composed of two clusters that provide the facilities withadvanced 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 iscomposed of the following subcomponents:

• Host Adapters -- Each cluster has one or more host adapters (HAs). Each hostadapter provides one or more host I/O interfaces. A host adapter cancommunicate with either cluster complex.


• Device Adapters -- Each cluster has one or more device adapters (DAs). Eachdevice adapter provides one or more storage device interfaces. Disk drivesare attached to a pair of device adapters, one in each cluster, so that thedrives are accessible from either cluster. At any given time, a disk drive ismanaged by only one device adapter.

• Cluster Complex -- The cluster complex provides the management functionsfor 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(CPs) configured as symmetrical multiprocessors (SMPs). The clusterprocessors execute the licensed internal code that controls operation of thecluster.

• Cluster memory/cache -- This is used to store instructions and data for thecluster processors. The cache memory is used to store cached data from thedisk drives. The cache memory is accessible by the local cluster complex, bydevice adapters in the local cluster, and by host adapters in either cluster.

• Nonvolatile storage (NVS) -- This is used to store a nonvolatile copy of activewritten data. The NVS is accessible to either cluster-processor complex and tohost adapters in either cluster. Data may also be transferred between the NVSand cache.

• Disk Drives -- Provide the primary nonvolatile storage medium for any hostdata stored within the ESS Storage devices. They are grouped into ranks andare managed by the clusters

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

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

• Supports 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 tomanage the ESS logical configuration.

• Excellent scalability:

– From 400 GB to over 11 TB

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

• Performance optimized to your heterogeneous environment needs:

– High bandwidth and advanced transaction processing capabilities providesolutions for both online and batch applications.

– Innovations such as Parallel Access Volumes to reduce resourcecontention and dramatically improve performance through the eliminationor reduction of IOSQ for single-host environments.


– Multiple Allegiance, which allows you to dramatically reduce or eliminateIOSQ time for a multiple-host environment.

– Performance Enhanced CCW commands.

– I/O Priority Queuing -- allows users to define the priority of applicationworkloads.

– Custom Volumes -- the ability to create your own custom-sized logicalvolumes.

• Availability required to support e-business applications.

– Business continuity through remote copy services - PPRC and XRC

– Rapid data duplication through FlashCopy, providing extensive capabilitiesto exploit, manage, and protect your information in a 7x24 environment

– Peer-to-Peer Remote Copy (PPRC) -- the ability to create synchronousvolume copies via ESCON channels

– Extended Remote Copy (XRC) -- the ability to create asynchronous volumecopies over long distances

– Concurrent Copy (CC) -- the ability to create volume or data set copies,locally and nondisruptively

• Storage server availability through redundancy and nondisruptive service withdesign for no single point of failure or repair.

More information is available from not only the ESS product manuals, but also asuite of IBM redbooks, which include:

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

www.redbooks.ibm.com .

Appendix G. Enterprise Storage Server 149

Appendix H. Special notices

This publication is intended to help those who are installing Siebel Applicationson OS/390 for the first time. The information in this publication is not intended asthe specification of any programming interfaces that are provided by OS/390 andDB2. See the PUBLICATIONS section of the IBM Programming Announcementfor OS/390 and DB2 for more information about what publications are consideredto be product documentation.

References in this publication to IBM products, programs or services do not implythat 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 orimply that only IBM's product, program, or service may be used. Any functionallyequivalent program that does not infringe any of IBM's intellectual property rightsmay be used instead of the IBM product, program or service.

Information in this book was developed in conjunction with use of the equipmentspecified, and is limited in application to those specific hardware and softwareproducts and levels.

IBM may have patents or pending patent applications covering subject matter inthis document. The furnishing of this document does not give you any license tothese patents. You can send license inquiries, in writing, to the IBM Director ofLicensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation 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 formalIBM 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 noresponsibility for its accuracy or completeness. The use of this information or theimplementation of any of these techniques is a customer responsibility anddepends on the customer's ability to evaluate and integrate them into thecustomer's operational environment. While each item may have been reviewed byIBM for accuracy in a specific situation, there is no guarantee that the same orsimilar results will be obtained elsewhere. Customers attempting to adapt thesetechniques to their own environments do so at their own risk.

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

Any performance data contained in this document was determined in a controlledenvironment, and therefore, the results that may be obtained in other operatingenvironments may vary significantly. Users of this document should verify theapplicable data for their specific environment.


This document contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples containthe names of individuals, companies, brands, and products. All of these namesare fictitious and any similarity to the names and addresses used by an actualbusiness enterprise is entirely coincidental.

Reference to PTF numbers that have not been released through the normaldistribution process does not imply general availability. The purpose of includingthese reference numbers is to alert IBM customers to specific information relativeto the implementation of the PTF when it becomes available to each customeraccording to the normal IBM PTF distribution process.

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

The following terms are trademarks of other companies:

Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli,and Tivoli Enterprise are trademarks or registered trademarks of Tivoli SystemsInc., an IBM company, in the United States, other countries, or both. In Denmark,Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S.

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

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

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

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

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

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

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks ownedby SET Secure Electronic Transaction LLC..

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

IBM � VTAMRACF XTRS/6000 3090S/390 400Seascape LotusSP NotesSystem/390


Appendix I. Related publications

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

I.1 IBM Redbooks

For information on ordering these publications, see “How to get IBM Redbooks”on page 155.

• DB2 UDB Server for OS/390 Version 6 Technical Update, SG24-6108

• DB2 UDB for OS/390 Version 6 Performance Topics, SG24-5351

• DB2 Server for OS/390 Version 5 Recent Enhancements - Reference Guide,SG24-5421

• DB2 UDB for OS/390 and Continuous Availability, SG24-5486

• OS/390 Workload Manager Implementation and Exploitation, SG24-5326

• WOW! DRDA Supports TCP/IP: DB2 Server for OS/390 and DB2 UniversalDatabase, SG24-2212

• The Universal Connectivity Guide to DB2, SG24-4894

• IBM Enterprise Storage Server - SG24-5465

• Implementing the Enterprise Storage Server in Your Environment, SG24-5420

• IBM Enterprise Storage Server Performance Monitoring and Tuning Guide,SG24-5656

I.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMsbutton at ibm.com/redbooks for information about all the CD-ROMs offered,updates and formats.

I.3 Siebel documentation

These Siebel publications (shipped with the product) are useful informationsources:

• Siebel Installation Manual

CD-ROM Title Collection KitNumber

IBM System/390 Redbooks Collection SK2T-2177IBM Networking Redbooks Collection SK2T-6022IBM Transaction Processing and Data Management Redbooks Collection SK2T-8038IBM Lotus Redbooks Collection SK2T-8039Tivoli Redbooks Collection SK2T-8044IBM AS/400 Redbooks Collection SK2T-2849IBM Netfinity Hardware and Software Redbooks Collection SK2T-8046IBM RS/6000 Redbooks Collection SK2T-8043IBM Application Development Redbooks Collection SK2T-8037IBM Enterprise Storage and Systems Management Solutions SK3T-3694




• Siebel Release Notes

• Security Considerations for Siebel on DB2/390, white paper

I.4 Other resources

These publications are also relevant as further information sources:

• DB2 UDB for OS/390 - Installation Guide Version 6, GC26-9008

• DB2 for OS/390 Performance on IBM Enterprise Storage Server, REDP0026

I.5 Referenced Web sites

These Web sites are also relevant as further information sources:

• http://www.siebel.com/ Siebel home page

• http://www.ibm.com/solutions/erp/ IBM ERP Web page

• http://www.software.ibm.com/data/db2/os390/ DB2 for OS/390 Web page

• http://www.software.ibm.com/data/db2/db2connect/ DB2 Connect Web page

• http://www-4.ibm.com/software/data/db2/db2tech/indexsvc.html

ftp://ftp.software.ibm.com/ps/products/db2/fixes/english-un/siebel DB2Connect FixPack Web page


How to get IBM Redbooks

This section explains how both customers and IBM employees can find out about IBM Redbooks, redpieces, andCD-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 readredpieces and download additional materials (code samples or diskette/CD-ROM images) from this Redbookssite.

Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few chapters willbe published this way. The intent is to get the information out much quicker than the formal publishing processallows.

• E-mail Orders

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

• Telephone Orders

• Fax Orders

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

In United StatesOutside North America

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

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

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

United States (toll free)CanadaOutside North America

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

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

IBM Intranet for Employees



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



mailto:[email protected]

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

http://w3.ibm.com/




IBM Redbooks fax order formPlease send me the following:

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

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to


Abbreviations and acronyms

ACD Automatic Call Distributor

CAE Client Application Enabler

CTI Computer telephonyintegration

DB2 Database 2

EAI Enterprise ApplicationInterface

EE Enterprise Edition (DB2Connect)

EIM Enterprise IntegrationManager

EIS Executive Information System

ESS Enterprise Storage Server

IBM International BusinessMachines Corporation

ITSO International TechnicalSupport Organization

OLE Object Linking and Embeding

RTC Run-Time Client

PE Personal Edition (DB2Connect)

SES Siebel Enterprise Server

SSL Secure Sockets Layer

© Copyright IBM Corp. 2000
157

Index

Aaccess path selection adjustment 110administration of DB2 83

database design 83buffer pools 85database objects 83EDM pool size 85free space 84locking 85

database maintenance 86database reorganization 86statistics gathering 86

database recovery 86disaster recovery 87point-in-time recovery 87recovery to currency 86

installation 83APARs (V6) 97application framework 2

admin services 4application integration services 3business processes services 3core services 3design time tools 3integration services 3

application servers 8file system 10gateway server 9

name server 9resonate central dispatch 9

Siebel Enterprise Server 8Siebel Server 9

architecture 1application services 2data services 2presentation services 1

authorizations 17

Bbuffer pools 18, 56, 85, 105built-in functions 104

Cclient 5

configuration 33, 116connected client 6mobile client 7

handheld client 8thin client 6

HTML client 6Java client 7thin client for Windows 7wireless client 7

conditional restart 94configurations 4

three-tier 5

© Copyright IBM Corp. 2000

two-tier 4connected client 59consistent restart 113, 114correlated subquery 110

Ddata spaces 105database connections 21

DB2 Connect EE 21DB2 Run-Time client 34DDF 21testing the connections 35

database server 10scripts 54

databases 57, 131DB2 Connect 21, 115

bind packages 81Enterprise Edition 21Personal Edition 115

DB2 customization 18DB2 features 97

225 tables 104access path selection 110built-in functions 104correlated subquery 110data spaces 105declared temporary table 108defer defining data sets 109DSMAX 103dynamic statement caching 98identity columns 107index screening 99log suspend/resume 109online system parameters 111ORDER BY 98outer join 101scrollable cursors 111self-referencing subselect 111stored procedures 98triggers 104uncorrelated subquery 101unmatched column join for VARCHAR 100update with subselect 106

DB2 Run-Time client 34DB2 utilities 112

consistent restart 113, 114COPY 112fast log apply 112image copies 114LOAD 112REBUILD index 112REORG 112, 113, 114reuse feature 114RUNSTATS 113statistics history 114

DDF 21, 118, 123, 124declared temporary tables 108

159

defer defining data sets 109disaster recovery 86DSMAX 103DSNTIJUZ 123DSNZPARM 19, 125dynamic statement caching 97

EEDM pool 106EIM 69Enterprise Storage Server 147

Ffast log apply 112file system 10, 39, 59

Ggateway server 9, 41

Hhandheld client 8hiperpools 105HTML client 6

Iidentity columns 107importing data 69index screening 99installation of Siebel 2000 15, 37

on client PC 59on NT 37on OS/390 56

interface tables 70ITSO system configurations 15

JJava client 7

LLOAD 114location name 22log suspend/resume 109

Mmobile client 7

Nname server 41

OOBDC 119online system parameters 111ORDER BY clause 98outer join 101

Ppassword

change 82encryption 82

point-in-time recovery 87considerations 93techniques 88

application programs 88conditional restart 90DB2 utilities 89dump/restore utilities 90suspension of DB2 updating 92

port number 22preparing the system 16

DB2 OS/390 environment 16NT environment 16Siebel environment 16

QQUIESCE 91

RRACF 124recovery to currency 86REORG 113repository 59RRS 139

SS/390 strengths 10

DB2 12Enterprise Storage Server 13OS/390 11

scrollable cursors 111security 77

application 77data 77data transmission 82DB2 79External Security Adapter 78OS/390 79

seed data 58self-referencing subselect 111service owner 37Siebel Enterprise Server 45Siebel Server 8, 9, 45statistics history 114storage groups 57, 131stored procedures 20, 98, 139SYS1.LOCAL.VTAMLST 123SYS1.TCPPARMS 124

Ttable spaces 57, 132tables 58, 133TCP/IP 118, 124temporary database 20, 137


temporary table spaces 20, 137thin client for Windows 7three-tier configuration 5triggers 104two-tier configuration 4

Uuncorrelated subquery 97, 101unmatched column join 100unmatched column join for VARCHAR 100update with subselect 106user catalog 19user ID 17, 26, 56

VVTOC 19

Wwireless client 7WLM 142

161


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 theRedbook, 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 [email protected]

Document NumberRedbook Title

SG24-5953-00Siebel 2000 Database Implementation on OS/390 Using NT Siebel Servers

Review

What other subjects would youlike to see IBM Redbooksaddress?

Please rate your overallsatisfaction:

O Very Good O Good O Average O Poor

Please identify yourself asbelonging to one of the followinggroups:

O CustomerO Business PartnerO Solution DeveloperO IBM, Lotus or Tivoli EmployeeO None of the above

Your email address:The data you provide here may beused to provide you with informationfrom IBM or our business partnersabout our products, services oractivities.

O Please do not use the information collected here for future marketing orpromotional contacts or other communications beyond the scope of thistransaction.

Questions about IBM’s privacypolicy?

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



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


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

(0.2”spine)0.17”<->

0.473”90<->

249pages

Siebel2000D

atabaseIm

plementation

onO

S/390U

singN

TSiebelServers

Siebel2000D

atabaseIm

plementation

onO

S/390U

singN

TSiebelServers

®

SG24-5953-00 ISBN 0738418730

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts fromIBM, 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

Siebel 2000 DatabaseImplementation on OS/390Using NT Siebel Servers

Siebel 2000 architecture using DB2 database on OS/390

Siebel two- and three-tier implementations on NT and S/390 servers

Siebel database setup with DB2 for OS/390

This IBM Redbook will help you install and customize Siebel 2000 V6.1 applications for OS/390 V2.8 using DB2 V6.1. It is based on the installation experiences gained while installing Siebel 2000 at the IBM ITSO in Poughkeepsie, New York.The book contains an overview of Siebel Systems and their two- and three-tier architectures in the OS/390 environment. It describes the connections to the Siebel-DB2 database server on S/390, as well as the customization needed for OS/390 and DB2. It provides installation guidelines to set up the Siebel applications on NT servers and the database on the S/390 server. The book gives recommendations on security and database administration issues, as well as the DB2 features which specifically benefit Siebel. An example of importing data to the Siebel-DB2 database, using Siebel’s Enterprise Integration Manager, is also provided. This IBM Redbook will be especially useful for those installing Siebel on OS/390 for the first time.




siebel 2000 database implementation on os/390 … siebel 2000 database implementation on os/390...

Documents