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



To have dependencies restore as desired from a production environment to a test environment, eliminate all cross-library dependencies. An alternate method to consider is to create objects instead of restoring them, then restore only the required data.

FWiW writing the scenario in a command\statement script form is generally much easier to understand than having to read generally descriptive text. As I understand of what was at least somewhat scripted [i.e. what was described as the recovery actions, in words implying commands], I am stumped at how even those described actions would be able to do anything more than create yet another illogical dependency.?

Perhaps rewrite the scenario more like the following, so there is little or no interpretation from general words what the intent might have been to describe what was done in statements and\or commands:

CRTLIB PROD
CRTLIB PRODCUSTOM
CRTLIB TEST
CRTLIB TESTCUSTOM
CRTLIB DIFFLIB
CRTSAVF QTEMP/P
CRTSAVF QTEMP/PC
CREATE TABLE PROD/PF (A INT)
CREATE VIEW PRODCUSTOM/LF AS (SELECT A FROM PROD/PF)
/* LF in lib PRODCUSTOM has based-on PF in lib PROD */
SAVLIB PROD *SAVF SAVF(QTEMP/P)
SAVLIB PRODCUSTOM *SAVF SAVF(QTEMP/PC)
CLRLIB TESTCUSTOM /* CPF3219 dictates order of clear */
CLRLIB TEST
CLRLIB DIFFLIB
RSTLIB PROD *SAVF SAVF(QTEMP/P) RSTLIB(TEST)
RSTLIB PRODCUSTOM *SAVF SAVF(QTEMP/PC) RSTLIB(TESTCUSTOM)
/* Result: LF in lib TESTCUSTOM has based-on PF in lib PROD */
/* Desired: LF in lib TESTCUSTOM has based-on PF in lib TEST */

/* Dependency mismatch correction attempt by script: */
CRTDUPOBJ LF PRODCUSTOM *FILE DIFFLIB
CRTDUPOBJ LF DIFFLIB *FILE TEST[CUSTOM]
DLTF DIFFLIB/LF
/* -?? not sure how above described script might assist ??- */

/* Perhaps this script with PROD vitiated momentarily.? */
MOVOBJ LF TESTCUSTOM *FILE PROD
CRTDUPOBJ LF PROD *FILE TEST
DLTF PROD/LF
MOVOBJ TEST/LF *FILE TESTCUSTOM

Regards, Chuck

Paul.Wilber 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 duplicate from the production library to a different library, delete the logical in test and duplicate 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?


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.