Page 1 of 1

Exclusive Access to a record in KSDS

PostPosted: Mon Jun 03, 2013 3:36 pm
by ashwin1990
Hi,

I have a CICs screen which fetches record from a KSDS file. This record can be modified on the screen (including part of key). When the part of key is modified, the original record is deleted and a new record is written into the file, with the new key.

Now there was a situation when two users modified the same record (key) and saved it simultaneously. This created two new records, which was not correct.

Can we handle this situation by allowing only one user to modify at a time.

I cannot use exclusive control on the file, as other records should be available for editing at the same time.

Its only the same record that should not be allowed to be edited (Users should be able to read the same record simultaneously).

Thanks

Re: Exclusive Access to a record in KSDS

PostPosted: Mon Jun 03, 2013 4:41 pm
by Robert Sample
You have two choices: (1) use some form of exclusive control, such as CICS ENQ/DEQ logic, to serialize updates, or (2) accept that your application can generate duplicate records and be prepared for such an event since it WILL happen again. telling us that you cannot get exclusive control of the data set is telling us that you cannot fix the situation -- period.

Re: Exclusive Access to a record in KSDS

PostPosted: Mon Jun 03, 2013 5:12 pm
by ashwin1990
Does using 'ENQ/DEQ' restrict the record from being read as well??

Re: Exclusive Access to a record in KSDS

PostPosted: Mon Jun 03, 2013 5:27 pm
by Robert Sample
What are the VSAM shareoptions for the data set? ENQ / DEQ can be used at whatever points in the program that make sense -- based on what you've posted, you probably want to ENQ, read, then either delete / write or read for update and rewrite, then DEQ.

Re: Exclusive Access to a record in KSDS

PostPosted: Wed Jun 05, 2013 11:21 am
by ashwin1990
Thnks for the reply Robert:)

Re: Exclusive Access to a record in KSDS

PostPosted: Mon Jul 15, 2013 9:54 am
by MFUser1
I think we have implicit record level locks in VSAM files for such situations. When a record is accessed in READ UPDATE mode followed by a DELETE/REWRITE, the record is locked not only for the duration of update but the lock extends to the end of UOW (UOW ends either when a SYNCPOINT is issued or when the CICS transaction ends). Refer to this page:- http://publib.boulder.ibm.com/infocente ... fht23i.htm

With this implicit locking feature for VSAM files, I am not sure how two transactions (users) could update the same record simultaneously.

Re: Exclusive Access to a record in KSDS

PostPosted: Mon Jul 15, 2013 3:04 pm
by Robert Sample
MFUser1, are you aware that the SHROPTIONS description in the Access Method Services for Catalogs manual EXPLICITLY states that what you posted is not true for certain values of SHROPTIONS? From that manual (I have highlighted the relevant statements):
SHAREOPTIONS(crossregion[ crosssystem]|1 3) Shows how a component or cluster can be shared among users. However, SMS-managed volumes, and catalogs containing SMS-managed data sets, must not be shared with non-SMS systems. For a description of data set sharing, see z/OS DFSMS Using Data Sets. To ensure integrity, you should be sure that share options specified at the DATA and INDEX levels are the same. The value of SHAREOPTIONS is assumed to be (3,3) when the data set is accessed in VSAM RLS or DFSMStvs mode.

crossregion Specifies the amount of sharing allowed among regions within the same system or within multiple systems using global resource serialization (GRS). Independent job steps in an operating system, or multiple systems in a GRS ring, can access a VSAM data set concurrently. For more information about GRS, see z/OS MVS Planning: Global Resource Serialization. To share a data set, each user must use DISP=SHR in the data set's DD statement. You can use the following options:





OPT 1 The data set can be shared by any number of users for read processing, or the data set can be accessed by only one user for read and write processing. VSAM ensures complete data integrity for the data set. This setting does not allow any non-RLS access when the data set is already open for VSAM RLS or DFSMStvs processing. A VSAM RLS or DFSMStvs open will fail with this option if the data set is already open for any processing.




