Johnny Luo wrote:
Thanks, Binyamin.
I have two extra questions after reading your reply. Sorry for my
ignorance.
The first is what actually determines the physical blocksize? You told me
BLKSIZE parm is a maxmimum value for QSAM. So I guess if I write 105
records
to a data set with BLKSIZE=20, I'll get five 20-byte physical blocks and
one
5-byte block(if no padding occurred.) Right?
Logical records are blocked up before being written
from memory to tape or DASD. This is because physical
I/O, the building of the channel program, the scheduling
of an I/O operation, the physical transfer, and handling
the interrupt that says the operation is done - all takes
a lot of time.
So if we gather a block of records together, we can transfer
a buffer's worth of logical records with only one physical
I/O. BLKSIZE is the size of your buffer. It is _not_ how
many records you are transferring, but how many bytes you
are transferring.
So if your records are 150 bytes long, you might typically
block them 10 records to a block, so your buffer size (and
BLKSIZE) would be 150 * 10 = 1500 bytes.
Most programmers tend to make block size too small; a block
can be any multiple of record size up to 32K bytes, so
larger blocks tend to be more efficient. This is why IBM
added SDB (System Determined Blocksize) a number of years
ago: when you create a QSAM file with the FB attribute
and request a BLKSIZE of 0 (or omit it, which is the same
thing), the system will choose a blocksize that will be
optimal; and it does a good job of this. [For example, there
are other considerations if you are using DASD: some block
sizes make use of track sizes better than others; with
tape, bigger is always better; in fact, recently you can
use large block sizes for tape - the designed max is 2GB,
although the current implementation only allows a much
smaller number, 256KB blocks.]
For input, if you specify BLKSIZE=0 (or omit it), then
OPEN uses the BLKSIZE value in the label of the data set
to determine the block size used when the file was created.
Hope this helps.
The second is concerning the minimal physical unit a program can process on
zos. I know acess method macros like QSAM are still at the high level. From
what you told me, I guess the minimal unit QSAM can process is one physical
block. It cannot read, say, half physical block. And that's why my program
abends: the buffer size cannot hold a physical block.
On 5/4/07, Binyamin Dissen <[EMAIL PROTECTED]> wrote:
The blocksize parameter tells QSAM the maximum size of the blocks to be
read
or written.
But since there are only four records in the dataset, the physical
blocksize
(on DASD) is 200 since QSAM does not pad.
By overriding the value to 200-32750 you are instructing QSAM as to the
maximum size - and since the block is 200 bytes long the physical I/O
succeeds.
When you set the blocksize below 200 the physical I/O operation gets an
error
due to a too long block.
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
