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>>

<<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.





Return to Archive home page | Return to MIDRANGE.COM home page