View information on installing DB2 for use with WebSphere Portal.

1. To install DB2 or the DB2 client and the required fix pack, follow the instructions that are provided with the DB2 documentation.
2. If DB2 is installed on another system than WebSphere Portal, perform the following instructions:
   • For JDBC Type 2 drivers only: The appropriate DB2 client must be installed on the same system as WebSphere Portal and have the same name as the server profile name.
   • For JDBC Type 4 drivers only: Copy the driver jar files to the Portal server. It is recommended that you place these driver files within the wp_profile_root directory; for example:
     • wp_profile_root/PortalServer/dbdrivers/db2jcc4.jar
     • wp_profile_root/PortalServer/dbdrivers/db2jcc_license_cu.jar
3. Open the services file on the DB2 system. Ensure that the DB2 instance port was added to the services file during the DB2 installation.
   • Use a text editor to open the file /etc/services.
   • Ensure that DB2_db2inst1 50000/tcp, where db2inst1 is the DB2 instance name, is in the services file. If you do not see DB2_db2inst1 50000/tcp in the services file, add this entry to the services file.
     Note: Ensure that the port number used is not in use. If your port number is already in use, select a different port number.
4. If you are using the JDBC driver in type 2 mode, configure your DB2 client with the following commands. If you are using a remote database, complete this step separately from the WebSphere Portal installation.
   • db2 update dbm cfg using tp_mon_name WAS
   • db2 update dbm cfg using spm_name hostname, where hostname is the host name of WebSphere Portal.
   Because the default for spm_name is the hostname itself, specifying the hostname parameter is optional. If your hostname is more than eight characters, use empty double quotes (" "). For example, db2 update dbm cfg using spm_name " ".

Before transferring the databases to DB2, you must first create the users and groups you have specified in wkplc_dbdomain.properties and assign the users to their corresponding group. The user and group names must comply with both the database management system software requirements and WebSphere Portal requirements.

1. Create a user for dbdomain.DbUser. If you have provided a value in the wkplc_dbdomain.properties file indicating that a runtime user should be used to connect to the database at runtime, create a user for dbdomain.DbRuntimeUser. When creating these users, use the same user ids and passwords entered in the wkplc_dbdomain.properties file.
2. Create a group for dbdomain.DbConfigRoleName. If you have provided a value in the wkplc_dbdomain.properties file for dbdomain.DbRuntimeRoleName, create a group for dbdomain.DbRuntimeRoleName.
3. Assign the created user for dbdomain.DbUser to the created group for dbdomain.DbConfigRoleName.
4. If dbdomain.DbRuntimeUser is specified, assign the created user for dbdomain.DbRuntimeUser to the created group for dbdomain.DbRuntimeRoleName.

You must modify the approriate properties files before transferring your data from the default database to the DB2 database.

1. Locate the following files and create a backup copy of each before changing any values:
   • wp_profile_root/ConfigEngine/properties/wkplc.properties
   • wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties
   • wp_profile_root/ConfigEngine/properties/wkplc_dbtype.properties
   • If you are transferring from a database other than Derby: wp_profile_root/ConfigEngine/properties/wkplc_sourceDb.properties

   Default values are listed in these files. Unless otherwise noted, all values are of type alphanumeric text string. Print out the steps below for reference before modifying the properties files. Make sure to enter the appropriate values for each instance of each property. In wkplc_dbdomain.properties, most properties are repeated for each domain.

