If the DB administrator wishes to modify the Schema DDL, he or she must generate a complete new Schema definition and have it compiled. BALTER enables the following modifications to be made to the Schema DDL:
at realm level
adding or deleting realms
at record type level
adding or deleting record types
changing LOCATION MODE
redefining, deleting or modifying SEARCH keys
adding, omitting, redefining, lengthening or shortening items
at set level
adding or deleting sets (with restrictions)
modifying the ORDER clause (with restrictions)
changing the sort criteria
redefining, deleting or modifying SEARCH keys.
During restructuring operations BALTER identifies the database elements (realms, record types, sets, keys, etc.) solely by means of their names:
BALTER recognizes elements as identical if they are of the same type (e.g. record type) and their names occur in the old and new Schema DDL.
BALTER deletes elements if the name for this element type does not occur in the new Schema DDL.
BALTER adds elements if the name for this element type does not occur in the old Schema DDL.
Consequently it is impossible to rename elements or in the same restructuring run delete an element and replace it by an element of the same type and name. The BRENAME utility routine is provided for renaming items (see chapter "Renaming database objects (BRENAME, BALTER)").
When the BGSIA run is carried out during restructuring, the numbers of the database elements remain the same. BGSIA allocates the numbers in question according to the element name. Consequently the sequence in which the elements are defined in the new Schema DDL is immaterial.
When restructuring is performed, the clauses of the Schema DDL and the SSL are subject to the same rules which apply when a database is defined (see the "Design and Definition" manual). This also means that when a clause of the Schema DDL is modified, all other associated clauses in the Schema DDL and SSL must be adapted so as to comply with these rules.
The following is a detailed description of the modifications possible in the Schema DDL and their effects on the stored data.
Schema entry
|
schema-name
may be changed if required.
|
The PRIVACY LOCK specifications can be changed as required.
Effects on stored data:
The DDL compiler enters the new PRIVACY LOCK specifications in the new DBCOM.
A subschema whose PRIVACY KEY does not match the new PRIVACY LOCK specifications can still be used (see section "Copying compatible subschemas"). The new PRIVACY LOCK specifications need only be taken into account when the new or modified subschemas are compiled.
Realm entry
|
Realms can be added or deleted.
If a realm containing records of a record type which also occurs in the new schema is deleted, these records must be unloaded before restructuring takes place, since BALTER does not transfer records to other realms. BALTER simply removes a deleted realm from the database. When restructuring is complete, the file of the realm must be deleted with the ERASE command.
Realms which have been added need not be formatted with BFORMAT. BALTER formats them automatically and adds them to the database. The realms must, however, be set up using the CREATE-FILE command before the BALTER run takes place.
Make sure that the secondary assignment is set to a value greater than 0 if the realm is to be extendable online (see the "Database Operation" manual, ACT INCR)
|
Adding or deleting the temporary realm is possible.
Changing a temporary realm into a non-temporary realm or vice versa is however not permissible.
Record entry
|
record-name
It is possible to add or delete record types or to modify their definitions.
A record type which is to be deleted need not first be unloaded. BALTER deletes all related information such as records, hash areas, DBTT and tables, with one exception: compressed records or records with variable items must be unloaded before restructuring, since otherwise BALTER cannot process them and therefore cannot delete them.
|
The LOCATION MODE clause can be modified, added or omitted as required.
CALC/DIRECT or CALC/DIRECT-LONG
Allows the conversion of DIRECT or DIRECT-LONG to CALC, and vice versa, or allows the
LOCATION MODE clause with one of these specifications to be omitted or added.
Effects on stored data:
DIRECT or DIRECT-LONG
->CALC:
BALTER creates a new hash area and transfers the data records to it.
If the record type is the member record type of a list, an indirect CALC is created. In the case of a distributable list the hash area for all records is located in one realm.CALC
->DIRECT or DIRECT-LONG:
BALTER deletes all system information needed for hashing but does not transfer those records of this record type which have already been stored to the database.Addition/omission of LOCATION MODE IS CALC:
This change has exactly the same effect on the data as changing the specification DIRECT or DIRECT-LONG to CALC, and vice versa.Addition/omission of LOCATION MODE IS DIRECT/DIRECT-LONG:
This change has no effect on the stored data, but needs to be taken into account in application programs.
DIRECT / DIRECT-LONG
item-name-1:
the key item may be altered as required
identifier-1:
may be changed
Effects on data:
These changes have no effect on stored data, but needs to be taken into account in application programs.
CALC hash-routine: Change permitted.
It is permissible to change from the standard UDS/SQL hash routine to a user hash routine or vice versa; it is also permissible to replace the user hash routine by a new user hash routine.
item-name-2,...:
Any change in the key items permitted.
DUPLICATES...:
Duplicates may be permitted or prohibited as required.
Effects on stored data:
If the key items or the hash routine are altered, BALTER creates a new hash area and transfers the records.
If the DUPLICATES specification is changed to NOT ALLOWED, it is important to remember that BALTER only checks data for duplicates in those cases in which further alterations make processing of keys necessary.
If BALTER finds records with duplicate key values, it does not eliminate these values. If duplicates are prohibited, a check must be carried out to ascertain whether records with duplicate key values occur. If so, duplicates must be removed before restructuring is performed.
BALTER logs duplicate key values in the EXECUTION phase only, not in the analysis log. Restructuring is then continued.
This treatment of duplicates should be applied to all clauses containing the DUPLICATES entry.
|
realm-name
It is permissible to change the allocation of record types to realms.
Effects on stored data:
When a realm which is defined with LOCATION MODE IS CALC is added to a record type, BALTER creates a hash area for the record type in this realm (except in the case of distributable lists).
When the record type is the member record type of a distributable list and this is defined with LOCATION MODE IS CALC, an indirect CALC area which is determined explicitly by the DETACHED WITHIN clause of the MODE IS LIST statement in the SSL or alternatively by the first realm name of the aforementioned WITHIN clause is used in one realm. A corresponding change causes the CALC area to be created anew.
If only one or more realms are added for a member record type of a distributable list, the existing list remains unchanged.When realm-name-1 is changed, BALTER relocates the record type’s DBTT to the newly specified realm if no SSL specification prevents this.
When a realm is omitted in the WITHIN clause, no records of the record type concerned may be stored in this realm, otherwise (except in the case of distributable lists) BALTER will abort the restructuring even if another realm is made available for these records.
When a realm is omitted in the case of distributable lists, this results in the list being recreated even if this realm contains no records.
When a distributable list is removed, for instance by changing the MODE clause to POINTER-ARRAY, the records of the member record type remain in the realm in which they were stored in the distributable list. If these records are accessed using LOCATION MODE IS CALC, it must be ensured that the AREA-ID is supplied with correct information after the list has been removed. To avoid any access problems occurring here, all pages in the list can be relocated with the UDS online utility to one realm before restructuring takes place, and just one realm can be declared for the record type when the list is removed.
To improve the runtime of BALTER with large databases, you can proceed as follows:
If you increase the realm allocation of an owner record type from one to two or more realms, you should restructure the database in a first cycle by changing the DETACHED-specifications (including the default values) to DETACHED WITHIN realm-name for the tables that depend on the owner record type. realm-name is the realm in which the owner records are currently stored. In a second restructuring cycle you should delete the DETACHED specification.
identifier-2
Can be changed as required.
Effects on stored data:
There are no effects on data; the change need only be taken into account in the application programs.
|
In the SEARCH-KEY clause any change is permitted. It is possible to:
- change existing SEARCH keys
- define new SEARCH keys
- omit SEARCH keys which are no longer required
item-name-3,... | |
There are no restrictions on which data items can be used as a SEARCH key or on which data items are combined to form the SEARCH key. | |
USING ... | |
Any change is allowed. Effects on stored data:
| |
name | This specification can be omitted, added or changed. |
DUPLICATES... | |
For duplicates the same applies here as for the LOCATION MODE clause (see section "Record entry"). BALTER checks for illegal key value duplicates and logs them only if it has to create a multi-level SEARCH key table or an indirect hash area. | |
|
The structure of record types can be modified as required, but it is important to bear in mind the following:
Length of record type
Record types which are stored in a single-level list must not be lengthened!
A single-level list means ORDER IS LAST, FIRST, PRIOR or IMMATERIAL and MODE IS LIST.Number and sequence of item
You may change the order of items. You may also delete items.
Newly defined items are initialized by BALTER dependent on item type:alphanumeric items with blanks
national items with national blanks (Unicode)
numeric items with the value zero
Length of items
Items can be lengthened or shortened. BALTER proceeds as follows, depending on the item type:Alphanumeric items:
When items are lengthened, BALTER pads to the right with blanks. When items are shortened, BALTER truncates to the right by the appropriate number of characters.National items:
When items are lengthened, BALTER pads to the right with blanks (Unicode). When items are shortened, BALTER truncates to the right by the appropriate number of characters.Numeric items:
When items are lengthened, BALTER pads to the left of the decimal point with zeros. When items are shortened, BALTER truncates to the left of the decimal point by the appropriate number of characters. Significant digits may be lost as a result. If the item has a sign, the sign is retained, provided the new item definition allows a sign.
Database key items
In the case of database key items, their type can be changed from DATABASE-KEY to DATABASE-KEY-LONG, and vice versa.
Figure 25: Changing the type of database key items
TYPE IS DATABASE-KEY
->TYPE IS DATABASE-KEY-LONG:
BALTER copies the 1-byte record reference number (REC-REF) of the DATABASE-KEY item right-justified into the corresponding 2-byte area of the DATABASE-KEY-LONG item. The 3-byte record sequence number (RSQ) of the DATABASE-KEY item is copied right-justified into the corresponding 4-byte area of the DATABASE-KEY-LONG item.TYPE IS DATABASE-KEY-LONG
->TYPE IS DATABASE-KEY:
BALTER copies the right byte of the 2-byte long record reference number (REC-REF) of the DATABASE-KEY-LONG item right-justified into the corresponding 1-byte area of the DATABASE-KEY item. The right 3 bytes of the 4-byte long record sequence number (RSQ) of the DATABASE-KEY-LONG item are copied right-justified into the corresponding 3-byte area of the DATABASE-KEY item.Due to the truncation of positions on the left for the REC-REF and RSQ when converting from TYPE IS DATABASE-KEY-LONG to TYPE IS DATABASE-KEY, data is lost if the REC-REF > 254 and/or the RSQ > 224-1. If this occurs, BALTER issues a warning, which contains the original DATABASE-KEY-LONG value; however, the BALTER run is not aborted. The database remains in a consistent state (see also “BCHECK” in the "Recovery, Information and Reorganization" manual). The logical consistency, i.e. the consistency of application data, will need to be verified and ensured.
Type of items
When you change the type of a numeric item to another numeric type (e.g. TYPE IS DECIMAL->TYPE IS BINARY), BALTER converts the data.
If you change the type of an unpacked numeric item to an alphanumeric type (of fixed length), BALTER will proceed as described below.
For all other type changes, BALTER fills the item in accordance with the new type with blanks or with the value zero. This also applies in particular for all type changes from or to national.unpacked numeric->alphanumeric (fixed length):
If required, BALTER converts the data by proceeding as follows:BALTER copies the numeric digit sequence left-justified into the alphanumeric target item. Leading zeros are retained.
Any symbol “V” (decimal point) that may be in the definition of the source item is ignored by BALTER, i.e. the whole part and the decimal positions are copied. Existing “P” symbols (implicit multiplication with 10) in the definition of the source item are taken into account by BALTER to the extent possible.
Depending on the size of the alphanumeric target item, BALTER proceeds as follows:If the target item contains fewer positions than the sequence of digits to be copied (including the considered “P” symbols), the excess positions in the digit sequence are truncated.
If the target item contains more positions than the sequence of digits to be copied (including the considered “P” symbols), the digit sequence is padded on the right up to the target item length with X‘40‘.
In the hexadecimal representation of the digit sequence obtained in accordance with 1, BALTER converts the second-last half-byte (sign) to hexadecimal “F”. This applies, in particular, even if the definition of the source item contains the symbol “S“ (sign).
Examples
Source item
(unpacked numeric item)Target item
(alphanumeric item)Item definition
Item contents
(hexadecimal)Item definition
Item contents
(hexadecimal)1)
PIC 9999
F8 F1 F2 C3
->PIC XXXX
F8 F1 F2 F3
2)
PIC S999PP
F5 F2 D3
->PIC XXXXX
F5 F2 F3 F0 F0
3)
PIC S99V99
F1 F4 F3 D5
->PIC XXXX
F1 F4 F3 F5
4)
PIC 9999
F1 F2 F3 F4
->PIC XXX
F1 F2 F3
5)
PIC 999P
F5 F2 E3
->PIC XXXXXX
F5 F2 F3 F0 40 40
6)
PIC S999V99
F0 F2 F3 F4 D5
->PIC XXXXXX
F0 F2 F3 F4 F5 40
7)
PIC SV999
F0 F2 B3
->PIC XX
F0 F2
8)
PIC V999
F7 F2 A3
->PIC XX
F7 F2
9)
PIC S999PP
F0 F2 B3
->PIC X
F0
10)
PIC 999PP
F8 F2 F3
->PIC X
F8
- Variable item
In record types, you can only add or modify a variable item providing no records of this record type are stored in the database (see "Summary of restrictions").
However, items of fixed length can be added to or omitted from records with a variable item when records are stored. You can also modify the length of such items. In addition, you can implement all changes in the schema which lead to a change in the system part (SCD). - Position of the decimal point
If the position of the decimal point or the scale factor is changed, BALTER shifts the digits within the item so that the former value is retained. Digits shifted beyond the left or right boundary of the item are lost; BALTER does not round up. Repetition factor
When the repetition factor of vectors or repeating groups is reduced, BALTER truncates the items at the end of the vector or the repeating group. Increasing the repetition factor causes BALTER to initialize new items with blanks or zeros according to type. It is easy to check whether BALTER copies, initializes or omits the contents of the items when the repetition factor is changed:
For indexed items the BALTER conversion routine uses a three-level index for both the old and new definitions. If the old item and the new item are represented with three-level indexing, they can be compared easily.CAUTION!
Reducing the repetition factor of vectors or repeating groups can cause loss of data.
Figure 26: Changing the item contents of stored records by modifying the repetition factor
Set entry
|
When changing the set entry, the following applies:
- Omission of sets is allowed without restriction.
- Addition of sets is permissible but subject to certain restrictions on the type of set membership (these do not apply, however, to the addition of SYSTEM sets).
- The changing of sets is subject to certain restrictions.
|
Dynamic sets may be added or omitted. The conversion of a set into a dynamic set and vice versa is, however, prohibited.
|
Changes to the ORDER clause must be considered in relation to the MODE clause of the SSL (see "MODE clause" in the "Design and Definition" manual).
The following applies to changes to the ORDER clause:
If no records of the member record type of the set to be changed are stored, all modifications are allowed; if records of the member record type of the set to be changed are stored, the modification of the ORDER clause is subject to certain restrictions.
Which modifications of the ORDER clause are allowed when records of the member record type are stored can be seen in the following table:
| new schema |
|
|
|
| ||
|
| No restrictions on use | allowed without restrictions |
| Only allowed if the member record type (incl. CD) is not lengthened as a result of the change. | ||
| Only allowed if the SCD of the owner/member record type need not be enlarged (see table 28) | ||
|
| Not allowed. | |
| Not allowed. | ||
| Only allowed if the SCD of the owner/member record type need not be enlarged (see table 28) |
Table 27: Changes to the ORDER clause when member records are stored
When and how the set connection data (SCD) for a set with MODE IS CHAIN is altered is shown in the following table:
new old |
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Table 28: Modifying the SCD for a set with MODE IS CHAIN
< | is shortened |
> | is lengthened |
- | no change in SCD length |
1) | modification allowed since SCD unchanged or shorter or in the new schema ORDER IS SORTED [INDEXED...]... |
2) | modification not allowed since SCD longer and in the new schema not ORDER IS SORTED [INDEXED...]... |
DUPLICATES ... | |
The same applies as for the LOCATION MODE clause (see section "Record entry") | |
NAME IS name | |
This specification can be modified, added or omitted as required. | |
|
Changing the OWNER clause of a set is prohibited!
|
record-name
Specification of a new member record type is prohibited.
set membership
If an existing set is changed and the database contains
- no records of the member record type, the set membership may be changed as required.
- records of the member record type, the set membership must not be converted from OPTIONAL to MANDATORY AUTOMATIC if certain member records are not allocated to an owner.
If the set is not modified in any other way, this change causes the database to be inconsistent. If the set must be processed to carry out other changes, this change causes BALTER to terminate abnormally.
If a new set is defined, and the database contains
- no records of the member record type, the set membership can be selected as required.
- records of the member record type, then MANDATORY AUTOMATIC must not be defined as set membership for sets other than SYSTEM sets. BALTER cannot automatically allocate member records to owner records if the set is not singular, i.e. the DB administrator must decide which member records are to be allocated to which owner record and then carry out allocation by program with the aid of the CONNECT statement.
Effects on stored data:
Changing set membership has no effect on the stored data. Possible changes in set membership must, however, be taken into account in programs when records are stored or deleted.
|
All modifications are allowed.
Effects on stored data:
BALTER recreates the pointer arrays, lists or chains concerned in accordance with the modified sort criteria.
The recreation of a list involves transferring the member records to another storage area, since BALTER has to rearrange them in a new sort sequence.
|
The same modification possibilities exist for SEARCH keys at both set level and at record type level (see the section on changing the SEARCH KEY clause).
|
Modification of the SET OCCURRENCE SELECTION clause is allowed.
Effects on stored data:
Modification has no effect on the stored data. The DB administrator must, however, take any modification into account in his DB applications.