In addition--a point I've made in other threads that touch on 'recovery'--do not depend on 'one final step' in production to allow for recovery elsewhere. You must assume that production has died an instant and agonizing death. There will be *no opportunity* for any further action there. What you get in the recovery environment is not a whit (no pun intended) more than what you have provided in advance of Armageddon. Nothing beats replication, the more the better.
. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jerry Whitteridge Sent: Wednesday, November 25, 2015 12:09 PM To: [email protected] Subject: (External):Re: User Cats and Replication Sites In addition to Lizette's comments - In the traditional Unload, Transmit, Load data transfer model you have to wait for the unload to complete before the transmit can start (I know Gil - Pipes in Unix can do things that classic MVS cant/doesn't). When writing large amounts of data this can induce long delays before the transmits can start. By using replication as soon as the first track is written into the replication pool the data starts it journey to the remote site. Once the tracks are all synced in the receiving replication pool bringing the volumes on line then has the data accessible to the receiving site. Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 925 738 9443 Corporate Tieline - 89443 If you feel in control you just aren't going fast enough. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Wednesday, November 25, 2015 11:59 AM To: [email protected] Subject: Re: User Cats and Replication Sites To try and answer the question : Why do this? If you do normal dumps/unloads of production data and ship it to your DEV/QA/Lifecycle environment - you might use productions like NDM, FTP, IND$FILE, etc... slow and dependent on your IP traffic or pipes. Or you might dump to tapes and either mail physical tape or have your tape environment use its own replication process. With Replication you could land your data needed in the lifecycle environment and use the speed of Replication. So, just pushing the data to a new location faster. Skip - This is what I was thinking. I tend to over think, so this is very helpful. Thanks all very much Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of J O Skip Robinson > Sent: Wednesday, November 25, 2015 11:09 AM > To: [email protected] > Subject: Re: User Cats and Replication Sites > > (Reposting with edited subject. Sorry that I forget to massage it so > often.) > > In order to make a 'foreign' catalog available, I don't believe you > DEFINE RECAT > because the catalog already exists. IMPORT CONNECT (whereby you name > the > volume) creates all the necessary pointers in the current system's > master catalog. > Furthermore, IMPORT CONNECT does not require that the catalog be > physically accessible. CATALOG task does not attempt to access the > catalog until you perform > some action that requires opening it, such as LIST. If the catalog is available, the > catalog is opened and the action completes. Otherwise you get a > catalog open error. I'm basing these observations on experience with > making various master catalogs available to each other, which we do a > lot. The foreign catalog becomes a > 'user catalog' in the current master regardless of its status in the > foreign system. > > So in the steps you propose, eliminate 3. Step 4 can be done at any > time even if the > volume is (still) offline; even now. Assuming that you IMPORT CONNECT > ahead of time, you're left with 1, 2, and 5. As for aliases--if you > want them--you can DEFINE > ALIAS at any time after IMPORT CONNECT. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > [email protected] > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of R.S. > Sent: Wednesday, November 25, 2015 2:33 AM > To: [email protected] > Subject: (External):Re: User Cats and Replication Sites > > As far as I udnerstand you replicate UCAT, but cataloged datasets > (volumes with > datasets). > I don't see any value in such approach. What's your goal? > > Note: it could worth to consider to replicate a set of datasets and UCAT. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2015-11-24 o 23:24, Lizette Koehler pisze: > > I have two sites, A and B > > > > A usercat is replicated (asynchronously) from Site A to Site B (one > > way trip) The volumes are offline in SITE B and ONLINE in SITE A > > > > I want to use that usercat on Site B at some point. > > > > So my plan is to > > 1) Break Replication > > 2) Vary the replication Volumes online to Site B > > 3) Define RECAT the USERCAT > > 4) Connect the UCAT to my MCAT on SITE B using IMPORT CONNECT. > > 5) Then access the files and VSAM datasets on SITE B through the > > replicated UCAT. > > > > I am fairly comfortable with an IMPORT CONNECT, but was wondering if > > there were other steps other than ensuring the aliases from Site A > > to this UCAT are available/installed/defined in Site B. > > > > > > Anything I need to be concerned about? > > > > I have discussed a couple of ideas with my team, but wanted to see > > if there was any other wisdom in this group that might help me make this > > right. > > > > Thanks > > > > > > Lizette Koehler > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN "Email Firewall" made the following annotations. ------------------------------------------------------------------------------ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately.. ============================================================================== ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
