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 IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs? Continue Reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology. Continue Reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible? 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.