2. Use a text editor to open the properties file wkplc_dbdomain.properties and modify the values to correspond to your environment.
   1. For dbdomain.DbType, type db2.
   2. For dbdomain.DbName, type the name of the WebSphere Portal domain database. DB2 database names cannot exceed eight (8) characters.
      Notes:

      • This value is also the database element in the dbdomain.DbUrl property.
      • This value is the TCP-IP alias for the database.
   3. For dbdomain.DbSchema, type the schema name of the database domain.
      Note: Review your target database management system documentation to define a valid schema name. Some database management systems have schema name restrictions that you need to understand.
   4. For dbdomain.DataSourceName, type the name of the data source that WebSphere Portal uses to communicate with its databases. Do not use the following reserved words:
      • releaseDS
      • communityDS
      • customizationDS
      • jcrDS
      • lmdbDS
      • feedback
   5. For dbdomain.DbUrl, type the database URL used to access the WebSphere Portal database with JDBC. The value must conform to the JDBC URL syntax specified by the database.
      Note: The database element of this value should match the value of DbName.
   6. For dbdomain.DbUser, type the user ID for the database configuration user.
   7. For dbdomain.DbPassword, type the password for the database configuration user.
   8. For dbdomain.DbConfigRoleName, type the name of the group for database configuration users. Database rights are granted to this group instead of individuals. The user specified for dbdomain.DbUser must be assigned to this group.
   9. Optional: For dbdomain.DbRuntimeUser, type the user ID of the database user that should be used by WebSphere Portal to connect to the database at runtime. If no value is specified for this setting, the database configuration user will be used to connect to the databases at runtime.
   10. If dbdomain.DbRuntimeUser is specified, you must set dbdomain.DbRuntimePassword to be the password of the runtime database user.
   11. For dbdomain.DbRuntimeRoleName, type the name of the group for database runtime users. Database rights are granted to this group instead of individuals. The user specified for dbdomain.DbRuntimeUser must be assigned to this group.
   12. Optional: For dbdomain.DBA.DbUser, type the database administrator user ID for privileged access operations during database creation. If you do not need this parameter, you can either accept the default value or leave blank.
   13. Optional: For dbdomain.DBA.DbPassword, type the database administrator password for privileged access operations during database creation. If you do not need this parameter, you can either accept the default value or leave blank.
   14. For dbdomain.XDbName, type the database loop back alias that needs to be set if you plan to use the create-database task.
       Note: Required only for local databases using a JDBC Type 2 driver.
   15. For dbdomain.DbNode, type the value for the database node name. Set this value if you want to call create-database.
       Note: Required only for local databases.
3. Save and close the file.
4. Update the following properties in the file wkplc_dbtype.properties.
   1. For db2.DbDriver, type the name of the JDBC driver class.
   2. For db2.DbLibrary, type the directory and name of the .zip or .jar file that contains the JDBC driver class.
   3. For db2.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal uses to communicate with its databases.
5. Save and close the file.
6. Update the WasPassword value in the wkplc.properties file. This value is the password for the WebSphere Application Server security authentication used in your environment.
7. Save and close the file.

You can create the DB2 databases that are required by IBM WebSphere Portal locally or remotely. When you create DB2 databases locally, you can create these databases using a configuration task or you can create these databases manually. When you create the DB2 databases remotely, you can only create the databases manually.

After you have created the DB2 databases, you can set up your databases automatically using a configuration task or manually. The setup path that you choose after your DB2 database is created is independent of whether you created your DB2 databases locally or remotely.

View the steps to set up JCR collation to work with your DB2 database. JCR collation is recommended when the language locales of your users do not natively collate correctly in the DB2 database and when language locale correct ordering is important.

1. Stop the WebSphere Portal server. See Starting and stopping servers, deployment managers, and node agents for instructions.
2. Copy the following files from the WebSphere Portal server to a temporary directory on the DB2 server:

   PortalServer/jcr/wp.content.repository.install/lib/wp.content.repository.install.jar

   wp_profile/PortalServer/jcr/config/registerCollationUDFTemplate.sql

3. Set up collation on the database where the JCR domain is located.
   1. Change to the directory db2_instance_owner_home/sqllib/function.
   2. Run the command:

      db2home/sqllib/java/jdk/bin/jar -xvf temporary location/wp.content.repository.install.jar icm/CollationUDF.class

   3. Change to the temporary directory where you copied the files in a previous step.
   4. Open the file registerCollationUDFTemplate.sql and change all SCHEMA references to the JCR schema; for example, JCR.

      The value set for SCHEMA should match the value set for the jcr.DbSchema property. You specify jcr.DbSchema in the configuration file wkplc_dbdomain.properties when you modify database properties. See Modifying database properties for more information.

   5. Run the following command to connect to the JCR database: db2 connect to jcrdb user user_ID using password.
   6. Run the script with the following command:

      db2 -tvf temporary location/registerCollationUDFTemplate.sql

   7. Disconnect from the JCR database.
   8. Restart the DB2 instance.
4. Verify that the UDF is registered properly.
   1. Log in as the db2instanceID.
      1. Open a DB2 terminal window.
      2. Run the following command: db2 connect to JCRDB user user_ID using password. You must connect to the JCR database as a database runtime user with the user ID and password for the WebSphere Portal JCR data source.
      If the command completes successfully, the UDF is registered correctly as follows: values schema.sortkeyj('abc','en').
