IBM Mainframe Forum

Please help me to understand why mainframe choose 27920 as a optimum block size ?? on what basis this size is choosen??

Optimum blocksize for what?

An FB(123) dataset? Not!
A VB(123) dataset? Not!
AN FB(23456) dataset? Not!

These users thanked the author prino for the post:

ndashore20 (Mon Sep 26, 2016 10:19 am)

The system will generally use half track blocking on a 3390. Since the half-track size is 27,998 the system will define a block size as close to this without going over. For variable length records, 27998 can be used. For fixed length records, divide 27998 by the record length and use the integer portion of the result (discard the fraction); multiply the record size by the resulting integer to get the block size.

These users thanked the author Robert Sample for the post:

ndashore20 (Mon Sep 26, 2016 9:56 am)

Let me expand Mr. Sample's post.

When System/360 DASD was originally defined device capacities were rather limited. The IBM 2314 disk device, for example had a track capacity of 7294 bytes, if I remember correctly. The most effective use of these devices could be achieved when the BLKSIZE was close to 7294, so 7280 (INT(7294/80)*80) would be "optimal" for the 2314.

By the 1980s devices could store more than 32768 bytes on a track. Since data management has a restriction of 32760 bytes in a record, full track records were no longer possible; so the decision was made that an "optimal" record size would be defined as whatever value <= 32760 that permited 2 records on a track. As Mr. Sample says, this works out to 27,998 bytes per track for 3390 type devices, even the simulated 3390s now commonly used, and data sets containing 80 byte card images should use BLKSIZE=27920.

No reasonable person should have to memorize this garbage, much less do the arithmetic, so the system will automatically figure this out for you when you do not specify a BLKSIZE.

OK?

These users thanked the author steve-myers for the post:

ndashore20 (Thu Oct 25, 2018 7:12 am)

yupp.. I got the mechanism behind picking the optimum blocksize. Recently I was working on one JCL and found one discrepancy while defining for BLKSIZE=0. I was posting my query under same topic.

The problem is while creating the dataset in one step and checking the same dataset for empty in next step. The job is abending with S013 abend in second step. It was showing return code as 34.

I create the dataset using below PARM:
//STEP1 EXEC PGM=xxxx
.
.
//DD1 DSN=TSLCLIIM.XXXX.YYYY,
// DISP=(NEW,CATLG,DELETE),
// UNIT=PERM,
// SPACE=(TRK,(1,6),RLSE),
// DCB=(RECFM=FB,LRECL=94,BLKSIZE=0)
//*
.
.

//STEP2 EXEC PGM=ALCOND,PARM='INPUT'
//INPUT DSN=TSLCLIIM.XXXX.YYYY,DISP=SHR
//OUTPUT DUMMY,DCB=BLKSIZE=80,
//XCONSOLE SYSOUT=*
//*

The above step has different return codes for the file if it is empty or not. The above empty check step is the standard one used in our system mostly.

I was expecting the system will pick the optimum block size for this dataset. when I browse the above dataset. it was showing invalid block size. when I see the info of the dataset, it was showing block size as 0. I don't think so it is a correct block size. it should have some non zero value.

Can you please look into the above definition and let me know if something is wrong in the above definition. What could be the cause of error?

Thanks in advance.

This will happen if the dataset was never opened. Add DSORG=PS to the JCL when you allocate the dataset to generate the blksize.

These users thanked the author willy jensen for the post:

ndashore20 (Thu Oct 25, 2018 7:05 am)

It is advisable to always open and close data sets. We had a case where this was not done and the space allocated to a report was that used by a part of the previous days reporting. Fortunately I spotted it before the reports ere sent out.

These users thanked the author NicC for the post:

ndashore20 (Thu Oct 25, 2018 7:06 am)

I agree with this. As it is new dataset, SMS do not have information regarding the dataset and hence unable to provide the optimum BLKSIZE. My concern is I am using the same dataset parm values in TEST region too. Test Job runs before the IMPL job. How the TEST region job works fine whereas for test also the dataset is new and SMS do not have any info at that time too. The concept is little bit shacking for me

Almost cetainly your test "region" is not an identiacl copy of your production "region". Talk with your support as they know if any differences would result in the behaviour you experience.

As it is new dataset, SMS do not have information regarding the dataset and hence unable to provide the optimum BLKSIZE

Well, if you use the DSORG parameter it does,as is demonstrated by this job

It allocates datasets as seen in ISPF 3.4