|
Dave A couple more thoughts.1. Yes, SAVOBJ onl goes down to the object type level. It's worse than you think - any DSPFs or PRTFs or any other object of type *FILE will be saved if you use generics that they match.
2. You can build a SAVOBJ from the objects, from the DSPOBJD output, as you obviously know. But you are limited to 300 object entries (including generic ones). There is an API, QSRSAVO, that lets you specify many more. I would use API QUSLOBJ instead of DSPOBJD to generate the object list, esp. as I'm comfortable with user spaces and APIs. It can be faster but is not a gain if this is run only once in a while.
3. There is good documentation on what happens when you save/restore PFs and related LFs. The order is crucial, as well as what exists where. Chapter 9 of the Backup and Recovery manual http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/info/rzaiu/sc415304.pdf has a section on how database files are handled. If you've not seen this, it will reward careful reading and answer things better than I can from memory. There's also a brief section on the order of restoring related objects.
4. Use DSPFD on the logical files in each test library to see what they are actually pointing to. Is all the restoring being done on the same system as the production files, or is it to a different system? Your narrative suggests the same box.
5. Logical files created in the test libraries without having the physical files present there first can result in what you describe. It does not really come from the SAV/RST process, but see the manual for more on this.
6. Once you have the PFs in the test libraries (can be empty) and have the LFs pointing to them properly, then you could use the CPYFRMTAP command to replace the contents of the PFs without having any adverse affects, AFAIK. I also think a restore should work, but it's been a while. I THINK you can restore the PF while the LFs are in place, but I'm not sure. So is you save the PF and its dependent LFs together, you are safe - the system handles this just fine. My concern comes when saving only the PF and restoring it - I don't know if it is like deleting the PF while its LFs still exist - this cannot be done.
But CPYFRMTAP avoids this - it does a CLRPFM, which the system will handle by updating the indexes. The PF is not deleted in this case.
7. You ask about access paths - LFs ARE the access paths, as well as a key on the PF and various constraints. Also SQL indexes - views are another matter altogether, I think. This is partly why I mention saving PFs and related LFs together if you are going to restore them together.
8. Finally, what about using DDM files and/or remote SQL to get the data over? Avoid tape altogether? DDM files take up no real space on DASD and are a communications portal, so to speak - they point at a remote machine, even using IP tp make the connection.
Am I getting the point of any of this? Hope so. ;-) Good luck Vern At 06:41 PM 8/29/2005, you wrote:
Vern, Thanks for the ideas. Yeah, I am aware of a solution using the DSPOBJD. But before we thought of using DSPOBJD..., Let me lay out in a little more detail what I'm trying to do and what we've run into using the SAV technique. I think you're talking about the SAVOBJ command. At least from what I can figure out, SAVOBJ only allows a gross backup of a particular library, that is to say PF and LF and allows you to save them as a SAVF. Yes, I know you can use some wildcards in the command to narrow what your backing up, but if I want to back up all the PF in a library I can not say particular attributes like PF, I have to back up both (unless I use the DSPOBJD technique first). So, using the "native" technique my systems programmer was stuck with backing up both PF and LF as they are of type FILE. So, he'd save the following: All FILES of library CXLIB, CRLIB, WFLIB and LXLIB. These are the production libraries. We need to restore ONLY THE DATA to the same named files but to different library names, such as, CXLIBTEST, CRLIBTEST, etc. What we found was, the restore went OK but the folks using the TEST environment after the restore were seeing the latest transactions of the PRODUCTION libraries on an ongoing basis!!! My assumption of the cause... because the LFs were forced to be restored from the RSTOBJ command( because there is a TYPE of FILE but there are no attribute choices), you get LFs pointing to the PRODUCTION libraries. So, we'll try the DSPOBJD technique. Now comes the second part... Let's assume DSPOBJD works and we only get the PFs and we restore them as outlined above. What about the LFs and/or access paths in the TEST environmnet(the target)... they are now pointing to data of which some may be new and much expanded in numbers of records since the last refresh? What about access paths...Will I have to run something to keep the users from suffering massive rebuilds of the access paths when they first access the applications or what? I know there is a command. Is it necessary to prevent the first access problem? I assume so. If the DSPOBJD technique works, we'll SAVOBJ to tape to save DASD space during the backup. Hope this makes sense. Any gotchas you can see? Thanks, Dave -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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
