John is correct. 

Many scheduling products (CA Workload Automation/ESP, CA7, Jobtrac, etc)
will monitor SMF data and have a function called a dataset trigger.

If you have such a tool, then you could review if it could help in your
situation.

Otherwise, you will need to look at the SMF Exits.

Or if you have a product like DB2 that you could extract updates from the
DB2 logs and apply them to your workstation.

Or if your application could be modified to generate a record modified log
that could be applied to your workstation.

You did not indicate if your VSAM dataset was being used by something like
CICS, home grown application.  Whether the file was held open for long
periods of time or opened and closed more frequently.  

Any additional details you could share with us, we might be able to come up
with other options.
  How large is the VSAM file that needs to be sync'd with the workstation?
  How do you sync the file?  FTP, NDM, CD, etc....
  How often do you sync the files?
  Does the workstation sync with the mainframe or is it just the mainframe
to the workstation?
  What is your SLA for this data to be sync'd?  
  Are you using IMS, DB2, CICS or is this native VSAM?  
  Do you have IMS, CICS, DB2 or MQ in your shop?  Could they be used to help
with this situation?

Lizette


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Friday, November 22, 2013 6:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 <abend...@gmail.com> 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:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of retired mainframer
> > Sent: 22 November 2013 00:54
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > 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:IBM-MAIN@LISTSERV.UA.EDU] On
> > :>: Behalf Of Robin Atwood
> > :>: Sent: Thursday, November 21, 2013 4:48 AM
> > :>: To: IBM-MAIN@LISTSERV.UA.EDU
> > :>: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to