5. Edit the icm.properties file, located in wp_profile_root\PortalServer\jcr\lib\com\ibm\icm directory. Add the following section to the end of the file:

   		# Enable/Disable collation support for all DB2 platforms
   		# Disabled by default
   		jcr.query.collation.db2.enabled = true
   
   		# Database specific collation mappings
   		# These mappings apply map a Java locale name into a collation name
   		# supported by the underlying database.
   		# Example mappings for DB2 platform
   
   		# English
   		jcr.query.collation.en = en
   	
   		# Swedish
   		jcr.query.collation.sv = sv
   
   		jcr.query.collation.zh = zh
   		jcr.query.collation.de = de
   		jcr.query.collation.da = da
   		jcr.query.collation.hu = hu
   		jcr.query.collation.jp = jp

6. Start the WebSphere Portal server. See Starting and stopping servers, deployment managers, and node agents for instructions.

This section provides information on how to manually transfer data from the default dataase to the Oracle datase. Follow these steps to transfer WP and Java Content Repository databases to DB2. As an alternative to the manual database transfer procedure described here, you can use the configuration wizard to complete the database transfer task.

1. If you are running a type 2 connection, edit the db2cli.ini file that resides on the local system, where WebSphere Portal is installed, before you transfer data.
   Important: The database transfer becomes unresponsive at task action-process-constraints if you do not complete these steps.
   1. Locate the file /home/db2inst1/sqllib/cfg/db2cli.ini.
   2. Add the following lines to the end of the file:
      Editing db2cli.ini:

      • If a section named [COMMON] already exists in the file, extend that section by adding the following lines. Otherwise, add a [COMMON] section to the file.
      • Leave an empty line after ReturnAliases=0.

      [COMMON]
      DYNAMIC=1
      ReturnAliases=0
      

2. Perform this step only if you are installing multiple instances of WebSphere Portal. Change the maximum number of databases MAX_NETBIOS_CONNECTIONS to increase the default configured number of databases. For example, enter the following command at the database prompt: set client MAX_NETBIOS_CONNECTIONS 254 A message indicates success if the number was increased.
3. Open a command prompt and change to the directory wp_profile_root/ConfigEngine.
4. Using a JDBC Type 2 driver only, export the DB2 user profile that you created when installing DB2 onto the administrative user using the following command. This command exports the DB2 user's profile onto the administrative user so that they can access the DB2 utilities.

   . /home/db2inst1/sqllib/db2profile

   where db2inst1 represents your database instance
   Note: You must complete this step before running database tasks and before enabling security.
5. Enter the ./ConfigEngine.sh validate-database -DWasPassword=password command to validate configuration properties.
   Tip: Add the -DTransferDomainList parameter to the above validating task to specify the domains you want to validate; for example: -DTransferDomainList=jcr. If you want to validate all domains, you do not need to specify this parameter on the command line.
6. From the same command prompt as the previous steps, change to the directory wp_profile_root/bin.
7. Stop both the server1 and WebSphere_Portal servers:
   
   • ./stopServer.sh server1 -username admin_userid -password admin_password
   • ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password
8. Transfer the database:
   Note: Important: Do not execute the database-transfer task as a background process. This might cause the task to stall.
   1. Change to the directory wp_profile_root/ConfigEngine.
   2. Enter the following command:

      ./ConfigEngine.sh database-transfer -DWasPassword=password 

      Note:

      • To select specific database domains to transfer, modify the -DTransferDomainList specified in the command to include only the domains that you want to transfer. For example, to transfer only the JCR domain you can enter the following command: ./ConfigEngine.sh database-transfer -DTransferDomainList=jcr -DWasPassword=password
      • If you have been storing data in Apache Derby for a long time, database transfer could fail with OutOfMemory exceptions. If database transfer fails, add the following property to the command in this step: ConfigEngine.bat database-transfer -DDbtJavaMaxMemory=1536M -DWasPassword=password
   3. After running the task, a message is added to the following log file for you to verify the task ran successfully: wp_profile_root/ConfigEngine/log/ConfigTrace.log If the configuration fails, verify the values in the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties files and then repeat this step.
