Page 1 of 2

Calculate Non-vsam space

PostPosted: Fri May 13, 2011 7:07 pm
by sensuixel
Hello,

I'm working on a program which calculate the number of tracks occupied by non-vsam files (to begin i assume that none of the file is extended
or multi-volume).

My input is a list of file + the volser of each file.

I use both of it to read the Format-1 DSCB, but how to calculate the total of tracks occupied by the non-vsam ?

The FMT-1 gives me the TTR (DS1LSTAR field) but the result is not as precise as the one i get by performing a DSList or browsing
ISMF.

I know i could use either a DCOLLECT or an IEHLIST to get the info but I'm trying to do it using VTOC.

Re: Calculate Non-vsam space

PostPosted: Fri May 13, 2011 8:07 pm
by steve-myers
DS1LSTAR is pretty accurate since it defines the resume point for DISP=MOD. The problem is it does not tell you allocated space, which is actually pretty involved since you have to translate extent data in DS1EXTx and DS3EXTx to allocated space, and you have to do this for each allocated extent.

Translate the CCHH values in DSxEXTx to a track from track 0, then subtract the starting track from the ending track to get the tracks in the extent. For example. in this dataset we have -
F1 C6E4E2D9F1C5 0001 6E00E5 000000 02 00 00 C9C2D4D6E2E5E2F24040404040   
6F0083A0000000 0200 90 00 6D10 0050 00 0000 82 C0000001 001E03 4532 0000
81000DAC00000DAD000E 81010FF400000FF4000E 00000000000000000000 0000000000
The first extent is from CCHH 0DAC0000 to CCHH 0DAD000E, or track 52500 to track 52529. That's 30 tracks. You can do the second extent yourself. The dump of the data area of the format 1 DSCB is from the TSO LISTDS command with the LABEL option.

Re: Calculate Non-vsam space

PostPosted: Fri May 13, 2011 9:00 pm
by sensuixel
Thanks for your answer, I just made a try on one of my file which has only one extent, here is the FMT1 DSCB gotten
via TSO LISTDS with LABEL option ( I didn't know this useful command so thank you)

--FORMAT 1 DSCB--                                                         
F1 D9C5C3F2F0F2 0001 6F0077 000000 01 00 10 C9C2D4D6E2E5E2F24040404040   
6F008500801810 4000 90 00 1810 008C 00 0000 80 50000111 001E05 7128 0000 
0100003D0007003F0007 00000000000000000000 00000000000000000000 0000000000


Lower limit CCHH = 00 3D / 00 07
Higher limit CCHH = 00 3F / 00 07


So after translation i get :

- Tracks 922 to tracks 952 so i assume that my file takes 30 tracks.

But when I perform a LISTDS I get 31, am I missing something ?

Re: Calculate Non-vsam space

PostPosted: Fri May 13, 2011 9:14 pm
by steve-myers
No, you're not missing anything. Consider 003D0007 to 003D0007. It's obviously 1 track, but you do the subtraction you get 0 tracks.

Re: Calculate Non-vsam space

PostPosted: Fri May 13, 2011 9:15 pm
by Akatsukami
sensuixel wrote:So after translation i get :

- Tracks 922 to tracks 952 so i assume that my file takes 30 tracks.

But when I perform a LISTDS I get 31, am I missing something ?

Remember the difference between a point and an object of finite size.

Re: Calculate Non-vsam space

PostPosted: Sat May 14, 2011 12:42 am
by sensuixel
Akatsukami wrote:Remember the difference between a point and an object of finite size.


You're way to represent it is really clear, i got it.

Re: Calculate Non-vsam space

PostPosted: Sat May 14, 2011 11:17 am
by enrico-sorichetti
any reason to reinvent the wheel?
using DCOLLECT and processing the output will be much more <cost> effective
both from the data collecting and reporting points of view
using DCOLLECT will put on IBM the burden of keeping things aligned ( software/hardware)

see the DFSORT samples from ibm
here http://www-01.ibm.com/support/docview.w ... g3T7000081

and the rexx samples from the cbt tape!
here
http://www.cbttape.org/cbtdowns.htm
and look for
file # 206 DCOLLECT REXX execs from Linnea Nichols

both approaches work well

but it looks like there is a communication gap in Your organization
periodical dasd/dataset accounting/statistics has always been in place
and DCOLLECT has been there alive an kicking for at least 15 years
so why not look at what Your storage people have been doing

Re: Calculate Non-vsam space

PostPosted: Sun May 15, 2011 5:52 am
by steve-myers
When I first read enrico-sorichetti's post I thought to disagree with it. DCOLLECT can be hard to collect since it involves IDCAMS, and it may not be vwry helpful since sensuixel is using his own list, which I gather he is creating using IGGCSI, which can be orders of magnitude quicker than IDCAMS, at least if he is collecting lists of datasets. Granted sensuixel is recreating the wheel, and he will find it painful for datasets like this one -
--FORMAT 1 DSCB--
F1 C6E4E2D9F1F1 0001 6E0063 000000 08 00 00 C9C2D4D6E2E5E2F24040404040
6F008680000000 0200 90 00 1810 0050 00 0000 82 80000001 000704 C35E 0000
0100001D000C001D000C 0101010D000C010D000C 01020095000E0095000E 0002000827
--FORMAT 3 DSCB--
03030303 0103001D0002001D0002 010400F9000E00F9000E 01050100000A0100000A
01060092000500920005 F3 01070071000900710009 00000000000000000000
00000000000000000000 00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000 0000000000000000000
00000000000000000000 0000000000
sensuixel has to process the three extent entries in the Format 1 DSCB, acquire the Format 3 DSCB, process the four extent entries in the key area of the Format 3 DSCB, and any remaining extent entries in the data area of the Format 3 DSCB. If the dataset has more than 16 extents, possible for SMS managed datasets, he has to acquire the next Format 3 DSCB and continue the process. Just to add more insult, and sensuixel may not know this, if the dataset is allocated in the cylinder managed area of an "extended attribute" volume, he will be dealing with different format extent areas in different DSCBs he will have to acquire using a new parameter in the OBTAIN/CAMLST macros. Unstated here, sensuixel also has to acquire the number of tracks/cylinder in the volume; it is not safe to simply use 15. So it can get unpleasant.

Actually, while the new parameter exists in both the OBTAIN and CAMLST macros, it is really just in the CAMLST macro; if the new parameter is specified in the OBTAIN macro, it just sets the flag in the CAMLST macro.

Re: Calculate Non-vsam space

PostPosted: Thu May 26, 2011 11:28 pm
by sensuixel
We already gather all the statistics we need by parsing the result of a DCOLLECT with PL/I or rexx or using DFSORT.

I try to get the same result using IGGCSI essentially for a matter
of performance and agility since the wild characters of IGCCSI really come in handy (and also to improve my Assembler's skills ;) )

It's more a challenge to me than a real issue to my organization.

And I confirm, files with more than 16 extents are giving me hard time, but this subject lead mo to code my first macro, use TRKCALC, OBTAIN, channel programming and so
on ... so it's a real positive experience to me.

And thanks to this forum and all the precious advices you gave me my progam keeps on growing (one problem at a time ;) )

Re: Calculate Non-vsam space

PostPosted: Fri May 27, 2011 2:13 am
by steve-myers
sensuixel wrote:... And I confirm, files with more than 16 extents are giving me hard time, ...
Datasets with more than 3 extents start to be painful since you have to read a Format 3 DSCB. More than 16 extents isn't much more painful since all you have to do is read more Format 3 DSCBs. Once you can process the extent entries in the first Format 3 DSCB, processing more of them shouldn't present an overwhelming problem.