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.
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.
This was first published in October 2002