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
 

 

BLKSIZE is ZERO in JCL
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
jonna

New User


Joined: 18 Apr 2005
Posts: 9

PostPosted: Fri Jul 04, 2008 12:18 pm    Post subject: BLKSIZE is ZERO in JCL
Reply with quote

HI,

If I will male BLKSIZE is ZERO in JCL for perticular dataset will it loose any data on output file.
Thanks,
Mahee
Back to top
View user's profile Send private message

dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Jul 04, 2008 12:23 pm    Post subject:
Reply with quote

Hello,

No. But why would you ask? Has something strange happened?
Back to top
View user's profile Send private message
jonna

New User


Joined: 18 Apr 2005
Posts: 9

PostPosted: Fri Jul 04, 2008 12:30 pm    Post subject:
Reply with quote

dick scherrer wrote:
Hello,

No. But why would you ask? Has something strange happened?


We are planing some performance improvements from my existing datasets which having BLKSIZE greater than zero. If you will change BLKSIZE zero it will take less CPU time. Just I need to confirm if I will do this change it will cause any problem like data loss in output datasets. Thanks for your reply.
Back to top
View user's profile Send private message
gcicchet

Senior Member


Joined: 28 Jul 2006
Posts: 1703
Location: Australia

PostPosted: Fri Jul 04, 2008 12:35 pm    Post subject:
Reply with quote

Hi,

if data is lost it will definitely run quicker. icon_lol.gif


Gerry
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Jul 04, 2008 1:06 pm    Post subject:
Reply with quote

Hello,

Quote:
If you will change BLKSIZE zero it will take less CPU time.
What source provided this information?

Quote:
if data is lost it will definitely run quicker.
That's just not right. . . icon_wink.gif
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 988
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Fri Jul 04, 2008 1:41 pm    Post subject:
Reply with quote

Quote:
If you will change BLKSIZE zero it will take less CPU time.


It's more likely to reduce elapsed time by reducing the number of EXCPs.

Quote:
Quote:
if data is lost it will definitely run quicker.
That's just not right. . . icon_wink.gif


I agree. The process of losing data (which I doubt would happen) can take just as long.

Garry 36_2_35.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7904
Location: Bellevue, IA

PostPosted: Fri Jul 04, 2008 8:53 pm    Post subject:
Reply with quote

Quote:
We are planing some performance improvements from my existing datasets which having BLKSIZE greater than zero. If you will change BLKSIZE zero it will take less CPU time. Just I need to confirm if I will do this change it will cause any problem like data loss in output datasets. Thanks for your reply.


Performance improvements will depend on what your current block size is. SMS-controlled datasets will use half-track blocking when BLKSIZE=0 is used in JCL. As long as the program can handle this (COBOL needs BLOCK CONTAINS 0 RECORDS, for example), there's no difference to the system whether BLKSIZE=????? or BLKSIZE=0 is coded. If the block size is already half-track blocking, you won't see any performance advantage to BLKSIZE=0. And unless the program expects a specific block size you won't lose any data no matter what block size is used.

What's the buffers set to (DCB=BUFNO=??)? In my experience, buffering has a much bigger impact on performance than block size (other than one record per block), and the default QSAM 5 buffers provides really bad performance. BUFNO=30 is typically a decent number and the memory increase usually doesn't impact the program.
Back to top
View user's profile Send private message
Pedro

Senior Member


Joined: 01 Sep 2006
Posts: 2019
Location: Silicon Valley

PostPosted: Fri Jul 04, 2008 9:58 pm    Post subject: Reply to: BLKSIZE is ZERO in JCL
Reply with quote

None of you made his point clear:
blksize=0 does not mean the blocksize will be zero. It tells the system to determine what the best blocksize is and use that. After the job runs, the dataset will have a proper blocksize.
Back to top
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Sat Jul 05, 2008 1:46 pm    Post subject:
Reply with quote

Hi,

Said bit differently..

BLKSIZE=0 can often cause problems if the dataset is not opened and closed unless your SMS environment has been correctly established.

If it has not, then the BLKSIZE=0 will be honoured and the dataset will have that attribute, which makes the dataset invalid for processing by DFHSM, or whatever other ILM software you use.

The correct coding is RECFM=xx,LRECL=nnn.
Back to top
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Sat Jul 05, 2008 1:50 pm    Post subject:
Reply with quote

Hi,
jonna wrote:
We are planing some performance improvements from my existing datasets which having BLKSIZE greater than zero. If you will change BLKSIZE zero it will take less CPU time. Just I need to confirm if I will do this change it will cause any problem like data loss in output datasets.
Check this article, might provide you some insght regarding the BLKSIZE

http://esj.com/article.aspx?ID=5220025647PM
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Tue Jul 08, 2008 6:21 pm    Post subject:
Reply with quote

Mmmmmmmmmmmmmm, BUFNO, with the modern DASD subsystems of today the BUFNO parameter is not really that useful, asuming that the DASD subsystems are set up correctly.

Using FASTWRITE and the DASD subsystem cache efficiently then the majority of the work will be handled by the subsystem itself ratherthan by z/OS.
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 988
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Tue Jul 08, 2008 7:20 pm    Post subject:
Reply with quote

Quote:
Mmmmmmmmmmmmmm, BUFNO, with the modern DASD subsystems of today the BUFNO parameter is not really that useful, asuming that the DASD subsystems are set up correctly.


