RE: RCLSTG on IPL? -- MIDRANGE-L

Chuck,

I had an issue some damaged objects with 3rd party software, ran rclstg, still had some issues.
Opened a PMR with IBM, they preferred customers no longer use rclstg.

Do you have any info on this?

Thanks
Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, November 22, 2013 6:45 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RCLSTG on IPL?

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.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.