30.06.2013 Views

File Management - IBM

File Management - IBM

File Management - IBM

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

128 <strong>File</strong> <strong>Management</strong> V4R5<br />

– A dependent file’s foreign key values that are not null must always have a<br />

corresponding parent key value. That is, if the to-file is a dependent file in a<br />

constraint relationship, the copy operation does not allow non-null foreign<br />

key records that do not have a corresponding parent key record to be copied<br />

into the dependent file.<br />

The copy operation ensures that the data in the parent or dependent to-file is<br />

not damaged. Records may be copied to the to-file provided they do not cause<br />

the constraint relationship to go into check-pending status. If a user attempts to<br />

copy a record that does not meet the constraint relationship rules, the copy<br />

operation will end unless the ERRLVL parameter has been specified (CPYF and<br />

CPYFRMQRYF commands only) with a value greater than zero.<br />

To circumvent the above rules, you can disable the involved constraints before the<br />

copy operation, perform the copy, and then re-enable the constraints. However, the<br />

file is in check-pending status if constraint rules are still not met.<br />

Copying files in check pending status<br />

If the parent or dependent file has an established constraint relationship that is in<br />

check-pending status, the following rules apply:<br />

v If the from-file has an established constraint relationship in check pending, data<br />

access is restricted. If the from-file is a parent file, the command can read and<br />

copy data to the to-file. If the from-file is a dependent file, the command cannot<br />

read data to the to-file, and therefore cannot copy the data to the to-file.<br />

v If the to-file has an established constraint relationship in check pending status,<br />

data access is restricted. If the to-file is a parent file, you can add new records<br />

(you can specify MBROPT(*ADD)). If the to-file is a parent file, you cannot clear<br />

the file (you cannot specify MBROPT(*REPLACE)). If the to-file is a dependent<br />

file, you cannot perform the copy regardless of which MBROPT parameter<br />

keyword you use.<br />

To circumvent the above rules, you can disable the involved constraints before the<br />

copy operation, perform the copy, and then re-enable the constraints. However the<br />

file will be in check pending status if constraint rules are still not met.<br />

Preventing copy errors related to your authority to files<br />

The following table summarizes the authority that is required for the from-file and<br />

the to-file.<br />

Table 16. Authority Required to Perform Copy Operation<br />

From-<strong>File</strong> To-<strong>File</strong><br />

DDM file *OBJOPR *READ *OBJOPR 1 *ADD<br />

Device file 2<br />

*OBJOPR *READ *OBJOPR *READ<br />

Logical file *OBJOPR 3 *READ Not allowed<br />

Physical file *OBJOPR *READ *OBJOPR 1 *ADD<br />

:<br />

1<br />

This is the authority required for MBROPT(*ADD). If MBROPT(*REPLACE) is<br />

specified, *OBJMGT and *DLT authority are also required. If MBROPT(*UPDADD)<br />

is specified, *UPD authority is also required.<br />

2<br />

3<br />

*OBJOPR and *READ authority is also required for any devices used for the file.<br />

Also requires *READ authority to the based-on physical file members for the<br />

logical file members copied.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!