|
Evan,
I've used STRASPBAL in the past to migrate data and load source.
But after reviewing, it will only work with units in the same ASP, cannot
be used to move data and/or load source from ASP1 to ASP2.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Evan Harris
Sent: Sunday, June 26, 2016 9:11 PM
To: Midrange Systems Technical Discussion
Subject: Re: Improve R&D LPAR poor disk performance (10K spiiny) MOVOBJ
and moving system libraries to another ASP
Hi Paul
It's not obvious to me what you are asking. It depends on what is on the
system and how it is set up, but STRASPBAL and a load source migration
would be one way.
If you are talking about the system you are currently building with ASP#2
served by storage spaces then I think it would be a little bit more
difficult.
On Mon, Jun 27, 2016 at 12:40 PM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>
wrote:
Evan,around.
If I want to virtualize OS and LPP, how would I do that?
Would take a system restore, correct?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Evan Harris
Sent: Sunday, June 26, 2016 8:37 PM
To: Midrange Systems Technical Discussion
Subject: Re: Improve R&D LPAR poor disk performance (10K spiiny)
MOVOBJ and moving system libraries to another ASP
Hi Paul
I was just asking as it was not clear to me how much was actually left
in ASP#1. Clearly quite a lot.
On Mon, Jun 27, 2016 at 12:24 PM, Steinmetz, Paul
<PSteinmetz@xxxxxxxxxx>
wrote:
Evan,
ASP1 has OS, all LPP, several other 3rd party products, and 6
various copies of production, totally 8tb, on 10k spinny.
If had 8tb of free SSD, I would.
But, I have to pick and choose.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf
Of Evan Harris
Sent: Sunday, June 26, 2016 8:06 PM
To: Midrange Systems Technical Discussion
Subject: Re: Improve R&D LPAR poor disk performance (10K spiiny)
MOVOBJ and moving system libraries to another ASP
Hi Paul
What are you actually leaving in ASP#1 ?
Have you considered just virtualising the entire system and being
done with it ?
if you only have the OS left in ASP#1 it may not be that much in
terms of additional storage but may save you quite a bit of messing
parameter.needed in the future.
On Mon, Jun 27, 2016 at 11:02 AM, Steinmetz, Paul
<PSteinmetz@xxxxxxxxxx>
wrote:
I've completed this process for about 30 libraries.
All is working, will have perf numbers to share in a few days.
I have several remaining libraries, all in QSYSLIBL.
I think the only way to move these is to
1) Remove lib from QSYSLIBL
2) IPL
3) Delete/rename lib
4) RSTLIBBRM lib to ASP2.
Repeat process for other libraries
5) Add lib back to QSYSLIBL
6) IPL
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On
Behalf Of Steinmetz, Paul
Sent: Sunday, June 26, 2016 6:47 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny)
MOVOBJ and moving system libraries to another ASP
After further reading on STRASPBAL, this can only be used to move
data within an ASP, not from ASP1 to ASP2.
Scratch plan B, STRASPBAL.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On
Behalf Of Steinmetz, Paul
Sent: Friday, June 24, 2016 4:09 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: Improve R&D LPAR poor disk performance (10K spiiny)
MOVOBJ and moving system libraries to another ASP
Chuck,
If I can't move a library from ASP 1 to ASP 2, because of
restrictions, I came up with plan B.
1) Save all my user data.
2) Delete all my user data.
R&D LPAR will only have LIC, OS, and LPP and this point.
3) STRASPBAL TYPE(*ENDALC) UNIT (all the 10k spiny)
4) STRASPBAL TYPE(*MOVDTA) TIMLMT(*NOMAX) PRIORITY(*MEDIUM)
5) Restore all user data to desired ASP.
PLAN C may be another possibility, but I think I need to be on
V7R2 for this.
Backup, Recovery, and Media Services (BRMS) modernizes its storage
tiering support to now include IFS, IASP, and tiering within an ASP.
The migration was originally required to be between ASPs, but now
policies can be set up to enable migration of database files
between faster and slower disks in the same ASP. Unlike typical
Easy Tier(r) functions that move small pieces of data to and from
faster storage based on patterns of usage, the BRMS storage
tiering function operates at a file or library level to help
optimize the value of using SSDs. A system administrator can
choose to keep on SSD a file or library that may currently have a
lot of low latency pieces of data, because of knowledge that the
whole file or library will be
agree:This aspect can be useful for month-end or quarter-end processing.ASP(1)].
The BRMS migration function integrates well with existing BRMS
policies that allow low-use files and libraries on slower disk to
eventually be automatically archived
to tape.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On
Behalf Of CRPence
Sent: Friday, June 24, 2016 2:31 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Improve R&D LPAR poor disk performance (10K spiiny)
MOVOBJ and moving system libraries to another ASP
On 24-Jun-2016 08:51 -0500, Steinmetz, Paul wrote:
On Friday, June 24, 2016 9:25 AM Rob Berendt wrote:
On 24-Jun-2016 07:38 -0500, Steinmetz, Paul wrote:
Is there a command or tool to move a library from ASP1 (10kRSTLIB ... RSTASP(2)
spinny) to ASP2 (Virtual SSD)?
immediately comes to mind.
I'd also like to move some system libraries, SYS, QSYS, QSYS2,
QUSRSYS and QGPL. But I know I can't restore these.
Not sure what library SYS is; perhaps meaning to imply, all of
the quasi-system libraries with naming SYS*, e.g. SYSIBM?
AFaIK the system still has a restriction [though not explicitly
enforced] requiring that those [non-LPP] system libraries [and
most|all quasi-system libraries] must reside on the
most|primary\*SYSBAS;
i.e. must reside on Basic User ASP(1), both to ensure proper
function and to be considered a /supported/ environment. Note:
Each Independent ASP (iASP) [i.e. not the Basic User ASPs of
*SYSBAS] already will have their own copy of [some of those]
libraries with naming that reflects the iASP number, e.g.
QSYS200033 for iASP=33, and *SYSBAS minimally needs those /system/
libraries to reside in *SYSBAS [even if possibly or if even
plausibly, in a Basic User ASP other than
to another. The following quote, from the following link, seems to
MOVOBJ allows you to move most object types from one ASP to
another ASP. *LIB however is excluded.
While the Move Object (MOVOBJ) and the equivalent API (QLIRNMO)
offer ASP-related parameters for designating where to search for
the named libraries [From ASP device (ASPDEV) and To ASP device
(TOASPDEV)], I do not expect the capability exists for that
feature to "move most object types from one ASP to another", at
least from what I recall for Basic User ASPs 1-32. I am not aware
that a request to _move_ an object can\will effect reassignment of
the storage of the object to that of the target Basic User ASP; i.e.
AFaIK the _move_ capability remains essentially, just an address
reassignment, merely giving addressability to the object via a
different library name in the same ASP, and is incapable of
reassigning the actual storage of that object because no LIC
[storage management] method exists to be invoked against an object
to make a change of the storage from one ASP
"You cannot directly move objec
ts between ASPs because the Move Object (MOVOBJ) command and the
Move Document (MOVDOC) command move only the pointer to the object.
They do not physically copy data from one location to another."
IBM i -> IBM i 7.2 -> Systems management -> Backup and recovery ->
Recovering your system -> Working with auxiliary storage pools ->
Transferring objects between ASPs [
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzarm/r
za
rm
mvasp.htm
]
_Transferring objects between auxiliary storage pools_ "You can
move entire libraries or folders from one auxiliary storage pools
(ASPs) to another. Special procedures are used to move a library
that contains journals because a journal and the journaled objects
must be in the same basic user ASP or the same independent ASP group.
The Working with nonlibrary user auxiliary storage pools topic
discusses the procedures for working with nonlibrary user ASPs.
You cannot directly move objects between ASPs because the Move
Object
(MOVOBJ) command and the Move Document (MOVDOC) command move only
the pointer to the object. They do not physically copy data from
one location to another. In general, follow these steps to move an
object to a different
ASP:
* Sign as QSECOFR.
* Save the object and its private authorities by specifying
the
PVTAUT(*YES) parameter.
* Delete the object from the system. If you are transferring
the object from one independent ASP to another independent ASP,
this step is not required.
* Restore the object to the target ASP by using the RSTASP
parameter on the RSTxxx command. If you are restoring objects to
an independent ASP, use the RSTASPDEV parameter. If you need to
restore the private authorities of the object, use the PVTAUT(*YES)
instruction:ASP. ..."..."
[
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzarm/r
za
rm
tejua.htm
]
Transferring journals and objects to a different auxiliary storage
pool "If you use a library user auxiliary storage pool (ASP), both
the objects you are journaling and the journal must be in the same
Independent ASPs; i.e.
Yet, I find that the MOVOBJ command help does show an example
seeming to imply the ability to move an object from one iASP to
another iASP, despite failing to explicitly note they are both
the following, which I had no knowledge was supported, nor how
that is possible with just the Modify Address (MODADR) MI
another ASP.
Example 3: Moving an Object from a Library in an Independent
Auxiliary Storage Pool (ASP) to a Library in a different ASP.
MOVOBJ OBJ(INVENTORY/MONTHLY) OBJTYPE(*PGM)
TOLIB(WINVENTORY) ASPDEV(SALES) TOASPDEV(WSALES)
Hmmm, OK; perhaps a _move_ is not always a literal /move/, and
instead is a /copy/, effected by save\restore. In contradiction
to the implication in the above doc, the Move Object (MOVOBJ)
command [though the API docs for that effect seem more sparse]
apparently actually effects a SAVOBJ\RSTOBJ to /mimic/ a move, so
as to enable spanning ASPs by making a /copy/ of the storage into
CPF327C].But done so, with some stated caveats [much the same as those for
the Move Library to ASP
(QHSMMOVL) API], whereby the effects for spanning an ASP [and
seems not to be limited to iASPs only] contradicts an expectation
of the typical _move_ request, because the actual implementation
is via the save\restore [and just like the Move Library to ASP
(QHSMMOVL) API, operating without the QDTA(*DTAQ), but with
PVTAUT(*YES)]. Still, that does not magically resolve the
restrictions such as journaled objects no longer being journaled
and database file dependencies that can not span ASPs [per msg
http://archive.midrange.com/midrange-l.http://archive.midrange.com/midrange-l.http://archive.midrange.com/midrange-l.
--
Regards, Chuck
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
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
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
Regards
Evan Harris
--
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
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
Regards
Evan Harris
--
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
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
Regards
Evan Harris
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
