Ask yourself which is easier and faster in a case where one has reason
to suspect a VSAM usage problem:
(1) running LISTCAT, running program, running LISTCAT;
or
(2) running program, waiting until following day when offloaded SMF
records become generally available, running or requesting a run of a
batch program to read through 1M+ SMF records to possibly locate
relevant statistics?
The "simplest" approach is frequently "better".
The fallacy of John's casino analogy is that the underreporting of VSAM
statistics is not caused by unpredictable and unknown actions of
individuals, but by specific understood system events which are mostly
observable (ABEND or cancellation of address spaces) or associated with
the running of specific programs. You may not know exactly what was
lost, but generally can determine when the losses occurred. There are
many useful cases where one can be 100% sure that you have an interval
in which no statistics have been lost, and can therefore accurately
assess the number of additional EXCP's, CI/CA splits, records
fetched/added/deleted, etc. resulting from applications run in that
interval.
As with many statistics related to MVS, one has to understand what they
mean and their limitations in order to use them intelligently. I don't
accept that it makes sense to eliminate LISTCAT VSAM statistics just
because some users don't understand the limitations. Flagging the
statistics as incomplete or questionable ought to be sufficient to warn
neophyte users that there may be something about the values they don't
understand - hopefully prompting them to research and understand the
limitations.
Ron and Jenny Hawkins wrote:
Isn't that why we have an SMF Type 64 record?
The delta in the LISTCAT VSAM statistics correctly reflects the activity
to the VSAM data set between two points in time, as long as you compare
between two points where the VSAM file is closed and also know there
are no intervening OPENs without a valid CLOSE. This is extremely
useful as an activity measurement tool, even if the absolute values are
missing counts from earlier accesses.
...
john gilmore wrote:
> Joel C. Ewing writes:
>> This also suggests that calling the statistics "INVALID" may be too
>> strong a pejorative, as all the counts reflect actual activity to the
>> file - it's just that they do not represent ALL the activity to the
>> file.
>
> and there is a perspective from which his view has merit.
>
> The operators of gambling casinos sometimes under-report their betting
> volumes and thus also their profits. This practice, called skimming,
> has the merit that it reduces their tax liabilities.
>
> However convenient this under-reporting may sometimes be, its defense
> because these low reported figures "reflect actual activity . . . just
> not . . ALL the activity" in the casino is disingenuous, as is Mr.
> Ewing's defense of the use of invalid, because biased in the technical
> sense, VSAM statistics.
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
