MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » July 2014

Start of IPL timestamp (was: Journal receivers)



fixed

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






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact