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
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...canOk.
you provide an example?
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
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.
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives