Need Help regarding the CA/CI Split

himanshu_pant · New User Joined: 08 Jul 2014 Posts: 14 Location: India

Hi,

I have KSDS dataset that is being reorganized begining every week(its backed up in a dataset, then KSDS is delete redefined and the backup is then loaded in the newly defined KSDS) . Right now the dataset had been reorganized two days back and when I see its current statistics through listcat, it shows me the below information:

expat · Posted: Tue Aug 19, 2014 2:46 pm

Topic moved to the appropriate forum section

The KSDS is defined as variable length records, so why do you say that all of the records will be maximum length.

Why do you reorganise the file, this would not really affect performance with most modern DASD subsystems, especially if it is a RAID 6 device.

Without knowing the key values where records are to be inserted, your guess of how many records will be as good as anyone else guessing.

I suggest that you allocate more space to the file and increase the CA free space allocations. Why you bother to have CI free space allocated if what you say is true about the record lengths, as only one record can fit into one CI. Even if the record has the minimum length, only one will fit into one CI.

himanshu_pant · New User Joined: 08 Jul 2014 Posts: 14 Location: India

Hi Expat,

Yeah realized that late and 10 minutes had already passed so couldn't edit. Will take care of this by the next time.

Yeah I know it is variable-length KSDS. My question was how many more could fit in if I consider all of them to be of maximum size(worst case scenario). I am not too sure of you other comment though like even if the records are of minimum size, only one would fit in a CI. Is it being derived from the Avg length which is 17000 for this dataset, as in this dataset I have seen record lengths vary from 100 to 25600? So if a record of 100 byte does come in, I think a CI would allow more than one to fit in.

Thanks.

expat · Posted: Tue Aug 19, 2014 3:31 pm

Oooops, yes you are correct, I did use the average record length.

As I said earlier, without knowing the key ranges of new records your guess to how many more records is as good as anyone else guessing.

If the key ranges are fairly evenly split, you could insert hundreds or maybe thousands of records without getting many splits. If the records are in a small key range then the number of splits will be much higher, and thus the number of extents will also increase.

Looking at your listcat, it seems that the last set of records iserts were within a small key range given that you have inserted 2K records and have 130 CA splits and 35 dataset extents.

Although the number of extents could have been high anyway from the original KSDS definition, I would hazard a guess that the number increased due to the splits that have occured.

Bill Woodger · Posted: Tue Aug 19, 2014 4:18 pm

130 is not really that big. 5 for the CI splits also argues for insertion in lump(s) of similar, ascending, keys.

himanshu_pant · New User Joined: 08 Jul 2014 Posts: 14 Location: India

Thanks Bill.

Just want to know what is the upper limit of CA split, which is considered to be high enough?

Bill Woodger · Posted: Tue Aug 19, 2014 5:46 pm

When there is a low ratio of records inserted to CI splits then you may want to become concerned. I'd guess that the CAs which are split are containing almost all the inserted data, so it's just "natural" usage.

It is good to know your "insertion pattern" for a KSDS if you believe there may be problems. The distribution of the new data in relation to key, and key in relation to other keys. I'd guess that most of your data that is inserted is done so in a block at the high end of your keys, and in ascending key order, but it's only a guess and a limited one with the limited information.

If this is the case, and you're really concerned to minimize things, you may find that dropping the freespace altogether saves you space. If you can arrange "bulk inserts" rather than individual inserts that may help a little, but for 2200+ records, I'm not convinced you'd notice anything much.

If I was looking for KSDS's "in trouble" I'd ignore that one in a flash. Why do you think there may be a problem?

himanshu_pant · New User Joined: 08 Jul 2014 Posts: 14 Location: India

Thanks Bill.

We have recently made change in our CICS program to make it write the most of the records with maximum record length (25600). Earlier it was much lesser and only sprodiacally records of length 25600 used to come. So I am concerned that this might cause problem in production where someday the KSDS run out of space. As a precautionary measure, I am monitoring these statistics and came across these CA splits. Could you please advise?

Marso · Posted: Wed Aug 20, 2014 12:41 pm

The number of splits is not an indication of the file capacity.
If you're worried about running out of space, you should monitor the number of extents, the free space on the volume, and the inserts rate, for example.

PeterHolland · Posted: Wed Aug 20, 2014 3:05 pm

It would be nice, to see a listcat immediately after the define/load, are there any splits already?

And get rid of the CI freespace, because no 25600 byte record wil fit in a CI space with around 22000 bytes left.

Pete Wilson · Posted: Wed Aug 20, 2014 3:20 pm

You could also look at altering the CA free-space value during the load of clustered key records. So in cases where you know there's large numbers of records with a similar key you increase CA freespace, then alter it back down again when loading the next set of keys where the keys are more variable. This means you get the freespace around the areas of the file that need it without having unnecessary freespace across the entire file, this reventing it from becoming larger than necessary.

You should probably reduce the frequency of your re-orgs to be very occasional, or only driven by the need should the file become very fragmented. The point is once the splits have occurred then VSAM has done the work to put freespace exactly where it is needed and a re-org just undoes that work so it has to be repeated.

Bill Woodger · Posted: Wed Aug 20, 2014 3:40 pm

Thanks, Pete, that's the answer I was looking for on this ramble. I'd come to the conclusion that it was a technique which was not actually used... file in this case looks too small to bother with, though.

So, remove all the freespace. Cancel the regular reorg. Monitor the file size (occasionally).

Also, it's actually better to keep VSAM records as small as possible for CICS (or "online" in general) I always thought. What was the reasoning behind the change?

himanshu_pant · New User Joined: 08 Jul 2014 Posts: 14 Location: India

Thanks guys for all your suggestions.

I researched this a bit further and found that there is only one volume which is prime and has all the data till now and there are still 24 candidate volumes left. With somewhat 200000 records it has not even fully consumed a volume and considering VSAM allows 123 extents, so I think it shouldn't cause much problem in the near future as the number of records that come daily as of today is not more than 2000. Although Index has lot of CI splits and low CA splits, but still it also has 5-6 candidate volumes left so needen't worry there as well.

Bill,
We have an assembler program which actually does this insertion in the KSDS file. We converted a batch program into a CICS program which calls this assembler program to do the inserts(as this is the architecture we follow). Somehow the calls to the assembler program for the insertion of record with the length less than that of maximum length was failing( its not that we didn't try, we tried all the things like passing the record length of actual bytes in the record, but didn't work. May be some problem with the assember), to overcome which we had to give the maximum length. I know its inefficient, but was working at the time. We are figuring out that part to reduce the length (or what is wrong with it) but for now its maximum length.

Thanks again.