mainframe optimum choice



Post anything related to mainframes (IBM & UNISYS) if not fit in any of the above categories

mainframe optimum choice

Postby ndashore20 » Sun Sep 25, 2016 10:38 pm

Please help me to understand why mainframe choose 27920 as a optimum block size ?? on what basis this size is choosen??
ndashore20
 
Posts: 14
Joined: Sun Sep 25, 2016 10:28 pm
Has thanked: 13 times
Been thanked: 0 time

Re: mainframe optimum choice

Postby prino » Sun Sep 25, 2016 11:13 pm

Optimum blocksize for what?

An FB(123) dataset? Not!
A VB(123) dataset? Not!
AN FB(23456) dataset? Not!
Robert AH Prins
robert.ah.prins @ the.17+Gb.Google thingy

These users thanked the author prino for the post:
ndashore20 (Mon Sep 26, 2016 10:19 am)
User avatar
prino
 
Posts: 635
Joined: Wed Mar 11, 2009 12:22 am
Location: Vilnius, Lithuania
Has thanked: 3 times
Been thanked: 28 times

Re: mainframe optimum choice

Postby Robert Sample » Sun Sep 25, 2016 11:49 pm

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)
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: mainframe optimum choice

Postby steve-myers » Mon Sep 26, 2016 10:50 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)
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times

Re: mainframe optimum choice

Postby ndashore20 » Wed Oct 24, 2018 12:54 pm

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.

:)
ndashore20
 
Posts: 14
Joined: Sun Sep 25, 2016 10:28 pm
Has thanked: 13 times
Been thanked: 0 time

Re: mainframe optimum choice

Postby willy jensen » Wed Oct 24, 2018 1:26 pm

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)
willy jensen
 
Posts: 455
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 69 times

Re: mainframe optimum choice

Postby NicC » Wed Oct 24, 2018 4:48 pm

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.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic

These users thanked the author NicC for the post:
ndashore20 (Thu Oct 25, 2018 7:06 am)
NicC
Global moderator
 
Posts: 3025
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisies (almost)
Has thanked: 4 times
Been thanked: 136 times

Re: mainframe optimum choice

Postby ndashore20 » Thu Oct 25, 2018 7:05 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
ndashore20
 
Posts: 14
Joined: Sun Sep 25, 2016 10:28 pm
Has thanked: 13 times
Been thanked: 0 time

Re: mainframe optimum choice

Postby NicC » Thu Oct 25, 2018 12:43 pm

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.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 3025
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisies (almost)
Has thanked: 4 times
Been thanked: 136 times

Re: mainframe optimum choice

Postby willy jensen » Thu Oct 25, 2018 2:24 pm

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
willy jensen
 
Posts: 455
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 69 times

Next

Return to All other Mainframe Topics

 


  • Related topics
    Replies
    Views
    Last post