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
