Baan Applications on OS/390 Implementation ... - IBM Redbooks

<strong>Baan</strong> <strong>Applications</strong> on OS/390
Implementation Experiences
Kathryn Arrell, Lou Doran, Lee Siegmund, Jeff Wiese
International Technical Support Organization
http://www.redbooks.ibm.com
SG24-5452-00

International Technical Support Organization
<strong>Baan</strong> <strong>Applications</strong> on OS/390
Implementation Experiences
October 1999
SG24-5452-00

Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix B, “Special Notices” on page 91.
First Edition (October 1999)
This edition applies to BAAN IV and <strong>Baan</strong>ERP <strong>Applications</strong> with DB2 V5.1 for use with OS/390 V2R6.
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
522 South Road
Poughkeepsie, New York 12601-5400
When you send information to IBM, you grant IBM anon-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1999. All rights reserved.
Note to U.S. Government Users —Documentation related to restricted rights —Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Chapter 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Understanding the License Process . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 <strong>Baan</strong>'s Support Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Understanding the Error Logs . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Points to Consider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2. Creating Additional <strong>Baan</strong> Users . . . . . . . . . . . . . . . . . . . . . 7
2.1 Setting Up Five Training User IDs . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Within RACF on OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Within DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3 Within UNIX Services for OS/390 . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Within <strong>Baan</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.5 Uppercase versus Lowercase User IDs . . . . . . . . . . . . . . . . . . 19
2.2 Setting Up User IDs for Production . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 DB2 Secondary Authid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Setting Up Privileges for End Users . . . . . . . . . . . . . . . . . . . . 22
2.2.3 How to Handle Expiration of Passwords . . . . . . . . . . . . . . . . . . 23
Chapter 3. Moving HFS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Allocation of the HFS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Creating the Mount Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Mounting the HFS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Copying the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Removing the Old Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapter 4. Setting Up Process Manager (PM) . . . . . . . . . . . . . . . . . . . 31
4.1 Process Manager Considerations . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Problems Encountered with PM in BPAERR.LOG . . . . . . . . . . . . . . . 32
4.2.1 Address Already in Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Running Out of HEAP Storage Message in the BPAERR.LOG . . . . . 32
4.2.3 Unable to Log On with BW Client but Able to with BA Client . . . . . 32
Chapter 5. Post-Installation Tuning . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1 Putting Modules in the LPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1 Putting Application Objects in Shared Memory . . . . . . . . . . . . . 34
5.2 Changing the Shared Memory Parameters . . . . . . . . . . . . . . . . . . 34
5.3 Small db2_storage File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 REBIND the Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Break Up the HSF File Systems into Smaller File Systems . . . . . . . . . 36
5.6 Change the Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.7 RMF Analysis for CPU and DISK . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.8 Setting Up Process Manager and Starting the PM Daemon . . . . . . . . 36
5.9 Putting the tmp File in Memory . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.10 Ongoing Monitoring and Tuning . . . . . . . . . . . . . . . . . . . . . . . . 36
© Copyright IBM Corp. 1999 iii

iv <strong>Baan</strong> on OS/390 Implementation Experiences
Chapter 6. Creating a New <strong>Baan</strong> Company . . . . . . . . . . . . . . . . . . . . . 37
6.1 Creating the db2_storage File . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Creating the DB2 DDL and Granting Privileges . . . . . . . . . . . . . . . . 39
6.3 Using <strong>Baan</strong> Tools to Load Data to the New Company . . . . . . . . . . . . 44
6.3.1 Create the Sequential Dump . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4 Running the <strong>Baan</strong> Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.5 RUNSTATS JCL - Long Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapter 7. Migrating and Copying <strong>Baan</strong> Company Data . . . . . . . . . . . . . 49
7.1 Reducing the Time to Move a Company . . . . . . . . . . . . . . . . . . . . 49
7.2 Problem with Creator ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 8. Backup and Recovery of <strong>Baan</strong> DB2 Databases . . . . . . . . . . . . 59
8.1 User's Primary Recovery Objectives . . . . . . . . . . . . . . . . . . . . . . 59
8.2 DB2/<strong>Baan</strong> IV Point-in-Time Recovery Overview . . . . . . . . . . . . . . . . 59
8.2.1 Point-In-Time Recovery Preventive Measures . . . . . . . . . . . . . . 60
8.2.2 Point-In-Time Recovery Techniques . . . . . . . . . . . . . . . . . . . . 60
8.3 User's Point-in-Time Recovery Strategy . . . . . . . . . . . . . . . . . . . . 62
8.4 User's Recovery to Currency Strategy . . . . . . . . . . . . . . . . . . . . . 63
8.5 User's Disaster Recovery Strategy . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 9. Migration to a New <strong>Baan</strong>IVc Porting Set . . . . . . . . . . . . . . . 65
9.1 Pre-Installation Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.1.1 Plan for Some Downtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.2 Migration and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.2.1 Connection Manager Changes . . . . . . . . . . . . . . . . . . . . . . . 67
9.2.2 Process Manager Changes . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.2.3 DB2 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.2.4 OS/390 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.5 <strong>Baan</strong> Runtime HFS Changes . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.6 License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.2.7 Variable to Be Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Chapter 10. Using Multiple Databases/LPARs . . . . . . . . . . . . . . . . . . . 73
10.1 Using One DB2 Subsystem (One System/LPAR) . . . . . . . . . . . . . . . 73
10.2 Using Two LPARs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.2.1 Using RVA and SnapShot to Clone a Second LPAR . . . . . . . . . . 74
10.2.2 Sample JCL to Produce the Snap and Cloned System . . . . . . . . 76
10.2.3 Rename the Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Appendix A. Sample Jobs and Script Used with <strong>Baan</strong> <strong>Applications</strong> . . . . . . 85
A.1 Procedures to Start and Stop <strong>Baan</strong> from the Console . . . . . . . . . . . . 85
A.2 Script to Convert a File from EBCDIC to ASCII . . . . . . . . . . . . . . . . 85
A.3 Script to Determine the Size of Files to Load with bdppost . . . . . . . . . 86
A.4 Script to Determine If the HFS Is Almost Full . . . . . . . . . . . . . . . . . 86
A.5 Script to Remove Idle Users . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix B. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Appendix C. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.1 International Technical Support Organization Publications . . . . . . . . . 93
C.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.3 Other IBM Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
C.4 <strong>Baan</strong> Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
IBM Redbook Fax Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Contents v

vi <strong>Baan</strong> on OS/390 Implementation Experiences

Figures
1. <strong>Baan</strong> Tools Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Validation of <strong>Baan</strong> License . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Minimum Information Needed . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Sample .bpaprofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Choose Maintain User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Choose Insert to Add a <strong>Baan</strong> User . . . . . . . . . . . . . . . . . . . . . . 15
7. Enter the Environment Data to Add a <strong>Baan</strong> User . . . . . . . . . . . . . . 16
8. Enter the Authorization Data to Add a <strong>Baan</strong> User . . . . . . . . . . . . . . 17
9. Enter the Miscellaneous Data to Add a <strong>Baan</strong> User . . . . . . . . . . . . . 18
10. Allocation HFS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Mount Temporary HFS File . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. Mount New HFS File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13. Example .bpaprofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Modifications to the Connection Exit Code . . . . . . . . . . . . . . . . . . 32
15. JCL to LinkEdit into the Library for LPA . . . . . . . . . . . . . . . . . . . . 34
16. JCL to Create Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
17. <strong>Baan</strong> Tools Menu to Request Sequential Dumps . . . . . . . . . . . . . . 45
18. Creating Sequential Dump of Table . . . . . . . . . . . . . . . . . . . . . . 46
19. Create Table from Sequential Dump . . . . . . . . . . . . . . . . . . . . . 46
20. Job to Execute RUNSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
21. JCL to Create Database, Tablespaces & Execute Grant Statements . . . 51
22. JCL to Rebuild the Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
© Copyright IBM Corp. 1999 vii

viii <strong>Baan</strong> on OS/390 Implementation Experiences

Preface
This redbook describes the post-installation actions that should be taken after
the initial installation of the <strong>Baan</strong> <strong>Applications</strong> for OS/390. It is based on the
experiences gained while installing <strong>Baan</strong> IV and <strong>Baan</strong>ERP <strong>Applications</strong> with DB2
V5.1 for use with OS/390 V2R6 at the ITSO in Poughkeepsie. It also contains
information from early customer installations and IBM lab sites. This redbook
will help you customize <strong>Baan</strong> IV or <strong>Baan</strong>ERP <strong>Applications</strong> for OS/390 with DB2.
<strong>Baan</strong> requires a certified <strong>Baan</strong> installer to install <strong>Baan</strong> <strong>Applications</strong> for OS/390.
This redbook is not meant to take the place of a trained consultant to do the
installation. Instead, it provides S/390 system programmers with detailed
information about the installation process, particularly how it relates to OS/390.
The Team That Wrote This Redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization Poughkeepsie
Center.
Kathryn Arrell is an ERP Specialist with the International Technical Support
Organization, Poughkeepsie Center. Before joining ITSO, Kathryn worked in
RS/6000 Marketing in IBM Canada.
Lou Doran is an ERP Solutions Specialist with the North American ERP
Competency Center in Philadelphia. Before joining the ERP Group, Lou worked
in Network Marketing and has a large systems background.
Lee Siegmund is a Consulting Marketing Support Representative from the DB2
Relational Support Unit of the Dallas Systems Center. He has worked at IBM for
30 years. For the past 16 years, he has supported DB2 starting with Version 1
Release 1 to the current Version 5. His areas of expertise include high
availability, recovery, data sharing, and application design. He has presented
DB2 availability topics to user groups around the world.
Jeff Wiese is a Market Support Representative in the US. He joined IBM in 1973
and was a PSR, Instructor, SE, and Large Systems Marketing Specialist before
joining the S/390 New Technology Center in Poughkeepsie, New York.
Thanks to the following people for their invaluable contributions to this project:
Richard Conway
Bill Ogden
Bob Haimowitz
Vasilis Karras
International Technical Support Organization, Poughkeepsie Center
Erik de Jeu
IBM <strong>Baan</strong> International Competency Center
Vicky Pollien
Jason Heim
Steve Henkels
Richard Ko
© Copyright IBM Corp. 1999 ix

Comments Welcome
Brad Forrest
Mythili Venkatakrishnan
IBM S/390 Division, Poughkeepsie
Mary Sue Record
IBM Boblingen
Phu Trinh
IBM Global Services
Michel Chartier
IBM Canada
Herve Sabrie
Jean-Jacques Noguera
Laurence Nicolas
IBM Parallel Solution Support Center, Montpellier
Dan Barr
Renza Klammer
Jos Odijk
Charles Saitta
<strong>Baan</strong>
Claude Bertin
James Gordon
Margaret Hum
Warren Tarasuk
Mohammed Mestari
Brian Pritchard
CAE
Val Chavez
Frank Snyder
Chris Sutter
Lawson Products
x <strong>Baan</strong> on OS/390 Implementation Experiences
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
Fax the evaluation form found in “ITSO Redbook Evaluation” on page 101 to
the fax number shown on the form.
Use the online evaluation form found at http://www.redbooks.ibm.com/
Send your comments in an Internet note to redbook@us.ibm.com

Chapter 1. Overview
This redbook is based on experiences gained from early customers' use of <strong>Baan</strong>
<strong>Applications</strong> on S/390. It assumes that the initial installation of Company 000 has
been completed, as described in the <strong>Baan</strong> publications <strong>Baan</strong> IV - Installation
Guide for <strong>Baan</strong> IV on OS/390 UNIX System Services, and <strong>Baan</strong>ERP - DB2
Installation Guide for <strong>Baan</strong>ERP, and the redbooks Installing <strong>Baan</strong> IV <strong>Applications</strong>
on OS/390, SG24-5334, and Installing <strong>Baan</strong>ERP <strong>Applications</strong> on OS/390,
SG24-5440.
It describes the OS/390 and DB2 tasks that may have to be completed to run
<strong>Baan</strong> <strong>Applications</strong> on OS/390. It does not contain information on how to use the
<strong>Baan</strong> Tools; rather it describes how to prepare the environment for the <strong>Baan</strong>
Tools for systems and database administration functions.
These tasks apply to both <strong>Baan</strong> IV and <strong>Baan</strong>ERP installations. The areas
covered are:
RACF and DB2 actions when adding <strong>Baan</strong> users
Moving OS/390 hierarchical file systems
Process Manager considerations
Some post-installation tuning considerations
DB2 layouts for creating new companies
DB2 Backup and Recovery processes
Migrating to a new Porting Set
1.1 Understanding the License Process
Setting up test, development, and production LPARs and DB2 subsystems
<strong>Baan</strong> enforces its licensing with a license daemon. This presents challenges to
the S/390 community, which is not generally accustomed to these processes and
procedures. The following describes some of the situations and resulting
activities that we encountered.
Note on accelerators (multiple Bshells for a batch run)
If you plan to use accelerators (multiple Bshells to implement parallelism) on
a batch run (batch is really a disconnected online user), remember to count
those when developing the user count for the license or you might exceed
the licensed maximum and be denied execution.
After the completion of the installation process, a message appears when
logging on to <strong>Baan</strong> <strong>Applications</strong>. It states that the initial license will expire in 28
days. During this time, the <strong>Baan</strong> Consultant will complete the license validation
process.
This license must be revalidated when certain changes are made, such as:
The system is moved to a new CPU with a different hostname.
The level of the operating system is upgraded.
© Copyright IBM Corp. 1999 1

The level of the <strong>Baan</strong> <strong>Applications</strong> is upgraded.
System maintenance is applied that results in a new / directory (the root
directory) on UNIX Services.
The validation process should be understood and documented, so if you have to
revalidate the license quickly you can do so, and not affect the availability of the
system to the end users.
<strong>Baan</strong> can provide you with a quick guide on how to do the validation. The basic
steps are:
1. Send a request to <strong>Baan</strong> requesting a new license.
2. Log on to <strong>Baan</strong> as bsp, go to <strong>Baan</strong> Tools and make the following menu
selections as shown in Figure 1:
Software Validation-->
Requested System Configuration
Figure 1. <strong>Baan</strong> Tools Menu
2 <strong>Baan</strong> on OS/390 Implementation Experiences
Then you are asked to enter a password. This is provided in the <strong>Baan</strong>
documentation.
Then, enter information from the <strong>Baan</strong> license code report (packages
information and dates as shown in Figure 2 on page 3). Click Save.

Figure 2. Validation of <strong>Baan</strong> License
3. Prepare the file to send to <strong>Baan</strong>. Again go to <strong>Baan</strong> Tools and make the
following selections:
Print Requested System Configuration-->
Enter password-->
Enter information for the <strong>Baan</strong> license code report-->
Choose print to file
Enter the file name (on UNIX Services on OS/390, for example,
/u/bsp/license).
4. Send the information in this file to <strong>Baan</strong> by fax or e-mail.
5. After receiving the Validation Key back, go to <strong>Baan</strong> Tools and make the
following menu selections, as shown in Figure 1 on page 2:
Software Validation-->
Requested System Configuration-->
Security Code/Validation Key-->
Enter Password-->
Enter Validation Keys-->
Exit and Save
6. Log on as root and select:
Tools
Software Validation-->
Validate Tools Set-->
Exit and Save
7. Log on as bsp and select:
Tools
Software Validation-->
Configure Application
Execute by typing Y
Exit and Save
Chapter 1. Overview 3

As you can see, the validation process takes several steps, including sending
information to and receiving information from <strong>Baan</strong> twice. Make sure you have
documentation and plans in place for this process.
Points to Note
1.2 <strong>Baan</strong>'s Support Structure
4 <strong>Baan</strong> on OS/390 Implementation Experiences
Each time you select Requested System Configuration, the validation code is
changed, so you cannot redo this function once you have sent the license file
to <strong>Baan</strong>.
Entering the date field requires that you get the date field in input mode. To
do this, choose GROUP, then GO TO, and then tab to the date field. When
the date field is ready for input, choose Tools, then Calendar to enter the date
to ensure it is in the correct format.
Take care when entering the long string of numbers for the validation code
The following information is the result of experiences at <strong>Baan</strong>'s North American
support center, which works much like the IBM support center. A typical
scenario is as follows:
The customer uses a <strong>Baan</strong> Web site to log a call and obtain a case number. The
case is used the same way IBM uses its Problem Management Record (PMR).
The <strong>Baan</strong> case, however, does not expire and remains in their data base for
future reference.
Although opening a case number can be done by calling <strong>Baan</strong>'s support center,
Web use is encouraged. Besides opening a case, the Web interface can be used
to check on and update a problem's status. Additionally, the Web interface can
access all kinds of support-related information, such as Product Advisory
Reports, and be used to download <strong>Baan</strong> software updates. Customers may
search <strong>Baan</strong> Support's knowledge base to resolve many of their problems or
questions.
Severity is designated 10, 20, 30, or 40. Severity 10 is a “production system
down” on a production system (<strong>Baan</strong> enforces this criteria, that is, a severity 10
will never be assigned to a test or training system), whereas severity 40 would
be a “simple” question.
Obviously, <strong>Baan</strong> support should be the first point of contact for <strong>Baan</strong> problems.
DB2 and system problems (OS/390 UNIX System Services) that appear to be
related to the <strong>Baan</strong> environment (Connection Manager, Process Manager, SQL
errors on <strong>Baan</strong> tables and so forth) should also use <strong>Baan</strong> support as the first
point of contact. Of course, if the problem is clearly in IBM's arena, use the IBM
support center as the first point of contact.
Depending upon the nature of the problem, different <strong>Baan</strong> locations take
responsibility for the case, for example the A & D (Aerospace and Defense)
extensions are supported in Seattle, so support for problem resolution comes
from that location.

1.3 Understanding the Error Logs
1.4 Points to Consider
As you go through the installation process and while you are running <strong>Baan</strong>
applications, you should understand where the error logs are stored and what
information they contain that might help you in debugging problems. Some of
the useful logs are:
cmx.log
This is stored in /tmp unless you have specified otherwise in the cmx.conf
file. This can provide information about DB2 requests and messages.
Install logs
There are several logs that track progress through the installation process
such as install6.1.log (for <strong>Baan</strong> IV), or install6.2.log (for <strong>Baan</strong>ERP). These are
stored in the $BSE/log directory.
Other logs
This is a list of the logs in $BSE/log after the installation of <strong>Baan</strong>ERP. When
you have a problem, use the command ls -alt. This sorts them in time
sequence so you can review the latest log entries. You can use the oedit
command to read the entire log or use the tail command to read only the
last few lines. For example, tail -100 log.error will list the last 100 lines of
the log.error file.
baanerp.stderr log.db2 log.oiex1288
baanerp.stdout log.db2.mesg log.pdaemon6.2
bshell.error6.2 log.db2_maint6.2 log.sh_server
log.bdbreconfig6.2 log.error log.shmmanager6.2
log.binput6.2 log.install.iex1288 log.shmtimer6.2
log.brand6.2 log.install6.2 log.shmvalues6.2
log.bshell log.ipc_boot6.2 log.sort6.2
log.bshell.inst log.licd6.2
log.compress6.2 log.oiex1287
Some of the key points to consider for your implementation are:
Support contacts
You will require support for:
− IBM Hardware and Software
− <strong>Baan</strong> Tools
− <strong>Baan</strong> <strong>Applications</strong>
Set up the problem tracking process and the escalation process so you will
be able to monitor and solve your problems in a timely fashion.
HFS Layouts (for example, /baanERP/bse and /baanERP/dict)
DB2 implementation
− Tables, tablespaces, amd database organization
− DB2 Stogroups
− Buffer pool usage
− Logs and archives
− Image copies
− Complete backup for point-in-time recovery
Chapter 1. Overview 5

Security
− DB2
− RACF
− <strong>Baan</strong>
Connectivity
− USS access
− ISPF access
Number of <strong>Baan</strong> environments
− How many
− Purpose - production, test, QA
− Data migration between environments
− VRC constructs
Access to legacy data
6 <strong>Baan</strong> on OS/390 Implementation Experiences
− Interface to be used
− Data migration
Some of these topics are discussed in this redbook. More information and
guidance may be obtained from the IBM ERP Competency Centers.

