Re-organizing a VSAM

Selva-kumar · New User Joined: 01 Mar 2007 Posts: 52 Location: chennai

Hi,

I have a vsam file which is of size CYL(1500,1200). It has almost 1177998081. It is a KSDS file and undergone 102962 CI splits and 226807 CA splits. So we decided to do a re-org. I copied this vsam to a flat tape file. It is successfully copied. But when i tried to copy that to a new vsam file, it is not getting copied.

It copy only about 30% of records and then abended with VSAM I/O return code 28. When looked into the file statistics, the number of extents is 83 whereas for the original input file its 192.

Is this extent can be a problem for not able to copy the entire records? Please throw some light on this..

Thanks.

Robert Sample · Posted: Fri Feb 26, 2010 8:27 pm

Despite providing lots of numbers, you've provided almost nothing of help to us. For example,

Bill O'Boyle · Posted: Fri Feb 26, 2010 8:28 pm

What BLKSIZE did you specify on the tape/cartridge output?

What is the file's LRECL?

What is your FSPC percentage?

Your CISZ in the definition may not be optimum and coupled with a low FSPC percentage, it seems that your splits might be greater than you'd like. CI splits are a part of VSAM and they go with the territory, but you want to avoid CA splits as much as possible, especially in CICS.

Bill

Selva-kumar · New User Joined: 01 Mar 2007 Posts: 52 Location: chennai

Hi,

Sorry for not mentioning it. The value is the total number of records. 1177998081 records. It is a KSDS file. The HI-A-RBA and HI-U-RBA values are 227126476800.

Selva-kumar · New User Joined: 01 Mar 2007 Posts: 52 Location: chennai

Hi,

The LRECL of the file is 2389. While copying it to a tape file, i specified the BLKSIZE as 0 only. It is succesfully copied. Problem is that when i try to copy that to another VSAM file.(KSDS). The CI size is 4096. The Free space value is 5657665536.

Selva-kumar · New User Joined: 01 Mar 2007 Posts: 52 Location: chennai

Sorry. The Free space value is 60585828352.

Robert Sample · Posted: Fri Feb 26, 2010 8:46 pm

CI size of 4096 is wasting 40%+ of the space allocated to your VSAM file -- using 26624 would be much better as far as space utilization.

How many volumes get allocated for the new file? How many candidate volumes are left? How much space is being allocated on each pack? Which version of the operating system are you running? Is the file under SMS control or not?

Again, most of these questions could be answered from the LISTCAT output, rather than having you piecemeal answers.

Selva-kumar · New User Joined: 01 Mar 2007 Posts: 52 Location: chennai

Following are the details of old file:

Robert Sample · Posted: Fri Feb 26, 2010 9:37 pm

Sigh. This is not a LISTCAT. This is an extract of a LISTCAT. You didn't include any of the volume data which my last post asked about.

I see a few problems already, though. From the buffer space and data component CI size, it appears the index component CI size is too small. The rule of thumb IBM provides suggests with a 4096 data CI size and key length of 47 bytes, the index CI size should be at least 5120 to prevent having data CIs that cannot be accessed. This probably explains the 10% free space your new file is showing -- but I'd watch for free space after redefining the index CI size to the right value and reloading the file.

Selva-kumar · New User Joined: 01 Mar 2007 Posts: 52 Location: chennai

Sorry that i couldn't post the volume data since its very huge. I will try with the suggestion of increasing the index CI value and will let know about how it turns out to be.

Thanks for the valuable information.

Robert Sample · Posted: Fri Feb 26, 2010 10:09 pm

How's the utilization per pack, and are there any unused volumes (* for the volume name) on the LISTCAT output?

Pete Wilson · Posted: Mon Mar 01, 2010 3:33 pm

Please post the full IDCAMS message id for the RC=28 including the REASON Code. It would be something like IEC161I or IDC3009I.

Also the JCL for your unload and reload might be useful, including the IDCAMS sysin cards which would indicate the way the file was defined.

The statistics in the LISTCAT you provided for the original file can't be relied on as it looks lilke the file was open (as indicated by the * against the numbers) and they're only written back to the catalog from the in-storage copy when the file is closed normally. Is it possible to close that file do and IDCAMS VERIFY then do another LISTCAT to get good statistics?

A 47 byte Keylen is unusually large although DFP will now adjust the index CISIZE to the minimum required to avoid the problem with unreferenced Data CI's. But the allocation size for the index component might have to be boosted.

Are the minimum and maximum record sizes indicated valid (i.e. 159 2389)? That is a big variation in size, and it would be nice to know what sizes are most frequently occuring as that has a bearing on the Data CISIZE selection, as well as free-space selection. The file can either be 57Gb or 866Gb depending on the record sizes present, and maybe it's coincidental but the record count of your new file times the smaller 159 record size seems to match up to the 57Gb. Data CISIZE 28160 seems to fit both sizes closely. That would certainly reduce the file size, but you'd have to check with your CICS people that they have LSR buffers for that size available before changing it. If you have Syncsort you can run a Histogram against the file to get the frequency of different record sizes, otherwise SAS or perhaps SORT can provide the numbers.

Note that whatever free-space you specify is imbedded in every CI and CA after you load it. Whatever percentage you specify should be sufficient to contain at least the minimum record size and hopefully the maximum record size otherwise it can't be used. If you know that there are certain records with clustered keys you can increase the the free-space before loading with REPRO for those specific keys by using the ALTER command and re-adjust it down for the rest of the records. This can further reduce the file size.

It would also be interesting to know how the Dataclas KSDSADRX is set up. You might want to check this with your Storage Admin people. I assume it is defined with Extended Addressability as the file is over 4Gb but it should also be Extended Format to avoid the 65k trks per volume size limit. Also I'd hope it has Space Constraint Removal enabled so that additional candidate volumes are added if required, otherwise you'd need to specify candidates volumes with the parameter VOLUMES(* * * *....) on the define, up to the maximum of 59 volumes (so 59 asterisks). Space Constraint also allows the allocation size to be adjusted to fit available space on the volumes, so if it is enabled you might want to make the allocation sizes larger because you have only 1.27Gb Primary and 1Gb secondary specified (when cyls converted). You could consider changing the allocation to use RECORDS instead with primary being 10% of the total number of records and secondary the same, so it can allocate the total requirement in 10 'chunks'.