InfoCenter Home >
3: Migration overview >
3.5: Switching administrative databases >
3.5.3: Switching server databases to DB2/390

3.5.3: Switching server databases to DB2/390

You can use DB2/390 to store the HttpSession and administrative databases. You can also use DB2/390 with enterprise beans.

This article does not outline the entire process of switching. As applicable, this article focuses on two steps: database setup in DB2/390 and administrative settings required in the application server.

If you are using DB2/390 in this capacity for the first time, additional configuration in the DB2 Connect product may be necessary. For more information, see the DB2 Connect documentation.

Setting up the HttpSession database in DB2/390

Session Manager now supports DB2/390 as a persistent datastore for failover support. Set up the database as follows:

  1. In DB2/390, create the database table.
  2. Create indexes for ID and PROPID.
  3. Use an SQL script like the following:
    CREATE TABLE DATABASE.SESSIONS
    (ID VARCHAR(64) NOT NULL,
    PROPID VARCHAR(64) NOT NULL,
    APPNAME VARCHAR(64),
    LISTENERCNT SMALLINT,
    LASTACCESS DECIMAL(21),
    CREATIONTIME DECIMAL(21),
    MAXINACTIVETIME INTEGER,
    USERNAME VARCHAR(256),
    SMALL VARCHAR(3313) FOR BIT DATA,
    MEDIUM LONG VARCHAR FOR BIT DATA,
    LARGE BLOB(2M),
    TROW ROWID GENERATED ALWAYS )
    IN WAS.CMPTB001;
    
    CREATE TYPE 2 UNIQUE INDEX CMP.CMPND001
    ON DATABASE.SESSIONS (ID, PROPID) USING
    VCAT DSN610; COMMIT;
    
    CREATE LOB TABLESPACE CMPLS001 IN WAS
    BUFFERPOOL BP32K
    LOCKSIZE LOB
    USING VCAT DSN610
    CLOSE NO;
    
    CREATE AUX TABLE CMP.CMPLT001
    IN WAS.CMPLS001
    STORES DATABASE.SESSIONS
    COLUMN LARGE;COMMIT;
    
    CREATE INDEX CMP.CMPLI001 ON
    CMP.CMPLT001 USING VCAT DSN610;COMMIT;
    

    This statement creates the SESSIONS table in the default database, which on DB2/390 is not recommended. Therefore, you should add an IN DATABASE() clause for your particular production requirements.

  • In DB2/390, set the RRULOCK parameter to YES.

    This parameter setting ensures an update lock on the table, which is required for proper serialization of session data. You can set this parameter by using option 19 on panel DSNTIPB.

  • In Session Manager, specify the database and version.
    1. Under the Persistence tab of Session Manager, assign the datasource that points to the DB2/390 location.
    2. Specify the user ID, database, and version in the userid field, as follows:
      userid::database$Vx
      
      Where     :: and $V are separators
      userid is the userid for connecting to database
      database is the database name
      x is the version of the database (values can be 6 or 7)

      Example for DB2 Version 6: user91::u091db92$V6

    3. Provide the password.
    4. Apply the changes.
  • Setting up the administrative database in DB2/390

    Before you start the setup in DB2/390, find the JCL file named db2390.sql, located in the bin directory. This sample is shipped with WebSphere Application Server, Version 3.5.3 and later.

    1. At a minimum, customize the JCL as follows:
      • For wasdb, substitute the name of the database in which the tables are to be defined.
      • For hlq, substitute the high-level qualifier for the datasets. This is used in the DDL so that DB2 can associate the tablespaces with the linear datasets.
      • For tgtVolume, substitute the target volume for dataset allocation.
    2. Transfer the customized JCL file to the target OS/390 system.
    3. Run the customized JCL.

      The JCL stream is broken up into three steps, as follows:

      1. DROPDB - The expected return code is 0 or 8. Expect a return code of 8 on the first run of this stream, because the database will not yet exist.
      2. DEFTABLE - Expect a return code of 0. This step creates the linear VSAM datasets for the tablespaces, indexes, and BLOB tablespaces used by the repository structure.
      3. CRTTABLE - Expect a return code of 0. DDL for the tablespaces, tables, and indexes is run in this step. In this step, several GRANT statements allow unlimited access to the tables by PUBLIC. The appropriate security measures must be implemented as required in your installation.
    4. Before the administrative server is started, verify the following property setting in the admin.config file:
      com.ibm.ejs.sm.adminServer.dbInitialized=nocreate

      This directs the administrative server not to try to create tables when DB2/390 is being used.

    Using DB2/390 with enterprise beans

    For session or BMP beans, you can use DB2/390 just as you would use any other version of DB2. No additional database setup or admininstrative configuration is required.

    You can also use DB2/390 to store persistent data for CMP beans, but this support is limited to CMP beans developed in IBM VisualAge for Java, Version 3.5.3 or later. The appropriate DDL script for table creation is generated by VisualAge for Java into the persister class for the CMP bean. For more information about this script, see the VisualAge for Java release notes for the EJB Development Environment component.

    1. In a process similar to that for setting up the administrative database, create the DB2/390 database, tablespace for the table, and tablespace for any BLOB fields in the schema for the CMP bean. (In DB2/390, BLOB fields are mapped to the LOB datatype, which is stored in a separate tablespace.)
    2. Customize the DDL script provided by VisualAge for Java.
    3. Using the customized DDL script, create the table for the CMP bean.
    4. In the application server, deploy the CMP bean.
    Go to previous article: Settings to change when switching administrative databases Go to next article: Developing applications

     

     
    Go to previous article: Settings to change when switching administrative databases Go to next article: Developing applications