Re: Copying data and/or metadata across LPAR boundaries

I was going to suggest SAVRST* commands, as well. They are part of an OS feature called ObjectConnect - it has to be installed, but it is free. It does use the AnyNet capability, and that is still around, I believe. There's another network thing that has to be installed in recent releases, in order to get AnyNet to work. These are the downsides to it.

So if this is on customer machines, you might be better off rolling your own. The simplest things would be to do some of the following -

1. CRTSAVF QGPL/TRANSFER
2. SAVLIB on the source system
3. Start an FTP session to the target system or LPAR (an LPAR can be considered a separate machine or system, no big deal there)
4. In the FTP session, do the following subcommands -
- bin
- quote site nam 1
- put /qsys.lib/qgpl.lib/transfer.savf
- quote rcmd rstlib etc.
- quit

That's the general idea. If you want to handle errors at each step, go get Scott K's FTP API, you can make CL commands out of it that'll let you know what's happening as you go along.

The RSTLIB could be to a different library than the source, as Charles suggests.

IASPs are definitely NOT the thing to use, especially since you are a vendor and this is probably for customers.

HTH
Vern


On 6/10/2011 7:15 AM, Charles Wilt wrote:

Assuming an environment is completely self contains in a library....

It would seem pretty easy to use SAVRSTLIB (or a manual equivalent)
to save source library on one LPAR, restore it to a temporary library
on the target LPAR and use your WTUPDENV to apply the configuration
from the temporary library to the target library.

I suppose you could get fancier....but I don't see that that would add
any value.

Charles

On Thu, Jun 9, 2011 at 4:57 PM, James Lampert<jamesl@xxxxxxxxxxxxxxxxx> wrote:

Charles Wilt wrote:

James I'm not sure I understand your questions...bit to generic...can
you provide an example?

Ok.

The application is our Wintouch CRM system. In that system, we have PFs
for Accounts, Contacts, Account/Contact Relations, Scheduled and
Completed Activities, and up to 55 different "Extended Profiles," which
can be tied to Account, Contact, Account/Contact Relation, or any
lower-numbered Extended Profile, or left "floating" with no parent.

There are other PFs as well, but the ones I mentioned can all have
User-Defined Fields.

And we can have multiple environment libraries.

We have a utility for altering the user-defined field configuration of
an environment, and rebuilding that environment, with the data intact.

We also have a utility for applying one environment's configuration to
another environment (e.g., you could try out a new configuration in a
test environment, then, when satisfied, apply it to the live one.)

But this WTUPDENV utility (some of you might remember a thread from a
year or two ago, when I solicited opinions on parameter order for this:
source-first, or target-first; I ended up settling on target-first) only
works within an LPAR. There have been some rumblings about being able to
do this across LPAR boundaries.

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