On 22-Nov-2013 13:37 -0800, Steinmetz, Paul wrote:
QSYS/RTVDSKINF will touch every object,
The Retrieve Disk Information (RTVDSKINF) is /implemented/ using the
/reclaim/ instruction, the same instruction used by the Reclaim Storage
(RCLSTG) to list every address in the /permanent storage directory/ but
only the latter has a _documented effect_ of /damage notification/ for
damaged objects. But Yes, in effect, that feature also will /touch/
every _permanent_ object.
However... The VLog notification is *not* assured for each /touch/ of
a damaged object. AFaIK mostly only for the first /touch/ *since* an
IPL started, would the [damage encountered] VLog be issued [again],
because the Licensed Internal Code (LIC) /object checker/ would perform
more validation on the object [due to the LIC header mismatching the IPL
number]. After that, the object may simply be notified as damaged by an
inquiry from a processor [e.g. MATSOBJ] or a returned status in a list
[e.g. QUSLOBJ], with _no logging_ effected. That is because potentially
repeatedly notifying of the same condition ad-nauseum is considered
inappropriate.... as doing so could cause the LIC log to wrap
prematurely due to the number of entries or possibly due to the storage
available for entries depending on logging size\characteristics.
Thus the RTVDSKINF request issued during\after an IPL, much like
inquired of reclaim in the subject and alluded in the OP, *could*
possibly suffice; i.e. per a new IPL number. But as I had noted in my
earlier reply, the support for RCLSTG during an IPL may not exist or may
be partial [having been retracted as a supported function, at least for
the *DBXREF-only, or the run-at-IPL feature perhaps was removed
entirely, I do not know]. To use the BCHTIMLMT of the ENDSBS *after* an
IPL, with the scenario described in the OP, may be a bit more
complicated than just doing the restricted-state batch reclaim.
Via SST, 5. Licensed Internal Code log
The Start Watch (STRWCH) should be capable of looking for any vlog
[LIC log entry] with the major code 03xx. That "03" prefix designates
both of the "Damage Encountered" and "Damage Set" conditions. I know of
two possible suffixes, "01" and "02", but there may be others; the
"Watch for LIC log entry (WCHLICLOG)" parameter I infer could specify:
WCHLICLOG(('0301' *ALL *NONE *N) ('0302' *ALL *NONE *N)) to watch for
damage. The "Damage Encountered" indicates that some processing of an
object /sees/ existing damage to that object; i.e. a prior "Damage Set"
was already done for that object. When the actions of some type of
processing against the object /detect/ the damage for the first time,
for which a MCH16## [e.g. mch1604 or mch1668] error is issued [from
#cfdamst], there will be a "Damage Set" condition. Again, if RTVDSKINF
should be the source of these per its /touch/ of the objects, then
likely only valid during\after an IPL.
any damaged objects can be seen in by looking for 0301 010B
Not "any damaged objects", just *QDDS [DataSpace] objects. But even
for that object type, that VLog identifier still may be too specific.
That VLog is specific to /Dataspace damage/ and presumably is
/partial damage/ given it is the space for the /data/ and the "01" in
either the major code or the minor code differentiates full vs partial,
and the other [IIRC] differentiates a /damage encountered/ versus a
/damage set/ log. Thus searching only for vl0301010B is only looking
for a specific kind of damage with a specific incident of damage against
a specific object type; very narrow. Reviewing the Display History Log
(DSPLOG QHST) for the CPF81## and CPF82## range of messages after the
damage-notification portion of the Reclaim Storage request may be a
better choice.
01008969 Damage encountered 0301 010B 10/25/13 02:50:09 0
5=Display entry
F10=Right
You can see object name and member
QAEZDISK QCURRENT
Display Licensed Internal Code Log Entry
Log entry ID . . . . . . : 0100896E Page/Line. . . 1 / 1
Major/minor code . . . . : 0301 / 010B Columns. . . : 55 - 132
Find . . . . . . . . . . .
+....6....+....7....+....8....+....9....+....0....+....1....+....2....+....3..
11/22/13 16:33:13 PAGE 1
) 010B NOTE SIZE 0064 DUMP SIZE 000000 TIME STAMP 10/25/13 20:08:15
000000 0000000000000000 0000000000000000 *.½.£É...........................*
000000 00000BB8F0F461F1 F861F1F240F1F87A *...................½04/18/12 18:*
404040 4040404040404040 4040404040404040 *04 #CFOCHKR *
404040 4040404040404040 4040404040404040 * *
D24040 D8C3E4D9D9C5D5E3 4040404040404040 * .°QAEZDISK QCURRENT *
000000 0000000000000000 0000000000000000 * ............................*
000000 0000000000000000 0000000000000000 *................................*
0 TO +02E0 SAME AS ABOVE
Assuming that is for the file QAEZDISK in QUSRSYS, then that logged
condition indicates the effect of RTVDSKINF is either somewhat
unpredictable for its ability to complete writing to the member [but
with an opportunity to perform data recovery], or the request will fail
to write anything to the member. If that file.mbr, then the only valid
recovery for the recorded condition is to either RMVM QUSRSYS/QAEZDISK
MBR(QCURRENT) or DLTF QUSRSYS/QAEZDISK, to destroy [aka delete] the
damaged object.
Rather than the Common Functions Damage Set[ter] (CFDamSt) diagnosing
the first encounter of damage with that Dataspace object, that VLog
indicates the Common Function Object Checker (CFOChkr) encountered a
prior\already-diagnosed damage condition.
FWiW: The DSPOBJD would, in most cases, be able to have identified
that with is ODOBDM flag, but which member(s) are affected remains to be
diagnosed; with a quick peek, neither DSPFD, TYPE(*MBR) nor
TYPE(*MBRLIST) seem to have a /damage/ flag. Only objects that are not
in a library but which should be, or are in another job's QTEMP library,
would be unable to be detected with DSPOBJD, for the condition of
/prior/ damage for which /Damage Set/ was already done. But
conveniently, another feature of RCLSTG is the /Context Recovery/ phase
which means that any permanent objects that are not in a library [but
their object types seems they must be,] will be placed in a QRCL
library... so if beyond just being out-of-context the object is also
damaged, then the DLTxxx can be issued against that object in the
QRCL#### library.
midrange.com
