GAVIN Darren * OPS EAS wrote:
I beg to differ right back, the default buffering is 2, according to the
IBM Manuals. Your shop might have changed that through SMS. Some places
do that.
Hmmm. Which manuals? Here are some excerpts:
JCL Ref.:
under DD DATA it says, in part:
"JES3 will honor the BUFNO specification for
SYSIN data sets. Values between 0 and 255
are accepted. When 0 or 1 is specified, a
default of 2 is used."
under DD DCB it says, in part:
"If the DCB BUFNO subparameter is not specified
in the program, five buffers are assigned."
I was astounded to see that BUFNO is not listed as a
standalone DD statement parameter, like most of the
DCB parameters have been for many years! I know I've
used BUFNO= on DD statements without the DCB parm
itself. Wonder why it's not documented as such?
Using Data Sets:
Under "Constructing a Buffer Pool Automatically":
"For QSAM, BUFNO can be specified or permitted to
default in the following ways:
* n — Extended format but not compressed format and
not LBI (n = 2 × blocks per track × number of
stripes)
* 1 — Compressed format data set, PDSE, SYSIN, SYSOUT,
SUBSYS, UNIX files
* 2 — Block size > =32 760 3—2540 Card Reader or Punch
* 5 — All others"
Macros for Data Sets:
For DCB for BDAM:
"If dynamic buffering is requested when an existing
direct data set is being processed, BUFNO is optional;
if omitted, the system acquires two buffers."
For DCB for BPAM:
"The default value is zero." for BUFNO
For DCB for BSAM:
"The default value is zero." for BUFNO
For DCB for QSAM:
"If BUFNO is omitted and the buffers are
acquired automatically, the system acquires:
* 1 for a PDSE member
* 1 for an extended format data set in compressed format
* 1 for a UNIX file
* (2 * number of stripes * number of blocks per track)
for an extended format data set if it is not in the
compressed format
* 2 if the block size is greater than or equal to 32768
* 3 for an IBM 2540 card reader or card punch
* 5 for other types of devices or data sets"
New in z/OS 1.9, if you use a DCBE and code MULTDSN=,
the system uses an alternate methodology to compute
the number of buffers to allocate
<Snip>In truth, the physical geometry is largely
Unknown and most of the data is actually returned from some level of
cache,
where blocksizes mean nothing (since gaps don't exist).</Snip>
And I will differ with you on this point as well, as I've done my own
testing of Buffering sizes based on Data Transfer Sizes (that are
readily available in the manuals) and that matching them is the most
efficient way to do I/O. Once the Data leaves the cache of the devices,
it is transferred at a certain size/rate. Matching that size with
additional buffers means that less actual I/O requests are made to the
channel.
Darren
-----Original Message-----
As to the BLKSIZE and LRECL parameters being archaic, they really are
not obsolete.
They are there for efficiency reasons.
Disk I/O is done on physical Blocks, not at the record level, so the
larger the block size the more Efficient I/O is. Each record read is
retrieved directly out of the program's I/O buffer(s) that matches the
Block Size (2 Buffers by default) For even more efficient I/O one can
use BUFNO on the DD to increase the buffering. Usually you want to
enough buffering to hold a size that matches the transfer data package
size of the device the file is on. (Cartridge drives are typically
64K,
Virtual Tape drive 128K, and 3390's are based on their track size (per
model), having enough buffering to return a full cylinder on DASD is a
good way to go or by multiples of full tracks.
I beg to differ. All the points that are being raised are indicative of
knowing what the underlying device geometry actually is, to try and gain
efficiency from I/O operations. In truth, the physical geometry is
largely
unknown and most of the data is actually returned from some level of
cache,
where blocksizes mean nothing (since gaps don't exist). A programmer
only
needs to specify the LRECL and RECFM (which exist as stand-alone parms),
so
I don't understand why BLKSIZE is even discussed unless people simply
aren't
using the existing facilities.
BTW. IIRC, the default buffer number is 5 for sequential files.
Adam
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
