On 14-Jul-2014 14:06 -0500, Steinmetz, Paul wrote:
John McKee on Monday, July 14, 2014 2:37 PM wrote:
On Mon, Jul 14, 2014 at 12:19 PM, Monnier, Gary wrote:
When was the system last IPL'd?
<<SNIP>> I am drawing a blank on where the last IPL date and time
is stored. <<SNIP>>
Check your QCTL start date and time is one quick way.
This reply is informational only, generally; that the reply is
composed contextually, in response to Paul's message, is merely
convenient for adding to the topic as it arose within the thread. Some
who are interested in the sub-topic, or even still the original Subject
topic [journal receivers], may find something of interest. The subject
is changed to reflect the followup more directly to the sub-topic.
The start date\time of the QCTLSBSD [which may not be QCTL] probably
is going to be limited in accuracy, with regard to "last IPL", because
although the subsystem will not completely END [merely pend in an ENDing
status due to ENDSYS], the request to Start Subsystem (STRSBS) of the
controlling subsystem after Restricted State likely results in the
subsystem monitor job having a new Job Started timestamp? However,
perhaps the Job Entered System date\time value would be accurate?; then
the only possible issue remaining is the ability to know for sure what
was the QCTLSBSD that was in effect for this IPL, i.e. what *is* the
controlling subsystem, because although the controlling subsystem could
not have changed in the current IPL, the system value certainly may have
been changed.
Although this question is asked periodically and a plethora of
/answers/ ensues in most cases. And recalling those answers as often
offering only _potentially accurate_ results, I am surprised I could not
recall the definitive means to obtain that information; sure there was
an MATxxx Machine Interface (MI) instruction or an API that offers the
information, I had to go searching. Note: For that, see MATMATR later
in this reply.
I presume the start of the 000000/QSYS/SCPF job is most definitive
[and already suggested by others in this thread]. However I recall that
since some level of enhancement to the robustness of the OS system-job
recovery that might call into question that source of the information; I
suppose that information could in rare instances be suspect if the SCPF
job is one of the system jobs that can be recovered\restarted? Perhaps
the SCPF job may persist as [the] one job for which that enhanced
ability to recover from an ended system job does not exist; there is,
IIRC, a System Reference Code (SRC) that says in effect "the SCPF job
ended". Though if some of the work [e.g. history logging] were not
moved from the SCPF job into some other system job, then the inability
to recover the SCPF job would be quite unfortunate; i.e. seemingly
lacking in robustness for something as mundane as history logging, such
that if that history logging resulted in the job crashing, then also
effected the system crashing... yuck.
Numerous other means to retrieve the "when last IPLed" information
are highly dependent on the datum not having been deleted from some
log[ging facility being queried]. The History (QHST) will have logged a
msg CPI0C04 but the history log file in QSYS that contained that record
might since have been deleted, journals [such as the QAUDJRN audit
journal] should have logged a J-IA or J-IN but a new receiver since
attached and the old receiver containing the entry since been deleted,
some new objects specific to the current IPL should have been created in
library QRECOVERY but possibly such object(s) could have since been
deleted and re-created due to some automatic corrective\recovery action,
and the major\minor codes of VLIC logs [VLogs; ¿major code 500?] that
identify an IPL could have since wrapped [i.e. implicitly deleted] or
since been explicitly deleted via DST or STRSST. Per VLog
identifiers\headers are likely to persist much longer than the actual
log data [i.e. wrapping has less impact on the entry identifiers than
the actual data], those might be quite persistent.
I could not recall any Materialize instruction or Retrieve API that
would return the specific datum or the necessary information to
calculate the value of "last IPLed", so I went looking. I still can not
find an API that returns either of the "timestamp of the last\current
IPL" or an "accumulated\cumulative clock time since the last IPL
(completed or started)" whilst searching the docs. In review of some
initial information, I was unsure if the values of "CPU time since IPL"
and "Shared processor pool idle time since IPL" could be used to
calculate an IPL timestamp; that data is from Materialize Machine
Information (MATMIF). With more searching, eventually...
I did find a "Start of IPL timestamp (local time)" in the Materialize
Machine Attributes (MATMATR). While there may be some some API that
returns that same date\time information [using that instruction; thus
allowing a user to avoid the release-dependent implementation caveat for
use of that MI instruction], I could not find one [among the Work
Management APIs].
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzatk/MATMATR.htm>
I suppose in a thread with subject "Journal Receiver", a response to
the inquiry effectively asking "When was the last IPL?" might
appropriately involve the lookup of a journal entry :-) I did already
make a passing reference, but offer additionally: An entry with the
Code=J and the Type equal to either IN or IA would log the timestamp of
the IPL, and could be retrieved from a journal known to be persistent
and active on the system; a journal for which the receiver management
will assuredly not have purged the receiver [in the chain] that would
store the logged entry of either:
J-IA - System IPL after abnormal system end
J-IN - System IPL after normal system end
<<SNIP inquiry about "system created on" answered in another reply>>
midrange.com
