On 10-Sep-2015 13:12 -0600, John McKee wrote:
From QSYSOPR yesterday:
CPA4088 Load next tape volume on device TAP35. (C G)
09/09/15 09:40:14
I waited for tape to be ready at load point before responding G.
Then, received this:
CPI5922 Device description TAP35 is not usable at this time.
09/09/15 09:40:14
No messages between those two.
As expected, for the failing scenario; though I would [at least if I
were (still) an OS developer], prefer a msg CPF8105 T/QHST, but maybe
that does occur as I expect, but only transpires on a damage-set vs a
damage-encountered.?
I do not know how I came up with the full damage bit. Definitely not
there. May have been misleading second level text.
Not so easy for the layperson to decipher the errors mostly
intended-for\directed-to the OS developers [even if the developers
should be aware and account-for that the messaging will necessarily be
viewed by others]; had the /partial damage/ recovery been [more
appropriately] listed *first* instead of *second*, that probably would
be useful, because the partial-damage approaches normal\expected [by
design] to be encountered as contrasted with the full-damage for which
should be very rare.
The second level text for CPI5922 has this for Technical
description: A machine interface instruction has failed to complete
causing device description TAP35 to become partially damaged. The
vertical licensed internal code log entry identifier is 01011C08.
If I am looking in the right place within SST, I see an entry with
that identifier. Major/minor code is 0300 / 0210.
That is the correct place. On the left should be the identifier
01011C08. The VLIC Log (VLOG) with that major\minor has the "symptom"
of VL03000210.
I do recall that the "10" of the minor code identifies the Object
Type [a Device Tape has an object-type x10, though I do not recall the
subtype], the "0300" is the DAMAGE SET major code. What I do *not*
recall, is the exact meaning of the "02" prefix to the minor code. I
think there is a separate "DAMAGE ENCOUNTERED" major-code to identify
prior damage, though perhaps the "02" designates that... or is that the
"partial" indication, or is partial\full the suffix of the major code???
Ugh! Bummer. I do not recall. FWiW, in the message
[
http://archive.midrange.com/midrange-l/201311/msg00706.html], I
probably was being generic in descriptions, and likely I did not recall
then either, the proper designations.
On the right side of the dump, I see IODRIVERTAPE and two lines down
TAP35. Nothing more means anything to me.
The eye-catcher data probably is not of too much interest, except in
trying to track-down possibly similar issues.
From the screen "Select Entries from Licensed Internal Code Log", the
entry id has Major Description "Damage set".
Hmm. That seems to contradict what I inferred from the joblog; i.e.
the joblog seems to imply Damage-Encountered [despite #cfdamst being the
notifier, conspicuously "st" standing for "set" and "dam" for "damage"
as part of the "cf" for "Common Function"]. I was just figuring the
#cfdamst was just generic, used for both damage-encountered and
damage-set; and probably is.
Prior to that entry is Source/Sink at 09:40:10,
These [unnamed major\minor] are what generally precede a "help me, I
have fallen, and I can't get up!" messaging; identifying details about
whatever condition transpired, such that the later vlogs\messaging will
be manifest to the user as "Oh crap, something bad happened" followed by
"Prior crap happening dictates we protect the drive from further use by
/damaging/ the device to indicate a condition of /logical damage/."
two more entries at 09:40:14 and a Tape support message with
IoDriverTape Object. Then, the damage set entry.
And the Tape Support entries clarify that the prior source\sink
entries were for Tape vs some other I\O device\communication.
I think I can print the entries and get them to
Google Docs, if they would be of any help.
Just have to move through a few hoops.
Those from the recent failure might help me to infer something else
on which to search for an issue that was corrected and\or prevented by
PTF(s). A full summary of the VLogs [list of entries only, no data]
allows seeing the /patterns/ that I have noted over several prior replies.
midrange.com
