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.

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

– INCCHAR(*NONE)<br />

– INCREL(*NONE)<br />

– SRCOPT(*SAME)<br />

– ERRLVL(0)<br />

Restrictions of COMPRESS(*NO) parameter and the CPYF<br />

command<br />

You cannot specify COMPRESS(*NO) for the following types of access paths over<br />

the to-file, including when the access path is contained in a logical file and is based<br />

on the to-file member:<br />

v Unique keys (you specified the UNIQUE keyword in the DDS).<br />

v Select/omit specifications without the DYNSLT keyword (in the DDS for the<br />

file), and immediate or delayed maintenance (MAINT(*IMMED) or<br />

MAINT(*DLY) specified on the CRTPF or CRTLF command).<br />

v Floating-point key field or logical numeric key field (in the DDS for the file), and<br />

immediate or delayed maintenance (MAINT(*IMMED) or MAINT(*DLY)<br />

specified on the CRTPF or CRTLF command). Note that a logical numeric key<br />

field is one of the following:<br />

– A numeric key field in a logical file<br />

– A field specified as a to field on the JFLD keyword that has different<br />

attributes than in the based-on physical file<br />

– A field specified as a sequencing field on the JDUPSEQ keyword that has<br />

different attributes than in the based-on physical file<br />

You cannot specify COMPRESS(*NO) for any of the following cases:<br />

v If you use the JRNPF command to journal the to-file<br />

v If the to-file member is in use or if any access path over the to-file member is in<br />

use<br />

v If you specify an EOFDLY wait time for the from-file on an OVRDBF command.<br />

Details of COMPRESS(*NO) parameter and the CPYF command<br />

COMPRESS(*NO) may allow the system to copy more quickly because records are<br />

transferred in blocks, but this is not always true. Usually, the COMPRESS(*NO)<br />

function does not significantly affect performance. One of the factors you should<br />

consider before you specify COMPRESS(*NO) is that the internal system function<br />

that must be used to perform this type of copy invalidates any keyed access paths<br />

that use the to-file member before the records are copied and then rebuilds the<br />

access paths after the copy is complete. The run time and resource that are<br />

required to rebuild the keyed access paths may be larger than the performance<br />

benefit that is gained by copying deleted records.<br />

If COMPRESS(*NO) is not specified, the system may still use the internal functions<br />

to perform the copy, but the choice of how the copy is performed is based on the<br />

number of records in the from-file and to-file members before the copy, and the<br />

number of keyed access paths over the to-file member.<br />

If MBROPT(*REPLACE) is specified, all keyed access paths over the to-file member<br />

must be invalidated and rebuilt, so specifying COMPRESS(*NO) does not cause<br />

any additional overhead for rebuilding access paths.<br />

If the from-file is a keyed physical file and neither a FROMRCD nor TORCD<br />

relative record number value is specified on the copy commands to force the file to

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

Saved successfully!

Ooh no, something went wrong!