On 02-Sep-2016 15:22 -0600, Jerry Draper wrote:
Our end of month routine does a full system backup followed by an IPL
of the system.
Yesterday the system did NOT come up because of an A6005008 error -
no console available message.
Turns out the mode was switched to manual from normal.
Is there any way to track what profile might have done that?
We know that it was in normal mode on 7/31/16 and we know that it
was in manual mode on 8/31/16.
In our case extremely unlikely anyone who could have done it
manually at the machine. I'm not sure anyone even knows how to
release the panel from the front of the machine.
Thus the only access to the mode setting would be through Ops
Console.
The only person who was in Ops Console recently confirms that he
didn't do it (when applying PTFs recently). Also, he wouldn't have
necessarily noticed if it was set to manual or normal mode because
during PTF load/apply Ops Console is up and running so there
wouldn't be an A6005008 and the system would go ahead and IPL with
the DSP01 available.
FWiW: There is a T-ST (Service Tools Action) Audit Journal entry
logged with a secondary entry-type of OP for OpsCons; not sure which
QAUDLVL setting effects that logging, nor the full meaning of its being
logged.
[
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzarl/rzarlf60.htm]
Lastly there was an AC power event and we are wondering if
something related to that event could have set the mode to manual.
If so, that would seem to be a problem, given manual-mode is
considered a security risk.?
Otherwise any ideas? Anybody have experience with this?
See the Change IPL Attributes (CHGIPLA) command, notably for the
Keylock Position (KEYLCKPOS) parameter specification:
[
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/cl/chgipla.htm]
While the CHGIPLA for the Key Lock Position (KEYLCKPOS) specification
does not include any capability for establishing a *MANUAL IPL [as was
seen for this topic] per security reasons [as alluded in the above doc
link], seems the "end of month routine" could be changed to ensure the
proper setting is establish with the CHGIPLA command per specification
of KEYLCKPOS(*NORMAL), before issuing the Power Down System (PWRDWNSYS)
command with the RESTART(*YES *IPLA).?
May be worth checking for any audit entries whilst full auditing is
in effect, to see if anything appears that correlates to a change
between Manual&Normal via either the OpsConsole or a CHGIPLA command
request.?
FWiW: There is the Retrieve IPL Attributes (QWCRIPLA) API that
"returns the settings of attributes that are used during the IPL. This
API provides support similar to the Display IPL Attributes (DSPIPLA)
command."
[
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/apis/qwcripla.htm]
While somewhat silly I suppose, as there is no way ever to see
*MANUAL, there could be some value in periodic retrieval and storing of
the setting(s) if the some specific auditing is not going to serve that
purpose -- to see what an upcoming IPL would be expected to effect.?
Hmm.. just did a web search and found a discussion "Detecting change
to Manual mode" 05-Dec-2003
[
https://groups.google.com/d/msg/comp.sys.ibm.as400.misc/V_9wwnkpEMo/2-nA_lij9OUJ]
that was just as unimpressed with knowing\obtaining that DSPIPLA
information, but there is allusion to an ILE RPG [though incorrectly
inferred to be written as an MI] program by Carsten Flensburg that might
provide the actual key position?
So looking for the reference made there, I came up with the following
topic "Key position API" 05-Nov-2003
[
https://groups.google.com/d/msg/comp.sys.ibm.as400.misc/9VNDQURwxJw/HboSodMyWpsJ]
in which a suggestion is that the current position can be determined
with a prototyped procedure call for one of the Material Machine
Attributes (_MATMATR1) features "using option x'0168'"; no program
source is given. See also:
[
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzatk/MATMATR.htm]
Additionally, the web search
[
https://www.google.com/search?q=MATMATR1] yielded the following article
that does offer some source, but for performing with different options
and thus different return information than the option=0x0168 to effect
the "Panel status request" for which the various "Key Mode" values would
be returned.
And while that also would not be directly helpful in answering the
"Subject" question, at least this [as contrasted with DSPIPLA info]
could narrow down when a change to the key-position took place, if
called periodically to retrieve\store that information.
midrange.com
