That is certainly a possibility, but wouldn't help in the (common) case of
a change that just appends to the end.   Perhaps hashing both the "first n
bytes" with the F1/8 DSCB (which has information about the last TTR and
bytes in the last track) would cover more of the common changes than either
alone.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Thu, Aug 20, 2015 at 12:04 PM, Charles Mills <[email protected]> wrote:

> I've given a bunch of thought to this.
>
> One of the things I've thought about was storing a hash of the first 'n'
> bytes or records of the dataset. If that changed then you would know the
> dataset had changed. If it did not change then you would have to run the
> full dataset hash, but for some large files the savings from this two-part
> strategy might be significant.
>
> Charles
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Kirk Wolf
> Sent: Thursday, August 20, 2015 9:55 AM
> To: [email protected]
> Subject: Ideas for hash of a sequential data set
>
> I'm trying to come up with an efficient way to see if a non-VSAM data set
> has been changed.
> Flipping the DS1IND08 bit is not an option, nor can I install SMF hooks,
> etc in the OS.
>
> The problem, of course, is that DSCBs don't have "last update timestamps".
>
> My initial whack at this would be to use a two-part hash:
>
> part 1: a shortened SHA1-hash of the format-1/8 DSCB part 2: a full SHA-1
> hash of all of the data
>
> The goal is to calculate something when I read an entire data set and keep
> it, and then later I can use this to later know if I need to read the data
> again.
>
> So: a part 1 match is non-informative (the data set could still have
> changed, although not likely)
>
>        a part 1 mismatch would tell me that most probably the data set has
> changed (or just moved?). I would then have to read the entire data set to
> determine if it really has changed.
>
> Thoughts?
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to