9. Optional: If you specified a runtime database user for the dbdomain.DbRuntimeUser parameter, that user must have sufficient database user privileges. To grant the database user privileges, choose either the manual steps or the command line steps:
   1. Complete these steps to manually grant database user privileges:
      1. Copy the appropriate template files to a work directory. Choose one of the following template files:
         • createRuntimeRoleForDifferentSchema.sql if the name of the database user and the schema name are not the same.
         • createRuntimeRoleForSameSchema.sql if the name of the database user and the schema name are the same.
         JCR database domain: For the JCR database domain, you must also copy grantExtendedPermissionsToRuntimeRole.sql.
         Locate these files in the following directories:
         • PortalServer_root/base/wp.db.impl/config/templates/setupdb/dbms/domain
         • PortalServer_root/pzn/prereq.pzn/config/templates/setupdb/dbms/domain
      2. Replace all placeholder values with the values as defined in wkplc_comp.properties. Placeholder values are surrounded by the character @.
      3. Run these statements.
   2. Complete these steps to grant database user privileges with the ConfigEngine task:
      1. Ensure the database administrator user ID is specified for domain.DBA.DbUser in wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties. For example, domain.DBA.DbUser=dbadmin.
      2. Run the following task: ./ConfigEngine.sh grant-runtime-db-user-privileges -DTransferDomainList=comma_separated_list_of_domains
10. After transferring the database tables, perform a reorg check to improve performance. Perform this step for each database alias in the property file.
    1. Connect to a database with the following command:

       db2 connect to database_alias user db2admin_userid
        using password

       Note: Additional options might be required if additional security has been installed. Refer to DB2 Universal Database commands by example for links to the command reference.
    2. After it is connected, run the following commands from the DB2 prompt:

       db2 reorgchk update statistics on table all > xyz.out

    3. Look in the reorg column for entries marked with a star or asterisk * in the file xyz.out.
       1. For each line with *, note the tablename and run the following command for each tablename:
          • db2 reorg table tablename
       2. After you have run the reorg command for each tablename, run the following commands:
          • db2 terminate
          • db2rbind database_name -l db2rbind.out -u db2_admin
          • -p password
    4. The output file db2rbind.out is only created when there is an error for the db2rbind command.
11. Run the ./ConfigEngine.sh create-jcr-jms-resources-post-dbxfer -DWasPassword=password command to create JMS resources in the new database.
    Note: Regardless of the method used to transfer data (configuration wizard or the steps in this topic), you must run this task to create JMS resources.
12. Change to the directory wp_profile_root/bin.
13. Start the WebSphere Portal server. See Starting and stopping servers, deployment managers, and node agents for instructions.

If you are using Web Content Management, you must update the database configuration to support large files. Do this by setting the fullyMaterializeLobData property in the WebSphere Application Server administrative console.

1. Log into the WebSphere Application Server administrative console.
2. Click Resources > JDBC > Data sources.
3. Select all scopes (the default setting) or select a specific cell, node, or node/server. Select the scope that corresponds to your instance of WebSphere Portal. The view refreshes.
4. Select the name of the data source that is defined in wkplc_dbdomain.properties for the JCR database domain. The default data source is wpdbDS.
5. Click Custom properties.
6. Ensure that the fullyMaterializeLobData property is set to false.

WebSphere Portal requires the use of either the IBM DB2 Legacy JDBC driver in type 2 mode or the IBM DB2 Universal JDBC driver in type 4 mode when connecting to DB2.

1. Open a command prompt and change to the directory wp_profile_root/ConfigEngine.
2. Using a JDBC Type 2 driver only, export the DB2 user profile that you created when installing DB2 onto the administrative user using the following command. This command exports the DB2 user's profile onto the administrative user so that they can access the DB2 utilities.

   . /home/db2inst1/sqllib/db2profile

   where db2inst1 represents your database instance
   Note: You must complete this step before running database tasks and before enabling security.
3. Enter the ./ConfigEngine.sh validate-database -DWasPassword=password command to validate configuration properties.
   Tip: Add the -DTransferDomainList parameter to the above validating task to specify the domains you want to validate; for example: -DTransferDomainList=jcr. If you want to validate all domains, you do not need to specify this parameter on the command line.
4. From the same command prompt as the previous steps, change to the directory wp_profile_root/bin.
5. Stop both the server1 and WebSphere_Portal servers:
   
   • ./stopServer.sh server1 -username admin_userid -password admin_password
   • ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password
6. Change to the directory wp_profile_root/ConfigEngine.
7. To change from one supported driver to the other, run the following task to connect the database, including only the domains that require the switch.

   ./ConfigEngine.sh connect-database -Drelease.DbPassword=password
    -Dcustomization.DbPassword=password -Dcommunity.DbPassword=password
    -Djcr.DbPassword=password -Dfeedback.DbPassword=password
    -Dlikeminds.DbPassword=password
   -DWasPassword=password

8. Change to the directory wp_profile_root/bin.
9. Start the WebSphere Portal server. See Starting and stopping servers, deployment managers, and node agents for instructions.

Learn how to modify the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties files to work with your database. Modify these property files before running tasks to create databases, create users, or transfer data.

