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.


On Fri, 4 May 2007 20:41:54 +0800 Johnny Luo <[EMAIL PROTECTED]>
wrote:

:>I'm learning QSAM and  I found one strange(to me) behaviour of BLKSIZE
:>parameter.

:>It's a very simple program:
:>
:>.............
:>          OPEN (INVMAST,INPUT)
:>          GET INVMAST
:>CLO   CLOSE (INVMAST)
:>.............
:>INVMAST  DCB DDNAME=INVMAST,DSORG=PS,MACRF=GL,EODAD=CLO,BLKSIZE=32750
:>............

:>JCL to run it:
:>....
:>INVMAST DD DISP=SHR,DSN=DMAP001.FILE.INVMAST
:>....

:>The input data set contains four records and its attribute is: PS, FB,
:>LRECL=50, BLKSIZE=32700.
:>It's SMS-managed, too.

:>Here I want to override BLKSIZE in DCB macro and see what will happen. (Why
:>I do this? Because I don't fully understand the BLKSIZE parm so I want to
:>test it. )

:>I tried many values from 200 to 32750 and the program just runs well.
:>However, when I decrease the BLKSIZE to 150,  I got a S001 abend. The Fault
:>Analyzer gives me the following description:

:>A system abend 001 occurred in module IGC0005E at offset
:>X'1366'.
:>The abend was caused by machine instruction 05EF (BRANCH AND LINK) in module

:>TEST CSECT TEST at offset X'34'.

:>Why 200 works and 150 can not? I notice that the input file contains four
:>records (4*50 =200)  so I add an additional one to it.  This time 200 also
:>gives me a S001 abend! And after i increase the BLKSIZE to 250, it runs
:>normally.

:>(The program is tested on z/os 1.7)

:>What I really don't understand is the relationship of BLKSIZE parm and the
:>physical structure of the data set.  In ISPF DSLIST I can see a data set has
:>BLKSIZE=32720. Does this mean the physical blocksize of the data set is
:>32720? If it's true,  when reading it, why we're allowed to spefify BLKSIZE
:>parm in DCB macro?

:>i also searched the archive and found out that for PDSE it's physical
:>bolocksize is always 4K and the BLKSIZE parm we specify is called 'logical
:>blocksize' - it only has impact on buffer size of access method. How about
:>other data sets?

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
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

Reply via email to