Chapter 2. Creating Additional <strong>Baan</strong> Users
As you progress from the installation phase to the testing and production phase,
one of the activities that the Database Administrator will have to perform is to
create additional <strong>Baan</strong> user IDs.
In this regard, you will have to make decisions on how to handle the security
aspects of RACF and DB2. This chapter presents two approaches:
1. The first is a simple approach based on the steps one customer used to
create five training user IDs.
2. The second approach details how the customer set up user IDs for
production considering the security aspects.
2.1 Setting Up Five Training User IDs
This approach uses the group BSPGRP, which is the same group that was used
for the user IDs BSP and ROOT. It sets up the user IDs with no expiration date,
and grants DBADM privileges on all tables.
The following steps must be executed to create additional <strong>Baan</strong> user IDs:
1. Add the user ID to OS/390 RACF (ensuring DB2 privileges are granted).
2. Create a home directory in $BSE/home.
For example, /baanIV/bse/home/baan0.
3. Add the user ID to the db2_users file in the $BSE/lib/db2 directory.
4. Create a file in directory $BSE/lib/user named uuserid.
For example, /baanIV/bse/lib/user/ubaan0.
5. Issue the DB2 grant command to give the user ID access to DB2.
6. Set up the Process Manager profile and the port number of the end-user
workstation (if using Process Manager).
The following sections show how to perform each of these steps, by describing
in detail how one customer created five user IDs: baan0, baan1, baan2, baan3,
baan4. Before performing these steps yourself, however, you must first ensure
that execute authority has been granted to “public” for the CMXPLAN.
2.1.1 Within RACF on OS/390
The user ID you want to create should be an OMVS user that is part of a group
that has access to DB2. This group must be in the /etc/alias file. As previously
mentioned, this example uses BSPGRP, the same group that was used for BSP
and ROOT during the installation. Note that the OMVS RACF segment must
specify a home directory. This is the directory that must contain the user's
.profile. A .bpaprofile may exist if the Process Manager is used.
There are two ways to create OMVS user IDs for RACF:
1. Use the TSO command option (option 6 of ISPF). Issue the command:
ADDUSER BAAN0 DFLTGRP(BSPGRP) OWNER(ROOT) OMVS(UID(131)
HOME('/baanIV/bse/home/baan0') PROGRAM('/bin/sh'))
© Copyright IBM Corp. 1999 7

Then, to change the default password to a permanent one and extend the
interval, enter the commands:
PASSWORD USER(baan0) NOINTERVAL ALU BAAN0 PASSWORD(BAAN0) NOEXPIRED
Repeat these three commands for each of the users you want to create. In
our case, we repeated this for baan1, baan2, baan3 and baan4,
Each user ID has a unique UID and home directory. The home directory and
the program must be in lower case. You do not have to give TSO access to
<strong>Baan</strong> users.
<strong>Baan</strong> users log on through a BW client. As the BW client cannot handle the
RACF message that the password has expired, we changed the default 30
interval to NOINTERVAL or to INTERVAL(365). See 2.2.3, “How to Handle
Expiration of Passwords” on page 23, for another way to handle expiring
passwords.
2. Use JCL to create five user IDs for OMVS access.
Following is a sample of JCL that was used to create user IDs. This JCL
does not include a password parameter. The default password is the same
as the DFLTGRP, so in our case it is BSPGRP.
Note that in the JCL stream there is an ALU command for each user. This
command will change the default password to something unique for each
user. In our case, the password was set to be the same as the user ID.
Attention
8 <strong>Baan</strong> on OS/390 Implementation Experiences
Each user ID has a unique UID and home directory. You do not have to
give TSO access to <strong>Baan</strong> users.

IBMUSERF JOB (0513),'SOFT-IBM',
// TIME=1440,
// NOTIFY=IBMUSER,
// REGION=0M,
// CLASS=A,
// MSGCLASS=X,
// MSGLEVEL=(1,1)
//* INSTALLATION OS/390 V2R6 (BAAN)
//*
//JOBLIB DD DISP=SHR,DSN=SYSP.CUSTOM.TS260006.LOADLIB
//*
//*--------------------------------------------------------------------
//* DOC: DEFINE USERIDS FOR TSO AND/OR OMVS
//*
//* MRC: THE MAXIMUM EXPECTED RETURN CODE IS: 0
//*--------------------------------------------------------------------
//RACFDEFI EXEC PGM=IKJEFT01
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR
//BRODCAST DD DSN=SYS1.BRODCAST,DISP=SHR
//SYSTSIN DD *
/* */
/* ADD A USERID TO RACF WITH AN OMVS SEGMENT */
/* */
ADDUSER BAAN0 DFLTGRP(BSPGRP) OWNER(ROOT) OMVS(UID(131) -
HOME('/baanIV/bse/home/baan0') -
PROGRAM('/bin/sh'))
LISTUSER BAAN0 OMVS
ADDUSER BAAN1 DFLTGRP(BSPGRP) OWNER(ROOT) OMVS(UID(132) -
HOME('/baanIV/bse/home/baan1') -
PROGRAM('/bin/sh'))
LISTUSER BAAN1 OMVS
ADDUSER BAAN2 DFLTGRP(BSPGRP) OWNER(ROOT) OMVS(UID(133) -
HOME('/baanIV/bse/home/baan2') -
PROGRAM('/bin/sh'))
LISTUSER BAAN2 OMVS
ADDUSER BAAN3 DFLTGRP(BSPGRP) OWNER(ROOT) OMVS(UID(134) -
HOME('/baanIV/bse/home/baan3') -
PROGRAM('/bin/sh'))
LISTUSER BAAN3 OMVS
ADDUSER BAAN4 DFLTGRP(BSPGRP) OWNER(ROOT) OMVS(UID(135) -
HOME('/baanIV/bse/home/baan4') -
PROGRAM('/bin/sh'))
LISTUSER BAAN4 OMVS
PASSWORD USER(baan0) NOINTERVAL
PASSWORD USER(baan1) NOINTERVAL
PASSWORD USER(baan2) NOINTERVAL
PASSWORD USER(baan3) NOINTERVAL
PASSWORD USER(baan4) NOINTERVAL
ALU BAAN0 PASSWORD(BAAN0) noexpired
ALU BAAN1 PASSWORD(BAAN1) noexpired
ALU BAAN2 PASSWORD(BAAN2) noexpired
ALU BAAN3 PASSWORD(BAAN3) noexpired
ALU BAAN4 PASSWORD(BAAN4) noexpired
/* ALU is Alter user */
/* LU is List User */
lu baan0
lu baan1
lu baan2
lu baan3
lu baan4
//NOTOK EXEC PGM=CPPMAXRC,COND=((0,GE,RACFDEFI),(4000,LT))
Chapter 2. Creating Additional <strong>Baan</strong> Users 9

2.1.2 Within DB2
Privileges can be granted to <strong>Baan</strong> users in one of the following ways:
1. You can grant DBADM privileges to each <strong>Baan</strong> user for each database.
2. You can grant SELECT, INSERT, DELETE, UPDATE, or ALL privileges to each
of the tables to each <strong>Baan</strong> user ID.
3. Set up all users (including BSP and ROOT) in BSPGRP and grant DBADM to
BSPGRP to all databases, and set up DB2 secondary authid exits.
4. Set up BSPRGRP for BSP and ROOT only, then create another group, say
BSPUSER, for the end users. Grant ALL to each table that the user
associated with this group will access, and set up DB2 secondary authid
exits.
This option can be further extended to set up several end-user groups, such
as BSPFIN (for financials) and BSPMANF (for manufacturing users).
For the training user IDs we used option 1. We had not set up a secondary
authid, so we granted each <strong>Baan</strong> user ID privileges on each database. The
statements we used for each user were:
GRANT DBADM on DATABASE C000DB1 TO baan0, baan1, baan2, baan3, baan4;
GRANT DBADM on DATABASE C000DB2 TO baan0, baan1, baan2, baan3, baan4;
GRANT DBADM on DATABASE C531DB1 TO baan0, baan1, baan2, baan3, baan4;
GRANT DBADM on DATABASE C731DB1 TO baan0, baan1, baan2, baan3, baan4;
GRANT DBADM on DATABASE C999DB1 TO baan0, baan1, baan2, baan3, baan4;
For option 2, set up the JCL to issue the grant statements for each table as
described in 2.2.2, “Setting Up Privileges for End Users” on page 22.
For option 3, if you have already set up the exits for the DB2 secondary authid,
as shown in 2.2.1, “DB2 Secondary Authid” on page 20, and you have granted
BSPGRP privileges on the DB2 databases you are using, you do not have to
grant privileges to the individual <strong>Baan</strong> user IDs.
For option 4, if you do not want to give the end users DBADM privileges, you can
grant the privileges to each table as shown in 2.2.2, “Setting Up Privileges for
End Users” on page 22.
2.1.3 Within UNIX Services for OS/390
We had to telnet into the UNIX Services for OS/390 and then complete the next
three steps.
10 <strong>Baan</strong> on OS/390 Implementation Experiences
2.1.3.1 Create the Home Directory for Each <strong>Baan</strong> User ID
We created a home directory for each user as specified in the RACF OMVS
segment home directory (for example, /baanIV/bse/home/baan0). Without this,
you cannot successfully log on to the user ID in telnet mode or with the BW
client. We created these directories by completing the following steps:
1. Go to the $BSE/home directory: cd /baanIV/bse/home
2. Create a /home directory for each user:

mkdir baan0
mkdir baan1
mkdir baan2
mkdir baan3
mkdir baan4
2.1.3.2 Create User Profiles
When a user logs on to <strong>Baan</strong> using the BW client, /etc/profile is executed (for
system-wide variables), and then the .profile in the user's home directory is
executed (for user-specific variables). The user's home directory is specified in
the RACF OMVS segment in the ADDUSER command. In our case this was
/baanIV/bse/home/baan0 for the user ID baan0.
The minimum information in the user's .profile in the home directory is shown in
Figure 3.
export _CEE_RUNOPTS="HEAP(17M,1M,ANYWHERE,KEEP),STACK(131072,131072,ANYWHERE,KEEP),
ALL31(ON),LIBSTACK(8),TERMTHDACT(UADUMP)"
export TERM=vt100
export DB2_MVS_SYNTAX=1
export _BPX_SHAREAS=YES
export _BPX_SPAWN_SCRIPT=YES
export PATH=$PATH:/baanIV/bse/bin
export LIBPATH=$LIBPATH:/baanIV/bse/bin
export BSE=/baanIV/bse
export BSE_TMP=$BSE/tmp
Figure 3. Minimum Information Needed
Using the Process Manager: When the <strong>Baan</strong> system has the Process Manager
process running, a user can log on with the BW client to the Process Manager
by placing the following line in the workstation's \windows\services file:
<strong>Baan</strong>Rexec 6000/tcp :Port for Process Manager
Note: This socket number must match the socket number specified in the
/etc/bpa/bpares.cfg file.
When users log on with the Process Manager they will inherit all the variables
set for the user ID which started the Process Manager. In other words, they do
not execute the /etc/profile or .profile profiles in their own home directory. In
our case, the user ID ROOT started the Process Manager so when ROOT logged
on, the /etc/profile and /.profile profiles were executed (the home directory of
root was /). In addition, if a .bpaprofile exists in the user's home directory, it is
also executed. Figure 4 shows a sample .bpaprofile.
Note: Ensure that the HEAP size specified in the profile for the user who started
the Process Manager is large enough for the whole environment. A HEAP size
of 17 MB was not large enough for 36 users, so it was changed to 30 MB.
BSE=/baanIVc/bse
BSE_TMP=/baanIVc/bse/tmp
PATH=$BSE/bin:$PATH
TERM=vt100
DB2_MVS_SYNTAX=1
_CEE_RUNOPTS=HEAP(17M,1M,ANYWHERE,KEEP),STACK(131072,131072,ANYWHERE,KEEP),ALL31(ON),
LIBSTACK(8),TERMTHDACT(UADUMP)
BPX_SHAREAS=YES
LIBPATH=$LIBPATH:/usr/lpp/bpa/lib:/baanIVc/bse/bin
NLSPATH=$NLSPATH:/usr/lpp/cmx/nls/msg/%L/%N:/usr/lpp/bpa/nls/msg/%L/%N
Figure 4. Sample .bpaprofile
Note that there are no quotes in CEE_RUNOPTS and that the underscore is
missing from the BPX variable.
Chapter 2. Creating Additional <strong>Baan</strong> Users 11

Another way you could do this is to set up an executable file that contains these
entries, for example, baanenv in the $BSE/bin directory. Then, the .profile you
put in each user's home directory only needs to contain one line.
. /baanenv
This allows you to make changes to the default profile in one place, not in each
user's home directory.
2.1.3.3 Add the Entries to the db2_users File
You can add the new users to the db2_users file in either of the following ways:
1. Execute the db2_install6.1 script, using the add user option. This will add a
line for each user in the db2_users file, as follows:
BSP:BSP:pDOH9BNtTkv.*3e!&t#

Tools
User Management
General User Data
Maintain User Data
and here we defined our user:
BAAN_User : baan0
System Login : baan0
Name : General_User
User Type : Normal user
Package Combination : B40Sc3 <strong>Baan</strong>_IV_c3_Standard
Company : 000 Standaard_data
Language : 2 English
Application Server :
Startup System :
Startup System 2 :
Startup Program (GUI) : Menu Browser
Startup Desktop Name :
Startup Menu (Ascii) : tt tls 0000m000 General Menu
Then go back to User Management and select Convert User Data to Runtime
Data Dictionary. You just have to fill in the <strong>Baan</strong> user name (we used baan0
in lower case), and press Enter. This created $BSE/lib/user/ubaan0.
2. An alternate way to do this is by using the BW client. We added the baan3
user ID this way.
Select Maintain User Data.
Chapter 2. Creating Additional <strong>Baan</strong> Users 13

Figure 5. Choose Maintain User Data
14 <strong>Baan</strong> on OS/390 Implementation Experiences
You must choose insert mode to be able to add a user.

Figure 6. Choose Insert to Add a <strong>Baan</strong> User
Complete the information in the first tab for Environment.
Chapter 2. Creating Additional <strong>Baan</strong> Users 15

Figure 7. Enter the Environment Data to Add a <strong>Baan</strong> User
16 <strong>Baan</strong> on OS/390 Implementation Experiences
Complete the Authorizations tab.

Figure 8. Enter the Authorization Data to Add a <strong>Baan</strong> User
Complete the fields in the Miscellaneous tab.
Chapter 2. Creating Additional <strong>Baan</strong> Users 17

Figure 9. Enter the Miscellaneous Data to Add a <strong>Baan</strong> User
18 <strong>Baan</strong> on OS/390 Implementation Experiences
Select Save to save the data. This creates the file $BSE/lib/user/ubaan3.
Then go back to User Management and select Convert User Data to Runtime
Data Dictionary.
If you have successfully set up one user ID this way, you need to repeat the
process for other user IDs that need the same access.
3. A third alternative is to copy an existing file.
Issue the following commands:
cd baanIV/bse/lib/user
cp ubaan3 ubaan4
vi ubaan4 (postion the cursor to the 3 in the second line
to replace the userid baan3 with baan4)
r
4
:wq!
We created the ubaan4 file this way rather than by using the <strong>Baan</strong> tools, since
the baan3 user ID and the baan4 user ID have the same characteristics.

2.1.5 Uppercase versus Lowercase User IDs
At this point we could log on using lowercase user IDs. If you want to use
uppercase, make a copy of the file with the user ID in uppercase, as follows:
cd /$BSE/lib/user
cp ubaan1 uBAAN1
If you want to give the user the flexibility of logging on in either uppercase or
lowercase, you can add the user ID to the /etc/alias file in UNIX System Services
for OS/390 as described in Chapter 2 of Installing <strong>Baan</strong>IV <strong>Applications</strong> on OS/390,
SG24-5334.
After you have completed these steps, the five user IDs are able to access the
training Company 200. The users can use the BW client to log on to <strong>Baan</strong>.
2.2 Setting Up User IDs for Production
This example describes how to set up user IDs for production. In this case, we
are using DB2 secondary authid exits, the Process Manager is being used, the
end users are in a separate RACF group that does not have DBADM privileges,
and the passwords have an expiration date.
Using option 6 of TSO, we executed the following steps to create production
<strong>Baan</strong> user IDs:
1. Create a new RACF group BSPUSER for the production users: ADDGROUP
BSPUSER UID(125),,,,,,,
2. Ensure a secondary DB2 authid is set up and privileges are granted to
BSPUSER. (This is shown in 2.2.1, “DB2 Secondary Authid” on page 20.)
3. Add the user ID to OS/390 RACF so the password will expire in 60 days:
ADDUSER PROD0 DFLTGRP(BSPUSER) OWNER(ROOT) OMVS(UID(231)
HOME('/baanIV/bse/home/prod0') PROGRAM('/bin/sh'))
To change the default password to a permanent one and to extend the
interval, enter the commands:
PASSWORD USER(prod0) INTERVAL(60)
ALU PROD0 PASSWORD(PROD0) NOEXPIRED
4. Create a home directory in $BSE/home/uuserid:
cd / baanIV/bse/home
mkdir prod0
5. Add the user ID to the db2_users file in $BSE/lib/db2:
BSP:BSP:pDOH9BNtTkv˚*3e!&t#

7. Set up the Process Manager profile and the port number of the end-user
workstation. Put an entry in the /window/services file on each of the users'
PCs that will be logging on to <strong>Baan</strong>. If that entry is not on the Workstation
PC, the Process Manager function will not be used.
2.2.1 DB2 Secondary Authid
To allow different DB2 users the ability to share the same table, DB2 uses the
group concept provided by the system authorization facility (SAF) of OS/390. The
SAF is the security product installed on OS/390, such as RACF, ACF2, or Top
Secret.
20 <strong>Baan</strong> on OS/390 Implementation Experiences
Secondary authorization ID support should be enabled in the DB2-provided
authorization exits DSN3SATH and DSN3SSGN during DB2 installation. A sample
job, DSNTIJEX, is provided in the sample library, hlq.SDSNSAMP, for this
purpose, as shown.

DB2LF JOB (999,POK),'DB2V510L',CLASS=A,MSGCLASS=T, 00000001
// NOTIFY=&SYSUID,TIME=1440,REGION=0M 00000002
/*JOBPARM L=999,SYSAFF=SC48 00000003
//*********************************************************************/00010000
//* JOB NAME = DSNTIJEX */00020000
//* */00030000
//* 2/1/99: ENABLE SECONDARY AUTH EXITS - VK */00090000
//* */00090000
//* */00090000
//* STATUS = VERSION 5 RELEASE 1 */00100000
//* */00110000
//* FUNCTION = PREPARE THE AUTHORIZATION EXITS */00120000
//* */00130000
//* PSEUDOCODE = */00140000
//* ASMPROC PROC - ASSEMBLE AND LINK AN ASSEMBLY LANGUAGE PROGRAM */00150000
//* JEX0001 STEP - INVOKE ASMPROC TO PREPARE SIGNON EXIT DSN3@SGN */00160000
//* JEX0002 STEP - INVOKE ASMPROC TO PREPARE IDENTIFY EXIT DSN3@ATH */00170000
//* JEX0003 STEP - INVOKE ASMPROC TO PREPARE ACCESS CONTROL */00173000
//* AUTHORIZATION (ACA) EXIT DSNX@XAC */00176000
//* */00180000
//* NOTES = */00190000
//* THIS JOB IS OPTIONAL. IT (OR AN EQUIVALENT) IS ONLY NEEDED IF */00200000
//* YOU DO NOT INTEND TO USE THE DEFAULT AUTHORIZATION EXITS. */00210000
//* */00220000
//*********************************************************************/00230000
//* 00240000
//ASMPROC PROC WSPC=500,MEM=TEMPNAME 00250000
//* 00260000
//* ASSEMBLE 00270000
//* 00280000
//ASM EXEC PGM=ASMA90,PARM='OBJECT,NODECK' 00290000
//SYSIN DD DISP=SHR, 00300000
// DSN=DB2V510.SDSNSAMP(&MEM) 00310000
//SYSLIB DD DSN=SYS1.MODGEN,DISP=SHR 00320000
// DD DSN=SYS1.MACLIB,DISP=SHR 00340000
// DD DISP=SHR, 00350000
// DSN=DB2V510.SDSNMACS 00360000
// DD DISP=SHR, 00370000
// DSN=DB2V510.SDSNSAMP 00380000
//SYSLIN DD DSN=&&LOADSET,DISP=(MOD,PASS),UNIT=SYSALLDA, 00390000
// SPACE=(800,(&WSPC,&WSPC)),DCB=(BLKSIZE=800) 00400000
//SYSPRINT DD SYSOUT=* 00410000
//SYSUDUMP DD SYSOUT=* 00420000
//SYSUT1 DD UNIT=SYSALLDA,SPACE=(800,(&WSPC,&WSPC),,,ROUND) 00430000
//SYSUT2 DD UNIT=SYSALLDA,SPACE=(800,(&WSPC,&WSPC),,,ROUND) 00440000
//SYSUT3 DD UNIT=SYSALLDA,SPACE=(800,(&WSPC,&WSPC),,,ROUND) 00450000
//* 00460000
//* LINKEDIT IF THE ASSEMBLER 00470000
//* RETURN CODE IS 4 OR LESS 00480000
//* 00490000
//LKED EXEC PGM=IEWL,REGION=1024K, 00500000
// PARM='SIZE=(900K,124K),LIST,XREF,RENT,OL,NCAL,AMODE=31,RMODE=ANY', 00510000
// COND=(4,LT,ASM) 00520000
//SYSLIN DD DSN=&&LOADSET,DISP=(OLD,DELETE) 00530000
//DSNLOAD DD DSN=DB2V510.SDSNLOAD,DISP=SHR 00540000
//SYSLMOD DD DISP=SHR, 00550000
// DSN=DB2V510L.SDSNEXIT(&MEM)

