Need help in estimating space of unload file

ashek15 · New User Joined: 20 Oct 2015 Posts: 48 Location: USA

Hi All

We need to unload a IMS database and we need to estimate the size of sequential data set(used for unload) by looking at the database size(which is basically a VSAM dataset) file. So, is there a way to estimate this given that sequential dataset has completely different format/organization from VSAM ones?

Robert Sample · Posted: Fri Apr 07, 2017 5:37 am

Have you tried running a LISTCAT on the VSAM data set? That should give you some idea about the number of records and the record length.

ashek15 · New User Joined: 20 Oct 2015 Posts: 48 Location: USA

Thanks for replying Robert. I tried running listcat on the VSAM and I believe you reffering to AVGLRECL and REC-TOTAL fields from the output. Am I right? Also i believe AVGLRECL is in bytes. Is that right?

ashek15 · New User Joined: 20 Oct 2015 Posts: 48 Location: USA

One more thing, I would like to share is that our ims database(i.e VSAM file) size is 2 gb, however when we unloaded the data, it got accommodated in 1 gb sequential file itself. So it seems there is no direct co-relation between VSAM and sequential data set. Please suggest on this.

Thanks.

steve-myers · Posted: Sat Apr 08, 2017 6:48 am

There is, but the relation is more complex.

Ignore everything in the ATTRIBUTES section of the listing. AVGLRECL, for example is nothing more than an estimate of the average LRECL when the data set was allocated. It may, or may not, have any meaning in reality. You don't know. The only statistic of value is MAXLRECL, and you only use it to define the LRECL of the dump data set.

In the ALLOCATION section, go to HI-U-RBA. Divide this byte count by 55996 to estimate tracks in your output data set. Most likely it will be high, but it's a start.

Now I'm no IMS DBA, but I believe just dumping the data data set is insufficient to put humpty back together. You want to discuss this with real IMS DBAs to find out proper way to dump and restore an IMS data base.

ashek15 · New User Joined: 20 Oct 2015 Posts: 48 Location: USA

I looked further into it but looks like AVGLRECL and MAXLRECL are same most of the times for datasets. Also could you pls advise how your arrive at figure of 55996 to calculate tracks? Thanks.

steve-myers · Posted: Mon Apr 10, 2017 6:14 am

The maximum BLKSIZE for system determined BLKSIZE is 27998 on a 3390. System determined BLKSIZE yields 2 records per track. 27998 * 2 = ?. OK?

ashek15 · New User Joined: 20 Oct 2015 Posts: 48 Location: USA

Thanks. Let me investigate more on this. will get back. Thanks.

don.leahy · Posted: Tue Apr 11, 2017 5:02 pm

Data bases contain a significant amount of free space in order to efficiently handle Inserts, so it is difficult to tell the Unload data set size by looking at the physical VSAM file. If you run a Reorg before your unload, the utility should produce a report of the number and size of each segment type.

Unload utilities typically add a prefix to each unloaded record that contains control information that is used if the data is loaded again. The size of the prefix can vary by data base type and the product that is used to unload it, but the size can be substantial enough that you would need to take it into account when you calculate the space requirements of the unload data set.

mucka · New User Joined: 11 Apr 2017 Posts: 5 Location: USA

This could be difficult to estimate. What kind of IMS DB. HIDAM adds to the ESDS front to back on dataset. It can however have free space. HDAM DBs are given space and the randomizer puts roots wherever they key randomized to. So if you look at a listcat no matter how many segments the report looks the same. Another issue is are your IMS segments compressed in the database? With some utilities you can leave them compressed when you reorg the DB but you can't read them. So you would have to unload them uncompressed or have a user written program. If no compression it is a simple task to find out how much space. Each segment has a defined length. Take that length and multiply by the number of that type of segments. Do that for each segment type and add them all together.

You asked a very simple question but the answer might not be simple.

mucka

ashek15 · New User Joined: 20 Oct 2015 Posts: 48 Location: USA

Thanks folks for sharing your inputs. I, however, further looked into it. This time I did not worry about VSAM vs seq file co-relation. Rather, took a different approach and I just got segment lenght of each segment type and multiply it with total segment numbers of each type and add them to get total data size. However, even this is not matching with sequential file size that was used for unload. Please suggest.

mucka · New User Joined: 11 Apr 2017 Posts: 5 Location: USA

What did you unload the DB with? Did you write a unload program, use an IMS unload utility, File-Aid for IMS/File Manager for IMS? Utilities can add prefix to each segment. Is the unload file compressed? When you say it is not matching with sequential file what does that imply? Is the unload file bigger than you think or smaller? If you unloaded the DB to a file why do you care how big it is? It is unloaded and you have the data for your use.

Please explain what your concern is.

mucka

enrico-sorichetti · Posted: Fri Apr 14, 2017 12:45 am

topic locked , getting nowhere trying to split the bytes