1. Locate the following files and create a backup copy of each before changing any values:
   • wp_profile_root/ConfigEngine/properties/wkplc.properties
   • wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties
   • wp_profile_root/ConfigEngine/properties/wkplc_dbtype.properties
   • If you are transferring from a database other than Derby: wp_profile_root/ConfigEngine/properties/wkplc_sourceDb.properties

   Default values are listed in these files. Unless otherwise noted, all values are of type alphanumeric text string. Print out the steps below for reference before modifying the properties files. Make sure to enter the appropriate values for each instance of each property. In wkplc_dbdomain.properties, most properties are repeated for each domain.

2. Use a text editor to open the properties files and enter the values that are appropriate for your environment. You can also modify each properties file locally on your System i5 system by typing the following on an OS/400 command line in a 5250 session:
   Note: This step only applies when WebSphere Portal is installed on IBM i, and you are transferring to IBM DB2 for i.

   EDTF 'wp_profile_root/ConfigEngine/properties/property filename.properties'

   where property filename is wkplc_dbdomain, wkplc, or wkplc_dbtype.

   Note: You must have a user profile on the IBM i server and must have at least *USE special authority to edit the properties file.
   Tip: The steps for transferring data to another supported database section provide instructions for manually transferring data. Instead of performing the following steps, you can use the configuration wizard, which is a graphical user interface, to transfer data to another supported database.

   Properties must be changed before creating a database name and schema on a local or remote IBM i server.

3. Use a text editor to open the properties file wkplc_dbdomain.properties and modify the values to correspond to your environment.
   1. For dbdomain.DbType, type db2_iseries.
   2. For dbdomain.DbName, type the name of the WebSphere Portal domain database.
      Note: This value is also the database element in the dbdomain.DbUrl property.
   3. For dbdomain.DbSchema, type the schema name of the database domain.
      Note: Review your target database management system documentation to define a valid schema name. Some database management systems have schema name restrictions that you need to understand.
   4. For dbdomain.DataSourceName, type the name of the data source that WebSphere Portal uses to communicate with its databases. Do not use the following reserved words:
      • releaseDS
      • communityDS
      • customizationDS
      • jcrDS
      • lmdbDS
      • feedback
   5. For dbdomain.DbUrl, type the database URL used to access the WebSphere Portal database with JDBC. The value must conform to the JDBC URL syntax specified by the database. The connection property metadata source=1 must be specified for databases running on systems older than IBM i V7R1. Refer to the following example when WebSphere Portal is installed on IBM i and you transferring data remotely or locally to IBM DB2 for i: dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1" Refer to the following example when WebSphere Portal is installed on Windows and you transferring data remotely to IBM DB2 for i dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1" Refer to the following example when WebSphere Portal is installed on a UNIX platform, and you are transferring data to IBM DB2 for i: dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1;prompt=false" If the X11 DISPLAY is set and active, do not add the ;prompt=false to the URL.
      Note: The database element of this value should match the value of DbName.
   6. For dbdomain.DbUser, type the user ID for the database configuration user.
   7. For dbdomain.DbPassword, type the password for the database configuration user.
   8. For dbdomain.DbConfigRoleName, type the name of the group for database configuration users. Database rights are granted to this group instead of individuals. The user specified for dbdomain.DbUser must be assigned to this group.
   9. Optional: For dbdomain.DbRuntimeUser, type the user ID of the database user that should be used by WebSphere Portal to connect to the database at runtime. If no value is specified for this setting, the database configuration user will be used to connect to the databases at runtime.
   10. If dbdomain.DbRuntimeUser is specified, you must set dbdomain.DbRuntimePassword to be the password of the runtime database user.
   11. For dbdomain.DbRuntimeRoleName, type the name of the group for database runtime users. Database rights are granted to this group instead of individuals. The user specified for dbdomain.DbRuntimeUser must be assigned to this group.
   12. Optional: For dbdomain.DBA.DbUser, type the database administrator user ID for privileged access operations during database creation. If you do not need this parameter, you can either accept the default value or leave blank.
   13. Optional: For dbdomain.DBA.DbPassword, type the database administrator password for privileged access operations during database creation. If you do not need this parameter, you can either accept the default value or leave blank.
4. Save and close the file.
5. Update the following properties in the file wkplc_dbtype.properties.
   Note: You must download the jt400.jar file prior to database transfer. Refer to wkplc_dbtype.properties for more information on downloading the jt400.jar file.
   1. For db2_iseries.DbDriver, type the name of the JDBC driver class.
   2. For db2_iseries.DbLibrary, type the directory and name of the .zip or .jar file that contains the JDBC driver class.
   3. For db2_iseries.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal uses to communicate with its databases.
   4. For db2_iseries.DbDriverType, type the number representing the driver type for the database.
