IBM Mainframe Forum

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.

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 -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.

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)



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 ?

No, you're not missing anything. Consider 003D0007 to 003D0007. It's obviously 1 track, but you do the subtraction you get 0 tracks.

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.

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.

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

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 -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.

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 )

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.