I read in the CICS Performance Guide that "There are some special performance considerations when choosing a STRINGS valus for an ESDS file. If an ESDS is used as an 'add-only' file (that is, it is used only in write mode to add records to the end of the file), a string number of 1 is strongly recommended. Any string number greater than 1 can significantly affect performance, because of exclusive control conflicts that occur when more...
than one task attempts to write to the ESDS at the same time."
Would you be able to elaborate on the principle behind this statement? I'm having performance problems with one of the ESDS files (used as add-only, defined with multiple strings.) Most of the wait is occuring on the resource type KC_ENQ. The command causing this wait is WRITE to the ESDS file. The CICS version is 4.1.
Oh dear! You are on CICS/ESA 4.1? Well, enjoy it for the next 70ish days because it goes out of service at the end of this year.....and you don't want to be unsupported by us chaps/chapesses here at Hursley do you?
The reason why we suggest only one String for an ESDS in write-mode is to do with locking and recovery. As you always add records at the end of an ESDS, in the case of a failure, Unit-of-Work recovery will delete all the records added since that start of that UoW (Add 5 records, and you want all 5 of them to disappear on a rollback).
If there are two transactions going, you cannot allow them to intermix the adding of records (AB12CD34E5 with ABCD from one tran and 12345 from another) because of the need to preserve the sequence (you cannot have physical holes in an ESDS) on a recovery. CICS will prevent this type of double access.
Thus, it's the case of getting a lock at the VSAM level, the File Level or the Buffer Level (in order from worst to best) which permits access for the 1st writer and waits the 2nd. If you use only one String, then you are getting locking at the Buffer level which is the most efficient in the CICS environment. Use more than one string (so as to get multiple writers) and you start getting locks at lower levels which have higher overheads - and no better throughput anyway.
If you are getting what you think of as unjustified waits due to multiple writers, you may want to adjust the duration of the Unit Of Work and so get a better throughput. However, the only real long-term answer is to have multiple ESDS' and join them up in offline/batch processing.
Dig deeper on Mainframe operating systems and management
Related Q&A from Robert Crawford
The mainframe is IT's original cloud, and there are still ways to float cloud operations onto big iron today. But is it pragmatic?continue reading
With 3270 bridge, you can't stack input messages into one structure. The bridge can't process them all at once. It takes a little more work.continue reading
CICS expert Robert Crawford offers advice on determining the connection between CICS transactions and MQ Queue name.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.