HP 3000 Manuals HP 3000 Manuals
Merging and Compiling
The two major functions of SDUTIL, merging dictionary data and compiling
dictionaries, are discussed on the following pages. Two other functions,
purging a dictionary and renaming a compiled dictionary, are explained in
the descriptions for the commands PURGE and RENAME, in Chapter 3.
Both major functions of SDUTIL have a common requirement, that the source
and target dictionaries be defined. The commands which define the
dictionary environments are:
* FROM, which defines a master or compiled source dictionary.
* MERGE-TO, which defines a master target dictionary.
* COMPILE-TO, which defines a compiled target dictionary.
The following table provides information on the commands which are used
in merging and compiling, and the functions they perform.
MERGE AND COMPILE COMMANDS
-----------------------------------------------------------------------------------------------
| | | |
| From | To | Command |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| master dictionary | master dictionary | FROM |
| | | MERGE-TO |
| | | MERGE-OPTIONS |
| | | MERGE/PREVIEW |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| master dictionary | compiled dictionary | FROM |
| | | COMPILE-TO |
| | | COMPILE-OPTIONS |
| | | COMPILE |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| compiled dictionary | master dictionary | FROM |
| | | MERGE-TO |
| | | MERGE-OPTIONS |
| | | MERGE/PREVIEW |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| compiled dictionary | compiled dictionary | NOT ALLOWED |
| | | |
-----------------------------------------------------------------------------------------------
Name Modes
When dictionaries are either compiled or merged, both the internal and
external names are affected, regardless of the name mode that is
specified. The name mode parameter of the FROM and MERGE-TO commands
allows you to specify either the internal or external names for the scope
name, domain name and version name when opening the dictionary. When
merging, however, SDUTIL checks only internal names to determine whether
or not a definition exists. Internal names are used because they can
never be changed, while external names can be.
Open Modes
SDUTIL allows you to choose the open mode with which to open the source
and target dictionaries in the FROM and MERGE-TO commands.
The FROM command is used to define the source environment for both
compiling and merging.
If you are compiling, open the source dictionary in either
Exclusive-Update mode or Read-Allow-Read mode, unless you are compiling
structure only. If you are compiling structure only, you may open the
source dictionary in Exclusive-Update mode, Read-Allow-Read mode, or
Customization mode.
If you are merging, the source dictionary can be opened in any mode.
Some general guidelines for source dictionary open modes used while
merging are:
* Open the source dictionary in Customization mode if you only want to
merge the complete dictionary structure and do not want to specify a
version and domain when opening the dictionary.
* Open the source dictionary in either Read-Only mode or Shared-Update
mode if you do not care if someone is modifying the dictionary while
you are merging either structure-only or a version.
* Open the source dictionary in either Exclusive-Update mode or
Read-Allow-Read mode if you do not want anyone to modify the
dictionary while you are merging either structure-only or a version.
The MERGE-TO command is used to define the target environment for merging
only. You can open the target dictionary in Read-Only mode only if you
are previewing the merge process. Otherwise use the following guidelines
for target dictionary open modes.
* Open the target dictionary in Customization mode if you are merging
structure only and want exclusive access to the target dictionary.
* Open the target dictionary in Exclusive-Update mode if you are
merging a version and expect structure changes are to be involved.
This will ensure that no one else is accessing the dictionary during
the merge, and the dictionary can be switched to Customization mode
when updating the structure. The switch is done automatically, so
you don't have to merge structure separately first, and then merge
occurrences, but can do them both at once.
* Open the dictionary in Shared-Update mode if you are merging a
version, do not expect structure changes, and do not need exclusive
access to the target dictionary while you are merging.
Compile / Merge Options
You can set various options for the compile/merge process via two
commands: The COMPILE-OPTIONS command, which allows you to set the
options for the compiling process, and the MERGE-OPTIONS command, which
allows you to set the options for the merging process. Note that these
options must be specified before the COMPILE or MERGE command is given.
Compiling / Merging Multiple Versions
You can compile or merge more than one version when running SDUTIL by
issuing multiple COMPILE or MERGE commands and specifying the appropriate
source and target environments as necessary. Note that multiple versions
can be compiled into the same compiled dictionary until the compiled
dictionary is closed.
Compiling a Dictionary
When you are compiling, the dictionary structure and the security schemes
are automatically included in the compiled dictionary. However, you have
an option to specify whether or not you want common links to be compiled.
If this option is set true, and the version to compile is in the local
domain and it is linked to a version in the common domain, then the
linked version in the common domain will also be compiled in addition to
the version in the local domain. The occurrence linking will then be
preserved in the compiled dictionary as in the source master dictionary.
You also have an option to specify what variable length attributes you
want to compile. You can include all, none or selected variable length
attributes in your compiled dictionary.
Closing the Compiled Dictionary File. The compiled dictionary is closed
when you
* enter an EXIT command.
* change the source dictionary to a different dictionary specified by
the FROM command.
* change the compiled dictionary file name to a different file name,
specified by the COMPILE-TO command.
Merging Dictionary Data
You can merge either dictionary structure from one dictionary to another,
or a version from the source dictionary to a new or existing target
version in the same or a different dictionary. Since only read access is
allowed for a compiled dictionary, the target dictionary must be a master
dictionary.
Previewing a Merge Option. The PREVIEW command is provided to allow you
to see the results of a potential merge before the merge actually takes
place. You can then choose how any reported conflicts between structure
or occurrence definitions in the source and target dictionaries should be
handled before the target dictionary is changed.
Merging Structure Vs. Occurrence. Structure is merged only when the
source dictionary is not also the target dictionary. Occurrences,
however, can be merged between versions within the same dictionary or
between two different dictionaries.
When occurrences are merged within the same dictionary, no structure
changes are involved because both versions already use the same
structure. When they are merged into different dictionaries, however,
the source dictionary structure will be merged into the target
dictionary. This is necessary because System Dictionary requires a
structure definition to support each type of occurrence in the
dictionary. For example, there cannot be any entities of type RECORD in
a dictionary if there is no entity type RECORD in the dictionary
structure. Refer to the HP System Dictionary/V General Reference Manual,
Volume 1 (32256-90004) for a complete explanation of dictionary structure
and occurrences.
The COMPLETE-STRUCTURE option is provided so that when merging dictionary
structure, you can specify whether to merge the whole dictionary
structure, or only those structures in the source dictionary that are
needed in the target dictionary to support the occurrences that will be
merged into it.
When you merge structure, SDUTIL copies the following structure
definitions:
* Attributes
* Entity Types and their associated attributes
* Relationship Classes
* Relationship Types and their associated attributes
When you merge a version, SDUTIL copies the following data:
* Entities and their attribute values including those of type alias and
variable length, synonyms, and common version links if needed
* Relationships and their attribute values including those of type
alias and variable length, and common version links if needed
Merging Security. In addition to occurrences you can also merge
dictionary security information. For the first release merging security
information will be limited to the DA since only the DA has full
capability to retrieve information about all other scopes and occurrences
owned by them. If the option to merge security is chosen, then the
following security information will be copied:
* scopes and their passwords and scope rights
* scope entity associations
* scope relationship associations
If you decide not to copy security, you can specify whether to copy just
the occurrences owned by the scope, or all occurrences accessible to the
scope. If you specify the option to merge only the occurrences owned by
the scope, then only those occurrences owned by the logon scope will be
copied. If you specify the option to merge all occurrences accessible
to the scope, then all occurrences owned by the logon scope,
accessible through the sensitivity attribute values of public read and
public modify, and accessible through explicit scope-entity and
scope-relationship associations will be copied.
Handling Conflicts. When you merge data into an existing dictionary,
SDUTIL may not always create an exact replica of the source dictionary.
If it did, it could cause some unwanted and possibly damaging side
effects to the dictionary, especially when structure changes are
involved. As a general rule, SDUTIL will take the approach of merging
data with no damaging side effects. The following text explains how
SDUTIL handles various kinds of conflicts.
STRUCTURE CONFLICTS. When you merge structure, it is possible that a
structure definition exists, but its external names are different.
Changing the external name of the target structure definition may not
always be appropriate, because programs may exist which rely on external
names of the dictionary structure. For this reason, when there is a
structure name conflict, SDUTIL will report the difference, but won't
change it. The name conflict in structure can occur for attribute names,
relationship class names and entity type names.
Attributes can have different data types, lengths and edit values. If
the difference between the attributes in the source and target
dictionaries is the attribute's data type, SDUTIL will terminate the
merge process because changing the type is not allowed in the dictionary.
Although the target attribute could be deleted and recreated, this
procedure will delete all the existing values of the attribute in the
dictionary, and is not recommended. If the difference is in the length,
then the source and target lengths will be compared. If the target
attribute length is shorter than the source, then the target attribute
length will be modified to have the same length as the source. If the
target length is longer than the source, then SDUTIL will report the
difference, but not modify the target attribute length. This is because
when an attribute length is shortened, all values of the attribute may be
truncated or modified depending upon the type. If the difference is in
the edit values, SDUTIL will preserve the existing edit values and add
the ones that are in the source but not in the target.
The number of attributes associated with a particular entity type or
relationship type in the source dictionary may be different than the
number of attributes associated with the same entity type or relationship
type in the target dictionary. If so, SDUTIL will preserve the ones that
are already associated in the target definition and add those that exist
in the source dictionary, but not in the target dictionary. Again, the
reason for doing this is because deleting the attributes also deletes the
attribute values of the entities and relationships. All the above
differences will be reported. You may make changes as desired after
SDUTIL completes the merge.
SCOPE CONFLICTS. The DA can merge security data such as scopes, scope
entity associations and scope relationship associations. When scopes are
being merged, SDUTIL checks for the internal name of the source scope in
the target dictionary. If it does not exist, SDUTIL will create it with
the same characteristics as the source scope. However, if the scope
already exists and the passwords and scope rights are the same, SDUTIL
will not change the target scope. If the external names or passwords are
different, SDUTIL will report the difference(s), but will not change the
external name or the password. If the scope-rights are different, SDUTIL
will take its consistent approach of preserving the existing scope-rights
of the target dictionary scope, and add those from the source scope that
do not exist in the target scope. Again, the differences will be
reported and you may make changes later as desired.
OCCURRENCE CONFLICTS. SDUTIL checks internal names to determine whether
or not an entity exists in the target dictionary.
* If an entity (internal name) already exists in the target dictionary,
but its external name is different than the external name in the
source dictionary, SDUTIL will not change the external name in the
target dictionary. The reasons for not changing the external names
are 1) it could cause conflicts with other existing external names,
2) it will preserve external names on which some applications may
depend, and 3) changing the entity names will also change the
relationships that involve the changed entity names, which may be
undesirable.
It is possible for an occurrence in the target dictionary to have the
same internal name as an occurrence in the source dictionary, but
have a different set of attribute values. When this happens,
you will be given a set of options to choose from to handle
this conflict. These options are explained in detail in the
INCOMPATIBLE-DEFINITION option in the description of the
MERGE-OPTIONS command in Chapter 3.
* If an entity (internal name) does not exist, SDUTIL will create it.
Note that even though the internal name of a new entity may not
exist, there may be an existing entity that has the same external
name as the entity being created. When this happens, SDUTIL will
take the action based upon the NAME-CONFLICT option. See the
description of the MERGE-OPTIONS command in Chapter 3 for details
about this option.
Common Version Linking. The local (source) version may be linked to a
version in the common domain, and occurrences in that local version may
be linked to occurrences in a version in the common domain. When you
merge a version with links, you have the option of either keeping the
links intact, or not including them in the merge. If you do keep the
links (set the link option to TRUE) and the target version exists, it
will be linked to the version being merged in. Occurrences will be
created in this version as necessary to support the links in the version
being merged in, and those links will be copied as in the source
dictionary. If the target version does not exist, a new version
containing the occurrences needed by the links will be created in the
common domain of the target dictionary. A link from the merged-in
version to this new common domain version will also be created. The
occurrence linking will then be copied as in the source dictionary.
If you set the link option to TRUE, the external name differences will be
checked both on the local entity and the common entity in the common
domain. The linking structure of occurrences will be copied or removed
based on the source occurrences. If, for any reason, an occurrence
cannot be linked to an occurrence in the common domain, then the
occurrence will exist as a local occurrence and will not be linked to the
occurrence in to the common version. Note that if you set the link
option to TRUE while the source version is not linked to a common
version, any existing links to occurrences in the target version will be
removed.
If you set the link option to FALSE, the attribute values for the linked
occurrences will be incorporated into the local definition and no links
from common occurrences to local occurrences will be created.
The following tables explain in detail, the actions taken by SDUTIL based
upon user specified options. In general, if there are problems modifying
the target common occurrence, then the occurrence linking will be removed
and the target occurrence will be kept as local.
LINK OPTION FALSE
----------------------------------------------------------------------------------------------
| | | |
| Source | Target | Action |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| LINKED | LINKED | If the occurrences are compatible then no action is |
| | | necessary. If they are incompatible then the |
| | | INCOMPATIBLE-DEFINITION option will determine whether or not |
| | | to replace the common occurrence attributes. |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| LINKED | NOT LINKED | If the attribute values of the common occurrence from the |
| | | source is compatible with the target local occurrence |
| | | attribute values, then nothing needs to be done. If they |
| | | are incompatible then the value of INCOMPATIBLE-DEFINITION |
| | | option will determine whether or not to modify the target |
| | | local occurrence attribute values. |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| NOT LINKED | LINKED | The value of the INCOMPATIBLE-DEFINITION option will |
| | | determine whether or not to modify the target common |
| | | occurrence attribute values if any action is necessary. |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| NOT LINKED | NOT LINKED | The INCOMPATIBLE-DEFINITION option will determine the action |
| | | if any is necessary. |
| | | |
----------------------------------------------------------------------------------------------
LINK OPTION TRUE
----------------------------------------------------------------------------------------------
| | | |
| Source | Target | Action |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| LINKED | LINKED | If the occurrences are compatible then no action is |
| | | necessary. If they are incompatible then the |
| | | INCOMPATIBLE-DEFINITION option will determine whether or not |
| | | to replace the common occurrence attributes. If replacing |
| | | the common occurrence fails then the target link will be |
| | | broken and the local occurrence will be modified to have the |
| | | source values. |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| LINKED | NOT LINKED | If the common occurrence does not exist in the target |
| | | version, the common occurrence will be created and linking |
| | | will be established. The common occurrence attribute values |
| | | are determined by the target local attribute values and the |
| | | INCOMPATIBLE-DEFINITION option. If the common occurrence |
| | | exists, the following table shows the actions taken. |
| | | |
| | | Local Common Action |
| | | *C C Link to common occurrence |
| | | C *IC If REPLACE specified, replace common |
| | | occurrence and link it |
| | | IC C If REPLACE specified, link it |
| | | IC IC If REPLACE specified, replace common |
| | | occurrence and link it |
| | | |
| | | *C means compatible *IC means incompatible |
| | | |
| | | If the common occurrence cannot be modified, then the |
| | | occurrence will be kept as local and its attribute values |
| | | will be determined by the INCOMPATIBLE-DEFINITION action. |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| NOT LINKED | LINKED | The link will be removed. If the definition is compatible, |
| | | the common occurrence attribute values will be kept in the |
| | | local version. If it is incompatible, then the |
| | | INCOMPATIBLE-DEFINITION option will determine the local |
| | | occurrence attribute values. |
| | | |
----------------------------------------------------------------------------------------------
| | | |
| NOT LINKED | NOT LINKED | The INCOMPATIBLE-DEFINITION option will determine the action |
| | | if any is necessary. |
| | | |
----------------------------------------------------------------------------------------------