Re: Start of IPL timestamp

a few weeks ago, I was "cleaning up" my DR system, which was initially a
direct clone of our production system...
I stumbled across a file, and I think it was a data base file, that
had dates and times OF EVERY IPL OUR COMPANY EVER MADE... back to 1991
when the first B50 was installed at the company...

I can't remember where I found it, and what it was called!!!!!!





On 7/16/2014 3:41 PM, CRPence wrote:

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>>