Re: CHGPF

[CRPence <CRPbottle@xxxxxxxxx>]

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