On 05-Mar-2014 11:00 -0800, James H. H. Lampert wrote:
On 3/5/14 10:36 AM, CRPence wrote:
The order of the records, collated by the names of the files
listed, is not necessarily a chronological ordering.
<<SNIP>> they would only break chronological sequence if they somehow
crossed a century boundary, which is (to say the least) unlikely to
happen again within the product life of IBM midrange systems.
Assuming that... the system date\time only ever moves forward, none
of the QHST files come from elsewhere, the naming of the files [by the
SCPF job] with other than decimal-digits matches the hex collating
sequence, none of the files are renamed [explicitly or by restore], none
of the files has been deleted out of the sequence, the maximum files in
a day that might break a sequence is assured not to have occurred [note:
always use a very large value for QHSTLOGSIZ; that SysVal had always
allowed, and possibly still does allow, entirely too small of values for
what the feature maintains] then... probably the order of the files by
name appearing as records of DSPOBJD output do not require any ordering
because arrival sequence matches chronological [oldest first]. Whether
I overlooked something or mentioned something not germane, no matter,
the point is that although the files might generally be sequenced, the
feature does not perform actions that guarantees they will be; the
effect on user programs that attempt to narrow their scope, and even
DSPLOG output itself, have been victim of failed assumptions about where
the data resides, though mostly due to changes in date and\or time.