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
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
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