开云体育

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Mike Schwab
Sent: Sunday, December 6, 2020 11:45 AM
To: [email protected]
Subject: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-

The track is the empty disk space. The blocksize is the physical block. VSAM writes Control Intervals (blocks) in multiples ofr 512, up to 4096. Larger control intervals are possible but are broken down into these physical blocks since they don't result in higher space utilization. VSAM files are often used for applications where you want to update records in place.

Non VSAM datasets you get to choose the physical block size. .Short blocks can be created at the end of a dataset when you close. Updates in place are permitted only if you don't change the length of the block.

Load modules are very, very interesting. First it is a PDS, so you have a PDS directory consisting of Key length 8 block size 256 containing 3 to 7 membernames and a pointer to the data, and empty names to fill the number of requested blocks. Then you have the eof record for the directory, which allows reading the directory as DSORG=PS file. After that you have the members. TXT records for the header, I think they are 80 bytes. Then a 8 bytes control record to read the next block. The actual load module block is then a multiple of 1024 bytes up to the remaining space on the track or the specified blocksize. These two records repeat until the end of the member.
Writing a member is always to the end. Replacing a member is writing the new contents to the end and the old contents no longer have a reference. Compression is then accomplished by skipping to the first unreferenced area, then moving the next member forward and repeating to the end.

Advance Function Printing (AFP) libraries are optimized with an 18K blocksize.

On Sun, Dec 6, 2020 at 6:30 AM Patrik Schindler <poc@...> wrote:

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.
.
zos.v2r4.idau100
/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

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?