We are going to built a self-developed VSAM KSDS file with a few AIX,
there are chances that records in the file are online-queried by in-house TSO users and updated by batch jobs at the same time.
The records for online query might be acquired by repro utility in TSO background and then they are plugged into an ISPF table for online display. On the other hands update batch jobs could be COBOL, EASYTRIEVE OR simply a IDCAMS REPRO (yet to be confirmed).
In this situation I wonder if share-option is the best way to manage access conflict between users and batch jobs. Also should every batch job need to make a copy of the VSAM file by repro before update?
that seems a little bit clumsy for recovery. How often would a VSAM file get corrupt !?
Joined: 06 Jun 2008 Posts: 8515 Location: Dubuque, Iowa, USA
I wonder if share-option is the best way to manage access conflict between users and batch jobs.
Actually, the shareoption setting is the ONLY way to manage access conflict -- you set the shareoption values depending upon what you are trying to do. And, depending upon the selected values, you may have to implement ENQUEUE / DEQUEUE logic in each program using the VSAM data set.
How often would a VSAM file get corrupt !?
Depending upon the way it is defined, and how it is accessed as well as the enqueue / dequeue facility used, the answer to this question could be never, or once in a while, or once a year, or once a month, or once a week, or once a day, or once an hour, or pretty much every time it is accessed.
And it is a data set, not a file -- z/OS has files on tape or in Unix System Services only; every disk data set (and VSAM is on disk) is a data set not a file.
If you have not downloaded / read the Redbook VSAM Demystified you need to do so -- NOW! It should be required reading for every VSAM rookie.