开云体育

"1) With RECFM=FB, the block's size must be a multiple of the record length. Plainly 28332
isn't a multiple of 80."

a 3390-1 has a tracksize of 56,664.

56664 / 80 = 708 records per track. 354 records per half-track. half-track is 28320, so i was off by 12 bytes on the blocksize.

my bad.

Joe

On Sun, Dec 6, 2020 at 5:38 AM <jacampbellaus@...> wrote:

DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)

nope.

Two things:

1) With RECFM=FB, the block's size must be a multiple of the record length. Plainly 28332
isn't a multiple of 80.

2) There are overheads in a block. In a Count-Key-Data disk type (such as a 3390), a data
block is preceeded by a count block and (possibly) a key block. In a physical 3390 blocks
are (were) stored in sets of 32 bytes (? so long since I've needed to know) - which includes
ECC data.

So each of these three block types takes a multiple of 32 bytes. While a count block is 5
bytes long (fwiw, 1 byte for record's number on track, 2 bytes for the length of the key block
(obviously zero if unkeyed) and two bytes for the length of the data block) it still consumes 32
bytes on the track.

In addition there are inter block gaps - in a 3390, each a multiple of 32 bytes. Both between
the count, key and data blocks and between sets of CKD blocks. I forget their sizes.


has actual maximum block size at various blocks per track values. The maximum block size
to store 2 blocks per track is 27998. Any size larger means one block per track, and any size
larger than 32760 requires low level access techniques.

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)

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.

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

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.

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 .

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.


James Campbell




On 5 Dec 2020 at 17:30, Joe Monk wrote:

Patrik,

Youre conflating a couple of concepts.

1 is LRECL - this is the size of 1 record
2 is BLKSIZE - this is the size of 1 block

The only reason we care about bytes in the mainframe world is for blocking
factor, how many records can I fit in 1 block, which can fit on a track?
So, we only care about the number of bytes per track for that reason. A track
is always a fixed number of bytes. A cylinder is ALWAYS 15 tracks.

Example: on a 3390, a track is 56,664 bytes. If I have 80 byte fixed
records, then I can fit 708 records on a track. BUT - when using QSAM,
efficient dasd usage mandates half-track blocking, or 1 block should be
about 28,332 bytes. This means 1 block should be about 354 records...

So in JCL:

DD DCB=(LRECL=80,BLSKIZE=28332,RECFM=FB)

Joe

On Sat, Dec 5, 2020 at 4:42 PM Patrik Schindler <poc@...> wrote:

Hello Jay,

Am 05.12.2020 um 22:32 schrieb Jay Moseley <JayMoseley@...>:

Take a look at

Thanks a lot, will do and report back. From the sample output, it?s not
too helpful for a rookie like me: I don?t yet have a feeling (or better:
deep understanding) for juggling with cylinders and tracks. I?m used to
bytes, but isn?t the size (in byte) per track device dependent?

Maybe an additional column with percentage-used would be more helpful for
a first glance? I?ll see if I could bring this thing into TK4-, and maybe I
can enhance the source. Tomorrow. Here?s nearly midnight...

:wq! PoC

--
This email has been checked for viruses by AVG.