Hello,
Am 06.12.2020 um 06:39 schrieb jacampbellaus@...
So 27998 is the largest realistic block size for most purposes. Rounding down to a multiple
of 80 bytes gives
DCB=(LRECL=80,BLSKIZE=27920,RECFM=FB)
Thanks for that explanation. I¡¯m glad to see that in the end, bytes are what really counts, even on MVS. Cylinder and track calculations appear to be a relict from the limited hardware of yesteryears, requiring (?) an unload of these to the user instead of the CPU.
In addition, taking some other things from this thread, in MVS type systems,
- data sets are allocated in, at a minimum, units of tracks. A one byte data set consumes at
least a whole track.
Now, that is what I call a solid basic information! Q: Is a track comparable to a sector in conventional disks? How do blocks fit into this picture? What about physical vs. logical block sizes?
- data sets are allocated in extents - which can range in size from a track to an entire disk.
Once a track is allocated to a dataset, it is not available to another dataset.
Sounds logical to me.
If you are looking at 'how full is a disk', you really need to look at two things:
- how many tracks are allocated to a dataset
- how much of each dataset's allocation is actually occupied by data. My recollection of Linux
and Windows is that unused space within a file's allocation is going to be somewhat less than
1 KB. In MVS is an be an entire disk.
Yes and no. Allocated tracks are not free, and as far as I understand, the free tracks count is what matters. Correct?
How much of each dataset's allocation is actually occupied by data is more of a ?how efficient is data stored¡°, expressed as overhead for preallocated tracks. I don¡¯t care about this. What¡¯s more, I guess to find out this ?empty space within datasets¡° within the countless DS¡¯s on a system could be tedious.
You might also find IEHLIST of use.
/iehlist.htm
((plain) MVS's version is much the same.) One advantage it seems to have is that it can
provide each data set's "LAST BLK(TTTT-R)" - that is you can calculate how much of the
data set's allocation is, in fact, unused .
Thanks for that hint!
Obviously, as others have mentioned, this, as with IBHLSPAC, is the 'logical' space inside
the disk. If the track is compressed, it doesn't relate to how much space each track
consumes in the hosting Linux/Windows environment. An allocated track full of zeros takes
less space than a 'free' track full of random stuff left over from when it was used.
This ?others¡° was me. ;-)
Thanks a lot! I¡¯m much closer to my goal now! And I had some ?aha¡° while reading your explanations.
:wq! PoC