6. Save and close the file.
7. Update the WasPassword value in the wkplc.properties file. This value is the password for the WebSphere Application Server security authentication used in your environment.
8. Save and close the file.

View information on setting up user profiles for IBM DB2 for i to work with WebSphere Portal.

This section provides information on using a ConfigEngine task to create and setup IBM DB2 for i databases and users.

1. Change to the directory wp_profile_root/ConfigEngine
2. To create the databases, type the following command:
   • ./ConfigEngine.sh create-database -DWasPassword=password

View the steps to manually transfer data to the IBM DB2 Universal Database for i database you have set up. As an alternative to the manual database transfer procedure described here, you can use the configuration wizard to complete the database transfer task. However, you cannot specify all settings through the configuration wizard. For example, regardless of the method used to transfer data, you must run a configuration task to create JMS resources as described in this topic.

1. Stop both the server1 and WebSphere_Portal servers:
   
   • stopServer server1 -username admin_userid -password admin_password
   • stopServer WebSphere_Portal -username admin_userid -password admin_password
2. Validate configuration properties using the ConfigEngine.sh validate-database -DWasPassword=password command.
   Tip: Add the -DTransferDomainList parameter to the above validating task to specify the domains you want to validate; for example: -DTransferDomainList=jcr. If you want to validate all domains, you do not need to specify this parameter on the command line.
3. Transfer the database:
   Note: Important: Do not execute the database-transfer task as a background process. This might cause the task to stall.
   1. Enter the following command:

      ConfigEngine.sh database-transfer -DWasPassword=password

      Note:

      • To select specific database domains to transfer, modify the -DTransferDomainList specified in the command to include only the domains that you want to transfer. For example, to transfer only the JCR domain you can enter the following command: ./ConfigEngine.sh database-transfer -DTransferDomainList=jcr -DWasPassword=password
      • This note only applies when transferring databases from IBM DB2 for i to another server with IBM DB2 for i. If you are transferring databases from a database other than IBM DB2 for i, you can skip this note. Use SBMJOB to submit the Qshell script as a batch job to run in *BASE pool when *INTERACT pool does not have 1GB or more of allocated memory. For example: SBMJOB CMD(STRQSH CMD(ConfigEngine.sh database-transfer -DWasPassword=password))
   2. After running the task, a message is added to the following log file for you to verify the task ran successfully: wp_profile_root/ConfigEngine/log/ConfigTrace.log If the configuration fails, verify the values in the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties files and then repeat this step.
4. Run the ConfigEngine.sh create-jcr-jms-resources-post-dbxfer -DWasPassword=password command to create JMS resources in the new database.
   Note: Regardless of the method used to transfer data (configuration wizard or the steps in this topic), you must run this task to create JMS resources.
5. Start the WebSphere Portal server. See Starting and stopping servers, deployment managers, and node agents for instructions.

After WebSphere Portal is configured to work with your database, test the database connection to ensure that it operates correctly.

1. Open a command line on the local machine whereWebSphere Portal is installed.
2. For WebSphere Portal on WebSphere Application Server (UserData path), enter the following on the command line: cd wp_profile_root/ConfigEngine.
3. Enter the following command:

   ConfigEngine.sh validate-database-connection -DTransferDomainList=release,community,customization,jcr,feedback,likeminds -DWasPassword=password

View information on how to install DB2 for z/OS for use with IBM WebSphere Portal.

This section provides information on how to modify the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties files to work with your database. Modify these property files before running tasks to create databases, create users, or transfer data.

db2 subsystem prefix display ddf

1. Locate the following files and create a backup copy of each before changing any values:
   • wp_profile_root/ConfigEngine/properties/wkplc.properties
   • wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties
   • wp_profile_root/ConfigEngine/properties/wkplc_dbtype.properties
   • If you are transferring from a database other than Derby: wp_profile_root/ConfigEngine/properties/wkplc_sourceDb.properties

   Default values are listed in these files. Unless otherwise noted, all values are of type alphanumeric text string. Print out the steps below for reference before modifying the properties files. Make sure to enter the appropriate values for each instance of each property. In wkplc_dbdomain.properties, most properties are repeated for each domain.

