You are on page 1of 3

Changing a PF definition with CHGPF

Note that removing or changing field names, attributes, or sizes can have a major impact on LFs and existing programs or utilities which use a file. if you change a file's DDS source code and compile it, you create the *FILE object again. The system will ask you if you want to delete the old *FILE object before it creates the new one. Be careful. ==> if the source type is PF, you will lose the data records the physical file previously contained! Since the member contains the data, and the object contains the member and the object is being deleted, you should be careful here. (If the source type is LF, you are just recreating the access path to the data in the based on PF. No worries here.) ==> if the physical file (PF) has dependent logical files (LF), the LFs must be deleted before the PF can be deleted and rebuilt. After all, LFs are access paths to PF data -- if there is no PF, then there is nothing the LF could point to. The system will not allow orphan LFs. the system provides a command to change a PF without losing data or worrying about dependent logicals: CHGPF -- CHanGe Physical File CHGPF will change the PF you specify based on your revised DDS specs only if you provide the name of your DDS source file (QDDSSRC) to the command. Try it out and you will see how the command defaults will find the file's member name. The change will be successful in most cases where field names have not been changed. Check the messages the system puts in the job log. If the system cannot complete the CHGPF command (because it would have to guess or compromise data integrity), please read on. The steps to change a *FILE definition without using CHGPF are: 1. Rename or copy your PF-DTA *FILE to another name in order to preserve the data

if you rename a PF, any LFs based on the old file name are now pointing to the new file name...what else would those LFs point to? That's OK but you may want to delete the LFs first. if you copy a PF, the old PF (and any LFs based on it) is unchanged. The new PF has no LFs pointing to it.

CRTDUPOBJ (WRKOBJPDM option 3) makes a clone of an object and requires certain authorities ... no problem if you created it.

2. change the DDS source 3. delete any LFs which are based the PF 4. recompile (CRTPF) the DDS 5. Use CPYF to copy the data from the renamed/copied file (in step 1.) to the newly recreated file.

If the record format did not change, e.g. you just changed some column headings or an editing keyword but did not change the field names, lengths or data types, then a simple CPYF will move your data from the old file to the new. (So would using the CHGPF command -- see above) Copying records whose from-file and to-file record formats are different needs the Format Options, FMTOPT, parameter...

If, and only if, you just changed one or more field names, you can use the FMTOPT(*NOCHK) option to copy data left to right, buffer position by buffer position between files disregarding any differences in the DDS specifications. Be careful with this. When using the *NOCHK option, change only the field names. Do not change any field lengths or data types. Do not add or delete any fields. Buffer locations (column positions) in the two files must match. Data types must be compatible -they will not be converted.

When record formats are different for reasons other than simple field name changes, you can use ForMaT OPTions to:

*MAP fields whose names are the same in the two files and whose field attributes are compatible. Data conversions will be done where possible. *DROP fields in the from-file record format that do not exist in the tofile record format. Dropped fields are not copied. Data in these fields is lost. The dropping and mapping of fields is based on a comparison of field names. Unless all the fields in the from-file have the same name in the to-file, you must specify *DROP.

If the names are the same, but the attributes or position within the record is different, you must specify *MAP. There must be at least one like-named field in both record formats to do mapping. See the AS/400 "Data Management" manual for more information, especially chapter/section: Copying between Different Database Record Formats (FMTOPT Parameter).

6. Now that your new PF-DTA *FILE has been created and repopulated with data:

delete the old, original PF-DTA file if it is no longer needed change the DDS (as required) of LFs to be based on the new PF and recompile them (CRTLF)

7. you probably need to recompile programs and queries that use the recreated PF and LFs so those objects will know about the new version of those files.

You might also like