Hi. We need to create a new test environment.
I'm planning to use SAVLIB/RSTLIB to do so once the new data libraries are created. The SAVLIB will be from our Production data libraries
My concern is using (or not using) Save Access Paths ACCPTH *YES as we not only have LFs against the PFs in the main data library but LFs in a custom library that are against PFs in the main library.
Both the main and custom libraries will be created for the new environment.
If I remember right, I've experienced a problem where, if we RSTLIB where we've saved access paths during SAVLIB of the new main library, the LFs in the Production custom library will now point to the new main library. I'm thinking instead I want to specify ACCPTH *NO for both the main and custom SAVLIBs and am okay with recompiling the custom library LFs as we have CLs to do this. Does this sound like the right way to go? My other question is if I do use ACCPTH *NO will it then have to rebuild all the access paths for the LFs in the main library and does this happen immediately upon restore or only as someone accesses each file?
Pinned topic Creating new test data library from Production database
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-09T06:12:22Z at 2013-01-09T06:12:22Z by SystemAdmin
QSECOFR 100000QNP855 Posts
Re: Creating new test data library from Production database2010-11-04T15:46:10ZThis is the accepted answer. This is the accepted answer.Hi Stephanie,
If you saved both the production library containing the physical file and the separate library containing a logical file, when you restore the separate library (no matter if access paths are saved or not), when the access paths are restored or created then they will be pointing to the original physical file and not the newly restored physical file.
You need to do the following:
1. Save and restore ONLY the production library containing the physical file (will save time if you save access paths)
2. Change and recompile the DDS source file
3. CRTLF in the new separate library by specifying the newly recompiled DDS source
*Note: If you plan on saving/restoring the separate library, you can OMIT those logical files
To answer your second question, If ACCPTH(*NO) is specified, then the access paths are rebuilt on the restore.
Re: Creating new test data library from Production database2010-11-05T14:28:30ZThis is the accepted answer. This is the accepted answer.Thanks, Brian. I'm almost there...
So with ACCPTH *YES there will be no issue where the LFs in the new main library point, i.e. they will point to the new main library PFs?
For the new custom library, again ACCPTH *YES, I'll restore all (omitting not really an option, it would take me all day to type them) and immediately kick off our CL to recompile the LFs that are against the new main library before anyone can do any damage.
I'm confused by what you said here:
2. Change and recompile the DDS source file.
I should also tell you that there are plenty of custom PFs with their own LFs in the custom production library and these would also be needed in the new custom library. Those LFs should act the same as main library LFs in terms of access path, I'm thinking.
I thought I had heard that OS/400 6.1 or 7.0 (we're on 5.4) would allow a SAVLIB/SAVOBJ and RSTLIB/RSTOBJ by Attribute and omit by Attribute but I'm not seeing it in the Memos to Users, at first glance anyway. That could come in handy!
Thanks again in advance.
QSECOFR 100000QNP855 Posts
Re: Creating new test data library from Production database2010-11-06T19:21:03ZThis is the accepted answer. This is the accepted answer.
- StephanieS26 270003NG7T
Re: Creating new test data library from Production database2010-11-09T13:30:36ZThis is the accepted answer. This is the accepted answer.That's good about the new main library.
We don't really have a choice about restoring the custom library. We need the custom PFs that reside there as well as other objects (for example all custom source including the LF DDS) and we can't do a RSTLIB and select by file attribute.
If we do the custom library restore, will the LFs in the Production custom library still be intact and point to Production main library as well, so the same custom LF in both custom libraries will point to the main Production PF? And doing a CRTLF on the custom LFs (with our LIBL set properly of course) will rebuild the access path to the new main library PF? I just don't want to do any damage to original Production libraries. One thing we can be sure of is that no user will have access to these new libraries until we give it to them so when those access paths are pointed in the wrong path, it will kind of be in a vacuum, unless the Production custom LFs have been compromised.
If you still think RSTLIB on the custom library is a bad idea I guess we could rig some kind of CRTDUPOBJ CL to handle building the new custom library.
Yes, that's what our CL does is recompile the custom LFs
using CRTLF but I'm not sure about the 2-step process you refer to, "Instead, you will need to first recompile the source file (maybe this is what your CL does?) and then CRTLF using the new source file". Our source goes with the new custom library build so typically we just need to set LIBL and recompile with CRTLF...
Thanks for your help... and patience!
SystemAdmin 110000D4XK353 Posts
Re: Creating new test data library from Production database2013-01-09T06:12:22ZThis is the accepted answer. This is the accepted answer.You could firstly try a free data recovery program, which has helped me restoring my important files from a corrupted drive.
If this freeware still cannot fix your problem, your drive must be terribly damaged. You’d better take it to a specialist or special recovery company.