Note: Keep RMODE at 31 and AMODE at ANY, even though other members
might have the values of 24 and 24. When we changed RMODE to 24 and
AMODE to 24, it did not work.
2.2.1.1 Process Manager Considerations
During connection (CAF, RRSAF) and signon (RRSAF only), the list of primary
and secondary IDs is established. With CAF, it is important to note that the
primary authorization ID is that of the address space as a whole. When running
with the Process Manager component of OS/390 UNIX Systems Services
Connection Scaling, the primary ID will be the user ID used to start the Process
Manager daemon.
As this is probably not the intent, it may be necessary to alter the DSN3SATH
routine to use the security environment of the connecting TCB (db driver
process). To do this, modify the connection exit that follows at label SATH024 in
member DSN3SATH of hlq.SDSNSAMP. Modify the code to look for an ACEE in
the TCB before looking in the ASXB (address space extension).
L R15,PSATOLD+PSA Get current TCB Address
Using TCB,R15 Tell the assembler
ICM R6,B'111',TCBSENV Get a (ACEE) if annyCE
BZ SSGN043 None, Check the ASXB
Drop R15 Do not need anymore
CLC ACEEACEE,EYEACEE Does it match an ACEE?
The following shows which profiles are executed when the Process Manager is
in use and when it is not in use:
Process Manager Only .bpaprofile
No Process Manager /etc/profile, then /home/user/.profile
Do not create the .bpaprofile with viascii.
2.2.2 Setting Up Privileges for End Users
If you do not want your end users to have DBADM privileges, do the grants at
the table level. Since Company 000 has more than 380 tables and each company
has more than 2700 tables, you must find an automated way to create the grant
statements.
22 <strong>Baan</strong> on OS/390 Implementation Experiences
2.2.2.1 Creating the Grant Statements
We used SPUFI to create an output file that contained our 3300 GRANT
statements, as follows:
- SELECT 'GRANT ALL ON TABLE' ,SUBSTR(CREATOR,1,7)||'.'||NAME,
- ' TO BSPUSER;'
- FROM SYSIBM.SYSTABLES
- WHERE CREATOR='DB2BAAN' ;
This shows only a small sample of the 3300 grant statements we created.

When you have saved the SPUFI output, run the following JCL to do the grants at
the table level (and not at the dbadm level).
GRANT ALL ON TABLE DB2BAAN.TTTAAD050000 TO BSPUSER;
GRANT ALL ON TABLE DB2BAAN.TTTAAD100000 TO BSPUSER;
GRANT ALL ON TABLE DB2BAAN.TTTAAD106000 TO BSPUSER;
GRANT ALL ON TABLE DB2BAAN.TTTAAD110000 TO BSPUSER;
GRANT ALL ON TABLE DB2BAAN.TTTAAD200000 TO BSPUSER;
GRANT ALL ON TABLE DB2BAAN.TTTAAD201000 TO BSPUSER;
GRANT ALL ON TABLE DB2BAAN.TTTAAD300000 TO BSPUSER;
GRANT ALL ON TABLE DB2BAAN.TTTAAD305000 TO BSAUSER;
2.2.2.2 Executing the Grant Statements
We used the following JCL to execute the grant statements generated by the
SPUFI command:
//GRANTALL JOB (999,POK),'BAAN INSTALL',NOTIFY=&SYSUID, 00010002
// CLASS=A,MSGCLASS=T,TIME=1439, 00020002
// MSGLEVEL=(1,1) 00030002
//* *00180002
//* GRANT ALL ON TABLE ..... TO BSAGRP1 *00190002
//* *00210002
//**********************************************************************00220002
//JOBLIB DD DSN=DB2V510D.RUNLIB.LOAD,DISP=SHR 00221002
// DD DSN=DB2V510.SDSNLOAD,DISP=SHR 00230002
//* DD DSN=SYS1.PLIBASE,DISP=SHR 00240002
//* DD DSN=SYS1.SIBMBASE,DISP=SHR 00250002
//* 00260002
//* 00420002
//* PRINT THE TABLES 00440002
//PH01PS02 EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT) 00450002
//SYSTSPRT DD SYSOUT=* 00480002
//SYSPRINT DD SYSOUT=* 00490002
//SYSUDUMP DD SYSOUT=* 00500002
//SYSTSIN DD * 00510002
DSN SYSTEM(DB2D) 00520002
RUN PROGRAM(DSNTIAD) PLAN(DSNTIA51) - 00550002
LIB('DB2V510D.RUNLIB.LOAD') PARMS('/ALIGN(MID)') 00560002
END 00570002
//* 00580002
//SYSIN DD DSN=KARRAS.SPUFI.CNTL(GRANTALL),DISP=SHR 00600002
//* 00720002
2.2.3 How to Handle Expiration of Passwords
As stated previously, <strong>Baan</strong> users log on through a BW client. Since the BW
client cannot handle the RACF message that the password has expired, we
changed the default 30 interval to NOINTERVAL or to INTERVAL(365). However,
this may not meet customer security requirements
As of July 1999, <strong>Baan</strong> is working on its own <strong>Baan</strong>LoginDaemon, which will
address this and other issues.
If you do not want to set the interval to 90 or 180 days until this solution is
available, you can use the following:
1. Create a script that looks in /etc/passw (that is, list the RACF database on
the OS/390).
Chapter 2. Creating Additional <strong>Baan</strong> Users 23

24 <strong>Baan</strong> on OS/390 Implementation Experiences
2. Extract the user IDs whose passwords are about to expire.
3. Check whether they are using <strong>Baan</strong> at the moment by using the command ps
-ef uxxxx (where xxxx is the user ID).
4. Issue the following command:
bshcmd6.2 -M "Your password is about to expire" -w1 -u1
5. Present a menu option to the users, giving them access to the UNIX
password command in order to facilitate changing the password.
menu field type]= shellprogram
program ] ] = passwd $logname
The noexpire bit must be set off after the initial logon.

Chapter 3. Moving HFS Files
As more companies were added after the installation phase, we noticed the
<strong>Baan</strong> HFS file was 80 percent full. We monitored the status by issuing the df
command. With OS/390 V2R6, the HFS file systems have a limit of one physical
pack, therefore, we could not enlarge the HSF as it had been set up with 3300
cylinders. We considered specifying on the RVA that the HFS was a model 009
but then we would have encountered UCB contention.
Our conclusion was that as your HFS files grow large, you need to create a new
HFS and move some of the data to it to avoid running out of space. This should
also improve performance.
The steps we used were as follows:
1. Create a new HFS file.
2. Mount it on a temporary mount point.
3. Change the access to 755 from the default 700.
4. Copy the files from the directory we decided to move (/dict).
5. Unmount the temporary mount point.
6. Mount the new HFS over the old mount point.
7. Test the access.
8. Erase the files under the old mount point to free up space.
9. Test the access.
You can perform this procedure using the ish command, or you can use
commands directly in UNIX Services. We used the ish command.
Attention
3.1 Allocation of the HFS Files
In OS/390 Rel 2.7, an HFS can span one volume, so the urgent need to
monitor and move HFS files is removed. However, for performance and
DASD management, you may want to move files to their own HFS as they
increase in size.
The HFS files are created using TSO, executing the following steps:
1. Choose ISPF option 6; issue the ish command.
2. Press PF10 to put the cursor on the action bar.
3. Tab to file_systems, press Enter.
4. Enter 2 for new from the pull-down menu.
We entered the information shown in Figure 10 on page 26 to create our
HFS file.
© Copyright IBM Corp. 1999 25

New Mount Point
File system name BAAN.DICT
Primary Cylinders 1000
Secondary cylinders 100
Storage Class SCBAAN
Management Class Standard
Data Class DCPDSE
Figure 10. Allocation HFS Files
3.2 Creating the Mount Point
Note: Check with the OS/390 systems programmer for the correct storage class,
management class, and data class to use.
Mount points are directories over which an HFS file system is mounted. An HFS
file system cannot be accessed through OS/390 UNIX System Services unless it
has been mounted.
The member BPXPRM00 in SYS1.PARMLIB can be used to automatically mount
the HFS data sets at IPL time. UNIX System Services Connection Scaling
Reference, SA22-7305, has the suggested settings for BPX parameters for <strong>Baan</strong>.
Attention
In our sysplex environment we do not put LPAR-specific mount points in
BPMXPARM in the SYS1.PARMLIB library because it is shared. We create a
started task that does the mkdir and mount commands for HFS files.
These mount points should be made permanent for the next IPL of your
system by updating your BPMXPARM, or by using the preceding procedure,
or by using your own operational procedure.
To change this session to OS/390 UNIX System Services, again log on as ROOT,
select option 6, and type omvs. Then create a directory for the mount point, using
the following commands:
cd /
mkdir baantmp
mkdir baantmp/dict
If you do not have access to the root file system, you could put the temporary file
in /tmp.
At this point, issue the exit command at the prompt and press Enter.
3.2.1 Mounting the HFS Files
An HFS file cannot be accessed through OS/390 UNIX System Services unless it
has been mounted. The HFS files must have been already allocated and the
mount point created before a mount point command can be issued.
26 <strong>Baan</strong> on OS/390 Implementation Experiences
HFS files are manually mounted through TSO. To manually mount HFS files:
1. Log on to TSO.
2. Choose option 6 (commands).

3. Enter ish.
4. Press PF10 to go to the action bar.
5. Tab to file_systems, press Enter.
6. Choose 3 for mount on the pull-down menu.
7. Complete the menu to mount a file system.
Figure 11 shows the information we entered for our temporary HFS file:
Mount Point /baantmp/dict
File System Name baan.dict
File System Type HFS
New Owner ROOT
Figure 11. Mount Temporary HFS File
3.2.2 Copying the Files
At this point we were ready to copy the files. To copy the files we issued the
commands:
cd /baanIV/dict
du -sk (to get the size of the files)
cp -R * /baantmp/dict
pax -wvf /tmp/api.pax *
Note: If you use /baanIV/dict instead of the asterisk (*), you will get an
additional directory layer and the resulting files will be in /baantmp/dict/dict,
which will cause a problem when you start the <strong>Baan</strong> application.
We first used the cp command instead of pax, but we found out that cp does not
copy symbolic links. Instead, it moves the link files, so you would end up with
two copies of some files and the sizes would be different.
After the copy is complete, we issued the following commands:
cd /baantmp/dict
du -sk
Using the du command allows us to check that the files are approximately the
same size. The size of the files seem to depend on the number of
subdirectories.
Now unmount the temporary file, using the following commands:
ish
pf10
file systems
option 1
u (u is the command to unmount baan.dict)
Note: If you get a message that the resource is busy, you can do it as
immediate. Mount the new dict HFS file over the old mount point. Go back to
file systems and choose 3 and enter the data shown in Figure 12 on page 28.
Chapter 3. Moving HFS Files 27

Mount Point /baanIV/dict
File System Name baan.dict
File System Type HFS
New Owner ROOT
Figure 12. Mount New HFS File
Now go back to OMVS and enter:
cd /baanIV/dict
3.3 Removing the Old Files
Change the owner and permissions for the dict files by issuing the following
commands:
chmod 755 .
chown -R bsp:bsp *
chown bsp:bsp .
chown bsp:bsp ..
This changes the ownership of the . and .. directories. Now you should make
sure this new file is mounted at IPL time by adding this new mount point to the
BPX parameters.
After we had tested the <strong>Baan</strong> <strong>Applications</strong> with the new HFS, we removed the
old files by going to OMVS and using the following commands:
Unmount the new HFS:
ish
PF10
1
unmount /baanIV/dict
Remove the old /baanIV/dict directory:
cd /baanIV/dict
rm -R *
Note: -R is equivalent to -r. If you specify baanIV/dict rather than *, it will
remove the dict directory. Do not remove the dict directory as you need it
for the mount point for the new HFS.
Mount the new HFS again:
ish
PF10
1
mount
28 <strong>Baan</strong> on OS/390 Implementation Experiences
Mount Point /baanIV/dict
File System Name baan.dict
File System Type HFS
New Owner ROOT
At this point, we had completed moving the /baanIV/dict HFS. In your case, if
you need more space, you could repeat the process for another directory.

See A.4, “Script to Determine If the HFS Is Almost Full” on page 86 for a script
to use to check if the HFS is close to running out of disk space.
Attention
To ensure you are moving and deleting the correct files, you may want to add
a small file to the old directory, just so you can be sure you are dealing with
the old directory. You could do this just after the pax command by using the
touch command. In the old directory, issue the command:
touch old file
Later you can check for the old file to see that you are in the correct
directory before issuing the remove command.
Chapter 3. Moving HFS Files 29

30 <strong>Baan</strong> on OS/390 Implementation Experiences

Chapter 4. Setting Up Process Manager (PM)
This chapter describes how to set up Process Manager (PM) and also discusses
considerations you should be aware of when using this component.
When you install Process Manager, ensure the following:
1. The log is in /var/bpa.
2. bpares/cfg is in /etc/bpa. This is where you specify the IP address and the
port number. This must also be specified in each user's /windows/services
file.
3. Code must be added to the exit for DB2 Secondary Authid as shown in 2.2.1,
“DB2 Secondary Authid” on page 20.
4. Process Manager must be started only after <strong>Baan</strong> is started, and it must be
stopped before you stop <strong>Baan</strong>. You could alter rc.start and rc.stop scripts to
include these commands. You might also want to start and stop the license
daemon in the rc.start script.
Do not start Process Manager twice. Issue a ps -ef |grep bpassp command
to check if it is running.
5. Each user can have a bpaprofile in the home directory; refer to Figure 13 for
an example.
BSE=/baanIVc/bse
BSE_TMP=/baanIVc/bse/tmp
PATH=$BSE/bin:$PATH
TERM=vt100
DB2_MVS_SYNTAX=1
_CEE_RUNOPTS=HEAP(17M,1M,ANYWHERE,KEEP),STACK(131072,131072,ANYWHERE,KEEP),ALL31(ON),
LIBSTACK(8),TERMTHDACT(UADUMP)
BPX_SHAREAS=YES
LIBPATH=$LIBPATH:/usr/lpp/bpa/lib:/baanIVc/bse/bin
NLSPATH=$NLSPATH:/usr/lpp/cmx/nls/msg/%L/%N:/usr/lpp/bpa/nls/msg/%L/%N
Figure 13. Example .bpaprofile
Note that there are no quotes in the CEE_RUNOPTS and that the underscore is
missing from the BPX variable.
It is important to understand which profiles are executed when Process Manager
is in use and which are executed when it is not in use. See 2.1.3.2, “Create User
Profiles” on page 11 for more information.
Note: Do not create the bpaprofile with viascii.
4.1 Process Manager Considerations
During connection (CAF, RRSAF) and signon (RRSAF only), the list of primary
and secondary IDs are established. With CAF it is important to note that the
primary authorization ID is that of the address space as a whole. When running
with the Process Manager component of OS/390 UNIX Systems Services
Connection Scaling, the primary ID will be the user ID used to start the Process
Manager daemon.
As this is probably not the intent, it may be necessary to alter the DSN3SATH
routine to use the security environment of the connecting TCB (db driver
process). To do this, modify the connection exit that follows at label SATH024 in
member DSN3SATH of hlq.SDSNSAMP. Modify the code to look for an ACEE in
© Copyright IBM Corp. 1999 31

the TCB before looking in the ASXB (address space extension), as shown in
Figure 14 on page 32.
L R15,PSATOLD+PSA Get current TCB Address
Using TCB,R15 Tell the assembler
ICM R6,B'111',TCBSENV Get a (ACEE) if annyCE
BZ SSGN043 None, Check the ASXB
Drop R15 Do not need anymore
CLC ACEEACEE,EYEACEE Does it match an ACEE?
Figure 14. Modifications to the Connection Exit Code
4.2 Problems Encountered with PM in BPAERR.LOG
In this section we describe problems we encountered with Process Manager in
BPAERR.LOG, along with the solutions we applied.
4.2.1 Address Already in Use
The following messages occur when the Process Manager has been started
twice:
BPA2002E message for port 2010 indicating the address is already in use
BPA0164S message with RC_DAE_CHECKANDOPENCOMMUNICATION
BPA0165S message with RC_DAE_ABEND
BPA2048W message with RC_RTS_SPAWN
The BPA2002E had an error of 744C7247
The BPA2048W had an error of 0B1B0473
4.2.2 Running Out of HEAP Storage Message in the BPAERR.LOG
If you receive the message that you are running out of HEAP storage, it may be
because you are using Process Manager and there is no bpaprofile in the user's
home directory. If a user does not request a HEAP of their own and they are
using Process Manager, the user will share the memory HEAP of the parent.
In our case, the user ROOT started Process Manager. Everyone shared the
memory HEAP of ROOT and after a while, the HEAP was overallocated and users
could no longer log on.
To resolve this problem, you can either create a BPAPROFILE in each user's
home directory or increase the HEAP size in the /.profile of the ROOT user ID.
4.2.3 Unable to Log On with BW Client but Able to with BA Client
When we encountered this problem, it was because the user workstation had a
port number entry in the /windows/services file but the Process Manager was
not running.
32 <strong>Baan</strong> on OS/390 Implementation Experiences

Chapter 5. Post-Installation Tuning
This chapter describes the steps we took to improve the performance of <strong>Baan</strong>
<strong>Applications</strong> on S/390. The installation process involves several steps, such as:
Installing Company 000
5.1 Putting Modules in the LPA
Licensing the <strong>Baan</strong> <strong>Applications</strong>
Installing the supplied demo companies or creating test companies
After completing the basic installation, there are several steps you can follow in
order to optimize the system for performance. These steps are described in the
Installation Guide available from <strong>Baan</strong>. Our experiences in post-installation
tuning are described in the following sections.
Note: <strong>Baan</strong>'s design is such that, for a given capacity, significantly better
interactive (online) response time results from faster engines. That is, having
fewer, faster engines is much better than more, slower engines. You should
therefore consider using the newest technology feasible to obtain the fastest
engines.
To improve performance we followed the <strong>Baan</strong> IV Installation Guide instructions
to put certain <strong>Baan</strong> executables in the Link Pack Area, as follows:
1. We verified the UW49280 PTF was installed. We found it had been
superseded by PTF UW50221, which was installed.
2. We set up a partitioned data set (PDS) to contain the <strong>Baan</strong> executables.
BAAN4.LPALIB
3. We ran the linkedit job as shown in Figure 15 on page 34.
4. We created three empty files in $BSE/bin using the touch command:
touch bshell61
touch shserv61
touch sort61
Note: The first time we did this we were logged on as ROOT, not BSP so the
owner of the files was incorrect. A second problem was that the umask was
not set correctly so we had to change the permission bits for these three
files:
chmod 755 bshell61
chmod 755 shserv61
chmod 755 sort61
5. Using the chmod command with user group and owner, we set the sticky bits
to “on” so the modules would be marked as being in the LPA:
chmod ugo+t bshell61
chmod ugo+t db2srv61
chmod ugo+t shserv61
chmod ugo+t sort61
chmod ugo+t globlvar
chmod ugo+t /usr/lpp/bpa/bpadll
To activate these in the LPA without doing an IPL, we issued the following
command at the console:
© Copyright IBM Corp. 1999 33

