Re: changing logical files to point to different physicals

On 20-Jun-2014 11:08 -0500, Gqcy wrote:

We have processes that will make copies of the production files into
a frozen library, and we append year on the end of the physical file
name... the logical files in this frozen library kept their
production name, they just pointed over the physical with the
appended year...

our process _had_ been to:
1) copy the production physical to frozen library, appending year.
2) delete all logicals over the previous years physical.
3) go into the DDS of the logicals and change the PFILE to the new
physical
4) re-compile the logicals

"somehow".... this close we got away with NOT updating the DDS or
re-creating the logicals, but they are pointing at the new
physical... (the person that ran the close procedure doesn't remember
how they did it?!?!)

I don't see how you can "change" a logical file, to point at a
different physical, but it does indeed appear to have happened...

General object auditing and journaled files would allow reviewing the logging to see what transpired; probably a joblog of the /process/ would also reveal the deviation.

The logical files or member(s) would either have to have been restored or re-created, or the physical file(s) would have had to been [moved and] renamed, in order to change the "logical files to point to different physical files"; in the case of just [move and] rename, the PFs are not really "different", the would just be of another name. Another possibility, but I infer from the scenario that such an effect was not implied, both the PFs and LFs could have been moved into the other\frozen library; the /new/ files would have been created, duplicated, or restored into the original library.

What Charles showed in a followup reply is a typical process to effect making /copies/. However that process [CRTDUPOBJ of the PFs, then CRTDUPOBJ of the LFs, then RNMOBJ of the PFs] was not what was used in the described scenario, *if* the definition of not "re-creating the logicals" implies the creation date was not indicative of when the processing occurred. If instead the implication that the Logical Files were not re-created was based merely on the lack of an update to the DDS, i.e. per the source change date, then just like with CRTDUPOBJ, the rename could have been delayed until after the /create/ of the new logical files. While Remove Member (RMVM) and then the Add Logical File Member (ADDLFM) could be utilized to change the based-on file, that is more complicated in the given scenario [as I understand it]. Similarly, the use of Restore Object (RSTOBJ), with either Delete File (DLTF) or RMVM done prior, is more complicated in the given scenario [as I understand it].