Referential integrity and CL commands

 

Referential integrity affects the characteristics of some CL commands.

• Add Physical File Member (ADDPFM): In the case where a constraint relationship is defined between a dependent file and a parent file each having zero members:

  • If a member is first added to the parent file, the constraint relationship remains in the defined state.

  • If a member is then added to the dependent file, the foreign key access path is built, and a constraint relationship is established with the parent.

• Change Physical File (CHGPF): When a constraint relationship exists for a file, you cannot change certain parameters available in the CHGPF command. The following parameters are restricted:

  MAXMBRS

  The maximum number of members for a file that has a constraint relationship is one: MAXMBRS(1).

  CCSID

  The CCSID of a file that is not associated with a constraint, can be changed. If the file is associated with a constraint, the CCSID can only be changed to 65535.

• Clear Physical File Member (CLRPFM):

  The CLRPFM command fails when issued for a parent file that contains records and is associated with an enabled referential constraint.

• FORTRAN Force-End-Of-Data (FEOD):

  The FEOD operation fails when issued for a parent file that is associated with an enabled referential constraint relationship.

• Create Duplicate Object (CRTDUPOBJ): If CST(*NO) is specified, constraints will not be duplicated in the new file. If CST(*YES) is specified, constraints will be duplicated. The following rules describe how constraints are duplicated:

  • If the parent file is duplicated either to the same library or to a different library, the system cross reference file is used to locate the dependent file of a defined referential constraint. Also, the system attempts to establish the constraint relationship.

  • If the dependent file is duplicated, then the TOLIB is used to determine constraint relationships:

    • If both the parent and dependent files are in the same library, the referential constraint relationship will be established with the parent file in the TOLIB.

    • If the parent and dependent files are in different libraries, then the referential constraint relationship of the duplicated dependent file will be established with the original parent file

• Copy File (CPYF):

  When the CPYF command creates a new file and the original file has constraints, the constraints are not copied to the new file.

• Move Object (MOVOBJ):

  The MOVOBJ command moves a file from one library to another. The system attempts to establish any defined referential constraints that can exist for the file in the new library.

• Rename Object (RNMOBJ):

  The RNMOBJ command renames a file within the same library or renames a library.

  An attempt is made to establish any defined referential constraints that can exist for the renamed file or library.

• Delete File (DLTF): The DLTF command has an optional keyword that specifies how referential constraint relationships are handled. The RMVCST keyword applies to the dependent file in a constraint relationship. The keyword specifies how much of the constraint relationship of the dependent file is removed when the parent file is deleted:

  *RESTRICT

  If a constraint relationship is defined or established between a parent file and dependent file, the parent file is not deleted and the constraint relationship is not removed. This is the default value.

  *REMOVE

  The parent file is deleted, and the constraint relationship and definition are removed. The constraint relationship between the parent file and the dependent file is removed. The dependent file's corresponding foreign key access path or paths, as well as the constraint definition, are removed.

  *KEEP

  The parent file is deleted, and the referential constraint relationship definition is left in the defined state. The dependent file's corresponding foreign key access path and constraint definition are not removed.

• Remove Physical File Member (RMVM):

  When the member of a parent file in a constraint relationship is removed, the constraint relationship is put in the defined state. The foreign key access path and referential constraint definition are not removed. The parent key access path is removed because the parent member was removed; the parent constraint definition remains at the file level.

  When the member of a dependent file in a constraint relationship is removed, the constraint relationship is put in the defined state. The parent key access path and constraint definition are not removed. The foreign key access path is removed because the dependent member was removed; the referential constraint definition is not removed.

• Save and restore commands:

  If the parent file is restored to a library, the system uses the system cross reference files to locate the dependent file of a defined referential constraint. An attempt is made to establish the constraint relationship. If the dependent file is restored, the TOLIB is used to determine constraint relationships:

  • If both the parent and dependent files are in the same library, the referential constraint relationship is established with the parent file in the TOLIB.

  • If the parent and dependent files are in different libraries, the referential constraint relationship of the duplicated dependent file is established with the original parent file.

  The order of the restore of dependent and parent files within a constraint relationship does not matter (parent restored before dependent or dependent restored before parent). The constraint relationship will eventually be established.

 

Parent topic:

Ensuring data integrity with referential constraints