View previous topic :: View next topic
|
Author |
Message |
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? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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. |
|
Back to top |
|
|
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? |
|
Back to top |
|
|
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. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
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. |
|
Back to top |
|
|
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. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
The maximum BLKSIZE for system determined BLKSIZE is 27998 on a 3390. System determined BLKSIZE yields 2 records per track. 27998 * 2 = ?. OK? |
|
Back to top |
|
|
ashek15
New User
Joined: 20 Oct 2015 Posts: 48 Location: USA
|
|
|
|
Thanks. Let me investigate more on this. will get back. Thanks. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
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. |
|
Back to top |
|
|
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 |
|
Back to top |
|
|
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. |
|
Back to top |
|
|
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 |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
topic locked , getting nowhere trying to split the bytes |
|
Back to top |
|
|
|