MVSFORUMS.com

[kolusu]

A 3390-n device has a capacity of 56,664 bytes per track,of which 55,996 bytes are accessible by applications programmers.

The largest blocksize you can define is 32,760, which is good for tapes,but it is mere waste on DASD, as 55,996 - 32760 = 23,236 bytes left over,and because tracks can't be shared between other files, that leftover space would just be wasted.

So,55,996/2=27,998,which is half-track blocking,the most space-efficient blocksize to use on 3390's.If you have 3380 devicetypes in your shop, the maximum half-track blocksize is 23,476.

To calculate the most efficient blocksize to use:
bestblocksize = INTEGER(half-track-blocksize/LRECL)*LRECL

In your case the lrecl is 500, so the best blocksize will be

Integer(27,998/500) is 55

55 multiplied by lrecl(500) gives you 27500 which is the optimum blksize.

On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file of record length 500 is 27,500.This will allow 55 records per block, or 110 records per track, or 1650 records per cylinder (cylinders are 15 tracks).

Since the volume of records you have is 10,000, you can fit that data in less than 7 cylinders(10,000/1650 = 6.06 rounded to 7)

So we allocate the primary space as 7 cylinders. Now the secondary space allocation is 20% of primary space
which in this case is 7 * 0.2 = 1.4 rounded to 2

So basically your space allocation for a dataset of lrecl 500 and a volume of 10,000 records would be

[blueash]

Though its theoritical and there may be other optimizations also based on I/O speeds,
lets see this example.

LRECL=4000, Records=100,000, Optimum blksize comes out to be=24,000
=> 12 records/cylinder => 8334 cylinders to store this file.

Now if you make BLKSIZE=4000, there would be 13 records/cylinder
=> 7693 cylinders to store the same file.

Means 641 less cylinders(8% less space)

Any thoughts what blocksize system will give when we give blksize=0 for this file.

Thanks.

[kolusu]

Blueash,

You had the calculations wrong.Let me explain it crealy once again for you.

Lrecl=4000 ;Max no: of records = 100,000

27,998,which is half-track blocking,the most space-efficient blocksize to use on 3390's

To calculate the most efficient blocksize to use:
bestblocksize = INTEGER(half-track-blocksize/LRECL)*LRECL

In your case it is

INTEGER(27998/4000) = 6

So the optimal blocksize = 6 * 4000 = 24000

On a 3390, the best blocksize for a QSAM (Queued Sequential Access Mode) file of record length 4000 is 24,000.This will allow 6 records per block, or 12 records per track, or 180 records per cylinder (cylinders are 15 tracks).

So for 100,000 records it is only 556 cylinders

By making the blocksize 4000 you are writting only 1 record per block and 2 records per track and 30 records per cylinder

so for 100,000 records it 3334 cylinders which is 600% increase.

Fyi... If you code blksize=0 for this file you will get a system determined blocksize of 24000.

Hope this helps...

cheers

kolusu

[RonB]

The most efficient blocksize for 3390 DASD is not ALWAYS half-track blocking. With an LRECL of 9333, for instance, the most efficient BLKSIZE for 3390 DASD ( at half track or less ) is 9333. With a BLKSIZE of 9333 you can fit 1 record per block, 5 blocks per track, which is 5 records per track. With a BLKSIZE of 18666, you get 2 records per block, but only 2 blocks per track, yielding only 4 records per track. At a BLKSIZE of 27999 you get 3 records per block, but only 1 block per track, yielding only 3 records per track. You could go to a BLKSIZE of 55998 ( full track blocking ) to get 6 records per block/track which would be most efficient for 3390 DASD. At any rate, do not assume that half-track blocking is ALWAYS the most efficient.

[Bill Dennis]

kolusu,
I must take exception to your response on the 4000 byte blocks.

[blueash]

Oops i forgot to divide by 15 at both places, but as Bill pointed out in case of LRECL=4000, there would not be 2 records/track, rather there would be 13 records/track.

So in this scenerio as far as space is concerned BLKSIZE=4000 would be more efficient then BLKSIZE=24000.

I guess it has also to do with I/O optimizations.

Try one more thing for LRECL=2000, BLKSIZE which system gives is 18000 and not 26000 as by the above formula.

There is something more to this SMS algorithm of IBM

[kolusu]

Bill Dennis,

Thanks for correcting me. I apolozise for posting the wrong info

Kolusu

[Premkumar]

RonB said

[RonB]

Whoa! Mea culpa! The IBM 3390 Storage Manual ( GC26-4574-## ) has a table, at this link 3390 DASD Table. That table shows a max data length of 56,664. I just got brain-numb and forgot that that data length is more theoretical than practical. Thanks for the reminder.

[Bill Dennis]

blueash,
please see the 3390 DASD table link in Ron's post. You'll see that the 4000 blksize allows only 12 blks per trk, not 13. This is because of track overhead space wasted between blocks. Smaller blocks = more wasted space!

For the example large lrecl 0f 4000, either 24000 or 4000 blksize gets you 12 per trk.

Bill

[blueash]

Thanks for correction Bill.

Ron this table is quite helpful, thank you.

[Cogito-Ergo-Sum]

This thread has been really very informative.

I have a concern. I allocated a PS dataset, LRECL=80, RECFM=FB using IEFBR14. If the half-track blocking method were to be the best method, then, for a 3380 device, the BLKSIZE must have been 23440. But, when allocated by IEFBR14, the BLKSIZE comes out to be 27920.

In the first case, there would have been 293 records per block. In the latter case, there would be 349. No wonder, allowing the system to mind it's own business, results in a better BLKSIZE!

However, using IEFBR14, I was able to allocate the dataset with BLKSIZE=32720. This means, 409 records per block. Why is BLKSIZE of 32720 ineffecient wrt BLKSIZE of 27920?

How do I proceed to calculate the space for a dataset LRECL=80, RECFM=FB and number of records close to 10000? Can I assume, that 1 track contains 349 records (in case of system calculated BLKSIZE) or 409 (in case of max possibility)? Because, looking at the system calculated BLKSIZE, it seems the range that it took was,

[kolusu]

cogito,
A 3390-n device has a capacity of 56,664 bytes per track, of which 55,996 bytes are accessible by applications programmers.

Well you can create a DASD file with the largest blocksize of 32,760, which is fine for tapes, but would be quite wasteful on DASD, as 55,996 - 32760 = 23,236 bytes left over, and because tracks can't be shared between other files, that leftover space would just be wasted. So, 55,996/2=27,998, which is half-track blocking, the most space-efficient blocksize to use on 3390's. If you have 3380 devicetypes in your shop, the maximum half-track blocksize is 23,476.

I bet your shop has 3390-n device type. That is the reason as for the blocksize to be 27,920 using the half-track-blocksize

If you shop has indeed 3380-n device type,then your blocksize would have been 23,440 using the half-track-blocksize

Hope this helps...

cheers

kolusu

[Cogito-Ergo-Sum]

You are right, Kolusu. I am sorry, I must have checked that.

But, why BLKSIZE of 32720 ineffecient wrt BLKSIZE of 27920?
_________________
ALL opinions are welcome.

Debugging tip:
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
-- Sherlock Holmes.

[kolusu]

Cogito,

Let me go over it for you once again.Let us say we have a file with the following attributes.