merging of KE files into a single SE file

pavankumarp · New User Joined: 13 Feb 2007 Posts: 12 Location: Hyderabad

i am merging 9 KE files into an SE file by using SYNCSORT

can anybody please advise how to calculate the space for that particular SE file..

Thanks

dick scherrer · Posted: Thu Feb 15, 2007 7:37 am

Hello,

Maybe i'm the only one in the forum who isn't familiar with KE and SE files. Please explain what they are.

Unless they are allocated/stored in some unique way, the merged file will take the same or less space than the total of the 9 originals (if you keep the same blocksize).

William Thompson · Posted: Thu Feb 15, 2007 2:11 pm

No Dick, I thought I was.....

pavankumarp · New User Joined: 13 Feb 2007 Posts: 12 Location: Hyderabad

Hi Dick,

the 9 Ke files have been allocated with the space cyl(150,150) with around 10 volumes for each of them on an average.

the Se file into which it is getting merged has been defined with 250,500 with around 20 volumes.

we do have sufficient space in the region.

but i would know like the optimum space that is required for that particular SE file. could you please help me on this

prav_06 · Posted: Fri Feb 16, 2007 12:04 pm

Pavan,

Please explain what is a SE and KE file , u say Sequential file as SE or wat is the full form man....

Cheer's,

Thamilzan.

pavankumarp · New User Joined: 13 Feb 2007 Posts: 12 Location: Hyderabad

ohh sorry

9 vsam files getting mergerd into an Sequential file

William Thompson · Posted: Fri Feb 16, 2007 1:57 pm

Pull a listcat on the 9 KE files, add the hiused values, divide by track size and that should give you a starting point.

dick scherrer · Posted: Fri Feb 16, 2007 8:54 pm

Hi Pavan,

How will the sequential file be used? For some one-time processes or be available for regularly scheduled jobs. Is the plan such that it would always be online and available (except when it is being rebuilt)?

Are the 90 (if i understood correctly) volumes near full or is there a large amount of unused space? If they are even 1/2 full that would be 45 volumes (depending on how much of the 90 volumes is index space). What kind of calculation was used to determine "20 volumes"?

When you are calculating how much space for the qsam file, you will not need to consider the index space.

As far as optimum, i'd suggest taking a representative sample of the data from one of the vsam files and copy it to a qsam file with a block size of zero and see what blksize the system chooses. Once you know what your system considers to be a good blkzise, you can follow Bill's suggestion and determine what you need to allocate. Once you have a number, plan on maybe 10% extra (just in case). When you actually run the copy job it will be better to ask for more space than you calculate (using RLSE to give back what you don't need) rather than to under allocate and get an x37.

Copying that much data to a qsam file will take a while, but will be faster than copying from qsam to vsam. . . .

Good luck

pavankumarp · New User Joined: 13 Feb 2007 Posts: 12 Location: Hyderabad

hi dick,
thanks for your inputs..will try it out

Regards,
Pavan.

dick scherrer · Posted: Tue Feb 20, 2007 1:23 am

Good luck - let us know how it goes & maybe how much dasd space was eventually allocated/used