I would have thought that BUFNO can be quite useful where the BLKSIZE is less than optimum as it can facilitate optimization of the dataflow on the channel(s). Where, say, BLKSIZE is half the optimum size, doubling the BUFNO should result in the movement of that amount of data in a single operation as would have been moved had the BLKSIZE been optimized.

Garry.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Wed Jul 09, 2008 12:36 pm    Post subject:
Reply with quote

Garry Carroll wrote:
Quote:
Mmmmmmmmmmmmmm, BUFNO, with the modern DASD subsystems of today the BUFNO parameter is not really that useful, asuming that the DASD subsystems are set up correctly.


I would have thought that BUFNO can be quite useful where the BLKSIZE is less than optimum as it can facilitate optimization of the dataflow on the channel(s). Where, say, BLKSIZE is half the optimum size, doubling the BUFNO should result in the movement of that amount of data in a single operation as would have been moved had the BLKSIZE been optimized.

Garry.

Yeah, silly me .............. I had made the rather rash assumption that all of your above points would have been done anyway. I have found that the default of BUFNO=5 hasn't caused me any problems yet icon_confused.gif
Back to top
View user's profile Send private message
revathitcs

New User


Joined: 09 Jul 2008
Posts: 1
Location: chennai

PostPosted: Wed Jul 09, 2008 10:38 pm    Post subject: Reply to: BLKSIZE is ZERO in JCL
Reply with quote

BLKSIZE =0
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Jul 10, 2008 12:02 am    Post subject:
Reply with quote

Hello revathitcs and welcome to the forums,

Is your post a question or are you offering some kind of information?

When you post, you need to use complete sentences. . .
Back to top
View user's profile Send private message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Thu Jul 10, 2008 12:44 pm    Post subject: Re: Reply to: BLKSIZE is ZERO in JCL
Reply with quote

revathitcs wrote:
BLKSIZE =0

And you win the smallest answer of the month award...
Back to top
View user's profile Send private message
Guru Bob

New User


Joined: 31 Jan 2008
Posts: 21
Location: Malaysia

PostPosted: Mon Jul 28, 2008 2:18 pm    Post subject:
Reply with quote

My understanding is that 240K (old channel data xfer size if not FICON or ESCON) is the optimum BUFFEr size required to cause no delay in READ/WRITEs for QSAM files.

240K is for a 3390 is 9 buffers at the maximum optimum BLKSize of 27998. Hence coding BUFNO=10 for any files with >24,000 bytes for a BLKSIZE will be cool. I believe that hence allocating twice the number of buffers from the 240K size will allocate you two sets of buffers one seat being read/written and the other still haveing records read or written to them simultaneoulsy.

WIth FICON and SANs etc I am not sure how tru this is now.

DATA (QSAM ) buffers reside for COBOL program where ever you have specified your DATA(31) above the line or DATA(24) below the line (hence a severe limit on the number of BUFNO values (S80A,S878 abends) ). AMODE and RMODE of the program also influence this.
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1238
Location: Richfield, MN, USA

PostPosted: Mon Jul 28, 2008 9:00 pm    Post subject:
Reply with quote

Agree with expat. I also thought increasing BUFNO would be beneficial, but notso according to a performance analyst I once talked to. Increasing BUFNO will not decrease EXCPs which is the elapsed-time-hogger. BLKSIZE has much more of an impact on reducing EXCPs, and therefore elapsed time, than BUFNO. You can see this for yourself by testing with various combinations of both. Also, half-track blocking is usually what SDB picks, but not always. The bigger the LRECL, the better the chances are that something like 1/3-track blocking might be chosen.
Back to top
View user's profile Send private message
Suresh Shankarakrishnan

New User


Joined: 11 Jul 2008
Posts: 42
Location: USA

PostPosted: Mon Jul 28, 2008 10:13 pm    Post subject:
Reply with quote

http://www.ibmmainframes.com/about22889.html

Although the above link states 27998, we use 27997 to get the block size of a dataset.

Example , lrecl = 133.

27997/133 = 210 (get the integer value by truncating the decimal point, not rounding off)

210 * 133 = 27930

This relates specifically to creating blocksize, not sure if this helps though.
Back to top
View user's profile Send private message
gcicchet

Senior Member


Joined: 28 Jul 2006
Posts: 1703
Location: Australia

PostPosted: Tue Jul 29, 2008 4:41 am    Post subject:
Reply with quote

Hi,

may I ask why you are using 27997 and not 27998.

If you have a file with LRECL=13999 RECFM=FB you would be wasting a fair bit of space.

Blocksize of 27997 would give you 3 records per track
Blocksize of 27998 would give you 4 records per track.


I picked LRECL of 13999 as an example as it is half of 27998.


Gerry
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
Goto page 1, 2  Next
Page 1 of 2

 

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 Changing blksize on JCL is changing a... nigelosberry COBOL Programming 19 Fri Jul 13, 2012 5:22 pm
No new posts Output files with DUMMY,DISP=SHR and ... krishna_ragav JCL & VSAM 4 Thu Aug 18, 2011 11:11 am
No new posts How to calculate SIZE of DSN on Tape ... praveensinha JCL & VSAM 4 Thu Nov 18, 2010 3:29 pm
No new posts Error Msg - INVALID DATA SET ATTRIBUT... dick scherrer DFSORT/ICETOOL 5 Sat Sep 25, 2010 4:26 pm


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