Re: RAID, journaling, and ASPs, oh my!

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

  In the referenced doc, the steps for such a recovery are the first 
listed in "Choosing the procedure to recover user ASPs"; i.e. in the 
task list, under the heading "Recovering a basic user auxiliary storage 
pool (ASP) after recovering the system ASP".  Such a setup is not a snap 
to recover from the loss of ASP1, but if limited almost exclusively to 
journals and receivers, DR for that loss within that setup enables a RPO 
[Recovery Point Objective] up to the last transaction without too many 
hassles.

  What was on ASPn is already there when recovering the system ASP 
after the loss of ASP1.  The data _remained_ on disks that make up each 
ASPn, because each ASPn was [in a sense] unaffected for the _existence_ 
of its objects.  It was the System ASP that was lost, so it was the ASP1 
that was then configured and its disks initialized as part of a 
re-install.  Later restores will be done into ASP1 to effect its 
recovery -- by restoring only what is new.  A RCLSTG SELECT(*ALL) 
OMIT(*DBXREF) needs to run before the restores, to get the 
_addressability_ to the objects [for example, the journals and 
receivers] that are in each ASPn, but which are not yet visible after 
only the install.  The /visibility/ will be obtained to the existing 
objects in ASPn by that reclaim request, before an effective restore 
OPTION(*NEW) is performed.  Restoring only new objects avoids replacing 
or conflicting with those existing objects on the disks making up ASPn. 
 However to avoid a large number of diagnostics logged for 
OPTION(*NEW), using OMITLIB(list_of_libs_in_ASPn) is the documented 
manner to effect restore of only the new objects; where that 
list_of_libs is available by DSPOBJD *ALL TYPE(*LIB), minus those 
libraries created in ASP1 by the install of the LIC and OS.

  [The restored] ASP1 does not remember the configuration of the ASPn 
as neither part of the OS nor user data.  That setup was established and 
was maintained across the loss & DR activity at a disk configuration 
level; DST was used to configure the ASPs.  The LIC can establish the 
visibility to the /objects/ on the disks because the reclaim storage 
request progresses though all of the permanent objects on disk to make 
them visible and assign /default/ ownership.  Each object in a library 
residing in ASPn still has addressability to its library, but each *LIB 
that is found in ASPn is inserted into the QSYS *LIB so that the library 
is visible in QSYS; its objects are then immediately addressable through 
that newly visible *LIB.  The *LIB objects were in ASPn but were not 
/in/ their *LIB because their library was in ASP1; i.e. where QSYS 
resided, the library in which all [other] *LIB objects reside.  Although 
I say /other/ *LIB, the QSYS *LIB is actually referred to as the 
/machine context/ to avoid the implication that a *LIB is in a *LIB.

  It is the ownership that makes the scenario less palatable, because 
ownership should be reestablished for each existing object which was 
made addressable\visible by name.  For library based objects, it is not 
too difficult to resolve if the rule is to reflect the ownership of the 
library in the objects within; then tools like CHGOWNLIB LIB() which 
effect that automatically can ease recovery.  And I see the doc fails to 
note CUROWNAUT(*REVOKE), even as the default, it should be very clear, 
that parm(specification) is an effective requirement.

Regards, Chuck