Re: Hands off monthly SAVSYS

On 22-Aug-2014 09:26 -0500, Steinmetz, Paul wrote:

CRPence on Friday, August 22, 2014 10:04 AM wrote:

On 22-Aug-2014 07:17 -0500, Mike Cunningham wrote:

Does anyone have a script or tool that would do a monthly SAVSYS
process without the need for an operator? End all subsystems to
a restricted state, do the SAVSYS, initiate an IPL to bring the
system back up,

<<SNIP>> I make a comment about Save System (SAVSYS) being a
combination of Save Security Data (SAVSECDTA) and Save
Configuration (SAVCFG), each of which do not require restricted
state, and then a doc reference to the feature that allows the
restricted-state work to be performed:
<http://archive.midrange.com/midrange-l/201211/msg00328.html>
Subject: Go Save 21 question
<<SNIP>>

Re: <I make a comment about Save System (SAVSYS) <<SNIP>> >

If you do NOT go to restricted stated, you will not get a clean
SAVSYS. (some LPP objects will be in use, locked)

AFaIK, a typical user would be unable to know the difference; no way they would know if objects locked by LPPs would matter per the help text clearly noting that "subsystems must be inactive before the SAVSYS command can" be issued, and having failed to effect that [restricted-state], the SAVSYS invocation should fail [again, according to the help text,] with the Escape msg CPF3785 "Not all subsystems ended."

Thus, all subsystems are normally ended prior to doing either SAVSYS
or full SYSTEM backup

To be clear, the SAVSYS does not perform any Licensed Program Product (LPP) save activity; what LPP objects are locked, [except if somehow that includes locking a user profile or a configuration object, mostly] should be moot with regard to using the combination of SAVSECDTA and SAVCFG *instead of* the SAVSYS. Likely of the most importance for a SAVSYS [other than having obtained a save of the PTFed level of the LIC and OS] are the User Profiles and their private authorities, which can be saved without restricted-state using the SAVSECDTA.

What I alluded to in my above quoted reply, was actually an option to *not* perform the SAVSYS; whether a "clean SAVSYS" can be obtained is not germane, as no SAVSYS would be performed. In the referenced archived message, I state that one can "remove the requirement for the restricted state; e.g. SAVCFG and SAVSECDTA instead of SAVSYS" but also *with a caveat* of "while understanding recovery implications" of not having obtained instead, an actual SAVSYS [that does require a restricted-state]. Though additionally, I allude to effecting truly restricted-state activity, if performing the SAVSYS is a requirement; a redirection being made to the comments in my past\archived reply, for each option.

If there is some specific issue worth discussing, with regard to one or more object locks effecting a SAVSYS failure [due to msg CPF3772 "SAVSYS completed. One or more objects not saved."], then perhaps a new\separate topic being composed and discussed would be apropos.?