On 21-Oct-2015 18:00 -0500, Vinay Gavankar wrote:
What does the 'Physical File Open accesses' displayed in the DSPFD
command indicate?
Does it really show the number of times this file was opened?
Shown as part of Data Space Activity Statistics, presumably the "open
accesses" count is literally the number of Activate Cursor (¿ACTCR?) MI
instructions issued against the LIC Cursor defined with any reference to
that data[space], and the "close accesses" count is literally the number
of Deactivate Cursor (¿DEACTCR?) MI instructions against a LIC Cursor
defined with a reference to that data[space]. A LIC cursor is the
implementation object for an Open Data Path (ODP) that is defined over
the run-time member that is defined over one or more dataspace(s).
OK, perhaps not very informative for the layperson. But effectively,
any time an ODP is created [and perhaps also when one is reused], the
/open/ count would increment. Any time an ODP is closed, then the LIC
cursor gets destroyed when the deactivate-cursor method is called, and
thus the /close/ count would increment for each referenced dataspace.
I am seeing pretty high numbers in one file (40000/min) but no one
has complained of degradation in performance of that file, and I
can't really believe that file is opened that frequently.
Can be shocking sometimes, how much /work/ gets done sometimes,
without anyone noticing just how much is actually being done to get
/something done/ :-) Very possibly, the counts are an accurate
representation of the total work being done, but may not reflect the
complexity nor cost of that work; i.e. some opens may be significantly
less costly than others, thus having little impact compared to other
[more expensive] opens.
The code is supposed to be extremely fine tuned with no program in
the call stack opening/closing files.
The statistic would be agnostic for job; i.e. every /open/ would be
counted, irrespective the job. And any job retrieving the statistics
would see the count reflecting activity from across the system, not just
of any one job or application. A popular file may be accessed by more
than the primary application that one associates with that file; e.g.
the primary application may maintain the data in the file, but there may
be many different applications and jobs reading or otherwise querying
the file.
And FWiW, much code that is described as /fine tuned/ with regard to
file-open, are coded to avoid full-open for efficiency. Thus while the
application may be known for not doing full-open, that application may
specifically be designed to use shared opens or SQL
pseudo-closed-cursors; thus huge savings in many ways [CPU,
temp-storage, temp-addresses, memory\disk, faulting].
The ODP in batch jobs I have checked is constant.
Not sure what is meant by that; if for example that implies a review
of the open files, via for example the Work With Job (WRKJOB) for Opened
Files option OPTION(*OPNF), that would not really be telling. But a
Trace of the job, that might be telling. That or a break-point in the
[shared] open code path(s); though unfortunately because the DB Open is
no longer OPM, and that the ILE gives no capability to effect the
equivalent of the effect from ADDBKP STMT('/1') on OPM, debug is no
longer very capable. I am not sure about whether the QDBSOPEN [for
shared open] is still OPM however, and if the Common Data Management
Open (QDMCOPEN) is, or if even the cursor-reuse would actually flow that
path, and I do not recall the SQL program name but that is surely ILE.
So again, probably only trace would help to see if real or faux opens
were really happening.
Note: A quick test in v5r3 seems to suggest shared-open, those that
merely increment the shared-count, seems not to effect an increment to
the /open accesses/ statistic.
Also, for that file 'Physical File Close accesses' is HIGHER than
Open accesses.
If pseudo-closed cursors [ODPs that are left open for reuse] never
effect the deactivate, which they would not given that is the whole
point of pseudo-close vs full-close, then the close count could
conceivably be very low as compared to the open count, *if* the reuse is
implemented via the activate-method. A possibly similar effect could be
from /shared open/ of an ODP.?
Hmmm... Then after writing all of that, I recall a recent discussion
mentioning use of multiple-dataspace Logical File Member (LFM) with a
keyed access path. That of course means that every DataSpace (DS) will
get that increment each time the LFM is opened. I do not recall there
being a cumulative count [e.g. as manifest in the presentation of the
LFM; I think not, because the DataSpae statistics as I recall, are
available only from displaying the Physical File Member (PFM)], but if
there were, that could skew [much more rapidly upward] the number being
seen; i.e. an aggregate of the open of a LFM built over 20 dataspaces
would increment by 20 vs by 1.
midrange.com
