Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Restructuring the converted database

When a database has been converted from the 2-Kbyte format to the 4-Kbyte or 8-Kbyte format, you can use the extended value range for the maximum number or records per record type without changing the database schema, unless a field of type DATABASE-KEY is defined in the record description or in the LOCATION-MODE in the schema DDL - if you want to use the extended value range for records then you must convert this field to DATABASE-KEY-LONG for each record type.
The main advantage of this is that application programs can be adapted independently of the database conversion.
Changes in the schema are required if you want to use the extended value range without restrictions even for record types with an explicitly defined database key item.

This section only illustrates the changes required in the Schema DDL and Subschema DDL If the extended value range is to be used. The restructuring of a database is described in detail in chapter "Restructuring the database (BCHANGE, BALTER)".

If DB application programs use database key values of a record type for which no more than

16 777 215 records are to be stored even in the future (RSQ < 224-1), you should ensure that the record type involved receives a record reference (REC-REF) < 255 when restructuring the database. This helps reduce the overhead for adapting and possibly recompiling the application programs, since the corresponding USAGE IS DATABASE-KEY items need not be adapted in this case (see section "Adapting COBOL and CALL DML statements").

Existing database key values are converted to the extended format on restructuring the database when the data repository is adapted with the BALTER utility routine (see section "Analyzing schema modifications and adapting stored data with BALTER").

In order to optimize your database, you should adjust the values specified for the population in the SSL to the extended value range (see the "Design and Definition" manual).

Adapting the database schema

The following language options of the Schema DDL must be changed in order to use extended database key values:

  • TYPE IS DATABASE-KEY changed to TYPE IS DATABASE-KEY-LONG

  • LOCATION MODE IS DIRECT changed to LOCATION MODE IS DIRECT-LONG

In the case of record types that contain a database key item (TYPE IS DATABASE-KEY), you should check whether this database key item will need to accept extended database key values in the future. Note, however, that a database key item need not always be used for the database key of the record in which it is defined. It could, for example, also be used for the database key of some other record type. You should therefore also examine all possible cross-links when deciding whether to convert an item of type DATABASE-KEY to a DATABASE-KEY-LONG item.
The conversion of a DATABASE-KEY item to a DATABASE-KEY-LONG item also requires all
LOCATION MODE IS DIRECT clauses in which that DATABASE-KEY-LONG item is addressed to be changed to LOCATION MODE IS DIRECT-LONG (see the "Design and Definition" manual).

Adapting subschemas

For each database key item of the database schema that has been changed to DATABASE-KEY-LONG, the associated USAGE IS DATABASE-KEY clauses must be changed to USAGE IS DATABASE-KEY-LONG in the subschema definitions involved (see the "Design and Definition" manual). These subschemas and the application programs that access them must then be recompiled.

If all record types of a subschema containing a DATABASE-KEY-LONG item are to be copied with the Subschema DDL statement COPY, this subschema will only need to be recompiled, but not adapted.

The subschemas that need to be adapted can be determined following the BALTER run to adapt stored data (see section "Schema entry", "Modifying the Schema DDL") by means of the DDL compiler run, which copies the subschemas and also filters out those that are incompatible (see section "Copying compatible subschemas").