Understanding the Procedure for Performing Modeling

The following general tasks are involved in the modeling procedure:

  1. Adding the MODEL option to the database description.

    The MODEL option specifies which existing database is to be used as the basis for the modeling. Any database in a family of databases can be chosen as the basis and the remaining databases modeled from it.

  2. Changing the description to accommodate your new requirements.

    The permitted changes are those to the dynamic parameters, which include

    Guard file titles

    • Audit trail attributes

    • Control file attributes

      AREAS, KIND, pack family name, and BUFFERS options for data sets and index sets

    • Data set REBLOCKFACTOR option

    • ALLOWEDCORE option

    • Controlpoint and syncpoint frequencies

    (Dynamic database parameters can be changed during a conventional DASDL update as well as under the MODEL option.)

    User compiler control options can be used to combine different sets of dynamic parameters in one DASDL source file.

    All of these parameters, except control file attributes, are stored in the control file. Each database in the family has its own control file, along with its own data files.

    The title of the Accessroutines code file is also stored in the control file. The normal title for the Accessroutines is SYSTEM/ACCESSROUTINES. In the absence of any other user action, this name is used. When a MODEL option is present, the name of the Accessroutines for the database specified in the option is used. The user can give any other name for the Accessroutines with an Accessroutines specification.

  3. Recompiling the DASDL description.

  4. Creating a new control file for the new database.

    SYSTEM/DMCONTROL uses the newly created description file to create the control file. SYSTEM/DMCONTROL can be initiated either directly by the user or by the DASDL compiler.

    Normally, the control file is created under the usercode from which the DMCONTROL program is run. The user can specify this usercode or the asterisk (*) usercode in the control file attributes. This usercode then is used for all the database data files. The DMCONTROL program must be run under the appropriate usercode or under a privileged usercode to create the control file.

  5. Initializing the data files with the DMUTILITY program.

    Once the data files have been initialized, user programs can be run. Modeled databases share the DMSUPPORT library. DATABASE/WFL/COMPILEDB does not recompile the DMSUPPORT library.

  6. Existing user programs for the old database can be run against the new database without being recompiled using a database equation. New programs compiled for either database can run against the other database.

If you are using the Open Distributed Transaction Processing facilities and are using models of your database, you must alter the RMSUPPORT library in each model so that its name is unique. A run‑time error (OPENERROR 88) results if any model attempts to share the RMSUPPORT library.

For more information on the Open Distributed Transaction Processing product, refer to the Open Distributed Transaction Processing Programming Guide and the Open Distributed Transaction Processing Installation and Administration Guide.

Example

This example creates a test database, TESTDB, from a production database called LIVEDB. The production data files reside on the DISK pack, and the database writes a duplicated audit to tape. The test database exists on the TESTPACK pack, where it writes a nonduplicated audit. The original DASDL description looks as follows: 

OPTIONS (AUDIT);
D DATA SET (K NUMBER(6)) AREAS = 100;
S SET OF D KEY K;
AUDIT TRAIL (KIND = TAPE, DUPLICATED ON TAPE);

The following WFL job creates the TESTDB database from the description file of the production database LIVEDB: 

?BEGIN JOB CREATE/TESTDB;
COMPILE TESTDB WITH DASDL;
COMPILER DATA
MODEL LIVEDB;
OPTIONS (AUDIT);
CONTROL FILE (PACK = TESTPACK);
D DATA SET (K NUMBER(6)) PACK = TESTPACK;
S SET OF D KEY K PACK = TESTPACK;
AUDIT TRAIL (PACK = TESTPACK);
?END JOB.

This DASDL compilation produces the file DESCRIPTION/TESTDB from the description file of the production database DESCRIPTION/LIVEDB. The update levels of both description files are equal. Because the ZIP compiler control option was not explicitly reset, DASDL automatically initiated the compilation of all tailored software for the TESTDB database except the DMSUPPORT library. The SYSTEM/DMCONTROL program was run to initialize the control file of the TESTDB database.

A user program compiled using DESCRIPTION/LIVEDB could open the production database LIVEDB, or the test database TESTDB, using a database equation.

Prev  Up  Next
Performing Modeling  Home  Modeling with the Update or Reorganization Process