On 02-Sep-2015 12:48 -0600, John McKee wrote:
I can easily convert the spool files to something in the IFS. Two
questions:
1) The LIC log, at 611 pages, seems a tad large. Maybe I used an
incorrect parameter or included too much by use of wrong parameter
value. Does this need to be corrected?
Seem a reasonable size, but hopefully that size suggests the data
from the selected logs was included, rather than just the summary of all
the entries; i.e. a listing of all LIC Log entries without any data can
be somewhat informative [to see the pattern for each failure and what
might have preceded the first or each occurrence; obviously the
timestamps of the begin\end of each failure would need to be noted
additionally], but the actual list of the thirteen logs [consistent each
time?] *with data* across the time-span of the failure(s) is what is
most desirable. Note: Review the spools for any /sensitive/ data, as
some logs could include some actual data from the save; paging through
the /eye-catcher/ data is generally able to be completed fairly quick.
I can not recall the means to get a summary-with-data over a specific
date\time-range when spooling the LIC log data. I recall mostly, that
there is a 6=print against that can produce a spool-with-data against
each log; of course that is one spooled file per log.
2) Where can I send the files to allow others to see them?
Some people use dropbox; there are a variety of such places. Google
docs should be an option as well, but I am unsure if there is a fully
public access, or if authorization is made only to specific accounts
[mine is my email I post with].
I appreciate your time, as well as explaining >why< multiple SAVs
don't trigger the same condition as GO SAVE >can<.
Allusion as to how possibly, not an explanation of why :-)
If I recall correctly (been well over ten years) applying cum will
almost certainly require an IPL to complete. So, no need to IPL
now >just< to clean up max unprotected.
Applying the cumulative [and HIPers] will indeed require an IPL
[perhaps an additional implicit IPL to which there may be only limited
visibility, most notably, that the system never appears available until
completion of the final IPL].
The job log from this morning indicated a previous damaged condition.
Repairable via IOP reset. Wish I had thought that through and
performed OP reset last week when it happened. The commands are
obviously doing a lot more than is obvious, otherwise, it would seem
like a nice feature to fail at the start rather than after an hour.
Some functions just don't work that way.
I would expect that, given the required repair for the partial damage
is vary-off and vary-on, the save would have failed quite nearly
immediately upon start; I do not recall the GO SAVE opt-21 having any
Vary Configuration requests coded. Additionally, a failure for
reference to the /damaged/ device should have been explicitly about the
reference to the previously-damaged object, not a condition diagnosing
an issue for which the effect was damage; perhaps not a conspicuous
difference to those less familiar, but trust that the difference is huge
and an important distinction.
So, just need a destination for these files. Maybe problem is now
"fixed" merely by me performing a proper reset.
Your call on if, where, and to whom the data is made available. I am
offering to look; not sure if anyone else would, and if not, I could
look at them sent as email attachments [preferably named in a way that
clarifies what each is; which incident and what type of data collection]
There is only a small chance I would be able to infer anything from
the set of VLogs [they are atypical of what I have had to review in the
past]. The recording in this discussion the list-summary [from each
occurrence; or just one, and indication that they were the logs were the
/same/ each time] would at least be valuable in comparison with any
other incidents in which that minimal amount of information was recorded.
midrange.com
