When binding a rununit, the runtime system must determine which segment (or segments) contain the data to be accessed. Although the subschema identifies the areas, there may be several areas with the same name in the DMCL. To determine which area to access, the runtime system must qualify the area name with the name of a segment.
To determine the segments to be accessed, the name of a segment or database must be provided at runtime. This name can be specified in any of the following ways:
If all areas to be accessed are within one segment, the name of the segment can be specified at runtime using one of the above techniques. For example, the EMPLOAD program executed during CA IDMS installation only requires access to areas in the EMPDEMO segment. The SYSIDMS parameter file in the execution job stream specifies DBNAME=EMPDEMO, identifying the segment to be accessed. No special DBNAME entry is required.
If the application needs access to areas within multiple segments, those segments must be grouped together as a single database whose name is provided at runtime. When the bind takes place, CA IDMS locates the definition of the database in the database name table. It then searches the segments associated with that database name for a match on each area named in the subschema.
The installation process again provides an example of using a DBNAME to group segments together as one database. The system dictionary is the dictionary used to contain both physical database definitions (DMCLs, SEGMENTs, and so on) and the DC/UCF system definition. The logical name of this dictionary must be SYSTEM, since components of the runtime system access it under this name. However, it is composed of multiple segments:
To treat all of these segments as a single database for processing by tools such as IDD and the command facility, the database name table contains a database name called SYSTEM which includes all three segments.
When binding a rununit, if no segment or database name is explicitly established, CA IDMS searches the list of DBTABLE mapping rules in the database name table looking for one in which the "from-subschema" matches the name of the subschema specified on the bind. If a match is found, the database to be accessed is determined from the DBNAME specified in the DBTABLE mapping rule. If no match is found (and therefore no segment names can be established), the bind will fail with an error status of 1491.
To ensure that rununits will bind successfully, you must specify DBTABLE mappings for all rununits that bind without establishing a DBNAME. For example, if all rununits binding to a subschema whose name begins with INS are to access the insurance database INSDB then specify the following DBTABLE mapping:
alter dbtable alldbs subschema ins????? maps to ins????? dbname insdb;
When defining a database name, you can specify subschema mapping rules that change the name of the subschema specified by the application at the time a rununit is bound. This feature allows an application program to be compiled against one subschema but execute using a different subschema. This can be useful when:
For example, two schemas, EMPSCHM and TEMPSCHM define the production and test versions of the same database. Separate schemas are maintained so that changes can be made to the test version without impacting production. Each schema has a set of subschemas: EMPPxxxx are production subschemas and EMPTxxxx are test subschemas. Programs are compiled against the test subschemas and copied into the production libraries when ready. The following subschema mapping rule ensures that rununits use production subschemas when binding to the production (EMPDB) database:
create dbname alldbs.empdb
subschema empt???? maps to empp????
.
.
.
In your database name definition, you must identify the segments containing the data to be accessed by applications binding to that database. If all applications specify a DBNAME on the BIND RUNUNIT statement, then only segments accessed by those rununits need to be included in the database name. If, on the other hand, the database name is specified externally (for example by using a DCUF command), then you may need to include additional segments within your database name definition or use subschema mapping rules to ensure that rununits bind successfully.
To illustrate this, assume that an application requires access to both employee and project data in segments EMPSEG and PROJSEG respectively. To satisfy this application, a database name of EMPDB is created:
create dbname alldbs.empdb include segment empseg include segment projseg;
Instead of specifying EMPDB within the application, the user issues a DCUF SET DBNAME command to establish EMPDB as the DBNAME session attribute. Because this session attribute applies to all rununits initiated on behalf of the user, to satisfy another rununit accessing insurance information, either:
or
alter dbname alldbs.empdb subschema empt???? maps to empp???? subschema ???????? uses dbtable mapping;
In addition to changing the name of employee subschemas, these parameters have the effect of treating rununits binding to other subschemas, as if no DBNAME were specified; instead, the database name is selected using the DBTABLE mapping rules.
|
Copyright © 2014 CA.
All rights reserved.
|
|