CICS moderates access to a VSAM file by doing internal CICS-level ENQs. For a KSDS, the ENQ is on the key value. A VSAM dataset in a single CICS region can be used and updated safely my multiple transactions running in that region (or in multiple regions if the file request is sent to a "file owning region"). Of course, this can lead to a dead lock situation if the transactions try to update multiple records in the same dataset, unless something is done to exclude it.
If the VSAM file is "local" to multiple regions, or between CICS and batch, then you can corrupt the data. If you need concurrent access via batch and CICS, I suggest H&W's SYSB product. We use it and it works with no real problems. Basically, SYSB extends CICS' support for Multi Region Option (MRO) access to a dataset to batch. The actual I/O is done in the CICS region. Another post mentioned that two records in the same CI could not undergo update processing at the same time. This is true. However, the current CICS versions use VSAM options such that VSAM returns a indicator on the second request to CICS. And CICS moderates this. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dfhp3c00/4.2.6.1 <quote> If you do not use VSAM record-level sharing, CICS serializes update requests by base cluster record key. The complete VSAM control interval (CI) containing the requested record is held for exclusive use while an individual command (for example, a READ command with the UPDATE option) is being executed on the record. Once each command is complete, the control interval is released, and only the requested record remains locked. For nonrecoverable data sets, both the VSAM exclusive use and the CICS exclusive use of the record end when the update request is complete in VSAM terms; for example, when the REWRITE command has completed. For recoverable data sets, however, the CICS exclusive use does not end until the task ends or issues a SYNCPOINT command. Recoverability is specified in the data set resource definition. See FILE definition attributes in the CICS Resource Definition Guide for more information about the FILE resource definitions. </quote> -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . [email protected] . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Walt Farrell > Sent: Thursday, April 05, 2012 6:16 PM > To: [email protected] > Subject: Re: A deep question about VSAM SHR(4) - can you help? > > On Thu, 5 Apr 2012 07:16:15 -0700, Mike Kovach > <[email protected]> wrote: > > >My specific question is this: > > >I want to introduce multi tasking so that 5 copies of the > program can update the file concurrently. If we change STRNO(1) to > >STRNO(5) on the CICS FCT Definition, will VSAM be smart > enough to manage the writes to the file so we don't break it and > >the BATCH still gets the current information? > > I am not a VSAM expert, nor a CICS expert (nor am I sure > whether your program is using CICS functions to write to the > data set, or using VSAM macros directly), but I would be > concerned about serialization. > > From DFSMS Using Data Sets at > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt > 2d4a0/2.7.2.1?SHELF=EZ2ZO213&DT=20110606092005 or > http://preview.tinyurl.com/76joxao you can read that for > SHAREOPTIONS 4 you have the same serialization requirements > as for SHAREOPTIONS 3, and for SHAREOPTIONS 3 the book says > <quote> > This option requires that the user's program use ENQ/DEQ to > maintain data integrity while sharing the data set, including > the OPEN and CLOSE processing. User programs that ignore the > write integrity guidelines can cause VSAM program checks, > lost or inaccessible records, uncorrectable data set > failures, and other unpredictable results. This option places > responsibility on each user sharing the data set. > </quote> > > So unless there's something in CICS issuing appropriate > ENQ/DEQ macros, I think you'll need to make some program changes. > > -- > Walt > > ---------------------------------------------------------------------- > 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
