Joined: 05 Dec 2006 Posts: 168 Location: Seattle, WA
This is a basic question, but one we're struggling with, so I beg patience up front!
We are experiencing slow performance in one of our CICS regions and one of the messages the log file keeps getting is this:
AL$0001I CICP6235, CICP6, LC4070IB, , MIPS235.P.C4070IB.DATA.VSAM
AL$ESD1E DATA SET IS ON MAXIMUM VOLUMES TERMINATING RECOVERY
I can see that this is a KSDS Ext-Addr file in File-Aid, but I'm not sure what else I should be looking for. The Current space allocated/used ratio is 69% (38,985 tracks/26,821 tracks), which doesn't seem like a bad ratio. The KSDS Index is 125 tracks. The total Data Records is 423,867, but the Retrieved Data Records is 14,226,052.
One thing I noted is that this VSAM file gets copied to a flat file daily, but is never deleted/redefined/reloaded like other VSAM files that I've seen. Could that be the source of the performance issue?
Joined: 06 Jun 2008 Posts: 8479 Location: Dubuque, Iowa, USA
I'd want to see a LISTCAT for the data set, and I'd be looking particularly at things like CI splits, CA splits, number of volumes in use, number of candidate volumes, number of extents per volume, HI-A-RBA and HI-U-RBA. The error message number you quoted is NOT a standard IBM error message number, so one place to start would be to find out what is generating the message and what that software says about that particular error message.
The Current space allocated/used ratio is 69% (38,985 tracks/26,821 tracks)
This may be a completely misleading number -- if the data set needs to add records (either at the end of the data set or through a split), the LISTCAT values may indicate that such an extension is not possible for one reason or another.
One quick-and-easy possible solution would be to unload the VSAM, delete / define it, and reload it. Comparing the LISTCAT from before this is done to the LISTCAT after this is done should shed some light on the situation.
The * means that it is a candidate volume. So the data set is on one volume. Splits don't have the performance impact that they did when disks were physically moving read/write heads from track to track, but 31741 CI splits and 1074 CA splits definitely means your data is scattered (especially considering the data set is only 3 weeks old). In a batch application, that usually doesn't matter but it can mean a performance hit to a CICS application, depending upon the read method (sequential or direct). Another factor to consider is the spanned records -- I don't recall ever hearing if spanned record access would be slower than non-spanned records, but I certainly think it is possible (since for the spanned records, 2-3 data CI have to be read not 1).
With a 25% CI freespace, you are getting about 10 records per CI based on the average record length, and 900 per CA. The data requires just over 540 cylinders and the used space is 1789 cylinders. I definitely think an unload, delete / define, reload is recommended. It will probably help the CICS performance as well, although CICS performance depends upon so many factors that it is hard to say for sure.