Commands (YCLRMDL - YDLTOBJTBL) › YCPYMDLOBJ (Copy Model Objects) Command › Notes

Notes

• You cannot copy to a target model if it is in use by another job. However, you can run the YCPYMDLOBJ command with the CPYOPT(*PREPASS) option. For concurrent use of the source model, refer to the MDLLCK parameter.
• The model library named in the TOMDLLIB parameter (target model) must be the first model library in your library list.
• For SQL you must create an SQL collection before generating source.
• When YCPYMDLOBJ copies the selected entries to the target, it matches objects between the two models by name and type. By default, an object in the source model is copied to the target model using the same object name. You can override this default by specifying a different name for an object in the target model on the YEDTCPYLST rename panel or by changing the object's Copy name before adding the object to the model list for copy. For existing entries you can refresh the copy name from the object's details using option or for all entries on a list using the Check Model List command (YCHKMDLLST).
• When you create a model object, by default its Copy name will be the same as its object name. However, if the default Copy name is not unique within the model for the owner and object type, the Copy name is set to the object name suffixed by the objects 7-digit object surrogate. For object types other than conditions and physical access paths, if you rename an object, its Copy name is not changed; if you rename a condition or physical access path, the Copy name is automatically set to the new object name. You can manually reset an objects Copy name using the Change Model Object Description (YCHGMDLOD) command.
• The Copy Model Objects command does the following:
• Expands the model list—Each of the explicitly selected objects in the list are examined in turn to see if it has any associated objects which are required in order for it to be used. Any referenced objects which are found are added to the model list as implicit selections. This means that they will be copied only if they do not already exist in the target model.

  Possible referenced objects for the file object type are as follows:

  • Any other files referenced by the relations which define the file.
  • The following messages belonging to the file:

file not found

file already exists

• The fields arising from the resolution of the relations or entries.

Possible referenced objects for the field object type are as follows:

• If the field is a REF field, the based-on field.
• Any field conditions, associated constants, and external message IDs.

Possible referenced objects for the access path object type are as follows:

• The based-on file.
• Any associated access paths and referenced access paths.

Possible referenced objects for the functions object type are as follows:

• The based-on access path.
• Any function parameters, any files used to define function parameters.
• Any objects referenced by the function's action diagram: constants, fields and conditions.
• Function fields.
• Action bars.

Note: Functions called by a selected function (other than built-in functions and message functions) are not copied unless they too are selected or unless CPYSUBFUN is specified to be *DBF, *INT or *ALL as appropriate. See also the Note later in this section on CPYSUBFUN and EXPRQDOBJ for details.

The possible referenced object for the messages object type is as follows:

• Any parameters (and files and fields named in parameter definition).

There are no referenced objects for the Application areas object type.

Note: The expand list does not automatically include functions of type SELRCD which are implicitly, rather than explicitly, referenced by other functions. If there are fields with a user-defined data type of the same name in both models, fields from the source model will take the attributes of the data type in the target model, unless the internal/external conversion functions do not match; that is, the target model data type attributes will not be overwritten.

• Preliminary Check—Makes a preliminary (pre-pass) check against the model named in the TOMDLLIB parameter. This checks whether an object with the same CA 2E name is already present in the target model and if so, whether it is the same in all its attributes. If there is a discrepancy, one of two types of messages will be generated on a report:
  • Warnings—A warning message indicates an insignificant difference between the two models, (i.e., one that can be handled automatically by the subsequent copy process). Warning messages can be subdivided into two classes by their severity levels:
  • Severity 10—(Additional objects) These occur when there are fewer associated objects in the target model than in the source model. In this case, the additional objects can be copied to the target model without changing any existing values in the target model.
  • Severity 20—(Property differences) These occur when the objects differ in one or more of their properties (for example, fields have different lengths or data types) but it will be possible to produce a viable new version simply by replacing the existing version in the target model with the version from the source model.
  • Errors—An error message will be issued if the two versions of an object differ in a way that cannot be handled automatically. For instance:
• The object in the target model has been locked to prevent change.
• The condition values for a given field conflict.
• A required relation does not exist in the target model.

  You may find further information about particular messages by using the i OS Display Message Description (DSPMSGD) command to display the second level text for the message. All YCPYMDLOBJ messages begin with the prefix Y2V5 and reside in the Y2MSG message file.

  If any error messages are generated during the pre-pass, no objects can be copied. You must first take action to remove the errors, then rerun the copy. Actions that you may take include:

• Changing, adding or removing objects in either of the two models as appropriate.
• Using the command Edit Copy List (YEDTCPYLST) to specify alternative names under which to copy the new objects into the target model.
  • If CPYOPT(*PREPASS) is specified, the YCPYMDLOBJ utility will stop at this point.
  • If CPYOPT(*COPY) is specified, and no errors are detected (i.e. warnings only), the YCPYMDLOBJ utility will copy the objects indicated by the model list into the target model. An audit report is generated which lists all the objects copied.

    In order to produce a viable copy of an object, one or more referenced objects may also need to be present in the target model; the referenced object may in turn require further objects. You should be aware of the implications that the inter-dependencies between the objects in a model have for the copying process, and in particular make sure you understand when an associated object will or will not be copied. The rules for copying an object are:

• Any object that you explicitly select will always be copied. If a version of the object already exists in the target model, it is replaced. Otherwise, it is added.
• Objects that are not explicitly selected, but are implicitly required by an object that has been selected, will be added to the target model only if they are not already present in it. Otherwise the existing versions of the referenced objects will be used.

  In summary, an object will never be replaced by the YCPYMDLOBJ command unless you explicitly select it.

The following table shows for each object type the possible referenced object types that may be copied or replaced.:

Note that:

• When a field is replaced, any existing conditions it may have in the target model are retained. In other words, the copy is a merge. New conditions are added but existing conditions are not updated. If there is a conflict over the condition values that would prevent the merge, an error message will be sent.
• When an application area is replaced, any existing files assigned to it in the target model are retained.