OPT 2 The data set can be accessed by any number of users for read processing, and it can also be accessed by one user for write processing. It is the user's responsibility to provide read integrity. VSAM ensures write integrity by obtaining exclusive control for a control interval while it is being updated. A VSAM RLS or DFSMStvs open is not allowed while the data set is open for non-RLS output. If the data set has already been opened for VSAM RLS or DFSMStvs processing, a non-RLS open for input is allowed; a non-RLS open for output fails. If the data set is opened for input in non-RLS mode, a VSAM RLS or DFSMStvs open is allowed.


OPT 3 The data set can be fully shared by any number of users. Each user is responsible for maintaining both read and write integrity for the data the program accesses. This setting does not allow any non-RLS access when the data set is already open for VSAM RLS or DFSMStvs processing. If the data set is opened for input in non-RLS mode, a VSAM RLS or DFSMStvs open is allowed.


OPT 4 The data set can be fully shared by any number of users. For each request, VSAM refreshes the buffers used for direct processing. This setting does not allow any non-RLS access when the data set is already open for VSAM RLS or DFSMStvs processing. If the data set is opened for input in non-RLS mode, a VSAM RLS or DFSMStvs open is allowed. As in SHAREOPTIONS 3, each user is responsible for maintaining both read and write integrity for the data the program accesses.

crosssystem Specifies the amount of sharing allowed among systems. Job steps of two or more operating systems can gain access to the same VSAM data set regardless of the disposition indicated in each step's DD statement for the data set. However, if you are using GRS across systems or JES3, the data set might not be shared depending on the disposition of the system. To get exclusive control of the data set's volume, a task in one system issues the RESERVE macro. The level of cross-system sharing allowed by VSAM applies only in a multiple operating system environment. The cross-system sharing options are ignored by RLS or DFSMStvs processing. The values are:





1 Reserved


2 Reserved


3 Specifies that the data set can be fully shared. With this option, each user is responsible for maintaining both read and write integrity for the data that user's program accesses. User programs that ignore write integrity guidelines can cause VSAM program checks, uncorrectable data set errors, and other unpredictable results. This option requires each user to be responsible for maintenance. The RESERVE and DEQ macros are required with this option to maintain data set integrity. (For information on using RESERVE and DEQ, see z/OS MVS Programming: Authorized Assembler Services Reference ALE-DYN and z/OS MVS Programming: Authorized Assembler Services Reference LLA-SDU.)


4 Indicates that the data set can be fully shared. For each request, VSAM refreshes the buffers used for direct processing. This option requires that you use the RESERVE and DEQ macros to maintain data integrity while sharing the data set. Improper use of the RESERVE macro can cause problems similar to those described under SHAREOPTIONS 3. (For information on using RESERVE and DEQ, see z/OS MVS Programming: Authorized Assembler Services Reference ALE-DYN and z/OS MVS Programming: Authorized Assembler Services Reference LLA-SDU.) Output processing is limited to update, or add processing, or both that does not change either the high-used RBA or the RBA of the high key data control interval if DISP=SHR is specified.

To ensure data integrity in a shared environment, VSAM provides users of SHAREOPTIONS 4 (cross-region and cross-system) with the following assistance:
Each PUT request immediately writes the appropriate buffer to the VSAM cluster's DASD space. That is, the buffer in the user's address space that contains the new or updated data record, and the buffers that contain new or updated index records when the user's data is key-sequenced.
Each GET request refreshes all the user's input buffers. The contents of each data and index buffer being used by the user's program is retrieved from the VSAM cluster's DASD.
Abbreviation: SHR

Re: Exclusive Access to a record in KSDS

PostPosted: Tue Jul 16, 2013 5:05 am
by MFUser1
Robert, Thank you for sharing the information on VSAM SHAREOPTIONS.