On 26-Mar-2014 12:33 -0700, CRPence wrote:
There is another doc reference [based on a KB item or Info APAR I
wrote long ago] that describes that the files appearing in DSPDBR
RCDFMT(*ALL) but which do not also appear in DSPDBR RCDFMT(*NONE)
will be re-created as part of the ALTER request. I am sure I have
posted a link to that in the past; I have no yet performed a web
search to find it.
The following web search did not yield exactly what I had hoped, but
did reveal the old APAR from which the docs should have been updated;
and a search of that APAR number was also not fruitful:
In the results of that search:
To determine the logical files that will be <or have been>
changed to match the changes in the physical file, the
request to DSPDBR RCDFMT(*ALL) on the physical file will
provide a list of those logical files.
The list of logical files listed in DSPDBR MBR(*NONE) on
the physical file will show all affected files.
The list of files obtained as a result of the exclusion of
the latter list <ie. MBR(*NONE)> from the former list <ie.
is the list of files which will not reflect changes to the physical
Another post in the above message thread from USENET [maintained in
>Francesco Candia wrote:
>> (Francesco Candia) wrote:
>>> ... I need to know with a program if a logical file will
>>> be modified during a CHGPF <ed: CHGPF SRCFILE(named)>
>>> command or not. How? There is a command or an API? ...
>> Thanks to everibody for answers and few more things.
>> Charles Pence (thank you) points to an APAR: SA67752.
>> This means will be implementation in the future? <<SNIP>>
> This APAR was closed with a 'DOC' closing code; meaning the
> documentation failed to properly describe the outcome. The
> information stated previously should be included in the
> <I assume> DB & SQL guides <CHGPF & ALTER TABLE>
> to determine the outcome <ie. using DSPDBR requests and
> set logic>. <<SNIP>>