Re: CHGPF

David FOXWELL wrote:

I copied this text from the IBM page concerning the CHGPF command:

If the access path attributes are changed or the attributes of one of
the key fields in the format are changed, a new access path may need
to be built.

Could anyone elaborate on this? What does MAY NEED TO BE mean exactly
? Does anyone know of a condition where the CHGPF will not work ?

That comment simply intends to suggest that care should be taken when changing field and file attributes, as you may end up /causing/ one or more access paths to be rebuilt; effected by the CHGPF itself, not to imply that the user /may need to/ do something outside of CHGPF. That text is not suggesting the request would /not work/. The text intends to warn that for the additional work required, the request can take significantly longer, with more CPU & storage than if\when access paths do not require rebuilding. If an access path is large and important to an application, if that must be rebuilt, although the CHGPF can complete such that control is returned to the requester, the large access path may continue rebuilding longer after the synchronous change and data copy activity has completed. For SQL that means missing keys and statistics such that queries will not perform as well, but for RLA that can mean the attempt to use that LF will delay the application until the access path rebuild is complete.

If for example the CHGPF SRCFILE() ACCPTHSIZ() were issued such that the access path size attribute [or other command parameter that impacts the access path] were to change, the access would be rebuilt during that ALTER. Similarly if a Key field had changed from for example, a Packed Decimal (15, 5) to (20, 5). As well if the format level keyword UNIQUE were removed or added; or similar, like LIFO kwd. Any of those changes would impact an /access path/ definition, such that the index would need to be rebuilt. As well, any shared access paths for logical files that were insulated from the changes to the physical might actually no longer be able to share due to the change, such that some logical access paths would need to be rebuilt.

Although neither explicitly documented nor prevented, a request to use the CHGPF SRCFILE() on an SQL TABLE is problematic [most notably date data type; some attributes are unique to DDS and another unique to SQL], and should be avoided. Use SQL ALTER TABLE to alter any SQL created TABLE.

Regards, Chuck