View previous topic :: View next topic
|
Author |
Message |
jonna
New User
Joined: 18 Apr 2005 Posts: 9
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
No. But why would you ask? Has something strange happened? |
|
Back to top |
|
|
jonna
New User
Joined: 18 Apr 2005 Posts: 9
|
|
|
|
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: 1702 Location: Australia
|
|
|
|
Hi,
if data is lost it will definitely run quicker.
Gerry |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
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
Senior Member
Joined: 08 May 2006 Posts: 1193 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
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
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
Global Moderator
Joined: 01 Sep 2006 Posts: 2546 Location: Silicon Valley
|
|
|
|
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 Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 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 Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 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
esj.com/article.aspx?ID=5220025647PM |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
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
Senior Member
Joined: 08 May 2006 Posts: 1193 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: 8797 Location: Welsh Wales
|
|
|
|
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
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
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 |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
revathitcs wrote: |
BLKSIZE =0 |
And you win the smallest answer of the month award... |
|
Back to top |
|
|
Guru Bob
New User
Joined: 31 Jan 2008 Posts: 21 Location: Malaysia
|
|
|
|
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 |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
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 |
|
|
Suresh Shankarakrishnan
New User
Joined: 11 Jul 2008 Posts: 42 Location: USA
|
|
|
|
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 |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006 Posts: 1702 Location: Australia
|
|
|
|
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 |
|
|
Guru Bob
New User
Joined: 31 Jan 2008 Posts: 21 Location: Malaysia
|
|
|
|
Terry
I have been playing with BUFNO and being a fan of 1/2 track blocking and knowing the benefit I was playing with BUFNO to see if it does or does not improve throughput. Previuosly I thought also that BUFNO had no effect but I am finally proven wrong.
Setting BUFNO to 5, 30 and 15 showed remarkedly different results in the ELAPSED time with 1 minute 35 secs and then 28 seconds and then 44 seconds for BUFNO=15 respectively. There is no difference in the number of EXCPS which is exactly what I expect. BUFNO 30 show me the best decrease in execution time being some 30% of the BUFNO=5 settings and BUFNO=15 was only 40% reduction in BUFNO execution times. I ran this 5+ times to prove thhe results.
I used IDCAMS 2 SEQUENTIAL FILES of 600+ cylinders) for my testing and will today use a COBOL program and a EASYTRIEVE Program also just to confirm.
Using 27997 for the BLKSIaze is frought with danger as pointed out. WHy not use the BLK3390 command instead? I also assume that that site does not use SMS else you would not even have to specify BLKSIZE parameter in the JCL. COding the BLKSIZE makes it difficult to change to a new device later or even CART usage. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Although you ran 5+ tests, the job mix was most likely different in each case. Improved elapsed time is tough to measure because of job mix. I'd like to see what EXCP results you get with varying block sizes. I'd test it myself if I had access to a mainframe. I'm not surprised that you found no difference in EXCPs with varying BUFNO parameters. That was my experience also. |
|
Back to top |
|
|
Guru Bob
New User
Joined: 31 Jan 2008 Posts: 21 Location: Malaysia
|
|
|
|
Terry
I know from previous tests that we run during training classes smaller blksizes (and production fixes) dramatically increase the EXCP count. I only recommend 1/2 track blocking or for large LRECL 1/3 track blocking.
Basically any BLKSIZE between 19K-25K on a 3390 is a waste of DASD. |
|
Back to top |
|
|
Guru Bob
New User
Joined: 31 Jan 2008 Posts: 21 Location: Malaysia
|
|
|
|
To go back to the original post and the requirement.
Thre is n=more to tuning than just changing the BLKSIZE parameter - IMS DB/DC tuning if you run it?
VSAM tuning if you run it?
DB2 tuning if you run it?
More benfit can be achieved by tuning VSAM than BLKSIZE usually unless the BLKSIZE is really bad.
COBOL ensure that BLOCK CONTAINS 0 RECORDS is coded
BACKUPS and RESTORES using SORT or ADRDSSU or IDCAMS all parmaterised correctly (including BUFND,BUFNI,BUFNO etc were permitteed) will assist greatly. SOunds like a small patch to a big problem.
Have you confirmed with your SYSPROG/DASD administrarot if SMS is running for all QSAM files or only some. Do you still code VOL=???? or omit this parameter? |
|
Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006 Posts: 1702 Location: Australia
|
|
|
|
Hi Guru Bob,
Quote: |
WHy not use the BLK3390 command instead? |
The above command is only site specific.
Gerry |
|
Back to top |
|
|
|