SETPROG LPA,ADD,MASK=*,DSNAME=BAAN4.LPALIB
Figure 15. JCL to LinkEdit into the Library for LPA. A LinkEdit job has to be run for each
module.
//BAANLNK JOB (999,POK),'BAAN LPA LINK',NOTIFY=&SYSUID,
// CLASS=A,MSGCLASS=T,TIME=1439,
// REGION=5000K,MSGLEVEL=(1,1)
//* LINKEDIT
//**********************************************************
//DB2SRV61 EXEC PGM=IEWL,
// PARM='LIST,XREF,LET,RENT,REUS,AMODE=31,RMODE=ANY,CASE=MIXED'
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,10))
//INLMOD DD PATH='/baanIVc/bse/bin'
//SYSLMOD DD DISP=SHR,DSN=BAAN4.LPALIB
//SYSLIN DD *
INCLUDE INLMOD(db2srv61)
ENTRY CEESTART
NAME DB2SRV61(R)
/*
//**********************************************************
//BSHELL61 EXEC PGM=IEWL,
// PARM='LIST,XREF,LET,RENT,REUS,AMODE=31,RMODE=ANY,CASE=MIXED'
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(10,10))
//INLMOD DD PATH='/baanIVc/bse/bin'
//SYSLMOD DD DISP=SHR,DSN=BAAN4.LPALIB
//SYSLIN DD *
INCLUDE INLMOD(bshell6.1)
ENTRY CEESTART
NAME BSHELL61(R)
/*
//**********************************************************
Note: We had to issue the command caps off on the command line in order
to get the lowercase PATH name and the lowercase INCLUDE name.
6. For these changes to take effect, we modified the $BSE/etc/ipc_info file by
changing the p to d for those modules we placed in the LPA, to change direct
to pipes.
5.1.1 Putting Application Objects in Shared Memory
As well as putting modules in the LPA to improve performance, further gains can
be had by putting <strong>Baan</strong> objects into shared storage. The STP and DSK modules
were put into shared storage by adding the object names in the shared memory
file SRdd_INIT6.1
5.2 Changing the Shared Memory Parameters
One of the things you can do to improve performance is to increase the values of
shared memory parameters in the file $BSE/lib/shm_param file. The steps we
followed were:
1. Stop the <strong>Baan</strong> application by issuing the command in the $BSE/etc directory:
rc.stop
34 <strong>Baan</strong> on OS/390 Implementation Experiences
2. Make a copy of the file by issuing the command:

5.3 Small db2_storage File
5.4 REBIND the Plan
cp shm_param shm_param_old
3. Change the values using the viascii command.
We changed three of the values in the $BSE/lib/shm_param file as follows:
NEW WAS
SHM_START = 18000000 15000000
SHM_STEP = 1000000 400000
SHM_BUFSIZE = 16384 4096
SHM_MAXMEM = 30
Note: Before making the changes, issue the command shmvalues6.2 The
values that are returned will tell you what to use for the SHM_START
parameter. See the <strong>Baan</strong>ERP Tools Technical Manual for more information.
4. Start the <strong>Baan</strong> application by issuing this command in the $BSE/etc
directory:
rc.start
The next thing we tried was to increase the values in the BPXPRMxx
parameters. In our case only ipcsemnsems was not set to the maximum
value. At the console we issued the following command to change the value:
setomvs ipcsemnsems
All values in the BPXPRMxx for ipcshm and ipcsem were set to the
maximum values.
After you have created and loaded the <strong>Baan</strong> Companies you can use a two-line
db2_storage file that will decrease the search time for <strong>Baan</strong> requests to DB2.
The following example shows a very simple db2_storage that puts everything
into one tablespace:
*:*:I::01::STOGROUP BAANGRP PRIQTY 64 SECQTY 960 BUFFERPOOL BP0
*:*:T:group:01:5: ARR_SIZE 1 OPT_ROWS 5 T_SPACE C000DB1.TDEMO0
.
.
We ran the job to bind CMXPLAN, changing DYNAMICRULES from RUN to BIND.
Note: If you are going to still be loading new companies, you must create a
second plan for user BSP that has DYNAMICRULES(BIND). The variable
CMXPLAN='Location of new plan', which in our case was
CMXCONF=/etx/cmx/bind/, must be placed in either the .profile or the
.bpaprofile file for user BSP.
Chapter 5. Post-Installation Tuning 35

5.5 Break Up the HSF File Systems into Smaller File Systems
5.6 Change the Name Server
Refer to Chapter 3, “Moving HFS Files” on page 25 for more detail on this
process.
We found that <strong>Baan</strong> does a GETHOSTBYNAME command. It was not able to
resolve this with the Name Server the system was using, so we had to change
the S/390 domain server name in the TCPIPDATA file to a local one. This saved
30 seconds on the initial logon.
You can verify if you have this problem by issuing the commands: NSLOOKUP
wtsc48 (wtsc48 was our hostname) or NSLOOKUP 9.2.12.14 (9.2.12.14 was the IP
address of our host).
5.7 RMF Analysis for CPU and DISK
We found we were not using a significant amount of CPU time or doing a lot of
I/O. Nevertheless, a process should be put in place to regularly gather and
review RMF data.
5.8 Setting Up Process Manager and Starting the PM Daemon
We found that starting Process Manager did not change the initial logon time at
all in our tests.
5.9 Putting the tmp File in Memory
Another option is to put the /tmp file that <strong>Baan</strong> uses into memory. To do this,
issue the command:
MOUNT FILESYSTEM('/baanIVc/bse/tmp') TYPE (TFS)
MOUNTPOINT ('/baanIVc/bse/tmp') PARM('-S 5')
Note that the 5 in the PARM parameter is the number of megabytes you want the
temporary file space to be.
5.10 Ongoing Monitoring and Tuning
36 <strong>Baan</strong> on OS/390 Implementation Experiences
You should be aware that the steps we covered in this chapter are only some
initial points to consider to start the tuning process.
In addition to these steps, it is important that you establish processes to capture
performance data that can be regularly monitored. These should include RMF
reports and DB2 Performance Monitor reports. <strong>Baan</strong> Support can provide
information on how to do specific traces if there are certain transactions with a
perceived performance problem.

Chapter 6. Creating a New <strong>Baan</strong> Company
This chapter describes the steps a customer performed to create a new
company for training. Prepare for this with the following tasks:
Choose the company number.
Choose the database layout.
Determine which user IDs require access.
Verify that there is enough disk space in DB2 STOGROUPS.
Verify that there is enough disk space in HFS file systems.
Verify that the indexes for Company 000 are not into a large number of
extents (119 is the maximum).
Determine which DB2 bufferpools will be used.
Create the new company by performing the following steps:
Create the db2_storage file.
Create the DB2 Databases and tablespaces.
Grant privileges to the group BSPUSER or the individual users that need to
access this new company.
Create the dump files to load the data.
Run bdppost to load the data.
Run the <strong>Baan</strong> Tools to verify that all tables are present.
Run the DB2 Runstats Utility.
Test the new company.
6.1 Creating the db2_storage File
The layout of the database includes data for the ba, cp, ct, ps, tc, td, tf, tg, ti,
tp, tr, ts, tu, and tttxt packages.
This company had been created primarily to use with the DEM and FI
applications so we allocated more tablespaces to the tf, tg, tp, and tttxt files.
We decided to:
− Create STOGROUP BAANGRP3 for the indexes.
− Create STOGROUP BAANGRP2 for the tablespaces.
− Use Bufferpool 5 for the indexes.
− Use Bufferpool 6 for the databases.
− Use Bufferpool 4 for the tablespaces.
− Use USRGRP1 for the users that will access this company.
− Use 998 for the company number.
To set up this layout for DB2 and <strong>Baan</strong>, we then created a db2_storage file
as shown in the following example.
© Copyright IBM Corp. 1999 37

38 <strong>Baan</strong> on OS/390 Implementation Experiences
ba:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998BA1.BA0001
cp:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998CP1.CP0001
ct:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998CT1.CT0001
ps:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998PS1.PS0001
tc:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TC1.TC0001
td:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TD1.TD0001
tfacp:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF1.TF0001
tfacr:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF1.TF0001
tfcal:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF1.TF0001
tfcmg:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF1.TF0001
tffas:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF1.TF0001
tffbs:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF2.TF0002
tffst:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF2.TF0002
tfgld:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF2.TF0002
tfzzz:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF2.TF0002
tf:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TF3.TF0003
tgbrg:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TG1.TG0001
tgeis:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TG1.TG0001
tgerm:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TG1.TG0001
tgtst:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TG2.TG0002
tgwms:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TG2.TG0002
tgwzr:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TG2.TG0002
tg:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TG3.TG0003
ti:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TI1.TI0001
tpbop:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP1.TP0001
tphrs:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP1.TP0001
tpism:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP1.TP0001
tppbs:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP1.TP0001
tppdm:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP1.TP0001
tppin:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP2.TP0002
tpppc:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP2.TP0002
tpprc:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP2.TP0002
tppss:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP2.TP0002
tpptc:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP2.TP0002
tpzzz:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP2.TP0002
tp:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TP3.TP0003
tr:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TR1.TR0001
ts:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TS1.TS0001
tttxt:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TTT.TTTX01
tu:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998TU1.TU0001
*:998:T:group:01:5:OPT_ROWS 5 T_SPACE C998OTHR.OTHR01
tg:998:I::01::STOGROUP BAANGRP3 PRIQTY 12 SECQTY 9600 DEFER YES BUFFERPOOL BP5
tttxt:998:I::01::STOGROUP BAANGRP3 PRIQTY 6040 SECQTY 9600 DEFER YES BUFFERPOOL
BP5
*:998:I::01::STOGROUP BAANGRP3 PRIQTY 12 SECQTY 9600 BUFFERPOOL BP5
*:*:I::01::STOGROUP BAANGRP3 PRIQTY 64 SECQTY 960 BUFFERPOOL BP5
*:*:T:group:01:5: ARR_SIZE 1 OPT_ROWS 5 T_SPACE C999DB1.TOTHEH0
We found the easiest way to create this was to change an existing db2_storage
file with a vi global change command as follows:
vi db2_storage
:1,$s/:200/:998/g (this changes 200 to 998 at the beginning of each line)
:1,$s/C200/C998/g
:wq! (this changes C200 to C998 for the table name at the end of each line)
Note that the dollar sign ($) means change all lines.
Then we checked to see that all the changes had been made correctly.

6.2 Creating the DB2 DDL and Granting Privileges
To create the DB2 DDL and grant privileges, we again used existing JCL and did
a global change using the command C/C200/C998/ ALL.
Then we verified the changes were correct. This JCL creates new STOGROUPs,
databases and tablespaces; it also grants privileges to bsp user ID and the
group BSPGRP (see Figure 16 on page 40).
Chapter 6. Creating a New <strong>Baan</strong> Company 39

40 <strong>Baan</strong> on OS/390 Implementation Experiences
//BALLOC JOB (0513),'BAAN INSTALL',
// TIME=1440,
// NOTIFY=ROOT,
// REGION=0M,
// CLASS=A,
// MSGCLASS=X,
// MSGLEVEL=(1,1)
//* INSTALLATION OS/390 V2R6 (BAAN)
//*
//*--------------------------------------------------------------------
//* GDE: IBM EXTENDED FACILITIES PRODUCT V2R1 INSTALLATION
//* DOC: FMIDS - SIB2110, TIB2111, SSKP122, ASAR55D, SSAT55D, ASAT55D
//*
//*--------------------------------------------------------------------
//*********************************************************************/
//* NAME = BAANDDL */
//* */
//* DESCRIPTIVE NAME = SAMPLE DDL TO CREATE DATABASES & TABLESPACES */
//* FOR BAAN IV INSTALLATION */
//* */
//* STATUS = VERSION 1 */
//* */
//* FUNCTION = THIS JCL PERFORMS THE NECESSARY DDL TO BUILD THE */
//* BAAN IV DB2 DATABASE. THE FOLLOWING DDL MATCHES THE */
//* SETUP SUPPLIED IN THE $BSE/lib/db2/db2_storage FILE. */
//* */
//* ANY CHANGES TO STOGROUP, DATABASE AND/OR TABLESPACE */
//* NAMES REQUIRES THE CORRESPONDING CHANGE IN THE */
//* $BSE/lib/db2/db2_storage FILE. */
//* */
//* YOU MUST UPDATE THE hlq IN THE JOBLIB. */
//* */
//* CHANGE ACTIVITY = */
//*********************************************************************/
//JOBLIB DD DSN=DSN510.SDSNLOAD,DISP=SHR
// DD DSN=DSN510.RUNLIB.LOAD,DISP=SHR
//CREATDDL EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN S(DSN)
RUN PROG(DSNTIAD) PLAN(DSNTIA51)
END
//SYSIN DD *
CREATE STOGROUP BAANGRP2
VOLUMES (V26DB5,V26DB6,V26DB7) VCAT DSN510;
CREATE STOGROUP BAANGRP3
VOLUMES (V26DB8,V26DB9,V26DB0) VCAT DSN510;
COMMIT;
CREATE DATABASE C998TG1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TG2
STOGROUP BAANGRP2
BUFFERPOOL BP6;
Figure 16 (Part 1 of 5). JCL to Create Database

CREATE DATABASE C998TG3
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TTT
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TP1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TP2
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TP3
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TF1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TF2
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TF3
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998BA1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998CP1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998CT1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998PS1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TC1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TD1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TI1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TR1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TS1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998TU1
STOGROUP BAANGRP2
BUFFERPOOL BP6;
CREATE DATABASE C998OTHR
STOGROUP BAANGRP2
BUFFERPOOL BP6;
COMMIT;
Figure 16 (Part 2 of 5). JCL to Create Database
Chapter 6. Creating a New <strong>Baan</strong> Company 41

42 <strong>Baan</strong> on OS/390 Implementation Experiences
CREATE TABLESPACE TG0001 IN C998TG1 BUFFERPOOL BP4
USING STOGROUP BAANGRP2
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TG0002 IN C998TG2 BUFFERPOOL BP4
USING STOGROUP BAANGRP2
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TG0003 IN C998TG3 BUFFERPOOL BP4
USING STOGROUP BAANGRP2
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TTTX01 IN C998TTT BUFFERPOOL BP4
USING STOGROUP BAANGRP2
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TP0001 IN C998TP1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TP0002 IN C998TP2 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TP0003 IN C998TP3 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TF0001 IN C998TF1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TF0002 IN C998TF2 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TF0003 IN C998TF3 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE BA0001 IN C998BA1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE CP0001 IN C998CP1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE CT0001 IN C998CT1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE PS0001 IN C998PS1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TC0001 IN C998TC1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
Figure 16 (Part 3 of 5). JCL to Create Database

CREATE TABLESPACE TD0001 IN C998TD1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TI0001 IN C998TI1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TR0001 IN C998TR1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TS0001 IN C998TS1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TU0001 IN C998TU1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE OTHR01 IN C998OTHR BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
COMMIT;
Figure 16 (Part 4 of 5). JCL to Create Database
Chapter 6. Creating a New <strong>Baan</strong> Company 43

GRANT DBADM ON DATABASE C998TG1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TG2 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TG3 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TTT TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TP1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TP2 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TP3 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TF1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TF2 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TF3 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998BA1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998CP1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998CT1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998PS1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TC1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TD1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TI1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TR1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TS1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TU1 TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998OTHR TO USRGRP1 WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TG1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TG2 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TG3 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TTT TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TP1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TP2 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TP3 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TF1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TF2 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TF3 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998BA1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998CP1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998CT1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998PS1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TC1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TD1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TI1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TR1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TS1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998TU1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C998OTHR TO BSP WITH GRANT OPTION;
GRANT USE OF STOGROUP BAANGRP2 TO BSP;
GRANT USE OF STOGROUP BAANGRP3 TO BSP;
GRANT USE OF STOGROUP BAANGRP2 TO USRGRP1;
GRANT USE OF STOGROUP BAANGRP3 TO USRGRP1;
//
Figure 16 (Part 5 of 5). JCL to Create Database
6.3 Using <strong>Baan</strong> Tools to Load Data to the New Company
44 <strong>Baan</strong> on OS/390 Implementation Experiences
There are several steps using <strong>Baan</strong> Tools that are necessary to create a new
company. This section covers the S/390 aspects. Someone trained in using
<strong>Baan</strong> Tools should execute these steps. The following sections describe some of
the steps. For more detailed information see documentation on Tools, available
from <strong>Baan</strong>.

6.3.1 Create the Sequential Dump
To create the sequential dump, go to <strong>Baan</strong> Tools and make the following
choices, as shown in Figure 17 and Figure 18 on page 46:
Database Management-->
Database Utilities-->
Create Sequential Dump of Tables
Figure 17. <strong>Baan</strong> Tools Menu to Request Sequential Dumps
Chapter 6. Creating a New <strong>Baan</strong> Company 45

Figure 18. Creating Sequential Dump of Table
After the sequential dump is completed, go back to <strong>Baan</strong> Tools to create the
table making the following choices, as shown in Figure 19:
Database Management-->
Database Utilities-->
Create Table from Sequential Dump
46 <strong>Baan</strong> on OS/390 Implementation Experiences
Figure 19. Create Table from Sequential Dump
Complete this screen with the required information.
Note: To speed up the largest dump file, we could have used the option DEFER
YES on the tg tables. Using this option would mean that the indexes were not
populated during the load phase. At the end of this job, we ran the following
DB2 utility to recover the indexes. This certainly decreased the time required to
load this company, and the recovery job ran quickly as well. See Chapter 7,
“Migrating and Copying <strong>Baan</strong> Company Data” on page 49, for more details.

6.4 Running the <strong>Baan</strong> Tools
6.5 RUNSTATS JCL - Long Job
DEFER YES should not be used in the initial load of Company 000 when youare
using the install6.1 or install6.2 scripts, but it can be used when moving
companies.
If you use DEFER YES as an option when loading a company using <strong>Baan</strong> Tools
(not when using the install6.1 script) or when moving a company, you must run
the DB2 REBUILD utility to rebuild the indexes. To do the move, the bdppost
command was issued for the 14 companies.
We had a S/390 with six engines, so we ran five or six bdppost jobs at a time in
an online mode. This made much more efficient use of the S/390. We thought
the time to run the move of the tg application could be half of the original 15
hours as it was 7.5 MB of the 15 MB of data. But in fact, with the DEFER=YES
option, the time was less than 30 minutes.
There was another option that we did not use as the 30 minutes was satisfactory.
There is a bdpsplit job that would have allowed us to split up the 7.5 MB dump
into three smaller files. Then we could have started three jobs to load the tg
data into the three databases we set up up for the tg application.
At this point there was a job to run using <strong>Baan</strong> Tools to verify that all the tables
were loaded and, if a table was missing, to create it so the package was
complete. Go to <strong>Baan</strong> Tools and make the following selections:
Application Configuration-->
Maintain Companies-->
Click on Application on the Tool Bar-->
Convert to Runtime
To add the missing table after loading from the dump, go to <strong>Baan</strong> Tools and
make the following menu choices:
Database Management-->
Miscellaneous-->
Create Tables
Note: Do not choose recreate index options. This is not necessary for DB2. It
increased the runtime from five minutes to six hours.
After the load tasks were completed, we had to run RUNSTATS as shown in
Figure 20 on page 48:
Chapter 6. Creating a New <strong>Baan</strong> Company 47

