Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Storage Experts: coding BLKSIZE in JCL really not good?

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
space_admin

New User


Joined: 04 Apr 2006
Posts: 7

PostPosted: Tue Apr 04, 2006 3:29 pm    Post subject: Storage Experts: coding BLKSIZE in JCL really not good?
Reply with quote

Hello together,

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

icon_confused.gif

Please help, I am looking forward to your answer.

Thanks in advance,

space_admin
Back to top
View user's profile Send private message

martin9

Active User


Joined: 01 Mar 2006
Posts: 287
Location: Basel, Switzerland

PostPosted: Tue Apr 04, 2006 7:57 pm    Post subject:
Reply with quote

hy space_admin,

do you really have 6.5 terabytes on dasd?????

are you sure you need that much data always accessible?

i think the best optimization is the relocate that data on tape,
or just delete it.

if you have a fb file, blksize must be a multiple of lrecl...
i.e. blksize=3120 lrecl=80

if you have a vb file, just give the maximum possible blksize
i.e. blksize=27998 lrecl=1500

if you need to release the over allocated space amount,
give in the SPACE=(unit,(prim,sec,dirblk),RLSE)

martin9
Back to top
View user's profile Send private message
space_admin

New User


Joined: 04 Apr 2006
Posts: 7

PostPosted: Tue Apr 04, 2006 8:55 pm    Post subject:
Reply with quote

hi martin9,

yes 6.5 TB under sms, but at all...? Tape are much more and without deleting work data every day nothing won't go! icon_wink.gif

With the optimum blocksize I hope to get about 70 GB free icon_rolleyes.gif

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???? icon_confused.gif
Back to top
View user's profile Send private message
martin9

Active User


Joined: 01 Mar 2006
Posts: 287
Location: Basel, Switzerland

PostPosted: Tue Apr 04, 2006 9:09 pm    Post subject:
Reply with quote

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.

martin9
Back to top
View user's profile Send private message
space_admin

New User


Joined: 04 Apr 2006
Posts: 7

PostPosted: Wed Apr 05, 2006 4:54 pm    Post subject:
Reply with quote

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?
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Thu Apr 06, 2006 4:19 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
space_admin

New User


Joined: 04 Apr 2006
Posts: 7

PostPosted: Wed Apr 12, 2006 5:19 pm    Post subject: Re: Storage Experts: coding BLKSIZE in JCL really not good?
Reply with quote

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?
Back to top
View user's profile Send private message
martin9

Active User


Joined: 01 Mar 2006
Posts: 287
Location: Basel, Switzerland

PostPosted: Wed Apr 12, 2006 7:06 pm    Post subject:
Reply with quote

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

martin9
Back to top
View user's profile Send private message
space_admin

New User


Joined: 04 Apr 2006
Posts: 7

PostPosted: Thu Apr 13, 2006 1:22 pm    Post subject: Re: Storage Experts: coding BLKSIZE in JCL really not good?
Reply with quote

hi martin9,

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?
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Allocate dataset withour BLKSIZE Susanta CLIST & REXX 2 Thu Sep 22, 2016 11:51 am
No new posts How storage is calculated for AN-Edit... Raghu navaikulam COBOL Programming 2 Wed Mar 09, 2016 3:51 pm
No new posts How can amount of the Storage Usage b... esduman61 CICS 6 Wed Mar 09, 2016 1:19 pm
No new posts CEE0813S Insufficient storage was ava... kishpra COBOL Programming 18 Mon Nov 09, 2015 8:37 pm
No new posts Insufficient Storage issue while exec... rexx77 JCL & VSAM 4 Fri Jul 10, 2015 10:29 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us