2. Use a text editor to open the properties file wkplc_dbdomain.properties and modify the values to correspond to your environment.
   1. For dbdomain.DbType, type db2_zos.
   2. For dbdomain.DbName, type the name of the WebSphere Portal domain database.
      Note: This value is also the database element in the dbdomain.DbUrl property.
   3. For dbdomain.DbSchema, type the schema name of the database domain.
      Note: Review your target database management system documentation to define a valid schema name. Some database management systems have schema name restrictions that you need to understand.
   4. For dbdomain.DbNameOnZos, type the name of the WebSphere Portal database on DB2 for z/OS.
      Note:

      • If running DB2 for z/OS as a remote database, set the value to the name of the remote database for the domain.
      • If WebSphere Portal is running on z/OS with DB2 for z/OS, set the value equal to the value of DbName.
   5. For dbdomain.DataSourceName, type the name of the data source that WebSphere Portal uses to communicate with its databases. Do not use the following reserved words:
      • releaseDS
      • communityDS
      • customizationDS
      • jcrDS
      • lmdbDS
      • feedback
   6. For dbdomain.DbUrl, type the database URL used to access the WebSphere Portal database with JDBC. The value must conform to the JDBC URL syntax specified by the database.
      Note: The database element of this value should match the value of DbName.
   7. For dbdomain.DbUser, type the user ID for the database configuration user.
   8. For dbdomain.DbPassword, type the password for the database configuration user.
   9. For dbdomain.DbConfigRoleName, type the name of the group for database configuration users. Database rights are granted to this group instead of individuals. The user specified for dbdomain.DbUser must be assigned to this group.
   10. Optional: For dbdomain.DbRuntimeUser, type the user ID of the database user that should be used by WebSphere Portal to connect to the database at runtime. If no value is specified for this setting, the database configuration user will be used to connect to the databases at runtime.
   11. If dbdomain.DbRuntimeUser is specified, you must set dbdomain.DbRuntimePassword to be the password of the runtime database user.
   12. For dbdomain.DbRuntimeRoleName, type the name of the group for database runtime users. Database rights are granted to this group instead of individuals. The user specified for dbdomain.DbRuntimeUser must be assigned to this group.
   13. For dbdomain.DbTablespace, type the name of the DB2 for z/OS tablespace.
   14. For dbdomain.DbStorageGroup, type the name of the storage group for the database.
   15. For dbdomain.DbVolumes, type the volumes for the database.
   16. For dbdomain.DbVcat, type the VCAT for the database.
   17. For dbdomain.Db4KBufferPoolName, type the 4K bufferpool name for the database.
   18. For dbdomain.Db32KBufferPoolName, type the 32K bufferpool name for the database.
   19. For dbdomain.DbIndex4KBufferPoolName, type the 4K bufferpool name for the database. If you choose to use the default bufferpool value BP3, verify that this bufferpool is active.
   20. For dbdomain.TablespaceTrackMod , set the value to determine TRACKMOD attribute of all tablespaces to use the specified value. Refer to the DB2 for z/OS documentation before changing this value.
3. Save and close the file.
4. Update the following properties in the file wkplc_dbtype.properties.
   1. For db2_zos.DbDriver, type the name of the JDBC driver class.
   2. For db2_zos.DbLibrary, type the directory and name of the .zip or .jar file that contains the JDBC driver class.
   3. For db2_zos.JdbcProviderName, type the name of the JDBC provider that WebSphere Portal uses to communicate with its databases.
   4. For db2_zos.DbDriverType, type the number of the driver type for the database.
5. Save and close the file.
6. Update the WasPassword value in the wkplc.properties file. This value is the password for the WebSphere Application Server security authentication used in your environment.
7. Save and close the file.

Create users for IBM DB2 Universal Database for z/OS to work with IBM WebSphere Portal.

1. Create all database user IDs in the security product you are using on z/OS. For jcrschema, the database schema name for IBM Java Content Repository data, create a group and connect it to the database user ID for Java Content Repository data, jcr. The following sample shows the RACF definition of such a user ID and group, where jcr is the database user ID for Java Content Repository data, yourDefaultUserGroup is your default RACF group for database user IDs, jcrschema is the database schema name for Java Content Repository data, and yourDefaultGroup is your default RACF group for groups. If you have some other security product such as Top Secret or ACF2 instead of RACF, translate the sample RACF definition into the appropriate syntax before running the job.

   ADDUSER jcr DFLTGRP(yourDefaultUserGroup) NAME('WAS DB2 ACCESS USER')
   PW USER(jcr) NOINTERVAL
   ALU jcr PASSWORD(********) NOEXPIRED
   ADDGROUP jcrschema SUPGROUP(yourDefaultGroup)
   CONNECT jcr GROUP(jcrschema)

