View previous topic :: View next topic
|
Author |
Message |
bbessa
New User
Joined: 03 Aug 2006 Posts: 13 Location: Brazil
|
|
|
|
Hello guys,
I've running into a problem here at work while trying to copy 16 GB sized tablespace partitions using DSN1COPY. The target dataset can't pass the 2 GB size mark for some odd reason, when it reaches that mark, DSN1COPY stops with "VSAM PUT ERROR RPLERREG = 008, RPLERRCD = 028" message. Doing a search over the Internet, I've came across the IBM documentation that specifies the limits to DSN1COPY and it clearly says that the utility can't copy datasets over 4GB UNLESS the target dataset is EA-Enabled. Guess what, the target and source datasets are EA-Enabled and I'm still getting errors. I don't know what I am doing wrong here. We've enough volumes with contiguous free space to hold the target dataset, volume count in the SMS DATACLASS is set to 10, target dataset is EA-enabled and I've tried all sorts of values in the DSSIZE parameter of DSN1COPY. Am I missing something? Can anyone help?
Thanks!
Bernardo |
|
Back to top |
|
|
bbessa
New User
Joined: 03 Aug 2006 Posts: 13 Location: Brazil
|
|
|
|
OK. Here's the workaround: I've changed the tablespace's PRIQTY value to fit exactly one volume, not 1 and half as before. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello bbessa and welcome to the forums,
Thank you for posting your resolution
d.sch. |
|
Back to top |
|
|
bbessa
New User
Joined: 03 Aug 2006 Posts: 13 Location: Brazil
|
|
|
|
The posted workaround didn't work for much time. We had another failed copy on a index with another set of storage parameters. So I did a little more research and came up with the cause to dsn1copy problem. DB2v8 for z/OS has the zparm MGEXTSZ that, when set to YES, makes DB2 uses some kind of automated space management for your index and table spaces even if you manually define your SECQTY values. It's seems that DB2 was choosing odd values (can't verify this though) for SECQTY while the index was growing thus making dsn1copy fail. We've put the zparm back to it's default value, NO, re-created the index and everything worked flawless.
It's seems MGEXTSZ is not really a good parameter to use if you know your storage very well. Does anyone have good experiences with this zparm to share? |
|
Back to top |
|
|
|