On Sun, 13 Dec 2020 16:37:55 +0000, "Jeff Bassett"
<bassettj@...> wrote:
Hi Jeff,
Some few questions if you allow me. (Warning! Absolute noob here!)
If I do understand the blocking reasoning, all these starts from
thinking that one is willing to write a large amount of data. If the
task at hand handles small amount of data that won't fit one large
block, the smaller blocksize can make a better use of the disk space.
Am I correct in think this way?
An example embedding a question, in a "CNTL" dataset, usually a PDS,
JOBs are small texts that many times wont fill a single average block,
a 115 cards deck will fill about 9KiB. The question, does in a PDS a
physical can be shared by different members? If not, a JOB deck with
a jobcard and few jobsteps will hardly fill a single block, (almost)
regardless the blocksize.
Ok, my point (if any) is like you said YMMV. The best blocksize will
mostly depend on what kind of information is being stored. Although
the simple math points to those numbers, perhaps knowing the data
content can make a better use of the tracks if one considers the block
fill by data contents.
HTH
Patrik,
Remember in the previous posts - each block has some amount of
overhead. So - to have the absolute BEST utilization - you want the
fewest number of blocks per track.
Now, blocks are addressed in a half-word - Max 32767 - so - using the
DISK capacity table - (there is also a command for each type in the
TK4- system To help you calculate the BEST block size on a GIVEN
track size (since we have multiple DASD TYPES ) -from TSO command -
type TSO HELP BLKSPTRK
The actual programs are in SYS2.CMDLIB
BLKSPTRK (devtype devtype ...)
BLKSIZE(<size or #count> <size or #count> ...)
KEYLEN(length length ...)
Or there is also another set of pgms
BLKxxxxx (look in sys2.cmdlib)
For instance BLK3390
So for a GIVEN record size - and DASD type - there are optimum block
sized - to use the space most effectively.
For instance - if you are using 80 byte records - or card images...
you have seen the calculations... however, lets say you want to store
some PRINT OUTS - that are LRECL 133 (these are really 132 bytes -
plus a 1 byte Carriage control in the first byte ) OR - certain OLDER
UTILITIES - when they were originally written to OLDER standards -
and use LRECL 121 - OR - you might have LONGER print records - 3211s
were capable of 150 character lines with a smaller type face - (I.E -
what I am trying to point out - YOUR MILEAGE MAY VARY - just because
it is PRINT RECORDS) - Here are a couple of examples - The trick is
to know - the LENGTH of the LRECL - and the TYPE of disk you are
using... This is why occasionally you see things - like - HAD to
REBLOCK for 3350 -
I used BLK3390 133 to produce the following -table
3390 BLOCKSIZE SUMMARY; LRECL=133 KEY LENGTH=0
BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION
--------- ------------ ------------ -----------
133 72 72 16.9%
2,926 16 352 82.6%
3,059 15 345 81.0%
3,325 14 350 82.2%
3,724 13 364 85.4%
4,123 12 372 87.3%
4,522 11 374 87.8%
5,054 10 380 89.2%
5,719 9 387 90.8%
6,517 8 392 92.0%
7,448 7 392 92.0%
8,778 6 396 92.9%
10,773 5 405 95.1%
13,566 4 408 95.8%
18,354 3 414 97.2%
RECOMMENDED-->27,930 2 420 98.6%
32,718 1 246 57.7%
FOR BLKSIZE 27,930 AND 100,000 RECORDS, ALLOCATE:
477 BLOCKS, 239 TRACKS, OR 16 CYLINDERS
***
So, you can do the arithmetic - or use tools - already provided -
clearly it helps to understand what the tools do...
Now here is a similar table generated by BLK3380 133
3380 BLOCKSIZE SUMMARY; LRECL=133 KEY LENGTH=0
BLOCKSIZE BLOCKS/TRACK LRECLS/TRACK UTILIZATION
--------- ------------ ------------ -----------
133 74 74 20.7%
2,394 16 288 80.7%
2,660 15 300 84.0%
2,926 14 308 86.3%
3,059 13 299 83.8%
3,458 12 312 87.4%
3,857 11 319 89.4%
4,256 10 320 89.6%
4,788 9 324 90.8%
5,453 8 328 91.9%
6,251 7 329 92.2%
7,448 6 336 94.1%
9,044 5 340 95.2%
11,438 4 344 96.4%
15,428 3 348 97.5%
RECOMMENDED-->23,408 2 352 98.6%
32,718 1 246 68.9%
FOR BLKSIZE 23,408 AND 100,000 RECORDS, ALLOCATE:
569 BLOCKS, 285 TRACKS, OR 19 CYLINDERS
***
I hope this is helpful.
-J-
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Patrik
Schindler Sent: Sunday, December 13, 2020 10:40 AM
To: [email protected]
Subject: [Marketing Mail] Re: [H390-MVS] Show disk usage in TK4-
Hello Joe,
Am 06.12.2020 um 00:30 schrieb Joe Monk <joemonk64@...>:
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...
Thanks. Q: Can you elaborate on ?efficient dasd usage mandates
half-track blocking¡°? Why not more? Or less? What¡¯s the reason behind
?³Ù·É´Ç¡°?
:wq! PoC
Roxo
--
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <mvs@...> | Editor?
Except where explicitly stated I speak on my own behalf.| VI !!
PU5RXO | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!
