In our installation (round about 6 and a half TB) we want to optimize the allocated space. In this case we want to optimize the BLKSIZE, I have some general considerations to this subject (according to G.D. Brown):
The perfect BLKSIZE is given by the system according to the used I/O-unit, so it is obsolete or NOT GOOD to specify it.
But is it ok when a lot of Datasets (RECFM=FB and VB) have a BLKSIZE of over 27998 Bytes? What is to said against this Blocksize in comparison to 32760 Bytes? (ok less cpu)
I think in general a BLKSIZE over 27998 is off-target, when I have no longer logical records!
Order:
1. DCB from program instruction
2. DCB from JCL
3. DCB from file
If the program does specify the DCB but no blocksize, would the BLKSIZE jcl parm be honored?
When I code BLKSIZE=0 in my opinion the blocksize should not be over 27998!
Why is there a limit of 32760 and not 27998, what is the reason of using 32760 or other size over 27998 ???
yes 6.5 TB under sms, but at all...? Tape are much more and without deleting work data every day nothing won't go!
With the optimum blocksize I hope to get about 70 GB free
thanks for your help, I think I get the solution --> the parm BLKSIZE=0 results in bigger blocksize than half track, because of DCB-order:
3. DCB from file
Quote:
if you have a vb file, just give the maximum possible blksize
i.e. blksize=27998 lrecl=1500
Why do you say the maximum possible blksize is 27998, can it be limited in any way?
I can set a limit at 32760 in sms, that is too high.
to all specialists: please provide the answers! Where does the big blocksize comes from????
Joined: 01 Mar 2006 Posts: 290 Location: Basel, Switzerland
hy space_admin,
i don't say 27998 is the max possible blksize,
this was just an example...
if you know which is the longest record possible,
you can also make smaller blksizes, but if not
give the max possible to avoid any problems
while running.... (vb-files)
...manual...
Syntax
BLKSIZE= {value}
{valueK}
{valueM}
{valueG}
Subparameter Definition
value
Specifies the maximum length, in bytes, of a block.
The number of bytes that you specify for BLKSIZE depends on the
device type and the record format for the data set. The maximum
is 32760 for DASD data sets and 2,147,483,648 for tape or DUMMY
data sets, except for data sets on magnetic tape with ISO/ANSI
version 3 labels, where the minimum value for BLKSIZE is 18 bytes
and the maximum is 2048 bytes. To allow a block size greater than
2048, use installation exit routine IFG0193G. Version 4 labels do
not have this restriction but is 2,760 for DASD, ISO/ANSI Version 4
tape labels, and other data sets.
valueK
Specifies the maximum length, in kilobytes, of a block.
(1 kilobyte = 1024 bytes.) The maximum is 2097152. If you code
2097152K, the blocksize is the maximum; 2,147,483,648 bytes.
valueM
Specifies the maximum length, in megabytes, of a block.
(1 megabyte = 1024 kilobytes.) The maximum is 2048. If you code
2048M, the block size is the maximum; 2,147,483,648 bytes.
valueG
Specifies the maximum length, in gigabytes, of a block.
(1 gigabyte = 1024 megabytes.) The maximum is 2G. If you code 2G,
the blocksize assigned is the maximum; 2,147,483,648 bytes.
With recfm=VB the LRECL is average, I think. Can I not be sure that the LRECL is always smaller than the block, except I code recfm=VBS?
that all seems very interesting... fortunately I only have to manage DASD. Are there any other DASD types then 3390 in the z/OS environment?
We have only 3390 and with this consideration a blocksize with over 27998 only makes sense if the logical records are longer and the system does not allow spanned records. For the space needs those blocksizes are inefficient.
To avoid those blocksizes:
Order:
1. DCB from program instruction
2. DCB from JCL
3. DCB from file
1.) If the program gives a blocksize, the JCL blksize=27998 will not be honored, so do dcb from file.
2.) If the program gives no blocksize, the size 27998 will be honored, but file not.
File blocksize is not important, only LRECL is, or not? 2 cases:
a.) FB: blocksize must be a multiple of LRECL
b.) VB: blocksize can always be 27998 except of longer records, then it have to be VBS.
This f****** recommendation of IBM to give no blksize doesn't make any sense, the size is then always at 32760. I think this recommendation is for end user, this size is sure.
In this context:
Which size is the biggest logical record in VB?
AS I recall blksize=0 and SMS blocking uses half track blocking as optimal. That may change as track capacities continue to increase.
I don't understand why the blksize is always 27K in your shop, as the blksize has to be a multiple of the lrecl. Maybe I misunderstood.
Using blksize=0 zero or letting SMS do it seems a wise choice. You'll be glad you did when you migrate to IBM's latest and greatest. The system does the recalcs for you.
You misunderstand, the BLKSIZE is often bigger than 27998 bytes and I don't understand why (not only in my shop). When you show the order, you will see why:
1. DCB from program instruction no given
2. DCB from JCL =0
3. DCB from file set to > 27998
This is the Common Recall Queue of which you're talking about? Is it necessary to go to newest DFSMS Version?
Joined: 01 Mar 2006 Posts: 290 Location: Basel, Switzerland
hy space_admin,
at my site, DFSMS is configured in a way,
that it is not necessary to give blksize for FB.
DFSMS calculates the optimum blksize for us.
if the file is VB, we have to give the blksize.
if we know the longest possible lrecl, we can give
a multiple of lrecl as blksize, if we do not, we give
the maximum blksize...
I've never said it is necessary to code blksize, but sometimes better:
What do you do if DFSMS calculates a blksize over 27998 bytes for any reason? Don't you have any Dasd dataset with a blocksize over 27998 bytes under DFSMS?? I can't imagine!
And then: What is the reason for this blksize in the 3390 dasd???
(except of program definition)
And why DON'T code blksize in JCL ???
(except of the reason that it is more work.)
Quote:
if the file is VB, we have to give the blksize.
if we know the longest possible lrecl, we can give
a multiple of lrecl as blksize, if we do not, we give
the maximum blksize...
You can also give a blksize = LRECL + 4 at VB files.
How do you find the size of the longest possible record?