150 lines
8.7 KiB
HTML
150 lines
8.7 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="en-us" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow" />
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="DC.Type" content="concept" />
|
|
<meta name="DC.Title" content="Referential integrity and CL commands" />
|
|
<meta name="abstract" content="Referential integrity affects the characteristics of some CL commands." />
|
|
<meta name="description" content="Referential integrity affects the characteristics of some CL commands." />
|
|
<meta name="DC.Relation" scheme="URI" content="rbaforzahfrca.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="rbaforzahfrc3" />
|
|
<meta name="DC.Language" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|
<title>Referential integrity and CL commands</title>
|
|
</head>
|
|
<body id="rbaforzahfrc3"><a name="rbaforzahfrc3"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Referential integrity and CL commands</h1>
|
|
<div><p>Referential integrity affects the characteristics of some CL commands.</p>
|
|
<ul><li class="liexpand"><strong>Add Physical File Member (ADDPFM)</strong>: <div class="p">In the case where a constraint
|
|
relationship is defined between a dependent file and a parent file each having
|
|
zero members: <ul><li>If a member is first added to the parent file, the constraint relationship
|
|
remains in the defined state.</li>
|
|
<li>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.</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li class="liexpand"><strong>Change Physical File (CHGPF)</strong>: <div class="p">When a constraint relationship
|
|
exists for a file, you cannot change certain parameters available in the CHGPF
|
|
command. The following parameters are restricted: <dl><dt class="dlterm">MAXMBRS</dt>
|
|
<dd>The maximum number of members for a file that has a constraint relationship
|
|
is one: MAXMBRS(1).</dd>
|
|
<dt class="dlterm">CCSID</dt>
|
|
<dd>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.</dd>
|
|
</dl>
|
|
</div>
|
|
</li>
|
|
<li class="liexpand"><strong>Clear Physical File Member (CLRPFM)</strong>: <p>The CLRPFM command fails
|
|
when issued for a parent file that contains records and is associated with
|
|
an enabled referential constraint.</p>
|
|
</li>
|
|
<li class="liexpand"><strong>FORTRAN Force-End-Of-Data (FEOD)</strong>: <p>The FEOD operation fails when
|
|
issued for a parent file that is associated with an enabled referential constraint
|
|
relationship.</p>
|
|
</li>
|
|
<li class="liexpand"><strong>Create Duplicate Object (CRTDUPOBJ)</strong>: <div class="p"><img src="./delta.gif" alt="Start of change" />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:<ul><li>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.</li>
|
|
<li>If the dependent file is duplicated, then the TOLIB is used to determine
|
|
constraint relationships:<ul><li>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.</li>
|
|
<li>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</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<img src="./deltaend.gif" alt="End of change" /></div>
|
|
</li>
|
|
<li class="liexpand"><strong>Copy File (CPYF)</strong>: <p>When the CPYF command creates a new file and
|
|
the original file has constraints, the constraints are not copied to the new
|
|
file.</p>
|
|
</li>
|
|
<li class="liexpand"><strong>Move Object (MOVOBJ)</strong>: <p>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.</p>
|
|
</li>
|
|
<li class="liexpand"><strong>Rename Object (RNMOBJ)</strong>: <p>The RNMOBJ command renames a file within
|
|
the same library or renames a library.</p>
|
|
<p>An attempt is made to establish
|
|
any defined referential constraints that can exist for the renamed file or
|
|
library.</p>
|
|
</li>
|
|
<li class="liexpand"><strong>Delete File (DLTF)</strong>: <div class="p">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: <dl><dt class="dlterm">*RESTRICT</dt>
|
|
<dd>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.</dd>
|
|
<dt class="dlterm">*REMOVE</dt>
|
|
<dd>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.</dd>
|
|
<dt class="dlterm">*KEEP</dt>
|
|
<dd>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.</dd>
|
|
</dl>
|
|
</div>
|
|
</li>
|
|
<li class="liexpand"><strong>Remove Physical File Member (RMVM)</strong>: <p>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.</p>
|
|
<p>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.</p>
|
|
</li>
|
|
<li class="liexpand"><strong>Save and restore commands</strong>: <p>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.</p>
|
|
<div class="p">If the dependent file is restored,
|
|
the TOLIB is used to determine constraint relationships: <ul><li>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.</li>
|
|
<li>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.</li>
|
|
</ul>
|
|
</div>
|
|
<p>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.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbaforzahfrca.htm" title="These topics discuss how to use referential constraints in your database to ensure that it contains only valid data.">Ensure data integrity with referential constraints</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |