×
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.
The library list during restore has nothing to do with the
file.mbr objects established as based-on for that restore, just as
the library list during CRTDUPOBJ has no effect on the based-on
established per:
http://archive.midrange.com/midrange-l/200905/msg01136.html
http://archive.midrange.com/midrange-l/200805/msg01194.html
http://archive.midrange.com/midrange-l/200805/msg01180.html
What file is eligible for the based-on depends on, in which
library the based-on file was located when the save was taken, or
which library the based-on and dependent logical files were located
when the CRTDUPOBJ is issued. Thus adjusting the *LIBL will have no
effect on the result of either RSTOBJ or CRTDUPOBJ of a logical
file, with regard to what file the logical becomes a dependent of.
http://archive.midrange.com/midrange-l/200803/msg01577.html
http://archive.midrange.com/midrange-l/200912/msg00186.html
http://archive.midrange.com/midrange-l/200906/msg00480.html
The given scenario as I understand, is a restore without any
CPF3204 "based-on object not found". It seems there is instead, an
undesirable dependency which is established to an existing file.
Unless all dependent logical files can be ensured to restore first,
I do not think there would be any deferrals, though even if there
were, I believe they would attach according to what was saved even
if an alternate based-on became available in some other library;
i.e. RSTDFROBJ does not have a NEWLIB() parameter to override in
what library the LF should look to find the depended-on [based-on]
file.mbr objects.
Regards, Chuck
Lennon_s_j@xxxxxxxxxxx wrote:
If I understand correctly, you have LFs in your custom library
over PFs in your standard library.
When you restore the custom library, is the standard library
still somewhere in your library list? Taking it out *might*
help.
And I seem to recall reading somewhere lately that there was an
enhancement in V6R1 to the restore commands that helped in cross
library dependency restores.
On 1/29/2010 11:42 AM, Paul.Wilber@xxxxxxxxxxxxxxxxxxx wrote:
We periodically refresh our test environment with production
data. We have a two different data libraries in each
environment, one for standard objects and one for custom
objects. We restore the standard objects first then the custom
objects. After the restore some of the logicals in the test
library still point to physicals in the production library. We
currently have a utility to correct this by using CRTDUPOBJ. We
dup from the production library to a different library, delete
the logical in test and dup the duplicated object into test and
then delete the previous duplicated object. Example; Dup LOGICAL1
from PROD to DIFFLIB, dup LOGICAL1 from DIFFLIB to TEST, delete
LOGICAL1 in DIFFLIB. This corrects the dependencies but is
there a way to perform the restore so that all logicals point
to the test library?
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
