Page 1 of 2

mainframe optimum choice

PostPosted: Sun Sep 25, 2016 10:38 pm
by ndashore20
Please help me to understand why mainframe choose 27920 as a optimum block size ?? on what basis this size is choosen??

Re: mainframe optimum choice

PostPosted: Sun Sep 25, 2016 11:13 pm
by prino
Optimum blocksize for what?

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

Re: mainframe optimum choice

PostPosted: Sun Sep 25, 2016 11:49 pm
by Robert Sample
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.

Re: mainframe optimum choice

PostPosted: Mon Sep 26, 2016 10:50 am
by steve-myers
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?

Re: mainframe optimum choice

PostPosted: Wed Oct 24, 2018 12:54 pm
by ndashore20
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.

:)

Re: mainframe optimum choice

PostPosted: Wed Oct 24, 2018 1:26 pm
by willy jensen
This will happen if the dataset was never opened. Add DSORG=PS to the JCL when you allocate the dataset to generate the blksize.

Re: mainframe optimum choice

PostPosted: Wed Oct 24, 2018 4:48 pm
by NicC
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.

Re: mainframe optimum choice

PostPosted: Thu Oct 25, 2018 7:05 am
by ndashore20
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

Re: mainframe optimum choice

PostPosted: Thu Oct 25, 2018 12:43 pm
by NicC
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.

Re: mainframe optimum choice

PostPosted: Thu Oct 25, 2018 2:24 pm
by willy jensen
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
//A   EXEC PGM=IEFBR14                                
//DD1  DD DSN=Z.TEST.FB80A,DISP=(,CATLG),            
//        UNIT=SYSDA,SPACE=(80,(1,1),RLSE),AVGREC=K,  
//        RECFM=FB,LRECL=80,BLKSIZE=0                
//DD2  DD DSN=Z.TEST.FB80B,DISP=(,CATLG),            
//        UNIT=SYSDA,SPACE=(80,(1,1),RLSE),AVGREC=K,  
//        RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS        

It allocates datasets as seen in ISPF 3.4
- Enter "/" to select action                 Dsorg  Recfm  Lrecl  Blksz
-----------------------------------------------------------------------
 Z.TEST.FB80A                                       FB        80      0
 Z.TEST.FB80B                                 PS    FB        80  27920