×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 08-Jan-2016 12:05 -0700, Steinmetz, Paul wrote:
We do QSYS/RTVDSKINF on a daily basis, touches every file.
To be clear, not all /first touch/ are created equal. While the
RECLAIM instruction, being the implementation for Retrieve Disk
Information (RTVDSKINF), and the further processing by that retrieve
feature must /materialize/ the size of the objects, that
reduced-function\generic /materialize/ may not have the same effect on
the object as an object-specific /materialize/ would have on the object.
If that retrieve feature does effect the full object validation
[associated with the /first touch/ term used for the Object Checker] for
the data-related pieces of a database *FILE object, then that likely
would be a mere side effect of an additional invocation of the /retrieve
object description/ for the *FILE, for which the cumulative object size
is accumulated by the Database File Size (QDBSIZFI) processing; but only
if the size-file processing had performed more than was required to
reveal only the cumulative size of the composite. IIRC that is not the
case, and that the more thorough materialize requirements of the Display
File Description (DSPFD) for the Type of either Member (MBR) or Member
List (MBRLIST) will _necessarily_ effect a /first touch/ for which the
the full validation effect of the Object Checker is performed; rather
than merely MATSOBJ, the MATDS and MATDSI instructions would be
performed. Otherwise there would exist almost no possibility for the
/first touch/ effects to be avoided for the first save after an IPL,
which I believe was at one time in effect for the LIC database objects,
specifically intended to reduce the negative impact [even if only for
that limited\specific set object of objects, which can be significant in
number].
The aforementioned /first touch/ is generally the domain of the
[generic] /Object Checker/. However for complex object types such as
the LIC database objects, AFaIK the effect is deferred to the LIC
Database feature [much like generic object handling is passed to the
object handler for the complex object types]; i.e. if the LIC Database
deems the first invocations via the Object Checker are not sufficiently
regarded as a /touch/, such that the validation could be delayed, then
that particular touch is not regarded as being the /first touch/, and
can decide because the LIC DB knows that the method is not its own
action for which a /first touch/ would be deemed mandatory. IIRC an
exception to that is when member [or perhaps dataspace or DSI]
conversions are required; i.e. conversions may be forced irrespective of
the /touch/, to ensure accurate reporting then and that any future code
will only ever see [because the new code will understand only] the
new\converted-to structures of the object.
For LIC database objects there is also another /first touch/ distinct
from that of the Object Checker, for which the effects can be seen in
the amount of temporary storage on the system; the /activation/ [aka
Open] of the member\data\access_path will create temporary run-time
objects that will persist until the next PwrDwn. Thus another issue for
post-IPL impact, also involving a /first touch/.
midrange.com
