DB2 VSAM LDS cisize

Xico Fino · New User Joined: 08 Apr 2009 Posts: 3 Location: Lisboa

Hello!
In my company we have DB2 for zOS version 8 installed.
As you might know, during version 8 migration process some Catalog Tablespaces where converted in VSAM LDS with cisize other than 4k, , ie, t some of them where converted to LDS 8k, 32k etc...

My question is: is there any other process to convert a user-defined Tablespace DB2's catalog from 4k cisize to 8k cisize ?
Putting in other words: supposing we find a Tablespace Catalog with LDS cisize of 4k, when it should be with 8k size, how can we convert it now?

Any help will be much appreciate !
Thanks

wanderer · Posted: Sat Apr 11, 2009 3:05 am

If that z-parm which allows ci size more than 4K is on and you have a tablespace in a bufferpool more than 4K, all you have to is reorg the tablespace and it should convert it to CI size larger than 4K.

Not sure how this works if you have a user defined dataset instead of DB2 defined. If the above doesn't work, there is an option in Define CLuster called CONTROLINTERVALSIZE. Can try that and test it.

Not sure what you mean by 'Tablespace Catalog'.

Xico Fino · New User Joined: 08 Apr 2009 Posts: 3 Location: Lisboa

Thank you for your help !

'Tablespace Catalog': I want to mean that is a DSNDB06 tablespace.

I made a new allocation using Define Cluster with CISIZE 8K, and then I tried to make a REPRO from de old file (4K) to the new one (8K).

The issue is that it returns a the following error msg:

REPRO INFILE(I) OUTFILE(O)
IDC3302I ACTION ERROR ON ...dsn file ...
IDC3351I ** VSAM I/O RETURN CODE IS 108 - RPLFDBWD = X'8508006C'

IDC0005I NUMBER OF RECORDS PROCESSED WAS 0

which means:
For a Logical I/O Error
108 The RECLEN specified was larger than the maximum allowed,
equal to 0, or smaller than the sum of the length and the
displacement of the key field of the base cluster or
related alternate index (AIX). The RECLEN was not equal to
the slot size specified for a relative record data set.

But I didn't specify any Record Length!!! (it´s a Linear Dataset), so I suppose REPRO won't be a good solution for that 'conversion'.

Does anyone have more ideas? Thanks in advance!

dick scherrer · Posted: Tue May 12, 2009 5:14 am

Hello,

Suggest you use only db2 utilities to work with db2 components. . .

Even if you get around the system now, something may fail at a later time and you will have a nightmare.

fwiw. . .

Have you opened an issue with db2 support?

wanderer · Posted: Tue May 12, 2009 10:55 pm

Since they are catalog datasets I guess they have to be user defined. I don't have experience in DB2 installation etc but I doubt REPRO is a good option here.

Reorg will be a better one. But trying to change CI size on catalog objects may not be a good idea. I wonder why you want to do that.

In our case, the z-parm change-reorg fix was suggested by IBM and I think they implicitly meant it to be valid for application object datasets, not catalog. Because I see our catalog datasets, some have CIsize 8k.

So contact IBM. But please tell us why you want to reduce Cisize.

Thanks!

Xico Fino · New User Joined: 08 Apr 2009 Posts: 3 Location: Lisboa

Hello,

First off all, I want to apologize for not giving any notice so far, but I’ve been very busy.

Regarding my issue:

1 - You all must be right: REPRO is not, in fact, a good ideia.

2 – As you suggest I’ll try to solve this issue with DB2 utilities, like REORG.

3 – I intend to do the follow ‘experience’ in a lab environment :

a) Run a REORG (SHRLEVEL REFERENCE) with UNLOAD PAUSE of that Tablespace.
b) When REORG finishes the UNLOAD phase, I’ll rename the old dataset (with CI 4K) and I'll make a new allocation with the proper name but with CI 8K.
c) Then, I’ll make a restart on REORG, and I suppose it will LOAD to this new dataset (8K) without problems. So I expect!

When I try it, I ‘ll give you feedback.

Thanks for your help !

dick scherrer · Posted: Tue May 19, 2009 11:42 pm

You're welcome - thanks for the update

Good luck,

d