Re: CHGPF

The reference to /logical/ may be somewhat misleading for those who understand that to mean the /logical database file object [type *FILE]/, especially given the question by the OP. Or at least might be inferred to be more work than what should be expected. When database related documentation suggests that an /access path/ is to be [re]built, it refers not to the logical file object, but to the index object of the logical file. As an object based system, the LF provides the definition for, and encapsulates the index object. That index can be rebuilt over the data using the definition it maintains as part of the object. The /file/ object does not need to be recreated for that index to be rebuilt. Most index rebuilds are initiated automatically by the system either asynchronously via an event to QDBSRV01 and then passed on to the QDBSRV## runpty-52 jobs, or synchronously to the requester of an Open of the file by its key.

The DLTDEPLF(*YES) can be used to request that LF dependent on a removed field, should automatically be deleted. The CHGPF SRCFILE() should be prevented when such a DROP COLUMN request occurs using the named DDS source.

Regards, Chuck

Pat Barber wrote:

If you change certain attributes, new logicals may need to be
created.

Suppose you changed the length of field that was a
key in a logical ? That logical would have to be rebuilt.

What would happen if you deleted a field that had logicals
built over that name ? (I have never tried that one).

Any time you start changing a file, you need to be very
aware of the end results. Even the help screen says to
"make a copy" prior to making any changes.


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 ?