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 (10k
spinny) to ASP2 (Virtual SSD)?
RSTLIB ... RSTASP(2)
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 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 ASP(1)].
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 to another. The following
quote, from the following link, seems to agree: "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."
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/rzarmmvasp.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) parameter.
…"
[
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzarm/rzarmtejua.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 ASP. …"
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 Independent ASPs; i.e.
the following, which I had no knowledge was supported, nor how that is
possible with just the Modify Address (MODADR) MI instruction:
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 another ASP. 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 CPF327C].
midrange.com
