+

Search Tips   |   Advanced Search

Linux clustered server: Configure the portal to use DB2 for z/OS


View information on manually transferring data to theDB2 for z/OS you have installed and set up. Follow these steps to transfer WebSphere Portal, and Java Content Repository to DB2 for z/OS. As an alternative to the manual database transfer procedure described here, we can use the configuration wizard to complete the database transfer task. However, we 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.


Before beginning:
Ensure that the following prerequisites are met:

  1. 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:

      Edit db2cli.ini:

      • If a section named [COMMON] already exists in the file, extent 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. cd WP_PROFILE/ConfigEngine

  3. Validate configuration properties...

      ./ConfigEngine.sh validate-database -DWasPassword=foo

    Add -DTransferDomainList to the validating task to specify the domains to validate; for example...

      -DTransferDomainList=jcr

    To validate all domains, do not specify this parameter.

  4. cd WP_PROFILE/bin

  5. Stop the WebSphere_Portal server:

      ./stopServer.sh WebSphere_Portal -username wpadmin -password foo

  6. Transfer the database:

    Important: Do not execute the database-transfer task as a background process. This might cause the task to stall.

    1. cd WP_PROFILE/ConfigEngine

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

      We can include only the domains to transfer.

      For example, to transfer only the JCR domain...

        ./ConfigEngine.sh database-transfer -DTransferDomainList=jcr -DWasPassword=foo

    2. Log output is written to:

        WP_PROFILE/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.

  7. If a dedicated run time database user has been specified (domain.DbRuntimeUser), ensure that this user has sufficient database privileges. Refer to the appropriate template file (grantRoleToConfigUser.sql or grantRoleToRuntimeUser.sql) containing the required GRANT statements for each of the db domains.

    • Open the createRuntimeRoleForDifferentSchema.sql file when different names are used for the run time database user name and the schema name. Open the createRuntimeRoleForSameSchema.sql file when the same name is used for the run time database user name and the schema name. These files are located in PORTAL_HOME/base/wp.db.impl/config/templates/setupdb/db2_zos/domain and PORTAL_HOME/pzn/prereq.pzn/config/templates/setupdb/db2_zos/domain directories.

    • Replace all placeholders (surrounded by '@' characters) with the values defined in wkplc_dbdomain.properties.

    • Execute these statements in the createRuntimeRoleForDifferentSchema.sql or createRuntimeRoleForSameSchema.sql file as appropriate.

  8. From the command line processor, reset the check pending status on the WebSphere Portal table spaces listed here. CHECK DATA is a DB2 batch utility invoked through JCL or through the DB2 utility panels. Type the following utility commands to check pending status:
    check data tablespace releasenameonzos.TS320A
    check data tablespace releasenameonzos.TS280A
    check data tablespace releasenameonzos.TS300A
    check data tablespace releasenameonzos.TS2110A
    check data tablespace releasenameonzos.TS830A
    check data tablespace communitynameonzos.TS8000B
    check data tablespace communitynameonzos.TS8011B
    check data tablespace communitynameonzos.TS280B
    check data tablespace customizationnameonzos.TS2110C
    check data tablespace jcrdbnameonzos.ICMSFQ04
    check data tablespace jcrdbnameonzos.TS2110D
    
    

    ...where... releasenameonzos, communitynameonzos, and customizationnameonzos are the names of the WebSphere Portal databases, and jcrdbnameonzos is the name of the JCR database. Refer to the Utility Guide and Reference for DB2 for z/OS for additional details.

  9. Run the RUNSTATS utility :
    LISTDEF JCRDBZOS INCLUDE TABLESPACE JCRDBZOS.* BASE
    RUNSTATS TABLESPACE LIST JCRDBZOS INDEX(ALL) KEYCARD TABLE(ALL)
    LISTDEF JCRDB01 INCLUDE TABLESPACE JCRDB01.* BASE
    RUNSTATS TABLESPACE LIST JCRDB01 INDEX(ALL) KEYCARD TABLE(ALL)
    ...
    

  10. Start the WAS.

    Verify the WebSphere Portal application server is running...

      http://hostname.example.com:10039/wps/portal

If you have additional nodes already configured, compare the following file on all nodes with the file from the primary node. Ensure all instances of the file are identical:

If the files are not identical, copy icm.properties from the primary node on which you ran the database-transfer task to the node.

  1. Stop the portal server on the secondary nodes.

  2. Copy

      WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

    from the primary node and replace icm.properties on the secondary nodes.

  3. Start the portal server on the secondary nodes.


Parent: Linux clustered server: Set up a remote DB2 for z/OS database
Previous: Linux clustered server: Assign custom DB2 for z/OS table spaces