VSAM Write error

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

Hi,

The VSAM file which am using is getting error while writing and abends with File status of 24. As file status 24 is meant for writing the file beyond its boundary, i checked the file attributes in LISTCAT and it has freespace.

This abend occurs when some other parallel jobs are running. When i re-ran this job once other job got completed, it ran fine. I like to know what esle could be the reason for it. I have given the LISTCAT entry details.

Robert Sample · Posted: Mon Dec 06, 2010 5:03 pm

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

Thats because if all the HI-A-RBA is being used up, and if we try to write, it could have caused file status 24.

PeterHolland · Posted: Mon Dec 06, 2010 5:15 pm

Your HURBA is not totally used, so there could be space. If your remove the FSPC with an ALTER what happens then?

And looking at your listcat i suggest to do a reorg for that dataset.

Robert Sample · Posted: Mon Dec 06, 2010 5:18 pm

PeterHolland · Posted: Mon Dec 06, 2010 5:21 pm

Robert Sample · Posted: Mon Dec 06, 2010 5:23 pm

No, Peter, you're just preceding me!

PeterHolland · Posted: Mon Dec 06, 2010 5:27 pm

Sorry Robert,

i forgot how fast i can be (sometimes).

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

Peter,

The file has a freespace allocation of (14 10) during the file creation. If i remove the FSPC with ALTER command, wont i get problem when i try to update/insert/delete records in this file? Also, i did a re-org to this file some 8 months back.

Robert,

I believe you are asking for the number of volumes that the file is on with the term 'disk pack is on'. The file is on 22 volumes. correct me if misunderstood ur question

Robert Sample · Posted: Mon Dec 06, 2010 7:15 pm

There's two limits that apply to VSAM extended addressability files -- 59 volumes and CI size times 4 GB. Since your data set is only on 22 volumes, it does not appear to be reaching either limit.

Freespace is only relevant when inserting records -- updates in place (unless the record length changes) won't impact the freespace, and deletes add to freespace (although it may not be usable freespace). If your file does not have freespace defined where an insert is done, the normal CI and CA split rules will apply.

Pete Wilson · Posted: Mon Dec 06, 2010 7:27 pm

You may need to add more candidate volumes for the file to extend to if it has reached the full number assigned by it's Dataclas, or Volume parameter on the define. This is obviously a very large file at 161Gb going by the HURBA.

Enter the following in an IDCAMS job to add a further 5 candidates:

ALTER dsname VOLUMES(* * * * *)

It's impossible to tell from the portion of LISTCAT shown but is the FSPC(14 10) appropriate? The file obviously has huge numbers of inserts so the CI freespace is probably required, and perhaps a reorg needs to be done more regularly, but does 14% CI freespace allow for the MAXLRECL at least? Be helpful to see the LISTCAT page showing MIN/MAX LRECL's, KEYLEN.

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

This is the definition of that vsam file.

Robert Sample · Posted: Wed Dec 08, 2010 6:15 pm

1. Your index CI size is too small based on the key length and data CI size.

2. The data CI size is not very good considering the maximum record length.

3. These help explain why your file is 81% free space.

And these may explain the intermittent 24 file status codes.

Pete Wilson · Posted: Wed Dec 08, 2010 8:15 pm

Data CICIZE would be better at 26624 for example as that would only waste 334bytes per CI for max recordsize, but two minlrecls could fit into that so not much waste at all. And if freespace was set to 9% it would allow for one maxlrecl record to fit comfortably in the 2396 bytes, or a fairly even number of lrecl 159's.

Data CICIZE at 12288 would also only waste 334bytes per CI for max recordsize. And if freespace was set to 20% it would allow for one maxlrecl record to fit comfortably in the 2457 bytes.

Using the 4096 byte Data CISIZE means you could be wasting up to 2245 bytes per CI for maxlrecl as only 1.7 maxlrecl can fit into 4096 wasting 1672 bytes and the 14% freespace provides 573 bytes which 2389 won't fit into, although two 159 lrecl's would.

Basically CISIZE can be any multiple of 512 so you find what fits your LRECL best for the Data CI and calculate what freespace will be as a percentage of the CISIZE in bytes. For the Index I think in these later releases of DFP IBM have finally made so it will provide an appropriate CISIZE by default to avoid the 'dead' unreferenced CI issue of the past.

NOTE: If the file is used by CICS you have to make sure there are buffer pools available for the changed CISIZE's first.