Thanks to everyone who replied. The server is a part of a product and so installation must have a minimal impact on a customer's system. I am currently going with using the last backup date as an indicator that the data set has been written and a sync is required.
Thanks Robin -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: 22 November 2013 21:34 To: [email protected] Subject: Re: Getting a VSAM data set's system timestamp Ah, my bad, I didn't realize this was not for an in-house type project. On Fri, Nov 22, 2013 at 8:32 AM, Robin Atwood <[email protected]> wrote: > Ingenious and it would be technically fascinating to try and implement! > However I imagine it would be a bit of a hard sell to the customers. > :) > > Thanks > Robin > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of John McKown > Sent: 22 November 2013 20:14 > To: [email protected] > Subject: Re: Getting a VSAM data set's system timestamp > > One possibility, which is not simply by any means, is to use the SMF > data in "real time", with the SMF IEFU8x exits, to trap the SMF type > 15 records (non-VSAM open for OUTPUT or UPDAT) and type 62 (VSAM > cluster opened). With the type 62, you need to test SMF62MC1 to see if > the open is for output/update. This can be done using CA-7 (if you > have it). We use it to trigger jobs when a file is created / updated > via something like ftp from a Windows server. Another possibility is > to create a discrete RACF profile for the dataset(s) you are concerned > about and AUDIT them. This will produce a RACF SMF record. Which you > could trap using the SMF IEFU8x exits, or simply process sometime > later, say when you dump the individual SMF data sets, if you don't > need "real time". Oh, the same for the type 15 & 62 records too, I > guess. > > > On Fri, Nov 22, 2013 at 1:48 AM, Robin Atwood <[email protected]> wrote: > > > So both you and Lizette are saying that even I can obtain it, the > > available timestamp is not very useful. We need to synchronise the > > mainframe data set with its workstation copy and currently use > > hashes of each file to see if they are different. This is CPU > > intensive and I had hoped to avoid it by comparing the last write > > dates. It looks like my scheme won't work in this case (it works > > fine for libraries of members > like PDSs and Endevor). Hmm. > > > > Thanks > > Robin > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of retired mainframer > > Sent: 22 November 2013 00:54 > > To: [email protected] > > Subject: Re: Getting a VSAM data set's system timestamp > > > > For a non-VSAM dataset, the last reference date in the F1 DSCB does > > not mean the dataset was changed on that date, only that it was > > opened (and closed?), even if only for input. > > > > :>: -----Original Message----- > > :>: From: IBM Mainframe Discussion List > > [mailto:[email protected]] On > > :>: Behalf Of Robin Atwood > > :>: Sent: Thursday, November 21, 2013 4:48 AM > > :>: To: [email protected] > > :>: Subject: Getting a VSAM data set's system timestamp > > :>: > > :>: I want our file server to be able to tell the clients when a > > data set > > :>: last > > :>: changed. For non-VSAM it's easy (if a bit vague), there's the > > last > > :>: reference > > :>: date in the F1 DSCB. > > > > -------------------------------------------------------------------- > > -- 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 > > > > > > -- > This is clearly another case of too many mad scientists, and not > enough hunchbacks. > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > 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 > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- 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