2. Run the following SQL statements using a tool like SPUFI while logged on to the DB2 subsystem to grant appropriate rights on the newly created databases. If you are configuring multiple WebSphere Portal instances to use a single DB2 for z/OS subsystem, be sure to use the database user associated with the WebSphere Portal instance you are setting up.

   (C) create/alter tablespaces
   (C) create/alter tables
   (C) create/alter indice;
   (C+R) read/write data 
   
   (C) - at configuration time 
   (R) - at runtime 
   
   GRANT USE OF ALL BUFFERPOOLS TO releaseusr;
   GRANT USE OF ALL BUFFERPOOLS TO communityusr;
   GRANT USE OF ALL BUFFERPOOLS TO customizationusr;
   
   GRANT DBADM ON DATABASE jcrdbnameonzos TO jcr;
   GRANT USE OF ALL BUFFERPOOLS TO jcr;
   GRANT DBADM ON DATABASE fdbkdbnameonzos TO feedback;
   GRANT USE OF ALL BUFFERPOOLS TO feedback;
   GRANT DBADM ON DATABASE lmdbnameonzos TO lmdbusr;
   GRANT USE OF ALL BUFFERPOOLS TO lmdbusr;
   GRANT SELECT ON SYSIBM.SYSCOLUMNS TO releaseusr;
   GRANT SELECT ON SYSIBM.SYSCOLUMNS TO communityusr;
   GRANT SELECT ON SYSIBM.SYSCOLUMNS TO customizationusr;
   
   GRANT SELECT ON SYSIBM.SYSTABLES TO releaseusr;
   GRANT SELECT ON SYSIBM.SYSTABLES TO communityusr;
   GRANT SELECT ON SYSIBM.SYSTABLES TO customizationusr;
   
   GRANT SELECT ON SYSIBM.SYSCOLUMNS TO jcr;
   GRANT SELECT ON SYSIBM.SYSTABLES TO jcr;
   GRANT SELECT ON SYSIBM.SYSCOLUMNS TO fdbkdbusr;
   GRANT SELECT ON SYSIBM.SYSTABLES TO fdbkdbusr;
   GRANT SELECT ON SYSIBM.SYSCOLUMNS TO lmdbusr;
   GRANT SELECT ON SYSIBM.SYSTABLES TO lmdbusr;
   GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO releaseusr;
   GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO communityusr;
   GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO customizationusr;
   
   GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO jcr;
   GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO fdbkdbusr;
   GRANT SELECT ON SYSIBM.SYSFOREIGNKEYS TO lmdbusr;
   GRANT SELECT ON SYSIBM.SYSRELS TO releaseusr;
   GRANT SELECT ON SYSIBM.SYSRELS TO communityusr;
   GRANT SELECT ON SYSIBM.SYSRELS TO customizationusr;
   
   GRANT SELECT ON SYSIBM.SYSRELS TO jcr;
   GRANT SELECT ON SYSIBM.SYSRELS TO fdbkdbusr;
   GRANT SELECT ON SYSIBM.SYSRELS TO lmdbusr;
   GRANT USE OF STOGROUP jcrstogroup TO jcr;
   GRANT CREATEIN, DROPIN ON SCHEMA jcrschema TO jcr;
   GRANT SELECT ON SYSIBM.SYSTABLESPACE TO jcr;
   GRANT SELECT ON SYSIBM.SYSVIEWS TO jcr;
   GRANT SELECT ON SYSIBM.SYSTRIGGERS TO jcr;
   GRANT SELECT ON SYSIBM.SYSINDEXPART TO jcr;
   GRANT SELECT ON SYSIBM.SYSINDEXES TO jcr;
   GRANT SELECT ON SYSIBM.SYSSYNONYMS TO jcr;

   where:
   • releasenameonzos, communitynameonzos, customizationnameonzos, and releaseusr, communityusr, customizationusr represent the databases and database users, respectively, of the WebSphere Portal instance you are setting up. (These users must be created on the host system.)
   • jcrdbnameonzos and jcr are the database and database user, respectively, for Content Repository data.
   • fdbkdbnameonzos and feedback are the database and database user, respectively, for Feedback data.
   • lmdbnameonzos and lmdbusr are the database and database user, respectively, for Likeminds data.
   • jcrschema is the database schema name for Content Repository data.
3. Grant the necessary access rights to all users who might require them. Depending on the architecture that you choose, these users might include Java Content Repository and Feedback users.