×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de CRPence
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. The text intends to warn that for the additional work required.
<<<
-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de smorrison@xxxxxxxxxxxxxxxxxxx
If the logical files list all of the fields, those definitions (including field length) will not be changed by CHGPF. If the LF just lists keys in the DDS, field length changes and new fields will be included in the LF when CHGPF modifies the PF.
Generally, CHGPF will set the PF and all LFs back to the original state if it determines it cannot complete the command.
<<<
-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de CRPence
DSPDBR
RCDFMT(*ALL) of the PF should be done to know what LF will change, and that the exception of that list from DSPDBR RCDFMT(*NONE) represents those LF that will not change;
<<<
Ok I think I grasped the situation. Just by coincidence, I had to restore some old files and had the case of an LF compiled on 2 PF's, one with 20 million lines. The CHGPF didn't work on the logical because of the fields listed in its DDS. I was able to verify this with DSPDBR and found another logical in the same situation. Great work thanks!
midrange.com
