|
|
| Author |
Message |
jonna
New User
Joined: 18 Apr 2005
Posts: 8
|
|
|
|
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 |
|
 |
References
|
 Posted: Fri Jul 04, 2008 12:18 pm Post subject: Re: BLKSIZE is ZERO in JCL |
|
|
|
|
dick scherrer
Global Moderator
Joined: 23 Nov 2006
Posts: 7437
Location: 221 B Baker St
|
|
|
|
Hello,
No. But why would you ask? Has something strange happened? |
|
| Back to top |
|
|
jonna
New User
Joined: 18 Apr 2005
Posts: 8
|
|
|
|
| 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 |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 444
|
|
|
|
Hi,
if data is lost it will definitely run quicker. 
Gerry |
|
| Back to top |
|
|
dick scherrer
Global Moderator
Joined: 23 Nov 2006
Posts: 7437
Location: 221 B Baker St
|
|
|
|
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. . .  |
|
| Back to top |
|
|
Garry Carroll
Active User
Joined: 08 May 2006
Posts: 130
Location: Dublin, Ireland
|
|
|
|
| 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  |
|
| Back to top |
|
|
Robert Sample
Senior Member
Joined: 06 Jun 2008
Posts: 327
Location: Atlanta, GA
|
|
|
|
| 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 |
|
|
Pedro
Active User
Joined: 01 Sep 2006
Posts: 296
Location: work
|
|
|
|
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 |
|
|
Anuj D.
Senior Member
Joined: 22 Apr 2006
Posts: 1638
Location: Mumbai, India
|
|
|
|
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 |
|
|
Anuj D.
Senior Member
Joined: 22 Apr 2006
Posts: 1638
Location: Mumbai, India
|
|
|
|
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 |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 2893
Location: Brussels once more ...
|
|
|
|
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 |
|
|
Garry Carroll
Active User
Joined: 08 May 2006
Posts: 130
Location: Dublin, Ireland
|
|
|
|
| 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 |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 2893
Location: Brussels once more ...
|
|
|
|
| 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  |
|
| Back to top |
|
|
revathitcs
New User
Joined: 09 Jul 2008
Posts: 1
Location: chennai
|
|
|
|
| BLKSIZE =0 |
|
| Back to top |
|
|
dick scherrer
Global Moderator
Joined: 23 Nov 2006
Posts: 7437
Location: 221 B Baker St
|
|
|
|
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 |
|
|
|
|
