Cloning a DMSII Database Via dbutility Process

To clone a DMSII database via dbutility process

  1. Make sure that DBServer or Enterprise Server is running. If it is not, the DATABridge Client will try to connect to the host and eventually time out.
  2. Make sure that your signon parameters are configured appropriately.
  3. If you plan to use the [EbcdictoAscii] section to customize character translation or any other parameters in the dbridge.cfg file, set them before you continue. In particular, make sure you have appropriate settings for the following parameters. (For information on setting these parameters, see Appendix D.)

    For Microsoft SQL Server:
    bcp_date_format

    For Oracle and DB2:
    bcp_delim
    bcp_decimal_char

    For all relational databases:
    statistics_increment
    show_perf_statistics
    show_statistics
    show_table_stats
    statistics_increment
    max_temp_storage (Windows only)
    max_clone_count (-s option only)
    controlled_execution
    min_check_time
    stop_after_given_afn
    stop_after_fixups
    linc_century_base
    inhibit_ctrl_chars
    inhibit_8_bit_data
    convert_ctrl_char
    error_display_limits
    discard_data_errors
    suppress_dup_warnings
    display_bad_data
    century_break
    enable_optimized_sql
    use_ext_translation
    eatran_dll_name

  4. Enter the following command:

    dbutility [signon_options misc_options] process datasource

    Where

    Is

    signon_options

    For each DATABridge Client type, the following command line options sign on to the relational database:

    SQL Server or DB2:

    [-U userid] [-P password] [-O ODBCdatasource]

    Oracle:

    [-U userid] [-P password] [-D database]

    misc_options

    Any of the following miscellaneous command line options:

    -L forces the client to use a new log file for this run.

    -T fileprefix to specify a prefix to be used instead of the default trace prefix ("trace")

    -f filename to specify a configuration file other than the default dbridge.cfg file in the working directory

    -w (toggle for use_dbwait in dbridge.cfg)

    -K inhibits the audit file removal WFL from being run on the host

    datasource

    The name of the data source specified in the DBServer control file (DATA/SERVER/CONTROL) or via Enterprise Server.

If the DATABridge Client connects to DBServer, it selects all the data sets whose corresponding active columns have a value of 1 in the DATASETS table. Next, the DATABridge Client requests that DBServer clone all the selected data sets. At the end of the data extraction phase, the DATABridge Client issues another request to start sending the fixup records followed by updates. The processing of audit files continues until there are no more audit files available.

If the DATABridge Client connects to DBEnterprise, DBEnterprise supplies the data, either by reading the DMSII data set directly or by issuing a request to DBServer to have DBEngine read a block of data from a specific region of the disk. DBEnterprise then processes this block of data. Since DBEngine is only reading raw data and does not do any processing of this data, this mode of operations is much less expensive in term mainframe resource utilization. In the case of audit file data, DBEnterprise either reads gets the data from its caches (if configured), or it reads the audit file directly by issuing a request to DBServer to have DBEngine read a block of data from a specific region of the disk.

After cloning, use the data in the relational database as usual. When you are ready to update the relational database with changes made to the DMSII database, see Updating the DATABridge Data Tables.