IBM Mainframe Forum

Hi,
I need to define a VSAM file which will always contain only one record and would be frequently updated by CICS online programs.
Should I define it as ESDS or KSDS ? What other parameters do I need to take care of when online programs are accessing it concurrently for update ?

From information in "VSAM Demystified" redbook, I think ESDS is the better option though I am not sure. And keeping SHAREOPTIONS(2 3). Please advise if I am thinking correct. Thanks.

"access for update" pretty much points you to KSDS.

I tend to think of ESDS as a "sequential" file in VSAM format; adding records only.
If you are going to have a VSAM file where records will/can be added/updated/deleted/browsed, then KSDS is best option.

Share Options… http://mainframe230.blogspot.com/2010/09/vsam-dataset-sharing-options.html

MFUser1 wrote:Hi,
I need to define a VSAM file which will always contain only one record and would be frequently updated by CICS online programs.
Should I define it as ESDS or KSDS ? What other parameters do I need to take care of when online programs are accessing it concurrently for update ?

From information in "VSAM Demystified" redbook, I think ESDS is the better option though I am not sure. And keeping SHAREOPTIONS(2 3). Please advise if I am thinking correct. Thanks.

A single-record dataset is not going to need too many inserts/deletes. An ESDS can certainly be updated (if you don't try to make the record larger than when read).

Your CICS technical people will be keen to have their say, as they will be aware of your site's standards and policies. Have a chat with them.

Hello. Thanks to all for the responses.

Robert, c62ap90 - I agree with you when you say that "tend to think of ESDS as a "sequential" file in VSAM format; adding records only" and that "access for update" pretty much points you to KSDS". That is the usual practise. But I was thinking of deviating only because its a single record dataset which will never need inserts/deletes. It will only be updated. So, defining a KSDS and using a key to access/update the KSDS file's single record did not look very optimal approach to me. Hence, thought of ESDS.

BillyBoyo - Our site usually uses KSDS for reads/updates and ESDS for inserts (ex: large log files). This single record file situation is a first for us. Our CICS people are fine either way and left it for us to decide.

Well, in a nice way, (talk to them) ensure that it is documented that they left it up to you.

I've worked where there have been ESDS single-record control-files. I wasn't involved in the set-up, they were working long before I arrived, but they were unproblematic. There will be slightly less memory usage. These days, that amount will probably not matter.

Assuming that you do all the access to the control-file through a module (rather than direct access in 1,000 different modules) I'd start with an ESDS and only switch to KSDS if you have problems.

If you want to go the nuts-any-program-can-access-it route, use KSDS for due to greater general familiarity.

BillyBoyo wrote:A single-record dataset is not going to need too many inserts/deletes. An ESDS can certainly be updated (if you don't try to make the record larger than when read).

I did not know an ESDS file could be updated! I've used ESDS for "adding" records only (i.e. audit trail). Learn something everyday.
Thanks.

Hello,

But I was thinking of deviating only because its a single record dataset which will never need inserts/deletes.

Your task is not so different than many. Do as 99.99% have done and define the ksds. There is no good reason to do something different just for the sake of doing it different