RUNSTAT JOB ,,TIME=NOLIMIT,
// REGION=0M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* COMPANY 000 DATABASE C000DB1
//*----------------------------------------------------------------
//RUNSDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
RUNSTATS TABLESPACE C998TG1.TG0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TG2.TG0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TG3.TG0003 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TTT.TTTX01 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TP1.TP0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TP2.TP0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TP3.TP0003 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TF1.TF0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TF2.TF0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TF3.TF0003 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998BA1.BA0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998CP1.CP0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998CT1.CT0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998PS1.PS0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TC1.TC0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TD1.TD0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TI1.TI0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TR1.TR0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TS1.TS0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998TU1.TU0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C998OTHR.OTHR01 TABLE INDEX SHRLEVEL CHANGE
/*
//
Figure 20. Job to Execute RUNSTATS
48 <strong>Baan</strong> on OS/390 Implementation Experiences
Doing this as one long job took one hour. We found it was possible to make it
run faster by splitting the runstats into 14 jobs so they could run simultaneously.
At this point, Company 998 has been loaded and the user testing can be done.

Chapter 7. Migrating and Copying <strong>Baan</strong> Company Data
This section describes the experiences gained while trying to reduce the time to
copy <strong>Baan</strong> company data from an Oracle database on RS/6000 to a DB2
database on OS/390.
The original run was done by creating one large job to move 15 MB of
compacted data in a single stream job. This took approximately 15 hours to
complete and, in fact, DB2 ended abnormally. It was later found that the abend
was due to a 1 GB DB2 thread. DB2 assumes 1 GB is too long for a thread and
causes an abend. To prevent the DB2 abend, you can install PTF UQ19012 and
add the following parameter to the DSN6SPRM section of the DB2 ZPARMS:
CONTSTOR=YES
7.1 Reducing the Time to Move a Company
Following are the steps we took to reduce the time needed to move a company
to approximately two hours:
1. The following recent PTFs were installed to DB2. At this point this was just a
precautionary measure as the dumps had not yet been analyzed.
With GA level of OS/390 R 6, plus the following fixes:
Process Manager UW53711
Open Edition UW54393
Communications Manager UW51307, UQ21379, UW49691, UW53341, UQ20607
DB2 5.1 with service through April 8, 1998, plus the following fixes:
PTFs UQ20185, UQ20574, UQ22003, UQ22004, UQ22331,
UQ2324
2. The dump of the data from the RS/6000 was broken into 14 dumps (by
package). The packages were ba, cp, ct, ps, tc, td, tf, tg, ti, tp, tr, ts, tu, and
tttxt.
This company had been used primarily with the DEM application, so we
found tg, tp, and tttxt were the largest files. In fact, tg was one half of the 15
MB of data.
3. Based on the analysis of the dump data, the following database layout for
Company 200 was agreed to. Then to set up this layout for DB2 and <strong>Baan</strong>,
we created a db2_storage file:
© Copyright IBM Corp. 1999 49

50 <strong>Baan</strong> on OS/390 Implementation Experiences
ba:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200BA1.BA0001
cp:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200CP1.CP0001
ct:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200CT1.CT0001
ps:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200PS1.PS0001
tc:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TC1.TC0001
td:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TD1.TD0001
tfacp:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF1.TF0001
tfacr:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF1.TF0001
tfcal:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF1.TF0001
tfcmg:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF1.TF0001
tffas:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF1.TF0001
tffbs:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF2.TF0002
tffst:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF2.TF0002
tfgld:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF2.TF0002
tfzzz:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF2.TF0002
tf:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TF3.TF0003
tgbrg:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TG1.TG0001
tgeis:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TG1.TG0001
tgerm:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TG1.TG0001
tgtst:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TG2.TG0002
tgwms:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TG2.TG0002
tgwzr:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TG2.TG0002
tg:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TG3.TG0003
ti:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TI1.TI0001
tpbop:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP1.TP0001
tphrs:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP1.TP0001
tpism:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP1.TP0001
tppbs:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP1.TP0001
tppdm:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP1.TP0001
tppin:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP2.TP0002
tpppc:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP2.TP0002
tpprc:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP2.TP0002
tppss:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP2.TP0002
tpptc:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP2.TP0002
tpzzz:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP2.TP0002
tp:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TP3.TP0003
tr:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TR1.TR0001
ts:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TS1.TS0001
tttxt:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TTT.TTTX01
tu:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200TU1.TU0001
*:200:T:group:01:5:OPT_ROWS 5 T_SPACE C200OTHR.OTHR01
tg:200:I::01::STOGROUP BAANGRP3 PRIQTY 12 SECQTY 9600 DEFER YES BUFFERPOOL BP2
tttxt:200:I::01::STOGROUP BAANGRP2 PRIQTY 6040 SECQTY 9600 DEFER YES BUFFERPOOL
BP2
*:200:I::01::STOGROUP BAANGRP3 PRIQTY 12 SECQTY 9600 BUFFERPOOL BP2
Using the global change command for the vi Editor, we changed an existing
db2_storage file by doing the following:
a. Pressing the Esc key.
b. Entering :1,$s/:200/:300/g
This changes 200 to 300 at the beginning of each line.
c. Pressing Esc again.
d. Entering :1,$s/C200/C300/g
This changes C200 to C300 at the end of each line.
e. Entering :wq! to save.
After you follow these steps, you should check whether all the changes
have been made correctly. Note that in the preceding commands, $
means change all lines and g is for global change.
To create the tablespaces and to grant privileges to the bsp user ID, we used
the JCL shown in Figure 21 on page 51.
Note: DSN was the DB2 subsystem name. That matched the entry in the
cmx.conf file we were using.

BALLOC JOB (0513),'BAAN INSTALL',
// TIME=1440,
// NOTIFY=ROOT,
// REGION=0M,
// CLASS=A,
// MSGCLASS=X,
// MSGLEVEL=(1,1)
//* INSTALLATION OS/390 V2R6 (BAAN)
//*
//*--------------------------------------------------------------------
//* GDE: IBM EXTENDED FACILITIES PRODUCT V2R1 INSTALLATION
//* DOC: FMIDS - SIB2110, TIB2111, SSKP122, ASAR55D, SSAT55D, ASAT55D
//*
//*--------------------------------------------------------------------
//*********************************************************************/
//* NAME = BAANDDL */
//* */
//* DESCRIPTIVE NAME = SAMPLE DDL TO CREATE DATABASES & TABLESPACES */
//* FOR BAAN IV INSTALLATION */
//* */
//* STATUS = VERSION 1 */
//* */
//* FUNCTION = THIS JCL PERFORMS THE NECESSARY DDL TO BUILD THE */
//* BAAN IV DB2 DATABASE. THE FOLLOWING DDL MATCHES THE */
//* SETUP SUPPLIED IN THE $BSE/lib/db2/db2_storage FILE. */
//* */
//* ANY CHANGES TO STOGROUP, DATABASE AND/OR TABLESPACE */
//* NAMES REQUIRES THE CORRESPONDING CHANGE IN THE */
//* $BSE/lib/db2/db2_storage FILE. */
//* */
//* YOU MUST UPDATE THE hlq IN THE JOBLIB. */
//* */
//* CHANGE ACTIVITY = */
//*********************************************************************/
//JOBLIB DD DSN=DSN510.SDSNLOAD,DISP=SHR
// DD DSN=DSN510.RUNLIB.LOAD,DISP=SHR
//CREATDDL EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
DSN S(DSN)
RUN PROG(DSNTIAD) PLAN(DSNTIA51)
END
//SYSIN DD *
CREATE STOGROUP BAANGRP2
VOLUMES (V26DB5,V26DB6,V26DB7) VCAT DSN510;
CREATE STOGROUP BAANGRP3
VOLUMES (V26DB8,V26DB9,V26DB0) VCAT DSN510;
COMMIT;
CREATE DATABASE C200TG1
STOGROUP BAANGRP2
BUFFERPOOL BP2;
CREATE DATABASE C200TG2
STOGROUP BAANGRP2
BUFFERPOOL BP2;
Figure 21 (Part 1 of 5). JCL to Create Database, Tablespaces & Execute Grant
Statements
Chapter 7. Migrating and Copying <strong>Baan</strong> Company Data 51

52 <strong>Baan</strong> on OS/390 Implementation Experiences
CREATE DATABASE C200TG3
STOGROUP BAANGRP2
BUFFERPOOL BP2;
CREATE DATABASE C200TTT
STOGROUP BAANGRP3
BUFFERPOOL BP2;
CREATE DATABASE C200TP1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TP2
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TP3
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TF1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TF2
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TF3
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200BA1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200CP1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200CT1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200PS1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TC1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TD1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TI1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TR1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TS1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200TU1
STOGROUP BAANGRP
BUFFERPOOL BP2;
CREATE DATABASE C200OTHR
STOGROUP BAANGRP
BUFFERPOOL BP2;
COMMIT;
Figure 21 (Part 2 of 5). JCL to Create Database, Tablespaces & Execute Grant
Statements

CREATE TABLESPACE TG0001 IN C200TG1 BUFFERPOOL BP4
USING STOGROUP BAANGRP2
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TG0002 IN C200TG2 BUFFERPOOL BP4
USING STOGROUP BAANGRP2
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TG0003 IN C200TG3 BUFFERPOOL BP4
USING STOGROUP BAANGRP2
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TTTX01 IN C200TTT BUFFERPOOL BP4
USING STOGROUP BAANGRP3
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TP0001 IN C200TP1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TP0002 IN C200TP2 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TP0003 IN C200TP3 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TF0001 IN C200TF1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TF0002 IN C200TF2 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TF0003 IN C200TF3 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 50000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE BA0001 IN C200BA1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE CP0001 IN C200CP1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE CT0001 IN C200CT1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE PS0001 IN C200PS1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TC0001 IN C200TC1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
Figure 21 (Part 3 of 5). JCL to Create Database, Tablespaces & Execute Grant
Statements
Chapter 7. Migrating and Copying <strong>Baan</strong> Company Data 53

54 <strong>Baan</strong> on OS/390 Implementation Experiences
CREATE TABLESPACE TD0001 IN C200TD1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TI0001 IN C200TI1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TR0001 IN C200TR1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TS0001 IN C200TS1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE TU0001 IN C200TU1 BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
CREATE TABLESPACE OTHR01 IN C200OTHR BUFFERPOOL BP4
USING STOGROUP BAANGRP
PRIQTY 25000 SECQTY 50000
LOCKSIZE ROW SEGSIZE 32 CLOSE NO;
COMMIT;
Figure 21 (Part 4 of 5). JCL to Create Database, Tablespaces & Execute Grant
Statements

GRANT DBADM ON DATABASE C200TG1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TG2 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TG3 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TTT TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TP1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TP2 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TP3 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TF1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TF2 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TF3 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200BA1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200CP1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200CT1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200PS1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TC1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TD1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TI1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TR1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TS1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TU1 TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200OTHR TO BSPGRP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TG1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TG2 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TG3 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TTT TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TP1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TP2 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TP3 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TF1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TF2 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TF3 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200BA1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200CP1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200CT1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200PS1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TC1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TD1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TI1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TR1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TS1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200TU1 TO BSP WITH GRANT OPTION;
GRANT DBADM ON DATABASE C200OTHR TO BSP WITH GRANT OPTION;
GRANT USE OF STOGROUP BAANGRP2 TO BSP;
GRANT USE OF STOGROUP BAANGRP3 TO BSP;
GRANT USE OF STOGROUP BAANGRP2 TO BSPGRP;
GRANT USE OF STOGROUP BAANGRP3 TO BSPGRP;
//
Figure 21 (Part 5 of 5). JCL to Create Database, Tablespaces & Execute Grant
Statements
Notes:
a. We assumed that executing the GRANT TO GROUP BSPGRP for these new
tables would then allow user ID bsp (which is part of bspgrp) to have
access to these new tables. This did not work and we had to grant bsp
privileges on these new tables. We needed to set up DB2 secondary
authority.
b. To speed up the largest dump file we used the option DEFER YES on the
tg tables. Using this option meant that the indexes were not populated
during the load phase. At the end of this job we ran the following DB2
Chapter 7. Migrating and Copying <strong>Baan</strong> Company Data 55

