How does BUFNO works? How to calculate optimal BUFNO ?

poshabrar · New User Joined: 10 Jul 2006 Posts: 23

Hi all,

I am currently working on a re-engg project. In my current assignment... I am trying to bring down the

I/O time for all the datasets (sequential) by using the BUFNO.

1) How exactly the BUFNO works.. If this is assigned in JCL for a dataset... how does the Read stmt in

cobol pair with it.

2) I have a file with Record length 3000 bytes , block size 27000 how do i calculate the optimal BUFNO for

these kind of datasets.

3)Can BUFNO be used for SORTIN datasets for SYNCSORT or by default SYNCSORT calculates the optimal BUFNO by itself.

-Regards
Rahman.

Robert Sample · Posted: Sun Feb 28, 2010 10:20 am

1. BUFNO determines the number of buffers to assign to a particular DD name (data set). For QSAM (sequential) files, the default assignment is 5 buffers. When you execute a COBOL READ statement, the data is fetched from the data set (disk or tape or whatever) into a buffer and that buffer's data is what is actually available to COBOL. Note that a buffer is the size of a block, not the size of a record so the entire block is read into the buffer and one record at a time made available to your program. You can override the default BUFNO assignment via JCL parameter.

2. The record length doesn't matter for buffering. The block size is what determines the buffer size. Determining the optimal number of buffers usually involves your site support group as they may be aware of site requirements that could impact the value. I usually see good performance improvements up to one cylinder (30 27000 byte buffers) of buffer space; depending upon the machine and dasd speed more may be helpful but only testing will tell you for sure.

3. I'll let one of the SYNCSORT experts answer this.

dick scherrer · Posted: Sun Feb 28, 2010 10:22 am

Hello,

Usually, more improvement will be seen by using a better BLKSIZE rather than changing BUFNO. . .

At the top of the page is a link to "IBM Manuals" among which are the JCL Reference for multiple versions of the Operating System. Using the flashlight/tubelight at the top left, search for BUFNO.

1. Buffers are memory used to hold data after it is read from the media and before it is used by the program code. This is automatic and is outside control of the program.
2. I'm not aware of a particular calculation.
3. Suggest you ask Syncsort support if you cannot find what you need in the Syncsort documentation.

poshabrar · New User Joined: 10 Jul 2006 Posts: 23

Hi Robert /scherrer,

Thanks a lot for your quick response on my query.

I have been looking for some script that would give me an indept knowledge about this simple parameter..(BUFNO) i came accross the following :

***********************
If you really need to do I/O then at least do it as neatly as possible.

1) Use of BUFNO for sequential Datasets:

When dealing with sequential DASD datasets, MVS does some performance tuning behind your back. Instead of dealing in 1 block chunks it now deals in 5 block chunks. What this means is that for the following blocked datasets you actually deal with larger chunks of data.

BLKSIZE BUFNO=5

22000 110,000 bytes gotten per access

6160 30800 bytes gotten per access

Thus when reading a 22,000 byte blocked dataset, MVS really works with 110,800 bytes chucks by default. The objective being met here is to minimize the amount of requests made to MVS's I/O subsystem, an expensive option.

But is 5 buffers enough? In today's environment, the answer is simple => NO. You should consider coding more. Another factor that comes into play at this time is if you exceed multiples of 31 buffers or 249,856 total bytes, then MVS will break your request into 2 or more parts and do Parallel I/O thus reducing the amount of time required to run I/O bound jobs. For example a job that read 100,000 240 byte records blocked at 24,000 took 8 seconds to run, but with 33 buffers it took only 6.5 seconds. If this job did a lot of process between request for data records the response time would decrease more!

You must also recognize that by increasing the BUFNO your job now require extra MEMORY, which can have an impact on your run time. In fact coding too many buffer can slow things down. Never code BUFNO < 5 unless you really understand the implications, and finally do not over code BUFNO, if you dataset is only 100K in size, don't code 200K of buffer space.

Also don't bother with this parm for SORTIN, SORTWK, or SORTOUT (sort datasets). Sort does its own special I/O processing to reduce EXCP and coding BUFNO will only confuse it.

2) Better Blocking of datasets.

Yes 6160 is another magic number, recommended 10 odd YEARS ago. It no longer as any value other than a magic number. Try and get as close as possible to 22,340 for DASD datasets. This rule does not apply to TAPE where 32767 block area always optimal. As a side point watch blocksizes when you concatenate datasets.

***************************

Can any one tell me the numbers mentioned here as "MAGICAL" are really correct and will work out almost all the time??

enrico-sorichetti · Posted: Sun Feb 28, 2010 12:29 pm

Terry Heinze · Posted: Mon Mar 01, 2010 9:56 am

I'm fairly certain that both DFSORT and SYNCSORT use their own buffering and ignore what you've defined. I don't know about CA-SORT.

dneufarth · Posted: Mon Mar 01, 2010 11:49 pm

and today's DASD and virtual tape devices have controllers monitoring behavior of disk accesses and use their own controller cache to anticipate next reads and delayed writes to expedite/lessen time spent getting data to/from their actual physical devices.