Ron, Thanks for the information. As I said in an earlier post, we don't have DFDSS, so I can't do dumpconditioning. I will take your statement, "This is the problem with the 2nd LPAR backup method - it's an accident waiting to happen.", and show it to my boss. That might be enough leverage to get FDRINSTANT, or the other product which I can't remember the name of, but I doubt it.
Another problem with the 3rd lpar approach is that we have a GRS ring, and as I understand it, a 3rd lpar contributes logarithmically to the wait times. That is why the 3rd lpar would be probably shut down except for the weekly pack backups. One question I do have though is if I am IPLing from a single or 2 pack system, and I have a few things online, such as the Zara tape catalog (which I know nothing about yet but soon will learn), or the usercatalog the tapes are cataloged in, what happens since there is a duplicate volume that was flashed? Is that part of the accident waiting to happen? By the way, we don't have DFHSM either, and I don't know what FRBACKUP is, but I assume that HSM is required. I'm not sure if we have FDRABR or not. I'll probably call them on Monday. I know we have FDR and I think we have Compaktor, but I'm not sure. In answer to Tom Conolly, since my internet connection at my hotel is so slow, I will look at FDRINSTANT, but my hopes are not too high. It was good talking to you several days ago. Eric Bielefeld On Sat, 6 Sep 2008 00:21:22 -0700, Ron Hawkins <[EMAIL PROTECTED]> wrote: >Eric, > >For your 2nd LPAR, have you considered simply cloning the existing system >and disabling the products that may cause you grief with your licenses or >MIPS usage? I think it will make your Basic Sysplex a lot easier to build >and maintain in the long run. > >You've already figured the need to share UCATs, and keeping the Production >Volumes edited out of that system stop any accidental access. If you don't >use DUMPCONDITIONING it still means that datasets on the FC target volumes >can be accessed accidentally, so you may want to disconnect unnecessary >catalogs, and remove alias associations. This is the problem with the 2nd >LPAR backup method - it's an accident waiting to happen. > >I guess you have looked at DFSMShsm FRBACKUP. If not, you may want to have a >look, but the applicability will depend on how much of your data is SMS >managed, and whether you wish to use FCV2 consistency groups (still appear >to unsupported for FRBACKUP). > >DUMPCONDITIONING, is something I think you may want to have a look at it. >Seeing as FDR is a complete functional replacement for DFSMSdss I believe it >also supports this. You will find that you can accomplish everything you >want to do from a single system. > >Setting up a 2nd LPAR for backup was something a few shops did back in the >early days of Snapshot, TimeFinder and Shadowimage, but DUMPCONDITIONING >with FlashCopy was developed to get around the need for a backup LPAR. Ipso >facto you no longer need a 2nd LPAR if you have FlashCopy compatible >products. > >Ron ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