utility to recover the indexes. This certainly decreased the time required
to load this company and the recovery job ran quickly as well. Figure 22
on page 56 shows the JCL we used to recover the indexes.
As previously described in 6.3.1, “Create the Sequential Dump” on page 45,
DEFER YES should not be used in the initial load of Company 000 when you
are using the install6.1 or install6.2 script, but can be used when moving
companies.
If you use DEFER YES as an option when loading a company using <strong>Baan</strong>
tools or when moving a company, you must run the DB2 REBUILD utility to
rebuild the indexes.
4. Figure 22 shows the JCL we used to rebuild the indexes for the tg
application.
//RECOVTG1 JOB ,,TIME=NOLIMIT,
// REGION=0M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* RECOVER INDEX AFTER LOAD
//*----------------------------------------------------------------
//RBLDDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
REBUILD INDEX (ALL) TABLESPACE C200TG1.TG0001
/*
//
//RECOVTG2 JOB ,,TIME=NOLIMIT,
// REGION=0M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* RECOVER INDEX AFTER LOAD
//*----------------------------------------------------------------
//RBLDDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
REBUILD INDEX (ALL) TABLESPACE C200TG2.TG0002
/*
//
//RECOVTG3 JOB ,,TIME=NOLIMIT,
// REGION=06M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* RECOVER INDEX AFTER LOAD
//*----------------------------------------------------------------
//RBLDDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
REBUILD INDEX (ALL) TABLESPACE C200TG3.TG0003
/*
//
Figure 22. JCL to Rebuild the Indexes
56 <strong>Baan</strong> on OS/390 Implementation Experiences

Again, as previously described in 6.3.1, “Create the Sequential Dump” on
page 45, to move the dump data, the bdbpost6.1 program was executed for
the 14 packages.
We had a S/390 with 6 CPUs, so we ran five or six bdbpost6.1 jobs at a time
in an online mode. This made much more efficient use of the S/390. We
thought the time to run the move of the tg application could be half of the
original 15 hours as it was 7.5 MB of the 15 MB of data. But in fact with the
DEFER=YES option, the time was less than 30 minutes.
There was another option that we did not use as the 30 minutes was
satisfactory: there is a bdbsplit job that would have allowed us to split up the
7.5 MB dump and to start three jobs to load the tg company into the three
databases we set up up for the tg package.
An example of the bdbsplit job is included here in case you have to further
reduce your time to move date. This has been tested and used in the
benchmark runs.
bdbsplit filename (sequential dump)
5. RUNSTATS JCL - long job
After the 14 move jobs had completed, we had to run RUNSTATS as follows:
//RUNSTAT JOB ,,TIME=NOLIMIT,
// REGION=0M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* COMPANY 000 DATABASE C000DB1
//*----------------------------------------------------------------
//RUNSDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
RUNSTATS TABLESPACE C200TG1.TG0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TG2.TG0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TG3.TG0003 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TTT.TTTX01 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TP1.TP0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TP2.TP0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TP3.TP0003 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TF1.TF0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TF2.TF0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TF3.TF0003 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200BA1.BA0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200CP1.CP0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200CT1.CT0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200PS1.PS0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TC1.TC0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TD1.TD0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TI1.TI0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TR1.TR0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TS1.TS0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TU1.TU0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200OTHR.OTHR01 TABLE INDEX SHRLEVEL CHANGE
/*
//
6. RUNSTATS JCL - one of the short jobs
We found it was better to split the runstats into 14 jobs so they could run
simultaneously. Three of these jobs are shown as follows:
Chapter 7. Migrating and Copying <strong>Baan</strong> Company Data 57

7.2 Problem with Creator ID
58 <strong>Baan</strong> on OS/390 Implementation Experiences
//STATTG JOB ,,TIME=NOLIMIT,
// REGION=0M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* COMPANY 000 DATABASE C000DB1
//*----------------------------------------------------------------
//RUNSDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
RUNSTATS TABLESPACE C200TG1.TG0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TG2.TG0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TG3.TG0003 TABLE INDEX SHRLEVEL CHANGE
//STATTT JOB ,,TIME=NOLIMIT,
// REGION=0M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* COMPANY 000 DATABASE C000DB1
//*----------------------------------------------------------------
//RUNSDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
RUNSTATS TABLESPACE C200TTT.TTTX01 TABLE INDEX SHRLEVEL CHANGE
//STATTF JOB ,,TIME=NOLIMIT,
// REGION=0M,MSGCLASS=H,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
//JOBLIB DD DISP=SHR,DSN=SYS1.DSN510.SDSNLOAD
//*----------------------------------------------------------------
//* COMPANY 000 DATABASE C000DB1
//*----------------------------------------------------------------
//RUNSDB1 EXEC PGM=DSNUTILB,PARM=DSN
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
RUNSTATS TABLESPACE C200TF1.TF0001 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TF2.TF0002 TABLE INDEX SHRLEVEL CHANGE
RUNSTATS TABLESPACE C200TF3.TF0003 TABLE INDEX SHRLEVEL CHANGE
At this point there was a job to run using <strong>Baan</strong> tools to complete the
verification of the packages, that all the tables were loaded, and, if a table
was missing, to create it so the package was complete.
We found that Company 200 tables were owned by BSP, not DB2BAAN, which
was the group name in the db2group file.
We had to redo these steps because the first time, we used the uppercase name
GROUP (instead of lowercase group) in the db2_storage file, so <strong>Baan</strong> used the
TSO user ID BSP as the owner instead of the group name DB2BAAN.

Chapter 8. Backup and Recovery of <strong>Baan</strong> DB2 Databases
This chapter addresses the DB2 recovery plans of one <strong>Baan</strong> IV user. The
following recovery environments are addressed by this user's plan:
Normal DB2 Backup and Recovery
This addresses recovery to currency or recovery through the last completed
DB2 unit of recovery that was logged.
Point-in-Time Recovery
This represented the major piece of this user's planning.
Disaster Recovery
The user's disaster recovery plans are reasonable and uncomplicated. The
plans were in development at the time of our analysis, consequently they are
presented at a brief overview level.
8.1 User's Primary Recovery Objectives
The user's primary objective was to develop a general recovery strategy that
would address the needs of recovery to currency, point-in-time recovery, and
disaster recovery. The biggest challenge was point-in-time recovery. From the
strategy to address point-in-time recovery, the requirements for recovery to
currency and disaster recovery were also addressed.
The user's recovery plans are discussed as follows:
A point-in-time overview
This overview presents the options available. Since point-in-time recovery is
the biggest challenge, this section is addressed in the greatest detail.
The user's point-in-time recovery strategy
The user's strategy follows from the available options and his objectives.
The user's recovery to currency and disaster recovery strategy
These are discussed as a logical consequence of his point-in-time strategy.
8.2 DB2/<strong>Baan</strong> IV Point-in-Time Recovery Overview
This overview of point-in-time recovery options is excerpted from Chapter 7 of
ITSO Redbook Installing <strong>Baan</strong> IV <strong>Applications</strong> on OS/390, SG24-5334. You may
refer to that publication for additional point-in-time recovery recommendations.
The usual reason for a point-in-time recovery is an application programming
error or a flawed operational procedure. Unfortunately, this exposure is always
present regardless of your hardware/software configuration. Additionally, a
point-in-time recovery has the potential to be the most disruptive outage you are
likely to encounter.
The reason is that in a <strong>Baan</strong> IV environment, you may have to recover all of the
table spaces and indexes to a prior point in time. Why possibly all objects?
<strong>Baan</strong> does dynamic SQL. You may not be able to determine a subset of tables
to be recovered. To play it safe, you may decide to recover all objects to a prior
© Copyright IBM Corp. 1999 59

point of consistency. Your usual point-in-time recovery techniques, which you
likely regard as conventional at this time, may be insufficient in this environment.
The following sections discuss point-in-time recovery preventive measures and
point-in-time recovery techniques.
8.2.1 Point-In-Time Recovery Preventive Measures
A failure in application development (such as introducing a programming defect)
or in operational procedures (perhaps by running a job twice) introduces the
requirement for point-in-time recovery. The available preventive measures are
increased attention to the following areas:
Change management
Problem management
Testing
Each of these disciplines is procedure-oriented and management-driven. As
attention to these disciplines is increased, the need for point-in-time recovery is
usually decreased. Unfortunately, the need for point-in-time recovery is never
entirely eliminated. Consequently, you will want to make every effort to avoid
having to do a point-in-time recovery, but you should be prepared to do one if
required.
8.2.2 Point-In-Time Recovery Techniques
The concept behind point-in-time recovery is well understood. It usually involves
setting a table or group of tables to a prior point in time when data was
determined to be consistent. The challenge in the <strong>Baan</strong> IV environment is
determining the set of tables that are logically related. It is possible that you will
not be able to determine a subset of the <strong>Baan</strong> IV tables to be reset. You may be
required to reset all <strong>Baan</strong> IV tables to a prior point of consistency. There are
three generally used techniques to effect a point-in-time recovery:
60 <strong>Baan</strong> on OS/390 Implementation Experiences
1. Point-in-time recovery using DB2 utilities
The DB2 Quiesce and Copy utilities are the primary tools.
2. Point-in-time recovery not using DB2 utilities
This is basically a dump/restore scenario.
3. Point-in-time recovery using user-written application programs
8.2.2.1 Point-In-Time Recovery Using DB2 Utilities
The scenario for a point-in-time recovery using DB2 utilities is:
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 <strong>Baan</strong> IV table spaces and indexes.
Execute the QUIESCE utility on all of the tables that are candidates to be
reset if a point-in-time recovery is required.
This establishes a point of consistency and causes the DB2 buffers for the
quiesced tables to be externalized to DASD.
Execute the COPY utility on all of the table spaces that are candidates to be
reset if a point-in-time recovery is required.

The obvious reason for this step is to back up the data. However, COPY will
fail if it cannot externalize the DB2 buffers to DASD. That is the reason we
invoked the QUIESCE utility first (to remove one reason why COPY may fail).
For the second time, execute the QUIESCE utility on all of the tables that are
candidates to be reset if a point-in-time recovery is required.
This invocation of QUIESCE will establish a log RBA which will be the point
of consistency.
When it is necessary to recover to this point of consistency, RECOVER to the
RBA established by the second invocation of the QUIESCE utility.
With the combination of the COPY and the second QUIESCE, the RECOVER
TORBA 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 all
indexes on all of the tables that have been reset to the prior point of
consistency. The indexes must be synchronized with the data in the
recovered table spaces.
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 the
QUIESCE utility, but this can likely be scheduled during off-hours to minimize
the disruption.
There is no disruption to the user when COPY is run with Share-Level
Change.
COPY — Share-Level Change allows updates concurrent with utility
execution.
The recovery of the table spaces will be efficient.
RECOVER TORBA will perform as well as RECOVER TOCOPY, assuming no
logging between the execution of the COPY utility and the second execution
of QUIESCE.
However, there is a significant disadvantage to this scenario: the requirement to
recover potentially many indexes may make this scenario impractical.
8.2.2.2 Point-In-Time Recovery Not Using DB2 Utilities
This scenario will use a DB2 command and a dump/restore utility program.
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 <strong>Baan</strong> IV environment, it may be all of the tables.
Use the DB2 Stop Database command to stop all of the table spaces that are
logically related.
The Stop Database command will cause the DB2 buffers to be externalized
and will cause the VSAM data sets that hold the DB2 data to be closed.
While the table spaces are stopped, the data will be unavailable to users.
Dump the table space and index data sets using your installation high-speed
dump utility.
Chapter 8. Backup and Recovery of <strong>Baan</strong> DB2 Databases 61

You may consider using SnapShot, a program product that runs with the IBM
RAMAC Virtual Array. The dumped data sets represent your point of
consistency.
When it is necessary to recover to this point of consistency, restore the data
sets that were dumped in the previous step.
Because the table spaces are stopped, there will be no outstanding units of
recovery, and the data will be consistent. The data being restored consists
of both the table spaces and the associated indexes.
This scenario is more efficient than the previous one, but preparing for it is more
disruptive to the user. The data is unavailable to the user while the table spaces
are stopped and while the data is being dumped. The duration of the period that
data is unavailable can be lessened by using SnapShot.
8.2.2.3 Point-In-Time Recovery Using User-Written App. Programs
This is a strategic direction and not a scenario. It acknowledges that data can
be corrupted due to program error. If this happens, the support staff may
attempt to correct the contaminated data with application programs. Failing the
ability to correct the data with application programming, a scenario such as one
of those previously described could be used as a last resort. This approach is
gaining favor among users striving for high availability.
In implementing an approach like this, it is important to determine which
transactions will make the data more corrupt or will propagate the errors. This
information then can either be communicated to the end users, or the DBA can
use it to disable the dangerous transactions.
8.3 User's Point-in-Time Recovery Strategy
62 <strong>Baan</strong> on OS/390 Implementation Experiences
The user decided to implement a dual point-in-time recovery strategy. Their
primary strategy is discussed in 8.2.2.2, “Point-In-Time Recovery Not Using DB2
Utilities” on page 61. The user will, on a daily basis, snap the <strong>Baan</strong>/DB2 data.
They have a RAMAC Virtual Array with the SnapShot capability. This is their
preferred point-in-time recovery strategy. The issue at the time of our analysis
was that this user had not finalized the decision to keep the RAMAC Virtual
Array.
The secondary point-in-time recovery strategy is discussed in 8.2.2.1,
“Point-In-Time Recovery Using DB2 Utilities” on page 60. The user will execute
the preparatory portion of this scenario daily.
This secondary strategy exists for several reasons:
This scenario will become the primary point-in-time recovery strategy if the
user decides not to keep the RAMAC Virtual Array.
This offers an option when point-in-time recovery is needed.
It is possible that, based upon the time of the backup, this secondary
scenario could be used if it would minimize the amount of lost data.
Although the timing of the execution of the scenarios had not been
determined, if the primary scenario was executed at midnight and the
secondary scenario was executed at noon, and if a failure occurred in the
early afternoon, this secondary scenario would cause less loss of work.

The image copies taken in this secondary scenario serve the requirements of
recovery to currency.
The combination of the image copies and the quiesce point produced by this
secondary strategy serve as a starting point for the disaster recovery
scenario.
With this dual strategy, the user has two point-in-time recovery options, and is
positioned to address the needs of the recovery-to-currency requirement and the
disaster recovery requirement.
8.4 User's Recovery to Currency Strategy
The user's strategy here is to be prepared. They prepare by taking daily image
copies of the <strong>Baan</strong>/DB2 data. The image copies are taken in the secondary
point-in-time recovery scenario previously discussed.
8.5 User's Disaster Recovery Strategy
The secondary point-in-time recovery strategy addresses the needs for disaster
recovery as well. The image copies and the Quiesce from the secondary
point-in-time scenario will enable a disaster scenario. Of course, the user must
address additional issues in the disaster recovery scenario, like getting a copy of
the DB2 logs off site. Those additional issues were work in process during our
analysis.
Chapter 8. Backup and Recovery of <strong>Baan</strong> DB2 Databases 63

64 <strong>Baan</strong> on OS/390 Implementation Experiences

Chapter 9. Migration to a New <strong>Baan</strong>IVc Porting Set
From time to time, a new release of the porting set (the platform-dependent
code) will be released. The porting set that is current at the time of writing is
PA.0868.
The set of instructions described in this chapter have been generalized to show
the steps that must be performed to update the porting set code. These are
based on the first refresh of the porting set that was released in March 1999.
The original document was intended for use by <strong>Baan</strong>IVc customers on OS/390 to
assist them in migrating from the GA (9/98) level of <strong>Baan</strong> on OS/390 code to the
first refresh (3/99). Major changes in that refresh included:
The EBCDIC file model
A new Connection Manager level (delivered via PTFs UW54946 and UW56882)
A new Process Manager level (delivered via PTF UW56015)
These steps are included here to give you a method to follow for future refreshes
of the porting set. The porting set does not touch any of the <strong>Baan</strong> applications
code.
The steps to perform are:
1. Preinstallation verification
2. Migration and installation
3. Verification
Note: There were additional files on the CD-ROM that were not needed just
for migrating to the new porting set. They were on the CD-ROM to provide a
complete porting set.
Some problems we encountered were:
A globlvar problem.
We had a globlvar problem that was resolved by doing a find command
for globlvar and placing the directory path in $LIBPATH.
A shared memory problem.
We had a shared memory problem that was resolved by changing the
shm_param from OS 390 2.5 to OS 390 2.6.
Format of .profile files.
The .profile files were originally in EBCDIC, so when we did the
ACSII-to-EBCDIC conversion we had to first move the .profile files and
later restore them to the original EBCDIC format. This only happens if
the user profile is part of $BSE.
The license needs to be converted to EBCDIC.
The brand6.1 file needed to be converted from ASCII to EBCDIC.
The new plan needs to have the bind job run and the grant statements
executed.
We could log on with the ba client but not with the bw client.
We had changed the inetd.conf file, but needed to recycle TCP/IP for this
to take effect.
© Copyright IBM Corp. 1999 65

9.1 Pre-Installation Verification
We could not log on with the bw client and user ID bsp.
We had set up a separate plan with dynamicrules(run) for user ID bsp to
be able to load companies. We needed to bind this plan and run the
grant job for this second plan called CMXPRUN. We realized that bsp
was using this plan because when we issued the command echo CMXCONF
it showed the value CMXRUN.CONF. We knew that there were two CMX
configuration files and that both plans needed to have the rebinds and
grants done.
Plan for some extra DASD space. We recommend reserving about 200 MB for
obtaining the new refresh copy of the porting set. Furthermore, you will
temporarily need an extra <strong>Baan</strong> environment (HFS files). To assess how much
DASD you will need for this temporary <strong>Baan</strong> environment, check to see how
many HFSs you have for the <strong>Baan</strong> runtime, and the sizes of each.
For example, if you have three HFSs in your <strong>Baan</strong> runtime environment
(/baanIV/bse/, /baanIV/dict, and /baanIV/bse/audit), you should check the sizes
of each HFS and allocate three additional HFSs of the same size. In this
redbook, the current runtime means your existing <strong>Baan</strong> runtime environment
(/baanIV in our example). The newly allocated HFSs are referred to in this
redbook as the new runtime.
9.1.1 Plan for Some Downtime
We think you should be able to migrate in half a day. You can choose to be
down during all those hours (this is the safest way, and will prevent eventual
loss of log files), or just during cutover (this is not recommended).
9.2 Migration and Installation
We recommend that <strong>Baan</strong> be down during migration. To stop <strong>Baan</strong>, make sure
no one is active by issuing the command ps -ef | grep bshell. This should
return only your own command. Change directory to your $BSE/etc directory,
and issue the rc.stop command. This should close shared memory, and the
printer and license daemons.
Ensure that all <strong>Baan</strong> users are logged off, shared memory is down, and the
Process Manager is down.
Migrating from the <strong>Baan</strong> IVc on OS/390 GA deliverable involves changes to:
Connection Manager
Process Manager
DB2
OS/390
66 <strong>Baan</strong> on OS/390 Implementation Experiences
<strong>Baan</strong> Runtime
Perform the following steps to do the migration:

9.2.1 Connection Manager Changes
1. Save your current DBRMLIB as a backup (for example, if your current
dbrmlib is CMX.SCMXDBRM, save it as CMX.SCMXDBRM.GA).
2. Install PTFs UW54946 (APAR OW36187) and UW56882 (APAR OW37302). You
can REBIND the DBRMLIB after applying UW56882. APAR OW37302 has
++HOLD data that contains information about the installation procedure.
You should look at the ++HOLD data carefully, as it contains pertinent
Connection Manager setup information related specifically to the APAR.
Both APARs have ++HOLD data.
Note: The code contained in the OS/390 UNIX System Services Connection
Scaling kit is integrated into the OS/390 base starting in OS/390 Version 2,
Release 7, but the fixes listed are still required.
3. Make sure that /usr/lpp/cmx/lib is included in the $LIBPATH environment
variable of each user (this is also in ++HOLD data for OW36187). For
example, export LIBPATH=/usr/lpp/cmx/lib:$LIBPATH.
4. Rerun the CMXBIND JCL to bind the DBRMLIB from the APAR installation to
a plan name, or multiple plan names if you have one plan bound with
DYNAMICRULES(RUN) and one with DYNAMICRULES(BIND).
5. Update your CMX config file (the default is /etc/cmx/cmx.conf). You may
have a config file specified with the CMXCONF environment variable, and
this file needs to be changed as well. The item in the config files to change
is DB2PlanName.
6. Update DB2PlanName with the plan name from the bind job.
7. Using a JCL job, or using DB2 SPUFI, you must grant authority to the plan
names you have chosen.
9.2.2 Process Manager Changes
1. Install PTF UW56015. This supersedes all previous Process Manager PTFs.
2. Look at the ++HOLD data and proceed as root, which means at least read
access to the BPX.FILEATTR.PROGCTL RACF facility class profile. This is
required to change extended attributes that are “program-controlled.”
3. Make sure that environment variables are exported as required. For
example,
export PATH=/usr/lpp/bpa/bin:/usr/lpp/bpa/samples:${PATH}
export LIBPATH=/usr/lpp/bpa/lib:${LIBPATH}
export NLSPATH=/usr/lpp/bpa/lib:${NLSPATH}
4. Run the script /usr/lpp/bpa/samples/post_inst_bpa, which backs up your
current configuration to /etc/bpa/bpares.old and changes the
“program-controlled” extended file attributes of the Process Manager
executables and dll.
5. Update your Process Manager config file /etc/bpa/bpares.cfg.
9.2.3 DB2 Changes
1. Install PTFs UQ18604, UQ19012 (APAR PQ14391), and UQ19292. Read the
information in APAR PQ14391 to learn about the use of the storage
contraction support shipped via that APAR.
Chapter 9. Migration to a New <strong>Baan</strong>IVc Porting Set 67

2. If EUR dates are preferred, change the appropriate DB2 DSNHDECP
parameter for date format (DATE=EUR), run the ZPARM job, and recycle
DB2.
3. If the DB2 date format is changed via ZPARM, the following line must be
added to the CMX config file /etc/cmx/cmx.conf:
CCSID“
DB2ccsid=819
DB2datefmt=EUR
The new parameter must match the DB2 setting. The options are ISO, EUR,
USA, and JIS; the default is ISO.
9.2.4 OS/390 Changes
1. For OS/390 Version 2 Release 6 (5647-A01), install PTFs UW49691, UW53341,
UW51307, and UW54393.
2. For OS/390 Version 2 Release 6 Language Environment (5647-A01), install
PTFs UQ23194, UQ24359, UQ21379, and UQ24510.
3. If running without Process Manager, and TCP/IP PTF UQ24539 is installed (or
UQ24540 if you are running OS/390 Version 2, Release 7), you must specify
the -s option in the rexecd line in /etc/inetd.conf. This will force rexec to
read each user's .profile. For example, the exec line in /etc/inetd.conf
should be changed to add the “s” after the “LV”:
exec stream tcp nowait bpxroot /usr/sbin/orexecd rexecd -LVs
9.2.5 <strong>Baan</strong> Runtime HFS Changes
The basic concept is that there will be a CD or CD snapshot that contains the
new executables that will eventually replace your existing $BSE/bin contents.
This is the primary content of the refresh. In addition, this refresh will allow all
<strong>Baan</strong> log and text files to be in EBCDIC, so as to avoid future ASCII-to-EBCDIC
conversion issues. This second piece is accomplished by creating EBCDIC
copies of each HFS in your current <strong>Baan</strong> runtime structure. Following are the
steps we suggest for both the CD refresh update and the HFS EBCDIC
translation.
68 <strong>Baan</strong> on OS/390 Implementation Experiences
1. In the preinstallation step, you put aside 200 MB of additional temporary
space in some HFS. Mount this HFS at some mount point outside the
current <strong>Baan</strong> runtime environment; for example, let us say that it is mounted
at /usr/<strong>Baan</strong>/refreshIVc. FTP the contents of the CD (a portset.pax file) to
this HFS. Unpack the file using the command pax -rf portset.pax. This
creates a subdirectory structure in the file system where you issued the
command, as follows: ln.0000/bse/bin.
In our example, /usr/<strong>Baan</strong>/refreshIVc/ln.0000/bse/bin will now contain the
porting set binaries for the refresh. Leave this as is for now. Later we will
copy this into $BSE/bin.
2. Clean up the current <strong>Baan</strong> file systems (log directory, tmp directory, any
dbs.log file in $BSE, files with “strange names,” and so on).
3. In the preinstallation step, you allocated a new HFS with the same attributes
for each HFS that is part of the existing <strong>Baan</strong> runtime. The next step is to
mount these file systems at the appropriate mount points. In our earlier
example, we had three HFSs:
/baanIV/dict
/baanIV/bse/audit

aanIV/bse/
Following this example, you would create three new mount points for the
three new HFSs, such as:
/baanIVebcdic/dict
/baanIVebcdic/bse/audit
/baanIVebcdic/bse/
Create these mount points using the mkdir command:
mkdir /baanIVebcdic/bse
mkdir /baanIVebcdic/dict
mkdir /baanIVebcdic/bse/audit
Then mount the three new HFSs you have created at the appropriate mount
points in the correct order (from the top down). In our example, first mount
the bse HFS at /baanIVebcdic/bse, then the dict HFS at /baanIVebcdic/dict,
and finally the audit HFS at /baanIVebcdic/bse/audit.
Make sure that after they are mounted, the permission bits on the
directories/mount points match what you have in your current runtime
environment.
4. Next, copy each of your current runtime HFSs into the associated new one.
However, during the copy, there some conversion needs to be specified. We
suggest copying each HFS separately, from the bottom of the tree to the top.
Note the recommended unmount step prior to copying the topmost HFS. In
our example, this means copying the dict and audit HFS first, then the bse
HFS.
These commands will pax all files in the specified directories. The output is
piped into pax, which will unpax the files to EBCDIC into the new HFSs that
have been created and mounted. All characteristics of the files are
preserved.
Following is the syntax of the commands to use, in the order we suggest
using for the example:
a. Copy and convert the current dict HFS in /baanIV/dict to
/baanIVebcdic/dict.
pax -wv /baanIV/dict/* | pax -rv -pe -o
from=ISO8859-1,to=IBM-1047 -s /baanIV/dict/baanIVebcdic/dict/
b. Copy and convert the current audit HFS in
/baanIV/bse/audit to /baanIVebcdic/bse/audit
pax -wv /baanIV/bse/audit/* | pax -rv -pe -o
from=ISO8859-1,to=IBM-1047 -s
/baanIV/bse/audit/baanIVebcdic/bse/audit/
c. Unmount the dict and audit HFS from the current runtime environment:
unmountx /baanIV/dict
unmountx /baanIV/bse/audit
These unmounts can be accomplished using ishell instead of the shell
unmountx command. At this step, if you have other HFSs mounted under
the bse runtime (in our example, /baanIV/bse), copy and convert these
using the same syntax, and unmount them as well. For example, you
may have a /baanIV/bse/tmp HFS.
d. Then copy and convert the bse HFS in /baanIV/bse to /baanIVebcdic/bse:
pax -wv /baanIV/bse/* | pax -rv -pe -o
from=ISO8859-1,to=IBM-1047 -s /baanIV/bse/baanIVebcdic/bse/
Chapter 9. Migration to a New <strong>Baan</strong>IVc Porting Set 69

70 <strong>Baan</strong> on OS/390 Implementation Experiences
5. After completion, you will need to copy files that are original EBCDIC files
from the current runtime into the new runtime. All the files in the $BSE/etc
directory should be copied from your current runtime (/baanIV/bse/etc in our
example) to the new runtime (/baanIVebcdic/bse/etc in our example). If they
exist, you should also copy the setbse script in $BSE, the &/period.kshrc, and
the .profile in $BSE from the current runtime to the new one, at the bse
location. You may also want to copy the $BSE/mswindows directory from the
old to the new runtime.
6. Next you need to copy the porting set refresh code into the new bin
directory.
In Step 1, you FTPed and unpaxed the porting set refresh code into a
temporary HFS of about 200 MB in size. In our example, this was in
/usr/<strong>Baan</strong>/refreshIVc/ln.0000/bse/bin. You will want to copy the entire
contents of this directory into the bin directory of the new runtime
environment. In our example, the bin directory of the new runtime is in
/baanIVebcdic/bse/bin, so copy all files from
/usr/<strong>Baan</strong>/refresh/IVc/ln.0000/bse/bin to /baanIVebcdic/bse/bin.
7. Put the high-use binaries into LPA.
We suggest the following:
<strong>Baan</strong> executables bshell6.1, db2srv61, sort6.1, sh_server6.1
audit_server6.1 globlvar
PM files bpadll, bpassp, bpasspm
CM files cmxdll
There is detailed documentation in the Installation Guide available from
<strong>Baan</strong> on the procedure for adding modules to LPA. This documentation has
sample JCL, as well as instructions on how to determine the module name in
the HFS and how to set the sticky bit.
Following are further examples:
To change the sticky bit, use the following commands:
touch xxxxxxx
chown bsp;bsp *
chmod 755 * all members are executable
chmod +t xxxxxx change sticky bit
Effecting changes to LPA
The SETPROG and dynamic LPA can be used to have the LPA changes
take effect. If dynamic LPA is not used, you may need to re-IPL the
system to pick up the LPA changes.
Changing the extended attributes
You must set the extended attributes Program Control flags for all <strong>Baan</strong>,
PM, and CM executables. First login as root, and then use the following
command on the required modules:
extattr +ps modname
or
extattr +ps *
This should be done for all <strong>Baan</strong> executables in $BSE/bin,
/usr/lpp/bpa/lib/bpadll, /usr/lpp/bpa/bin/bpassp,
/usr/lpp/bpa/bin/bpasspm, and /usr/lpp/cmx/lib/cmxdll.

9.2.6 License
Note: The Process Manager executables and library are set up using the
post_inst_bpa script.
Alter “program-controlled” bits for additional OS/390 DB2 libraries by
issuing:
RALTER PROGRAM ** ADDMEM('SYS1.LINKLIB'/'******'/NOPADCHK +
'SYS1.SCEERUN'/'******'/NOPADCHK +
'SYS1.SEZATCP'/'******'/NOPADCHK +
'SYS1.SEZALINK'/'******'/NOPADCHK +
'DSN510.SDSNLOAD'/'BADB20'/NOPADCHK +
'DSN510.SDSNEXIT'/'BADB20'/NOPADCHK +
'DSN510.SDSNLOAD'/'BADB00'/NOPADCHK +
'DSN510.SDSNEXIT'/'BADB00'/NOPADCHK +
'DSN510B.SDSNLOAD'/'BADBNW'/NOPADCHK +
'DSN510B.SDSNEXIT'/'BADBNW'/NOPADCHK) UACC(READ)
8. Unmount HFS.
The next step is to unmount all HFSs belonging to both the current runtime
and new runtime, and to mount the new runtime environment in a top-down
manner over the old mount points. This is done so that your new runtime
can still preserve the same name. In our example, we would unmount the
following (if not done already):
Current: /baanIV/dict
/baanIV/bse/audit
/baanIV/bse
New: /baanIVebcdic/dict
/baanIVebcdic/bse/audit
/baanIVebcdic/bse
9. Mount HFS.
Mount each HFS data set associated with the new runtime in the appropriate
place:
mountx /baanIV/bse NAME.OF.NEW.BSE.HFS
mountx /baanIV/bse/dict NAME.OF.NEW.DICT.HFS
mountx /baanIV/bse/audit NAME.OF.NEW.AUDIT.HFS
These mounts can be done via the ishell instead of the shell mountx
command.
Once the migration is complete, you may have some license-related error
messages when starting a <strong>Baan</strong> session. The following commands, issued by
root, should solve that problem:
cd $BSE/etc
rc.stop_licd
cat /.brand/.brand6.1 | iconv -f ISO8859-1 -t IBM-1047 > /.brand/.brand6.1
rc.start_licd
Chapter 9. Migration to a New <strong>Baan</strong>IVc Porting Set 71

9.2.7 Variable to Be Set
The new porting set requires a new variable to be set in the .profile file of each
user. To ensure that locks on the database are released, you should add the
environment variable CMX_THREAD_WAIT=0 to the .profile file of the users, and
to the /etc/profile file for root.
9.3 Verification
72 <strong>Baan</strong> on OS/390 Implementation Experiences
You should now be able to restart <strong>Baan</strong> (from the $BSE/etc directory, issue the
rc.start command), and login <strong>Baan</strong> users.
Note: From now on, every time you receive a patch from <strong>Baan</strong> to be
implemented in your working environment, you must remember to convert it
from ASCII to EBCDIC prior to installing it. This also applies to dumps developed
on a different platform that would be imported to your S/390 environment.

Chapter 10. Using Multiple Databases/LPARs
This chapter describes the alternatives you can use in setting up your
production, system test and pre-production (user test) environments. The
alternatives described are in order of least-to-most isolation:
One DB2 subsystem, that is, using a single system/LPAR
Several DB2 subsystems on one LPAR (system)
Multiple DB2 systems on multiple LPARs
Important
A single-system solution with one DB2 subsystem would be implemented by
using different company numbers for the same function on each of the
different <strong>Baan</strong> systems.
Multiple DB2 subsystems on a single system (LPAR) facilitates the handling
of DB2 issues, but does not address situations that arise from sharing the
same UNIX Systems Services.
Multiple LPARs, each with its own DB2, provides the most isolation, but adds
the additional work of maintaining the multiple operating systems and all
their ancillary processes and procedures.
There are several points that should be understood before making this decision.
As one moves from the least isolated to the most isolated alternative, different
issues and solutions present themselves. The first stage is usually to set up a
pilot or training system, so there will be time to weigh the pros and cons of each
alternative. Our experience leads us to favor multiple DB2s on multiple LPARs.
Consider these points when analyzing the alternatives:
A separate DB2 subsystem is recommended just for <strong>Baan</strong> production. One
key reason for this is that <strong>Baan</strong> handles data integrity, so the separate DB2
subsystem alternative offers the best backup and recovery processes.
Each <strong>Baan</strong> system requires the user ID root and bsp for certain functions.
Having all <strong>Baan</strong> environments on the same LPAR would require the
switching of .profiles, thus presenting opportunities for confusion.
<strong>Baan</strong> licensing is for the aggregate of all systems. If, for example, you have
acquired a license for 50 users, this will include your test and training users,
as well as production users. You will have to determine how you will share
the license file.
Sharing the shared memory parameters may cause some conflicts. For
example, the C compiler requires HEAP to be zero, while <strong>Baan</strong> requires it to
be 24 M.
10.1 Using One DB2 Subsystem (One System/LPAR)
You can set up several <strong>Baan</strong> Companies in the same DB2 subsystem, which will
allow different users to test different functions. You can also put <strong>Baan</strong>
application patches only on a particular company so that you can pretest any
application changes before affecting all users. You can have a training
company, make a backup copy, and then easily restore it for the next class.
© Copyright IBM Corp. 1999 73

10.2 Using Two LPARs
For example, one customer had the following companies:
750 and 550 for <strong>Baan</strong> demo companies
200 to load the data
300 to prepare for production
500 to test <strong>Baan</strong> patches
998 for training
The advantage to using a two-LPAR environment is that you can minimize the
impact to users by testing any changes to the following:
OS/390
DB2
The <strong>Baan</strong> Porting Set
TCP/IP
<strong>Baan</strong> <strong>Applications</strong>
Even in the early implementation stages, the end users will have a lot of testing
and training to do and will not be able to tolerate planned outages, except
possibly during evenings or weekends.
To enable the IT team to progress and to be able to quickly make changes to the
production environment, a test LPAR becomes a necessity. It allows the IT team
to minimize the planned outages, gain much needed experience in this new
environment, and become proactive in keeping up with the implementation
schedule.
10.2.1 Using RVA and SnapShot to Clone a Second LPAR
An effective way to set up the test LPAR, if you have RVA and SnapShot, is to do
the following:
74 <strong>Baan</strong> on OS/390 Implementation Experiences
1. Set up the hardware to an LPAR environment.
2. Snap all the production environment.
A sample job is shown in 10.2.2, “Sample JCL to Produce the Snap and
Cloned System” on page 76.
3. Make the minimal changes to denote a new hostname and new IP address.
Modify the IP address for the new LPAR in the profile data set that is used
when you start TCP/IP. Change the IP address in the HOME and statements.
HOME
9.12.2.14 OSAL2160
4. Modify the HOST name in TCPIP.DATA file.
5. Modify the HOST name in /etc/host file.
6. Modify the IP address in /etc/resolv.conf file.
7. Change the snapped volumes ID.
Sample code to do this is shown in 10.2.3, “Rename the Volumes” on
page 79.

8. IPL the second LPAR from the new snapped pack.
You now have a complete cloned system to work with for the test LPAR.
10.2.1.1 Example
The BAANPROD addresses are 300 to 305 and are named VOL001 to VOL005.
The BAANTEST addresses are 400 to 405 and are named TAR001 to TAR005.
The steps are:
1. Prepare the Volumes for the BAANTEST LPAR, using the ICKDSF program to
initialize them offline, on addresses 400 to 405.
2. Submit a SnapShot job to create the Volumes for the BAANTEST LPAR.
3. After the SNAPVOL JOB has worked correctly, put the addresses 400 to 405
of the Volumes for the BAANTEST LPAR offline.
4. Submit a JOB using the REFORMAT command of ICKDSF to change the
volumes on addresses 400 to 405 to the same name as the BAANPROD
Volumes on addresses 300 to 305.
5. IPL the BAANTEST LPAR with the Volumes on addresses 400 to 405.
6. Put production volumes offline.
When you do the IPL you will receive a message telling you that you have
two addresses with Volumes of the same name. You have to specify the
addresses that you want to keep offline. You then answer with the
addresses of the BAANPROD volumes. This will put the addresses of the
BAANPROD Volumes offline. If, after the IPL, someone tries to vary one of
these addresses online, the system will reject it as there is already a volume
online with the same name.
(The next time you IPL the BAANPROD LPAR you will receive the same
message asking you which addresses you would like to keep offline. You
specify the addresses of the BAANTEST LPAR this time.)
7. Create new procedures for the BAANTEST LPAR.
The procedures that need to be created or modified are the ones related to
TCP/IP.
Important
As the Volumes on addresses 400 to 405 are identical to the addresses on
300 to 305, there will be no problem for the CATALOG.
Use CLPA when you do the IPL for the BAANTEST LPAR.
The only point of caution is that the users of the test LPAR must make sure
that they are logged on to the test LPAR, and not the production LPAR, as all
the volumes have the same name and a careless error could destroy the
production environment.
Chapter 10. Using Multiple Databases/LPARs 75

10.2.2 Sample JCL to Produce the Snap and Cloned System
This is the JCL that was used to SNAP volumes from the production LPAR.
76 <strong>Baan</strong> on OS/390 Implementation Experiences
//SNAPSPEC JOB (0513),'SOFT-IBM',
// TIME=1440,
// NOTIFY=SFT02,
// REGION=0M,
// CLASS=A,
// MSGCLASS=X,
// MSGLEVEL=(1,1),TYPRUN=HOLD
//* INSTALLATION OS/390 V2R6 (BAAN)
//*********************************************************************
//*
//* SEE "SYS3.OS390.BAANTEST.LPAR(SNAPVOLP)"
//*
//*********************************************************************
//STEP1 EXEC PGM=SIBBATCH
//*
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD *
SNAP VOLUME( +
SOURCE(VOL(V26TG1)) +
TARGET(VOL(V26910)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26TG2)) +
TARGET(VOL(V26911)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26CAT)) +
TARGET(VOL(V26912)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DL1)) +
TARGET(VOL(V26913)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DL2)) +
TARGET(VOL(V26914)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +

TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26SMS)) +
TARGET(VOL(V26915)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26BA1)) +
TARGET(VOL(V26916)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26BA2)) +
TARGET(VOL(V26917)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26BA3)) +
TARGET(VOL(V26918)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26BA4)) +
TARGET(VOL(V26919)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DBA)) +
TARGET(VOL(V2691A)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DBB)) +
TARGET(VOL(V2691B)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
Chapter 10. Using Multiple Databases/LPARs 77

SOURCE(VOL(V26DB1)) +
TARGET(VOL(V2691C)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB2)) +
TARGET(VOL(V2691D)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB3)) +
TARGET(VOL(V2691E)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB4)) +
TARGET(VOL(V2691F)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26CAU)) +
TARGET(VOL(V26978)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB0)) +
TARGET(VOL(V26979)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB5)) +
TARGET(VOL(V2697A)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB6)) +
TARGET(VOL(V2697B)) +
COPYVOLID(NO) +
78 <strong>Baan</strong> on OS/390 Implementation Experiences

CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB7)) +
TARGET(VOL(V2697C)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB8)) +
TARGET(VOL(V2697D)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26DB9)) +
TARGET(VOL(V2697E)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
SNAP VOLUME( +
SOURCE(VOL(V26PAG)) +
TARGET(VOL(V2697F)) +
COPYVOLID(NO) +
CONDVOL(LBL) +
REPLACE(YES) +
TOLERATEENQFAILURE(Y) +
)
/*
10.2.3 Rename the Volumes
This is the JCL that was used to rename the Volumes on the test LPAR to the
same names that they had on the production LPAR. This is necessary so all the
catalog entries will be correct.
//
//RFMT3101 JOB (0513,SOFT),'SOFT', 00010000
// MSGCLASS=X,CLASS=A,REGION=1024K,NOTIFY=IBMUSER,TIME=1440 00020000
//* 00030000
//RFMT09F0 EXEC PGM=ICKDSF 00031000
//SYSPRINT DD SYSOUT=* 00032000
//SYSABEND DD SYSOUT=* 00033000
//SYSIN DD * 00034000
REFORMAT - 00035000
UNITADDRESS(09F0) - 00036000
VERIFY(V269F0) - 00037100
VOLID(V26TG1) 00038000
/* 00039000
//RFMT09F1 EXEC PGM=ICKDSF 00040000
//SYSPRINT DD SYSOUT=* 00050000
Chapter 10. Using Multiple Databases/LPARs 79

80 <strong>Baan</strong> on OS/390 Implementation Experiences
//SYSABEND DD SYSOUT=* 00060000
//SYSIN DD * 00070000
REFORMAT - 00080000
UNITADDRESS(09F1) - 00090000
VERIFY(V269F1) - 00100000
VOLID(V26TG2) 00110000
/* 00120000
//RFMT09F2 EXEC PGM=ICKDSF 00130000
//SYSPRINT DD SYSOUT=* 00140000
//SYSABEND DD SYSOUT=* 00150000
//SYSIN DD * 00160000
REFORMAT - 00170000
UNITADDRESS(09F2) - 00180000
VERIFY(V269F2) - 00190000
VOLID(V26CAT) 00200000
/* 00210000
//RFMT09F3 EXEC PGM=ICKDSF 00220000
//SYSPRINT DD SYSOUT=* 00230000
//SYSABEND DD SYSOUT=* 00240000
//SYSIN DD * 00250000
REFORMAT - 00260000
UNITADDRESS(09F3) - 00270000
VERIFY(V269F3) - 00280000
VOLID(V26DL1) 00290000
/* 00300000
//RFMT09F4 EXEC PGM=ICKDSF 00310000
//SYSPRINT DD SYSOUT=* 00320000
//SYSABEND DD SYSOUT=* 00330000
//SYSIN DD * 00340000
REFORMAT - 00350000
UNITADDRESS(09F4) - 00360000
VERIFY(V269F4) - 00370000
VOLID(V26DL2) 00380000
/* 00390000
//RFMT09F5 EXEC PGM=ICKDSF 00400000
//SYSPRINT DD SYSOUT=* 00410000
//SYSABEND DD SYSOUT=* 00420000
//SYSIN DD * 00430000
REFORMAT - 00440000
UNITADDRESS(09F5) - 00450000
VERIFY(V269F5) - 00460000
VOLID(V26SMS) 00470000
/* 00480000
//RFMT09F6 EXEC PGM=ICKDSF 00490000
//SYSPRINT DD SYSOUT=* 00500000
//SYSABEND DD SYSOUT=* 00510000
//SYSIN DD * 00520000
REFORMAT - 00530000
UNITADDRESS(09F6) - 00540000
VERIFY(V269F6) - 00550000
VOLID(V26BA1) 00560000
/* 00570000
//RFMT09F7 EXEC PGM=ICKDSF 00580000
//SYSPRINT DD SYSOUT=* 00590000
//SYSABEND DD SYSOUT=* 00600000
//SYSIN DD * 00610000
REFORMAT - 00620000
UNITADDRESS(09F7) - 00630000
VERIFY(V269F7) - 00640000

VOLID(V26BA2) 00650000
/* 00660000
//RFMT09F8 EXEC PGM=ICKDSF 00670000
//SYSPRINT DD SYSOUT=* 00680000
//SYSABEND DD SYSOUT=* 00690000
//SYSIN DD * 00700000
REFORMAT - 00710000
UNITADDRESS(09F8) - 00720000
VERIFY(V269F8) - 00730000
VOLID(V26BA3) 00740000
/* 00750000
//RFMT09F9 EXEC PGM=ICKDSF 00760000
//SYSPRINT DD SYSOUT=* 00770000
//SYSABEND DD SYSOUT=* 00780000
//SYSIN DD * 00790000
REFORMAT - 00800000
UNITADDRESS(09F9) - 00810000
VERIFY(V269F9) - 00820000
VOLID(V26BA4) 00830000
/* 00840000
//RFMT09FA EXEC PGM=ICKDSF 00850000
//SYSPRINT DD SYSOUT=* 00860000
//SYSABEND DD SYSOUT=* 00870000
//SYSIN DD * 00880000
REFORMAT - 00890000
UNITADDRESS(09FA) - 00900000
VERIFY(V269FA) - 00910000
VOLID(V26DBA) 00920000
/* 00930000
//RFMT09FB EXEC PGM=ICKDSF 00940000
//SYSPRINT DD SYSOUT=* 00950000
//SYSABEND DD SYSOUT=* 00960000
//SYSIN DD * 00970000
REFORMAT - 00980000
UNITADDRESS(09FB) - 00990000
VERIFY(V269FB) - 01000000
VOLID(V26DBB) 01010000
/* 01020000
//RFMT09FC EXEC PGM=ICKDSF 01030000
//SYSPRINT DD SYSOUT=* 01040000
//SYSABEND DD SYSOUT=* 01050000
//SYSIN DD * 01060000
REFORMAT - 01070000
UNITADDRESS(09FC) - 01080000
VERIFY(V269FC) - 01090000
VOLID(V26DB1) 01100000
/* 01110000
//RFMT09FD EXEC PGM=ICKDSF 01120000
//SYSPRINT DD SYSOUT=* 01130000
//SYSABEND DD SYSOUT=* 01140000
//SYSIN DD * 01150000
REFORMAT - 01160000
UNITADDRESS(09FD) - 01170000
VERIFY(V269FD) - 01180000
VOLID(V26DB2) 01190000
/* 01200000
//RFMT09FE EXEC PGM=ICKDSF 01210000
//SYSPRINT DD SYSOUT=* 01220000
Chapter 10. Using Multiple Databases/LPARs 81

82 <strong>Baan</strong> on OS/390 Implementation Experiences
//SYSABEND DD SYSOUT=* 01230000
//SYSIN DD * 01240000
REFORMAT - 01250000
UNITADDRESS(09FE) - 01260000
VERIFY(V269FE) - 01270000
VOLID(V26DB3) 01280000
/* 01290000
//RFMT09FF EXEC PGM=ICKDSF 01300000
//SYSPRINT DD SYSOUT=* 01310000
//SYSABEND DD SYSOUT=* 01320000
//SYSIN DD * 01330000
REFORMAT - 01340000
UNITADDRESS(09FF) - 01350000
VERIFY(V26DFF) - 01360000
VOLID(V26DB4) 01370000
/* 01380000
//RFMT0913 EXEC PGM=ICKDSF 01390000
//SYSPRINT DD SYSOUT=* 01400000
//SYSABEND DD SYSOUT=* 01410000
//SYSIN DD * 01420000
REFORMAT - 01430000
UNITADDRESS(0913) - 01440000
VERIFY(V26913) - 01450000
VOLID(V26CAU) 01460000
/* 01470000
//RFMT0914 EXEC PGM=ICKDSF 01480000
//SYSPRINT DD SYSOUT=* 01490000
//SYSABEND DD SYSOUT=* 01500000
//SYSIN DD * 01510000
REFORMAT - 01520000
UNITADDRESS(0914) - 01530000
VERIFY(V26914) - 01540000
VOLID(V26DB0) 01550000
/* 01560000
//RFMT0917 EXEC PGM=ICKDSF 01570000
//SYSPRINT DD SYSOUT=* 01580000
//SYSABEND DD SYSOUT=* 01590000
//SYSIN DD * 01600000
REFORMAT - 01610000
UNITADDRESS(0917) - 01620000
VERIFY(V26917) - 01630000
VOLID(V26DB5) 01640000
/* 01650000
//RFMT0918 EXEC PGM=ICKDSF 01660000
//SYSPRINT DD SYSOUT=* 01670000
//SYSABEND DD SYSOUT=* 01680000
//SYSIN DD * 01690000
REFORMAT - 01700000
UNITADDRESS(0918) - 01710000
VERIFY(V26918) - 01720000
VOLID(V26DB6) 01730000
/* 01740000
//RFMT0919 EXEC PGM=ICKDSF 01750000
//SYSPRINT DD SYSOUT=* 01760000
//SYSABEND DD SYSOUT=* 01770000
//SYSIN DD * 01780000
REFORMAT - 01790000
UNITADDRESS(0919) - 01800000
VERIFY(V26919) - 01810000

VOLID(V26DB7) 01820000
/* 01830000
//RFMT091A EXEC PGM=ICKDSF 01840000
//SYSPRINT DD SYSOUT=* 01850000
//SYSABEND DD SYSOUT=* 01860000
//SYSIN DD * 01870000
REFORMAT - 01880000
UNITADDRESS(091A) - 01890000
VERIFY(V2691A) - 01900000
VOLID(V26DB8) 01910000
/* 01920000
//RFMT091B EXEC PGM=ICKDSF 01930000
//SYSPRINT DD SYSOUT=* 01940000
//SYSABEND DD SYSOUT=* 01950000
//SYSIN DD * 01960000
REFORMAT - 01970000
UNITADDRESS(091B) - 01980000
VERIFY(V2691B) - 01990000
VOLID(V26DB9) 02000000
/* 02010000
//RFMT091C EXEC PGM=ICKDSF 02020000
//SYSPRINT DD SYSOUT=* 02030000
//SYSABEND DD SYSOUT=* 02040000
//SYSIN DD * 02050000
REFORMAT - 02060000
UNITADDRESS(091C) - 02070000
VERIFY(V2691C) - 02080000
VOLID(V26CAV) 02090000
/* 02100000
Chapter 10. Using Multiple Databases/LPARs 83

84 <strong>Baan</strong> on OS/390 Implementation Experiences

Appendix A. Sample Jobs and Script Used with <strong>Baan</strong> <strong>Applications</strong>
This appendix lists sample jobs and scripts that were used by customers in their
<strong>Baan</strong> IV application installations on OS/390.
A.1 Procedures to Start and Stop <strong>Baan</strong> from the Console
These are sample procedures to put in SYS1.PROCLIB that can be used to start
and stop <strong>Baan</strong> from the console.
Note: If you are using Process Manager, you should include the starting and
stopping of it in the rc.start and rc.start shell scripts.
//* To start <strong>Baan</strong>
//BAANSTA EXEC PGM=BPXBATCH,TIME=NOLIMIT,REGION=0M,
// PARM='SH /baanIVc2/bse/etc/rc.start'
//STDERR DD PATH='/tmp/baansta.stderr',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRWXU)
//STDOUT DD PATH='/tmp/baansta.stdout',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRWXU)
//* To stop <strong>Baan</strong>
//BAANSTP EXEC PGM=BPXBATCH,TIME=NOLIMIT,REGION=0M,
// PARM='SH /baanIVc2/bse/etc/rc.stop'
//STDERR DD PATH='/tmp/baanstp.stderr',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRWXU)
//STDOUT DD PATH='/tmp/baanstp.stdout',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=(SIRWXU)
A.2 Script to Convert a File from EBCDIC to ASCII
This is a script we used to change a file comp065_part1 in the /tmp directory
from EBCDIC to ASCII.
cd /tmp/comp065_part1
for j in ¦ls $1*¦
do echo $j
¦iconv -f IBM-1047 -t ISO8859-1 $j > /tmp/$j¦
¦mv /tmp/$j $j¦
done
echo ' DIRECTORY LISTING '
¦ls -1 $1*¦
exit
© Copyright IBM Corp. 1999 85

A.3 Script to Determine the Size of Files to Load with bdppost
This script will give you the exact size of a file (in our case, /tmp/compdata/498).
cd /tmp/compdata/498
#for j in ¦ls -la $1*¦
let fsize=0
ls -la $1* | {
while read a b c d e f g h i;
do
echo $e $i
let fsize="fsize + e"
echo $fsize
# ¦iconv -f IBM-1047 -t ISO8859-1 $j > /tmp/$j¦
# ¦mv /tmp/$j $j¦
done
}
#echo ' DIRECTORY LISTING '
#¦ls -1 $1*¦
exit
A.4 Script to Determine If the HFS Is Almost Full
<strong>Baan</strong> uses HFS files, which can grow with usage. The HFS files should be
monitored to prevent them from reaching 100 percent utilization, which would
affect the availability of the <strong>Baan</strong> application to users. This is a sample script
that can be used to create a monitoring tool.
#!/bin/ksh
#
# This script verifies if one of the following filesystems is full:
#
# -> /
# -> /var
# -> /tmp
# -> /home
# -> /home/root
# -> /usr/local
#
# If one or more filesystem(s) are full (base on the value of the MAX
# variable), a mail is send to root.
#
#
#-----------------------------------------------------------------------------
#
#===================#
# #
# Global variables. #
# #
#===================#
#
MAX=70
LIST="/ /var /tmp /home /home/root /usr/local"
MESSAGE_FILE="/home/root/tmp/message.out"
MESSAGE_FLAG="/home/root/tmp/message.flag"
date > ${MESSAGE_FILE}
86 <strong>Baan</strong> on OS/390 Implementation Experiences

for FS in $LIST
do USED=$(df -k $FS | awk '{ print $4 }' | grep -v Used | tr -d '%')
if $USED -gt $MAX “; then
touch ${MESSAGE_FLAG}
echo "\n\t${FS} is ${USED}% full." >> ${MESSAGE_FILE}
fi
done
if -e ${MESSAGE_FLAG} “; then
mail root < ${MESSAGE_FILE}
rm ${MESSAGE_FLAG}
fi
rm ${MESSAGE_FILE}
exit 0
A.5 Script to Remove Idle Users
The <strong>Baan</strong> system does not have any idle time log off option. Once a user logs
on to <strong>Baan</strong>, the user stays active until an explicit log off is done by that user.
Automatic logging off of inactive users may be desirable for security or licensing
reasons. The following is a sample script that could be used to terminate idle
sessions (users).
#
#
# dpskillb :
# Kills bshells and db2 processes that have been idle for specified amount
# of time. First checks bshell by comparing to previously loaded file of
# users and cpu usage. If cpu usage has not changed, compares db2 process
# to see if cpu usage changed.
#
#
#
# Varibles
# Time in seconds processes are idle before they get killed
WAITTIME=2400
if -z "${BSE}" ‘
then
BSE=/baan4ct/bse
BSE_TMP=${BSE}/tmp
fi
# Specify temp directory for work files
PROCLIST="${BSE}/tmp/dpskillb_prslist"
BSHLLIST="${BSE}/tmp/dpskillb_bshlist"
DB2LLIST="${BSE}/tmp/dpskillb_db2list"
LOGFILE="${BSE}/log/log.dpskillb"
# Create entry in logfile for start of process
echo "*** dpskillb started at ¦date¦ by ${LOGNAME} ***" >>${LOGFILE}
Appendix A. Sample Jobs and Script Used with <strong>Baan</strong> <strong>Applications</strong> 87

# Init files
init_files()
{
>${PROCLIST}
>${BSHLLIST}
>${DB2LLIST}
>${PROCLIST}1
>${BSHLLIST}1
>${DB2LLIST}1
}
collect_data()
{
# Create list of all bshell process
ps -ef ] grep bshell ] grep -v grep ] grep -v GRP ] grep -v SFB >${PROCLIST}
# Create file with 3 fields : 1=User, 2=PID, 3=CPU Time
awk '{print $1 "]" $2 "]" $7}' ${PROCLIST} >${BSHLLIST}
# Create file for DB2 processes running for the bshells.
# and only use 4 fields : 1=USER, 2=PID, 3=Parent PID, 4=CPU Time
# commented out db2 data
#for BSH in ¦awk -F"]" '{print $2}' ${BSHLLIST}¦
#do
# ps -ef ] grep db2 ] grep -v grep ] grep -v GRP ]\
# awk '{if($3 == "'$BSH'"){print $1"]"$2"]"$3"]"$7}}' >>${DB2LLIST}
#done
}
main()
{
# Init files for next loop
init_files
# Get process data for the first time
collect_data
# Wait specified time and get data again
echo "** Wait ${WAITTIME} seconds at ¦date¦." >>${LOGFILE}
sleep ${WAITTIME}
echo "** Wake at ¦date¦." >>${LOGFILE}
PROCLIST=${PROCLIST}1
BSHLLIST=${BSHLLIST}1
DB2LLIST=${DB2LLIST}1
collect_data
PROCLIST="${BSE}/tmp/dpskillb_prslist"
BSHLLIST="${BSE}/tmp/dpskillb_bshlist"
DB2LLIST="${BSE}/tmp/dpskillb_db2list"
check_bshl_times
}
88 <strong>Baan</strong> on OS/390 Implementation Experiences
check_bshl_times()
{
# Compare bshell CPU times
# If the CPU time of the second list has not changed from that of the first
# list, the DB2 CPU time is checked and if it has not changed, the process
# is killed.

while read BSHREC
do FRST_BSHL_TME=¦echo ${BSHREC} ] awk -F"]" '{print $3}'¦
BSHL_USR=¦echo ${BSHREC} ] awk -F"]" '{print $1}'¦
BSHL_PID=¦echo ${BSHREC} ] awk -F"]" '{print $2}'¦
SCND_BSHL_TME=¦awk -F"]" '{if($2 == "'$BSHL_PID'") {print $3}}' ${BSHLLIST}1¦
if "${FRST_BSHL_TME}" = "${SCND_BSHL_TME}" ‘
then
# echo "- check db2 time for ${BSHL_USR} ${BSHL_PID} at ¦date¦" >>${LOGFILE}
check_db2_times
fi
done >${LOGFILE}
echo "bshcmd6.1 -u1 -w1 -e ${BSHL_PID} >>'${LOGFILE}' 2>&1" >>${LOGFILE}
bshcmd6.1 -u1 -w1 -e ${BSHL_PID} >>${LOGFILE} 2>&1
sleep 10
if (ps -ef ] grep bshell ] grep ${BSHL_PID} ] grep -v grep 2>/dev/null)
then
# comment out kill and drop to kill-9
# echo "-- User/Process not killed, use UNIX kill :" >>${LOGFILE}
# echo "kill ${BSHL_PID} >>${LOGFILE} 2>&1 at ¦date¦" >>${LOGFILE}
# kill ${BSHL_PID} >>${LOGFILE} 2>&1
# sleep 10
# if (ps -ef ] grep bshell ] grep ${BSHL_PID} ] grep -v grep 2>/dev/null)
# then
echo "---User/Process not killed, use Unix kill -9:" >>${LOGFILE}
kill -9 ${BSHL_PID} >>${LOGFILE} 2>&1
# fi
fi
#fi
}
main
rm -f ${PROCLIST}
rm -f ${BSHLLIST}
rm -f ${DB2LLIST}
rm -f ${PROCLIST}1
rm -f ${BSHLLIST}1
rm -f ${DB2LLIST}1
# Create finish entry in logfile
echo "*** dpskillb finished at ¦date¦ ***" >>${LOGFILE}
Appendix A. Sample Jobs and Script Used with <strong>Baan</strong> <strong>Applications</strong> 89

90 <strong>Baan</strong> on OS/390 Implementation Experiences

Appendix B. Special Notices
This publication is intended to help those who have installed <strong>Baan</strong> IV or
<strong>Baan</strong>ERP <strong>Applications</strong> on OS/390 with DB2. The information in this publication is
not intended as the specification of any programming interfaces that are
provided by BAAN IV or <strong>Baan</strong>ERP Applcations, or DB2. See the PUBLICATIONS
section of the IBM Programming Announcement for DB2 V5.1 for more
information about what publications are considered to be product documentation.
References in this publication to IBM products, programs or services do not
imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not intended
to state or imply that only IBM's product, program, or service may be used. Any
functionally equivalent program that does not infringe any of IBM's intellectual
property rights may be used instead of the IBM product, program or service.
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact IBM Corporation, Dept.
600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
("vendor") products in this manual has been supplied by the vendor and IBM
assumes no responsibility for its accuracy or completeness. The use of this
information or the implementation of any of these techniques is a customer
responsibility and depends on the customer's ability to evaluate and integrate
them into the customer's operational environment. While each item may have
been reviewed by IBM for accuracy in a specific situation, there is no guarantee
that the same or similar results will be obtained elsewhere. Customers
attempting to adapt these techniques to their own environments do so at their
own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of these
Web sites.
This document contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples contain
the names of individuals, companies, brands, and products. All of these names
© Copyright IBM Corp. 1999 91

are fictitious and any similarity to the names and addresses used by an actual
business enterprise is entirely coincidental.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes available
to each customer according to the normal IBM PTF distribution process.
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
The following terms are trademarks of other companies:
C-bus is a trademark of Corollary, Inc.
92 <strong>Baan</strong> on OS/390 Implementation Experiences
DataJoiner DB2
DFSMS DFSMSdss
IBM OpenEdition
OS/390 RAMAC
S/390 SNAP/SHOT
System/390 S/390 Parallel Enterprise Server
Java and HotJava are trademarks of Sun Microsystems, Incorporated.
Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarks
or registered trademarks of Microsoft Corporation.
PC Direct is a trademark of Ziff Communications Company and is used
by IBM Corporation under license.
Pentium, MMX, ProShare, LANDesk, and ActionMedia are trademarks or
registered trademarks of Intel Corporation in the U.S. and other
countries.
SET and the SET logo are trademarks owned by SET Secure Electronic
Transaction LLC.
UNIX is a registered trademark in the United States and other
countries licensed exclusively through X/Open Company Limited.
Other company, product, and service names may be trademarks or
service marks of others.

Appendix C. Related Publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
C.1 International Technical Support Organization Publications
C.2 Redbooks on CD-ROMs
C.3 Other IBM Publications
For information on ordering these ITSO publications see “How to Get ITSO
Redbooks” on page 95.
Installing <strong>Baan</strong> IV <strong>Applications</strong> on OS/390, SG24-5334
Installing <strong>Baan</strong> ERP <strong>Applications</strong> on OS/390, SG24-5440
Implementing DFSMSdss SnapShot and Virtual Concurrent Copy, SG24-5268
Implementing SnapShot, SG24-2241
IBM RAMAC Virtual Array, SG24-4951
DB2 for OS/390 and Data Compression, SG24-5261
WOW! DRDA Supports TCP/IP: DB2 Server for OS/390 and DB2, SG24-2212
Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs
offered, updates and formats.
CD-ROM Title Collection Kit
Number
System/390 Redbooks Collection SK2T-2177
Networking and Systems Management Redbooks Collection SK2T-6022
Transaction Processing and Data Management Redbooks Collection SK2T-8038
Lotus Redbooks Collection SK2T-8039
Tivoli Redbooks Collection SK2T-8044
AS/400 Redbooks Collection SK2T-2849
Netfinity Hardware and Software Redbooks Collection SK2T-8046
RS/6000 Redbooks Collection (BkMgr Format) SK2T-8040
RS/6000 Redbooks Collection (PDF Format) SK2T-8043
Application Development Redbooks Collection SK2T-8037
IBM Enterprise Storage and Systems Management Solutions SK3T-3694
These publications are also relevant as further information sources:
UNIX System Services Connection Scaling Reference, SA22-7305
SnapShot for MVS/ESA Using SnapShot Version 1 Release 2, SC26-7173
SnapShot for MVS/ESA Installing and Using Version 1 Release 2, SC26-7174
SnapShot for MVS Version 1 Release 2 Installation Notes, SC26-7175
SnapShot for MVS/ESA Implementing SnapShot, SC26-7176
DB2 for OS/390 V5 Administration Guide, Volumes I and II, SC26-8957
DB2 for OS/390 V5 Application Programming and SQL Guide, SC26-8958
DB2 for OS/390 V5 Call Level Interface Guide and Reference, SC26-8959
© Copyright IBM Corp. 1999 93

C.4 <strong>Baan</strong> Publications
DB2 for OS/390 V5 Command Reference, SC26-8960
DB2 for OS/390 V5 Data Sharing: Planning and Administration, SC26-8961
DB2 for OS/390 V5 Installation Guide, GC26-8970
DB2 for OS/390 V5 SQL Reference, SC26-8966
DB2 for OS/390 V5 Utility Guide and Reference, SC26-8967
OS/390 SecureWay Communications Server: IP Configuration, SC31-8513
These publications, available from <strong>Baan</strong>, are also relevant as further information
sources. For information on how to contact <strong>Baan</strong>, go to the following Web site:
http://www.baan.com
94 <strong>Baan</strong> on OS/390 Implementation Experiences
<strong>Baan</strong> IV - Installation Guide for <strong>Baan</strong> IV on OS/390 UNIX System Services
<strong>Baan</strong> IV - DB2 Installation Guide for <strong>Baan</strong> IV
<strong>Baan</strong>ERP - DB2 Installation Guide for <strong>Baan</strong>ERP
<strong>Baan</strong>ERP - Installation Guide for <strong>Baan</strong>ERP on OS/390 UNIX System Services
<strong>Baan</strong>ERP Tools Technical Manual

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

IBM Redbook Fax Order Form
Please send me the following:
Title Order Number Quantity
First name Last name
Company
Address
City Postal code Country
Telephone number Telefax number VAT number
Invoice to customer number
Credit card number
Credit card expiration date Card issued to Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
96 <strong>Baan</strong> on OS/390 Implementation Experiences

List of Abbreviations
AFP advanced function printing
ASCII American National Standard
Code for Information
Interchange
ba <strong>Baan</strong> ASCII client
bi <strong>Baan</strong> Internet client
bw <strong>Baan</strong> Windows client
bx <strong>Baan</strong> Xwindows client
BPX buffer prefix
BSE <strong>Baan</strong> Software Environment
CAF call attach facility
CM Connection Manager
cp Constraint Planning (<strong>Baan</strong>
Application Package)
DB database
DB2 DATABASE 2 (an IBM
relational database
management system)
DEM Dynamic Enterprise Modeling
EBCDIC extended binary coded
decimal interchange code
ERP enterprise resource planning
HFS hierarchical file system
IBM International Business
Machines Corporation
ISPF Interactive System
Productivity Facility
ITSO International Technical
Support Organization
LPA link pack area
OS/390 Operating System (for the)
IBM System/390
PCL printer control language
PM Process Manager
ps Process (<strong>Baan</strong> Application)
RACF Resource Access Control
Facility
RDBMS relational database
management system
RRS resource recovery services
RS/6000 IBM RISC System 6000
RVA RAMAC Virtual Array
S/390 IBM System/390
tc Common (<strong>Baan</strong> Application
Common Package)
td Distribution (<strong>Baan</strong>
Application Package)
tf Finance (<strong>Baan</strong> Application
Package)
tg Orgware (<strong>Baan</strong> Application
Package)
ti Manufacturing (<strong>Baan</strong>
Application Package)
tp Project (<strong>Baan</strong> Application
Package)
tr Transportation (<strong>Baan</strong>
Application Package)
ts Services (<strong>Baan</strong> Application
Package)
tt Tools (<strong>Baan</strong> Application Tools
tu Utilities (<strong>Baan</strong> Application
Utilities)
TCP/IP Transmission Control
Protocol/Internet Protocol
vrc Version Release customer
extension
© Copyright IBM Corp. 1999 97

98 <strong>Baan</strong> on OS/390 Implementation Experiences

Index
A
abbreviations 97
acronyms 97
adding a user to <strong>Baan</strong> 12
B
<strong>Baan</strong> support 5
baan users 7
backup and recovery 59
bibliography 93
C
Connectivity 6
copying companies 49
creating a new <strong>Baan</strong> company 37
D
DB2
DB2 grant statement 23
DB2 security 10
DB2 Subsystem 74
db2_storage File 37
disaster recovery 59, 63
E
EBCDIC to ASCII 85
expiration of passwords 23
H
HFS file systems 25
HFS files 25
I
idle users 87
J
JCL to create database 40
L
license 1
loading data 44
log.brand6.2 5
log.bshell 5
log.db2 5
log.oiex1288 5
log.pdeamon6.2 5
logs 5
LPARS 73
M
management disciplines 60
migrating companies 49
mount point 26
mounting temporary HFS file 27
multiple LPARS 73
N
new <strong>Baan</strong> company 37
P
passwords 23
point-in-time
point-in-time recovery 59
porting set 65
problem tracking 5
procedure 85
to start <strong>Baan</strong> 85
to stop <strong>Baan</strong> 85
process manager 11, 22, 31, 32
bpaprofile 31
problem 32
profiles 73
Q
quiesce utility 61
R
RACF 7
runstats 47
S
sample JCL 85
scripts 85, 87
EBCDIC to ASCII 85
Second LPAR 76
security 6
shared memory 65, 73
sharing an LPAR 73
SnapShot 76
T
test system 73
© Copyright IBM Corp. 1999 99

V
validation of license 3
100 <strong>Baan</strong> on OS/390 Implementation Experiences

ITSO Redbook Evaluation
<strong>Baan</strong> <strong>Applications</strong> on OS/390 Implementation Experiences
SG24-5452-00
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this
questionnaire and return it using one of the following methods:
Use the online evaluation form found at http://www.redbooks.ibm.com/
Fax this form to: USA International Access Code + 1 914 432 8264
Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you?
__Customer __Business Partner __Solution Developer __IBM employee
__None of the above
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction ____________
Please answer the following questions:
Was this redbook published in time for your needs? Yes____ No____
If no, please explain:
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
What other redbooks would you like to see published?
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!)
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
© Copyright IBM Corp. 1999 101

SG24-5452-00
Printed in the U.S.A.
<strong>Baan</strong> <strong>Applications</strong> on OS/390 Implementation Experiences SG24-5452-00