× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We have 7 full copies of Production on DEV.
Each copy has its own set of libraries, 22 total.
Manager, programmers, trainers control and inform us when the refreshes are needed.
On any given night, we can refresh up to 3 environments, have them ready by 8 am.

We use AJS, advanced job scheduler.

Production - Nightly FULL save at 10:00 am every night.
R&D -
Each environment has two jobs.
1) DLTLIB job - runs at 5 PM as needed.
2) RSTLIBBRM job - runs at 00:30 as needed.

One simple CL program that does a dummy RSTLIBBRM, confirms if volume is available, in case Production Save ran longer.

I remember years back, Power5, before we had a tape library and BRMS, SAVRSTLIB(s) for one environment was taking up to 15 hours.
It was a chore back then.

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Matt Olson
Sent: Monday, September 28, 2015 1:10 PM
To: Midrange Systems Technical Discussion
Subject: RE: Quickest way to copy data from production LPAR to DEV LPAR

Thanks Paul and Larry.

Paul, what do you do in regards to the DEV partition in regards to multiple developers? The Dev partition presumably has ongoing work from multiple developers on it, and if you restored you may be whipping out changes a developer has made? How do you segment each developers work?

Matt



-----Original Message-----
From: Steinmetz, Paul [mailto:PSteinmetz@xxxxxxxxxx]
Sent: Monday, September 28, 2015 11:56 AM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxx>
Subject: RE: Quickest way to copy data from production LPAR to DEV LPAR

Ditto SAVRSTOBJ and/or SAVRSTLIB for small amount of data.

However, large amounts of data. .5 tb could take long and use a large amount of temp space for the temporary savf.

Another solution, which we use often, is to do a RSTLIB or RSTLIBBRM from your latest production save.
We do a full save on Production every night, following the save RSTLIBBRM on DEV is run to refresh DEV.
We've automated the entire process, save is 2 hours, restore is 2 hours, P7 LTO5 fiber drives.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Monday, September 28, 2015 12:34 PM
To: Midrange Systems Technical Discussion
Subject: Re: Quickest way to copy data from production LPAR to DEV LPAR

SAVRSTOBJ Hands down the best way for such things. Can be on line, can
be batch, scheduled etc. Maintains all attributes about the object.

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 9/28/2015 12:26 PM, Matt Olson wrote:
*This message was transferred with a trial version of CommuniGate(r)
Pro* I am attempting to copy data from a file in the production LPAR to the DEV LPAR and have yet to find an easy way to do it.

Here is what I looked at so far:


1. iSeries Navigation Export/Import function. No Go, only works with flat files, can not point to other system.

2. DDM (so far not working due to bug in iSeries navigator with base database *LOCAL name on DEV LPAR being same as production LPAR and navigator apparently doesn't understand aliases to overcome this limitation). Apparently if we could get this working you can do a copy/paste from one system to another in iSeries navigator (would be awesome if it worked).

3. SAVF, FTP, restore SAVF, do a rain dance.

So far nothing is easy. I'm about ready to just build a Microsoft SQL Server SSIS data transfer package but it seems like I shouldn't have to do this. Option #3 has been the historical mode of operation but is too time consuming.

Any other thoughts on how to do this quickly with as few steps as possible?

Matt

--
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.

--
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.


--
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.